1 Introduction

Process orientation is a key driver of corporate success. Organizations of all sizes and from all industries use process-aware information systems (PAIS) like modeling tools and workflow management systems to control and execute their processes (e.g., planning and controlling of production, processing of incoming customer requests) efficiently. However, most PAIS that are available on the market based on the assumption that processes have only a few variants and that these variants can be planned prior to execution. However, this assumption is no longer valid because of increasing economic complexity, which is further intensified by digitalization.

Small and medium-sized enterprises (SMEs) in particular are affected by the risks associated with changes in their business models toward a digital business model and by the risks associated with an increasingly complex environment. As SMEs tend to have lower budgets, limited resources, and a significantly lower capability to take over risks compared to those of large corporations, SMEs may lose the ability to react and adapt to environmental influences. Because of the lack of appropriate IT support, the planning and control of complex business processes that feature both planned and unplanned events in an increasingly complex environment are often carried out manually, without considering internally or externally available key figures or key performance indicators (e.g., order-specific, profit-specific, or product-specific delivery date). Such manual processes are time-consuming and prone to error, causing SMEs to tie up scarce resources that are then available for neither value-creating tasks nor innovation.

The ability to handle planned and unplanned events like delayed shipments, machine breakdowns, and changes in customer requirements and orders in a continuously changing environment can be defined as agility or, more precisely, operational agility (Conboy & Fitzgerald, 2004; Hinsen, Jöhnk, & Urbach, 2019; Jöhnk, Roeglinger, Thimmel, & Urbach, 2017). Planned events can be predicted prior to execution and captured via process models, while unplanned events are not modeled but can be handled by reprioritizing or re-sequencing tasks. However, agile processes would enable organizations to respond to customers or suppliers individually and faster, which would increase customer satisfaction and competitive advantage. Nevertheless, most available PAIS do not support the design and enactment of agile processes, do not meet the high demands of agile processes, and neglect the impact of organizational key figures for process management. Specifically, practical concepts and implementations that go beyond research prototypes are lacking.

Against this backdrop, the development of a PAIS that addresses these challenges is sorely needed. To realize such a system, we structure the PAIS architecture along the common three-layer architecture, extended by a novel component for handling agile processes. This component prioritizes process instances that are relevant to an organization’s internal and external key figures (e.g., the profit from an order or a product’s delivery date) and to plan for the processing of instances or activities that vary in importance. As a result, the PAIS architecture comprises three layers: data storage (i.e., data related to process model, runtime data, and historical data), application logic (i.e., a modeling component and an execution and monitoring component with a workflow engine, a worklist, and a prioritization component), and user interface (i.e., for modeling agile processes and worklist processing).

To realize the PAIS for the execution and monitoring of agile processes, an interdisciplinary consortium consisting of the University of Bayreuth’s Chair for Databases and Information Systems, the Professorship for Information Systems and Business Process Management, and four SMEs—three application partners and one implementation partner—collaborated in a joint project funded by the Bavarian Ministry of Economic Affairs, Regional Development and Energy. The project’s goal was to design, demonstrate, and evaluate an agile PAIS in the form of a software prototype that supports the modeling and key-figure-based monitoring and execution of agile processes. Demonstration and evaluation took place by testing the prototype at the operational level at the SMEs’ sites. The proposed PAIS helps make these organizations’ processes adaptable, increases their ability to react to unexpected customer requests, and increases their competitiveness. The case serves as a rich example of how the various components of a successful BPM approach interlink (vom Brocke, Mendling, & Rosemann, 2021), specifically in regard to the IT capabilities role to enable agile practices and the organization's ability to deal with change.

In the following, we describe the case of N-DECT, a producing SME that provided one of the most complex scenarios in our project consortium. This case focuses primarily on the monitoring, execution, and improvement of business processes (Dumas, La Rosa, Mendling, & Reijers, 2018; Rosemann & Vom Brocke, 2010). We examine N-DECT’s core processes, which are highly variable and can be improved with the addition of expertise (vom Brocke, Zelt, & Schmiedel, 2015).

