Subject-Oriented Monitoring of Processes

Abstract

Optimized and implemented processes go live after their final acceptance sign-off. This means that they are executed in the course of ongoing business operations, in the organization and IT environment described in the previous chapters. Experience reveals that process execution here is exposed over time to changes to a variety of influencing factors. These can negatively affect the process performance and thus increasingly decrease value generation, if not addressed properly. An example of such factors is the rapid, nonpredicted increase in parallel occurring instances of customer inquiries in a bidding process. This can lead to an increase in turnaround time for quotations, with the risk that potential customers switch to competitors.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

11.1 To Go

11.2 Nature of Monitoring

Optimized and implemented processes go live after their final acceptance sign-off. This means that they are executed in the course of ongoing business operations, in the organization and IT environment described in the previous chapters. Experience reveals that process execution here is exposed over time to changes to a variety of influencing factors. These can negatively affect the process performance and thus increasingly decrease value generation, if not addressed properly. An example of such factors is the rapid, nonpredicted increase in parallel occurring instances of customer inquiries in a bidding process. This can lead to an increase in turnaround time for quotations, with the risk that potential customers switch to competitors.

A permanent, real-time monitoring of process efficiency in the key dimensions of quality, time, and cost can help to avoid such developments and also help to identify opportunities for improvement (Heß et al. 2005, p. 10). In doing so, usually IT systems with appropriate functionality record actual (as-is) values for suitable key performance indicators, compare them with predetermined target (to-be) values, report deviations outside tolerance limits, and so provide the basis for a cause analysis and subsequent actions. Addressees of the recorded data and exception reports are the work performers as Actors and the process owner as Governor. They interpret the results and take appropriate action.

Recognize the beginnings of deviation from predetermined target behavior!—The monitoring task is to track possible deviations in a timely, causality-driven way with respect to resources and to immediately reveal these to stakeholders and operation managers.

Process Monitoring is also termed Process Performance Measurement (PPM) or Operational Process Control. It is logically the last bundle of activities of the open S-BPM life cycle. Since a performance value recorded in a running operation environment is usually interpreted arbitrarily by its receiver, monitoring is linked closely to the activity bundle of analysis. It is an essential part of the Process Performance Management (PPM), which is the planning, measurement, evaluation, and control of business processes (Schmelzer and Sesselmann 2010, p. 230). The PPM is in turn part of a company-wide Corporate Performance Management (CPM), which refers to the overall corporate performance (Heß et al. 2005, p. 11).

Schmelzer and Sesselmann distinguish between ongoing and periodic monitoring, which usually complement each other (Schmelzer and Sesselmann 2010, pp. 281 f). Figure 11.1 provides an overview of the essential characteristics of the two variants.

Fig. 11.1

Types of monitoring in business process management

Periodic monitoring is about capturing the maturity of both the business processes, as well as the overall business process management approach in the company, at longer intervals, e.g., quarterly or semiannually. Maturity models can serve to support in this case. Well-known examples are the Business Process Maturity Model (BPMM), which was developed by the Object Management Group, and the process assessment models for business processes (PAB) and for enterprises (PAE), which are based on the Model of the European Foundation for Quality Management (EFQM) (cf. Hogrebe and Nüttgens 2009; OMG 2008; Schmelzer and Sesselmann 2010, pp. 288 ff.).

These models include five maturity levels to assess the processes and the BPM concept, respectively. They help an organization with the evolutionary increase in process maturity by providing guidance for the prioritization of opportunities for optimization (cf. OMG 2008, p. 11). We do not hereby regard the maturity models only as a means of operational process control, like Schmelzer and Sesselmann but also as instruments of strategic process controlling which feedback control information for revising the S-BPM strategy (see Sect. 3.6.3.2) and represent a kind of link between operational and strategic process controlling.

Due to its affinity to execution, S-BPM supports all of the various variants of monitoring equally. Behavior data can be generated continuously and periodically from the flow of messages and execution of function.

