Infrastructure developments for agile virtual enterprises - Uninova

Int. Journal of Computer Integrated Manufacturing, ISSN 0951-192X, Vol. 16, N. 4-5, Jun-Aug 2003

Infrastructure developments for agile virtual enterprises L. M. Camarinha-Matos1, H. Afsarmanesh2, R. J. Rabelo3 1

New University of Lisbon, PORTUGAL Quinta da Torre, 2829 Monte Caparica, Portugal, [email protected] 2 University of Amsterdam, THE NETHERLANDS Kruislaan 403, 1098 SJ Amsterdam, The Netherlands, [email protected] 3 Federal University of Santa Catarina, BRAZIL UFSC/DAS Cx. Postal 476, Florianopolis, SC, Brazil, [email protected]

Abstract. Agility is an important requirement for successful organizations in periods of market turbulence and largely unpredictable socio-economic changes. Agility in a virtual enterprise depends not only on the skills of its member enterprises but also on the characteristics of its supporting infrastructure. In this paper various requirements and approaches for agility support during the full VE life cycle are presented and topics requiring further research are identified. Finally two practical application scenarios are introduced and learned lessons presented.

1. Introduction As a reaction to the highly dynamic market challenges, and taking advantage of the facilities offered by the advances in the information and communication technologies, enterprises are increasingly operating in cooperative networked environments. As such, enterprises seek for complementarities that allow them to participate in competitive business opportunities and new markets. Therefore, in a network of enterprises, sometimes even competing enterprises act cooperatively, and sometimes these same enterprises act independently and concurrently. In the current market scenario, recent trends in industry are also emphasizing the relevance of agility, understood as the ability to recognize and rapidly react and cope with the unpredictable changes in the environment (Goranson, 1999, Kidd, 1994), with a smooth adaptation of its entire structure to the new / current reality. The concept of virtual enterprise (VE), understood as a temporary consortium of enterprises that strategically join skills and resources, supported by computer networks, to better respond to a business opportunity, embeds an implicit notion of agility. The idea of highly dynamic organizations that form themselves according to the needs and opportunities of the market and that remain operational as long as these opportunities persist is commonly associated to this concept. Once the business case ends, the organization dismantles itself although its members will continue to exist and will probably participate in other such dynamic consortia. The composition of a VE is determined by the need to associate the most suitable set of skills and resources contributed by a number of distinct individual organizations. When and if necessary, the VE can reorganize itself by adding / expelling some members or by dynamically re-assigning tasks or roles to its members. The VE paradigm suggests, therefore, an inherently agile organization. This does not necessarily mean that each member of the VE is an agile enterprise. In fact there is even the risk that companies that are overspecialized in their core competencies, and especially in the case of SMEs with limited resources, become vulnerable when the changes in the market determine that their core skills are less important. Several authors have advocated outsourcing and the need for companies to focus on a reduced set of core competencies, towards lean enterprises, in order to reach world class in those areas. In fact, this has been observed in some enterprises over the

1

world, which put more emphasis on production optimization than on product flexibility. From a more abstract point of view, the competitiveness required from the enterprises in a global market is slightly changing some earlier “academic forecasts” that pointed out the need for extreme high degree of flexibility in industries. It is right that the large enterprises, typically the core industries in an extended/virtual enterprise or in a supply chain, keep a level of flexibility in all levels. However, in some cases the “satellite” enterprises are becoming more optimized, producing a lower product variety, which reduces the agility of these individual companies. The highly unpredictable directions of the market change and the fast speed of this change suggest however, that in order to survive companies should keep a balanced set of competencies and the capability to develop new competencies even at the price of being less lean. On the other hand, the actual presence of agility in a VE depends on a number of technical, legal, cultural, and socio-organizational factors. In technological terms there is a need for a commonly accepted, highly flexible, secure and robust infrastructure to support agility along the life cycle of the virtual enterprise. The legal framework of the countries may represent an obstacle to agility, especially when there is not yet a wide body of knowledge on cooperation agreements and contractual regulations for this type of organizations (Scherer, 1997, Goranson, 1999). As pointed out by Goranson, companies operating under code-based laws, requiring extensive contract definitions, show less agility than those operating under a case-based law context. Additional difficulties arise when a VE is composed of enterprises operating in different legal frameworks, for instance, when different customs policies, taxes, consumer rights, etc., applies. Even more, another difficult issue is the management of intellectual property that is generated as a result of a cooperative multi-party effort. Finally the cultural and socioorganizational aspects are key issues for both the implantation and agility of the VE paradigm. Creating a culture of cooperation, trust building, bridging inter-cultural differences, redefining the internal organization of the companies, defining new internal roles, and planning appropriate training programs, are major challenges faced by enterprises. This paper, which is a revised and extended version of a presentation made at the PRO-VE 2000, the 2nd IFIP Working Conference on Infrastructures for Virtual Enterprises (CamarinhaMatos, Afsarmanesh, Rabelo, 2000), is mainly focused on the technological requirements to support agility in a VE. The discussion of these requirements and proposed solutions follow the typical major phases of the VE life cycle (Fig. 1), namely the creation, operation, reconfiguration, and dissolution (Camarinha-Matos, Lima 1998, 2001). Creation

Operation

Dissolution

Evolution

Figure 1 – Main typical phases in the VE life cycle This work is based on the research activities and experiences acquired in various European projects, with particular relevance to the Esprit PRODNET II (Camarinha-Matos and Afsarmanesh 1999), INCO-DC MASSYVE (Rabelo et al. 1999), and IST FETISH-ETF (Afsarmanesh, Camarinha-Matos 2000). The paper first carefully addresses and describes the main steps and requirements for provision of agility in sections 2 to 5. Then in section 6 two example cases from the mentioned projects will be provided emphasizing the application of this agile infrastructure in manufacturing scenario cases. Section 7 introduces a number of additional issues that remain as key challenges for the practical development of virtual enterprises.

2

2. Virtual enterprise creation 2.1 Major steps Once a business opportunity is detected, there is a need to rapidly plan a suitable VE, identify partners and roles, and establish cooperation agreements to regulate the operation of the VE. In order to help the VE creator (VE coordinator, VE architect, or broker) the support infrastructure should provide a set of specific service functions. A number of international R&D projects have contributed to the identification and partial development of some of these functionalities. For instance, some of the major steps and required functions in VE creation were identified by PRODNET (Fig. 2). The first two steps of setting up infrastructure resources and manifestation are preparatory operations to make a company ready, from the infrastructure point of view, in order to participate in VEs which end with the registration of the company in a public directory or cluster of enterprises willing to cooperate. When a business opportunity is detected, there is the need to plan and create the VE, establish the contract or cooperation agreement among partners, and configure the infrastructure to operate according to this agreement. PRODNET II developed some tools to support some parts of the creation process. Setup Infrastructure Resources E

Decide on Computational resources Install Computational resources

Enterprise profile definition

E

Manifestation

VE Infrastructure configuration Registration in cluster directory

VE Creation/ C Evolution

Partners Search and Selection VE Network Definition Distribute selected VE config. data

Contract Negotiation/ E Re-negotiation C

Enterprise Configur./ E Re-configuration

Identification of business opportunity Plan VE

VE Initiation agreement

Establish Contract Technical Information Supervision clauses Distribute selected supervision data Load VE net def./. supervision clauses Access rights definition Specific config. for each PCL module

Modification

VE operation E C

Activity to be performed for each enterprise

Activity supported by some PRODNET tools Activity not supported by PRODNET tools

Activity to be performed by the VE creator / coordinator

Figure 2 – Major steps and required functionalities in VE creation Other projects such as the Brazilian VIRTEC (Jairo, Bremer, 2000), the ALFA COSME-VE (Molina et al., 2000), and COWORK (Alzaga and Martin, 1999) have addressed the specific aspects of creation and management of clusters of enterprises. The concept of a cluster of enterprises, which should not be confused with a VE, represents a group or pool of enterprises that have the potential, and the will, to cooperate with each other, and therefore they become partners in a VE once a business opportunity is found by one of the cluster members (Camarinha-Matos, Afsarmanesh, 1999). The cluster enterprises are normally “registered” in a directory, where also their core competencies are “declared”. Based on this information, the VE initiator / creator can select partners when a new business opportunity is detected. Clearly, several VEs can co-exist at the same time within a cluster, even with some members in common. 3

