Engineering the Virtual Enterprise: An Architecture ... - Semantic Scholar

The International Journal of Flexible Manufacturing Systems, 13 (2001): 145–162 c 2001 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

Engineering the Virtual Enterprise: An Architecture-Driven Modeling Approach ADRIEN PRESLEY Division of Business and Accountancy, Truman State University, Kirksville, MO JOSEPH SARKIS Graduate School of Management, Clark University, Worcester, MA WILLIAM BARNETT College of Business Administration, University of Louisiana-Monroe DONALD LILES Industrial and Manufacturing Systems Engineering Department, University of Texas at Arlington

Abstract. The managerial and organization practices required by an increasingly dynamic competitive manufacturing, business, and industrial environment include the formation of “virtual enterprises.” A major concern in the management of virtual enterprises is the integration and coordination of business processes contributed by partner enterprises. The traditional methods of process modeling currently used for the design of business processes do not fully support the needs of the virtual enterprise. The design of these virtual enterprises imposes requirements that make it more complex than conventional intraorganizational business process design. This paper first describes an architecture that assists in the design of the virtual enterprise. Then it discusses business process reengineering (BPR) as a methodology for modeling and designing virtual organizations. While BPR presents many useful tools, the approach itself and the modeling tools commonly used for redesign have fundamental shortcomings when dealing with the virtual enterprise. However, several innovative modeling approaches provide promise for this problem. The paper discusses some of these innovative modeling approaches, such as object-oriented modeling of business processes, agent modeling of organizational players, and the use of ontological modeling to capture and manipulate knowledge about the players and processes. The paper concludes with a conceptual modeling methodology that combines these approaches under the enterprise architecture for the design of virtual enterprises. Key Words: business process reengineering, process modeling, virtual enterprises

1.

Introduction

Increasingly, continued competitiveness by manufacturers in the evolving global economy depends on their ability to practice the principles of agility and agile manufacturing. One key vehicle for competitiveness is the participation of agile enterprises in virtual enterprises (VE). The VE is a form of joint venture but with important differences. It is designed to be a temporary alliance of member companies who join to take advantage of a market opportunity. It is expected that the VE will possess almost no employees or inventoried resources. Each member organization provides its own core competencies in organizational functional areas such as marketing, engineering, and manufacturing. Only a small headquarters staff

146

ADRIEN PRESLEY ET AL.

is required, to deal with administrative and management details, with the actual work being performed by geographically separated shareholder companies, subcontractors, and partners joined through computerized hardware and software. When the market opportunity has passed, the VE is dissolved. The VE differs from existing interorganizational models by the degree of shared accountability and responsibility of the participants and the structure by which companies contribute their competencies through “plug compatible” processes. The rapid formation and reconfiguration of enterprises and their processes, and the need to protect the core competencies and workings of individual partner enterprises, provide complexities for process engineering and integration. One aspect of responding to this change is the ability to effectively design an enterprise’s processes through efforts such as business process reengineering, enterprise integration, and enterprise engineering. All these efforts concern themselves with the design of processes to achieve enterprise goals. In the case of the VE, even the goals of the partner organizations must be integrated. A common thread among these organizational development approaches is the use of process models as an aid to the understanding and design of the organizations. Process modeling characteristic requirements for VE modeling and design call for innovative tools and techniques. In evaluating these innovative tools and techniques, we first describe and present the concept of enterprise architectures. A more detailed VE architecture description then provides the foundation for process design, development, and application tools for engineering the virtual enterprise. We then investigate the current available techniques and tools for process modeling and the varying requirements for the VE. Additional research opportunities and avenues for more effective treatment of these issues are presented with the introduction of some conceptual models. 2.

Enterprise architecture

An enterprise is a collection of enterprise activities organized into a set of business processes that cooperate to produce desired results. In the context of this paper, an enterprise activity is defined as any organized behavior that transforms an input into an output. The paper proposes that enterprise activities are the basic building blocks of an enterprise and, furthermore, that enterprise activities become useful and add true organizational value only when organized into business processes. An enterprise architecture can be thought of as a “blueprint” or “picture” that assists in the design of an enterprise. 2.1.

A generic enterprise architecture

The presentation of a general generic architecture is an important foundational element for describing the VE architecture. In this section, we describe one such architecture and its development. In structuring a generic architecture, we researched into current “enterprise” architectures. Examples of these architectures included computer-integrated manufacturing (CIM) architectures and activity enterprise modeling efforts (Automation and Robotics Research Institute, 1990; National Center for Manufacturing Sciences, 1992). In addition to the

ENGINEERING THE VIRTUAL ENTERPRISE

Figure 1.

147

Top-level activity view.

