Keywords

1 Introduction

There is general awareness that organizations cannot compete as isolated entities; it is obvious that working together in networks would be much easier [30] and much productive if achieved in an effective way. However, one of the main problems that organizations face when it comes to working together is the existence of business interoperability problems. Business interoperability can be defined as ‘the organizational and operational ability of one business unit to collaborate or cooperate with its business partners and to efficiently establish, conduct and develop information technology (IT)-supported business relationships with the objective to create value [1]. A study conducted by Gallaher et al. [20] estimated the efficiency losses in the U.S. capital facilities industry resulting from inadequate interoperability. This study quantified U.S. $15.8 billion in annual interoperability cost, namely design changes due to inadequate information access, construction changes due to inadequate information access, manual data re-entry, paper-based information management systems, etc.

In order to overcome the managerial problems of business interoperability, a number of researchers have been attempting to establish a solution that can be used as reference. Nevertheless, a comprehensive solution to those problems, mainly in a context of Supply Chain Networks (SCNs) is still missing. For instance, Grilo et al. [21] stated that although there is considerable effort in interoperability standards development, there still exists today a failure to deliver seamless architecture, engineering and construction interoperability. Corella et al. [12] also agree that there are few real practical examples of Supply Chain (SC) interoperability that can be used as a reference. Indeed, the literature shows that most of the studies conducted up to now have focused on the study of individual dimensions of business interoperability, e.g. information systems [13, 27] or on the integration of only few dimensions, e.g. business, knowledge and information and communication technologies (ICT) dimensions [25], organizational, semantic and technical dimensions [14, 19], business, process, services and data dimensions [8], technical, syntactic, semantic, and organizational dimensions [31]. Even those researches that have explored the issue of business interoperability as a multidimensional construct [1, 32, 36] did not provide an explanation on how to simultaneously integrate the various dimensions of business interoperability nor how they relate to each other; and did not provide an explanation on how to analyze the impact of business interoperability on the performance of networked organizations (e.g. [17]). Therefore, as a new contribution to overcome the managerial problems and the research gaps addressed above, this paper grounds in a context of collaborative SCNs to propose amethodology that enables: (1) the design of collaborative SCN platforms that are able to deliver a high degree of business interoperability (DBI) in a context of collaborative SCN management practices implementation; and (2) the analysis of the impact of (low) interoperability on the performance of these collaborative SCN platforms.

The remainder of this article is structured as follows: Sect. 17.2 looks at the background on collaborative SCNs. Section 17.3 introduces the concept of business interoperability, the major existing initiatives and frameworks, and the dimensions of business interoperability. Section 17.4 presents a theoretical axiomatic design (AD) model and a theoretical agent-based simulation (ABS) model developed to guide in the modeling of collaborative SCN platforms. In the Sect. 17.5, the applicability of the proposed modelsis tested through an application scenario to implement Reverse Logistics (RL) in a context of an automotive SCN. Section 17.6 presents the potential implications for theory and practice.

2 Theoretical Background

In the context of business relationships, networking refers to any kind of organization structures in which two or more geographically dispersed business units need to work in interaction [34]. A business network is a set of connected actors performing different types of activities in interaction with each other [24]. In a context of SCNs, a network can be defined as a set of three or more entities (organizations or individuals) directly involved in the upstream and downstream flows of products, services, finances, and/or information from a source to a customer [29]. Chituc et al. [11] define collaborative SCNs as a collection of heterogeneous organizations with different competences, but symbiotic interests that join and efficiently combine the most suitable set of skills and resources (e.g. knowledge, capital, assets) for a time interval in order to achieve a common objective, and make use of ICTs to coordinate, develop and support their activities. In brief, the objective of a collaborative SCN is to achieve synergistic results.

3 Business Interoperability

