· Programme Integrating and Strengthening the European Research Strategic Objective Networked...

Programme

Integrating and Strengthening the European Research Strategic Objective

Networked businesses and governments Integrated Project / Programme Title

Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application

Acronym

ATHENA Project No

507849 ATHENA – Project Name

Business Interoperability Research ATHENA - Project No

B3

Deliverable D.B3.1

Business Interoperability Framework

Work package – B3.1-4 Leading Partner: HSG

Security Classification: Project Participants (PP)

January, 2007

Version 2.0

IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Business Interoperability Framework Project Number B3 Document Deliverable DB31 Save Date 14.03.07

070313_ATHENA_DB31_V10.doc CONFIDENTIAL Page ii / 96

Table of contents

Background: Business Interoperability Framework within the ATHENA Project 1

Management Summary 2

1 Introduction and Motivation 3 1.1 Challenges in Business Interoperability 3 1.2 Existing Approaches to Interoperability 3 1.3 Objectives and Structure of this Document 4

2 Towards an Excellence Model for Business Interoperability 5 2.1 Defining Business Interoperability 5 2.2 An Excellence Model for Business Interoperability 6 2.3 Unit of Analysis – the “Networked Enterprise” 7 2.4 Structure of the Excellence Model – Building on Organisational Theory 8

3 State of the Art in Business Interoperability 12 3.1 Fundamental Concepts of Interoperability 12 3.1.1 Interoperability Frameworks 12 3.1.1.1 IDEAS Interoperability Framework (IDEAS) 12 3.1.1.2 European Interoperability Framework (EIF) 13 3.1.1.3 e-Government Interoperability Framework (eGIF) 14 3.1.1.4 Levels of Information Systems Interoperability (LISI) 14 3.1.1.5 EICTA Interoperability White Paper 16 3.1.1.6 SIF Implementation Specification 16 3.1.1.7 ATHENA Interoperability Framework (AIF) 16 3.1.1.8 Enterprise Interoperability Maturity Model (EIMM) 17 3.1.2 Enterprise Modelling 19 3.1.2.1 Enterprise Modelling in the Context of Collaborative Enterprises 19 3.1.2.2 Zachman Framework for Enterprise Architecture 20 3.1.2.3 Generalised Enterprise Reference Architecture and Methodology (GERAM) 20 3.1.2.4 GRAI Framework 21 3.1.2.5 Architecture of Integrated Information Systems (ARIS) 21 3.1.2.6 CIMOSA Framework 22 3.1.2.7 Active Knowledge Modelling (AKM) Technology 22 3.1.3 Networked Organisations 22 3.1.3.1 Business Networking 22 3.1.3.2 Networked Organisations 25 3.1.3.3 Inter-organisational Systems 26 3.1.3.4 Coordination Theory 27 3.1.4 Standards 27 3.1.5 Communication Theory - Semiotics 28 3.1.6 Contributions to the Business Interoperability Framework 29 3.1.6.1 Perspectives on Interoperability 29 3.1.6.2 Dimensions of Business Interoperability 30 3.2 Excellence Models 33 3.2.1 EFQM Excellence Model 33 3.2.2 The Capability Maturity Model 36 3.2.3 Collaboration Maturity Grid for the New Product Introduction Process 38 3.2.4 Contribution to Business Interoperability Framework 40


070313_ATHENA_DB31_V10.doc CONFIDENTIAL Page iii / 96

4 Business Interoperability Framework (BIF) 41 4.1 Outline of the Business Interoperability Framework 41 4.1.1 Categories 42 4.1.2 Levels of Business Interoperability in the BIF 42 4.2 Business Interoperability Categories and Related Interoperability Levels 43 4.2.1 Category “Management of External Relationships” (Governance Perspective) 43 4.2.1.1 Cooperation Model 44 4.2.1.2 Cooperation Targets 45 4.2.1.3 Cooperation Management (Roles and Processes) 45 4.2.2 Category “Employees & Culture” (Behavioural Perspective) 45 4.2.2.1 Trust 46 4.2.2.2 Visibility 46 4.2.3 Category “Collaborative Business Processes” (Operational Perspective) 47 4.2.3.1 Public Processes 48 4.2.3.2 Business Semantics 48 4.2.4 Category “Information Systems” (Electronic Interaction Perspective) 49 4.2.4.1 Interaction Type 49 4.2.4.2 Connectivity / Cooperation Architecture 49 4.2.4.3 Security & Privacy 50 4.3 Contingencies 50 4.3.1 Internal Contingencies 50 4.3.1.1 Coordination Area and Targets 51 4.3.1.2 Business Partners / Business Network 52 4.3.1.3 Cooperation Dynamics 52 4.3.1.4 Network Governance 53 4.3.1.5 Interdependence 54 4.3.1.6 Specificity & Frequency 55 4.3.2 External Contingencies 55 4.3.2.1 Legislation / Regulation 56 4.3.2.2 Standardisation 56 4.3.2.3 E-Business Maturity 56

5 Application of the Business Interoperability Framework 58 5.1 How to Apply the Business Interoperability Framework 58 5.2 Application in the Automotive Industry 58 5.2.1 Situation in the Automotive Industry 58 5.2.2 Business Relationships in the Automotive Value Chain – Two Cases 60 5.2.3 Analysis of Business Interoperability 61 5.2.4 Conclusions 63 5.3 Retail industry 64 5.3.1 Background 64 5.3.2 Situation in the European Retail Industry 64 5.3.2.1 Collaboration in the Retail Industry 64 5.3.2.2 External Contingencies in the Retail Industry 65 5.3.2.3 Metro Group 67 5.3.3 Assessing Business Interoperability of Metro Group 67 5.3.3.1 Management of Business Relationships 67 5.3.3.2 Collaborative Business Processes 68 5.3.3.3 Employees & Culture 70 5.3.3.4 Information systems 70 5.3.3.5 Discussion 71 5.3.4 Summary and Conclusion 72


070313_ATHENA_DB31_V10.doc CONFIDENTIAL Page iv / 96

6 Interoperability Guidelines 73 6.1 Technical Interoperability Solutions 73 6.2 Deriving Business Interoperability Profiles (BIP) 74 6.2.1 Method of Work 74 6.2.2 Business Interoperability Profiles - Description 74 6.2.3 BIP 1: Ecosystem Design & Cooperation Strategy 77 6.2.4 BIP 2: Design of “Public Process” 77 6.2.5 BIP 3: Coupling with Existing "Public Process" 77 6.2.6 BIP 4: Definition of Business Semantics 77 6.2.7 BIP 5: Design of Services and Business Documents 78 6.2.8 BIP 6: Implementation of Process Integration 78 6.2.9 BIP 7: Implementation of Data Integration 78 6.3 Summary and Outlook 79

Appendix A Business Interoperability Framework 80

Appendix B Contingency Values 83 B.1 Collaboration Space 83 B.1.1 E-Business Maturity 83

Appendix C Glossary 86

Literature 88


070313_ATHENA_DB31_V10.doc CONFIDENTIAL Page v / 96

List of Figures Figure 2-1. Different Aspects of Business Interoperability 5 Figure 2-2. The Excellence Model of Business Interoperability 7 Figure 2-3. The Networked Enterprise 8 Figure 2-4: Contingency Theory of Organisation 9 Figure 2-5. Contingency Theory Applied to Business Interoperability 10 Figure 2-6. The Optimum Level of Business Interoperability 10 Figure 3-1. IDEAS Interoperability Framework [Blanc 2005] 12 Figure 3-2: ATHENA Interoperability Framework [ATHENA 2007] 17 Figure 3-3. The Three Levels of Business Engineering Applied to Business Networking 23 Figure 3-4: Interaction Type and Levels of Agreement in Inter-organisational Integration (Adapted from [McAfee 2005b, McAfee 2005a]) 27 Figure 3-5. Message standards 28 Figure 3-6. Semiotic Aspects of Communication 29 Figure 3-7. Analysis of State of the Art Approaches 32 Figure 3-8. The EFQM Excellence Model [EFQM 2003d, p.5] 33 Figure 3-9. Structure of the CMM [Paulk et al. 1993a, 29] 36 Figure 3-10. Collaboration Maturity Grid for the Structured Develoment Process [Fraser 2003, 1518] 39 Figure 3-11. Summary Maturity Grid [Fraser 2003, 1519] 39 Figure 4-1. Assessing the Level of Business Interoperability 42 Figure 4-2. Criteria in Category “Management of External Relationships” 44 Figure 4-3. Criteria in Category “Employees & Culture” 46 Figure 4-4. Criteria in Category “Collaborative Business Processes” 47 Figure 4-5: Criteria in Category “Information System” 50 Figure 4-6: Coordination Area and Level of Business Interoperability 52 Figure 4-7: Business Partners and Level of Business Interoperability 52 Figure 4-8: Cooperation Dynamics and Level of Business Interoperability 53 Figure 4-9: Network Governance and Level of Business Interoperability 53 Figure 4-11: Specifity / Frequency and Level of Business Interoperability 55 Figure 4-12: Standardisation and Level of Business Interoperability 56 Figure 4-13: e-Business Maturity and Level of Business Interoperability 57 Figure 5-1. Structure and application of the BIF 58 Figure 5-2. Emerging roles in the automotive value chain 59 Figure 5-3. Level of Business Interoperability for Case 1 and 2 62 Figure 5-4. Level of Business Interoperability for Case 1 and 2 (Cont.) 63 Figure 5-5: Management of External Relationships (Metro) 68 Figure 5-6: Collaborative Business Processes (Metro) 69 Figure 5-7: Employees & Culture (Metro) 70 Figure 5-8: Information Systems (Metro) 71 Figure 6-1. Method of Work 74 Figure 6-2. Business Interoperability Profiles - Overview (Part I) 75 Figure 6-3. Business Interoperability Profiles - Overview (Part II) 76 Figure 6-4. e-Business Index by Sector [e-Business Watch 2005, 2] 83 Figure 6-5. E-Business Index by Country [e-Business Watch 2005, 2] 84 Figure 6-6. E-Business Index by size-band [e-Business Watch 2005, 3] 85


070313_ATHENA_DB31_V10.doc CONFIDENTIAL Page vi / 96

List of Tables Table 0-1. Description work package B3.1 from DoW 1 Table 3-1. Problem Space for Collaborative Enterprise Integration (cf. [ATHENA 2005c, 7]) 19 Table 3-2. Approaches for Designing Networkability (adapted from [Österle et al. 2001a, 83f.]) 24 Table 3-3. Existing Approaches to Organisation Strategies 25 Table 3-4. Relevant Sub-Criteria and Guidance Points for Business Interoperability (cf. [EFQM 2003b]) 34 Table 3-5. Attributes of the RADAR elements (cf. [EFQM 2003a]) 35 Table 3-6. CMM Maturity Levels and Key Process Areas (cf. [Paulk et al. 1993a, Paulk et al. 1993b, Adler 2005]) 37 Table 3-7. Key Process Areas of the Collaboration Framework (cf. [Fraser 2003, 1505]) 38 Table 4-1. Business Interoperability Framework – Categories and Contingencies 41 Table 4-2. The Five Levels of Business Interoperability in the BIF 43 Tabelle 4-1. Internal Contingencies 51 Figure 4-10: Interdependence and Level of Business Interoperability 54 Table 4-3. Transaction characteristics of commercial transactions (cf. [Williamson 1979]) 55 Table 4-4. External Contingencies 56 Table 5-1. Changing roles in the automotive value chain - core competencies and responsibilities 59 Table 5-2. External Contingencies 60 Table 5-3. Comparison of internal contingencies of case 1 and 2 (based on [Maidl/Axtner 2004, Maidl et al. 2005] for case 2) 61 Table 5-4: External contingencies in the retail industry 66 Table 6-1. Component Indicators of the E-Business Scorecard [e-Business Watch 2005, 215] 83 Table 6-2. E-business Maturity Levels – Industries 84 Table 6-3. E-business Maturity Levels – Countries 84


070313_ATHENA_DB31_V10.doc CONFIDENTIAL Page 1 / 96

Background: Business Interoperability Framework within the ATHENA Project

Numerous new business opportunities and business solutions are created for enterprises that work effectively and efficiently together in business networks. This includes new or improved products and services (e.g. combination of physical products and electronic services from different partners), new ways in which business partners can cooperate (e.g. collaborative product design, collaborative maintenance), and more effective management of value chains (e.g. through real-time monitoring of distributed value chains). A prerequisite for efficient cooperation is the existence of ICT systems to support the communication between business partners, as well as the compatibility of their business strategy, organisation and culture. This is the concept of interoperability.

ATHENA (“Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and their Applications”) is an Integrated Project sponsored by the European Commission [ATHENA 2005a]. Building upon the ambitious Vision Statement “By 2010, enterprises will be able to seamlessly interoperate with others”, ATHENA aims to make a major contribution to interoperability by identifying and meeting a set of inter-related business, scientific & technical, and strategic objectives.

ATHENA will achieve its objectives through the execution of work organised into three interlinked and mutually reinforcing Action Lines: Action Line A: Research and Development focussing on Technology. Action Line B: Community Building focussing on Business. Action Line C: Management focussing on Project Governance.

This document was developed in sub-project B3 in Action Line B. Action Line B aims at laying down the foundation work for long-term research into interoperability from a business perspective. The overall context is the future company, creation and management of dynamic collaborative networks, knowledge management to support innovation, and evolution towards digital ecosystems. The full description of work package B3.1 from the DoW of the ATHENA project is provided in the following table (cf. Table 0-1).

Work Package Description Work package B3.1 Business Interoperability Framework

Leading participant HSG Starting M01 Ending M36 Objectives

To provide a framework for determining business challenges relating to interoperability. Description of Work

Task B3.1.1 Identity Business Interoperability main elements. Identity the main elements which constitute “Business Interoperability” and explore their contexts and applications in industrial and other business environments. Explore business process integration issues from a business perspective, and the achievement of integration through leveraging ICT and emerging applications and services for supporting business goals.

Task B3.1.2 Establish an initial set of trusted eBusiness requirements. Research, analyse and identity the core elements of trust that enable eBusiness interoperability and their application in industrial environments. Explore the common resources and community services that might be needed in facilitating and enabling a more “trusted” eBusiness environment.

Task B3.1.3 Establish an initial set of Business Interoperability Guidelines. Research, analyse and develop general guidelines for facilitating business interoperability, with due consideration of sector-specific requirements and industrial trends.

Collaboration with B4 Investigation and identification of user requirements

Receives from

Provides to A1 – A6 Business requirements and drivers for interoperability B1 Development of services for the EIC B6 Material for training courses

Table 0-1. Description work package B3.1 from DoW

Result of this work package is a comprehensive Business Interoperability Framework (BIF) which outlines the main elements of business interoperability. It supports in assessing the level of inter-operability from a business perspective, and in determining the optimum level of interoperability for a company given the company’s strategy and competitive environment. It complements the ATHENA Interoperability Framework (AIF) developed in sub-project A4 which details interoperability problems, issues and requirements and structures the results of ATHENA Action Line A (tools, models, approaches, methodologies, ontologies).



Management Summary

This document summarises the results of the ATHENA B3 project relating fundamental concepts which underlie business interoperability.

Although the research community sees networked organisations as an undisputable reality, companies find it very time-consuming and difficult to establish electronic business relationships with a larger number of business partners. Prior work in B3 already highlighted that enterprises face major challenges when implementing closer forms of cooperation. Challenges include the lack of responsi-bilities for the space between businesses; the heterogeneity of terminologies, business processes and information systems; and the prohibitive need for resources to setup electronic business relationships or trust issues. This motivates the extension of the more technically focussed notion of interoperability to cover organisational and operational aspects of setting up and running electronic collaboration with external business partners. In the context of this document business interoperability is defined as “the organisational and operational ability of an enterprise to cooperate with its business partners and to efficiently establish, conduct and develop IT-supported business relationships with the objective to create value”. It builds on the vision that full interoperability is achieved when companies are able to cooperate with new partners without any additional cost involved and even small businesses can easily participate in electronic business relationships. This scalability of electronic business relationships is also referred to as m:n connectivity.

The Business Interoperability Framework (BIF) consolidates existing research in the fields of inter-operability, networked organisations and B2B integration. This deliverable deduces fundamental con-cepts of how a company can achieve business interoperability and comes up with four main consti-tuents of business interoperability: Management of External Relationships, Employees & Culture, Business Process and Information Systems. These constituents are further detailed in Section 4 by a set of sub-criteria which represent the key design decisions for establishing interoperable electronic business relationships. In order to explain why some investments in interoperability are value-adding and others are not, the Business Interoperability Framework makes use of contingency theory. It postulates that the level of interoperability has to fit internal and external contingencies. Internal contingencies relate to characteristics of the coordination area as well as the business network, whereas external contingencies comprise environmental factors, such as e-business maturity or level of industry standardisation. The Business Interoperability Framework thereby explains the observation that the level of interoperability differs between very integrated and mature supply chains (e.g. the automotive or hightech industry) and more fragmented supply chains (e.g. facility management).

In order to demonstrate how to apply the BIF, three case studies are included in this document. We have selected the automotive and retail industry as area for application since we consider these industries as being very advanced with regard to B2B integration. This application of the BIF leads to several interesting insights: Even in mature industries, companies are not fully interoperable. Electronic relationships are usually established as 1:1 or 1:n connections. Limitations to achieve full interoperability may result from lacking industry standards for more intensive forms of collaboration (e.g. in product development), from business partners which are less IT-savy or from the simple fact that full electronic connectivity does not pay off given the existing transaction volumes. In the case of the Automotive as well as the Retail industry, enterprises realise different levels of business interoperability for different partner types. This is due to a broader portfolio of partnerships and a segmented partnering approach: As demonstrated for the case of BMW and Metro, an enterprise may collaborate based on standardized logistics processes with most of the supplier base (with a relatively high level of business interoperability), and at the same time realize more intensive collaboration with selected partners. The latter typically are formed as one-to-one relationships given the fact that they are built to achieve competitive advantage.

This document concludes with an initial set of interoperability guidelines which link business interoperability issues to the appropriate interoperability solutions and tools. To this purpose, a set of Business Interoperability Profiles (BIP) are described. These BIPs address recurring business interoperability issues and assist an organisation to select from the broad range of emerging interoperability solutions.



1 Introduction and Motivation

1.1 Challenges in Business Interoperability

Companies increasingly achieve competitive advantage by forming innovative networks of value creation and bundling core competencies from different partners. This is the core idea of concepts that have been published under the term of networked or virtual organisations, business networking or value networks. Progress in information technology (IT) contributes to more decentralised forms of organisations. Given the vision of the ATHENA consortium that “by 2010, enterprises will be able to seamlessly interoperate with others”, technical interoperability of software applications will generate numerous business opportunities and business solutions.

Although the research community sees networked organisations as an undisputable reality, companies find it very time-consuming and difficult to establish electronic business relationships with a larger number of business partners. Enterprises that wish to implement closer forms of cooperation with their business partners face major challenges (cf. [Kim et al. 2001, 473f], [Ross et al. 2001, 3], [Jun et al. 2000, 412]¸ [Leser 2005]): Win-Win-Situation: Reciprocal benefit is the prime motivation for partners to participate in collaborative processes, with lack of trust being the most important barrier. Both issues contradict buyer-supplier relationships that focus on squeezing prices [Hoyt/Huq 2000]. Heterogenity of process and information systems: Process models, data models and information systems differ between companies and limit “instant integration” capabilities. Despite the rapid advent of Internet technologies and the wide use of packaged enterprise applications, decades of isolated business models have left semantic islands with own standards and services, resulting in individual expectations and capabilities [Kling et al. 1996, 20f]. Responsibility gap: Responsibility for the space between businesses is not reliably assigned. New issues for businesses like network outages, disruptions of syntactic or semantic data integrity or system updates affect collaborative processes. In contrast with internal processes, responsibilities have not been assigned and readily lead to conflicts [Kumar/Van Dissel 1996, 296]. Prohibitive need for resources: The resources required for integrating partners exceed the capabilities of internal IT. At the same time, partners do not have such capabilities either [Dai/Kauffman 2001, 63]. Trust & intellectual property: The intellectual property of collaborative process design and the exchange of information needs to be protected from competitors, but shared with partners. Exchanged messages contain confidential information that must be safeguarded against unauthorised access and operations must be fail-safe. Many-to-many relationships: Collaboration with one partner is a starting point. To reflect and improve existing flows of goods, information flows need to be optimised across several tiers and several partners. The problems above have to be solved several times over. (cf. [Le 2002, 117]) The ability to quickly and inexpensively integrate a lot of processes and supply chain partners is the key to benefit from cooperation processes (cf. [El Sawy 2003]).

1.2 Existing Approaches to Interoperability

So far, three major approaches exist which treat the issue of interoperability: Networked organisations and value model research: Important scientific contributions have come from transaction cost theory (cf. [Williamson 1989a]), organisational theory (cf. [Sydow 1992], [Snow et al. 1992]), new institutional economics (cf. [Malkin 1995], [Williamson 1998]), coordination theory (cf. [Malone/Crowston 1994]), business networks and inter-organisational systems (cf. [Klein 1996a, Wigand et al. 1997]). Networked organisations and value model research explain the emergence and success factors of new types of networked organisation, but tend not to focus on business interoperability and lack supporting management techniques (cf. [LI 2005]). Various interoperability frameworks, e.g. the e-Government Interoperability Framework, the Levels of Information Systems Interoperability (LISI) framework or the European Interoperability Framework (EIF), have emerged over the last years. These frameworks provide a systematic view on various interoperability dimensions. Until now, they are either focussed on technical interoperability or only applicable in specific contexts, e.g. e-government. This motivates research within the ATHENA project, which aims at providing a more holistic interoperability framework. Standards: In their early study, [Benjamin et al. 1990] reported that insufficient availability of standards has been the most important barrier to inter-organisational integration. Up to date standards are mostly



