Enhancing decision-making of IT demand management with process mining

Abstract

Purpose

Digitalization, innovation and changing customer requirements drive the continuous improvement of an organization's business processes. IT demand management (ITDM) as a methodology supports the holistic governance of IT and the corresponding business process change (BPC), by allocating resources to meet a company's requirements and strategic objectives. As ITDM decision-makers are not fully aware of how the as-is business processes operate and interact, making informed decisions that positively impact the to-be process is a key challenge.

Design/methodology/approach

In this paper, the authors address this challenge by developing a novel approach that integrates process mining and ITDM. To this end, the authors conduct an action research study where the researchers participated in the design, creation and evaluation of the approach. The proposed approach is illustrated using two sample demands of an insurance claims process. These demands are used to construct the artefact in multiple research circles and to validate the approach in practice. The authors applied learning and reflection methods for incrementally adjusting this study’s approach.

Findings

The study shows that the utilization of process mining activities during process changes on an operational level contributes to (1) increasing accuracy and efficiency of ITDM; (2) timely identification of potential risks and dependencies and (3) support of testing and acceptance of IT demands.

Originality/value

The implementation of this study’s approach improved ITDM practice. It appropriately addressed the information needs of decision-makers and unveiled the effects and consequences of process changes. Furthermore, providing a clearer picture of the process dependencies clarified the responsibilities and the interfaces at the intra- and inter-process level.

Citation

Novak, C., Pfahlsberger, L., Bala, S., Revoredo, K. and Mendling, J. (2023), "Enhancing decision-making of IT demand management with process mining", Business Process Management Journal, Vol. 29 No. 8, pp. 230-259. https://doi.org/10.1108/BPMJ-12-2022-0631

1. Introduction

Digitalization, innovation and changing customer requirements drive the improvements of business processes. However, in order to make accurate decisions on these process changes, a deep understanding of the real-world execution of an implemented process is required. Business process change (BPC) includes different ideas like process redesign, re-engineering or improvement, with the goal to incrementally or radically changing a process (Gross et al., 2019). However, the redesign of business processes is associated with various challenges, especially in relation to information technology (IT) or information system (IS) integration. Such challenges include the efficient allocation of resources, clarification and understanding of issues, and problems of quality assurance (Javidroozi et al., 2019).

IT demand management (ITDM) is an approach to holistically manage IT demands which relate to changes of business processes. ITDM complements existing software development methods and facilitates the allocation of resources to implement the company's requirements (Alonso et al., 2013), which eventually leads to process improvement (Pombinho et al., 2013). One of the consequences is growing dependency between IT and BPC, as well as the new challenges arising from this. ITDM is meant to ensure that the IT resources of a company are used economically (Mckeen et al., 2012), but also faces trade-offs and blind spots. While the cost and benefits of each decision must be balanced (Thompson et al., 2014), the expectations of a demand realization diverge between the decision-makers (Quichiz and Oré, 2017). They are typically unaware of how the business processes operate and interact with other IT resources. As a consequence, ITDM faces allocation challenges due to the risk of causing negative impacts on the (to-be) changed process (Pombinho et al., 2013; Quichiz and Oré, 2017). This leads to inaccurate and inefficient decision-making with follow-up costs and impacts on stakeholder satisfaction.

In this paper, we address these challenges by introducing a novel approach that combines process mining techniques with ITDM to improve decision-making on process changes. The used process mining techniques provide operational insights with the potential to inform decision-making (van der Aalst, 2008; Mendling et al., 2017). We conducted an Action Research (AR) study that brings together a team of researchers and practitioners who were involved in activities for planning, designing and evaluating a new ITDM approach. The benefits of the new approach are demonstrated in a use case from a leading European insurance company. In our work we complement an IT methodology for process changes in form of IT demands with process mining techniques. We demonstrate how the availability of a tool that visualizes the “real” process offers various insights for decision-makers with the effect of a more efficient and effective ITDM approach.

The rest of the paper is structured as follows. Section 2 defines the theoretical background of ITDM and decision-making in the context of BPC management. Section 3 describes the research method. Section 4 introduces the case and explains how we follow the research process to create our approach. Section 5 presents the findings from applying our approach in the partner company with a discussion of lessons learned. Section 6 concludes the paper and outlines future research.

2. Theoretical background

2.1 Managing and mining of business processes

A business process is defined as a set of activities that are performed based on a given input by an organization to achieve a specific goal. These activities are typically designed to be repeatable, scalable and may involve a combination of human actors, machines and IS. Business processes are essential for organizations to achieve operational efficiency, consistency and quality in their operations (Dumas et al., 2018). For instance, a claims process is an example of a business process used by insurance companies to handle claims from policyholders. The process involves a series of steps such as claim verification, investigation, pay-out calculation and payment issuance. A well-designed claims process ensures efficient and accurate handling of claims, which helps to maintain customer satisfaction and minimize costs associated with fraud or errors.

BPM integrates different perspectives from computer science, management science and information systems research and is an important method to establish a comprehensive process view of operations within a company (Mendling, 2016). It was established at a time when the reengineering of business processes was a common practice, but the impact on the business was not completely clear (Davenport and Stoddard, 1994). The change of business processes always comes with problems that have a different influence on the success of the changes (Grover et al., 1995). However, important success-factors when changing or redesigning a business process are factors related to IT investment, integration, development and sourcing (Al-Mashari and Zairi, 1999).

In the meantime, companies use IT-supported BPM to control processes, increase organizational flexibility, support innovation measures and achieve digital strategy goals. Furthermore, BPM methods and IT provide employees with the means to communicate and collaborate, as well as to prepare for the digital transformation of processes (Fischer et al., 2020). We are engaged in an ongoing discussion about how IT can support existing BPM methodologies. The main driving force for the integration of new IT solutions is not just their availability, but the requirements that arise from insights gained into how business processes are executed (Szelągowski and Lupeikiene, 2020). This leads to an increasing demand of socio-technical assets and methods, which yields adaptations to a social, technological and operational setup.

The approach of process mining is based on the analysis of event logs generated by IS during the execution of business processes such as a claims process. By using this trace data, process analysts can discover the very nature of business processes in a data-driven manner. The advantages of process mining, in comparison to manual process analysis, are its real-time capability and depth of detail. As an outcome of process mining, process visualizations in the form of directly-follows graphs or process performance indicators can then support decision-making of analysts by pointing out bottlenecks, inefficient resource allocations, cycle times, compliance, etc. (van der Aalst, 2008).

2.2 IT demand management in context of BPM and BPC

