Collaboration in Decision Making: A Semi-Automated Support for Managing the Evolution of Virtual Enterprises

1. Introduction

Collaborative Networked Organizations (CNO) has become one of the most prominent strategic paradigms that companies have sought as a mean to face the challenges imposed by globalization (Camarinha-Matos et al., 2005). There are several types of CNOs, like as supply chain, virtual labs, virtual organizations breeding environment (VBE), extended enterprises, virtual organizations and virtual enterprises. The common rationale behind such alliances is that they rely on collaboration with other companies to be more competitive. This work focuses on virtual enterprise.

A Virtual Enterprise (VE) can be generally defined as a temporary alliance of autonomous and heterogeneous enterprises that dynamically joint together to cope with a given business opportunity, acting as one single enterprise. A VE dismiss itself after accomplishing its goal (Rabelo et al., 2004).

Managing the VE life cycle very efficiently is crucial for the business realization. This involves the creation, the operation, the evolution and the dissolution of a VE. This work focuses on the VE evolution phase. In general, the VE evolution phase comprises activities related to managing changes and adaptations in the VE’s plan (i.e. the VE operation phase) in order to guarantee the achievement of its goals and duties. This can comprehend actions like simple modifications in some technical specification, passing by changes in and/or negotiations on the VE’s schedule, or more drastically the replacement of some of its members.

VEs have, however, some intrinsic and particular characteristics which impose respecting a number of requirements in decision making. The most important one is that decision should be performed in a collaborative, decentralized, distributed and transparent way, considering that VE members are autonomous, independent and geographically dispersed. Besides that, the fact that each VE is per definition completely different from one to another (in terms of number of partners, their skills, culture, local regulations, specificities determined by the given client, etc.) makes the solution of some problems not necessarily deterministic and the use of previous decisions for equivalent problems not necessarily useful. As such, managing the VE evolution requires additional approaches in order to be properly handled (Drissen-Silva & Rabelo, 2009b).

Figure 1 presents a general vision of the aspects related to the management approach and the decision making process in a centralized and decentralized ways, trying to expose the necessary requirements for offering a new decentralized and collaborative decision making model for the Virtual Enterprise evolution, as offered by this work.

Figure 1.

Source: Extended from Ollus et al., 2009 and Loss, 2007.Requirements for a decentralized decision with collaborative work.

Considering that a VE is usually a grasp-driven alliance for a short-term business opportunity, the major challenge for a decision making that respects those requirements is to be agile. This means that, once identified, a problem should be solved as fast as possible, with high quality and feasibility, and relying on trustful information. It has to be also taken into account that enterprises are often involved in several VEs simultaneously and that some of them are inter-related. Therefore, managing the evolution of a VE requires an ample spectrum of issues that make decision-making extremely complex, making phone calls or chatting among VE members by far insufficient to solve a problem.

This work proposes a novel decision-making approach and framework as a contribution to face those requirements. It is represented by an integrated collaborative decision making framework that assist VE managers along the entire decision making process, including the possibility of evaluating decision feasibility and its impact over each VE that members are involved in.

This chapter is organized as follows: Section 1 presented a general analysis of the requirements for VE management and the evolution phase. Section 2 discusses the problem related to a collaborative decision making and its requirements for the offered framework. Section 3 introduces the proposed framework for managing the virtual enterprise evolution with a collaborative discussion. Section 4 presents the results of the framework considering a prototype development. Section 5 provides a general evaluation with contributions, limitations and future research. Finally, section 6 discuss around the conclusions reached on termination this work.

2. Collaborative decision making

Distributed decision-making is not a new research topic and many works have been developed along the last decade concerning this matter, especially in the form of distributed decision support systems (Bostrom et al., 2003). Actually, the work presented in this chapter follows the same line but it adds diverse elements and requirements from the VE area. The approach addressed in this paper is anchored in the following scenario:

“Partners, although being distributed and autonomous, belong to a long-term alliance of type VBE (Virtual Organization Breeding Environment), so sharing common operating principles. One of the main principles is that they trust on each other and they should collaborate towards reaching a globally feasible solution for a problem that takes place during the VE operation. Partners should solve the problem related to the VE they are involved in and hence they should discuss about it through a computing network (e.g. Internet). The discussion should be structured in order to get focused and to have potentially better quality, making use of a shared distributed decision-making environment guided by a decision protocol. This structure should be connected to business processes management. Besides that, it should be flexible and adaptive regarding the problem and the VE characteristics. However, there is not one very pre-defined protocol for every single problem. Each VE tends to be so unique and problems so particular for a given business context and VE composition. Partners should have some freedom to exchange ideas while they evaluate possibilities against their availabilities. This evaluation should be made via an easy access to the most common managerial supporting software tools in order to facilitate Small and Medium Enterprises (SME) managers’ activities. After this, they should have means to evaluate the impact of their decisions before acting. All this should be supported by adequate ICT infrastructures, which can also provide the necessary security in the communications and access rights.”

In order to cope with this scenario and with those requirements previously mentioned, six aspects have to be supported by a comprehensive decision-making environment for the VE evolution: 1) Partners’ discussion; 2) Methodological guidance; 3) Modular and flexible execution of decision protocols, aligning business and processes; 4) Performance measurement; 5) Performance evaluation; and 6) ICT Infrastructure. Next sections provide a resumed revision of the most important techniques used to support these six aspects. The methodological approach followed in this work is to use existing theoretical and software results related to those aspects and to combine and adapt them respecting the envisaged environment.

