In this section, we first present an overview of PMSS and discuss the activities that need to be taken for each guideline step. In Sect. 5.2, we briefly introduce the tool support and we illustrate the application of PMSS on an example business case in Sect. 5.3.
Elements of PMSS
A graphical representation of PMSS is shown in Fig. 3. The bottom part serves as a legend. The white blocks indicate the steps that are taken in order to conduct a process improvement project. As mentioned before, these steps are based on the process mining methodology of PM2 (van Eck et al. 2015) (which fulfills the requirement R3 as presented in Sect. 4.2). The goal of PMSS is to guide Six Sigma practitioners in using process mining to support the DMAIC of Six Sigma, and potentially make it more efficient/effective in order to perform related DMAIC activities. To do so, the steps of PMSS have been aligned with the phases of the DMAIC model (fulfilling R1). However, as a result, the steps no longer flow in the same order as in PM2.
As depicted in Fig. 3, PMSS consists of eight steps in the main flow that are explicitly positioned within the five phases of DMAIC: (Define) Planning, preliminary data preparation, exploratory mining & analysis, (Measure) data preparation, (Analyze) explanatory mining & analysis, (Improve) process improvement, and (Control) monitoring and evaluation. These steps and phases are depicted in sequence with a feedback loop connecting the end phase to the first to represent the cyclic nature of the DMAIC model. However, this depicts an ideal flow and PMSS presumes iterations between steps and phases (fulfilling R6) to reflect the case in real-life Six Sigma initiatives. Inheriting the properties of PM2, PMSS is designed to be applicable for the improvement of processes in any business domain (fulfilling R5).
The guideline contains a resource layer showing the roles that act as the leading role for each step. Three roles are at the core of PMSS: Data analysts, process analysts, and business user. Briefly put, a data analyst collects, processes, and uses the data related to process executions. The process analyst is an (IT) professional specialized in analyzing business processes and workflows with the objective of finding opportunities for improvement. The business user is an abstract role representing those that are knowledgeable of organizational processes, such as business unit managers, process owners, change managers. Each PMSS step is assigned to one of these roles as being responsible (leading), although the work at each step requires a team with members representing all three roles which are closely collaborating and making use of the expertise and viewpoint brought along by each one of them.
Table 4 provides more details regarding each PMSS step with a brief list of corresponding inputs, outputs, activities, and the responsible role (fulfilling R2). (Further details regarding these activities of each step is available at: https://goo.gl/nBm3e5). Section 5.3 demonstrates a number of steps alongside an example business case.
In the paragraphs below, we elaborate more on the PMSS steps that have been defined and enhanced based on the feedback gathered from field experts along the DMAIC phases. (Where necessary, we explicitly refer to the feedback gathered from the experts we interviewed to justify specific design decisions made for PMSS).
The Define phase incorporates three steps. In the Planning, the business goals and questions are identified, the processes to be analyzed and improved are selected, and a project team is established. In order to help identify appropriate business goals and accompanying business questions (that are related to one or more aspects of business processes, i.e., quality, time, resource, costs), the preliminary data preparation is performed, so that a brief overview of the process can be gathered on the event data in the exploratory mining & analysis step. However, before considering the event data, it is important to have clear business goals and questions that you expect to be addressed in the following steps. If there is no clear orientation for the improvement project, it is likely to fail (as maintained by PMC1 and PMM2; please refer to Table 3 for abbreviations).
The input for the planning step comprises a broad spectrum of information regarding the organization, such as its business processes and major issues faced regarding these processes [PMD1], a selection of processes that are known to contain issues and require attention for improvement [PMC3], and first insights gained from exploratory mining and analysis. As a result of a set of activities in this step, the business goals and questions are defined, processes to be improved and supporting systems are identified, the project team with members that bring different perspectives to the process execution is composed, and a preliminary description of the business case is defined. The leading role in this step is the business user acting as the project owner and contributing with the domain knowledge and relevant context information (satisfying R4) to ensure that the initiative starts in the right direction [PMC1, PMS1]. Although these activities in the planning step are depicted in an ideal sequence, they are iterative as their actual execution unfolds.
The objective in the preliminary data preparation step is to provide data for the coming exploratory data analysis, and in turn to facilitate the planning step in better identifying business problems and building a business case for the initiative. As depicted in Fig. 3, this step is a special form of data preparation. At the Define phase, process mining can provide insights into the current process-related problems and complement the traditional techniques applied in this phase. Therefore, there is a need for a set of quickly-performed data preparation activities to provide sufficient input for the subsequent exploratory mining and analysis. Hence, we differentiate this set of preliminary data preparation activities, which would quickly offer data that can allow process analysis to be conducted with a wider lens, and the data preparation activities performed in the Measure phase, which aim to provide enriched data regarding KPIs that are focused on the identified business problem and scope to enable more in-depth explanatory mining & analysis for performance measurement.
The (preliminary) data preparation is comprised of three sub-steps: (preliminary) data extraction, where the process execution data is extracted from selected information systems; processing, where the data is prepared so that it can be stored in an event log and can be loaded into a process mining tool; and verification, where the data is reviewed for correctness and validity to ensure that it correctly depicts the actual process. In the data processing sub-step, the good practices include the definition of an audit trail of the changes made to the data and the description of the data types in the log [PMM1]. At this step, the leading role is the data analyst [SSP1 and SSP2].
The exploratory mining & analysis step is a special form of mining & analysis that is carried out with exploratory motives to support the identification of process-related business problems. It takes the data originating from the previous step as input and incorporates three families of techniques (that we discussed in Sect. 2): process discovery, conformance checking and process analysis (covering also enhancement techniques). In addition to process mining techniques, the process analysis incorporates statistical methods and techniques (such as Pareto analysis, histograms, descriptive statistics (Pyzdek 2003)). Such techniques are often used in Six Sigma initiatives to support traditional process analysis. The importance of traditional process analysis alongside process mining is stressed by multiple studies in the process mining field in which process analysis makes up for a large share of the actual reasoning (Berger 2017; Ryu et al. 2017; Smith and Day 2017). Note that the mining & analysis does not enforce any predefined order for the use of process discovery, conformance checking, and process analysis techniques.
The feedback arrow from the exploratory mining & analysis step to planning indicates that the insights gained from the exploratory analysis can serve as input for establishing the business goals. The process analyst ensures that the activities in this step are properly carried out (van Eck et al. 2015).
The three steps in the Define phase, planning, preliminary data preparation, and exploratory mining & analysis can be conducted iteratively until the business goals for the improvement project are clearly defined. The define phase also clarifies which additional execution-related information should be extracted from the information systems.
Based on the specification of the required additional information to be extracted from the information systems, in the data preparation step of the Measure phase, process data and metrics relevant to the business problem are retrieved, a baseline is established, and current process performance is determined. This is achieved through the sub-steps of data extraction, processing and verification. The objective is to extract additional process execution-related data from the information systems of the organization, to process it to obtain a clear, filtered, and enriched event log, and to verify that the data is correct and valid and can be used as input to the next step, i.e., the explanatory mining & analysis. The leading role for this step is the data analyst [SSP1 and SSP2].
In the Analyze phase, a closer look is taken at the data through explanatory mining & analysis. In this phase, the team guided by the process analyst performs detailed analyses of the data with the aim to detect potential causes for the problems identified in the previous phase (Define), and identify improvement opportunities that can be acted upon in the next phase (Improve).
The explanatory mining and analysis step comprises three sub-activities: process discovery, conformance checking, and process analysis (as indicated in the legend by the block titled mining and analysis in Fig. 3). Although the techniques used in this phase are the same as those used in the exploratory mining & analysis step, the analyses are driven by identified business questions aiming to address the improvement goals. In turn, the level of analysis at this step is deeper and intense. The main input constitutes the event logs created in the data preparation step, the audit trail, the data description, and business problems.
The opportunities identified in the previous step are addressed in the Improvement phase. In this phase, process mining can be useful in detecting the likely impact of alternative improvement actions and in selecting those that are likely to bring the highest impact when implemented.
As the actual implementation of the process improvement action takes place on the business side, the business user takes the leading role in this step, and implements and manages the required changes in the processes [PMC1, PMC2, PMM1, PMM2] taking the improvement opportunities found in the previous step as input. The deliverable of this step is subsequently improvements or so-called process changes towards business goals.
In the Control phase, the process mining techniques can be used to monitor the predefined process performance indicators to help evaluate if the implemented changes have yielded the expected results. In this phase, we can distinguish two steps: monitoring, where the process execution is monitored with respect to the performance indicators, and evaluation, where the organization determines if the impact of the changes depicts the expected results and whether the process has been successfully improved. As a result of monitoring, new findings may also emerge leading to new business problems and in turn a re-initiation of the DMAIC cycle. As we mentioned above, although Fig. 3 depicts a single feedback loop from the Control to the Define phase, PMSS assumes iterations that allow traversing between any prior phase.
In the monitoring step, the business user (e.g., the change manager) is the leading role to identify and prioritize the process performance indicators (and metrics) that are of importance to the organization and thus should be monitored [PMS1]. In addition, since it is important to have domain knowledge at this point and since the evaluation happens on the business side [PMM2], the business user (e.g., improvement project leader) is responsible for evaluating the values of the indicators that are monitored in order to assess if the process improvements have yielded the expected result [PMM2].
The Tool Support
As indicated in R7 (Sect. 4.2), a complementary tool support that allows Six Sigma practitioners to use available process mining techniques in a single platform is important for the usefulness of PMSS. As described in Sect. 4.5, we developed the tool support for PMSS as an extension to the ProcessGold platform. One of the unique features of the ProcessGold platform is its ability to add tags to cases in order to group them according to certain relevant properties. For example, in the ProcessGold platform the cases with certain issues can be tagged so that they can later be located using filters for the tag. This has made it a suitable candidate platform for our tool support.
For each of the phases of the DMAIC model, one or more dashboards have been created based on the draft interface sketches developed during the brainstorm sessions with potential users and experts (Sect. 4.5). These sketches were refined during the focus group sessions and usability tests performed with domain experts (Sects. 4.5 and 4.6) and during the demonstration and evaluation sessions that we discuss in the next section. 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 more elaborate analyses.
As an example, a screenshot of the dashboard created for the Define phase is presented in Fig. 4. Each dashboard element (numbered 1–3 in the Fig. 4) addresses a certain need to fulfill a particular user objective that we gathered through the brainstorm sessions. For instance, as maintained by all experts except one, 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 in Fig. 4 (#1) is placed showing a discovered process graph tuned with respect to the number of execution paths.
As also supported by 4 experts (PMD1, PMD2, PMC1, PMC2), 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 in Fig. 4 (#2) 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. From these dashboard elements, it is possible to navigate to that part of the application that supports more elaborate analyses of the information shown in the charts.
A detailed explanation of the tool support and reasoning regarding specific design decisions is available at: https://goo.gl/LPZJpC.
Demonstration by Means of a Business Case
In this section, we provide a brief demonstration of the PMSS and tool support by going through a real-life business case that involves an organization (ABC Inc.) adopting Six Sigma quality management framework and following the DMAIC model.
In the Define phase, ABC performs the planning, preliminary data preparation, and exploratory mining & analysis activities. For the planning, ABC considers a number of complaints that it has received from its suppliers about invoicing, and conducts short discussions with a number of employees that are involved in the related process with the main objective of defining the scope for the initiative and the goals that it aims to attain after improvement actions are implemented. As result, ABC considers focusing on its invoicing process, which is deemed to suffer from long processing times. It sets up a team involving a number business users, internal data and process analysts, and a team leader appointed as the project/process owner.
The planning is facilitated by the preliminary data preparation and exploratory mining & analysis activities in order to provide a better understanding of the business problem in the invoicing process. Relevant data about the invoicing is extracted from ABC’s current enterprise information system, prepared and loaded into the PMSS tool support for the subsequent exploratory mining and analysis. At this stage, the data requirements are kept at a minimum to expedite the mining and analysis. (For the sake of brevity, we do not show the screens of the application components that show the loading of the data).
Figure 4 (given in the section above) shows the screen for the Define dashboard of this business case. The first screen element shows the process graph for the invoicing process. At the bottom of the second element, we can see that the average processing time is 4 days when all 1855 process execution instances (cases) are considered. The avg. processing time is highest for medium invoice cases (9 days) and lowest for employee declaration cases (2.3 h).
Checking the process graph, the team notices considerable repetitions of certain activities as a sign of excessive rework (i.e., loops and self-loops in the process graph) which potentially lead to longer processing times. For further analysis, the team selects one of the arrows that indicates a repetition of a certain activity (i.e., the activity ‘final check of invoice’). Figure 5 shows the updated dashboard screen when the process instances (cases) with repetition of this activity are selected by the user. As can be seen in the figure, the average processing time for the cases where this activity is repeated is twice as long (8 days) as the average time when all cases stored in the tool is considered.
Performing similar analyses on other activity repetitions (and possibly a more elaborate analysis of the information shown in the charts) confirms the initial considerations regarding the potential cause of long processing times. Having gained an initial understanding of how the process has been executed, its performance and potential problems, the team closes the Define phase and moves onwards to the next DMAIC phase.
At the Measure phase, the data analyst takes the lead to extract additional process execution-related data from ABC’s enterprise system for enriching the event log (e.g., with data from an extended period of time and other type of cases), and verify that the data is correct and valid. Figure 6 shows the dashboard for the Measure phase. The data analyst uses the dashboard to check if the data loaded into the application is correct (for instance, by comparing the numbers of cases, activities, and users with those in ABC’s enterprise system from which the data has been extracted). Furthermore, the open and closed cases are rechecked to ensure that the cases started and closed as expected.
At the top right of Fig. 6, the number of activity repetitions per case is shown. The fact that, on average, each activity in a case is repeated 1.14 times, provides a further suggestion regarding the cause of the problem.
When the team has verified the correctness of the data, they move to the Analyze phase. Figure 7 shows the dashboard for this phase, which consists of two views: the overview and statistics. In the overview (as shown in Fig. 7), the cases that are problematic are compared to the other cases. In the case of ABC’s invoicing process, problem cases refer to those process executions that feature activity repetitions, and, in turn, rework. Hence, the overview dashboard shown in Fig. 7 is tailored to reflect the Six Sigma waste problem at hand, i.e., rework (as opposed to, for instance, inefficiency).
The overview dashboard features a process graph (element #1 in Fig. 7) to determine if the paths of the problem cases with rework (in purple) deviate significantly from the paths of other cases (in orange). In addition, the team analyzes a number of graphs each differentiated for problem cases and other cases. They analyze the average processing times for different cases (#2), the resources involved in the process to check if a particular resource is a major contributor to the problem (#3), and the average number of times an activity occurs in the cases (#4). The graph in dashboard element #5 shows the progress of ‘defects per million cases’ (DPMO) – a metric that is of particular importance for the Six Sigma initiatives. The graph in element #6 shows the workload, i.e., the percentage of cases that are considered problematic with regard to the repetitions.
The team sees that the average processing time (#2) is higher for the problem cases than for the other cases for majority of the case types. The same situation holds for the number of activity repetitions per case (#3). The DPMO metric, which is expected to be 3.4 for Six Sigma, is considerably higher – around 175 k.
Furtheron in the analyze phase, the team performs additional investigations and analyses supported by a number of dashboard elements and related graphs with the aim to locate the causes that contribute most to the problem, and hence to decide on the improvement alternatives to act upon in the improve phase.
In order to keep this section concise, we present the further demonstration steps on the following page: http://tiny.cc/pqesdz.