Advantages and disadvantages of using predefined process models
Bjørn Andersen
Department of Production and Quality Engineering, Norwegian University of Science and Technology S.P. Andersensv. 5, N-7491 Trondheim, Norway E-mail: Bjorn.Andersen@ipk.ntnu.no

Tom Fagerhaug
SINTEF Industrial Management, Productivity and Project Management S.P. Andersensv. 5, N-7465 Trondheim, Norway E-mail: Tom.Fagerhaug@indman.sintef.no Abstract The purpose of this paper is to discuss advantages and disadvantages of using predefined process models in process orienting an organization. The paper has five main parts. First, process orientation of enterprises is described briefly. Then, a standard process model for IT service management is presented. Third, a case where this model has been implemented is discussed. Fourth, the experiences from the case are presented. Finally, the need for standard process models in other industries is discussed. Following the conclusion that indeed such standard models could be helpful in many industries, a process for developing such models is outlines along with some requirements for them. Keywords: Process orientation; business process modeling; the ITIL model

The concept of process orientation
The traditional way to organize enterprises and indeed all types of organizations is through the formation of departments consisting of individuals with the same or similar area of expertise. Up to a few years ago, this way of organizing was highly dominant. Organizing people and work in departments certainly provided, and still provides, some benefits: • People are allowed to specialize within their field of expertise, thus developing a highly refined set of skills. • Lower costs from centralizing various functions, e.g., finance, personnel, maintenance, etc. as a smaller number of specialists can service the needs of many other functional areas. • Such concentrated areas of specialists are usually quick to pick up the latest development within that field and bring it into the organization. • Secure workplace setting, everyone know where they belong, which tasks they are supposed to perform, and what the career patterns ahead look like. • Well-defined structure, the organization can easily be drawn and presented. Thus, we can safely claim that modern enterprises consist of functional departments, while at the same time they perform processes. Figure 1 depicts a typical enterprise with its vertical departments and horizontal processes that run through these (Andersen and Pettersen, 1996).

Departments/Functions
Purchasing Manufact. Engineering Dep. Dep. Dep. Finance Dep.

Inbound logistics

Processes

Order handling

Product development

Figure 1 The contradiction between vertical departments and horizontal processes The functional organization tradition has created a number of problems, which have formed the basis for the last years’ changes - from viewing the company as a number of departments to focusing on the business processes being performed. Several issues make this a logical transition: • Every process has a customer, and focusing on the process ensures better focus on the customer. • The value creation with regard to the end product takes place in horizontal processes. • By defining process boundaries and the customers and suppliers of the processes, better communication and well-understood requirements can be achieved. • By managing entire processes that run through many departments, rather than managing individual departments, the risk of suboptimization is reduced. • By appointing so-called process owners, who are responsible for the process, the traditional fragmentation of responsibility often seen in a functional organization is avoided. • Managing processes provides a better foundation for controlling time and resources. At this point, it is probably of use to define the term business process, consisting of the two components ”business” and “process”. First, a look at the element process. One basic definition of a process is: “… a logic series of related transactions that converts input to results or output.” To separate a company’s processes from any other form of processes, the word business has been added to form the term business process. A business process can be defined in a number of different ways, but we think the following definition is quite accurate (Ericsson, 1993): • • • • • A chain of logical connected, repetitive activities that utilizes the enterprise’s resources to refine an object (physical or mental) for the purpose of achieving specified and measurable results/products for internal or external customers.

Most organizations that have made an attempt at moving toward process orientation agree that it does indeed provide numerous benefits, including cost savings through a more efficient execution of work, improved customer focus, better integration across the organization, etc. This has recently been confirmed by a survey among one hundred international and US companies (McCormack, 2001) to determine any relationship between Business Process Orientation (BPO) and the factors of: • • • business performance. interfunctional conflicts. interdepartmental connectedness.

•

esprit de corps (team spirit).

