Performance Measurement in Business Process, Workflow and ...

Download PDF
4 downloads 16692 Views 893KB Size Report
Comment
Jan 10, 2011 - and analysis tools with human resource management and management tools. The aim of ... known business process and workflow modelling.
Knowledge and Process Management Volume 18 Number 4 pp 241–265 (2011) Published online in Wiley Online Library (wileyonlinelibrary.com) DOI: 10.1002/kpm.387

■ Research Article

Performance Measurement in Business Process, Workflow and Human Resource Management Michael Glykas* Financial Management Engineering, University of the Aegean, North Aegean, Greece

Organisational performance measurement systems still suffer from different shortcomings such as the following: performance measurement is still focused too strongly on financial performance indicators found on balance sheets and accounting information, business processes are not measured systematically, real-time performance data become available with a considerable time lag, access to performance data is complicated, and the performance measurement processes are poorly defined. During execution, a system records a series of data useful for both scheduling of tasks and for overall performance evaluation of the process and other organisational elements. These real-time data allow the comparison between planed and actual performance. In this paper, we present a process monitoring tool that integrates process modelling and analysis tools with human resource management and management tools. The aim of the tool is to allow performance measurement at both the individualistic (employee) level and the holistic (process–organisational unit) level with changes in one level being transferred to the other in an integrated manner. Analysis is performed on effort-based activity-based costing at both aforementioned levels. Copyright © 2011 John Wiley & Sons, Ltd.

Keywords: process management, performance measurement, human resource management, work-flow management, human resource management

INTRODUCTION For many years, companies have been seeking to improve their business performance to remain cost competitive and customer focused in rapidly changing market conditions. To achieve this goal, they have to model and analyse business processes that consume organisational resources to achieve their purpose and results. These processes are executed by humans who work in the organisation whose performance influences and gets in turn influenced by process performance. So changes at the individualistic level of the employee cause changes to business processes and vice versa (Ghanem et al., 2002; Syed et al., 2002; van der Aalst and Hofstede, 2002; Andrews et al., 2003; Buhler and Vidal, 2004;

*Correspondence to: Michael Glykas, Department of Financial and Management Engineering, University of the Aegean, 34 Kountouriotou Street, Chios, Greece, 82100. E-mail: [email protected]

Copyright © 2011 John Wiley & Sons, Ltd.

Buhler and Vidal, 2005; Upstill and Boniface, 2005; Bradley et al., 2006; Hull et al., 2006; Ludascher et al., 2006; Taylor et al., 2006; Ghanem et al., 2008; Inforsense Ltd, 2008). Most Business Process Modelling Notations (BPMNs) concentrate on modelling the holistic process model and assume that the micro-individualistic employee level follows process execution. Workflow modelling notations on the contrary concentrate on the flow of documents and work amongst job description holders and pay more attention to automation of document–process flows (Michalickova et al., 2002; Oinn et al., 2004; Pillai et al., 2005; Taylor et al., 2005; Winder, 2006; Taylor et al., 2007; Freefluo, 2008). Human resource management (HRM) systems concentrate on the management of a firms most valuable element the employee (Boudreau et al., 2002; Rowe et al., 2003; Curcin et al., 2004; Ghanem et al., 2004; Guo et al., 2005; Richards et al., 2006). They target performance measurement at the micro-employee level; they allow the development of systems like rewards and incentives, training and education, salary

242

M. Glykas

and pay ranges, career pathing, etc. (Allen et al., 2002; Taylor et al., 2003; Balasubramanian et al., 2005). The use of these systems and their different performance measurement ratios result in confusion in real life and may cause conflicting results and outcomes. However, if these systems work in a consistent and integrated manner, they can produce astonishing results. In this paper, we present a business analysis engine that provides for the integration of performance measurement techniques and the appropriate ratios used in these three tool categories both during design and process execution. In sections 2 and 3, we describe the most wellknown business process and workflow modelling notations, respectively, before we present in section 4 the most well-known workflow modelling language used for importing and exporting data from the three tool categories (process, workflow and HRM) to the ADJUST tool. In the remaining sections, we present the ADJUST tool functionality as well as importing and exporting mechanisms.