Nowadays, IT-enabled processes run partly or fully automated, and change on a regular basis due to new customer demands or new regulations. Consequently, the implementation of these changes within corporate IT is an integrative step of business process improvement (Niedermann and Schwarz, 2011). BPM as a management approach focuses on analysing and continuously improving business processes within their lifecycles (Dumas et al., 2018). Furthermore, the presence of an ERP system automatically leads to a dependency between IS customizing and business process reengineering (Etame and Atsa, 2018).

One of the possible ways to increase process maturity is flexible solutions based on agile practices. These methods renewed old ways of thinking of how to design IS and have established as successful approaches for managing system design projects. Specific methods of agile practices are used by companies including Adaptive Software Development (ASD), Agile Modelling, Dynamic Systems Development Method (DSDM) – along with Agile Project Management (AgilePM), Extreme Programming (XP), Agile Software Process (ASP), SCRUM and many more (Marcinkowski and Gawin, 2019). What all these methods have in common is the need to manage change in the form of IT demands or IT requirements. In this context, the allocation of IT services is a key outcome of decision-making in organizations (Urbach et al., 2019), and methods are required to streamline business demands and IT investments for new products and services.

ITDM is a complementary component of existing methods and procedures, like requirements engineering or project portfolio management, to understand, assess and manage the IT demands of a company (Legner and Löhe, 2012). Successful ITDM ensures that a company's IT resources are used optimally and that internal operational processes are organized economically (Mckeen et al., 2012). Moreover, ITDM can support the transformation of a company as an eminent constituent and bridging element for strategic demand management by improving strategic business planning (Alonso et al., 2008). From the perspective of corporate IT, it is possible to identify increased and justified requests about what to change, improved specification of benefits and value generation mechanism, stakeholder visibility, prioritization based on known and systematic criteria, value models that can be checked and reduction of planning volatility (Pombinho et al., 2013).

ITDM manages the process from the emergent demand to the ready-to-use solution (Legner and Löhe, 2012). Demands are a request for a change within the existing IT landscape and are therefore typically linked directly to a process change. The associated effects on resources and processes must also be managed within a demand. In addition, these demands can have a strategic, tactical or operational origin (Mckeen et al., 2012). The management of IT demands involves nine major steps, starting with (1) the collection and classification, (2) specification and (3) evaluation. Next, demands are (4) planned within the IT portfolio, (5) initialized and their (6) functional and (7) technical specifications are approved. Finally, demands are (8) developed and tested, and (9) deployed (Legner and Löhe, 2012).

While IT plays a strategic business role in organizations, strategic ITDM is hardly known by senior executives and IT professionals (Alonso et al., 2013). Yet, the integration of a working demand management within the strategic and operative planning is regarded as one of the key components to the business success of an enterprise (Alonso et al., 2008). As a consequence, ITDM needs to be considered from an operational, as well as a strategic point of view (Orta et al., 2014). Up to now, ITDM has hardly been integrated into operational planning and is mostly decoupled from BPC activities. Although critical success factors for ITDM have been identified (Pombinho et al., 2013; Quichiz and Oré, 2017), there is no model to maximize IT and business alignment (Alonso et al., 2008). Additionally, because of its disconnection to BPC activities, management detains from early commitments because of inaccurate estimations and high-level solution design at the beginning of IT demands (Pombinho et al., 2013). Although IT demands should provide an end-to-end perspective on the new business requirement, they typically lack process specific details which would create a value model between the stakeholders (Legner and Löhe, 2012; Pombinho et al., 2013).

2.3 Decision-making for business process change

Changing market conditions and new customer requirements need quick action when implementing BPC. The implementation of such changes is an important competitive factor for companies (Dumas et al., 2018, pp. 185–211). Yet, transforming business processes does not necessarily require a complete redesign (Champy, 1995), but can be part of incremental business process improvement steps (Davenport et al., 1990; Niedermann and Schwarz, 2011). Regardless the type of redesign, BPM has various ways of how it can contribute to better processes (Van Der Aalst et al., 2016).

An appropriate business process management (BPM) strategy can improve BPC efficiency (Legner and Wende, 2007; Xu, 2011) and facilitate enterprise systems integration (Javidroozi et al., 2019). Various success factors have been discussed in this context, including the availability of information and the push for standardisation of business processes and workflows (Xu, 2011). BPC has evolved into three different themes, namely redesign, reengineering and improvement. Gross et al. (2019) argue that these three consist of the same stages and can be used interchangeably.

A significant challenge for BPC success is the interoperability and responsibility between the departments and process executors. As the change of processes has different implications for different departments (Chen et al., 2008; Smeds et al., 2015), a process change should not be driven by IT alone (Guha et al., 1997). In essence, managing the information between the departments and inter-operation and inter-coordination of the processes are essential. Yet, with growing importance of IT supported processes, the integration of information and technology are important factors for process redesign (Gross et al., 2021).

During a BPC, we distinguish between two dimensions of decision-making. The first dimension characterizes four types of decisions regarding the time-factor of process implementations (van der Aalst, 2008).

1. Design-time decision concerns a decision made during the initial modelling of the process;

2. Configuration-time decision concerns a decision made during the implementation of the process;

3. Control-time decision concerns a decision to manage processes while they are running;

4. Run-time decision is a process-dependent decision made within individual process instances.

The second dimension describes the stage of a process change. An IT demand is a process change effort to incrementally improve processes and a result of either redesign or reconstruction activities. The different stages of a process change are: (1) envision, (2) initiate, (3) diagnose, (4) redesign, (5) reconstruct and (6) evaluate (Gross et al., 2019). In our case, an IT demand is triggered in either the redesign or the reconstruction phase of a process change and we do not distinguish between the origins of a change, regardless it being a redesign, reengineering or improvement effort. In our case, we analyse ITDM decisions that represent the control-time and run-time decisions in regard to the first dimension, and focus on the redesign or reconstruct stage of a business process in regard to the second dimension.

While documentations of running processes exist, organizations often have limited insights and narrow understanding of how the processes are really executed or technically implemented. Yet, an understanding of how business processes are changed is essential for management and stakeholders (Cochran and Gupta, 2017). Therefore, reducing this problem includes clarification and knowledge of existing processes (Momoh et al., 2010). Traditional process improvement relies on top-down or de-jure process analysis instead of bottom-up de facto data-driven approaches (Fleig et al., 2018, pp. 228–244). Visualization, as part of such analysis, is an important benefit to understand current business processes (Harmon, 2019, p. 325; Slack and Brandon-Jones, 2018) but is considered as a significant requirement of BPC as well (Liu et al., 2009). Furthermore, the use of process mining will help to understand the practical value of a new technology in conjunction with BPM methods and IT requirements, which still remains a challenge today (Szelągowski and Lupeikiene, 2020).

