Process mapping basics: events

Process mapping starts with choosing a process, identifying process goals and choosing a good process name. Tasks and events add the next levels of detail in a process mapping session. This article describes how to identify and organise business process events.
This article follows on from the previous sections of this process mapping tutorial:
This tutorial started with a process goal. The second part, using the example of an employee onboarding process, continued by creating a timeline of tasks that represent the work on the process.
You can use this kind of tasks timeline as a framework to add business process events to.
Business process tasks describe the work in a process. First, you work out what order they happen in, and which tasks you can perform in parallel. Then you can address the following questions about each task.
The answers to these questions do not belong inside the task. Instead, events between the tasks answer these questions. These events describe both the reasons for the tasks and their consequences.
In the context of process mapping, a business event describes a noticeable change in either a business process or the context it occurs in. An event is an occasion, such as lunchtime or a delivery arriving somewhere, or a result, such as a management decision.
The employee onboarding example includes two events that you could have identified before thinking about tasks.
These process milestones are independent of tasks in the onboarding process. In general, a process has a number of key milestones that correspond to events. For the onboarding example, you can skip the end event if you haven’t yet decided what marks the end of the process.
You can look for business process events in several places.
If you look for events that relate to a task like ‘Create email account’, you might end up with requirement and result events like ‘Employee name recorded’ and ‘Email account created’.
These events don’t add much to your understanding of the process. If the process starts with a signed employment contract, which includes the employee’s name, then ‘Employee name recorded’ already happened. Similarly, the successful result of creating an email account is obviously ‘Email account created’, so the event doesn’t add anything to the process model.
Excluding obvious events, the tasks in the onboarding process example suggest some more events.
Next, before you can add these to the timeline, you need to come up with good names that fit on sticky notes.
Good naming is good communication, for events as much as for tasks. For the onboarding example, a consistent set of event names for the onboarding process looks like this: Contract signed, Laptop delivered, Laptop ready, Desk ready, New hire arrived at office, New hire familiar with office, New hire introduced to team.
Good event names describe some kind of change, so the naming guidelines differ from those for processes and tasks.
Having named the events, you can now add them to the tasks timeline.
To add events to the tasks timeline, write their names on different colour sticky notes to the tasks, and position them between the tasks, which you’ll have to move to make space.
At this point, you will probably want to revisit the tasks. The last tasks don’t look like the end of the onboarding process: asking ‘What’s next?’ after getting to know the team and the office will result in additional tasks, such as ‘Assign new hire to project’ or ‘Plan training.’ You may also want to split tasks into separate tasks, when an interesting event happens in between.
You might also struggle with how to represent the order of events. In this example, the new hire’s laptop and desk can be prepared in parallel, but you don’t know (or necessarily care) what happens first: ‘Desk ready’ or ‘Laptop ready’.
What you do want is for both of those events to happen before ‘New hire arrived at office’, but you probably can’t guarantee that, unless you take the unusual move of telling new hires not to turn up until their desk and laptop are ready. These issues don’t belong in this high-level model, so you are better off representing the ideal case. Similarly, you can ignore everything else that can go wrong, for now.
Adding the events exposes a limitation of the timeline representation. Events that you align vertically do not necessarily happen at the same time. Instead, you merely indicate that they both happen before whatever comes next, to the right.
The employee onboarding process model now address what happens in the work, and why. The next steps start with who does it.