available for communication services and on the syntactical level [Bussler 2003]. This also applies to WS-I Organisation (Web Services Interoperability Organisation, http://www.ws-i.org) which is chartered to promote interoperability across platforms, operating systems and programming languages by Web Service standards, including Simple Object Access Protocol (SOAP), Universal Description, Discovery and Integration (UDDI) and Web Services Description Language (WSDL). Various initiatives have been launched to extend XML-based standards to comprise standardisation on the semantic level either by industrial associations – e.g. RosettaNet Partner Interface Protocols (PIPs) in the hightech industry, ChemXML as part of CIDX in the chemical industry, the Universal Product Code (UPC) or the European Article Number (EAN) in the retail industry – or by independent providers such as Dun & Bradstreet for company identifiers. Standards on the pragmatic level are available within companies, but solutions which span across multiple organisations, such as Bolero.net which creates trust among business partners by establishing business agreements and legal frameworks, are rare. Besides the neglect of semantical and pragmatical issues in existing standards, referred to as the ‘organisational gap’ by [Kubicek 1992], the enforcement and the overlapping between standards remain a problem.

Most existing frameworks and standards cover the technical aspects by suggesting standards for presenting, collecting, exchanging, processing and transporting data. The research on networked organisations and value models mainly covers strategic and organisational topics. However, a syste-matic analysis on business issues associated with interoperability of organisations is currently lacking.

1.3 Objectives and Structure of this Document

Objectives of this document are

1. to define business interoperability (as opposed to technical interoperability);

2. to outline the structure of a comprehensive Business Interoperability Framework;

3. to identify the main elements which constitute “Business Interoperability”;

4. to apply the Business Interoperability Framework to selected cases; and

5. to identify an initial set of business interoperability guidelines.

As such, this document builds on and further enhances previous research in ATHENA sub-project B3. Since interoperability addresses the interplay between business strategy, organisational design and information system design, the document follows the design-science approach outlined by [Hevner et al. 2004]. Based on the review of different research streams and approaches to interoperability, it deduces the relevant artefacts and comes up with a first version of a comprehensive business inter-operability framework. Case studies are used to validate and enhance the framework.

This document is structured as follows: Section 2 provides the baseline by defining business inter-operability and outlining the structure of the Business Interoperability Framework. Section 3 reviews approaches and models which may serve as input to the further development of the Business Inter-operability Framework. In particular, it reviews the existing body of work on interoperability, networked organisations and value networks in order to identify the dimensions that constitute business inter-operability. Section 4 details the Business Interoperability Framework by defining criteria and related levels of interoperability. Section 5 applies the Business Interoperability Framework to different busi-ness environments and introduces case studies from the automotive and the retail industry. Section 6 suggests an initial set of interoperability guidelines which link business interoperability issues to the broad range of emerging interoperability solutions.



2 Towards an Excellence Model for Business Interoperability

This section lies the foundation of the Business Interoperablity Framework: Based on the definition of business interoperability in Section 2.1, it

2.1 Defining Business Interoperability

The definition of interoperability that underlies the ATHENA project is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” [ATHENA 2005a]. From a business perspective, technical interoperability allows for seamlessly propagating and sharing information between partners. This results in business decisions related to forming innovative networks of value creation and defining new ways of collaboration with partners.

In the context of the ATHENA project, we define business interoperability as “the organisa-tional and operational ability of an enterprise to cooperate with its business partners and to efficiently establish, conduct and develop IT-supported business relationships with the objective to create value.”

Based on this definition, being interoperable refers to the organisational design and imple-mentation of external business relationships, including cultural aspects as well as the ICT solution. Thus, business interoperability describes specific characteristics of the inter-organisational design from an enterprise perspective. It extends the more technically focussed notion of interoperability to cover organisational and operational aspects of setting up and running IT-supported relationships. Business interoperability builds on the concept of networkability (cf. [Wigand et al. 1997, 11, Österle et al. 2001b, 5]). Networkability is a continuation of coordination theory and sees coordination as the management of relationships of dependence (cf. [Malone et al. 2003]). Among the different issues which may arise on the business level are the following (cf. Figure 2-1): Defining the cooperation model and identifying target partners; defining consistent business goals; formalising these goals by contracts and service level agreements; establishment of a climate of trust and confidence among business partners; providing visibility to external partners without loosing competitive advantage; aligning the individual business processes of partners in order to allow for coordination; defining a common “language” by aligning the individual business semantics; deciding on the appropriate level of electronic interaction; and deciding on standards and platforms to use.

Enterprise B(Customer)

Enterprise A(Supplier)

Targets / Benefit ?

Cooperationmodel ?

Visibility?

Trust?

Collaborationprocess ?

Business semantics?

Interaction type?

Connectivity?

Security & Privacy?

Cooperationmanagement?

Business Model / Value Chain

Governance

Roles & Responsibilities

Tasks

Functions

Applications

Data

Info

rmat

ion

Sys

tem

sB

usin

ess

Pro

cess

esS

ocia

lCap

ital

Stra

tegy

Figure 2-1. Different Aspects of Business Interoperability



When comparing different industries, it becomes evident that they are characterised by different levels of business interoperability. In the hightech industry, the supply chain between Original Equip-ment Manufacturers (OEM), contractors and component manufacturers is tightly integrated. Com-panies like Cisco or HP adhere to process standards (e.g. RosettaNet) and use collaboration platforms (e.g. Viacore) which ease electronic collaboration within their value chain (cf. [Leser et al. 2005]). In many other areas, such as in facility management, the fragmentation of the value chain and the size of the companies make it more difficult to establish similar IT-supported business relationships. This examples illustrates that the achievable level of business interoperability depends on industry maturity with regard to electronic business as well as on the target cooperation scenario.

The breakthrough for networked organisations will occur when companies can cooperate with new partners without any additional cost involved and even small businesses can easily participate in electronic business relationships. This scalability of electronic relationships is called m:n capability. However, few examples (e.g. SWIFT) of successful n:m relationships exist so far.

2.2 An Excellence Model for Business Interoperability

The Business Interoperability Framework (BIF) is intended to describe fundamental concepts how a company can achieve business interoperability. In addition, the BIF will serve as a basis for assess-ment and a guideline towards excellence. To this purpose, it has to fulfil the following requirements: As a comprehensive framework, the BIF defines the relevant elements (or dimensions) which constitute business interoperability, i.e. different aspects of inter-organisational design. As outlined in Section 0 this goes beyond the technical aspects, such as platforms, communication protocols, messages or data standards. Also, it includes aspects of business processes and strategy. In order to assess business interoperability of an organisation and to benchmark it against others, the BIF has to operationalise the elements of business interoperability. Ideally, the BIF would comprise a set of criteria which are well-described and measurable and distinguish between higher and lower levels of business interoperability. Serving as a guideline towards excellence, the BIF has to characterise different options of inter-organisational designs and allow for identifying areas for improvement. The BIF has to take into account that interoperability requirements may differ between organisations. The configuration of the business network and the industry environment impact the optimum level of interoperability. The BIF has to take into account that the highest level of interoperability is not necessarily the optimum level of business interoperability. In a first stage, the BIF has to represent a generic framework which abstracts from an industry or cooperation context. It can be further detailed and applied to a specific cooperation model (e.g. supplier integration) or a specific organisation.

The Business Interoperability Framework is complemented by the Interoperability Impact Assess-ment Model (IIAM) which is developed by INSEAD in the context of the ATHENA project: The Business Interoperability Framework (BIF) describes the level of business interoperability of an organisation. It provides the assessment of different levels of interoperability as an input to the IIAM. The Interoperability Impact Assessment Model (IIAM) describes and analyses the various possibilities of value creation by achieving higher levels of interoperability. The IIAM will provide measures which characterise the effect of interoperability on the performance of the organisation or the entire value chain (cf. Figure 2-2).1

Both, the BIF and the IIAM, make up the Excellence Model for Business Interoperability.

1 Please refer for detailed information on the IIAM to the deliverable D.B3.3.



Figure 2-2. The Excellence Model of Business Interoperability

2.3 Unit of Analysis – the “Networked Enterprise”

Business interoperability describes the relationships between an enterprise and its business partners, such as customers, suppliers or external service providers. The objective of the BIF is to characterise the level of business interoperability of this enterprise and to guide it towards the optimum level of interoperability. We assume that an enterprise is able to influence business interoperability by setting its organisational boundaries and designing its inter-organisational relationships. Hence, the BIF takes an enterprise-centric approach with the “networked enterprise” being the unit of analysis (Figure 2-3).

Our research concentrates on B2B relationships which may take either the form of market-based interactions or of more intensive, long-term collaboration. [Fleisch/Österle 2000b] distinguish four operative coordination areas, that show low dependencies between each other, but a high level of dependency within each area: The goal of supply chain management is to handle operative planning and execution processes as efficiently as possible. It multiplies clearly defined outputs and tries to utilise the effects of economies of scale in order to achieve profit. Supply chain management is characterised by a large integration depth in the coordination of its well structured processes. It prefers the coordination form of a stable network. The goal of relationship management is to win customers and/or suppliers and to gain their loyalty. Relationship management tries to cover as wide a spectrum of customer requirements as possible in order to utilise the effects of economies of scope. Partners in this area are above all customers with whom a market-like relationship exists. The goal of the coordination area innovation is the rapid creation of new products, which requires a dynamic environment in the early phases. As a project advances in maturity a business unit will coordinate with a large number of different partners and, depending on the task in question, follow the rules of different forms of coordination. The area infrastructure distinguishes itself from supply chain management in terms of content, which does not necessarily show a high degree of repetition (e.g. preparation of a corporate balance sheet), and its transactions may be complex in nature (e.g. outsourcing of IT). There is a high level of dependency between the infrastructure partners which calls for the relationship to be stable.

These four areas represent different cooperation models: They pursue different economic goals, implement different types of network, are characterised by widely divergent cultures, link different partners, have interdependencies based on different resources and use different information systems for coordination purposes.

Inter-organisational coordination relies on a collaboration infrastructure, i.e. electronic services and platforms. The model of the networked organisation (cf. Figure 2-3) brings together those design



areas of a company which are most important from the networking point of view. It provides an indication of how to usefully break down the networking problem, without neglecting the interdependencies of the delimited areas. Moreover, it serves as reference framework for deducing recommended action while considering the central role of IT and the collaboration infrastructure.

Enterprises can participate in several networks simultaneously, for example, if they operate in several value chains or offer a wide range of products and/or services. At the same time these networks may mutually influence each another. They use different information systems and information technologies, depending on the business processes to be coordinated. (cf. [Fleisch/Österle 2000b]). Consequently, it is not always appropriate to assess business interoperability on the level of the enterprise, but rather for a specific business unit or a specific coordination area (or cooperation model).

NetworkedEnterprise

Collaborationinfrastructuredefined by networkingstandards and process, supporting and basicservices

Innovation

DevelopmentPartner

CustomerR

elat

ions

hip

Man

agem

ent

Infrastructure

Sup

ply

Cha

in

Man

agem

ent

Supplier

Outsourcingpartner

Figure 2-3. The Networked Enterprise

2.4 Structure of the Excellence Model – Building on Organisational Theory

As discussed earlier, we assume that there is no optimum level of business interoperability and no direct effect of business interoperability on performance. In fact, only if the inter-organisational design (business interoperability) fits environmental as well as strategic factors, positive effects on the overall performance will be achieved. Similar dependencies have been outlined by [Donaldson 2001] in the Contingency Theory of Organisational Design. [Donaldson 2001] states that the relationship between some characteristic of an organisation (variable X) and its organisational effectiveness (variable Y) is determined by contingency factors (variable W). Figure 2-4 exemplifies the contingency theory for the organisational structure of a company. An organisational structure (e.g. hierarchical, organic, bureaucratic or functional) which “fits” the contingency factors, such as size of the organisation, environment or organisational strategy, is more effective with regard to efficiency, profitability or innovation rate. [Donaldson 2001] distinguishes between contingencies within the organisation (e.g. task uncertainty, task interdependence) and outside of it, i.e. environmental contingencies (e.g. environmental uncertainty).



+ -

+-

+-

Organisational performancee.g. efficiency, profitability,

innovation rate

Characteristics of an organisatione.g. organisational structure

External contingencies e.g. environment

Internal contingencies e.g. size of the organisation,

organisational strategy

Variable X

Variable Y

Variable W1 Variable W2

Figure 2-4: Contingency Theory of Organisation

It follows that, if the contingency, its value and its influence on the organisational effectiveness is known to the enterprise, the enterprise is able to adopt its organisational characteristic, such as its structure. Thereby, it achieves a positive effect on its performance. On the other hand, if the organisa-tional structure “misfits” the contingency, it will have a negative impact on the performance. As an example, the size of an organisation affects the degree to which an organisation’s structure is bureau-cratic and decentralised. The bureaucratic, decentralised structure fits large organisations, since a large size leads to repetitive operations and requires clear rules for decision making. On the contrary, a centralised structure fits small organisations, because all decisions can effectively be made perso-nally by the management. Once a contingency has changed, resulting in a misfit of the organisational characteristic, enterprises try to adopt organisational characteristics to restore the fit, and therefore achieve again higher performance. (cf. [Donaldson 2001])

Universalistic organisational theories argue that the maximum level of organisational effectiveness results from the maximum level of a structural variable, such as specialisation. In contrast, a main characteristic of the contingency theory of organisations is that it does not assert one best strategy to organise: "Contingency theory (…) sees maximum performance as resulting from adopting, not the maximum, but rather the appropriate level of the structural variable that fits the contingency. Therefore, the optimal structural level is seldom the maximum, and which level is optimal is dependent upon the level of the contingency variable." [Donaldson 2001, 4] This view is also shared by [Daft 2004] who defines organisations as “(1) social entities that (2) are goal-directed, (3) are designed as deliberately structured and coordinated activity systems, and (4) are linked to the external environment.” [Daft 2004, 11] Two aspects of this definition are particularly valuable for business interoperability. First, organisations are designed by purpose, i.e. the top management decides how the structure of the organisation ought to be. If the structure of an organisation has any influence on interoperability (which e.g. [Bowersox et al. 2003] claim), the top management is able to adopt and shape the organisation in a way that it becomes interoperable. Second, organisations are not closed systems that are independent of their environment. They are open systems that “must interact with the environment to survive” and “must continuously adapt to the environment.” [Daft 2004, 14] Organisational environment can be defined as “all elements that exist outside the boundary of the organisation and have the potential to affect all or part of the organisation.” [Daft 2004, 136]. This aspect is considered through the external contingencies of business interoperability.

Applied to business interoperability, we consider the design of relationships with external business partners as a characteristic of the organisation (Variable X). The kind of effect on the organisation per-formance depends on contingencies within the organisation (e.g. specificity and frequency of trans-action) as well as outside of it, i.e. external contingencies (e.g. e-business maturity, industry standards, legislation/regulation). The resulting high-level contingency theory for business interoperability is represented in Figure 2-5. It will be further enhanced in Section 4.



+ -

+-

+-

Value creation

Business interoperability

External contingencies e.g. e-business maturity, industry standards, legislation/regulation

Internal contingencies e.g. specificity of transaction,

frequency of transaction

Variable X

Variable Y

Variable W1 Variable W2

Figure 2-5. Contingency Theory Applied to Business Interoperability

[Donaldson 2001, 17] postulates that external and internal contingencies are not independent, in fact, the “Environmental contingencies indirectly shape the organisation through the intervening variables of the intraorganisational contingencies.” For example a dynamic environment (external) leads to uncertainty within the organisation and therefore also to uncertainty in the tasks the organisation conducts (internal). The interdependence between internal and external contingencies is also valid for business interoperability.

Applying the concept of an optimum rather than a maximum level of the organisational characteristic to the contingency theory of business interoperability, the maximum interoperability level is not necessarily the ideal or optimum level. For a specific cooperation scenario, i.e. a certain level of contingency factors, also lower levels may be sufficient (cf. Figure 2-6). For example, trust between business partners does not play a decisive role in electronic invoicing scenarios, whereas for collaborative product development it may be very important. Companies that always seek the maximum level of interoperability hence can misfit contingency factors. A misfit results in lower efficiency of business relationships, such as over-investments in interoperability.

Dimension (Sub criteria)

5 (fully interoperable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Cooperation Model / Scenario

Cooperation model is defined and documented, cooperations are established according to cooperation model

Cooperation model is defined and documented (e.g. in company strategy)

Established cooperations; but no defined cooperation model

Occassional ad-hoc cooperations; no clear cooperation model

No cooperation, focus on inhouse capabilities

…

Cooperation management

A steering board conducts periodic reviews of the cooperation

0 unregular reviews of cooperation are performored; no steering board defined

0 no cooperation management

…

Cooperation process ("Public Process")

"public" processes (n:m) are co-defined with business partners, documented and reflect industry standards

0 Defined and documented private process exists, but it is used inconsistently, and is not manageable or practical

0 cooperation processes with partners are performed ad-hoc

…

Trust Blind faith (mutual sense of trust and confidence, appreciation on both sides of continuing value)

Good working relationship (Growing sense of trust and confidence)

Information is shared "Better the devil you know…"

Mistrust (Them and us attitude, new skills jealously protected)

…

Electronic channel Machine - machine 0 human - machine (e.g. portal, …)

0 human - human (e.g. phone, fax, e-mail)

…

Employee & Culture - "How do we behave?"

Information Systems - "What are the enabling technologies we use?"

Level of Business Interoperability

Strategy & Business Model - "What do we want to achieve?"

Governance - "How are we organised?"

Business processes - "How will it be executed?"

Optimum level of interoperability (“fit”) maximum performanceAs-is level of interoperability (“misfit”) suboptimal performance

External contingencies Internal contingencies

Figure 2-6. The Optimum Level of Business Interoperability



The performance of the company refers to how efficiently and effectively it is able to transform the inputs to outputs. The stakeholders of the organisation (internal and external) are interested in its performance. Their satisfaction level can be assessed as an indication of the organisation’s efficiency and effectiveness. (cf. [Daft 2004])

External stakeholders and their interests include (cf. [Daft 2004]): Owners and shareholders (financial return), Customers (high-quality goods and services, value), Suppliers (satisfactory transactions, revenue from purchases), Community (good corporate citizen, contribution to community affairs), Union (worker pay, benefits), Government (obedience to laws and regulations, fair competition).

Interactions with external stakeholders and their interest in the organisation’s performance influence its interoperability. The optimum level of interoperability is where it “fits” the interests of external stakeholders, which will result in maximum performance.



3 State of the Art in Business Interoperability

The following section discusses and reviews existing research which may serve as a baseline for the business interoperability excellence model. The outline is as follows: Section 3.1 reviews models and frameworks explaining the fundamental concepts of interoperability: We hereby consider interoperability frameworks, reference models and research on networked organisations.

The results of this analysis will be used in Section 4. Section 4 identifies a set of criteria for business interoperability and related contingencies. Section 3.2 analyses excellence models and their structure. This includes maturity and excellence models which are either generic or applicable to a specific industry context.

These models will provide input for creating an excellence model for business interoperability.

3.1 Fundamental Concepts of Interoperability

We shortly describe and compare these models and frameworks using a common structure. Regarding the BIF, the following aspects are of relevance: Scope, i.e. the domain in which the framework or model is applicable (area, industry) and/or the geographical region, definition of interoperability and its applicability to our notion of business interoperability, and the main elements which constitute interoperability.

3.1.1 Interoperability Frameworks

Over the past years, a number of interoperability frameworks have emerged, mostly with focus on the technical aspects of interoperability (e.g. technical infrastructure, data formats, message formats) or on a specific context (e.g. government). The frameworks which will be presented in the following section have been chosen for their wide awareness and their relevance to the Business Interoperability Framework. They are the IDEAS Interoperability Framework, which builds the foundation work for the ATHENA project, the European Interoperability Framework (EIF), the eGovernment Interoperability Framework (eGIF), the Levels of Information Systems Interoperability (LISI), the EICTA interoperability white paper and the SIF implementation specification.

3.1.1.1 IDEAS Interoperability Framework (IDEAS)

The ATHENA project builds on the research challenges identified by the IDEAS thematic network2. The objective of IDEAS was to “elaborate a strategic roadmap in the domain of enterprise application and software interoperability” [CORDIS 2005]. The IDEAS network identified the need for a structured approach for collecting, identifying, and representing interoperability challenges. It defined a framework for capturing and inter-relating this information from many perspectives called the “IDEAS interoperability framework".3 The IDEAS Interoperability Framework defines four layers which are depicted in Figure 3-1.

Figure 3-1. IDEAS Interoperability Framework [Blanc 2005] 2 IDEAS: Interoperability Developments for Enterprise Application and Software – roadmaps, FP5 IST program, Jun 2002 – May 2003 3 The IDEAS framework was developed to enable the comparison of data within and between the different work packages of the IDEAS project.



The interoperability framework was also used to show a conceptual model of the interaction between two enterprises. In order to achieve meaningful interoperation between enterprises, interoperability must be achieved on all layers of an enterprise. This includes the business environment and business processes on the business layer; the organisational roles, skills and competencies of employees and knowledge assets on the knowledge layer; and applications, data and communication components on the ICT layer. In addition, enterprises that want to collaborate can use semantic descriptions to create the necessary mutual understanding. (cf. [ATHENA 2005a]) Institution / Organisation

IDEAS EU Project Date / Version

May 2003 / 1.0 Description

The IDEAS framework was developed to enable the comparison of data within and between the different work packages of the IDEAS project. The framework introduces two-dimensional views comprising interoperability aspects and quality attributes/extra-functional concerns.

Domain / Scope IDEAS community, EU, generic

Definition of interoperability Ability of interaction between enterprise software applications

Main elements / dimensions of interoperability Interoperability is considered achieved if interactions can, at least, take place at three levels: data, application and business process with the semantics defined in a business context.

Enterprise: business (decisional model, business model, business process) and knowledge (organisation roles, skills competencies, knowledge assets)

Architecture & platform: application (solution management, workplace interaction, application logic, process logic), data (product data, process data, knowledge data, commerce data) and communication

Semantic (business ontology, knowledge ontology, applications ontology, data ontology) URL/Source

http://www.ideas-roadmap.net4, [Ideas 2003]

3.1.1.2 European Interoperability Framework (EIF) The European Interoperability Framework describes the elements that have to be addressed by pan-European eGovernment Services. The ultimate goal is to introduce a pan-European dimension into the interoperability frameworks and national infrastructures across the EU member state administrations, the EU Institutions and Agencies. The EIF considers three aspects of interoperability: technical, semantic and organisation interoperability.

4 This official homepage of the IDEAS project was not reachable anymore at the time this document was written.



Institution / Organisation

European Community, IDABC Date / Version

2004 / 1.0 Description

The EIF defines a set of recommendations and guidelines for eGovernment services and the development of national interoperability frameworks so that public administrations, enterprises and citizens can interact across borders, in a pan-European context.

Definition of interoperability Interoperability means the ability of information and communication technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge.

Organisational interoperability: is concerned with defining business goals, modelling business processes and bringing about the collaboration of administrations that wish to exchange information and may have different internal structures and processes. Moreover, organisational interoperability aims at addressing the requirements of the user community by making services available, easily identifiable, accessible and user-oriented.

Domain / Scope European eGovernment projects

Main elements / dimensions of interoperability Besides the general definition of interoperability, the EIF distinguishes three aspects of interoperability: technical, semantic and organisational interoperability:

Technical interoperability covers the technical issues of linking computer systems and services (e.g. open interfaces, data integration, middleware, accessibility, and security services). EIF provides IDABC guidelines and standards; front office, back office and security recommendations; four sophistication levels of interaction types.

Semantic interoperability refers to the possibility for the exchanged information to be precisely understandable and processable by any application. EIF recommends the use of open standards and the development of XML vocabularies.

Organisational interoperability concerns the definition of business goals and the modelling of business processes to enable different organisations to work together (to deliver a service or product). This includes implications of interoperability from the pan-European and national perspectives; support of pan-European eGovernment projects (in context with IDABC programme); recommendations for national interoperability frameworks. URL/Source

http://europa.eu.int/idabc, [IDABC 2004]

3.1.1.3 e-Government Interoperability Framework (eGIF) Institution / Organisation

UK Government Cabinet Office e-Government Unit Date / Version

March 2005 / 6.1 Description

The e-GIF sets out the government’s technical policies and specifications for achieving interoperability and ICT systems coherence across the public sector.

Definition of interoperability A system is interoperable if it is able to exchange information and services in a coherent way with other systems.

Domain / Scope Interactions with and between UK government systems

Main elements / dimensions of interoperability eGIF architecture consists of the framework (high-level policy statements, technical policies and management, implementation and compliance regimes) the e-GIF registry (technical/semantic specifications: e-GMS, GCL, GDSC, XML schemas, TSC) URL/Source

www.govtalk.gov.uk, [U. K. Government Cabinet Office 2005]

3.1.1.4 Levels of Information Systems Interoperability (LISI)

The DoD identified a need to define certain levels of interoperability in order to distinguish different requirements for system interaction, to enable assessment of interoperability and to serve as guideline for system improvement. Part of the LISI interoperability framework is a maturity model in which in-creasing levels of sophistication for system-to-system interaction are defined. The five maturity levels – isolated, connected, functional, domain and enterprise – identify capabilities of a system on its way to improve its ability to interact with other systems. The levels are measured by using the Interoperability Maturity Model. In addition, the model can be used “as a guide to develop and improve a system’s



general capability to interoperate with other systems without predefined or formal sets of requirements necessarily established between them.” [DoD 1998, 2-1]. By means of a set of increasingly sophisticated levels multiple, heterogeneous systems can be compared regarding interoperability.

A system with a high maturity level is not necessarily better than a system with a lower one, “even though each higher level does imply added capabilities and flexibility (beyond known or projected re-quirements) for interaction between systems.” [DoD 1998, 2-4]. The appropriate level of interoperability has to be judged based on the individual aspects of each situation of interaction and the supporting systems. If a “low” level of interoperability perfectly matches the situation, costly improvements to existing systems may be unwarranted.

The LISI model describes a level of interoperability as a composite of three different aspects (cf. [DoD 1998]): The Statement of Need describes the information exchange requirements of the involved systems (e.g. text message, multimedia data). The Set of Enabling Capabilities is described in terms of procedures, applications, infrastructure, and data (e.g. multimedia applications, common data models). Governing Implementation Criteria comprise the technical realisation of the capabilities and include standards and conventions (e.g. operating systems, gateways).

The increase in capabilities over the previous level of interoperability is expressed in terms of pro-cedures, applications, infrastructure, and data (called “PAID”). Each attribute possess its own identity and purpose, but on its own, none is sufficient to identify a meaningful definition of interoperability. To-gether, they define “a full set of conditions, characteristics, and criteria necessary for achieving inter-operable environments.” [DoD 1998, 2-7]. The PAID attributes allow for identifying the set of charac-teristics needed to interact at a certain level of interoperability. They enable the identification of improvements needed for higher interoperability levels. Procedures: Documented guidance and operational controls; implementation options selected and overarching standards and architecture guidance; include standards, management, security policy, operations. Applications: Purpose and function for which a system is built; functional requirements to perform an operational activity. Infrastructure: Establishment and use of a connection between systems or applications; include communication and networks, system services, hardware, security equipment. Data: Information processed by the system; data formats (syntax) and content (semantics). Institution / Organisation

Department of Defense (DoD), United States of America Date / Version

30.03.1998 / Version 3 Description

LISI provides the basis for defining, evaluating, assessing, measuring and improving information systems interoperability across DoD in a uniform and incremental manner.

Definition of interoperability The ability of systems, units, or forces to provide services to and accept services from other systems, units, or forces, and to use the services so exchanged to enable them to operate effectively together. “The condition achieved among communications-electronic systems or items of communications-electronic equipment when information and services can be exchanged directly and satisfactorily between them and/or their users. The degree of interoperability should be defined when referring to specific cases.” [Kasunic/Anderson 2004, 2]

Domain / Scope DoD community; complete information system life cycle

Main elements / dimensions of interoperability LISI "Maturity model" with 5 increasing levels of system interoperability maturity: 0 - isolated, 1 - connected, 2 - functional, 3 - domain, 4 - enterprise LISI "Capabilities Model" identifies for each level a common suite of capabilities across procedures, applications, infrastructure, and data ("attributes of interoperability") LISI "Implementation Options Tables" identify for each capability specific technical implementations or products LISI "Interoperability Assessment Process" provides mechanisms and common metrics to assess current interoperability postures and to develop strategies for achieving higher states of interoperability maturity LISI "Reference Model", "Interoperability profile", LISI "Metric", LISI "Products" URL/Source

www.devenselink.mil, [DoD 1998]



3.1.1.5 EICTA Interoperability White Paper Institution / Organisation

European Information & Communication Technology Industry Association (EICTA)[Eicta 2004] Date / Version

21.06.2004 / Version 1 Description

The EICTA interoperability white paper introduces the main aspects of interoperability relevant for the European high technology sector, how interoperability can be achieved and what actions and policy principles should be observed in this context.

Definition of interoperability The ability of two or more networks, systems, devices, applications or components to exchange information between them and to use the information so exchanged. Interoperability is purposely defined as a technical capability.

Domain / Scope High technology sector. European companies that offer services to consumers (e.g. Telecom, TV broadcast, IT) and European Governments

Main elements / dimensions of interoperability User: satisfaction, experience

Technical capability: levels of interoperability, promotes use of open standards and standard interfaces

Organisational: recommendations for Governments URL/Source

http://www.eicta.org, [Eicta 2004]

3.1.1.6 SIF Implementation Specification Institution / Organisation

School Interoperability Framework (SIF) Date / Version

11.10.2004 / Version 1.5r1 Description

SIF Implementation Specification is a technical blueprint for software used in schools and kindergartens that will enable diverse applications to interact and share data now and in the future. SIF defines the requirements of architecture, communication, software components, and interfaces between hardware and software products.

Definition of interoperability -

Domain / Scope United States, education software developers and primary and secondary school (K-12) / district personnel

Main elements / dimensions of interoperability Software implementation guidelines (requirements for architecture, communication, software components, and interfaces) Concepts: Zone Integration Server (ZIS) for managing the interface agents data model for messages, message processing (request and response model, publish and subscribe model, asynchronous model), security model (encryption, authentication, access control), SIF Architecture: functional requirements and definition of interfaces for ZIS and other SIF components (integration agents, infrastructure transport layer) URL/Source

http://www.sifinfo.org/, [Schools Interoperability Framework 2005]

3.1.1.7 ATHENA Interoperability Framework (AIF)

The ATHENA Interoperability Framework (AIF) [ATHENA 2007] provides a compound framework and associated reference architecture for capturing the research elements and solutions to interoperability issues. Building on the IDEAS Interoperability Framework (c.f. Section 3.1.1.1), the ATHENA Integrated Project adopts a holistic perspective on interoperability in order to achieve real, meaningful interoperation between enterprises. Figure 3-2 shows a simplistic view of the reference architecture that indicates the required and provided artefacts of two collaborating enterprises. Interoperations can take place at the various levels (enterprise/business, process, service and information/data). For each of these levels ATHENA prescribes a model-driven interoperability approach where models are used to formalise and exchange the provided and required artefacts that must be negotiated and agreed upon.



Collaborative enterprise modelling concerns the exchange and alignment of knowledge models for describing the processes, organisations, products and systems in the collaboration context. Modelling of cross-organisation business processes focuses on process views that define the interactions between two or more business entities. Flexible execution and composition of services is concerned with identifying, composing and executing various applications. Information interoperability is related to management, exchange and processing of different documents, messages and other information structures. To overcome the semantic barriers which emerge from different interpretations of syntactic descriptions, precise, computer processable meaning must be associated with the models expressed on the different levels.

Enterprise/Business

Processes

Services

Information/Data

Cross-OrganisationalBusiness Processes

Collaborative EnterpriseModelling

Flexible Execution and Composition of Services

InformationInteroperability

Mod

el-D

riven

Inte

rope

rabi

lity

Sem

antic

s &

Ont

olog

ies

Enterprise/Business

Processes

Services

Information/Data

Provided Required

Figure 3-2: ATHENA Interoperability Framework [ATHENA 2007]

Institution / Organisation

ATHENA - EU Integrated Project Date / Version

March 2005 / V 1.0 Description

The ATHENA Interoperability Framework provides a compound framework and associated reference architecture for capturing the research elements and solutions to interoperability issues

Domain / Scope ATHENA community, EU, generic

Definition of interoperability Interoperability is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” (IEEE definition)

Dimensions / Layers of interoperability Required and provided artefacts of two collaborating enterprises: Collaborative enterprise modelling Cross-organisational business processes Flexible execution and composition of services Information interoperability Model-driven interoperability approach Semantics & Ontologies URL

http://www.athena-ip.org

3.1.1.8 Enterprise Interoperability Maturity Model (EIMM)

The Enterprise Interoperability Maturity Model has been developed within the ATHENA project [ATHENA 2005b]. It aims at assessing the maturity level of a company concerning the use of enter-prise models as well as the capability of these models to enable the company to participate in colla-boration. The EIMM comprises indicators which describe an organization’s relative ability to use approaches for representing enterprise knowledge within the organization to improve organizational



and personal performance.

The EIMM is structured according to the Capability Maturity Model (CMM, cf. 3.2.2) and distin-guishes six areas of concern. Whereas these areas have been traditionally covered by using languages for enterprise modelling, i.e. structure the knowledge representation around graphical (typically two-dimen-sional) diagrams, enterprise modelling practices need to be extended to approach interoperability and to facilitate collaboration: Business strategy and processes: For the purpose of interoperability, practices need to comprise modelling collaborative processes. Organisation and competences: For the purpose of interoperability, practices should include the identification of external entities to collaborate with, the specification of the topology of a networked organization, and its deployment and improvement. Products and services: For the purpose of interoperability, practices need to cover the identification of new opportunities and specification of the same aspects for new products and services that make use of networked technologies for its delivery. Systems and technology: For the purpose of interoperability, practices need to comprise the evolution of enterprise systems to apply innovative technologies that foster interoperability. Legal, security and trust requirements: Practices should consider legeal, security and trust requirements due to the collaboration with external entities, and the provision of solutions to manage these aspects which are a key for interoperability. Enterprise modelling: Besides the specification, construction, application and improvement of the enterprise models, this aspect has to deal with the interoperability of enterprise models. EIMM maturity levels rank from level 1 (enterprise modelling is performed, but in an ad-hoc and chaotic manner) to 5 (optimising, i.e. Enterprise models allow the organisation to react and adapt to changes in the business environment in an agile, flexible and responsive manner). It is important to note that the maturity levels characterise the use of enterprise modelling in the organisation which is seen as an enabler to achieve interoperability. Institution / Organisation

ATHENA - EU Integrated Project Date / Version

February 2005 / Version 1.0 Description

The Enterprise Interoperability Maturity Model represents a maturity model for enterprise interoperability with a particular focus on the use of enterprise modelling tools: (1) It identifies the main Areas of Concern on which an enterprise needs to work and improve in order to seamlessly interoperate with others. (2) Five maturity levels describe the improvement path for each Area of Concern.

Definition of interoperability c.f. ATHENA

Domain / Scope Generic

Main elements / dimensions of interoperability EIMM “Areas of Concern”: Business strategy and processes Organisation and competences Products and services Systems and technology Legal environment, security and trust Enterprise modelling EIMM “Maturity Levels”: Performed Modelled Integrated Interoperable Optimising URL/Source

http://www.athena-ip.org



3.1.2 Enterprise Modelling

An enterprise model represents the fundamental structure of an enterprise. It comprises the main sets of concepts to model and build an enterprise. In ATHENA sub-project A1 “Enterprise Modelling in the context of Collaborative Enterprises” selected frameworks for integrating enterprise modelling have been analysed, with emphasis on their potential contribution towards future layered operational enterprise architectures. In the context of our analysis, enterprise models may comprise some concepts which are relevant to business interoperability.

3.1.2.1 Enterprise Modelling in the Context of Collaborative Enterprises

[ATHENA 2005c] identifies heterogeneity, need for flexibility and complexity as three core challenges of achieving interoperability among collaborative enterprises. These challenges must be managed at different levels: Knowledge - approaches, methods and skills needed for innovation, problem solving and work performance, shared language and frames of reference needed for communication, etc.; Process - planning, coordination and management of cooperative and interdependent activities and resources; and Infrastructure - information formats, software tools, and interoperability approaches of the participating companies.

The resulting problem space is summarised in Table 3-1. The unique nature of each collaborative enterprise, and the dynamic set of partners, seldom makes it economically viable to integrate information systems through developing new software interfaces. Instead, we need an open, model-supported and model-driven infrastructure for collaborative concurrent modelling and execution, supporting shared understanding, work management and learning, and allowing interoperability to emerge from work, rather than being a prerequisite for cooperation. Enterprise models, articulating who performs which tasks when and why, are powerful resources to understand and master complexity. (cf. [ATHENA 2005c])

Knowledge Process Infrastructure Heterogeneity Communication: establishing

common languages and meanings across companies and disciplines

Process diversity: negotiating different rules and procedures between the partners

Interoperability across companies' knowledge spaces and enterprise architectures (Business, Knowledge Software)

Complexity Integrate capabilities: form effective teams across different local cultures; align views with contents and context among and between stakeholders and people

Work management and planning, task assignment, coordination and monitoring of activities and tasks across projects, partners and networks, dealing with uncertain interdependencies among several concurrent activities

Enterprise architectures: managing project and systems portfolios; providing new model driven approaches for solutions design and development; avoiding featuritis (unmanageably complex systems)

Flexibility Learning: partners must be able to improve practice based on common experience from the Collaborative Enterprise

Supporting both structured and ad hoc work (with evolving plans); Handling unforeseen exceptions

Customised and personalised support; Rapid formation of Collaborative Enterprises, allowing partners to join along the way

Table 3-1. Problem Space for Collaborative Enterprise Integration (cf. [ATHENA 2005c, 7])



3.1.2.2 Zachman Framework for Enterprise Architecture Institution / Organisation

John A. Zachman Date / Version

1992 Description

The Framework as it applies to enterprises is simply a logical structure for classifying and organising the descriptive representations of an enterprise that are significant to the management of the enterprise as well as to the development of the enterprise’s systems.

Dimensions / Layers The Framework graphic depicts the design artefacts that constitute the intersection between the roles in the design process (i.e. OWNER, DESIGNER and BUILDER) and the product abstractions (i.e. WHAT (material) it is made of, HOW (process) it works and WHERE (geometry) the components are, relative to one another). Contribution to interoperability

Zachman’s architecture provides a set of concepts and principles to model, design and implement enterprise systems in a holistic way. It supports the integrated interoperability paradigm.

Recommendations for contribution to ATHENA The Zachman Framework has with some success been used by the Canadian Government to design their EA approach, and has been successfully used as a visual reference categorisation structure for enterprise knowledge repositories.

URL http://www.zifa.com

3.1.2.3 Generalised Enterprise Reference Architecture and Methodology (GERAM) Institution / Organisation

IFIP - IFAC Task Force on architecture for enterprise integration, ISO WD15704 Requirements for enterprise-reference architectures and methodologies

Date / Version 1996 / Version 1.6.2

Description GERAM encompasses all knowledge needed for enterprise engineering and integration. Thus it is defined through a pragmatic approach providing a generalised framework for describing the components needed in all types of enterprise engineering/enterprise integration processes.

Dimensions / Layers Components: GERA (generalised enterprise reference architecture) defines the generic concepts recommended for use in enterprise engineering and integration projects EEM (enterprise engineering methodology) describe the processes of enterprise integration EML (enterprise modelling languages) define the generic modelling constructs GEMC (generic enterprise modelling concepts) are the most generically used concepts and definitions of enterprise integration and modelling PEM (partial enterprise models) are models which capture concepts common to many enterprises EET (enterprise engineering tools) support the process of enterprise engineering and integration EMO (enterprise modules) are implemented building blocks or systems EM (enterprise models) include all descriptions, designs, and formal models of the enterprise EOS (enterprise operational systems) support the operation of an enterprise Contribution to interoperability

The GERA architecture can be used to support enterprise modelling of collaborative enterprises. The GERAM framework can be used to categorise ATHENA expected research results and better structure ATHENA solution components.

Recommendations for contribution to ATHENA The GERAM framework gives a good overview of the different EM modelling aspects and domains, but lacks some very important aspects such as meta-modelling capabilities, knowledge spaces and modelling platforms with repositories.

URL http://www.cit.gu.edu.au



3.1.2.4 GRAI Framework Institution / Organisation

LAP/GRAI University of Bordeaux and GRAISOFT Date / Version

Description

GRAI Integrated Modelling (GIM) proposes a modelling framework in which all the models needed for analysis, design and implementation of an enterprise are considered.

Dimensions / Layers Abstraction levels: conceptual level (What?), structural level (Who? When? Why?), realisation level (technical constraints)

Domain decomposition: systems (physical, decisional, informational), views (functional, process, resource) Contribution to interoperability

GIM modelling framework introduces the decision dimension/view which is not taken into account in other modelling frameworks. The decisional aspect is important to establish interoperability in the context of collaborative enterprises. To interoperate in such an environment, decision-making structure, procedure, rules and constraints need to be clearly defined and modelled so that decentralised and distributed decision-making can be performed.

Recommendations for contribution to ATHENA The GRAI Framework has strong support for performance indicator management and decision making, but has limited scope and expressiveness and lacks platform integration.

URL

3.1.2.5 Architecture of Integrated Information Systems (ARIS) Institution / Organisation

Institute of Information System, University of Saarbrücken (Prof. Scheer), German Research Centre for Artificial Intelligence (DFKI), IDS Scheer AG

Date / Version 1999

Description The Enterprise Modelling approach of ARIS is based on a view concept. The objective is to reduce the complexity by dividing the enterprise into individual views.

Dimensions / Layers Organisational view (organisational charts, network diagram, shift calendars)

Function view (function trees, objective diagram, application system diagram)

Data view (ERM, attribute allocation diagram, class diagram)

Output view (product tree)

Control view (event driven process chain, function allocation diagram, value-added chain diagram) Contribution to interoperability

The different views of the ARIS-concept include variable modelling languages, e.g. EPC for illustrating the collaborative business processes. But there are extensions needed concerning the requirements of modelling collaborative enterprises like new role-concepts or the problem of depicting internal and external views of the same business process.

From an interoperability point of view the ARIS Toolset can support the exchange of process knowledge. It is also possible to control collaborative business processes and to deduce necessary improvement activities. At the moment there is a close cooperation with SAP concerning interoperability of modelling methodologies and software systems.

Recommendations for contribution to ATHENA ARIS has strong top-down process modelling and integration capabilities, but lacks expressiveness, view management and language constructs for other aspects, and does not support the “big picture” created by more holistic approaches.

URL http://www.ids-scheer.com



3.1.2.6 CIMOSA Framework Institution / Organisation

CIMOSA Association e.V. Aachen, Germany Date / Version

2000 / Version 3.3 Description

CIMOSA is a framework for structuring enterprise modelling related issues. It addresses concepts and models that are necessary to model integrated enterprise systems focusing on process model-based enterprise activity control.

Dimensions / Layers Dimension of genericity (generic level, partial level, particular level)

Dimension of model (requirements model, design model, implementation model)

Dimension of view (function view, information view, resource view, organisation view) Contribution to interoperability

There is no explicit consideration on interoperability issues in CIMOSA modelling framework. However, CIMOSA can be a contribution for integrated paradigm to establish interoperability.

Recommendations for contribution to ATHENA The CIMOSA Framework is a good reference framework, but lacks expressiveness for multiple dependencies of types of view, for evolving concepts, contents and capabilities and for capturing context. Knowledge sharing and representation is poorly supported.

URL http://www.cimosa.de

3.1.2.7 Active Knowledge Modelling (AKM) Technology Institution / Organisation

Troux Technologies AS, Norway Date / Version

2002 Description The AKM technology and corresponding methodology is based on the concepts of Enterprise Knowledge Spaces. It captures knowledge spaces that are comparable to the four knowledge dimensions that both coordinate human action and human thinking, and can be found in all enterprise working environments created by humans. Dimensions / Layers AMIS principle for innovative work: approach, methodology, infrastructure and solutions Contribution to interoperability

The AKM technology implements the layered Enterprise Architecture, is prepared for the POPS and POP* methodology, for the Enterprise Knowledge Architecture and the Intelligent Infrastructure services. Many of the right design principles and implementation architectures are defined as principles and methods inherent in the AKM technology.

Recommendations for contribution to ATHENA The AKM technology and Knowledge Space methodology has its strength in the concepts of Enterprise Knowledge Spaces, knowledge architectures for reuse, and the expression and representation of work-generative knowledge. It is lacking an integrated platform and support for the knowledge architecture.

URL http://www.computas.com

3.1.3 Networked Organisations

3.1.3.1 Business Networking

Business Networking extends the three-level business engineering model5 to cover inter-organisational relationships (cf. [Fleisch/Österle 2000a], Figure 3-3). The Business Networking Architecture structures main elements of inter-organisational design on the levels of business strategy, business process and information system. Business Networking also provides methods for transforming business networks.

5 Business Engineering aims at combining insights gained from both science and practice to derive concepts and tools for the planning and realisation of business solutions in the information age. It integrates knowledge from business and information technology with means of representation, process models as well as cultural and political aspects.



The strategy level includes business units and cooperation relationships between business units.6 A business unit has a business strategy, a series of business processes to implement that strategy, resources, such as personnel, information, capital, and relationships with internal and external business units. Cooperation between business units is based on formal and informal cooperation relationships. Outline agreements, mutual participating interests and supply chain interdependencies are examples of formal or ‘hard’ cooperation relationships. Equally important for cooperations to function correctly are informal or ‘soft’ cooperation relationships. Trust between partner companies and commonly maintained standards and values are examples of this kind of relationship (cf. [Klein 1996b, 100], [Jarillo 1993, 135ff]). At the operative level they generate a coordinating effect. Business units and cooperation relationships together form a business network [Klein 1996b, 87ff].

The process level covers the process networks. A process network is an association of processes between business units. It implements a cooperation strategy at the operative level and provides outputs for customer processes. Coordination relationships between the processes ensure that the provision of outputs is coordinated. The granularity of a business unit would appear to be too coarse for deriving concrete procedural instructions for the design and implementation of networks. Business units are usually active in several networks. They simultaneously participate in development and purchasing communities, enter strategic marketing partnerships and are involved in different value chains with different products and services. This differentiated view of networking required for implementation can be more clearly visualised using the reference object business process than with the reference object business unit.

The information system level covers information system networks. These support process networks. Their nodes correspond to integrated information systems which can consist of people and machines. Their edges describe links for the purpose of system integration such as e.g. voice communication by telephone or the exchange of EDI messages.

Business Network Strategy level

Process network Process level

Coordination

Information system(IS)-network

IS levelCommunication

Business unit

Business process

Application

Data

Cooperation

Figure 3-3. The Three Levels of Business Engineering Applied to Business Networking

The objective of every networked enterprise is to increase competitiveness through higher networkability. The concept of networkability builds on the organisational ability to cooperate (cf. [Österle et al. 2001a]). Corresponding to the dimensions of business engineering, networkability has different aspects or design objects which create dependencies among business partners. Networkability expresses the attribute needed for management of theses relationships of dependence. Networkable business models can be adapted quickly and inexpensively to new market requirements. Networkable products and services can be altered quickly and inexpensively for specific partners or be integrated in other products. Networkable employees are oriented to the customer and understand the relevance of win-win-situations. The company culture promote cooperation by being open to change and by basing cooperation on a relationship of trust.

6 Business units are economic units such as e.g. corporations, divisions, national subsidiaries, profit centers or small and medium-sized enterprises, which are responsible for profits and operate within the market economy.



Networkable processes can quickly and inexpensively establish and conduct a relationship of coordination with corresponding processes. Networkable information systems can be linked up to other IS quickly and inexpensively and support communication on the system level.

Activities for designing a company’s networkability have three basic effects: 1) Reduction of time and costs when new business relationships are established or when

transactions are conducted; 2) reduction of the specifity of investments and increased flexibility of existing investments: and 3) improved opportunities for detecting and occupying new market segments at an early stage.

