Integrating information systems: case studies on current ... - CiteSeerX

Electron Markets (2010) 20:161–174 DOI 10.1007/s12525-010-0037-8

GENERAL RESEARCH

Integrating information systems: case studies on current challenges Alexander Schmidt & Boris Otto & Hubert Österle

Received: 18 October 2009 / Accepted: 20 April 2010 / Published online: 18 May 2010 # Institute of Information Management, University of St. Gallen 2010

Abstract Integration of information systems is a prerequisite for efficient collaboration within and between organizations. Despite intensive research on integration issues in Information Systems research, companies nowadays still encounter considerable challenges in integration projects. The question for the reasons still engages researchers and practitioners. The paper at hand investigates current integration problems by deriving a framework for integration problems from literature research and applying it for the analysis of concrete cases from business practice. The examples are described in detail in explorative case studies examining three integration projects from different industries and with different objectives. From the comparison of theoretically derived and practically proven integration problems, the paper identifies integration problems that have been insufficiently addressed so far and discusses open challenges of integration in the Information Systems discipline. Keywords Integration problems . Case study research JEL M

Responsible editor: Hans-Dieter Zimmermann A. Schmidt (*) : B. Otto : H. Österle Institut für Wirtschaftsinformatik, Müller-Friedberg-Strasse 8, 9000 St. Gallen, Switzerland e-mail: [email protected]

Introduction Problems relating to integration have been a fundamental phenomenon in business management research and practice for many years. Galbraith pointed out the challenge of integrating tasks by means of information systems in enterprises with specialized organization units (Galbraith 1968), while Mertens investigated the problem of integrated inter-organizational data processing at around the same time (Mertens 1966). As a result, integration went on to become a research focus of Information Systems and Information Management (Heilmann 1989; Rosemann 1999). In this context, integration issues are examined on different levels: organizational integration during the course of company mergers and acquisitions (Kromer and Stucky 2002); interorganizational integration for coordinating business processes between business partners (Hasselbring 2000; Medjahed et al. 2003); the integration of application landscapes within an enterprise (Singletary et al. 2003); the integration of heterogeneous data sources (Batini et al. 1986); or the alignment of IT functionality with business requirements (Luftman and McLean 2004). In the past, both research and business practice have proposed a large number of solutions for these areas of integration. Nonetheless, real-world examples can be found time and again, where integration fails or results in an unsatisfactory outcome. In a Forrester study on the effectiveness of integration infrastructure among 260 IT managers in enterprises of different sizes and from different sectors, almost 40% stated that they were dissatisfied with their current integration capability (Forrester Research 2009). According to the respondents, integration projects continue to fail due to outmoded integration methods and tools as well as the absence of an integration strategy.

162

This discrepancy between intensive research and the continuing integration problems raises the question of why this should be: What are the reasons for the failure of integration efforts in companies? How can existing integration problems in practice be explained? Are the proposed solutions addressing the wrong problems, i.e. is there a lack of suitable solutions? Are they not known to practitioners or are they not practicable? In order to provide a basis on which to answer these research questions, this paper pursues three goals: 1) to identify existing integration problems from business practice and to describe them comprehensibly; 2) to explain the reasons behind them and categorize them; and 3) to highlight the areas in which unresolved problems remain by examining the state of the art. The remainder of this paper is structured as follows: The chapter on theoretical foundations which follows the introduction encompasses a detailed analysis of the scientific knowledge base on integration in Information Systems research. This provides an overview of established layer and view concepts for the topic of integration and deduces a framework for structuring integration problems from scientific and practice-oriented articles. While chapter 3 outlines our case study based research approach and gives an overview of the case studies of this paper, the findings of the cases are described thereafter in chapter 4, documenting the current status of practice. The integration problems in business practice are summarized in chapter 5 and assigned to the layers of the integration framework. Here, we will incorporate the findings from further cases that have been published in the past and that identify integration problems. Additionally, this chapter discusses reasons for integration failure which cannot be classified in accordance with the reference framework for integration problems and are yet to be adequately addressed by research. The paper concludes with a summary of findings thus far and gives an outlook on future research.

Theoretical foundations In this chapter, we give an overview on publications related to the topic of the paper from Information Systems and Information Management research. For this purpose, approaches to the identification, description and structuring of integration problems developed in recent years are presented briefly. Building on from here, objects of integration are identified and used for detailed classification of the integration problems. Integration in information systems When it comes to managing the complexity of integration projects, concepts for forming views and layers have

A. Schmidt et al.

proven successful in science. In the German-speaking world of Information Management, a frequently adopted approach to the structuring of integration problems is to distinguish according to the dimensions of integrated information processing. These are (Mertens 2007; Wigand et al. 2003; Rosemann 1999): & &

& &

the integration object, denoting the artifact that is to be integrated; the integration direction, differentiating between horizontal integration along the supply chain and vertical integration between administrative systems and planning and control systems; the integration scope, indicating the extent to which integration is to be achieved, i.e. intra- versus interorganizational; and the level of automation, signifying the degree of manual activities that are necessary for integration.

As the dimension integration object is most frequently referred to in literature (Stadlbauer 2007) and allows for the most detailed differentiation of integration problems, we derive the initial structure of our framework in the following based on analysis of differentiation approaches with regard to this dimension. On the basis of requirements to be met when integrating information systems, Bunjes et al. distinguish three layers based the integration objects data, applications and processes (Bunjes et al. 2002). Whereas on the first layer the emphasis is on uniting schemata as well data sets and data elements of different applications, application integration deals with linking the applications themselves. An integration object classification frequently referred to is the distinction between the five layers of data, program, function, process/operation and method integration (Mertens 2007). In this case, the first two correspond to the layers of data and application integration respectively (in line with understanding a program as a software module or application). If a business process is understood to mean a temporally and logically related sequence of tasks (Österle 1995) and the definition of function integration as the coordination of individual tasks is taken into account (Mertens 2007), then it becomes clear that function and process integration address similar integration challenges. In the Architecture of Integrated Information Systems (ARIS) the views data, functions and organization which are integrated via the control layer (processes) are also distinguished according to the integration object (Scheer and Schneider 2005). Being a specific sub-discipline of Information Systems Business Engineering (BE) discusses the challenges associated with integration on the basis of the threelayer model in relation to strategy, processes and systems (Alt et al. 2001). As an interdisciplinary approach between

Integrating information systems: case studies on current challenges