2 Situation Faced

N-DECT develops and produces customer-specific solutions for materials testing with a particular focus on eddy current and ultrasonic testing. With the company’s investigation procedures, materials and components can be tested for purity, accuracy, and robustness. For this purpose, testing machines are integrated into customer-specific machine constructions. Thus, N-DECT’s processes handle up to 20 orders in the form of projects, resulting in agile processes of varying complexity that result from variations in customer requirements. For most orders, a new testing machine has to be developed that corresponds to the customer’s requirements. It is not possible to exactly predict the duration of single activities in the process, and as the risk of changes in the customer’s requirements is high, N-DECT must often reschedule its processes. N-DECT’s core process can be divided into three main steps (Fig. 1): processing a customer’s request, setting up the project, and carrying out the customer’s order.

Fig. 1
figure 1

Overview of N-DECT’s manufacturing process

Full size image

Existing methods and tools for process execution and monitoring do not cover such agile development, construction, and assembly processes satisfactorily. The decision process to select which customer orders are most important for N-DECT is carried out manually, which requires considerable effort and can be subjectively biased. To process customer requests and related orders more efficiently, a software prototype of an agile PAIS was used at N-DECT as an execution and monitoring component. In this system, customer orders are instances of an agile process that must be prioritized depending on N-DECT’s strategic key figures, which are either order-related (e.g., delivery date and delivery volume, turnover, profit, replacement time of goods for assembly) or customer-related (e.g., importance of the customer, history with the customer). Based on the prioritization of customer orders, an initial feasibility check, concerning which customer orders can be postponed and which cannot, is visualized on a dashboard. Furthermore, a worklist for processing orders is created to ensure integrated monitoring and control of customer orders across all departments. Based on this prioritized worklist, employees select the most important activities. To consider the real conditions at N-DECT, the process steps and the related effort (e.g., working hours) are compared with the available capacities (e.g., in the design and production process). The available capacities can be taken, for example, from the project hours booking system. In addition, unplanned events like human error and machine failures that require customer orders to be rescheduled must be considered. The solution must also be integrated with existing (e.g., MS Project) and future (e.g., ERP system, CRM system) information systems, as they are important sources for key figures.

The additional requirements focus primarily on refining the simulation of various project constellations because the prioritization of projects based on key figures already provides reliable results. For example, N-DECT needed to describe the employee as a central resource more precisely, including whether employees are assigned to the project according to their capabilities, whether they can perform particular tasks (e.g., construction of mechanical or electronic components), and whether several employees work simultaneously on a process step. Additional data sources, such as personnel, project, and customer data, had to be considered so feasibility checks are carried out not only with regard to available employees but also with regard to further process parameters, such as cost.

3 Action Taken

In developing the agile PAIS, we started with a planning and structuring process that revealed that the research project should be carried out along five development phases: (1) Requirements engineering, (2) designing, (3) development, (4) evaluation of the prototype, and (5) specification of the system.

Phases 1 and 2 focused on the requirements analysis and the technical specification and software design of the agile PAIS. In Phases 3 and 4, the results of the preceding phases were first implemented as an IT artifact in the form of three software prototypes—one per application partner. Then the prototypes were evaluated at the application partners’ sites to ensure that changes that were relevant to the application partners had been incorporated. After the evaluation of the prototypes and the incorporation of changes in Phase 4, a detailed system specification was developed in Phase 5. Figure 2 shows the five phases of the research project.

Fig. 2
figure 2

Phases of the project

Full size image

Phase 1: Requirements Engineering

Phase 1 focused on the identification and cataloging of requirements to produce a requirements catalog. To cover all important requirements, a broad range of sources was used to identify requirements: (1) application partners’ use cases, (2) analysis of software solutions the application partners had used, (3) a literature review with a focus on execution and monitoring of business processes, key figure-based process monitoring, and agile processes, and (4) an analysis of publicly accessible and scientific PAIS implementing agile approaches. Both sources (1) and (2) are described in the Situation faced section. Steps (3) and (4) are discussed in more detail in the following.

