Reference Models for Virtual Enterprises

Business and Reference Models for Virtual Enterprises

Martin Tølle1, Peter Bernus2 and Johan Vesterager1

1Department of Manufacturing Engineering and Management, Technical University of DENMARK
Email: [mat, jve]@ipl.dtu.dk

2Griffith University, Nathan (Brisbane) Queensland 4111 AUSTRALIA

Email: bernus@cit.gu.edu.au

This article presents a generic Business Model for Virtual Enterprises (VEs) and analyses different types of Reference Models (RMs) applicable to support the set up and (re)configuration of VEs. RMs are models capturing concepts common to VEs aiming to convert the task of setting up of VE towards a configuration task, and hence reduce the time needed for VE creation. The RMs are analysed through a mapping onto the Virtual Enterprise Reference Architecture (VERA) based upon GERAM created in the IMS GLOBEMEN project.

1INTRODUCTION

Enterprises co-operate more and more extensively with other enterprises in all product phases of a product’s life cycle. This is driven by to various reasons such as cost reduction, flexibility, and a connected focus on core competencies. The result is anything from rather stable alliances between partners in fixed supply chains to a more transitory co-operation as in a virtual enterprise (VE). One possible definition of a VE is that a VE is a customer solution delivery system created by a temporary and re-configurable Information and Communication Technology (ICT) enabled aggregation of core competencies [Vesterager et al, 1999]. VEs can be formed to perform a one-of-a-kind production or service task, such as building a plant, or building of a ship, but VEs can also be formed to perform the manufacturing of a product line, or the delivery of after sales services for a product line [Hartel & Burger, 2001]. In this latter case several VEs can be set up depending on e.g. the service needs, alternatively a VE may sustain for a long time, but during its lifetime its constituents may change – such as some suppliers leaving the VE and some others joining it.

The potential competitive advantage of a VE – is to being able to configure world class the best available competencies of several companies together into a project enterprise. – However, this is often jeopardised by the time it takes to set up a VE; especially if the VE is composed of partners without thorough knowledge of each one another before the formation of the VE [Tølle et al, 2002].

The concept of Virtual Enterprise (VE) has been in currency for some years [Davidow & Malone, 1992] [; Goldman et al, 1995]. Other authors have given similar definitions of VEs, placing emphasis on the speed and agility with which such entities must be formed [Kusiak, XXX; Goranson 1998; Goranson 1999]. However, the implementation of VEs has been hindered by the lack of well-documented and analysed models in the open literature. The concept is to design entire supply chains in which a multitude of companies co-operate and co-ordinate their actions – as if they were part of a single enterprise. Furthermore, the idea of VEs involves the requirement that VEs should be able to be frequently modified to suit changing business requirements. Unfortunately, the know-how of how to do this is at present not widely disseminated, and even those large companies, which have such coordinated and flexible supply chains use only part of the VE concept. This article presents a generic Business Model, which applies to many industries and can be tailored to the particular situation of individual companies.

A Business Model is an arrangement between companies where the relationships among the participants are strategically designed, so as to be able to perform sustained business activity with the aim of cost-optimised and high quality delivery of production and services. The Business Model defines the roles of participants – some being core partners, and some suppliers (while less strongly bound to the given business) – all being co-ordinated through a set of management processes inherit to the model. Through this Business Model VEs can be formed on demand for the production of goods or the delivery of services, as well as can be reconfigured in a short span of time as business requirements change. While in general the term ‘business model’ might be interpreted in various ways, it is used here in a narrower sense, to signify the result of the strategic management process that identifies how and under what conditions business is to be conducted in the future – thus it is a description, or ‘model’ of the business.

In order to implement such a Business Model and be able to form VEs in a short span of time so called Reference Models (RMs) are needed. Reference Models are models of business processes, information models describing the structure of data exchanged through interfaces, resource models among other things describing the structure of hardware and software resources as well as their necessary capabilities, and organisational models that describe how human and automated resources are best allocated to tasks in the business processes (including management, production and service processes). In other words, a Reference Model is a blueprint that companies can follow to design their own particular model of VE creation and operation.

The availability of reference Models has been a critical success factor in the widespread use of enterprise architectures. E.g., the usefulness of the ARIS [Scheer, 1998] framework (ARchitecture for Information Systems) – which is the framework used by many users of the SAP ERP (Enterprise Resource Planning) system – is greatly enhanced by the availability of an extensive set of reference models for typical business functions in many industries [SAP reference models]. Unfortunately, detailed enough reference models for VEs have not been published in the open literature, and this has been an entry barrier to companies who wished to exploit the VE concept, as had been evident from the result of workshops held as part of the ICEIMT process (International Conference on Enterprise Integration and Modelling Technology) [Kosanke and Nell, 1997]. This problem has been recognised and made part of several research and development programmes, such as the GLOBEMEN consortium, however, more needs to be done as evidenced in the EU IST Framework 6 Programme.[PB1]