Increased process awareness would be beneficial for ITDM and BPC in various ways. First, ITDM stakeholders would benefit from the process insights and level expectations on technical and business perspective. In the same way, BPC would benefit because existing business processes would be better analysed and assessed in detail before a change. Second, the involvement of process managers, subject matter experts and IT experts would increase the collaboration between the departments in regard of changing processes. Third, the availability of process related data would improve quality, timeliness and provision of a change.

3. Research method

3.1 PADRE as a research method

As a research method, we utilize the PADRE framework proposed by Haj-Bolouri et al. (2016). This iterative method is an extension of active design research (ADR) (Sein et al., 2011) that incorporates elements of participatory design (PD) to shift the focus towards organizational learning (Haj-Bolouri et al., 2016). In fact, we, as researchers, actively guide and contribute during different stages of the design to foster an integrative perspective of science and practice (Avison et al., 2018). Similar to classical design science research (DSR), the output of our research is an artefact (Mullarkey and Hevner, 2019). Thereby, we follow previous work in the area of process mining that provides a practical view on its application (Emamjome et al., 2019; Grisold et al., 2020; Jans et al., 2011) by considering the social and organizational dimension (Baskerville and Myers, 2004; Mead, 1913).

PADRE adopts principles and philosophy from participatory action research (PAR) and participatory design (PD), to provide a front-end of action research (AR) that emphasises learning through incremental iteration (Haj-Bolouri et al., 2016). PADRE consists of four key components, which are linked and connected by reflection and learning activities. These components are (1) problem definition and planning, (2) implementation, (3) evaluation and (4) reflection and learning. The project is initiated by problem definition and planning activities that are similar to concept and problem design stages of Mullarkey and Hevner (2019). Afterwards, (2) the implementation exploits PD to address the formulated needs and requirements. The (3) evaluation documents continuously the learning outcomes through participative observations together with the involved stakeholders and evaluates the created artefact against the requirements and findings. During the (4) reflection and (5) learning sessions, researchers and participants present results and discuss proposed decisions for further action implications. Finally, all reflection outcomes are addressed and formalized for communication and documentation.

In this work, following the PADRE concept, we iterated through the phases (1) problem definition, (2) planning, (3) developing, (4) evaluating and (5) learning proposed by Haj-Bolouri et al. (2016). During the course of action, we have returned to previous phases several times in order to sharpen the outcomes. Every phase was closed by a reflection and learning step. Overall, we conducted two iterations based on feedback workshops and interviews we collected during the learning phases.

3.2 Data collection and analysis

This section presents the results of our action research study at the insurance company INSUR. We conducted our action research study between January 2021 and December 2021 at three subsidiaries of INSUR. INSUR operates in 30 different countries with more than 25,000 employees. INSUR offers solutions in the life and non-life insurance sectors and the gross premiums written reached more than 11 billion EUR in 2021. The largest market is Austria with three subsidiaries, all of them participating in the study. The company has a centrally organized BPM and runs processes differently in each subsidiary. Harmonization and standardization efforts are one strategic goal of the company. A decision on a process mining vendor is still pending, and the scoping of an implementation is ongoing. The IT governance is mostly centralized, though some subsidiaries have their own IT departments and software applications.

As a primary data source, we used semi-structured interviews to collect information during all five phases. Table 1 lists the interview partners, in which phase they mainly provided information, and when they were interviewed. Some people have been interviewed twice to consider the evolved approach during the iterations and to update their feedback and evaluation. As participatory researchers, we engaged with the involved stakeholders and actively provided input from a scientific point of view. After collecting the data, we transcribed all interviews.

The further research process was a joint effort of the researchers and the on-site experts, enriched by a large body of secondary data. This included process descriptions, process flows, process maps and documentations from collaboration platforms such as Confluence [1]. Confluence is a team workspace to share and exchange knowledge. It is highly integrated with JIRA [2] which is a cloud-based issue and project tracking platform. Additionally, we extracted event-log data from a SAP system associated to a claim business process. Later, the different types of secondary data were categorized and divided into decision classes.

For data analysis, we utilized methods from Grounded Theory (Strauss and Corbin, 2014) according to practise in the IS literature (Seidel and Urquhart, 2016). More specifically, we used the Straussian paradigm as a method for coding in order to describe the phenomenon from the perspective of causal conditions, context, intervening conditions, action/interactional strategies. Afterwards, we formed categories by grouping codes along dimensional characteristics (Strauss and Corbin, 2014). Finally, we abstracted and constructed the final IT artefact from those categories.

During the entire data analysis procedure, a learning mechanism has been implemented (Haj-Bolouri et al., 2016). Thereby, the learned outcomes of the previous activities have been collected via feedback discussions, which then were documented and communicated to all participants.

4. Research process and results

Our five-step phased research process started with the problem definition. We analysed existing documents and conducted interviews with managers of INSUR to specify the current ITDM approach. Starting with collecting this information, we were able to formulate our research problem, followed by the definition of our requirements. In the planning phase, we agreed on two sample processes to analyse the decision-making. The two processes provided the data for the following process mining steps. The discussions about the process mining outcomes led to a redesign of the ITDM approach. After two iterations, the new approach was tested and implemented. The following chapters describe the steps of each research cycle with two iterations as shown in Figure 1.

4.1 Problem definition: decision-making with ITDM

The first phase started with interviews of INSUR management to formulate the problem. We used the outputs of the interviews to gather detailed information about the problems of ITDM and to create an understanding of the goals for a solution.

The Running as-is ITDM Approach At INSUR, ITDM represents a structured way of decision-making. The demand process is well documented and implemented company wide. Demands originate from different ITDM activities. A demand for a change is triggered by internal or external stakeholders who are planning to change existing processes or activities that involve IT in any form (e.g., IT infrastructure, IT applications, IT security). Thereby, IT acts as service provider to ensure that the implementation and maintenance of IT aligns with the business processes in which it is embedded.

ITDM at INSUR consists of multiple steps, involves multiple stakeholders and has a final delivery as output. Every step of the demand process has input/starting conditions, a clarification of participating roles, a list of IT supporting tools, a description and an output/outcome definition. The delivery of an IT demand has different sizes, from small ERP software changes to new components and functions, or new software applications. ITDM requires data of different sources and distinct information to decide how to manage the demand. IT demands can be categorized in legal requirement, strategic requirement or business process improvement activities.

The current ITDM procedure starts with a demand description after a potential new IT demand has been identified (Figure 2). The demand is usually raised by experts or responsible key users. In addition, the requester describes the business case and creates an initial scoring sheet. The scoring sheet helps to identify the business value and indicates an estimation. The next step is the demand verification. Demand, portfolio and IT manager review the demand and release the budget. In some cases, demands require additional assessment of the “Panel for Company Architecture” (PCA). Next, IT developers and analysts provide a detailed effort estimation and a technical concept. After the estimation is completed, the demand manager and manager of the business department order the demand and approve the final budget, which will set the demand ready for implementation. After developing, testing and accepting, the demand is finalized, and expenses are invoiced to the client.

