Master thesis:
‘Towards a generic engineering change management process at Philips
Healthcare’
Msc. Technology management Rijksuniversiteit Groningen Student: Eelco Lippinkhof Student id: 1506250 Date: 26-10-2009
Philips supervisor: Gerard van Ballegooyen RUG supervisors: Ashwin Ittoo
MANAGEMENT SUMMARY
At Philips Healthcare an urgent need for business process standardization among business units (BUs) rises. This is because company wide software tools are being implemented which require the business processes of the involved BUs to be similar. Also there is a need for transparency among the BUs, so BUs can learn from each other and establish a best practice business process. To fulfill these needs this research will present a generic business process for the BUs; cardio vascular, general x-ray, magnetic resonance, and clinical informatics. This generic process is constructed with the use of an innovative methodology which is presented in this paper. For the creation of a generic business process, undesired differences between the processes have to be resolved. Differences are sought in the involvement of roles (organizational functions like teams, departments, or persons) in the tasks of the business process. For example if BU1 has team 1 involved for task X, and BU2 has team 2 involved in task X then we will try to solve this difference in the generic process. Other kinds of differences like, differences in the order of tasks, and differences in information flows are neglected in this research.
The business process that is investigated is the engineering change management (ECM) process. This process starts with a structural customer complaint coming in form various sources (helpdesk, field engineers etc.) and ends with an engineering change (EC) which is a change to the designs of the product and the production process. For some important complaints (e.g. safety related complaints) also a field change order (FCO) is executed, which updates already sold products in the field.
The ECM processes of the four BUs are modeled in flowcharts and RACIs to enable further analysis. Information is mostly obtained by interviewing and by document analysis. Flowcharts are used for communication purposes during interviewing, and the RACIs provide the basis for detailed analysis on process differences. RACIs show in a tabular format which role is responsible, accountable, informed or consulted for a specific task in a business process.
ABSTRACT
INDEX
This thesis is structured as follows. Section 1 will give an introduction to the subject. It will explain what business process is investigated and it will provide Philips specific background information which is relevant for this research. Also a problem statement is formulated in this section. In Section 2, a literature review is provided which shows what literature is useful and which will be used in this paper. The 3rd Section will explain the methodology which is used to achieve the goals of this research. The 4th Section elaborates on the analysis at Philips Healthcare. It shows the research data and how the methodology is applied on that data. Section 5 provides the results of this analysis, and Section 6 provides a discussion and issues for further research.
1. INTRODUCTION ... 6
1.1 The business process ... 6
1.2 The organization ... 7
1.3 Research outline ... 9
2. LITERATURE REVIEW... 11
2.1 Generic ECM processes... 11
2.2 ECM influence factors... 13
2.3 Process comparison ... 16
2.3.1 Business processes models for comparison... 16
2.3.2 Modeling languages ... 17
2.3.3 Methods for finding similarities and differences ... 18
2.3.4 Similarities to enable authorization differences ... 20
2.3.5 Resolving differences ... 20
3. METHODOLOGY... 22
3.1 Research design ... 22
3.1.1 Conceptual model ... 22
3.1.2 Research questions ... 26
3.2 Data collection and analysis... 27
3.2.1 Which roles and tasks are comparable among the four BUs? ... 27
3.2.2. What authorization differences and similarities exist among the four BUs?... 28
3.2.3 What authorization differences are needed to cope with BU specific factors? ... 30
3.2.4 What solution to overcome authorization differences has the most positive impact on overall ECM performance? ... 31
4.4.1 Primary process... Fout! Bladwijzer niet gedefinieerd. 4.4.2 Control process ... Fout! Bladwijzer niet gedefinieerd. 4.5 Determining best practice ... Fout! Bladwijzer niet gedefinieerd. 4.5.1 The primary process... Fout! Bladwijzer niet gedefinieerd. 4.5.2 The control process... Fout! Bladwijzer niet gedefinieerd. 4.6. Syntheses ... Fout! Bladwijzer niet gedefinieerd.
5 RESULTS ... 33
5.1 Generic ECM process ... Fout! Bladwijzer niet gedefinieerd. 5.2 Validity ... Fout! Bladwijzer niet gedefinieerd. 6. DISCUSSION & FURTHER RESEARCH... 34
6.1 Discussion ... 34
6.2 Limitations and further research ... 34
1. INTRODUCTION
Business processes are, according to Davenport (1990), “a logically related set of tasks performed to achieve a defined business outcome”. However this does not mean that all business processes with the same defined business outcome are similar. Differences still can exist in business processes when one would expect they could be similar because their outcome is the same. Several scenarios can exist in which those differences have to be resolved and standardization of those business processes is desirable. For e.g. a single business process could be desirable during organizational mergers. Another situation is the implementation of a company-wide information system which requires business units (BUs) to resolve the differences so that the information system is successfully realized. Furthermore, standardization of business processes can have performance benefits when the parties involved learn from each others way of doing and determine a best practice process. Differences in business processes can originate from various causes. The existence of some differences are justifiable and in fact, required, for example to deal with specific factors that need different handling mechanisms. However, in other cases, the existence of these differences could be merely due to a lack of consensus. In the latter scenario, differences are not justifiable.
At Philips Healthcare, a large manufacturer of medical equipment, there is an urgent need for standardized processes. The factors spurring this standardization are: To facilitate the implementation of company-wide information systems, to improve transparency among the different BUs and to create a best performing generic process for all the BUs. The aim of this research is to address this need by conducting a study on the differences among the BUs for the ECM process and to see what differences can be overcome. This research aim is significant because: currently the process differences are not known and no insights are available on which process is the best.
1.1 The business process
produce two outputs. An engineering change (EC) and a Field Change Order (FCO). An engineering change is a change to the designs of a product and to the production process to create products which do not contain the specific error, as pointed out in the initiating customer complaint, anymore. An FCO, on the other hand, is an update for the products already in the field to fix the problem. That is, an EC fixes issues for products under production from now on, while an FCO deals with problems for products already in the field. An FCO is always performed together with an EC to ensure that new products will not contain the specific error anymore. The input and output of this ECM process at Philips is similar across all its business units (BUs), however the implementation of this process differs among BUs.
Figure 1: Input and outputs of the investigated process at Philips Healthcare
1.2 The organization
This research includes the ECM processes of four business units (BUs) from Philips Healthcare, namely Cardio vascular (CV), General X-ray (GXR), Magnetic resonance (MR), and Clinical Informatics (CI). CV, GXR, and MR are all BUs from the BU Imaging systems, while CI is part of the BU Healthcare Informatics. Figure 2 shows the organogram of the BUs which are involved in this research. The focus is on these business units because they can be seen as the core of the Philips organization. Over the years, lots of acquisitions have taken place which has resulted in more business units. This research however limits itself to these traditional Philips BUs and exclude those that were created as a result of acquisition.
ECM process at Philips Healthcare FPR
EC
Figure 2: Organogram of involved BUs
In the BU CV, X-ray imaging equipment for diagnosing cardiovascular diseases is developed and manufactured. Cardiovascular diseases refer to the class of diseases that involve the heart or blood vessels (arteries and veins). The imaging equipment produced by the BU CV is used to make images of these blood vessels for diagnosing the disease
but also for creating images during treatment on the operation table. CV currently holds around 35% of the market share worldwide for these products. Figure 3 shows CVs latest product the Allura Xper. The development and production of these systems both take place at Philips Healthcare in Best in the Netherlands.
Figure 3: CVs product Allura Xper
The BU GXR also develops and manufactures X-ray machines but for purposes different than CV. GXR produces a broad variety of X-ray equipment for a varied range of applications. They produce several imaging equipments for Radiography, which is used to diagnose broken bones. Also several types of equipment for fluoroscopy are produced. Fluoroscopy is used to obtain real-time moving images of the internal structures of a
patient through the use of a fluoroscope. Furthermore also movable C-bows are produced which can take X-ray images during the operation of a patient. Development and production takes place in Best and Hamburg Germany. 50.000 systems are currently operating in the field. Figure 4 shows one of their X-ray imaging equipment which can take images of bones when a patient is lying down or standing.
The third BU which is involved in this research is the BU MR. MR produces MRI scans, which stands for Magnetic Resonance Imaging. MRI scans provide great contrast between the different soft tissues of a body in their images. It is therefore often used in neurological (brain) and oncological (cancer) imaging. There are 2 variants of this
equipment:
1) A single cylinder in which the patient slides into, and 2) A double cylinder placed on top of each other where
the patient is placed in the middle.
These two types of scanners come in several strengths which are measured in Tesla. Strengths from 1,5 to 3 Tesla are used in these kinds of equipment. The development takes place in Best, while some production is also occurring in Cleveland USA and Helsinki Finland. Figure 5 shows an example of an MRI scanner.
Figure 5: MRs product the MRI scanner
The last involved BU is CI. CI produces workstations which process data into images for different BUs of Philips Healthcare. Their products consist of
relatively standard computer hardware, like hard disks and processors. However the software on the workstations is developed and created by CI. This software processes the raw data, which comes from the imaging equipment, into pictures or moving pictures. CI is a smaller BU than the other BUs. They produce 5 types of workstations which are used by other Philips BUs. Some products are also sold to external companies.
Figure 6: CIs image editing workstations. 1.3 Research outline
The four business units mentioned in the previous section all perform ECM. However, within Philips Healthcare little is known about the similarity of these business processes, and if the ECM process among the four BUs can be standardized into one generic process. Therefore, the aim of this research is first of all to provide insights into the differences and similarities of the ECM process of the four BUs. Secondly, the aim is to determine a best practice generic ECM process which can be applied at the four BUs. These goals will be realized by presenting an innovative approach to business process standardization, which can form the basis for standardization of non ECM business processes as well. Therefore this research can be seen as the first step in creating process standardization among BUs within Philips Healthcare. To realize these goals this research contributes to the need of Philips to provide more transparency among the BUs which can benefit organizational learning. Also, more standardized business processes will simplify the implementation of company wide information systems.
To fulfill the goals of this research, the following research question has been drawn up:
After studying literature more detailed questions arose on how such a generic process can be created. Literature on generic ECM processes exists, but what literature is helpful in determining a generic ECM process for Philips? In what way should information about the ECM processes be collected and modeled before comparison can take place? How can differences between the business processes of the BUs be determined and solved? And, what parts of the process cannot be made generic because of BU specific factors which require a different approach?
2. LITERATURE REVIEW
This section discusses literature relevant to our research. We start by reviewing literature on generic ECM processes in Section 2.1. This is done to determine common tasks in ECM processes which will be helpful in the determination of tasks at the four BUs later on in this research. Also, these generic ECM processes from literature provide insights in the functioning of an ECM process which adds to the total understanding of this business process. Section 2.2 discusses literature on company specific influence factors relevant for ECM. These influence factors require differences in ECM processes to handle ECM optimally for that type of business. This means that when these factors apply, it is not desirable to overcome business process differences, because it might affect the performance of the process negatively. The next section, Section 2.3, shows what literature is useful for comparing a business processes in order to create a generic ECM process. First of all it is described how a business process can be modeled to enable comparison. Secondly, it will be explained what methods are used to find similarities and differences between business processes. In the end of this section, literature on solving these differences to create a generic ECM process is presented.
2.1 Generic ECM processes
Several researchers have identified generic ECM processes in literature (Jaratt et al. 2006; Tavcar et al. 2005; Riviere et al. 2002). These generic ECM processes all describe on a high level which tasks are performed in the ECM process. This section explains those generic ECM processes to provide insight in the tasks which are essential to perform ECM and to provide a general understanding of generic ECM processes.
The first generic ECM process is from Jaratt et al. (2006) and is shown in figure 7. They determined three phases which all have several tasks. Their process starts with a change trigger. This change trigger can for example be information on a structural failure of a product. When this change trigger is identified an engineering change request is raised. This is a formal document which describes what has to be changed about the product. Based on this document, an identification of possible solutions is made. This means that a list of possible solutions is created which can solve the problem of the product. Subsequently, the risk and impact of every possible solution is assessed. These steps provide a change board with all the needed information in the next step, which is called selection and approval of a solution by a change board. This Change board is a multi disciplinary team including all the roles (e.g.: team manager, engineer) who are involved in the change. This team assesses the problem and selects a solution. Once a selection has been made by a change board the selected solution is implemented by engineers. The final step is to review the ECM process and determine potential improvements in handling future ECs. The execution of such an entire ECM process can be very time consuming according
to Tavcar et al. (2005). Throughput times of several months to a year are not unusual in ECM practice.
Riviere et al. (2002) also created a generic ECM process which divides the ECM actions into three stages. The stages are: 1) EC proposal, 2) EC investigation, and 3) EC embodiment. The EC proposal stage shows the initialization of the ECM process and a pre-feasibility study. Different departments’ representatives assess the risks and costs of a problem associated to a product. Based on the risks and costs, they decide if it is necessary to find a solution for this problem. In the second stage all roles affected by the EC devise a set of potential solutions. From these solutions the best one is selected by a multi-disciplinary team by looking at the impact in terms of cost/risks and feasibility of the solutions. In the third stage, the solution is implemented. This is done by updating the design documents of the product, by notifying customers and suppliers, and by changing the production lines to manufacture the new improved product. This generic ECM process is shown in figure 8.
Figure 8. A generic ECM process by Riviere et al. (2002)
The third generic ECM process which can be found in literature is from Tavcar et al. (2005). This process is a higher-level description then the other two (of Riviere et al. 2002, and Jarrat et al. 2006). However, its description is very similar to the one of Riviere et al (2002). Tavcar et al. describe a similar initialization of the ECM process by an idea change request which can be a structural product error. Secondly, they distinguish a change preparation task, which investigates the problem. The third task approves the change. They decide on changing the product based on the information provided by the previous task. Tavcar et al. (2005) also describe that for this task usually a multi disciplinary team is most suited. Once it is decided to change the product, the products documentation is updated and the change is implemented in production. Figure 9 describes this generic ECM process.
General change management literature (Ibbs et al. 2001) describes a process which applies for any kind of change management system. Three tasks are shown which are similar to tasks of the three other generic ECM processes. These are: Recognize change, Evaluate change, and implement change. ‘Recognize change’ for example is similar to the ‘idea change request’ task of Tavcar et al. (2005), or the ‘EC proposal’ stage of Riviere et al. (2002). The task ‘evaluate change’ approves a change. This is similar to the ‘change approval’ task of the process from Tavcar et al (2005). Also the task description of ‘implement change’ shows similarities with the other processes which describe this task. However Ibbs et al. (2001) also incorporate two tasks in their models which are not present in those of Riviere et al. (2002), Tavcar et al. (2005) and Jarrat et al. (2006). These two tasks play an important role in maintaining the change process and cannot be suitably positioned within the generic ECM process. These tasks are: promote a balanced change culture, and continuously improve from lessons learned. Although these tasks are not directly needed to create an EC; they ensure the proper functioning of the process. Because of the existence of these tasks, a distinction can be made between a primary ECM process which shows a sequence of tasks to create an EC and a control process which is supportive for the ECM process. The tasks that comprise above-mentioned ECM processes are summarized in table 1.
Jaratt et al. (2006) Riviere et al. (2002) Tavcar et al. (2005) Ibbs et al. (2001) Primary
process
1 Change trigger ECM initialization Idea change request Recognize change 2 Request ECR Pre feasibility study Change preparation Evaluate change 3 Identify possible
solutions
Impact and feasibility study
Change approval Implement change 4 Risk/impact
assessment of solution
Selection and solution definition
Change of documentation 5 Select and approve
solution
Update documentations Implementation in production 6 Implement solution New solution
notification
7 Review change process Embody new solution Control process 1 Promote balanced change culture 2 Continuous improve process Table 1. Overview of ECM tasks
2.2 ECM influence factors
section is to identify these factors that influence ECM processes. Hereby the focus is on formal criteria and not on factors that relate to culture, behavioral or change management aspects. These formal influence factors will be used in the analysis to explain differences in ECM processes among the BUs.
The first influence factor we identify in literature is product complexity. The complexity of products which are produced by a company is seen as an important influence factor for ECM processes according to Tavcar et al. (2005). They determined four types of product complexities, each with its own influence on the way ECM processes should be organized to perform ECM effectively. These complexities are:
A) Construction complexity B) Technology complexity C) Number of variants D) Number of parts
Construction complexity refers to the complexity of constructing the product. For example a camera mechanism is complex to construct and therefore exhibits construction complexity. This factor can be measured by looking at assembly times and amount of resources and costs involved at assembly. When these values are high a product exhibits construction complexity. A product is technologically complex when it contains/embeds specialized knowledge, for example x-ray technology. The level of technological complexity can for example be measured by the education level of the people who work on the product. High technology complex products require highly skilled people. When a product is available in many variants it can be seen as complex in terms of ‘number of variants’. The amount of parts of which a product contains shows how complex it is in terms of ‘number of parts’.
According to Tavcar et al. (2005) each type of complexity requires a sound arrangement of selected phases in the ECM process. When a product is complicated from the construction and technological points of view, the ECM process requires a detailed preparation of ECs, while products composed of many parts and variants are more complicated in the later phases of the ECM process. Figure 10, which is obtained from Tavcar et al. (2005), shows where these complexities influence the generic ECM process. The larger a specific complexity is the larger the influenced task in the ECM process will be in terms of people involved, the amount of checks and subtasks.
Another influence factor was identified by Huang et al. (1999). In their survey among 100 companies in the UK that perform ECM, they discovered a correlation between the size of a company and the scope of ECM processes. For large companies more rigorous and formal ECM processes where in place. They saw that large companies have full time EC coordinators and multi disciplinary teams involved, while smaller ones incorporated ECM activities in their daily normal operations. Thus, company size can also be treated as an influence factor. This factor, company size, influences the amount of tasks and people involved in the ECM process.
Huang et al. (1999) also showed that finding a balance between effective and efficient ECM processes is a major concern in ECM. Effectiveness assesses whether or not changes are necessary and beneficial, while efficiency strives to get an optimal use of resources such as time and money when handling an EC. Designing a process with numerous checkpoints can be very effective. However, such a highly effective system creates lots of inefficiencies because it consumes a lot of resources. According to Pikosz et al. (1998) a company can focus on efficiency when they want fast throughput times of ECs and they can focus on effectiveness when they want the ECs to be of high quality. For example companies that produce their products in large amounts usually have a time focus for their ECs, because large quantities of defective products will be produced when the EC process is not fast in correcting that error. Companies can have a quality focus when they produce a safety critical product. In that case lots of checks have to be performed to ensure that the improved product does not form any safety risk. These extra checks will increase the throughput time of an EC. Therefore, the company focus, whether on quality or throughput time, determines whether they should strive for effective or efficient ECMs. Inherent, justifiable differences among ECM processes can be attributed to these different areas of focus. This can result in differences in the ECM processes like the amount of people involved, the amount of checks and subtasks.
ECM influence factors Measurable by Effects on ECM Construction complexity
(Tavcar et al. 2005)
- assembly time of product - number of assembly employees
of product
The scope of the process in the first phases of ECM Technology complexity (Tavcar
et al. 2005)
- education level The scope of the process in the first phases of ECM Number of variants (Tavcar et
al. 2005)
- number of variants The scope of the process in the last phases of ECM Number of parts (Tavcar et al.
2005)
- number of components The scope of the process in the last phases of ECM Company size (Huang et al.
1999)
- Amount of employees
- Amount of revenues and costs
The scope of the process throughout the entire ECM process
Time focused vs Quality focus (Huang et al. 1999)
- Large batches
- Safety importance: amount of governmental regulations
The scope of the process throughout the entire ECM process
Table 2. ECM influence factors
2.3 Process comparison
The previous section covered generic ECM processes and factors that influence them. This section will show how business processes can be compared to derive a generic process. To derive a generic ECM process for Philips Healthcares 4 BUs, the business processes of the 4 BUs under investigation have to be compared to find their differences. This section describes methods mentioned in literature to compare the business processes of the four BUs. Section 2.3.1 shows how a business process like ECM can be modeled to enable comparison. Section 2.3.2 describes what methods exist to determine the differences and similarities of the compared processes. The final section 2.3.3 illustrates what methods are used to overcome the business process differences so a single generic process can be established.
2.3.1 Business processes models for comparison
Before the ECM processes of the BUs can be compared, the business processes have to be modeled in a modeling language. According to Axenath et al. (2005) it is well-accepted that there are different aspects of business processes that can be modeled and investigated independently of each other. Figure 11 shows the three basic aspects of a business process, which are:
1) The organizational aspect. This aspect of the business process describes the organizational structure and, in particular, the resources, and the way these resources are involved in the business process. It mainly defines the static part of the organization such as departments and teams and the distribution/allocation of tasks to the departments/resources.
3) The informational aspect. This aspect defines the information involved in a business process as well as the propagation of information among different tasks. Information, in this case, can be seen as documents which represent some peace of information.
The tasks which are being performed in a business process can be seen as the general part of the three aspects. This is because the tasks are common to all aspects. The tasks are the activities which have to be performed to achieve the business outcome of the business process. All three aspects deal with the tasks, however each with another focus. Figure 11 shows how the three aspects each focus differently on the tasks.
Beha vioura l a spect Inform ation al as pect Tasks B A C --- - ---
---Figure 11: The three aspects of a business process.
Because different business process aspects exist, the analyst should carefully consider what information should be obtained for analysis. The next section shows what modeling languages will be used to obtain the business process information which is needed for this research. 2.3.2 Modeling languages
Concerning modeling languages to represent business processes, Axenath et al. (2005) observe that no modeling language is adequately representative and expressive to model the three aspects of a business process. A modeling language is only able to represent information in a certain aspect. Therefore, it is crucial to first elicit the types of information that will be modeled in the business process to make the selection of an appropriate business process modeling language easier and more informed.
1) RACI tables 2) Flowcharts
A RACI table is a suitable representation formalism to both depict and analyze a business process along the organizational dimension (Smith et al. 2007; Ramzi et al. 2008). RACIs show which tasks are assigned to which roles, where as mentioned before, a role can be a single person, team or department. The tasks are listed in the table rows (i.e.: horizontal axis) and their respective roles are in the table’s columns (i.e.: vertical axis). Therefore, a table cell illustrates the involvement of a particular role (in the corresponding table row) to the task (in the corresponding table column). A cell value can be either R, A, C, I. The ‘R’ stands for ‘responsible’, indicating that a specific role is responsible for executing the particular task. An ‘A’ stands for ‘accountable’, denoting the role which is ultimately accountable for completing the task. The ‘C’ stands for ‘consulted’ which is a role that must be consulted before a decision or activity is finalized. The ‘I’ means ‘informed’ and designates a role or function that must be notified about the completion or output of a task. A RACI table therefore shows for every task of a business process who is responsible, accountable, consulted and informed.
According to Vergidis et al. (2008), flowcharts are suitable modeling tools to depict the tasks of a business process. Flowcharts are however not suited for formal mathematical analysis but they are suited for situations in which fast and informal information about tasks has to be represented. They require no technical knowledge to understand them. This makes them suited to communicate the business process among different stakeholders of the business process. Because flowcharts are suited for communication purposes this modeling language will be used to obtain a clear picture of the ECM processes. The information in the flowcharts will subsequently be used to construct the RACIs, which are suitable for detailed analysis in the organizational aspect of a business process.
2.3.3 Methods for finding similarities and differences
Once the business processes are modeled they can be compared to find similarities and differences. Scientific literature about previous studies attempting to detect similarities and differences in business process is scarce. More research efforts were geared towards identifying similarities, while overlooking the equally important activity of detecting differences between business processes.
Ehrig et al. (2007) proposed an approach to measure the degree of similarity between business processes, by using petri nets and ontologies. However, their approach failed to capture exact differences between business processes. A technique of Van Dongen et al. (2007) calculates the degree of similarity between two business processes, and also ignores the determination of differences.
describe differences in the organizational perspective of business processes and they guide the analyst in the visual inspection of the modeled business processes. More specifically, Dijkman provides an overview of the differences in the involvement of roles in the execution of tasks, which they call “authorization differences”. Because the technique of Dijkman is based on visual inspection, a modeling language which enables visual inspection should be used to represent the business process. Both flowcharts and RACIs, which are used in this project, enable visual inspection which makes them suitable for the Dijkman analysis.
The three categories of differences, which Dijkman lists, across business processes collectively are called “authorization differences”. These three categories are:
- Different roles. This authorization difference exists if a task is assigned to different roles in different business processes for the same tasks, i.e.: different roles are involved for the same tasks in different business processes. Figure 12.i shows an example of this type of difference. Evaluate request is the task and adm. worker and 1st adm. worker are the roles
- Single role vs. collection of roles. This authorization difference exists if a task is assigned to a single role in one process and assigned to multiple roles in the other. Figure 12.ii shows an example of this type of difference
- Different collections of roles. This authorization difference exists if a task is performed by one collection of roles in one process, to be performed as an interaction between those roles, and to another collection of roles in the other process. Figure 12.iii shows an example of this type of difference.
Figure 12: Examples of authorization differences between similar business processes.
Besides finding differences, Dijkman also describes rules to find similarities between two business processes. This method, also based upon visual inspection of modeled business processes, relies on two criteria to check whether tasks are similar. The two criteria are:
2. The way in which the effect is achieved must be the same. This means that every task and the involvement of roles should be the same before they can be called similar.
Dijkman explains that tasks or collections of tasks are classified as black-box equivalent when they meet criteria 1. When criteria 1 and 2 are met, then they are white-box equivalent. White box equivalent implies that the tasks are completely similar, while black-box equivalent means that the effect of the compared tasks is the same.
It is the responsibility of the analyst to decide whether the tasks should satisfy criterion 1 (i.e.: black box equivalent) or both criteria 1 and 2 (i.e.: white box equivalent) to be deemed similar. Besides tasks, the roles of different business processes can also exhibit similarities. Roles are composed of one or more organizational functions. When two roles contain similar organizational functions, they are considered similar, although they may be named differently. For example project team X consists of three organizational functions: a team leader, an engineer, and an administrative worker. When team Y consists of these same organizational functions, team X and team Y are similar roles.
2.3.4 Similarities to enable authorization differences
Finding role and task similarities among business processes is an essential first step which has to take place before the determination of authorization differences can take place. Authorization differences can only be found when similar tasks and roles are being compared with each other. In figure 12 it can be seen that the roles and tasks are similar in the comparison of authorization differences. An authorization difference involves similar roles and similar task for the compared business processes. The way those similar roles are involved in the similar task however differs among the compared business processes for an authorization difference.
2.3.5 Resolving differences
After identifying the similarities and differences across the various business processes, the next logical step in devising a generic process that encompasses the individual ones is to try
reconciling their individual differences. However, it should be noted, as already mentioned, that some differences should exist in order to perform optimal for that specific business unit. This section will show how identified differences can be resolved.
show what impact specific differences in authorizations have on performance. For example heuristic X says that it is better to use two roles for the execution of task A instead of one role, because it improves throughput time. Reijers et al. (2005) summarize 29 of these best practices with their corresponding performance changes.
These performance changes are linked to performance aspects of the devils quadrant (Brand et al. 1995) which is shown in figure 13.
Figure 13: Devil quadrants aspects of business process performance (Brand et al. 1995)
3. METHODOLOGY
As mentioned in the introduction, the aim of this research is the determination of a generic ECM process and to provide insights into the differences and similarities of the ECM processes of the four BUs. Another of our contributions is an innovative approach for the creation of a best practice generic ECM process. Best practice means that the best process parts from the cooperating BU’s CV, GXR, MR, and CI are selected This section will elaborate on the methodology to realize these goals of this research.
This chapter is organized as follows. We start with Section 3.1 which discusses the design of the research. This includes a conceptual model which explains the concepts used in this research and their interactions. From this conceptual model detailed questions are formulated which will be answered to fulfill the goals of this research. Section 3.2, called ‘data collection and analysis’, explains in detail how these questions will be answered in this research. Also the way data is obtained at Philips Healthcare is explained in this section.
3.1 Research design 3.1.1 Conceptual model
In the introduction section concepts like ECM process and business process have been introduced, while the theory section explained concepts like authorization differences and influence factors. Our motivation in this section is to show the synthesis that exists between all the concepts and theories introduced thus far. These relations are shown in a conceptual model as shown in Figure 14. The purpose of this conceptual model is to provide a clear understanding of the interactions of concepts and to show how these are involved in the realization of the goals of this project. Also, later on in this section detailed steps to fulfill the goals of this research are derived from this conceptual model.
Five groups of related concepts can be identified from the conceptual model, namely: 1. Process concepts,
2. Performance concepts, 3. Influence concepts, 4. Authorization concepts, 5. generic process
They are described next. 1. Process concepts
The process related concepts show the concepts which relate to business processes. It can be seen that an ECM process is a business process consisting of a primary process and a business process. A primary process shows a sequence of tasks to create an EC and a control process shows the tasks which are supportive for the ECM process. The control process comes into play during the execution of the primary process, for example when abnormalities occur in the primary process.
research will only deal with the organizational aspect, which shows which roles are involved in the execution of tasks. The other aspects have been neglected to limit the scope of this research. The choice has been made for the organizational aspect because theory (Tavcar et al. 2005) showed that there are many differences in resource involvement among different ECM processes in companies. The informational aspect of ECM processes show less differences in theory. Pikosz et al. (1998) say that the information which is processed in ECM is to a large extent the same. Also the sequence of ECM tasks shows no extreme differences when we look at the generic ECM processes of the theory section. Furthermore, explorative interviews at Philips Healthcare indicated that most differences could be expected in the organizational aspect of a business process. This organizational aspect has a link with the authorization group of concepts. These concepts will be discussed later on in this section.
2. Performance concepts
A performance criteria can consist of four types, which are derived from the devils quadrant, exist; costs, quality, time, and flexibility. The ‘performance criteria’ concept links with the business process concepts because performance criteria provide measurements for business processes. Also, the concept ‘best practice heuristics’ can be seen in this group of concepts. This ‘best practice heuristics’ concept describes for several differences in business processes what the corresponding performance changes are. The ‘best practice heuristic’ concept has a link with the concept ‘solved authorization’ of the authorization concepts. This is because the best practice heuristic concept is used to solve authorization differences by showing what solution has the best performance impact. This concept will be explained in more detail at the authorization concepts.
3. Influence concepts
The influence concepts consist of six concepts which all are influence factors. These factors explain why some differences in ECM processes among BUs are needed. Resolving differences which are related to these influence factors is not desirable because it might affect performance negatively as is discussed in the literature review. It can be seen that the concept ‘justifiable difference’ is linked to at least one influence factor, which means that justifiable differences have a justified reason to be different. These justifiable differences will be explained in more detail at the authorization concepts.
4. Authorization concepts
5. Generic process
The final concept, the concept generic process, has a connection with three other concepts. A generic process first of all can consist of solved authorizations. These solved authorizations are non-justifiable differences which are solved with the use of best practice heuristics. This means that the best role involvement, which is concerned in the difference, is selected for implementation in the final generic process. Secondly the generic process can consist of justifiable differences. These differences are not resolved, because these differences can be linked to influence factors and are therefore required for optimal functioning for the specific BU. Therefore, these differences will not be generalized in the generic model but they will show up as exceptions for specific BUs. The third connection of the generic process concept is with the authorization similarities concept. When two role involvements are compared and they turn out to be similar then this role involvement is used in the generic process. In that case, no further analysis is needed because the role involvements are already similar, i.e. generic.
3.1.2 Research questions
In this section detailed research questions are formulated based on the conceptual model of the previous section. In the introduction it was mentioned that the goal of this research is to create a generic ECM process for the four cooperating BUs at Philips Healthcare. To realize this goal a research question has been formulated. This research question will be split up in sub-questions which can subsequently be solved individually before an answer to the main research question is provided. The goal of each sub-question is explained in this section. The next section (Data collection and analysis) will explain in detail how these questions will be answered and how the corresponding data is obtained.
The main research question as was stated in the introduction is:
How to develop a generic business process from individual, heterogeneous business processes that are in place in different business units?
In order to answer this main research question we have identified four sub-questions from the conceptual model in Figure 13.
1) Which roles and tasks are comparable among the four BUs?
2) What authorization differences and similarities exist among the four BUs? 3) What authorization differences are needed to cope with BU specific factors?
4) What solution to overcome authorization differences has the most positive impact on overall ECM performance?
The first sub-question finds out which roles and tasks are comparable among the BUs. Determining the similarity of roles and tasks among the BUs is a crucial step that enables the authorization differences to be highlighted further on in this research. The answer to this question should be a set of tasks and roles which are similar across the BUs.
The second question is raised to determine the authorization differences and similarities. To find these differences and similarities first of all the role involvements have to be determined for all the identified similar tasks. Once the role involvements are known for each BU, they can be compared for each task to find authorization similarities and differences. This should provide a set of authorization differences and similarities among the investigated BUs.
For the third question there has to be determined which authorization differences might be related to influence factors. Therefore, the influence factors for every BU need to be determined. Also for every authorization difference it has to be determined if they are caused by influence factors. If so, then these differences are marked as justifiable. If the differences are not caused by the influence factors they are marked as non-justifiable.
Once these sub-questions have been answered the main research question can be answered. When looking at the conceptual model it can be seen that a generic process consists of solved authorizations, justifiable differences, and authorization similarities. These are all available after answering these sub-questions which makes the construction of the final generic process possible.
3.2 Data collection and analysis
This section will explain in detail how the sub-questions of the previous section will be answered in order to fulfill the goals of this research. It will also be explained how the necessary information is obtained at Philips Healthcare.
3.2.1 Which roles and tasks are comparable among the four BUs?
The first sub-question is intended to map the ECM process of all the BUs involved to find similar roles and tasks among the involved BUs. These similarities form the basis for comparison on authorization differences later on. To identify similar tasks and roles among the BUs the ECM processes of the four BUs have to be mapped first. This mapping is achieved using flowcharts. Key elements depicted in the flowcharts are the tasks, and the roles which perform these tasks. The flowcharts are not used for a final analysis but are created to infer similar tasks and similar roles among the BUs.
The data to map the ECM processes in flowcharts is obtained by a combination of interviews and content analysis of documents. First, the contents of documents are analyzed to obtain information about the ECM processes of the four BUs. Missing data is obtained via interviews, with questions structured according to the technique of Emans (2004). This technique provides a systematic way of creating interview questions which cover all the information crucial for a research. It ensures that all relevant information is asked from the interviewee. Several different people were interviewed on the same topic in order to reduce the bias due to personal interpretations and to cross-validate findings. Flowcharts are suited for these kinds of communication purposes because no expert knowledge is needed to understand them. Some direct observations of the ECM process were possible. Attending team meetings has proven to be a useful way to obtain the desired information on who is involved in what specific tasks. For each BU at least two team leaders, one involved engineer, and one employee who collects customer complaints, were interviewed. The activities of these interviewees cover the entire ECM process of their BU. Team meeting were attended at the teams who decide on which action to take for customer complaints. These teams are called customer complaint teams, which will be explained in detail in Section 4.2.2.
these tasks of BU1 and BU2 both have the same effect (similar input and output) in their process they are called black box equivalent. Therefore, this grouping of tasks ‘check customer complaint’ is marked as a similar grouping of tasks across BU1 and BU2. To categorize a group of similar tasks under one label among the BUs, we rely on high level ECM tasks of several generic ECM process that are mentioned in literature. They are depicted in Table 1. It contains several task names that are common in ECM processes. Thus, for each task name in the table a corresponding group of tasks can be sought in the ECM processes.
Figure 15: Example of blackbox equivalent group of tasks.
Once task similarity is established, the next step is to determine role similarity. Role similarity is determined by comparing all the roles involved in the four ECM processes. Roles are similar when they consist of the same organizational functions. For example consider two roles: team A from BU1 and team B from BU2, with both teams consisting of a manager, an administrative worker and an engineer. In this case, we assume the two roles, team A and team B, to be similar since they consist of the same organizational functions.
At the end of this phase of our methodology, we establish a set of tasks and roles that exhibit similarities across the different BUs. This set is used as the basis for our comparison. After establishing these similarities across the 4 BUs, we can proceed with determining differences in the way the similar tasks are handled by roles.
3.2.2. What authorization differences and similarities exist among the four BUs?
In this phase, we use the set of established similar tasks and roles in order to determine authorization differences among the BUs. The roles and tasks, identified from the previous step,
Check if information is complete Check if complaint is already known T E A M 1 T E A M 2 T E A M 3 Customer complaint Checked customer complaint Customer complaint Check for formalities Checked customer complaint BU 2
BU 1 Check customer complaint >
are used to create a RACI table for each BU. These RACIs will show the role involvements of the ECM processes. RACI tables are efficient in modeling a business process along the organizational dimension.
A RACI table consists of tasks which are listed in the rows and roles which are listed in the columns. Each cell can consist of the value R (responsible), A (accountable), C (consulted), and I (informed). Every row stands for one role involvement. The RACI matrices enable the role involvement to be compared across the BUs.
The flowcharts, previously generated, provide us with much basic information about the role involvements of the four ECM processes. However more detailed information on how the roles are involved in the tasks has to be obtained, because RACIs show role involvements in more detail. For example, a role can be responsible but also accountable for executing a task. This information is not visible in flowcharts. This more detailed role involvement information is obtained in a similar way as for the flowcharts. Interviews have been conducted and team meetings have been attended. Also several different people are interviewed on the same topic in order to reduce the bias due to personal interpretations and to cross-validate findings. Having a RACI for each BU enables the comparison on role involvement. Every row in the RACI represents a similar grouping of tasks from one BU. By comparing the RACI rows in a different table it becomes clear what differences exist in the way roles are involved in the execution of the tasks. This visual inspection of RACI row differences will be supported by Dijkmans (2007) categorization of frequently occurring differences between similar business processes. Differences are sought in the three categories which are presented in the literature section, namely: different roles, single role vs. collection of roles, and different collections of roles. To perform this comparison on authorization differences two tables for each task are created. The first table will contain for each task the corresponding RACI rows of all the BUs. The second table will show what authorization differences exist for that specific task. So the first table lists the RACI rows to enable comparison on authorization differences and the second table lists the authorization differences which are found in the first table. Figure 16 illustrates these steps to find the authorization differences for a specific task. This example is purely illustrative and does not contain real research data. The first step is to select the RACI rows from the original RACI of each BU for one specific task. These are copied into Table 1 from Figure 16. The analyst subsequently checks Table 1 for differences and lists them in Table 2. Table 2 gives an identification number to the difference, shows which BUs are involved and shows the kind of difference according to Dijkman (2007). When no differences are found in Table 1 then no difference is listed in Table 2. This means that the corresponding task has no authorization differences and therefore already is generic among the involved BUs.
RACI
BU 1 Role1 Role2 Role3
Task1 R R A Task2 R Task3 A Task4 I RACI
BU 2 Role1 Role2 Role3 Task1 R A
Task2 A
Task3 R
Task4 I
Figure 16: Example of finding authorization differences
The answer to the second sub-question will be a list of these authorization differences which are found in the RACIs between the four BUs.
3.2.3 What authorization differences are needed to cope with BU specific factors?
After identifying the authorization differences among the individual ECMs, it is important to find out which of them are justifiable, and should not be overcome in the process of merging these individual processes into a single, generic one. As discussed previously, some of these differences should exist to handle various BU specific intricacies, and their annihilation could lead to performance degradation. For example the company size has been identified as influence factors in Section 2.2. When BUs differ largely in their size, then authorization differences might be related to this influence factor. To answer this sub-question, every difference is inspected if it can be linked back to an influence. When a difference can be attributed to an influence factor the difference is marked as justifiable and will not be resolved. The first step in answering this question is the determination of the values of the influence factors of the four BUs. There have been six influences factors identified in Section 2.2. For every factor a value will be determined. This is done for all the BUs. The values for these influence factors are represented in categories. Table 3 gives an example of the influence factors and their values. In this example it can be seen that the factor constructions complexity is high for BUs 1 until 3, and is low for BU4. The data to determine these influence factor values at Philips Healthcare is obtained by studying product documentation, production process documentation, and organograms.
Table1 Task1:
BU1 R R A
BU2 R A
Table2
Difference: BU vs. BU Type of difference
#1 BU1 – BU2
BU1 BU2 BU3 BU4
Construction complexity high High high Low
Technology complexity … … … …
Number of variants …
Number of parts Company size
Time focused vs Quality focus Time focus Quality focus Quality focus Quality focus Table 3: Example influence factor values
The next step in answering this question is to attempt to link authorization differences to differences in influence factors. For each authorization difference found we will try to find a justification by looking at the influence factors. For example when we find an authorization difference between BU1 and BU2 of our example in Table 3, we know that it cannot be linked to the influence factor construction complexity because BU1 and BU2 have the same value for this factor. However we might be able to link it to the factor ‘time focused vs. quality focus’ because this factor does show difference among BU1 and BU2. Our literature review explains in Section 2.2 that this influence factor can cause a larger scope of the process throughout the entire ECM process. If the authorization difference between BU1 and BU2 is indeed a difference in ECM scope then we justify the authorization difference. In this way all the authorization differences are compared with the influence factor values.
3.2.4 What solution to overcome authorization differences has the most positive impact on overall ECM performance?
A solution is sought to overcome the identified non-justifiable differences. This is done with the use of ‘best practice heuristics’ from Reijers et al. (2005). These best practice heuristics explain what performance consequences business process redesign efforts have. The BU which has the best performing role involvement according to these best practice heuristics is chosen. This means that a RACI row, which represents a role involvement, of one specific BU is chosen as best practice based on these heuristics.
ECM process. Based on that choice the role involvement from BU1 or from BU2 will be selected to be implemented in the generic ECM process.
Table1
Task1: Role 1 Role 2 Role 3
BU1 R R A
BU2 R A
Figure 17: Example of the use of best practice heuristics
4. ANALYSIS Censored
6. DISCUSSION & FURTHER RESEARCH 6.1 Discussion
In the beginning of this paper, a research relevance with a corresponding research question was formulated. The main question for this research is:
How to develop a generic business process from individual, heterogeneous business processes that are in place in different business units?
To answer this question a methodology has been developed which was used to create a generic ECM process for Philips Healthcare’s four BUs. This methodology led to the generic ECM process which is presented in the previous section. By answering this research question new knowledge has been created for Philips Healthcare. It is now known which differences exist among the BUs and which differences could be solved. Also a new methodology has been provided which can be used by Philips Healthcare to construct a generic ECM process.
The presented methodology could also be used for other kinds of process standardization as well. The other perspectives of business processes, namely, the behavioral and the informational perspective could also be investigated with the use of this methodology. In that case different modeling languages should be used to represent the process in the behavioral or informational aspect. Axenath et al (2005) explains which process models could be used when other business process aspects are modeled. Also, Dijkman (2007) gives categorizations for differences which could be found in the other business process aspects.
The methodology in this paper could also be used to determine a generic process for other heterogeneous business processes then ECM processes. However, the influence factors presented in Section 2.2 are specific for ECM processes. When other business processes at Philips Healthcare, or other companies, are standardized with the use of this methodology then influence factors for that specific business process have to be determined firstly.
6.2 Limitations and further research
The presented generic ECM process represents only the organizational aspect of a standardized business process. However to create a complete standardized ECM process for the involved BUs, the other aspects of business processes, the informational and behavioral aspect should be investigated in detail as well. Besides the focus on the organizational aspect, the focus was also mainly on the formal issues of business process redesign, like best practices and formal influence factors. Other factors, like culture and change management aspects, which might influence the implementation of new business processes, have been neglected in this research. This research can therefore be seen as a first step towards creating standardized business processes across BUs within Philips Healthcare.
compared business processes the more accurate this methodology works because in that case those tasks can be analyzed on authorization differences. However, when tasks among the compared business processes are very different then the determination of authorization differences is hard and at some point stops making sense. Further research could find out how similar processes should be before they can be compared with this methodology. Similarity indexes developed by Ehrig et al. (2007) and van Dongen et al. (2007) could be helpful to find a minimum degree of similarity between business processes as a prerequisite for the methodology.
REFERENCES
Axenath B, Kindler E, Rubin V, (2005), “The aspects of business processes: An open and formalism independent ontology”, Software engineering group, University of Paderborn
Brand N, Kolk H van der, (1995) “workflow analysis and design”. Kluwer bedrijfswetenschappen (In dutch)
Davenport T.H., Short J.E., (1990), “The new industrial engineer: information technology and business process redesign”, Sloan management review, pp 11- 27
Dijkman. (2007) A Classification of Differences between Similar Business Processes. In Proceedings, “IEEE International Enterprise Distributed Object Computing Conference
(EDOC’07)”, pages 37–50.
Dongen B.F., Dijkman R.M., (2007), “Measuring similarities between business process models”, Eindhoven university of Technology
Ehrig M, Koschmider A, Oberweis A, (2007) “Measuring similarities between semantic business process models”, CAN International Conference Proceeding, vol 247, pp. 71-80
Emans E. (2004) “Theory, techniques and training”, Stenfert Kroese
Huang G, Mak K, (1999) “Current practices of engineering change management in UK manufacturing industries.” Int J Oper Prod Manage 19(1):21–37
Ibbs, C. W., Wong, C. K., Kwak, Y. H., (2001) “Project Change Management Systems”, Journal of Management in Engineering, Vol 17, No 3, pp159-165
Jansen-Vullers M H, Loosschilder M W N C, Kleingeld P A M, Reijers H A, (2007) “performance measures to evaluate the impact of best practices” Department of technology management, Eindhoven university of technology
Jarratt, Eckert, Clarkson, (2006) “Pitfalls of engineering change: change practice during complex product design”, Engineering design centre, university of Cambridge
Limam Mansar S., Reijers H.A., (2007), “Best practices in business process redesign: use and impact”Business Process Management, Vol. 13 No. 2, pp. 193-213
Pikosz P, Malmqvist J (1998) “A comparative study of engineering change management in three Swedish engineering companies.” In: ASME design engineering technical conference
Razmi J, Jolai F, Hezarkhani B, (2008), “Designing collaborative roles and responsibilities in supply chain” International Journal of Management Practice, Vol 3, No 1
Reijers, H.A., and Limam Mansar, S. (2005), “Best Practices in Business Process Redesign: An Overview and Qualitative Evaluation of Successful Redesign
Riviere A, Dacunha C, Tollenaere M (2002) “Performance in engineering change management.” In: Proceedings of IDMME 2002, Clermont-Ferrand, France
Tavcar, J. Duhovnik J, (2005 ) “Engineering change management in individual and mass production”, Robotics and Computer Integrated Manufacturing, Elsevier
Tavcar J, Duhovnik J, (2006) “Engineering Change Management in Distruted
Environment with PDM/PLM Support” Manufacturing the Future, Concepts - Technologies - Visions , pp. 908
Vergidis, Tiwari, Majeed, (2008) “Business process analysis and optimization: Beyond reengineering”, IEEE transactions on man. and cybernetics.
Vos C, Tsikriktsis N, Frohlich M, (2002), “Case research in operations management” International Juornal of Operations & Production Management, Vol 22, No 3, pp.195-219
Smith M. L,. Erwin J, (2007), “Role & Responsibility Charting (RACI)” http://www.pmforum.org/library/tips/pdf_files/RACI_R_Web3_1.pdf,
ABBREVIATIONS CCT Customer complaint team
CI Clinical informatics CV Cardio vascular EC Engineering change
ECCB Engineering change control board ECM Engineering change management FCO Field change order
FPR Field problem rapport GXR General X-ray
MR Magnetic resonance
MRI Magnetic resonance imaging PLCM Product life cycle management RACI Responsibility matrix
Appendix 2.1: RACI table CV
Appendix 2.3: RACI table MR
Appendix 2.4: RACI table CI