A cluster represents a long-term organization and therefore, an adequate environment for the establishment of cooperation agreements, common infrastructures and ontologies, and mutual trust, which are facilitating elements when building a new VE. The establishment and management of clusters through adequate infrastructures, represents therefore an important support for the creation of agile virtual enterprises. Also other projects such as ViVE have focused on the understanding and modeling of distributed business processes as a step in the VE creation process. Further work is necessary in order to develop generic planning tools integrating the VE planning, the high-level business processes modeling, the distributed resources planning and the multi-party capacity planning. The solutions provided by various projects for these issues remain very specific for particular applications. 2.2 Partners search and selection The selection of business partners is a very important and critical activity in the operation of a company. Similarly, and even in a more acute way, selection of partners is a very important process in the life cycle of a VE. Partners search can be based on a number of different information sources, being private, public, or independent. The enterprise’s private suppliers’ list – an important asset of a company - is a data repository that contains information about the companies that have had commercial relationships with this enterprise. This information is usually maintained by the ERP or PPC System, composing an Internal Suppliers Directory. External sources include directories maintained by industrial associations, commerce chambers, or Internet services already available for several countries and that offer WWW interfaces to a database of enterprises served by a local search engine, the External Suppliers Directory (ESD). As mentioned above, another emerging solution is the creation of clusters of enterprises that agree to cooperate and whose skills and available resources are registered in a common Cluster Directory . The search based on Internal Suppliers Directory can take advantage of previous knowledge of partners and cooperation experience, leading to higher confidence on the relationships. The suppliers are usually ranked according to some particular criteria and specialized decision support systems can be used to speed up the partner’s selection process. But even when this information source is available, for some business opportunities it might be necessary to look for new partners when new skills or more resources are necessary. In PRODNET II both Internal and External directories were considered. Fig. 3 illustrates the main steps when searching for partners in Internet based directories (Camarinha-Matos and Cardoso, 1999). Remote Search Engine

General Query Generator Filter Potential Suppliers

Potential Suppliers’ Contacts

ESD External Suppliers Directory

Remote Search Engine

ESD

Internet

“Call for Tenders”

Potential Decision Support System

Supplier

Potential Suppliers’ Bids

Potential

Contract Generation

Potential Supplier

Supplier

Figure 3 – Partners search and selection based on external directories

4

A typical difficulty – and an obstacle to agility – is the current dependency on the specific formats and access interfaces of each ESD. The lack of a standard interface and standard representation of enterprise profiles does not facilitate the development of generic tools. Recent initiatives such as UDDI, if successful and although not sufficient, might constitute one step towards the development of harmonized directories. These problems can be eliminated when the search is restricted to controlled clusters of partners. Within a cluster it is possible to establish a common model for the enterprise profiles tailored to the needs of a broker responsible for VE creation. The VIRTEC, COSME-VE, and COWORK projects are examples of this approach. Similarly to the case of Internal Suppliers Directory, the Cluster Directory can maintain knowledge about the past cooperation experiences and partners performance, constituting important information for the partners search phase. The cluster directory, although maintained by a cluster manager, is available to the various members of the cluster that can take the initiative to create a VE. Whenever a new member joins the cluster it has to comply with the registration rules of the Cluster Directory. One approach to partners search within a cluster is proposed by the MASSYVE project (Rabelo, Camarinha-Matos, Afsarmanesh, 1998), (Rabelo, Camarinha-Matos, Vallejos, 2000). Instead of resorting to a classic centralized directory, a multi-agent approach based on the negotiation paradigm (Davis and Smith, 1983) is adopted. The proposed system includes a broker agent responsible for handling business opportunities, a facilitator agent, consortium agent(s) that design and plan the potential VE(s) and negotiates with potential partners within the cluster, and a set of agents representing the enterprises participating in the cluster. Once a business opportunity is acquired, the facilitator makes a pre-evaluation of possible partners by comparing the required skills and resources with the profile and current status of the cluster members. The contract-net protocol is then used to collect bids from cluster members and select the most adequate ones based on the costs and delivery dates for instance. Figure 4 illustrates this process. In case the cluster does not cover all the requirements, a more general search for partners can be performed through Internet directories of enterprises. Mould_i mould_size 2 tons mould_type mould mould_material aluminum due_date 28/12/00 max_price 90.000 I can do it only if ...

I accept it !

Me too

I cannot make that !

I will be in maintenance

I accept it too !

I know how to do that !

Total Cost & Delivery Date

I’m free in that period

EPS Tool

Shopfloor

Selected Enterprise_Agent for the mould

Figure 4 – Negotiation mechanism applied to a cluster of enterprises Some other works such as (Rocha et al., 1999, Davidrajuh and Deng, 2000, Huang, Liu, Wu, Gou, 2000) have pursued a multi-agent-driven automated solution for brokerage / partners search. However, a major difficulty with their approach lies in the lack of a universally accepted 5

framework for agents’ interoperability. In fact, currently enterprises are not represented as agents in the cyberspace, and the lack of a standard will be a major obstacle for the dissemination of this approach. One of the distinctive aspects of the MASSYVE approach is its hybrid / semi-automatic philosophy in which agents are used as human assistants. The fact that the MASSYVE approach is focused on clusters of enterprises, i.e., a controlled multi-agent universe, makes it a feasible solution from the implantation point of view, since a common modeling framework can be adopted by all members of the cluster. An example application was developed for a cluster in the moulds industry in Brazil (Rabelo, Camarinha-Matos, Vallejos, 2000) and will be described in section 6.2. An alternative approach to implement a flexible partners search is based on the concept of federation of services as for instance proposed by JINI (SUN, 1999). The JINI architecture can support, in a transparent way, a federation of service functions offered by different service suppliers and running on different nodes of a network. Special directories – JINI Lookup Services – provide the registration of service specifications and the associated functions to search such services based on a configurable search criterion, see Fig. 5. According to this model, enterprises should be able to plug/unplug their services to/from the service directories, and clusters must agree on a proper “standard” service interface. Service interfaces aim at supporting the interoperability with other (requesting) enterprises, regardless of the heterogeneity associated with the actual implementation of the services themselves. This means that no matter how the service is actually implemented, in terms of the computer platform, operating system, programming language, internal modules, etc., there is a client service interface that can be managed by the lookup service and made available to other enterprises that may request it. Although JINI may contribute to facilitate the interoperability among services offered by different enterprises, its use in VE environments requires the development of additional support functionalities. For instance, in VEs the matter of access rights and enterprises information visibility is a very important issue, and therefore when searching and accessing a specific service type it is also relevant to determine both the supplier of the service and the requesting client, in order to check such visibility rights. It is also necessary to define the rules for both service specification/definition and service registration through the service interface. Furthermore, the general acceptance of the service interface by the service providers for developing services compliant with such rules is of great importance. This can be easier achieved within the context of a cluster of enterprises. Therefore the JINI system for instance can be used as an extension to the current cluster directories of enterprise profiles. A VE support infrastructure for the tourism industry following this approach is being developed within the IST project FETISH-ETF (Afsarmanesh, Camarinha-Matos, 2000), (Camarinha-Matos et al. 2001). SPN

Wrapper_S1

SPN

Client

Lookup service

SPN

ValueAdded Added Value Service Service definition definition

Wrapper_S1

Service Catalogue

Access Access Rights Rights Manager Manager

Service Promoter Nodes

Service Implementation

Service_S1 Other services

Figure 5 – JINI-based cluster manager 6

SPN