In our example case (Table 2), the business department requested a change in the claims process under comprehensive automobile insurance. Usually partner workshops, which are handling the repair of a damaged vehicle, are created via external interface as an SAP Business Partner. External providers create the corresponding master data by themselves. This demand included the change of the input (creation) of a repair shop, the automatic processing of deductibles and automatic status processing between external service providers.

ITDM Roles & Responsibilities In column 3 of Table 2 we can observe different roles and responsibilities. The handling of an IT demand requires different expertise and decision competence. This is why every process step contains a different set of participants. In addition, the involved roles depend on the size and budget of the requested IT demand. Budgets for demands above a certain threshold require management attention and board member participation. ITDM involves the following roles and responsibilities.

1. C-Level Manager is the highest level of decision-making, responsible for approving changes and budget;

2. Portfolio Manager is responsible for a group of IT portfolio;

3. Demand Manager manages demands, quarterly budget and business requests;

4. IT Manager is responsible for a specific IT system or SAP module;

5. BD Key User, Expert is a user and subject matter expert that creates demand or new requirement for a process change;

6. IT Expert is a developer or business analyst that works on concept and effort estimation;

7. PCA is an enterprise or solution architect;

8. BPM is the process owner, process designer or process manager;

Problem Formulation As PADRE presupposes, the research problem originates out of a particular organizational context (Haj-Bolouri et al., 2016) for which there are currently neither practical nor scientific solutions. In our case, we were presented with a proposal of an insurance company that was facing serious problems with its ITDM. To be concrete, their planned IT resource allocation is often unreliable and caused negative impacts on the as-is business process. They had not enough information about how the business processes operated and interacted with other IT resources. As a consequence, inaccurate and inefficient decision-making results in more change requests, higher implementation costs and less stakeholder satisfaction. As a predetermined requirement by the insurance company, process mining was chosen as the technological approach to be applied. With proceeding in this form, we “conceptually [move] from building a solution for a particular instance, to […] applying that learning to a broader class of problems” (Hevner et al., 2004). Considering the decision-making difficulties faced by the company and the predetermined technological requirement of using process mining, we formulated the following research question:

RQ.

How can process mining be integrated in the practice of IT demand management concerning business process change?

INSUR operates in different countries and intra-company competition often relies on high-level financial performance. This data is usually period-based and incomplete, because of missing information, aggregated reporting data in the form of Process Performance Indicators (PPI) does not reflect specific details.

We know that we have different processes, we know that we need more time than other subsidiaries, I can argue, but I have no evidence. Without concrete facts, I cannot achieve certain optimization activities

(Head of Corporate Insurance).

INSUR management articulated current issues in decision-making around process changes. Decisions to change a process are often based solely on financial data and intra-company competition is based on financial performance. While processes are evaluated with PPI (time-to-market, counted output, quality) or financial Key Performance Indicator (KPI) (cost per unit, total process costs), the company's reporting is based on inflexible and incomplete data. C-Level managers are missing substantial process information for argumentation in context of decision-making.

4.2 Action planning: define the goals

The second phase defined the approach requirements as design principles of our work. In addition, we agreed on the historic demands to analyse, from which we can improve our approach design. The first demand was a process change in a car comprehensive claim (cooperation repair shop handling). The second demand was the digitalization and automation of the breakage of glass claims (coverage check, duplicate checks and payment approvals).

Requirements for Approach Processes can be evaluated by PPI, such as total process runtime cost, counted output or service quality. These numbers build the basis of BPM activities such as standardization, harmonization or optimization. Furthermore, process metrics can be very important for argumentation or justifications of operational actions. At INSUR, C-level managers are sometimes missing substantial process information to discuss strategic actions or operative planning. For example, a claims process in corporate business requires more information than in retail (e.g. coverage data is more complex, mostly written on paper and non-standardized). Process improvement activities are often rejected because of missing understanding and facts about the complexity of the as-is process. INSUR's management has the essential need on factual based information of the process to be improved by ITDM and defined the following requirements to improve decision-making:

R1: The improved ITDM approach must be based on the existing demand process. The ITDM approach is established in different departments of the company and should not be completely redesigned. However, it should be adapted in certain steps to cover specific problems.

R2: The improved ITDM approach must better document and justify the process changes. A demand requires PPI and KPI, descriptions and input from process experts but in many cases the decision-makers are usually unaware of the detailed process. The managers lack on solid process information to argue about process changes. INSUR's strategic goal to harmonize processes aggravates the justification of process changes for business units. Managers need a clear picture of processes to justify their demands and finance the cost of change.

R3: The improved ITDM approach must increase system stability and business reliability. Due to incomplete and outdated process information (e.g., not up-to-date process models) the realization of a demand can have negative side-effects. Unknown dependencies can have a negative impact on the process which can cause interruption in the provided services.

R4: The improved ITDM approach must support acceptance and billing processes. The demand manager solely accepts demands after information from the business department. The acceptance is based on limited data sets as well as test scenarios and therefore do not include the full picture of the process. Additionally, the changed process flow is not monitored after implementation in the production system which prevents an actual and instantaneous examination of the changed processes.

A sample process To inform the design of our approach, we decided upon an implemented INSUR ITDM process, on which we can analyse historic decision-making. As most of our project participants are claims experts, we used two already implemented demands of a claims process. For each iteration we selected one historic demand of a claims process. These demands were analysed from start to finish to draw our conclusions. After consolidation of documents, the interviewees were asked what kind of information is required to improve decision-making. Based on this information, we defined the scope for a process discovery.

4.3 Action taking: design a solution

The design phase of our study starts with the extraction of the event data. Process mining discovery requires an event log to create the process model. Therefore, we designed and implemented an SAP program to extract the data. Table 3 contains an example of our event data.

However, we had to overcome specific data quality issues. SAP Insurance [3] works transactionally, i.e. all activities or steps performed by the user are saved with the same timestamp when the user saves the data. As a consequence, we needed to pre-process the event data and introduce a sequence number to create a logically correct business flow. As preparation for the event log extraction, the business users and data analysts agreed on prioritization of specific tasks. For example, the “IBAN added” event has a higher priority than the “Payment saved”, therefore – although we have the same timestamp – it was possible to create a logically correct process flow.