The survey was based on a 32-question questionnaire distributed among 500 organizations, and then analyzed using correlation analysis and regression analysis. The analysis results are shown in Figure 3, and the main findings summarized as follows: • Companies with strong measures of BPO showed better overall business performance. This, of course, is what every BPO practitioner would have hoped, but we believe that this is the first time the link has been demonstrated empirically. • Companies with strong measures of BPO tended to have better esprit de corps, better connectedness, and less interfunctional conflict. Companies structured into broad process teams rather than narrow functional departments should have less internal conflict and stronger team spirit. • Process management and measurement and process jobs had strong relationships to the organizational variables, but process view did not. We interpret this to mean that documentation, or process view, alone doesn't have a major impact. Documentation just provides a foundation that can be used to organize jobs and measures.

Figure 2 Analysis results of process orientation benefits To embark on a journey toward process orientation, a prerequisite is that the business processes of the enterprise can be identified. This can at times be rather difficult, as it rarely is obvious which processes are undertaken by the different departments in a functionally organized organization. Traditionally, two complementary routes to such an understanding have been utilized (Peppard, 1998). The most direct way is to simply generate a list of the business processes believed to be encompassed by the organization. Such a job will often be based on existing process descriptions or procedures written for ISO-9000 certification or similar purposes. A more rewarding and systematic route is to map the following sequence of elements (which is also illustrated in Figure 3): • The strategy of the organization, which defines and is shaped by: • Stakeholders, i.e., organizations, institutions, or persons affected by or with a vested interest in the organization and its business processes, who hold: • Expectations with regard to products or services delivered by the organization through: • The business processes that produce these products or services and support and enable the production of them.

Strategy shape defines delivers encapsulated in

Stakeholders hold satisfy

Processes deliver consolidate

Expectations
Figure 3 Business process identification By going through this set of elements and identifying them in sequence, it is usually easier to point to the business processes carried out by the organization and that are necessary in fulfilling the expectations of its stakeholders. However, even if this approach, which is a clear improvement compared with the near impossible task of simply listing all business processes of the organization, has emerged, there is no doubt that a process orientation project is a difficult and large undertaking. The authors have worked with a number of companies in projects of this kind, and they all have in common that they end up being lengthy processes, they require a lot of work, and some even give up before they see the project through to completion. In our experience, one of the main stumbling blocks is the initial job of defining which business processes the organization currently undertakes, which processes it will need in the future, and how these are linked to each other in a web of multitudes of connection points. Recently, we were involved in a project where this phase was executed in a different fashion, by building extensively on the so-called ITIL model, which is presented in the next section.

The ITIL model
As far as we know, very few industries have something close to worldwide-accepted business process models. A major exception for this statement is the IT industry, for which the IT Infrastructure Library (ITIL) has become almost a standard. ITIL is a set of comprehensive, consistent, and coherent codes of best practice for IT service management. It consists of over forty books developed by the Central Computer and Telecommunications Agency (CCTA) and its partners (IT Service Management Forum, 2001). From its beginnings in the UK and Europe, the ITIL has rapidly become a world standard for measuring and improving standards of IT service delivery (Proactive, 2001). Used by many hundreds of organizations around the world, a whole ITIL philosophy has grown up around the guidance contained within the ITIL books. The objective of the CCTA was to promote business effectiveness in the use of information systems. With the ever-increasing demand for organizations to reduce costs while maintaining IT services, a need for a set of standards was demonstrated. Thus the ITIL concepts of best practices for IT services were developed in collaboration with leading industry experts, consultants, and practitioners. Since the ITIL model itself is proprietary and not made generally accessible to the public, we can unfortunately not show the model in this paper. The model is of course available in numerous publications on ITIL, but the general model has not been released for reprint by others. However, the model consists of a graphical depiction of a set of the most common business processes to be found in different types of IT companies. It also contains descriptions of varying detail of “best practice” for each of these processes. As such, it represents a business process library that can help organizations in the initial phases of a process orientation project to identify which processes it should put in place. This is exactly how the ITIL model was utilized in the case project we describe in the next section.