business administration, information management and technology management, BE develops models and methods for the systematic resolution of transformation problems in organizations (Höning 2009; Winter et al. 2008). In this context, transformation always implies the task of integration: the integration of new business units in the course of company mergers and acquisitions, the integration of application systems to support new business processes, the integration of business and IT structures as part of business/IT alignment. Therefore, the BE approach and its underlying metamodel represents a valid reference for a comprehensive framework for integration problems. Building on from the BE core business metamodel (Höning 2009; Österle et al. 2007), the three aforementioned layers can be specified in concrete terms by means of the corresponding design objects. For this purpose, the next chapter identifies those design objects of the core business metamodel which potentially need to be considered for integration. Detailing integration problems The design objects of BE provide the starting point for the specification of integration categories (depicted in the second column of Table 1). The integration categories define the three general integration layers (depicted in the first column) in further detail. Following the other approaches outlined in the previous chapter, the systems layer is divided into the integration objects applications and data. The third column contains possible problems when integrating the respective design object and is derived from literature. For the literature analysis, scientific and practiceoriented publications were included which address integration problems relating to at least one design object. As the volume of publications in the case of some integration problems is very large, Table 1 only refers to selected works. With the exception of Data exchange / Communication and Data models, all design objects have been taken from the core business metamodel. These two design objects are not explicitly contained in the metamodel, but are implicitly modeled by means of the relationships between the entities “Application” (data exchange) and “Data Element” (data model). They are also contained in the metamodel in the work by Vogler (2006) on process and system integration in BE as the design objects “Data transfer” or “Data flow between tasks” and “Data structure”. The problems associated with the strategic layers are above all relevant in the case of strategic alliances and company mergers necessitating the long-term alignment of business segments and goals between formerly independent enterprise (Sperling 2007). Bakker and Helmink refer to

163

differences in the business operating model, i.e. the organizational units and competencies, as significant obstacles in mergers and acquisitions integration (Bakker and Helmink 2000). Process integration is defined as the realization of cross-application business processes, the focus being above all on the coordination and control of process logic, i.e. the choreography and synchronization of activities and milestones between business partners (Weigand and van den Heuvel 2002; McAfee 2005). In addition, publications point out the importance of a shared process vocabulary based on a common understandings of business objects between process actors (Reimers 2001; Medjahed et al. 2003; Legner and Vogel 2008). Where the integration of applications is concerned, the authors look primarily at problems of access to distributed datasets and application functions (Bunjes et al. 2002; Linthicum 2000) as well as problems that are related to the message exchange between applications, such as communication protocols, message formats and structures (Jain and Zhao 2003; Medjahed et al. 2003; Kubicek 1992). On the data layer, several publications state syntactic and semantic conflicts between data schema in particular (Bunjes et al. 2002; March et al. 2000). Some authors provide a more differentiated distinction, also mentioning structural conflicts that mainly result from different perspectives and the degree of freedom of the data modeller when mapping real-world phenomena in a model as well as data model heterogeneity that is due to differing modelling constructs provided by modelling notations (Leser and Naumann 2007; Spaccapietra et al. 1992; Conrad 2002; Batini et al. 1986). The integration problems stated in Table 1 are not confined to an intra-organizational scope. Diverging strategic goals, variances in business processes or heterogeneous structures and semantics of messages and data models—just to mention some—are as (or even more) critical in crossorganizational scenarios. Integration problems on the Strategy layer are actually more relevant in cases when formerly independent legal entities are being merged. Moreover, particularly in large-scale enterprises differences between intra- and inter-organizational vanish as heterogeneity of autonomous business units within a company can be as high as of two legally separate companies. Accordingly, application integration on a company-internal scope (as subsumed under the concept of Enterprise Application Integration) relies on similar technologies and approaches (e.g. middleware solutions) as B2B Application Integration to solve resembling integration problems (Linthicum 2001). Therefore, the framework is intended to be applicable in both cases. The integration layers and the integration categories distinguished according to the design objects described form the reference framework for the classification of integration problems from business practice. The detailed

164

A. Schmidt et al.

Table 1 Classification of integration problems based on integration objects Integration Layer

Integration Category

Possible Integration Problems

Strategy

Business segment

1. Lack of overlap and/or complementarity (Sperling 2007) 2. Different business operating models (Bakker and Helmink 2000) 3. Conflicting goals (Sperling 2007) 4. Different performance indicators 5. Diverging number of roles 6. Different function scope 7. Different granularity 8. Different sequence of activities (control flow) and process interaction (Weigand and van den Heuvel 2002; McAfee 2005) 9. Semantic heterogeneity between business objects (Legner and Vogel 2008): existence of synonyms / homonyms and differing structures 10. External access to data and functions (Boles et al. 2004; Linthicum 2000) 11. Function granularity (Papazoglou and van den Heuvel 2006) 12. Different communication / transmission protocols such as HTTP, SOAP, JDBC (Jain and Zhao 2003) 13. Different message formats such as flat files, EDI, XML (Kubicek 1992) 14. Diverging message and interface structure (structural conflicts (Conrad 2002)) 15. Uncontrolled redundancy through data distribution (Jung 2006) 16. Data model heterogeneity (Batini et al. 1986) 17. Syntactic heterogeneity (Leser and Naumann 2007): different data types (numeric, alpha-numeric, etc.), field lengths and value ranges 18. Structural heterogeneity (Spaccapietra et al. 1992): different understanding of entities as attribute or as (data) object, different cardinalities between entities 19. Semantic heterogeneity (March et al. 2000): different understanding of data objects, existence of synonyms and homonyms 20. Attributes are defined differently (e.g. as mandatory or optional) (Riehm 1997)

Goal system Processes

Roles Activities/tasks

Systems

Applications

Business objects (including business documents) Application function Data exchange / Communication

Data

Data models / schemas

Data elements / data objects

21. Inadequate data quality and/or data value conflicts, e.g. accuracy, missing attributes (Kim and Seo 1991)

integration problems stated in the third column are enumerated in order to allow for an easier assignment of the problems described within the case studies. We will reference to the framework during the description of the cases by indicating the number of the integration problem (1 to 21). Thereby, the paper identifies and categorizes integration problems enterprises are currently facing and describes them comprehensively.

Research method In order to respond to the research questions raised in the introductory chapter, the adopted research approach is based on the methods of primary and secondary research (desk research). From a qualitative literature analysis (Mayring 2004), which included works with content directly related to integration, a framework was deduced in the previous chapter that depicts integration layers and the associated integration problems in a structured manner. Subsequently, we carried out explorative case studies