To receive these benefits, organisations need to increase their networkability. With regards to the design objects they have several opportunities. For example, the important coordination mechanism for designing people’s roles and company culture are openness, the identification and control of goal-conflicts, and trust-creating measures. The coordination mechanisms for networkable processes include process standards and the form of process integration. Standardised processes (e.g. CPFR) reduce the effort involved in coordination and, in the ideal case, lead to integration on a pragmatic level or electronic workflows between anonymous partners.

Design Object Networkability of Design Object Coordination Mechanism Objectives of Networkability Business Model Flexible business models

which enable participation in several different networks

Virtualisation

Modularisation

Distributed responsibilities

Internal networks

Stable networks

Dynamic networks Products and Service

Rapid and inexpensive individualisation of products or services

Modularisation

Standardisation

Digitalisation

Mass customisation

Postponement

Culture and Employees

Cooperation-promoting company culture and employees with the capacity for internal and external cooperation

Relative openness

Identification and control of goalconflicts

Trust-creating measures

Autonomy

Communicative competence

Information acquisition

Establishing and maintaining personal networks

Process Rapid and flexible establishment and use of appropriately coordinated processes

Process standardisation

Process integration

Pragmatic integration

Real-time coordination

Appropriate flexibility

Information System

Rapid and inexpensive establishment of an individual communications link between information systems

Communication standards and data standards system integration

Semantic integration

Making information externally available

High data quality

Real-time data processing

Table 3-2. Approaches for Designing Networkability (adapted from [Österle et al. 2001a, 83f.])



The design areas are closely interlinked. For instance, provision of a service or product for the customer depends on numerous processes. Processes, in turn, depend on the abilities of the people and IS involved. In addition, the modular design of products and services only leads to an increase in competitiveness, if processes and IS support this modularisation. The formulation of concrete action alternatives for increasing networkability therefore is challenged by the simultaneous coordination of several objects. Institution / Organisation

Institute for Information Management (Österle/Fleisch/Alt), University of St. Gallen Date / Version

2000 Description

Business Networking uses the three-level business engineering model for structuring and visualising networking problems and solutions, and shows the basic dependencies between business strategy, business process and information system.

Domain / Scope Generic

Dimensions / Layers of Interoperability Business engineering levels:

Strategy level – Business Network (business units and cooperation relationships between business units)

Process level – Process Network (association of business processes between business units)

Information system level – IS Network (system networks consisting of integrated information systems) Definition of Interoperability

Interoperability is closely related to the concept of networkability, which is defined as the capability of an organisation to establish, maintain and develop relationships with other organisations in order to pursue new common business opportunities or improve the results of an existing business through co-operation.

URL http://www.iwi.unisg.ch, [Fleisch/Österle 2000a]

3.1.3.2 Networked Organisations

A number of theories explain the emergence and success factors of new types of networked orga-nisations and value models. Important scientific contributions have come from transaction cost theory [Williamson 1989b, Clemons et al. 1993], organisational theory [Snow et al. 1992, Sydow 1992], new institutional economics [Williamson 1991, Malkin 1995]. Table 3-3 summarises a number of suggested organisation strategies.

Approach Options Reference Transaction Cost economics / organisation theory

Hierarchy, market, hybrid

electronic markets, electronic hierarchies

in-house manufacture, market supplier,

partnership

[Williamson 1985]

[Malone 1987]

[Clemons/Reddi 1993]

Telecooperation

Hierarchical organisation, networked organisation, modular organisation, virtual organisation

[Reichwald et al. 1998]

Strategic networks

Internal networks, stable networks, dynamic networks

Quasi-externalisation, quasi-internalisation

[Snow et al. 1992]

[Sydow 1992] Virtual organisations

Intraorganisational, interorganisational

[Davidow/Malone 1992], [Bleicher 1996], [Scholz 1997]

Resource-based approaches Pooling, allying, linking [Moss-Kanter 1989]

Table 3-3. Existing Approaches to Organisation Strategies



Transaction cost theory identifies three effects of information technology on the boundaries of a firm [Malone et al. 1987]: Electronic communication effects, electronic brokerage effects and electronic integration effects. In the case of low asset specifity, this leads to a shift towards market based coordination and increases the power of the buying side (“Move-to-the-Market”). In other cases, coordination with a smaller number of suppliers has resulted in significant efficiency gains, for example by reducing the inventory across the entire supply chain (“Move-to-the-Middle”) [Clemons et al. 1993]. Consequently, enterprises invest in creating strategic supplier networks. During the last decade, an increasing number of companies has been re-evaluating their core competencies with the effect of realising a higher degree of outsourcing.

Organisational theory [Snow et al. 1992, Sydow 1992] investigates inter-firm relationships and the emergence of networked organisations. It deduces different types of networked organisation based on structural properties, such as duration of relationships, number of partners, the level of interaction or the inter-organisational division of labor.

According to [Alt et al. 2001] four alternatives of organisation strategy exist, depending on whether the future business segment is new or old and on whether the cooperation is about existing core competencies or not: Develop new resources with existing core competencies in a new business segment ( virtual organising, insourcing) Externalise resources if it is a non-core competence in an old business segment ( outsourcing) Pool resources with partners if a new business segment is to be entered without having all required core competencies to be competitive in this field ( virtual organising) Strengthen resources with an existing core competence in an old business segment ( insourcing).

For more information on networked organisations and value models including a state of the art analysis, please refer to ATHENA document WD.B3.3 “Assessment of Networked Organisations and Value Models”.

3.1.3.3 Inter-organisational Systems

Inter-organisational Systems (IOS) denote network-based information systems that transcend organizational boundaries [Johnston/Vitale 1988, Hong 2002]. Electronic data interchange (EDI) has been employed as the major tool for electronic coordination with external business partners in the past, but since the mid-1990s is being complemented with web technologies such as portals, XML or Web Services.

Inter-organisational information systems can be classified according to their interaction type. Human-human-interaction describes traditional forms of interaction between humans which may be supported by electronic means, e.g. groupware or e-mail. In the case of human-machine-interaction, external users are getting direct access to internal data and applications. This is typically realized by internet front ends or portals which bundle data and applications on the basis of users and roles. Machine-machine-interaction finally describes the direct communication between two information systems without human intervention. It leads to consistently automated processes and requires a linkage of applications across company borders.

With higher levels of electronic integration, the need for inter-organizational agreements increases [Reimers 2001, McAfee 2005b]: In order to allow IS-mediated interaction, different levels of agreement have to be in place (c.f.Figure 3-4): At the lowest level, information systems have to share agreements about how data is to be transported over a network. Once agreements at this basic transport level, e.g. through standard internet protocols such as HTTP, are in place, human-human and human-machine interactions can take place. Since information systems are not as flexible as humans in interpreting documents, further ex ante agreements have be made for human-machine or machine-machine-interactions. This includes data definitions and document syntax defining the contents and structure of messages, as well as process-level information.

The implementation and use of an IOS implies considerable organisational change. Similar to the company-internal situation, the use of information technology in inter-organisational relationships is most beneficial if accompanied by process innovations, such as Collaborative Planning, Forecasting and Replenishment (CPFR). Otherwise the impact of IOS is limited to automation effects, mainly the reduction of data-entry errors and costs.



Adoption of IOS has been slower than often postulated [Löwer 2005]. This can be explained by the high upfront investments which are associated with direct and indirect network effects. The value of IOS implementation for an organisation increases with every additional business partner they can reach with the system. XML and Web Services are expected to lower the cost of IOS implementation by leveraging the Internet infrastructure and open Internet standards.

Level 1: Transport

Link / network used to transmit messages between machines

Level 2: Payload Contents and structure of messages sent between machines

Level 3: Process Parameters of business process(es) making use of inter-machine messages

Human-Human Example: Sending an e-mail or an instant message

Necessary and sufficient for human-human interaction Network, e.g. TCP/IP; com-munication protocol, e.g. SMTP

N/A N/A

Human-Machine Example: Using self-services on a supplier portal

Necessary and sufficient for human-machine interaction Network choice, e.g. TCP/IP; Graphical user interface, e.g. web browser; encoding; authorization; authentication

N/A N/A

Machine-Machine Example: Linking applications based on XML-fomatted message exchange

Necessary for all computer-mediated interactions Network choice, e.g. TCP/IP; encryption; encoding; transmission integrity mechanisms

Necessary for all single-step machine-machine interactions Data definitions ; document syntax, e.g. EDI standards; acceptable values

Necessary for all multi-step machine-machine inter-actions Sequence of activities, e.g. RosettaNet PIPs; possible branches; possible end-points; exception triggering

Figure 3-4: Interaction Type and Levels of Agreement in Inter-organisational Integration (Adapted from [McAfee 2005b, McAfee 2005a])

3.1.3.4 Coordination Theory

[Malone/Crowston 1994] consider coordination as managing dependencies between activities. They identify a number of dependencies and related coordination processes: (1) Managing shared re-sources, (2) managing producer / consumer relationships, (3) managing task / subtask dependencies, and (4) managing other dependencies. They see coordination processes as key to understand the effects of information technology on organisations and to designing cooperative work tools. Although [Malone/Crowston 1994] provide a number of examples and application areas for coordination proces-ses, they outline a research agenda and call for further developing this “interdisciplinary study of coordination”.

3.1.4 Standards