Ongoing monitoring records evaluation data during process execution for each instance, calculates actual values for defined metrics (see Sect. 11.4), and prepares these for reporting to relevant stakeholders. In addition, process structure parameters, such as the available work capacity at a certain point in time, can be a matter of ongoing monitoring. For instance, in case the number of subject carriers drops under a certain threshold due to illness, managers could respond quickly to maintain the stability of critical factors, such as throughput time. The evaluation of the measured data can occur continuously, periodically at short intervals (daily and weekly), or ad hoc, depending on targets and purpose.

The following sections focus on ongoing monitoring and its main subtasks of measurement and analysis of data in the form of key performance indicators for process execution and design, and the associated reporting including preparation, delivery, and distribution of findings to relevant stakeholders (cf. Wagner et al. 2007, p. 186). Figure 11.2 shows this process of monitoring, including the essential information required for this purpose, which should be carefully and systematically defined in the form of key performance indicators (cf. Kütz 2009, pp. 47 ff.; Marx Goméz and Junker 2009, p. 131).

Fig. 11.2

Procedure of process monitoring and the associated information from the key performance indicators

We will now deal first with the S-BPM stakeholders in monitoring and then, following the structure of the figure above, with the measurement of key performance indicators, and finally, with evaluation and reporting.

11.3 S-BPM Stakeholders in Monitoring

11.3.1 Governors

The Governor in monitoring is often the process owner. His role is characterized mainly by the assessment and analysis of performance indicators with target values provided for the overall process, which he has usually assisted in defining in other bundles of activities (e.g., analysis). Examples of such performance indicators are the work load of the subject carrier, the cycle and throughput times of instances, the number of instances per time unit and their temporal distribution (e.g., on weekdays), as well as the average cost per instance. The process owner is the addressee of the actual (as-is) values, which are usually automatically measured and prepared in the form of reports for key performance indicators. He analyzes and interprets them and initiates steps to eliminate problems, if required.

11.3.2 Actors

The Actors as subject carriers observe the process and identify during operation both relevant quantitative and qualitative aspects of the execution process. For example, each subject carrier notes when continuously too many or too few instances per time unit are due for his attention, or the response time of a shared IT system is not satisfactory. The first case could be an indication of deficiencies in the organization-specific implementation (insufficient work capacity), so that the Actor informs the Facilitator who then verifies this. In case Actors are not able to evaluate values for key performance indicators or identify root causes by themselves, they can contact the Facilitator, or via the Facilitator available experts. The same is true, when they identify their own deficiencies, e.g., missing know-how or IT expertise. In this case, the Facilitator can, for example, organize appropriate trainings by Experts. If Actors recognize execution deficiencies or communication problems with other stakeholders involved in the process, they can collaboratively identify causes, and in coordination with the responsible Governor, either eliminate these themselves or initiate their elimination via the Facilitator. The Actor is primarily the addressee for reporting of performance indicator values related to the (partial) process he is involved in, i.e., his behavior and interactions. Typical examples are the processing times of his steps and the latency time in his inbox.

11.3.3 Experts

Expert roles in the monitoring process could be taken by controllers and external consultants in assessing measured indicators, comparing them to benchmarks, providing explanations for poor results, and suggesting means for improving them. Also, these activities reach over into the activity bundle “analysis”.

11.3.4 Facilitators

A Facilitator helps the Actors (as shown) in the assessment of perceived problems and in finding solutions. This role could be taken, e.g., by the process owner, the service desk (also as external service provider), or a quality management representative (QMR).

11.4 Measurement of Process Indicators (Key Performance Indicators)

11.4.1 Overview

Process indicators as measuring objects are, like any business metrics, scale values expressing quantifiable facts in numbers, and thus making them comparable. They need to be relevant for achieving process goals (reference to strategy), economically determinable, comprehensible for all involved, and influenceable in terms of controlling. For the application of key performance indicators, often their operationalization function (manageability of goals), target function (setting targets), control function (target/actual value comparison including variance analysis), impulse function (detection of abnormalities), and simplification control function (simplification of complex control processes) are highlighted. Indicators can only meet their target function if they have meaningful target value sets. In particular, for any new processes or those with a low level of maturity, it is often difficult to determine realistic target values for process indicators in the course of goal setting. It may be helpful to use one’s own experience with other, potentially comparable transactions, estimates, and benchmarks of other organizations.

