Master’s thesis
Developing the
Enterprise Process Model
A framework for process design and governance
II
Developing the
Enterprise Process Model
A framework for process design and governance
by Hylke Sluis S1385402 hylkesluis@hotmail.com October 2008 University of Groningen Faculty of Economics and Business Master of Science in Business Administration
Specialization Business & ICT
Supervisors Drs. D.J. Schaap Dr. N.B. Szirbik
Faculty of Economics and Business
Ir. P.C.L. Walraven
Preface
Five months ago I started at Company X on an assignment to design the Enterprise Process Map (EPM): one map that shows all Company X’s processes at a high level. Company X was
implementing ARIS, a process modeling tool. Processes were modeled at lower levels, but there was no integration of these processes into a higher-level model.
During interviews to identify requirements for the EPM, I found out that the Process Governance Board (Company X’s ‘highest’ process management platform) also had started such an initiative. We teamed up, which broadened the scope of the research (less tool-dependent). And this top-management support opened doors to resources, stakeholders and credibility. Suddenly I was in a Project Team with a PGB representative and my supervisor at Company X. The impact of the project emerged: from a map in a tool (which alone is very important and surely does have its organizational impact) to a Company X-wide reference model and process language. As the Business Process Director puts it: “When we talk about processes at Company X, this is the reference model and the process-language we use”. The organizational impact is one reason why my internship at Company X has been such an interesting time for me.
The process-design part of the framework developed in this thesis is used one-on-one at
Company X. Only the theoretical arguments and some principles that were not considered useful were left out. The Process Governance part of the framework is a proposal to Company X. As process management is a fairly young discipline in science, there is not one source which tells what to do when designing processes. Paul Harmon’s book comes close, but Harmon is not very detailed and not always applicable for this research at Company X. I think there is a need for somebody like Michael Porter is for strategy and Peter Drucker and Philip Kotler are for
Marketing. One theorist who sets principles that guide the road for future research, and that are applicable in both theory and practice.
However, this is the second reason why this was an interesting time. The lack of starting point made me use a variety of sources, some more influential than others, and combine them into one framework. The law of advancing insight truly was applicable: at first I could not distinct in important and non-important issues. At first I thought I understood the matter but numerous brainstorm sessions later I can say that at first I only understood parts of the whole. Therefore, I could not have imaged the result of this thesis.
Many people helped me during my internship. I do not like to use this preface to thank half of the world for reasons up to ‘just being in my life’. However, four people have had a substantial influence on this thesis. I would like to thank Pieter Walraven, my supervisor at Company X for giving me this opportunity, for explaining a lot to me and for the discussions about the
Framework Process Design and about process management in general. I also would like to thank my other project teammate Ghislaine Prins for her ideas, the discussions we have had and for reviewing what I have written. The discussions in the project team meetings really advanced our process thinking. Third I would like to thank Marc Goumans, Business Process Director for the feedback and ideas; and for always having his door open. Last but not least I want to thank Dick Schaap, my supervisor at the University. Every feedback meeting helped me. Sometimes it was already helpful when I walked out the door, sometimes ‘the quarter fell’ after a few days. Thank you all.
Leaves me wishing all of the readers an interesting time reading this thesis. It is a lot, but I think every section is interesting in its own way. At least it was fun writing it.
IV
Abstract
In this research Company X’s Framework for Process Design and Governance is developed. Basically, the framework is divided in three parts:
• Principles and elements for process design and governance • Process design at level 1 and 2
• A governance structure
The principles and elements are the foundation for process design and governance. It consists of a lot of principles and elements. The most important principles are that processes are
hierarchically structured in five levels; each lower level has a greater level of detail. Level 1, Process Domains, is categorized in Management, Core and Enabling processes. The principles and elements can be seen as the process language for Company X.
The design of level 1 and 2 of the process hierarchy is done in a workshop with stakeholders. This part of the framework puts the principles and elements of the first part in practice.
Governance for Process Management and Process Design consists of two components: a governance structure and tasks and duties in phases of process design. The governance
structure is aligned to the process levels: at every level there are owners for the domains, groups and processes. These roles have different tasks and duties in the four phases of process design: Plan & Develop, Implement, Deliver & Support and Monitor and Evaluate.
Table of Contents
1. Problem Description ... 1
1.1 Objectives ... 3
1.2 Structure of the thesis ... 4
1.3 Research method ... 5
1.4 Scope of the thesis ... 5
1.5 Harmon’s BPTrends Enterprise Methodology ... 6
1.5.1 Harmon’s BPTrends Methodology ... 6
1.5.2 Understand the enterprise ... 7
1.5.3 Define Business Process Architecture ... 7
1.5.4 Build Process Management Capability ... 7
2. Company X Company Description and Requirements ... 9
2.1 Company Description ... 9
2.1.1 Strategy ... 9
2.1.2 IT strategy ... 9
2.2 Business Process Management at Company X ... 9
2.2.1 Process governance ... 9
2.2.2 Business process modeling ... 10
2.3 Stakeholders Process Design and governance ... 11
3. Theory and Analysis ... 15
3.1 Benefits Business Process Management ... 15
3.2 Theory Review and analysis Process Design ... 16
3.2.1 Presentation structure ... 17
3.2.2 Purpose of the design ... 24
3.2.3 Level concept ... 25
3.2.4 Framework and foundation of the model ... 26
3.2.5 General principles ... 27
3.2.6 Techniques and tools ... 30
3.2.7 Types of process models ... 30
3.2.8 Elements of model ... 31
3.2.9 Quality of the model ... 32
3.3 Theory review and analysis process governance ... 33
3.3.1 Organizational Structures ... 33
3.3.2 Components of process governance ... 43
3.3.3 Focus of Process Management – Process Portfolio Analysis ... 43
4. Company X Business Process Framework ... 47
4.1 Introduction ... 47
4.1.1 Why is process design needed? ... 47
4.1.2 Framework context, objective and audience ... 48
4.1.3 Definition Business Process ... 48
4.2 Principles and Conventions ... 49
4.2.1 Framework principles ... 49
4.2.2 Enterprise Process Map ... 53
4.2.3 Management, Core and Enabling processes... 53
4.3 Level 1, 2 and 3 Processes ... 59
4.3.1 Innovate & Market... 59
4.3.2 Source to Pay ... 60
VI
4.3.5 HR Management ... 64
4.3.6 Record to Report ... 65
4.3.7 Master Data Management ... 66
4.4 Process Governance ... 67
4.4.1 Introduction ... 67
4.4.2 Governance Structure ... 67
4.4.3 Governance for Plan and Develop ... 70
4.4.4 Governance for Implement ... 71
4.4.5 Governance for Deliver and Support ... 71
4.4.6 Governance for Monitor and Evaluate ... 72
5. Conclusion ... 73
6. Further research, strengths & limitations ... 77
6.1 Further research ... 77 6.2 Strengths ... 77 6.3 Limitations ... 77 REFERENCES ... 79 Books ... 79 Published articles ... 79
Company X company resources ... 82
Other resources ... 82
Appendix A: Glossary ... 84
Appendix B: IT Strategy Company X ... 85
Appendix C: Organizational Chart ... 86
Appendix D: Details shortlisted presentation structures ... 87
1.
Problem Description
Traditionally, the organization Company X is structured in departments. Departments are for example Supply Chain, where Company X’s main product produced. And Commerce, where Company X’s branding and advertising campaigns are developed. This functional structure brings along its advantages and disadvantages. For example, as a functional structure emerges around groups of similar knowledge and activities, this structure enhances expertise. But it may decrease efficiency, when there is not enough coordination between departments.
In the last years the companies industry is marked by a consolidation wave. Now, the top-four players share 44% of the market (Company X Company Presentation 2008). During this research, two major examples of the consolidation wave happened: the acquisition of a competitor by Company X, meaning almost an 18% growth for Company X in group volume. And the bid of a competitor Y for competitor Z. The second-largest company bids for the fourth largest company. When the latter acquisition takes place, it results in a company that is over two times bigger than Company X.
Company X’s culture is characterized by local entrepreneurship. The quick consolidations contribute to this decentrally organized management structure. Operating Companies (OpCo’s) have lots of differences in the way they are managed and in the way they work.
Not having one common way or working (common processes) makes it difficult to integrate acquired competitors. Employees are less flexible: they cannot easily be transferred to another OpCo. Best-practice sharing is more difficult, as well as benchmarking and controlling processes. Furthermore, global IT systems such as ERP systems need common processes.
Company X’s top management acknowledges these issues. In response, a business process
management structure is set-up. A Process Governance Board (PGB) is formed to govern processes. In January 2008, a Business Process Director was appointed. This is an executive-level director (reporting to the Chief Financial Officer of the Executive Board) with a responsibility for Business Process Management (BPM). The Business Process Director chairs the PGB. Simply said, the main task in 2008 of the Business Process Director is to get BPM going at Company X.
The PGB aims to govern Company X’s processes. It exists next to the departmental structure. The PGB consists of Functional owners who are responsible for processes in a particular function. Table 1.1 lists and briefly explains the functions that are represented in the PGB.
Table 1.1 Brief function descriptions
Function Description
Order to Cash Every step between the order of a customer and the payment of a
customer. Orders without payment (for example free goods) are within this process’s scope.
Customer Relationship Management
The processes that create and maintain a relationship with a customer. Wholesale The processes in Company X’s wholesale business.
Hire to Retire Every HR-related process between hiring an employee and the retirement of an employee. Also known as Hire-to-Fire.
Purchase to Pay Every step between the intention to purchase goods and the payment of these goods to the supplier.
Internal Audit The processes of Internal Audit.
Record to Report Every step between recording financial data and the reporting of financial data, including tax, treasury and insurance processes.
2 However some of the functions have a process-like name (Order to Cash, Purchase to Pay), they cannot for certain be called processes. A business process is a set of partially ordered activities aimed at reaching a goal (Hammer and Champy, 1993). At enterprise level, it is not defined what the goal of a process is, what the inputs and outputs are, what resources are used, what elements constitute the process, etc. The lower-level processes (e.g. delivery or packaging) are on the other hand well defined. Not having defined enterprise-level processes means that it is not clear where a process starts, where it ends and it is possible that multiple functional owners are responsible for parts of the same process.
Not having well-defined processes leads to difficulties in BPM. For example, when the PGB asked itself what Company X’s processes are, the answer was the left column of table 1.1. But is that correct? Basic understanding of business is enough to say that it is not complete. Second, there is possible overlap in those processes: Order to Cash is also a process that creates a relationship with a customer, so maybe Order to Cash is a part of CRM. The PGB and the Business Process Director don’t have a correct understanding of what they are responsible for and therefore cannot know if they properly do their job.
This introduction to Company X and BPM at Company X sketches several causes of (potential and actual) problems, which are also visible at Company X. Therefore, there are practical reasons to develop a framework for process design and governance:
1. The PGB, communities of practice (an international platform for process owners) and functional ownership are not clearly developed nor communicated. Process design will provide a foundation for their work. With proper process design it is transparent what they are responsible for and how they relate to the rest of BPM and the rest of Company X. In the same way, process design gives the basis for governance of projects like the
development of ERP systems.
2. Measuring and comparing process performance is difficult when OpCo’s do not measure the same process.
3. Consistent process design is a precondition for having common processes. Process commonality can only be assessed – and changed – if everybody has the same principles and language. If two OpCo’s use different design principles or understand/explain BPM differently, it is not possible to assess commonality.
4. The framework contains the reference model for Company X’s processes. Such a model is needed to challenge OpCo’s in the way they execute processes.
5. Process Design enables harmonization between processes (for example: designing Order to Cash according the same principles as Purchase to Pay), and harmonizing projects on process commonality (for example: doing the projects to design the common process for Order to Cash and Purchase to Pay in the same way), by having the same principles and the same process language.
6. Having Company X-wide common processes enables and improves a. Flexibility of employees
b. Successful mergers and acquisitions c. Benchmarking
d. Best practice exchange e. Controllability
f. Common IT architecture g. Common master data
7. The framework takes BPM out of the IT corner. At the same time, it enables and visualizes a business-driven connection between IT and the business.
With common processes is meant the standardization of processes over multiple OpCo’s. To summarize the above discussions, the following three problems are identified.
• There is no good foundation for process governance
• There is no good framework to base common processes and performance measurement on
• There is no uniform process language
There are frameworks and methodologies to design processes present at Company X, but they aren’t up to date and they too often have a strong IT-focus.
1.1 Objectives
There is a need to design end-to-end processes at enterprise-level. End-to-end processes are processes with a clear and logical disconnection between the preceding and subsequent processes. In order to design processes, there is a need for a process design method.
Process design at Company X should lead to more effective process governance. Since process design is an ongoing activity (processes may change due to best-practice copying or changing environmental requirements), process design should be governed too. Next to that, governance is less effective when it is not clear how responsibilities for process elements are allocated. Therefore, there is also a need for a clear process governance structure, which is constituted of two parts: Process Governance structure (how to set the organizational structure and conditions in which processes are managed) and Process Design Governance (how to develop, roll-in and maintain process design). For simplicity reasons, the two parts are referred to as governance structure. There is also a need for reference processes that can challenge OpCo’s in their process design and that can provide the basis for process commonality.
This leads to the following objectives. Of course, Company X has a view of which direction the research must take. The directions given by Company X are formulated as sub-objectives.
• To develop a process design method
o The method must have a strong Business Process orientation: bringing together data, organizational departments, IT solutions, Performance Indicators, etc. It does not have its basis in IT.
o The method must comprise a uniform process language. o It must be understandable for people from various disciplines.
• To put the method into practice: design Company X’s enterprise-level processes
o This must be the reference model for Company X. It must serve as a stepping stone for future process-initiatives.
o It must be understandable for people from various disciplines. • To develop a governance structure for these processes
o Develop a general process governance structure and focus on how to gover process design.
o Address how to identify focus areas for process management.
4 This leads to the following main question:
Company X’s management wants to have a method to design and describe business processes and wants to understand what Company X’s main business processes are. This should lead to having well-defined processes, a clear and consistent terminology, a way to present processes, a basis for process governance and a complete set of Company X’s processes where KPI’s, data, IT solutions and organizational departments can be linked to.
The focus of this research is on the development of this framework, so what elements should it contain and what is best for Company X’s purpose. To structure the answering of the main question, the following sub questions are formulated:
1. What are the principles and elements that comprise a method for process design and governance?
2. What are Company X’s enterprise-level processes, using this method? 3. How can Company X govern process design?
These sub questions closely relate to Harmon’s BPTrends Enterprise Methodology. In section 1.5 is described how this thesis is based on that methodology.
For information about how this research is done from a company perspective, see Appendix E: Project Charter Process Design, containing among other things project phases, time planning and project structure. The Project Team Process Design and Governance, who executed the practical elements of this research at Company X, consisted of the author of this thesis (100% of time devoted to this project), the Functional Consultant BPM (40%) and a PGB representative (20%).
1.2 Structure of the thesis
This thesis is structured according three research phases: description, analysis and design. The sub questions overlap the chapters. Figure 1.1 shows a graphical decomposition of the structure, to show how the research phases and chapters relate to each other. The sub questions are mapped against the phases/chapters to show what chapter answers which sub question.
Chapter 1 - Introduction Chapter 2 - Description Chapter 3 - Analysis Chapter 4 - Design Chapter 5 - Conclusion Theory
Sub question 3 - Governance
SQ 2 - Process Design Sub question 1 - Principles and elements
1.3 Research method
The following table gives the research methods per sub question. Table 1.2 Research methods per sub question
Sub question Method Additional information
What are the principles and elements for process design and governance?
Field research, desk research
Interviews with Process Governance Board members to identify background and requirements for process design and governance; desk research to find principles and elements.
What are Company X’s enterprise-level processes, using these principles and elements?
Field research Field research to design processes according the principles and elements identified in sub question 1.
How can Company X govern process design?
Desk research, field research
Interviews with PGB members to identify background and requirements for governance, desk research to find a theoretical basis for governance.
1.4 Scope of the thesis
The scope of the thesis is limited in two dimensions: horizontally and vertically. Horizontally limitations refer to which processes at a certain level to include and which not. Vertical limitations refer to which hierarchical levels of processes to include and which not (levels in processes are the result of decomposing an organization’s value chain (Harmon, 2007a; Telemanagement Forum, 2007).
The scope of the thesis is horizontally limited to the processes represented in Company X’s Process Governance Board. This leaves for example processes in the corporate groups Business
Development and Corporate Relations out of scope. Table 1.3 lists the processes in scope. Having more processes in scope would be difficult due to the (in general) low maturity of other processes and the fact that other processes do not have an owner yet.
However, the principles and foundations of the framework will apply for every process. So, only the development of the framework is done based on the eight processes below. The framework is however applicable to the other processes.
Table 1.3 Processes in Scope of Research
Innovate and Market (although low level of maturity) Source to Pay Demand to Warehouse Market to Cash Order to Cash* HR Management Record to Report
Master Data Management
* Order to Cash is a part of Market to Cash, but since it has a separate owner in the PGB it is often mentioned in this research as a separate process
6 Furthermore, the results of this thesis must be validated. In the stakeholder analysis (in section 2.3) there is concluded that the framework must be validated with OpCo’s. However, this validation process will take a long time, since OpCo’s must go through the entire process of process design. Because the timeframe for this research is limited to 21 weeks, the validation part is executing the methodology to design the reference processes at Company X International.
1.5 Harmon’s BPTrends Enterprise Methodology
During the theory reviews, Harmon’s BPTrends Enterprise Methodology was found to be a useful ‘overall methodology’ about how to develop process design and governance. It provides the elements that must be covered in a BPM framework and it gives the order of these elements. This research is based on Harmon’s methodology. Parts of his methodology are left out of scope and the order is sometimes changed. This is explained in 1.5.1 to 1.5.4.
In the next sections is discussed what is important in each phase and how it relates to the Company X Process Design framework.
1.5.1 Harmon’s BPTrends Methodology
Harmon (2007a) provides a strategy driven enterprise methodology. The methodology consists of four steps: understand the enterprise; define the business process architecture; build the process management capability; manage enterprise processes. This is presented in figure 1.2.
BPTrends Enterprise Methodology
Understand enterprise Define Business Process Architecture Build Process Management Capability Manage Enterprise Processes
- Create business model - Define value chains - Align to strategy
- Model major processes - Establish KPI's - Align resources to processes
- Identify process managers - Define managers scorecards - Create BPM group
Monitor process & process manager performance
Figure 1.2 BPTrends enterprise methodology and relation to strategy (after: Harmon, 2007a) The BPTrends methodology gives a high-level framework of what needs to be done and in what order. How it needs to be done is not addressed in the framework, which will be investigated in this thesis.
The first three phases of Harmon’s framework are covered in this thesis. The fourth, manage enterprise processes, is not covered since this refers to the daily management of processes, it is the execution of what is developed in the first three phases.
Introduction Desciption Analysis Design Conclusion Understand enterprise
Define Business Process Architecture Build Process Management
Capability
Figure 1.3 BPTrends Enterprise Methodology versus the structure of this thesis
Understanding the enterprise is covered in the introduction, but mainly in chapter 2, the company description. Defining the BP architecture and building a process management capability consists of both analysis and design. Since the conclusion is about the developed process design and
governance, the two BPTrends phases also cover the conclusion. 1.5.2 Understand the enterprise
This phase consists of three steps: create business model, define value chains and align to strategy. In this thesis this step is stretched to a full company description. Defining value chains is already done at Company X: there is just one. There is no need in distinguishing value chains because the products have very similar processes.
1.5.3 Define Business Process Architecture
The three steps in this phase are model major processes, establish KPI’s and align resources to processes. Modeling major processes is done in chapter 4 (Framework), according to the principles and conventions developed in chapter 3 (Theory and Analysis).
KPI’s are also part of chapter 4. However, the principles for establishing KPI’s are addressed, in relation to Process Performance Indicators (PPI’s). The actual formulation of KPI’s is left out of scope.
Aligning resources to processes is a very complex and comprehensive process. That it should be done is evident, but to do so as part of this research will be too much. Leaving it out does not decrease the value of the rest of the framework, nor does it make it an incomplete story. So the alignment of resources is left out of scope.
1.5.4 Build Process Management Capability
Building a process management capability is referred to in this thesis as developing a governance structure. The first of the three steps, identifying process managers, is interpreted as identifying roles of process managers. The names that will fill in the roles are not mentioned, this is the responsibility of the company.
2. Company X Company Description and Requirements
This chapter describes various aspects of Company X. To get to know Company X better, general information, a short history and the strategy is described. The IT strategy is also provided, because the IT department accelerates business process management at Company X. However, BPM is much broader than just IT. Furthermore, the BPM developments at Company X are discussed. In section 2.3 the organizational requirements for the Framework Process Design and Governance are given.
2.1 Company Description
Company X is a multinational, based in the Netherlands, active in the food and beverages industry. 2.1.1 Strategy
2.1.2 IT strategy
One of the main forces behind process management at Company X is the IT department. Company X views Group IT as a support function. This is implied in the IT strategy by the main elements in the strategy: standard solutions and cost effectiveness.
Company X’s Group IT relies heavily on SAP. SAP is used in several business functions such as production and finance. For functions not supported by SAP, Group IT relies on development of solutions, as well as copying of best practices and outsourcing.
SAP has a major impact on process management. SAP requires a standard way of working, using common business processes. This means that the business processes at lower levels should be common, for the processes that are supported by SAP.
2.2 Business Process Management at Company X
In 1998 was decided that Company X should move to standard global information systems. Since then, IT had been a driver for common processes. In this section is described what the current state is of BPM at Company X.
Two major BPM movements can be identified. Process governance and a process-modeling project. The two movements are discussed below.
2.2.1 Process governance
BPM is of growing importance at Company X. A Process Governance Board (PGB) is formed, consisting of functional owners. This board has the following objectives:
1. To design, describe and implement common processes, including the measurement of process performance indicators (PPI’s). This enhances best practices, increases efficiency and effectiveness of how processes are defined and organized.
2. To develop new common functionality and maintain, enrich and support roll in’s of existing common applications. This is closely connected to IT.
10 From January 2008, a Business Process Director is in charge of process management and chairs the PGB. The Director reports to the Chief Financial Officer of the Executive Board.
2.2.2 Business process modeling
Company X started a project to model business processes. A short introduction of the modeling project is provided here. The processes designed in this research are directly modeled, so this parallel project must be considered.
2.2.2.1 ARIS
Company X uses ARIS as a tool to model business processes. ARIS is a platform for BPM, providing software and an approach to process strategy, design, implementation and control. In ARIS, Company X models current processes. Before ARIS the separate process descriptions are located in Word-, Visio- and Powerpoint-documents. In ARIS these process descriptions are modeled and integrated. Integration is both horizontal (resulting in end-to-end processes) and vertical (resulting in process hierarchies). When completed, a business process architecture is developed in which every process has its location.
One of the main aspects in the ARIS philosophy is that there are multiple viewing points to see the same process or activity. The shape of a funnel best visualizes this: at the top of the funnel there is room for many views. When navigating deeper in the architecture, the views are more and more integrated. This implies that there is one lowest level where all views are integrated. This is true: when you look at an activity in ARIS, you see which roles, which KPI’s, which risks, which
information systems etc. are related to that activity. The ARIS house represents five different views on processes. These can be seen as ‘standard ARIS views’, views that are proposed to each
company that uses ARIS.
Figure 2.1 ARIS house
The ARIS house consists of 5 views on processes.
• The organization view provides models of the structure of the organization. It includes departments, people, resources, roles, etc.
• The data view consists of business information. Includes data models, knowledge structure etc.
• The function view consists of process tasks. Includes function hierarchies, business objectives, supporting systems, etc.
• The process (control) view provides models of the business processes and how they relate to resources, data and functions of the business. Includes process chains, information flows, communication diagrams, flow charts etc.
The importance of the ARIS tool for this research is that it enables to focus on business processes only, not on IT processes. IT processes can be linked to Business Processes in ARIS, so the
framework does not need to have an IT focus. 2.2.2.2 Approach to process modeling
Company X has a bottom-up approach to process modeling. First, low-level processes are modeled. Davis and Brabänder (2007) argue that it is better to start top-down (start with the Enterprise Process Map (one map containing all main high-level processes) and decompose this map into lower levels). However, because few people can correctly visualize the entire structure of their models before they start modeling, the top-structure will emerge form detailed modeling (Davis & Brabänder, 2007, p47). The bottom-up approach to process modeling is an important issue in this thesis, because when developing the enterprise-level processes, it has to be kept in mind that they have to be connected to the already modeled processes.
In past ERP implementation projects processes are already modeled at three detailed levels.
2.3 Stakeholders Process Design and governance
The success or failure of a project is to a considerable extent dependent on how stakeholders are involved in a project (Boonstra, 2006; Mitchell, Agle and Wood, 1997). In order to identify requirements of stakeholders, it is useful to know who the stakeholders are and their
characteristics. Stakeholders are analyzed according the salience theory of Mitchell et al. (1997). Because this research mainly focuses on the top-levels of the process hierarchy, management at this level is considered a stakeholder. This is a legitimate choice, because people working with the top-level design are included. People who do not work at the designed levels are excluded. This leads to the following (groups of) stakeholders (table 2.1).
Table 2.1 Stakeholders
Stakeholder Why a stakeholder
Business Process Director Is hierarchical the highest director dedicated to processes Functional Owners Are responsible for (parts of) a process
Delegated Functional Owners Are responsible for the day-to-day management of (parts of) a process
International Business Process Owners (IBPO)
Are responsible for processes in a particular function (e.g. Finance, Wholesale, installations)
OpCo management Must be able to design OpCo-specific processes according the method in this research
According to the stakeholder salience theory (Mitchell et al., 1997), these stakeholders have urgency, legitimacy and/or power in relation to process design and governance.
A group has power to the extent that it can exert its will over another group. Urgency is based on time sensitivity and cruciality. Legitimacy is a social good; if groups share the perception the actions of one group are desirable.
12 Urgency Legitimacy Power 1. Dormant stakeholder 5. Dangerous stakeholder 7. Definitive stakeholder 4. Dominant stakeholder 2. Discretionary stakeholder 6. Dependent stakeholder 3. Demanding stakeholder 8. Nonstakeholder
Figure 2.2 Stakeholder typology (after Mitchell et al., 1997)
1. “Dormant stakeholders possess the power to impose their will on a firm, but because they do not have a legitimate relationship or an urgent claim, their power remains unused” (Boonstra, 2006). 2. “Discretionary stakeholders possess legitimacy, but have no power of influencing the firm and no urgent claims. There is no pressure to engage in a relationship with a stakeholder” (Boonstra, 2006).
3. “Demanding stakeholders exist where the sole stakeholder relationship attribute is urgency, referring to those with urgent claims, but having neither legitimacy nor power” (Boonstra, 2006). 4. “Dominant stakeholders are both powerful and legitimate. Their influence in the relationship is assured, since by possessing power and legitimacy they form the dominant coalition” (Boonstra, 2006).
5. “Dependent stakeholders are characterized by a lack of power, but have urgent and legitimate claims. These stakeholders depend on others to carry out their will. In their relationship power is not reciprocal and is advocated through the values of others” (Boonstra, 2006).
6. “Dangerous stakeholders possess urgency and power, but not legitimacy, and they may be coercive or dangerous. The use of coercive power often accompanies illegitimate status” (Boonstra, 2006).
7. “Definitive stakeholders possess power, legitimacy and urgency. Any stakeholder can become ‘definitive’ by acquiring the missing attributes” (Boonstra, 2006).
8. “Non-stakeholders possess none of the attributes” (Boonstra, 2006).
Table 2.2 Stakeholder analysis
Stakeholder Urgency Legitimacy Power Classification*
BP Director X X X Definitive stakeholder
Functional Owners X X X Definitive stakeholder
Delegated FO’s X X Dependent stakeholder
IBPO’s X X Dependent stakeholder
* Classification according Mitchell et al. (1997)
** Some OpCo’s show urgency, other OpCo’s don’t express the need
Why these stakeholder groups show these attributes is explained below. Also, it is described to what extent they will be involved in the research.
The BP Director and Functional Owners are definitive stakeholders. As PGB members, they have been given the power to decide over process issues. They show urgency because they requested a process design in their meeting on March 25, 2008. If they have legitimacy is hard to define, since it is a social good. Because process management is their daily work, it is expected that other
employees will see them as legitimate to decide about processes. Since they have power next to urgency and legitimacy, they will be used to identify requirements for process design, and the deliverables will be validated and approved by them.
The dFO’s and IBPO’s have no power, because their work is ordered from the Functional Owners. But they do have urgency (since they also do not precisely know their processes) and legitimacy (same reasoning as with the BP director and FO’s). Since they are responsible for the day-to-day management of processes, they will be used to identify requirements for process design. Also, as they are close to the processes they can deliver input for the actual process design.
Some OpCo’s show urgency in process design and governance. Examples are the Netherlands and Russia, who modeled many processes and requested process-modeling tools. Other OpCo’s do not express the need for process orientation. Since there are over 60 different OpCo’s worldwide, it will be too much to include them all in the project. It is however necessary to validate the framework with the OpCo’s. As said in the scope of the thesis (section 1.5) this is out of scope due to time limitations.
This is compensated in two ways. First, since FO’s and dFO’s are based in different locations, there is already input from some OpCo’s. In the group of FO’s, the Dutch and French OpCo are
represented. In the group of dFO’s, the Dutch, Spanish and Italian OpCo are represented. Second, validation of the method will occur in a case study at Company X International. The results of this method, the process design for reference processes, are part of the Framework.
3.
Theory and Analysis
In this chapter the theoretical basis for the framework is discussed. In sections 3.2 and 3.3 theory reviews are summarized, respectively of process design and process governance. The elements described in these sections form the basis for the conventions in the framework.
But first theoretical and practical benefits or BPM are discussed. These benefits are general, specific benefits for Company X were discussed in chapter 1.
3.1 Benefits Business Process Management
Potential benefits of BPM are widely discussed in literature. Breaking departmental boundaries, alignment of resources, strategic alignment, market orientation, commoditization and outsourcing are discussed. This section is concluded with two practical examples showing benefits of BPM. Breaking departmental boundaries and prevailing process boundaries, often referred to as breaking silo thinking, is one of the most discussed benefits (Harmon, 2007a; Segars, Harkness and Kettinger, 2001; Küng and Hagen, 2007; Ghoshal and Bartlett, 1995; Majchrzack and Wang, 1996; Garvin, 1995; Porter, 1985; Hammer & Champy, 1993).
Alignment of resources is in organizations perhaps the most visible utilization of processes. Many authors have published about alignment of both human resources (Harmon, 2007a; Llewellyn & Armistead, 2000; Ghoshal & Bartlett, 1995; Hung, 2006) and Information Technology resources (Küng & Hagen, 2007; Leymann & Altenhuber, 1994; Wang & Wang, 2006; Reijers, 2006; Nayak et al., 2007). Basically, resource alignment is a subset of breaking functional boundaries because resources used to be aligned to functions, now to processes.
Next to resource alignment, some authors stress that process management is useful to execute strategies. This is broader than resource alignment. Process management can align the entire organization to a strategy (Earl, Sampler & Short, 1995; Kettinger & Teng, 1998; Armistead, Pritchard & Machin, 1994). Strategic alignment through process management is making sure that the organization does what the strategy orders. Strategies don’t consider functional boundaries. Strategy is how a firm gains a favorable competitive position (Porter, 1985), by executing better activities and by executing activities better (Porter, 1996). A strategy is aiming at what an organization delivers, not about functional deliverables. So, basically is about processes.
Another benefit of process management is that everybody in an organization is working to deliver something to a customer, because the customer is eventually at the end of the process. This enhances market orientation (Garvin, 1995) and market orientation leads to competitive advantage (Slater & Narver, 1994) and more (new) product success (Narver, Slater & MacLachlan, 2004). Process management brings along process analysis, standardization and quality checks (Davenport, 2005). This, in turn, leads according to Davenport, to commoditization and outsourcing on a massive scale. This can have both positive and negative consequences. Outsourcing can lead to major costs savings, but also to fiasco’s (Cullen, Seddon & Willcocks, 2005). Process standardization can also be positive or negative (Davenport, 2005). It can lead to cost savings and to agility
16 What a zoo can teach you (Steward & Jacoby, 1992)
“The San Diego Zoo was organized in 50 departments: animal keeping, horticulture, maintenance, food service, fund raising, education, and others. It had all the traits of functional management, says David Glines, head of employee development. Glines started out as a groundsman, responsible for keeping paths clear of trash. If he was tired or rushed, Glines remembers, “sometimes I'd sweep a cigarette butt under a bush. Then it was the gardener's problem, not mine.”
The departments are invisible in the redesigned parts of the zoo. Tiger River, for instance, is run by a team of mammal and bird specialists, horticulturists, and maintenance and construction workers. The four-year-old team, led by keeper John Turner, tracks its own budget on a PC that isn't hooked up to the zoo's mainframe. Members are jointly responsible for the display, and it's hard to tell who comes from which department. When the path in front of an aviary needed fixing last autumn, the horticulturist and the construction man did it.
Seven people run Tiger River; when it started there were 11, but as team members learned one another's skills, they decided they didn't need to replace workers who left.”
The inventory level
A classic example of the shortcomings of functional management is the amount of goods in an inventory. The performance of the inventory manager, who is responsible for the inventory level, is measured by the average costs of inventory. Therefore, the manager’s aim is to keep the inventory as low as possible. In another part of the company’s building, a sales manager promises a customer timely delivery of a large order. The sales manager, who wants to keep his promise, wants high inventories, so he can always sell products. The question remains what is best for the company.
3.2 Theory Review and analysis Process Design
There is a large amount of literature about process design. A theory review is performed of which an overview is given in table 3.1. The table summarizes the review by highlighting the most important conclusions about an aspect. The main source is also stated, which provides the best overview of an aspect. The remainder of section 3.2 covers the discussion of the aspects, including either how Company X does it or how it should be done at Company X.
Process design is referred to in science as both process design and process modeling. Process modeling is, in essence, the formalization of the process design. Since (to a large extent) the same principles are applicable to both design and modeling, the theory review is a combination of process design and process modeling.
Furthermore, many authors use the term enterprise modeling and enterprise design for instead of process. Enterprise modeling is often IT-oriented, sometimes oriented. The process-oriented articles about enterprise modeling are included in the theory review.
The information in this chapter is to a large extent gathered during interviews with several Company X employees. Also, corporate resources as the intranet or corporate documents were used. The sources are given where used.
Table 3.1 Overview Theory Review Process Design
Aspect Highlight Main sources
Presentation structure process design
A presentation structure must be chosen for the designed processes.
Several, including Earl & Khan, 1994 and Davis & Brabänder, 2007. Purpose Way of designing is dependent on the purpose.
There can be various purposes, related to organizational maturity.
Aguilar-Savén, 2004
a choice should be made in how many levels to incorporate.
2007 Framework/foundat
ion
A framework helps a company to go through (parts of) the lifecycle of process design. The starting point of the framework is the
foundation of the model. Different foundations result in different process designs.
Kettinger et al., 1997; Kusters & Wortmann, 2007
General principles A process has several characteristics, are traceable to higher levels, are dependent from one another, have dynamic aspect, must have standardized name and numbering formats.
Telemanagement Forum, 2007
Techniques and tools
Processes are modeled using a tool (for example software). Using the tool requires certain modeling techniques. Different techniques entail different notations of processes, thus different designs.
Kettinger et al., 1997
Types of process models
Different perspectives on processes result in different types of process models. Examples of model types are deterministic machines and social constructs.
Kusters & Wortmann, 2007; Melão & Pidd, 2000
Elements of the model
Depending on the purpose, various elements can be included in the design. For example Organization and Customers.
Earl & Khan, 1994; Reijers & Limam Mansar, 2005; Limam Mansar & Reijers, 2005
Model quality There are criteria that measure the quality of a model.
Vernadat, 1996
Process design can have various uses, purposes, elements, techniques, formats etc. In order to have a good theoretical foundation for the process design, a great deal of literature on this subject is reviewed. The published articles discuss a variety of issues in enterprise and process design. The issues are structured under the headings below. For each issue a couple of notions or approaches that represent the total field are discussed.
The issues discussed are, consequently: • Presentation structure
• Purpose of the design • Level concept
• Foundation and framework of the model • General principles
• Techniques and tools to model processes • Types of process models
• Elements of the model • Quality of the model 3.2.1 Presentation structure
18 To identify criteria to choose a presentation structure, 11 interviews with 14 people were held. 4 FO’s were interviewed, 5 dFO’s and 4 IBPO’s were interviewed. Also one IT architect was
interviewed, both for IT alignment and for his extensive knowledge on the SCOR framework. The interviewees have different levels of knowledge in process design. Therefore, they cannot always picture what process design will result in, because of lack of experience. This makes it difficult to identify criteria. To give the interviewees a foundation to build preferences, requirements and criteria on, they were given six examples of top-level process models with different presentation structures.
Top-level process models are called Enterprise Process Maps (EPM) (Davis & Brabänder, 2007). This term emerged as companies started to model top-level processes in ARIS. Many companies are using this name, and also at Company X the name is established. What was showed to the interviewees, are presentation structures for the Enterprise Process Map. The presentation structure usually brings along a method, principles, definitions and/or criteria, which were explained to interviewees.
The interviews were performed by Company X’s Project Team Process Design and Governance. The Project Team Process Design and Governance consists of a PGB representative, the ARIS project manager and the author of this research.
First is described how and why those six examples were chosen. Next to that, the shortlist is given. In section 3.2.1.3, the criteria that were identified are given. Also, the shortlisted examples are given a score on those criteria.
3.2.1.1 Review presentation structures EPM
Both out of theory and practice frameworks, models and presentation structures were gathered. The examples from practice were presented in Business Process congresses (IDS Scheer
ProcessWorld 2007 and ARIS Userday 2007). This resulted in a list of 17 different structures. Because 17 is too much to show to the interviewees, a shortlist was made based on the following criteria:
– Strong representation of specific (other) industries
– No presentation structure (one modeling method had no presentation structure) – Strong IT focus (except the SAP solution map since it was already used by Group IT) – When models are similar, only one is chosen
Before the examples in the shortlist were discussed with FO’s, dFO’s and IBPO’s, two IDS Scheer consultants with broad experience in business process modeling checked the shortlist. These consultants confirmed that the shortlist is a good representation of what is used in practice. During the theory review, methods taking IT as leading were left out because there is a need for a focus on business processes, one of the objectives of this research (see section 1.1). Many of the available methods aim at designing business processes for IT architecture (Jennings et al., 2000; Kuo, 2004; Shaw et al., 2007; Sadeh, Hildum, Kjenstad and Tsjeng, 2001).
Table 2.3 Presentation structures EPM for Process Design
Method Goal/description Reason to include/exclude Source
BPTrends Strategy driven enterprise methodology. Consists of four steps: understand enterprise; define business process architecture; build process management capability; manage enterprise processes. Does not address how processes must be identified or presented.
Methodology is useful, will be used as basis for Company X methodology. Doesn’t provide a clear structure for process design, so excluded from the shortlist, but used as ‘overall’ methodology.
Harmon, 2007a
eTOM The Telemanagement Forum, consisting of USA
telecom companies, created a common business process architecture. The framework is very extensive in process descriptions and principles.
The process descriptions are based on the Telecom industry, which is not appropriate for Company X, so it is excluded. However, the principles and the way the framework is set-up is useful.
Telemanagement Forum, 2007
DoDAF The USA Department of Defense method consists of
three views: operational, systems/services and technical standards. The operational view comes close to the business process view. Describes organizational nodes and connectivity, information exchange, activities, rules and data. Not per se a process model.
Focus is on integrating three views, as this research takes process design as leading (other views can be aligned to processes when wanted) this method is less useful.
Department of Defense, 2007
Morgenwalp & Sage – EAF Sees architecture as a system of systems. Describes an organization in three dimensions: stakeholders, context and level.
Too many aspects taken into consideration; since simplicity is one of the organizational requirements, this method is considered too complex for Company X.
Morgenwalp & Sage, 2002
Primary Process The primary process is the transactional and transformational process, including the processes that manage disturbances and that are necessary to keep the whole up (adapted from: De Leeuw, 2004).
Primary Process is a well-known phenomenon in business science, a very helpful view in analyzing an organization, so useful to include in the shortlist.
De Leeuw, 2004
Porter’s Value Chain Porter uses the value chain to analyze sources of competitive advantage. Differences between
companies in how the value chain’s activities interact and how a firm performs them can be a source of competitive advantage.
Widely used, famous theory, so useful to include in the shortlist.
Porter, 1985
SEAF SEAF stands for SAP enterprise architecture
framework. This framework is developed by SAP,
Strong technology focus, three domains in the framework aren’t in scope of this research, so
20 based on other frameworks. It is composed of four
domains: business, data, application and technology.
excluded.
SCOR The Supply Chain Operations Reference model
describes the processes of a company in four levels. The first level consists of five management processes: plan, source, make, deliver and return.
Framework used by almost 1000 companies (www.supply-chain.org), the five steps provide another way of viewing a company, so useful to include in the shortlist.
Supply Chain Council, 2008
TEAF The Treasury Enterprise Architecture Framework
maps four levels of users (perspectives: planner, owner, designer, builder) are mapped against four views on processes (functional, information, organizational and infrastructure).
TEAF entails four views on processes, of which are three out of scope in this research. The four perspectives aren’t useful for Company X because it prescribes four levels. Excluded from the shortlist.
Department of the Treasury, 2000
Zachman’s framework Zachman maps in his framework six views on processes (data, function, network, people, time, motivation) from five different levels.
Is difficult and takes a lot of time to complete (Vail, 2002). Has a too strong technology focus (Harmon, 2007b; Harmon, 2008b) so excluded from the shortlist.
Zachman, 1987
Iyer & Gottlieb - FDA Zachman’s framework’s complexity inspired various authors to develop supporting methods (Vail, 2002; Iyer & Gottlieb, 2004). Iyer and Gottlieb provide the Four Domain Architecture for that purpose. It describes typical elements of an enterprise
architecture. This method is reviewed as an example of a support method.
Zachman is excluded from the shortlist, so Iyer and Gottlieb also.
Iyer & Gottlieb, 2004
HypoVereinsbank HypoVereinsbank uses a model where the processes are categorized in core, management and enabling processes (Earl and Khan, 1994). The most important processes in each category are modeled.
Included in the shortlist under the name Management, Core and Enabling processes.
Jascke, 2007
Credit Suisse Credit Suisse uses the categories core, management and enabling processes. In every core process, the next level is modeled. Credit Suisse has a model for each of the four organizational activities: Asset Management, Investment Banking, Private Banking and Shared Services.
The categorization is similar to Siemens (under the name Management, Core and Enabling included in the shortlist).
Küng, 2007
Cargolux Cargolux uses the same three categories in their process model as HypoVereinsbank and Credit Suisse:
Included in the shortlist, under the name Management, Core and Enabling.
core, management and enabling processes. Coca Cola Coca Cola has a strong emphasis on planning. A
business planning cycle links the different main processes. Main processes are showed in two levels.
The business planning cycle differentiates Coca Cola from other companies, so included in the shortlist.
Cunningham, 2007
Medrad Medrad uses Porter’s value chain as process model. Included in the shortlist under the name Porter. Ankomah, 2007 Siemens Siemens uses the three categories core, management
and enabling processes. In the core processes, the second level of each process is modeled.
Included because distincting management, core and enabling processes is potentially a useful
categorization, and because several companies use it. Under the name Management, Core and Enabling.
Siemens VDO, 2007
SAP Solution map This architecture is based on SAP solutions. It represents the business processes as seen from an SAP perspective.
Included because it is the most comprehensive process model present at Company X.
3.2.1.2 Shortlist presentation structures EPM
The pictures and descriptions of the shortlisted presentation structures are given in Appendix E. The list is as follows.
• Management, Core and Enabling • Primary processes
• Coca Cola • SCOR
• SAP Solution Map • Porter
3.2.1.3 Criteria and score
The following criteria were identified during the interviews. Supportive to PPI’s
– The extent to which Process Performance Indicators can be traced back to specific processes. (Strong from a business perspective)
Recognizable by the Company X business
– The extent to which Company X is recognizable in the model by users. (Strong from a business/user perspective)
RACI compatible
– The extent to which RACI elements can be formulated. RACI stands for Responsible, Accountable, Consulting and Informing. It is often used at Company X to define responsibility and accountability for a project, process, function, etc; and who should be consulted and informed about it. (Strong from a business perspective)
Translatability to SAP
– The extent to which the processes can be translated to SAP. This is necessary to ensure IT alignment. (Strong from a business/IT perspective)
Adherence to other companies
– The use of the structure by other companies for this purpose. (Strong from a maintainability/development perspective)
Reusability of existing documentation
– The extent to which existing process documentation fits in the presentation structure, so does not need to be made again. (Strong from a maintainability/asset utilization perspective)
Simplicity of the structure
– The extent to which the presentation structure is simple, easy to understand by a viewer. (Strong from a user perspective)
Insightfulness in what a process is
– The extent to which it is clear to the viewer what is meant by a process in the model. The structure can help in this matter. (Strong from a user perspective)
After the interviews, the Project Team Process Design and Governance scored the shortlisted presentation structures on the criteria. Table 2.4 lists these scores. In appendix E the score on the criteria is explained.
24 S u p p o rt iv e t o P P I’ s R e co g n iz a b il it y R A C I C o m p a ti b le T ra n sl a ti o n t o S A P A d h e re n ce t o i n d u st ry R e u sa b il it y o f d o cu m e n ta ti o n S im p li ci ty In si g h tf u ln e ss T o ta l
Management / Core / Enabling 2 3 3 2 3 3 3 3 22
Primary Process 2 3 3 2 1 3 2 3 19
Coca Cola 2 2 3 2 2 3 2 3 19
SCOR 3 1 3 2 3 1 2 2 17
SAP Solution Map 2 1 2 3 2 3 1 1 15
Porter’s Value Chain 1 1 2 2 2 2 3 1 14
This concludes that the presentation structure of Management, Core and Enabling is most suitable for Company X.
3.2.2 Purpose of the design
An enterprise can choose to design and model their processes for various reasons. Aguilar-Savén (2004) distinguishes four kinds of purposes:
1. Descriptive models for learning;
2. Descriptive and analytical models for decision support to process development and design; 3. Enactable or analytical models for decision support during process execution, and control; 4. Enactment support models to Information Technology.
The purposes of Aguilar-Savén cover many purposes as discussed by other authors. Using models for learning, as Aguilar-Savén calls it, is referred to by many authors as gaining understanding of processes (for example Kaplan & Simon, 1990; Nurcan et al., 2005; Danesh & Kock, 2005). Descriptive and analytical models for decision support to process development and design, covers most part of the redesign purposes, as discussed by many authors like Reijers & Liman Mansar (2005), Nurcan et al. (2005) and Hammer & Shampy (1993). Enactable models for process execution and control includes simulation purposes (Chatha & Weston, 2005), but also identification and analysis of (management) information about the process (Aguilar-Savén, 2004). Finally, the use of models for IT purposes is widely discussed in literature (Jennings, 2000; Kuo, 2004; Zachman, 1987; Leymann & Altenhuber, 1994). In the ‘90s, this was the main use of business process models (Davenport, 2004).
processes with the same goal and objectives differently. When employees execute a process differently from each other, it can have negative effects on output quality, certainty and efficiency (Ungan, 2006). Moreover, in large organizations it is often the case that multiple departments or locations achieve the same process goals through different processes (Scheer et al., 2006 describe many examples).
Standardization of processes can be useful for easier management of processes at different
departments or locations, for easier transfer of resources (staff), to quickly adapt processes (Scheer et al., 2006), to enable easier and successful outsourcing (Davenport, 2005), cost reduction through common IT (Hadfield, 2007) and to enable enterprise-wide ERP systems (Mitchell, 2006).
A more detailed look at purposes can be found in two papers of Reijers and Limam Mansar (Reijers & Limam Manser, 2005; Limam Mansar & Reijers, 2005). They identify many best practices in BPM that can be supported by process models. These best practices do not cover the whole range of purposes as Aguilar-Savén’s categories do, nevertheless are the contributions of Reijers and Limam Mansar very useful. They link purposes (best practices) to elements that should be incorporated in the model. This is further discussed in the section ‘elements of the model’.
What Company X wants to accomplish with process modeling is (Decision Paper ARIS, Walraven, 2008): 1. One database for all documentation about processes, information systems and controls 2. One integrated model to support decision support and consequence analysis
3. Structured, standardized, transparent, easily accessible and integrated information available at global scale
4. Compliance with the code Tabaksblat
Herein the following purposes as defined by Aguilar-Savén are recognizable (between brackets are the corresponding goals of process modeling):
• Descriptive and analytical models for decision support to process development and design (goal 1, 2 and 3);
• Enactment support models to Information Technology (goal 1).
The purpose decision support to process development and design is strengthened by the increased executive-level emphasis on business process management. When the executive board announced the so-called Priorities for Action 2008, it was recognized that business process management can support two of the four Priorities for Action: speed of implementation and Efficiency Improvements. Section 2.1.2 explains how it supports this Priority for Action.
When looking at the current (research-related) problems of Company X and the objectives of this research, standardization of processes is also a goal. Processes that are heavily supported by IT are useful to standardize because of the common systems strategy (see IT strategy). Examples are production processes, but also Customer Relationship Management.
3.2.3 Level concept
Designing processes for a large organization results in a great amount of models. The best way to structure a great amount of content and detail, while still allowing the higher levels to present a summary view, is to structure the information in multiple levels (Telemanagement Forum, 2007). Levels in process design are the result of hierarchical decomposition (Harmon, 2007a, Telemanagement Forum, 2007).
26 To visualize process levels, often a pyramid is used. The following figure presents, for explanatory purposes, the level concept of HypoVereinsbank (Jascke, 2007).
GROUP Process Types
Partial Processes
Detail Processes Main Process Groups
Main Processes Leve l 5 Leve l 4 Leve l 3 Leve l 2 Leve l 1
Figure 3.1 Level Concept HypoVereinsbank
The number of levels to use for the Company X Business Process Framework may depend on several aspects. When governance is aligned to the levels, there is in principle one person responsible for a process at a level, reporting to the person responsible for the higher level. This means that fewer levels will result in a flatter organization. However, it must be possible to capture existing processes in a certain number of levels.
At Company X, there are already three levels defined, the lowest levels. Because of that, the number of levels to use in the Company X BP Framework remains a very practical question. How many levels are needed to decompose level 1 in such a way that it logically links to the levels that already are designed? Interviews with delegated Functional Owners, which were held before the processes were actually defined, tell that it is expected that two levels are needed on top of the three existing levels. This results the (provisional) use of five levels.
3.2.4 Framework and foundation of the model
A lot is written about the foundation of a model. Many frameworks have been developed. A framework encompasses or is a foundation for a model. For example, Kettinger et al. surveyed 25 frameworks (Kettinger et al., 1997). Also many authors wrote something about the foundation of the model, without developing a framework around it. Those notions are discussed first.
Since a model is a representation of a part of reality (Kusters & Wortmann, 2007), models of the same process can have different formats. It is also possible that two models of the same parts of reality are different, due to modeling ambiguity (Kusters & Wortmann, 2007). It is easy to imagine that the foundation of the model isn’t always easy to recognize. The same foundation can result in different models, and different foundations can lead to the same model. Nevertheless, it is useful to discuss the foundation of the model, since it certainly influences the model. Multiple authors stress the necessity of strategic alignment (Earl et al., 1995; Armistead et al., 1999; Nurcan et al., 2005). The basic idea is that the model must tell the viewer how process goals are achieved. This ‘how’ question is (or at least must be in line with) the corporate strategy. Danesh argues that models must be founded on communication flows.
Company X’s ERP system supports the lower three levels of the level concept, so the three lowest levels are based on IT. The scope of this research is level 1 and 2. This means that a top-down approach (strategic foundation) can be applied here. It must be kept in mind, however, that level 2 and level 3 can be connected. To align the process design with the corporate strategy, the level 1 processes must tell a viewer how the company’s mission is executed. So, when designing processes, the first question must be; what processes are executed to make the mission come true.
There are many frameworks present to guide a company in the way to process design. They vary in abstractness. For example, Harmon (2007a) presents a high-level framework. It starts at the strategy, through the steps understand enterprise; define BP architecture and build process management capability an organization must be able to manage their processes. Very detailed frameworks are SCOR (Supply Chain Council, 2008) and eTOM (Telemanagement Forum, 2007). Both frameworks give principles, levels and standard processes in a great level of detail.
Abstract and detailed frameworks do not exclude each other. Harmon’s BPTrends Enterprise
Methodology is very useful as a high-level methodology (as suggested in the overview of process design methods in table 2.3), which prescribes the development process of Company X’s Business Process Framework. Because this is an important issue, there is an elaboration on Harmon’s methodology in section 3.5. SCOR and eTOM are useful as example frameworks, using the format and principles. They cannot be used as example process designs, since they do not apply to the organizational requirement that Company X is recognizable in the model. That SCOR is not recognizable is a result of the interviews; that eTOM is not recognizable is because a framework for the telecom industry is not easily applicable to the fast moving consumer goods industry.
3.2.5 General principles
There are general principles that apply to a business process framework. Including general principles in a framework is very useful to help the users of the framework gain more understanding of processes. These principles are described in eTOM (Telemanagement Forum, 2007). There are a few other authors that describe aspects of these principles. Where applicable, other sources are given. The rest is
described in eTOM.
3.2.5.1 Characteristics of a process
According to eTOM, a business process in general will have the following characteristics: - It has a goal
- It has specific inputs - It has specific outputs
- It transforms inputs into outputs - It uses resources
- It consists of a number of activities that are performed in some order in time (a succession of elements/activities)
- It creates value for the customer, or it enables a value adding activity. The customer may be internal or external.
- It may affect more than one organizational unit.
Company X’s project team Process Design and Governance added the following characteristics: - It is related to a physical or virtual space
- It has acknowledged ownership and a route of issue resolution - It can be measured
- It has one or multiple triggers - It may influence risks
- It may have links with and appearances in other processes/levels