information obtained from these sources, experts in enterprise development verified a number of the models presented here. Activity and process models of a generic manufacturing enterprise have been completed. Other proposed architectures were studied to identify the activities performed by a generalized manufacturer to investigate the proposed integration strategies for linking activities into an efficient manufacturing system. The integration strategies and structures were considered in the development of the TO-BE activity and process models. A team of experts from industry assisted in the validation of the models. In the second phase, several small manufacturers were studied to analyze and document their AS-IS activity and process models. The results were combined to develop a consensus AS-IS architecture, consisting of a process view and an activity view. The top-level diagram of this generic activity model is shown in figure 1. The model is described using the IDEF0 formalism, in which boxes represent activities and arrows represent the flow of information or material between the activities. Arrows entering a box from the left are inputs to the activity, which are transformed into the outputs represented by the arrows leaving the box to the right. Arrows entering the top of the box represent things that control the activity (Mayer, Painter, and deWitt, 1992). Each box is decomposed into “child” diagrams, which further describe the parent activity. Supporting text is present for each diagram. The six highest-level activities described by the models are 1. Perform strategic planning. Activities are associated with the long-term strategies of the enterprise. This planning is concerned with defining, in broad outline form, an

148

2.

3.

4.

5.

6.


enterprise’s long-term goals, translating those goals into measurable objectives, and determining the strategy by which those objectives can be met. Manage resources. This function concerns the management of resources, including capital, personnel, information, and facilities. It translates the strategic-level objectives into tactical plans, defining the expected contributions of each operational level. Market product. This function provides the enterprise with its dynamic external links to customers and the environment. It is responsible for identifying and translating customer requirements into information usable by the design and manufacturing functions. Orders for products are the responsibility of this function. Design product and process. This function is responsible for developing the products and the processes by which they will be produced. Effective design requires the use of current management techniques, including concurrent engineering. This is an iterative process requiring interaction with customers and internal functions such as manufacturing. Conduct manufacturing operations. This function ensures the effective and efficient production of the products of the enterprise. It ensures that adequate resources are available to meet production requirements and plans, monitors, and controls the use of these resources. Support product. Activities are associated with after-sale support of the product. This activity has taken on added importance as the life-cycle support of the product becomes an increasingly important competitive tool.

The process view was described using a modified IDEF3 syntax (Mayer et al., 1992). IDEF3 was selected because it directly supports the documentation of a sequential set of enterprise units of behavior making up a process. In documenting the process view, 10 “generic” business processes performed by most enterprises were identified. These processes, and a brief description of each, follow: 1. Generate, accept, and fill order for product. Areas involved in this process might include activities related to marketing the product, order entry, production planning, manufacturing, and invoicing customers for products. 2. Generate, accept, and fill order for service. This process would involve order entry, whatever service function was required, and invoicing the customer for the service. Service functions might require some production planning and manufacturing involvement for the production of spare parts. 3. Develop a new product or service. New products require idea generation, market evaluation, major design development, and manufacturing capability evaluation. This process probably would involve strategic planning, marketing, design, and manufacturing. 4. Identify and fill need for depreciable nonhuman resources. Strategic planning sets acceptable levels for long-term, depreciable resources. The process to identify a need for such resources might include aggregate planning or some less formal mechanism. The actual purchase of depreciable resources usually involves considerable input regarding financial capability to fund such an asset, approval, purchasing, receiving, and payment for the resource. 5. Identify and fill need for nondepreciable nonhuman resources. The identification of a need for a resource might take place via a production planning system or within


6.

7.

8.

9.

10.

149

manufacturing, according to acceptable capacity and resource levels that have been set by management. The rest of the process might include purchasing, receiving, and distribution of the resource, as well as its payment. Identify and fill need for human resources. Upper management sets the acceptable levels of human resources. Identification of a need for human resources might come from the management of any department. The process to fill this need might involve personnel in hiring and training functions, departmental approval, and reimbursement to the employee for services rendered. Appraise, improve, and maintain human resources. This process might include goal setting, data compilation, data review, and feedback to the employee. It also includes development of and transfer of information regarding salary, training, or other motivational programs. Appraise, improve, and maintain nonhuman resources. This process might include data collection at the operational level, data review and evaluation at tactical levels, and development and transfer of information regarding resource maintenance. Develop and translate strategic plans to tactical plans. This process covers the development of long-term plans and the translation of these plans to mid-term departmental goals, plans, and policies. Translate tactical plans to operational plans. This process covers the translation of mid-term plans and policies to short-term operational procedures.

