Managing distributed business processes in the virtual enterprise

Managing Distributed Business Processes in the Virtual Enterprise Alexandra Augusta Pereira Klen 1; Ricardo J. Rabelo 1; Aureo Campos Ferreira 1; Luiz Marcio Spinosa 2 1 Federal University of Santa Catarina - GSIGMA (Intelligent Manufacturing Systems Group), Brazil {klen;rabelo;ferreira@gsigma-grucon.ufsc.br} 2 PUC-PR, Brazil {spinosa@cits.br} Abstract In this work the supply-chain co-ordination in the virtual enterprise environment is subject of analysis. The system developed by UFSC – DBPMS – for the management of distributed business process is presented and some basic concepts for its definition and development are detailed. The DBPMS provides means for getting, analyzing, making available and managing the information from and about a virtual enterprise, enabling the enterprises to make their logistics more efficiently by means of a integrated information-based supply-chain management. All the work presented in this paper was developed within the scope of the ESPRIT project PRODNET-II (Production Planning and Management in an Extended Enterprise). Keywords: Virtual Enterprise, Supply Chain Management, Distributed Business Process. 1. INTRODUCTION This paper presents an implemented approach on how the intra-organizational logistics carried out by the classical PPC (Production Planning and Control) systems can be extended with a higher level vision of the Virtual Enterprise’s (VE) logistics, giving rise to an inter-organizational logistics. Since the use of information technology is being increasingly encouraged for sharing and exchanging information among individuals and organizations in different places, this trend is here understood as a consequence of a new strategy of conducting business, which is the concept of Virtual Enterprises (VE). In the manufacturing sector, the Virtual enterprise is mostly composed of small and medium-sized enterprises acting as suppliers and having no definite relations, policies and implications. Hence, it is not difficult to perceive the degree of complexity in managing this kind of value-chain as well as coordinating the logistics of a business process that is distributed. The work will focus on the possibilities of getting, analysing, making available and managing production-related information from and about a VE as well as enabling the enterprises to make their logistics more efficiently. For this purpose, a software called "Distributed Business Process Management System" (DBPMS) will be presented, highlighting its general approach as well as its main functionalities and modules. At the end, some considerations about the integration and interoperation mechanisms will be made. DBPMS was developed under the scope of the ESPRIT PRODNET-II (Production Planning and Management in an Extended Enterprise)1 (Pereira Klen & al., 1999). 2. DISTRIBUTED BUSINESS PROCESS Similar to the traditional enterprises, a VE must also deal with order requests. In this case, these orders are considered as being distributed business processes (DBP). A DBP is a dynamic and temporary set of business processes (BP) which jointly gives rise to the end product of the VE. As the BPs are supposed to be performed by various enterprises, the enterprise that triggered the creation of a given VE normally coordinates its operation in order to avoid business chaos (Rabelo & al., 1996). In a VE 1 PRODNET-II consortium: Federal University of Santa Catarina (Brazil), Herten Engenharia de Moldes (Brazil), CSIN- Construção de Software e Automação na Indústria Lda (Portugal), Universidade Nova de Lisboa (Portugal), University of Amsterdam (The Netherlands), ESTEC - Estudos e Tecnologias da Informação Lda (Portugal), LICHEN Informatique (France), Miralago S.A. (Portugal), ProSTEP GmbH (Germany), UNINOVA - Instituto de Desenvolvimento de Novas Tecnologias (Portugal). scenario the management of the value-chain is a complex task, especially when some degrees of coordination are envisaged for support. (Pereira Klen & al., 2000) classifies these coordination levels in three main groups: a low coordination view, which comprises the activities carried out by workflow systems; a middle co-ordination view, which considers advanced co-ordination functionalities - and will be further detailed in the next -; and a high co-ordination view represented by smart co-ordination functionalities. Figure 1 illustrates a DBP concept via its production graph. The VE Coordinator is, in this case, the client-enterprise, whereas VE Member 1, VE Member 2 and VE Member 3 are its direct suppliers. Each involved enterprise has some (sub-)BPs under its responsibility (and so the respective Enterprise Activities -EAs). They represent the value added by each enterprise on the production chain, in the course of time. For example, VE Member 1 has to perform four interdependent BPs (BP1_10, BP1_22, BP1_22A and BP1_22B), whose result has to be sent to the VE Coordinator so that the BP1_1 can be carried out and so the whole production can be maintained generating the end-product 1. VE Member 1 BP1_22 BP1_22A BP1_22B BP1_10 VE Coordinator BP1_1 VE Member 2 BP_1 BP1_22C end-product 1 EA1 EA2 EA3 VE Member 3 BP1_11 BP1_11A BP1_111 Figure 1 – DBP concept 2.1 Distributed Business Process Management - DBPM New logistics requirements, imposed by the virtual environment scenario, have brought about changes that have made logistics what it is today, seen as an integrated or embedded flow of material and information that has to be managed as one entity from the raw material to the final consumer. For this new perception of doing business, offered by the VE philosophy, the employment of Integrated Logistics (IL), as a concept meeting the needs of the distributed relations, may help understand its implications in the true integration of the VE. The Integrated Logistics framework focuses on the overall performance instead of on individual performance, considering that the time is too short for multiple co-ordinating organisational levels and inventories to exist (Christopher, 1994; Møller & al., 1994; Slats et al., 1995; and Bowersox and Closs, 1996). Furthermore, it is recognised that for the real benefits of the logistics concept to be implemented, there is a need to extend the logic of the logistics upstream to suppliers, and downstream to final customers. This is the concept of Supply Chain Management (SCM) (Leach & al., 1996; Christopher, 1994). The evolution of the logistics business concept has directly influenced the importance of improving understanding and managing the DBP. Since BPs are supposed to be performed by several enterprises (figure 1), the VE coordinator must, for instance, manage the operation of all BPs. As such, the VE is also liable to unexpected events, like BP delay, BP or DBP cancellation/modification, changes in DBP priorities, as well as to local communication deficiency and network overloading or failure. When one of these problems occurs and the responsible enterprise cannot solve the problem locally, it violates the DBP contract, and thereby causes a conflict. This conflict basically influences the DBP production dates (the planned delivery date) and can affect the whole production chain. Because the components of a DBP are all inter-related, an enterprise cannot (re)plan itself for its own benefits only, but it must also seek to benefit the whole net. Consequently, a close cooperation has to exist both intra and interorganizations in order to minimize the global loss in the “DBP contract”. The complexity of the resolution of a conflict may vary considerably. Because an enterprise usually plans with some temporal intervals between the BPs (just to absorb the unexpected occurrences), a replanning negotiation may be relegated to adjust the planned delivery date either to the earliest delivery date or the latest delivery date. This policy could be one solution for a rapid contract renegotiation and thus for a fast DBP re-establishment of plans. However, depending on the severity of the problem, the solution may involve a deeper - and possibly complex - analysis. Many considerations and evaluations have to be taken into account, especially considering that an enterprise usually does not have just one DBP contracted, but a number of them, and this, in turn, can be indirectly affected by the problematic BP. Thus, the overall complexity makes it almost impossible for a user or a system to solve the problem individually. A single user lacks the knowledge and capabilities (in terms of time and technical background) and a system lacks the natural human 'business flexibility' and experience for good trade-off analysis / decisions. In this sense, a balanced approach seems to be a suitable solution to contemplate the enterprise with these two 'knowledge sources' simultaneously. In other words, a Decision Support System (DSS) which can assist the user in decision-making. In this context, a DSS has to cope with the following stages (O'Neill, 1995): identifying the problem situation; acquiring and analysing data; determining causes of problem; defining objectives; generating alternative solutions; comparing and evaluating alternative solutions; selecting (the 'best') solution. A framework for this DSS must provide the decision-maker with selected information, describing both the competitive external environment and the way the enterprise is operating. In addition, it must also provide well-established decision-making support models and techniques. The developed DBPM system (DBPMS) offers an enterprise with an environment that provides reliable and timely production-related information about the supply-chain and a support for rapid decision-making facilitating, in this way, the coordination of the VE. 2.2 Advanced Coordination based Functionalities The co-ordination is a subject of great importance for the realisation of VEs. Considering that the network of enterprises is formed due to the requirements of specific orders, there must be a way to coordinate these activities. In the Prodnet-II (Prodnet,1999) project this is done through “Advanced Coordination Functionalities” (ACF). ACFs corresponds to specialised software modules developed to help solve specific problems that require co-ordinated actions within the VE, improving the quality of supply-chain management. The coordination functionalities are, in fact, a subset of the functional requirements for a VE. The Prodnet-II architecture comprises a number of semiautonomous software modules that provides the enterprise with several other functionalities, such as: exchange of commercial data (using EDI/EDIFACT and Internet), exchange of technical product data (STEP), quality related information exchange, VE information management, and the management of incomplete and imprecise orders. All these “services” are supported by other basic software modules to guarantee the privacy and safety of communication, distributed data management, architecture/services configuration and global coordination among the modules (Camarinha-Matos & al., 1998). From the enterprise point of view, all those functionalities are seen as a “black boxes”, which offer VE services – the Prodnet-II Platform. It corresponds to an upper layer of software to be installed in the enterprise legacy systems (their internal modules) so that the enterprises can operate in a VE scenario in a “transparent” and integrated way. In fact, this platform comprises two main modules: the Prodnet Cooperation Layer (PCL) and the ACF modules represented by the DBPM system (Figure 2). The ACFs can be seen as high-level services to be offered to an enterprise/user, who uses the basic services from the other Prodnet-II Platform modules. The communication between the ACFs and the PCL is supported by means of a specific API (Application Program Interface), which was developed in the project. VE Node VE Node I nternal Module Cooperation Layer PCL STEP Advanced Coordination DBPMS Functionalities Production Planning and Control Engineering & other internal modules Module P C L A P I EDI Module Config. Module User I nterface LCM [ Workflow Manager] Coordination Kernel PCI DI MS [ Distributed I nfo. Manag. System ] Figure 2 – The Advanced Coordination Functionalities in the Prodnet-II Architecture 3. GENERAL APPROACH The developed DBPMS is an ACF that seeks to provide means for obtaining, analysing, making available and managing production-related information from and about a VE, enabling the enterprises to perform their logistics more efficiently. It was designed to act mainly in the operation phase of a VE life cycle (Spinosa & al., 1998), although it may also be required during the VE configuration i.e. in the creation phase. The essential objectives of the DBPMS are to offer an enterprise with an environment that provides reliable and timely production-related information about the supply-chain and a support for rapid decision-making, two extremely important enabling aspects to support the agility of the enterprise and hence its competitiveness. So, the DBPMS extends the intra-organisational information logistics carried out by the classical PPC systems, with a higher-level vision of the VE’s logistics, giving rise to an inter-organisational information logistics (Pereira Klen & al., 1998). The DBPMS is then a kind of support system built up to help an enterprise for a better integrated supply-chain management, with an emphasis on the information flow. Its general approach is illustrated in the Figure 3. Supervision Clauses, Monitoring and Production Bulletins historic files In t er n et VE Client Workflow DBPMS PCL PCL Internet Workflow DIMS DIMS PPC PPC Supervision Clauses & Production Bulletins Rights & Duties Shopfloor VE Coordinator Shopfloor VE Member Figure 3 – DBPMS General Approach DBPMS Basic Services The whole process starts when the VE-Coordinator wants to monitor, after a given VE is created, the processing of a particular BP at a given VE-Member’s site. During the VE creation phase a set of agreements is made, including the specification of a number of information items that the VEMember’s PPC should send to the VE-Coordinator (like order status, remaining process time, the amount of parts already produced, etc.) as well as how often this should be done. These specifications are indicated in the “supervision clauses” (see later), an information structure aggregated to the respective BP contract (the “purchase order contract” in the PPCs), which is filled up by the user via a specific graphic interface. Once a given VE is created, all the information about it – and that one required by the DBPMS – is stored in a system responsible for the management of distributed information (DIMS), and fed by the VE-Coordinator’s PPC. Using the Prodnet-II approach, the information being monitored (specified in the “rights” of the VE-Coordinator) is sent and managed by the DIMS module. This means that the VE-Member’s PPC should obtain that information (in time cycles) from its shop floor and make it available in its DIMS so that the VE-Coordinator’s DBPMS can have access to it in order to reason about it. Modifications in the VE-Coordinator’s PPC may be carried out according to the decisions made by the PPC (and not by the DBPMS). In another direction there are the rights of the VE-Member or, in other words, the duties of the VECoordinator. It is also important to provide the suppliers with reliable information. In this sense, the VE-Coordinator may have to inform the VE-Member about a set of information, previously agreed on and specified in the supervision clauses / duties. It means that a minimal set of DBPMS services should also be provided on the VE-Member’s side. The inter-communication between the DIMS modules of the VE-Coordinator and the VE-Member is “transparently” supported by the DIMS’ services as a federated and distributed database (Afsarmanesh & al., 1998). This involves, in turn, a secure and encrypted information flow between the VE- Coordinator and the VE-Members, which is supported by the PCI (Prodnet Communication Infrastructure) module (Osorio & al., 1998). The coordination of the whole process, both “intra” Prodnet Cooperation Layer (PCL) and “inter” PCLs, is carried out by the workflow-based system called Local Coordination Module (LCM) (Camarinha & al., 1999). 4. DBPMS MAIN FUNCTIONALITIES The implemented DBPMS functionalities are comprised in four main blocks (figure 4): Interoperation I nteroperation Viewer DBPMS Suppliers’ PCLs PRODNET Cooperation Layer (PCL) I nteroperation Services Configurator DSS Supervision Clauses Production Bulletins PPC Conflict Detection VE Supervisor Supply-Chain Reactive DecisionMaking DBP Monitoring (orders follow-up) DBP Control Suppliers’ PPCs (in order processing) (Action Advice) Simulation of Alternatives VE Analyzer PPC DBPMS Figure 4 – DBPMS Architecture v VE Supervisor: This functional block aims to offer an electronic way to get production-related information from the suppliers so that the enterprises can constantly update their production plans and schedules (Rabelo & al., 1997), as well as provide important advises to VE members when coordination actions apply. It is composed by two modules: − DBP monitoring: real-time information gathering from the suppliers’ PPCs (in terms of orders); − DBP Control: generator of a set of actions that should be carried out in order to implement a selected decision. v Decision-Support for Logistics Management (DSS): It aims at helping an enterprise to evaluate and to decide in the presence of a conflict in the supply chain. It is composed by four modules: − Conflict detection: detection and identification of unexpected problems during the orders processing; − Reactive decision-making: support for a decision-making according to the conflict detected; − Simulation & assessment of alternatives: support for the selection of a simulated decision by the user; − VE Analyzer: it provides an intra-organizational analysis of the VE in operation as well as an inter-organizational analysis comparing the alternative re-scheduled solutions with the conflicting situation. v Configurator: It allows the user to interactively configure the DBPMS. It involves the configuration of the supervision clauses to be applied upon every VE-Member of a given VE, the mapping between the VE-Members’ PPCs capabilities in terms of information gathering against the DBPMS needs, and also configuration of the production bulletins. v Interoperation: It gives the support for the interoperation between the DBPMS and the other Prodnet’s modules (Prodnet Cooperation Layer). It is composed by two modules: − Interoperation Services: it can be considered as the DBPMS’s API (Application Program Interface). It contains all the services that guarantee the DBPMS interoperation with the other Prodnet modules. − Interoperation Viewer: it provides a browser allowing the user to monitor all the interactions between the DBPMS and the other modules, based on an error log file generated by the DBPMS. Taking the main DBPMS modules into account, figure 5 illustrates its general control and information flow. All these modules will be further explained in the next subsection. Completing the frame, the integration and interoperation mechanism will also be highlighted. Selected alternative DBP Control VE-Member’s PPC Simulation of Alternatives Supply-chain monitoring PCL VE-Coordinator’s PPC Interoperation Interoperation Viewer Monitoring Configuration Conflict Detection Conflict diagnosis and partial treatment Conflict resolution simulation Reactive Decision Making Conflict treatment Conflict treatment evaluation VE Analyzer Figure 5 – DBPMS general control and information flows 5. DBPMS MAIN MODULES 5.1 Monitoring This module receives all the relevant production-related information to be monitored from both the VE-Members and the VE-Coordinator, which means that the DBPMS is prepared to deal with (a subset of) both intra and inter-organisation conflicts. These unexpected events may be, for instance, BP delay, BP or DBP cancellation/modification, changes in DBP priorities and so on. The information covers a given DBP, DP (Domain Process), BP, Order, product specification as well as their supervision clauses, which specify rights and obligations in terms of information access for monitoring purposes. From the DBPMS point of view, all the information comes from the PCL/DIMS module. Once the information is received and organised into the DBPMS, it is passed on to the Conflict Detection module. An example of one of the graphical user interfaces of this module is presented in figure 6, showing the main monitoring window. Figure 6 – Monitoring user interface 5.2 Conflict Detection This module receives the production-related information that is being periodically monitored and then it checks whether it matches with what was planned, normally the order due dates and their execution status. If nothing wrong happens, the user keeps monitoring the order follow-up. In case a conflict is detected, it is identified and passed on to the Reactive Decision-Making module. The checking is also carried out when the VE is created and the PPC sends the DBP-related information to the DIMS, which in turn will be accessed by the DBPMS. This action intends to prevent wrong data input such as typing mistakes or some inconsistency. Thus, the DBPMS makes a full consistency check before instantiating its internal information models. When this kind of conflict is detected, the user is notified and asked to correct it. An example of one of these graphical user interfaces is presented in figure 7, showing a conflict that has been detected. Figure 7 – Conflict Detection user interface 5.3 Reactive Decision-Making This module receives the conflict identified by the Conflict Detection module and then tries to solve it. It is done by means of the application of a decision protocol, which was based on the case study of the two Prodnet-II end users. The protocol provides “solutions” that represent the set of actions that the (specialised end-user) enterprise uses to solve a conflict. An event picked up from the supply-chain is considered a conflict if it is not previously planned and/or if it affects the normal delivery dates of given BPs. It can be in terms of either order execution delay or anticipation in the order ending. The protocol involves several kinds of actions, such as interactive steps, sending recommendation messages to the suppliers, branches for new search and selection of partners, and rescheduling procedures with the evaluation of results. If the conflicting supplier cannot internally solve a conflict, the VE coordinator should be notified. A conflict may affect only the BP under responsibility of that supplier (i.e. it does not affect the other BPs/suppliers) or, at worst, may affect other VE members. Considering that the prime VE goal is to finish its “product” on time, rescheduling actions are always triggered in order to (try to) keep the delivery date unaltered. The DBPMS user has three possibilities for rescheduling: automatically, semi-automatically, and manually. In each case the rescheduling can be done in the DBPMS by means of the application of three of the most “popular” scheduling strategies: backward, forward and bottleneck, where a given BP is kept fixed and some of its neighbors are rescheduled backward and the others forward. The Reactive Decision-Making module is the one responsible for doing the automatic rescheduling. Based on the conflict analysis and applying one of those three scheduling strategies, a “valid” (re)schedule is automatically generated. According to the protocol, if a valid schedule cannot be found, the DBPMS suggests a BP cancellation to the user. Once a valid schedule is generated, it is passed to the Simulation of Alternatives module. In this module the user can try to improve its quality via either manual or semi-automatic rescheduling. In fact, in that previous case, when a valid schedule could not be generated, the Simulation of Alternatives module is also called so that the user can try to generate it by him/herself, based on his/her experience. 5.4 Simulation Alternatives This module receives a solution (a schedule) from the Reactive Decision-Making module so that the user can refine it and/or evaluate it directly. If the user understands that the “automatic” schedule is “good enough” to take a decision, he/she can set it immediately. But, if the user considers that the suggested schedule can be improved, there is always the chance of changing it semi-automatically or starting the reschedule manually. In the manual way the user “sees” in a graphical interface a Gantt Diagram with the BPs involved and then he/she can work on it making manual changes. In order to avoid invalid specifications by the user, this module “calls” the Conflict Detection module to check them. In the “semi-automatic” scheduling, the Simulation of Alternatives module automatically generates a schedule which can be modified by the user. Moreover the user is also allowed to work on one of the new modified schedules (because they may be better than the previous ones). Then, the user can repeat this process on the “selected” schedule and new other schedules may be generated, until the user is certain that a given schedule is satisfactory enough for him/her. An example of one of the graphical user interfaces of this module is presented in the figure 8, showing the case when the user has to choose a rescheduling strategy. Figure 8 –Simulation of Alternatives user interface 5.5 VE Analyser This module is responsible for providing the user with the quality evaluation of a given schedule “sent” by the Simulation of Alternatives module, or of individual BPs from the VE, triggered by the Monitoring module. The quality of a schedule is evaluated by means of the application of six production indicators (from the VE / inter-organisation point of view), such as number of rescheduled BPs and DBP global extra-time. In addition to that, from the intra-organisation point of view, the rescheduling consequences for each BP can be evaluated through fifteen BP indicators, such as due date, lead time and lateness. An example of one of the graphical user interfaces of this module is presented in figure 9, showing the intra-organisation impact of a given schedule upon a “BP1”. Figure 9 –VE Analyser user interface 5.6 Control It corresponds to a set of actions and advice that should be carried out and be considered in order to “implement” a selected decision. It basically represents what has to be done once an alternative solution is chosen. In the current DBPMS version, the user of the VE-Coordination site works with the DBPMS for decision-making support only. Based on the real data from the supply-chain obtained through the DBPMS monitoring module, he/she can simulate a number of decision alternatives for a possible conflict. With this information he/she evaluates the alternatives and may feed its PPC with it. This means that there is not a direct/on-line integration between the decision simulated / “approved” and the PPC. Firstly this is because the DBPMS is a decision-support system, and not a decision-maker, secondly because a decision that can affect the whole supply-chain cannot be taken unilaterally, but rather after a global negotiation with the other enterprises involved in the modifications/rescheduling suggested by the DBPMS. Finally, because the DBPMS, as an ACF (i.e. acting at the VE level), cannot interfere in the “internal side” of the enterprise. 5.7 Supervision Clause Configuration The need of a "contract" in a VE scenario is the same as it is in traditional relationships between two enterprises. In general, a contract specifies the rights and obligations from one enterprise to another, represented in terms of “clauses”. This specification includes different kinds of clauses, comprising legal, technical and financial information. However, from the supply-chain supervision point of view (i.e. for the DBPMS), an additional and innovative nature of clauses must exist: the “supervision clauses”. Thus, supervision clauses are used to specify rights and obligations in terms of information access for monitoring purposes. In general, they specify what, how, when, where and how far a given set (within “classes”) of information about an order from a given supplier should be monitored (this scenario was illustrated in figure 3). The supervision clauses are an information model logically aggregated to the contract model and are necessary among the VE-Coordinator and Members. In order to facilitate the user task in the specification of the supervision clauses for a given relation VE Coordinator / Member, a set of graphical interfaces was also developed. From the DBPMS point of view, two enterprises cooperate with each other when they reach an agreement on which set of information one should be made available to the other about a BP under their responsibility, so as to allow a BP to be remotely monitored for supervision purposes. The enterprises are not obliged to cooperate in that sense, i.e. depending on the business profile and/or trust aspects, perhaps they may not cooperate. However, if they decide to cooperate, the DBPMS offers a supporting module for configuring the enterprise cooperation behavior. The configuration of the supervision clauses is one of the first procedures the user should carry out once a VE is formed. He/she should specify which information the DBPMS should get from a member in time cycles. This information typically comprises production dates, quantities produced, order status, levels of information “visibility”, decisions about sending auxiliary documentation in parallel or about sending monitoring information (production bulletins) in a text file to a client, etc.. An example of a configuration interface is shown in figure 10. The user should type some data and/or mark the options he/she is authorized to receive / provide, based on the previous general agreement. Figure 10 – Configuration for a given Requested Item Although this configuration will normally take place only in the VE creation phase, it can also be modified during the VE operation. According to the evolution of business and changes on the agreements, the user can modify the previously configured clauses and set them accordingly. Both in the creation and operation phases, the DBPMS allows the user to store/recover supervision clauses according to the time from a “historic file”. Another aspect related to the supervision clause configuration concerns the capabilities of the VEMembers’ PPCs involved. In the DBPMS configuration module, when a VE is going to be configured, the user has to perform an interactive “mapping” between what a certain PPC is able to provide (in terms of “production-related information”) and what it is not. Thus, the “users” (the VE-Coordinator and the respective VE-Member) do not need to waste much time negotiating “access right” levels if the PPC of the VE-Member is, for instance, too poor and hence only able to get little productionrelated information from its shop floor. This configuration step is only carried out if a given member is “new” for the coordinator (it has never worked with it before) or due to changes in the PPC of a previously known member (PPC capabilities, for instance). Completing the frame, a special browser was developed to support the exception handling management in the DBPMS. This is very important for the tool interpretation and VE operation. Through this functionality the user can check the status of all interactions being carried out by the DBMPS and the other modules, by its internal modules and by the user. Moreover, it reduces the risk of crash also allowing the user some possibilities of intervention. 5.8 Integration and Interoperation Mechanism The interoperation between DBPMS and PCL is necessary on two specific occasions. Initially, when the DBP Model - the main information structure of DBPMS - has to be instantiated and filled with information about the VE Members, as well as with the Orders information they have to execute. Later, during the Orders follow-up that involves gathering reliable information, interoperation is required again on three different levels: a generic level (concerning the status of the Requested Orders), an intermediate level (providing the status of the Items composing the Requested Orders) and a detailed level (concerning the Production Orders generated by the VE Member to execute each Item). The level (s) that has (have) to be monitored is (are) specified by the VE-Coordinator in the Configuration Module. To handle both moments, considering those different follow-up levels, two sets of interoperation services are provided according to the Common Interface Specification for PCL Modules Interoperation. Basically, the services request from PCL the necessary information involving either a Local Query Processing or a Federated Query Processing. The former involves mainly DIMS and the latter involves almost all PCL modules. In both cases, PCL answers the requests providing DBPMS with the “keys” to retrieve the information from DIMS, the main PCL data repository. 6. CONCLUSIONS All the research in the literature and the conceptual work presented in this paper were actually motivated by the need to identify some advanced co-ordination functionalities (ACFs) in order to try to avoid business chaos when co-ordinating one or more DBPs of a VE. One of the identified ACFs offers some support to the logistics and it was implemented in a system called DBPMS. This system sets out to support the means for obtaining, providing, and managing production-related information from and about a VE, enabling the enterprises to conduct their logistics more efficiently. DBPMS incorporates part of the concepts from the Supply Chain Management and, mainly, from the Integrated Logistics Management. The DBPMS enables enterprises to work better in an integrated and virtual environment. The system is modular, basically comprising four main interactive and cooperative modules: VE Supervisor (to monitor the DBP execution), DSS (Decision Support System, to help the user in the decision-making process based on the information received by the VE Supervisor), Supervision Clause Configuration (where the rights and duties of the VE Coordinator and Members of a given VE are specified) and Interoperation (for the interoperation support between the DBPMS and the other Prodnet modules). DBPMS has been implemented on a PC/Windows-NT/ C++ platform and, in summary, it can be said that its main features are: Ä Order follow-ups of the supply-chain, based on “supervision clauses” associated with the BP’s (orders) contracts; Ä Interactive support for conflict analysis and resolution in the order processing, via reactive decisions; Ä Configuration for each particular enterprise (way of operating); Ä General support for Distributed Requirements Planning (DRP), since basic VE scheduling actions are provided; Ä Integration with PRODNET Cooperation Layer (PCL): − information integration: via PCL’s DIMS module; − safety communication: via PCL’s PCI module; − interoperation with the PCL’s workflow engine module; − interaction with the internal PPC: via PCL; In addition, it should be pointed out that, considering the DBPMS complexity, the innovative aspects that remain to be investigated and the open questions still present in the VE paradigm, the experiments to be exploited by each DBPMS module had limited scope and scenarios. Besides that, they were tested only with the Prodnet-II platforms and oriented to a specific demonstration pilot prototype. The research being carried out nowadays by the group responsible for the development of DBPMS (The Intelligent Manufacturing System Group – G-SIGMA) lead us to conclude that the next step of the Advanced Coordination will go in the direction of Smart Coordination. According to Filos (1999), Smart Organization is represented by a business environment in which clusters of inter-networked organizations collaborate around a particular technology and make use of a common architecture to deliver independent elements of value that grows with the number of participating organizations. As an upper level of abstraction, smart coordination will require the consideration of the whole dynamic supply chain (production chain + sales chain) within a smart organization environment (Pereira Klen & al., 2000). ACKNOWLEDGEMENTS The authors would like to thank CNPq (The Brazilian Council for Research), project ProTeM-CC 680120/96-3 PRODNET-II, and European Union, Esprit project 22647 PRODNET-II for the financial support as well as all the project partners. Special thanks to the DBPMS development team of GSIGMA, namely Mr. Allan Keller, Ms. Regina Bússolo, Mr. Rodrigo Ardigó and Mr. André Jacomino. REFERENCES 1. Afsarmanesh, H., Garita, C., Hertzberger, L.O. (1998) Virtual Enterprises and Federated Information Sharing, in Proceedings of the 9th IEEE International Conference on "Database and Expert Systems Applications", DEXA'98, Lecture Notes in Computer Science, Vienna, Austria. 2. Bowersox, D. J. and Closs, D. J. (1996) Logistical Management – The Integrated Supply Chain Process; McGraaw-Hill. 3. Camarinha-Matos, L.M., Afsarmanesh, H., Garita, C., Lima, C. (1998) Towards an architecture for virtual enterprises. The Journal of Intelligent Manufacturing, Vol. 9, Issue 2. 4. Camarinha-Matos, L.M, Lima, C.P. (1999) Coordination and Configuration Requirements in a Virtual Enterprise, in Proceedings of the Working Conference on Infrastructures for Virtual Enterprise (PROVE’99), October 27-28, Porto, Portugal. 5. Christopher, M. (1994) New directions in Logistics, Logistics and Distribution Planning – strategies for management, ed. by James Cooper, Kogan Page Limited, 2nd edition. 6. Filos, E. (1999) Virtual Organisations, Business Networks & the 5th Framework Programme, Invited Speech of the Working Conference on Infrastructures for Virtual Enterprise (PRO-VE’99), October 27-28, Porto, Portugal. 7. Leach, N. P. et al. (1996) Supply Chain Control: Trade-Offs and System Requirements; Proceedings of the ESPRIT – COPERNICUS Symposium, Budapest, Hungary. 8. Møller, C. et al. (1994) Logistics Concept Development – A new Approach to Overall Integrated Logistics Modelling and Design, IFIP Working Group 5.7, Working Conference on Evaluation of production Management Methods, Brazil. 9. O’Neill, H. (1995) Decision Support in the Extended Enterprise, Ph.D. Thesis, Cranfield University, England. 10. Osorio, A. L.; Gibon, P.; Barata, M.(1998) Secure electronic commerce in virtual enterprises of SMEs, presented in Basys’98, IEEE IFIP International Conference on Balanced Automation System, Prague, Czech Republic. In Intelligent Systems for Manufacturing – Multi-Agent Systems and Virtual Organizations, Eds. Luis M. Camarinha-Matos, Hamideh Afsarmanesh and Vladimir Marik, Kluwer Academic Publishers, pp. 207-218. 11. Pereira Klen, A.A.; Rabelo, R.J., Spinosa, L.M; Ferreira, A. C. (1998) Integrated Logistics in the Virtual Enterprise: The Prodnet-II Approach, to be presented in IMS’98 – 5th IFAC Workshop on Intelligent Manufacturing Systems, Gramado – Brazil. 12. Pereira Klen, A.A.; Rabelo, R.J., Spinosa, L.M; Ferreira, A. C. (1999) Distributed Business Process Management, in Proceedings of the Working Conference on Infrastructures for Virtual Enterprise (PRO-VE’99), October 27-28, Porto, Portugal. 13. Pereira Klen, A.A., Rabelo, R.J., Ferreira, A. C (2000) Enabling Supply Chain Management through Advanced Coordination, to be presented in WAC 2000 – IEEE World Automation Congress, Hawaii, USA. 14. PRODNET, (1999) http://www.uninova.pt/~prodnet 15. Rabelo, R. J., Camarinha-Matos, L. M. (1996), Towards Agile Scheduling in Extended Enterprise, em "Balanced Automation Systems II - Implementation Challenges for Anthropocentric Manufacturing", Eds. Luis M. Camarinha-Matos and Hamideh Afsarmanesh, Chapman & Hall. Proceedings BASYS'96 - IEEE / ECLA / IFIP - International Conference on Architectures and Design Methods for Balanced Automation Systems, Lisbon, Portugal. 16. Rabelo, R.J., Spinosa, L. M. (1997) A Mobile-agent-based approach in supply-chain supervision in the food industry, Proceedings Agosoft'97 / Workshop on Supply-Chain Management, Vitoria, Brazil. 17. Slats, P. A., et al. (1995) Logistics Chain Modelling, European Journal of Operational Research No. 87, 1-20. 18. Spinosa, L.M., Rabelo, R.J., Pereira Klen, A.A. (1998) High-Level Coordination of Business Processes in a Virtual Enterprise, in Proceedings of Prolamat'98 / The Tenth International IFIP TC5 WG-5.2 WG-5.3 Conference, Trento, Italy.