Through my experience with implementations of sophisticated BPM solutions – predominantly in the telecoms sector – I have learned that many companies conclude to commence such implementation for the wrong reasons. The common train of thought is: we have a problem with that process, it takes too much time/effort, and therefore we need to implement something like a Busines Process Management system to improve the key indicators.
Although this sounds simple, I find this logic has flaws that drive such “process transformation” initiatives off road. So, where does the logic go wrong? To me, the implementation of a typical BPM system should follow the process definition and improvement effort and not running alongside of it.
This is how the process is usually planned:
What is a major problem here?
The BPM implementation runs in parallel with Change Management and therefore is prone to all the high risks of the typical operational change programs on top of its own delivery risks.
Moreover, companies usually involve Business Analysts that are either experienced in BPM implementation and therefore provide little value on the process improvement side, or focus on Process Improvement and therefore undermine the IT implementation.
What should happen instead?
As the diagram above shows, the proposed methodology includes such changes as carrying out a research that will feed statistics and facts into Process Redesign and Change Management program.
What is that Research for?
We propose the following mandatory questions to be answered before moving ahead to the Process Redesign:
- What is the process lead time and how does it vary for different sub-processes (e.g. order types or product types or any other vital process parameter)?
- If broken into major phases, what is the average time for each phase/step?
- How many exceptions happen during the process that either create additional effort or introduce delays? What types of exceptions there are and how impactful each of them is?
One might say that this is going too far into the management consulting field, however the authors based on their vast experience, argue that such study can be carried out within 2-3 weeks on a reasonably complex process. It often requires interrogation of existing IT systems, such as ERP or legacy BPM that can be handy, but the only tool that’ll be required to master the collected data is a simple spreadsheet.
Aside of that, another important outcome of this phase is establishing the targets for the future improvements: what KPIs should be targeted and how. It should be clear how each target is reached and by what means or tools, i.e. change in the process flow, reporting, collaboration or other standard BPM tools.
The change management programs have to tackle the problems identified in the previous steps. The list of issues with their severity and impact needs an appropriate “change” within such program.
A result of this, the new process map with established and proven flow (one that business actually follows!) is generated and then used later for BPM implementation.
The approach we advocate is to tackle the process redesign and process automation in separate steps. What’s more important is:
- To be fact-based
Follow the evidence-based practice and establish facts prior to doing any of the above steps. Know your weaknesses. It is critical to establish performance gaps qualitatively and then address the organizational part before implementing a Business Process Management system.
- To be target-based
Do not get both feet deep into any BPM implementation without clear qualitative KPI improvement goals. Each such improvement should be listed along with specific tools that will help you achieve them.