In this paper, we propose that business processes naturally fall into three categories: those processes that transform external constraints into internal constraints, those processes that acquire and prepare resources, and those processes that use resources to produce enterprise results. Processes 9 and 10 are category 1 processes. Category 2 processes are represented by processes 4, 5, 6, 7, and 8. Processes 1, 2, and 3 are category 3 processes. This categorization assists in the identification of common properties of processes that fall into the three categories, facilitating analysis and design. A virtual enterprise architecture. The preceding generic architecture takes a system’s view of an enterprise, in which an enterprise is modeled as a system that takes in inputs and produces outputs under some set of environmental constraints. Figure 2 shows several sets of enterprise activities (boxes) logically organized into business processes (shaded ellipses). The business processes are organized into an enterprise represented by the larger box. At this high level of abstraction, the enterprise itself is represented as a system that takes inputs and transforms them into outputs using available resources under the bounds of certain constraints. The figure also exhibits the interaction of the three process categories. A category 1 process (BP8, in the diagram) takes constraints from the environment and through some process converts them into a set of constraints that will be used to constrain other processes. A category 2 process (BP7) likewise takes in resources from outside of the system and prepares them for use by a category 3 process (BP5). A conceptualized generic, high-level virtual enterprise architecture is graphically represented in figure 3. The VE consists of a set of business processes from category (1) that are collectively owned by the VE and a set of business processes from all three categories (1, 2, and 3) that are owned by two or more individual agile enterprises and used by both

150


Figure 2.

Enterprise as a collection of business processes.

the individual enterprise and the VE. The VE temporarily disturbs but does not consume the individual enterprise. It owns no category (2) and (3) processes and no resources that support category (2) and (3) processes. However, it does own category (1) processes as well as enterprise inputs and outputs and is constrained by an environment that may be different from the environments of the individual enterprises.

2.2.

Developmental requirements for virtual enterprise architectures

For a virtual enterprise, the specification of required characteristics of agility need to be finalized. Based on these characteristics, a set of essential business processes should be identified and described. These essential processes are those all enterprises must perform well to become agile or maintain agility. Development and integration of templates for a VE need to be completed for its quick and reliable formation. These templates identify the processes agile enterprises perform and describe how they should be performed. The development of templates could be either general or specific to the VE’s characteristics. The techniques and tools that follow provide the necessary ingredients to develop a template. In addition to identifying the processes, the architecture and templates must specify how the business processes are to be accomplished. To complete this, identification of the following will be necessary:


Figure 3.

151

A virtual enterprise schema.

• • • • • •

The enterprise activities contained in the process. The logical and temporal arrangement of the activities. The inputs transformed by each activity in the process. The intended output of each activity. The set of constraints that limit each activity. The set of activation rules that define which output is triggered by which combination of inputs and constraints. • A set of behavioral rules that define how inputs are transformed into outputs. • The resources used to perform each activity. 3.

Engineering virtual enterprises

In the design and development of VEs, we need to consider the current and future direction of some dimensions of organizational development theory and practice. Requirements for some of the architectural tools in this environment have been presented. Their use within more common approaches for engineering (designing) a VE in the context of business process

152


reengineering and enterprise engineering now are described. Initially, a brief discussion of each of these organization development practices is presented.

3.1.

Business process reengineering

Business process reengineering has become a field of its own, in both the practitioner and academic literature. In general, BPR is the redesign of the business processes of an enterprise. However, the paradigms attributed to BPR are broad. Some believe true BPR is concerned with radical, all-or-nothing approaches that cannot be accomplished in small steps. Hammer and Champy (1993), for example, characterize BPR as “a set of procedures for effecting radical change.” The changes result from the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed. Others, including Harrington (1993) and Davenport and Short (1990), advocate less drastic approaches. In fact, even established practices such as continuous process improvement sometimes are claimed under the umbrella of BPR, either on its own or in combination with more drastic approaches. Other BPR advocates feel that true organizational improvement can be accomplished only through redesign leveraging on new technology. The design of the new process is based on consideration of available automation and information technologies with the new process designed to exploit the capabilities provided by these technologies. The increasingly popular work-flow management approach uses this technology-enabled process-improvement paradigm. It looks at the identification of software tools for automating and improving business processes. Examples of software employed under work-flow management include document management, imaging, messaging, and database systems. A major concern with work-flow systems is the interoperability and connectivity of systems between work-flow products, especially as relates to the integration of systems of different enterprises. Organizations such as the Workflow Management Coalition (WfMC, 1999) are trying to address these issues.

3.2.

Enterprise engineering

“Enterprise Engineering (EE) is defined as that body of knowledge, principles, and practices having to do with the analysis, design, implementation and operation of an enterprise” (Liles, Johnson, and Meade, 1996). EE, although still a process-focused approach, attempts to take a more holistic approach than more narrowly focused BPR approaches. The enterprise engineering paradigm views the enterprise as a complex system of processes that can be engineered to accomplish specific organizational objectives. According to the Society for Enterprise Engineering, a fundamental question is how to design and improve all elements associated with the total enterprise through the use of engineering and analysis methods and tools to more effectively achieve its goals and objectives. Advocates of EE do not see it as necessarily technology focused. It is an encompassing approach beginning with an explicit consideration of the goals and objectives of the enterprise and how every process in the enterprise should be designed to accomplish the goals and objectives.


3.3.

153

Limitations of current methods

