Building a Process Performance Model for Business ... - Springer Link

Building a Process Performance Model for Business Activity Monitoring Claire Costello and Owen Molloy Department of Information Technology, National University of Ireland, Galway {c.costello | owen.molloy}@nuigalway.ie

Abstract A formal business process model serves as a common understanding of how business tasks are carried out to achieve end goals. The business process life cycle is managed using Business Process Management tools and methodologies. Business Activity Monitoring provides (near) real-time visibility into process execution notifying relevant personnel of process exceptions. Business process modelling captures business and execution semantics, but lacks any foundation for process analysis. This chapter will outline a model for process performance management for use in the monitoring phase of the process life cycle and how this model is leveraged within the iWISE architecture. iWISE provides a single view of business processes spanning disparate systems and departments.

1 Introduction and Motivations Traditionally, reporting and Business Intelligence systems rely on the details of workflow logs and separate, standalone modules to support process reporting. Mendling and Neumann (2005) provide a comparison of current process modelling languages with respect to common modelling aspects. WfMC’s XML Process Description Language (XPDL) emerges as the only language of fifteen candidate languages that supports the gathering of statistical data useful for simulation analysis of business processes. There is a need to integrate the development and definition of a process with associated past and expected performance measures. This chapter presents a process model that combines event and other process performance information to allow (near) real-time process monitoring and alert generation. The remainder of this study is organized as follows. Sect. 2 describes the background for this research and provides a context for Business Process Management (BPM) and Business Activity Monitoring (BAM). Process modelling and definition languages are also summarized along with a review of some related process monitoring research. Section 4 and Section 5 present the model used as part of this work, whilst Sect. 6 presents the iWISE architecture which uses this model.

C. Barry et al. (eds.), Information Systems Development: Challenges in Practice, Theory, and Education, Vol.1, doi: 10.1007/978-0-387-68772-8_19, © Springer Science+Business Media, LLC 2009

237

238

Claire Costello and Owen Molloy

Fig. 1. Typical phases of the process life cycle

2 Background Business Process Management can be defined as ‘supporting business processes using methods, techniques and software to design, enact, control and analyse operational processes involving humans, organizations, applications, documents and other sources of information’ (van der Aalst et al., 2003). A BPM system (BPMS) is an integrated software platform that allows for full management of the process life cycle. Managing process performance is paramount to business effectiveness. Melchert et al. (2004) view Process Performance Management (PPM) as a method for ‘collecting and reconciling all operational data related to a certain business process’ to identify areas for process improvement. Neely (2004) defines a performance measure as a metric used to quantify the efficiency and/or effectiveness of an action. The terms ‘metric’ and ‘key performance indicator’ (KPI) are also used when discussing process performance.

2.1 Business Process Life Cycle Management A business process has many phases and constitutes what is widely accepted as the process life cycle (zur Muehlen and Rosemann, 2004; van der Aalst et al., 2003). The life cycle is depicted in Fig. 1 as a closed loop of activities. A process model is captured during the define phase. Once modelled, a process model is transformed into an executable model ready for deployment on process execution architectures. Once deployed, a process is ready to be executed. As a process instance is executing, a monitoring module will track its execution against predefined metrics and generate exceptions if necessary. The analysis phase may use complex statistical techniques to analyse process execution data and metrics to identify any unwanted trends in the process. Using this information, improvements can be made which lead back to the define phase where the cycle begins once more. This closed loop for process management is similar to the Define, Manage, Analyse, Improve and Control (DMAIC) model of the Six Sigma approach to process improvement (Smith, 1993).

Building a Process Performance Model for Business Activity Monitoring

239

2.2 Process Modelling and Definition Languages The current set of standards for process management complement the process life cycle depicted in Fig. 1 Process modelling languages (PMLs) specify a notation and include the Unified Modelling Language (UML), Business Process Modelling Notation (BPMN) and Business Process Definition Metamodel (BPDM). Process execution or definition languages (PELs/PDLs) are specifications which contain semantics understood by process execution engines. Prominent process execution languages include Business Process Execution Language (BPEL), Business Process Modelling Language (BPML) and the XML Process Definition Language. The Event-driven Process Chain (EPC) modelling notation contains symbols for functions, events and control flow points. An EPC model does not have a corresponding machine representation. Rather than separate the process modelling and monitoring phases using different underlying models, this research builds a process model inclusive of fields for metric calculations, in particular, cycle time performance measures. Further enhancements will include the specification of business parameters defined at the process definition phase. The use of a single model will also enable portability of process definitions between various software modules regardless of what phase in the life cycle they apply to.

