Initially, Process Mining solutions were really designed for experts (even if they prentended to provide their solution to business users). That may be also the reason why it was so complicated to set up and make successful such projects or initiatives like this. Unfortunatly not all the Process Mining were successful. at the beggining at the era of this solution.
The complexity of these tools due also to the nature of the processes themselves has drawn the limitation of the outcomes. Moreover addressing a Business Process Improvement project by the technical prism is really a big mistake. There is no magic behind any solution ! You always need to manage the magic tuple (Resources, Solution and Methodology).
The reality is more simple. Only the business analyst (or Process Analyst) knows and can really understand and improve its own process. This job cannot just be done simply by a technical person ! On one hand you have someone who is the only one to be able to use the Process Mining solution, and on the other hand you have someone who owns the process and can say what behavior is normal and what is not. So the project success was clearly and totally linked to the capability of working together the two teams IT-Business could provide. And we all know that’s not so obvious.
This is why it was so important to have another approach, an exploration approach. The business users need to explore their process, they need to be able to see the variations, the duration, and all what’s happening when a process is performed.
So in addition to the reporting approach, it’s important to let these business users explore their data/processes so that they could, alone, figure out new outcomes, pains or behaviors not expected.
Let’s try to summarize the two different approaches:
| Process Reporting | Process Exploration |
|---|---|
| Design and usage for IT mainly | Design for a business user usage |
| More features | Less feature |
| Complexity of use (Low Code, for example such solution have their own Query languages) | Ease of use (native business views ready to use, no code) |
| Longer to setup/get an outcome | Quick win easy to get (low hanging-fruit) |
| Can provide very complex and complete reports/outcomes | The purpose is not to provide reports but instead helps user to navigate into the processes |
| Dashboard capabilities | Dashboard capabilities |
| Monitoring + alerting capabilities (designed by IT) | Monitoring + alerting capabilities (designed by Business) |
That does not mean at all the reporting approach is never appropriate. In fact these two approaches should get along well because they do not have the same goal. So choosing one or both approaches is not so easy.
The choice can be guided by these criteria:
- The targeted personas (users)
- The outcome expected / duration (and cost)
- Generic vs Specific solution
- The pareto law