BPR, EE, and other change management approaches, such as total quality management and continuous improvement, rely heavily on process modeling. Giaglis, Paul, and Doukidis (1996) state that, for models to support these approaches, they must be capable of describing the current way of doing things, identify opportunities for improvement, and design and implement new ways of carrying out the business processes. Traditional modeling methods, however, do not adequately support the needs of engineering a VE. In an interorganizational setting such as with a VE, process modeling becomes even more difficult (see Curtis, Kellner, and Over, 1992, and Giaglis et al., 1996, for discussions of the requirements and limitations of business process modeling methods). Among the needs specifically addressed in this paper is the ability to 1. 2. 3. 4.

Represent multiple views of the enterprise. Support and integrate multiple means of analysis. Support a top-down design of virtual enterprises. Allow for the contribution and protection of core competencies.

Multiple views of enterprises. Traditional process modeling methodologies typically emphasize one aspect of enterprise operation over another. For example, the views presented in section 2 focus on process elements. To get a more complete description of an enterprise (virtual or otherwise), we examine a number of additional views, including information, organization, business rule, and resource viewpoints. In addition, mapping the views to each other helps complete this more comprehensive architecture. By mapping one view on another, the interfaces of processes can be evaluated. This evaluation can help determine the information, resource, and organizational needs of a particular process. Many issues can be addressed with these extradimensional characterizations. For example, what is the information and organizational impact of a process improvement? Or which processes and organizations use a particular data item? These questions could be answered more readily if fully mapped views are available. Separation of the perspectives or views of a business process into a number of exclusive models is an unnatural representation method (Barnett, Presley, and Liles, 1995). The distinct pieces of a business process exist and have meaning as a single systemic unit. Curtis et al. (1992) also identify the issue of model verification and validity. Multiple perspectives of an enterprise are required, due to the various questions and viewpoints of the final consumers of a design effort. The works discussing the need for multiple perspectives include the computer-integrated manufacturing open-systems architecture (CIMOSA) work described by Vernadat (1996), which promotes four views: function, information, resource, and organization. Curtis et al. (1992) define the four views as functional (process elements being performed), behavior (when process elements are performed, i.e., sequence), organizational or resource (where and by whom processes are performed), and informational (information entities produced or manipulated by the process). In the forthcoming section, we present an extension to these views, integrating and expanding to a five-view model. The five views consist of activity, business process,

154


organization, business rule, and resources. The activity view specifies the functions performed by the enterprise. The business process view outlines the time-sequenced steps making up the processes the enterprise uses to achieve its objectives. The organization view details how the enterprise organizes and manages itself. The business rule view defines the entities managed by the enterprise and the rules governing their relationships. The resource view models the resources managed by the enterprise. This five-view approach is used as the basis for the modeling scheme described in this paper. Most current modeling methods focus on one or a few aspects at a time. Even in a suite of methods such as the IDEF methods (Mayer, Benjamin, Caraway, and Painter, 1995), integration across methods is not clear and ad hoc. Multiple means of analysis. Related to the need to represent multiple views of an enterprise is the need to support multiple means of analysis. Analysis and decision making in the design of a process or enterprise rarely is completed along a single dimension. However, most modeling methods can support only a very few analysis methods. For example, process modeling techniques such as IDEF3 allow for comparison of alternate process designs on cost and time through links to discrete event simulation and activity-based costing. Analysis of other dimensions, such as quality, strategic alignment, and complexity, are more problematic and may require the creation of distinct models for these purposes. This is especially problematic in designing a VE. In this case, the analysis includes a resource selection problem coupled with the process design problem. Current modeling and analysis methods give little, if any, support to the strategic and organizational issues related to virtual enterprise configuration. Top-down support of virtual enterprise design. The design of the VE must begin with the development of the strategic objectives and criteria for success and be able to integrate the needs and preferences of its constituencies. The design of the virtual enterprise must occur within this management framework. Most current modeling methods take a bottomup approach to process modeling and design and are in conflict with the need for top-down analysis. Additionally, the VE is an organizational design fundamentally different from existing organizational forms. Design of a VE, therefore, requires setting aside existing concepts of how an enterprise should be developed. BPR, in general, and the tools and methods with which it is associated are aimed at the reengineering of processes of existing enterprises. While its advocates purport that radical redesign means disregarding all existing structures and procedures and inventing completely new ways of accomplishing the root purposes of the processes in question, practically, this rarely is the case. A process change usually exists within some existing process, management, and technology framework. The design of virtual enterprises does not always have the advantage of an existing framework. In other cases, the VE might have to deal with multiple competing frameworks, if each organization brings its own ways of conducting business into the design process. Core competencies. Another problem associated with the virtual enterprise is the need to both integrate and protect the core competencies of the partner enterprises. Each partner contributes its core competencies (those things it does especially well) to the VE. This contribution is manifested in processes that accomplish an activity or meet an objective.


155

