Process mapping starts with a process’ end goal, and then adds detail that describes the work that contributes to this goal. This article discusses who does the work: process roles.
This article follows on from the previous sections of this process mapping tutorial:
- Introduction to process mapping
- Process Mapping Tasks - identifying parts of the work and how they relate to each other
- Process Mapping Causes/Events - why the work happens when it does
Previous steps in process mapping
The first three parts of this tutorial used an employee onboarding process to illustrate process mapping. This started with a process goal, and then added tasks and events to describe the work performed in the process and some of the dependencies and milestones. The result is a simple timeline that focuses on specific parts of the process.
In the same way that you can use a set of process tasks to identify business process events, you can also use tasks to identify process roles.
In the onboarding process example, the hiring manager introduces the new hire to the team at lunch. The hiring manager may also perform other tasks, such as choosing a project for the new hire to work on. When you describe a process, you use a role name like ‘hiring manager’ to avoid referring to a specific person.
Process roles are names for whoever performs certain tasks in a process. A name like ‘hiring manager’ isn’t a job title; it is just one of many roles that someone performs as part of their job.
Someone becomes a hiring manager in the context of a single new hire, and may perform several tasks in the onboarding process as hiring manager. At the same time, the same person might also be hiring manager for another new hire, and take other roles in other processes. Meanwhile, the next new hire may have a different hiring manager.
As with task and event names, role names create a vocabulary that makes it easier to talk about a process. Creating a shared language for process participants to use is an important benefit of process mapping, because it improves communication.
The following summary describes the key points for process roles.
- A role is a name for a participant in a specific process.
- Roles make it easier to discuss a process without referring to specific cases.
- A role is not an organisation-wide job title.
- A process may include more than one task for the same role.
- A role is assigned to a different person for each case, in general.
- A role is usually only assigned to one person for one case.
- One person may have different roles in different cases and processes.
To put this into practice, you can now identify roles that participate in your process.
Identifying and naming roles
The next step is to identify process participants to add them to the process model. To do this in a process mapping session, start by listing roles involved in your process, on a separate piece of paper.
Your first attempt to list the roles involved in the onboarding process might look like this:
- Employee - the new hire
- IT support - prepares the laptop
- HR - welcomes the new hire on the first day in the office
- Hiring manager - puts the new hire to work.
You’ve already thought about the new employee and the hiring manager, but ‘IT’, ‘facilities’ and ‘HR’ sound more like departments than individual people. This might be appropriate if their tasks encapsulate sub-processes, but you will probably find it clearer to start with individual tasks that individual people will perform. The roles are then:
- IT support engineer
- Hiring manager.
To choose a good name for each role, use a name that sounds like one person, so that you can use the role to complete the sentence, ‘For this new hire, Alice is the…’
Assigning roles to tasks
Now that you have an initial list, check that you have a role for each of the tasks in your process. This only uses the tasks, so you could add roles to the process description before adding the events.
Now we can see that we don’t have a role for the ‘Allocate desk’ and ‘Order laptop’ tasks, which isn’t work that the IT support engineer or the recruiter do. Instead, you can add ‘Office manager’ to the list, and add a role name to each task:
- Allocate desk - Office manager
- Order laptop - Office manager
- Configure laptop - IT support engineer
- Create email account - IT support engineer
- Tour office - recruiter
- Eat lunch with the team - Hiring manager
This is a good time to discuss whether the office manager should be responsible for ordering the laptop. Perhaps the recruiter or hiring manager is managing the process at this point, and could do it instead.
It turns out to be odd to say that ‘the hiring manager eats lunch with the team’, since the intent is to capture that the new hire does meets the team, rather than the hiring manager. You could split this task into ‘Introduce new hire to team’ and ‘Eat lunch with the team’: the hiring manager does one and the new hire does the other.
When you assign roles to tasks, you often discover that a task is really performed by two different people. The solution is to separate the work according to the roles, so that each task is assigned to one role. Alternatively, you could identify the single role that is accountable for completing the task.
If you’re not sure of who does a task, you may have discovered something interesting! If nobody performs any work then it isn’t a task at all.
Adding roles to the timeline
Now that you have identified the roles that participate in the process, you can indicate their task assignments on the tasks timeline. Annotate the sticky notes for the tasks with the role name or initials in the bottom right corner.
There is more than one way to show role assignments. You may see process diagrams that use ‘swim lanes’, where each role has a horizontal lane for its tasks.
Next steps in process mapping
The employee onboarding process model now shows who does the work, as well as what the work is and when it happens. As a next step, it’s now possible to consider how to improve the process.
- Process Mapping Hassle vs Value - which parts of the work are essential and eliminating waste
- Process Mapping Conclusions - lessons learned, software tools, next steps.