Interoperability is defined as ‘the ability of ICT systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge’ [14]. However, this definition is mainly focused on the ‘technical aspects of exchanging information between ICT systems’. Interoperability should not only be considered a property of ICT systems, but should also concern to the business processes and to the business context of an organization [2]. A more comprehensive definition should be provided in order to address the other aspects of business. Thus, the concept of business interoperability is introduced. Figay et al. [18] define business interoperability as ‘a field of activities with the aim to improve the manner in which organizations, by means ICTs, interoperate with other organizations, or with other business units of the same organization, in order to conduct their business’. Regarding at the major initiatives and frameworks on interoperability/business interoperability proposed in the last thirty years, the following are highlighted and categorized as follows: (1) characterization of the dimensions of (business) interoperability and their corresponding factors [1, 8, 14, 15, 25, 32, 36]; (2) process for (business) interoperability evaluation and measurement [1, 9, 10, 13, 16, 22, 26, 28, 36]; (3) development of (business) interoperability maturity model [1, 7, 13, 22, 23, 31]; and (4) quantification/analysis of the impact of (business) interoperability on the performance of networked organizations [3, 4, 20, 27]. The dimensions of business interoperability represent the different facets of interactions at which collaborating organizations can engage in [36]. In a context of collaborative business networks, business interoperability can in the first instance be described at nine dimensions [6, 36]: business strategy, management of external relationships, collaborative management process, exchange of products and services, employees and work culture, knowledge management, business semantic, information systems and network minute details. Each dimension consists of a set of factors that are responsible for the interaction between two or more collaborative business units. For instance, collaborative business process consists of clarity, visibility, alignment, coordination, synchronization, integration, flexibility, and monitoring of collaborative business process.

4 Proposed Modeling Approach

4.1 Theoretical Axiomatic Design Model

Same as any design using the AD theory, our design starts with the identification of the customer needs (CNs). Customers are the end-users of the SCN platform being modeled, that is, automaker, suppliers, distributors, retailers, logistics providers, recyclers, disposal centers, etc. In the development of the theoretical AD model we assumed that: (1) “implementation of collaborative SCN management practices” is CN; (2) “dimensions of business interoperability (and their corresponding factors)” are functional requirements (FRs); and (3) “steps needed to materialize/satisfy the FRs” are design parameters (DPs). To satisfy the CN, i.e. to implement the selected practice in a seamless way, we propose the following top-level FR: FR0: Ensure interoperability in the implementation of the selected practice. The proposed DP to materialize the FR0 is DP0: Development of collaboration mechanisms among the collaborative organizations. Then we started the decomposition of the top-level FR to incorporate the dimensions of business interoperability, which represent the fundamental requirements to implement the selected collaborative SCN management practice. The decomposition is executed from the highest level of business interoperability (business strategy) to the lowest level of business interoperability (network minute details). At each level of the decomposition, a design matrix has been generated to explore the interdependence between FRs and DPs, and to evaluate the “quality” of the design matrix (as per Axiom 1). In the end, a design matrix comprising all the levels of the decomposition has been generated. This matrix is designated as “design matrix to implement the collaborative SCN management practice”. The information content (Axiom 2) is not evaluated in this paper.

4.2 Theoretical Agent-Based Simulation Model

Our ABS model consists of a set of networked organizations and a set of links (relationships among the networked organizations). To develop our ABS model, we have used the last level DPs (output of the AD model) as input to evaluate the current and the required DBI in each dyadic relationship and then to analyze the impact of these last level DPs on the business interoperability performance of the collaborative RL partners. In the context of this study, we call those last level DPs as “interoperability design parameters (IDP)”. Those IDPs are used in the simulation model as link variables. The DBI is evaluated according to a SCN interoperability maturity model [5] consisting of five maturity classes: class 0 (isolated), class 1 (initial), class 2 (functional), class 3 (connectable), and class 4 (interoperable). The analysis of the DBI is made in terms of (dyadic) relationships but the impact is estimated at the organizational performance. Our approach to carry out the analysis of the impact is described as follows: first, one should evaluate the current and the required DBI; based on this evaluation, a distance between these two states is calculated. Having calculated this distance, a probability of problem occurrence can be estimated, based on the achieved distance. Then, one should start to conduct the analysis of the impact using information related to the performance measures (e.g. cost of transportation of one unit from organization \(i\) to organization \(j\), cost and time spent in reprocessing information, cost and time spent in re-planning the production, etc.) and the amount of problems occurred at a given time interval. The distance for each IDP is calculated according to the following formula: Business interoperability distance \(=\) current degree of business interoperability \(-\) required degree of business interoperability.

5 Illustrative Example

In order to demonstrate the applicability of the proposed methodology, an illustrative example is presented in this section. This illustrative example is based on an application scenario to implement RL in a context of an automotive industry. In order to ensure seamless implementation of RL, an interoperable reverse SCN platform is designed through the application of the AD theory. The effectiveness of this platform is then evaluated through the application of the ABS. The organizations included in this application scenario and the relationships among them are illustrated in Fig. 17.1. Sorting and separating of returnable items (pallets/packages, damaged items, waste or scrap) are carried out internally by each organization. The First Tier Suppliers (FTSs) are responsible for the remanufacturing of nonconforming and damaged components. The considered main RL operations are: return of nonconforming and damaged components to be re-manufactured; return of pallets and packages to be reutilized; transport of waste and scrap to recycling or disposal center.

