Enterprise Interoperability IV || An Interoperable Enterprise Architecture to Support Decentralized Collaborative Planning Processes in Supply Chain Networks

An Interoperable Enterprise Architecture to Support Decentralized Collaborative Planning Processes in Supply Chain Networks

Jorge E. Hernández1, Raul Poler1 and Josefa Mula1 1 CIGIP (Research Centre on Production Management and Engineering). Universidad

Politécnica de Valencia. Escuela Politécnica Superior de Alcoy. Edificio Ferrándiz y Carbonell, 2, 03801 Alcoy (Alicante), Spain. {jeh, rpoler, fmula}@cigip.upv.es

Abstract. Supply chain management, since many years, has been realated to coordinate the efforts among the supply chain nodes in order to mitigate unpredictable behaviours related to environment uncertainty. This allows to the involded nodes to achieve common goals in a efectivelly maner likewise the customers demand. Thus, by sharing accurate and actionable information, on a timely basis, the collaboration among the nodes will emerge in order to improve the decision-making process related, mainly, to the planning processes in the supply chain. Hence, from a decentralized perspective, each supply chain node will consider their own enterprise systems in order to manage and exchange the right information among them. Thereafter, aspects such us the interoperabilty of the systems are a very crytical issue to be considered, even in the modelling process and also in the implementation stage. Then, this paper, supported by the Zachman framework and by the REA standar ontology, proposes an novel interoperable enterprise architecture to support the decentralized collaborative planning and the decision-making processes in the supply chains. In addition, the proposed architecture consider a multi-agent based system approach as well as its application to a real automobile supply chain network.

Keywords: Enterprise architecture, Interoperability, Multi-Agent, Collaborative planning

1. Introduction

The supply chain (SC) management process encompasses all the necessary activities to satisfy final customer demand by considering, in the most of the cases, the distribution of components and raw materials among SC nodes and also how they interact to coordinate their activities and decision-making process. In fact, [3] emphasize how the main information elements to be considered in the SC management process must cover node actions (orders, order filling, shipping, receiving, production, etc.), node policies (inputs and outputs inventory policies),

J. E. Hernández, R. Poler and J. Mula

and the costs and rates involved. Therefore a collaborative process will emerge by sharing the proper information among the SC nodes. In addition, collaboration in SCs is important in terms of innovation as every node realize the benefits related to the high quality, lower costs, more timely deliveries, efficient operations and the effective coordination of activities [21]. Moreover, and from a descentralized point of view, collaborative planning (among SC partners) can be achieved by a simple form of coordination of upstream planning by providing the collaboration partners an opportunity to modify suggested order/supply patterns iteratively [7]. Thus, the collaborative relationships change the way in how the business are doing in SC’s, in this context it is possible to say that nodes trends to evolve from cooperation to collaboration [18].

In order to support this, and by considering the fact that enterprise engineering has been leveraged as key topics in enterprise management [17], the concept of enterprise architecture emerges as a system to support the integration of the main concepts, information and processes related to the SC. Thus, as defined by [25] the enterprise architecture gives an interpretation for the enterprise relationships, the information that the enterprises use, and a view of the physical and technological layers considered in the enterprise. Nevertheless, [12] establish that enterprise architectures should not be considered as a “magical” solution to the main enterprise problems (communication, information technologies, etc.), but also it should be considered to support the development efforts in the integration of specified units and processes. Moreover, [23] consider that the enterprise architectures can be used as blueprints in order to achieve the business objectives by considering the information technologies. Hence, in order to support the development process of enterprise architectures, it is highly recommended the use of some meta-architecture to facilitate communication and provide standardized terminologies [5], In this context, [6] review the most importants approach such as the Zachman Framework, ARIS, TOGAF, ATHENA, DoDAF and many more, which can be considered in any enterprise architecture.