However, because of the fleeting nature of the VE, the enterprise may not wish to reveal exactly how it accomplishes this process to its partners, since they may become competitors in the next VE. Modeling tools must account for the rapid joining of these competencies through definition of the interfaces with other processes but still allow for the inner workings of the process to remain “hidden.” 4.

Recent advances in tools for virtual enterprise engineering

In this section, we discuss several advanced approaches in process and enterprise modeling, while addressing the previous concerns related to engineering the virtual enterprise. These approaches include a number of tools and techniques. The use of object-oriented business process modeling, holons and agents, and ontological approaches form the foundation of the proposed enterprise engineering tools described next. 4.1.

Object-oriented business process modeling

The object-oriented modeling paradigm and pattern-based development provide a powerful solution to the process modeling needs of organizations in a dynamic competitive environment, such as the virtual enterprise. The characteristics and advantages of the object-oriented approach in software systems development are well documented and will not be discussed in detail here. However, the fundamental characteristics of the object-oriented approach (such as abstraction, encapsulation, message-based communication, inheritance, and polymorphism) provide a proven basis for developing rapidly reconfigurable process models of complex systems (Jacobson, Ericsson, and Jacobson, 1995; Taylor, 1995). Under the object-oriented approach to process modeling, phenomena (a process or activity) are perceived as whole entities, just as they are in real life. At a high level of abstraction, similar real-world phenomena are classified or grouped based on their shared characteristics and behaviors. These abstract groupings form classes. All aspects of a given phenomenon are encapsulated within the representation of a class. This class representation then forms a central repository for all of the information pertaining to a physical phenomenon, such as the information, activity, organizational, and resource views. Further, the class definition specifies the communication mechanisms and responsibilities associated with the real-world phenomenon it represents. Object-oriented views of the enterprise are created by developing these class definitions for both the activities and the products that make up the VE. Objects represent the physical occurrence or implementation of the type of phenomena defined by a class. The business environment is represented as the relationships and interactions among these objects. The sum of these class definitions and relationships forms a component specification of the underlying enterprise. This arrangement provides a more natural representation of the organizational environment and improved coordination between the various contextual views of the enterprise. This representational method also formalizes the communications relationship between process elements. Objects created from the class definitions are perceived as “black boxes,” which maintain their own information, business rules, and procedures for managing their assigned responsibilities. This level of independence provides a set of stable components

156


that can be reconfigured in a plug-and-play fashion to suit current business needs (Raja and Barnett, 2001). 4.2.

Agent representation of enterprise entities

Agent modeling extends the object-oriented (OO) approach by introducing a specialization of the concept of object to represent real-life entities. The agent modeling approach maintains the functionality and advantages of the OO properties of classification, encapsulation, message-based communication, and inheritance discussed earlier. The use of agents to describe enterprise entities allows the consideration of properties shared by these entities and those that separate them from the other objects of interest in an enterprise. Most important among these properties is the ability of an agent to explicitly consider its goals, potential actions, the goals and actions of other agents, and the current and possible states of its environment to plan and execute tasks to best meet its goals given limited resources. Parunak (1996) reviews the use of agents for manufacturing. The coordination of agents is a major area of research in agent literature. Hayes-Roth (1994) looks at issues related to optimizing the action of agents to optimize overall system performance given multiple agents, multiple goals, limited resources, and highly dynamic environments. Lin and Sodberg (1992) describe agents utilizing a marketlike bidding system for real-time shop floor control. This is especially important in the virtual enterprise, in which the rapid integration and interaction among entities is vital for both the creation and ongoing operation of the enterprise. Swaminathan, Smith, and Sadeh (1996) and Fox, Chinoglo, and Barbuceanu (1993) are among those researching the use of agents in more conventional supply chains. While virtual enterprises introduce additional requirements to the coordination issue, the concepts, tools, and techniques being developed by these and other researchers are adaptable to the virtual enterprise. Rajan (1996) begins to address the use of agents for virtual enterprises. An extension to the agent concept that is especially attractive in the design of virtual enterprises is the holon. The term holon first was proposed by Arthur Koestler (1989 [1967]) as the basic unit for modeling biological and social systems. The term, according to Koestler, is intended to describe any entity that is at the same time “a whole unto itself, and a part of other whole(s).” Several aspects of holons make them attractive for representing virtual enterprise entities. Holons belong to structures called holarchies, which consist of selfcontained units capable of functioning independently but nevertheless dependent on other units. The holarchy is a temporary assembly of holons that has a specific set of temporal goals and objectives. The strength of a holarchy lies in its ability to construct highly complex, resource-efficient systems that are highly resilient to internal and external disturbances and adaptable to changes in the environment. An enterprise can be considered a holon consisting of other sets of holons, representing the various functions or organizations of the enterprise. Both hierarchical and heterarchical control structures can be in place within a holarchy. Higher-level holons set goals for lowerlevel holons and coordinate overall control; the lower-level holons are granted autonomy in their actions and controls. In the case of a virtual enterprise comprising several participating companies, the virtual enterprise is the highest-level holon, with each partner enterprise


