1.5
Write down all activities
Each ‘actor’ has its own ‘lane’ of activities. Decide who ‘starts’ the process; what is the ‘trigger event’ that starts the process?
By putting the activity in the lane of an actor, you only need to write two words: a VERB and a SUBJECT:
[Customer] [Sends Request]
The verb is always an activity. You do not need to write: [Sales] [Receives Request]
Write what the action of the next actor would be; e.g.
[Sales] [Confirms Receipt]
On each line we see the activities of an actor in time. Now it becomes clear who does what and in what sequence.
| TIP |
Try to put yourself in the place of the item being processed. YOU are the document, order or whatever it is that is being processed; what is happening to you, what are you doing? |
Try to simulate an average flow of this item through the process: what would be most likely to happen? Think it over: it is not about singling out people’s work; it is about discovering where the PROCESS is losing effectiveness!
Simulate the process
After Actors and (some) Activities are written in the map, start ‘reading’ the process in a similar manner one would read a piece of written music.
You can ‘play’ the process ‘in your head’, without actually performing it, thus allowing to learn and understand how the process ‘behaves’ and to feel what its dynamics look like.
How to simultate
One of the participants tells the others what the process looks like, from READING WHAT IT SAYS. But not just ‘dumb’ reading. He should as vivid as possible explain how the process works, based on the information in the map. The rest of the team corrects: Is that really how it works in real life? If not: Correct the map.
Keep doing this untill everybody agrees: “This is how we work!”
| TIP | IMPORTANT! Having multiple simulation-runs may seem to be time consuming. And it may even be so. But this is the way to get high quality information about how the process REALLY works in practice. There is no value in just writing something down. You them may as well use the ISO Handbook… |
Using ‘Black boxes’
In some cases, part of the process runs outside of your scope; for example you send a quotation to the customer and at some point he responds after which the process carries on.
In such cases this step is marked as a ‘black-box’; it happens outside of our control.
To calculate a realistic throughput-time, you may want to set this black-box on a fixed average. However; if you want to know what YOUR process is capable of, it might be useful to set the time of the black-box to zero. In other words; you blank it out.
(example)
When there seem to be ‘Parallel Flows’
Sometimes parties perform tasks in the same time-frame, in other moments parties work together and perform a task simultaneously.
When two or more actors work simultaneously -so synchronized in the time- on a specific task, this is visualized by
sticking the post-its vertically on the same moment,
Example: parties work at the same moment in a synchronized way. In real live you will only find synchronized tasks when actors come together for a meeting;
When two or more parties work in the same time-frame on one or more tasks, however they do not work together (tasks are not performed synchronal), this is visualized by sticking the post-its overlapping in time.
Example: parties work at parallel streams yet not in a synchronized way:
How many exceptions do we describe?
In many situations you will be confronted with exceptions; “After this action it can go here or there… and sometimes it even goes such or so…”
So what to do now?
Mainstream first
Apply the 80 – 20 rule:
Register what is happening in the Majority of the cases. This is what makes the basis, the kernel of the current state map. Look for the ‘usual situation’. What is happening in 80% of the cases? Is this an exception or daily business?
From mainstream to exceptions
Once the kernel of the process is mapped, take the main exceptions and find out where the process will have a deviant flow. Is this relevant? Then map this extra steps too.
The extra –or deviant- steps to handle the exceptions, will always start with a decision:
“Are we going to do the normal route or the exceptional one?”
When there are more exceptions to handle in the “20% part” of the situations, more decisions have to be made:
One for each new exception.
At this point we can already start to think about ways to eliminate complexity by eliminating exceptions in the future state design.