Therefore, important aspects related to the SC collaboration and enterprise architectures are related to the sharing information process among the SC nodes and also to the involved decision-making process which request the information related with the SC planning process. Moreover, those nodes commonly consider different enterprise resource planning (ERP) systems, in where the concept of interoperability come ups in order to support the right understanding in the collaborative process related to each SC node ERP systems. In this context, [4] establish that a software interoperability represents a problem for the SC enterprises, mainly due to the unavailability of standards and the existence of heterogeneous hardware and software platforms. In this same context, [4] consider that there are three main research themes, or domains, that address interoperability such as enterprise modelling, architecture-platform and the ontology’s (details of this concepts can be found in [24]). Then, as established by [11], if the enterprise architecture is defined based on ontology’s, the communication problems among different ERP systems will be supported more precisely. Hence, the stakeholder decision-making process by considering a common understanding among the SC parties is enriched [11].

214

An Interoperable Enterprise Architecture

Therefore, by considering the modelling methodology established in [9] and by extending the already defined architecture in [10] in order to highlight it links with the interoperable concepts, this paper presents an interoperable architecture to support the collaborative planning in SC networks by considering elements such as enterprise architecture, standard enterprise ontology supported by the platform Protegé, the language OWL-S (Semantic Markup for Web Services) and a multi-agent based system (MAS) approach supported by JADE 3.6 and ECLIPSE. Hence, the paper is set out as follows: Section 2 briefly reviews the relevant literature on SC collaboration, interoperability and ontology’s. Section 3, extending [10], presents the interoperable enterprise architecture by considering the standard REA ontology in order to support the decentralized collaborative planning in SC and, in addition by considering [8] a case study applied to the automobile SC sector, supported by MAS, is presented in order to observe the real application of the proposed interoperable enterprise architecture. Finally, Section 4 provides the main conclusions of the paper and also establishes a brief description of our future work.

2. Background in Supply Chain Collaboration

Two main aspects regarding the study of the collaborative relationship in the SC are commonly considered: the first deals with the intensity of the relationships between partners, which consider the simple information sharing and also the the risk and profits related to this shared information; the second studies the extent of the collaboration across the SC [13]. Thus, companies consider SC cooperation at levels which implies planning, forecasting and replenishment in a collaborative context (collaborative planning, forecasting and replenishment or CPFR). [22] defines the CPFR systems as a step that goes beyond the efficient answers which the consumer requires. [1] define collaboration as the sharing of information, functions and functionality, knowledge and business processes with the objective of creating a multi-win situation for all the participants of the community of businesses in the chain value, including employees, customers, suppliers and partners. The coordination process of autonomous, yet inter-connected tactical-operational planning activities, is referred to as collaborative planning [9]. Therefore collaborative planning constitutes a decision-making process that involves interaction components, which presents a wide range of dynamic behaviours [14]. For this reason, the visions that address the collaboration process in recent years, like a distributed decision-making process, are becoming more important than the centralised perspective.

Thereafter it is possible to highlight that the collaboration in SCs helps in to get an efficient information management. This information primarily supports the decision-making process of the company which, in most of the cases, is related with the how and when the orders must be placed and be sent to the suppliers as well as to anticipate the demand changes from the customer. In this sense, regarding to [10] and [19], in order to foster collaboration in SCs necessarily the collaborative and non-collaborative nodes must be identified. Moreover, regarding

215


to the information flow oriented to support the decision-making process, result a critical issue that the SC nodes must be able to share information in order to support any decision level (strategic, tactic and operative), this in order to support the feedback on time at any decision-making level.

3. The Interoperable Enterprise Architecture for Collaborative Planning in Supply Chains Networks

The collaborative planning process, supported by the proposed enterprise architecture (Figure 1), is oriented to promote the exchange of information by considering an interoperable environment. This in order to show the informational flows which supports, on one hand, the collaboration among the SC nodes and, in the other hand, decision-making process of the SC nodes. In this sense, it is possible to say that the collaboration involves the exchange of information such us plans, decisions, actions, etc… Thus, a tactical perspective in the decision-making process is to be considered in order to support the collaborative decision-making. Thereafter, this section presents an extension of [10] in where the main models related to the collaborative process have been shown. Then, in the same way, the interoperable enterprise architecture to support the decentralized collaborative planning process, consider the Zachman enterprise framework [26] to support the structure of the interoperable architecture. Moreover, by considering the SCAMM-CPA modelling methodology expressed in [9], the MAS are used to model the main actions and information flows related to the collaborative SC processes.