Searches in scientific databases like EBSCOhost, Google Scholar, and ScienceDirect, along with contributions from practitioners and other Internet sources were carried out continuously during the research project. In particular, the review of the relevant literature served as a starting point for the requirements catalog (e.g., optimization of process instances, determination of process instances including risks, prediction of the execution of process instances, and prediction of the process result) (Di Francescomarino, Ghidini, Maggi, & Milani, 2018). The results of the literature review showed that requirements for agile PAIS are widely distributed in the literature and that there is no holistic approach that meets all requirements. In particular, the literature review revealed that the prioritization of process instances (i.e., activities) based on organization-specific key figures is all but missing. In addition, existing work usually addresses small application scenarios or does not use extensive real-world data. As a result, one of the goals of the research project was to combine the extant approaches to develop a more holistic system.

Here the research project came into play, as the process management software has to enable organizations to prioritize their processes on the basis of organization-specific key figures and to compose the various approaches from the literature to provide a holistic approach that can deal with a large amount of real-world data. However, the available literature provides only part of the requirements, so the requirements the literature provided were supplemented by an analysis of publicly accessible and scientific process-management systems that use agile approaches. Reflecting these parameters in one system is the key challenge of this project.

The Department of Databases and Information Systems at the University of Bayreuth developed the Process Navigator, a declarative PAIS that can be used to execute declarative process models. The Process Navigator evaluates whether a process’s activities violate the rules defined in the process model, so only valid activities are provided to the user during the process execution. However, the Process Navigator does not prioritize process instances based on key figures, which is an essential differentiation of our research project. Furthermore, the Process Navigator covers little of the subareas derived from the literature (e.g., optimization of process instances, determination of process instances, including risks).

Camunda BPM is another publicly available workflow management system that makes it possible to define and execute business processes, although it uses different modeling notations (e.g., BPMN 2.0, CMMN, DMN). Camunda BPM is relevant to the research project, as it provides a comprehensive IT architecture, the Camunda stack, a three-layer architecture that is similar to the architecture of our agile PAIS. In addition, the system can be extended using self-developed plug-ins like our prioritization component. Camunda BPM also provides both imperative (i.e., BPMN 2.0) and declarative (i.e., CMMN, DMN) modeling notations.

In addition to Process Navigator and Camuda BPM, PAIS like ADONIS, Axon Ivy, Bizagi, KiSSFLOW, Signavio, ARIS, and ProcessMaker are also based on the process modeling language BPMN 2.0.

The identified requirements were systematized in a multi-perspective catalog, which was used in Phase 2 as a basis for the conception and in Phase 4 for evaluation of the software prototype. In the following, the requirements catalog and its underlying structure are described in more detail.

A useful framework for classifying requirements is the Work System Theory (Alter, 2013). Alter (2013) describes a work system as one in which participants like employees, machines, and application systems act together in performing processes by using information, technologies, and other resources to create products or services for internal or external customers. The work system is influenced by the environment (e.g., laws, technology trends, the organization’s culture), the infrastructure (e.g., technologies, available information), and stakeholders’ strategies (e.g., strategies of organizations or departments) (Fig. 3) (Alter, 2013).

Fig. 3
figure 3

Work system theory (Alter, 2013)

Full size image