Using the ITIL model in an IT infrastructure management enterprise
The case project took place in the internal IT infrastructure management enterprise of a large multinational telecom corporation. This is an independent company, wholly owned by the corporation, but run as a business unit with regular requirements for profitability. It employs approximately 300 people, and is scattered throughout about ten locations in the country. Early in 2000, after having experienced a poor 1999 in terms of financial performance, the company initiated a project to identify, highlight, and implement a set of key business processes, train all employees in these processes, and start working along them - in short to process orient the organization. The main reasons for starting this project were cited as a need to focus its processes and enhance its performance in customer issues. Another rationale was to improve the bottom line as a result of the process improvement. External assistance was engaged in the project, among others people with knowledge and experience from the ITIL model, something the authors did not have. It was soon decided to base the work on the ITIL model, something that had not been clear from the start, and the project was planned with close to a oneyear duration, ending just before Christmas of 2000. The project was designed to involve large portions of the organization’s employees, both in the task of designing the detailed processes and through extensive training in the model and its elements. At an overview level, the main activities of the project were: • Designing the overall business process model. Although the work would be based on the ITIL model, there was a need for some modifications of this model. Especially since the ITIL model has been designed with an internal IT department of a larger organization in mind, some of the more general management and market activities are not included and needed to be added. In the end, the complete model ended up with twenty-four processes, in this case termed PDs. • Training, both in the ITIL model and the detailed business processes. Initially, the training was focused on the rationale behind process orientation and the ITIL model in general. As the organization’s own detailed business processes started to emerge, the focus was shifted to training in these with the aim of achieving a sufficient level of insight to implement the processes and start working according to them. • Process definition of each of the business processes. After completing the overall business model, for all of the twenty-four processes in parallel, a coarse process map was designed depicting the main activities within the process and its interfaces to the others. • Process documentation, a much more detailed effort for each process to draw precise flow charts of every process and possible sub-processes within it. This activity also included producing required templates, forms, or other documents to be used in the execution of them. • IT support systems, a sub-project to develop or acquire the necessary IT systems and tools to run the new business processes, e.g., service desk management software, data warehouse, and the likes. • Implementation, focusing on staffing the different processes, test runs to eliminate problems and errors, and eventually “pushing the button” to start working according to the new processes and discarding the old procedures, which were documented in old quality assurance manuals. • Management system, a collection of some miscellaneous activities such as designing performance measurement routines and indicators, a more overall business excellence model, inspired by the EFQM model, etc. The overall business process model that was designed in the project is shown in Figure 4.

System Owner Authorized Purchaser

User

Helpdesk

Inf rastructure

Customer

Market

PD17 PD02

Market Development

PD20

Service Delivery Reporting
PD18

PD01

Order Reception and Processing

User Contact and Complaints Handling

Customer Comm. and Sales
PD16

Operations

PD05

PD19

Service Follow-Up and Reporting
PD03 PD21

Problem Solving

Agreement Design
PD04

Configuration Management and Control

Portfolio Planning and Service Design

PD22 PD15

Change Management and Control

Transfer to Production

PD12

PD06

Service Supplier Monitoring

Infrastructure Planning, Evaluation, and Design

PD14

Testing

PD13 PD07 PD10

Requirements Analy sis Resources and Competence
PD08 PD11

Planning and FollowUp of Availability and Capacity
PD09

Development

Follow-Up of Service Pricing and Incom e

Crisis Prevention and Management

IT Security Planning and Follow-Up

Support Processes

Service Supplier

Application Supplier

Figure 4 The overall business process model based on the ITIL model

All in all, this turned out to be a rather large and complex project, involving close to all of the 300+ employees in some way or another, as well as perhaps ten external facilitators of different areas of expertise. From previous projects of process orientation that we have worked in, our first guess of a logical project duration for this project would be two years. In fact, we have seen many cases where organizations smaller than this one have easily spent two years trying to process orient the organization in a less extensive fashion than this and still have not managed to complete the project. This one aimed for a completely new environment consisting of a totally new set of processes, and throwing out all of the old routines. After some discussion about the overall project plan, the decision was as already mentioned to make this a oneyear project. We felt this to be an extremely ambitious plan, quite certain it would have to fail. To be honest, it did not quite reach its target. When we broke for Christmas last year, only about 95% of the project had been completed. January of this year had to be included in the project before the new process model was fully launched February 1st, almost exactly one year after the project commenced!