2.3 Configuration aspects The ease of configuration of the VE, using the VE support infrastructure, is a major requirement for agility. In order to cope with the diversity of virtual organization types and different business practices adopted by different companies, the VE support infrastructure should allow an easy configuration of the desired behavior. Configurability was a major design requirement in the PRODNET infrastructure. PRODNET provides tools for configuration of its different services (i.e. besides the internal configuration of each of the infrastructure modules). For instance, to support enterprise’s autonomy in definition of its behavior and the rights for other enterprises, the PRODNET infrastructure provides: Workflow-based graphical definition of the VE nodes behavior regarding each cooperative event, via the node’s local activity coordination module. However, in spite of the recent progresses in the workflow management systems, they are not very flexible in terms of dynamic changes of the workflow plans. Similarly, the area of project management support tools, especially when involving consortia formed by people from different organizations, can benefit from flexible negotiation-based scheduling and supervision. In particular, the introduction of agile scheduling, relaxation of constraints, tasks re-assignment, etc., are particularly promising here. Configuration of data access rights and information visibility levels, via the export schemas in the node' s federated information management module. These schemas are defined at the VE-members providing the proper visibility rights for the VE coordinator according to the supervision clauses defined in the VE contracts. Setting and configuration of the used common technology for the VE, and the communication characteristics, via the selection of data exchange standards (EDIFACT, STEP, …) and security mechanisms (cryptography, digital signature, …). In spite of these tools, and because of the VE infrastructure proposed by PRODNET involves many technologies and paradigms, the practical implantation requires a diversity of specialized knowledge for installation and configuration, what may be a major obstacle for SMEs and small system integrators. Although a more automated installation is desired, this requires a more stabilized technology, as well as special consideration at the system design phase. In either case, the configuration effort is always larger for the first time that an enterprise participates in a VE, since at this stage the socio-organizational issues and all the required business process reengineering also need to be addressed, to properly support the enterprise for its VE participation. In the case of industry clusters, foreseeing a long-term cooperation, the costs of implantation and configuration efforts can be more easily absorbed and accepted by enterprises than in the case of a single business VE.

3. Virtual enterprise operation Agility is also required at various levels during the VE operation, in order to cope with the unexpected changes in the environment. 3.1 Agility and distributed business process coordination When a Business Process (BP) is executed by a virtual enterprise parts of the decomposition of this BP (i.e. sub-processes) are assigned to different enterprises, becoming a Distributed Business Process (DBP) (Rabelo et al., 1996) (Camarinha-Matos 2001) or a virtual business process in the WISE terminology (Alonso et al., 1999). The problem of the supervision or coordination of a DBP at its various levels of decomposition becomes very important in this

7

context where its definition and enactment is not limited to a single organization, but instead to a set of autonomous, distributed and heterogeneous nodes that need to cooperate. When properly “orchestrated”, the various processes taking place in the different members of the VE are expected to lead to the achievement of the global goals of the VE. The VE coordinator is responsible for the coordination of the entire DBP execution, while the VE members are responsible for the coordination of the sub-BPs assigned to them. The VE coordinator may itself act also as a VE member. As such, the VE coordinator can also be responsible for a particular sub-BP. Furthermore a VE member may itself become the coordinator of a sub-VE inside the VE to coordinate (or supervise) its sub-BP when parts of this sub-BP are assigned to different partners. Under this approach, temporary (sub-) consortia can be formed inside a VE and so on. These sub-consortia are formed for the sole purpose of facilitating the coordination of activities involved in the related sub-business processes. Once a sub-business process ends, the sub-consortium “dissolves” and its members may become involved in other sub-consortia dynamically formed in this or other VEs as the execution of the VE DBPs evolves. For instance, the enterprise C (in Fig. 6) coordinates sub_VE1 and is a member of sub_VE2. Once a global business process is defined, scheduled and responsibilities are assigned to each individual partner, the successful achievement of the common goal – delivery of the final product or service to the client – depends on the proper and timely operation of each VE member (and each supporting service in each VE member). A delay, failure, or even an anticipation of a failure in one node, if not properly attended in time, may jeopardize the common VE goal. Therefore, it is necessary to properly manage (supervise) the inter-dependencies among various (distributed) BPs. Business Opportunity

B VE coordinator

BP0

E

BP1

A

BP3

BP2

BP2.1

VE members

VE

BP2.2

Sub-VE1

Sub-VE1 coordinator

BP3.1

Sub-VE2 coordinator BP3.2

Sub-VE2

C

D

BP coordination BP execution

Figure 6 – Example of distributed execution of a DBP This idea of dynamic formation of sub-consortia inside a community of cooperating agents (a VE) in order to coordinate sub-business processes is being exploited by the MASSYVE project (Rabelo et al., 1999), providing higher levels of agility within the enterprise. The process of BP assignment is similar to the one illustrated in Fig. 4, but the set of target agents is now restricted to the members of the VE and not the full list in the cluster. Several languages and formalisms have been proposed for BP modeling and coordination. In the VE area many projects, such as the case of PRODNET II (Camarinha-Matos and Lima, 2001), adopted a workflow-based approach due to both availability of experience with workflow systems in many enterprises and the standardization efforts promoted by the Workflow Management Coalition (WfMC, 1994). Regarding BP modeling and execution, two major but distinct approaches – a bottom up and a top down - have been followed by different research projects focused on Virtual Enterprises. 8

While flexible infrastructures are not properly addressed, a few projects have followed a bottom up approach, trying to support the main functional VE requirements for both the information exchange and basic coordination of inter-enterprises activities. Once these services are guaranteed, the efforts are progressively directed towards the support of the BP execution. Meanwhile, a second group of projects have devoted their efforts to the identification of the major BPs common to the VE, and their decomposition into some key areas of manufacturing, without paying enough attention to the base VE infrastructure requirements. However, although important, modeling BPs brings little benefit to the actual operation of the VE, if the VE is not supported by an execution infrastructure – namely the VE execution system (fig.7). It is therefore necessary to “close the gap” between these two approaches. There are not yet projects and initiatives covering this aspect properly what in turn reinforces the need for the design and development of comprehensive and effective VE reference models. Business Opportunity

DBP Modeling & Planning

BPDBP Model Model

VE Execution System or VE Infrastructure

Enterprise resources

Figure 7 – VE Execution System PRODNET II, although mainly aims at the first approach, also addresses (although not supporting it) the coordination of BPs within the VE, at different levels of abstraction, see Figure 8. The proposed infrastructure extends the functionalities of each VE member (represented by the enterprise applications such as ERP/PPC, PDM, CAD, etc.) with a Cooperation Layer responsible to handle all enterprises cooperation events. Central to this coordination kernel are a Distributed/Federated Information Management System and a workflow-based Coordination Engine. A safe Communications Infrastructure and a library of support services complete the Coordination Layer; see Figure 8. The complete description of the layered hierarchical coordination architecture of PRODNET is described in (Camarinha-Matos and Lima, 1999).

9

PCL - PRODNET Cooperation Layer

Network

Configur. & Interface

Service

...

VMF Service

ECL- Enterprise Cooperation Layer

Coordination kernel PCI

LCM

VE Management Functionalities

DIMS

EMF- Enterprise Management Functionalities

CCL- Core Cooperation Layer

Figure 8 – PRODNET Infrastructure 3.2 Complete support or controlled transparency for the customer Interaction with the customer during the full life cycle of the business process is a major facet of agility. New management objectives focused on pursuing customer satisfaction imply not only the supply of up to date information to the customer, but even his/her involvement in the process. Regarding the information access, once an infrastructure such as the PRODNET Cooperation Layer is established, adequate information visibility / access levels for the customer can be easily defined, and if necessary later reconfigured, using the mechanisms provided by the federated/distributed information management system (DIMS) of the PRODNET (Afsarmanesh et al., 1999). But true agility is only achieved when the customer is not just a passive observer but also an actor having some capability to intervene in the process. For instance, in some cases, the customer may change the order requirements or be an active member in a conflict resolution process (re-scheduling, for instance), or even an active partner in the product / service definition. For this purpose a new type of actor – the customer – has to be defined in the VE environment, specific interface front-ends must be provided for the customer by the VE coordinator (for instance, via a web browser), and furthermore suitable distributed business processes and a set of specific monitoring workflows may need to be created. It shall be noted that some logistic operators already provide some primitive steps in this direction that in addition to giving the customer some information about the status of his/her order, also allow them some interaction (even cancellation in some cases). A similar approach can be extended to the manufacturing process as well. One approach in this direction is supported by the PRODNET DBPMS module, which through e-mail periodically sends “production bulletins” to the customer, both in text and HTML formats. Furthermore, to better support customer' s monitoring of the activities related to the order, a "push mechanism", for sending the information from the legacy ERP/PPC to the cooperation layer, needs to be implemented. In PRODNET three modules together support the implementation of this push mechanism. On one hand, the configuration of information visibility levels, is supported by the federated information management of the DIMS module, on the other hand the configuration of the contract-based monitoring functionalities is supported by the DBPMS module, and further execution of the this process supported by the Local Coordination Module (LCM), which provide the base platform for pushing the status information from the VE-members to the VE coordinator, that in turn can make it available to the customer.