2.3 Business Activity Monitoring Business activity monitoring (BAM) is a term coined by The Gartner Group. BAM seeks to ‘provide real-time access to critical business performance indicators to improve the speed and effectiveness of business operations. Unlike traditional real-time monitoring, BAM draws its information from multiple application systems and other internal and external (inter-enterprise) sources, enabling a broader and richer view of business activities’ (McCoy, 2002). The key term in this definition is real time. BI approaches take a historical perspective providing information retrospective to the time when important events may have occurred. In contrast, BAM is event-driven and provides quick-time visibility by capturing events from operational IT infrastructure. Decision latency is the length of time between the point when an important event occurs during operations processing and when a decision should be made to correct any anomalous behaviour. To decrease decision latency and therefore increase responsiveness to changing conditions, organizations need BAM software that will provide real-time visibility into their key operations. A BAM system must be able to detect enterprise events, integrate event and contextual information on-the-fly and provide intuitive interfaces for rules and metrics (Nesamoney, 2004).

240


3 Related Research Thomas et al. (2005) describe a loosely coupled architecture overlaid upon a business process expressed in a PEL such as BPEL. The architecture is agent-based and uses the Web Ontology Language (OWL) for describing performance criteria for business processes and individual activities, but does not show how to model the metric itself or how the parameters of a metric are mapped from operational business data. A Web service-based intelligent Decision Support System called the ‘Solution Manager Service’ is described in McGregor et al. (2006). The contribution here focuses on the ability to monitor Web service executions which is important given that many process modelling and definition languages are based on Web services. Haller and Oren (2006) describe an ‘intermediate ontology’ that will act as a common mapping mechanism between the various internal and external process formats used by business systems. However, the measurement aspect of a process is omitted by this ontology and other workflow and process modelling and definition languages (Mendling and Neumann, 2005; Thomas et al., 2005). McGregor (2002) suggests an amendment to the WfMC reference model that incorporates business performance monitoring information for use with the Balanced Scorecard (BSC) approach to business performance management. Although the works mentioned here outline various frameworks for process performance monitoring and management, they do not detail a process model that explicitly contains the elements for aiding process monitoring activities in (near) real time. In addition, since a process model is captured at the define phase (see Fig. 1), then a user should also be able to express important business parameter thresholds or control limits such as target cycle time or expected utilization level. The proposition of this research is that performance metrics and relevant metric thresholds should be incorporated into the process model.

4 Modelling Process Performance Information The process model developed uses XML as its internal representation. The major elements of the model are discussed in this section. The section also details an ontology representation of the concepts required to capture process performance information.

4.1 Model At a diagram level, a model contains processes. The XML Schema for a model is shown in Fig. 2a. Important information relating to a model includes a unique modelID, name and description. An additional boolean attribute, called root, denotes a model that is the root of a model hierarchy. This attribute is necessary for efficient retrieval and reconstruction of multi-level models during both the


241

process capture and monitoring stages. Links between processes are expressed using transition elements. This research does not concern itself with controlling process executions, but instead aims to model and analyse as-is processes which may execute across many different systems. For this reason, complex control structures such as those described in van der Aalst (2003) are not represented here.

(a)

(b) Fig. 2. Model XML Schema (a) and Process XML Schema (b)

4.2 Process A process represents a business activity. The XML Schema for a process is shown in Fig. 2b. Along with general attributes such as a unique processID, name and

242


description, a process is also associated with multiple event definitions. A process must contain at least a start and end event which help to identify the total processing time for a process. Each event is defined by an EventType element which is described in more detail in Sect. 4.3. A process owner must also be specified. A process owner has typical attributes such as name, email address and mobile number. A process may be defined by another level of detail. This is captured using a separate model (associated by subModelID) and is considered a level deeper in the model hierarchy. There is a one-to-one relationship between a process and a model to represent a sub-model of a process. Some elements relate to cycle time statistics for a process. Time granularity is expressed using CycleTimeUnits, whilst TargetCycleTime is a constant for the expected processing time of a task. Both these elements must be specified when the process is defined and are inputs to runtime metric calculation modules. The remaining cycle time elements are calculated at runtime and represent an aggregate view of process execution over time. Valuable information relating to the current performance of a process is captured and preserved by these elements. Elements Capacity and EfficiencyTimeUnit must be specified at process design time and are required for calculating process utilization and productivity statistics as a process is executing. These elements described here are not included as part of any current PDL specification.

