Simplify Your Business Processes
In this guide we’d like to demonstrate how process definitions may significantly simplified and presented in a more readable way. As we work with our clients with ProcessMate Cloud Process Management software we see how our customers define their processes. They often make a single mistake by describing their processes in a very low-level convoluted fashion, trying to capture all complex cases. In ProcessMate Cloud Process Management software, we encourage our customers to simplify process definitions as much as possible. This delivers immediate value, especially when the process is configured in ProcessMate or any other process management software, or simply shared with colleagues for training purposes.
What is Process Definition
Process definition is a documented flow (sequence) of tasks, together with responsible actors (people or systems taking those steps), information documented during this process or as input to the process.
Please bear in mind, that the simplification of the process itself, that is changing the sequence of steps or actual steps themselves that simplifies the business workflow is outside of the scope of this article. We simply aim to advise on simplification of the process definition (description).
Below is a number of simple steps that can be taken in order to simply your definition of the process.
Remove “micro-flows” and micro-tasking
Consider the process from very high level point of view. What would managers consider as pivotal points in the process, what would the senior management like to see in their reports?
See how on the low-level process may be defined:
Why reduce it so much? People do not need micromanagement. In most cases, they know how to do their job within an individual task. If your instruction set (or a process management software) attempts to micromanage people by introducing too granular tasks, people would reject the instructions and the system that imposing them. If you absolutely need to give guidance, give it as a description of the task. This will keep the workflow map simple, while still providing the required information.
Our advice: try to create a process in a spreadsheet, such as MS Excel or Apple’s Numbers, where each activity (step) is a column. What activities/columns would you introduce while looking at your process from high level-standpoint? Consider whether this is enough? If not, why?
Document 90-95% of the cases, not 100% of the cases
Don’t point out all possible paths the process may take. Go for the majority of cases as, otherwise, the complexity would grow exponentially with little benefit.
Complexity grows substantially with % of scenarios covered. The basic idea is that most (90-95%) of the process scenarios follow the same flow or sequence of tasks. The rest though provide major complexity, as they may vary significantly. The question we’d like you to ask yourself, do I care about those exceptions, and if so, can they still fit into the definition of the other 90-95%? If not, can that be covered by 1 optional step?
For example, your quality assurance team may introduce a complex sub-flow in a rare case when product quality standards are breached. Instead of defining this detailed workflow, why would you introduce a single step “Handle quality issues, if any” to manage that. Hopefully, the quality problems occur not so frequently, therefore you don’t necessarily want to introduce a dedicated workflow for them.
Our advice: take a look at each step, identify how frequently it really happens. If it happens frequently enough, see if that can be modelled as optional step or as a separate flow.
Don’t try to define out all possible paths
With human driven workflows, the flow can really be disrupted by any point. What if your team finds a mistake done at one of the initial step? Do they correct it right there or they go back to that step? And if latter, do they still implement every step all over again or they “recycle” what they had done initially?
The truth is, in many cases, process can divert and/or go back to any previous (and sometimes, next) step. Extra steps may be introduced along the way.
The question is, whether that matters at all or not? Of course, your employees and management should know that an individual process diverted.
Check “Report problem” (link) mechanism of ProcessMate, that provides a great tool to handle exceptions.
Our advice: use a common flow, something that typically happens. This would help make process readable and understandable without introducing multitude of branches.
Apply “sub-process” concept
The “sub-process” concept is a simple methodology to encapsulate complex sub-flows into a single task, such as “approval sub-flow” for a complex approval. This hides unnecessary complexity and gives a better high-level view on the process.
Introduce “optional flag” for tasks that aren’t always carried out
When tasks or steps are carried out optionally, do not create “branching” with conditions. Instead just mark those tasks as optional. This will also simplify the view while provide sufficient information of the process.
Don’t merge several flows into one
What’s the criteria to understand whether you have multiple processes bundled into one? A simple set of criteria that helps us is this:
- Multiple sub-processes converge into a single process;
- The other way around, one process deviates into a multitude of sub-processes;
- One part of the process tend to stop with no continuation to the rest of the process (e.g. sales process does not always end up generating an order, therefore it makes little sense to bundle both sales and delivery into a single workflow).
Use swim-lane diagrams
They are more structured, have information about responsible parties, as well as easy to analyse from the standpoint of one user group. For example, users in the group A can easily see all tasks attributed to them since they are there in a single swim lane.