10

Another facet is the remote supervision, and even interaction with the local processes taking place at the shop-floor of each VE member. In some cases, the customer may want to “see” and participate on the run time decisions being made on the remote shop-floors (according to contractual rules). The local supervision functionalities installed in each production site shall interact / cooperate with global VE (network-wide) supervision, providing controlled levels of transparency. For this purpose, recent developments in the areas of virtual laboratories, remote operation and virtual reality can be adopted. In this direction one experiment developed at the New University of Lisbon applies intelligent mobile agents that are sent to the remote sites carrying high-level abstract plans (missions). When arriving at the target destination, the mobile agents refine their plans according to the actual capabilities found in that destination, what provides a high level of agility (Camarinha-Matos, Vieira, 1999). Another perspective is related to a wider vision of the inventories and enterprises capacities aiming at a better supply chain management. The scope of supply chain management under an integrated logistics management covers the flow of goods from supplier through manufacturing and distribution chains to the end-user. This concept suggests a holistic approach to material and information flow management. Partnership and trust aspects are introduced as important elements in this kind of supplier relations. Actually, the basic notion of supply chain management is grounded on the belief that efficiency can be improved by sharing information and by joint planning. Therefore, a global and more profitable supply chain can be achieved in the sense of more balanced / negotiated planning based on an entire optimum perspective (Klen et al., 1998).

4. Virtual enterprise reconfiguration During the operation of a VE it might be necessary to replace some partner or change the roles of some partners. This is the case, for instance, when there is a scheduling conflict to resolve at the DBP level. A partial solution is given by the DBPMS module of PRODNET (Klen et al. 1999). A more general solution can be achieved with dynamic scheduling solutions as proposed by the MASSYVE project following the negotiation paradigm. MASSYVE is investigating the application of multi-agent approaches to agile scheduling in virtual enterprises. A component-based approach is adopted in this project that integrates previous work on multi-agent based scheduling inside an enterprise (the HOLOS system (Rabelo, Camarinha-Matos, 1996) ) with the federated information management (the DIMS/FIMS system (Afsarmanesh et al., 1999, Garita et al. 2000) ) and extends the approach to VE (Rabelo et al., 1999, Rabelo et al., 2000). A multi-agent scheduling system is composed of a set of “processors” (nodes in a network of manufacturing resources), each one with its own particular capabilities (typically heterogeneous), that have to exchange and process information in order to contribute to finding a solution to the global scheduling problem. These agent nodes represent either enterprises, when the scheduling problem is discussed at the VE level, or the internal manufacturing resources of a company when dealing with the internal scheduling of tasks assigned within a company. Several problems can arise during the schedule generation, after its generation, and during its execution, such as the temporal, capacity, or technologic conflicts. These problems come from the planning, scheduling or execution supervision activities. There are several methods that can be applied for conflict resolution in a multi-agent system. As previously mentioned, MASSYVE uses the Contract-Net Protocol mechanism to support the task assignment among the agents, and the Negotiation method to overcome conflicts taking place during one of the three mentioned scheduling phases. The proposed agile scheduling system in MASSYVE is a collection of classes of agents that are configured for each particular

11

scenario. For each of the two levels – VE or enterprise level - four classes of agents are responsible to perform certain coordination tasks: • Scheduling Supervisor (SS): is the class whose (unique) instance performs the global scheduling supervision. • Enterprise Activity Agent (EAA): is the class whose instances are associated to the production resources, i.e., resources are represented by EAA. These agents are the executors of tasks. • Local Distribution Centre (LDC): is the class whose instances represent functional clusters of EAAs in order to avoid announcement broadcasting and hence to make the selection of an EAA faster. They are also responsible to select the most suitable agent for a certain task after the negotiation process. • Consortium (C): is the class whose instances are dynamically created to supervise (locally and in a decentralized way) the schedule of a logical arrangement of EAAs selected to execute an entire task or BP. When the scenario is intra-organizational scheduling (i.e. scheduling of the tasks / BPs assigned to a particular enterprise), these classes can have the following interpretation: - The Scheduling Supervisor is the coordinator for all tasks assigned to the enterprise. - The Enterprise Activity Agents represent the various internal resources. For instance, an EAA can be associated to each machine in the shop floor, being responsible to acquire new contracts to this machine and to report about its status. - A Local Distribution Center represents a cluster of internal resources. - A Consortium is a temporary association of agents involved in the execution of a task or BP inside the enterprise. Please note that a given BP awarded to a company by a VE supervisor can be further decomposed (internally) in a sub-tree of BPs and enterprise activities. For the inter-organizational scheduling (i.e. high level scheduling of BPs at the VE level), the following interpretation applies: - The Scheduling Supervisor is the global coordinator of the DBP, running at the VE coordinator node. - The Enterprise Activity Agents are representatives of the VE members. Therefore, an EAA representing an enterprise coincides with the internal SS of that enterprise. - The Consortium corresponds to a group of agents, representing a subset of enterprises that are involved in the execution of a given BP. Figure 9 illustrates this scenario. There are two enterprises shown in this picture, A and B. Assuming that A has triggered the entire process of contracting and managing the production of a given product, it is viewed as the business process coordinator. Through the Internet, A can manage the suppliers (B, in this case) involved in this production/business. Each of the involved enterprises is represented by an agent - the enterprise-agent - acting in the same perspective that a Scheduling Supervisor does. At this level, an enterprise-agent supervises a set of Consortium agents. At the Consortium level, each Consortium supervises a set of EAA agents. At the EAA level, each EAA agent supervises one (or more) machine(s). Both intra-organizational and inter-organizational schedules are generated and supervised via a cooperative and tightly coordinated information exchange among agents.

12

Enterprise A

(the Coordinator)

VE schedule

Enterprise agents

Internet

(a Supplier)

Enterprise B

Enterprise agents

distributed / local schedule

Consortium agents

EAA agents

Figure 9 – Multi-agent-based inter-organizational scheduling scenario. In a MAS approach, the cooperation among agents is traditionally supported via message passing, with the communications protocol acting as the vehicle to transport control and data together. An interesting concept investigated in MASSYVE is that the data is not sent from one agent to the other via a high-level protocol, as in the traditional push strategy, but rather through pull strategy via the access to a federated information management system (FIMS) associated to each agent (Rabelo et al., 1999; Rabelo et al., 2000). Thus, the high-level protocol is used for coordination purposes only, while massive data exchanges are performed by FIMS. Figure 10 illustrates this approach. Consider the case that a given enterprise (B) processes some information and generates some results (for example r-17) that should be sent to another enterprise (A). Then Agent-B sends a message to Agent-A (represented by 1), communicating that certain information (r-17) is available in its local database (that can be accessed through its export schema). Please notice that the access rights for the shared data among nodes is dynamically and bilaterally configured, according to the role and the needs of every node and preserved through the export schemas. Therefore, once this message is received at Agent-A, whenever it wishes A can retrieve this updated information (r-17) from B. However, this access and transfer of information does not occur between the two agents, rather it occurs between the two information management modules (FIMSs) of the two enterprises. Namely, enterprise-A, through its integrated schema at the FIMS sends a request to access r-17 to FIMS-B (represented by 2), using the federated mechanisms for information access – that receives the authorized information (r-17) from B (represented by 3). The details of this interaction are outside the scope of this paper and the subject of forthcoming publications.

13

Enterprise A Enterprise Agent_A

Enterprise B Enterprise Agent_B

1 Internet

export schema

3

integrated schema

r-17 FIMS- A

2

FIMS - B

imported schema