2.1. Partners’ discussion

This issue is related to endowing partners with a collaborative environment where they can exchange information towards the problem resolution. In this sense, Groupware or CSCW tools (Wulf et al., 2008) have been largely used to support multiple users working on related tasks in local and remote networks. However, they cope with a partial – and perhaps less complex – part of the problem. The issue here is not only to make partners interact with each other, but also to globally coordinate their discussions about each identified problem, and as fast as possible. Besides that, it is necessary to integrate information for further auditing, giving transparency to the whole process, as well as to regulate partners’ involvement and information access as long as decisions are taken. After a review in the literature, three works have been found out that offer elements for this desired environment.

HERMES (Karacapilidis & Papadias, 2001) is a support system used for collaborative decision-making via argumentation. It helps in the solution of non-structured problems, coordinating a joint discussion among decision makers. It offers an online discussion about one or more specific subjects, where each participant can suggest alternatives to the problem or simply point out their pros and cons in relation to current alternatives. There is an association of weights that considers the positioning in favor of or against the suggestions, hence providing a global vision of the opinions.

DELPHI is a classical method (Dalkey & Helmer, 1963) created with the purpose of finding a consensus about a given topic of discussion but without confrontation. Essentially, a summary of the opinions is elaborated along diverse rounds and it is sent back to the participants keeping the names anonymous. The process continues until the consensus / final decision or opinion is reached.

Woelfel et al. (described in Rabelo et al., 2008) developed an integrated suite of web-based groupware services that has considered CNOs requirements. This suite includes the services of instant messaging, mailing, discussion forum, calendar, wiki, content management system, and news & announcement. One interesting feature of the instant messaging service is the possibility of having private discussions rooms, allowing having several parallel discussions involving all partners and some rooms only available for authorized partners.

2.2. Methodological guidance

The methodology’s goal is to prevent partners from dealing with the problem without any guidance, losing time and resources, which can hazard the VE’s business. An approach for that is to see a VE as a project, making use of project management reference models. This means making partners to be guided along the problem resolution through a set of steps grounded on project management foundations.

One of the most relevant foundations to support VE as a project is the Project Management Body of Knowledge, or just PMBOK (PMBOK, 2004). PMBOK states that “a project is a temporary effort to create a unique product or service”. Respecting the VE evolution phase and the VE definition (see section 1), it is argued that a VE can be seen as a project as both are temporary and unique in view of the creation of a product or service or to cope with a specific collaboration need. Jansson and Eschenbaecher (2005) advocate that managing a VE is more than managing a project as the creation of VEs requires a long and previous preparation. However, this also embraces the VE creation phase, whereas the focus here is the VE evolution phase, i.e. when the VE is already in execution.

In spite of being is a very comprehensive model, PMBOK is too general for handling changes in projects subjected to constant changes - which is the case of VE - and for which other models have been proposed.

The model called as Capability Maturity Model Integration (CMMI, 2006) has been fundamentally used in the area of software development. It presents a decision and resolution analysis with more details (compared to PMBOK), and gives a strong foundation to assist organizations in the improvement of their processes and in their capacity to manage the development, acquisition and maintenance of products and services. Some CMMI steps can be useful in the development of an agile method for the VE concept, but it is too focused on software development business processes.

The Agile Project Management (APM) model sees the changing need as an adaptation in the exploration of alternatives that can fit to new scenes. APM was essentially created for projects which demand more agility and dynamism (Leite, 2004), presenting a deeper set of actions for handling changes. There are other management models that handle changes in a project, namely ECM - Engineering Change Management (Tavčar & Duhovnik, 2005), CC - Configuration Control (Military Handbook, 2001) and CM – Change Management (Weerd, 2007). In general, they organize the phases of change management in four macro phases: i) need of change identification, where the causes of the problem and the affected members are identified in order to prepare a change solicitation; ii) change proposal, where the members that are going to participate in the change analysis are defined; iii) change planning, where the different possible scenarios to solve the problem are evaluated via general evaluations, and; iv) Implementation, where the most suitable alternative for the problem is settled and the new project’s parameters are reconfigured.

All these reference models are very general and they can be instantiated to any type of VE topology. As such, any managerial style and model, different support techniques, management tools and performance evaluation methods can be applied in each case (Karvonen et al., 2005). Considering their generality the models are not ready used in VE evolution scenarios. Therefore, in spite of the extremely importance of their foundations, they should be adapted for that.

2.3. Decision protocols

Decision protocols are seen in this work as an instrument to: i) systemize a set of actions where there is a strong human intervention, ii) to standardize and iii) to enhance their execution efficiency. In the context of VE, three works were found out in the literature those offer some computer assistance for handling decision protocols.

ILMSS system (Rabelo et al., 1998) was developed to systemize logistic actions in Extended Enterprises following a pre-defined and general decision-protocol. DBPMS system (Rabelo et al., 2000) was an evolution of ILMSS, and it was developed to coordinate conflicts among partners in a Supply Chain applying a modular but fixed approach to generate decision protocols. SC² (Rabelo & Pereira-Klen 2002) was a multi-agent system developed as an evolution of DBPMS. One of its agents was responsible for managing conflicts that took place along the execution of tasks in dynamic Supply Chains. The decision “blocks” were chosen by an agent but the blocks had a high granularity. Another relevant particularity – and limitation – of these three works is that they assumed that the main coordinator was the only one who could trigger the process of looking for solutions close to members when problems arose, as well as the only one who could make suggestions, who could have access to the others’ information, and who took the decision. Besides that, these works only dealt with rescheduling and basic actions towards partners’ replacement. As it was stressed in the previous section, managing VE evolution requires several other features and types of actions.