Fig. 17.1
figure 1

The structure of the considered RL network

Full size image

5.1 Demonstration of the Theoretical Axiomatic Design Model

As stated in the previous section, the purpose of the design is to develop SCN platforms that are able to ensure interoperability in the implementation of RL. Thus, the top-level functional requirement and its corresponding DP are defined as follows:

  • \(FR_0\): Ensure interoperability in the implementation of RL.

  • \(DP_0\): Development of collaboration mechanisms among RL partners.

As \({\text {FR}}_0\) does not provide sufficient detail to implement RL, this FR was decomposed in order to incorporate the dimensions of interoperability described in Sect. 17.3. Table 17.1 illustrates the decomposition of the level 1 FRs and their corresponding DPs. This decomposition does not include factors related to the knowledge management because it is assumed that there are no issues of intellectual property rights involved in the implementation of RL.

Table 17.1 Decomposition of the level 1 FRs and corresponding DPs
Full size table
Fig. 17.2
figure 2

Design matrix for level 1 FRs

Full size image

To evaluate the independence axiom for the level 1 FRs, a design matrix is shown in Fig. 17.2. This matrix provides the sequence of implementation of the DPs. For instance, to achieve the last functional requirement (\({\text {FR}}_{1.8}\)), the design parameters \({\text {DP}}_{1.1}\), \({\text {DP}}_{1.2}\), \({\text {DP}}_{1.3}\), \({\text {DP}}_{1.4}\), and \({\text {DP}}_{1.7}\) must be implemented before of \({\text {DP}}_{1.8}\).

As can be observed in Fig. 17.2, the design matrix for the level 1 FRs is decoupled, as all upper triangular elements are equal to zero. Because there are some lower triangular elements that are different from zero, the independence of FRs can be guaranteed if and only if the DPs are determined in a proper sequence [33]. However, with the present decomposition the design does not get required detail because most of the proposed FRs are too much abstract. Therefore, the designer should go back to the functional domain and decompose those FRs to the next level FRs (level 2). Following, we present the decomposition for \({\text {FR}}_{1.3}\) of Table 17.1, which result will be used as input to the ABS model. The decomposition of the other FRs follows the same approach used to decompose \({\text {FR}}_{1.3}\), i.e. they should include their corresponding business interoperability factors.

In order to fulfill the \({\text {FR}}_{1.3}\), Table 17.2 presents the main sub-FRs and sub-DPs necessary to establish and manage RL collaborative processes in a context of network.

Table 17.2 Decomposition of sub-FRs (level 2) and sub-DPs for \({\text {FR}}_{1.3}\)
Full size table

5.2 Demonstration of the Theoretical Agent-Based Simulation Model

To demonstrate the application of the theoretical ABS model, we developed an application scenario through a simulation environment developed through the Netlogo software [35]. We used three IDPs derived from the theoretical AD model: ‘\({\text {DP}}_{2.3.1}\): mechanisms to ensure clarity on the definition of entities in charge of each RL collaborative process’ and ‘\({\text {DP}}_{2.3.3}\): mechanisms to communicate the processing status of the RL collaborative processes along the network’. The \({\text {DP}}_{2.3.3}\) is further decomposed into \({\text {DP}}_{3.2.3.1}\): mechanisms to communicate the processing status of the components being remanufactured and \({\text {DP}}_{3.2.3.2}\): mechanisms to provide visibility of the inventory level of the returnable products/materials.

The considered RL network in the demonstration of the theoretical ABS model is the same that was considered in the demonstration of the theoretical AD model. In order to conduct the analysis of the impact, we made some assumptions as the empirical data are not available at this moment: the FTS 1 delivers to the Automaker 600 type A components per day, and five times a day; the lead time for remanufactured type type A component is 1 h; the FTS 2 delivers to the Automaker 1200 type B components per day, and five times a day; the lead time for remanufactured type A component is fourth five minutes; the transportation of these components from the FTSs to the Automaker is carried out by the Internal Logistics Provider (ILP). In each shipment of type A components, four pallets are used and each type A component is packaged using one packing; for the type B component, six pallets are used and each component is also packaged using one packing; both pallets and packings used to ship components from the FTSs to the Automaker are reusable; the organizations operate 8 h a day and five days a week; DBI for the IDPs are normally distributed, i.e. \({\text {DBI}} \sim N(\mu , \sigma ^2)\); Table 17.3 shows how the average DBI of the links change over time.