Figure 11.3 shows a differentiation of key performance indicators according to execution and structure, as well as a further distinction between business and, in terms of IT support for business processes, technical indicators.

Fig. 11.3

Types of process indicators

11.4.2 Process Execution Metrics

Process execution metrics as performance parameters (Key Performance Indicators) target instances of processes. Their values are acquired dynamically, e.g., when processing a limited number of test instances in the course of validation or a large number of them during simulation in the context of optimization (see Chaps. 7 and 8). The most important application area, however, is monitoring. Hereby, actual values are recorded which are obtained when processing real process instances, i.e., concrete business cases. The term Key Performance Indicator (KPI) is assigned to a measure of particular importance for the organization, as it represents a critical success factor. In many cases, several performance parameters are subsumed as a KPI, e.g., when summarizing latency, transportation, and processing time as throughput time. Common key performance indicators are the satisfaction of external or internal customers, the quality of the process results, reliability of meeting deadlines for delivery of results, the process time (throughput time and cycle time), and the process costs (cf. Schmelzer and Sesselmann 2010, pp. 239 ff.). The partial interdependence of indicators requires their joint consideration. In addition to absolute key measures, such as totals (e.g., total cost of a process), situational measurements (e.g., average processing time), and measures of dispersion (e.g., standard deviation of processing time), often relative measures, also known as ratios, are used (e.g., number of bad credit offers per 100 offers).

A proper business implementation of S-BPM monitoring requires the alignment of process key measures to the behavior parameters of subjects. This provides the basis for developing Key Performance Indicators.

Key measures can accommodate fixed values or probabilities, which have been defined as plan or target values in the course of analysis and modeling. For example, employees as Actors can run their own tests to determine a realistic value for the completion of a business trip application, and define, in coordination with the process owner as Governor, 5 min as maximum completion time (see Fig. 11.4). Analogously, a maximum limit for preparation of a message for sending a mail can be defined, as a conventional approach in the example, i.e., the insertion of the business trip request into an interoffice mail envelope and its deposit in the main mailbox in the office. An example of the labeling of a complete partial path of a behavioral description of a subject with time information is also shown in the figure. Thus, the path from application to the state where the business trip can be started, takes 2 days. In this example, it might also be useful to measure real-time operation, namely how often the branch of rejecting business trip requests is executed in general, and how often with respect to each subject carrier in particular. A high or progressively increasing proportion of the total number might suggest a lack of coordination between employees and supervisors, or some potential for conflict in the individual organizational units.

Fig. 11.4

Selected performance indicators for the behavior of the subject “employee” in the business trip application process

An example for the specification of target values by way of a probability distribution would be the requirement that the completion time should not exceed 5 min in 80 % of all cases or the limitation of the average processing time of the whole path to 2 days.

Process execution metrics are continuously measured. This means the values are collected along the process in each run of an instance at defined positions so-called measurement points (cf. Kronz et al. 2005, p. 35). This can be done manually or automatically via sensors, counting and timing functions, etc. in workflow engines, application systems, and system software. The resulting process execution data is continuously recorded (logging).

Typical examples of entries in log files are process numbers, activity keys, time stamps for the beginning and end of activities, etc. The sum of log records is also known as an audit trail from which, among other things, can be reconstructed, who executed what steps and when of a business process instance during runtime. Using appropriate algorithms, also values can be calculated, such as the duration and cost for each activity in process steps, for process branches, or for entire processes.

Using the subject-oriented methodology, the main process execution metrics can be applied to the subject behavior and measured in terms of function, send, and receive states, as well as in their transitions. This allows the assessment of both the subject behavior and the subject interactions and provides ideas for their optimization. Figure 11.5 shows an example of how different times can be measured by recording of state transitions. We distinguish here between the time-relevant elements of processing, waiting, and latency. The individual elements can be aggregated to cycle and lead times.