The VOM Toolkit (Pěchouček & Hodík 2007) is an integrated environment that has been developed to help the VE coordinator in doing several activities, such as VE performance monitoring, alerting about changes in the expected performance, and rescheduling and reconfiguration simulation to optimize the VE performance. However, likewise in those other three systems, it leaves totally to the VE coordinator to implement the corrections to solve the conflict. No guidelines or supporting methodology are offered to help in these activities.

Another perspective is that all these works - and some other more recent ones (e.g. Hodík & Stach, 2008; Negretto et al., 2008; Muller et al., 2008) – are however disconnected from the global operation ambient of the companies. This means that the decision-making process is carried out separated of the other processes. In practice, this obliges managers to switch from one environment to another and to cope with different sources of information (this is a problem as SMEs usually have several basic problems of systems integration). A sound alternative for that is the BPM (Business Process Management) approach (Grefen et al., 2009) and the SOA (Service Oriented Architecture) paradigm (Ordanini & Pasini, 2008). BPM provides foundations for a loose-coupled, modular, composite and integrated definition of business processes. From the process execution point of view, BPM tools generate BPEL (Business Process Execution Language) files as output, allowing a direct integration among business level (BPM) and execution level (SOA / web services). There are both commercial and academic supporting tools for that (e.g. Oracle BPEL Designer, IBM WebSphere). This combination can provide the notion of flexible and modular decision protocols.

2.4. Performance monitoring and measurement

Performance monitoring and measurement look to the current situation of the production system, treating the problem in the (VE) operation phase. The goal of this aspect from the VE evolution management point of view is to offer conditions for the VE partners to measure their own performance and to check their capacity in order to get more confidence when deciding about how to do respecting the given problem. This involves, therefore, monitoring (i.e. gathering of internal information) and further analysis (performance measurement). There are a number of performance measurement models. Two of the most relevant ones are the Balanced Scorecard (BSC) and SCOR (Supply Chain Operation Reference).

BSC is a method that “translates the mission and the view of companies in a wide group of performance measures which is a foundation to a measurement system and strategic management” (Kaplan & Norton, 1997). It allows managers to identify which of the activities could be considered as critical for the well functioning of the organization that are directly responsible for the generation of value to the shareholders, clients, partners, providers and to the community.

SCOR is as the cross-industry de facto standard diagnostic tool for supply chain management grounded on three fundamental perspectives: processes, performance indicators and best practices (Supply Chain Council, 2005). SCOR is based on five distinct management processes: Plan, Source, Make, Deliver, and Return, which have many standard performance indicators associated to. The goal is to optimize and integrate processes and logistics while attending client needs.

In terms of performance indicators, Baldo et al. (2008) has developed a framework to identify the most relevant performance indicators that should be applied to a VE regarding the characteristics of the business opportunity and involved partners.

In terms of techniques, OLAP (On-line Analytical Processing) is an approach to quickly provide answers to analytical queries that are multi-dimensional in nature (sales, marketing, budgeting, forecasting, capacity, etc.). Via the so-called OLAP cube, it allows for complex analytical and ad-hoc queries with a rapid execution time based on historical data facilitating decision-making (adapted from Lechtenborger & Vossenm, 2003; Moon et al., 2007).

2.5. Performance evaluation

Performance evaluation aims at providing decision elements based on performance measurement results. The goal of this aspect in the context of VE evolution management is to provide partners with techniques that help them to evaluate the impact of their decisions at their companies along the discussion process. At the same time, it allows the VE coordinator to evaluate the global solution before validating the final decision.

According to Raj Jain (1991), the three techniques of performance evaluation are: (i) analytical modeling, (ii) simulation, and (iii) direct measurement. Each one has pros and cons, and there are several considerations to decide which technique is better to use, like modeling time, data acquisition, model complexity, execution time, required skills, among others. Actually, simulation has been attracting a large number of users due to its intrinsic capability for creating and evaluating what-if scenarios, capturing the dynamic behavior of the system (Johnsson & Johanson, 2003). On the other hand, analytical models are more adequate when near-optimum solutions are needed. Capacity planning is a sensible part as most of the problems that use to happen in the VE operation requires changes in the companies’ production capacity.

2.6. Information and Communication Technology Infrastructure

Information and Communication Technology (ICT) Infrastructures are a mean to support all (or almost all) the transactions among partners in a CNO. Actually, this is one of the conditions to work as such. In the context of VE evolution and decision-making, ICT infrastructures are responsible for providing the necessary functionalities to allow partners in making all the previously mentioned tasks: partners’ discussion, methodological guidance, decision protocols, performance measurement and monitoring and performance evaluation.

Security is a crucial issue to provide the required trust building in CNOs. Sowa and Sniezynsky (2007) developed a security framework that controls information access dynamically according to partners’ roles in a VE. This guarantees that all the sensible information can be accessed only by authorized partners. Yet, that the information comes from recognized and authenticated partners and sources.

Rabelo et al. (2008) developed an integrated, web-based and on-demand ICT infrastructure devoted to cope with CNO requirements. Although it currently does not have implemented all those necessary functionalities to support the VE evolution phase (at least in the way the problem is approached in this work), it is opened to receive new functions.