BUSINESS PROCESS MODELLING NOTATIONS The BPMN (Harmon and Davenport, 2007) provides a BPMN for business analysts, technical developers and business people who manage and monitor these processes. BPMN generates execution definitions that can be used to implement the business processes and thus providing the bridge between modelling and execution (Nagatani, 2001; van der Aalst et al., 2003; Lee and Xiong, 2004; Brooks et al., 2005; Chen and van Aalst, 2007; Goderis et al., 2007a). BPMN allows users to create business process diagrams that represent the activities of the business process and the flow controls that define the order in which they are performed. The Business Process Modelling Language (BPML) (Harmon and Davenport, 2007) provides an abstract model for expressing business processes. BPML defines a formal model for expressing abstract and executable processes that address all aspects of enterprise business processes, including activities of varying complexity, transactions and their compensation, data management, concurrency, exception handling and operational semantics. BPML also provides a grammar in the form of an XML schema for enabling the persistence and interchange of definitions across heterogeneous systems and modelling tools. Its formalism is a transactional finite state machine with state transitions as shown in Figure 1. The Discovery Process Markup Language (Nakaya et al., 2010) is a declarative XML processing language. It is more than a simple transform pipelining language as it allows conditional processing, loops, sub-routines and exception handling. It considers XML documents as the basic data quantum and URLs (Uniform Resource Locator) as the method Copyright © 2011 John Wiley & Sons, Ltd.

Figure 1 Transactional finite state machine with state transitions

of addressing them. The XML processing instructions and resolution of URI schemes are abstracted from the language so as to be fully extensible. The Grid Job Definition Language is part of a set of definition languages called Grid Application Definition Language, developed within the Fraunhofer Resource Grid (Hoheisel, 2002; Hoheisel and Der, 2003a; Hoheisel, 2004). It is based on the formalism of Petri nets. The Generic Workflow Description Language (GWorkflowDL) (HoheiselF, 2002; Hoheisel, 2004) is an extension of the existing Grid Job Definition Language, an XML-based language that makes use of the formalism of Petri nets to describe the dynamic behaviour of distributed Grid jobs (Figure 2). The advanced GWorkflowDL has the following features: (1) The rules of coloured Petri nets apply. (2) Definition of transitions. (3) A transition may also refer to a whole sub net –> hierarchical approach. (4) Edges link transitions to input places and output places. Edge expressions are used to relate input places to a specific parameter of a Web service operation. (5) Definition of places. (6) Transitions may be annotated with conditions. Conditions could be expressed by queries,

Figure 2 Distributed Grid Jobs Formalism

Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

Performance Measurement in HR Management by Web service (as will be discussed later) operations or other (user-defined) modules that return a Boolean value. (7) Tokens are placed on places and contain highlevel control information (e.g. true or false) or data related to the input and output parameters of the Web service operations. Tokens store the state of the workflow. One implementation of a Workflow Engine for the GWorkflowDL is the so-called Generic Workflow Execution Service (Hoheisel, 2004). Figure 3 represents the XML schema of the GWorkflowDL version 0.4. The Grid Services (Hoheisel and Der (2003b); Richards et al., 2006; Chen and van Aalst, 2007; AGWL, n.d.) Flow Language is an XML-based language that allows the specification of workflow descriptions for Grid services. It has been defined using XML schemas. It has the following important features: • Service Providers, which are the list of services taking part in the workflow; • Activity Model, which describes the list of important activities in the workflow; • Composition Model, which describes the interactions between the individual services; and • Lifecycle Model, which describes the lifecycle for the various activities and the services which are part of the workflow. The Service Workflow Language (SWFL) (Hoheisel, 2004; W3C, n.d.), is an XML-based metalanguage for the construction of scientific workflows. SWFL was developed at Cardiff University in 2002 and 2003. SWFL supports a new set of conditional

243

operators and loop constructs as well as arrays and objects. SWFL has a workflow engine.

WORKFLOW LANGUAGES The XML Process Definition Language is a format standardised by the Workflow Management Coalition (WfMC, n.d.a.) to interchange Business Process definitions between different workflow products like modelling tools and workflow engines (Addis et al., 2003; Hoheisel and Der, 2003a; Hoheisel, 2004; Wassermann et al., 2006a; Wassermann et al., 2006b; Goderis et al., 2007b; Slominsky, 2007).

Web Service-Based Languages A Web service (W3C, n.d.; Web Services Description Language (WSDL), n.d.; UDDI: Universal Description, Discover and Integration of Business for the Web, n.d.; Web Services Inspection Language (WSIL), n.d.; Web Services Flow Language (WSFL), n.d.) is a software application whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols. Automated resources accessed via the Internet. Web services are software-powered resources or functional components whose capabilities can be accessed on the Internet. Standards-based Web services use XML to interact with each other, which allows them to link up on demand using loose coupling.

Figure 3 XML schema of the GWorkflowDL version 0.4

Copyright © 2011 John Wiley & Sons, Ltd.

Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

244

M. Glykas

A self-contained, modular application that can be described, published, located and invoked over the Web. Platform-neutral and based on open standards, Web services can be combined with each other in different ways to create business processes that enable you to interact with customers, employees and suppliers. The Web Services Conversation Language provides the following capabilities:

description of service interfaces and their protocol bindings. WSDL is a format for describing a Web services interface. It is a way to describe services and how they should be bound to specific network addresses. WSDL has three parts:

• Sequencing of interactions between operations of a single interface; • Document Type Descriptions; • Types of documents to be exchanged; • Interactions; • The actions of a conversation between participants; • Transitions; • Ordering relationships between interactions; • Conversations; and • Set of interactions and transitions.

Definitions are generally expressed in XML and include both data type definitions and message definitions that use the data type definitions. These definitions are usually based upon some agreed upon XML vocabulary. This agreement could be within an organisation or between organisations. Vocabularies within an organisation could be designed specifically for that organisation. Operations describe actions for the messages supported by a Web service. There are four types of operations:

Business process execution language for web services (BPEL4WS) BPEL4WS (WS-BPEL, n.d.) provides a formal language for the specification of business processes and business interaction protocols. It extends the interactions of Web services as it enables it to support business transactions. BPEL4WS defines an integrated model that facilitates the expansion of automated process in both intra-corporate and the business-to-business environments (Hoheisel 2002). Executable business processes imitate actual behaviour of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behaviour of each of the parties involved in the protocol, without revealing their internal behaviour. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used to model the behaviour of both executable and abstract processes.

• one-way: messages sent without a reply required; • request/response: the sender sends a message and the received sends a reply; • solicit response: a request for a response. (The specific definition for this action is pending.); and • notification: messages sent to multiple receivers. (The specific definition for this action is pending.)

Web services flow language The Web Services Flow Language (Web Services Flow Language (WSFL), n.d.; Web Services, n.d.) is a language for the description of Web services compositions. WSFL considers two types of Web services compositions. • The appropriate usage pattern of a collection of Web Services, in such a way that the resulting composition describes how to achieve a particular business goal; typically, the result is a description of a business process. • The interaction pattern of a collection of Web services; in this case, the result is a description of the overall partner interactions. Web Services Flow Language uses Web Services Description Language (Web Services Description Language (WSDL), n.d.; Web Services, n.d.) for the Copyright © 2011 John Wiley & Sons, Ltd.

• definitions, • operations and • service bindings.

Operations are grouped into port types. Port types define a set of operations supported by the Web service. XML-based workflow language Developed at the University of Melbourne, XMLBased Work-flow Language is a simple language for describing workflows with tasks, parameters and data dependency links. An example of a workflow document is essentially a list of tasks (which could be either executables or Web service operations) followed by a list of interconnections between them.

Grid-based languages A Grid can be defined as a layer of networked services that allow users single sign-on access to a distributed collection of information technology, data and application resources (WS-BPEL, n.d.; W3C, n.d.). The Grid services allow the entire collection to be seen as a seamless information processing system that the user can access from any location. Abstract grid workflow language Currently, Grid application developers often configure available application components into a workflow of tasks that they can submit for executing on the Grid. The Abstract Grid Workflow Language (AGWL, n.d.) describes Grid workflow applications at a high level of abstraction. AGWL has been designed such that the user can concentrate on Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

Performance Measurement in HR Management specifying scientific applications without dealing with either the complexity of the Grid or any specific implementation technology such as Web/ Grid services (Web Services Description Language (WSDL), n.d.; UDDI: Universal Description, Discover and Integration of Business for the Web, n.d.; Web Services Inspection Language, (WSIL), n.d.; Web Services Flow Language, (WSFL), n.d.), software components or Java classes. AGWL is an XML-based language that allows a programmer to define and interconnect activities that refer to computational tasks or user interactions. Activities are connected by control and data flow links. A rich set of constructs is provided to simplify the specification of Grid workflow applications that includes basic control flow constructs such as ‘if-then-else’, ‘foreach’ and ‘while’ loops as well as advanced control flow constructs including parallel sections, parallel loops and collection iterators. Moreover, AGWL supports a generic high-level access mechanism to data repositories. AGWL is the main interface to the ASKALON (ASKALON, n.d.) Grid application development environment and has been applied to numerous real-world applications. Data grid language The GriPhyN Data Grid Language (DGL) (Li et al., 2003) developed by GriPhyN is an XML schema-based language that defines the format of gridflow requests and gridflow responses. It borrowed well-known computer science concepts in Compiler Design (recursive grammar, scoped variables and execution stack management), Data Modelling (schema definitions for all logical data types), Grid Computing (Fundamental data grid operations) and other features like XQuery that provide query capabilities during gridflow execution. It currently supports the following gridflow patterns: • • • • •

sequential flow, parallel flow; while loop, for loop; milestone execution; switch-by-context; and concurrent parameter sweep, n of m execution.

