How to reflect org structure in ServiceNow for optimum effect? Business Units vs Departments vs Companies vs other org related tables

[Michal Sadowski]

Hi ITBM Superstars,

Here's another curveball from a real work-in-progress implementation.

We want to assign Projects and Demands to what the client calls Divisions and Business Units. Division is a parent of one or more business units in their org structure. 

We're looking at OOTB Business Unit & Department tables that sit idle in the client's instance and are there in Project and Demand forms OOTB. Plus there are OOTB Performance Analytics reports, interactive filters and other components based on these tables that we want to use in the future.

Problem 1 (easier) is the client wants table names to reflect their reality. So OOTB Business Unit would have to be relabelled Division and OOTB Department would have to be relabelled Business Unit...

Do you see any risks here?

Problem 2 (harder) is that the client's org structure is partially reflected in ITSM/CSM applications in both Domains and Companies tables. Unfotunately it would be impractical to hook up to this data for two reasons: 1. it is not and will not be aligned with Project and Demand Management processes, 2. It lives in tables (Domains & Companies) that are not used in OOTB PA reports, filters & other components for Demands and Projects.

What's your experience with essentially duplicating the org structure in SNOW for a different set of processes? Do you think it's OK to use Business Unit and Department table (currently idle) a bit creatively to meet medium-term requirements or would you take it upon yourself to re-architect in a way that marries everybody's needs and serves all processes and all teams that use ServiceNow?

Thanks.

[Hadyn]

I am looking at the same sort of thing for my organization.

We would be in the same boat at some point. Thinking about re-labelling BU to Division/Portfolio.

I am not too familiar with how departments in SN relate to Project Management but maybe your customer would just as well be happy with calling a "department" an "Organisational Unit", or "OrgUnit". This way you are clearing the way for the future so they don't confuse a business unit with a department.

That may be what I end up doing as some people see "departments" as a type of org unit.

[Jason Sturgeon]

Hi Michal,

It's been about a year! I am surprised your question didn't attract more responses because it is well written and I'd say a big deal. How did you solve the problem?

[Michal Sadowski]

Hi Jason,

Thanks for the question.

For that specific implementation, the problem dragged on until the client decided last minute to:

• leave table names as is and conform to OOTB data model
• manually load Business Units (their Divisions) and Departments (their Business Units)

It was hard to come up with a long-term, re-architected solution as the platform had been implemented starting with ITSM with little thought for core data in Organization Management application. When ITBM came around, the expectation was that everything works great and we don't go back and re-architect. We focus on ITBM. Which is not ideal as ITBM relies heavily on things like Business Units, Departments, Goals, Strategies, Cost Centers, etc.

Anyway, this experience and other implementations have taught me a lot about Organization Management in ServiceNow, how it's not a trivial thing to implement, how organizations struggle to identify master data that can be used across processes and how maintaining this data long-term is another under-estimated topic.

I'm currently starting another ITBM implementation and have put a lot of emphasis on this aspect. I'm still unsure how this plays out in practice. As part of lessons learned, I'll try to craft a community article at some point in the future to share as much as I can in a more structured way.  

[Jason Sturgeon]

Thank you for your timely and thoughtful reply. I was about to go down the road you describe and chose instead to populate the Departments table which I also updated the label to mirror the organization's terminology. My thinking is that the Department table [cmn_department] is a core table, making it a better candidate. There is a reference to Business Unit [business_unit] in our instance but I suspect that was due to the ITBM implementation.

Further I want to associate our user groups with the departments so we can move away from naming conventions for understanding the relationships. Using the parent field to create the hierarchy has worked so far but now I have to look at the LDAP integration to make sure our system of record knows how to associate the users with their departments correctly.