Business Process Frameworks

Abstract

In Business Process Management (BPM) research as well as in practice, a whole host of different Business Process Frameworks supporting various tasks connected with BPM in organizations have been introduced and further developed. However, the term Business Process Framework is ambiguous and has been used for different BPM-related systemization approaches concerning BPM methods and techniques. Against the background that so far no attempt to systemize the different meanings and understandings of the term Business Process Framework is known, this article aims at clarifying this term by analyzing and systemizing its different facets giving an overview of available understandings and usages of the term. The identified facets are investigated and several different classes of Business Process Frameworks are described and explained in more detail. In this context, one predominant class of Business Process Frameworks summarizing business process reference models is presented in more detail.

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

1 Introduction

Business Process Management (BPM) gains more and more importance for practice and an increasing number of organizations use BPM methods and techniques in order to support their operations (Fettke 2009). This makes BPM a highly relevant object of study and development for researchers and practitioners who strive for designing new and innovative BPM approaches and, furthermore, investigate their effects in real world application. In this context, BPM research and practice has created a whole host of so called Business Process Frameworks supporting different tasks connected with BPM in organizations. However, the term Business Process Framework is ambiguous and has been used to denominate different BPM-related systemization approaches, BPM methods and techniques etc. The term has not been consistently defined and various understandings can be identified in literature until now. This word sense ambiguity has already been mentioned before, e.g. by Harmon (2014) and process frameworks have been identified an important element of strategic alignment in BPM (Rosemann and vom Brocke 2014). However, so far no attempt to systemize the different meanings and understandings of the term Business Process Framework is currently known and so the term has remained ambiguous.

Against this background, this article aims at further clarifying the term Business Process Framework by means of an investigation and systemization of its different facets and an overview of a selection of different understandings and usages of this term in literature shall be given. Another goal of this article is to clarify the various facets of the term Business Process Framework and the different classes of Business Process Frameworks by means of a more detailed description and explanation of several Business Process Framework instances.

In order to reach the goal of further clarifying the term Business Process Framework, a review and investigation of selected articles referring to Business Process Frameworks is our research approach. We report on different usages and understandings of the term Business Process Framework in literature and systemize different identifiable instances into consistent classes of Business Process Frameworks.

This article is structured as follows: after this introduction, the second section analyses the ambiguity of the term Business Process Framework in more detail based on an investigation of frameworks in the context of BPM research and the clarification of different possible facets of the term business process as well as the term framework. A classification of identified understandings of the term Business Process Framework is given. In Sect. 3, each of the different Business Process Framework classes are described in more detail and explained by means of according framework instances. In this context, we especially focus on some Business Process Framework instances in the sense of business process reference models and also report on empirical insights concerning real world effects of using reference models in practice. Section 4, discusses the findings of our investigation before the article is summarized and concluded in Sect. 5.

2 Business Process Frameworks: An Ambiguous Term

2.1 Frameworks in Business Process Management Research

Frameworks in general are highly relevant in the context of Information Systems (IS) research as they commonly provide a systemization or overview of relevant objects or phenomena in a certain domain of interest. The general term framework has, furthermore, quite often been used in the context of BPM research addressing a whole host of different aspects of BPM, e.g. Rosemann and vom Brocke (2014) develop a framework for the description of Six Core Elements of BPM which supports structuring BPM as a holistic approach; Tregear (2014) introduces a Global BPM framework for process standardization supporting BPM in globalized organizations; Bhat et al. (2014) differentiate several classes of Business Process Management Frameworks, e.g. maturity models with according assessment tools as well as BPM lifecycle methodologies (pp. 333f.) and use a specific Business Process Management Adoption Framework in order to investigate Business Process Outsourcing effects. In summary, frameworks play an important role in BPM research and the term Business Process Management Framework has been used for the description of many different aspects of BPM.