Case analysis
We realize that the case description presented in the previous section is very brief and only scratches the surface of the impressive effort that was put into the project. Thus, it might be difficult for you as an outsider to the case to see what we think are important lessons learned, lessons that we also think carry more general consequences. In our view, the most important findings from the case were: • First of all, the use of a predefined process model like the ITIL model in this case reduced the time needed for process orienting the organization significantly. There is no reliable way of estimating how much time and work was saved by starting the project from the ITIL model. A considerable amount of know-how can be found in the model and the guidelines complementing it, know-how that can be put directly to use and which makes it less likely you will reinvent the wheel by making the same mistakes as numerous projects before you. Comparing this project with similar ones we have also participated in or observed closely, however, we would hazard a guess of six to twelve months and several hundred hours of work. In a time where fast is the ethos and projects are sanctioned mainly based on how quickly they can deliver results, this is an important issue. We have seen enough examples of perfectly sound improvement projects not approved by the decision makers because of too long payback times. This is the key impression we are left with after this project, something we did not anticipate before the project, as we normally are skeptical toward attempts at uniforming businesses whose environments are never identical. • However, we have also seen that the employees can be proned to view the ITIL process model as strange and hard to comprehend at first. It certainly took some time to make people buy into the model and start using the terminology it is based on. The “not invented here” syndrome was certainly in place in the beginning, but it was interesting to see how the attitudes slowly started to change throughout the organization. Gradually, people starting referring to PD this and PD that when talking about other departments, and within two to three months the model had been truly “sold”. • Third, ITIL can easily be regarded as a complex and rigid model. It prescribes a set of processes in quite some detail, processes that are linked through a complex mesh of interfaces and connections. Making individual adjustments to this model requires considerable insight into both the ITIL model and the organization in question. Luckily, two of the external consultants knew the ITIL model in great detail and could guide the company through the process of adapting the model to the rather special situation of being an independent business unit with many functions outside the scope of the ITIL model. • Fourth, the industry specific knowledge that is incorporated into such a model as ITIL gives the users a thorough knowledge of how standard processes in the industry could and should be performed. This way, the model might be viewed as some sort of an industry benchmark that has been refined over the years and through the collective effort of literally thousands of companies. As such, a model

like ITIL constitutes an intravenous, massive injection of a large doze of accumulated wisdom on how to structure and run the business process required to meet the specific challenges of the industry. • Finally, the combination of the ITIL model with an overall business framework was successful. In the case organization, many employees were questioning the process model’s place in the overall improvement framework and its relationship with other management entities in the enterprise. As an answer to this problem, a Business Excellence Model (BEM) was introduced. The BEM was based on the Business Excellence Model from the European Foundation for Quality Management (EFQM, 2001), but it was restructured to fit the enterprise. The BEM then provided an overall framework for the process model, and it depicted the structure of the different elements in the organization. This helped place the business processes in a larger context, not in the least how they were linked to the goals of the organization, both financial and otherwise. In summary, let us again reiterate our initial position of skepticism toward both the ITIL and other mechanisms for standardizing businesses that in all fairness never are the same. We have often reflected that the large ERP systems have the same effect, i.e., that they prescribe one, universally best way of executing different tasks in an enterprise, irrespective of singular characteristics of the enterprise, the industry it is in, or regional aspects. Such universal best practices are in our view more geared toward stifling innovation and the everlasting quest for improvements and new ways of doing things. Thus, it was surprising to see how well such a standard process model worked in this case. We believe some of the answer lies in the fact that it is indeed industry-specific, not claiming that all organizations should look the same, and the next logical question to us therefore is:

Is there a need for other predefined process models?
Based on our involvement in this case project and the subsequent brief analysis of it, we are strongly inclined to conclude yes. Need is perhaps a strong word, but we truly believe other industries could benefit from having similar models developed. A number of benefits can be provided through the existence of such models, but we would like to emphasize two in particular: • Perhaps the most obvious one is the effect we saw in the case project, namely how the ITIL model helped accelerate many aspects of the process orientation project by providing a starting point for designing the overall process model of the organization. Compared with more generic enterprise models or framework, for example the EFQM model, such an industry-specific model is able to go into more detail in terms of specific processes, the logical flow between them, their structure, etc. In some cases, this starting point might need significant alterations, in other it can possibly be used almost as it is – anyway it does aid the project in its initial and most insecure phase. • To the extent that such standard industry-specific models emerge as the result of discussions among a large number of enterprises within that industry, as indeed is the case with the ITIL model, it can be construed as some kind of a benchmark. It will reflect the most common business processes within the industry and how a large number of organizations have agreed they should logically be structured. Thus, building on the model, an enterprise about to restructure its organization based on business processes can achieve a massive learning effect from studying the model. At the same time, we fully realize that such standard process models are not only brilliant examples of simplifying standardization. There are quite a few problems attached to the use of such models, some of which were also clearly demonstrated in our case project. The most prominent are probably: • In the case of the ITIL model, the generic model is already quite complex, and it does not come with any indications of which processes are more important than others or discern between critical and “nice-to-have” flows of services or information. As such, it might be difficult for inexperienced users to decide which parts to focus on, especially since it rarely is feasible to include every aspect of the model. • It can be difficult to strike a suitable balance when designing such models between the desire to include a largest possible number of relevant processes and the need to keep the model relatively simple. We could argue that the ITIL model to some extent is so complex that it is not very

accessible for novices in the field, thus normally requiring the use of external assistance with a deeper knowledge of the model. This also makes it more likely that the large majority of the organization will find it difficult to follow the discussions about how the model should be altered to fit this specific case, thus endangering the involvement and sense of ownership for the project. • Even though we have concluded that the advantages of such standard models seem to outweigh the disadvantages, we cannot suppress the fact that we still have our reservations about the way these models can stifle the innovation level of the organization. This mechanism normally shows itself in that the organization buys into the standard processes prescribed by the model, especially since they to some extent represent industry best practices, and stick to them, and often stop or at least reduce their efforts to come up with new and more innovative ways of doing things. • After having gone through a large job of process orienting an organization based on a standard process model, it can be a tough decision to make changes to the processes. We saw in the case project how it gradually developed a large amount of documentation at different levels, from the overall process model through process definition documents, flow charts, work description, interface documents, templates to job descriptions and the likes. In our case project, they even went so far as to develop a web-based model of the process organization, navigable through all these documents. It goes without saying that even if someone thinks a revision of parts of this material is due, it is easy to argue that it can wait, since it will involve so much work. As such, a comprehensive model of this type can make the organization more static than it should be. Again, based on these advantages and disadvantages of standard industry-specific process models, we conclude that it can indeed be useful to develop more of these, along the lines of the ITIL model. The final contribution of this paper is a very coarse outline of how such a model can be developed and what it should contain. We have recently written a forthcoming book on the topic of performance measurement system design (Andersen and Fagerhaug, 2001), structured around an eight-step process for such a design task. In developing this paper, we realized that parts of this process could very well be used a starting point for a process for designing a standard process model. Slightly adapted, the following seem to be the vital steps if you should set out to create such a process model for your industry: 1. Business structure understanding and mapping, the first introductory step of the process, whose main purpose is to ensure that you think through the structure of the industry and its enterprises. Some important activities of this step are to develop an overall enterprise model of a typical company within the industry and the environment it exists in, map the most common stakeholders, and their needs and expectations toward such a typical company. Stakeholder analysis is a not very formalized exercise forcing you to systematically identify and understand the actors in the organization’s environment that have a vested interest in the organization and its well-being, typically its customers, suppliers, competitors, partners, authorities, etc. This step culminates in a mapping of the stakeholders’ expectations and requirements to the products or services delivered by the organization. A simple stakeholder model is included in Figure 5. 2. Identify the main business processes, whose outcome should be a more or less complete set of the most important business processes in such a typical company. The two main sources for identifying these processes are first of all the stakeholders’ requirements. For every one of them, is should be ensured that the business process set contains the processes required to fulfill it, as that is the main goal of the organization. The other source is insight into what processes companies in this industry typically do run currently. In the end, the final set of business processes must contain those processes needed to satisfy the mapped stakeholder requirements representing the overall needs that the organization must fulfill. 3. Design the process model itself, from which the outcome should be a graphical model of the business process set developed in the previous step. This model should depict the processes in some logical way, either arranged by topic, flow of activities, or some other order, and also illustrate how the different processes interact and deliver input to each other. There are probably a dozen different ways of constructing such a model, all with their inherent strengths and weaknesses, so we will not venture any recommendation to this question. However, the one developed in the case project illustrates one approach.