The target of B2B standards is to ensure compatibility and interoperability between business part-ners. In the past, standardisation mostly focused on technical communication standards. This also applies to WS-I Organisation (Web Services Interoperability Organisation, http://www.ws-i.org) which is chartered to promote interoperability across platforms, operating systems and programming languages by Web Service standards. These standards include Simple Object Access Protocol (SOAP), Univer-sal Description, Discovery and Integration (UDDI), and Web Services Description Language (WSDL). Various initiatives have been launched to extend XML-based standards to comprise standardisation on the semantic level. Initiators have been either industrial associations, such as RosettaNet Partner In-terface Protocols (PIPs) in the high-tech industry or ChemXML as part of CIDX in the chemical in-dustry, or independent providers, such as Dun & Bradstreet for company identifiers. In addition, UN / CEFACT and ISO play a major role in B2B standardisation. With more than 16 000 international stan-dards which have been published between 1947 and today, the International Organization for Standar-dization ISO is the world largest developer of standards. It actively promotes e-Business standardisa-tion and joins forces with other organisations, e.g. in order to develop and promote the Universal Busi-ness Language (UBL). The United Nations Center for Trade Facilitation and Electronic Business (UN /CEFACT) currently aims at standardising semantic building blocks for the basic business entities by developing the Core Component Library (CCL) and Core Component Technical Specification (CCTS).

B2B standards can be classified into:



Message standards (e.g. EDIFACT, cXML, Chem eStandards) which define the semantics of business documents; catalog standards (e.g. BMECat) which specify the content of product catalogues; identification standards (e.g. EANCOM, EPC Global) which define unique identifiers for products or other information objects; classification standards (e.g. UN/SPC, eCl@ss, SIC) which provide common categories to group information objects; process standards (e.g. RosettaNet PIPs, CPFR) which describe inter-organisational process coordination; and business standards (e.g. Bolero Rulebook) which define business rules and service level agreements between business partners.

Message Standards

Ord

er

Del

iver

y N

ote

Invo

ice

Prod

uct /

C

atal

og

Fore

cast

Inve

ntor

y Le

vel

openTrans OpenTrans cXML Commerce XML xCBL Commerce Business Library UBL Universal Business Language RosettaNet RosettaNet Technical und Business Dictionary CIDX CIDX Chem standards EANCOM EANCOM EDIFACT EDIFACT ANSI X.12 ANSI X.12 ebXML Electronic Business XML

Figure 3-5. Message standards

3.1.5 Communication Theory - Semiotics

Semiotics is an aspect of communication which refers to the study of signs and how meaning and understanding are made. Communication is defined as transmitting a message from a sender to a receiver using a channel. A message is made from a collection of signs. Semiotics includes three subjects or levels of communication: Syntax, semantics and pragmatics (cf. Figure 3-6). Syntax studies the structure of the message, i.e. the interrelation of the signs without regard to meaning. Semantics refers to the relation between signs and the objects to which they apply. Semantics enables the receiver of a message to understand it. Pragmatics adds an additional aspect to simple understanding. It constitutes the relation of signs and interpreters, so that the message has a meaning for the receiver. Hence, the receiver is able to react to the content of the message. Business interoperability relates to the semantics and pragmatics of a message. Technical interoperability is more related to syntactical and infrastructure aspects. The technical infrastructure refers to the channel on which the message is transmitted to the receiver, such as the Internet.



Signs are transmitted

Infrastructure and rules for transmitting signs

Technical

Signs can be readThe formal or structural relations between signs

Syntax

The message is understood

The relationship of signs to what they stand for (message)

Semantics

The message has a meaning (context)

reaction

The relation of signs to interpreters (information)

Pragmatics

Signs are transmitted

Infrastructure and rules for transmitting signs

Technical

Signs can be readThe formal or structural relations between signs

Syntax

The message is understood

The relationship of signs to what they stand for (message)

Semantics

The message has a meaning (context)

reaction

The relation of signs to interpreters (information)

Pragmatics

Sender Receiver

Communication

Figure 3-6. Semiotic Aspects of Communication

3.1.6 Contributions to the Business Interoperability Framework

3.1.6.1 Perspectives on Interoperability

Considerable work has been conducted on the technical and semantic aspects of interoperability by suggesting standards for presenting, collecting, exchanging, processing and transporting data. This is reflected by the following definitions:

European Interoperability Framework (EIF): “Interoperability means the ability of informa-tion and communication technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge.” [IDABC 2004]

EICTA interoperability white paper: “The ability of two or more networks, systems, devices, applications or components to exchange information between them and to use the information so exchanged.” [Eicta 2004]

IDEAS: “IDEAS project defines interoperability as the ability of interaction between enterprise software applications.” [Blanc 2005]

Since these definitions focus on the aspect of exchanging information between ICT systems, components or networks, the “actors” are mostly restricted to non-human, technical ICT devices, i.e. applications, systems or networks. The LISI definition includes additional, non-technical actors. It extends the aspect of simply exchanging information to the provisioning and accepting of services.

Levels of Information Systems Interoperability: “The ability of systems, units, or forces to provide services to and accept services from other systems, units, or forces, and to use the services so exchanged to enable them to operate effectively together.” [DoD 1998]

Regarding business interoperability, we have to extend the perspective from a pure ICT related view to include interoperability of organisations, business processes, and even human actors. In this extended context, services are not just exchanged, but have to be understood by the external business partners and be of use to them. Consequently, communication aspects (semiotics), in particular semantics and pragmatics, have to be considered. The need for a broader perspective on inter-operability has been recognised by some of the interoperability frameworks. As an example, EICTA mentions the factors “commercial availability, organisation/business model compatibility, semantic con-sistency and technical infrastructure/skill capabilities of potential users. There are multiple other factors that influence the actual ability of a user to gain access to a particular service. These other factors may very well merit attention and remedial action but they generally are outside the scope of this paper.” [Eicta 2004].,One of the rare frameworks which incorporates the non-ICT related perspective, is the Enterprise Interoperability Framework which distinguishes technical, semantic and organisational interoperability [IDABC 2004]:



Technical interoperability covers the technical issues of linking computer systems and services (e.g. open interfaces, data integration, middleware, accessibility and security services). Semantic interoperability refers to the possibility for the exchanged information to be precisely understandable and processable by any application. Organisational interoperability concerns the definition of business goals and the modelling of business processes to enable different organisations to work together (to deliver a service or product).

The IDEAS interoperability framework contains also a business level of interoperability. However, it only deals with the aspects of enterprise modelling and business semantics. Research within the ATHENA project has been contributed to filling this gap by providing more holistic approaches, namely the ATHENA Interoperability Framework and the Enterprise Interoperability Maturity Model. However, given the research areas of ATHENA the concepts and maturity models are more focused on enterprise modelling, architectures and platforms and ontologies.

Whereas interoperability is widely discussed in a technical context, interoperability is not (yet) used as a concept in organisation or network theory. However, interoperability issues translate into a number of concepts from these theories, such as the “fit” between organisations forming a cooperation or network, or the design of inter-organisational business processes and systems.

3.1.6.2 Dimensions of Business Interoperability

In order to deduce the fundamental constituents of business interoperability, the following section analyses the contributions that interoperability frameworks, enterprise modelling, research on networked organisations, and standards provide to the Business Interoperability Framework.

We can associate interoperability with the following aspects: Networked organisations / inter-organisational cooperation type and models Network management / cooperation management Cross-organisational business processes Inter-organisational information systems Architecture / platform / infrastructure Data semantics User interface Security Software Governance aspects of interoperability

The contribution of this research can be classified into the following categories: Recommendations, i.e. general guidelines and design principles that assist in achieving interoperability Policies, i.e. mandatory instructions that must be adhered to Conceptual model, i.e. models and frameworks which explain the fundamentals of interoperability Standards, i.e. universally agreed upon sets of guidelines for interoperability Method, i.e. a particular procedure or procedural model which outlines steps and techniques for achieving interoperability Theory, i.e. self-consistent model or framework which describes the principles which underlay interoperability and capable of being tested through experiment or otherwise falsified through empirical observation

An additional dimension for classifying our research is the domain under consideration. Some of the approaches are limited to either a geographical region or a specific industrial sector. They are classified according to the following characteristics: Industry-specific, i.e. only applicable in one industry, vs. generic, i.e. applicable to all industrial sectors Country-specific, i.e. only applicable in one country, vs. regional, i.e. applicable to a broad region (e.g. Europe) vs. global, i.e. globally applicable.

Figure 3-7 summarises the contribution of the state-of-the-art approaches to business inter-operability. It is obvious, that existing interoperability frameworks support mainly the ICT aspects. Few frameworks actually consider business-related interoperability aspects, collaborative business processes or inter-organisational management issues.



For the Business Interoperability Framework, concepts of networked organisations, inter-organisational systems and coordination theory provide valuable input. They suggest models, methods and theories related to cross-organisational business processes, inter-organisational coordination and new organisational configurations. Business interoperability itself is not (yet) considered in those concepts, but they can serve as input for identifying a comprehensive overview on business interoperability issues. However, they usually do not link the design of inter-organisational relationships to the design of information systems and lack supporting management techniques.

Enterprise modelling approaches traditionally refer to the single enterprise as their unit of analysis, but are being extended to include modelling related to value chains and external business relationships.

B2B standards mostly focus on message exchange and thereby are restricted to data syntax and semantics. Only few examples for standardisation of business processes exist so far.

We conclude that a systematic analysis on business issues associated with interoperability of organisations is currently lacking. By combining the different approaches to interoperability, we deduce a number of fundamental artefacts describing technical and business interoperability. These artefacts are illustrated in Figure 3-7 and will form the basis of the Business Interoperability Framework.



Arc

hite

ctur

e

Dat

a sy

ntax

/ Se

man

tics

Use

r int

erfa

ce

Secu

rity

Softw

are

func

tions

Interoperability Development for Enterprise Application and Software (IDEAS)

Generic Europe M M M

European Interoperability Framework (EIF)

Public Sector / eGovernment

Europe R R R R R R R

e-Government Interoperability Framework (eGIF)

Public Sector / eGovernment

United Kingdom RP SRP R RP P

Levels of Information Systems Interoperability framework (LISI)

Defense United States MR MR MR R R R H

European Information & Communication Technology Industry Association (EICTA)

Information and Communication

Technology

Europe R R R R

ATHENA Interoperability Framework (AIF)

Generic Global M M M M M

Enterprise Interoperability Maturity Model (EIMM)

Generic Global MR MR M MR MR MR MR

Zachman Framework Generic Global (M) M M M M M

Generalised Enterprise Reference Architecture and Methodology (GERAM)

Generic Global M M M M M

GRAI Framework Generic Global (MH) M MH MH MH

Architecture of Integrated Information Systems (ARIS)

Generic Global (MH) M MH MH MH MH

CIMOSA Generic Global M M M M

Active Knowledge Modelling Technology (AKM)

Generic Global M M M M

POP* Generic Global

Catalog standards (e.g. BMECat, …)

Generic or industry specific

Global / Regional / Country

S

Identification standards (e.g. EANCOM, EPC Global, …)



S

Classification standards (e.g. UN/SPSC, ecl@ss, SIC, …)



S

Message standards (e.g. EDIFACT, cXML, Chem eStandards, …)



S

Process standards (e.g. CPFR, RosettaNet, ...)

Generic or industry specifc

Global S (S)

Networked Organizations Generic Global MT MT MT MT

Business Networking Generic Global MH M M MH MH MH MH

Interorganizational Systems Generic Global MT MT MT MT

Transaction Costs Generic Global MT MT

Coordination Theory Generic Global M

Org

anis

atio

n

Gov

erna

nce

Domain Contribution to Business InteroperabilityInformation Systems

Reg

iona

l sco

pe

Coo

pera

tion

type

/ m

odel

sC

oope

ratio

n m

anag

emen

t

Bus

ines

s pr

oces

ses

Com

pete

nces

Inte

rope

rabi

lity

Fram

ewor

ksB

2B S

tand

ardi

zatio

nN

etw

orke

d O

rgan

izat

ions

Indu

stry

sco

pe

Ente

rpris

e M

odel

ling

Contribution:H - Methodology M - Conceptual ModelP - Policies R - RecommendationsS - Standards T - Theory

Figure 3-7. Analysis of State of the Art Approaches



3.2 Excellence Models

The following section presents three excellence and maturity models: The EFQM Excellence Model, the Capability Maturity Model (CMM) and the Collaboration Maturity Grid for New Product Introduction (NPI). These models provide valuable input for structuring the business interoperability framework and assessing different levels of business interoperability.

3.2.1 EFQM Excellence Model

The EFQM Excellence Model was introduced in 1991 by the European Foundation for Quality Management (EFQM). Applicants for the European Excellence Award (EEA) are assessed against this framework. EFQM, based in Brussels, Belgium, is a not-for-profit organisation with over 800 member organisations of all sizes from both the private and public sector. It was founded by the CEOs of fourteen prominent European businesses, such as Bosch, Nestlé, Philips and Volkswagen, in 1988. Its aim was to promote world-class approaches to the management of European organisations that would lead to sustainable excellence. Since 1992 EFQM assigns the EEA yearly to organisations in Europe that demonstrate sustainable excellence in all aspects of the EFQM Model. (cf. [EFQM 2006])

The EFQM Excellence Model is not only a framework for assessing organisations but also for their improvement. They might achieve a sustainable advantage “in a world of increasing global competition, rapid technological innovation, changing processes and frequent movement in the economic, social and customer environments” [EFQM 2003c, 3]. The EFQM Excellence Model is based upon nine fundamental concepts of excellence: Results orientation, customer focus, leadership and constancy of purpose, management by processes and facts, people development and involvement, continuous learning, improvement and innovation, partnership development, and corporate social responsibility. “Excellent results with respect to Performance, Customers, People and Society are achieved through Leadership driving Policy and Strategy, that is delivered through People, Partnerships and Resources, and Processes.” [EFQM 2006].

Organisations may use the Excellence Model as a tool for self-assessment. They determine their current state, deduce areas for improvement, and measure progress periodically. It also facilitates the comparison with other organisations (cf. [EFQM 2003d]). The non-prescriptive framework consists of nine criteria which are the application of the fundamental concepts of excellence (cf. Figure 3-8). The criteria are divided into five “enablers” (what an organisation does) and four “results” (what an organisation achieves). Enablers and results influence each other in a way that results are caused by enablers and enablers are improved using feedback from results. Innovation and learning help to improve enablers that in turn lead to improved results.

Figure 3-8. The EFQM Excellence Model [EFQM 2003d, p.5]

Every high level criterion is divided into a number of sub-criteria (criterion parts) for which a maturity level of excellence is actually defined. In the following matrix the sub-criteria of enablers relevant for business interoperability and partnerships are named. “Guidance Points” further exemplify the meaning of the sub-criteria and give hints for their application.



Criterion Sub-Criterion Relevant aspects related to Business Interoperability Leadership (1c) Leaders interact with

customers, partners and representatives of society

Develop, establish and actively participate in partnerships

Develop and engage in joint improvement activities (2a) Policy and Strategy are based on the present and future needs and expectations of stakeholders

Collect and understand information to define markets in which the organisation will operate now and in the future

Identify, understand and anticipate needs of present and future stakeholders (customers, employees, partners, society, investors)

Policy and Strategy

(2c) Policy and Strategy are developed, reviewed and updated

Identify core competencies and define necessities for partnerships and alliances for the deployment of policy and strategy

Interlock strategy with that of partners and alliances (4a) External partnerships are managed

Realise opportunities for partnerships with other organisations and society in accordance with policy, strategy and mission

Establish partnerships (e.g. with suppliers) along the supply chain to increase the value added for customers

Identify and deploy core competencies of partners and support joint enhancements

Assure cultural compatibility and knowledge sharing with partners

(4d) Technology is managed Develop a strategy for technology management in accordance with policy and strategy

Use information and communication technology to support and improve business processes

Partnerships and Resources

(4e) Information and knowledge are managed

Develop a strategy for information and knowledge management in accordance with policy and strategy

Provide internal and external users access to relevant information and knowledge

Use information technology to support internal communication, information exchange and knowledge management

Develop and protect unique intellectual assets to maximise the value added at customers

(5b) Processes are improved, as needed, using innovation in order to fully satisfy and generate increasing value for customers and other stakeholders

Inspire creative and innovative talents of employees, customers and partners for gradual and fundamental improvements

Announce process changes to all affected stakeholders

(5c) Products and services are designed and developed based on customer needs and expectations

Develop new products and services together with customers and partners that increase the value added for customers

Using creativity, innovation and core competencies of both employees and external partners to develop competitive products and services

Processes

(5e) Customer relationships are managed and enhanced

Pay actively attention to customers to share needs, expectations and concerns

Establish partnerships with customers to improve the value added along the supply chain

Table 3-4. Relevant Sub-Criteria and Guidance Points for Business Interoperability (cf. [EFQM 2003b])



The final and core element of the EFQM Excellence Model is the RADAR-Logic. RADAR is an abbreviation for Results, Approach, Deployment, Assessment and Review. It reflects the lifecycle aspect of excellence (plan, build, run, monitor): The organisation defines results which it wants to achieve with its policy and strategy. The organisation plans and develops approaches and methods to realise the results. The organisation deploys the approach to ensure the realisation of the results. The organisation assesses and reviews the approaches and their application through monitoring and analysis of the achieved results. The organisation identifies, prioritises and plans improvements and implements it.

Whereas the Results element is used for the results criteria, the other four elements are used to assess the enabler criteria (cf. [EFQM 2003a]). Every element has some attributes that further define the elements and help the assessor to evaluate the sub-criteria in its context. Elements and attributes are described in Table 3-5.

Criteria RADAR-Element Attributes Results Results Tendency – tendency is positive and/or there is a sustainable good

performance

Goals – goals have been met; goals are appropriate

Comparisons – results are positive in comparison to others and/or results are positive in comparison with “first class” enterprises

Causes – results are caused by approaches Approach Established – approach is well-founded; approach is based on defined

processes; approach is in alignment with stakeholders

Integrated – approach supports policy and strategy; approach is linked to other methods were applicable

Deployment Implemented – approach is implemented

Systematic – approach is realised in a structured, planned and well-founded way

Enabler

Assessment & Review

Measurement – the approach’s effectiveness and its deployment is regularly measured; the measurement categories are appropriate

Learning – is used for best practice and improvement identification

Improvement – results from measurement and learning are analysed and used to identify, prioritise, plan and implement improvements

Table 3-5. Attributes of the RADAR elements (cf. [EFQM 2003a])

The maturity within every criterion part is a combination of the maturity level within every attribute of every element of the RADAR logic. So, for every criterion part the maturity level is derived from five (results) to seven (enablers) single assessments. The assessment is based on a scale ranging from 0% to 100% with three intermediate levels (25%, 50% and 75%). Every maturity level has a narrative description to facilitate the assessment. The attribute “establish” of the “approach” element, for example, has the following levels (other attributes have similar levels): 0% - no evidence or anecdotic 25% - some evidence 50% - evidences 75% - obvious evidences 100% - comprehensive evidences

The EFQM Excellence Model provides a comprehensive approach to assess an organisation’s state of excellence maturity. The combination of criteria, criterion parts, guidance points, the RADAR elements and their attributes allow for a deep analysis of the organisation. They cover different parts of excellence and life-cycle aspects. Some criterion parts are useful to assess an organisation’s ability to cooperate and will therefore influence the Business Interoperability Framework.



3.2.2 The Capability Maturity Model

Uncertainty, complexity and interdependence frequently determine software development processes. Uncertainty is the difficulty of solving the problems posed, whereas complexity is understood as the number of different types of problems posed. Interdependence, finally, is the extent to which the solutions to these problems are related. In order to address these three dimensions organisations can use the Capability Maturity Model (CMM) as an approach of bureaucratic rationalisation. The main focus is on standardising the work process with the attempt of reducing uncertainty. Simultaneously, greater levels of complexity and interdependence can be managed.

The Capability Maturity Model (CMM) describes key elements of an effective software process which is understood as an evolutionary improvement path, starting from an ad hoc, immature process to a mature, disciplined process. By following the key practices of the CMM, organisations can improve their ability to meet goals for cost, schedule, functionality, and product quality.

The CMM is composed of five successively more ‘mature’ levels of process capability. Each level is characterised by mastery of a number of key process areas (KPAs, except level 1). The KPAs represent clusters of related activities for achieving maturity level goals. They are organised into common features. The common features define key practices that have to be accomplished in order to achieve the goals of the key process areas.

The components of the CMM in detail (cf. [Paulk et al. 1993a]): Maturity levels: A well-defined evolutionary level of software process. Process capability: Range of expected results that can be achieved by following a software process. Key process areas: Cluster of related activities. In order to achieve goals relevant for a maturity level, activities have to be performed collectively. Goals: Scope, boundaries, and intent of key process areas. Common features: Attributes indicating whether the implementation and institutionalisation of a key process area is effective, repeatable, and lasting. The common features are activities performed (related to implementation activities), commitment to perform, ability to perform, measurement and analysis, and verifying implementation (all related to institutionalisation activities). Key Practices: infrastructure and activities contributing most to the effective implementation and institutionalisation of key process areas.

Figure 3-9. Structure of the CMM [Paulk et al. 1993a, 29]

“The CMM belongs to a class of improvement approaches that focus on ‘process’ rather than ‘people.’ It does not recommend any particular approach to organisational and behavioral issues: it focuses on the ‘whats’ and not the ‘hows,’ leaving CMM users to determine their own implementation



approach.” [Adler 2005, 409]. The maturity levels and their key process areas are depicted in Table 3-6. The key process areas can be categorised into three broad process categories which illustrate the relationships between KPAs of different maturity levels. The management process category explains project management activities (e.g. software project planning, management), the organisational process category defines cross-project responsibilities (e.g. senior management review) and the engineering process category contains technical activities (e.g. requirements analysis, design, code, and test). The categorisation in process categories is marked as M, O and E in the table.

Level Focus And Description Key Process Area 1: Initial Competent people and heroics: There is not a stable

environment for developing software. By consequence, the process is ad hoc, occasionally, and chaotic. As planning is not possible, projects are practiced by coding and testing. Therefore success depends on individual effort and the software process, its schedules, budgets, functionality and quality are unpredictable.

2: Repeatable Project management processes: By implementing policies for basic project management processes basing on experience with earlier projects, successful practices of similar applications can be repeated. Furthermore, basic software management controls are established in order to track cost, schedule, and functionality. Therefore the software process can be described as disciplined.

Requirements management (M)

Software project planning (M)

Software project tracking and oversight (M)

Software subcontract management (M)

Software quality assurance (M)

Software configuration management (M)

3: Defined Engineering processes and organisational support: The software process for management and engineering activities is documented, standardised, and integrated into a coherent whole standard software process across the organisation. All projects for developing and maintaining software refer to that defined standard process. As a result, cost, schedule, and functionality can be managed.

Organisation process focus (O)

Organisation process definition (O)

Training program (O)

Integrated software management (M)

Software product engineering (E)

Intergroup coordination (M)

Peer reviews (E) 4: Managed Product and process quality: Setting quantitative quality

goals, product and process qualities can be measured, collected in an organisation-wide database, and analysed. Therefore projects can be controlled whether their performance fall within acceptable quantitative boundaries. By consequence, the software process capability can be concluded as to be predictable.

Software quality management (E)

Quantitative process management (M)

5: Optimising Continuous process improvement: The organisation is focused on continuous process improvement. Weaknesses and strengths of the process are identified in order to prevent the occurrence of defects. Besides process improvement, innovative ideas and technologies are piloted and transferred throughout the organisation.

Defect prevention (E)

Technology change management (O)

Process change management (O)

Table 3-6. CMM Maturity Levels and Key Process Areas (cf. [Paulk et al. 1993a, Paulk et al. 1993b, Adler 2005])



3.2.3 Collaboration Maturity Grid for the New Product Introduction Process

Collaborations are an increasingly common feature of the new product introduction (NPI) process. They raise additional challenges over purely in-house projects. [Fraser 2003] proposes a framework which considers collaborative maturity as a tool to examine the issues concerned with outsourcing of design or development activities. In addition, the framework provides guidance to managers that are involved in such collaboration projects.

The Collaboration Maturity Grid (CMG) describes seven key process areas of collaboration: Collaboration strategy, structured development process, system design and task portioning, partner selection, project initiation, partnership management, and partnership development. For each process area four levels of maturity can be defined. A distinction is made between issues that are relevant to the OEM and those that relate to collaborative projects themselves (cf. Table 3-7).

Context Key Process Area Primary Issues

Collaboration strategy Investment in core competencies and make-collaborate-buy decision

Structured development process Formality of NPI process and cultures

Company Specific

System design and task partitioning

Modularity, interface definition and task interdependencies

Partner selection Investment in search and assessment of partner capabilities

Partnership formation and project initiation

Negotiation of roles and responsibilities, deliverables and payments

Partnership and project management

Day-to-day project management and resolution of problems

Partnership Specific

Partnership development Investment in the relationship that will pay off in future projects

Table 3-7. Key Process Areas of the Collaboration Framework (cf. [Fraser 2003, 1505])

For every key process area several elements of collaborative maturity are defined. For example, collaboration strategy includes the conscious identification of core technological competencies and their active development, as well as processes for identifying external sources of expertise and their use. The structured development process includes the development of a well-defined NPI process within the company and by its partners, the compatibility of the processes, and provision for integrating third-parties.

The maturity grid envisages four levels of maturity that describe typical collaborative behaviour (cf. [Fraser 2003]): Level 1: No conscious collaboration process; a successful outcome may well be accidental or dependent of the heroics of a few key individuals Level 2: Some basic collaboration management processes are established Level 3: The collaboration process is used consistently in all collaborative projects Level 4: The process is continuously improved; the ability to manage collaborative activity is considered a core competence

The maturity levels capture elements of “good practice” rather than a rigorous metric. [Fraser 2003] also postulates that level 4 might not be ideal under all circumstances. The CMG is completed by a definition, discussion questions and some elements of “good practice” for every key process area. The full collaboration maturity grid for the process “structured development process” is given in Figure 3-10 as an example. The summary maturity grid including all processes and maturity levels is illustrated in Figure 3-11.



Figure 3-10. Collaboration Maturity Grid for the Structured Develoment Process [Fraser 2003, 1518]

Figure 3-11. Summary Maturity Grid [Fraser 2003, 1519]



3.2.4 Contribution to Business Interoperability Framework

[Farrukh 2003, 1132] explain the concept of maturity levels by the example of activities and business processes: “Maturity grids are a way of describing the characteristics of an activity at a number of different levels of performance. At the lowest level, the performance of an activity may be rather ad hoc, or depend on the initiative of an individual, so that the outcome is unlikely to be predictable or reproducible. As the level increases, activities are performed more systematically and are well defined and managed. At the highest level, best practices are adopted where appropriate and are subject to a continuous improvement process. For areas which are repeated across the company in different projects, it is likely that there will be some form of defined process, the primary purpose of which is to ensure consistency of approach and outcome.” A similar approach can be taken for interoperability. Low levels of business interoperability usually are associated with ad hoc setup of bilateral relationships. Higher levels of business interoperability can only be achieved by a more systematic approach which allows for 1:n or m:n connectivity.

Maturity models provide valuable contribution to the Business Interoperability Framework with respect to structure and building blocks. Maturity models examine a complex subject by dividing it into “categories” or “criterion”. In some cases, these categories are further divided into sub-categories. Maturity levels help to define the state of an organisation or process within the subject of investigation. [Fraser 2003] examined a number of maturity models and found that most models use four or five maturity levels. Finally, some models contain some kind of “life-cycle aspect”. Once a certain level of maturity could be reached by the object of investigation, the question is how it can stick to the level or how it must adapt to future requirements. Another life-cycle aspect is inherent to processes, such as collaborations, which start with a planning and design phase, are implemented and used, and are sub-ject to future changes. In every phase of the life-cycle, different aspects may be applicable to achieve maturity. For example, in the EFQM framework the RADAR elements define the life-cycle aspects.

The structure of the BIF and its function as an Excellence Model for Business Interoperability is designed with regards to these three aspects. Special attention is paid to the structure of the EFQM Model. In the case of the BIF, the object of investigation is the collaboration between networked enter-prises. The complex issue of business interoperability is structured into several categories which are sub-divided into criteria. The life-cycle aspect in IT-supported relationships can be covered by the RADAR dimensions (approach, deploy and assess & review). In addition, the existing maturity models provide some input for the appropriate naming and the number of maturity levels within the BIF.



4 Business Interoperability Framework (BIF)

The following section presents a detailed overview on the Business Interoperability Framework: Section 4.1 explains the outline of the framework. It is followed by a detailed presentation of the four categories which determine business interoperability (in Section 4.2) and the contingencies (in Section 4.3) which influence the level of business interoperability. This section presents Version 2.0 of the Business Interoperability Framework which incorporates the feedback from the application to various cases and, in particular, the ATHENA pilots. The previous version 1.0 is available as ATHENA Working Document WD.B3.1.

4.1 Outline of the Business Interoperability Framework

As outlined in Section 2, business interoperability characterises the business relationships of an enterprise and its external partners, such as customers, suppliers and service providers. The objective of the Business Interoperability Framework is to describe the main constituents of business interoperability and to outline how an enterprise may assess and improve its business interoperability. To this purpose, the BIF distinguishes 4 categories (Table 4-1): Management of External Relationships Employees & Culture Collaborative Business Processes Information Systems

Building on the Contingency Theory of Organisations, the Business Interoperability Framework postulates that the optimum inter-organisational design fits external (environmental) and internal contingencies.

Business Interoperability (= organisational design of business relationships)

Category Perspective Description

Management of External Relationships

“How do we manage and control business relationships?”

(Governance Perspective)

Interoperable organisations manage and monitor their business relationships.

Employees & Culture “How do we behave towards our business partners?”

(Behavioural Perspective)

Interoperable organisations promote relationships with business partners at an individual, team-based and

organisational level.

Collaborative Business Processes

“How do we collaborate with business partners?”

(Operational Perspective)

Interoperable organisations can quickly and inexpensively establish and conduct electronic

collaboration with business partners.

Information Systems “How do we connect with business partners?”

(Technical Perspective)

Interoperable ICT systems can be linked up to other ICT systems quickly and inexpensively and support the

cooperation strategy of the organisation.

Contingencies (= factors which impact the organisational design)

Category Perspective Description

Internal Contingencies

“What are the characteristics of the business relationship?”

Cooperation targets and transactional characteristics impact the optimum level of business interoperability.

External Contingencies

“Which environmental factors affect the business

relationships?”

E-Business maturity, legislation and industry dynamics determine preconditions in the specific context.

Table 4-1. Business Interoperability Framework – Categories and Contingencies



4.1.1 Categories

The core of the Business Interoperability Framework describes and assesses the IT-supported business relationships of an organisation. It comprises the following elements:

• The four categories represent the fundamental concepts of business interoperability as identified in the state of the art analysis. They cover governance, behavioural, operational and technical perspectives. The technical perspective comprises key decisions related to the type and depth of electronic interaction with business partners and are considered an integral part of the organisational design, thus reflecting a business driven view on IT.

Each of these categories is operationalised by a set of criteria (or sub-categories) which outline the key business decisions companies have to solve when establishing interoperable IT-supported business relationships. Metaphorically speaking, criteria are parameters that can be tuned in order to increase interoperability of an enterprise. The interoperability levels per criteria serve as a basis for assessment and a guideline towards higher levels of interoperability. To this purpose, the BIF considers the life-cycle aspect (cf. Section 3.2.1) by the RADAR dimensions. It distinguishes the aspects of approach, deploy and assess & review: The organisation plans and develops approaches and methods to define and realise IT-supported relationships. The organisation deploys the approach by implementing it systematically. The organisation assesses and reviews the approaches and their deployment through monitoring and analysis of the achieved results. The organisation identifies, prioritises and plans improvements and implements it.

Category Description Life-Cycle 5 (fully interoperable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Approach Strategic importance of cooperations is recognized and embedded in company strategy (senior management commitment); cooperation models with external partners are co-defined and embedded in a network business model

Strategic importance of external cooperation is recognized and embedded in company strategy (senior management commitment); the cooperation model with external partners are documented

Significance of external partnerships is recognised; a cooperation model with external partners has been outlined

Cooperation model is not explicitely defined; cooperations are established with well-know partners

No awareness of external relationships; ad-hoc setup of external relationships

Deploy Applied in all partnerships Applied in most partnerships

Applied in all strategic partnerships (focussing on "A partners")

Applied in some (new) partnerships

Not (yet) applied

Assess & Review

Systematic review and assessment of cooperations with partners, "lessons learned" (positive and negative) are integrated in cooperation model

Periodic evaluation of success factors is performed and leads to adaption of cooperation model

Sporadic or occasional evaluation of success factors is performed and leads to adaption of cooperation model

Updates and changes are an exception and only occur as reaction to external pressure (e.g. when imposed by legislation or external partners)

No review

Approach Public processes have been defined and documented; they are built by consensus and reflect multilateral agreements, industry or domain standards (m:n)

Public processes have been defined and documented; they have been defined for a broader number of relationships (1:n) taking into account previous and future requirements (building variants with limited deviations)

Cross-organisational processes are defined bilaterally (1:1)

Cross-organisational processes are imposed by one of the partners

Cross-organisational interaction is performed ad-hoc




Not (yet) applied

Review & Assess

Cross-organisational process is managed and subject to continuous improvement

Cross-organisational process is monitored and adapted regularly to include important changes and new requirements

Sporadic or occasional evaluation of success factors is performed and leads to adaption of cross-organisational process design

Updates / changes are an exception and initiated external events (requested by dominant partner, changes in legal requirements, …)

No monitoring or improvement of the cross-organisational processes

Management of External Relationships - "How do we manage and control external relationships?"


Cross-Organisational Business processes - "How do we collaborate with business partners?"

Publ

ic P

roce

ss

Pragmatics: A public process describes how companies interact. It establishes a common understanding of the roles, activities and in particular the organisational interfaces. Ideally public processes are built by consensus and reflect multilateral agreeme

Coo

pera

tion

mod

el

Strategic dimension: A cooperation model has been defined serving as the frame for external relationships

CategoryCategories

CriteriaCriteria

Life-cycle Perspective

Level of Business

Interoperability

Figure 4-1. Assessing the Level of Business Interoperability

4.1.2 Levels of Business Interoperability in the BIF

The idea of interoperability does not fit binary choices like “yes” or “no”, but is multi-faceted. Consequently, there is a need for distinguishing different interoperability levels. This is also reflected by [Fraser 2003, 1508f.]: “Whereas checklists provide a yes/no binary response to a single ‘good practice’ proposition and Likert-scale questionnaires generally provide at most two descriptive anchor phrases, the maturity grid is able to capture a range of good and not-so-good practice.” Hence, the structure of the Business Interoperability Framework is inspired by existing excellence models like the



EFQM Excellence Model or the Capability Maturity Model (see Section 3.1.3.2).

However, unlike with EFQM and CMM, a higher level of business interoperability is not necessarily a sign of excellence or maturity, due to the fact that the optimum level of interoperability depends on “fit” between interoperability and its contingencies. The highest level of business interoperability represents the maximum value, i.e. the fact that an enterprise is fully interoperable in the sense that new business relationships can be established at low costs involved. It does not necessarily represent the optimum level for the specific organisation, but could also be the result of an over-investment in interoperability. To reflect the optimum vs. maximum condition we propose a “neutral” naming of the business interoperability levels (see Table 4-2).

No. Business

Interoperability Description

(1) None No awareness of external relationships; interaction with external partners is not planned or performed ad-hoc

(2) Minimum No previsions for interoperability; individual design of each external relationship

(3) Moderate Relevance of business interoperability is “understood”; Measures for improving interoperability have been taken, but substantial room for improvement remains

(4) Qualified External relationships are designed for improved business interoperability; only few factors missing on the way to full interoperability

(5) Fully interoperable

Maximum level of business interoperability; external relationships can be established at no or few cost involved

Table 4-2. The Five Levels of Business Interoperability in the BIF

4.2 Business Interoperability Categories and Related Interoperability Levels

4.2.1 Category “Management of External Relationships” (Governance Perspective)

Numerous scholars (e.g. [Ford 2003, Daft 2004, Schuh et al. 2005, Klein/Poulymenakou 2006]) confirm the need for a dedicated management function in order to “handle the inherent complexity of inter-firm relationships” [Riemer/Klein 2006]. [Dyer et al. 2001] defines the role of network manage-ment to “coordinate all [network] related activity within the organization”. It starts with planning and defining the cooperation, e.g. by selecting partners and preparing cooperation contracts. Following the life-cycle of the cooperation, it covers all aspects of realising and sustaining the relationship, such as managing conflicts and establishing communication channels with the external partners. Once the cooperation is finished, feedback loops ensure learning from good as well as bad experiences.

Criteria related to “Management of Business Relationships” include: Cooperation model: The cooperation model represents the strategic dimension of managing external relationships. In order to realise a sustainable and viable collaboration with other organisations, an enterprise has to define its cooperation models and embed them as integral part into the company strategy. Cooperation targets: Cooperation targets reflect the economic dimension of the inter-firm relationships which covers benefits as well as measures for success. Ideally, business partners reconcile and monitor the plans and objectives that they pursue. Cooperation management (roles and processes): Cooperation management relates to the organisational aspects of managing external relationships. On the firm-level, an enterprise needs to manage the initiation, realisation, control and monitoring of a cooperation and take previsions for the management of risk and conflict. This includes roles as well as processes.




4 (qualified)

3 (moderate)

2 (minimum)

1 (none)









Not (yet) applied

Assess & Review





No review

Approach Cooperation targets are defined and re-conciled with partners, jointly monitored and re-adjusted

Cooperation targets are individually defined and shared among the partners; individual targets that are not communicated remain

Cooperation targets are explicitely defined, but imposed by one (dominant) partner

Partners pursue individual cooperation targets and do not communicate them to partners

No definition of cooperation targets




Not (yet) applied

Assess & Review

Systematic review and assessment, "lessons learned" (positive and negative) are integrated in target setting and controlling approach

Periodic evaluation of success factors is performed and leads to adaption of target setting and controlling approach

Sporadic or occasional evaluation of success factors is performed and leads to adaption of target setting and controlling approach


No review

Approach Cooperations are actively managed along the entire life-cycle; escalation procedures are defined for conflict resolution

Partner management processes have been defined and cover most phases of the life-cycle; rigorous partner selection is applied

Guidelines for partner management exist for the most critical phases of the cooperation live-cycle; main focus is on partner selection

No formal cooperation processes; cooperations are set up individually with each partner based on previous experiences

Partners are chosen ad hoc and with no pre-defined evalution criteria; no guidelines or processes exist




Not (yet) applied

Assess & Review

Systematic review and assessment, "lessons learned" (positive and negative) are integrated in partner management approach

Periodic evaluation of success factors is performed and leads to adaption of partner management approach

Sporadic of occasional evaluation of success factors is performed and leads to adaption of partner management approach

Updates and changes are an exception and only occur due to external pressure (e.g. when imposed by legislation or external partners)

No review

Approach Roles and responsibilities related to partner management are comprehensively defined

Some responsibilities for external partners have been defined

A central contact point for the external partner has been defined

No formal responsibility for partner management; partner contacts are individually defined





Not (yet) applied

Assess & Review



Occasional evaluation of success factors is performed and leads to adaption of partner management approach


No review

Economic dimension: Plans and objectives, that partners pursue in the cooperation, are defined and reconciled with partners, monitored and adjusted

Coo

pera

tion

man

agem

ent

(rol

es)

Organisational dimension: Specific roles (e.g. partner managers) have been introduced in the organization in order to establish well-defined and efficient communication paths between the different organizations.


Coo

pera

tion

man

agem

ent

(pro

cess

es)

Organisational dimension: The processes for initiation, realisation, control and monitoring of cooperations are managed; previsions for risk and conflict management have been taken

Coo

pera

tion

targ

ets


Coo

pera

tion

mod

el


Figure 4-2. Criteria in Category “Management of External Relationships”

4.2.1.1 Cooperation Model

Increasing levels of external collaboration require enterprises to systematically define their cooperation model and select target partners. The cooperation model and partners are heavily depen-ding on the business model of an enterprise which represents the “architecture for the product, service and information flows, including a description of the various business actors and their roles; and a description of the potential benefits for the various business actors; and a description of the sources of revenues”. [Timmers 1998, 4]. On the other hand, the cooperation model represents the firm-level perception of the “network business model” [Riemer/Klein 2006] or the “business network design”, which specifies the group of actors, their roles in terms of value creation activities (“who does what”),



the interplay between the actors (“how does it work together”) and the value flow between the partners.

The criterion “cooperation model” describes to what extent an enterprise defines its role within a business network and clear rules of engagement which underlie any cooperation. At the lowest BI level an organisation is not aware of external relationships and does not see the need for a cooperation model at all. Fully interoperable enterprises define their cooperation model either per partner or per partner segment. Ideally they reconcile it with their business partners.

In B2B, relationships with external organizations are typically reflected by an economic contract. This formal agreement clarifies the juridical elements of the business relationships, such as the purpose and duration of the cooperation as well as the resources and revenue streams committed with a clear definition of roles, responsibilities and property rights. Some authors (cf. [Schuh et al. 2005]) highlight the need for social contract, which defines the “what” and “how” of the cooperation. This can include parts of risk and conflict management, e.g. mechanisms to use in case of conflicts. If both contracts actually need to be written down depends on the cooperation partners. Some partners may find it constrictive; others are not able to execute a cooperation without written contract. However, it is impossible to fully govern interorganisational relationships by contracts because the complexity of such relationships results in a high proportion of non-contractible issues.

4.2.1.2 Cooperation Targets

Inter-firm relationships typically lack hierarchical governance. Consequently, they heavily rely on reciprocity within the relationships and the fact that both parties feel that they are gaining (win-win-situation). Although the economic benefits of closer collaboration might be distributed asymmetrically due to the distribution of power, we consider that sharing and aligning the individual targets contributes to interoperability.

At the highest level of business interoperability, cooperation targets are reconciled between business partners and aligned with the overall networked goals. In the situation with low business interoperability, enterprise are unaware of external partners and do not formulate cooperation targets.

4.2.1.3 Cooperation Management (Roles and Processes)

Cooperation management defines the roles and processes for initiation, realisation, control and monitoring of the cooperation. It takes previsions for the management of risk and conflict as well as for the protection of property rights [Dyer et al. 2001]. Cooperation management represents the firm perspective on network governance [Riemer/Klein 2006].

In the early phases of a cooperation, cooperation management implies evaluation criteria for partner selection and assessment. Once the cooperation is set up, it requires previsions for decision making (consensus vs. majority, formal vs. informal) as well as conflict solving (informal discussion vs. mediation vs. arbitrage vs. court decision). The latter are helpful given the inherent conflicts which may arise in inter-firm relationships .

As organisations tend to expose their internal complexity to their business partners, dedicated responsibilities for cooperation management gain importance with an increasing number of external relationships. Specific roles which serve as contact points for external partners ensure a clear communication route, such as escalation procedures for the early identification of conflict.

4.2.2 Category “Employees & Culture” (Behavioural Perspective)

This category relates to the behavorial aspects of inter-firm relationships. Effective collaboration with external partners requires organisations to be open to change and establish a relationship of trust and confidence instead of mutual checks. Interoperable enterprises promote inter-firm relationships at an individual, team-based and organisational level. At an organisational level, the participating firms are the institutional actors forming the collaborative relationship, but the employees carry out the actual work at an individual or team level [Riemer/Klein 2006]. In practice, collaboration cannot be neither ordered nor imposed on someone. Since inter-firm relationships are often too costly to be completely formalised in contracts (as outlined in Section 4.2.1.1), informal relationships and trust between em-ployees are key to make more intensive forms of collaboration work. This aspect is also referred to as ‘Social Capital’ in literature [Riemer 2006]. The establishment of social integration among the involved people improves the flow of information, facilitates the emergence of trust and helps to avoid mis-understandings and conflicts.



The category “Employees & Culture” covers behavorial aspects at the firm level as well as the individual level. It concentrates on trust and information sharing since these are the two most promi-nent dimension in research.

Criteria related to “Employees & Culture” include: Trust: Trust characterises behavorial aspects at the individual level. Ideally, the employees who are involved in the inter-firm relationship cooperate in a climate of trust and confidence. Visibility: Whereas trust arises from the informal relationships between employees, visibility represents the formal relationships and relates to the openness and information sharing at the firm level. Giving a certain visibility of the internal operations to external partners can be considered a prerequisite for aligning and optimizing the cross-organizational business processes. Category Description Life-Cycle 5

(fully interoperable)4

(qualified)3

(moderate)2

(minimum)1

(none)


Approach Mutual sense of trust and confidence; employees act as cross-organisational team with appreciation on both sides

Good working relationship; Growing sense of trust and confidence

Initial measures are taken to establish social integration

Significance of trust and confidence in external relationships is recognised

Them and us attitude, new skills jealously protected ("Better the devil you know…"); ; control




Not (yet) applied

Review & Assess

Periodic review and assessment, "lessons learned" (positive and negative) with employees involved in inter-firm relationships

Periodic evaluation of success factors is performed with employees involved in inter-firm relationships

Sporadic or occasional evaluation of success factors is performed with employees involved in inter-firm relationships

Updates/changes are only initiated in case of conflicts or pressure by the external parties

No review

Approach Pro-active information sharing and full accessibility of relevant information for external partners

The relevant information is accessible for external partners

Certain visibility focusing on the most critical pieces of information is provided to external partners

Visibility is only provided "on demand", i.e. only in case of request by the external partner

No visibility for external partners




Not (yet) applied

Review & Assess

Periodic review and assessment of the information needs and practices

Periodic evaluation of success factors is performed and leads to adaption of information sharing practices

Sporadic or occasional evaluation of success factors is performed and leads to adaption of information sharing practices


No review

Behavorial dimension - organizational level: Information sharing and accessibility of internal information for business partners. A certain visibility of the internal business processes (e.g. status information, availability, inventories, …) allows for cross-organizational optimization.

Employee & Culture - "How do we behave towards our external business partners?"

Trus

t

Behavorial dimension - individual level: Responsibility, sympathy, reliability and confidence between partners. Building a climate of trust and confidence, with the development of a dependable relationship.

Visi

bilit

y

Figure 4-3. Criteria in Category “Employees & Culture”

4.2.2.1 Trust

Trust characterises the mutual respect, openness, reliability and confidence between the employees involved in the collaborative relationship. Social ties and team-building are essential for building a climate of trust and confidence, with the development of a dependable relationship.

When low interoperability prevails in inter-firm relationships, people from different organisations show a “them and us” attitude. In contrast to that, a high level of interoperability makes people act as a cross-organisational team.

4.2.2.2 Visibility

Experiences from e-business projects confirm that collaboration requires information sharing and a minimal visibility of the internal operations to external business partners (e.g. status information or notification in the case of an exception). Based on combined information and knowledge, business partners are able to make joint decisions and optimise performance [Bowersox et al. 2003, 22]. This implies that information and knowledge that used to be considered proprietary or even strategic is shared [Fricke et al. 2002].

The criterion “visibility” describes the degree to which information is shared with partners and which external partners gain visibility of the business process. Visibility is essential in collaboration scenarios related to product development (e.g. engineering and design processes of complex pro-ducts) or supply chain management (e.g. VMI / vendor managed inventory and BMI / buyer managed inventory). These scenarios often fail in reality because organisations are not prepared or willing to share the required internal data with their partners. (cf. [Fricke et al. 2002]).



4.2.3 Category “Collaborative Business Processes” (Operational Perspective)

In B2B relationships, responsibilities of the partners often are not well-defined. As a consequence, activities are performed ad hoc. This often results in resource conflicts as well as coordination effort. Business interoperability builds on the vision that companies can quickly and inexpensively establish and conduct a relationship of coordination with corresponding partner processes. In order to ensure frictionless operations and coordination, partners have to clarify responsibilities and allocate tasks between them (cf. [Clark/Stoddard 1996, Alt 2006]). This is done by the means of agreements on the collaborative business processes. The alignment of cross-organisational business processes relies on a common business vocabulary and terminology among the partners.

Criteria related to “Collaborative Business Processes” include: Public process: Public processes define the pragmatics of the business relationships. They describe how firms interact. They establish a joint understanding of the roles, the cross-organisational activity flow and the organisational interfaces. In the vision, this public process should not be subject to lengthy bilateral discussions, but be applicable in a broader context (m:n instead of bilateral agreements). Business semantics: Business semantics align the proprietary terminology of the different organisations and establish a common business vocabulary. They have to cover the transactional information flow (main business documents / messages) as well as the contextual information (in particular master data). Category Description Life-Cycle 5


(qualified)3

(moderate)2

(minimum)1

(none)


Approach Public processes have

been defined and documented; they are built by consensus and reflect multilateral agreements, industry or domain standards (m:n)








Not (yet) applied

Review & Assess






Approach Business vocabulary of reference is defined and reflects industry or domain standards

Business vocabulary of reference is defined for a broader number of relationships (1:n)

Business vocabulary is defined bilaterally (1:1)

Proprietary business vocabulary of one of the partners is used

Use of proprietary semantics




Not (yet) applied

Review & Assess

Business semantics and information quality are managed and subject to continuous improvement

Business semantics and information quality are monitored; they adapted regularly to include important changes and new requirements

Sporadic or occasional evaluation of success factors is performed and leads to adaption of business semantics

Updates/changes are initiated externally (requested by dominant partner, changes in legal requirements, …)

None

Approach Business vocabulary of reference is defined and reflects industry or domain standards


business vocabulary is defined bilaterally (1:1)

Proprietary business vocabulary of one of the partners is used





Not (yet) applied

Review & Assess





None

Bus

ines

s se

man

tics

(bus

ines

s do

cum

ents

)

Semantics: A common business vocabulary establishes a joint understanding of the content and structure of business documents as well as the meaning of its elements. The semantics for main business documents / messages should be defined, commonly accepted and reflect industry standards.


Bus

ines

s se

man

tics

(info

rmat

ion

cont

ext)

Semantics: A common business vocabulary establishes a joint understanding of the identification, description and classification of relevant information context (e.g. product, partner, …). The semantics for master data should be defined, commonly accepted and reflect industry standards.

Publ

ic P

roce

ss

Pragmatics: A public process describes how companies interact. It establishes a common understanding of the roles, activities and in particular the organisational interfaces. Ideally public processes are built by consensus and reflect multilateral agreements, industry or domain standards (m:n).

Figure 4-4. Criteria in Category “Collaborative Business Processes”



4.2.3.1 Public Processes

A business process “is a set of activities, which are to be undertaken in a specified sequence and which are supported by information technology applications. Its value creation consists of the outputs to process customers. The process has its own management, which steers and designs the process in line with the business strategy using performance indicators …” [Österle 1995, 62]. In an inter-organisational relationship, two or more autonomous organisations jointly execute a process with the purpose to create a certain output. Cross-organisational business process design tends to be complex and has to cope with the following challenges: Business processes of external organisations are often perceived as “black box” since process activities and their interdependencies with internal processes are unknown to the internal staff. Business processes encapsulate the business logic and organisational knowledge of a company. For external business partners it is often very time-consuming to understand the internal process logic and terminology of an organisation. In cross-organisational business processes, actors are essentially autonomous and have the freedom to design and modify business processes within their organisational boundaries. This may result in individual business process life cycles, which may be very time-consuming or even impossible to align, especially in the case of a larger number of external partners. As [Riemer/Klein 2005, 33] put it, “partners have to agree on tasks allocation and network procedures in a way that will reduce complexity and heterogeneity in the network.” The BIF consequently introduces different views on business processes and distinguishes between public (or external) processes and private (or internal) processes. Public processes represent an abstracted view of the cross-organisational business processes which focuses on the interaction between the partners (e.g. activities, roles, inputs/outputs) thereby hiding all private details from the business partners.

Similar concepts are used for example by the European Interoperability Framework: Since it is unrealistic that national administrations will harmonise their business processes because of pan-European requirements [IDABC 2004, 18], it suggests identifying and documenting the “entry and exit points” of cooperation processes. Through these “business interoperability interfaces” (BII) the administrations will be able to cooperate with administrations of other Member States. For creating a public process two alternatives exist: (1) Multi-lateral agreement on the public process, or (2) definition of the public process by a dominant partner. The first approach can be fostered by standardisation initiatives, e.g. SCOR for supply chain management or ODETTE in the automotive industry.

Higher levels of business interoperability imply that business partners can rely on a clear and well documented public process that is practical and reflects industry standards. In contrast to that, ad-hoc interaction between business partners typically results in high coordination efforts and is a symptom of low business interoperability.

4.2.3.2 Business Semantics

Whereas business processes define the pragmatics of collaboration, they have to rely on a common terminology defining the underlying semantics [Clark/Stoddard 1996, Alt 2006]. Every organisation creates its own terminology which is reflected by the underlying information systems and the different internal representations of the relevant business objects. A prerequisite for inter-organisational collaboration is a common understanding of the structure and significance of the information to be exchanged. Consequently, business interoperability requires the semantics of main activities, documents / messages and master data to be defined and aligned between organisations.

The alignment of business semantics refers to both, the process-related transactional information flow as well as to further contextual data as outlined by [Siegel/Madnick 1991, Madnick 1995] under the term context interchange. [Madnick 1995] points out, that information transferred from a sender to a receiver may be misinterpreted since the systems usually operate in different contexts. To solve this problem, contexts need to be exchanged or aligned whenever changes at the sender side or at the receiver side occur. For example, large parts of the contextual data needed for supply chain collaboration between retailers and manufacturers consists in article descriptions (master data) which are referenced in business documents, such as orders or shipping notes.



4.2.4 Category “Information Systems” (Electronic Interaction Perspective)

Information systems enable the efficient and effective flow and use of information between and in organisations with the goal to contribute to the overall performance of the cooperation (cf. [Riemer/Klein 2005]). Although empirical studies report a relatively broad adoption of online advertising, marketing and customer support, they also show a limited penetration of electronic business partner integration (e.g. 8.3% in the manufacturing industry and 9.1% for wholesale / retail distribution) [König/Wigand 2004]. When setting up electronic links with business partners, companies often struggle with bilateral discussions. The lack of scalability to a broader number of business partners has hindered the diffusion of inter-organisational systems so far. Until now, standardisation has only partly been successful in creating this common terminology, since many standards, including XML and core Web Service standards, relate only to the syntactical layer. In the future, service-oriented architectures (cf. [Papazoglou/Georgakopoulos 2003]) could promote semantic integration by providing standardised interfaces which follow industry norms.

An additional factor in B2B relationships is the necessity to conduct transactions over the Internet that meet user’s privacy and security requirements as well as existing e-business legislation. This typically involves questions of authorisation, authentication, encryption etc.

Criteria with regard to “Information Systems” include: Type of interaction: The interaction type describes the coupling depth of the electronic interaction (human-human, human-machine or machine-machine). Connectivity: Connectivity characterises scalability of the electronic connections. In particular, it reflects whether connections are formed as point-to-point (1:1) or multilateral (1:n or m:n) connections. Security & Privacy: Security & privacy relates to the ability to conduct transactions over Internet which meet business partner’s privacy and security requirements as well as existing e-business legislation.

4.2.4.1 Interaction Type

With regard to coupling depth and technical integration, different interaction types can be distinguished (cf. [McAfee 2005b], [Reimers 2001]): “human-to-human” describes traditional forms of interacting between humans which may be supported by fax, phone, or e-mail communication. “human-to-machine”: Customer or supplier portals bundle data and applications on the basis of users and roles, and thus support human-to-machine connections with external partners. “machine-to-machine” denotes consistently automated processes and thus an inter-organisational linkage of applications. EDI is the standard example for machine-to-machine interaction, but has been excelled by XML and Internet technologies. Depending on the integration with internal backend systems, we differentiate between file-to-file and application-to-application. In the case of file-to-file connection, an electronic document generated in one organisation is electronically transmitted (e.g. using e-mail or ftp), but has to be manually uploaded into the target system.

Initially, portal solutions represent the dominant collaboration strategies as they have the lowest integration requirements. In the medium- and long-term, companies will prefer to network by means of business collaboration infrastructures due to the higher efficiency potentials.

According to our definition of business interoperability, manual interaction is considered as being not interoperable. We consider the ability of an enterprise to conduct machine-to-machine interaction as a characteristic of enhanced business interoperability.

4.2.4.2 Connectivity / Cooperation Architecture

Electronic interaction is associated with initial investments in B2B integration infrastructure. Depending on the interaction type, it may require the setup of a website or a portal (in case of human-machine), or an EDI or Web Service connection plus additional interfaces to the backend systems. By connectivity, we characterise the cooperation architecture which supports the electronic interaction. Point-to-point connections typically result in relationship-specific investments, whereas positive network effects play in the case of multilateral connections. The latter should build on industry and domain standards or involve hubs or exchanges.

We associate low interoperability with the dominance of point-to-point connections and consider the ability to realise m:n connectivity as a characteristic of an interoperable enterprise.



4.2.4.3 Security & Privacy

In B2B relationships, security & privacy issues have to be solved in order to conduct business transactions over an electronic channel. Security issues cover authentication and authorisation as well as as the encryption of messages. Additional privacy and legal requirements have to be respected, e.g. in electronic contracting and invoicing, since they deal with sensitive data and additionally need to comply with e-business legislation.

Low interoperability is associated with lacking previsions for security & privacy in electronic transactions. This results in additional manual or organisational efforts (e.g. parallel paper-based processes) in order to fulfil requirements. Contrastingly, advanced levels of interoperability rely on standard-based approaches to security & privacy, e.g. by using WS-Security.

Category Description Life-Cycle 5


(qualified)3

(moderate)2

(minimum)1

(none)


Approach Advanced machine-to-

machine interactionMinimum machine-to-machine interaction by simple file exchange of machine-readable documents

Advanced human-to-machine interaction (e.g. online services on portal); information is provided by electronic means, but needs to manually be processed

Minimum human-to-machine interaction (e.g. static website); information is provided by electronic means, but needs to manually be processed

Human-to-human interaction (e.g. phone, fax, e-mail)




Not (yet) applied

Review & Assess

Periodic review and assessment, "lessons learned" (positive and negative) are integrated in the set of electronic channels offered and the related interaction type

Periodic evaluation of success factors is performed and leads to adaption of electronic channels and interaction type

Sporadic or occasional evaluation of success factors is performed and leads to adaption of electronic channels and interaction type


No review

Approach Scalable B2B architecture with m:n-connectivity; using a common set of technologies, protocols and interfaces that reflect open or industry standards

Scalable B2B architecture with 1:n connections; using a set of widely used technologies, protocols and interfaces

1:1 connections and the related technologies, protocols and interfaces are bilaterally defined and established

Technologies, protocols and interfaces are imposed by the dominant partner

No architectural considerations




Not (yet) applied

Review & Assess

Periodic review and assessment, "lessons learned" (positive and negative) are integrated in B2B cooperation architecture

Periodic evaluation of success factors is performed and leads to adaption of B2B cooperation architecture

Sporadic or occasional evaluation of success factors is performed and leads to adaption of B2B integration approach


No review

Approach Security & privacy issues are defined and documented; they are built by consensus and reflect multilateral agreements, industry or domain standards (m:n)

Security & privacy issues are defined for a broader number of relationships (1:n)

Security & privacy issues are defined bilaterally (1:1)

Relevance of security & privacy issues is recognised; parallel manual or paper-based processes are in place in order to fulfill requirements

Cooperation is not aware of security & privacy issues




Not (yet) applied

Review & Assess

Periodic review and assessment, "lessons learned" (positive and negative) are integrated in B2B integration approach

Periodic evaluation of success factors is performed and leads to adaption of B2B integration approach



No reviewSecu

rity

& P

rivac

y

Electronic transactions respect the business partner's privacy and security concerns, and comply with e-business legislation.

Inte

ract

ion

type

The depth of electronic interaction with partners may differ between human-to-human, human-to-machine or machine-to-machine. Interaction.

Information Systems - “How do we connect with business partners?”

Con

nect

ivity

/ C

olla

bora

tion

plat

form

A high connectivity is achieved by replacing individual connections (1:1) with many-to-many connections (m:n); The collaboration architecture supports external relationships in an appropriate manner.

Figure 4-5: Criteria in Category “Information System”

4.3 Contingencies

External and internal contingencies represent preconditions for the enterprise’s optimum level of business interoperability.

4.3.1 Internal Contingencies

Internal contingencies describe the structural characteristics of the coordination area which an enterprise targets for improving inter-firm relationships (cf. Section 2.3 Unit of Analysis – the



“Networked Enterprise”). We consider the type and number of actors, the power distribution as well as the frequency and specificity of interaction as internal contingencies. As outlined in Section 3, we rely on prior research on networked organisations and inter-organisational systems for deriving the internal contingencies. We formulate additional hypothesis which postulate how internal contingencies are supposed to impact the optimum level of business interoperability following prior research.

Criteria Sub-Criteria / Values

Coordination area and targets

Innovation: e.g. time to market, enhanced product / service offering … Customer relationship management: e.g. customer retention / loyalty, access to new customers … Supply chain management: e.g. efficient supply of products, reaction time, asset utilisation … Infrastructure: e.g. costs of routine operations …

Business Partners / Business Network

Partner type: e.g. customer, supplier, service provider, competitor Number and size of partners Industry Geographical coverage: national, regional, international

Cooperation dynamics Stable – dynamic Network governance Hierarchic – heterarchic Interdependence Pooled interdependence – sequential interdependence – reciprocal interdependency Specificity Non-specific – mixed – idiosyncratic Frequency One-time – occasional – recurrent

Tabelle 4-1. Internal Contingencies

4.3.1.1 Coordination Area and Targets

A coordination area is typically associated with specific coordination requirements and resulting interaction frequency and intensity (cf. Section 2.3): The goal of supply chain management is to handle operative planning and execution processes as efficiently as possible. It multiplies clearly defined outputs and tries to utilise the effects of economies of scale in order to achieve profit. Several studies indicate that by coordination and information sharing each supply chain actor can make better decisions on ordering, capacity allocation and production / materials planning. As a result, the supply chain as a whole can reduce costs and respond more quickly to end-consumer demand [Lee et al. 2000, Cohen Kulp et al. 2004]. Supply chain management is characterised by large integration depth in the coordination of its well structured processes. It prefers the coordination forms internal and/or stable network. The goal of (customer) relationship management is to win customers and to gain their loyalty. Relationship management tries to cover as wide a spectrum of customer requirements as possible in order to utilise the effects of economies of scope. Partners are above all customers with whom a market-like relationship exists. The goal of the coordination area innovation is the rapid creation of new products, which requires a dynamic environment in the early phases. As a project advances in maturity, a business unit will coordinate with a large number of different partners. Depending on the task in question, the business unit follow the rules of different forms of coordination. The area infrastructure distinguishes itself from supply chain management in terms of content. The content does not necessarily show a high degree of repetition (e.g. preparation of a corporate balance sheet) and its transactions may be complex in nature (e.g. outsourcing of IT). There is a high level of dependency between the infrastructure partners which calls for the relationship to be stable. Hypothesis 1: We assume that the optimum level of business interoperability varies per coordination area:

Due to stable relationships and well structured processes with relatively large transaction volumes, supply chain management and infrastructure require higher levels of business interoperability (levels 3-5). Innovation is often associated with creative ways of collaboration, thus resulting in lower levels of business interoperability. With regard to customer relationship management, the optimum level of interoperability depends on power distribution between buyers and sellers: If an enterprise operates in a buyer market, higher levels of business interoperability might be required (e.g. imposed by the customers) than in a seller market (where low level of business interoperability creates lock-in effects).



Coordination Area 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Supply Chain Management

Innovation

Customer Relationship Management


Stable relationships, large transaction volumes and well-structured processes

creative ways of working in changing partner networks, less structured processes

Buyer marketsSeller markets

Figure 4-6: Coordination Area and Level of Business Interoperability

4.3.1.2 Business Partners / Business Network

Coordination requirements depend on the size and number of partners as well as on their diversity regarding industry and regional focus. Existing research on IOS [Iacovou et al. 1995, Löwer 2005] argues that SMEs are reluctant to higher levels of electronic integration due to the significant invest-ments (related to setup, personnel, operations) and their lacking organisational readiness for IOS adoption. Empirical studies on e-business adoption confirm that the size of an organisation impacts e-business adoption: “In general, ICT systems of large companies obviously tend to be more powerful and sophisticated than those of small firms. This translates into more intensive and advanced electronic business practices, and a greater potential for exploiting cost-saving opportunities.” [e-Business Watch 2005] Hypothesis 2: Since coordination requirements increase with the number of external relationships and partners, the level of business interoperability is negatively correlated with the number of external partners.

Hypothesis 3: Larger enterprises achieve higher levels of business interoperability than SMEs which have fewer resources and are often lacking the necessary organisational and technical capabilities.

Hypothesis 4: A broader industry and regional focus increases the diversity of the individual business relationships and thereby leads to lower levels of business interoperability.

Business Partners / Business Network

5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Increasing number of external partners

Size of enterprise

Diversity of the individual business relationships (Geographical scope, industries, …)


Figure 4-7: Business Partners and Level of Business Interoperability

4.3.1.3 Cooperation Dynamics

Inter-organisational relationships can be characterised with respect to their (planned) duration and the intensity of the relationship between partners (cf. [Sydow/Möllering 2004]). As an example, supply networks in the automotive industry are in place for several years. Companies in the construction industry usually cooperate only for the given period of a project (weeks, months) (cf. [Sydow 1999]). The automotive supply industry is an example for a stable network, whereas typical project relationships in the construction industry represent dynamic networks as outlined in [Snow et al. 1992, Sydow 1999]: In a stable network the asset ownership and the risk is spread between several independent companies. Partners in stable networks usually benefit from simplified coordination and the prospect of



future cooperation. The stability in supply and distribution is both advantage and disadvantage. Negative effects are the loss of flexibility and mutual dependences. Dynamic networks are common in fast-paced or discontinuous industries with short innovation cycles, such as fashion or biotechnology. In dynamic networks companies usually do not have enough resources or capabilities to keep pace with changing challenges. The assets owned by the participating companies are usually identified and assembled by a lead firm. The gain in flexibility in dynamic networks is accompanied by the risk of quality variations and temporarily unavailable resources. Hypothesis 5: In a stable network, investments in business interoperability are more likely to occur, thereby leading to higher levels of business interoperability. However, there might be not enough incentives to achieve m:n connectivity.

Cooperation Dynamics 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Stability of relationships


Figure 4-8: Cooperation Dynamics and Level of Business Interoperability

4.3.1.4 Network Governance

Network governance characterises the basic mechanisms with which decisions are made within a network [Hess 2002]. The governance of a network can be hierarchical and heterarchical [Sydow 1999]. In hierarchical networks the “nodes” (companies, partners) are organised in a pyramid-like system of ranking. Each node is subordinate to another node, except for the top node. The top node, called “focal enterprise”, controls the other companies in the network. The focal enterprise has most power and privileges and takes decisions which impact the entire network. A typical example is the automotive supply industry characterised by powerful OEMs. OEMs impose their supply chain practices and their own platforms on their suppliers.

Heterarchical networks consist of “equal” nodes. Each node has a position on the same “hierar-chical” level and possesses the same power and authority. No focal enterprise controls the network. Decision-making is distributed among partners. In contrast to hierarchies, where partners are usually only directly connected with their “children” and “parent”, the partners in heterarchies can connect directly to any other partner in the network. The self-organising Joint Ventures proposed by [Lorange/Probst 1987] are an example of a heterarchical network. Regarding business interoperability, heterarchical networks are characterised by “excess inertia” or “start-up-problems” which are typical for situations in which positive network externalities exist. The value of business interoperability for net-work’s members would increase with every new member joining. But too many standards and diverse technical solutions prevent potential members from taking the disproportionate risk of deciding for a specific implementation. Hypothesis 6: In hierarchical networks, a medium level of business interoperability (1:n relationships) will prevail, since the focal enterprise imposes its practices related to processes and information systems on the network.

Hypothesis 7: Due to “excess intertia”, heterarchical networks are characterised by low levels of business interoperability in the process and information systems categories. Typically 1:1 relationships prevail.

Network Governance 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Hierarchical networks

Heterarchical networks


Dominance of focal enterprise

excess-inertia / start up problems

Successful industry standardization / platforms

Figure 4-9: Network Governance and Level of Business Interoperability



4.3.1.5 Interdependence

[Kumar/Van Dissel 1996] suggest that inter-company relationships can be described by interdependence among the partners. They propose three types of interdependence: Pooled dependency. Partners share and use common resources but are otherwise independent (e.g. common data pool for customer data, market places, (m:n) hubs). Sequential dependency. Partners work in series; the output from one partner becomes the input to another partner (e.g. supplier-customer-relationship, order-to-pay process, sequential EDI connections). Reciprocal dependency. Partners work interactively; each partner receives input from and provides output to others (e.g. collaborative product design, CPFR).

Each type of interdependence demands a different coordination mechanism which influences the optimum level of interoperability. The more complex the interdependence type (pooled is least and reciprocal most complex) the more complex and indeterminate in nature the corresponding coordination mechanism becomes. As a result, the need for human intervention and contact increases.

Standardisation, which is the appropriate coordination form for pooled interdependence, “requires less frequent decisions and smaller volume of communication during a specific period of operations that does planning” [Kumar/Van Dissel 1996, 185]. Planning is the appropriate coordination mechanism for sequential interdependence and mutual adjustment for reciprocal interdependence, which obviously involves most communication activities. The interdependence among business partners also affects the type of inter-organisational system that should be used to support the relationship. It therefore affects the optimum interoperability level of the category information system. Pooled dependencies demand for pooled information resource IS (e.g. common databases, common communication networks, and common applications). Sequential dependencies require value/supply-chain IS (e.g. EDI-based transactions, transfer of CAD-based specifications). Reciprocal dependencies are supported by networked IS (e.g. e-mail, CSCW systems, discussion databases) (cf. [Kumar/Van Dissel 1996]). Hypothesis 8: Since standardisation is the appropriate coordination form for pooled interdependence, the optimum level of business interoperability with regard to business processes and information systems is high (level 4 - 5).

Hypothesis 9: Reciprocal interdependence is complex and therefore typically characterised by relatively low levels of interoperability in the process and information system category (level 1 - 3).

Interdependence 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Pooled dependency

Reciprocal dependency


Complexity of dependencies

Coordination by standardisation

Figure 4-10: Interdependence and Level of Business Interoperability

As each coordination mechanism demands different levels of human intervention it affects the optimum level of interoperability in the category employee & culture. [Kumar/Van Dissel 1996] identify possible conflicts inherent in the type of interdependence. They argue that the increased need for direct contact in planning and mutual adjustment increases the possibility for human misunderstanding and error. Partners in pooled interdependence do not necessarily need to directly interact with each other. Hence, the inherent risk of interpersonal conflicts is minimal and a low level of interoperability in trust and partnership management is optimal (level 1 to 2). Sequential partnerships need a higher level of interoperability in cultural criteria to avoid cultural and human conflicts (level 3 to 4). The high degree of direct interaction in reciprocal relationships requires the highest interoperability level (level 4 to 5) to avoid cultural misunderstandings: “the shear variety of reciprocal relationships would require the use of human agents and mechanisms such as trust to identify, assess, and manage the dynamically occurring risk in this situation.” [Kumar/Van Dissel 1996, 294]



Hypothesis 10: The higher the interdependence among cooperation partners, the higher the optimum level in category employee & culture.

4.3.1.6 Specificity & Frequency

Transaction Cost Theory distinguishes frequency, uncertainty and asset specificity as characteristics of commercial transactions (cf. [Williamson 1998]). These characteristics also impact the optimum level of business interoperability.

The frequency of transactions within a business relationship can be one-time, occasional and recurrent (cf. [Williamson 1979]). Asset specificity describes to what extent investments made for the business relationship are idiosyncratic. It relates to physical as well as to human assets and dedicated assets [Williamson 1998]. Investments can be classified as non-specific, mixed and idiosyncratic. To some extent, asset specificity describes the dependency between business partners, since more specific upfront investments result in higher dependency. This dependency can be unidirectional or bidirectional. Table 4-3 depicts illustrative examples of commercial transactions with certain asset specificity and frequency.

Investment Characteristics Non-specific Mixed Idiosyncratic

Occasional Purchasing standard equipment

Purchasing customized equipment

Constructing a plant Frequency

Recurrent Purchasing standard material

Purchasing customized material

Site-specific transfer of intermediate product across successive stages

Table 4-3. Transaction characteristics of commercial transactions (cf. [Williamson 1979])

Hypothesis 11: The optimum level of business interoperability is negatively correlated with asset specificity: Low specificity is associated with high levels of interoperability (level 3-5). Idiosyncratic investments imply 1:1 relationships and low levels of interoperability.

Hypothesis 12: In the case of low or occasional transaction frequency, business interoperability typically is low.

Specificity & Frequency 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Low asset specificity

High asset specificity

Low or occasional transaction frequency


Idiosyncratic investments

Figure 4-11: Specifity / Frequency and Level of Business Interoperability

4.3.2 External Contingencies

Every enterprise is part of a specific (industry) environment and its specific dynamics (cf. [Daft 2004]). Moreover, it is bound to legislation and regulations set up by authorities. These external factors highly influence an enterprise’s internal decisions and strategies, and have an impact on its interoperability. Few possibilities exist for organisations to change or influence its environmental conditions. [Daft 2004] names four techniques: Change of domain (e.g. by acquisitions or divestment), political activity and regulation (e.g. by lobbying), trade associations, and illegitimate activities (e.g. by illegal or unethical activities).



The Business Interoperability Framework considers the industry and general environment as external contingencies which are not changeable by the enterprise.

Criteria Sub-Criteria / Values

Legislation and Regulation Existence of national (including city, state, federal) and international legislation as well as industry-specific, national or international regulation and standards which impose interoperability on

Degree of Standardisation Syntax – semantics (messages, identification, classification, …) – Pragmatics (Process, business standards …)

E-business maturity Maturity of the industry, country and the size-band of the organisation with regards to e-business (low – moderate – high) Availability of platforms that provide m:n connectivity (e.g. SWIFT in the financial industry)

Table 4-4. External Contingencies

4.3.2.1 Legislation / Regulation

National and international legislation as well as industry-specific, national or international regulation and standards increasingly oblige companies to become more interoperable. As an example, a new regulation on food traceability, EC/178/2002, has been effective in the European Union since January 1st 2005. The regulation requests from any food operating business, at each echelon in the supply chain, to store information regarding the supplier as well as the buyer of a food product. This request for transparency has forced companies to connect their IT systems - a move that has eventually created higher needs of business interoperability. As another example, the United Nations Drug Control Program imposed the tracking of narcotics which has been transformed in national law and forced doctors, hospitals, pharmacies as well as the pharmaceutical industry to become interoperable. Hypothesis 13: Legislation / regulation may force enterprises to become more interoperable.

4.3.2.2 Standardisation

The availability of standards, such as the unique identification of products using the EAN.UCC identification number and bar code symbology, increases the interoperability between retailers and their suppliers. In order to fully specify an inter-organisational relationship for electronic integration, standardisation has to cover all aspects of semiotics, i.e. syntax, semantics (messages), semantics (master data) and pragmatics. The availability of widely used standards fosters business inter-operability. Hypothesis 14: With increasing levels of standardisation, the optimum level of business interoperability rises.

Hypothesis 15: However, an excess of standards and the existence of conflicting standards may hinder business interoperability.

Standardisation 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Increasing level of standardisation

Conflicting standards


Figure 4-12: Standardisation and Level of Business Interoperability

4.3.2.3 E-Business Maturity

Doing business in an e-business-mature industry will imply that certain prerequisites for electronic collaboration exist: Enterprises use ICT systems internally; they have built up the necessary communication infrastructure; and already have some experience with electronic integration. Under these circumstances, an inter-organisational relationship will more likely be based on (industry-specific) public processes (e.g. CPFR processes for supply chain activities) and business semantics (e.g. ChemXML in the chemical industry). Also, it will more likely involve automatic (machine-to-



machine) data exchange over the Internet. A company cooperating with such organisations hence requires a high level of interoperability regarding information systems and cooperation processes.

The E-Business Index from [e-Business Watch 2005] (see also Apendix B.1.1) provides an instrument to quantify e-business maturity. It deduces three different levels of e-business maturity (low, moderate and high) per industry, country and organisation’s size-band. A high level of e-business maturity within an industry implies that in these enterprises (cf.[e-Business Watch 2005]). a high percentage of employees has broadband access to the Internet and can virtually access their company using VPN and remote access; a high percentage of employees works with Enterprise Document Management (EDM) and Enterprise Resource Planning (ERP) systems; at least 5% of purchases are made online with special e-procurement systems; SCM systems and systems to manage inventory and capacity online are used; and at least 5% of sales are made online with special marketing and sales IT solutions.

Consequently, we assume that the contingency e-business maturity particularly impact the categories business processes and information systems. Hypothesis 16: E-business maturity positively impacts the optimum level of business interoperability, particularly regarding business processes, business semantics and interaction type.

The availability of electronic platforms or exchanges in a certain industry or country can be considered a sign of high e-business maturity. For example, the industry owned SWIFT platform supplies secure, standardised messaging services and interface software to nearly 8,000 banks, broker-dealers and investment managers worldwide. Hypothesis 17: The availability of electronic platforms increases business interoperability within a business network.

e-Business Maturity 5 (fully inter-operable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

E-Business maturity

Availability of electronic (industry) platforms


Categories: Business processes, business semantics, interaction type

Figure 4-13: e-Business Maturity and Level of Business Interoperability



5 Application of the Business Interoperability Framework

The following section demonstrates the application of the Business Interoperability Framework in three case studies. Section 5.2 assesses and compares the level of business interoperability for two types of OEM-supplier relationships. Section 5.3 analyses the supplier relationships of a large retailer. Depending on the availability of information as well as on the goals of the assessment, both sections focus on specific aspects of the BIF.

5.1 How to Apply the Business Interoperability Framework

We will take a three step approach in order to apply the Business Interoperability Framework and assess the business interoperability of a specific enterprise. First of all, we will describe the contingen-cies which impact the enterprise’s optimum level of business interoperability. In the second step, the actual assessment of the scenario, the level of business interoperability (from 1 “none” to 5 “fully interoperable”) is defined for every criterion and life-cycle perspective (cf. Figure 5-1). The base for this assessment is adequate data and information about the enterprise and its external relationships. Sources can be (structured) interviews, self-assessment based on questionnaires, or secondary data. Finally, the result needs to be interpreted. The interpretation depends on the objective of the assess-ment, which could be benchmarking with other organisations or industries, or identification of potential for improvement in the design of external relationships. For the comparison of two results, it is essential to consider that the contingencies influence the level of business interoperability. Criteria Definition Life

Cycle 5


(qualified)3

(moderate)2

(minimum)1

(none)Description

App

roac

h

Strategic importance of cooperations is embedded in company strategy, rigorous partner selection process, advanced process is in place

Importance of cooperations is addressed in company strategy, Partner selection process taking into account "hard factors", expandable process is defined

Cooperations are addressed in company strategy, some evaluation criteria for partner choice exist, process covers only parts of the cooperation live-cycle

Cooperations are established with known partners, "best practices" / cooperation knowledge / experience of individuals

Cooperations are not part of company strategy, partners are chosen ad hoc and with no pre-defined evalution criteria, no guidelines or processes exist

Dep

loy Process is rolled out to all

external relationships, cooperations are actively managed

Process is used in most partnerships

Process is used in some (new) partnerships

Individual "process" is setup with each partner

no / ad-hoc setup of electronic relationships

App

roac

h Cooperation targets are co-defined with partner built by consensus

All partners are involved in target setting

Targets are specified by one (dominant) partner

Targets are defined individually

No target setting

Dep

loy Targets are documented,

openly communicated and shared with all partners ("common purpose")

All partners communicate their targets; individual targets that are not communicated remain

Dominant partner communicates targets to partners, but may pursue other hidden aims

Partners pursue individual targets and do not communicate them to partners

Targets are unclear

Management of External Relationships - "How do we manage and control external relationships?"1: cooperation process of no relevance2: cooperations are of strategic importance and cooperation process is in place

Coo

pera

tion

targ

ets

Plans and objectives, that partners pursue in the cooperation, are defined and reconciled with partners before the cooperation starts

1: Each partner has individual targets, which are not communicated among partners2. Targets are identified by BMW and communicated to Magna


Coo

pera

tion

(man

agem

ent)

proc

ess Process for

initiation, realisation, control and monitoring of cooperations is in place

Assess-ment

CategoryLevel of Business

Interoperability

CriteriaCriteria

Life-cycle Perspective

Explanation for assessment

Figure 5-1. Structure and application of the BIF

To use their “Cross-Enterprise Collaboration Framework” [Bowersox et al. 2003] suggest a similar two step procedure. In a first step, management should identify and reach consensus on existing collaborative competency (which contains parts of the BIF). To this purpose, managers from various backgrounds and knowledge apply the framework individually and thereafter review responses jointly to reach an agreement. The second step is to benchmark the result against high-achieving firms in comparable industries. Benchmarking current capabilities against desirable capabilities identifies gaps. Gap identification helps managers to focus on committing resources to support change initiatives as well as blueprints for improvement in critical areas [Bowersox et al. 2003, 26f].

5.2 Application in the Automotive Industry

5.2.1 Situation in the Automotive Industry

Automakers have traditionally executed control over the entire value chain, including the develop-ment and production of parts and components, integration of modules and systems, as well as the as-sembly of the entire vehicle. Value creation in this industry took place within established supplier hierarchies: Original Equipment Manufacturers (OEMs) developed a concept of a new car with the major systems and modules. They assigned the production of components, modules, and systems to a large extent to suppliers, whereas the OEM assumed the responsibility for their integration as well as the assembly of the entire vehicle. Suppliers were involved in hierarchical relationships in the automo-tive supply chain, where OEMs acted as focal players.



In recent years, the established role model has changed (cf.[Dannenberg/Kleinhans 2004, Dodel 2004, Mercer Management Consulting 2004]): OEMs increasingly focus on branding and downstream activities. Engineering, production and assembly activities are relocated to automotive suppliers and service providers. Today, their share of total value creation is about 65%, which could increase to 77% over the next decade. Innovative business models include the outsourcing of the entire car production to so-called Tier-0.5 suppliers or “little OEMs”. The supplier industry consolidated. The base of suppliers shrank from about 30’000 suppliers in 1988 to 5’600 in 2000. In 2015 only half of them will probably exist.

Recent studies (e.g.[Mercer Management Consulting 2004, Vollrath/von der Eichen 2004]) assume an extreme decomposition of the automotive supply chain. The traditional roles will change, and firms will develop or acquire new core competences (cf. Table 5-1). For example, system integrators increasingly take over development, production, and integration of entire vehicles as Magna Steyr did for the BMW X3 (cf. [Maidl/Axtner 2004]). In addition, innovative business models may emerge and dramatically transform the future structure of the whole industry. Figure 5-2 depicts new roles and business models in the automotive value chain.

Vehicle brand owner

Vehicleintegrator

Engineeringserviceprovider

Technology specialist

Manufacturingspecialist

Customer

Figure 5-2. Emerging roles in the automotive value chain

Role / Business Model Core Competency Responsibility Vehicle brand owner

(OEMs)

Generation of product ideas and concepts (product innovation), Branding, marketing, sales & service

Entire vehicle

Vehicle integrator

(OEM, or “little OEMs”/Tier-0.5 suppliers)

Series development and production, integration of modules and systems into the vehicle, coordination of supplier network

Entire vehicle

Manufacturing specialist

(Tier-1 … n suppliers)

Development and production of standardised components (e.g. windshield wipers) and parts (e.g. door hinges)

Components or parts

Technology specialist

(Tier-1 …n suppliers)

Functional innovation of modules (e.g. wheel suspensions) and systems (e.g. chassis, steering systems), development and production

Functional systems, modules and specialised components

Engineering service provider Innovation, design and engineering of components, modules and systems

Table 5-1. Changing roles in the automotive value chain - core competencies and responsibilities

The resulting new forms of collaboration between OEMs and their suppliers require higher levels of process integration, from product design and engineering to supply chain management and quality management, from marketing and sales to after-sales service.

The automotive industry has a long tradition in value chain integration and is one of the most ad-vanced industries with respect to infrastructures and standards for electronic collaboration. The 2005 e-Business Survey reports one of the highest scores for the automotive industry related to the intensity of ICT use in industries (cf. [e-Business Watch 2005], Section B.1.1). Established standardisation or-



ganisations (e.g. VDA in Germany, ODETTE in Europe) exist that create a common understanding of the relevant public processes and the related business documents within the industry, such as supply chain processes, financial processes, and engineering. Besides traditional electronic channels like EDI, portals are commonly used. Table 5-2 summarises the external contingencies for the automotive industry.

Business Environment Description Automotive Industry

National (including city, state, federal) and applicable international laws and legislation

Legislation / Regulation

Existence of industry-specific, national or applicable international regulation and standards

EU and national law applicable, e.g. Directive 2000/53/EC of the European Parliament and of the Council of 18 September 2000 on end-of-life vehicles, guarantee law

Industry dynamics Industry sector

Industry size and competitiveness Related industries

Actors

Industry structure (power distribution within industry)

Automotive

Large, highly competitive

OEMs, tier-1 … n supplier, vehicle integrator, system integrators, module manufacturers, …

Power is with OEM, increasing influence of tier-1 suppliers, supplier concentration, oligopoly (tier-1),

Existence of commonly accepted public processes

Highly standardised for supply chain processes, e.g. VDA recommendations, ODETTE;

Level of standardisation

Availability of (industry) standards and their maturity with regard to defining semantics of the specific domain

VDA recommandations, ODETTE (EDIFACT subset), ENGDAT messages

Sociocultural aspects Degree to which electronic communication and partnerships are tolerated or postulated by partners and organisations

High

Degree of e-business maturity of the industry sector, country and company size-band

high (Automotive)

high (Germany, Austria)

high (>250 employees) Dominant interaction type in the industry 1:n (Portals) or 1:1 (EDI)

E-business maturity

Availability of communication infrastructure, platforms that enable connectivity

EDI via VPN, (exchanges, e.g. SupplyOn)

Table 5-2. External Contingencies

5.2.2 Business Relationships in the Automotive Value Chain – Two Cases

In this Section we look at two examples of business relationships in the automotive industry. The first example represents a traditional OEM-1st tier supplier-relationship, whereas the second case describes an emerging partnership between OEM and a so-called vehicle integrator (“little” OEM or tier-0.5 supplier). A comparison and description of the cases can be found in Table 5-3.

Case 1: The business relationship between WAFA and BMW dates back to the 1960s. WAFA is one of the world’s leading suppliers in the fields of plastic injection moulding and surface finishing of decorative components, such as automotive exterior like front grilles, wheel covers and hub caps and around 100 times smaller than its customer BMW (cf.[WAFA]). We analysed a typical supply chain scenario, the order process, as seen from WAFA’s viewpoint. The cooperation scenario itself, common and traditional in the automotive industry, has not been changed since several years (described as “electronic control” relationship already in 1995 by [Bensaou/Venkatraman 1995]). Prior to ordering, BMW and WAFA sign master agreements that regulate the basic conditions for orders, products and deliveries for a fixed period (usually one year). On a regular base, BMW than submit its concrete orders via EDI to WAFA. The orders automatically enter WAFA’s PPS system.

Case 2 (cf. [Maidl/Axtner 2004, Maidl et al. 2005]): Case 2 exemplifies the emerging collaboration forms in the automotive industry. In 2001, BMW decided to outsource the complete serial development and production of its sport utility vehicle (SUV) X3 to Magna Steyr. Magna Steyr, ten times smaller than BMW, aims at being the leading global, brand-independent engineering and manufacturing partner to OEMs in engineering and assembly of complete vehicles, development and manufacture of



components and systems (cf. [Magna Steyr 2006]). Design, purchasing, testing, sales and service remained with BMW. The main reason for BMW was missing resources for developing and producing this new car. For this case, we analysed the whole cooperation, starting with the development of the car, from BMW’s viewpoint.

Internal contingencies Case 1 (WAFA/BMW) Case 2 (BMW/Magna Steyr) Cooperation area

Coordination targets

Procurement of automotive exterior

Supply of parts

Contract manufacturing (serial development & production of an entire vehicle)

Enter a new business segment (SUVs)

Accessing additional know-how and competencies for SUVs

Cooperation partners WAFA Kunststofftechnik GmbH, based in Augsburg, Germany (1st tier supplier) and BMW, based in Munich, Germany (OEM)

BMW, based in Munich, Germany (OEM) and Magna Steyr AG & Co KG, based in Graz, Austria (vehicle integrator)

Cooperation dynamics Stable Stable, but limited for a certain time period (years) Network governance Hierarchic Hierarchic Interdependence Sequential Reciprocal Specificity Low High Frequency High High

Table 5-3. Comparison of internal contingencies of case 1 and 2 (based on [Maidl/Axtner 2004, Maidl et al. 2005] for case 2)

5.2.3 Analysis of Business Interoperability

The application of the two cases to the BIF reveals different levels of business interoperability. We will show that the different levels result from different cooperation models, and that more innovative forms of collaboration differ from traditional relationships in terms of business interoperability. To this purpose, we assume that the cases are representative for their cooperation model and their level of business interoperability reflects typical requirements. But, neither the first nor the second case has a higher or better level of business interoperability. Although similar external contingencies apply to the cases (as described in 5.2.1), internal contingencies – due to the different coordination targets – are quite different (Table 5-3).

Case 1 (WAFA/BMW) Case 2 (BMW/Magna Steyr) Case 1&2

Figure 5-3 depicts the assessment of the two cases. With regard to the management of external relationships, new forms of collaboration proof to be more demanding than traditional OEM-supplier relationships. WAFA purely reacts on collaboration opportunities with no alignment of cooperation targets and no clear escalation procedures. When entering a strategic partnership with Magna Steyr, BMW actively manages the cooperation, communicates cooperation targets and makes provisions for risk and conflict management.

WAFA and BMW base their collaboration on state-of-the-art B2B processes using EDI standards which are also subject of VDA recommendations. These results correspond with findings of [Bensaou/Venkatraman 1995] about the great use of ICT functionality when “the technology is more reliable and offers stable standards” as for example in supply chain functions. The more extensive collaboration scenario between BMW and Magna Steyr required the definition of cross-organisational processes, starting as early as in the series development and continuing to after-sales service. The alignment of business processes and the resulting integration of information systems were time-consuming and costly, since both partners entered this specific cooperation model for the first time. The medium to high business interoperability levels for case 2 result from heavy investments made by BMW and Magna Steyr in the collaboration infrastructure (e.g. 50 roll-outs of BMW systems to Magna, more than 280 IT projects). BMW took over additional effort in order to anticipate future requirements of similar cooperation models.



Category Life-Cycle 5 (fully interoperable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

Description






Deploy Applied in all partnerships Applied in most partnerships Applied in all strategic partnerships (focussing on "A partners")


Not (yet) applied








Not (yet) applied








Not (yet) applied








Not (yet) applied

Approach Business vocabulary of reference is defined; it is built by consensus and reflects multilateral agreements, industry or domain standards (m:n)



Proprietary business vocabulary of one of the partners is imposed




Not (yet) applied








Not (yet) applied


Bus

ines

s se

man

tics

(info

rmat

ion

cont

ext)

Publ

ic P

roce

ssC

oope

ratio

n m

odel

Coo

pera

tion

man

agem

ent

(pro

cess

es)

Coo

pera

tion

targ

ets


1: EDI messages as defined by VDA or ODETTE recommendations2: Mainly proprietary formats from BMW

1: Standard logistics process applied with all partners (based on VDA or ODETTE recommendations)2: Defined on a 1:1 base,but taking into account future cooperations

1: Information context (e.g. product data,) provided from BMW2: Information context (e.g. product data,) provided from BMW

Bus

ines

s se

man

tics

(bus

ines

s do

cum

ents

)

1: no defined collaboration models, reaction to collaboration opportunities2: cooperations are of strategic importance

1: Each partner has individual targets, which are not communicated among partners2: Targets are identified by BMW and communicated to Magna

1: cooperation process of no relevance; conflicts were solved when they arise2: cooperation process is in place; some mechanisms for preventing conflicts have been made



Figure 5-3. Level of Business Interoperability for Case 1 and 2




4 (qualified)

3 (moderate)

2 (minimum)

1 (none)

DescriptionLevel of Business Interoperability

Approach Pro-active information

sharing and full accessibility of relevant information for external partners







Not (yet) applied

Approach Advanced machine-to-machine interaction

Minimum machine-to-machine interaction by simple file exchange of machine-readable documents






Not (yet) applied








Not (yet) applied

1: EDI 1:1 connections with all OEMs2: Point-to-point interfaces were built to link BMW's systems to Magna

1: EDI used with all OEMs2: Necessary IT landscape was closely intgrated between two partners

Inte

ract

ion

type

Con

nect

ivity

/ C

olla

bora

tion

plat

form



1: No information is shared2: Information is shared openly with partner

Visi

bilit

y


Figure 5-4. Level of Business Interoperability for Case 1 and 2 (Cont.)

The level of business interoperability for the two cooperation models represents the “organisational design” of the relationship with regard to several dimensions (“hard” dimensions such as ICT infrastructure or process design; “soft” dimensions e.g. in cooperation management processes or visibility). We assume that both companies chose the organisational design that best fits their respective internal and external contingencies in order to maximise value creation. Since for both cases, similar external contingencies apply which reflect industry structure and dynamics, the different business interoperability profiles can be explained by the two different coordination areas and targets, which represent an internal contingency. For the “traditional” OEM-supplier relationship higher inter-operability levels with regard to public processes, semantics for business documents and cooperation architecture were deduced. This reflects the maturity of B2B collaboration in the automotive sector. The “innovative” cooperation is more demanding in terms of cooperation management and social integration. As a result, the level of interoperability with regard to cooperation processes and targets, and visibility are higher in these areas. Similar interoperability levels were deduced for the interaction type which is machine-to-machine in both cases. In the case of the Magna cooperation, however, the cooperation architecture was 1:1 since many custom interfaces had to be built in order to couple BMW’s with Magna Steyr’s information systems.

5.2.4 Conclusions

New forms of collaboration in the automotive industry demand integration of the involved business partners. The extensive need for coordination of inter-organisational business processes results in new requirements regarding business interoperability. Great demands are not only made on ICT systems (e.g. network infrastructure, data semantics, message standards, system interfaces) but also on organisational, business process and cultural issues. For example, as seen in the BMW/Magna Steyr case, the outsourcing of the entire X3 series development and production results in extensive project work defining the cross-organisational business process flow and implementing the links between information systems. In addition, these new forms of cooperation need to be actively managed, e.g. through a deployed cooperation process and actions taken for risk and conflict management.

A strategic decision in favour of a tight coupling to a business partner and the existence of a technical integration infrastructure does not automatically enable a smooth collaboration with external partners. Application of the Business Interoperability Framework to the automotive industry has resulted in different profiles of business interoperability for typical collaboration models.



5.3 Retail industry

5.3.1 Background

Competition among European retailers is strong today. Consumers not only demand for low prices but also for high quality services and products [Euromonitor 2005]. At the same time, a number of inefficiencies in the retail supply chain still prevail, such as incorrect ordering and deliveries, low levels of shelf availability, and inventory inaccuracies. A promising concept for coping with these problems is “Efficient Consumer Response (ECR)”. ECR denotes a strategy of close cooperation between the retailers and their business partners in order to eliminate costs while improving customer value [Reyes 2005]. As a consequence, both parties need to develop organisational and operational abilities to seamlessly integrate their business activities. In this context, the key question to be answered is which level of interoperability is necessary to establish a certain form of cooperation. It is against this background that we investigate the example of Metro Group in order to make statements on the need for interoperability in the retail supply chain.

We apply BIF to the cooperation between Metro Group and its suppliers with a particular focus on Metro’s custom-made supplier portal “Metro Link”. By these means, we aim at analysing and discus-sing the necessities for different levels of interoperability with regard to corporate strategy, business processes, and information systems. The primary data source of our research is publicly available information about Metro's supplier portal Metro Link [Metro Group 2006a]. Furthermore, we conducted interviews with Metro Group executives using questionnaires in order to collect additional data and to validate the information gathered by desk research.

5.3.2 Situation in the European Retail Industry

European retail markets only grew slightly in recent years. The volume of retail trade grew by 1.1% from June 2004 to June 2005 in the Euro-zone and by 1.5% in the EU25 [Eurostat 2005]. At the same time, competition among retailers increased disproportionately. Particularly, discounters steadily increased their market share from 9.4% in 1991 to 16.0% in 2004 [AC Nielsen 2005].

When looking at the growth of the private label market compared to its brand manufacturer counterparts, private labels showed stronger growth and outpaced manufacturer branded products. In 2003 the market share amounted to 22% with a growth rate of 6% compared to the previous year. Furthermore, private brands were priced on average 31% lower than their manufacturer counterparts. The power of private brands is expected to continue to grow [AC Nielsen 2003].

From 1995 to 2001, consumer spending increased in all countries of the European Union (EU25). In particular, a higher percentage was spent for culture but less for food and non-alcoholic beverages, i.e. about 20% in 1995 vs. about 17% in 2001 [Lienhardt 2006].

Although many retail markets are highly mature and intensively competitive, the high levels of purchasing power within such markets remain attractive to retailers [Euromonitor 2005].

5.3.2.1 Collaboration in the Retail Industry

The intensive price cutting strategies of major retailers have consolidated low price expectations in the minds of the end customers and have changed their perceptions of value [Euromonitor 2005]. As a consequence, retailers need to offer both low prices and high quality products and services. A promising concept for coping with this problem is ECR as it focuses on both the end customer and efficient processes.

ECR is a strategy in which the retailers and their business partners work closely together with the objective of eliminating costs while improving customer value [Reyes 2005]. Whereas the focus of the supply side concepts (i.e. cooperative logistics) is set on streamlining the supply chain by improving procurement and distribution, the demand side concepts (i.e. cooperative marketing) yield at increasing turnover and improving customer service by selective pricing, product, campaign, and placing policies. The core activities of ECR include efficient assortment, efficient promotion, efficient product introduction, efficient replenishment, and category management [Reyes 2005]. Category management comprises a major shift from the traditional brand management approach to the product category management approach [Dussart 1998]. The underlying assumption is that a decision about one brand has an impact on the other products in a category. Thus, the basic business



decisions have to be taken on the level of the product category as opposed to the brand or product line. Efficient store assortment focuses on the optimization of store space and productivity of inventory [Svensson 2002]. Optimal allocation of goods maximises consumer satisfaction by providing the best products and services while ensuring the most efficient use of available space. Efficient product introduction focuses on the development and introduction of new products with the objective to minimise costs and failure rates. This is achieved by involving all partners of the supply chain early on in the life of a new product [Kurt Salmon Associates 1993]. Efficient promotion focuses on the maximisation of the system efficiency of trade and consumer promotion and yields at eliminating inefficient promotions [Svensson 2002]. The focus of efficient replenishment is on ensuring the most effective flow of products to the retailer's shelves. In order to achieve this goal supply chains are being reengineered to exploit the advancements in information technology. The strength of this approach is that by the automatic replenishment system the retailer has the opportunity to maintain minimal stock levels without jeopardising service levels [Aviv 2001]. Efficient replenishment is based on consumer demand pull which is monitored through point of sale (POS) data which prompts the replenishment ordering and delivery cycle. The overall objective is to optimise time and cost by insuring that the right product is delivered to the right place, at the right time, in the right quantity and at the most efficient manner possible [Kurt Salmon Associates 1993]. While this concept could create increased ordering and transportation costs, the decreased holding costs and an improved customer service off-sets the increased costs.

Enabling standards of the ECR concept such as EDI facilitate interaction among supply chain partners to coordinate activities and enable companies to achieve seamless integration. By means of EDI communication business documents such as invoices or bills are exchanged electronically in a structured format.

ECR stresses the vertical integration of the marketing channels. In the past, manufacturers, suppliers, wholesalers, and retailers have concentrated on their own business activities. They have not focused on a common vision for their marketing and logistics processes. As a consequence, this led to low efficiency leading to low profitability. According to this background, ECR stresses the need to provide a holistic view of the supply chain.

According to [Hofstetter/Jones 2005], the highest adoption levels of the ECR demand side concepts in Europe are found in France, Germany, and Greece, the lowest level in Switzerland. Among the demand side element "Efficient Planning" is the most adopted, followed by "Category Management". The lowest adoption levels are reported for "Efficient Product Introduction" and "Efficient Promotion". Whereas the two leading countries in the adoption of the supply side concepts are Germany and France, Italy reports the lowest level. The analysis of the adoption of ECR enablers reveals that the standardisation activities have achieved considerable momentum. The highest adoption levels are found in Germany, France, and the UK, the lowest in Greece.

In their attempt to adopt ECR, companies face various different barriers. Correctly addressing and overcoming these barriers is vital for sustainable and successful ECR adoption. Among others, following issues are to be considered [Hofstetter/Jones 2005]: There are substantial differences in the understanding of the term ECR. Some ECR concepts are perceived as being overly complex. Top management commitment to collaborative business practices is necessary. The level of trust between retailer and manufacturer is often insufficient. Companies hardly monitor ECR-adoption in daily operation and they do not actively manage the adoption. Companies lack the specific organizational and technological capabilities required to benefit from ECR and are reluctant to invest in those capabilities. Companies do not integrate ECR thinking into their business strategy.

5.3.2.2 External Contingencies in the Retail Industry

The external contingencies for ECR processes in the retail industry are summarised in Table 5-4. In recent years, retailers and manufacturers have focused primarily on efficient replenishment. This led to standards and recommendations for the design of the supply processes. In this analysis we will primarily focus on efficient replenishment for the simple reason that this is the most mature process within the ECR initiative.



Commonly accepted public processes exist in the retail industry, e.g. for vendor managed inven-tory, master data exchange via SINFOS or e-procurement via Agentrics. SINFOS operates the leading European product data pool. Moreover, the master data pool supports internationally standardised contents, process rules and functions. Agentrics is a B2B internet marketplace for the consumer goods industry. Started in 2005, it provides Internet-based solutions with the objective to optimise and to simplify shared business processes to serve the consumer more effectively. The solutions include a bidding platform to procure goods and services.

Standards play a significant role for defining business semantics. The European Article Number Communication (EANCOM) is the most frequently used standard in the consumer goods industry. The standard for Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT) ensures that each information segment in an EDI message is in a specified position. For almost all transactions in a retail company’s process chain there is a corresponding EANCOM message standard such as ORDERS for orders, DESADV for announcement of deliveries and INVOIC for invoices. More than 40 internationally applicable EANCOM message types exist, which represent the business processes between retailers and manufacturers [Metro Group 2006b]. Furthermore, the Global Data Synchronization Network (GDSN) provides standards for partner and product identification, product classification, as well as product description [GS1 2004].

Coordination Area Description Retail industry

Pragmatics: Existence of commonly accepted public processes

Recommendations and standards, e.g. for Vendor Managed Inventory, Cross Docking (as part of the ECR initiative)

Level of standardisation

Semantics: Availability of industry standards and their maturity with regard to established semantics within the domain

Message standards: GS1, EANCOM, EDIFACT, EDI

Product identification: EAN

Product description: GS1 data model for product data

Product classification: GPC Degree of ebusiness maturity of the industry sector, country and company size

Moderate

High (Germany)

High (big companies) Dominant interaction type: The dominant interaction type which depends on the availability of platforms

1:n (portal)

1:1 (EDI)

Ebusiness maturity

Availability of communication infrastructure, platforms that enable connectivity

EDI Classic

Web-EDI

EDI trade portals

Table 5-4: External contingencies in the retail industry

The degree to which electronic communication and partnerships are tolerated or postulated by partners and organisations in the retail industry is high. New communication technologies play a significant role within the ECR concept not only for streamlining processes but also for strategic issues. According to this background, more and more enterprises invest in electronic cooperation.

The dominant interaction types in the retail industry are portals and EDI. Most retailers and big suppliers have already implemented EDI for orders and bills. However, most smaller and medium size manufacturers have not yet leveraged EDI. Retailers try to overcome this situation by offering different technical infrastructures such as Web-EDI and EDI trade portals which are less cost incentive for the manufacturer and improve the retailer's efficiency [Thonemann et al. 2003, p. 118].

According to [e-Business Watch 2005] the retail industry has a moderate e-business maturity. Whereas Germany, Spain, and the UK have the highest level of e-business maturity, the Czech Republic, France, Italy, and Poland have the lowest level. On the enterprise level we find that medium and large enterprises have a high e-business maturity, whereas small and micro firms have a low maturity.



Within ECR activities, retailers rely on a close cooperation with their suppliers and hence need to develop organisational and operational abilities to seamlessly integrate their business partners in respect to strategy, processes, and information systems. As a consequence, the importance of addressing interoperability issues within the supplier-retailer cooperation becomes evident.

5.3.2.3 Metro Group

Metro Group was founded in 1996 through the merger of leading retailing companies. Metro AG operates at the top as the strategic management holding company. The operative business is divided into the segments wholesale, food retail, non-food specialty stores and department stores. The company consists of high-performance, operationally independent businesses and includes Metro Cash & Carry sales brand, the international market leader in self-service wholesaling, the hypermarket operator Real, the supermarket chain Extra, Europe’s leading consumer electronics sales brands Media Markt and Saturn as well as Galeria Kaufhof, the system leader in the department store business. Additionally, cross-divisional service companies are responsible for a number of services in such areas as procurement, logistics, information technology, and marketing [Metro Group 2006a].

A number of innovative software applications within the scope of ECR have been developed by Metro with the objective of intensifying and improving the cooperation with suppliers. Examples of these applications are data warehouse and master data tools as well as various ECR instruments. Metro Link is a supplier portal which pools these applications to create one source and makes it easier for the business partners to regularly work with collaborative applications and contribute towards optimizing cooperation in day-to-day business. Suppliers have a single sign-on and can access all applications and information which they are authorised to use. Today, only few suppliers access and use Metro Link. However, Metro's long-term objective is to connect all business partners [Metro Group 2006b].

5.3.3 Assessing Business Interoperability of Metro Group

In this section, we determine the level of interoperability for the categories (a) management of external relationships, (b) collaborative business processes, and (c) information systems. We do not consider the category culture and employee in detail since the available empirical evidence on this category is too limited to allow for a valid assessment. For each category, we present a number of criteria and their actual values that help us to determine the respective interoperability levels. The assessment is based on public information provided by Metro supplemented by interviews and questionnaires.

5.3.3.1 Management of Business Relationships

The criterion cooperation model characterises to which extent the target partners and the form of cooperation have been defined. The level of interoperability is moderate for all three stages: The importance of cooperation is recognised by Metro Group, but is not embedded in the company's strategy. Cooperation contracts are based on both standard parts such as technical issues related to EDI and cooperation specific parts such as service level agreements. The contracts not only include technical but also economical issues such as penalties. With regard to deployment, ECR projects have been established with some big suppliers, but not with small and medium sized companies.

The criterion cooperation targets covers the definition, reconciliation, and monitoring of the cooperation's objectives. The level of interoperability is qualified for approach and review, and fully interoperable for the deployment: Whereas the overall targets – streamlining the supply chain and creating value for the customer – are set by both partners, Metro Group defines the key performance indicators (KPIs) and their values. Metro Group communicates these KPIs to all suppliers. However, not all information is shared. Two types of scorecards are being used: An internal one and an external one. The success of the cooperation is evaluated using scorecards which assess the performance and reliability of suppliers. However, resulting figures are not used for the adaptation of the management process. Metro Group reviews the KPIs and adjusts their values if necessary.

The criterion cooperation management (process) describes the process of initiation, realisation, control, and monitoring of the cooperation. In our case, the level of interoperability is qualified for the



approach, which is deployed in all partnerships (level 5) and only occasionally reviewed (moderate): Cooperation processes include a three step approach when integrating a partner via electronic data interchange (EDI) and the involvement of third parties such as SINFOS (i.e. a public master data portal). Metro Group is aware of involved risks and conflicts of the cooperation. The mechanisms are well established and not subject to continuous change.


4 (qualified)

3 (moderate)

2 (minimum)

1 (none)








Not (yet) applied

Assess & Review





No review








Not (yet) applied

Assess & Review





No review








Not (yet) applied

Assess & Review





No review


Coo

pera

tion

man

agem

ent

(pro

cess

es)

Coo

pera

tion

targ

ets


Coo

pera

tion

mod

el

Figure 5-5: Management of External Relationships (Metro)

5.3.3.2 Collaborative Business Processes

The public process is the business process which describes the sequence of IT-supported activities between two or more independent cooperation partners. The level of interoperability is qualified for the approach and deployment, but minimum for the review: A limited number of public process variants are defined, such as the type of master data exchange or the type of EDI integration (Classic EDI, Web EDI, Tradeportal). The variant to be implemented is chosen on a case by case basis by Metro together with the supplier. Metro Group adapts its public processes irregularly in order to include new requirements.

The business semantics of documents defines the content and structure of exchanged documents including the meaning of their elements. The level of interoperability is fully interoperable for the approach, qualified for the deployment and moderate for the review:



Metro Group plans to standardise all exchanged business documents. However, today the company relies on both standard messages and bilateral agreements about the structure and meaning of business documents. Gradually, Metro Group extends the electronic exchange of business documents via EDI.

The business semantics of master data define the content and structure of master data. The level of interoperability is fully interoperable for the approach, varies from fully interoperable to moderate for the deployment and is moderate for the review: Metro Group plans to exchange master data using the master data portal SINFOS. However, today data reaches the company not only through the portal but also via email and fax. Metro Group’s objective is to gradually optimise the flow and quality of incoming master data.


4 (qualified)

3 (moderate)

2 (minimum)

1 (none)









Not (yet) applied

Review & Assess













Not (yet) applied

Review & Assess





None








Not (yet) applied

Review & Assess





None

Bus

ines

s se

man

tics

(bus

ines

s do

cum

ents

)


Bus

ines

s se

man

tics

(info

rmat

ion

cont

ext)

Publ

ic P

roce

ss

Figure 5-6: Collaborative Business Processes (Metro)



5.3.3.3 Employees & Culture

Visibility describes the transparency of business processes to external partners which includes information such as availability of products and inventory. The level of interoperability is qualified for approach and deployment, and moderate for review: KPIs and other relevant information such as sales data or stock levels are defined and reported to the supplier. Today, over 60 reports are available which are divided into the topics sale, advertising, inventory, and master data. Metro Group gradually expands the volume of exchanged data such as forecasts and orders.


4 (qualified)

3 (moderate)

2 (minimum)

1 (none)


Approach Pro-active information

sharing and full accessibility of relevant information for external partners







Not (yet) applied

Review & Assess





No review


Visi

bilit

y

Figure 5-7: Employees & Culture (Metro)

5.3.3.4 Information systems

The interaction type describes the kind of electronic cooperation (human-to-human, human-to-machine, machine-to-machine). The level of interoperability is fully interoperable for the approach and review but qualified for the deployment: Metro Group aims at establishing machine-to-machine interaction for all relevant processes. Today, machine-to-machine cooperation is implemented only for selected relationships if economically and technically feasible.

The cooperation architecture supports the relationship and describes the type of connection (one-to-one, many-to-many, one-to-many). The level of interoperability is qualified for the approach, varies from qualified to moderate for the deployment and is moderate for the review: Metro Group aims at establishing one-to-many connections for the exchange of EDI messages and master data. This can be achieved by using standard EDI and third party providers such as SINFOS. Today, only big suppliers use EDI and SINFOS but not small and medium sized companies. As Metro Group's cooperation architecture is well established, modifications are implemented only on fundamental changes in the information technology or cooperation.

Security and privacy addresses the secure transmission of data and execution of transactions over the Internet. The level of interoperability is qualified for the approach, varies from qualified to moderate for the deployment and is moderate for the review: Security aspects are covered in Metro Group’s architecture such as the use of electronic signatures and value added networks. Moreover, mechanisms exist that ensure that information can only be accessed by those authorised. Security issues represent state-of-the-art solutions and are continuously reviewed and improved.




4 (qualified)

3 (moderate)

2 (minimum)

1 (none)









Not (yet) applied

Review & Assess





No review








Not (yet) applied

Review & Assess





No review








Not (yet) applied

Review & Assess





No review


Con

nect

ivity

/ C

olla

bora

tion

plat

form

Secu

rity

& P

rivac

yIn

tera

ctio

n ty

pe

Figure 5-8: Information Systems (Metro)

5.3.3.5 Discussion

When looking at our assessment summarised in Table 1, some particularities can be identified which lead to the following questions:

a) Why does being fully interoperable not always seem to be the optimum level from Metro Group’s perspective? Being fully interoperable means a company is able to establish new IT-supported business relationships at low or no costs. However, the higher the level of interoperability the higher the required investments for all involved parties. According to this background, the optimum level is the level where these accumulated investments outbalance the benefits. For instance, the fact that ECR projects are rolled out only to big suppliers (i.e. moderate level for the cooperation process) is primarily due to the high costs involved which makes this solution not feasible for small and medium sized companies.

b) What is the reason for ambiguity of interoperability levels within the deployment? Our assess-ment shows ambiguous results for the deployment in the case of the cooperation architecture and the semantics of data. This observation can be explained by the suppliers’ different financial and technical capabilities. For instance, in contrast to small and medium sized suppliers, big suppliers are able to finance and implement EDI and to integrate a master data portal into their processes. Thus, as Metro Group relies on a pool of different suppliers, the company must provide different modes of electronic



cooperation which is reflected in a heterogeneous architecture and different levels of interoperability.

5.3.4 Summary and Conclusion

It is the aim of this section to provide an analysis of interoperability issues in the retail industry. Against the background of the case example of Metro Group, we have applied the BIF to the cooperation between a retailer and its suppliers. In a second step, we have discussed the causes and motives for the resulting interoperability ratings. The following managerial implications can be drawn from our analysis: Being fully interoperable is not always the optimal choice. This is primarily due to high costs compared to potential benefits of providing an extensive degree of interoperability. Areas for improvement can be identified in cases where the interoperability approach is rated higher than the actual deployment. Moreover, special attention has to be given to categories with high levels for all stages within the life cycle. Having ambiguous interoperability ratings within the deployment is caused by the different financial and technical capabilities of a retailer’s suppliers. As Metro’s strategy as a classical channel retailer, for example, depends heavily on a large pool of different suppliers, the variance of interoperability can only be reduced if the suppliers themselves improve their capabilities.

Based on our investigations, we see potential for further research in various directions. Reference models need to be developed for different industries that allow for the benchmarking of existing applications. Finally, besides identifying areas of improvement, methodologies and specific techniques will be required which support practitioners in the adjustment of their company’s level of interoperability.



6 Interoperability Guidelines

In order to address business interoperability issues, the emerging field of interoperability research has come up with a vast number of concepts and technical solutions. Among them are model-driven design of cross-organisational integration, ontology building and semantic reconciliation. However, until today, those technical interoperability solutions are not yet sufficiently linked to the business problems they address. Based on the Business Interoperability Framework, the following section aims at systemising typical interoperability issues from a business perspective (described by Business Interoperability Profiles, BIP), and relating them to the appropriate interoperability solutions which may solve these issues.

6.1 Technical Interoperability Solutions

Recent research and technology development has led to a number of new technical solutions addressing interoperability problems. Major interoperability research streams come from enterprise modelling (c.f. ATHENA deliverables from project A1) and model-driven development [OMG 2003], semantic technologies such as ontology management systems or semantic reconciliation (c.f. ATHENA deliverables from project A3), service-oriented architectures (c.f. ATHENA deliverables from project A5) and a semi-automated support for modelling and executing cross-organisational business processes (c.f. ATHENA deliverables from A2). These research streams address different aspects of interoperability and consequently can be distinguished according to the artefacts they are focussing on: business processes, services, information / data, and other aspects such as security, service-level agreements and contract handling.

ATHENA has produced new concepts and technical solutions for solving interoperability issues related to these artefacts: Recent approaches to cross-organisational business process definition and implementation separate public and private views of the business processes spanning multiple organisations. Service-oriented solutions suggest the realisation of a service-oriented architecture combined with the use of Web Services as the technical basis for integrating heterogeneous software application. In the area of information/data concepts such as semantic reconciliation address aspects related to modelling and detailed specification of information that is exchanged between collaborating organisations. For the other aspects technical solutions come for instance from projects in the security and trust area or from research on virtual organisations (c.f. TrustCom project, www.eu-trustcom.com).

Orthogonal to these artefacts, model-driven development [OMG 2003] suggests that the building of an interoperability solution can be organised around a set of models, ranging from the overall enterprise perspective to the execution or code level. A formal underpinning for describing models in a set of meta-models facilitates meaningful integration and transformation among models, and is the basis for automation through tools: Business Level (Computational Independent Model, CIM): This level represents the business view on a business relationship, reflecting strategic decisions on the competitive positioning of an enterprise as well as the organizational and process design. Technical Level (Platform Independent Model, PIM): To achieve an executable interoperability solution, the business level models first have to be transformed into platform-independent models. Optimally, business level models are transformed into technical level models and enriched with more detailed information. However, the models on this level still abstract from the implementation platform. Execution Level (Platform Specific Model, PSM): With the second transformation the technical level models are transformed to platform-specific execution level models. Platform-specific models are indispensable for the actual implementation of a system. These models are executed and make the interoperability solutions work.



6.2 Deriving Business Interoperability Profiles (BIP)

6.2.1 Method of Work

In order to accomplish a business-oriented approach towards the implementation of technical interoperability solutions, we identify typical, recurring Business Interoperability Issues and systemise them into a set of Business Interoperability Profiles (cf. Figure 6-1, Step 2). This is based on various case studies that were conducted within and outside the ATHENA project (Step 1) which are docu-mented in the ATHENA Impact Assessment (D.B3.4). At this stage we have identified seven Business Interoperability Profiles which we believe to cover a fairly large portion of issues. This grouping of Inter-operability Issues leads us to the identification of a dedicated technical approach that is required to im-plement the desired level of business interoperability (Step 3). By knowing what needs to be done on a technical level, we can now determine general technical Interoperability Solutions that are applicable (Step 4).

Figure 6-1. Method of Work

All Business Interoperability Profiles and the related Interoperability Issues are explained in more detail in the next Section. For each profile we first describe the internal and external contingencies (cf. Figure 6-2, column 3-4) before detailing the Interoperability Issues related to Management of External Relationships, Employee and Culture, Collaborative Business Processes and Information Systems (column 5-8). The textual descriptions are complemented by colours that depict the levels of business interoperability for each profile (cf. Section 6.2.2). The arrows provide an indication of possible improvements of interoperability levels when implementing the proposed solution. Column 9 (cf. Figure 6-3, “Approach”) explains the design and implementation approach that is required to solve the related Interoperability Issues. The next columns then list the applicable interoperability solutions, the modelling levels involved and the artefacts to be considered. The classification of solutions into the above defined artefacts and modelling levels, help us to specify more precisely which interoperability solutions have to be implemented and which type of models have to be generated during design and development.

6.2.2 Business Interoperability Profiles - Description

In the following, we provide a detailed description of each Business Interoperability Profile (BIP). These profiles represent clusters of typical business interoperability issues and the associated solutions. Figure 6-2 and Figure 6-3 provides the consolidated overview of all BIP.



No

Business Interoper-

ability Profile (BIP)

Cooperation Model (Internal

Contingency)

External Contingencies

Definition of business semantics

Cooperation scenario and targets defined, high cooperation specificity

Low e-business maturity, usually fragmented industries

Design of public process

Basic level of trust between partners



not relevant, usually human-to-human interaction

Connectivity: not relevant, usually 1:1 relationships

Proprietery business semantics

Public process: No awareness of collaborative business processes

Low e-business maturity, usually fragmented industries

Cooperation is managed, cooperation targets are defined individually by partners

Not relevant, usually human-to-human interaction

Human-to-machine interaction, process integration


Connectivity: 1:1 or 1:n relationships

not relevant, usually human-to-human interaction

Low awareness of external partners

Information Systems

Human-to-human interaction

Cooperation model not defined

Collaborative Business Process

Public process: No awareness of collaborative business processes


Management of External

Relationships

Employee & Culture

No electronic connectivity


Human-to-machine inter-action, data integration

Cooperation scenario and targets defined

Public process and business semantics defined, medium e-business maturity


Partners trust each other and invest in good working relationships


Business semantics are defined on a proprietary base or bilaterally

Partners trust each other and invest in good working relationships

Public process: individual business processes are not aligned


Human-to-machine interaction

Commonly accepted business semantics employed

Individual business processes are aligned by a public process



Individual business processes are aligned by a public process



Existence of services and business documents, medium to high e-business maturity

Public process is not relevant (usually low to medium levels)



Implemen-tation of process integration


Public process, business semantics, services and business documents defined, medium to high e-business maturity

Cooperation is actively managed, cooperation targets are shared

Public process is not relevant (usually low to medium levels)

1

3 Coupling with existing public process

Cooperation is actively managed, cooperation targets are shared

Business relationships are formed ad-hoc

Low to medium e-business maturity, usually fragmented industries


Existence of public process and business semantics, medium e-business maturity

Ecosystem design & cooperation strategy


6

7

2

5

4

Design of services and business documents

Implemen-tation of data integration


Figure 6-2. Business Interoperability Profiles - Overview (Part I)



No

Business Interoper-

ability Profile (BIP)

Approach Technical Interoperability Solution Modelling and specification level Main artefacts

Public processes / activities

Services, information / data

Definition of business semantics

Describe common vocabulary, Define ontology

Ontology definition methods and ontology authoring tools (e.g. ATHOS, Protégé); Semantic annotation (e.g. A*)

Business level (Information and Knowledge)

Information / knowledge

Design of public process

Organizations and roles, input-output relationships (information, physical goods, …)

Public and private processes (views) / activities

Workflows, services, information / data

Define source and target data format; define data transformation and mapping; define and deploy on execution infrastructure

Mapping methods and tools (e.g. STEP Mapper); Semantic annotation and runtime reconciliation (e.g. A*, ARGOS, ATHOS, Semaphore)

Technical and execution level

Services, information / data

Commonly define public process Process modelling methods and Tools specificly targeted at cross-organisational processes (e.g. ARIS EPC, BPMN, GraiTools, Maestro, METIS, MoGo); Exchange of business process models

Methods and tools for service specification (e.g. XMLSpy, Johnson); Methods and tools that support a definition and mapping of business documents (e.g. Maestro, XML Editing Tools)

Technical and execution level

Technical level

Business level (Organization and Processes)

Methods and tools for enterprise modelling that support modelling of value network and business model (e.g. ARIS, GraiTools, Mo2Go, METIS), exchange of enterprise models (e.g. using POP* meta-model)

Business level (Strategy)

Link private process to public processes: Model private and view processes, map private process to public process; if necessary re-organise private processes

Process modelling methods and tools that are capable of supporting the view approach and allow for a linkage of private, view and public processes (ARIS EPC, Mo2Go NG, BPMN, Maestro, …); Model-transformation of business process modelling tools; Global modelling solution

Business level (Organization and Processes)

Design ecosystem, define and document cooperation strategy, exchange documentation between partners

Model private and view processes on technical level; map private process to public process on technical level; create services; connect processes with services; create message exchange; define and deploy on execution infrastructure

Methods and tools for model-driven developement e.g. PIM4SOA); Methods and tools for technical speficification of services and workflows (e.g. Maestro, Gabriel); Respective execution infrastructure: SOA (e.g. Johnson), agents (e.g. JACK), peer-to-peer (e.g. WS Execution Engine)