It allows description of pre-process and postprocess rules to be executed, very similar to triggers in databases. Research prototype to compile DGL at runtime into a format is called DAX (DAG in XML). This format serves as input for the GriPhyN Pegasus Planner (Li et al., 2003) that can be used to start DGL computational processes in the grid using Condor-G (Li et al., 2003). Simple conceptual unified flow language Simple Conceptual Unified Flow Language is used in the myGrid project. It defines a high-level workflow description language that allows the user to map a conceptual task to a single entity with a minimal amount of implementation specific information (the translation to lower-level entities is done by the Copyright © 2011 John Wiley & Sons, Ltd.

245

underlying system called the IT Innovation Enactment Engine). Three main entities are defined: processors, data links and coordinations. Unfortunately, it is not possible to specify user-defined constraints neither to processors nor to data links. There is a basic exception handling mechanism included. It supports retry of invocation with configurable time out and number of retries and user-defined alternatives for processors failing constantly.

Petri net-based languages Van der Aalst and Kumar (2000) give an overview of how to describe different workflow patterns using Petri nets. Petri nets are suitable to describe the sequential and parallel execution of tasks with or without synchronisation; it is possible to define loops and the conditional execution of tasks. Petri nets are used not only to model but furthermore to control the execution of the workflow. In most cases, the workflow within Grid jobs is equivalent to the data flow, i.e. the decision when to execute a software component is taken by means of availability of the input data (ISO 15909–1, 2004-15909-1). Therefore, the tokens of the Petri net represent real data that are exchanged between the software components. In this case, Petri nets are used to model the interaction between software resources represented by software transitions and data resources represented by data places (Jensen, 1994; ISO 15909–2, 2005). In other cases, however, the workflow should be independent from the data flow, and the issue of control becomes of uppermost importance; in this case, data places and software transitions are enhanced by control places and control transitions (van der Aalst, n.d.; Mulyar and van der Aalst, 2005). Control transitions evaluate logical conditions. In the case that a software transition is linked to a command line program, the tokens on the output places contain the exit status of the process (e.g. done, failed), whereas in the case of Grid services, the tokens store the output parameter returned by the method call. The state of the workflow is represented by the marking of the Petri net, which makes it easy to implement tools for workflow check pointing and recovery. An XML syntax similar to the Petri Net Markup Language developed by Weber and Kindler (2002) was developed for specifying Petri nets within the GJobDL (Hoheisel and Der, 2003b; Hoheisel and Der (n. d.)). Yet another work-flow language Yet Another Work-flow Language (YAWL) (YAWL, n.d.) is a workflow language built upon two main concepts: workflow patterns and Petri net. It enhances Petri nets by adding mechanisms to allow a more direct Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

246

M. Glykas

and intuitive support of the workflow patterns identified. YAWL supports the control flow perspective and the data perspective. As communication patterns are built-in, YAWL is an attractive alternative in the area of Web services and Enterprise Application Integration. Yet Another Workflow Language provides the following: • OR, AND and XOR splits/joins; • single tasks are atomic ones or subworkflows; • Web services may be used as atomic tasks of a workflow; • explicit parallelism (multiple instances of an atomic task); and • cancellation of a part of a workflow by a particular task.

Agent-based languages More recently, many attempts have been undertaken to integrate workflow management systems with advances in the field of software agents. These agents are usually very basic and used to implement autonomous activities. Agent technology can provide system architectures for integrating multiple workflow systems and thus be considered themselves as multi-agent systems. Applications of agents to workflow management systems can be classified into two forms (Yan et al., 2001): agent-enhanced workflow management and agent-based workflow management. Several proposals have appeared in the literature for distributed workflow enactment mechanisms based on the Agent paradigm (Buhler and Vidal, 2004). Such approaches differ from each other in the supported dimensions of distribution (computation, control and data), in the adopted coordination model (control-driven, data-driven) and in the exploited MAS (Multi Agent Systems) organisational structure (hierarchical, peer-to-peer). Some authors propose an agent-based workflow engine (Repetto et al., 2003; Ehrler et al., 2006; Savarimuthu et al., ), centred on a hierarchical structure in which a ProcessAgent executes a workflow instance by requesting the execution of the tasks composing the workflow to a set of ResourceAgents. ResourceAgents can be seen as representing Web services and can be dynamically discovered and allocated to a ProcessAgent by a ResourceBrokerAgent. In this control-driven approach, the control about the state of the workflow execution is hierarchically distributed between the ProcessAgents and the computation, whereas data are distributed among the ResourceAgents who are responsible of the task execution. Others suggest an agent-based approach for enacting workflows specified in BPEL4WS (Buhler and Vidal, 2004; Buhler and Vidal, 2005; Guo et al., n.d.; Buhler and Vidal (B)). The novelty of the approach is that the enactment of the workflows is carried out Copyright © 2011 John Wiley & Sons, Ltd.