157

making up the first level of holons. Each enterprise then would have the autonomy to organize and manage itself as it sees fit. Holon concepts have been applied successfully to manufacturing floor control situations (Winkler and Mey, 1994); enterprise-level holon analysis seems to be a natural extension. 4.3.

Ontology approaches

According to Benjamin, Menzel, Mayer, and Padmanaban (1995), “an ontology is a description of the kinds of things, both physical and conceptual, that make up a given domain, their associated properties, and the relationships that hold among them as represented by the terminology in that domain.” An ontology creates a formal representation of a domain. This common representation then can be used as a means of communications among different parties. A common criticism of enterprise models is that they often are single-use, proprietary models that cannot be shared or reused. Developing a common, shareable representation and definition of the enterprise facilitates the design of the enterprise. This characteristic is important in joining different organizations in the development of a VE. The availability of a VE ontology assists in arriving at a common understanding of the VE and integrating the processes of partnering enterprises. Additionally, the ontology knowledge can be represented in formal languages, which then can be used in knowledge-based systems for automated analysis and reasoning (Gruninger and Fox, 1995; Uschold, King, Moralee, and Zorgios, 1995). Several researchers currently are developing ontologies for enterprise modeling. The Enterprise Integration Laboratory (Fox, Gruninger, and Zhan, 1994) is developing a set of ontologies to answer questions and develop queries pertaining to information in the models in areas such as activities and states, products, organization, and activity-based management. The Enterprise Project at the Artificial Intelligence Applications Institute (AIAI) developed the Enterprise Ontology, a collection of terms and definitions relevant to enterprises with a goal of supporting a larger effort to automate the analysis and design of business enterprises (Uschold et al., 1995). 5.

An enterprise modeling methodology

This section presents a conceptual modeling methodology to address the needs of process modeling for a VE. It includes a modeling scheme that specifies five views of the enterprise, briefly described earlier. The scheme incorporates the IDEF suite of modeling methods (Mayer et al., 1992). Each IDEF method provides a set of modeling syntax elements and steps for describing a particular perspective of an enterprise. The proposed modeling scheme uses the IDEF0 (functional modeling), IDEF3 (process description capture), and IDEF5 (ontology capture) methods. While IDEF methods are used for this scheme, the underlying principles on which the scheme is built allows flexibility to be implemented in other modeling methods. IDEF was chosen because of its wide use, formalized methods, and the integration (although still limited) among the methods. The modeling scheme builds on and takes advantage of the object-oriented, agent, and holon representations described in the previous sections. To promote and capture the shared

158


understanding required when bringing disparate enterprises together, an ontology is proposed through the business rule view. While the methodology to use the modeling scheme is not described in detail in this paper, the development is accomplished by defining each of the views in succession, starting with the business rule view. Feedback and refinement of previously defined views ensure consistency among the views.

5.1.

Business rule view

A business rule model identifies the objects of interest in a particular domain and their relationships. It is equivalent to an ontology. The modeling scheme uses the IDEF5 ontology capture method (Mayer et al., 1992) to represent the business rule view. IDEF5 facilitates the collection of knowledge about physical and conceptual objects along with their associations. It provides facilities for diagrammatic representations of an ontology. In addition, a structured text language is used for detailed ontology characterization. Figure 4 provides an example characterization of the business rule model for an enterprise. The circles represent classes and arrows represent relations. As can be seen, tangible things (Production Plan), concepts (Status), and activities (Support Production) are defined as entities. This model forms the basis for the other four views. Entities and relationships for all views are specified within the business rule view. Each of the other views is built by extracting the entities and relationships particular to that view. This helps ensure integration of the views and eliminates redundancy in building the views. For example, a resource entity is defined once. Properties and relationships relating to the resource are progressively specified as the other views are developed. Even as these new properties and relationships

Figure 4. A partial ontology model: business rule view of the organization.


159

are specified, there is only one instance and specification of the resource. This is in contrast to traditional techniques, where the resource is specified in the activity view, respecified within an information view, and so forth. A “meta-model” of the modeling elements supports the creation of the enterprise model. To date, this meta-model identifies approximately 40 entities and 50 relations. Base sets of properties (attributes) are specified for each of the entities and relationships. A model for an enterprise can be created by instantiating instances of each of these properties and specifying entities that might be particular to an industry or enterprise. 5.2.

Activity view

The scheme uses the IDEF0 functional modeling approach to represent the activity view. IDEF0 is used to represent the functional (i.e., activity or process-oriented) framework of a system. The characteristic of the IDEF0 modeling technique in which each activity and arrow can be decomposed into more detailed levels of analyses is especially useful in VE modeling. Details about lower-level activities can be captured yet hidden from models of the enterprise at higher, more abstract levels, thus supporting the need to protect core competencies. The decompositional nature also directly supports the holon-based approach of this scheme, where each holon can be decomposed into component holons and modeling and analysis of holons can be conducted independently without showing child or parent holons. 5.3.