This plurality of meaning can also be observed for the term Business Process Framework. In literature, the term Business Process Framework is used very differently, e.g. Harmon (2014) mentions this ambiguity but predominantly understands Business Process Frameworks as reference process models or organizational best practices like the IT Infrastructure Library (ITIL) or the Enhanced Telecom Operations Map (eTOM), while Scheer (1998) uses the term Business Process Frameworks in the sense of methodical engineering approaches for business processes and process-oriented IS addressing technical infrastructure, organizational aspects as well as existing business objects. Table 1 gives an exemplary overview of different usages and understandings of the term Business Process Framework in literature.

Table 1 Different usages of the term Business Process Framework

This exemplary enumeration of different usages of the term Business Process Framework illustrates the mentioned term ambiguity in literature. We assume that this ambiguity is related to two different aspects: the ambiguity of the term business process as well as the ambiguity of the term framework.

2.2 Term Clarification “Business Process”

According to the Cambridge Dictionary¹ a process in general is “a series of actions that you take in order to achieve a result”. The term business process can accordingly be understood as a sequence of actions carried out in a business context for the creation of goods and services. In common speaking as well as in literature the term business process can occur in different contexts. For the clarification of its meaning it is important to ask, whether (a) a business process in the real world or in the model world is addressed and, furthermore, (b) if we are talking about a business process instance or a business process schema. The influence of these two dimensions will be explained in more detail in the following.

As already mentioned, the term business process can address both sequences of executions which can be observed in the real world and sequences of intended executions documented in the form of a process model (model world). A clear differentiation between the term business process related to the real world on the one hand and related to the model world on the other hand seems highly important as this term indeed has different meanings depending on the context. As far as the model world is concerned, a business process can be represented in different ways and using different types of methods and techniques (Desel and Juhás 2001). In literature, a common classification differentiates (I.) informal, (II.) semi-formal and (III.) formal representations of business processes. However, there are also different opinions in literature concerning how these classes of representations can be distinguished in detail and what the exact criteria for this differentiation are.

The mentioned (I.) informal representations are typically considered to comprise business process description in free prose (Markovic 2010), e.g. a transcript of an interview with an employee concerning the sequences of executions commonly performed at her workplace for the documentation of as-is processes.

As natural language can be ambiguous and is likely to be interpreted differently, there have been several initiatives towards the development of formalized business process representations. A first step towards a more formal and standardized representation of business processes has been the introduction and usage of graphical elements and symbols with a standardized meaning in graphical business process models. This resulted in methods and techniques which support – besides several other tasks – the development of technical drawings of processes, e.g. Event-driven Process Chains (EPCs), the Business Process Model and Notation (BPMN) or UML Activity diagrams. In literature, such representations are often considered to be (II.) semi-formal. One important purpose of these modeling techniques is the graphical representation of business processes.

However, in the meanwhile several of these business process representation techniques have been further developed and stronger formalizations have been proposed in order to have a (III.) formal representation of business process models, e.g. for EPCs by van der Aalst (1999) or Nüttgens and Rump (2002). In this context, two different types of formalizations can be distinguished: (a) formal representations by means of mathematical expressions and structures based on set theory or first-order logic, and (b) formal representations by means of a formal language in the sense of the field of theoretical computer science. A formal language in the sense of theoretical computer science is a finite set of strings of symbols (Davis et al. 1994). In this context, formal languages can support several different purposes: (1) the provision of a machine-readable representation of a process model in order to make them interchangeable, e.g. the Event-driven Process Chain Markup Language (EPML) or the ARIS markup language (AML) for EPC models, and (2) the provision of a machine-readable representation of a process model in order to make them executable by means of a process engine (execution semantics).

Furthermore, as already mentioned above the exact meaning of the term business process also depends on the differentiation between process instances (tokens) or process schemata (types). This results in the following classes of business processes (represented in Fig. 1):