by peer agents that can be associated with Web services. The control flow is coded in an interaction protocol that is not defined at the development time but only at run-time exchanged between agents together with the messages so informing each agent what to do next regarding workflow execution. Another peer-to-peer agent-based enactment approach is presented in the study conducted by Yan et al. (2005). In this approach, the workflow to be enacted is decomposed into a set of interrelated task partitions. Each task partition represents a service and its position, i.e. the interaction and dependency with the other services in the process. Then, each task partition is distributed to an agent, which represents a service provider offering a service required by the specific workflow instance. Each agent autonomously manages the enactment of the represented service and the interactions between this service and the others only on the basis of the assigned task partition; agents are not conscious of the whole process in which they are involved. Such adopted coordination model is known as a choreography coordination model (Purvis et al., 2004). XLANG One of the most notable examples of agent-based workflows is XLANG (XML language) (Biztalk, n.d.), which allows the modelling of business processes as Autonomous Agents. The unit of actions is a Service Process, which consists of a set of operations according to a defined sequence of Sequential and parallel control flow constructs. XLANG provides its users the following capabilities:

• transaction support; • custom correlation of messages; • flexible handling of exceptions; • dynamic service referral; and • contracts to agglomerate services XLANG and the pi calculus One of the most interesting features of XLANG is the support for explicit exception handling and compensating transactions. Compensating transactions are a crucial emerging pattern in the scenario of Service-Oriented Computing (Biztalk, n.d.). Compensation triggering, as implemented by the Microsoft XLANG engine BizTalk, has been modelled with the pi calculus (Biztalk, n.d.).

Composition tools and our proposition The most notable example of this category is Taverna (Taverna, n.d.) that contains a composition of several tools for business modelling, graphical user interfaces for workflow composition, process enactment engines, etc. The Taverna suite is written in Java and includes the Taverna Engine (used for enacting workflows) that powers both the Taverna Workbench (the Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

Performance Measurement in HR Management desktop client application) and the Taverna Server (which allows remote execution of workflows). Taverna is also available as a Command Line Tool for a quick execution of workflows from a terminal. However, all tools we have seen so far concentrate on workflow engines and the enactment of business processes with the workflow schemata being provided by business modellers. However, most BPMNs concentrate on modelling the holistic process model and assume that the micro-individualistic employee level follows process execution. Workflow modelling notations on the contrary concentrate on the flow of documents and work amongst job description holders and pay more attention to automation of document–process flows. HRM systems concentrate on the management of a firm’s most valuable element—the employee. They target performance measurement at the micro-employee level; they allow the development of systems like rewards and incentives, training and education, salary and pay ranges, career pathing, etc. The use of these systems and their different performance measurement focus results in confusion in real life and may cause conflicting results and outcomes. However, if these systems work in a consistent and integrated manner, they can produce astonishing results. In this paper, we present a business analysis engine that tries to integrate performance measurement techniques and ratios used in these three tool categories both during design and process execution. In the next sections, we present a system that attempts to integrate all these concepts in the workflow engine and present real-time data and comparisons between planned and real performance. The resulting tool has been developed over many years, and its validity has been assigned in real-life case studies (Glykas and Valiris, 1998; Valiris and Glykas, 1998; Gykas and Valiris, 1999a; Valiris and Glykas, 1999; Valiris and Glykas, 2000; Xirogiannis and Glykas, 2004a; Glykas, 2011; SMD, n.d.).

247

THE WORK-FLOW MANAGEMENT COALITION STANDARDS The Work-flow Management Coalition (WfMC, n.d.a; WFMC, ) is a grouping of companies that have joined together to address the issue of standardisation in workflow languages and execution engines. Recognising that all work-flow management products have some common characteristics, the WfMC has undertaken the responsibility to define common standards for various functions, which would allow for a reasonable degree of interoperability. The WfMC has developed a Workflow Reference Model for workflow management systems, which describes a generic model for the construction of work-flow systems and identifies how it may be related to various alternative implementation approaches.

The work-flow management coalition workflow reference model The Work-flow Reference Model has been developed from the generic work-flow application structure by identifying the interfaces within this structure, which enable products to interoperate at a variety of levels. All work-flow systems contain a number of generic components that interact in a defined set of ways; different products will typically exhibit different levels of capability within each of these generic components. To achieve interoperability between work-flow products, a standardised set of interfaces and data interchange formats between such components is necessary. A number of distinct interoperability scenarios can then be constructed by reference to such interfaces, identifying different levels of functional conformance as appropriate to the range of products in the market. Figure 4 illustrates the major components and interfaces within the work-flow architecture. The Workflow Reference Model will not be reproduced in its

Process Definition Tools Interface 1 Interface 5

Workflow API and Interchange formats

Interface 4 Other Workflow Enactment Service(s)

Workflow Enactment Service

Administration & Monitoring Tools

Workflow Engine(s)

Interface 2 Workflow Client Applications

Workflow Engine(s)

Interface 3

Invoked Applications

Figure 4 ©The WfMC reference model

Copyright © 2011 John Wiley & Sons, Ltd.

Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

248

M. Glykas