Resource view

The resource view specifies two basic aspects: the resources necessary to accomplish activities and how those resources are organized and “owned” by the organization. To form the resource view, actors and the processes they perform are coupled, in essence, creating the holons described earlier. This coupling of actor and process allows for attributes and performance characteristics of interest to be represented in a more holistic manner. We propose that only when a particular process is assigned to a particular resource can the values of these performance characteristics be identified. The assignment is done through user-defined selection rules, with the aid of available analysis tools. Once the agents performing the activities are identified, the performance of the enterprise can be specified. Two classes are especially important here: activity and actor. Also important is the relationship of the two as expressed by attributes named activity-performance and actor-performance. The performance capability required by an activity is matched to the performance capabilities available in potential actors. These are evaluated on a set of measures as determined by a decision maker to select the best alternative. 5.4.

Business process view

The business process view specifies the time-ordered sequence in which the tasks making up a process are executed. The primary difference between it and the activity view is that the business process view explicitly specifies this sequence but the activity view does not.

160


Figure 5.

An IDEF3 diagram of a “ship product” process.

The business process view typically is at a lower level of abstraction and describes what happens in a particular instance or execution of the process, such as the manufacturing of a particular part. The activity view describes actions that may be occurring continually in the enterprise, such as the manufacturing function. For any actor, several process scenarios can be created. Examples include alternate ways of performing a process based on existing constraints and the tracing of alternate inputs through the actor. The process model is specified by examining the business rule model. This process view is specified using the IDEF3 process description capture method (Mayer et al., 1992). The linkage of IDEF3 to simulation allows evaluation of cycle time and cost performance. Additionally, the linkage of IDEF3 to the IDEF5 ontology capture method makes it an attractive alternative for representing the business process view. An example IDEF3 model representation of the “Ship Product” business process with timing and process completion time is shown in figure 5. 5.5.

Organization view

The organization view specifies the reporting and constraint structures put in place to guide the performance of entities and activities. Many of the entities specified in the other views also participate in the organization view. However, several entities are specified specifically to support the organization view. These entities are provided within the scheme to assist in developing the view. Included in these entities are planning objects such as goals, plans, policies, and measures. The roles and positions agents in the enterprise play are identified. These then are linked to activities, planning objects, and each other through a set of management and organization links. The modeler, by identifying the specific instances of each class, completes the model. The result of this activity is an organization view specified in IDEF5.


6.

161

Conclusion and future directions

This paper introduces a virtual enterprise architecture. It discusses the needs of modeling and designing the processes of a virtual enterprise and the shortcomings of current modeling techniques, especially in relation to modeling the virtual enterprise. We describe how approaches such as object-oriented modeling, autonomous agents, and ontologies show promise in helping engineer and improve processes within the virtual enterprise. We then described some research that is attempting to bring together these techniques into an integrated modeling technique. The research pertains to modeling the enterprise from five view-points and mapping these viewpoints. To date, the methodological tools and techniques for virtual enterprise engineering have been defined at a conceptual level and applied to limited processes. There are a few reasons for this. First, a true virtual enterprise situation has yet to exist. A number of dynamic network organizations have formed, to some degree, but virtual enterprises as idealistically envisioned by the literature have yet to form. Research has tried to help in the development and understanding of virtual enterprises. The set of tools described here fall within that scope. Yet, the tools described here can be applied effectively to dynamic organizational settings. As customer’s needs become more diverse and innovation “velocity” increases, this agility becomes more prevalent. These initial conceptual developments, like all theoretical work, can be advanced with actual implementation. Some implementations for these tools have been attempted for a major subcontracting partnership for a defense development program. But the robustness of the research and development efforts related to the tools was limited by the real-world concerns of profit-making entities and the deadlines for projects. The work presented here is at an upper level of analysis, with substantial opportunity for development at lower levels. Further work involves extending the modeling scheme by specifying more fully the elements of the ontology. This may require a technique other than IDEF5, as the development of IDEF5 has not progressed to the point where it is fully usable in the scheme. In addition, the work of other researchers such as the AIAI (Uschold et al., 1995) and EIL (Fox et al., 1994) in developing ontologies should be explored for applicability in this scheme. In conclusion, clearly current BPR tools cannot fully meet the needs of the virtual enterprise and agile environments. The methodology and tools reviewed in this paper provide advantageous characteristics that more traditional BPR tools lack. The tools need to be evaluated empirically in either a laboratory or real-world study. Diffusion of such innovative tools also requires adequate support mechanisms, specifically software. References Automation and Robotics Research Institute, Operate a Small Manufacturing Enterprise, Automation & Robotics Research Institute, Fort Worth, TX (1990). Barnett, W., Presley, A., and Liles, D., “Object-Oriented Process Modeling for the Virtual Enterprise,” Proceedings of the Fourth Agility Forum Conference, Atlanta, GA (1995). Benjamin, P., Menzel, C., Mayer, R., and Padmanaban, N., “Toward a Method for Acquiring CIM Ontologies,” International Journal of Computer Integrated Manufacturing, Vol. 8, No. 3, pp. 225–234 (1995).