• 1. According to the above definition of a business process, a business process instance in the real world describes a unique and singularly happening sequence of executions in a business context, e.g. production process #1111 concerning article #2222 performed on the 1th of July 2013 in the Example Company’s plant #15. Its existence is actually independent of the existence of a process model or an information system.

• 2. A business process schema in the real world is the common schema of execution steps which all the production processes in an organization typically follow, e.g. concerning the article #2222 produced by the Example Company. This schema does not necessarily have to be documented by means of a process model and is actually also independent of an IS.

• 3. A business process instance in the model world is the unique graphical or informal representation (e.g. EPC diagram or a textual description printed on one particular sheet of paper), or a formal representation (EPML code running on one particular computer) of a sequence of executions in a business context. The latter example typically represents a process instance in the real world, e.g. a currently running workflow instance. However, as already mentioned above, a process model can exist independently of a business process in the real world and vice versa.

• 4. A business process schema in the model world is a graphical (e.g. EPC diagram), a formal (e.g. EPML code) or an informal (e.g. prose) representation of a documented, intended or suggested sequence of executions, e.g. a business process model which is contained in the SAP reference model.

Fig. 1

Different meanings of the term business process

In conclusion, it can be stated that the term business process can have several different meanings. Thus, the underlying understanding of business process is likely to influence intended meanings of the term Business Process Framework, which will also be indicated in the following sections in more detail.

2.3 Term Clarification “Framework”

As already mentioned, the development of frameworks plays an important role in IS research. However, the term framework is generally used in many different senses in IS research and, as has been shown, especially in the context of BPM research. This is probably also related to the fact that the general English term framework has several different meanings. Besides other meanings which are probably less important for IS research, e.g. the parts of a building or an object that support its weight and give it shape, framework – according to the Cambridge Dictionary² as well as the Oxford Advanced Learner’s Dictionary³ – can have the following meanings:

• 1. a set of beliefs, ideas or rules that is used as the basis for making judgements, decisions, etc. and

• 2. the structure of a particular system.

Both interpretations are valid for BPM research compared to the different usages and understandings of the term Business Process Framework which we have seen in Table 1. This will also be shown in more detail after the introduction of our classification of the usages and understandings of the term Business Process Framework in literature by means of a mapping of these two meanings of the term framework onto our Business Process Framework classes in the following section.

2.4 A Classification of Business Process Frameworks

As we have already seen, several different classes of Business Process Frameworks can be identified in literature. During our investigation, we discovered that in some of the contributions the term Business Process Framework has been used as a shorter form for unique and specific frameworks in the context of BPM like the Business Process Knowledge Framework by Hrastnik et al. (2007) or the Business Process Framework in the sense of a set of assumptions, concepts, values, and practices for BPM by Karagiannis and Woitsch (2014). Moreover, we found characteristic usages and understandings of the term Business Process Framework which can be identified significantly more often than others in literature. In the following, these serve as our Business Process Framework classes. Figure 2 summarizes these characteristic classes.

Fig. 2

An overview of different types of Business Process Frameworks

The first major class of Business Process Frameworks in our classification subsumes methodical business process engineering approaches, e.g. the Architecture of Integrated Information Systems (ARIS) (Scheer 1998), the Zachman Framework (Zachman 1987), the Computer Integrated Manufacturing Open System Architecture (CIMOSA) (AMICE 1993) etc. Such engineering approaches support the development of process-oriented IS, the definition of process models and not only propose the structure of such IS but sometimes also provide according procedure models and according software implementations supporting BPM in practice. For such Business Process Frameworks the second meaning of the general term framework given above (structure of a system) is relevant in the first place as these business process engineering approaches basically provide systemizations of underlying structures of process-oriented IS. However, they also provide certain beliefs, ideas and rules for taking decisions for the design of such systems. Thus, also the second given meaning of frameworks applies for this Business Process Frameworks class.

