C. Bussler et al. (Eds.): BPM 2005 Workshops, LNCS 3812, pp. 399–407, 2006. © Springer-Verlag Berlin Heidelberg 2006
and a Method
Antonella Longo and Gianmario Motta
Department of Innovation Engineering, Università di Lecce
Department of Industrial Engineering, Politecnico di Milano
Abstract. In this paper we present a model that defines performances of a busi-ness process. The process is conceived as a service chain that delivers services to customers by a glow that links a set of organizations. This concept implies a wider view of performance. The model includes all the performances that increase over-all competitiveness (i.e. classic cost and efficiency indicators are integrated by ef-fectiveness indicators, that measure service level and quality). Second, the model considers the different stakeholders involved in a process: management, custom-ers and operators. The model maps the performance indicators on these pcustom-erspec- perspec-tives. This multiple perspective can be used in benchmarking and diagnosis to evaluate an existing process or to design a new process.
1 Business Process as a Service Chain
We define a business process as a service chain, by which a network of organizations processes a service request, made by a customer, and delivers a product or service to the customer. This simple schema can depict a variety of real life cases, like buying a book from Amazon, processing a building permit in Government, responding to a customer order in a machinery vendor.
Actually, the concepts of business process, of flow of activities and process-oriented organizations are well-established in classic authors of business process engineering such as Hammer (5) and Davenport (2).
In the concept of “service chain” a process exists inasmuch it delivers a service to a customer. The importance of the service concept is testified by the common business practice. Actually, transportation authorities, government authorities, health authorities and utilities publish on their Web sites service statements that define the service promise to the customer. Moreover, many organizations, when outsource a service, set service level agreements, that define the service scope and service levels expected from the outsourcer. In a service-oriented environment, with the customer focus as a cornerstone (21), measuring service chains becomes a must. These “qualitative” and non-financial measures complement the financial measures necessary to management to control the efficiency, as it happens with Activity Based Costing (8). In short, service chains are increasingly important, and their measurement becomes important too. The performance of business processes is a quadrant of the Balanced Score Card (7) and it can be seen as a standard framework of performance measurement. Additionally service and quality
performance indicators are incorporated in a reference model of the supply chain (SCOR), a major research field in logistic management (1). In recent years the quest of process performance is boosting the success of continuous improvement methods, such as Six Sigma (4).
In short, the measurement of the business process should encompass financial, ser-vice and quality measures. This wide measurement framework can be used (i) to con-trol the performances of an existing process, thus defining the measures of its concon-trol panel, (ii) to benchmark the performances of a given process (iii) to set the design objectives of a new process. Here we focus on point (iii).
The objective of this paper is to define a set of performance measures that help the analyst to design good and sustainable business processes. In our view, a process design is good if it allows good performance on the whole range of performance measures. Further, the process design is sustainable if it allows good performance for the diverse actors who are involved in the process, who are regarded as process stake-holders. They include the management, who controls the process, the customer, who makes request and receives the output and the operators, who are people who actually work on the process.
In the following sections we present the key points of our model and method. In section 2 we present the key performance measures and map the performance indica-tors within the different stakeholders perspectives. Section 3 illustrates the method steps and relations between performance modeling and the design of business process. The major novelty is in section 2. The model and the method are illustrated by a case study in the e-government in section 3.
2 Identifying the Indicators and Relating Them with Stakeholders
Based on empiric experience we have defined a general framework to be specialized by the analyst when dealing with an individual process (Figure 1). The general framework reflects the process model as service chain we have introduced above and includes four major classes of indicators: overall, cost, quality, service and time.Overall indicators have the objective of describing the process context by quantify-ing the size of requests made by customers (i.e. input of the service process), outputs produced and resources used. Resources include both physical (human resources, equipment, inventory) and virtual resources such as information. These measures are relevant to benchmark or study the dynamics of the process (e.g. seasonality).
Cost indicators have the objective of measuring the economics of the process. Ac-tually, they measure the unit cost of input or output, the productivity of resources used by the process, and the usage of resources (i.e. the rate of used resource over available resources). The meaning of some measures changes dramatically depending on the stakeholder perspectives, as we show below in this paper.
Quality indicators have the objective of measuring the capacity of the process input or output of being consistent with the expected performance, and therefore include conformity measures, availability and customer satisfaction measures.
Finally, service indicators have the objective of measuring the performance against time in terms of response time, punctuality, perfect orders and flexibility. Most of these measures are clearly customer oriented.
Indicators
Indicators
Overall Cost Quality Service & time
Service request Product & service Resources Unit cost Productivity Usage Conformity Availability Customer satisfaction Response& lead time Punctuality Perfect orders Flexibility
Fig. 1. A tree of process performance measures
Fig. 2. A graphic overview of the stakeholder oriented performances
A process involves several stakeholders: the customer who receives the output, the manager who controls the process, the operator who works in the process. Each stakeholder views the process and would maximize the value from a different stand-point. The customer would minimize costs, maximize quality and squeeze times. The operator is motivated by a nice work environment, thus maximizing his own return from work. The manager would squeeze costs and maximize productivity and get the highest quality at the lowest cost.
Figure 2 summarizes the concept of the three perspectives. Each axis indicates a perspective and shows performance levels i.e. target, current, minimal. The target can be the performance expected by the stakeholder, a benchmark or an objective. The current value reflects the actual level in the existing process. The minimal value is the information on the minimal performance each stakeholder can allow and actually it is rather complicated to be calculated. The total percentage score within each perspec-tive is given by the sum of the percentage of each individual performance measure.
To calculate this nice graphic, the analyst should map the general performance measures on the different stakeholders’ perspectives. So we have crossed the indica-tors with stakeholders, obtaining the tree shown in Figure 3. The resulting list helps the analyst to identify the performances of an individual process.
Stakeholder Perspectives
Management Customer
Operator
Cost Service
& Time Quality Quality Service & Time Cost Service & Time Cost Quality
Quality Service &
Time
Cost
Fig. 3. Mapping generic indicators in stakeholder perspectives
3 Using the Performance Method
Some established process design methodologies, as of ARIS (19) consider different process views, that include activity flow, organization structure and information tech-nology. In general, process innovation (5, 20,12) affects almost the whole range of organization variables and, in turn, the organizational setting affects performances (just recall the case of the assembly line against assembly islands). Therefore, we can assume the process performance is driven by some key organizational variables.
In the as-is analysis, the analyst considers the qualitative relation between the situation of organizational variables and the performance; in the to-be design, the analyst evaluates, by tests or simulation, if innovation can eventually give expected performances. If not, the analyst can come back to the design and modify it or, conversely, to re-analyze performances. We have defined a simple questionnaire, that helps the analyst to spot critical points (e.g. to identify no-value-added activities that affects efficiency and increase service times) (16).
The performance driven approach, supported by a multiple stakeholder perspective, is an iterative, almost heuristic, method. It requires an approach that differs from others used to implement Enterprise Systems, which are based on “best practices” or adapt a pre-designed normative process model to the individual process. This ap-proach, largely used in ERP projects, gives very controversial results (14, 22).
The design of the actual process can also be oriented to the performance and to the stakeholder perspective. For example, UWA+ methodology (11) designs user experi-ence and data models that incorporate the informational objectives of different stake-holder communities (e.g. the design of use cases is based on stakestake-holders goals, that in turn arise from stakeholders expected performance measures). Requirements stem from goals and are implemented in the use-cases.
Hence the performance analysis and the stakeholder view goes all the way down from the high level strategic analysis to the design of software.
4 Case Study
The performance model has been tested. First the overall modelling methodology has been tested in laboratory case studies (i.e. written case studies) that included an insur-ance company, the service process of a lift company, the equipment mainteninsur-ance process of a transportation authority. Second, the models have been used on real-life cases, such a very large healthcare company and an e-government agency. In the last, only performance and information modelling have been used. Modelling has been proved easy to use and powerful. In the next section we discuss the case of e-government.
4.1 The Context
A Municipality manages the territory through a Planning Scheme, Technical Imple-mentation Rules and Building Rules. A Government Decree (D.P.R. 380/01 “Testo Unico per l’Edilizia”) has introduced the One Stop Counter of Building Services (SUE - Sportello Unico per l’Edilizia). The Counter provides a complete front-end to whoever wants to build or modify a building. The service chain begins with an appli-cation to the Department of Planning and Community Development. The process ends with the permit and the payment of permit fees.
The case study considers a small Municipality in the South of Italy (16.000 citi-zens). The organization includes Departments and Divisions with specialized tasks. The process delivers a service assigned to the Department in charge of Public Works Services and Town Planning Services. In the latter Services 5 employees are em-ployed, one Manager, and one technical expert as external contractor.
4.2 Goals and Indicators
Analysts have assessed the changes requested by new regulations that include the use of the Web for deploying services to citizens. From the management perspective, the introduction of Web has these goals: (a) To reduce the time of response from the Municipality, (b) Less errors in applications and related contentious and to provide citizens with a better interaction experience with Public Administration (e.g. reducing to zero the number of customers requesting information at the front end office), (c) keeping constant the number of clerks.
From the citizen/applicant ( = customer) perspective, the goals are (a) applying and receiving the building permit and (b), in case of refusal, getting clarifications.
The quantification of the performances (including processes and web applications) are made by indicators. Indicators are from both interviews and experiences. We observe indicators of quality can be extended with specific indexes of Web systems usability, which depends on the way the service is delivered (front-end desk, Web, kiosks, etc.).
Table 1, 2 and 3 present stakeholder indicators. Table 1 shows the process owner’s ones, in which we include all the managers.
Table 1. Key Performance Indicators (KPI) of the Management Perspective
Indicator classes Indicators Measures
Unit cost Headcount / applications (year)
Process Costs
Time usage Work time/ available time
Process Time and Service level
Process duration Duration (days)
Incorrect documentation Incorrect-missing applications / total applications
Re-working rate Applications reworked / complains
Process Quality
Rate of special cases Special cases/ applications
Table 2. Key Performance Indicators (KPI) of the Process Customer Perspective
Indicator classes Indicators Measures
Complaints # Complaints in a year Information on application
status
Provided/ Not provided
Contentious applications Number of contentious applications Bureaucratic language
sim-plification
Clearness in the presentation to a generic user
Information availability Time required to get updated about the application status
Easiness of finding informa-tion Qualitative scale Easiness of filling applications Qualitative scale Quality delivered to Customers
Easiness to find regulations corresponding to a case
Qualitative scale
Response Time Time from submission to issue (days) Punctuality Applications late/ Total applications
Time and Ser-vice to
Custom-ers Rate of worked requets Worked requests / total requests Customer Cost Product cost / fee (Euros)
Customer Time (Time for information on application) + (time for following the application status) + (time for receiving the service)
Information Access Cost Time spent in asking for information about application and service (in days) Cost of information on service (Euro)
Cost of Customer
Cost for the customer service use
Cost of use the service during the life cycle (Euro)
Table 2 shows the indicators of the customer. Please note that many indicators evaluate the performance of the customer independently from technology. As an ex-ample we show some indicators strictly linked to the Web application, and in particu-lar to usability indicators, that we have inserted in the Quality delivered to Customer category.
Table 3. Key Performance Indicators (KPI)of the Process Operators Perspective
Indicator classes Indicators Measures
Capability to prevent task errors Task error rate Capability to prevent syntactic
errors
Syntactic erro rate
Flexibility Capability to manage anomalies (not technical): present/ not present Quality delivered to
Operators
Integration Capability Capability to integrate different information
Rate of process steps supported by computer systems
Number of process steps supported by computer systems/ Total number of steps
Supports to Opera-tors
Rate of process steps replaced by computer systems
Number of process steps replaced by computer systems/ Total number of steps
Number of elementary operations to complete the task
Number of elementary operations to complete the task
Time for training on the procedure Measured in hours Information access time Seconds
Time to accomplish a task Measured in minutes Costs and time to
Operators
Information sharing cost Time for system data entry + time for system delivery output
Table 3 illustrates the indicators related to the Operator perspective. Even if in-cluded in the resources of the Building permit process, the Operator is a user of the IT systems. His or her major requirement is the capacity to have more efficient work and less prone to errors. As we can see the meaning of a same generic indicator (.e.g. cost) changes dramatically depending on the stakeholder, which could be the management (financial internal cost of executing the service chain), the operator (effort and time spent to accomplish a task) or the customer (cost of placing the service request, buy-ing the service and usbuy-ing the service).
The case study on e-government shows how standard indicators can be customized on a specific case, and how powerful is the potential diagnosis the tool enables. In fact, by giving a value to the current and expected values of performance measures and simply summing up the resulting percentage, the analyst can get a radar diagram, and, in this specific case, would probably realize that the performances are below expectations from all the three perspectives. By eliciting goals from KPIs the analyst will design a system that reflects perspectives and expected performances.
5 Conclusion and Future Work
In this paper we have illustrated the concepts of a process modeling, based on the red thread of the stakeholders perspectives. We have discussed the key idea of customiz-ing the performance accordcustomiz-ing to stakeholders perspectives and the reason why a good design should balance the different interests of the stakeholders, i.e. manage-ment, operators and customers. Also we have suggested how the stakeholder perspec-tives can eventually be used all the way down, from a nearly strategic assessment of
the process to the design of the Web system. The case study has shown how model-ling can be customized to evaluate an e-government service chain.
Our work is continuing. Our next objective is integrating process simulation. Actu-ally, there are a variety of self-contained simulators that allow simulating perform-ances in term of process duration and workload on process resources. The purpose of integration is to have a quick simulation of different performance alternative and process configuration. A second objective is to build a knowledge base on e-government and alike service processes wherefrom the analyst can directly pick process configurations and test them by simulation.
References
1. Bolstorff P., Rosenbaum R. Supply Chain Excellence: A Handbook for Dramatic Im-provement Using the SCOR Model, Amacom (2003) ; Davenport T.H., Short J.E. “The new industrial engineering: Information Technology and Business Process Redesign”, Sloan Management Review, vol. 31, n.1, 1990
2. Davenport T.H., Stoddard D.B., “Reengineering: business change of mythic proportions?”, Harvard Business Review, March-April 1994
3. Davenport, T.H., “Putting the enterprise into the enterprise system,” Harvard Business Re-view, vol. 76, no. 4, 1998, pp. 121-131
4. Gupta P., Six Sigma Business Scorecard, McGrawHill, New York , 2004
5. Hammer M., “Reengineering work: don’t automate, obliterate”, Harvard Business Review, July-August, 1990
6. Hammer M., “the Superefficient company” , Harvard Business Review, September/ Octo-ber 2001, pp. 82-91
7. Kaplan R. S., Norton D.P., Balanced Scorecard, Harvard Business School Press, Boston, Ma, 1996
8. Kaplan R. S., Norton D.P., Strategy Maps: Converting Intangible Assets into Tangible Outcomes , Harvard Business School Press, Boston, Ma, 2003
9. Klein M., Herman G.A., Lee J:, O’Donnel E:, Malone T.H., “Inventing new business process using a process repository”, in Malone T.H., Crowston K., Herman G.A. Organiz-ing Business Knowledge - the MIT process handbook, The MIT press, Cambridge Ma., 2003
10. Longo A., Bochicchio M., Carducci M.,: “Reducing Normative And Informative Asym-metries In Fiscal Management For Local Administrations”, in Digital Communities in a Networked Society: e-Commerce, e-Business and e-Government (ISBN 1-4020-7795-5), 2004
11. Longo A., Bochicchio M.,: UWA+: bridging Web systems design and business process modeling, HyperText 2004, Santa Cruz, August 2004
12. Markus M.L., Benjamin R.L., “The magic bullet theory of IT-enabled transformation”, Sloan Management Review, vol. 38, n.2, 1994
13. Mabert Vincent A., Soni Ashok, Venkatraman M.A., “Enterprise Resource Planning: common myths versus evolving reality”, Business Horizons, May-June, pp 69-75, 2001 14. Motwani J., Mircahandani D., Madan M., Gunasekaran A. “Successful implementation of
ERP projects: evidence from two case studies”, International Journal of Production Eco-nomics, 75, pp. 83-96, 2002
15. Motta G., “Il progetto dei sistemi infornativi direzionali” (= Design of Management Information Systems) in Bracchi G., Motta G., Progetto di sistemi informativi (= Design of Information Systems) , Etas Libri, Milano 1993
16. Motta G., Barbieri T., Francalanci C. , “Business information and process modelling: an integrated modelling platform”, Dipartimento di Elettronica e Informazione, Politecnico di Milano, internal report 2004.27
17. Motta G, “Il metodo dei KPI” (= the KPI method) in: Bracchi G., Francalanci C., Sistemi Informativi e impresa digitale (= Information Systems in the Digital Enterprise); McGrawHill, Milano 2005
18. Rigby D.K., Anderson S.R, “CRM done right”, Harvard Business Review, vol 82., n11, november (2004).
19. Scheer A. W., ARIS - Business Process Modelling, Springer, 2000
20. Scott-Morton M (ed.) The Corporation of the 1990s: Information Technology and Organ-isational Transformation, Oxford University Press, New York, 1991
21. Seybold P., Marshak, R.T., The Customer Revolution (2000)
22. Mabert Vincent A., Soni Ashok, Venkatraman M.A. (2001), Enterprise Resource Plan-ning: common myths versus evolving reality, Business Horizons, May-June, pp 69-75