Furthermore, to remove incorrect data consisting of duplicates and technical logging events, we extracted the full set of event data into an excel sheet. Together with process experts and data analysts, we grouped the process steps and activities by their description and decided which events are important for the process discovery. After the event data was finalized, we used DISCO [4] to create the as-is process visualization and process statistics.

Our example is based on a new demand to integrate an automated sharing agreements process for car/auto insurance. Sharing agreements are agreements between insurance companies for the sharing of car claims payments in the event of a collision or accident. It stipulates that the insurance of the innocent party involved in an accident pays up to 50% of the damage to the liability insurance of the guilty driver. The prerequisite for settlement under the sharing agreement is that the insured person has fully comprehensive or partially comprehensive cover in addition to liability cover.

Due to the high complexity of the E2E claims process, we only show those sections of the process that were actually analysed by the experts evaluating the process change. For visibility reason, we reduced the total number of attributes from 76 to 48 and did not simply reduce the percentage of activities in DISCO, as that would hide important process steps relevant in the TAK process (because of the smaller number of TAK agreements in relation to overall car accident claims). TAK agreements are valid in approximately 20% of all motor/vehicle claims. The goal of the demand was to standardize TAK handling in the claims processing. Before, claim handlers created memos, added notes and documents or assigned manual tasks to identify the TAK agreement in a claim. Therefore, we had to identify all activities that are somehow related to a TAK agreement within the as-is process. With the help of the process discovery, we were able to filter on those processes and identify their predecessors and followers. In addition, we visualized all paths of a claims process that mandatory included these steps. Consequently, we identified all dependencies to internal and external services (like partner client services that show documents or display claim status and payment information).

Table 4 shows a comparison of the claims process before and after a demand realization. Column 1 describes the process step before the demand was realized and the process was changed. Column 2 describes the step after the process change. Both columns refer to figures in the appendix, which show screenshots of the process mining tool. The third column is a reference to the results in Table 5, where we describe each finding in more detail.

With the help of the process discovery in the process mining software, we were able to recognize dependencies to document management services, as well as external partner clients (repair shops and vehicle appraisal services). Based on the process analysis we evaluated how this information helps us during the implementation of the IT demand. Table 5 describes the specific findings we were able to analyse based on the process discovery. The individual items in the table show in what form the analysis results had an influence on the handling of the process changes.

Furthermore, we used the statistics provided by DISCO to analyse the case numbers per year, number of process variants, case duration (total and average), number of events per case (activities) and active cases over time. In addition, we analysed the generated as-is process model to identify interfaces to external applications, unexpected process behaviour, bottlenecks and loops. Finally, we compared these metrics before and after the demand (process improvement) was implemented. This was possible by filtering the end-date in DISCO to before and after the demand was implemented. In this way, we were able to identify the definitive impact of the process change.

4.4 Evaluation: implement and test

Based on the aforementioned observations, we implemented a novel ITDM approach by considering specific process mining activities. After our second research cycle, we added additional steps to the current procedure. Figure 3 gives an overview of such an enriched ITDM approach. During problem description, the first discussion about process mining is planned to start. It can be the first entry point to decide whether process mining will be used during the demand life-cycle. In the next step, when the user story is created and the demand is described, a request for process mining data (i.e. the discovery of the process to be changed by the demand) can be ordered by the demand manager or process owner. During the demand verification, the participants consider it very helpful to retrieve important facts (i.e. case numbers, interfaces, run-times, involved resources) of the process which are based on the process mining discovery actions.

In comparison to the current ITDM approach, we split the “Describe/Identity Problem” into two main steps with four activities. This is due to the finding that a demand (a process change) originates from either internal or external sources. Internal: An employee identifies a problem during work, a running project or optimization activities. External: Regulatory or legal changes (new tax laws, meet new legal requirements) require changes in the business process. In addition, changes can be the result of innovation or strategic actions, such as external consulting activities that result in BPC because of strategic goals.

Furthermore, the findings of the process discovery (and the discovered process model) can support testing and documentation. Test cases and test data can be created, specifically based on the data and sequence that was discovered in process mining. Based on a regular basis, the extraction and mining of process data can support process monitoring as the discovered processes can help to find variations or drifts in the implemented process. Table 6 shows our contribution and describes our proposed changes to build our to-be ITDM approach. The decision points describe the involvement of process mining to acquire additional decision data.

4.5 Reflection and learning

Each phase of the PADRE cycle was closed by a reflection and learning session. While our activities and outcomes of the problem definition and action planning phase received minor feedback, design and evaluation outcomes have been discussed extensively. After the design of the approach, we analysed the output (i.e. the decision-making for a process improvement) based on the following criteria: (1) how the decision was influenced by process mining discovery, (2) whether there was other information outside mining, (3) whether it led to a better decision, (4) what additional information is important and (5) how useful was the outcome for the users. Consequently, the R&L session answered the question to what extend process mining had impact on the decision and how ITDM has to be improved (Table 7).

4.6 Impact evaluation: findings and side-effects

In addition to our findings during the design phase, we confirmed them by getting feedback from our involved ITDM experts. Based on the analysis results in Table 5, we were able to infer individual improvement measures in the demand process (Figure 3). Once the new actions were incorporated into the demand process, the new overall process was validated by stakeholders. We discussed the impact of the implemented process mining steps after we tested our novel approach based on two IT demands. The outcome of our discussion is presented in Table 8. The success on the novel ITDM approach is weighted by the following criteria: (1) is it based on process mining data, (2) did the process discovery lead to other important information, (3) did it lead to a better decision and (4) what are the side-effects of knowing the process mining outcomes (Table 8). The validation answered the question to what extend process mining had impact on the demand process.

As a final step, we test and implement the new ITDM approach at INSUR for a new demand on a process improvement in claims management. The demand runs through the whole ITDM approach from the problem description until the demand finalization. After the demand is implemented and ran for three weeks, a group of experts was interviewed.

5. Discussion

The resulting ITDM approach contributes to the understanding of the role played by process mining in two major ways. First, we extend ITDM research by creating a novel ITDM approach and show its practical relevance (Alonso et al., 2013; Quichiz and Oré, 2017). Second, we contribute to the question how process mining does complement other approaches and technologies (vom Brocke et al., 2021). By combining ITDM and the process mining discovery technique, we show how process mining is used during the realization and implementation of an IT demand. We extend recent research that focused on the role of process mining by additional findings of benefits and practical application (Grisold et al., 2020; Reinkemeyer, 2020).

5.1 ITDM on an operational level for process changes

ITDM integrated into BPC activities require a more process-design-driven view of the process to-be changed. Process mining can support the integration by providing valuable insights of the process and guide the discussion of the different stakeholders. As a consequence, the participants responsible for a process change, IT experts and process experts, jointly assess the process change in various dimensions. We find similarities to Gross et al. (2021), where a business process design space guides the organization about the objectives, participants, information source and usage, as well as infrastructure and automation.