The second Business Process Frameworks class summarizes technical infrastructures for process integration and for the interchange of business process models, e.g. XML-based approaches like the XML Process Definition Language (XPDL) or the ebXML Business Process (ebBP) OASIS standard. These technical infrastructures provide the basis for formal representations of business process models (model world) and the execution of singular process instances in the real world by means of workflow systems. Concerning this Business Process Frameworks class, the second meaning of framework which is related to structural aspects of a system is relevant.

The third major class which also represents the most common understanding of the term Business Process Framework summarizes so called business process reference models which are often representations of best practice processes, e.g. the Supply Chain Operations Reference Model (SCOR), the Information Technology Infrastructure Library (ITIL) or the Control Objectives for Information and Related Technology (COBIT). Reference models are process descriptions (model world) which can provide the basis for real world process instances. Looking at the interpretation of Business Process Frameworks in the sense of reference models, both of the above meanings of the term framework are relevant. Reference models are often interpreted as prescriptions of how a real world business processes could or should be conducted. They contain certain believes and ideas aiming at the improvement of a process-oriented organization. Furthermore, the structural aspects of reference process models are especially important as business process models represent a structure of work in an organizational system or sub-system.

In the following section, these different classes of Business Process Frameworks and selected instances of Business Process Frameworks are presented in more detail. We first introduce exemplary Business Process Frameworks in the sense of business process engineering approaches, then some exemplary technical infrastructures for process integration and process model interchange before we put a stronger focus on established business process reference models.

3 Description of Exemplary Business Process Frameworks

3.1 Methodical Business Process Engineering Approaches

A whole host of methodical engineering approaches for process-oriented IS have been presented in literature. Furthermore, several according software prototypes exist. Therefore, we can only introduce a selection of Business Process Frameworks in this sense in the following. However, these frameworks have in common that they typically provide a systemization of domain-independent approaches, methods and techniques for the development of process-oriented IS considering different views and perspectives on involved systems and business processes.

The Architecture of Integrated Information Systems (ARIS) is a comprehensive methodical framework for the design of process-oriented IS. It provides a holistic view on business processes comprising the organizational view, the data view, the function view, the output view and the control view (Scheer 1998). In addition, the ARIS phase model defines several consecutive development phases (requirements definition, IS concept and implementation description) which are relevant for each view and, furthermore, necessary for a structured development of integrated IS. Besides offering an architecture for process-oriented IS, the ARIS concept provides the basis for several concrete modeling methods and techniques as well as software implementations for business process modeling. The ARIS platform offers comprehensive functionality in the context of BPM in general, e.g. the development of the business process strategy, business process implementation, business process monitoring or business process controlling.⁴

The Zachman Framework was initially developed in the late 1980s as a domain-independent approach providing guidelines and a systemization of roles and perspectives as well as and their specific requirements which should be considered during the development of IS (Zachman 1987). Based on the insight that the size and complexity of IS implementations as well as enterprises in general keep increasing and, furthermore, that individual perspectives on a complex system matter (“Architecture is relative. What you think architecture is depends on what you are doing”, Zachman 1987, p. 291) this systemization of relevant roles (planer, owner, designer, builder, programmer and user, p. 284ff.) and perspectives (data, function, network, people, time and motivation) for individual IS development has been proposed as a two-dimensional framework and further developed into a comprehensive multi-dimensional Enterprise Architecture Framework.⁵

The Computer Integrated Manufacturing Open System Architecture (CIMOSA) has been developed in the early 1990s (AMICE 1993). Although the underlying research projects of this initiative focussed on the development of an open system architecture for CIM, the CIMOSA can support enterprise modeling in general and has some similarities compared with ARIS (Scheer 1998). The CIMOSA architecture (the CIMOSA cube) is represented by three dimensions: the “stepwise generation” dimension (function view, information view, resource view and organization view) which is comparable to the views in ARIS, “stepwise derivation” (requirements definition, design specification, implementation description) which is comparable to the ARIS phase concept and “stepwise instantiation” which describes the necessary individualization of concepts during the development from basic requirements (generic), to industry specific requirements (partial) to enterprise specific requirements (particular) (Scheer 1998). Former and current research on CIMOSA as well as software implementations supporting enterprise modeling according to the CIMOSA approach can be accessed via the website of the CIMOSA Association.⁶