Figure 10 - Pull-based data exchange among the agents Thus, the high-level protocol is only used for control/coordination purposes. The main advantages of this approach follow: - The inter-agent message’s content becomes shorter and leaner; - Agents will always access the necessary up-to-date data from its source, at the exact time they need it; - Transparent and controlled access to distributed data is provided over the agents’ network in an integrated method. In this way, the agents can concentrate their tasks on the reasoning and processing of information instead of the management of information; - Data and control is separated from each other in multi-agent interaction environment; - The information access rights and visibility levels can be defined efficiently and evolve dynamically using the federated information management system functionalities; - Scheduling agents can only access authorized data with respect to current access right definitions so that desirable autonomy of each agent is preserved in terms of their data. Considering the extreme importance of trust building among the enterprises involved in a VE, preservation of the information visibility and access rights is a main concern of all autonomous enterprises. Therefore, the possibility of configuring, on a bilateral basis via the federated information management mechanisms (Afsarmanesh et al. 1999a) (Frenkel et al. 2000), the specific access rights to data owned by one agent for every other agent in the community, represents an important functionality. This functionality in turn supports the adequate levels of autonomy required by each enterprise in a VE environment, which constitutes another advantage regarding the traditional MAS approaches. In the general case when there is a need to find partners outside the consortium in order to solve a conflict, the same tools used during VE formation can be used, but there is a need to define liabilities / future responsibilities and rights for “leaving partners”.

5. Virtual enterprise dissolution As stated in (Metes et al. 1998), “an organizational marriage is much easier to achieve than an organizational divorce”. There are, in general, consequences of the operation of a VE that cannot be simply discarded when the VE dissolves. Most of these consequences are of a legal nature and shall be regulated by the cooperation agreements. That is the case, for instance, of the responsibility of customer support / product maintenance during the life cycle of the product / service generated by the VE. Environment regulations are also forcing companies to plan provisions regarding the product disposal and recycling after its end of life. Recent regulations in some countries also state that the liabilities regarding each component of a product may ultimately lie with the component’s supplier. In the case of a network chain type of manufacturing this forces each node in the chain to keep track of the history of each 14

component/sub-product that “passed by” this node. This is a functionality that is properly supported by most of the more advanced ERP systems, but not by most of the scheduling systems, for instance. For example, regarding this new “rule”, the composition of a given production lot has to take into account the several suppliers involved in. There are however other several less “material” issues that are more difficult to handle. One of these issues is the IPRs policy, namely for the post-dissolution phase and their consequences in terms of information accesses by the VE members. In some cases there is also the possibility that the VE evolves into a more permanent organization, a joint venture enterprise created by the VE members, to exploit the intellectual and industrial property results developed in cooperation. From an information systems perspective it is also necessary to offer a set of configuration tools that allow each enterprise to cancel / limit the access rights of its former partners once the VE ends. The configuration tools developed in PRODNET, although designed for the creation phase, can be used here as well but some kind of expert assistance would be desirable at this phase. For instance, granting access to some information item or resource (during creation) can be done via a manual procedure because, in case of error, there will be feedback from the involved partner(s). However, for the cancellation phase it is more critical to give the company the confidence that everything the company wants to protect is in fact protected. Due to the time span between creation and dissolution, the human operators involved, even if the same, might not remember anymore all the granted rights. Therefore, a strong “memory link” between the two configuration phases is necessary. There is also considerable knowledge that can be elicited from the ending cooperation experience, namely the knowledge about what went right, what went wrong, partners performance / reliability, jointly defined business process templates, etc. Defining the ownership and access rights to this knowledge is not an easy task and requires further investigation. Only when these issues are better understood, it will be possible to specify which set of support services are necessary. Unfortunately this is an area almost unexplored by the recent research efforts even by most of the running projects. But understanding the mechanisms and requirements involved in the VE dissolution process and providing a set of computer-assisted tools is certainly a major step towards proper support for agility in virtual enterprises.

6. Application examples 6.1 Bicycle assembly In the context of the PRODNET project, a VE demonstration scenario involving four enterprises, two in Europe and two in Brazil was implemented. The application area is the design and manufacturing of bicycles. The PRODNET infrastructure, and in particular its PCL layer (see Fig. 11; notice that the actual names of the enterprises are not shown for commercial confidentiality), was installed at each enterprise and the communications infrastructure was based on the Internet. In addition to the installation and configuration of the cooperation infrastructure, there was a need to integrate the PCLs with enterprises’ legacy systems, such as ERP / PPC and CAD / PDM.

15

European Union

Enterprise A

P C L

Bike Frames and Pedals

P C L

Mould Pedal

PVC Resin

Brazil

Enterprise C

P C L

Enterprise B

P C L

Enterprise D

Figure 11 – PRODNET Demonstration scenario It shall be noted that this system was implemented for demonstration purposes, and it was not in real operation. Although comprising a limited number of enterprises, the implantation of this demonstrating scenario was not a simple task. The difficulty of such a demonstration is strongly due to the complexity of the integration process considered in this scenario. Three basic integration levels / aspects is considered: i) The first one is related to the platform’s services themselves. There is a wide variety and a large number of functionalies of different nature, that shall be executed in / managed by the platform. Some of these are synchronous and some asynchronous. Some examples include: the exchange of information among the platform’s modules; thousands of distributed / federated database queries exchanged among enterprises; the procedure involved in the creation of new instances of virtual enterprises by means of manual configuration of the platform; interactive monitoring of the distributed processes; and the intensive use of the network in order to communicate with the other enterprises. ii) The second aspect refers to the fact that the integration barriers are increased by the need to accommodate distributed and heterogeneous applications into a common environment and low cost hardware (PC). It comprises the integration of the platform with legacy systems, i.e., an ERP/PPC and possibly some PDM tools in this manufacturing scenario. This means to face the difficult issue of interoperation, when all the modules have to communicate with each other by means of potentially and usually different protocols and APIs. iii) The third and final aspect refers to the intrinsic amplification of the integration and testing problems due to the inter-enterprise / intercontinental communications (through the Internet) with “almost real” transactions that shall be tackled. A complete business scenario, designed to use all PRODNET modules and assess their functionalities, aims at designing and producing a bike pedal. In this scenario, Enterprise A and Enterprise B sign a contract and start the development of a pedal, which is produced according to the needs of Enterprise A. Such a pedal is produced through plastic injection, and Enterprise B needs to find a PVC resin supplier  in this case Enterprise C, and a mould maker supplier  Enterprise D in this case. Enterprise B first buys PVC resin from Enterprise C. Then, Enterprise B and Enterprise D exchange some STEP model definitions in order to produce the mould design for the new pedal. Finally, Enterprise B produces the pedal, which is approved by Enterprise A. To support this activity, a large number of PRODNET modules and legacy systems were used:

16

• • • • • • • • •

ERP/PPC (Production Planning and Control System module); DIMS (Distributed Information Management System module); EDI (Electronic Data Interchange module); LCF (Local Configuration Module); LCM (Local Coordination Module); PCI (Prodnet Communication Infrastructure module); STEP (PDT module); DBMPS (Distributed Business Process Management System module); EPST (Electronic Partners Search and Selection tool).

Furthermore, a large number of interactions among the four companies were supported. For example, Fig. 12 shows the interactions between two of these enterprises. (L) (K) (H)

( I)

(G)

Enterprise C

P C L

(C)

(D) (A)

(B)

P C L

Enterprise D

(E) (F) (K) (M)

( J)

Steps Enterprise B searches a mould maker supplier; Enterprise B identifies Enterprise D as a supplier; An industrial “confidential” contract is signed, and the VE is configured; Enterprise B sends a pedal design to Enterprise D; (C) Enterprise D and Enterprise B analyze interactively the project, exchanging STEP models; (E) Enterprise B agrees with the design and sends a “design acceptance” to Enterprise D; (F) Enterprise D sends proposal for the mould production; (G) Enterprise B evaluates the proposal and sends a “confirmation order” to Enterprise D; (H) Contract is signed and sporadic supply is planned; (A) Suppliers and product data are configured in PPC; Enterprise B generates and order entry and sends it to Enterprise D; (B) Enterprise D sends an order acceptance and the project confirmation; (D) Production is started by Enterprise D; Enterprise B manages the VE orders; (N) Enterprise B can request “production follow up bulletins” from Enterprise D; (I) Enterprise D delivers pedal mould and delivery record to Enterprise B; (J,K) Enterprise B receives and inspects the product; Enterprise B sends a “reception report” to Enterprise D; (L)

Modules involved PST PST STEP,LCM,EDI, PCI,DIMS STEP,LCM,EDI, PCI,DIMS STEP,LCM,EDI, PCI,DIMS