3.1. The Conceptual Enterprise Architecture in Supply Chain Networks for Collaborative Processes

From the background section, it can be said that the most of the authors suggest consider a framework to carry on the enterprise architecture development process, such us definitions, modelling process and experiments. Moreover, the right selection of a framework will depend on the modeler’s experience and how robust it can be in the environment to which is to be applied. In this context, the Zachman Framework [26] has been chosen to represent the main elements of the architecture based on MAS which will support the collaborative processes in the SC. In this context, the interoperability involves an upper level (customer), the first-tier supplier and the suppliers at the lower level (second or N-tier supplier). Therefore, the selected cells from the Zachman framework grid [20] have been chosen to collect and transmit the related information from the SC nodes which are intended to participate in a collaborative process as collaborative or non-collaborative nodes. Then, the collaborative decision-making supported by the SC information flow takes place in the following highlighted Zachman grid blocks: (1) at the business concepts level (“where” and “who”, is defined as Physical Layer), then at the (2) system logic level (“what”, is defined as Data Layer), followed by the (3) business concepts level again (by considering the “how” and is defined as the Information Layer). Next, (4) the level of technology physics is defined (in where

216


the “what”, “how” and “where” is considered, this level is named as Ontology REA-based Layer). Next, (5) the technology physics and components assembles are considered in order to build this view (here, the “who” and “when” perspective are considered, thus this layer is defined as the Agent Communication Layer). Finally, (6) the operation classes are considered in order to give a real perspective of the system and the processes as well (at this level the “where” and “who” define this level, thus this layer is defined as Behaviour Layer).

Thus, the model representation (as can bee seen in the Figure 1) related to each selected cell consider, on one hand, the representation proposal of [16] and, on the other hand, an extension of [10] to support SC interoperability in collaborative processes (first from its basic point of view and then, in the Figure 2, each selected cell are shown in detail).

Fig. 1. Main blocks from the Zachman framework to support the interoperbility in

collabortive SC’s (adapted from [26])

By considering the review from the previous section, it is possible to state that the collaborative process presented in Figure 1 aims to promote the exchange of information. In this context, the main purpose of the proposed architecture is to show the informational flows that will support interopebility among the SC nodes and also de decision-making process related to every node. In this sense, it is possible to say that collaboration involves many types of processes, and this papers is dedicated to propose an interoporable architecture to support the collaborative planning in SC’s. Moreover, in a collaborative context, these processes relate to the exchange of the demand plans which will eventually imply the consideration of a tactical perspective within the decision-making process. Additionally, and in a SC management context, there are other relevant processes that foster collaboration such as forward and reverse logistics, requesting management, inventory control, key performance indicators, and so on. Thus, in order to conceptually and graphically explain the collaborative process among the SC nodes, and also to efficiently reach a right solution through a decentralized collaborative decision-

217


making process, this architecture focuses in the planning process in where a negotiation on demand plans is considered by lonking the main constraints related to all SC nodes to the information and decisional flow..

• Physical Layer (1): Through this layer the SC configuration is analyzed as well as the resources and items related to it. This layer will provide aspects like the enterprise flows, topologies. This is also considered as the real system in where the decision making process take places.

• Data Layer (2): this layer can be considered as a respository systems which provides simplified access to data stored by consideting an entity-relational database. From a decentralized point of view, every node consider their on data base.

• Information Layer (3): The information layer collects, manage and structure all the necessary information for the information exchange process from a generical view. This in order to support the upper layer on ther collaboration process.

• Ontology REA-based Layer (4): In this case, the REA [15] enterprise ontology has been considered regarding to its standar approach and to its simplicity in the modeling process. Thus, at this layer the mains description logic is established by considering the main economical resources, events and MAS. After this, in order to support the conectivity with the MAS (next layer) a sematic languaje will be choosen in order to support the comunicacion between the physical and agent layer. This layer can be supported by some ontological software desginer, such as protegé.