Additionally, we would like to mention further examples of Business Process Frameworks in the sense of methodical business process engineering approaches which are of relevance for Enterprise Modeling and BPM such as Multi-Perspective Enterprise Modelling (MEMo) by Frank (1994), the Semantic Object Model (SOM) by Ferstl and Sinz (1995), ProMet by Österle (1995) or The Open Group Architecture Framework (TOGAF).⁷ In the following section Business Process Frameworks in the sense of technical infrastructures for process integration and process model interchange will be treated.

3.2 Technical Infrastructures for Process Integration and Process Model Interchange

The second major class of Business Process Frameworks summarizes technical infrastructures for process integration and process model interchange. In this area, several different specifications have been developed based on the specific tasks which are supposed to be supported, e.g. process model interchange between different modeling or workflow tools, inter-organizational process integration or web service orchestration. In the following, some examples of such technical infrastructures will be presented in order to further clarify this specific interpretation of the term Business Process Framework.

The XML Process Definition Language (XPDL) is an XML-based standard for the exchange of business process models and has been developed and advanced by the Workflow Management Coalition (WfMC) since 1993. The current version 2.2 has been released in 2012 and supports a graphical representation of XPDL specifications by means of the Business Process Model and Notation (BPMN) 2.0 standard.⁸ Furthermore, XPDL facilitates the interchange of BPMN diagrams in general, also for earlier versions of the BPMN up to version 1.2.⁹ This distinguishes XPDL from similar XML-based standards like the Web Services Business Process Execution Language (WS-BPEL) which mainly focusses on business process execution and not so much on graphical representation aspects. WS-BPEL is a description language for business processes comprising functions and activities which are implemented as web services.¹⁰ The WS-BPEL has been extended by the so called WS-BPEL Extension for People (BPEL4People) specification which additionally considers process activities conducted by humans in BPEL processes.¹¹

The ebXML Business Process (ebBP) OASIS standard is another XML-based standard for the technical specification of business processes.¹² It especially aims at supporting inter-organizational business process integration and is based on the former process integration standard eBusiness Extensible Markup Language (ebXML) which has also been developed by the Organization for the Advancement of Structured Information Standards (OASIS).¹³

Besides these quite current business process integration approaches, many other technical infrastructures and approaches exist – some of them meanwhile obsolete – like Workflow-XML (Wf-XML) by the WfMC¹⁴ or the Business Process Modeling Language (BPML) by the Business Process Management Initiative (BPMI).¹⁵ In the following section, we present several Business Process Frameworks in the sense of business process reference models in more detail.

3.3 Business Process Reference Models

3.3.1 What Is a Business Process Reference Model?

The term business process reference model has not been consistently defined and there is still a lively discussion which aspects this term comprises. This discussion shall not be comprehensively recapitulated in this contribution. In general, business process reference models can be understood as business process models which should fulfil certain criteria and offer certain features. These criteria are still under discussion, e.g. in (vom Brocke 2003; Thomas 2006; Fettke and Loos 2007). Referring to Fettke and Loos (2007) and Ardalani et al. (2013), we consider the following features as important:

• 1. Reusability: Business process reference models represent business process blueprints for the development of process-oriented IS which can be reused in different IS development projects (vom Brocke 2007).

• 2. Exemplary practices: Business process reference models can provide common, good or even best practices describing how business processes are actually designed in practice or how they could or should be designed and executed in order to reach certain goals. In this context, a descriptive as well as a prescriptive or even normative connotation of business process reference models becomes apparent depending on their interpretation.

• 3. Universal applicability: Business process reference models do not only represent business processes of one particular organization but aim at providing universally applicable business process representations which are valuable for different organizations in a certain domain.

