4. Success factor for effective process orientation - Transparent role concept and responsibilities

In the fifth part of our blog series, "7 Success Factors for Sustainable and Effective Process Orientation," we explore the fourth success factor: transparent role concepts and responsibilities. Together with Thomas Hardegger from Business-Partner, we take a deeper look at this topic, which may seem simple at first glance. Process orientation requires active responsibility at all levels of the organization. Every person involved must know not only how the process works, but also with whom they can deliver a stable, desired result. In this article, we focus on the operational responsibility for executing a process—or, in other words, "working within the process."

The fifth part of our blog series is therefore dedicated to the fourth success factor for sustainable and effective process orientation: "Transparent role concept and responsibilities." This success factor focuses on the following questions:

Have the roles within the processes (RACI/DEBI, swimlanes) been defined along with their competencies and responsibilities?
Can these roles be consistently linked to the positions and functions within the organizational structure?

As part of a seven-part series, we will discuss all seven success factors for sustainable and effective process orientation in detail every two weeks.

Overview of previous parts of the blog series: 7 Success Factors for Sustainable and Effective Process Orientation:

• Part 1: 7 Success Factors for Effective Process Orientation
• Part 2: 1. Success factor for effective process orientation – Defining process management goals and a vision for the future
• Part 3: 2. Success factor for effective process orientation – clear customer and stakeholder focus through graphical process landscapes
• Part 4: 3. Success factor for effective process orientation – Process documentation as a means to an end for effective process orientation

1. The concept of roles

To answer these questions, we must first address the concept of roles.

When we talk about roles, we mean a role within the operational workflow that is assigned to a task in a process (as responsible for execution or participation). This is distinct from positions or functions within the organizational structure, which process management does not initially influence. In principle, all employees (including management) are assigned to multiple roles and usually one position or function.

A practical example from our own experience illustrates this. At Business-Partner and intellior, we have the function of "Management Consultant" and several associated positions. The function of Management Consultant can be broken down into several roles, such as: Account Manager, Proposal Writer, Project Planner, Technical Implementer, Aeneis Customizer, Process Modeler, Workshop Designer, Facilitator, Trainer, Lean Manager, and many more.

These roles are not primarily defined by job descriptions, but rather emerge from the grouping of related tasks within processes.

A role is therefore responsible for a bundle of related tasks for which...

• specific requirements and thus
• specific qualifications (skills and abilities) as well as
• specific competencies and authorizations

are required.

This also highlights the potential of a process-oriented role concept for personnel planning and development. A role describes a group of employees who perform specific tasks based on their methodological and professional knowledge. Roles are deliberately not based on organizational structures, hierarchies, titles, functions, or individuals. Roles are derived by analyzing processes for related tasks.

2. Why role concepts are useful and beneficial

First, a role concept creates clarity regarding responsibility for a specific task. In process management, a distinction is classically made according to the DEBI or DEMI principle (equivalent to RACI in English-speaking regions). Here:

• D stands for execution responsibility. This role holds the responsibility and authority to carry out the task and ensures its smooth completion until the task results are "handed over" to the next role. It is the primary assignment in the swimlanes of process diagrams.
• E stands for decision responsibility. It is used when a specific role must decide on the execution of a task or its outcome, for example, in the form of an approval. However, we recommend using this sparingly. In practice, it has proven effective to model decisions as explicit tasks with execution responsibility, potentially linked to specific conditions.
• B or M stands for consultation or participation. This role is involved in a task on a case-by-case or permanent basis but does not bear final responsibility for it. We recommend only assigning "M" to a task where participation is the standard procedure. In any case, the role with execution responsibility decides on the necessity of such participation.
• I stands for information and means that this role must be informed by the role responsible for execution (a duty to provide information). Organizationally, "I" can also be interpreted as a duty to seek information, but this is not practical. This example makes it clear that transparency is only possible where there is also clarity in terminology and meaning. Mandatory information is typically only passed on to roles that are not involved in the process or are involved at a much later stage.

In Aeneis, a wide variety of visualizations can be generated as a byproduct of modeling tasks with role assignments. In addition to swimlane diagrams (shown here from the perspective of execution responsibility), role-specific task lists are also displayed.

Switching from one swimlane to another makes a change in roles visible. This can essentially mean two things: either different skills are required, or a mandatory or intentional transfer of responsibility is taking place (e.g., front-office/back-office in financial service processes). The latter places demands on a smooth flow of information (potentially via IT systems) and appropriate communication to avoid friction and time loss.

Based on our experience, using roles during the introduction of process management and the maturation of processes offers a multitude of advantages over using functions. Here are a few examples:

