Best approach to populating the Location table for multi-state health system

Blue · ‎09-17-2024

Has anyone come up with a good approach to populating the Location table to support IT Service Management functions like INCs, CHG, RITM, etc.?

How have you structured your location table, does it have a hierarchy?

Thanks

Manville · ‎09-17-2024

I like addresses at BOTH the building and campus level. or to indicate a primary building on a campus. You could do away with the primary building and address at campus level, but I like providing an intelligent default for someone just sending something to a campus. If the campus is really just not centralized to that point, then leave the location at the building level.

A floor is just a location with a location type of floor and a parent that is a building. A room has a parent of a floor. Suites could be an in between for floor and rooms.

I find a more granular typing to indicate purpose to a room to be very helpful: conference room, office, printer room, OR, ER, exam room, etc. This can help make you to align priority to particular rooms. fixing a device in an OR room is more important than fixing a device in a office space.

I like to name floors by combining the building name with the floor number. Floors can seem like a placeholder, but I find that floorplans can be very reliable so I like to attach them there. you can later do some fun things with floor plans: https://www.youtube.com/watch?v=wiebJJvP-Yw

keep in mind, you can also track other locations, like vendor locations and associate them with their companies. An interesting use case when you get into field ops or asset management. Not very important for ITSM though.

To create a floor or room, add the location type to your form, set the name and parent, and save. Full name field is the display label for the record. Usually this is done programmatically.

View solution in original post

Manville · ‎03-27-2025

yes, which is the display name of a room should always incorporate the name of its parent floor/room and why floors should incorporate the building name.

Blue · ‎09-17-2024

Also, what we have to solve for is how ticket types get routed to certain assignment groups based on location, specifically for work fulfilled by the at-the-elbow IT support team. Do you use location on a ticket to drive the a task to the right team?

Manville · ‎09-17-2024

we have a centralized service desk dispatching but I am with a single state provider. For a multi-state health system, I'd recommend a location based solution. Its pretty common.

here is where I see location based routing go wrong. Location based assignment should go by the nearest best match; It should NOT be an explicit match. Not every location should have a group.

if a group covers an entire state, the STATE should have the assignment group.
if a group covers a particular campus, the campus should have that assignment group
if a different group covers a particular building, that BUILDING should have the different group.
If a room in that building has a different group, that ROOM should have a different group.

When a location is set, your location assignment logic should check for an assignment group and then walk UP the parents until you find an assignment group.

This guarantees 100% coverage for all locations including present and future with an intelligent default. A new room or building pops up and your routing goes to a reasonably near team. Just make sure you have a catch all bucket assignment group in case you open up in a new state.

The other nice part of this is its very reliable to check your ticket history against your location assignment.

Blue · ‎09-17-2024

@Manville , so it sounds like you recommend against building a hierarchy of locations that groups locations based on regions the IT at-the-elbows team have design their support model against because it will impact the other modules?

Thanks

Manville · ‎09-17-2024

assignment logic is one of those things that can get very messy very fast. I recommend this model because its flexible enough to accommodate basically any level of granularity or vagueness while providing an intelligent default while also reliably providing reasonable data to correct your model if incorrect (location assignment group does not match task assignment group)

I think there are a few ways to solve the region based solution. first and simplest solution is to assign their locations to regional assignment groups. region based can be very fluid model with locations changing hands based on need. create each regional assignment group and assign them their locations.

A less flexible solution is to create a region location type and add it as a layer between other locations. the nice thing with this is that it can be added at any part of the hierarchy. However, I think this is needless detail that obfuscates your actual location.

I prefer the first solution because I don't think "regions" are a location. They are an assignment logic for resources to locations.