Process: “a series of actions or events performed to make something or achieve a particular result, or a series of changes that happen naturally” Source: Cambridge Dictionary
When used correctly, process modelling is an invaluable activity, and along with process maps can be a powerful way of communicating of what is happening or should happen. At its simplest it helps us to decompose a process into a sequence of steps, with a defined start and end, and understand the various events that trigger specific actions. They can also help us to identify the users (‘actors’) and what their involvement is.
This provides the basis for analysis and optimization.
However, it can be easy to fall down the path of over-complication, especially when it comes to drawing up a process. Meaning that instead of being helpful, they can be time consuming and not fit for purpose.
Therefore, here are my set of 10 principles for working with processes, whether that be through a discovery activity to define an ‘as-is’ or through a design phase to build up a set of potential ‘to-be’ processes.
- Understand the purpose and why, before anything else — what are the models going to be used for? Is it to share with others to seek a consenus view on how something works? Is it to enable you to perform analysis activities off the back of? Is it to identify to a list of users (‘actors’) in an existing process?
- Consider your audience, and use notation frameworks sparingly. Notation frameworks such as UML and BPMN, can be helpful in the right circumstances. Especially as a ‘behind the scenes’ analytical aid. But, bear in mind, they often confuse many who haven’t had the same training.
- Focus on ‘just enough’, don’t let perfection be the enemy of good. Low-fi is generally fine, share early. Iterative process modelling is often the best form.
- Think about accessibility, when sharing process maps—not everyone may have a Visio or Lucid license. Consider the best tool so that everyone who needs to access it, can access it. If in doubt, export it as a PDF before sharing.
- Levels, know when you need them and when you don’t — you don’t need to model every level every time. However, you may need to understand something at a higher level first, before you can break it down further. All goes back to the purpose!
- Beware relying on previously documented processes — Beware of re-using or relying on the information in a previously modelled processes unless you have a robust process library, that is regularly maintained and with stringent change control. Processes have a shelf life!
- Consider sample size, like you would with any other type of research — there are documented processes, and then there are workarounds that users and customer actually do. Not everyone may approach or engage with it in the same way, so consider how many people you should speak to, in the same way you would with any other type of research activity.
- Talk to users who ‘do’ the process, not just the person who ‘owns’ the process. Expectations vs reality are often very different.
- Obsess over the events that trigger a process. They might be automated, such as triggered at a set time or upon a specific action being completed. They could be manual, triggered by an interaction from a user. Whatever, they are — invest time in understanding what they are, how they work and assess whether they’re helpful.
- Reference your contributors — its theirs, not yours — whether they’ve helped you to to understand how a current process works, or if they’ve been involved in designing an improved or new process. Not only is it polite, to reference those who you’ve collaborated with along the way, it‘s a helpful record when looking back. It may also prompt others, to suggest additional people who should be involved.
Lastly, remember processes are different to customer journey maps, service maps, business capabilities. Don’t be fooled into thinking that you don’t need to understand processes, if you have a good grasp on the customer journey or business capabilities. They provide different thinking and perspectives, and will uncover different information. Especially in discovery settings, processes are the closest you can get to understanding what is actually happening for all users involved. They also consider both visible and invisible triggers and events.