The combination and some adaptations in all these mentioned works are seen as a feasible starting point to support the envisaged distributed and collaborative decision support scenario.

3. Collaborative decision support for the virtual enterprise evolution

Previous section has presented the scenario for the management of VE evolution associated to the collaborative decision making as well as the aspects to support it. In order to cope with all of them, a framework has been conceived. This framework gathers such aspects and groups them into four categories, or pillars: Human, Organizational, Knowledge and Technological. The essential rationale of these four pillars is to enable humans to discuss and to decide about a problem related to a given organizational process, applying a set of organizational procedures and methods, using information and knowledge available in the VBE’s repositories, all this supported by a sort of ICT (technological) tools and infrastructures (Drissen-Silva & Rabelo, 2009a). That discussion is framed by a decision protocol (conceived using project management foundations) and is carried out within a distributed and collaborative decision support environment. The decision protocol is the mechanism which “links” the four pillars according to the particular problem to be solved within the VE evolution phase. Figure 2 shows the framework.

Figure 2.

Framework for VE Evolution Management.

The Human pillar represents people, i.e. the VE companies’ managers who use their tacit knowledge and collaborative attitude to help solving the problem came from the VE operation phase. It embraces the empowered managers and the experts that can (re)configure the decision protocols. The Organizational pillar comprises intra and inter-enterprises processes, ontologies as well as working methods, techniques and procedures that should be involved in a distributed and collaborative decision-making process. It embraces companies’ business processes themselves, project management, performance measurement and performance evaluation methods and techniques, and decision procedures and rules to be followed. The Knowledge pillar comprises explicit information and knowledge that are available in the VBE’s repositories and that managers can have access to for helping in the decision-making process. This embraces lessons learned, best practices as well as information about partners, regulations, historical data, etc. The Technological pillar refers to all kind of ICT tools, platforms and security artifacts that should be available to support managers in managing the processes accessing suitable methods. It embraces OLAP, BPM, simulators and groupware tools, besides databases, ontology management systems and the general computing infrastructure for systems deployment, security, communication, interoperation and services management.

It is important to point out an issue about the human pillar. SMEs have many difficulties in terms of management skills, whereas working in collaborative networks requires several levels of additional preparedness (Afsarmanesh & Camarinha-Matos, 2005 ). In fact, it seems unrealistic to assume that VE partners are already prepared and know the most relevant managerial and performance evaluation techniques and methods that can help them during the discussions and decision-making. If on one hand their experience and knowledge are of extremely importance for that, on the other hand they are insufficient for dealing with all the intrinsic complexity that managing the VE evolution represents. Therefore, in order to effectively support the use of the proposed framework, it is essential that VE partners are also empowered with adequate training. Klen et al. (2008) has proposed a methodology for training VBE members relying on governance and individual competences on VE management.

The proposed approach relies on and combines two basic areas: Project Management (PM) and Decision Support Systems (DSS). One of the most important framework’s elements is a decision protocol. It corresponds to a mechanism that coordinates the problem solving and that is based on an adaptation of the ECM (Engineering Change Management) model (Rozenfeld et al., 2006) for agile and change management. This protocol has the aim of guiding decision-makers towards more effective solutions in a methodological way. In essence, this all aims at offering a Collaborative and Distributed DSS for VE’s partners to get together to discuss about necessary changes but guided by a decision protocol that consider the most relevant VE characteristics. A set of performance evaluation and knowledge mechanisms completes the framework, providing a previous analysis before decisions are implemented. A database model saves all the discussed information for further auditing.

The management of collaborative projects deals within distributed environments. Activities and process are distributed through partners and organizations on different locations and countries, with different cultures but the management could be done in centralized or distributed way (Ollus et al., 2009). Collaborative work has been imposing the conception of a new kind of tools for supporting its management offering lessons learned and knowledge for future decisions (Loss, 2007). Differently from extended enterprises where there is a dominant enterprise (O’Neill, 1995), managing the VE evolution implies to consider that all partners are autonomous and have to participate in the decision making process transforming the evolution management a complex process.

3.1. Framework architecture

The four framework’s pillars are operated through three concrete elements: the decision protocol, the distributed and collaborative decision support computing environment, and the ICT Toolbox. They all form the Distributed Collaborative Decision Support System for the Management of VE Evolution (DDSS-VE). Figure 3 presents the framework architecture, also illustrating the relation of the elements with the pillars. Yet, it shows the three different types of actors that are involved in the discussions about the problem detected in the VE operation. To be highlighted the fact that all transactions – involving both humans and systems – are carried out over computing networks making use an adequate ICT supporting infrastructure.

3.1.1. Decision protocol

The decision protocol is a sequence of steps that defines the activities that have be executed in given situations within a given context to solve a problem. Conceptually, it should indicate what has to be done, why, by whom, where, when, how, and with which resources.

Figure 3.

Framework Architecture.

The conception of the proposed protocol has considered three aspects: its generality, its underlying foundation, and its execution automation. As far as the generality is concerned, the protocol is not seen as a reference protocol that would be generic enough to comprise all possibilities of how every single different problem should be solved by/at certain companies related to a certain VE. Instead, it is seen as a basis on which particular protocols can be derived, grounded on project management reference models, considering the VBE policies and operation rules. Figure 4 shows the proposed decision protocol.