• Avoiding multiple assignments for individual functions, which improves process readability (e.g., tasks that can be performed by a manager and one or more clerks).
• Making it visible where the same or similar roles are performed within the process and the organization.
• Fine-tuning responsibilities and accountabilities with minimal maintenance effort, i.e., without having to assign tasks to individual people.
• Identifying which employees perform which roles and whether these correspond to their actual position and function.

3. How do I go about introducing roles?

Initially, it is important to define a very simple and narrowly focused starting set of roles that can be expanded iteratively over time, keeping the final role concept as broad as possible and only as granular as necessary. The initial set is derived by analyzing processes for related tasks. Once such a bundle of tasks has been identified, a suitable name for the role must be found according to the definition explained above. A role should have a memorable name, usually consisting of a single word that best describes the nature of the related tasks. A role must be named specifically rather than too generally.

Example from the banking sector, e.g., for a credit process:

• Loan Advisor
• Credit Analyst
• Collateral Appraiser
• Credit Auditor
• Credit Approver
• Loan Processor

If roles or job profiles are already being used consistently by HR, these can and should be utilized and synchronized with the BPM system.

4. Special roles that do not arise from processes

The goal of process management is not to map every single management task within a company's line or project organization. Therefore, management and project roles are only differentiated in very broad terms and can, for example, be aligned with management levels:

• Division Head
• Department Head
• Group Manager
• Team Lead
• Project Manager
• Project Staff

Committees are also used in process management as a type of role. Committees are institutionalized groups of employees tasked with fulfilling specific duties. Terms such as board, commission, or panel are used synonymously in companies. A characteristic feature of committees is their working method: a committee holds meetings or other gatherings at regular intervals, which conclude with a decision or recommendation. In contrast, role holders generally perform their tasks individually rather than as a group. Committees are modeled as an independent category in Aeneis and, like roles or role groups, can be assigned to tasks.

5. Process and organizational structure are two sides of the same coin

Process orientation is not tied to a specific form of organizational structure; rather, it defines and develops it between the extremes of a "pure functional organization" and a "pure process organization" to achieve an optimum between efficiency and effectiveness. The role concept clearly regulates the different responsibilities of line (functional) managers and process owners.

The challenge now lies in reconciling existing job creation—which is usually based on legal requirements, collective bargaining agreements, qualification needs, and other factors such as the degree of desired or necessary specialization—with the task requirements derived from the defined processes for the defined roles. In this process, sometimes extensively detailed job profiles must be questioned and, like the assignment to positions, revised. This prevents the duplication of roles: once as process roles in the process structure (where they are often just a master list) and once as job profiles in the organizational structure. Some companies are aware of this and copy existing job profiles into the process model, others maintain both separately (process management and organizational management do not communicate with each other), and others have no job profiles at all and want to use process management to compensate for this shortcoming.

However, there should be no separation between process management and the management of the organizational structure; both are part of an overarching organizational management that should also be managed as such. Today, the management of the organizational structure is rarely a distinct function within a company, and there is seldom a process with clearly defined responsibility for it. It is often operationally assigned to human resources: positions are created there when employees need to be hired. The requirements come from the departments (and usually not from processes) and are implemented operationally. The fundamental structure of the organization is determined by the executive level and adjusted from time to time as part of reorganization projects. Here, too, process management is rarely the trigger, nor are the results of regular or sporadic analyses of the existing organizational structure. Usually, the drivers are changes due to acquisitions, shifts in the company's product portfolio, new outsourcing strategies, or the development of new markets.

For HR, an organization's personnel managers, and executives, a number of further advantages can be gained from using roles, provided the process documentation is of high quality:

• Mapping requirements from processes to roles and defining the necessary competencies (competency model)
• Determining the required FTE per role and comparing this with available capacity
• Deriving strategic and operational personnel requirements and headcount planning
  o Qualifications
  o Capacities
• Using roles for personnel development: an employee's focus areas can be identified more easily, and suitable training modules can be determined in a more targeted manner (onboarding/further education)
• Improving personnel allocation from the perspective of key processes
• Identifying personnel impacts of strategic process changes, such as digitalization, automation, or outsourcing
• Contributing to the design of levels and ranges in the compensation/salary system
• During restructuring or personnel changes, processes do not need to be adjusted; only the connection between roles and (planned) positions needs to be updated.

6. Competency management via roles in the role concept