Another aspect of the integration is the coverage of existing BPC challenges mentioned by Javidroozi et al. (2019). The results of the process mining activities helped to clarify, analyse and address existing business process in detail before a change, supported business networking and increased business process collaboration management (Javidroozi et al., 2019, p. 482 Figure 3). Furthermore, from a quality assurance perspective, it improved quality, timeliness and provision of data, helped to understand integrated business processes as an activity network, and highly supported testing and troubleshooting continuously (Javidroozi et al., 2019, p. 482 Figure 3).

Additional steps related to process mining in the demand process, increase the overall ITDM cycle-time and hence require higher initial budgets. At first glance, this seems contradictory to the findings of Alonso et al. (2013) who see a need for a lean and expedited ITDM. As a consequence, we argue that the utilization of process mining is highly dependent on the demand size. Yet, with pre-existing process mining data available and established in the company, this effort will decrease significantly.

Our findings indicate that starting with medium-sized demands, the benefits outweigh the costs, and more efficient decision-making compensates for the higher initial costs and makes project estimation more accurate. Thereby, our results are in line with Alonso et al. (2013) who identify sufficient project estimation connected to budget planning as one main objective to “find out whether the projects have produced the expected benefits through the connection with project investment” (Alonso et al., 2013, p. 905). To take this further, conducting discovery with process mining provides a clearer picture of the process dependencies that clarify the responsibilities for estimation and implementation tasks. In contrast to business intelligence-related approaches, process mining explores details and visualization of the operative process and increases transparency. Alonso et al. (2008, p. 12) explain a similar level of information enrichment for ITDM as “value-oriented solution design”.

Looking at this from a more operational viewpoint, Legner and Löhe (2012) propose an “end-to-end demand management” procedure. Their fourth design principle particularly mentions the “integration with adjacent [business] processes” (Legner and Löhe, 2012, p. 11) in order to improve ITDM. We pick up this idea by leveraging process mining to gain such insights to make it useable for ITDM. Finally, we do see a similar positive impact of process visibility on process improvement and operations like Berner et al. (2016).

5.2 Decision-making accuracy, efficiency and risk-reduction for process changes

The resulting ITDM approach improves decision-making in several ways. The common look on the as-is process model and its key figures such as case numbers per year, number of process variants, case duration (total and average), number of events per case (activities), and active cases over time, reduced information gaps and misunderstandings (van der Aalst, 2008; Grisold et al., 2020). We agree with Badakhshan et al. (2022) in two ways. First, the use of process mining within our approach enables a more flexible and accurate view on the end-to-end process and the PPIs. Furthermore, increased transparency helps to understand the needs of involved stakeholders and contextual knowledge ultimately supports decision-making. Second, we provide a detailed case uncovering how process mining affords sense-making both in terms of descriptive and prescriptive analyses. “While formerly, due to lack of objective data, it was difficult to compare processes […], process mining can be used to objectively assess processes and make decisions grounded in data.” (Badakhshan et al., 2022).

Furthermore, BPC drives systems integration and vice-versa, but decisions need to be made economically (Kettinger et al., 1997). Thereby, we agree with the finding of Jurisch et al. (2014), which IT capabilities impact the performance of BPC. ITDM efficiently allocates resources, which leads to a positive effect on BPC. In addition, we go in line with van der Aalst (2008), when he mentions that bottleneck analysis with process mining improves the design of IT systems and acts “as input for redesign decisions which may be supported using simulation” (van der Aalst, 2008, p. 14).

In general, we found out that the particular process mining-related steps we included into the adapted ITDM approach highly depend on the source of the demand. (1) Internal – reason for a process improvement is business perspective-driven, such as process improvement, or redesign; and (2) external – change becomes necessary due to legal requirements, strategic business adjustments or other external factors. We saw similar findings in an approach of Pfahlsberger et al. (2021) who discuss the realignment of certain IT resources in relation to process mining based on the external or social context in which the business process is embedded.

Moreover, potential risks can be unveiled at a much earlier stage of the demand and trigger intervening action. Fernandez-Llatas (2022) showcase this in a case study using process mining in a cardiology outpatient department. This avoidance of potential risks could also be observed with our improved ITDM approach. In fact, the investigation on the analysed business process can be used as reasoning basis for decision-making in PCA for an architectural context. It can expose previously unknown dependencies and helps to understand architectural requirements. The consideration of technical events, like the display of internal and external services in the original process, can be used for risk evaluation and planning of system down-times. We refer this to the level of operational and tactical decisions proposed by Kaplan and Norton (1996) which are concerned with imminent impacts but also mid-term effects on business processes.

5.3 Limitations

Beyond the general limitations of qualitative research, there are specific limitations to our study. First, our work is based on the cooperation with one company only. In this regard, it would be interesting to extend this study to a multi-case setting in order to validate our findings. Second, the interviews of the sample process focused on employees from one business unit. Therefore, we know about the potential process improvements and impact of changed processes only through the perspective of the claims department. Third, our approach is based on a small number of different demands and the approach was tested and validated to one IT demand exclusively. Fourth, the on-site availability of study participants was limited due to Covid-19 restrictions. All meetings, workshops and interviews had to be held via video or audio conference as a personal engagement was prohibited by the company during the time of research.

For future research, it is desirable to conduct a longitudinal case study on the implemented ITDM approach in order to validate our findings ex ante vs ex-post. Furthermore, it would be interesting to see whether the benefits of using process mining increase with the inclusion of multiple business processes or integrating ones with higher transactional volumes like order-to-cash or purchase-to-pay.

6. Conclusion

Our study proposes a novel ITDM approach that integrates process mining techniques. We thereby demonstrate the applicability of process mining and its implications on decision-making. We enhance an existing ITDM approach to optimize decisions of process improvements. Under specific circumstances, the discovery of processes with the help of process mining supports process experts, demand managers, enterprise architects, or IT managers to gain important process information when planning to implement new IT demands. Therefore, our redesigned ITDM approach experiences a better overall performance and an increased acceptance of the process by the actors involved. Hence, we demonstrate how process mining complements other approaches and technologies and extend current research in the field of the adoption of process mining in organizations.

Figures

Figure 1

Research process – conducted five-step phases with outcomes based on PADRE (Haj-Bolouri et al., 2016)

Figure 2

Steps of the current ITDM procedure at INSUR – steps highlighted in black indicate main steps of an IT demand, whereas white highlighted steps are sub-steps of an IT demand

Figure 3

Redesigned ITDM approach (final research artefact) – Black chevron shapes indicate the main process steps

Table 1

Interview Partners during PADRE phase