This particularization means that new steps can be added, some modified / adapted and some disabled (Figure 5). The whole approach can be seen under three layers: basis protocol, specific protocol, and computer aided. As said before, the basis protocol layer for the VE evolution phase is the one showed in the figure 4, where the box outside the main square contains activities within the VE operation phase. The specific protocol layer represents the one that would have been customized for a given VBE and that would be effectively applied in the VEs created from it. The computer aided layer contains digital information repositories and very concrete ICT tools and infrastructure that are used to support the diverse actions in a decision-making process. This is made available via an ICT toolbox (see section 3.1.3).

A modification in the basis protocol is however not hard coded made. Thanks to a BPM tool, the protocol is flexibly modeled and directed connected to software services that execute the protocol’s steps themselves. Therefore, if a modification is required, the user modifies the processes at BPM level (or even at the SOA level), but not at programming code level. However, a protocol particularization has some restrictions. This refers to the second aspect of its design, which is the underlying foundation. Actually, the steps of the basis protocol comprehend the most typical ones presented in the changes management reference models, and ECM in particular (see section 2.2). Thus, users are not allowed to change its essential logical structure (the macro steps Need of Change Identification, Change Proposal, Change Planning, and Implementation, as well as some of their sub-steps). Besides using ECM and adapting it to the VE evolution context, this work has also used some ideas proposed in O’Neill (1995) when determining the most significant events to handle in more strategic decisions. In resume, this proposed decision protocol represents the mentioned framework’s methodology and it is modeled via BPM and SOA-based tools.

Figure 4.

Basis Protocol for the VE Evolution Management.

Figure 5.

Multi-layered conceptual scenario of the proposed framework.

3.1.2. Partners’ discussion environment

This second element of the framework corresponds to the Distributed Collaborative Decision environment and it is the main element to support partners’ discussion over the network.

It is important to point out that VE partners are fundamentally composed of SMEs. Therefore, it is important to offer an easy and low cost way to support the access to management methods, techniques and tools to help the involved people in the discussions, performance measurement and evaluation.

This underlying vision of this environment relies on the assumption that there is no sense to develop a wizard-like, expert systems or agent-based decision support systems solution that are used for modeling closed world problems (e.g. Baffo et al., 2008). Instead, partners should have room – with a methodological support and integrated within the companies’ business process environment – for exchanging ideas, exercising their creativity, and reasoning about particular cases based on the very current status of the involved companies.

In this environment, the actors involved in a discussion are (figure 3) the VE partners: 1) the VE coordinator, who owns the business and who is, at last, responsible for it; 2) the VE members, who are the companies’ representatives in the given VE and; 3) an invited expert (e.g. the broker, a specialized technician, a VBE’s representative), an ad-hoc member who may participate in the discussions and whose role is defined for each case.

This environment is controlled by the DDSS-VE. Based on different classifications for decision support systems (Turban & Aronson, 1998; Phillips-Wren & Forgionne, 2001) this model for distributed decisions support system with argumentation and moderation for the VE evolution (DDSS-VE) is of type:

• Negotiation: decision about a problem is reached via a negotiation process, where the reaching of the solution involves relaxations of constraints and changes in the plan;

• Decentralized: the VE coordinator coordinates the discussion but the decision itself emerge from the discussions;

• Partially hierarchical: the VE coordinator has the power to validate the final decision achieved after a (non-hierarchical) discussion;

• Multi-stage: a decision can be reached after several rounds of discussion;

• With semi-structured tasks: the problem and related information is partially made available by the DDSS-VE system and VBE’s information repositories, and the discussion is generally assisted. The other part of the information and knowledge come from the tacit knowledge of the own participants;

• Multi-participant: several members can participate simultaneously in the discussion;

• Team-based: although autonomous and independent, VE members act collaboratively as they share the same goal.

In order to give an overview on how the framework works, figure 6 illustrates an abstract discussion scenario to be supported by the DDSS-VE where partners would exchange their opinions about a given problem. Actually, DDSS-VE will manage the interaction among three entities. One entity is the companies’ representatives, each one having a DDSS-VE’s graphical interface to interact with. Another entity is the set of ICT and network infrastructure, tools (the ones common to all VBE members, and the local ones, accessible only by each company) and VBE’s information repositories (see next section). The third entity is the decision protocol, which will help guiding the discussions.

After the problem has been detected, DDSS-VE starts the protocol steps (Figure 4), within the Need of Change Identification phase. In this phase the goal is to identify the problem reasons and to check if it can be solved by the own partner, without impacting the other VE members. This reveals the strategy to involve the other partners only if the problem cannot be solved at a “local” level. For this, the VE coordinator and the partner that has generated the conflict (illustrated as Partner 1) discuss together (e.g. via chat and file transfer), initially. After discussions and evaluations, if the problem is considered solved without needing the other partners, the protocol’s flow goes through another phases, the Change Proposal, Planning and Implementation phases. In the case the problem could not be solved, it is necessary to evaluate which partners were affected and that should then be involved in the collaborative discussion and decision-making. In the Change Proposal phase, the discussion is supported by the services that combine the ideas of HERMES and Delphi methods (see section 2.1). The part inspired in HERMES aims to organize partners’ arguments in a concise structure, using an appropriate semantic, communicating their suggestions but in a compiled way, including an association of weights to the most important arguments. This aims at finding the better (and faster) consensus about the problem. The part inspired in the Delphi method aims at avoiding direct confrontations among participants, which could generate counterproductive discussions. In this sense, all the arguments are gathered by the VE Coordinator who, in a first moment, acts as the moderator selecting, deleting, changing or suggesting changes in the arguments received before they can be published to all participants. Actually, it is not the aim to restrain partners conversation and information exchange, but rather to guarantee a faster discussion and, mainly, that some sensible information (e.g. the precise level of capacity of a given partner) can be disclosed to everybody. In this way, the VE coordinator have the option to just say to the others that the given partner has “enough” capacity. This discussion round, with the compiled opinions, is illustrated as gray frames in figure 6, at each member’s side. The white frames illustrate the argumentation console where partners expresses their opinions as well as where the VE coordinator receives them. He moderates the discussion via this console. After the arguments have been sent out to the other participants, they can reevaluate their considerations and make other suggestions. This process continues until a consensus is reached (within the Change Planning phase).