Model business documents (high-level and components), define services and service interfaces

Implemen-tation of process integration

1

3 Coupling with existing public process

Ecosystem design & cooperation strategy

6

7

2

5

4

Design of services and business documents

Implemen-tation of data integration

Figure 6-3. Business Interoperability Profiles - Overview (Part II)



6.2.3 BIP 1: Ecosystem Design & Cooperation Strategy

BIP 1 characterises organisations which do not systematically manage their external relationships. Since they typically have not defined their cooperation model, they are unaware of collaborative business processes and have not yet invested in electronic connectivity with business partners. This business interoperability profile is more frequent in industries which are highly fragmented and are characterised by low e-business maturity, e.g. facility management.

In order to become more interoperable, companies have to identify relevant partners, i.e. their ecosystem, and define their cooperation strategy. Enterprise modelling supports stakeholders such as business and strategy experts in describing and visualising their value network and their business model. Main modelling elements are organisations with their input and output relationships (physical goods, financial and information flows). Popular modelling tools are for example ARIS [Scheer 1992], GraiTools, Mo2Go or METIS. Since different organisations may use different tools and techniques for enterprise modelling, meta-model based transformation and exchange of models facilitates interoperability. The translation of the top-level (strategic) cooperation strategy into specific collaborative processes and system architectures is subject of subsequent project phases.

