What Are Some Guidelines for Setting Up the Resource OBS and Project OBS?
The OBS represents the hierarchy where projects and resources sit, respectively.
A Resource OBS may look something like an organizational structure and/or contain functional areas. For example, it may be made up of the following nodes (where the organization and each business unit can be defined, then the departments in that unit, followed by sub-departments or groups):
Organization
Business Unit
Department
Group
Resources would then be added to the appropriate group node (generally at the lowest node level), and people can be given view or edit rights to specific nodes (higher or lower level). Having rights to a higher level node gives you the same rights to the lower levels within that node. Also, you may have view rights to a higher node, but edit rights to only one of the sub-nodes in that parent node.
A Project OBS might look similar to the Resource OBS (e.g., it could be a departmental hierarchy based on where projects are managed, or less often which area the project is meant to serve. Or the project OBS may be based on some other portfolio grouping as well. Keep in mind, however you break it down, it will dictate how you control user rights and how you control which projects you want to filter on in a session.
Some general guidelines and notes are as follows:
1) Nodes are important for controlling rights (i.e., who has visibility and management control over what departments or groups of work). This also plays into reporting, since reports can be defined based on a filter of certain nodes. OBS nodes also are used for selecting and managing “portfolios” for your user ID (via the OBS node selection).
2) Keep in mind that you also have the ability to have User Defined Fields (for instance for supervisor or geography, etc.) which can then be used in view filters or global filters as needed. So the geography and/or supervisor name need not be part of the hierarchy per se.
2) Resource nodes are generally by department within the organizational hierarchy. Project nodes can be similar or can be by some other portfolio grouping. Again, consideration is how you want to be able to control rights. As mentioned, for simply reporting summaries by various categories or groupings, a User-Defined field can be used for that in lieu of a node. But for controlling of rights, the node is the primary vehicle.
3) For the Resource OBS, using department names instead of manager names is typically easier to understand and maintain. That way, when managers leave or change jobs, you only need to edit the rights, not the node names. However, some organizations do use manager names because it’s important to them that people can easily identify who someone’s supervisor is. An easy alternative is to put someone’s supervisor in a User-Defined field, and keep the Resource OBS by department. That way, you can always have views by Supervisor and filter on that, while still using the department names in the Resource OBS. Some organizations used department names at the higher node levels, and manager names at the lowest node level.