• Agente Comunication Layer (5): This layer is oriented to support the MAS infrastructure in order to provide the information requested. Thus, the information flow consider aspects such as the transfer and processing of the information which is linked to the corresponding database. The most common librarie wich support this decentralized infraestructure is JADE.

• Behaviour Layer (6): the behaviour layer can be defined in three types, the first one related to MAS which generates a call for proposal ACL menssage (CFP) offers and receive proposals or inform in a ACL language, the second one related to the reception of CFP and proporsal and the generation of CFP messages as well, and the last one oriented to receive the CFP request and answer by accepting, refusing or proposing the CFP request.

In this context, by supporting the enterprise architecture with the REA enterprise ontology (as happen in mostly all of the enterprise resource planning, ERP, systems), the business processes are viewed as components of a single value chain. The exchange processes (like the sale of a product) is modelled twice, once in the enterprise system of each SC node. Then, the Collaboration layer (this is presented in the Figure 3 in where the OWL-S semantic ontology has been considered to support the collaboration among the SC nodes) is established for every node from an independent perspective. Hence, the information exchange

218


process is modelled once in independent terms that can be then mapped into internal enterprise system components. Then it is possible to say that REA cover independent SC models for trading partner. In general, the concepts which support the proposed enterprise architecture is due to the information layer, which consider the common information oriented to support the collaborative planning in SC’s

1

2

3

4

5

6

CDB FTSDB STSDB

C FTS STS

Demand Demand

PartsProducts

Physical Layer

Data Layer

Common information

REA Standar Ontology Layer

Behavioral Layer

Agent comunication Layer

Standarized information

INSTANCES

Fig. 2. Interoperable enterprice architecture supported by REA enterprise ontology

Thus, the relationship among the collaborative nodes will be supported by the demand plan exchanging process, which will collaboratively promote the negotiation of unfeasible values, thus the collaborative decision-making.

3.2. Application of the Proposed Interoperable Enterprise Architecture to a Real Automobile Supply Chain Network

The proposed architecture is being applied to a real automobile SC network. A full description of the company and main processes can be found in [8]. In particular, the plant under study herein supplies seats for automobiles, and the main results related to the interoperable enterprise architecture application can be seen in the Figure 3.

219


Hence the interoperability, supported by this proposed architecture, establishes that the collaboration among the different supply chain tiers will be held by the information exchange among them. In the context of the automobile supply chain sector, this information is mainly related to the production planning, which linked to the decision-making process. Hence, by considering a longer horizon plan, the capacity to react to some unexpected demand plan requirement will be improved, and then the collaborative decision-making will emerge. Thus, by conspiring the advancement of orders, or by changing the respective safety stock, respective suppliers will be able to react to the uncertainty in demand by avoiding an excess of orders or by maintaining a sufficient stock of materials in order to effectively and efficiently cope with changes in orders. Then, in terms of the SC, the order may be accepted, negotiated or rejected. Thereafter, the negotiation process takes place when the SC configuration is in such a state that suppliers of suppliers will exist, and the information exchange (inherent in the decision-making process) will involve several SC nodes which, in turn, will imply that the nodes will exchange the proper information (timely) needed to cover possible backlogs in the production planning process from upper and lower SC tiers in a collaborative and decentralized manner.

Then, the Figure 3 shows the results about applying the interoperable architecture to the real automobile SC:

• Automobile Supply Chain (A): This layer consider the decision-makers related with production planning process in order to generate demand plan and diceminate it through the SC tiers. In this context, this layer will feed the rest of layers (B, C, D and E) in order to validate the system.

• Ontological Data Base (B): The information contained herein is to store the ontologies with which the SC tiers will support their communication. This information is related with the production planning process, which will be considered by the MAS in order to support the decentralized negotiation process supported by the REA standar ontology. Then, this is connected with A, D and E

• Protégé Platform (C): The Protégé platform is to be considered in to generate the apropiate language which will support the communication technology with the defined ontologies. This in order to build respective classes that every agent will use and also the behviours in the context of the FIPA-ACL ContractNet protocols. This layers is connected with all the rest of the layers.

