Proposal for Master Department Hierarchy at MIT

Draft - Jim Repa - revised 01/31/2002

I. Background

Today, if someone asks to see MIT's organization chart, the only proper response is to ask "Which one?". For financial data, there is a Profit Center hierarchy, a Funds Center hierarchy, and a hierarchy of Spending Groups (also known as Custom Funds Centers or organizations in SAP's PD Org). There is also a hierarchy of org. units used by the Payroll system, a hierarchy of units used by the graduate admissions system, the department list according to MIT's phone directory, and a few other hierarchies of department-like objects. All of these hierarchies can be considered representations of departmental units at MIT, but there are three kinds of differences between them:

The schools and areas used for grouping the departmental units are organized differently in the different hierarchies.
The codes used to represent a given departmental unit are not the same (e.g., Chemical Engineering is represented by profit center node 0HPC0000202, funds center FC100056, course 10, Payroll org. unit 062000, LDS unit 70000013, custom funds center FC_CHEME, etc.).
The different hierarchies do not all include the same set of units, although many of them overlap. Sometimes non-departmental units (such as financial holding-areas) are intermingled with departmental units. In other cases, departmental units are omitted (e.g., Bates Linear Accelerator Center does not have a Profit Center).

In 1999, to meet the need for defining departmental "Primary Authorizors" in the Roles Database, a new department hierarchy was built in the Roles Database with links to tie together departmental-objects in the Profit Center, Funds Center, Payroll Org. Unit, and several other "organizational" hierarchies. There is a crude but functional web interface for maintaining the new hierarchy, and it has been kept uptodate, at least for financial objects, by Jim Repa with help from the Business Liaison Team. The new "Department" hierarchy has worked reasonably well for solving authorization and reporting problems in the Roles Database. However, it has not been officially sanctioned by high-ranking officials at MIT, and it still has these shortcomings:

We cannot yet call it the "official" MIT organizational hierarchy.
We have gotten mixed responses when asking for cooperation from the maintainers of the various organizational hierarchies at MIT. This cooperation is required to keep the links between various representations of departmental units uptodate and coherent.
The Roles DB's "Department" hierarchy is organized well for authorization purposes, but in a few instances, may not be appropriate for other uses. (For example, Chemical Engineering is a child of ASO rather than the the School of Engineering.)

The work done so far in the Roles Database has been a good start, but to meet all of MIT's needs, an official master department hierarchy must be

Officially recognized
Supported by all of the owners of master data at MIT with their own departmental-unit codes which must be synchronized with the new master department hierarchy
Maintained according to written policies and procedures

II. Launching an official project

The need for a master department hierarchy at MIT linking the various department hierarchies has now been officially recognized, as noted in this memo from Dan Fitzgerald to Scott Thorne and Jim Repa, sent on 10/30/2001:

  The HR-Payroll project's Organization Management process review team had
several recommendations. One of the key recommendations had to do with the
development of a "master" hierarchy at MIT that would link the various
hierarchies such as the Profit Center hierarchy, the Budget hierarchy and
the HR hierarchy.  A critical element of this recommendation is building
the process for approving new or changing existing organization units, and
developing procedures for coordinating the change to multiple hierarchies
and linking them together.

  This recommendation was approved by the HR-Payroll's Design Review team
and the project sponsors. The project sponsors (Jim Morgan, Laura Avakian,
Marianne Howard and Deb Fisher) asked if the development of the master
hierarchy and the creation of the associated processes for maintaining can
be completed prior to SAP HR implementation. I believe it is possible to
complete this before the SAP HR roll out next summer and want to request
this be a priority I.S. project worked on over the next several months.

  Besides the business endorsement for this project I expect the project
will need business owner involvement. With your knowledge of the MIT
community I believe you are best to identify the persons who can best
support this work. Myself or the project sponsors can insure that you have
these people resources available to you if needed.

  Intersection or coordination required with other hierarchy efforts
include; (1) the recent completion of a task force to make the budget and
profit center hierarchies more common and to keep them common, and (2) the
creation of a HR hierarchy in SAP's Organization Management module.

III. Proposed new system: Database and user interface

We'd like to propose that we implement a new database and user interface to store Master Department data. To reduce the development effort, we would reuse existing components from the Roles Database, where appropriate.

In the new database, which we will call the Master Department database, we will store the following data:
1. A list of departments, with their code numbers and names.
  - Department code numbers will be newly-assigned 8-digit numbers. These numbers will be arbitrarily assigned, and they will not match any existing codes or numbers used for representing departments.
  - After the initial set of departments are inserted into the system, future department numbers will be assigned sequentially.