6.2.4 BIP 2: Design of “Public Process”

BIP 2 characterises organisations which have defined their cooperation model, and as a consequence need to re-organise the way they are collaborating with their business partners. They need to identify the affected cross-organisational business processes and have to clarify the public process. The latter can be defined either by starting a consensus building approach with business partners or by one partner defining the process for all partners. In industries with equal power distribution the first approach is prevailing, whereas in hierarchical business relationships the focal partner (or network orchestrator) will more likely define the process.

The definition of and the consensus building on public processes is supported by enterprise modelling tools (similar to the tools mentioned in BIP 1) as well as specific business process modelling languages, concepts and tools, such as ARIS Event-driven Process Chains, UML activity diagrams or BPMN which allow for modelling cross-organisational business processes. Business experts use them to detail the interaction between business partners and to agree on a common public business process. Furthermore global modelling languages should be used to define high level service interaction models. The design of further artefacts such as detailed service descriptions and information/data is not subject of this BIP, but will be covered later (BIP 4 and 5).

6.2.5 BIP 3: Coupling with Existing "Public Process"

BIP 3 characterises organisations which have defined their cooperation model and seek to adhere to an already existing public process. A high-tech company which seeks to interact with their business partners using RosettaNet PIPs may serve as an example. BIP 3 requires the existence of a documented public process which may have either been defined by other organisation(s), acting as focal companies or network orchestrators, or a standardisation body. It is consequently more frequent in an environment with a medium e-business maturity.