4.3 Event A process containing event definitions represents an abstract view of system activities. All events are defined according to the EventType XML Schema illustrated in Fig. 3a. Similar to the model and process elements, an event type element also contains general fields for eventID, name and description. A process can be in various states such as queued, started or finished. The model supports an event classification scheme that includes six event types to model process execution: queue, start, interrupt, resume, cancel and end. Each event definition is linked to a process definition using the appropriate element in Fig. 3b. Events have significance; they happen for a reason. Therefore, an XMLSchema element is provided to describe the expected format of business information relevant in the context of an event. This information can also be referred to as the business object, and its XML Schema structure is supplied during event definition. It is important to note that there is no restriction on the business content encapsulated as part of an event definition; if information can be observed as part of an event that occurs in the IT infrastructure, then it may also be defined as part of an event making it available during process analysis. In this way, business data can be linked to particular process instances through event definitions. Events are related to each other through the process they are defined with (referred to as event relativity). Therefore, an event correlation technique is required such that all events related to each other are grouped together for process analysis. This is achieved using the XMLPathExpression element in Fig. 3a which specifies an XPath value from the XML Schema supplied with the event definition. At run-


243

time, this XPath value is evaluated, based on the XML document packaged as part of the enterprise event. This value must be capable of uniquely identifying event instances for a given process definition. The same value must be present across all event definitions for each process defined within a particular model. For example, for an Order Fulfilment process model, an Order Number could be used to match start and end events for each process within the model.

(b) (a) Fig. 3. EventType XML Schema (a) and runtime Event XML Schema (b)

Given the structure of an event definition in Fig. 3a, an event at runtime follows the structure of Fig. 3b. The eventInstanceID is assigned by the source system or listener software. The Timestamp element is the time when an event occurred as recorded by the source system. The EventTypeID relates the event to its appropriate EventType definition. The XMLPayload element is an XML document containing the business information defined by the XML Schema supplied during event definition. The CorrelationID is the value of the XMLPathExpression specified at process design time. The recursive nature of models and processes allows a model hierarchy to be constructed. Events defined for one process must be reused at the sub-model level. In this way, a process and its associated event definitions can be seen as an aggregation of all processes and events defined at the sub-model level. Using this balancing approach, metrics for high-level processes can be derived using lower-level process and event definitions. The model developed here links events, processes and business information to provide a comprehensive process description that includes metric thresholds and measurements. With the exception of XPDL which provides a limited set of elements for simulation activities, current process modelling standards do not provide any fields for performance metrics or measurement definitions; this is the contribution of this work.

244


5 Defining Rules for Activity Monitoring A business rule engine (BRE) is a software component that will execute business rules against a set of facts from a given scenario. A BRE consists of a knowledge base (or rules base), a working memory of facts and an inference engine.

Fig. 4. Defining concepts for a process metric ontology

5.1 An Ontology for Performance Management Lera et al. (2006) state that it is ‘impossible to make a complete ontology that embraces all existing metrics’ and that the scope of the ontology will depend on the domain of interest. The model discussed earlier has a corresponding ontology representation. This ontology was developed using OWL (W3C, 2004). A straightforward mapping of the major components of the event-based model presented in the previous sections leads to the ontology in Fig. 4. This will serve as a basis for writing rules to test the current state of a process with respect to its performance thresholds.

5.2 SWRL for Process Exceptions SWRL (Horrocks et al., 2004), a W3C member submission, is a Semantic Web Rule Language combining OWL (W3C, 2004) and RuleML (RuleML, 2000). SWRL facilitates rule authoring using ontology concepts as part of rule predicates. In addition to OWL axioms, a knowledge base can now include Horn-like rules written using a logical implication between an antecedent (body) and consequent (head). Since SWRL is based on the RuleML, it inherits the RuleML rule structure.


245

Using the knowledge concepts discussed previously, the SWRL rule specification is used to compose IF-THEN rules to specify when exceptions arise in processes. For example, a rule might be constructed to test the value of a metric for process utilization against a pre-defined lower control limit (UtilizationLCL element in Fig. 2b). The rule given later raises an exception where a process performance metric has dropped below an acceptable lower limit. The rule is an IFTHEN rule which is true only when all predicates in the IF portion are true. Each predicate is joined using logical AND, also known as conjunction. A variable is denoted using the ‘?’ symbol, for example, ?x and ?y are variables and are given sample values here. Rule definition (abstract syntax): Process(?x)

Sample Rule (with values):

∧

hasBusinessObject(?x, ?b)

∧

hasPerformanceMetric(?x, ?y)

hasMetricValue(?y, ?a)

∧

