End-user’s corner: Dominic Giss

end-users corner

An interview with Dominic Giss

Dominic Giss is the Head of the Competence Center for Operational Excellence of the biggest Swiss Health Insurer. We ask him how he sees process mining in his experience.

Dominic, where and when did you first hear about process mining? 

I got introduced to process mining while working for a large consulting company. I then helped several clients to understand and improve their business processes, both in terms of process assurance and sustainable optimization.

How do you use process mining in your organisation? 

At my current employer, we use various data-driven methods for monitoring/controlling and to optimize processes. If process mining is applied, then primarily during early project phases (discovery) of larger process optimization projects.

This allows us to create a strong, precise data-layer upon which we build, on the one hand, dashboards containing the processes' "vital signs", on the other an interactive analytical instrument to search for undesired patterns.

How do your counterparts perceive and adopt process mining? 

They very much like the visual representation of the processes and the fact-based nature of the results. This allows for a much more objective discussion on the current state of the processes, as well as a single source of truth for impact quantification.

I am not saying that this makes the discussion more pleasant though :-) 

What is the major challenge while using process mining? 

Challenge is twofold: first, getting (the right, complete) data and, secondly, translating the visual transparency into insights that can be incorporated into the overall project workflow. For the first leg of the challenge: I see process data coming from different systems at different levels of abstraction (e.g., workflow steps, web-service calls or clicks on a GUI), and processes triggered by an automated user (robot or batch) which may occur in random order. So, constructing a log that faithfully represents the complete process and without introducing unneeded complexity is tricky (see below my recommendation for research - Occam's razor!)

For the second leg of the challenge: data tells us how the processes are executed and recorded in the system, but it does not put it into the context in which they are executed. We need, then, to be careful when interpreting those “maps” and be very selective to what extend these “insights” are of value during root-cause and hypothesis validation step. This is why an effective process optimization project typically applies various tools and methods.

What was your “ah-ha” moment while using process mining? 

Laugh… a bit embarrassing. When I empirically discovered/understood the difference between an event- and a case attribute. So easy it might be or sound, the impact during the log-engineering phase is tremendous.

How do you see process mining in the future?

As digitalization continues and thereby digital process footprints become more accessible, the foundation for process mining greatly improves. However, I believe that data-driven methods or data-driven decision making as such become more important and not a single method.

Finish with a freestyle, maybe provocative, but anyway to you relevant question. What would it be? "What should research in/around Process Mining stop doing/assuming?"

Stop thinking the process map or a visualization of a process is your result or of massive value for the business. Typically, there is hardly any value that goes beyond process discovery phase by just having a process map. The inputs created using process mining have to be incorporated into the overall process optimization methodology.

  1. Stop thinking the process map or a visualization of a process is your result or of massive value for the business. Typically, there is hardly any value that goes beyond process discovery phase by just having a process map. The inputs created using process mining have to be incorporated into the overall process optimization methodology.
  2. Stop thinking there are event logs ready to be used, at least until you know how they are built.
  3. Stop assuming there is event data at all that could be transformed into event logs
  4. Stop thinking event logs are all of the same structure (data model). Log engineering is key!
  5. Stop thinking that there is just one process-object. Typically, there are several hierarchical levels and analytical questions that must be addressed can incorporate all of them simultaneously.
  6. Stop thinking you can optimize processes solely on the grounds of process mining.