• OWL-S (D): This layer support the semantic comunication among the SC nodes in order to make the service functionalities possible. Moreover, by considering the main ontologies defined in B and C three main issues are covered in this layer: Service profiles, modelling process and interoperability through messages, which will support the agent comunication in the decentralized collaborative process.

220


• Jade Application (E): The behaviours related to the collaborative processs, such as the decision-making process, in the context of production planning process involved in the ERP systems is supported by the implementation of the negotiation, which is supported by the FIPA CFP protocol as can be seen in the dotted square and by the JADE 3.6 libraries. Then the interoperability, at this application layer, will accour among the threads which correspond to the instantiated classes in order to represente the collaborative process among the decision-makers.

Fig. 3. Application of the proposed interoperable architecure to an automobile SC

Therefore in the automobile SC domain context, the model considers the automobile manufacturer (or assembler), the first tier supplier, the second tier supplier, and transport as the main nodes that exchange information and take decision among them as the main human resources involved in the process.

Supported by [2], Figure 3 shows that the integration involves the conceptual, technical and applicative aspects such us the conceptual SC model, the ontological platform supported by protégé, OWL-S and a relational database, and the application which highlight the communication process from a dynamical point of view, respectively.

Thus, from this case study, it is possible to observe that the interoperability system is specific to the information systems, so it inherits all the characteristics of information systems (the information layer in Figure 2). Moreover, the

221


interoperability can be defined by using the REA enterprise ontology and the OWL-S semantic are supported by the protégé system Hence, some properties of the interoperable enterprise architecture, in the automobile SC, can be highlighted: (1) the interoperability is defined by considering a common semantic which is interpreted by the MAS, (2) the different layers are defined to support the interoperability in different enterprise systems, (3) MAS are instances of the related ontological classes defined in protégé, which support interoperability among this and another MAS which will be related to the same SC network configuration.

4. Conclusions

This paper has presented a novel architecture proposal based on the REA enterprise ontology to support the decentralized collaboration process in SC networks such as the planning process. This proposal also has considered the Zachman enterprise framework in order to give a well defined structure to the architecture. Furthermore, it is possible to conclude that MAS are an appropriate tool to model collaborative process from a decentralized perspective, in where the information coming from the collaborative and non-collaborative SC nodes must be identified. As further research objectives, is expected to (1) apply this architecture to study the collaboration in SC with another modeling approaches such us mathematical models, discrete event-based simulation, among others, (2) apply another semantics and ontology’s to this architecture and, (3) consider another standard frameworks such as ATHENA, ARIS among others in order to compare its applicability in real supply chain networks considering the proposed interoperable architecture proposed in this framework.

5. Acknowledgments

This research has been supported partly by the EVOLUTION project (Ref. DPI2007-65501) which is funded by the Spanish Ministry of Science and Education and partly by the Universidad Politécnica de Valencia (Ref. PAID-05-08) and the Generalitat Valenciana, www.cigip.upv.es/evolution.

6. References

[1] Ashayeri J, Kampstra P, (2003) Collaborative Replenishment: A Step-by-Step Approach, Ref: KLICT Project: OP-054, Dynamic Green Logistics, Tilburg University.

[2] Berre AJ, Elvesæter B, Figay N, Guglielmina C, Johnsen SG, Karlsen D, Knothe T and Lippe S (2007) The ATHENA Interoperability Framework. In: Enterprise

222


Interoperability II, Gonçalves, R.J.; Müller, J.P.; Mertins, K.; Zelm, M. (Eds.) Springer London: 569-580.

[3] Chatfield DC, Harrison TP, Hayya JC, (2009) SCML: An information framework to support supply chain modelling. European Journal of Operational Research 196: 651–660.

[4] Chen D, Doumeingts G, (2003) European initiatives to develop interoperability of enterprise applications—basic concepts, framework and roadmap. Annual Reviews in Control 27: 153–162.

[5] Chen Z, Pooley R, (2007) Rediscovering Zachman Framework using Ontology from a Requirement Engineering Perspective. 33rd Annual IEEE International Computer Software and Applications Conference: 3-8.