Contract Management PPC PPC, EDI, PCI, LCM, DIMS PPC, EDI, PCI, LCM, DIMS PPC PPC, LCM, DIMS, DBPMS, PCI PPC, EDI, PCI, LCM, DIMS, ACF PPC, EDI, PCI, LCM, DIMS PPC PPC, EDI, PCI, LCM, DIMS

Figure 12 – Interoperation between Enterprise D and Enterprise B The actual behavior of each VE node, i.e. the coordination of various modules in the PCL of each enterprise, is achieved through a workflow plan for that enterprise. The workflow plan for the enterprise is configured through a graphical workflow process design editor. At the same time, the autonomous behavior of the enterprises is preserved through their independent definition of information visibility and access rights on their data for other enterprises. The PRODNET infrastructure, although based on several independent modules, presents a very tight integration of its key components. For instance, Fig. 13 illustrates the complexity of the interactions among modules, when a federated query is being processed, in order to provide the

17

Distributed Business Process module (DBPMS) with monitoring information about the status of the processes running at a partner enterprise. DBPMS

LCM

PCL_GetXXX

DIMS

PCI

PCI

LCM

DIMS

PPC

(1) DIMS_ GetXXX (2) LCM_SendExternalDimsQuery (3) PCI_DeliverMessage DIMS_GetPciMsgContent ServiceAnswer (3) ServiceAnswer (2) ServiceAnswer

LCM_ReceiveDimsMessage (1) PCL_RecognisingMessage (1) DIMS_ReceiveMessage (1) ServiceAnswer (1)ServiceAnswer (2)LCM_SendInternalDimsQuery (3) PPC_PutData

(3) ServiceAnswer (2) ServiceAnswer

DIMS_PutXXX ServiceAnswer

(4) LCM_SendDimsQueryResult (2) PCI_DeliverMessage (3) DIMS_GetPciMsgContent (3) ServiceAnswer DIMS_PutPciMsgContent LCM_AnsweringExternalDimsQuery (4) PCL_RecognisingMessage

(2) ServiceAnswer

(4) ServiceAnswer

ServiceAnswer

(4) ServiceAnswer (5) DIMS_ReceiveMessage (5) ServiceAnswer (1) ServiceAnswer

ServiceAnswer DIMS_ GetDataXXX ServiceAnswer

Company A

Company B

Figure 13 – Example of the steps involved in a federated query process The developed infrastructure successfully proved to be flexible enough to support such scenarios and allowed the specification of different behaviors for different enterprise nodes, according to each enterprise’s policies. The adoption of a graphical process definition language proved especially adequate as it allowed the configuration / re-configuration of the coordination policies by a business process expert without requiring programming expertise. However, the large number of involved tools and technologies, each one requiring a specific configuration process, made the implantation process a non-trivial task, and required the participation of experts with some level of knowledge about the multiple areas involved. In addition to the technological difficulties, there were other barriers coming from the socio-organizational side, which required a careful analysis and treatment of issues such as definition of new organizational structures, new roles and corresponding re-training of people, etc. These difficulties confirm our point that, at the current stage and for the manufacturing sector, true VE agility can only be achieved with an industry cluster. 6.2 Moulds industry TECHMOULDS is a cluster made up of nine mould and die SMEs located in the south of Brazil. This cluster, although formed by enterprises that used to compete with each other, was created as a strategic answer to face the current market needs, in the sense that the business potentialities and competitiveness of the enterprises are increased in the global market since they behave as a stronger coalition, gathering the sum of their individual capacities. However, this strategic approach must be accompanied by other changes as well. From the operational point of view, for instance enterprises have to become more and more efficient, extending the “traditional” metrics through which the customer usually decides to purchase a mould. Now, besides quality, cost, and delivery time, the agility in the business negotiation

18

process is a must. In the modern enterprising world, one way to contribute to such agility is to support brokerage. In the TECHMOULDS cluster context, the importance of brokerage emerges in the creation phase of a virtual enterprise, when it is necessary to decide on the appropriate set of skills and resources to respond to a given business opportunity. In fact, the broker concept is wider, with its use also during the VE operation phase, when it is necessary to change a partner. A business case in the TECHMOULDS cluster scenario occurs when a customer order arrives at the broker site. Two major difficulties usually come up at this point. The first one is related to the complexity of finding a suitable team of enterprises to provide the customer order. There can be so many possibilities of teams of members to fit a given business that it makes the job of a human broker extremely difficult and complex, when he/she should focus on gathering new business opportunities. In this context, the importance of a brokerage function, as the one being presented here, ascends in significance as it is almost impossible for a human being to generate the best possibilities of teams (i.e. possible VEs within the TECHMOULDS cluster) and to evaluate every corresponding schedule. Thus, a non-assisted generation of such VEs may imply a less profitable coalition in terms of final cost and delivery time, and in the worst case, the loss of the business opportunity. The second problem is related to the agility to provide the client with a fast but solid answer. It is therefore important to provide the human broker with some supporting system to help him/her speed up the whole process of announcing the opportunity, generating the possibilities, analyzing them, selecting one and finally giving a final answer. In this sense, a good brokerage system can offer the required agility that nowadays is a must in terms of competitiveness. Figure 14 illustrates the creation of VE1 within the TECHMOULDS cluster. Client Broker E8

E1 E2 E9

BPa

E5

BPc

E6 E12

DBP E3

BPd

E11 BPb

E10

E4

E7

Figure 14 – The VE1 Scenario within the TECHMOLDES cluster In the scope of MASSYVE Project, the prototype of a multi-agent-based decision support system is developed to assist a human-broker in the selection of the team of enterprises within TECHMOULDS cluster that best fits a given business opportunity (Rabelo, Camarinha-Matos, Vallejos, 2000) . By means of a broker agent an acquired business opportunity – building a specific package of moulds – is transformed into a distributed business process (DBP) that is split into several business processes (BP), where each BP corresponds to an individual mould or die. The individual mould/die tenders are then distributed among the enterprises in the TECHMOULDS cluster. In this process, depending on the business requirements and the available capacities and skills, various alternative candidates of teams of enterprises (potential VEs) that can accomplish the various BPs may be found, but eventually the most adequate coalition is elected. As the cluster members are potential competitors, the final decision is made by the TECHMOULDS management board and not by the broker agent. However, the decision

19

is based on the broker’s analysis, represented by the set of alternative consortia generated (and evaluated) by the system. Figure 15.a illustrates the interface of one agent and the details of the potential tender received. Figure 15.b shows the interface through which that enterprise manager is represented to indicate the delivery date and price.

Figure 15.a - A package of moulds is received

15.b - Bidding, with human intervention

Figure 16 shows an interface at the broker site, where several potential VEs (with their respective schedules) were formed for a given package. It is possible to zoom on each alternative and evaluate each one individually. The performance indicators, which are the base for the decision-making, are provided at two levels: intra-organizational (i.e. the impact inside each enterprise) as shown in this figure, and inter-organizational (i.e. considering the vision upon the whole VE). The broker agent makes a pre-evaluation on candidate VEs generated and makes its final suggestion to the TECHMOULDS management board. The selection criteria are based on the lowest global cost and the shortest delivery date.

Figure 16. Evaluating possible VEs One important aspect to be highlighted in the system is the direct involvement of the enterprises’ representative in the negotiation process. In the mould and die sector, the quotation and specification of the delivery date are two “vital” pieces of information to be sent to the broker. Even small mistakes can imply huge losses. Hence it is fundamental for the manager – at least at this stage of the system – to have this information “under his/her control”. In this system

20

architecture, besides the agent that assists the broker at his computer, there is one stationary agent placed at every enterprise’s site, acting as an intelligent front-end between the brokerage system and the enterprises’ legacy systems. Therefore, when a stationary-agent receives a tender, it makes the necessary computation, then its manager is explicitly requested to manually provide this information to the broker. It means that, although agents are used to give more agility in the brokerage process, humans make the decisions. It corresponds to a hybrid or semi-automated approach as the managers acts directly both in the interaction with the agents, and in the final election of the best composition of enterprises for a given package. The example showed in this section is a realistic case for application of multi-agent technology in VE creation. When the universe of potential partners is “well defined and controlled” within a cluster, it becomes feasible to have all enterprises represented by homogeneous agents and to establish common ontologies and negotiation protocols for different purposes, including the VE creation. However, the fact that the concept of virtual organization and the principles of the multi-agent technology are not well-known in many sectors, makes it still difficult for the acceptance and deploying such a system and architecture in real operation by the involved enterprises.