ID	Function	Phase	Date
1	C-Level Executive	Problem Definition	January 2021
2	Process Owner Claims	Planning	January 2021
3	IT System Manager	Planning	February 2021
4	Demand Manager	Planning	March 2021
5	Enterprise Architect	Planning	March 2021
6	BPM Process Manager	Designing	March 2021
7	Process Expert Claims	Designing	June 2021
8	IT System Manager (2nd)	Designing	June 2021
9	IT System Manager (3rd)	Evaluating	September 2021
10	Demand Manager (2nd)	Evaluation	September 2021
11	BPM Process Manager (2nd)	Evaluating	September 2021

Source(s): Created by authors

Table 2

Steps of the current ITDM approach undertaken in the process of car insurance claims

Step	Description	Role
1. Identify problem	Starting Condition: Problems are identified on a regular basis in team meetings due to new requirements or improvement activities During this discussion, the actors ask other users about previous experience with these topics and decide to create a short description about the problem and – if required – collect additional information (i.e. process descriptions, feedback from other departments). In our example, new data quality in the product (the deductible agreements as insurance clauses) leads to improvements in the claims process. This issue was discussed with IT architecture, who identified an optimization potential Output: Problem is a potential demand for a process change	Key User, Expert, PCA (architecture), IT Manager
2. Describe demand	Starting Condition: Process improvement potential is identified Business department describes the as-is scenario. The demand description consists of the to-be scenario in form of a user story: In case of an accident claim, deductibles agreed with cooperating repair shops should be granted automatically. The policy system determines the deductible amount based on agreements with the repair shop. During claims handling, this amount has to be deducted from a payment. In an additional step, the demand creator describes and scores the business case Output: Problem is identified as new demand	Key User, Expert
3. Verify demand	Starting Condition: “description completed”, demand ready for validation by demand and portfolio management The content is checked for completeness by the demand manager. Team architecture raised concerns about interfaces to one external provider. The responsible IT manager checked if the initial budget for an estimation is available. Technical and business analysts estimated the demand. During the estimation, a technical and business concept was created and jointly approved by IT and business department. Due to missing information on how the deductible was originally considered, the concept included only a to-be scenario. After the concept and the estimation is accepted, the demand is officially ordered Output: Demand approved, Budget for effort estimation released	Demand Manager, IT manager, PCA (architecture), Portfolio Manager
4. Realize demand	Starting Condition: Demand commissioned, and the tasks are planned in the backlog Description: Implementation of the demand according to the specification and concept, the development team faced problems due to unexpected interface, the specification to the policy agreements were unclear. The technical communication to the external provider was complicated because of a wrong service definition. Due to an incomplete test case description, the tests of the new functionality did not consider a full end-to-end scenario Output: Demand implemented and tested, transported to production	IT Expert, IT Manager
5. Finalize demand	Starting Condition: Demand implemented/accepted Demand is accepted in production system and the new functionality is subject to a previously agreed stabilization period. Due to problems in the development the budget exceeded the estimations by 50%. Although business department accepted the demand in user acceptance test (UAT), there have been problems in production due to missing conceptual work in the process. Dependencies to other demands were not clarified (an open concept from the agreement specifications in the policy system were different to the specified steps in claims) Output: Demand finalized. Software delivery accepted in production	IT Manager, Key User, Expert
6. Invoice demand	Starting Condition: Demand Finalized Demand is closed in the systems, bookings are no longer possible, the expenses are invoiced to the client Output: Billing to customer Demand closed	IT Manager, Portfolio Manager
7. Maintain demand	Starting Condition: Demand Invoiced If agreed in the demand, the new functionality can be subject to regular reporting Output: Reporting on regular basis	Operations, Demand Manager, BPM

Source(s): Created by authors

Table 3

Event log example

Claim	SQ	TS	Activity	Description	User	Appl
2803157265	1	16.03.2020 13:57	Subclaim Update	Workflow created	USE01	SAP
2803157265	2	16.03.2020 13:57	Subclaim Update	Status changed	USE01	SAP
2803157265	1	16.03.2020 13:59	Payment Update	Payee added	USE01	SAP
2803157265	2	16.03.2020 13:59	Payment Update	IBAN added	USE01	SAP
2803157265	3	16.03.2020 13:59	Payment Update	Payment saved	USE01	SAP
2803157265	4	16.03.2020 13:59	Subclaim Update	Workflow Approval cr	USE01	SAP

Source(s): Created by authors

Table 4

Comparison of the process discovery before and after the demand realization

Before demand realization (business process changed)	After demand realization (business process changed)	Finding
The SAP automatically created a workflow (task) to indicate a new document, the task TAK agreement was created manually by the user. In case of forgetting to create the task, it leads to a long process duration Please see appendix table A, Figure A1 for more details	The DMS system was enhanced to identify the type of document, therefore the tasks TAK agreement was created automatically and process duration was improved significantly Please see appendix table A, Figure A2 for more details	(1) New DMS/scan is followed by TAK agreement
After the creation of a workflow (task) TAK agreement, an update flag indicated changes for the external partner systems Please see appendix table A, Figure A3 for more details	The automatic creation of the task leads to an early and reliable update of external providers Please see appendix table A, Figure A4 for more details	(2) Task TAK agreement is followed by Update EPC stat
When the user received the workflow that a TAK agreement was active for a specific claim, the user updated the memo field and the reserve of a claim Please see appendix table A, Figure A5 for more details	The full process can be automated, since the payments and total expenses indication in a document can lead to automatic processing Please see appendix table A, Figure A6 for more details	(3) Manual memo “TAK” is followed by a reserve change
The process expert identified the need of additional involvement of architecture, DMS (document services) and external party providers as there was an interface to these systems Please see appendix table A, Figure A7 for more details	The increased awareness of all teams lead to better decision-making and improved teamwork on changing this process. The early involvement of the responsible teams lead to a better alignment in development, testing and release of the change Please see appendix table A, Figure A8 for more details	(4) New claim DMS/scan is followed by task TAK agreement
In the old process, the identification of a TAK agreement happened after the closure of a subclaim (and the claim was already closed) Please see appendix table A, Figure A9 for more details	The change of the process lead to a more reliable and efficient processing, since the TAK process is identified very early Please see appendix table A, Figure A10 for more details	(5) Subclaim closed is sometimes followed by TAK document

Source(s): Created by authors

Table 5

How our process discovery impacts the demand