(Specht et al. 2004; Yin 2002), which investigate three integration projects from different industries and with different objectives. The goal pursued with explorative case studies is to describe and to structure complex object areas (Meyer 2003), in our case integration. The ability to investigate problems that need to be examined in their real-world setting due to their complexity and interdependencies was the reason why we opted for case studies. Alternative research methods, such as surveys, do not provide these opportunities. Case studies make it possible to examine existing cause-and-effect relationships between a phenomenon and its context (Yin 2002). The paper explains cause-and-effect relationships of integration by describing concrete integration problems from business practice. For this purpose, case studies appear best suited as they do not only allow to cover the whole breadth of integration problems, but to deepen the examination of certain issues as well. Due to space limitations the paper presents only three case studies in detail that are summarized with their main characteristics in Table 2.


165

Table 2 Characterization of case studies SOA for Automotive

inet-logistics

Automavision

Industry

Automotive industry

Engineering

Integration focus

Inter-organizational integration (B2B) • Processes • Data

Transport logistics in business air traffic Inter-organizational integration (B2B) • Processes • Applications • Data • Reduced time and cost involved when integrating aircraft manufacturers (OEMs) and freight carriers • Cost savings through simplified consolidation of transport orders • Increased transparency regarding order progress through consistent tracking

(Schmidt 2009)

–

Integration layers primarily addressed (see Table 1) Expected benefits

Further information

• M:n-capable service oriented reference architecture for the inter-organizational coordination of change management • Increased transparency regarding processing status of change requests • Reduced throughput time and costs of processing change requests • Reduced time and effort for integrating several players into the value chain (Vogel 2009; Vogel et al. 2007)

We will analyze further cases—either recorded in expert interviews or described in scientific publications—that explicitly address integration problems in the penultimate chapter. The rationale for choosing exactly these three case studies for this article is that they address different layers of the integration framework (as depicted in Table 2). According to Yin each case study of a multiple-case design can either focus on the same unit of investigation (in our case the same integration problem) or multiple logically delimitable units (Yin 2002) as pursued in our research. This allows us to cover the multiform phenomenon of integration in Information Systems reflected in the large number of integration problems more comprehensively. The data collection in the case studies was performed in accordance with a uniform framework of analysis and using different methods of investigation, such as case study interviews, content analysis of documents and findings from observations (Yin 2002; Senger 2004). The case study interviews were semi-structured and were conducted on the basis of a questionnaire with mostly open-ended questions (Cavana et al. 2001).

Master data harmonization • Applications • Data • Increased data quality through harmonized master data (less erroneous and redundant master data) • Simplified aggregation of data for company-wide reporting

SOA for automotive1

Case studies

The research project SOA for Automotive aimed at developing a service-based integration architecture for inter-organizational business processes in the automotive industry, using the example of the Engineering Change Request (ECR) process. For multilateral process integration, the concept of public processes was applied, with the aid of which the sequence of activities between two business partners is modeled (Legner et al. 2007).2 The concept was introduced in two steps: First, the interaction (public process) between the partners is defined and modeled from the organization, process and information viewpoint; then the internal process architecture is matched with the public process architecture. The second step revealed problems with coordination of the roles (organization view) and the sequences of activities (process view) as well as with matching the individual business object models which are analyzed in greater detail below. For the public process, specifications of the German association of the automotive industry (Verband der Automobilindustrie, VDA) were authoritative in respect of activities, milestones, roles and business objects. Most notably, the specification VDA 4965 as an industry standard for technical change

The three case studies presented in the following are described in a shortened form and exclusively focusing on concrete integration problems. Additional information on the cases that is not necessarily required for argumentation within this paper can be found in the referenced literature.

1 The name of the case study complies with the name of the corresponding consortial research project. 2 The integration problems described below apply generally to the processes of different enterprises, irrespective of whether this public process concept is used.

166

A. Schmidt et al.

management was used for the Engineering Change Request (ECR) process. Table 3 shows the comparison of roles which are defined within VDA 4965 and are significant for the public process with internal roles of the project partners. The roles stipulated by the standard could not be fully identified within the company and consequently assigned for all partners (5; 6). The variances between internally existing and publicly defined roles are attributable both to different designations and to different understandings of roles with the same name. They lead to problems with integrated process handling between business partners and additional bilateral coordination effort as information cannot be exchanged between the roles defined in the process and the process cannot progress. In this context, the following three cases are to be differentiated: 1. The roles defined in the standard is more comprehensive than the private roles, which means that several public roles have to be combined in one private role with regard to their range of authority and tasks. For example, Table 3 shows that both Receiver and Creator of the ECR coincide in the case of Supplier 1 because of the role of Request Initiator or Change Manager. 2. In the second case, there are two company-internal roles to one role in the public process. In the case of Supplier 1, the roles of Request Initiator and Change Manager, for example, are not clearly assigned to ECR Creator in the public process. 3. Public and internal roles do not match in respect of individual role definitions, which means, for example, that there is a strong variance in the assignment of responsibilities.

A similar problem arises when matching the process models (consisting of phases and milestones) between public and internal processes. Table 4 shows a comparison between the process phases defined in VDA 4965 (which are linked to specific milestones in each case; these have not been included in the table for reasons of clarity) and the individual phases of the various project participants (7; 8). As with the differences between the roles, three categories of variances can also be identified in the case of the process models: 1. The public process encompasses a higher number of process phases and consequently milestones. This also becomes evident amongst others in the lack of a differentiation between Phases 3 (Technical Analysis) and 4 (Commenting on ECR) with some enterprises. This leads to a situation where change requests are commented upon before the actual extent of the change is known precisely. 2. On the other hand, the internal process can encompass a further subdivision of a process phase, as is the case e.g. with Phase 5 (Approval of ECR) for the OEM. 3. Finally, it can be the case that important milestones (in some cases phases as well) have no equivalent in the internal process. When it comes to exchanging information, the discrepancies shown lead to problems with inter-organizational process integration as results required for proceeding to the next process phase are not available and cannot be passed on to the project partners (8). In addition to the outlined integration problems on the process layer, variances were also found on the information layer as a result of different schemata and/or data models. An “x” in Table 5 denotes that the corresponding attribute is contained in information models of the different

Table 3 Comparison of roles between VDA 4965 and internal roles of project partners VDA Process Role