This article presents results from the recently finished IMS GLOBEMEN project [GLOBEMEN]. The objective of this article is twofold. Introducing and analysing different types of Reference Models (RMs) applicable to support the set up and (re)configuration of VEs. Second, to show how the Virtual Enterprise Reference Architecture (VERA), created in GLOBEMEN based upon GERAM [GERAM, 2000], can be used as a structuring architecture by mapping the RMs onto it.

GERAM was developed as a generalisation of several enterprise reference architectures (also sometimes called architecture frameworks), such as GRAI [REF], CIMOSA [REF], PERA [REF], became part of the international standard ISO 15704, and work is underway[1] to demonstrate the possibility of mapping onto GERAM of other architecture frameworks that were not originally used in the creation of this generalisation, such as the Zachman Framework [REF] and the C4ISR/DoDAF [REF].

While GERAM (and compliant reference architectures) could be used to systematise the set of necessary reference models for VEs, these architectures, being of generic nature, require that the user should identify the enterprise entities involved in creating and operating VEs. Once this has been done, there will be a modelling framework for each enterprise entity. Therefore to create a consensus about what types of entities are involved in VE creation and operation, the GLOBEMEN Consortium decided to develop a specialisation of GERAM (and its reference architecture GERA), called VERAM (Virtual Enterprise Reference Architecture and Methodology) and VERA (Virtual Enterprise Reference Architecture) respectively. While GERA defines the need for the identification of enterprise entity types and proposes a generic relation between these, VERA has a built-in set of VE-related enterprise entity types and their relations are elaborated so as the user of VERA may identify these relations as representations of the company’s business relations in the VE context.

The use of a life-cycle based Reference Architecture (such as VERA / GERAM) is that these architecturesit systematises the set of models necessary to develop VE capability, and help companies to implement a Business Plan, with clear deliverables.

Section 2 introduces in more details the concept of virtual enterprises and further explains the need for RMs in VEs. In Section 3, VERA is presented. The following sectionSection 4 describes RMs applicable for VEs by mapping them onto VERA and thereby shows how VERA can be used to structure the different RMs. The methodology followed in this section was to identify models that builders of a VE business need but at the moment can not be regarded as generally followed best practice (but are needed in a VE setting, e.g. ISO 15288 ‘System Life Cycle Processes’), or models which may be presently in use in companies, but the relevance of these to the VE building effort is not generally known (and thus may be the source of parallel development in the company, e.g. ISO 9000:2000). This eliminated the need to compile a comprehensive list and mapping of it onto VERA, although the authors recognise that the listed set of eight RMs may have to be extended in the future. The control of this methodology was to confirm the relevance of the models that were actually mapped with GLOBEMEN Consortium partners. RMs that are specific to the actual production or service that VEs deliver have not been included in this mapping – although it goes without saying that in the design of the mission fulfilment by VEs (i.e. by the involved processes as performed by contributing partners), a number of other, industry-specific, RMs must be taken into account (e.g. STEP product data exchange standards [REF]).

Adiscussion concludes this article.

2VIRTUAL ENTERPRISE & REFERENCE MODELS

2.1Virtual Enterprise

This article applies the VE understanding of the GLOBEMEN project, which regards a Network of Enterprises (the ‘Network’) as the breeding ground for the preparation and formation of VEs, cf. Figure 1. It has been understood in the Globemen Consortium, that VE creations to different extents require a high degree of preparedness on behalf of business partners. Partners need to have a demonstrated capability, relying on management competencies for VE creation (which includes a level of enterprise engineering knowledge as well as the possession of Reference Models that can be used for fast creation or re-creation of VEs), as well as partners need to have tested ICT building blocks available that can be used to realise operational systems based on these models. The collection of the above may be called preparedness for VE creation [REF Kåre Christiansen thesis].

It is important that this VE creation task must be done through configuration rather than for example ad hoc decision of procedures and rules or through new software design and implementation, because the objective is to be able to create and re-create efficient VEs in a very short time.

To achieve the mentioned preparedness it is necessary to identify (and if not available then develop) a set of reference models for network and VE creation and operation. To make this task managable the focus was on models that can be commonly used by all partners in the Consortium, as opposed to models that would have been relevant only to some partners.

Figure 1: Enterprise Networks and Virtual Enterprises

Thus as a part of forming the Network, network partners will establish a degree of preparedness for forming particular (individual) VEs. VEs are formed based on the production and service competencies available in the network in order to meet customer demands as well as necessary management competencies in order to manage the realisation. Additional competencies from sub-suppliers or local contractors may be included in VEs as well [Vesterager et al, 1999] & [Tølle et al, 2000].

Depending on the roles that partners and suppliers take in a Network and its VEs there can be a variety of Business Models. They can cover from at one ‘extreme’ the network being a loose association of partners where the network only offers brokerage services bringing together partners with suitable suppliers, to a more controlled Network, where a few partners and pre-qualified suppliers form carefully pre-designed types of VEs. This article focuses on RMs for this second type of VE. Still, within the limits of these RMs there can be differences, depending on the set of functions that partners wish to perform through the Network and its VEs and those functions, which remain within the operations of the individual partners. It is the strategic intent of the partners that determines which functions to share and which ones to keep within the walls of the company. Clearly companies do not wish to share functions that are part of their core competencies.