Authorities

Owners

Management

Suppliers Financial institutions Employees Environment

Customers

Competitors

Alliance partners

Figure 5 A simple stakeholder model In terms of requirements for such a standard process model, some main issues to keep in mind are: • The model must be sufficiently generic to cover a major portion of the enterprises active within the industry in question, otherwise it will either be of little use or there is a need for several models covering separate segments of the industry. • Although such a model should strive to inform the industry about best practice, it must not represent the leading edge so far ahead of the average company that it will require much more of an enterprise development job than a process orientation project to put it to use, e.g., in terms of technology development, investments in equipment or other resources, etc. • It must strike a balance between sufficient complexity to convey the business process structure in enough detail to be useful and sufficient simplicity to be understood by the broad masses of the enterprises and thus be accepted and used. Personally, we have been involved in research projects developing quite generic process models for the manufacturing sector (for example the IST projects ENAPS and APM), but those models seem to be too generic to be of much use. That has led us to the opinion that “manufacturing” or “service” are too broad categories, we believe the suitable unit of analysis is a more detailed industry classification, e.g., the NACE classification scheme. This scheme breaks manufacturing down into a number of more detailed industry segments, with their particular sets of stakeholders and processes. The same goes for the service sector, and the public sector is probably a third main group. We will probably try to follow the initiative of the forces behind the ITIL model and strive for similar models for some selected industries, most likely through European initiatives. However, if the majority of industries are to have the same advantage as the IT industry in this respect, they are dependent on the adequate organizations within these industries to take an initiative. Such organizations will typically be industry associations, public or state authorities, the European Commission, etc., as all of these organizations with a potential for establishing standards. We hope this paper can inspire some such initiatives! References Andersen Bjørn and Pettersen, Per-Gaute (1996): The Benchmarking Handbook - Step-by-Step Instructions, Chapman & Hall, London, England. Andersen, Bjørn (1999): Business Process Improvement Handbook, ASQ Quality Press, Milwaukee, USA. Andersen, Bjørn and Fagerhaug, Tom (to be published 2001): Designing and Implementing Your State-ofthe-art Performance Measurement System, ASQ Quality Press, Milwaukee, USA. Ericsson Quality Institute (1993): Business Process Management, Gothenburg, Sweden. EFQM (2001) The Homepage of the European Foundation for Quality Management, http://www.efqm.org/ IT Service Management Forum (2001); What is ITIL, http://www.itsmf.com/page26.html

McCormack, Kevin (2001): Business Process Orientation: Do You Have It?, Quality Progress, January 2001, USA. Peppard, Joe (1998) Benchmarking Business Process: A Framework and Classification Scheme, Proceedings of the symposium Distributed Enterprise, Intelligent Automation, and Industrial Benchmarking, Wroclaw, Poland. ProActive (2001): The IT Infrastructure Library, http://www.proactive-sv.com.au/public.htm ITIL Online (2001): The Official ITIL Website, http://www.itil.co.uk