Since Work System Theory describes an organization’s internal and external drivers of an organization at various levels, this classification can also be applied to classifying the requirements of a PAIS. To classify the requirements we gathered, the research, application, and development partners used an iterative process to assign the requirements to the dimensions derived from the Work System Theory. However, we found that the dimensions “customer,” “products and services,” and “technologies” deviated from Alter’s (2013) work, so they were not considered. The reasons for this choice are that the “customer” is assigned to the environment (i.e., external dimension), as the customer influences the organization’s processes primarily through external specifications. The dimension “products and services” is less relevant for the research project, as the focus lies on the SME’s processes. Therefore, requirements with a relation to “products and services” are subsumed under other dimensions (e.g., delivery of products within a certain time as a restriction from the customer as part of the environment). Furthermore, the dimension “technology” was removed, as the project does not focus on technologies (i.e., tools for operating processes) other than our developed PAIS. Instead of the technology dimension, we added the new dimension “application systems” with the goal of capturing requirements that result from the user’s interaction with the PAIS, an aspect that was missing from the requirements catalog.

We gathered a total of 30 requirements and assigned them to the dimensions of environment, strategy, processes and activities, process participants, application systems, information, and infrastructure. Table 1 shows an excerpt of the catalog, focusing on key figures and the simulation of process instances.

Table 1 Excerpt of the requirements catalog
Full size table

Phase 2: Designing the Prototype

Based on the requirements catalog developed in Phase 1, Phase 2 focused on both the technical concept and the agile PAIS’s software design. In on-site meetings, application, development, and research partners discussed the processes and information systems related to the application partners’ use cases to achieve a common understanding. In these use cases, we considered only the core processes that had a significant need for flexibility. The actual design took place afterward in the context of workshops with application and development partners and guided by the research partners. Here, the key challenge was to develop a PAIS architecture that copes with all the requirements of the project partners.

Figure 4 illustrates the structure of the PAIS for the use case of N-DECT. As N-DECT does not use information or process management systems that provide an appropriate architecture, the use case was realized using Camunda BPM.

Fig. 4
figure 4

Technical concept and software design—N-DECT

Full size image

Data Storage Layer

The data management in the use case of N-DECT was challenging since the data for key figures (e.g., order-related and customer-related) are stored mainly in Microsoft Office applications like Excel and MS Project. Therefore, the data was extracted from N-DECT’s Office applications and transposed into a form that can the PAIS could process. The import functionality was especially useful for the initial filling of the PAIS. After extraction, the prepared data was buffered for further processing and prioritization. The data extracted was stored as execution data during and after the prioritization step. Data related to the process flow also had to be considered, as the process model data was used in defining the process flow in Camunda BPM. Thus, certain activities (e.g., construction of a component) and related information (e.g., information on components) were assigned to the right employees (e.g., construction and assembly) in the right order.

Application Logic Layer

The modeling component and the execution and control component of Camunda BPM were used in the application layer. The execution and control component comprised a workflow engine and a worklist as an integrated part of Camunda BPM, which was extended by a self-programmed component for the prioritization of processes based on key figures. The prioritization component stored the prioritized key figures and matched them with the characteristic values of the key figure from N-DECT’s information systems. Therefore, management must periodically evaluate the prioritization of the key figures with regard to their topicality and update the prioritization if necessary.

The prioritization component works on the basis of multi-criteria decision-making approaches, which enable the evaluation and prioritization of alternatives (e.g., number of customer orders to be processed) based on such criteria as order-related key figures. A well-known multi-criteria decision-making approach is the Analytic Hierarchy Process (AHP). The AHP evaluates several alternatives using pair-wise comparisons. This procedure is carried out for all decision criteria, resulting in a sequence of all alternatives (e.g., sequence of customer orders to be processed depending on their importance) (Saaty, 1990).

To use the AHP, N-DECT first uses AHP to weight key figures as they relate to their customer orders, resulting in a list of prioritized key figures that are then stored as reference in the prioritization component. Then the Workflow Engine assigns the corresponding key figure characteristic value to each customer order, which originates from the Office applications of the N-DECT. For example, if the key figure characteristics of two customer orders are equal except for the values of the sales volume, then the customer order with the higher sales volume is prioritized. As a result, the Workflow Engine creates a list of prioritized customer orders whose individual tasks (i.e., activities) are provided to the employees across all departments (e.g., construction, assembly) via the Camunda Tasklist.