The protocol is not fixed in its inner actions. Regarding VE uniqueness and topology, and the natural partners’ heterogeneity, the protocol can be different for each situation. There are many possible scenarios that could influence the decision to be taken in order to solve the current problem. In this way, the protocol acts as a reminder of some more important questions so that partners can recall they should check them. For example, if an item is delayed and the final customer is very important or the fine is too high, partners can agree on subcontracting part of the production in order to keep the delivery date. If the client has a very rigorous quality control and he manages the suppliers’ certification level quite tightly, perhaps is not possible to hire any company, but one equivalent, and so forth. In the case of any other particular issue, partners should handle this, managed by the VE coordinator. Once the problem is solved, the new VE’s parameters are set up (Implementation phase) and the control flow goes back to the VE operation phase.

This hypothetical argumentation scenario would be based on the results achieved helped by a pool of tools for performance evaluation modeling, monitoring and tasks rescheduling, which can also involve the invited expert’s opinion (Change Planning). Some participants could use their own tools or the common toolbox (including the access to the VBE database) available to all participants to help in the discussions.

Figure 6.

Illustration of the collaborative decision support environment.

3.1.3. The tool box

Traditionally, SMEs have many difficulties to access, use and maintain software, mainly due to its costs and to the required expertise to do that. The toolbox concept was introduced in (Bernhard, 1992) with the goal of providing a pool of industrial software to help users from all departments of a single company to implement the CIM philosophy (Computer Integrated Manufacturing).

This concept was largely extended in Rabelo et al. (2008) through the development of a web based distributed ICT infrastructure (ICT-I) devoted to CNOs. The access to ICT-I is totally made in the form of services, which are invoked either by the user or by other software services. Besides integrating many CNO supporting tools, it provides the access to the VBE’s information repositories. These tools cover the VE creation (Afsarmanesh et al., 2008) and operation phases (Negretto et al., 2008). However, there are no specialized services for the VE evolution and dissolution phases yet.

Taking the ICT-I scalability facilities into account, the framework for the VE evolution and associated protocol was added to and seen as another class of services of ICT-I. This also involves some non directed CNO-related services, such as simulators, spread sheets, CSCW, assisted methods and other supporting tools that help VE members along the protocol execution. This all corresponds to the computer aided layer illustrated in figure 5.

In this work, these supporting tools are group into a logically centralized repository of ICT tools called ICT Toolbox. ICT Toolbox is therefore a pool of common tools that are accessed via ICT-I – hence via the network – facilitating members’ acceptance and use of management methods. This however does not cover the existing local tools used by each member at their companies. The Toolbox’s tools themselves can congregate both the set of tools previously agreed (or existing) in the VBE and tools that can be accessed on demand from other providers.

4. Prototype implementation

This section presents the results of the implementation of the DDSS-VE framework, which is concentrated in three different functionalities: the Decision Protocol, the Partners’ Discussion Environment and a Tool for previous evaluation scenarios. The decision protocol once started will help manager to do actions in the right moment in the decision making process. It was used an adapted VBE database in order to access the competences of all partner in the usage scenario. Partner’s Discussion Environment is implemented considering ideas from HERMES System and Delphi method, applying a collaborative discussion with voting and comparing suggestions all on supervision by the moderator. The Toolbox is populated with a tool for capacity planning using the performance evaluation method applied in advanced dashboards. Within a controlled testing environment, the problems detected in the VE operation phase are manually introduced and the discussions are simulated in a distributed scenario using a number of PCs.

As already said, the Collaborative Discussion Environment has the goal to combine HERMES system and Delphi method, and to adapt them to the desired decision philosophy. In other words, it aimed at facing the partners’ autonomy and transparency requirements as well as the need for a more structured way of deciding. The main adaptations include:

• The creation of a moderator (role), who is responsible to evaluate and to make available the arguments sent by members. Depending on the case, the moderator can be the own VE coordinator;

• The comparison of two different arguments using different connectors (better than; worse than; equal to; as bad as; as good as). Each comparison assigns negative and/or positive points to each argument, depending on the connector;

• Voting: Partners can vote pro or against to each argument;

• During the discussion, partner are guided by the Decision Protocol;

• Is possible to use a previous evaluation decision tool, in order to evaluated the impact of a new scenario into the VE operation.

4.1. Usage scenario

In order to evaluate the collaborative discussion using the DDSS-VE, a VE scenario has been created. This VE would be responsible to develop a new helmet style for racing, involving four partners from different countries (Drissen-Silva & Rabelo, 2009b).