∧

hasLowerControlLimit(?y, ?z)

∧

IF there is a process ?x, e.g., ‘analyse sample’ and A process ?x ‘analyse sample’ has an associated business object ?b, e.g. with value ‘specimen.345’, and A process ?x ‘analyse sample’ has a performance metric ?y, e.g., ‘utilization’ and A performance metric ?y ‘utilization’ has a particular value ?a, e.g., ‘85’ and A performance metric ?y ‘utilization’ has a pre-defined lower limit value ?z, e.g., ‘92’ and

swrlb:lessThan(?a, ?z)

The actual metric value ?a of ‘85’ is less than the pre-defined lower limit value ?z of ‘92’

→

THEN process ?x ‘analyse sample’ with business object ?b ‘specimen.345’ is in an exception state.

hasException(?x, ?b)

From Fig. 4, the OWL classes BusinessObject, Process, Metric and Excepare used in the SWRL rule definition given here. Through definition of OWL properties, a process ?x has a business object ?b and performance metric ?y. In the sample rule, it may not be fully necessary to track the business object that has given rise to the exception, but for the sake of (near) real-time processing, current business data may be necessary for alerting purposes. The rule given here also uses the SWRL built-in lessThan. The SWRL specification includes a set of builtin predicates (SWRLB), named the ‘SWRL built-ins’, which includes predicates for comparisons, mathematical operations and string handling methods to name a few. tion

246


6 iWISE Architecture The iWISE software facilitates management of the business process life cycle (Costello et al., 2006). Once a process is captured and deployed, raw event streams are correlated with relevant processes to provide monitoring software with appropriate metrics. iWISE is a common event infrastructure that uses the eventbased process model described in Sect. 4. The iWISE software addresses each of the phases outlined in Fig. 1 with the exception of the execute phase. Process execution is handled by the systems already in place within an organization. Such systems may include ERP systems or more process-oriented systems such as process execution engines. The iWISE system does not seek to replace these systems but leverage the system events triggered and business data created or manipulated.

Fig. 5. iWISE architecture containing the iWISE Event Server as the core

The iWISE architecture is illustrated in Fig. 5. Process models are captured using the iWISE Process Capture Tool (PCT) which is a Microsoft Visio-based standalone application. The PCT allows users to construct a process map and define events and metric thresholds linked to a process. The iWISE Legacy Listener components are configured to detect events in IT systems. Once detected, the events are constructed using the format in Fig. 3b and sent to the iWISE Event Server where they are parsed and stored. The iWISE Event Server is the central component responsible for managing models, event streams and metric calculations using the three software packages shown in Fig. 5: the Model Manager, Event Manager and Metric Manager. The Model Manager receives process models from the iWISE PCT and compiles them for further processing. The Event Manager component receives enterprise events


247

from Listeners defined in the format as specified during process capture. When raw events arrive, they are parsed and associated with the correct process. As events are processed, the Metric Manager component generates alerts based on a pre-defined set of rules. It also generates metrics on-the-fly to provide an up-todate process view for the iWISE Process Dashboard. The iWISE Process Dashboard is a Microsoft portal application that provides a timely snapshot of process performance.

6.1 Generating Process Alerts The iWISE Event Server Metric Manager (see Fig. 5) component detects process execution anomalies in (near) real time and structures these exceptions for further processing by Microsoft Notification Services (MSNS). Before alerts can be generated, rules must be defined, based on the model described in Sect. 4. The rules are specified using SWRL based on the ontology concepts defined in Sect. 5. The Protégé Ontology Editor is used to create both the ontology and SWRL rules to form the knowledge base required for analysing process runtime exceptions. Once specified, the rules are loaded into the Event Server for access at runtime. At runtime, a Java stateless session bean is invoked at every time interval (set in configuration properties before application deployment) to calculate various process measurements. For example, using the rule given in Sect. 5, the current process utilization level can be calculated and compared against a minimum acceptable value defined during the process design phase. The details of the process and metric are supplied to the Bossam reasoner (Jang and Sohn, 2004), where the SWRL rules are used to reason if the metric supplied, and therefore the process, are outside normal limits of execution. In the case of process utilization, if the current level is below a minimum level, then that process is out of bounds. When a process metric is in such an exception state, the monitoring software will supply the exception information to an SQL Server database. MSNS will detect the information and generate a notification and alert if there are any subscribers defined for the process and metric in question. The iWISE Process Dashboard contains a process alerts subscription management page to allow users to subscribe to predefined alerts for processes deployed within the Event Server.