The modeling component provided by Camunda BPM via the Camunda Modeler is also considered in the application layer. By defining the process model in the modeling component, the process flow and its rules are defined, so the process model ensures that certain activities and related information are assigned to the right employees.

User Interface Layer

The user interface for N-DECT deviates from the generic three-layer architecture. In addition to the worklist component realized by the Camunda Tasklist (i.e., employees can accept, process, and confirm the execution of activities), a dashboard for the management has been developed. The purpose of the dashboard is to visualize and carry out an initial feasibility check (i.e., which customer orders are really necessary) on the one hand and to track the progress of customer orders on the other. Furthermore, the weighting of the relevant key figures can be adjusted here. The Camunda Modeler is used for modeling N-DECT’s business processes. In addition to the modeling of the process flow, activities with a high degree of agility can be defined (i.e., activity in which a large number of alternatives have to be prioritized).

Phase 3: Developing the Prototype

In Phase 3, the developed technical concept and the software design along the three-layer architecture were implemented in the form of a software prototype. The implementation was used as a feasibility study to evaluate whether these manifold requirements could be implemented within a single PAIS. The functionality of software available on the market was examined regarding its suitability for the implementation of our agile PAIS. Camunda BPM and its architecture in particular served as an ideal starting point, as they had only to be extended by a prioritization component. Based on this existing architecture, the individual components of the technical concept and the software design were prioritized and implemented. The software prototypes were realized based on the use cases of the three application partners involved in the project. Furthermore, the interfaces to other information systems (e.g., Office applications, ERP, QM system) defined in Phase 2 were realized as far as was reasonable. An iterative development of the software prototype in the form of an agile development process had the advantage of the continuous involvement of the application partners, whom we asked for feedback after each iteration. This development process also enabled an iterative evaluation of the prototype and the identification and elimination of technical risks in early iterations.

Phase 4: Evaluating the Prototype

In Phase 4 the software prototypes implemented at the application partners’ sites were evaluated with a focus on the prototype’s functional correctness, practicability, and integration with other information systems, as well as whether it delivers valid results despite a high number of decision parameters (i.e., key figures). In particular, we examined whether the execution and control component delivered valid results based on the application partners’ real-world data.

The evaluation was carried out at the partners’ sites in tests that lasted several weeks. The evaluation was accompanied by semi-structured interviews based on a questionnaire. In the case of N-DECT, the prototype was evaluated by using real-world data. With the help of a sensitivity analysis, it was possible to determine whether the AHP’s calculations remained stable even after the input parameters changed. We found that adjusting the weighting of the key figures improved the results. Furthermore, the prototype began to be used in the project managers’ weekly meetings to validate the results.

In another step, the requirements catalog from Phase 1, which served as an evaluation template, was compared with the application partners’ software prototypes. The requirements’ coverage was assessed with Harvey balls, round ideograms that can be completely, partially, or not filled. The aim is to indicate whether a requirement is completely fulfilled, partially fulfilled, or not fulfilled. An excerpt of the evaluation based on the requirements catalog is shown in Table 2.

Table 2 Excerpt of the evaluation based on the requirements catalog
Full size table

Phase 5: Specifying the System

The goal of Phase 5 was to define a detailed concept for the agile PAIS’s system. In addition to collecting additional functional requirements, the prerequisite for the development of a system is to collect nonfunctional requirements, which are implemented in the follow-up to the project. To implement a specification across every use case, additional functional and nonfunctional requirements were identified in Phases 4 and 5 and classified in addition to the requirements catalog for functional requirements.

The literature already provides a good overview of nonfunctional requirements that should be considered in the context of software development. These requirements relate to dimensions like the system’s performance and usability or the validity of its results (Robertson & Robertson, 2013). These and other dimensions form the framework for the nonfunctional requirements, which were discussed with the application and development partners in interviews. The result of the interviews along the three use cases were 25 nonfunctional requirements.