[6] Chen D, Doumeingts G, Vernadat F, (2008) Architectures for enterprise integration and interoperability: Past, present and future. Computers in Industry 59: 647–659.

[7] Dudek G, Stadtler H, (2005) Negotiation-based collaborative planning between supply chains partners. European Journal of Operational Research 163(3): 668-687.

[8] Hernández JE, Mula J, Ferriols FJ, Poler R, (2008) A conceptual model for the production and transport planning process: An application to the automobile sector. Computers in Industry 59(8): 842-852.

[9] Hernández JE, Alemany MME, Lario FC, Poler R, (2009a) SCAMM-CPA: A Supply Chain Agent-Based Modelling Methodology That Supports a Collaborative Planning Process. Innovar 19(34): 99-120.

[10] Hernández JE, Poler R, Mula J, (2009b) A supply chain architecture based on multi-agent systems to support decentralized collaborative processes. In: Leveraging Knowledge for Innovation in Collaborative Networks, Camarinha-Matos, LM, Paraskakis I, Afsarmanesh H, (Eds.) Springer – Boston: 128-135.

[11] Kang D, Lee J, Choi S, Kim K, (2010) An ontology-based Enterprise Architecture. Expert Systems with Applications 37: 1456–1464.

[12] Kilpeläinen T, Nurminen M, (2007) Applying Genre-Based Ontologies to Enterprise Architecture. 18th Australasian Conference on Information Systems Applying Ontologies to EA. Toowoomba Kilpeläinen: 468-477.

[13] La Forme FG, Genoulaz VB, Campagne J, (2007) A framework to analyse collaborative performance. Computers in Industry 58(7): 687-697.

[14] Lambert MD, Cooper MC, (2000) Issues in supply chain management. Industrial Marketing Management 29: 65-83.

[15] McCarthy WE, (1982) The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review: 554-78.

[16] Nahm YE, Ishikawa H, (2005) Ahybrid multi-agent system architecture for enterprise integration using computer networks. Robotics and Computer-Integrated Manufacturing 21: 217–234.

[17] Ortiz A, Anaya V, Franco D (2005) Deriving Enterprise Engineering and Integration Frameworks from Supply Chain Management Practices. In: Knowledge Sharing in the Integrated Enterprise - Interoperability Strategies for the Enterprise Architect, Bernus P, Fox M, (Eds) Springer - Boston: 279-288.

[18] Poler R, Ortiz A, Lario FC, Alba M, (2007) An Interoperable Platform to Implement Collaborative Forecasting in OEM Supply Chains. In: Enterprise Interoperability New Challenges and Approaches, Doumeingts G, Müller J, Morel G, Vallespir B, (Eds) Springer – London: 179-188.

[19] Poler R, Hernández JE, Mula J, Lario FC (2008) Collaborative forecasting in networked manufacturing enterprises. Journal of Manufacturing Technology Management 19(4): 514 – 528.

223


[20] Shen W, Hao Q, Yoon HJ, Norrie D, (2006) Applications of agent-based systems in intelligent manufacturing: An updated review. Advanced Engineering Informatics 20: 415–431.

[21] Soosay CA, Hyland PW, Ferrer M, (2008) Supply chain collaboration: capabilities for continuous innovation. Supply Chain Management: An International Journal 13(2): 160-169.

[22] Tosh M, (1998) Focus on forecasting. Progressive Grocer 77(10): 113-114. [23] van den Hoven J, (2003) Data Architecture: Blueprints for Data. Information Systems

Management 20(1): 90-92. [24] Ushold M, King M, Moralee S, Zorgios Y (1998) The Enterprise Ontology. The

Knowledge Engineering Review 13(1): 31-89. [25] Vernadat FB, (2007) Interoperable enterprise systems: Principles, concepts, and

methods. Annual Reviews in Control 31: 137–145. [26] Zachman JA, (1997) Enterprise Architecture: The Issue of the Century. Database

Programming and Design: 44-53.

224

Documents

Enterprise Interoperability IV || An Interoperable Enterprise Architecture to Support Decentralized Collaborative Planning Processes in Supply Chain Networks