Automobile Manufacturer (OEM)

Supplier 1

Supplier 2

Supplier 3

Supplier 4

Request Receiver

Procurement

Request Initiator or Change Manager

Change Responsible

Initiator

ECR Creator Change Team

Creator Main Person Responsible

Change Round

Project Team Member, Sales, Quality Manager Project Manager Project Team

Author Change Team

Decision Team

Authorizer, Checker

Decision-maker

Change Board

Request Initiator Function: Person Responsible –

Requester

Requester (user must exist in the system)

Comment Performer

Receiver of an L-AFO

Contact exclusively via single point of contact via single point of contact

Customer (OEM), Procurement (Supplier) Procurement (Customer)

Change Control Board Customer, Supplier

Customer, Supplier

Initiator (customer) –


167

Table 4 Comparison of process phases of engineering change management VDA Phase

OEM

Supplier 1

Supplier 2

Supplier 3

Supplier 4

1: Receipt of ECR Request 2: ECR Creation 3: Technical Analysis of ECR

– Creation

Request Initiation

Change Request Change Entry Evaluation

Set up Engineering Change Request Change Evaluation / Check and Approve Feasibility

Create Request

Authorize Change Request

Change Approval

Detailing Concept

4: Commenting on ECR 5: Approval of ECR

Comments Decision

Check Approval

roles. The table illustrates that there are differences in structure and content between the individual business object models of the individual business partners (9). For example, in the case of Suppliers 3 and 4, the attributes “creator” and “leading_change_scope”, which are essential for message exchange and continuation of the Engineering Change Management process (transition to VDA Phase 3), are missing in the ECR_Header. OEM and Supplier 1 lack the information passed on in these attributes for further processing of the change request. Even when a matching internal attribute field was identified for a public attribute field, syntactic, semantic and structural heterogeneities made depiction difficult, giving rise to the need for a format transformation, manual mapping between value lists or more complex depiction mechanisms. Examples here are: &

&

Syntactic heterogeneity (17): The business object “date” with the attribute field of the same name calls for a syntactic representation as per ISO 8101 (yyyy-mm-dd); various partners use a syntactically different date representation. Semantic heterogeneity (19): The classification schemata for change requests vary between one partner and the VDA recommendation. Thus, one supplier has the

&

Coordinate Request Elaborate Request Check Request Decide on and Complete Request

values Specification Change, Design Correction, Manufacturing Technology, Quality Requirement or Product Termination, whereas VDA 4965 envisages amongst others the values Change of Project Targets, Legal Requirement, Rationalization, Corrections or Quality. Structural heterogeneity (14; 18): Some partners have the possibility of depicting change requests by means of several hierarchically structured items, which means that a change request can have several change items. In contrast, other players have a modeling structure that is specified so that each change request has precisely one change item and consequently each change has to be stated in a separate change request. As a result, requests containing several items cannot be broken down into the individual items and further processed by some partners.

inet-logistics The case study “inet-logistics” investigates an integration solution in the area of transport logistics, at the center of which the inet–logistics information hub acts as intermediary between aircraft manufacturer, logistics provider (the

Table 5 Matching business object attributes of different business partners Attribute

Card.

OEM

Supplier 1

Supplier 2

Supplier 3

Supplier 4

Business Objects

ID Name Description Change_process_type EC_manager Requester Creator Leading_change_ scope Attachments

1 0..1 1 0..n 1 0..1 0..1 1..n 0..n

x x x x x x x x x

x x x x x – x x –

x x x x x x x x x

x – x x x x – – x

x – x x – x – – x

Status

1

x

x

x

x

x

ECR_Header, ECR_id ECR_Header ECR-Header ECR_Header ECR_Header ECR_Header ECR_Header ECR_Header ECR_Header, ECR_Detail, ECR_Comments ECR_Header, ECR_Detail, ECR_Comments

168

company Fiege for which inet-logistic has developed a software solution for the integrated handling of transport logistics), freight carriers and the customer (Jet Aviation). The first difficulties with integration arose when integrating the aircraft manufacturers at strategic and cultural level. On the one hand, there was significant resistance to a change on the part of the manufacturer as people did not see the benefit of the new solution and in their view the project was not a priority (3). For the aircraft manufacturers, the new solution represented first and foremost increased complexity as a result of an additional application and a greater variety of processes. On the other hand, the aircraft manufacturers had to adapt their processes to the new solution and supply the information in the right level of detail (dimensions, weights, etc.) and quality, over which both Jet Aviation (as a business aviation service provider) and Fiege (as a logistics service provider) have only limited influence. Inadequate data quality was identified as another integration problem (21). For Jet Aviation, the inadequate quality of master data constituted the actual obstacle to data integration and interface definition. This primarily affected supplier data where databases contained on the one hand different numbers and on the other different addresses. This made integrating supplier data for the purpose of consolidation more difficult as the same suppliers could not be recognized as such by the inet software. Additional effort through manual reworking is the consequence. Jet Aviation continues to strive for a solution to these problems through internal data quality initiatives (amongst others by cleansing). Another example is the absence of stated time frames for supply contracts. As a result of the failure to state a “must” delivery date for Jet Aviation (20), consolidation and consequently cost-saving potentials are not utilized. There was also another problem relating to data: While at the manufacturer end data had up to now been entered manually into the internet-based tools of the respective freight carrier, the new solution required the direct integration of the manufacturers’ ERP systems (primarily by means of EDI). As courier services call for a greater level of detail in the data, but this is not maintained to the required depth in the ERP systems, the question arises of where these data can be obtained. This relates primarily to weight and volume data (dimensions) in respect of the spare parts and packages to be transported. While similar problems due to process adaptation (provision of the necessary information) could be resolved with relative ease at Jet Aviation, this was much more difficult in the case of the aircraft manufacturers, which meant that the process repeatedly came to a halt. The problems with process integration in this case result from the absence of the necessary data (21) for performing a task within the process (e.g. it is not possible to consolidate orders if the delivery date is missing). In contrast with the data quality problems outlined above, the purely technical integration proved to be less

A. Schmidt et al.