7 Conclusions iWISE supports process exception alerting by executing business rules against thresholds using semantic techniques. This research addresses the major functionality of a BAM system as outlined in Nesamoney (2004). Most important is the process-aware nature of the iWISE framework and underlying model that incorporates a performance aspect into its structure. Current work is focussing on the extension of the event model to cater for business parameter definitions not related to cycle time to allow calculation of Six Sigma type metrics on a constant basis. Further discussion can be found in Costello et al. (2005). The use of business rules

248


to monitor process performance is novel compared with the retrospective nature of BI techniques.

References Costello, C., Molloy, O., Duggan, J., and Lyons, G. (2005). Using Event-Based Process Modelling to Support Six Sigma Quality. In Sixteenth International Workshop on Database and Expert Systems Applications (DEXA), Copenhagen, Demark, 22–26 August. Costello, C., Fleming, W., Molloy, O., Duggan, J., and Lyons, G. (2006). iWISE: A Framework for Providing Distributed Process Visibility Using an Event-Based Process Modelling Approach. In Eighth International Conference on Enterprise Information Systems (ICEIS), Paphos, Cyprus, 23–27 May. Haller, A. and Oren, E. (2006). A Process Ontology to Represent Semantics of Different Process and Choreography Meta-Models, http://www.m3pe.org/deliverables/process-ontology.pdf. Horrocks, I., Patel-Schneider, P. F., Boley, H., Tabet, S., Grosof, B., and Dean, M. (2004). SWRL: A Semantic Web Rule Language Combining OWL and RuleML, http://www.w3. org/Submission/SWRL/. Jang, M. and Sohn, J.-C. (2004). Bossam: An Extended Rule Engine for OWL Inferencing. In Rules and Rule Markup Languages for the Semantic Web. Third International Workshop, RuleML 2004, Hiroshima, Japan, 8 November. Lera, I., Juiz, C., and Puigjaner, R. (2006). Performance-related Ontologies for Ubiquitous Intelligence Based on Semantic Web Applications. In AINA’06: Proceedings of 20th International Conference on Advanced Information Networking and Applications, Vienna, Austria, 18–20 April. McCoy, D. (2002). Business Activity Monitoring: Calm Before the Storm, http://www.gartner.com. McGregor, C. (2002). The Impact of Business Performance Monitoring on WfMC Standards. In WfMC Workflow Handbook 2002, Vol. (Ed., L. Fischer), Future Strategies: Lighthouse Point. McGregor, C., Schiefer, J., and Muehlen, M. z. (2006). A Shareable Web Service Based Intelligent Decision Support System for On-Demand Business Process Management, International Journal of Business Process Integration and Management, 1 (3). Melchert, F., Winter, R., and Klesse, M. (2004). Aligning Process Automation and Business Intelligence to Support Corporate Performance Management. In Tenth Americas Conference on Information Systems, New York, NY, August 5–8. Mendling, J. and Neumann, G. (2005). A Comparison of XML Interchange Formats for Business Process Modelling, In WfMC Workflow Handbook 2005, Vol. 185–198. Neely, A. (2004). Performance Measurement System Design: A Literature Review and Research Aagenda, International Journal of Operations and Production Management, 25 (12), 1228–1263. Nesamoney, D. (2004). BAM: Event-Driven Business Intelligence for the Real-Time Enterprise, DM Review, 14 (3), 38–40. RuleML (2000). The Rule Markup Initiative (RuleML), WWW, http://www.ruleml.org/. Smith, B. (1993). Making War on Defects: Six-Sigma Design, IEEE Spectrum, Vol. 43–47. Thomas, M., Redmond, R., Yoon, V., and Singh, R. (2005). A Semantic Approach to Monitor Business Process, Communications of the ACM, 48 (12), 55–59. van der Aalst, W. M. P. (2003). Workflow Patterns, Distributed and Parallel Databases, 13 (7), 5–51. van der Aalst, W. M. P., ter Hofstede, A. H. M., and Weske, M. (2003). Business Process Management: A Survey. In Proceedings 1st International Conference on Business Process Management, Eindhoven, The Netherlands, 26–27 June. W3C (2004). OWL Web Ontology Language Overview, http://www.w3.org/TR/2004/REC-owlfeatures-20040210/. zur Muehlen, M. and Rosemann, M. (2004). Multi-Paradigm Process Management. In CAiSE'04 Workshops – Fifth Workshop on Business Process Modeling, Development and Support (BPMDS 2004), (Eds., J. Grundspenkis and M. Kirikova), Riga, Latvia, 7–8 June.