Reference models can provide benefits for both theory and practice. Besides the provision of general descriptions of enterprises, which is especially interesting from a theoretical point of view, practice profits, e.g. from decreases in modeling costs, modeling time and modeling risk as reference models can represent proven solutions (Becker and Meise 2011). Moreover, increases in model quality based on the reuse and adaption of already validated process models can be expected.

Prominent examples for reference models which have been extensively used in practice in order to profit from these advantages are, e.g. the Y-CIM Model by Scheer for industrial enterprises (Scheer 1994) or the SAP reference model as a basis for the SAP R/3 system which has been partly published in (Keller and Teufel 1998). An overview of a collection of reference models is provided by the Reference Modeling Catalogue hosted by the Institute for Information Systems (IWi) at the DFKI and Saarland University, Saarbrücken.¹⁶ In the following, we present a selection of relevant Business Process Frameworks in the sense of business process reference models: the SCOR Model, ITIL, eTOM and the APQC Process Classification Framework^SM (PCF).

3.3.2 Supply Chain Operations Reference (SCOR) Model

The Supply Chain Operations Reference (SCOR) Model is a process-oriented reference model for supply chain management which has been introduced in 1996 and further developed by the Supply Chain Council.¹⁷ After several revisions, the SCOR model has been available in version 10 since August 2011. While at first only the 69 founding members were part of the Supply Chain Council, the Council now comprises almost 1,000 companies and research institutions.¹⁸

The SCOR model defines five different types of processes in organizations. Their relationship is visualized by means of a multi-stage supply chain in Fig. 3:

• 1. Plan: includes the planning and management of supply and demand for goods.

• 2. Source: comprises the purchase of goods, the goods receipt, pre-delivery check, storage and method of payment for any goods.

• 3. Make: covers all stages of production processing.

• 4. Deliver: comprises all the steps of the ordering and delivery of goods to the customers.

• 5. Return: includes all the steps for handling returned goods, both repairs and maintenance are taken into account.

Fig. 3