Fig. 11.5

Measurement of processing and waiting time in the subject-oriented approach

S-BPM enables localizing work activities and responsibilities due to its stakeholder orientation and subject behavior models. Together with the organization-specific implementation, an entire set of data describing a certain situation is available for evaluation.

The processing time is the period of time in which a subject is in a function state processing a task. The total processing time in a process can thus be represented by the sum of all time periods subjects are in function states. In the figure, it is obvious that the processing time of the subject “manager” begins with the transition from the receive state “receive business trip request” to the state “check business trip request”. It ends when one of the states “accept” or “reject” has been reached.

Waiting time is defined as the period of time which elapses between the moment in which a subject enters a receive state, and the time at which the expected message from the sender is actually received. The total waiting time of a process is consequently calculated by summing up the waiting times for all subjects. In the example, the waiting time of the subject “employee” starts as soon as it enters the state “receive Bt-request from manager”. It ends, once the response is received from the manager (“from manager: acceptance” or “from manager: rejection”).

In reality, operations cannot be processed immediately in a processing station. This results in latency time, which in subject orientation refers to the time that elapses after the arrival of a message in the input pool of the receiving subject until its processing by the subject.

A selection of business process execution metrics that are relevant for S-BPM is shown in Fig. 11.6. They usually refer to time, frequency, cost, and quality and are generally defined in the course of analysis or modeling by Actors, together with the Process Owner (Governor) and process controllers (Experts). When monitoring, the Actors measure the specified parameters on the fly in real instances, either manually or with the help of appropriate software functions. Process participants and controllers can measure time- and cost-related parameters also on test instances simulated during optimization. Sensitivity analyses performed in the course of simulation require a lot of process or methods experience to achieve improvements by parameter changes without creating local suboptima (e.g., reduction in cycle time due to additional personnel, but without overcompensating increase in costs). Here, Actors can bring in internal or external Experts having the necessary experience and qualifications.

Fig. 11.6

Selected business process execution metrics related to S-BPM

Since work performers sometimes need to adapt their behavior in processes to changing requirements, but this knowledge usually is lost, in S-BPM they are able to update their subject behavior by themselves while following agreed rules of governance in the respective models, and thus, ensure consistency between process documentation and execution.

Technical process execution parameters refer to the IT infrastructure, within which the IT support of processes is implemented. Examples are CPU utilization (per server), the number of concurrent users, main memory usage, and database response times. By capturing these parameters, IT architects and system specialists can, e.g., determine the system load and identify opportunities for virtualization. They define such execution parameters in the course of IT implementation and specify target values, e.g., in terms of Service Level Agreements, in cooperation with the person functionally responsible for the process (typically the process owner) and based on the expected numbers (e.g., number of parallel instances and system users).

System and service programs measure actual values with real instances in the course of operation with respect to the actual performance and use of IT assets and make these accessible for evaluation by process and IT managers. In addition, users themselves recognize flaws in the system performance and articulate them, e.g., to a service desk as a Facilitator.

11.4.3 Process Structure Key Indicators

For process management, in addition to the performance parameters, the process structure key indicators are relevant as they identify potential that describes mainly the human and technical infrastructure for the execution of process instances, and thus affect the performance parameters. They are static and refer to a process or its model. Examples are the number of simultaneously available subject carriers for a subject, the number of processes in which a person is subject carrier, or the computing power of a supporting IT system in accordance with the Service Level Agreement. Process and IT executives define such indicators usually in the course of organizational and IT implementation and provide their target values. In monitoring, they compare these with the actual values obtained from the current operation. The actual available number of Actors during operation could vary from the number specified in the course of organization-specific implementation, e.g., due to illness and fluctuation. The maturity level of a process can also be regarded as a structural key indicator. As an actual value it captures the current state of a process as an overall entity, and as a target value it sets the intended (to-be) state.