Table 17.3 Evolution of the average DBI
Full size table
Table 17.4 Average value for the performance measures
Full size table

We also assumed that: the DBI of the ‘mechanisms to ensure clarity on the definition of entities in charge of each RL collaborative process’ have an impact on the return rate of pallets and packing; it is assumed that the return rate of pallet/packings is between 95 and 100 % if the distance is zero, between 85 and 94 % if the distance is \(-1\), between 65 and 84 % if the distance is \(-2\), between 38 and 64 % if the distance is \(-3\), and between 0 and 37 % if the distance is \(-4\); it was assumed that for each non-returned pallet and packing, there is an impact on the inventory cost at Automaker and on the cost of acquiring new pallets and/or packing at the FTSs; it was assumed that the unit inventory cost at the Automaker is 4€ for non-returned pallets and 2€ for non-returned packings; at the FTSs, it was assumed that the cost of acquiring a new pallet is 10€ for both FTSs; the cost of acquiring a new packing is 5€ for the FTS 1 and 4€ for the FTS 2; regarding at the ‘mechanisms to communicate the processing status of the components being remanufactured’ we assume that its impact is on the cost and time spent in production planning at the Automaker; it was assumed that the impact (both on time and cost) is zero if the distance is zero, between 0.05 and 0.12 if the distance is \(-1\), between 0.13 and 0.30 if the distance is \(-2\), between 0.31 and 0.60 if the distance is \(-3\), between 0.61 and 1 if the distance is \(-4\); for the ‘mechanisms to provide visibility of the inventory level of the returnable products/materials’, it is assumed that its impact is on the cost and time spent in production planning at the organization that will receive the returned products/materials; to analyze the impact of this IDP, we considered the links from the Automaker to the FTSs and the links from the Automaker and from the FTSs to the Recycling Center; it was assumed that the impact (both on time and cost) at the FTSs is zero if the distance is zero, between 0.12 and 0.18 if the distance is \(-1\), between 0.19 and 0.32 if the distance is \(-2\), between 0.33 and 0.58 if the distance is \(-3\), and between 0.59 and 1 if the distance is \(-4\); in terms of the impact on the Recycling Center, is was assumed that the impact is zero if the distance is zero, between 0.05 and 0.15 if the distance is \(-1\), between 0.16 and 0.30 if the distance is \(-2\), between 0.31 and 0.6 if the distance is \(-3\), and between 0.61 and 1 if the distance is \(-4\); the time spent in production planning in each organization is also assumed to be normally distributed as follows: the average time spent at the Recycling Center is 2.5 h a day with a standard deviation of 15 min (0.25 h); the cost of each hour spent in production planning is assumed to be fixed in 600€; at the FTSs, the time spent in planning remanufacturing process is normally distributed with a mean of 2 h and a standard deviation of 15 min (0.25 h) and the cost of each hour spent in planning is fixed in 800€; At the Automaker the time spent in production planning is normally distributed with a mean of 4 h and a standard deviation of 30 min (0.5 h) and that the cost of each hour spent in planning is 1,000€.

5.3 Computational Experiments and Simulation Outputs

As the purpose of this paper is to explore and demonstrate the applicability of the proposed methodology through an application scenario, rather than to achieve generalization about the outputs obtained, the issues such as the number of replications, warm-up period as well as the confidence interval for the mean of the performance measures are not considered. The run-length of the simulation is defined to be one year. We assume that there are six holidays during the year. In each quarter it will be discounted two holidays. Therefore, the simulation runs 265 (271–276) time periods (days) of 8 h. In this paper the simulation run is executed only one time due to the reason pointed out above. The average values for each considered performance measure are summarized in Table 17.4.

6 Conclusions

The purpose of this paper was to add to the knowledge on operations management research by developing a methodology for modelling business interoperability in a context of collaborative SCNs. By presenting a holistic methodology that enables to integrate the various dimensions of business interoperability, this study represents a novelty on how to relate different dimensions of business interoperability (and their corresponding factors) and how to analyze their impact on the performance of networked organizations.

The preliminary findings of this research suggests important implications for the managers in the collaborative SCNs to understand how to design interoperable SCN platforms and how to analyze the impact of low interoperable platforms in the performance of networked organizations. More importantly, the proposed methodology provides decision makers with the ability to evaluate the current DBI and the points where improvement can be achieved. The preliminary findings also suggest that the combination of the AD theory with the ABS proved to be a suited tool for modeling business interoperability in a context of collaborative SCN.