Process optimisation is often a goal when analysing business processes. In this post I will outline the most common reasons why the process analysis might not lead to the expected results. Notice that 7 out of 10 common reasons are due to the way the analysis is approached and not due to the modelling technique.
#1 – Not knowing the current process
It takes a process to optimise one. A very common failure is to rush to the design of the to-be process before the as-is process is fully understood and clear. Often the as-is process is not modelled at all. Not knowing the process to optimise gives you no way of knowing what process steps can be removed, automated or planned in parallel with other process steps. In other words, you will be lacking your baseline and it will be impossible to know what process steps to optimise, and it will be impossible to know if the new to-be process is in fact better than the existing as-is process.
#2 – The current process is not followed
All right, after a bunch of interviews and workshops we’ve got the as-is process outlined. However, one problem still exist: the as-is process outlined is the process the business thinks it is having or wishes it is having, but it is not the way the process is executed in reality. This is a tricky one because it can be hard to identify. Try cross interview business units to see if the process being outlined can be confirmed or even better; try study the process in action yourself. If the as-is process is not the process being executed in real life you might design a to-be process that is better than the outlined as-is process, but worse than the defacto as-is process which is being executed in reality.
#3 – It is not clear what to optimise for
Often it is a goal to optimise the current as-is process. To do this we need to agree on what to optimise it for.
- Should it be optimised for time, so that the process lead time will be reduced?
- Should it be optimised for cost, so that the cost of the process will be reduced?
- Should it be optimised for quality, so that the variance of the process flow will be reduced or the variance in quality of the output is reduced?
- Should it be optimised for better customer experience?
Without knowing what to optimise for you do not know if you will succeed and you do not know which of the optimisation techniques will be sufficient – for example automate processes, reduce processes not bringing value to the product, run certain processes in parallel etc.
#4 – Autonomous processes exist
If autonomous processes exist and you are not aware of it, it can be hard to know if you have identified the right as-is process and hard to know if you are optimising the right process. For example, if you are outlining the ordering process and in reality, the organisation (or various business units) is having multiple ordering processes depending on who you ask or what business unit you talk to. In this case you might end up with an as-is process that is correct, but only for a fraction of the organisation. In this situation it is necessary to outline all the ordering processes in order to be able to design a to-be process that all can apply to. Or, if you are willing to accept the risk (verify with the project steering committee) outline the most common process and base the to-be process on that one.
#5 – Lead time is measured but cycle times is not measured
If you are focusing on optimising the process time it is important to measure the lead time (the end-to-end time for the process) and also the cycle times (the individual process steps). If you measure the lead time only (for example if you measure the time it takes for a customer to place an order, starting from the point where the customer decides to buy something, and ending at the time when the customer receives an order confirmation) you will be facing some difficulties.
First, you don’t know what process steps are time consuming, so you don’t know what effect process redesign will have.
Second, you might accidentally optimise the process, but worsening another process; Explanation: Imagine your ordering process having a very time consuming step where the office clerk is receiving the order verbally from the customer. In your to-be process that step is reduced by a computer where the customer types in the order herself. So far, so good. However it turns out that the process time is optimised but that the as-is [Type-in order] process were slow because the customers were asking for information on how to use the product, and that this step is now moved to the pre-ordering process where it is even slower and creates bottlenecks.
#6 – Process diagrams become huge and looses clarity
Processes should be broken down into sub-processes that can even be broken down into sub-sub-processes and so on. If your process maps become huge spanning over several A3 prints connected with glue you are about to lose clarity of the process and it will be hard to review, hard to optimise and hard to explain.
#7 – Process break-down error
A common error is that processes are broken down in an unstructured manner making it difficult to over view the process from an end-to-end perspective. The problem occurs if you on the same drawing have mixed Level1 processes with Level2 processes and Level3 processes. For example if you on the same drawing have the Level2 process “Create Order” and the Level3 process “Send Order Confirmation” and the Level1 process “Invoicing Customer”.
#8 – Processes documented in an unstructured way
If your processes are not documented in the same way – for example some documented in excel, some documented in diagrams, some documented in plain text, some documented with no attributes, others documented with different sets of attributes and so on. In this situation you will have no way of comparing processes to one another and you will have a hard time optimising the processes. In addition to that, it will be hard for other analysts to take over your work or to add something to your work. Decide on a documentation strategy up-front, stick to it and use it for all processes.
#9 – Lots of text, no diagrams
The more you base your process analysis on diagrams the easier it is to overview the process, find patterns, optimise the process and explain the process to others, It is as simple as that. Stick to diagrams and minimise the text.
#10 – Diagrams created using your own drawing style.
If you develop your own drawing style your diagrams will be difficult to read for others and your diagrams can easily be misinterpreted. Use industry standards when creating diagrams. Determine up-front what notation you will be using when drawing diagrams – for instance BPMN, UML, EPC diagrams etc.
Comments