The values of process structure key indicators are measured at fixed time intervals (e.g., daily calculation of the actual available work capacity in the travel office) or ad hoc on the basis of certain value constellations of process performance metrics (e.g., determining the actual work capacity when instances have to wait longer at a processing site than previously planned). The measurement is carried out when optimizing the model or when running test instances, and also during monitoring at runtime, independent of specific instances, namely on the process level. Figure 11.7 exemplifies a selection of business process structure metrics.

Fig. 11.7

Selected business process structure key indicators

Technical process structure key indicators are defined by IT specialists in the course of IT implementation. For the existing or envisioned IT infrastructure, they specify the performance potential as gross values. Examples are the number of available application servers, their main memory capacity, and their computing power per time unit. These provide insights into the processing potential. Its consumption is measured by the above-mentioned technical process execution metrics.

11.5 Evaluation

We distinguish between different types of evaluation. We will now introduce these in the context of S-BPM.

11.5.1 Periodic and Ad hoc Evaluation

On the basis of permanently recorded and stored execution data, retrospective, periodic log file evaluations of completed process instances (store-and-analyze), i.e., every week, every month, or every quarter, are common. Hereby, Actors and/or process owners use predefined conventional database queries and calculate on the basis of statistical functions. According to the given calculation rules, where appropriate, previously determined key indicators are composed from raw data (e.g., summation of times for individual process steps to achieve the overall runtime of a process).

In this way, in addition to the usual quality-, time-, and cost-related indicators, additional information can be gained, such as the number of instances initiated per time unit and their temporal distribution, the average duration of an instance in a processing station, or the average data throughput per instance. The results obtained serve as a basis for regular reports. From these reports, conclusions can be drawn for modeling, for the organization-specific implementation, and for the IT-related implementation (e.g., on the need for additional homogeneous workstations or higher bandwidth for data transmission).

In addition to the periodically, usually automatically generated and preprogrammed analyses, individual evaluations are carried out in practice, using interactive ad hoc queries to meet specific, singular objectives. This enables subject carriers as Actors to search themselves for causes of perceived events (e.g., increased waiting time).

A special form of evaluation is represented by process mining. Hereby, the data collected in the log files of the workflow engine are analyzed together with comparable information, e.g., delivered by ERP systems. The initial aim is to generate process models out of the information accumulated in the course of process execution of multiple instances and to create transparency of process structures in this way. This is helpful for the initial creation of actual (as-is) models for the documentation and verification of lived processes. It also facilitates the analysis of discrepancies between lived processes and existing, previously documented flow schemata (target models), which may provide clues for improvement.

Such discrepancies often occur, when Actors need to adapt their behavior in the process on short term autonomously to changing demands on the process. S-BPM enables them to update their modified subject behavior themselves in the model, in accordance with the agreed governance arrangements (e.g., consultation with, and approval by, the process owner as Governor), and thus to ensure consistency between process documentation and execution.

In addition to models derived from objective facts, process mining also allows conclusions about the actual distributions of process variants (e.g., what percent of all instances have passed paths A, B, and C, respectively). Another objective is the generation of information on process performance and success by comprehensive inclusion of additional information such as the business object (e.g., customer orders), the process result (e.g., customer order completed on the requested delivery date), the subject carriers (such as acting people and systems), etc. (cf. Grob et al. 2008, pp. 269 ff.).

Process mining can be used as a diagnostic tool in monitoring and analysis, while using methods thereof, such as analytical sequence and graph-oriented procedures, Markov chains, and genetic algorithms (Grob et al. 2008, p. 270).

Process Mining delivers useful insights with respect to distributions of process variants and provides a fundamental basis for organizational agility.

11.5.2 Continuous Business Activity Monitoring

The concept of Business Activity Monitoring (BAM) denotes the continuous, business-oriented monitoring and evaluation of business process instances in real time (cf. Heinz and Greiner 2009; Hauser 2007; Reibnegger 2008). The view taken here on BAM does not only include business-related key indicators as targets for continuous monitoring activities but also technical parameters such as database response times. Business Activity Monitoring uses the continuously acquired data, analogous to periodic and ad hoc reporting. However, it usually leads to an immediate stream-oriented analysis (stream-and-analyze) of these data, using methods of complex event processing (CEP) (cf. Heinz et al. 2009, p. 84).