entirety here; however, five basic or ‘top level’ categories of interoperability and communication standards that will allow multiple work-flow and other products to coexist and interoperate within a user’s environment have been extracted and will serve as the preliminary criteria for the workflow product comparison that will be carried out in the subsequent section. The five main areas of conformance as defined by the WfMC are described briefly as follows: Interface 1 – Process Definition Interchange Interface Objective: to allow the use of different work-flow process definition tools to produce process descriptions to be used by several different work-flow engines. Using the same process definition format, for example BPR (Business Process Reengineering) tools can load the results of a complete BPR cycle directly into the work-flow engine, accelerating live implementation of the reengineered business processes and lowering the development costs. This interface is termed the process definition import/ export interface that would provide a common interchange format for the following types of information:

management services or existing user applications. The coalition sees value in the development of standards for the invocation of such applications by building ‘tool agents’, which will provide the interface to invoke the applications. In addition, it is seen that it may be possible to develop a set of APIs (Application Programming Interface) that will allow other developers to build ‘workflow-enabled’ applications that can be invoked directly from the workflow engine. Interface 4 – Workflow Interoperability Interface Objective: to allow interoperability between heterogeneous workflow systems. By exchanging electronic information and commands through networks, workflow interoperability supports processes that cross enterprise boundaries:

• one procedure can span several workflow engines; • enterprise wide workflows can be built using several different workflow engines; and • virtual enterprises can be implemented by the cooperation of engines.

• process start and termination conditions; • identification of activities within the process, including associated applications and workflow relevant data; • identification of data types and access paths; • information for resource allocation decisions; and • definition of transition conditions and flow rules.

Within a large enterprise, this facility may be vital when specialised workflow applications use their own environment (like in Computer Aided Design (CAD)/ Computer Aided Manufacturing (CAM) applications) and need enterprise-wide integration into a global process, thereby bringing together contributions from each department to provide best service.

Interface 2 – Work-flow Client Application Interface

Interface 5 – System Administration and Monitoring Interface

Objective: to enable work-flow client applications to retrieve, perform, submit and monitor work. It defines standards for the construction of a common work-list handler to provide work-list management for one or more work-flow systems, thereby enabling the delivery of several different work-flow services to be combined at the desktop, giving the appearance to the end user of a single service. The work-list handler is a software component that manages and formulates a request to the work-flow enactment service to obtain a list of work items. It allows the interaction between several work-flow services controlled from the desktop environment (for example, work-flow relevant data interchange between two processes instantiated on different workflow services or an activity within one process enactment causing the start of a new process on the second service - the activity gateway approach). Interface 3 – Invoked Application Interface Objective: to allow application agents and applications that have been designed to be ‘workflowenabled’ to interact directly with the workflow engine. There is a requirement for workflow systems to deal with a range of invoked applications, for example to invoke an email service, a fax service, document Copyright © 2011 John Wiley & Sons, Ltd.

Objective: to support common management, administration and audit functions across several workflow management products. For instance, logs collected by several engines can be gathered at a central point and processed to produce aggregated statistics. This interface also refers to scalability in terms of allowing for the central administration of a network of remote servers. Work-flow enactment service The workflow enactment service provides the runtime environment in which one or more workflow processes are executed. This may involve more than one actual workflow engine. The enactment service is distinct from the application and end-user tools, which are used to process items of work. A wide range of industry-standard or application-specific tools can therefore be integrated with the workflow enactment service to provide a complete workflow management system. This integration takes two formats.

• The invoked application interface, which enables the workflow engine directly to activate a specific application to undertake a particular activity. This would typically be server based and require no user action, for example to invoke email application. Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

Performance Measurement in HR Management

• The workflow client application interface through which the workflow engine interacts with a separate workflow client application responsible for organising work on behalf of particular user.

REAL-TIME ORGANISATIONAL PERFORMANCE MEASUREMENT IN WORKFLOW ENGINES The aim of ADJUST is not to develop yet another workflow engine-tool but rather a platform that will get information from languages, workflow engines or tools (WorkFlow Management System (WFMS), BPR) that comply to the WfMC standards to perform a holistic analysis of business models in real time.

Workflow management coalition interface 1: process definition interchange process model This interface includes a common meta-model for describing the process definition and also a textual grammar for the interchange of process definitions (Work-flow Process Definition Language (WPDL)) and APIs for the manipulation of process definition data. A variety of different tools may be used to analyse, model, describe and document a business process. The work-flow process definition interface defines a common interchange format, which supports the transfer of work-flow process definitions between separate products. The interface also defines a formal separation between the development and run-time environments, enabling a process definition, generated by one modelling tool, to be used as input to a number of different work-flow engines and tools. This meets the oftenexpressed user’s requirements for the independence of modelling and work-flow engines and tools. Interface 1 of the WfMC reference model is implemented in ADJUST as a process definition tool that has the capability of interfacing with other tools that are using the same standard. To provide a common method to access and describe work-flow definitions, a work-flow process definition meta-data model has been established. This meta-data model identifies entities that are used commonly in the two work-flow engines or languages. The WPDL exporters and importers are capable of ‘translating’ a limited number of entities that compose the ‘Minimum Meta Model’ necessary for the calculations and ratios used in the ADJUST Business Analysis Engine. One of the most important elements of the WPDL is a generic construct structure that captures workflow engine-tool specific attributes in a generic form. Both batch and API-based interface architectures of ADJUST contain a ‘filter’ mechanism to support the information exchange. Via this ‘WfMC interface/1 layer’ input or output of real-time information can Copyright © 2011 John Wiley & Sons, Ltd.