By using roles to which tasks are assigned in processes, process-oriented qualitative workforce planning becomes possible. The required professional competencies (skills) for a role are derived from the assigned processes or activities. Additional competency areas (methodological, communication/personal, etc.) are assigned from a competency catalog. Subsequently, typical target levels are defined (ranging from a minimum level to an expert level, capable of independently solving the most difficult cases and teaching skills to others). When assigning employees to roles, the system checks the extent to which required competencies are present (actual qualification) and how much capacity (FTE) is required per competency level. As part of the (annual) qualitative workforce planning, it is determined which role holders can develop competencies from the current to the target state to better master and improve the process, and what measures are required to achieve this. This also enables the documentation required by many standards for systematic personnel development and demand-oriented planning. If mandatory certifications are also assigned to qualifications for each role and employee, and their validity is monitored with a notification system for renewal, further regulatory requirements can be met.

7. Capacity planning via roles

By capturing volume structures and times in processes, process management provides a reliable basis for analyzing effort data without the need to introduce comprehensive process cost accounting. In practice, this is done in Aeneis by recording an estimated "target processing time" for each task. This type of time tracking is a prerequisite for subsequent capacity analyses for management purposes.

Every employee is hired at a specific employment level. This employee capacity must be distributed across the roles and committees that a specific person holds. This is modeled via the employee-role relationship or the employee-committee relationship.

In most cases, employees have operational roles. For managers, a leadership role is added, while for project managers or project staff, a corresponding project role comes into play.

The assignment of a person or a (planned) position to roles and committees, as well as the determination of the respective capacity in the role/committee-employee relationship, is the responsibility of management. It is only important to ensure that the sum of all role and committee capacities of an employee does not exceed their employment level.

In contrast to tasks from operational business, leadership and project tasks are usually not fully mapped in the processes. The necessary role and thus personnel capacity cannot therefore be derived solely from process capacities:

• As a rule of thumb, 30% of capacity can be allocated for leadership tasks. However, this value depends on the span of control and the efficiency of the leadership processes. It is recommended to design a separate role for each management level and to specify a certain capacity.
• The capacity used for project tasks is in "competition" with that required for operational tasks. When distributing employee capacity, it must therefore always be negotiated how much a company must allocate to ensure operational business and how much capacity is necessary for strategic topics and change. It should be noted that the distribution of capacity can be adjusted to current needs at any time.

By comparing the stored capacities per role and committee with the role and committee efforts modeled in the processes, operational capacities can be managed. The following illustration uses an example of 3 employees to show how their capacities are distributed across various roles and committees and what efforts result from the processes for these roles and committees. The example focuses on operational roles and does not include leadership or project roles.

At the role level, Aeneis can report the required role capacity based on the recorded times, cost drivers, and volume structures from the processes.

The result shows the required FTE per role. At the same time, the stored actual capacities per role are displayed as a sum. This provides the actual utilized role capacity, also in FTE. These two figures can be compared for each role to identify understaffing or overstaffing. (The illustration shows the assignment of employee capacities to individual roles and committees as well as the evaluation of role and committee capacities modeled in processes)

8. Role-based access management

Intelligently designed role concepts also provide a solid foundation for creating user groups (or access roles) for IT systems. This can go so far that the roles defined within process management are mapped one-to-one into target systems, ranging from ERP systems to a company's Active Directory. Often, these user groups and access roles are further refined within the IT systems themselves. For example, the "Accounts Payable Clerk" access role in an SAP system will certainly be further differentiated based on organizational criteria, such as the company code. Nevertheless, the core permissions remain rooted in the "Accounts Payable Clerk" role derived from the process role. If the process management tool also has visibility into the organizational structure and staffing plans, including employee assignments, rule-based analysis of the link between the organizational and process structure can dynamically determine which employees are actually assigned to which roles.

“A process management tool like Aeneis is not only capable of providing the 'master roles' for application access management, but can even manage system users and assign them to the appropriate access roles.”
‍Guido Langer, Lead Software Architect, intellior

And if additional information is already stored in the organizational model—allowing roles like "Accounts Payable Clerk" to be automatically broken down into sub-roles with specific employee assignments (e.g., "Accounts Payable Clerk EMEA" or "Accounts Payable Clerk_CC_001")—then managing permissions across various application systems from a tool like Aeneis becomes both feasible and highly effective. This is because organizational changes automatically trigger updates to employee permissions in IT systems, ensuring they remain aligned without the need for manual intervention.

Best practices on our blog

In a series of follow-up posts, I, along with colleagues from intellior and our partner network, will present "Best Practices" for each of the 7 success factors. These practices are supported by the intellior BPM platform, Aeneis, and will help you achieve effective process orientation. We look forward to your comments, discussions, and insights.