7. Further issues 7.1 Interoperability In spite of all technological developments, lack of proper interoperability mechanisms among enterprise applications is a major obstacle to agile VEs. As complex organizations, formed by heterogeneous and autonomous entities, VEs need to deal with a combination of different technologies and a variety of application sources. Although it is not a new subject but rather the central question in systems integration, interoperability remains as a critical topic in the agenda of VE supporting infrastructures. In fact, effective cooperation in a VE requires interoperation among the enterprise applications at two levels (Fig. 19): Intra-enterprise interoperability – comprising systems integration at the level of enterprise applications. Inter-enterprise interoperability – comprising systems integration at the level of virtual organization (requiring that similar reference models are adopted).

Figure 19 – Levels of interoperability among applications in a VE Considerable efforts are spent in the intra-enterprise area and a large number of enabling technologies – CORBA, DCOM, Jini, RMI, ... – and reference models – CIM-OSA, PERA, GRAI-GIM, GERAM - are introduced. Some efforts are also spent on the minimum interoperation infrastructure, for long-term collaboration in supply chains, enforced by the main contractor (e.g. in automotive industry). However, new needs are emerging for the other kinds of networked organizations such as the Industry clusters and One-of-a-kind cooperation (dynamic VEs).

21

When discussing the interoperability approaches there is a need to carefully address the “life cycle” aspects as different enterprise technologies have quite different life cycles (e.g. IT, manufacturing technology, products, services), and the components to be integrated may be at different stages of their life cycles. The need for “product recycling” introduces also new questions in terms of interoperability and technology life cycles. It is therefore necessary to identify the “persistent components” in the company (knowledge, data, protocols / processes, etc.), namely what remains in spite of the technology changes. As mentioned before however, the above problems can also be “simplified” for established communities of users (e.g. industry clusters), as mappings and agreements can be established for long-term relationships. Interoperability solutions require “common” reference models, namely in terms of the functionalities available at each enterprise, business process models, and the VE supporting infrastructure. The componentization efforts being pursued by some associations of enterprise application suppliers, such as the OAG, will contribute, if successful, to facilitate the required interoperability. Formalization and normalization of the “representations” both in terms of the information-semantics and business processes is necessary, in order to allow the distribution of information and BPs among the VE members. In addition to WPDL (from the Workflow Management Coalition), a language used by several VE projects, there are other candidates for process modeling, such as PIF and PSL. PIF (Process Interchange Format) emerged in the area of Business Process Reengineering (Lee, Yost, 1994) and aims to be a neutral format to act as a bridge across different process representations. The Process Specification Language (PSL) (Schlenoff et al., 1998) project of the American National Institute of Standards and Technology (NIST) proposes a neutral, standard language for process specification to help the integration of multiple process-related applications throughout the manufacturing life cycle. There have also been some initiatives towards the merging of PSL with PIF, an effort that could bring together the representation of both business and manufacturing process-related concepts into a single, unified process modeling language. Finally, there is a need for some harmonization in terms of the VE supporting infrastructures. Currently there are several proposals for VE infrastructure, originated in different R&D projects, but although some similarities can be found among the various proposals, there is not yet one common reference architecture. A recent initiative launched by IFIP, the COVE (Co-Operation infrastructure for Virtual Enterprises and electronic business) project aims at contributing to a harmonization of these different proposals towards a common reference model for VE infrastructures (COVE news, 2001). 7.2 Socio-economic, organizational and legal issues As a consequence of the emergence of knowledge and skills-based economy and the widespread of the e-business concepts, the traditional business models and concepts are gradually being abandoned or challenged. The concept of “organization with clear boundaries” is dissolving and being replaced by new forms of more dynamic and highly re-configurable virtual organizations. However, being at its early stages, clearly many consequences of the practical development, implantation, and performance of new agile virtual organizations is still unknown and their affect on the day to day running of enterprises and their production/services need to be carefully investigated and evaluated. A major obstacle in the study of virtual organization paradigm is the long-standing “divorce” between the information/communication technology and the socio-organizational communities. Namely, these two communities are persistently analysing these trends and the identification of the necessary supporting tools as well as the evaluation and performance criteria, in isolation. At present, only a few research and development projects are making an attempt to combine the various types of expertise in a multi-disciplinary team. 22

From the socio-organizational angle, necessary re-definitions of working methods, roles and training needs, understanding and handling the legal frameworks, creation of appropriate methods to manage intellectual properties, or even the basic economic principles that drive the new organizations, are becoming relevant issues that must be discussed together with other organizational models as well the technological development trends and solutions. In particular, multi-disciplinary teams should definitely address the identification and characterization of the new value systems, new ways of performance measurement, as well as new ways of creating a human-centric ecology. Many open issue and challenges are emerging in this area. At the European level, a recently launched initiative, the IST THINKcreative project, represents an effort in this direction. A particularly challenging open issue is the extension of the infrastructures to accommodate metrics and mechanisms for dynamic evaluation of fractional values for instance either for a distributed process or a process improvement performed by an enterprise, and to support a consistent risk / liability / reward incentive strategy. Another related challenge is the creation of appropriate legal frameworks able to regulate the new business models, and to support the interoperation among different legal systems, supporting the multi-national virtual organizations. A number of recent international initiatives such as the IST projects eLEGAL, E-ARBITRATION-T, or ALIVE, are aiming at understanding the legal needs and complexities, and establishing a legal framework for regulating such collaborative business environments, including modeling, negotiation, conflict resolution, and the management of contracts and cooperation agreements. Once clear concepts and models are developed in this context, the next issue in support of agility is the derivation of the support mechanisms, to be implemented at the infrastructure level. Currently a large list of support tools and mechanisms are foreseen, to address negotiation and tendering, contracts management, supervision clauses definition, and clauses monitoring and supervision among others.

8. Conclusions Support for agility is an important requirement in any infrastructure for virtual enterprises and its consequences are reflected at all phases of the VE life cycle. A number of contributions in this direction were developed in the framework of some European funded projects: PRODNET II, MASSYVE, and FETISH-ETF, covering mostly the creation, operation, and reconfiguration phases of Virtual Enterprises. The paper addresses many of these developments. Nevertheless more work on this subject is necessary, namely in terms of the distributed business process planning, high-level coordination, advanced cooperative information management, more flexible VE creation processes, configurability and distribution of supervision rules, support for the VE dissolution phase, and harmonization of architectures and applications interoperability. Acknowledgements. The authors thank the European Commission for the partial funding for this work and their partners of the PRODNET II, MASSYVE, FETISH-ETF, and THINKcreative projects for their valuable contributions. REFERENCES 1. Afsarmanesh, H.; Camarinha-Matos, L.M., 2000 – Future smart organizations: A virtual tourism enterprise, Proceedings of WISE 2000 – 1st ACM/IEEE International Conference on Web Information Systems Engineering, Vol. 1 (Main Program), pp 456-461, IEEE Computer Society Press, ISBN 0-7695-0577-5, Hong Kong, 19-20 June 2000. 2. Afsarmanesh, H., Garita, C., Ugur, Y., Frenkel, A., and Hertzberger, L. O., 1999 - Design of the DIMS Architecture in PRODNET, in [6].

23

3. Alonso, G. at al, 1999 The WISE approach to Electronic Commerce, http://www.inf.ethz.ch/department/IS/iks/research/wise.html, Feb 15. 4. Alzaga, A.; Martin, J., 1999 - A design process model to support concurrent project development in networks of SMEs, in [6]. 5. Camarinha-Matos, L. M., 2001 - Execution system for distributed business processes in a virtual enterprise, Journal Future Generation Computer Systems (Elsevier), Vol. 17, Number 8, pp.1009-1021, Jun 2001, ISSN: 0167-739X.