249

be translated to the generic WPDL form and from this to engine or tool-specific representations if needed. The transfer mechanism could be either API based or batch oriented (via files or memory transfers). The transfer mechanism that has been selected in ADJUST for common use is the batch-oriented approach. Two exporters have been constructed in ADJUST. The ARIS Toolset , (IDS-SCHEER, n.d.) to WPDL exporter that ‘translates’ ARIS Toolset techniques like extended Event Process Chain Diagrams, organisational models, function trees, etc. to WPDL ready for import to ADJUST. The ELENIX workflow engine (SMD, n.d.) to WPDL exporter that in a similar manner ‘translates’ ELEXIX workflow–process models to WPDL. The one importer implemented in ADJUST reads WPDL text files and imports the information into ADJUST Repository. The ‘WfMC interface/1 layer’ is implemented as a client–server application as required by the WfMC Reference Model presented in Figure 4 in the previous section. ADJUST vendor tool exporters There are two possible approaches to achieve proper interchange of a workflow process definition. • Define build-time APIs for the creation of the objects, their attributes and relationships participating in a work-flow. • Define a common language for describing workflow processes that can be transferred as part of a textual file. This section describes the meta-model that used in ADJUST to define the objects and attributes contained within a process definition. The WPDL grammar is directly related to these objects and attributes. This approach needs two types of interfaces to be provided by a vendor. • Import a workflow definition from a character stream of definitions according to the common process definition language into the vendor’s internal representation. • Export a workflow definition from the vendor’s internal representation to a character stream according to the common process definition language. In ADJUST, we have implemented both types of interfaces. For example, we export ARIS Toolset and ELENIX internal representation into WPDL, and the later is translated and imported into ADJUST Repository internal representation. Process definition interchange The requirement to transfer process definitions, in whole or part, may occur for a number of business reasons. • The use of a vendor-specific tool to define, model, analyse, simulate or document a business process before its enactment on a (different) workflow execution service (or services) enables separate selection of workflow and process definition/modelling tools, allowing the most suitable tool to be used for each part of the overall system. • The transfer and retrieval of process definitions to/ Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

250

M. Glykas

from a common database repository, accessed by a number of different tools or run-time systems, may be desirable to provide a single consistent-controlled process definition repository to all different tools and run-time systems and thus identifying, presenting and bridging conceptual or functional inconsistencies amongst them. • The modification of existing process definitions by authorised users during enactment, either on a one-off or persistent-basis need to be broadcast in all systems in a consistent and controlled manner. • The transfer of a process definition (in whole or part) from one workflow engine to another may be necessary to facilitate interoperability of that process between two or more workflow engines during process enactment. Such transfer may take place before, or in some cases during, enactment. The workflow process definition interface defines a common interchange format, which supports the transfer of workflow process definitions between different products to solve problems arising in the situations described earlier. The interface also defines a formal separation between the modelling and design face and the runtime, enabling a process definition, generated by a modelling tool, to be used as input to a number of different workflow run-time engines. This meets the often-expressed user’s requirements for the independence of modelling and workflow run-time phases. A workflow process definition, generated by a runtime tool, is capable of interpretation in different workflow run-time engines. Process definitions transferred between these engines or stored in a separate repository are accessible via that common interchange format. The principles of process definition interchange are illustrated in Figure 5. The proposed version of ADJUST process definition interchange is shown in Figure 5. The ADJUST meta-model describes the top-level entities contained within a Workflow Process Definition, their relationships and attributes (including some, which may be defined for simulation purposes rather than workflow enactment). It also defines various conventions for grouping process definitions into related process models and the use of common definition data across a number of different process definitions or models (Figure 5). For each of the entities presented, there is an associated set of attributes (some mandatory and others optional) that describe the entity characteristics. The following sections describe these entity/attributes in more detail.

Figure 5 The ADJUST meta-model

proposed WPDL (WfMC, ) grammar for each entity. Grammar description will present WPDL output from the Exporter tools. The top-level entities are as follows. Workflow Process Definition This describes the process itself, i.e. ID and textual description, and provides other optional information associated with administration of the process definition (creation date, author, etc.) or to be used at process level during process execution (initiation parameters to be used, execution priority, time limits to be checked, person to be notified, simulation attributes, etc.). The Workflow Process Definition entity thus provides header information for the process definition and is therefore related to all other entities in that process. Workflow Process Definition Language grammar representation ::= WORK-FLOW [] [] // for use as subprocess [] // optional [] [] [] END_WORK-FLOW [] ::=