SCOR model process types in a supply chain (According to: http://supply-chain.org/)

In the study of Fettke (2008) the real world effects of using the SCOR model have been investigated based on different theoretical perspectives, such as the market-based view, the resource-based view and network theory. Moreover, the hypothesis saying that the application of the SCOR model comes with positive effects on typical supply chain management goals is supported by an empirical study which has addressed all members of the Supply Chain Council. Furthermore, Bolstorff et al. (2007, p. 27) report on additional experiences with the SCOR model:

• 1. Increase of total income by three per cent after a SCOR project through the reduction of costs and the improvement of customer services;

• 2. Two to six fold return on capital within 12 months after completion of the SCOR project;

• 3. Lower operating costs for information technology;

• 4. One to three per cent increase in annual operating profit.

Besides these findings, a recent survey identified positive impacts of using the SCOR model on customer-facing supply chain quality performance and internal-facing business performance (Li et al. 2011). Another survey could also confirm several positive influences of using the SCOR model on supply chain management performance (Zhou et al. 2011).

3.3.3 Information Technology Infrastructure Library (ITIL)

The Information Technology Infrastructure Library (ITIL) represents a business process framework for IT service management (ITSM) which is widely accepted and applied in professional IT service organizations.¹⁹ The current version ITILv3 has been published in 2007 and updated in 2011. ITIL is considered a de-facto standard for ITSM and describes standardized key processes, key concepts and principles, key roles and responsibilities as well as according KPIs and checklists in five different areas of ITSM. Concerning ITILv3, for each of these areas one separate volume with detailed process descriptions in the following areas has been published: (1) ITIL Service Strategy which supports the definition of an adequate IT service strategy in the sense of a longer term development of IT service skills under special consideration of the customer requirements, (2) ITIL Service Design which supports the development of new IT services and solutions as well as the further development of existing services based on the service strategy, (3) ITIL Service Transition which supports the coordination of the IT services’ development and deployment, (4) ITIL Service Operation which supports an effective and efficient IT service fulfillment and (5) ITIL Continual Service Improvement (CSI) which uses methods of quality management in order to continuously learn from success and failure to improve IT services. Figure 4 visualizes these five areas of the ITILv3 and the according core processes within these areas.

Fig. 4

ITILv3 core processes

As ITIL represents the de-facto standard for ITSM, a large amount of experience with the usage of ITIL in practice exists. Furthermore, there is quite an amount of empirical studies conducted by scholars reporting on the positive effects of ITIL usage on IT service organizations’ performance, e.g. Henson and Geray (2010) or Meziani and Saleh (2010) in the context of service management in public administration settings or Lapão et al. (2009) in the context healthcare environments. Furthermore, there are some recent studies on factors influencing ITIL adoption, e.g. the contribution of Cater-Steel et al. (2009) or the comprehensive international survey by Marrone and Kolbe (2011) which reports on the ever-increasing ITIL adoption and the increasing realized operational benefits caused by the usage of ITIL.

3.3.4 Enhanced Telecom Operations Map (eTOM)

The enhanced Telecom Operations Map (eTOM) represents a business process reference model for the telecommunications industry which has been introduced by the TM forum as their Business Process Framework.²⁰ It provides a detailed description of relevant business processes for service providers based on a four-level-hierarchy. Figure 5 shows Level 0 and Level 1 within the eTOM process hierarchy.

Fig. 5

eTOM architecture (Level 0 and 1) (According to: http://www.tmforum.org/Overview/13763/home.html)

Level 0 represents the overall enterprise level and defines the three major sections: a. Strategy, Infrastructure & Product, b. Operations and c. Enterprise Management. Level 1 “contains seven end-to-end vertical Level 1 process groupings in the areas of Strategy, Infrastructure and Product and Operations. These vertical groupings of processes focus on end-to-end activities […] and each grouping includes processes involving customers, supporting services, resources and suppliers/partners. […] The horizontal groupings represent major programs or functions that cut horizontally across an enterprise’s internal business activities.”²¹ More detailed process definitions exist on level 2 and level 3 of the eTOM specification.

In practice, a certain amount of experience with the application of eTOM exists as it is one of the most popular standards for managing business processes in the telecommunications industry (Tanovic and Androulidakis 2011). However, so far there are only few empirical studies driven by scholars concerning the real world effects of eTOM; e.g. Chou et al. (2008) report on a successful application of eTOM especially in the context of trouble management operations in the largest Taiwan telecommunications corporation resulting in an improved performance and improved user satisfaction.

3.3.5 APQC Process Classification Framework^SM

The APQC Process Classification Framework ^SM (PCF) provides a comprehensive taxonomy of operating processes as well as management and support processes. The PCF supports benchmarking of organizational performance within one or among organizations “regardless of industry, size or location” of the compared organizations by means of a common terminology to describe and compare business processes.²² It has been developed by the American Productivity & Quality Center (APQC) since the early 1990s and the current version 6 comprises more than 1,000 relevant business processes. Besides the cross-industry version, several industry-specific versions of the PCF exist, e.g. for retail, automotive, telecommunications, education. The content of the PCF is organized into the following five levels²³:

• Level 1: Category, represents the highest level of processes in enterprises such as financial organization, human resources etc. One example of a category in PCF version 6 is “1.0 Develop Vision and Strategy (10002)”.

• Level 2: Process Group, represents connected groups of business processes within one category. One example of a process group in PCF version 6 is “1.1 Define the business concept and long-term vision (10014)”.

• Level 3: Process, represents a sequence of interrelated activities converting input into output. One example of a process in PCF version 6 is “1.1.1 Assess the external environment (10017)”.

• Level 4: Activity, comprises key events performed during the execution of a process. One example of an activity in PCF version 6 is “1.1.1.1 Analyze and evaluate competition (10021)”.

• Level 5: Task, next level of decomposition after activities, more fine-grained. One example of a task in PCF version 6 is “12.2.3.1.1 Identify project requirements and objectives (11117)”.

Figure 6 gives an overview of the process categories contained in the PCF.

Fig. 6

Overview of categories in the APQC Process Classification Framework^SM

According to the APQC reporting, the PCF has been used for business process management and benchmarking in many different businesses in the last two decades worldwide and several practical case studies providing detailed experiences with the PCF in renowned companies from different industries exist.²⁴ Furthermore, the PCF has been used as a systemization approach for business processes as a fundament for scientific empirical studies and surveys, e.g. concerning IT and business process alignment (Cragg et al. 2007; Cragg and Mills 2011) and in the context of comparing service offerings in business transformation projects (Srivastava and Mazzoleni 2010).

4 Discussion

Our investigation showed that the term Business Process Framework is ambiguous and that quite a number of different understandings and usages of this term exist. However, on the basis of our underlying definitions of business process and framework and the commonly identified understandings an expedient systemization of Business Process Frameworks could be developed. Presenting several instances of each understanding of the term Business Process Framework could further clarify the specific subtleties of each framework class.

During our investigation, several quite similar Business Process Frameworks within the different classes have been identified, e.g. ARIS and CIMOSA as methodical business process engineering approaches, XML-based process model interchange and process integration infrastructures like XPDL and ebBP or ITIL and eTOM as reference models. Figure 7 gives an overview of Business Process Frameworks within the according classes which have been presented in this contribution.

Fig. 7

Business Process Framework classes and instances

The similarity of these Business Process Frameworks makes the topic of mapping frameworks which belong to the same class an interesting subject-matter. In the above mentioned cases there are several intersections and considerable overlapping of addressed content of Business Process Frameworks e.g. comparing ITIL and the COBIT framework, another valuable IT governance framework. In this comparison also several differences in content between such Business Process Frameworks are observable. In practice, this can lead to severe problems when both frameworks could provide important functionality for an organization. In such a context, the mapping of the Business Process Frameworks in terms of terminology, procedure models etc. is highly desirable in order to be able to profit from a combination of functionalities. Such mapping initiatives exist for several Business Process Frameworks, e.g. ITIL and COBIT²⁵ or ITIL and eTOM.²⁶ Furthermore, the mapping of Business Process Frameworks in order to combine functionality and to profit from the strengths of every single approach also seems promising for the other classes of frameworks.

Investigating Business Process Frameworks in the sense of reference models, we found that empirical research concerning the real world effects and relevant characteristics like factors influencing the adoption of a Business Process Framework has so far only been conducted to a moderate extent. In order to assess these empirically observable effects in more detail, more empirical research into this seems to be desirable besides the design of new and innovative Business Process Frameworks.

5 Conclusion

Business Process Frameworks are of considerable importance in Business Process Management practice and research. In this contribution, we investigated the research community’s underlying understanding and usage of the term Business Process Framework which showed to be an ambiguous term with different meanings. We introduced a systemization of common understandings and presented several Business Process Frameworks which have been relevant for BPM research and practice in recent years. Thereafter, we discussed our results.

Our assumption that the two central terms business process and framework seem to influence the Business Process Frameworks term ambiguity seems plausible to a certain extent. In our investigation we found that important aspects and meanings of these underlying terms can be found in the different interpretations of the term Business Process Framework and in the content dimensions of the presented frameworks.

Future work concerning Business Process Frameworks should – besides the design and further development of innovative frameworks – concentrate on the empirical assessment of the effects of existing Business Process Frameworks in the real world. A further-going investigation of the possibilities of mapping similar Business Process Frameworks could support a better understanding of how valuable functionalities could be combined and, thus, made accessible for practice. However, in this context it has to be further investigated how engineering challenges concerning the maintenance of framework mappings could be faced in order to have consistent and at the same times flexible Business Process Frameworks.