6. Camarinha-Matos, L. M., and Afsarmanesh, H., 1999 - Infrastructures for Virtual Enterprises - Networking Industrial Enterprises, Kluwer Academic Publishers, ISBN 0-7923-8639-6, Oct 1999. 7. Camarinha-Matos, L. M., and Afsarmanesh, H., 2001 - Virtual Enterprise Modeling and Support Infrastructures: Applying Multi-Agent Systems Approaches, in Multi-Agent Systems and Applications, M. Luck, V. Marik, O. Stpankova, R. Trappl (eds.), Lecture Notes in Artificial Intelligence LNAI 2086, pp.335-364, Springer, ISBN 3540-42312-5, July 2001. 8. Camarinha-Matos, L. M.; Afsarmanesh, H., Kaletas, E.C.; Cardoso, T., 2001 - Service Federation in Virtual Organizations, Proceedings of PROLAMAT 2001, Budapest, Hungary, Nov 2001, Kluwer Academic Publishers. 9. Camarinha-Matos, L. M.; Afsarmanesh, H., Osório, A. L., 2001 - Flexibility and safety in a web-base infrastructure for virtual enterprises, International Journal of Computer Integrated Manufacturing (Taylor & Francis), Vol. 14, N. 1, Jan 2001, pp 66-82. 10. Camarinha-Matos, L. M., and Afsarmanesh, H.; Rabelo, R., 2000 - Supporting agility in Virtual Enterprises, in "E-business and Virtual Enterprises", Kluwer Academic Publishers, ISBN 0-7923-7205-0, pp. 89-104. 11. Camarinha-Matos, L.M.; Cardoso, T., 1999 - Selection of partners for a virtual enterprise, in [6]. 12. Camarinha-Matos, L. M.; Lima, C., 1998 – A framework for cooperation in virtual enterprises, Proceedings of DIISM’98 – Design of Information Infrastructure Systems for Manufacturing, Fort Worth, USA, May 1998. 13. Camarinha-Matos, L. M.; Lima, C., 1999 – PRODNET coordination module, in [6]. 14. Camarinha-Matos, L. M.; Lima, C., 2001 - Cooperation coordination in virtual enterprises, Journal of Intelligent Manufacturing (Kluwer), Vol. 12, Nº 2, ISSN 0956-5515, Apr 2001, pp. 133-150. 15. Camarinha-Matos, L.M.; Viweira, W. - Intelligent mobile agents in elderly care, Journal of Robotics and Autonomous Systems (Elsevier), Vol. 27, N. 1-2, April 1999, ISSN 0921-8890, pp. 59-75. 16. COVE News – Newsletter of the IFIP project COVE: Co-operation infrastructures for virtual enterprises and electronic business, ISSN 1645-0582, vol. 1&2, 2001, www.uninova.pt/~cove/newsletter.htm. 17. Damascos - http://www.damascos.com 18. Daviddrajuh, R.; Deng, Z., 2000 – Identifying potential suppliers for formation of virtual manufacturing systems, Proceedings of the World Computer Congress 2000, Track on Information Technology for Business Management, R. Gan (Ed.), Publishing House of Electronics Industry, pp. 278-286, ISBN 3-901882-05-7, Beijing, China, 21-25 Aug. 19. Davis, R.; Smith, R., 1983 - Negotiation as a Metaphor for Distributed Problem Solving, Artificial Intelligence, 20, pp. 63-109, 1983. 20. Frenkel, A., Afsarmanesh, H., Garita, C., and Hertzberger, L. O., 2000 - Information Access Rights in Virtual Enterprises, Proceedings of the 2nd IFIP / MASSYVE Working Conference on Infrastructures for Virtual Enterprises, Pro-VE 2000, Florianopolis, Brazil. 21. Garita, C., Afsarmanesh, H., and Hertzberger, L. O., 2001 - The PRODNET Federated Information Management Approach for Virtual Enterprise Support (to appear). Journal of Intellingent Manufacturing. 22. Goranson, H.T.. 1999 – The Agile Virtual Enterprise – Cases, metrics, tools. Quorum Books, ISBN 1-56720264-0. 23. Kidd, P., 1994 - Agile Manufacturing: forging new frontiers, Addison-Wesley. 24. Klen, A. P.; Rabelo, R.J., Spinosa, L.M; Ferreira, A. C., 1998 – Integrated Logistics in the Virtual Enterprise: The PRODNET-II approach, Proceedings IMS’98 – 5th IFAC Workshop on Intelligent Manufacturing Systems, pp. 289-295, Gramado – Brazil. 25. Klen, A. P.; Rabelo, R.J., Spinosa, L.M; Ferreira, A. C., 1999 - Distributed Business Process Management, in [6]. 26. Lee, J.; Yost, G. - The PIF Process Interchange Format and Framework, Version 1.0, http://ccs.mit.edu/pifmain.html, Dec22, 1994.

27. Li, Y.; Huang, B.; Liu, W.; Wu, C.; Gou, H., 2000 – Multi-agent system for partner selection of virtual enterprise, Proceedings of the World Computer Congress 2000, Track on Information Technology for Business Management, R. Gan (Ed.), Publishing House of Electronics Industry, pp. 287-294, ISBN 3-901882-05-7, Beijing, China, 21-25 Aug. 28. Metes, G.; Gundry, J.; Bradish, P., 1998 – Agile Networking – Competing through the Internet and Intranets, Prentice Hall, ISBN 0-13-760125-5. 29. Molina, A.; Flores, M., 2000 – Exploitation of business opportunities: The role of the virtual enterprise broker, in E-Business and virtual enterprises, L.M. Camarinha-Matos et al. (Eds.), Kluwer Academic Publishers, ISBN 07923-7205-0, pp.269-280.

24

30. Rabelo, R.; 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 e Hamideh Afsarmanesh, Chapman & Hall, pp. 413-422. 31. Rabelo, R., Camarinha-Matos, L. M., and Afsarmanesh, H., 1998 - Multiagent-based Agile Scheduling, International Journal of Robotics and Autonomous Systems, Special Issue on Multi-Agent System Applications, 27(1-2), 15-28. 32. Rabelo, R. J.; Afsarmanesh, H., Camarinha-Matos, L.M., 1999 - Applying Federated Databases to Distributed Multi-agent Scheduling, in Multi-Agent Systems in Production, Ed. P. Kopacek, Pergamon, pp. 213-218, 1999. 33. Rabelo, R. J.; Afsarmanesh, H., Camarinha-Matos, L.M., 2000 - Federated Multi-Agent Scheduling in Virtual Enterprises, Proceedings of PRO-VE’2000 2nd IFIP / MASSYVE Working Conference on Infrastructures for Virtual Enterprises - Managing Cooperation in Virtual Organizations and Electronic Business Towards Smart Organizations. 34. Rabelo, R. J.; Camarinha-Matos, L.M.; Vallejos, R. V., 2000 – Agent-based brokerage for virtual enterprise creation in the moulds industry, in E-business and Virtual Enterprises, L.M. Camarinha-Matos, H. Afsarmanesh, R. Rabelo (Eds.), Kluwer Academic Publishers, ISBN 0-7923-7205-0, pp. 281-290. 35. Schlenoff, C.; Gruninger, M.; Tissot, F.; Valois, J.; Lubell, J. Lee, J. - The Process Specification Language (PSL) - Overview and Version 1.0 Specification, NIST Internal Report (NISTIR) 6459, http://www.mel.nist.gov/psl/, 1998.

36. Siqueira, J.; Bremer, C., 2000 – Action research: the formation of a manufacturing virtual industry cluster, , in E-Business and virtual enterprises, L.M. Camarinha-Matos et al. (Eds.), Kluwer Academic Publishers, ISBN 0-7923-7205-0, pp.261-268. 37. Spinosa, L.M.; Rabelo, R.J.; Klen, A. P., 1998 - High-Level Coordination of Business Processes in a Virtual Enterprise, in Globalization of Manufacturing in the Digital Communications Era of the 21st Century: Innovation, Agility, and the Virtual Enterprise, Edited by Jacucci, G., Olling, G.J., Preiss, K. and Wozny, M., Kluwer Academic Publishers, pp. 725-736. 38. SUN, 1999 JINI Technology Architectural Overview, Jan 1999, http://www.sun.com/jini/whitepapers/architecture.html. 39. WfMC - Workflow Management Coalition, 1994 - The Workflow Reference Model - Document Nr. TC00 1003, Issue 1.1, Brussels Nov 29.

25