To adhere to the public process, companies may have to re-organise and change their internal processes. Technical solutions to support these changes can be from the area of enterprise and business process modelling. Recent extensions of business process modelling provide concepts for modelling public and view processes and map them to internal processes. Tool support for public-view-internal process mapping is for example offered in Maestro and Mo2Go NG. To design internal processes and to link them with a public process, it is sufficient to consider the business process models on a business level without consideration of technical details such as message exchange or service interfaces. Involved stakeholders are business experts that translate cooperation strategy and business model into a process design.

6.2.6 BIP 4: Definition of Business Semantics

BIP 4 addresses the issue of defining a common terminology and understanding of the information to be exchanged between business partners. Whereas standardisation initiatives have produced data dictionaries and information models for specific domains (e.g. supply chain management), a comparable level of shared business semantics is still lacking across different industries or for more complex collaboration scenarios (e.g. in the area of product development and post-sales).

Common business semantics are a prerequisite to implement data-based as well as process-



based connectivity and can be achieved through information modelling. BIP 4 typically focuses on the terminology and meaning of the information exchanged in the specific context and does not yet take into account the data structures which have been implemented in different information systems. Business experts and IT architects are involved in defining a common ontology or a common vocabulary for the specific domain. They are supported by respective methodologies for ontology definition as well as ontology authoring tools (e.g. ATHOS as an ATHENA deliverable or Protégé). Semantic annotation can be used for formal knowledge representation.

6.2.7 BIP 5: Design of Services and Business Documents

BIP 5 relates to the design of services and business documents which are the basis for electronic integration. Depending on the focus on either process or data integration, it requires that a public process and/or common business semantics have been established. This situation is frequent in industries which are increasingly moving towards networked business models and have a high e-business maturity. Alike the design of a public process, design of services and business documents can either emerge as result of a consensus building activity or be defined by the focal company or network orchestrator.

Definition of business documents is supported by modelling tools that support e.g. a component-based modelling of business documents. To define services and service interfaces, technical specifications such as WSDL (Web Service Definition Language) can be used. Technical staff such as IT architects is necessary to actually create the services and data models using methods and tools for service specification (XMLSpy, Johnson as an ATHENA deliverable, etc.) and tools that support a definition and mapping of business documents (Maestro as an ATHENA deliverable, XML Editing Tools, etc.). The transformation to models for a particular execution platform is subject to later project phases.

6.2.8 BIP 6: Implementation of Process Integration

This BIP focuses on the electronic coupling of business processes with the target to move from human-human or human-machine interaction to machine-machine integration. Basis for achieving higher levels of electronic process integration is a common understanding of the public process, the availability of service definitions as well as the existence of common business semantics. This business interoperability profile typically is found in business environments with high e-business maturity, e.g. the retail or the automotive industry.

To achieve the coupling of the processes, IT architects first transform the business level models of processes to a platform-independent technical representation. On this level they enrich the models of private and view processes with more detailed information about the services to call and the messages to exchange. They also link the private process models of the partners to a technical level model of the public process. Model-driven development (e.g. supported by PIM4SOA) and tools for technical specification of services and workflows (such as Maestro or Gabriel) increase interoperability at this stage. To actually enact the processes, IT architects and IT administrators have to define the desired execution infrastructure, e.g. service-oriented architectures, agents or peer-to-peer. They then transform the technical level model to execution level models and deploy them on the selected execution infrastructure.

6.2.9 BIP 7: Implementation of Data Integration

BIP 7 relates to the electronic exchange of data in a machine-readable format. It requires common business semantics to be in place. A public process is not a prerequisite since this business interoperability profile may also relate to knowledge-oriented scenarios with an unstructured interaction.

To achieve machine-readable data exchange, IT architects define source and target data formats as well as the transformations between them (using e.g. STEP Mapper). To implement the transformation, an execution infrastructure is identified and the transformations are deployed. This can be supported for instance by functionality to export component-based document models to XML. Semantic annotation and runtime reconciliation facilitate model-based (instead of implementation) transformation. If the data transformation relates to message exchange in a common business process, the respective links between data and process steps have to be maintained by the process execution platform.



6.3 Summary and Outlook

In order to systemise the broad range of emerging interoperability concepts and tools, we suggested an initial set of business interoperability profiles and the associated interoperability solutions. Mapping the Business Interoperability Profiles to the interoperability solution schema allows organisations to select the interoperability solutions which best fit their interoperability issues. The Profiles also help researchers to position their research results in a broader context.

Given the background from the ATHENA project, the BIPs defined in this paper have a strong focus on the modelling and implementation of business processes at different levels of abstraction. So far, Business Interoperability Profiles and their mapping to the interoperability concepts and solutions have been tested in a limited number of case studies. Depending on the existing level of business interoperability, these cases started with different BIPs and consecutively applied a set of three to five BIPs. Given the background from the ATHENA project, the BIPs defined in this paper have a strong focus on the modelling and implementation of business processes at different levels of abstraction.

Further evaluation and completion of categorisation of business interoperability issues and BIP is subject to future research.



Appendix A Business Interoperability Framework

Category Description Life-Cycle 5


(qualified)3

(moderate)2

(minimum)1

(none)









Not (yet) applied

Assess & Review





No review









Not (yet) applied

Assess & Review





No review









Not (yet) applied

Assess & Review





No review

Approach Roles and responsibilities related to partner management are comprehensively defined

Some responsibilities for external partners have been defined

A central contact point for the external partner has been defined

No formal responsibility for partner management; partner contacts are individually defined





Not (yet) applied

Assess & Review



Occasional evaluation of success factors is performed and leads to adaption of partner management approach


No review

Economic dimension: Plans and objectives, that partners pursue in the cooperation, are defined and reconciled with partners, monitored and adjusted

Coo

pera

tion

man

agem

ent

(rol

es)

Organisational dimension: Specific roles (e.g. partner managers) have been introduced in the organization in order to establish well-defined and efficient communication paths between the different organizations.


Coo

pera

tion

man

agem

ent

(pro

cess

es)

Organisational dimension: The processes for initiation, realisation, control and monitoring of cooperations are managed; previsions for risk and conflict management have been taken

Coo

pera

tion

targ

ets


Coo

pera

tion

mod

el





4 (qualified)

3 (moderate)

2 (minimum)

1 (none)










Not (yet) applied

Review & Assess














Not (yet) applied

Review & Assess





None









Not (yet) applied

Review & Assess





None

Bus

ines

s se

man

tics

(bus

ines

s do

cum

ents

)

Semantics: A common business vocabulary establishes a joint understanding of the content and structure of business documents as well as the meaning of its elements. The semantics for main business documents / messages should be defined, commonly accepted and reflect industry standards.

Cross-Organisational Business processes - "How do we collaborate with business partners?"B

usin

ess

sem

antic

s (in

form

atio

n co

ntex

t)

Semantics: A common business vocabulary establishes a joint understanding of the identification, description and classification of relevant information context (e.g. product, partner, …). The semantics for master data should be defined, commonly accepted and reflect industry standards.

Publ

ic P

roce

ss

Pragmatics: A public process describes how companies interact. It establishes a common understanding of the roles, activities and in particular the organisational interfaces. Ideally public processes are built by consensus and reflect multilateral agreements, industry or domain standards (m:n).




4 (qualified)

3 (moderate)

2 (minimum)

1 (none)


Approach Mutual sense of trust and confidence; employees act as cross-organisational team with appreciation on both sides

Good working relationship; Growing sense of trust and confidence

Initial measures are taken to establish social integration

Significance of trust and confidence in external relationships is recognised

Them and us attitude, new skills jealously protected ("Better the devil you know…"); ; control




Not (yet) applied

Review & Assess

Periodic review and assessment, "lessons learned" (positive and negative) with employees involved in inter-firm relationships

Periodic evaluation of success factors is performed with employees involved in inter-firm relationships

Sporadic or occasional evaluation of success factors is performed with employees involved in inter-firm relationships


No review

Approach Pro-active information sharing and full accessibility of relevant information for external partners








Not (yet) applied

Review & Assess





No review









Not (yet) applied

Review & Assess





No review









Not (yet) applied

Review & Assess





No review









Not (yet) applied

Review & Assess





No reviewSecu

rity

& P

rivac

y

Electronic transactions respect the business partner's privacy and security concerns, and comply with e-business legislation.

Trus

t

Behavorial dimension - individual level: Responsibility, sympathy, reliability and confidence between partners. Building a climate of trust and confidence, with the development of a dependable relationship.

Inte

ract

ion

type

The depth of electronic interaction with partners may differ between human-to-human, human-to-machine or machine-to-machine. Interaction.


Con

nect

ivity

/ C

olla

bora

tion

plat

form

A high connectivity is achieved by replacing individual connections (1:1) with many-to-many connections (m:n); The collaboration architecture supports external relationships in an appropriate manner.

Visi

bilit

y

Behavorial dimension - organizational level: Information sharing and accessibility of internal information for business partners. A certain visibility of the internal business processes (e.g. status information, availability, inventories, …) allows for cross-organizational optimization.




Appendix B Contingency Values

B.1 Collaboration Space

B.1.1 E-Business Maturity

The contingency e-business maturity is based on the E-Business Index from [e-Business Watch 2005]. In 2005 an e-business survey was conducted with about 5200 enterprises from ten industries and seven countries. The E-Business Index comprises some of the results in order to compare industries, countries and enterprise size-bands with regards to their e-business maturity. Based on a Balanced Scorecard approach, the Index is composed from 16 indicators taken from the e-business survey. The indicators are aggregated into four categories that represent major application areas of e-business (cf. Table 6-1). Although the scorecard might have some shortcomings (e.g. a bias towards manufacturing activities, cf. [e-Business Watch 2005]) it can serve as an indicator for the e-business maturity in the Business Interoperability Framework.

A: ICT infrastructure and basic connectivity

B: Internal business process automation

C: Procurement and supply chain integration

D: Marketing and sales processes

Enterprises connecting computers with a LAN

Use of an Intranet Enterprises purchasing at least 5% of their supplies online

Enterprises maintaining a website with a CMS

Internet connectivity Use of online technology to track working hours and/or production time

Use of specific ICT solutions for e-procurement

Use of CRM software systems

Remote access to the company network

Use of EDM systems Use of SCM systems Enterprises selling at least 5% of their goods and services online

Enterprises with a VPN Use of ERP systems Online management of capacity and inventory

Use of specific ICT solutions for marketing and sales processes

Table 6-1. Component Indicators of the E-Business Scorecard [e-Business Watch 2005, 215]

Indicators from groups A and B are compared with indicators from groups C and D. The result spans a matrix in which the industries are entered. The result for the ten industries Aerospace, Automotive Industry, Construction, Food and Beverages, IT Services, Machinery and Equipment, Pharmaceutical Industry, Publishing and Printing, Textile Industry and Tourism is depicted in Figure 6-4.