Finding	Resource allocation	Impact on demand
(1) New DMS/scan is followed by task TAK agreement	Budget Business	Currently, the claim handler creates a manual task after receiving a task for a new document > potential automation/optimization during demand
(2) Task TAK agreement is followed by Update EPC stat	Budget Development, Architecture/Infrastructure	Early involvement of third party provider required, risk management of demand required
(3) Manual memo “TAK” is followed by a reserve change	Budget Business	Potential automation identified because TAK reduces reserve by 40%
(4) New claim DMS/scan is followed by task TAK agreement	Budget Development	Early involvement of other DevTeam during demand identified, additional budget and time
(5) Subclaim closed is sometimes followed by TAK document	Budget Business	Sometimes the TAK agreement is only identified after the subclaim is already closed > potential process optimization
(6) Existing external links to partner client	Budget Development, Architecture/Infrastructure	Support TestTeam to integrate internal provider for E2E test, demand
(7) Overall process map	Demand Management, Test Team, Release Management	Supports User STory and technical Specification for DevTeam, supports demand acceptance
(8) Memo TAK, task creation, document scan	Budget Development, Budget Business	Acceptance criteria for demand regarding tests and approval, by defining must have functionality

Source(s): Created by authors

Table 6

Changes of the redesigned ITDM approach

Step	Description	Role
1. Identify problem	Our example problem to change the car comprehensive claims handling resulted from a change in the policy/product portfolio. New information in the product led to new possibilities in claims handling	Claim Handler, Key User, PCA (architecture) Expert, External (audit)
2. Describe problem	Decision Point: The stakeholders can use available process data such as models, case numbers or number of variants to support problem definition and identify optimization possibilities If this data is not available, it can be a scoping requirement for the BPM department (which is responsible for process mining)	Claim Handler, Key User, Subject Matter Expert
3. Describe demand	Decision Point: Scoping for process mining data to define the data required for the demand verification and realization In our case, we requested the claims data to be extracted. Relevant information such as important events (list of events that are relevant for this type of claim) and the timeframe, were defined in this step. This creates a request for the BPM department, which is responsible to provide the data from process mining	Key User, Business Analyst, BPM
4. Verify demand	Decision Point: Process mining is used to discover the process and generate PPI such as number of cases, activities and variants. Process mining helped to display the as-is process and design the desired output (i.e. changes in the process). Process manager and key user utilized process mining to analyse how the demand will impact the process. Eventually, IT architecture did see dependencies to other components or to external services	Key User, Business Analyst
5. Realize demand	During development the IT expert was able to see dependencies to the external system, and at which time interfaces exchanged information. The development steps within a sprint are followed by a SIT (system integration test). After a successful SIT, UAT (user acceptance test) can start, and the documentation of the implementation/demand has to be finished. The (process) model created with process mining supports IT and users as this documentation guides testers to create test scenarios	IT, IT System Manager, Operations
6. Finish demand	Decision Point: Verify new process in quality system. After acceptance in a quality assurance system, the demand is finished, and the development/customizing is released to production. Process mining helped to approve the demand, by checking if the developments/changes are correctly implemented in the process. Process Mining data can be used for manual and automatic regression tests	IT, IT System Manager, Operations
7. Invoice demand	Decision Point: Use the process mining results for invoice clarification. The new process model (after the demand is running) was used for successful order confirmation. Invoicing process starts after the demand is accepted and finished	Operations, Demand Manager
8. Maintain demand	Decision Point: Real-time process documentation and monitoring. After the changes are in production and the process is changed, it will be maintained and monitored. Continuous reporting based on process mining would highly improve monitoring activities. Optimizations and improvements will be visible and can be proved and communicated. On-time monitoring of processes would be possible	IT Operations

Source(s): Created by authors

Table 7

Summary of the feedback after the design and evaluation circles

Step	Findings of discovery (quotes of interviews during research circle 1 + 2)	Learnings (interview feedback after two circles)
Describe problem	“Because of the effort for process mining activities, an early involvement makes no sense”	“If process mining data is widely available in the company, we can probably better identify problems and analyse their impact”
Describe demand/User story	“If process mining data is available, it can support the problem description at an early stage. Because of the availability of process maps and a clear picture of process variants, it can definitely support the creation of the user story.” “It is much easier and faster to describe a change if you can see the process and somehow expect the impact of the change” (That statement was made at the second iteration, at a time the process discovery was already available)	“The need for process mining data can drive a process mining project decision.” “It helps to define a process mining project scope” “If the change decision is solely made by the business department and not triggered by our activities, the BPM department gets involved at a very early stage and can support further decision-making”
Verify demand	“The process maps and KPI's really help us to understand the problem and avoid misunderstandings” “We have a much better discussion basis and are all talking about the same now”	“An early understanding of the problem and the requested change can avoid difficulties at a later point of time” “We have a much better picture about the end-to-end process know, and a better feeling about the architectural impact”
Realize demand	“For me as a developer, it was really helpful to get a full picture about the process and the requested change. I was able to estimate the impact and know how and what to (unit) test” “For us in the test team it was great to fully understand what and how to test”	“We definitely had an improved effort estimation and slightly quicker realization time because of what we knew upfront” “Test planning has improved, period.”
Finish demand	“The approval was not faster but easier” “We avoided misunderstandings and I think we created a much better testing scenario”	“We should use process mining to approve changes and validate changes in the future” “I simply had a better ‘feeling’ because I knew what I have approved”
Invoice demand	n.a	“It is not hard to put the results into the approval documents, such I do it with the scoring card already”
Maintain demand	n.a	“It finally helps the BPM department to work closely with IT operations and maintenance”

Source(s): Created by authors

Table 8

Overview of qualitative validation

Circle	Based on ProMi	What do we learn after we used process mining within an IT demand?	Impact on demand/Decision	Side-effects
Process A – change 1	N	Higher overall effort because of detailed description	* no impact (except total effort for demand)	Early involvement of BPM department and process manager
	N	Initial cost for process mining data can be very high	* If the data is not available and not funded by other activities, then process mining for a particular change makes only sense at very big changes	Scoping for process mining projects
	Y	Business analyst, user and developer have the same picture of the problem	* Faster Effort estimation because of better overview and faster problem understanding * Better risk analysis	Avoidance of misunderstandings between user and developer
Process B – change 2	Y	Improved creation of qualitative testcases and test planning	* Test planning and execution improved because of better integrative testing	No impact of effort for testing but high qualitative improvement!
	Y	PCA was able to analyse dependencies on printing and DMS (document management system) services	* Clear responsibilities (internal and external) * Faster effort estimation from third party	Change led to additional tasks for other team, but revealed responsibilities very early

Source(s): Created by authors

Table A1

Appendix for Table 4 Columns before and after the business process changed

Notes

1. https://www.atlassian.com/software/confluence

2. https://www.atlassian.com/software/jira

3. https://www.sap.com/industries/insurance.html

4. https://fluxicon.com/disco/