This site aims to complement the material published at:
Graafmans, T., Turetken, O., Poppelaars, H. et al. (2021) Process Mining for Six Sigma. Business Information Systems Engineering. 63, 277–300 (2021). https://doi.org/10.1007/s12599-020-00649-w
The tool support for the PMSS guideline has been developed as an extension to the ProcessGold platform (https://processgold.com/en/).
For each of the phases of the DMAIC model, one or more dashboards are created based on the draft interface sketches developed with a number of potential users and experts. Each dashboard contains visualizations that support the initial analysis relevant for each phase. When further analysis is needed, the visualizations link to that part of the application that supports this more elaborate analysis.
Below, we briefly explain the tool features supporting the phases of the PMSS (Process Mining for Six Sigma) Guideline
A screenshot of the dashboard created for the Define phase is presented in Figure 1. Each dashboard element (numbered 1-3 in the Figure 1) addresses a certain need to fulfill a particular user objective that we gathered through the brainstorm sessions. For instance, the most prominent mining technique that can be used for exploratory mining & analysis at this phase is process discovery, which reflects how the actual process execution took place and what bottlenecks can potentially be identified in the process. Therefore, to check for deviations in the process, the first dashboard element (#1) is placed showing a discovered process graph tuned with respect to the number of execution paths.
Particularly when the goal of the project is to improve the performance of a business process, process analysis (or enhancement) techniques can be used to analyze the performance through indicators, such as throughput time, waiting time, or total cost. Hence, the second dashboard element (#2) in Figure 1 presents the average completion times of different case types in order to check if cases with certain properties in common have different average processing times. In relation to that, the third element (#3) shows the extent to which certain activities or resources contribute to that average to assess if they are potentially responsible for long processing times. From these dashboard elements, it is possible to navigate to that part of the application that supports more elaborate analysis ofthe information shown in the charts.
Figure 1. Screenshot of the dashboard for the Define phase
For the use case depicted in Figure 1, the goal of the improvement project is business process performance improvement. In this use case, the metric that the organization wants to improve upon processing time. The process graph (#1) is highlighted based on the number of cases. The darkest paths are those that are taken more frequently, while the lighter paths are not taken that often. The bar chart (#2) shows the average processing time of cases, where the grouping is based on the selected case property. By combining this bar chart with the process graph, it is possible to, for example, check whether the less frequently visited paths yield a higher processing time and therefore could be a problem. Lastly, it may be the case that there are certain activities or resources that are responsible for high processing times. Therefore, a bar chart (#3) is added where the contribution of activities or resources to the average processing time is shown.
From all three dashboard elements, it is possible to navigate to that part of the application that supports more elaborate analysis ofthe information that is shown in the chart. These dashboard elements can be used to support the identification of potential process-related problems. For example, when all cases with a self-loop are selected from #1, the team can see in #2 that the average processing time doubles. Thereby, the team can show that the suspected rework problem is in fact an actual problem.
The findings from the exploratory mining & analysis can serve as input and be combined with traditional Six Sigma tools in the DMAIC toolkit. Next, a preliminary business case can be created which serves as the basis for the improvement project. Once the team has created this, they can move on to the Measure phase.
Figure 2 presents the screenshot of the dashboard in the Measure phase. In the PMSS tool, the data extraction and data preparation happen in a separate module of the ProcessGold platform, called the Connector. Thus, the goal of the dashboard presented in Figure 2 is to verify that the data imported into the tool is correct. The dashboard shows the a collection of metrics (number of cases (#1), activities (#2), events (#3), and users (#4)) so that they can be compared to the output of the information systems. For the use case depicted in the dashboard, the potential problem is rework. Hence, the number of repetitions per case (#5) is also shown to confirm the exisitance of the problem. In addition, the trendlines of the open (#6) and close (#7) activities are also shown, so that it can be verified that the data only contains cases that are opened and closed. Finally, the dashboard contains a trendline of the events over time (#8) to check if there are no abnormalities. From these dashboard elements, it is possible to navigate to that part of the application that supports more elaborate analysis ofthe information that is shown in the module.
Figure 2. Screenshot of the dashboard for the Measure phase
The goal of the dashboard for this step is to provide a general overview about the business problem in relation to the other cases, and relevant statistics. Creating dashboards which are generic and suitable for multiple problems is a challenging task. The design should show the versatility of the platform and support continuous improvement analysis when the problem changes. We should note that, in this phase, the dashboard elements can be tailored to address the needs for a specific problem or a viewpoint (e.g., rework or inefficiency).
The overview dashboard is presented in Figure 3. This dashboard consists of a process graph to determine if the paths of the problem cases deviate from the paths of the other cases (#1). Additionally, it shows the average processing time for the problem cases and the other cases (#2). Using that dashboard element, it is possible to see if there are problem cases with certain properties that have a higher average processing time than other cases with the same properties. Furthermore, a dashboard element that shows the resources that are involved is added (#3) to check if a resource might be responsible for the problem. If a case has a lot of repetitive activities, it contributes to the average processing time. Therefore, it is shown how many times an activity occurs within a case (#4). The DPMO (#5) is shown to provide Six Sigma practitioners with a familiar metric which indicates how many problem cases per million cases there are. The workload (#6) is shown to indicate the percentage of the cases that is a problem case.
Some of these dashboard elements map to different types of wasteof the Lean Six Sigma methodology. For the use case, the selected metric is the processing time. When the selected metric would be waiting time instead of processing time, dashboard element #2 links to waiting. Dashboard element #4 links to defects (which are sometimes defined as cases with rework) and dashboard element #3 can be used to investigate non-utilized talent.
Figure 3. First Screenshot of the dashboard for the Analyze phase
We also developed the statistics dashboard as depicted in Figure 4. This incorporates traditional statistical Six Sigma tools that can be used in the explanatory mining & analysis step. Here, for instance, it is possible to identify the different causes that contribute to the problem and how these causes relate to time. Therefore, it consists of a Pareto chart which shows the contribution of the causes to the problem (#1) and line charts to analyze the potential causes in relation to time (#2). The Pareto chart (#1) can be used to select the improvement opportunities that contribute the most to the problem. The causes that contribute the most serve as input for an Ishikawa (cause-and-effect) diagram. The line charts can be used to find out for which cases with certain properties the problem is structurally high.
Figure 4. Second Screenshot of the dashboard for the Analyze phase
The dashboard in Figure 5 helps to determine the impact of the different improvement alternatives identified in the Analyze phase. It presents the impact of the improvement alternatives on metrics such as total costs, processing time, and DPMO (#1). Furthermore, it would be interesting to check the improvements alternatives over time to see if they are time-dependent (#2).
Figure 5. Screenshot of the dashboard for the Improve phase
The PMSS Tool can also be used to visualize if the process changes actually improved the process. The dashboard presented in Figure 6 shows how the problem and the improvements change over time for the same metrics we used in the Improve phase. It shows an X/Y analysis (#1), where the problems ("Y") and causes ("X") that contribute to the problem. In order to check how these causes differ before and after the improvement , line graphs are created so that the periods can be compared to each other by looking at the height of the lines before and after the improvement . For the use case, the organization looks if the processing time changed after the improvement date for the cases with a rework problem.
Figure 6. Screenshot of the dashboard for the Control phase
PMSS has been developed by Eindhoven University of Technology, Infornation System Group and ProcessGold. For more information, please contact: o.turetken@tue.nl