problematic. When defining interfaces, integration problems arise from company-specific attributes defined in the ERP system which are not provided for in this way in the inet software (20). This relates to additional attributes, differently used attributes and attributes with a companyspecific meaning (e.g. a company uses its own interpretation of Incoterms without making it evident for business partners who is liable for what in respect of transport). Manual mappings are therefore necessary with the aid of translation tables and enhancers (that automatically derive data from existing master data)3, which takes from 5 to 10 days per interface. A (semi-) automatic solution using schema matching procedures would not appear to be possible due to the semantic information required for the mapping (and/or the inadequate formalizability of the semantics). For this purpose, the meaning of specific attributes in a given process would have to be defined for the actor. The possibility to resolve structural as well as semantic conflicts with the help of ontologies was evaluated as not being practical, as a domain-specific ontology was not known to the interviewees and the effort for building a proper ontology was considered as immense and uneconomic. In summary, it can be said with regard to message and data integration that aspects of syntactic integration can be viewed as resolved through standardized message formats and structures (such as e.g. Order IDocs4 or IFTMIN Messages5). Semantic integration (9; 19), on the other hand, remains extremely problematic in view of the wide scope for customizing an ERP system as well as the different use of message fields (e.g. must and can fields in the case of IFTMIN messages). The following example is aimed at illustrating the problems involved when integration can only be resolved manually (by direct definition of the individual fields in interface workshops): An attempt is made to map an incoming EDIFACT Order onto an SAP IDoc Order (14). Addresses are defined in the NAD segments of the EDIFACT Order (see Fig. 1). The address is qualified as buyer by the additional qualifier “BY”. In the respective IDoc Order, qualified values are also transferred to the addresses in the segments E2EDKA1003 (see Fig. 2). In this concrete example, the qualified values

3 As a rule, enhancers function by using master data held on the inet logistics server, with the aid of which the missing information is derived by calculation algorithms (e.g. weight data calculation via goods receipt) and customer-specific assumptions (e.g. deriving a carrier’s Incoterms from historical data). However, this is not a perfect solution to the problem. 4 IDoc represents an proprietary SAP format for transferring data in a business transaction. 5 IFTMIN is an EDIFACT message format for the electronic transfer of transport and forwarding orders.


Fig. 1 Qualification of the example address 0000123456 in an EDI order

belong to the field PARVW, in which codes for defining the business partner’s function are stored. The two extracts show that the address qualifiers cannot be translated 1:1 as the buyer address is mapped from the EDIFACT message onto two addresses in the IDoc (AG for “Sold-to Party” and RG for “Payer”), despite the fact that direct mapping onto a buyer address in IDoc format would be possible (corresponding qualifier exists). The specific definition of the workflow in the SAP target system nonetheless requires data for one Sold-to Party (AG) and one Payer (RG). However, this definition was not known a priori and therefore had to be defined and implemented manually between the partners concerned in order make a correct import possible. The same problem existed when mapping the address match code LG07 qualified as Delivery Party (DP) in the NAD segment of the EDIFACT message onto the SAP customer number 0000123248, which is in contrast defined as Goods Recipient (WE) in the IDoc. Once again, a straight 1:1 translation of the address qualifiers would not be successful. Automavision6 This case study focuses on the initiative to harmonize company master data, in particular material and customer master data. With production plants and sales offices being shared around more than 80 countries, this master data has been held and distributed decentrally and, thus, redundantly between different locations within Automavision AG (15). The most important element introduced for this purpose is a central master data server which is replacing the previously heterogeneous system landscape for master data management. The company is successively migrating master data held in local applications to this server (an SAP system) and implementing company-wide processes that guarantee exclusive creation and maintenance of master data on the central SAP system before distributing it to the different locations. Integration problems resulting from migration continue to arise at the interfaces between the systems of the country organizations to be integrated and the central master data server. As a result of the historical independence of the regional subsidiaries, there are differences between standardized and decentralized article and customer numbers 6

Case anonymized due to company’s communication policy.

169

(17) which make the manual mappings necessary at the interfaces very complex. The greatest integration problems nonetheless occur with the cross-system use of data (e.g. customer order) in a process chain which requires access to various systems (10). While purely technical mapping is still possible by defining mapping rules, enterprise-wide communication between systems fails due to a different understanding on the part of the business units and their users (semantics of data objects and their attributes, 19). As an example, the attribute “Material Status” does contain information about restrictions for use of the material in some locations while in others it does not. Further system-related problems exist with predefined fields. For example, product hierarchies (e.g. bill of materials) cannot be adapted in line with internal requirements in certain cases, making complex conversions necessary in order to be able to exchange product structure data (18). In this context, individual system adjustments for customizing data content and structures during operations are limited due to system restrictions. The process of eliminating duplicates for material master data in order to maintain consistency across distributed systems currently still poses a huge challenge. As yet, the necessary organizational arrangements for assigning responsibility for the creation of master data to a specific organizational unit are missing. In addition, unlike the customer fields, the information in the material master is too unspecific to allow a qualitatively good similarity comparison (19). The material master classification and/or the material master short text are all that is left for duplicate checks. However, this is only possible if there are clear, enterprise-wide rules and regulations for setting up and maintaining these data and attributes, which at Automavision AG is not currently the case. This problem is aggravated by the fact that even recognized material duplicates are very difficult to eliminate as they are usually linked to other objects (in parts lists and drawings) and have a history. Today, the customer data are extensively and for the most part automatically checked for duplicates according to a defined process in each migration project. The checking process is performed iteratively (internal duplicate check in the system to be migrated, check against the datasets on the master data server, definition of customers to be retained—“mapping customer”—by the member of staff responsible on the basis of a proposal list). In the area of material masters, those which are to be migrated are manually checked against the existing datasets and the matching is defined accordingly in collaboration with the business unit responsible within Automavision AG. This is particularly true in the context of interorganizational information systems and collaborative processes between organizational units (even within the same company).

170

A. Schmidt et al.

Fig. 2 Qualification of the same example address 0000123456 in an IDoc order

The solution using a search engine with a flexible key word search which is supposed to make it easier to find material master data—and therefore possible duplicates— hits limits when different languages are used to describe products. In these cases, short texts cannot be compared with one another and any duplication cannot be recognized. To resolve this problem, the company has tried to standardize the short texts (consisting of a languagedependent and a language-independent element) through the use of internal specifications and to generate the language-dependent element automatically in all the other languages (18 in total). Up to now, however, this has not been fully implemented. In summary, the following aspects can be stated which have proved to be decisive for successfully harmonizing master data during the course of the individual integration projects: &

&

