How to Define Roles in a Process-oriented Way — and Why it Matters

AKV + VMI: Linking Activities and Roles From Different Perspectives

Both AKV and VMI are about connecting what needs to be done with who does it. But they approach this connection from opposite angles:

• AKV begins with the role and assigns relevant activities to it.
• VMI, on the other hand, starts with the activity and assigns roles to it.

Each logic poses different questions — and each provides valuable insights when defining roles and processes:

• AKV logic:
  • What tasks does this role carry out?
  • What authority (decision-making power) does it have?
  • For what outcomes is it accountable?
• VMI logic:
  • Who is responsible for this process step?
  • Who is involved in the execution?
  • Who should be informed?

Because each model emphasizes a different angle, it’s worth considering both when designing or improving business processes.

Describing Roles with the AKV Matrix

The AKV matrix is a classic tool for writing clear, structured role descriptions. The acronym stands for:

• A – Aufgaben (Tasks): Recurring activities carried out by the role
• K – Kompetenzen (Competencies):
  • As authority: What decisions is the role empowered to make?
  • As skills: What qualifications or abilities must the person in the role bring?

Skills vs. Authority

In job postings, competencies are often listed as skills. For example, a bus driver must be able to drive a bus — and ideally, that requirement would be backed by a measurable criterion like a commercial driving license. In operational practice, however, defining competencies as authority tends to be more actionable: It clarifies what decisions the person in this role is allowed to make, and whether those powers are aligned with the responsibilities they’re held accountable for.

Responsibility Must Match Authority

Consider the role of a Learning & Development Manager responsible for employee training. If this person can’t register employees for courses or approve training budgets, they can’t actually fulfill their responsibility — at least not effectively.

Bottom line: A role’s authority and its accountability must go hand in hand.

Defining Responsibilities with the VMI Matrix

The VMI matrix stands for Verantwortlich, Mitwirkend, und zu Informieren — or in English, Responsible, Supporting, and Informed (often abbreviated as RSI).

This model is especially useful in project and process management:

• In projects, VMI matrices clarify who owns each task or work package.
• In processes, VMI highlights which roles are involved in each step — even if it’s often done implicitly rather than deliberately.

In process design, every step involves at least one change of responsibility — that's what defines a process. But it's also important to document:

• Who else supports the step (M)
• Who needs to be informed once it’s completed (I)

These often-overlooked details are crucial for smooth handoffs, especially in manual or infrequently executed processes.

All Roles Matter — Even the “Informed” Ones

Just because someone’s role is marked “to be informed” doesn’t make it any less important. Here’s a simple example: A production worker finishes a job and places the completed parts in the designated area — but no one notifies logistics. So the parts sit for five days. Even though the step was completed successfully, the overall process failed — because a seemingly minor “I” role wasn’t fulfilled.

Rule of thumb:
The more important it is that someone is informed, and the less automated the notification process is, the more explicitly this responsibility should appear in the process documentation — even as a standalone process step if necessary.

Why Task Lists Don’t Work as Role Descriptions

Organizations often invest time and effort into crafting detailed role descriptions. But if confusion still reigns — “Who’s responsible for what? Why didn’t logistics get the memo?” — then something is off. Most often, the issue lies in non-process-oriented role descriptions. They read more like a list of tasks than a clearly defined set of responsibilities tied to specific processes. Without context or connection to who else is involved, these lists don’t help employees understand how their work fits into the bigger picture — or how to coordinate with others.

6 Steps to a Process-Oriented Role Description

To improve transparency and eliminate confusion, tasks should always be described within the context of a process. Here’s a simple method:

1. List what’s being done
2. Put tasks in sequence
3. Assign responsibility
4. Identify supporting and informed roles
5. (Optional) Add "informing" as its own process step
6. Write a formal role description for key roles

This approach aligns roles directly with day-to-day activities. It also bridges the gap between process documentation and role management, creating clarity and consistency.

When Is a Separate Role Description Necessary?

Ask yourself:

• Does this role require authority or access rights not visible in the process itself?
• Is this a technical role where permissions are critical (e.g. admin, key user)?

If yes, a distinct role description is essential.

Processes and Roles Evolve — Keep Them Aligned

Processes change. So do roles. New steps appear, responsibilities shift, systems evolve. That’s why role descriptions and process descriptions should be reviewed and updated regularly. Keeping them aligned avoids contradictions — and prevents the common frustration of employees having to choose between following “the process” or “the role description.”
----
Read part I here >> What Roles Exist in Process Management — And Why They Matter