162


Curtis, B., Kellner, M., and Over, J., “Process Modeling,” Communications of the ACM, Vol. 35, No. 9, pp. 75–90 (1992). Davenport, T. and Short, J., “The New Industrial Engineering: Information Technology and Business Process Redesign,” Sloan Management Review, Vol. 32, No. 5, pp. 554–571 (1990). Fox, M., Chionglo, J., and Barbuceanu, M., The Integrated Supply Chain Management System, Enterprise Integration Lab, Toronto, CA (1993). Fox, M., Gruninger, M., and Zhan, Y., “Enterprise Engineering: An Information Systems Perspective,” Proceedings of the Third Industrial Engineering Research Conference, Atlanta, GA (1994). Giaglis, G., Paul, R., and Doukidis, G., “Simulation for Intra- and Inter-Organisational Business Process Modelling,” in: Proceedings of the 1996 Winter Simulation Conference, San Diego, CA, pp. 1297–1304 (1996). Gruninger, M. and Fox, M., “Methodology for the Design and Evaluation of Ontologies,” Workshop on Basic Ontological Issues in Knowledge Sharing—IJCAI-95, Montreal, Quebec (1995). Hammer, M. and Champy, J., Re-engineering the Corporation: A Manifesto for Business Revolution, Harper Business, New York (1993). Harrington, H., “Process Breakthrough: Business Process Improvement,” Journal of Cost Management, pp. 30–43 (Fall 1993). Hayes-Roth, B., “Opportunistic Control of Action in Intelligent Agents,” IEEE Transactions on Systems, Man, and Cybernetics, Vol. SMC-23, No. 6, pp. 1575–1587 (1994). Jacobson, I., Ericsson, M., and Jacobson, A., The Object Advantage: Business Process Reengineering with Object Technology, Addison-Wesley, Reading, MA (1995). Koestler, A., The Ghost in the Machine, Arkana Books, London (1989 [1967]). Liles, D., Johnson, M., and Meade, L., “The Enterprise Engineering Discipline,” Proceedings of the Fifth Industrial Engineering Research Conference, Minneapolis, MN (1996). Lin, G. and Solberg, J., “Integrated Shop Floor Control Using Automomous Agents,” IIE Transactions, Vol. 24, No. 3, pp. 57–71 (1992). Mayer, R., Benjamin, P., Caraway, B., and Painter, M., “A Framework and Suite of Methods for Business Process Reengineering,” in: Business Process Change: Reengineering Concepts, Methods, and Technologies, V. Grover and W. Kettinger (Eds.), Idea Group Publishing, Harrisburg, PA, pp. 291–329 (1995). Mayer, R., Painter, M., and deWitte, P., IDEF Family of Methods for Concurrent Engineering and Business Re-engineering Applications, Knowledge Based Systems, Inc, College Station, TX (1992). National Center for Manufacturing Sciences, Strawman Enterprise Reference Model, National Center for Manufacturing Sciences, Ann Arbor, MI (1992). Parunak, V., Workshop Report: Implementing Manufacturing Agents, National Center for Manufacturing Sciences, Ann Arbor, MI (1996). Raja, M. and Barnett, W., “An Object-Oriented Approach to Enterprise Engineering,” Journal of Engineering Valuation and Cost Analysis, forthcoming (2001). Rajan, V., “An Agent-Based Fractal Model of Agile Manufacturing Enterprises: Modeling and Decision-Making Issues,” Proceedings of the Artificial Intelligence and Manufacturing Workshop, Albuquerque, NM (1996). Swaminathan, J., Smith, S., and Sadeh, N., “A Multi-Agent Framework for Modeling Supply Chain Dynamics,” Proceedings of the Artificial Intelligence and Manufacturing Workshop, Albuquerque, NM (1996). Taylor, D., Business Engineering with Object Technology, John Wiley & Sons, New York (1995). Uschold, M., King, M., Moralee, S., and Zorgios, Y., The Enterprise Ontology, Artificial Intelligence Applications Institute, Edinburgh, Scotland (1995). Vernadat, F., Enterprise Modeling and Integration, Chapman & Hall, London (1996). Winkler, M. and Mey, M., “Holonic Manufacturing Systems,” European Production Engineering, Vol. 18, Nos. 3–4, pp. 10–12 (1994). Workflow Management Coalition (WfMC), on-line, http://www.aiim.org/wfmc/ (1999).