The elimination and avoidance of duplicates as the basis for harmonization calls for an appropriate organizational embedding if it is to be effective. In particular, change management issues need to be considered. Data mapping should not be limited to the interface, but must be implemented across systems. This means that the meaning of data which are held and exchanged, i.e. their semantics, must be precisely defined (19).

assigning the problems described in the case studies to the integration framework. Due to space limitations we will not describe those cases in detail but only refer to the integration problems identified. The results of the analysis are summarized in Table 6. The identified integration problems are indicated with their corresponding number according to Table 1. Analysis of the case studies indicated that all described integration problems could be assigned to one of the categories of the reference framework. Consequently, large parts of reference framework derived from literature research can be confirmed by examples from the case studies, while none of the case studies encompasses problems in respect to all integration categories. Whereas the case study “SOA for Automotive” primarily addresses problems of integrating organizational and operational structures (roles, business object model, tasks), the emphasis of the other cases can mainly be assigned to the systems layer (see also Table 2). The integration problems of the case studies do not allow complete coverage of the integration framework layers as only few concrete examples could be identified for integration problems on the strategy layer. The problems associated with these layers are above all significant in the case of strategic alliances and company mergers, which were not the focus of any of the case studies. This applies most notably to the integration problems (1) and (2). Reasons for integration failure

Interpretation of findings So, what are the reasons for the failure of integration efforts? How can integration problems companies are facing nowadays be explained? This chapter first gives a consolidated overview of the findings from the case studies and then discusses the reasons for integration failure in more detail. Analysis of the case studies In the following section, the findings from the case studies are summarized and consolidated. Additionally, we incorporate analysis of further case studies that we either recorded ourselves (e.g. (Sfintesco 2009)) or that have been published in the past addressing integration problems explicitly. With these supplementary cases we intend to further enhance the validity of our reference framework by

In the past, a wide range of approaches to resolving the problems described in the integration framework have been proposed. The fact that integration projects nonetheless fail in practice can be attributed on the one hand to specific problem categories still being inadequately addressed and a consequent lack of valid approaches. This applies amongst others to the integration of business object and roles. As shown by the case study “SOA for Automotive”, business objects and roles usually have to be manually mapped onto a common standard. While standards exist which define business objects and roles uniformly either for a specific industry (see VDA Recommendation 4965) or across industries (e.g. the Core Component Library of UN/ CEFACT), techniques and methods are lacking which support the mapping (e.g. in the case of conflicts). The situation is similar with regard to semantic heterogeneity.


171

Table 6 Examined case studies with identified integration problems Case Study

Identified Integration Problems 1

SOA for Automotive inet-logistics Automavision PostLogistics (Sfintesco 2009) Bank Austria, Kontron AG, AGI Group (Vogler 2006) ITAIDE Beer Living Lab (Vogel 2009)

2

3

4

5

6

7

8

9

X

X

X

X

X X

X

7 8

11

12

13

14

16

X X

X X

Lack of knowledge and diffusion in practice. Some concepts find (as yet) little application in companies, either because the knowledge of potential approaches is lacking (Vogler 2006) or because they are seen as too complex to be used. One example in this context is the use of ontologies to overcome structural and semantic heterogeneity. Promising ontology-based concepts have been proposed by research recently (such as solutions developed by the EU funded research projects SUPER7 or TAO8) and show the potential of semantic concepts for resolving semantic conflicts within processes or between data. However, the interviews showed that these

17

18

19

X

X

X X

X X

X X X X

X

X

For further information see http://www.ip-super.org/ For further information see http://www.tao-project.eu/index.html

15

X X

The most striking evidence from Table 6 is the fact that in all cases companies were exposed to challenges with semantic ambiguity on the data level (integration problem (19)). Despite increasing attention in Information Systems research for this problem in the past years (Batini et al. 1986; March et al. 2000) multiple interpretations of the same data still make an integration effort extremely difficult since each source of information and potential receiver of that information may operate within a different context, which leads to large-scale semantic heterogeneity (Madnick 1999). Here, the case studies revealed that efficient tools and techniques for resolving semantic problems have not reached practice yet leading to considerable manual efforts (see following paragraphs). On the other hand, failure can also be attributed to reasons which cannot be depicted by the layer framework. As a rule, these do not relate to a concrete integration object, but are primarily associated with the integration process and/or integration management. The following problems became evident through the recorded case studies and were contrasted with scientific evidence: &

10

X X

X

X

X

X X

&

&

&

X

20

21

X

X

X

X X

X

concepts were either not known to practitioners or too demanding to be applied. In the specific case of inetlogistics, the interviewees mentioned missing ontologies in the logistics domain and considerable development effort for building an ontology with an appropriate level of detail on their own. In corresponding literature on diffusion and acceptance of innovation, (perceived) complexity (or more precisely the ease of use) is mentioned as a decisive factor for adoption of new technologies (Cooper and Zmud 1990; Rogers 2003; Davis et al. 1989). The authors of this article therefore deduce that some technologies are still in a relatively early stage of adoption in practice. Cost-benefit ratio of integration. In the event of an unfavorable cost-benefit ratio, integration efforts are abandoned irrespective of feasibility. The question to be asked here is where the reasons for the inefficiency lie: Is the integration solution associated with a huge manual effort (as in the case of the manual interface mappings or the necessity to self-develop appropriate ontologies) and therefore too costly? Is the possible solution in the long run too complex to be implemented and maintained? Missing standards. All the case studies underline the importance of standards for integrating processes, roles and business objects (VDA 4965) as well as data elements (IDocs, EDI). However, the case study inetlogistics in particular revealed the problems of having an excessive number of existing “standards” (EDI, XML, IDocs), which means there is no binding reference further encouraging heterogeneity. Lack of a will for change. The organizational changes which became necessary during the course of master data harmonization posed a challenge for Automavision AG, but could not always be satisfactorily resolved even after resorting to change management methods and techniques.

172

&

A. Schmidt et al.

Power asymmetry. Situations are subsumed under this point, in which the integration problems are fundamentally resolvable but individual market players obstruct or prevent the implementation of integration solutions. Typical examples can be identified in the case studies: For a long time, leading automotive manufacturers refused to accept an integration solution based on a serviceoriented architecture as it did not offer them any decisive benefit compared with existing portal solutions or EDI connections (Gerst and Bunduchi 2005). A similar situation existed in the case of the integration of aircraft manufacturers into the inet-logistics information hub. For them, the change effort for integration and the associated requirements in terms of data quality or the necessity for new data formats was too great and at the same time their position of power in respect of the other players was too strong, so some have continued to resist the integration solution. The decreasing willingness to integrate information systems as a result of an asymmetrical distribution of power between players is also a topic of discussion in literature in individual cases (Schober 1999).

