Using organisational roles in process design

In this lesson, you’ll learn how to define organizational roles (swimlanes) the right way—so processes become usable standard work, handoffs are clear, and employees can execute reliably with fewer errors.

Key learnings

• Process Owners work WITH processes; Process Roles work IN processes—both are essential.
• Roles = hats, not job titles: define Name, Purpose, Responsibilities, Required competencies/capabilities, Processes involved.
• Use output-to-input logic: each Role Owner executes an activity to produce a clear output for the next role.
• Manage competencies in context (e.g., required certificates) to ensure safe, capable execution.
• Right granularity = roles aligned to handoffs and skills; keeps instructions lean.

Transcript

After this lesson, you’ll know how to define and use organizational roles—the swim lanes in process design—so employees can understand what to do and execute reliably with fewer errors.

Why roles matter to governance and design

Clear roles make process maps usable.

When responsibilities and competencies are explicit, teams understand who does what, handoffs are clean, and work instructions stay lean. Roles help turn process diagrams into standard work by making it clear what each person’s job is.

Process Owners vs. Process Roles (WITH vs. IN)

It’s important not to confuse process owners with role members, or ‘role owners’….

• Process Owners work WITH processes. They steward outcomes, interfaces, and improvements.
• Role members work IN the process. They execute specific activities and are responsible for each activity’s output.

Owners enable; roles execute. You need both.

A process role is a ‘hat’ you can wear that is defined by skills and responsibilities, not a job title.

One person can wear multiple hats at different times —e.g., ‘Supplier Administrator’ and ‘Customer Service Rep.’

Define each role with:

• Name
• Purpose (why the role exists)
• Responsibilities (what outcomes it owns)
• Required competencies (skills, certificates)
• Required capabilities (tools/systems the role must use)
• Processes involved (where it appears)
  When roles are consistent, you don’t need to over-document every step—the trained operator assumption keeps instructions concise.”

Example: Supplier selection (roles in the flow)

Now let’s look at the Role member in the context of an example process:

• Process: Supplier selection
• Process result (output): Supplier selected, evaluated, and ready for orders
• Activity: Select supplier
• Activity result (output): Supplier chosen and data summarized

The Role Member executes the activity by following its work instruction to produce the intended output for the next activity—typically handled by a different role.

That output-to-input logic keeps the chain unbroken and makes swimlanes useful for clarifying who does what.

How to design roles for swimlanes (practical steps)

Design a list of common organizational roles before you start mapping processes.

Why? Because the better your role is defined, the shorter your work instructions can be. Think about it: Untrained people require more detailed instructions, than trained. It’s all defined by your roles.

So here’s one way of doing it…

1. List roles you already have.
2. Write a one-liner purpose per role.
3. Draft responsibilities as outcomes (‘Ensures due diligence dossier is complete’).
4. Add required competencies (e.g., vendor risk screening, basic contract terms).
5. Add capabilities/tools (ERP vendor master, contract repo).
6. Tag processes where the role appears.

Then place roles as swimlanes; assign activities; verify outputs and handoffs.

Role granularity: how many roles is “right”?

How many roles do you need? It’s hard to say in general since it depends on your company size and specialization level. The larger the company and the more specialized work is, the more roles you will need.

Too few roles = blurry accountability; too many = chaos.

Aim for roles that align with competency sets and handoffs.

A good test: can multiple people with the same role execute the activity to the same standard after short training? If yes, your granularity is about right.

Competencies in context (skills & certifications)

Managing competencies in the context of processes verifies that people can do the work.

Example: servicing a high-voltage transformer station requires a high-voltage certificate. Add it as a role requirement and link it to the activities that need it. Benefits: targeted training, safer execution, audit-ready evidence, and faster approvals.

Writing lean work instructions using roles

If roles contain competencies, then instructions can be shorter and more actionable:

• Start with preconditions tied to role competence (‘HV certificate on file’)
• Steps written for a trained operator, with links to forms/screens.

Acceptance criteria = the activity’s output

This keeps SOPs readable and reduces rework.

Governance touchpoints: owners, editors, role owners

Make it clear who updates what:

Role Owner (frontline): executes, gives feedback, flags gaps in skills or tools.

Tie role changes to your monthly review and maintain a lightweight RACI. RACI will be covered in a separate lesson.

Process Owner (L3): approves role definitions and changes that affect outcomes.

Editor (L4/L5): updates activities and instructions.

Adoption play: train-the-trainer by role

So how do you train people?

Use a train-the-trainer model: certify a few experienced Role Owners to coach peers. This accelerates rollout and keeps expertise where work happens.

Train by role, not just by department.

Bundle skills and instructions for each role into a short learning path – and give them access to your work documentation so they can stay updated on all improvements.

So how do you start?

Pick a process. Define three core roles with purpose, responsibilities, competencies, and tools. Map the swimlanes, write the top two instructions.

Run it with real role owners and let them comment, then turn comments into improvements and try again. This iteration will get them trained and involved through on-the-job training.

So to summarize.

Roles are the backbone of usable processes.

Define them as skills-based hats, map activities to roles, and anchor instructions and competencies to those roles. That’s how you get clarity, speed, and safe execution—at scale.