Importantly, the Network not only creates VEs and sets them into operation, but also ensures that the knowledge and experience gained during the operation of VEs is captured. Thus, when the customer’s demand has been satisfied, the experiences gained in the VE are transferred back to the network, the VE is decommissioned, and the network awaits or seeks other possibilities in the market [Vesterager et al, 1999] & [Tølle et al, 2000].

2.2Reference Models

The mentioned preparedness of partners can be achieved by adopting existing RMs and/or by creating RMs for e.g., the Network, VEs, the participating enterprise and/or the products and services of VEs. Some of these RMs will describe the production and service processes (and associated information, resources and organisation) [Bremer, 2000], [Bernus et al, 2002b], and some will describe the necessary management processes [Kalpic & Bernus, 2002].

A reference model (RM) is a model that captures characteristics/concepts common to several entities (e.g. networks or VEs) [Mertins & Bernus, 1998]. The purpose of RMs is to “capitalise on previous knowledge by allowing model libraries to be developed and reused in a 'plug-and-play' manner rather than developing the models from scratch” [GERAM, 2000]. Hence, RMs “make the modelling process more efficient" [ibid.].

RMs for Virtual Enterprises are used to convert the VE formation task into a re-use and configuration task obtaining a quick, low-cost, and secure VE creation process [Tølle et al, 2002]. They can have many forms, covering different aspects and be applied in many ways. It is important to note that despite RMs often representing generally accepted characteristics of a group or type of entities or a way of doing things; they should not be applied uniformly within all enterprises/projects [PMBOK, 2000] – they often have to be adapted or instantiated before use. This process is called tailoring [Bernus et al, 2002b].

3VIRTUAL ENTERPRISE REFERENCE ARCHITECTURE

As a continuation of the work in Globeman21 [Vesterager et al, 1999] the GLOBEMEN project has defined a Virtual Enterprise Reference Architecture (VERA) based upon the GERA modelling framework of GERAM [GERAM, 2000]. VERA is a central layer of the so-called VERAM framework (Virtual Enterprise Reference Architecture and Methodology) [Zwegers et al, 2001, 2002]. As shown in Figure 2 VERA captures the VE concept described abovein Section 2.1. VERA consists of three recursive entities, viz. a network, VE and product. The figure shows that the network in its operational phase creates VEs and a VE carries out some products life cycle phase activities (indicated by the double arrows).

Figure 2: Virtual Enterprise Reference Architecture (VERA)

Each of the three entities is represented by use of the three dimensions of the GERA modelling framework: the life cycle dimension, the genericity dimension, and the view dimension [GERAM, 2000]. More elaborate descriptions of VERA can be found in [Vesterager et al, 1999, 2001a, 2001b, 2002].

The generic and partial boxes in Figure 2 have been shaded indicating the location of RMs in VERA. The remaining non-shaded boxes represent the particular entities containing instantiated RM components or self developed components. Enterprises engaged in VE-focused networks should determine which of the non-shaded boxes they would need to prepare up-front and most importantly by what means (using available standards, RMs from other sources, and/or through the development of their own RMs) [Tølle et al, 2002]. It is important to note that this is not an “either-or” choice, but more a matter of assessing available RMs and fill in the blanks by self-developed RMs. Of course, enterprises should only develop own RMs if needed and not publicly available elsewhere.

As indicated in Figure 2 RMs are, or can be, developed for all three entities. Models addressing the product itself (e.g. product models, engineering bill of materials), although important for a fast product realisation, are product and industry specific and will not be addressed in this article. The focus of this article is RMs describing the network and VE entities including how to execute product related activities in VEs (distributed concurrent engineering, procurement, quotation, etc.).

4VE REFERENCE MODELS

4.1Mapping Reference Models to VERA

As mentioned, in the process of preparing and setting up VEs different types of RMs should be considered. Applying the modelling views of VERA/GERA (cf. Figure 2 and Figure 3) can help distinguish between different aspects that should be addressed by RMs. The Functional view represents the activities and the (temporal) behaviour of the business processes of the entity [GERAM, 2000]; the Information view represents data models for e.g. strategic information systems requirements capture, management database design (e.g. management information system database, data warehouse), and operational database design (e.g. product data representation); the Resource view consists of resource models for software and hardware, and for management and control information system; the Organisational view represents organisational models for designing the organisation [Bernus, 1999] and among other things describes the allocation of resources to activities / processes. Note that in the first two life cycle phases of an entity (i.e. identification and concept phase) no distinction is be made between the modelling views.

In the following some of available RMs or RMs under development will be described by mapping them onto a subset of VERA depicted in Figure 3. The mappings are intended to support enterprises, preparing for or operating in a VE focused network, to identify RMs of possible relevance. The VERA subset consists of the network and VE entities and applies the life cycle dimension, the modelling and purpose views of GERAM. Thereby, VERA provides a structure which allows a mapping of RMs related to the set up and (re)configuration of Networks and set up and (re)configuration of VEs by a network.