The reference framework for integration problems that we deduced from scientific literature has shown to be applicable to real-world cases. The three case studies described in detail brought some insight into the underlying phenomena as well as a certain confirmation of the classification underlying the framework. In a next step, the framework should be further validated and refined with the help of additional case studies. A larger number of case studies can address the limited significance of a small number of case studies and increase the validity of the reference framework for integration problems. At the same time, the findings gathered so far provide a basis for identifying those critical integration problems that are most relevant, such as semantic heterogeneity (see Table 6), and thus justify a more detailed examination by means of a long-term, quantitative analysis. Additionally, research could relate theoretical solution concepts and technologies for integration, such as ontologies, to the identified problems. This would help clarify the contribution of these theoretical concepts to real-world problems. The example of ontologies has shown that company representatives widely view the concept as too complex, despite the fact that it is judged very positive in scientific discussion.

Summary and future research This paper deals with current integration challenges in Information Systems from the perspective of business practice. It sets out to identify, describe in detail and classify existing integration problems with the aid of case examples from business practice in order to answer the question of why integration efforts are failing today. The starting point was a reference framework for integration problems derived from current research findings, which identifies objects of integration and groups together associated problems in a structured manner. The literature analysis included scientific articles from the areas of Information Systems and Information Management whose content is directly related to the topic of integration. The case studies pursued two goals: On the one hand, they illustrate the integration problems stated in the theoretically derived integration framework and describe the causes of the problems. On the other hand, the case studies enabled the recognition of problems with integration which go beyond the integration framework and which cannot be assigned to an integration object, but are nonetheless significant in the course of integration projects. The case studies in this paper highlight the fact that—despite intensive research in the area of integration—considerable progress for resolving the problems has yet to be made for all research questions. Irrespective of industry, reach (intraorganizational or inter-organizational) or division, company representatives find themselves confronted with irresolvable or inadequately resolved integration problems.

Acknowledgements This research was carried within the Competence Center Corporate Data Quality (CC CDQ) at the Institute of Information Management at the University of St. Gallen. The CC CDQ is part of the research program Business Engineering at the University of St. Gallen (BE HSG).

References Alt, R., Cäsar, M. A., Leser, F., Österle, H., Puschmann, T., & Reichmayr, C. (2001). Architektur für das business networking. St. Gallen: University of St. Gallen. Bakker, H. J. C., & Helmink, J. (2000). Successfully integrating two businesses. Farnham: Gower. Batini, C., Lenzerini, M., & Navathe, S. B. (1986). A comparative analysis of methodologies for database schema integration. ACM Computer Surveys, 18(4), 323–364. Boles, C., Friebe, J., & Luhmann, T. (2004). Typische Integrationsszenarien und deren Unterstützung durch Web Services und andere Technologien. EAI-Workshop 2004 - Enterprise Application Integration, Tagungsband, Tagungsband des GI-/GMDSWorkshops EAI’04, OFFIS, pp. 57–67. Bunjes, B., Friebe, J., Götze, R., & Harren, A. (2002). Integration von Daten, Anwendungen und Prozessen am Beispiel des Telekommunikationsunternehmens EWE TEL. Wirtschaftsinformatik, 44(5), 415–423. Cavana, R. Y., Delahaye, B. L., & Sekaran, U. (2001). Applied business research—qualitative and quantitatvie methods. Milton: Wiley. Conrad, S. (2002). Schemaintegration—Integrationskonflikte, Lösungsansätze, aktuelle Herausforderungen. Informatik - Forschung und Entwicklung, 17(3), 101–111. Cooper, R. B., & Zmud, R. W. (1990). Information technology implementation research: a technological diffusion approach. Management Science, 36(2), 123–139.

Integrating information systems: case studies on current challenges Davis, F. D., Bagozzi, R. P., & Warshaw, P. (1989). User acceptance of computer technology: a comparison of two theoretical models. Management Science, 35(8), 982–1003. Research, F. (2009). The value of a comprehensive integration solution. Cambridge: Forrester Research. Galbraith, J. R. (1968). Achieving Integration through Information Systems. Academy of Management Proceedings, 111–120. Gerst, M., & Bunduchi, R. (2005). Shaping IT standardization in the automotive industry—the role of power in driving portal standardization. Electronic Markets, 15(4), 335–343. Hasselbring, W. (2000). Information system integration. Communications of the ACM, 43(6), 32–38. Heilmann, H. (1989). Integration: Ein zentraler Begriff in der Wirtschaftsinformatik im Wandel der Zeit. HMD, 26, 46–58. Höning, F. (2009). Core business engineering—Metamodell, Vorgehensmodell, Techniken, Ergebnisdokumente und Rollen. St. Gallen: University of St. Gallen. Jain, H., & Zhao, H. (2003). A conceptual model for comparative analysis of standardization of vertical industry languages. pp. 210–221. Jung, R. (2006). Architekturen zur Datenintegration. Gestaltungsempfehlungen auf der Basis fachkonzeptueller Anforderungen. Wiesbaden: Deutscher Universitäts-Verlag. Kim, W., & Seo, J. (1991). Classifying schematic and data heterogeneity in multidatabase systems. Computer, 24(12), 12–18. Kromer, G., & Stucky, W. (2002). Die Integration von Informationsverarbeitungsressourcen im Rahmen von Mergers & Acquisitions. Wirtschaftsinformatik, 44(6), 523–533. Kubicek, H. (1992). The organization gap in large-scale EDI systems. In R. J. Streng, C. F. Ekering, E. van Heck, & J. F. H. Schultz (Eds.), Scientific research on EDI “bringing worlds together” (pp. 11–41). Amsterdam: Samsom. Legner, C., & Vogel, T. (2008). Leveraging web services for implementing vertical industry standards—a model for servicebased interoperability. Electronic Markets, 18(1), 39–52. Legner, C., Vogel, T., Löhe, J., & Mayerl, C. (2007). Transforming Inter-Organizational Business Processes into Service-Oriented Architectures: Method and Application in the Automotive Industry. Kommunikation in Verteilten Systemen - 15. ITG/GI Fachtagung (KIVS 2007), pp. 37–48. Leser, U., & Naumann, F. (2007). Informationsintegration—Architekturen und Methoden zur Integration verteilter und heterogener Datenquellen. Heidelberg: dpunkt.verlag. Linthicum, D. S. (2000). Enterprise application integration. Upper Saddle River: Addison-Wesley. Linthicum, D. S. (2001). B2B application integration: e-BusinessEnable your enterprise. Boston: Addison-Wesley. Luftman, J. N., & McLean, E. R. (2004). Key issues for IT executives. MIS Quarterly Executive, 3(2), 89–104. Madnick, S. E. (1999). Metadata Jones and the tower of Babel: The challenge of large-scale semantic heterogeneity. Proceedings of the 3rd IEEE Meta-Data Conference, pp. 1–13. March, S. T., Hevner, A. R., & Ram, S. (2000). Research commentary: an agenda for information technology research in heterogeneous environments. Information Systems Research, 11(4), 327–341. Mayring, P. (2004). Qualitative content analysis. In U. Flick, E. von Kardorff, & I. Steinke (Eds.), A companion to qualitative research (pp. 266–269). London: Sage. McAfee, A. (2005). Will web services really transform collaboration? MIT Sloan Management Review, 46(2), 78–84. Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A. H. H., & Elmagarmid, A. K. (2003). Business-to-business interactions: issues and enabling technologies. Int VLDB J, 12(1), 59–85. Mertens, P. (1966). Die zwischenbetreibliche Kooperation und Integration bei der automatisierten Datenverarbeitung. Meisenheim am Glan: Technische Hochschule München; Anton Hain Verlag.