Entities overview The meta-model identifies the basic set of entities and attributes used in the exchange of process definitions. In this section, we will also give an overview of the Copyright © 2011 John Wiley & Sons, Ltd.

Workflow process activity A process definition consists of one or more activities, each comprising a logical, self-contained unit of work Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

Performance Measurement in HR Management

251

[] to declare more than one participants in the activity (WPDL limits the use of one participant per activity but ARIS Toolset and ELENIX assign more than one participant per activity).

within the process definition. An activity represents work that will be processed by a combination of resources and/or computer applications (specified by application assignment). Other optional information may be associated with the activity such as whether it can be started/finished automatically by the workflow management system or its priority level relative to other activities when congestion for resource or system services occurs. Usage of specific workflow relevant data items by the activity may also be specified. The scope of an activity is local to a specific process definition. An activity may be atomic and in this case is the smallest unit of self-contained work that is specified within the process. It can also generate several individual work items for presentation to a user invoking, for example different IT tools. An activity may be a sub-flow that may be executed locally within the same workflow service, or (using the process interoperability interface) on a remote service. The process definition identified within the sub-flow contains its own definition of activities, internal transitions, resource and application assignments (although these may be inherited from a common source). Inparameter and out-parameter permit the exchange of any necessary workflow relevant data between calling and called process (and, where necessary, on return). An activity may also be specified as a loop, which acts as controlling activity for repeated execution of a set of activities within the same process definition. In this case, the set of looping activities is connected to the ‘controlling (loop) activity’ by special loop begin/end transitions. A number of activities may form an online block, which is specified by particular transition constructs, and may be used, for example to represent a decomposition of a higher level activity within a process definition as an alternative to a sub-flow. Finally, a dummy activity is a skeletal activity that performs no work processing (and therefore has no associated resource or applications) but simply supports routing decisions within the incoming transitions and/or within the outgoing transitions. Workflow Process Definition Language grammar representation

Transition information Activities are related to one another via flow control conditions (transition information). Each individual transition has three elementary properties, the fromactivity, the to-activity and the condition under which the transition is made. Transition from one activity to another may be conditional (involving expressions that are evaluated to permit or inhibit the transition) or unconditional. The transitions within a process may result in the sequential or parallel operation of individual activities within the process. The information related to associated split or join conditions is defined within the appropriate activity, and split is defined in the form of ‘post activity’ processing in the fromactivity; similarly, join is defined as a form of ‘preactivity’ processing in the to-activity. This approach allows the workflow control processing associated with a process instance thread splitting and synchronisation to be managed as part of the associated activity and retains transitions as simple route assignment functions. The scope of a particular transition is local to the process definition, which contains the activity itself and its associated activities. More complex transitions, which cannot be expressed using the simple elementary transition (Route) attributes and the split and join functions associated with the from-activity and to-activity, are formed using dummy activities, which can be specified as intermediate steps between real activities allowing additional combinations of split and/or join operations. Using the basic transition entity plus dummy activities, routing structures of arbitrary complexity can be specified. Because several different approaches to transition control exist in different workflow tools and engines, several conformance classes need to be specified within the ADJUST WPDL grammar. Workflow Process Definition Language grammar representation

::= ACTIVITY [NAME ] [DESCRIPTION] [LIMIT ] [] // optional [] [] END_ACTIVITY [] ::= In ADJUST, we have used the [] to get the flow of information between activities, to declare sub-flows and therefore to get functional decomposition and

::= TRANSITION [NAME ] [DESCRIPTION ] [] END_TRANSITION [] ::= ::= FROM TO [CONDITION ] | FROM LOOP TO // connects first Activity in loop body | FROM TO LOOP // connects last Activity in loop body

Copyright © 2011 John Wiley & Sons, Ltd.

Know. Process Mgmt. 18, 241–265 (2011) DOI: 10.1002/kpm

252

M. Glykas

Transitions were not used in ADJUST. To be compliant though with standards, we translated transitions that appear in Satellite tools to WPDL. The transition part of a WPDL file was not transferred into ADJUST Repository. Work-flow Participant Declaration This provides descriptions of resources that can act as performer of activities. The resource, which can be assigned to perform an activity, is specified in the participant assignment attribute, which links the activity to the set of resources (within the work-flow participant declaration), which may be allocated to it. The work-flow participant declaration does not necessarily refer to a single person, user or a job description, but rather it may refer to a set of people of appropriate skill or responsibility, or machine automata resources or even other software programs. The meta-model includes four simple types of resources for the work-flow participant attribute. Workflow Process Definition Language grammar representation