Considering the decision protocol showed in figure 4, it is assumed that the phase “Need of Change Identification” has been passed. Figure 7 illustrates in a general way how the discussion would try to solve the conflict resolution from the protocol‘s phase “Change Proposal” on. All this have been implemented in a web portal, on top of Liferay web application server (www.liferay.com). In this example, the VE Coordinator (Mr. Ricardo) has concluded that it is necessary to start a discussion with two members (Mr. Marcus and Mr. Rui) due to a problem detected in the specification of the first lot. After starting the collaborative discussion, the protocol gets in the “Changing Planning” phase where different scenarios are evaluated using tools form the tool box. “Changing Planning“ phase ends when the best alternative has been chosen in the “Implementation” phase, where the new scenario is put on practice. The sequence described below quickly explains figure 7.

Starting the discussion (to be conducted via the DDSS-VE):

1. The protocol ask some questions to delineate the better attitude for each case (e. g. if it is a rigorous client constraint that avoids from choosing another supplier);

2. Each participant can use some tools to preview which different scenarios could be acceptable to reschedule the activities that have to be done, choosing the best one, and publishing it as a suggestion for the problem resolution:

3. Mr. Rui posts the first suggestion: ‘Buy from another supplier’ (Figure 7a);

4. Each partner can vote pro or against it (bottom Figure 7a);

5. Each suggestion can be compared with other suggestions using ‘COMPARE’ button (Figure 7a). Figure 7b presents the list of suggestions and the possible logical connectors. For example, a comparison using ‘is better than’ as the connector assigns +1 point to the best suggestion and -1 to the worst;

6. Figure 7c shows a tree (associated to the detected problem: helmet strip allotment) with the three posted suggestions (plus authors) and four comparisons among them. One of them is not yet evaluated as it is ‘awaiting approval’;

7. The moderator (Mr. Ricardo) evaluates the different suggestions and the comparisons, mainly to see if there is some confrontation among the participants:

8. Figure 7d shows the Moderator’s view. He can modify and/or simply approve Mr. Rui‘s opinion (“RE: buy from another supplier is as good as …”) and send them to the group;

9. Figure 7e represents the vision seen by the other two members before Mr. Rui‘s opinion approval. Thus, they only see ‘message awaiting approval‘;

10. In what the final voting result is concerned:

11. It is possible to see the number of votes of each suggestion, which is +3 in relation to the Mr. Rui’s one (Figure 7a), also meaning that the three consulted members (including the VE coordinator) have agreed on it;

12. Figure 7c shows a signaled number beside each suggestion expressing the final sum of voting with the weights of comparisons. In this case, ‘Buy from another supplier’ has more positions in favor (+3 from direct voting) that is added to more 2 points from two positive comparisons, resulting 5 points in favor;

Once agreed, the most suitable solution is settled on the VE plan and partners (re)start to work based on it. This means that VE evolution is ended and the VE management goes back to the operation phase.

4.2. Previous evaluation tool for decision making

Performance evaluation needs the selection of the most important factors for the best system’s performance. For each factor is necessary to set some levels (in terms of numbers) they could assume. In a manufacture environment the factors could be machines or employees, for example, and levels could be the quantity each one could be available. The performance evaluation could indicate which is the most important factor in the system’s performance effect.

In order to offer a tool for previous evaluation of the decision’s impact using performance evaluation it was developed a module adequate to the conceptual model previous described. This tool uses different spreadsheets compounding a dashboard that offers the possibility to see each partner’s competence, production scheduling, available resources, number of resources looking for the integrations of the scheduling in order to calculate another scenario for solving the problem in the discussion on DDSS-VE. Figure 8 shows the developed dashboard.

Figure 7.

Some snapshots of the Partner’s Discussion Environment.

5. General evaluation

The developed prototype passed through a sequence of exhaustive tests for the verification and validation of the conceptual model for the collaborative discussion around a problem emerged in the Virtual Enterprise operation phase forcing it to go on the evolution phase. The conceptual model and the prototype were evaluated by experts on the main areas studied in the model development process. In the evaluating average all experts agreed in the contribution, relevance and attending the needs of the scientific problem to be solved: ‘to find a more transparent and collaborative environment that puts autonomous partners in a discussion around the partnership conflict using a set of computable tools and a decision protocol to support the decision’. The methodology used to evaluate this work followed three main steps: i) prototype evaluation in a sequence of stressed tests; ii) explanation the conceptual model by a scientific article to the experts with a number of questions answered with their evaluation; iii) explanation the prototype functionalities in an example execution with another number of questions answered with their opinions.

Figure 8.

Previous Evaluation Scenarios Tool using Dashboards for Tasks Rescheduling.

5.1. Contributions

Main scientific contribution of this work is centered in using different techniques, tools and methods already acceptable in an adequate semi-automated system that help managers in the decision making process around a problem in the VE operation phase. The integration of those different methods can offer a distributed and collaborative discussion with transparency, controlled by moderation using previous analysis of the decision’s impact.

Central element is the human, who has the ability to feel and to decide what is the best scenario respecting his knowledge. The framework can only support his decision offering flexibility, calculus tools and communication availability through partners.

Compared with the state-of-the-art in the area, this work covers different aspects, which are showed in the Table 1.

Considering the flexibility offered by the decision protocol, this framework could be adapted to other strategic alliances models and also to the management of virtual organization operation phase, only making the necessary modification on the some phases and processes in the base protocol in order to attend different cases needs.

5.2. Limitations