173 Mertens, P. (2007). Integrierte Informationsverarbeitung 1. Wiesbaden: Gabler. Meyer, J. A. (2003). Die Fallstudie in der betriebswirtschaftlichen Forschung und Lehre. Wirtschaftswissenschaftliches Studium, 8, 475–479. Österle, H. (1995). Business engineering—Prozess- und Systementwicklung (Band 1: Entwurfstechniken). Berlin: Springer. Österle, H., Winter, R., Höning, F., Kurpjuweit, S., & Osl, P. (2007). Business engineering: Core-Business-Metamodell. Wisu - Das Wirtschaftsstudium, 36(2), 191–194. Papazoglou, M. P., & van den Heuvel, W.-J. (2006). Service-oriented design and development methodology. International Journal of Web Engineering and Technolology, 2(4), 412–442. Reimers, K. (2001). Standardizing the new e-business platform: learning from the EDI experience. Electronic Markets, 11(4), 231–237. Riehm, R. (1997). Integration von heterogenen Applikationen. St. Gallen: Universität St. Gallen. Rogers, E. M. (2003). Diffusion of innovations. New York: Free Press. Rosemann, M. (1999). Gegenstand und Aufgaben des Integrationsmanagements. In A. W. Scheer, M. Rosemann, & R. Schütte (Eds.), Integrationsmanagement (pp. 5–18). Münster: Westfälische Wilhelms-Universität. Scheer, A.-W., & Schneider, K. (2005). ARIS—Architecture of Integrated Information Systems. In P. Bernus, K. Mertins, & G. Schmidt (Eds.), Handbook on Architectures of Information Systems (pp. 605–623). Berlin: Springer. Schmidt, A. (2009). Fallstudie inet-logistics—Integration von Jet Aviation und Fiege. St. Gallen: University of St. Gallen. Schober, F. (1999). Kostenallokation für interorganisationale Informationssysteme. Proceedings der 4. Internationalen Tagung Wirtschaftsinformatik - Electronic Business Engineering, pp. 135– 146. Senger, E. (2004). Zum Stand der elektronischen Kooperation Fallstudien, Muster und Handlungsoptionen. St. Gallen: University of St. Gallen. Sfintesco, A. (2009). Elektronische B2B-Integration in der Logistik Herausforderungen, Lösungsansätze, Verbesserungspotenziale. Institut für Wirtschaftsinformatik, Universität St. Gallen. Singletary, L., Pawlowski, S. D., Watson, E. (2003). What is Applications Integration? Understanding the perspectives of managers, IT professionals, and end users. Ninth Americas Conference on Information Systems, pp. 486–493. Spaccapietra, S., Parent, C., & Dupont, Y. (1992). Model independent assertions for integration of heterogeneous schemas. VLDB Journal, 1(1), 81–126. Specht, G., dos Santos, A., & Bingemer, S. (2004). Die Fallstudie im Erkenntnisprozess: die Fallstudienmethode in den Wirtschaftswissenschaften. In K.-P. Wiedmann (Ed.), Fundierung des Marketing: verhaltenswissenschaftliche Erkenntnisse als Grundlage einer angewandten Marketingforschung (pp. 539–563). Wiesbaden: Deutscher Universitätsverlag. Sperling, S. (2007). Konzeption einer Methode zum Integrationsmanagement bei Unternehmenszusammenschlüssen auf der Basis von multiperspektivischen Unternehmensmodellen. Berlin: Logos. Stadlbauer, F. (2007). Zwischenbetriebliche Anwendungsintegration. IT-Management in Unternehmensnetzwerken. Wiesbaden: Deutscher Universitätsverlag. Vogel, T. (2009). Serviceorientiertes business networking—Referenzarchitektur und Gestaltungsprinzipien. St. Gallen: Universität St. Gallen. Vogel, T., Legner, C., Au, C., Augenstein, C., Löhe, J., Schnabel, F., et al. (2007). SOA for Automotive: Konzept m:n-fähiger Web Services für das überbetriebliche Änderungsmanagement. St. Gallen: University of St. Gallen.

174 Vogler, P. (2006). Prozess- und Systemintegration—Evolutionäre Weiterentwicklung bestehender Informationssysteme mit Hilfe von Enterprise Application Integration. Wiesbaden: Deutscher Universitäts-Verlag. Weigand, H., & van den Heuvel, W.-J. (2002). Cross-organizational workflow integration using contracts. Decision Support Systems, 33(3), 247–265.

A. Schmidt et al. Wigand, R. T., Mertens, P., Bodendorf, F., König, W., Picot, A., & Schumann, M. (2003). Introduction to business information systems. Berlin: Springer. Winter, R., Müller, J., & Gericke, A. (2008). Business Engineering: der St. Galler Ansatz zum Veränderungsmanagement. OrganisationsEntwicklung, 27(2), 40–47. Yin, R. K. (2002). Case study research. Design and methods. London: Sage.