Complex event processing denotes computational methods, techniques, and tools, which allow the processing of events at the time of their occurrence, i.e., in a continuous and timely manner (Eckert et al. 2009, pp. 163 ff.). It especially deals with the recognition and processing of event patterns (observed facts), which only become visible by combining several individual events (simple events) in so-called complex events (Luckham et al. 2008, pp. 5 ff.), defines a simple event in this context as “anything that happens, or is contemplated as happening” and a complex event as “an event that is an abstraction of other events called its members”. It is important to conclude the likelihood of the occurrence of the complex event as soon as possible after the occurrence of the associated simple events, in order to still initiate proactive measures for preventing or limiting the consequences. Detailed information on complex event processing, in addition to the sources already mentioned, can be found in Luckham (2002), Levitt (2009), Chandy et al. (2010), and Etzion et al. (2010).

An illustrative example of the conceptual framework of CEP and its effect can be described as part of the business trip application process. The travel office tries to use the lowest available rates for train and flight tickets whenever possible. These are early booking rates, usually only available up to a certain date, e.g., seven days prior to departure. The threat of losing the early bird discount can be understood as a complex event. It is defined by the simple events “processing status: open”, “current latency time of the application in a processing station”, and “expected remaining processing time”. A CEP application is capable of calculating on the basis of these data, by means of continuous evaluation, consolidation, and correlation of generated values of simple events, for each instance the complex event or the likelihood of its occurrence, respectively.

Moreover, the system can recognize, e.g., that for a specific business trip request, delays have occurred (e.g., due to lack of approval), and its processing by the travel office will be too late to claim the early bird discount. One consequence then could be that the IT system ranks the business trip application with highest priority, thus putting it on top of the work list of subject carriers of the travel office, or that it at least induces such a proposal, leaving the decision to the subject carriers. CEP supports S-BPM by allowing subject carriers to recognize complex relationships, assess them independently, and become active in order to avoid negative consequences for the process result.

In order to recognize previously known patterns of events, e.g., as in the case of the business trip application, event query languages are suitable (e.g., composition operators, data stream query languages, or production rules), while previously unknown patterns in data streams are tackled for identification with methods of machine learning and data mining (Eckert et al. 2009, pp. 163 f.).

The aim of Business Activity Monitoring is to automatically identify in the course of operation short-term problems and missed targets in the execution of process instances and to respond in accordance with the predefined escalation procedure. Such problems can occur both on the technical level of process support caused by IT, as well as on the basis of economic performance indicators, and may be interdependent.

In the first case, a BAM solution within operational system control will monitor and analyze mainly simple events related to the functioning and utilization of information and communication technology resources (cf. Becker et al. 2009, pp. 174 ff.). Examples of responses to detected problems could be automatic load balancing across multiple application servers, or exception messages to system administrators, e.g., when the specified maximum response time has been exceeded for database queries.

Events in the form of variations in economic performance indicators can trigger as reactions alarms to process owners. BAM could provide the prognosis for an instance of a customer order after the first half of the processing steps that the total processing time will exceed the target value (complex event) due to already accumulated delays. It informs the people in charge, so that they can take any necessary measures to accelerate the process or inform the customer about the delay.

Systems for Business Activity Monitoring, especially with CEP functionality, can be understood as an enabler of S-BPM. They relieve work performers (Actors) and process owners (Governors) of regular and continuous monitoring tasks and create spaces, e.g., for subject carriers to reflect on optimizing their behavior and interactions with partners in the process.

Business Activity Monitoring comprises technical parameters in addition to economic key indicators for monitoring.

11.6 Reporting

Reporting covers the preparation, delivery, and distribution of evaluation results in the form of reports. It therefore follows the same pattern over time as evaluation. Figure 11.8 gives an overview of possible report types and their characteristics.

Fig. 11.8