2. A hierarchical representation of the official organizational hierarchy in which the departments are "leaves"
  - The organizational hierarchy will include nodes for schools and areas, and probably additional higher levels (e.g., "Provost's area", etc.). The number of levels between the root of the hierarchy and the leaves (i.e., the departments) will be variable.
  - There may be a reason to define two different "views" of the organizational hierarchy, possibly treating the "headquarters" part of a school, area, or department in two different ways. The deployment of a 2nd view might be postponed until Phase II of the implementation of the system.
3. A set of links between a given master department number and various other objects, e.g., Profit Center nodes, Funds Centers, Payroll org. unit numbers, and Spending Groups. There will also be a link to the department codes in the Roles Database "department" hierarchy described in section I.
4. An editable set of rules for allowable or required links between master department numbers and other sorts of objects, e.g.,
  - For each master department number, there must be exactly one link to a Payroll org. unit number
  - For each master department number, there must be at least one link to a Funds Center
  - For each master department number, there can be 0, 1, or more than one links to Profit Center nodes
There will be a user interface to the Master Department database, probably a web-based interface, that will allow authorized people to do the following:
1. View the hierarchy of departments, along with master department numbers and department names, and the links to other objects.
2. Maintain the organizational hierarchy.
3. Add or delete a master department, with its number and name.
4. Edit the name of a master department.
5. Maintain links between master department numbers and other kinds of objects.
6. Maintain the set of rules for allowable or required links between master department numbers and other objects.
7. View an exception report for links, which will show instances where link rules have been broken or where linked objects are obsolete (e.g., a Profit Center node or Funds Center has been deleted).
The Roles Database will be used to store authorizations for who is allowed to view or maintain various objects in the Master Department database.
Data from the Master Department database will be periodically exported to the Data Warehouse, allowing users to view the data in various reports, and to join Master Department data with financial or other data.

IV. Proposed new system: Ownership and maintenance policies

In order to put the proposed system into production, it will be necessary to identify who is responsible for requesting or approving changes, and determine how those changes will actually be entered into the system. We'd like to propose the following list of "players" who will have decision-making or maintenance responsibilities related to the Master Department Database:

Player Responsibilities

Information Systems (or more specifically, Jim Repa and Scott Thorne)

Technical owner of the system. Design, implement, and maintain the database and related software
Set authorizations for who can view or maintain department hierarchy and links to other objects

Senior VP and Provost (or designees)

Make decisions on overall hierarchy, i.e., how the departments are grouped into schools and areas
Approve new, merged, or renamed departments

System owners

Support standard high-level hierarchy of org. units
Provide nodes or objects in each system that are linked to official org. units, e.g., which Funds Center, Profit Center node, NIMBUS budget node, etc., corresponds to a given official org. unit such as "Biology"?

Data Administrator and designated members of the Warehouse team

Receive departmental requests for name changes or link changes
Check authority of requestor, or make sure change is approved by Provost or Senior VP, and apply requested changes to database
Check authority of requestor, and apply requested changes
Share responsibility of checking integrity of data with the BLT. Watch errors that could lead to reporting problems (e.g., linking one department to a parent funds center and a different department to a child funds center, resulting in multiple departments links to the same cost collector).
Assist with the development of BrioQuery reports based on master department hierarchy

Business Liaison Team

Assist Warehouse team in reviewing error reports, checking for problems
When work with departments identifies changes, forward those change requests to Data the Administrator

Player	Responsibilities
Information Systems (or more specifically, Jim Repa and Scott Thorne)	Technical owner of the system. Design, implement, and maintain the database and related software Set authorizations for who can view or maintain department hierarchy and links to other objects
Senior VP and Provost (or designees)	Make decisions on overall hierarchy, i.e., how the departments are grouped into schools and areas Approve new, merged, or renamed departments
System owners	Support standard high-level hierarchy of org. units Provide nodes or objects in each system that are linked to official org. units, e.g., which Funds Center, Profit Center node, NIMBUS budget node, etc., corresponds to a given official org. unit such as "Biology"?
Data Administrator and designated members of the Warehouse team	Receive departmental requests for name changes or link changes Check authority of requestor, or make sure change is approved by Provost or Senior VP, and apply requested changes to database Check authority of requestor, and apply requested changes Share responsibility of checking integrity of data with the BLT. Watch errors that could lead to reporting problems (e.g., linking one department to a parent funds center and a different department to a child funds center, resulting in multiple departments links to the same cost collector). Assist with the development of BrioQuery reports based on master department hierarchy
Business Liaison Team	Assist Warehouse team in reviewing error reports, checking for problems When work with departments identifies changes, forward those change requests to Data the Administrator

V. Proposed new system: Specifications and project tasks

Preliminary specifications and project task items are shown in a separate technical document.