People
The way the people of an actor in an ecosystem are organized is only of secondary importance to the performance of the ecosystem. Organizational structures can be changed by the actor as they please, without necessarily changing the things the actor does or how they do it. Besides, by definition, organizations have different people, different numbers of people, and their people may have different skills, knowledge, experience, cultural standards, and many other characteristics. It is, therefore, impossible to standardize the organization. As a consequence, the organizational structure is a matter of local optimization of one of the three essential organizational resources: the people.
Given this lack of standardization, a methodical approach to service management can only provide one recommendation: whatever structure is determined by local management, that structure should contribute explicitly to the organization's control over their contribution to supply chains and the ecosystem.
Separation of duties
One of the oldest instruments to assure service delivery and to improve the organization's control over its performance is separation of duties: separating the responsibilities and authorities when performing a certain task.
Separation of duties: Separating the responsibilities and authorities for tasks by creating a cut between specifying and realizing.
In USM, separation of duties is applied in two principles:
- domain separation - separating a task domain into two sub-domains for specifying and realizing
- process-based working - separating management tasks within a task domain into process management and line management
Because domain separation and process-based working are principles, they can be applied to any task domain. However, it is not mandatory to apply both principles: a task domain which is not divided into two sub-tasks with separation of duties can be partially assured with process-based working. In such a case the organization takes additional measures to achieve the desired assurance. These are measures which do not have the fundamental impact of domain separation or process-based working. Even though they are less efficient, such additional measures still contribute to the desired assurance. Think, for instance, here of:
- the 4 eyes principle: at least two different people check an activity or facility
- audits: regular testing of the quality of actions or facilities, by an internal or external party
- organizational structures: specialization, hierarchical steering, project-based work
Domain separation
Domain separation is often assured with an organizational setup: the task to specify is assigned to another person or team than the task to realize. From the customer's perspective, this separation takes place in two sub-tasks 'behind the front door' of the responsible party. The domain separation is used within the task domain.
Supply chain setting
In a supply chain setting, the customer only has an interface (customer-provider relationship) with the outside of the task domain. That outside is functional management ('functionality management', 'design management', 'specification management'), which takes care of the specification of the service and the support in the use of the facility.
The realization of the specified service concerns technology management ('realization management') and is an internal matter of the task domain. In this way, the service organization can optimize the technical realization independently of the customer, as long as the delivered service meets the agreed specifications. This way the customer does not look 'in the kitchen' of the task domain.
Functional management acts as the bridge between the customer and the provider of the facilities used. This bridge often uses profiles such as service manager, account manager, pre-sales, and business analyst: representatives of the task domain who have insight into the customer's business activities. These specialists know what support is possible, choose coherent solutions in consultation with that customer, have them realized by the internal realization domain, and support the customer in using the facility.
Drama triangles
If the chain of command doesn't run from left to right in a supply chain setting, the organization may be subject to a drama triangle setting. A drama triangle occurs when the supply chain arrangement of the previous section is replaced by a triangular relationship, as shown in the image below. The (internal) customer here faces the challenge of managing two domains that act as separate (internal or external) providers. As soon as there is any tension between the two providers in this triangle, or if there is an imbalance between the interests of the three parties, the integral performance of the task domain suffers. Drama triangles may reflect various situations, including:
- customer <> specification <> realization
- customer <> provider 1 <> provider 2
- customer <> provider <> users
- customer <> application management <> systems management
Process-based working
A second form of separation of duties is created by process-based working, whereby a distinction is made between process management and line management, i.e. between specifying the routines and realizing them. Working in a process-based manner does not imply that the organization also coordinates the work in a process-based manner: the balance between process-based coordination and team-based coordination may fall to the side of the line.
Because in USM it is no longer just the processes but the workflows that organize the targeted coherence of activities in the process model, service management can also shift from process-based to workflow-based. As a consequence, process manager and process coordinator profiles can shift to workflow manager and workflow coordinator.
Workflow-based work has explicit consequences for all activities that already applied to process-based work. Not only is the management of work now based on workflows instead of individual processes, the reporting on performance is also affected. For example, a service report is now drawn up in terms of workflows, which include the integral delivery of support. This formulation fits in perfectly with USM's customer-driven approach: after all, the customer only 'sees' the support through the interface, which can be divided into wishes, changes, incidents and service requests.
How far an organization can implement these consequences depends on the [maturity] of the organization: if process-based working has not yet been brought under control (level 2 or 3 of the maturity model), then the organization is not yet ready for workflow-based working.
Working in a process-based way inevitably leads to a matrix organization, where the steering along hierarchical relations is combined with steering along the logic of the processes (workflows).
Matrix organizations hold great opportunities to cope with variation of the environment: the organization now has two structures that can be used to cope with external factors: hierarchy and process logic. An organization that only uses hierarchy for determining the distribution of powers is much more vulnerable than an organization that can manage two lines of defense. The matrix also offers interaction between the two steering perspectives, which allows for continual challenging of decisions, and therefore fosters better decision making. The challenge of the matrix organization is always to find the right balance between the two steering perspectives.
Team structures
A team is a part of an organization, with a specific, limited set of tasks. A team uses processes and technology (resources). Teams, therefore, use the processes that are established in the organization. In USM these processes are organized in workflows because there is an integrated and non-redundant process model underlying it. What then applies to processes, also applies to workflows.
Teams relate to a group of individuals (>=1) with a coherent task. These individuals are the employees, each of whom has one or more profiles in which their tasks are defined. Whether a team is a fixed element in the organizational hierarchy, a virtual team, or a temporary project team, in all cases the team includes the combined tasks of the individuals involved. For these combined tasks, the team uses routines and technology (resources).
Teams can be arranged to different dimensions, for example:
- infrastructure, e.g., the Maintenance Team
- service quality, e.g., Security Management Team
- activity, e.g., Cleaning Service, MT, Finance, Maintenance
- geography, e.g., the Service Desk East
Sometimes the teams' reason for existence can be traced back to:
- service agreements, e.g., a Large Customer Account Management Team
- internal business rules, setting up supervision leads to an Internal Auditing Team
- government or industry regulation, e.g., a Compliance Team
- sourcing, e.g., a Supplier Management Team
An organization divides its organizational structure and teams entirely according to its own insights. No laws and regulations apply to setting up teams. In practice, only general characteristics need to be clear, such as that it must be clear what that team does, who is part of it, how tasks are assigned, and what resources they use.
In all cases, these teams use the same set of processes (see the image below). Only the extent to which they do so differs.
A RACI model may specify the relationships between the People dimension and the Process dimension. A RACI model is a cross-table that establishes the relationships between 'who' and 'what' in an organization. These relationships determine the tasks, authorities, and responsibilities (TAR) of an employee.
In a RACI table, the axes are of great importance: which quantities are related to each other? Are they functions, roles, or profiles on the horizontal axis? And on the vertical axis: activities, process steps, or tasks? For both axes, the organization must have a structure that explains which quantities are on those axes. This may be based on complex task packages, but also on a simpler arrangement of the USM process steps.
Not roles and functions, but profiles
USM applies a simple and straightforward model for assigning responsibilities to people. Based on the principle of Separation of Duties, USM differentiates managers, coordinators, and operators, in a process perspective and a line perspective:
- A process manager specifies how the process should be executed, and agrees with the line organization on that execution.
- A line manager specifies how the line executes the agreed processes, and agrees on that execution with the coordinators.
- A process coordinator specifies how the agreed work is done by the operators, and steers on the execution from the (logical) process perspective.
- A line coordinator specifies how the agreed work is done by the operators, and steers on the execution from the (hierarchical) line perspective.
- The operator executes the work as assigned, whether this is coordinated by a process coordinator or a line coordinator.
With this simple set of profiles, you can build any organization, whether it's a traditional hierarchical organization (the upper part of Figure 5 above), or a modern process-based organization (the lower part of Figure 5 above). In the case of a process-based organization, it may be evident that a clear process model will be extremely helpful to creative unambiguous steering at the level of the operator.
