I consider a Parent business unit can contains 1 - many divisions (child business units). That's why ServiceNow only has Business unit table, not Division table.
My team implemented HR organization - HR operational model based on the HR Centers of Excellence (COEs) data model.
I list two departments of Our company HR organization structure below for your reference:
Is there any more help needed on your question?
If my reply is Helpful/Correct, please mark the answer as Helpful/Correct. This will help others searching for a similar question, and will take the question off the unsolved list.
Best regards,
This begs the question whether the undefined "Division" object should be represented as child business units or top level departments, and also how to traverse the hierarchy intelligently when it is distributed across two distinct tables.
I agree that colloquially we generally use the term "business units" to refer to the top level(s) of the organization, and "divisions" to represent the middle strata, and "departments" to represent the smaller units. The problem is indeed where to draw the lines and which table to store them in.
Business units tend to be related to business applications, business capabilities, business processes, and business services, whereas departments tend to be related to lower functions, like who owns an asset or what team your direct manager is the head of. Business units are used for business level things like financial reporting, risk, and compliance. Departments tend to be more operationally focused and human resource focused.
Unfortunately, because they are in different tables, there are different business rules that run on various referencing tables, which can result in inconsistencies such as two users or assets belonging to the same department but different business units. In earlier releases before business units were introduced, customers often simply defined business units as the top level departments. They may have defined custom field to define the department as a "business unit" or "division" or they may have extended the Department table for similar reasons. I have often wondered why ServiceNow did not take the same approach and define the organizational hierarchy in a single table. All I have been able to determine is that they intentionally allowed for business units and departments to be more loosely coupled to allow for such cases as two users or assets belonging to the same department but different business units. Otherwise, treating both of them as a single organizational unit hierarchy might have been a better way to go.
For example, see the screen shots below which show that I can defined a Business Unit hierarchy and a Department Hierarchy that are diametrically opposed to one another and ServiceNow won't complain a bit. The business unit hierarchy is defined as A --> B --> C, and the department hierarchy is defined as X --> Y --> Z. But I am able to set the business unit of X to C and the business unit of Y to A and the business unit of Z to B, which is nonsensical. Not only does ServiceNow not cascade the business unit selection to child departments, but it will not update the business unit selection of a referencing object based on the selected object based on the selected department. In essence they are implemented as two distinct organizational hierarchies with no connection to one another in practice, even though ironically they are related to one another according to the data model and available documentation.
Here is how TBM defines business units, which as you see actually include departments.:
The divisions, lines of business (LOBs), departments, affiliates, or other legal
or organizational entities that consume solutions. Sometimes are charged for
consumption via chargeback. Usually viewed as the entities that fund IT and
often have a direct say in how the enterprise’s IT resources are directed. May
have their own technology teams and resources as well.