Types of reports

Ongoing and Exception Report s

Based on the continuous evaluation of the Business Activity Monitoring, results are continuously processed and documented. The focus is on monitoring business operations, which means constant reporting on running instances in very short time intervals (minutes, seconds, etc.).

For the presentation here, so-called dashboards and cockpits are used. The metaphors for appropriate IT solutions underline the intuitive and quickly understandable display of a few, but very important parameters for control (Key Performance Indicators). Instruments such as speedometers permanently visualize values like the number of instances currently in progress. The ending of the more or less short time interval triggers refreshing of the quasi-analog display. Digital accessories such as warning lights or traffic lights can signal the presence of special situations, such as exceeding the specified maximum processing time of an instance for a subject carrier. Here, the trigger is the exceptional case.

In any case, the cockpit/dashboard system independently informs the user with a push of information, without the necessity of his proactive involvement. These instruments are often integrated into process portals. Process owners and managers in their role of Governors can take a quick look and easily grasp information like in a control station. They also can oversee the current process steps and projected trends and compare them with historical data when needed. Such portals offer Actors involved in the process personalized work environments for executing their process-related activities. In a portal area, each employee finds a list of pending, to-be-processed instances of the processes in which he is involved (“my work”). Another list shows him the range of processes he is allowed to trigger by generating an instance (“my processes”). Examples of these could be the business trip request, the request for leave, etc.

Predefined Standard Reports

The periodic evaluations provide the basis for issuing predefined standard reports, e.g., weekly, monthly, or quarterly reports. According to the previously identified information needs of the recipients, usually printer optimized versions of presentations including business graphics (bar charts, pie charts, etc.), tables, and text blocks are generated and distributed in paper form or as electronic documents by e-mail, or published on the intranet. In addition to these traditional presentation methods, for periodic reporting cockpit/dashboard systems are increasingly used. The recipient of information automatically receives the reports themselves at a defined reporting date, or the information that they are available via the process portal or elsewhere (information push).

Individually Required Reports

The evaluation using individual ad hoc queries needs to meet a very specific interest in knowledge. It usually turns into an equally individual report. It may be sufficient to display query results on the screen or to issue them informally in paper form. Evaluation and report correspond to the request and activity of a user, so that in this case we speak of an information pull.

Reporting overall, but individually required reports in particular, represent an enabler of S-BPM. Only when subject carriers have appropriate functionalities and privileges, are they able to obtain process- and instance-related information, which can be applied in a self-organized way for optimal process design and processing. For detailed information on reporting, see, e.g., Mertens et al. (2002, pp. 69 ff.) and Gluchowski et al. (2008, pp. 205 ff.).

Reporting requires identifying a specific target group, and possibly compressing data for measurement, e.g., in dashboards, in order to support individual subject carrier groups according to their needs.

11.7 Process Key Indicators Related to Bundles of Activities

The acquisition and compilation of data concerning running processes to support decision making when deviations from a predefined target behavior occur is the focus of monitoring. In this section, we have identified possible variants of data collection, introduced different forms of decision making, and established their relevance for S-BPM and/or illustrated it by examples.

Figure 11.9 gives a summarizing overview of the application of the discussed types of process performance indicators in the S-BPM activity bundles. It shows where they are usually defined, provided with target values, and used for simulations and analyses on the level of process, model, and instances.

Fig. 11.9

Process performance indicators along the S-BPM bundles of activities

Feedback always leads to the activity bundle of analysis, regardless of who is analyzing (Actor, process owner as Governor, etc.). The analysis result determines the next activity. Thus, an Actor with poor performance of the IT system supporting his process steps will contact the IT service desk as Facilitator, which then itself carries out a root cause analysis or initiates it. Its result in turn leads to the activity bundle of IT implementation, in case load balancing between servers is required as a solution.

If the process owner receives an ad hoc message from monitoring that the waiting times in a subject increase significantly, he can increase on short-term notice, in consultation with line managers, the number of deployed subject carriers. This measure is part of the activity bundle organization-specific implementation.