4 Results Achieved

The goal of the research project was to develop a PAIS that supports the execution and monitoring of agile business processes based on company-specific key figures. Demonstration and evaluation took place at three SMEs using a software prototype at the operational level. The main finding of our project enables companies to prioritize process instances objectively and automatically based on company-specific key figures. During the execution of our project, we did not find a similar approach either on the market in the form of an available product, or in the literature in the form of a (research-) prototype. The agile PAIS we developed helps to make organizations’ processes adaptable, increases their ability to react to unexpected customer requests, and increases their competitiveness. In the case of N-DECT, we estimate that the software prototype can significantly decrease the time required to select the most important projects and allocate the available resources.

Generic Three-Layer Architecture

To realize a PAIS for executing and monitoring agile processes, we developed a three-layer architecture in line with common systems, extended by an innovative component for key-figure-based process prioritization (Fig. 5). A major result of our project is that the requirements with respect to the application partners’ agility can be addressed by one generalized PAIS architecture. As a result, this PAIS architecture comprises three layers: data storage, application logic, and user interface.

Fig. 5
figure 5

Generic three-layer architecture

Full size image

The data storage layer comprises a database for process models (declarative, imperative, or hybrid) and a database for execution-related data like currently running and historical instances. The application logic comprises a modeling component and an execution and monitoring component. The modeling component enables the specification of agile processes in the form of process models, as well as key figures, relationships among key figures, preferences of the individuals involved in the process, and relationships between key figures and the process model. The execution and monitoring component comprises a workflow engine, a key-figure-based prioritization component, and a worklist. The component for key-figure-based prioritization, as an entirely new approach compared to other PAIS, has the task of prioritizing all process instances based on company-specific key figures. After prioritizing, the workflow engine enables the generation of valid process instances based on the defined process flow and the rules contained in the process model.

Relevant process instances and their activities are assigned to a user via a worklist. The user interface has a modeling component (i.e., modeling of processes with different modeling notations such as hybrid, imperative, or declarative) and a component for processing the worklist (i.e., individual activities based on the user’s role in the organization). Based on evaluation of its generic and modular architecture in various organizational contexts (e.g., manufacturing and service processes), the PAIS and its components can be applied to other contexts and information system landscapes. For example, some organizations may be interested only in the prioritization component, as they have information systems already that provide the necessary infrastructure.

Key Figure-Based Prioritization

The project demonstrates that it is possible to identify sets of criteria for process prioritization in a highly agile and heterogeneous application domain. We developed an innovative prioritization component based on multi-criteria decision-making with the goal of objective and automated prioritization of strategically relevant and agile processes. Multi-criteria decision approaches enable the prioritization of alternatives based on various criteria. We used the AHP to evaluate several alternatives (e.g., number of customer orders to be processed) with regard to various decision criteria (e.g., key figures like sales related to a customer order, the importance of the customer) by means of pair-wise comparisons (Saaty, 1990). As an important result, we showed that our prioritization component can handle a huge amount of external (e.g., customer-, supplier-, or law-related) and internal (e.g., the organization’s strategic goals and restrictions) key figures and related data. For example, one of the application partners gathered 55 key figures for prioritizing technicians that process customer orders. Our result shows that companies have only to determine the weighting of their key figures.

Then the PAIS calculated process instances from a pool of possible process instances using data from a variety of sources, including Office applications, ERP, and QM systems. As a result, the prioritization and selection of important activities based on key figures helps organizations to make the prioritization more structured, transparent, objective, and efficient based on, for example, increasing customer satisfaction or making decisions easier for employees to trace. For example, in the use case of N-DECT, we used the PAIS to prioritize customer orders with the goal of determining which customer orders are important and can be managed under restrictions like employee and machine capacity and time (e.g., delivery date). Thus, the PAIS with its prioritization component uses data from nearly all sources to give recommendations.