Figure 6-4. e-Business Index by Sector [e-Business Watch 2005, 2]

However, the e-business maturity is one dimensional and therefore we combine both dimensions in the E-Business Index. All industries in the lower right quadrant (less than 50% in both dimensions)



got the value low. Industries in the middle (between 50% and 70% in A/B and between 50 and 60% in C/D) have a moderate e-business maturity. All other industries have a high e-business maturity (more than 70% in A/B and more than 60% in C/D). Table 6-2 illustrates the e-business maturity levels of the industries.

E-business maturity A/B indicators C/D indicators Industries Low Less than 50% Less than 50% Construction, Tourism Moderate Between 50 and 70% Between 50 and 60% Food, Machinery, Publishing, Textile High More than 70% More than 60% Aeronautics, Automotive, IT

Services, Pharmaceuticals

Table 6-2. E-business Maturity Levels – Industries

Figure 6-5. E-Business Index by Country [e-Business Watch 2005, 2]

The same E-Business Index have also been developed for the seven European countries Czech Republic, France, Germany, Italy, Poland, Spain and UK. Figure 6-5 illustrates that there are only two groups in the analysed countries. Countries with a moderate e-business maturity are Czech Republic, France, Italy and Poland (A/B between 50 and 70%, C/D between 30 and 60%). Germany, Spain and UK have a high level with more than 70% in A/B and more than 60% in C/D indicators. We will include a third level – low – for countries that score less than 50% in A/B and less than 30% in C/D indicators (cf. Table 6-3).

E-business maturity A/B indicators C/D indicators Countries Low Less than 50% Less than 30% - Moderate Between 50 and 70% Between 30 and 60% Czech Republic, France, Italy,

Poland High More than 70% More than 60% Germany, Spain, UK

Table 6-3. E-business Maturity Levels – Countries

Finally enterprises in the survey were divided into four classes of size-bands namely micro (1 to 9 employees), small (10 to 49 employees), medium (50 to 249 employees) and large (250 and more employees). Figure 6-6 depicts the E-Business Index matrix with regards to enterprises’ size-bands. We will distinguish between two maturity levels – high and low – with regards to the size of the enterprises. Medium and large enterprises have a high e-business maturity, whereas small and micro enterprises have a low maturity.



Figure 6-6. E-Business Index by size-band [e-Business Watch 2005, 3]

If the contingency e-business maturity is applied to a specific cooperation scenario in order to identify the optimum level of business interoperability, it is a combination of three values: the level of e-business maturity of the industry of the considered organisation (low/moderate/high), the level of e-business maturity of the country in which the organisation is located (low/moderate/high) and the level of e-business maturity related to the organisation’s size (low/high).



Appendix C Glossary

ATHENA Advanced Technologies for interoperability of Heterogeneous Enterprise Networks and

their Applications (FP6 IST program February 2004 – January 2007)

AKM Technology Active Knowledge Modelling Technology (cf. Section 3.1.2.7)

AMIS Approach-Methodology-Infrastructure-And-Solutions principle for innovative work (AKM Technology)

BE Business Engineering (cf. Section 3.1.3.1)

BIF Business Interoperability Framework

BII Business Interoperability Interfaces (EIF)

Category The four categories represent the fundamental concepts of business interoperability. (BIF)

CMM Capability Maturity Model (cf. Section 3.2.2)

CMS Content Management System

Contingency The relationship between some characteristic of an organisation (variable X) and its organisational effectiveness (variable Y) is determined by contingency factors (variable W). (cf. Section 2.4)

CPFR Collaborative Planning, Forecasting and Replenishment

Criteria Each BIF category is operationalised by a set of criteria (or sub-categories) which outline the key business decisions companies have to solve when establishing interoperable electronic business relationships. More technically spoken, the criteria are parameters that can be tuned in order to make an enterprise interoperable. (BIF)

CSCW Computer-Supported Cooperative Work

DoD Department of Defense

EAN European Article Number

EDI Electronic Data Interchange

EDM Enterprise Document Management

EFQM European Foundation for Quality Management (cf. Section 3.2.1)

eGIF e-Government Interoperability Framework (cf. Section 3.1.1.3)

e-GMS e-Government Metadata Standard (eGIF)

EICTA European Information & Communications Technology Industry Association (cf. Section 0)

EIF European Interoperability Framework (cf. Section 3.1.1.2)

ERP Enterprise Resource Planning

FP5 Fifth Framework Programme (Since 1984, research and innovation activities of the EU are grouped in one big programme, the Framework Programme. Framework Programmes are conceived for a period of 4 years. They are elaborated and proposed



by the Commission and have to be adopted by European Parliament and Council. [http://fp6.cordis.lu/fp6/glossary.cfm, 26.08.05])

FP6 Sixth Framework Programme (see FP5)

GCL Government Category List (eGIF)

GDSC Government Data Standards Catalogue (eGIF)

ICT Information and Communication Technology

IDABC Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens

IDEAS Interoperability Developments for Enterprise Application and Software – roadmaps (FP5 IST program June 2002 – May 2003)

IIAM Interoperability Impact Assessment Model

IST Information Society Technologies (research priority in FP5 / FP6)

LISI Levels of Information Systems Interoperability (cf. Section 3.1.1.4)


The interoperability levels per BIF criteria serve as a basis for assessment and a guideline towards higher levels of interoperability. (BIF)

Networked Enterprise Unit of analysis in the Business Interoperability Framework; describes that the enterprise has relationships with its business partners, e.g. customers, suppliers or external service providers

The objective of the BIF is to describe the interoperability of this enterprise and to guide it towards the optimum level of interoperability. The networked enterprise can influence business interoperability by the design of its inter-organisational relationships. (cf. Section 2.3)

NPI New Product Introduction

OEM Original Equipment Manufacturer

RADAR Abbreviation for Results, Approach, Deployment, Assessment and Review and reflects the lifecycle aspect of excellence (EFQM)

SCM Supply Chain Management

SIF Schools Interoperability Framework (cf. Section 3.1.1.6)

SOA Service-Oriented Architecture

TSC Technical Standards Catalogue (eGIF)

VPN Virtual Private Network

XML Extensible Markup Language

ZIS Zone Integration Server (SIF)



Literature

[AC Nielsen 2003]

AC Nielsen, The Power of Private Label: A Review of Growth Trends Around the World, AC Nielsen, Frankfurt am Main, 2003

[AC Nielsen 2005]

AC Nielsen, AC Nielsen Essentials, http://www.acnielsen.de/pubs/documents/ACNielsenEssentials1_2005_000.pdf, last accessed on 31.01.2007

[Adler 2005]

Adler, P. S., The Evolving Object of Software Development, in: Organization, Vol. 12, 2005, No. 3, pp. 401-435

[Alt 2006]

Alt, R., Business Network Redesign – Overview of Methodologies and Example of Process Portals, in: Grover, V., Markus, L.M. (eds.), Advances in Management Information Systems, Volume Business Process Transformation, M.E. Sharpe, 2006,

[Alt et al. 2001]

Alt, R., Puschmann, T., Reichmayr, C., Strategies for Business Networking, in: Österle, H., Fleisch, E., Alt, R. (eds.), Business Networking: Shaping Collaboration Between Enterprises, 2. Ed., Springer, Berlin etc., 2001, pp. 95-115

[ATHENA 2005a]

ATHENA, ATHENA European Integrated Project, www.athena-ip.org, last accessed on 23.09.2005

[ATHENA 2005b]

ATHENA, Framework for the Establishment and Management Methodology, Deliverable D.A1.4.1, Version 1.0, 2005b

[ATHENA 2005c]

ATHENA, Second Version of State of the Art in Enterprise Modelling Techniques and Technologies to Support Enterprise Interoperability, 2005c

[ATHENA 2007]

ATHENA, Specification of Interoperability Framework and Profiles, Guidelines and Best Practices, Deliverable D.A4.2, Version 2.3, 2007

[Aviv 2001]

Aviv, Y., The effect of collaborative forecasting on supply chain performance, in: Management Science, Vol. 47, 2001, No. 10, pp. 1326-1343

[Benjamin et al. 1990]

Benjamin, R. I., DeLong, D. W., Scott Morton, M. S., Electronic Data Interchange: How Much Competitive Advantage?, in: Long Range Planning, Vol. 23, 1990, No. 1, pp. 29-40

[Bensaou/Venkatraman 1995]

Bensaou, M., Venkatraman, N., Configurations of Interorganizational Relationships: A Comparison Between U.S. and Japanese Automakers, in: Management Science, Vol. 41, 1995, No. 9, pp. 1471-1492

[Blanc 2005]

Blanc, S., Interoperability problems: Management of evolution of collaborative enterprises, Geneva, Switzerland, 23.-25.02.2005, 2005,



[Bleicher 1996]

Bleicher, K., Neue Arbeits- und Organisationsformen - Der Weg zum virtuellen Unternehmen, in: Office Management, Vol. 1996, No. 1-2, pp. 10-15

[Bowersox et al. 2003]

Bowersox, D., Closs, T., Stank, T., How to Master Cross-Enterprise Collaboration, in: Supply Chain Management Review, Vol. 2003, No.

[Bussler 2003]

Bussler, C., B2B-Integration: Concepts and Architecture, Springer, Berlin, 2003

[Clark/Stoddard 1996]

Clark, T. H., Stoddard, D. B., Interorganizational Business Process Redesign: Merging Technological and Process Innovation, in: Journal of Management Information Systems, Vol. Vol. 13, 1996, No. Issue 2, pp. 9-29

[Clemons/Reddi 1993]

Clemons, E. K., Reddi, S. P., Some Propositions Regarding the Role of Information Technology in the Organization of Economic Activity, Proceedings of HICSS-26, Volume VII: Information Systems: Collaboration Technology, Organizational Systems and Technology, 01.01.1993, IEEE Computer Society Press, 1993, pp. 809-818

[Clemons et al. 1993]

Clemons, E. K., Reddi, S. P., Row, M. C., The Impact of Information Technology on the Organization of Economic Activity: The "Move to the Middle" Hypothesis, in: Journal of Management Information Systems, Vol. 10, 1993, No. 2, pp. 9-35

[Cohen Kulp et al. 2004]

Cohen Kulp, S., Lee, H. L., Ofek, E., Manufacturer Benefits from Information Integration with Retail Customers, in: Management Science, Vol. 50, 2004, No. 4, pp. 431-444

[CORDIS 2005]

CORDIS, IST Project Fact Sheet - Interoperability Developments for Enterprise Application and Software - roadmaps (IDEAS), http://dbs.cordis.lu/fep-cgi/srchidadb?ACTION=D&SESSION=25102005-8-26&DOC=24&TBL=EN_PROJ&RCN=EP_RPG:IST-2001-37368&CALLER=PROJ_IST, last accessed on 26.08.2005

[Daft 2004]

Daft, R. L., Organization Theory and Design, 8th Edition. Ed., Thomson South-Western, Manson, Ohio, 2004

[Dai/Kauffman 2001]

Dai, Q., Kauffman, R. J., Business Models for Internet-Based E-Procurement Systems and B2B Electronic Markets: An Exploratory Assessment, Proceedings of the 34th Hawaii International Conference on System Sciences, 03.01.2001, 2001,

[Dannenberg/Kleinhans 2004]

Dannenberg, J., Kleinhans, C., The Coming Age of Collaboration in the Automotive Industry, in: Mercer Management Journal, Vol. 17, 2004, No. June, pp. 88-94

[Davidow/Malone 1992]

Davidow, W. H., Malone, M. S., The Virtual Corporation: Structuring and Revitalizing the Corporation for the 21st Century, Harper Business, New York (NY), 1992

[DoD 1998]

DoD, Levels of Information Systems Interoperability (LISI), DoD, Washington, 1998

[Dodel 2004]



Dodel, J.-H., Supply Chain Integration: Verringerung der logistischen Kritizität in der Automobilindurstrie, Dissertation, Universität St. Gallen, Wiesbaden, 2004

[Donaldson 2001]

Donaldson, L., The Contingency Theory of Organizations, Sage Publications, Thousand Oaks, CA, 2001

[Dussart 1998]

Dussart, C., Category management: strengths, limits and developments, in: European Management Journal, Vol. 16, 1998, No. 1, pp. 50-62

[Dyer et al. 2001]

Dyer, J. H., Kale, P., Singh, H., How to make strategic alliances work, in: Sloan Management Review, Vol. 42, 2001, No. 4, pp. 37-43

[e-Business Watch 2005]

e-Business Watch, The European e-Business Report, 2005

[EFQM 2003a]

EFQM, Assessoren Bewertungsbuch, EFQM, Brüssel, 2003a

[EFQM 2003b]

EFQM, Das EFQM-Modell für Excellence, EFQM, Brüssel, 2003b

[EFQM 2003c]

EFQM, The Fundamental Concepts of Excellence, Brussels, Belgium, 2003c

[EFQM 2003d]

EFQM, Introducing Excellence, Brussels, Belgium, 2003d

[EFQM 2006]

EFQM, The EFQM Excellence Award, http://www.efqm.org, last accessed on 24.01.2006

[Eicta 2004]

Eicta, EICTA interoperability white paper, 2004

[El Sawy 2003]

El Sawy, O. A., Collaborative integration in e-business through private trading exchanges (PTXs), in: Information Management and e-Business Management, Vol. 1, 2003, No. 1, pp. 119-137

[Euromonitor 2005]

Euromonitor, The World Market for Retailing, Euromonitor, 2005

[Eurostat 2005]

Eurostat, Europa in Zahlen: Eurostat Jahrbuch 2005, http://epp.eurostat.ec.europa.eu, last accessed on 31.01.2007

[Farrukh 2003]

Farrukh, C. F., P.; Gregory, M., Development of a structured approach to assessing practice in product development collaborations, in: Proceedings of the Institution of Mechanical Engineers - Part B - Engineering Manufacture, Vol. 217, 2003, No. pp. 1131-1144

[Fleisch/Österle 2000a]

Fleisch, E., Österle, H., Business Networking: A Process-oriented Framework, in: Österle, H., Fleisch, E., Alt, R. (eds.), Business Networking - Shaping Enterprise Relationships on the Internet, 1. Aufl. Ed., Springer, Berlin etc., 2000a, pp. 55-91

[Fleisch/Österle 2000b]



Fleisch, E., Österle, H., A Process-oriented Approach to Business Networking, in: Electronic Journal of Organizational Virtualness, Vol. 2, 2000b, No. 2, pp. 1-18

[Ford 2003]

Ford, D. e. a. (ed.), Managing business relationships, 2nd. Aufl., Chichester, 2003

[Fraser 2003]

Fraser, P. F., C.; Gregory, M., Managing product development collaborations - a process maturity approach, in: Proceedings of the Institution of Mechanical Engineers - Part B - Engineering Manufacture, Vol. 217, 2003, No. pp. 1499-1519

[Fricke et al. 2002]

Fricke, M., König, W., Lampe, R., Weitzel, T., EDI and Business-to-Business Systems: The Status Quo and the Future of Business Relations in the European Automotive Industry, Institute of Information Systems University of Frankfurt, Frankfurt am Main, 2002

[GS1 2004]

GS1, GDSN Introductory Brochure, Working Paper, 2004

[Hess 2002]

Hess, T., Netzwerkcontrolling: Instrumente und ihre Werkzeugunterstützung, Deutscher Universitätsverlag, Wiesbaden, 2002

[Hevner et al. 2004]

Hevner, A. R., March, S. T., Park, J., Ram, S., Design Science in Information Systems Research, in: MIS Quarterly, Vol. 28, 2004, No. 1, pp. 75-105

[Hofstetter/Jones 2005]

Hofstetter, J., Jones, C. C., The Case for ECR. A review and outlook of continuous ECR adoption in Western Europe, ECR Europe, 2005

[Hong 2002]

Hong, I., A new framework for interorganizational systems based on the linkage of participants' roles, in: Information & Management, Vol. 4, 2002, No. 2, pp. 261-270

[Hoyt/Huq 2000]

Hoyt, J., Huq, F., From arms-length to collaborative relationships in the supply chain, in: International Journal of Physical Distribution & Logistics Management, Vol. 30, 2000, No. 9, pp. 750-764

[Iacovou et al. 1995]

Iacovou, C., Benbasat, I., Dexter, A., Electronic data interchange and small organisations: adoption and impact of technology, in: MIS Quaterly, Vol. 19, 1995, No. 4, pp. 495-479

[IDABC 2004]

IDABC, European Interoperability Framework for Pan-European eGovernment Services, 2004

[Ideas 2003]

Ideas, Required Activties in Research, Technology and Standardisation to close the RTS Gap, 2003

[Jarillo 1993]

Jarillo, J. C., Strategic Networks: Creating the Borderless Organization, Butterworth-Heinemann, Oxford, 1993

[Johnston/Vitale 1988]

Johnston, H. R., Vitale, M. R., Creating competitive advantage with Interorganizational Information systems, in: MIS Quarterly, Vol. 12, 1988, No. 2, pp. 153-165



[Jun et al. 2000]

Jun, M., Cai, S., Peterson, R. T., EDI use and participation models: from the inter-organizational relationship perspective, in: Industrial Management & Data Systems, Vol. 100, 2000, No. 9, pp. 412-420

[Kasunic/Anderson 2004]

Kasunic, M., Anderson, W., Measuring Systems Interoperability: Challenges and Opportunities, Carnegie Mellon University Software Engineering Institute, 2004

[Kim et al. 2001]

Kim, C.-H., Weston, R., Woo, H.-S., Development of an integrated methodology for enterprise engineering, in: International Journal of Computer Integrated Manufacturing, Vol. 14, 2001, No. 5,

[Klein 1996a]

Klein, S., Interorganisationssysteme und Unternehmensnetze, Wiesbaden, 1996a

[Klein 1996b]

Klein, S., Interorganisationssysteme und Unternehmensnetzwerke, Deutscher Universitätsverlag, Wiesbaden, 1996b

[Klein/Poulymenakou 2006]

Klein, S., Poulymenakou, A. (eds.), Managing Dynamic Networks, Aufl., Berlin, 2006

[Kling et al. 1996]

Kling, R., Kraemer, K. L., Allen, J. P., Bakos, Y., Gurbaxani, V., Elliott, M., Transforming Coordination: The Promise and Problems of Information Technology in Coordination, Paper 88, Center for Research on Information Technology and Organizations, University of California, Irvine, 1996

[König/Wigand 2004]

König, W., Wigand, R. T., Globalization and E-Commerce: Diffusion and Impacts of the Internet and E-Commerce in Germany, in: I-Ways, Digest of Electronic Commerce and Regulation, Vol. 2004, No. 27, pp. 197-227

[Kubicek 1992]

Kubicek, H., The Organization Gap in Large-Scale EDI Systems, in: Streng, R.J., Ekering, C.F., van Heck, E., Schultz, J.F.H. (eds.), Scientific Research on EDI "Bringing Worlds Together", Samsom, Amsterdam, 1992, pp. 11-41

[Kumar/Van Dissel 1996]

Kumar, K., Van Dissel, H. G., Sustainable collaboration: managing confict and cooperation in interorganisational systems, in: MIS Quaterly, Vol. 20, 1996, No. 3, pp. 279-293

[Kurt Salmon Associates 1993]

Kurt Salmon Associates, Efficient Consumer Response - Enhancing Consumer Value in the Grocery Industrie, Washington, 1993

[Le 2002]

Le, T. T., Pathways to Leadership for Business-to-Business Electronic Marketplaces, in: Electronic Markets, Vol. 12, 2002, No. 2, pp. 112-119

[Lee et al. 2000]

Lee, H., So, K., Tang, C., The Value of Information Sharing in a Two-Level Supply Chain, in: Management Science, Vol. 46, 2000, No. 5,

[Leser 2005]

Leser, F., Business Collaboration Infrastructures, Dissertation, 2005



[Leser et al. 2005]

Leser, F., Alt, R., Österle, H., Implementing Collaborative Process Management – the Case of Net-Tech, in: International Journal of Cases on Electronic Commerce, Vol. 1, 2005, No. 4, pp. 1-18

[LI 2005]

LI, M.-S., Business Interoperability Research Requirements Gathering and Analysis, http://www.athena-ip.org/components/com_docman/dl2.php?archive=0&file=MDUwMjIyX0lOVEVST1AtRVNBX0FUSEVOQV9CM19NU0xfdjIucGRm, last accessed on 07.03.05

[Lienhardt 2006]

Lienhardt, J., Das Ernaehrungsgewerbe in Europa: Statistik kurz gefasst, http://epp.eurostat.ec.europa.eu, last accessed on 31.01.2007

[Lorange/Probst 1987]

Lorange, P., Probst, G. J. B., Joint Ventures as Self-Organizing Systems - A Key to Successful Joint Venture Design and Implementation, in: Columbia Journal of World Business, Vol. 87, 1987, No. 2 - Summer, pp. 71-77

[Löwer 2005]

Löwer, U. M., Interorganisational Standards: Managing Web Services Specifications for Flexible Supply Chains, Physica-Verlag, Heidelberg, 2005

[Madnick 1995]

Madnick, S., Integrating information from global systems: dealing with the “on- and off-ramps” of the information superhighway, in: Journal of Organizational Computing, Vol. 5, 1995, No. 2, pp. 69 - 82

[Magna Steyr 2006]

Magna Steyr, Our Vision, www.magnasteyr.com, last accessed on 31.03.2006

[Maidl/Axtner 2004]

Maidl, J., Axtner, H., IT für Kooperationen in der Automobilindustrie, in: ZfAW, Vol. 7, 2004, No. 1, pp. 36-41

[Maidl et al. 2005]

Maidl, J., Axtner, H., Arlt, M., Virtualisierung in der Automobilindustrie am Beispiel der IT-Vernetzung für die Kooperation zwischen der BMW Group und Magna Steyr Fahrzeugtechnik (MSF) im Projekt BMW X3, in: HMD - Praxis der Wirtschaftsinformatik, Vol. 2005, No. 242, pp. 84 - 92

[Malkin 1995]

Malkin, G. S., Comprehensive Networking Glossary and Acronym Guide, Manning Publications, Greenwich, 1995

[Malone 1987]

Malone, T. W., Modeling Coordination in Organizations and Markets, in: Management Science, Vol. 33, 1987, No. 10, pp. 1317-1332

[Malone/Crowston 1994]

Malone, T. W., Crowston, K., The Interdisciplinary Study of Coordination, in: ACM Computing Surveys, Vol. 26, 1994, No. 1, pp. 87-119

[Malone et al. 2003]

Malone, T. W., Crowston, K., Herman George, A. (eds.), Organizing Business Knowledge - The MIT Process Handbook, Aufl., Hong Kong, 2003

[Malone et al. 1987]



Malone, T. W., Yates, J., Benjamin, R. I., Electronic Markets and Electronic Hierarchies, in: Communications of the ACM, Vol. 30, 1987, No. 6, pp. 484-497

[McAfee 2005a]

McAfee, A., Two Electronic Hierarchie Hypotheses, Working Paper, Harvard Business School, 2005a

[McAfee 2005b]

McAfee, A., Will Web Services Really Transform Collaboration?, in: MIT Sloan Management Review, Vol. 46, 2005b, No. 2, pp. 78-84

[Mercer Management Consulting 2004]

Mercer Management Consulting, Studie "Future Automotive Industry Structure FAST 2015", in: Automobil Produktion, Vol. 2004, No. April,

[Metro Group 2006a]

Metro Group, Metro Group Homepage, http://www.metrogroup.de, last accessed

[Metro Group 2006b]

Metro Group, Metro Link Supplier Portal, http://www.metro-link.com, last accessed

[Moss-Kanter 1989]

Moss-Kanter, R., Becoming PALs: Pooling, Allying, and Linking Across Companies, in: The Academy of Management Executive, Vol. 3, 1989, No. 3, pp. 183-193

[OMG 2003]

OMG, MDA Guide - Version 1.0.1, 2003

[Österle 1995]

Österle, H., Business in the Information Age - Heading for new Processes, Springer, Berlin, 1995

[Österle et al. 2001a]

Österle, H., Fleisch, E., Alt, R., Business Networking - Shaping Collaboration Between Enterprises, Second Revised and Extended Edition. Ed., Springer, Berlin etc., 2001a

[Österle et al. 2001b]

Österle, H., Fleisch, E., Alt, R. (eds.), Business Networking: Shaping Collaboration Between Enterprises, 2. Aufl., Berlin et al., 2001b

[Papazoglou/Georgakopoulos 2003]

Papazoglou, M. P., Georgakopoulos, D., Service-Oriented Computing, in: Communications Of The ACM, Vol. 46, 2003, No. 10, pp. 25-28

[Paulk et al. 1993a]

Paulk, M. C., Curtis, B., Chrissis, M. B., Weber, C. V., Capability Maturity Model for Software, Version 1.1, Software Engineering Institute Carnegie Mellon University, Pittsburgh, Pennsylvania, 1993a

[Paulk et al. 1993b]

Paulk, M. C., Weber, C. W., Garcia, S. M., Chrissis, M. B., Bush, M., Key Practices of the Capability Maturity Model, Version 1.1, Software Engineering Institute Carnegie Mellon University, Pittsburgh, Pennsylvania, 1993b

[Reichwald et al. 1998]

Reichwald, R., Moeslein, K., Sachenbacher, H., Englberger, H., Oldenburg, S., Telekooperation. Verteilte Arbeits- und Organisationsformen, 1. Auflage. Ed., Springer Verlag, Berlin, Heidelberg, 1998



[Reimers 2001]

Reimers, K., Standardizing the new e-business platform: Learning from the EDI experience, in: Electronic Markets, Vol. 11, 2001, No. 4, pp. 231-237

[Reyes 2005]

Reyes, P. M., Efficient consumer response: literature review, in: Integrated Supply Management, Vol. 1, 2005, No. 4, pp. 346-386

[Riemer 2006]

Riemer, K., The Role of Social Capital in Managing Relationship with IT Suppliers - A Case Study in Electronic Commerce, in: Klein, S., Poulymenakou, A. (eds.), Managing Dynamic Networks, Springer, Berlin, 2006, pp. 125-166

[Riemer/Klein 2005]

Riemer, K., Klein, S., Network Management Framework, in: Klein, S., Poulymenakou, A. (eds.), Managing Dynamic Networks, Springer, Berlin, 2005, pp. 17-66

[Riemer/Klein 2006]

Riemer, K., Klein, S., Network Management Framework, in: Klein, S., Poulymenakou, A. (eds.), Managing Dynamic Networks, Springer, Berlin, 2006, pp. 17-66

[Ross et al. 2001]

Ross, C. F., Cameron, B., Ysaguirre, D., Reinventing eBusiness Services, Forrester Research, Cambridge, MA, 2001

[Scheer 1992]

Scheer, A.-W., Architecture of Information Systems, Springer, Berlin, 1992

[Scholz 1997]

Scholz, C., Strategische Organisation: Prinzipien zur Vitalisierung und Virtualisierung, Verlag Moderne Industrie, Landsberg/Lech, 1997

[Schools Interoperability Framework 2005]

Schools Interoperability Framework, Schools Interoperability Framework Implementation Specification, Version 1.5r1, Washington, DC, 2005

[Schuh et al. 2005]

Schuh, G., Friedli, T., Kurr, M. A., Kooperationsmanagement: Systematische Vorbereitung, gezielter Auf- und Ausbau, entscheidende Erfolgsfaktoren, Hanser, München, 2005

[Siegel/Madnick 1991]

Siegel, M., Madnick, S., Context interchange: sharing the meaning of data, in: ACM SIGMOD Record, Vol. 20, 1991, No. 4, pp. 77-78

[Snow et al. 1992]

Snow, C. C., Miles, R. E., Coleman, H. J., Managing 21st Century Network Organization, in: Organizational Dynamics, Vol. Vol. 20, 1992, No. Issue 3, pp. 5-20

[Svensson 2002]

Svensson, G., A firm’s driving force to implement and incorporate a business philosophy into its current business activities: the case of ECR, in: European Business Review, Vol. 14, 2002, No. 1, pp. 20-30

[Sydow 1992]

Sydow, J., Strategische Netzwerke: Evolution und Organisation, 1. Auflage. Ed., Gabler Verlag, Wiesbaden, 1992

[Sydow 1999]



Sydow, J., Management von Netzwerkorganisationen - Zum Stand der Forschung, in: Sydow, J. (ed.), Management von Netzwerkorganisationen, Gabler, Wiesbaden, 1999, pp. 279-314

[Sydow/Möllering 2004]

Sydow, J., Möllering, G., Produktion in Netzwerken: Make, Buy & Cooperate, Vahlen, München, 2004

[Thonemann et al. 2003]

Thonemann, U., Behrenbeck, K., Diederichs, R., Grosspietsch, J., Küpper, J., Leopoldseder, M., Supply Chain Champions: Was sie tun und wie Sie einer werden, Gabler, Wiesbaden, 2003

[Timmers 1998]

Timmers, P., Business models for Electronic Markets, in: EM - Electronic Markets, Vol. 8, 1998, No. 2, pp. 3-8

[U. K. Government Cabinet Office 2005]

U. K. Government Cabinet Office, e-Government Interoperability Framework Version 6.1, 2005

[Vollrath/von der Eichen 2004]

Vollrath, C., von der Eichen, S. F., Outsourcing - Die Kernfrage, in: Automobil Industrie, Vol. 2004, No. 11, pp. 18-22

[WAFA]

WAFA, Philosophy, www.wafa.com, last accessed on 31.03.2006

[Wigand et al. 1997]

Wigand, R. T., Picot, A., Reichwald, R., Information, Organization and Management: Expanding Markets and Corporate Boundaries, Wiley, -, 1997

[Williamson 1979]

Williamson, O. E., Transaction-Cost Economics: The Governance of Contractual Relations, in: Journal of Law and Economics, Vol. 22, 1979, No. 2, pp. 233-261

[Williamson 1985]

Williamson, O. E., The Economic Institutions of Capitalism: Firms, Markets, Relational Contracting, The Free Press, New York (NY), 1985

[Williamson 1989a]

Williamson, O. E., Transaction Cost Economics, Elsevier Science Publishing, Amsterdam, 1989a

[Williamson 1989b]

Williamson, O. E., Transaction Cost Economics, in: Schmalensee, R., Willig, R.D. (eds.), Handbook of Industrial Organization, Elsevier Science Publishing, Amsterdam, 1989b, pp. 135-182

[Williamson 1991]

Williamson, O. E., Comparative Economic Organization: The Analysis of Discrete Structural Alternatives, in: Administrative Science Quarterly, Vol. 36, 1991, No. 2, pp. 269-296

[Williamson 1998]

Williamson, O. E., Transaction Cost Economics: How it Works; Where it is Headed, in: De Economist, Vol. 146, 1998, No. 1, pp. 23-58

· Programme Integrating and Strengthening the European Research Strategic Objective Networked...

Documents

Transcript of · Programme Integrating and Strengthening the European Research Strategic Objective Networked...