The main limitation of this work is related to CNO concept that assumes each partner are autonomous and has to participate in a collaborative way trying to help other partners in difficulties. Some aspects related to VE concept is difficult to reach in the reality because trust among partners has to be strong, and also it is necessary a well developed ICT infrastructure to put this environment on work. But on the other hand, there are a number of VBE in execution in the world that feed expectative of a strong dissemination of the VE concepts to these kinds of enterprises collaborative environment.

	Traditional Management Model	CNOs / VEs; (current approaches)	CNOs / VEs; (proposed approach)
Decision	Centralized	Centralized	Decentralized
Information sharing between partners	No or eventual	Yes	Yes
Transparency in the decision	No or partial	Partial	Yes
Decision quality evaluation	No	Low and Eventual	Yes
Decision scope	Intra-organizational	Inter-organizational	Inter-organizational
Decision process Rigidity	Inflexible / “Data flow”	Inflexible / “Data flow”	Flexible / Systemized / Adaptable
Information integration between partners	Low / Medium	Medium / High	High / Very high
Trust between partners	Implicit	Explicit	Explicit / Reinforced
Decision objective	Best global results	Good global results	Good global results with previous analysis
Mutual help between partners	Cooperation	Punctual; Collaboration	Full-fledged; Collaboration along decision making
Methodological aid / Assisted decision	No or partial	Low efficiency and without assistance	Yes

Table 1.

Source: Adapted from Drissen-Silva & Rabelo, 2008. Comparison between traditional management model, current and proposed CNOs/VEs approaches.

Considering the prototype it was developed only with one tool for supporting previous impact analysis of the decision, but the conceptual model can consider a big number of available tools those could be put in a collaborative access environment for all partners.

5.3. Future research

Considering the high complexity of the problem presented in this work, there were another themes to be researched to better develop the ideas described in the Distributed and Collaborative Decision Making Environment for the Virtual Enterprise Evolution (DDSS-VE), for example:

• Development of a model that consider aspects of hierarchy, power and governance between VBE and VE partners. A model that also consider the moderator’s competence and his position during the decision process;

• Adequate the collaborative discussion environment, that uses ideas from HERMES system and Delphi method to the Moodle system;

• Creation of an ontology that describes formally the relations, hierarchies and concepts associated to the explored domain on decision making in the Collaborative Networked Organizations (CNO).

6. Conclusion

This chapter has presented a framework to support a collaborative discussion among VE members for solving problems during the VE evolution phase. It is essentially composed of a decision protocol, a distributed and collaborative decision support system, and of ICT supporting tools and communication infrastructure. It was designed to cope with the VE requirements, mainly in what members’ autonomy and decision transparency is concerned.

Developed based on project management methodologies, discussions are guided and assisted by the system but preserving and counting on the members’ experience and knowledge in order to reach a suitable/feasible solution for the given problem.

The proposed framework groups such requirements and organizes them into four pillars: Human, Organizational, Knowledge and Technological. The essential rationale of these four pillars is to enable humans to discuss and to decide about a problem related to a given organizational process, applying a set of organizational procedures and methods, using information and knowledge available in the VBE’s repositories, supported by a sort of ICT tools. A crucial aspect in the proposed approach is the human intervention, i.e. the problem is so complex that is unfeasible to try to automate the decisions. Instead, the approach is to put the managers in the centre of the process, surrounding them with adequate tools and methods.

All the framework’s elements operates in a methodological way by the human element, on a democratic, transparent, decentralized, systematized and moderated basis, considering their geographical distribution.

In order to offer more quality in the suggestions made by each partner during a discussion around a problem resolution, different tools, techniques and methods for performance evaluation are offered to provide a vision for a future capacity planning in order to evaluate different scenarios for solving the problem in discussion. In this way, the participants have conditions to previously evaluate the impact of the decision to be taken. This evaluation can be made isolated by each participant during the conflict resolution process.

A software prototype has been implemented to evaluate the framework, and it was tested in an open but controlled environment. The implementation copes with the required flexibility and adaptability of the decision protocol to different VEs, applying BPM (Business Process Management) e SOA (Service Oriented Architecture) technologies as a support for. The developed framework fundamentally assumes that VE partners are all members of a kind of cluster of companies. This presupposes the presence of a reasonable degree of trust among members, of an adequate computing infrastructure, of common organization vision (in terms of collaboration and enterprise networking) and operational procedures to be followed when problems take place, and that VE managers are trained for that.

The implementation results have showed that the proposed mechanisms for supporting partners’ autonomy, Internet-based decentralized decision-making, voting and transparency have worked out in a controlled environment. During the discussions, selected partners can have access to the problem, can freely exchange opinions about how to solve it, and can express their preferences via voting. This guarantees that the solution emerges from the collaboration and trust among partners. The decision protocol helps participants to take the right action on the right moment. The scenarios evaluation tools is capable to offer a pre-evaluation of the decision impact.

This work’s evaluation was composed of a set of procedures that offers conditions to affirm the final general research conclusion: “A semi-automated decision protocol, flexible and adaptable, integrated with scenarios analysis tools and a collaborative discussion environment makes better the quality and trust in the decision around a problem in a VE”.

Acknowledgments

This work is partially supported by CNPq – The Brazilian Council for Research and Scientific Development (www.cnpq.br). The authors would like to thanks Ms. Cindy Dalfovo, Mr. Leonardo G. Bilck and Mr. André C. Brunelli for the software implementation.