In the future, we expect that the PAIS can significantly decrease the time required for selecting important projects and allocating the available resources. This in turn leads to better communication with customers, since N-DECT now can determine more valid delivery dates based on well-prioritized processes and the optimal allocation of its resources.

5 Lessons Learned

To cope with the increasingly complex environment surrounding SMEs and the impact on these organizations’ business processes, the project team developed, implemented, and evaluated software prototypes for an agile PAIS at three SMEs, one of them N-DECT. The agile PAIS was based on a three-layer software architecture and extended by an innovative key figure-based prioritization component for monitoring and executing agile processes. During the project, the project team gained first-hand experience that has important implications for practice and research.

Learning 1: There Are Different Kinds of Agility

One main finding was that there are different kinds of agility, depending on the SME’s use case. A common feature across all of our application partners’ use cases is that process agility can always be traced back to a certain activity, a decision point for the prioritization of process instances. A decision must be made based on a large number of key figures, which are used to prioritize and select relevant process instances. Examples are the prioritization of incoming customer orders, the selection of a technician to handle a customer order, and the selection of articles with critical manufacturing defects to determine which should be processed first.

The application partners’ use cases had substantial differences. In one partner’s use case, the agility step focused exclusively on the selection of an alternative based on a high number of key figures. The subject of the use case was the selection of a technician for processing customer orders based on key figures like the distance to the customer or the customer’s importance. Approximately 55 key figures were gathered for the prioritization of technicians. However, the selection of the technician is not followed by a complex process. While the technician must carry out certain activities to process the customer order, the activities for solving the customer problem are always the same (e.g., organization of materials). In contrast, the use cases of N-DECT and those of a third application partner not only focus on agility within an individual activity, but the selection and prioritization of alternatives always affects subsequent processes. Based on the selection and prioritization, the organizations know which process steps or activities must be processed next (e.g., in the case of N-DECT an organization-wide worklist is created). Furthermore, both agility types can be combined since there can be several decision points in the process. For example, the procurement of materials can be a decision point, as the selection and prioritization of a supplier can be based on a large number of key figures. Finally, depending on their complexity, the processes can be modeled with an imperative, declarative, or hybrid process modeling language. Processes with few execution alternatives can still be modeled with an imperative language.

Learning 2: Prioritization Can Be Realized Through Key Figures

The results of the research project enabled the application partners to prioritize activities and the associated process instances based on internal and external key figures in a new way. Because of the AHP’s functionality, the number of key figures and organization uses can be almost arbitrary. Since one of the application partners gathered approximately 55 key figures, the company decided to define categories (i.e., super-categories) for the key figures (e.g., technician, logistics, and customer). In accordance with the AHP, the categories were initially prioritized against each other on the first hierarchy level. In the hierarchical approach are key figures that correspond to each super-category. These are also prioritized against each other on a second hierarchy level. Multiplying the two levels results in a weighting for each key figure. In addition to defining thematic categories, the application partner also classified key figures according to their importance. With this alternative, there is no thematic classification of the super-categories (the first hierarchy level), but the super-categories differ based on their importance. Within the super-categories (the second hierarchy level) are thematically mixed key figures, which are weighted against each other. As a result, our approach can handle a large number of strategically important key figures in different ways.

Learning 3: Methodological Support Is Needed

The findings from the use cases show that the adoption of an agile PAIS in organizations has many aspects, ranging from the identification of decision points and the associated type of agility in the process to the selection and weighting of relevant key figures to the linking of both findings with operational processes and information systems. To make this procedure manageable for organizations, a method, e.g., based on the situational method engineering approach, should be developed in the future (Braun, Wortmann, Hafner, & Winter, 2005; Denner, Püschel, & Röglinger, 2018; Vanwersch et al., 2016). Methods of this kind consist of various substeps and aim to support organizations in establishing a PAIS for agile business processes. This would allow organizations to act independently from external partners and to be able to design their business processes more efficiently on their own.