Combining Workflow and PDM: Enhancing the Workflow Module of axalant™ based on the WfMC and STEP Standards

Kamel ROUIBAH1i, Samia Rouibah1 & Wil van der AALST2 1Department of Quantitative methods & Information systems, Kuwait University, P.O. Box 5486 Safat, Code No 13055, Kuwait 2Department of Technology Management, Eindhoven University of Technology, P.O. Box 513, NL-5600 MB Eindhoven, The Netherlands Keywords

Product data management, workflow management system, process modeling, axalant™, ProView, WfMC, STEP

Abstract

Product Data Management (PDM) supports management of both data and the product development process during the total life cycle of the product. However, current technology has several pitfalls such as lack compliance of workflow modules to standards as well as lack interoperability between PDM systems. This paper illustrates the extension of the current workflow management system (WfMS) part of the PDM system axalant™ to support engineering processes management. The paper describes the interface improvements done specifically to comply the WfMS of axalant™ with the WfMC and STEP standards, and to exchange workflow data with existing WfMS on the market. In this paper the STEP and WfMC standards are analyzed, the required PDM workflow architecture is specified, and the resulting implementation is described. The necessary enhancements include the extension of the data model of axalant™, the modification of the corresponding software, the modification of the user interface, and the link to the interface between ProView and axalant™. ProView helps to generate graphical process definitions. Major achievements consist of the enhancement of process design through the creation of building block (split- and join-operations) as well as the enhancement of organizational structure through the usage of roles as a resource for process activities. Moreover, the paper adds flexibility for axalantTM to handle changes. As consequence, axalant™ is able to generate workflow templates and ad-hoc processes and to communicate with external WfMS. Paper describes this efforts and point out to perspectives.

1. INTRODUCTION Companies around the world are increasingly implementing Product Data Management (PDM) to improve their competitiveness. The PDM market is increasing and has experienced a growth of 62% and reached $2.86 billion in 2000, and the forecast will exceed $13 billions in 2005 (www.CIMdata.com). According to the definition of CIMdata PDM systems support management of both engineering data and the product development process during the total life cycle of the product. They allow seamless interoperability between different departments and throughout the supply chain during product design. Participation/collaboration is especially eased by the use of latest web-based technologies (Chu and Fan 1999, Liu and Xu 2001). PDM systems are particularly important for companies in the engineering area, concerned with responding quickly, integrating large volume of

2

2

engineering data, and being flexible (Harris 1996). The term engineering data includes geometry, engineering drawings, project plans, part files, assembly diagrams, product specifications, numerical control machine-tool programs, analysis results, correspondence, bills of material, engineering change orders, etc. PDM systems have several benefits (Philpotts 1996, CIMdata 1998, EDM 1999 and 2000, Anonymous 2001, Smith 2004): they allow interdisciplinary collaboration, contribute to reduce product development cycle time, enable to reduce complexity of accessing the information of a company, improve project management, and supply chain collaboration.

1.1. Focus of this paper

A PDM system has several functions. Workflow and interoperability functions are the central focus in this paper. Indeed, a survey performed in the United Kingdom in more than 100 middle-sized and large leading companies in manufacturing and engineering (EDM 2000) has shown that important reasons for implementing PDM systems were access to engineering data (85%) and workflow & configuration management (70%). Workflow component has similar functions as stand alone workflow management system (WfMS). The Workflow Management Coalition (WfMC 1999) defines the term WfMS as system that helps an organization to "define, create and manage the execution of workflows through the use of software, running on one or more workflow engines (in our case it is part of the PDM system), which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications (other PDM components in our case)". The WfMS is used to implement company procedures. Communication and notification function is facilitated by an integrated mail system that facilitates both process-specific and independent exchanges of messages. Over the last decade, PDM literature has addressed several PDM issues including case studies about their benefits (Schmitz 1999, Anonymous 2001, Smith 2004), methods to design PDM web-based (Chu and Fan 1999), PDM implementation issues (Siddiqui et al. 2004, Smith 2004), description of specific PDM systems (Mansfield 2002), guidelines for PDM implementation (Siddiqui et al. 2004), security requirements for distributed PDM systems (Leong et al. 2003), identification of strategic PDM components requirements (Kumar and Midha 2004), literature review and summary of the emerging research questions (Harris 1996), and integration of PDM systems with other systems such as ERP systems (Gao et al., 2003). However, workflow enhancement within PDM systems and their interoperability has received little attention. The aim of the paper is neither to re-invent the wheel nor to innovate workflow design. Rather it aims to improve the WfMS module of the PDM system CADIM/EDB (later called axalant™) according to existing to standards. Enhancements are done in order to be at the cutting edge of other PDM systems who offer stronger WfMS built in such as the PDM Windchill. This paper describes the trend in the PDM systems, the open PDM-workflow architecture and the improvements done for axalant™. Such enhancements focus on workflow interoperability, workflow module design and its ease of use. Specifically, this paper brings two main contributions. First, we enable axalant™ to comply with the standards of the WFMC (Workflow Management Coalition) and STEP (STandard for the Exchange of Product model data) since few

3

3

papers described such compliance. Second, we add interoperability functions to WfMS of axalant™ in order to facilitate exchanging workflow data with workflow modules of other PDM systems as well as with Proview, a workflow modeling tool. Enhancement efforts were initiated within the European Communities (EC) project EP26780 SIMNET. Section 2 is an overview of current functions and limits of existing commercial PDM systems. Section 3 describes the analysis phase including user’s requirements for an enhanced workflow module. Section 4 focuses on the design phase that specifies the desired WfMS taking into account the analysis phase. Section 5 describes the adaptation of the axalant™ workflow architecture. Finally the last section ends the paper with the conclusions and future research directions.

2. EVOLUTION OF PDM SYSTEMS AND ASSESSMENT OF THEIR FUNCTIONS The world of PDM continues to evolve, and new acronyms, definitions and viewpoints abound. Over the past 20 years, PDM systems have developed in three stages. First they evolved from extensions of CAD systems into an independent system; the concept was established during 1980. Their objectives were to perform technical tasks within a workgroup (in engineering) such as CAD file management and change control. In a second phase, and during the 1990s, the concept was broadened to encompass the management of product data as well as product development process across the whole organization. The focus has been shifted to the improvement of the entire product life cycle from the initial concept to the finishing product within a single company. During the third phase, PDM systems have been extended to evolve into a new generation under different names such as Collaborative Product Definition Management (cPDM), Collaborative Product Development (CPD) or Product Lifecycle Management (PLM). The extension aims to address clear business objectives such as expanding operations globally, managing supply chain (with supplier and engineering partner integration), and establishing e-business.

2.1. Capabilities of PDM systems

According to CIMdataii (1998), five basic user functions are supported by PDM systems. At the basic level or low end, a PDM system (those of the second phase) provides the following:

• Data vault and document management: the former is responsible of security authorization for information access, and the later is responsible to organize documents and coordinates their development, revision, control and distribution over the documents’ life cycles.

• Product structure management handles bills of material, product configurations, and associated versions and design variations.

• Parts management provides information on standard components and facilitates re-use of designs.

4

4

• Program management provides work breakdown structures and allows coordination between processes, resource scheduling, and project tracking.

• Workflow and process management controls procedures for handling product data and processes, such as the engineering change management (ECM) process, common in the domain of product development; this enable to track changes and control revisions.

Furthermore, there are some other utility functions that enhance PDM systems (CIMdata 1998).

• Communication and notification capabilities, such as links to e-mail, provide for information transfer and events notification.

• Data transport function tracks data locations and moves data from one location or application to another.

• Data translation capability exchanges files in a proper format.

• Image services handle storage, access, and viewing of product information.

• Administration function controls and monitors system operation and security.

• Besides, the system provides simple interface to other systems. To support collaboration within the supply chain, PDM systems of the third phase (cPDM, CPD or PLM) offer high and more sophisticated functions (Kumar & Midha 2004).

• Interoperability functions enable to connect data hosted in distributed systems (e.g. other PDM, or ERP systems or CRM systems) of the supply chain and to ease data exchange (Kempfer 2000, Gao et al., 2003, Puschmann and Alt 2004). For example some functions such as workflow presents in PDM systems are also included in ERP systems.

• Inter-organizational communication & web integration functions: they offers to link distributed teams over the supply chain (Liu and Xu 2001, Kumar & Midha 2004).

• Management of distributed processes: they offer support for collaborative processes related to product development in the supply chain.

• Security functions: they ensure that all the data are secured and all users are under controlled and managed corporation (Leong et al., 2003).

2.2. Limits of current PDM technology

Despite their numerous benefits, the potential of PDM is not yet achieved by current systems. Beside the fact that no single PDM system available in the market provides all the previous PDM capabilities (Kumar and Midha 2004), there are several drawbacks of current PDM technology.

5

5

First, there is a lack of interoperability standards between PDM systems. Accordingly, PDM systems provide limited interoperability functions. A Dutch study (Wognum and Drongelen 2001) has shown that 50% of sampled companies do exchange data using PDM system with their customers and suppliers, and the exchange is limited. Another study was performed in cooperation with IBM and CIMdata (EDM 1999) and included 100 managers with more than 15 years of experience with PDM systems in 33 medium-sized to large companies. The study showed a weak level of system integration. Only 15% of the adopters have achieved the highest level of system use and integration. Since engineering data and workflow data are distributed among the collaborative network, system integration and workflow systems interoperability are two critical issues for cPDM. Several authors have raised similar issues. For example Yeh and You (2002) study was concerned with how to ensure system integration and how product data exchange is shared between heterogeneous systems. The authors proposed an integrated data model that is based upon STEP. Gao et al., (2003) study presented two other drawbacks of commercial PDM systems: inexistence of a generic standard for PDM system implementation and lack of design knowledge sharing. The authors proposed a model integration that is STEP based. Puschmann and Alt (2003) observed (outside the scope of PDM field) that efficient coordination and control of cross-organizational business process can be achieved only with integrated information systems that deliver timely exact and right information. They also stress that the integration should not only at data-level but also at process level. Since PDM systems have been developed according to different paradigms, PDM interoperability may be achieved through: (a) use of proprietary applications, which requires major, complex and costly customization (Gao et al., 2003, Currie et al., 2004), (b) use of STEP standards (Yeh and You 2002, Gao et al., 2003); (c) use of UML (Oh et al. 2001). Per opposite to PDM, WfMSs interoperability may be achieved through other standards such as WfMC standards. Outside the PDM field, other initiatives to overcome system interoperability emerged after the SIMNET project. These include the Web Serviceiii paradigm (Currie et al., 2004). This aims to integrate software applications across heterogeneous technology platforms and business environment. System integration is also an important issue in area of Enterprise Application Integration systemiv (EAI) (Puschmann and Alt 2003). According to these authors, organizations spend at least 40% of their IT budget for integration purposes. Second, several WfMS of PDM systems are very restrictive and inflexible as observed by Gao et al., (2003). In the engineering areas, processes are complex, dynamic, subject to several changes, which require flexibility and adaptability. WfMS modules within PDM systems show also limited functions for collaborations processes that span company borders (Rouibah and Caskey 2003b) as well as dynamic data sharing (Noel and Brissaud 2003) such as the engineering change management process (ECM). This process encompasses the emergence of a need for a change, the request for a change, the management approval of the change, implementation, and documentation where all impacted product data have been updated (Rouibah and Caskey 2003a). In addition; other PDM workflow modules are not enough user friendly (limited ease of use and accessibility) as observed by Liu and Xu (2001). This limits the reusability of the system in real world situations. Flexibility could be achieved by complying

6

6

WfMS with standards such as WfMC (see WfMC.org). Moreover, we did a search through the ProQuest data base about related researches that focused both on workflow and PDM over the last 15 years. We observed lacking researches except the study done by Kim et al., (2001). The author developed a dynamic and flexible workflow model that is based on STEP standards. The main emphasis is placed on dynamic process adaptation which is a requirement by product development. Choi et al., (2002) discuss and present a workflow model that satisfies requirements of engineering / manufacturing processes. Anonymous (2001) reports that DaimlerChrysler has used FastCar, a web based system for collaborative workflow and change management. It is based on collaborative technology from i2 and a PDM (from IBM and Enovia). The company processes tens of thousand of engineering changes annually. FastCar enables DaimlerChrisler to reduce the engineering change from twelve weeks to few hours. However, the paper does not specify whether the systems allow DaimlerChrysler’s partners to be involved or not.

Third, Other limits of current PDM system technology have been mentioned by other researches such as limited security functions within distributed PDM systems (Leong et al., 2003) as well as inter-organizational and concurrent workflow (Rouibah and Caskey 2003a).

2.3. Research methodology

The research method used in this article is action research (Checkland and Holwell, 1998). This method consists of five steps:

• Research and practice together define research questions. • The researcher structures the research area and develops suggestions for the design of the

possible solution based on his theoretical practical knowledge. • Research and practice together check the suggestions and refine them. • In the next step, practice adopts and uses the solutions. • Finally, the results are reviewed in a joint process, in order to improve the solutions.

The open architecture for the enhanced workflow module of axalant™ in this article was developed on the basis of this research process. The research question was jointly defined by the department of Information Technology at the Faculty of Technology Management (Eindhoven, Netherlands) together with the EIGNER+PARTNER (EP). This has been done during their participation in the EC project EP26780 SIMNET, between 1999 and end of 2001. The architecture and the enhancements were derived from: (a) analysis of current functionalities of PDM system and their limits, including the axalant™ (see Section 2.1, 2.2 & 3.1), (b) also from existing theoretical knowledge on existing standards (WfMC and STEP) – see Section 3.2, as well as from practical experience from EP about integration of PDM and STEP. The proposed enhancements were reviewed in several workshops within the SIMNET consortium. The theoretical input from research, the practical input from EP and feedback from other members of the project finally lead to the improved workflow architecture which

7

7

is described in Sections 4. The proposed enhancements were validated and implemented (see Section 5) within axalant™ and commercialized since 2002.

The next section describes the analysis phase including user’s requirements for an enhanced workflow module.

3. ANALYSIS & REQUIREMENTS COLLECTION Many perspectives characterize a WfMS design (Jablonski and Bussler 1996). The desired WfMS should support five perspectives: process, organization, information, operation, and integration. In the process perspective, workflow-process definitions are defined to specify which tasks need to be executed and in what order. Many languages have been proposed for designing workflow process definitions. Typical languages are graphical and use the building blocks such as OR-split, OR-join, AND-split, and AND-join to model sequential, parallel, conditional, and iterative routing. These have been included as a prerequisite in the reference model of WfMC. In the organization (or resources) perspective, the organizational structure, the resources are specified as well as the notification service that informs workflow participants about pending activities. The organizational structure describes relations between roles (resource classes based on functional aspects, e.g. mechanical staff) and groups (resource classes based on organizational aspects, e.g. sales department). Resources (people and/or machine) are allocated to roles and groups. The information perspective deals with control and production data. Control data are introduced for WfMS and/or for the workflow engine purposes. Production data are information objects (such as documents) whose existence does not depend on workflow management. The operation perspective describes the elementary operations performed by resources and applications. Typically, these operations are used in the process perspective to create, read, or modify control and production data. The integration perspective is the link between the above four perspectives. Recent research in workflow domains addresses characteristics typically neglected by contemporary WfMS. Among the desired functions, flexibility (e.g. see Aalst and Basten 2002) is of the utmost importance. A flexible workflow is a WfMS that can be easily adapted to change. It allows user to perform ad-hoc activities; to alter flows as appropriate; and to do unplanned exception handling. According to Aalst and Basten (2002), changes might range from ad-hoc modifications of a process for a single customer (i.e. the process definition remain the same) to a complete restructuring for the workflow process to improve efficiency (evolutionary changes). For example a complete restructuring may be a consequence of BPR efforts or a law which has been changed. However, this paper is not concerned with complete restructuring but focuses on the first category of change. With regards to the above functions, next section describes the weakness of axalant™, and argues why improvements are needed.

8

8

3.1. The current workflow module of axalant™ and its limitations

Axalant™ is a PDM system that is the proprietary of EIGNER+PARTNER (EP). Besides lack of interoperability with existing workflow technology, analysis of the axalant™’s workflow module shows two major disadvantages: Axalant™ exhibits limitations with respect to workflow design and does not comply with WfMC. With regard to process perspective, it exhibits several drawbacks. First, the user interface of the workflow module is part of the PDM system and can not be separated. The PDM systems does feature a workflow engine that executes workflows but, its capabilities are limited. Second, the WfMS does not have a facility to generate graphical workflow process definitions. Besides, it is able only to process workflows with linear sequences of activities. It features only one type of activity, the standard "Activity". In nowadays and modern complex business, most processes are not linear. Compliance with WfMC requires adding the logic of control flow such as in a situation involving synchronization or choice (OR / AND split). See Aalst et al. (2003) for a detailed discussion of the design patterns workflow system should support. Third, workflow definitions are stored as a sequence of activities with associated organizational units. The role concept specified by WfMC is missing. Organizational units can be expressed either by “users”, “groups of users” or “distribution list”, which exhibit disadvantages. Without an organization role model, for each activity it would be necessary to enumerate all privileged users individually. If a new user is added to the workflow application, it is necessary to analyze every single workflow activity, if the new user shall be privileged to execute this activity. The administration effort is enormous. Fourth, linked to previous, only two types of work items are available: the “user specific work items” and the “group specific work items” are successively executed either by individuals or by members of specific groups. Accordingly, role specific work items are missing. With regard to resource perspective), the WfMS of axalant™ exhibits only an internal notification service and does not support intra collaboration, since external notification (or e-mail) used by external users is not currently possible.

Axalant™ exhibits limitations with respect to flexibility. The term flexible workflow has been used in the literature mainly to denote workflow systems that allow for a change in the process during its execution (Aalst and Basten 2002). This can either happen by changing the process plan for a particular instance (for example, to deal with one exceptional event) or by changing the global process plan for all instances (this is the case of re-engineering of process). With regard to workflow flexibility, the WfMS exhibits three limits. First, each process within axalant™ is designed from scratch, and it is impossible to specify a workflow process definition once and replicate it across the company. One solution consists to use workflow templates (Aalst and Basten 2002). It is a standard design of common workflow processes that lets designers reflect local differences and reuse common parts (Sheth et al. 1999). Second, linked to previous limit, the WfMS does not allow users to change processes once they are designed, and to deal with unexpected situations. Example may include incorrect review of a milestone, a deadline is over, or an exception due to incorrectly performed tasks or when a deadline

9

9

for a task expires or a responsible is off for a travel. Third, the WfMS does not allow users to generate workflow processes on ad-hoc basis, i.e. workflow processes whose structure cannot be predicted and involve situations of negotiations. In the engineering domain, workflows processes are not totally specified. In a recent case study Rouibah & Caskey (2004) found that engineers do neither think in documents nor in processes, but in term of specifications and their relationships. Since this paper deals with workflow interoperability, two categories of specifications are available (Sheth et al., 1999): (a) specifications for workflow modeling and workflow description (design time) and (b) specifications for runtime interoperability. Interface 1 of the WfMC falls into the first category whilst WFMC (interface 4), STEP, OMG’s jointFlow, and SWAP fall into the second category. Interface 4 (published in 1998) defines the mechanisms that workflow product vendors are required to implement for one workflow engine to make requests of another. While it was not stable during axalant's enhancements, the new standards OMG’s jointFlow and SWAP were emerging at that moment too. Accordingly we opted for Interface 1 (WfMC, 2002) for workflow description and STEP for runtime interoperability. It should be noted that since the implementation of axalant's enhancements new standards have emerged. In particular the web services paradigm triggered the development of new and relevant standards. The functionality of web service composition languages (also referred to as "web service orchestration") like BPEL4WS, BPML, WSCI, WSWSFL, XLANG, etc., is very similar to traditional workflow languages. The recently released BPEL4WS (Business Process Execution Language for Web Services), cf. Curbera et al. (2002), specification builds on IBM's WSFL (Web Services Flow Language) and Microsoft's XLANG. XLANG is a block-structured language with basic control flow structures such as sequence, switch (for conditional routing), while (for looping), all (for parallel routing), and pick (for race conditions based on timing or external triggers). In contrast to XLANG, WSFL is not limited to block structures and allows for directed graphs. The graphs can be nested but need to be acyclic. Iteration is only supported through exit conditions, i.e., an activity/subprocess is iterated until its exit condition is met. The control flow part of WSFL is almost identical to the workflow language used by IBM's MQ Series Workflow. See Wohed et al. (2003) for more information about the evaluation of BPEL4WS, XLANG, and WSFL using the workflow patterns (Aalst et al. 2003, Aalst 2003b). The next sections describe how the existing WfMS can be extended, in order to meet the standards defined by the WfMC and STEP.

3.2. Analysis of the STEP standard: allowing the ECM

We focus our attention on STEP for several reasons. The STEP community copes with objects that are handled in a PDM system. There are more emerging software products dealing with it. Some of them are commercial and quite expensive others are under public domain. Besides the experiences with the STEP technology at EP, the availability of these numerous software products is a reason for the

10

10

decision to implement the interface with the exchange of STEP physical file. The current focus is especially on objects which are contained in the so-called “PDM-Schema”. It offers vendors the ability to standardize the functionality, using common nomenclature for much of the functionality of PDM systems, whilst allowing them to extend the functionality using for example the EXPRESS schemas. STEP (ISO 10303) is an international standard to facilitate the storage and exchange engineering data related to products. STEP defines formats of product data for all types of products as well as for specific industry sectors. Two important parts of the STEP receive particular analysis: the object oriented modeling language EXPRESS (defined as ISO standard 130303 part 21) and the definition of data exchange formats (STEP Physical File format, defined as ISO standard 10303-21). The most important elements of the STEP are the so-called “Application Protocols” (AP) which define application specific objects. AP 214 is specific to the automotive domain. It defines for instance the major objects such as items, documents and bills of material. For an open workflow architecture, STEP is only interesting for the exchange of data, and thus for the interoperability of different PDM-systems. However STEP does cover dynamic aspects such as processes. Step entities for processes (such as “process_plan”, “process_operation”) cannot be used for a definition of a workflow process since they have different meaning in STEP. Objects like “work_orders” are suitable to describe ECM. Two important related objects are useful for our purposes: the Engineering Change Request (ECR), which is an official request to carry out a specific modification, and the Engineering Change Order (ECO) which results in an approved ECR, and is usually required to perform any modification of released products. ECR and ECO have been used as an ECM template in the WfMS of axalant™. But STEP does not cover the workflow aspect of ECM that describes the execution of the modification such: who has to examine what? Who is using which tools to modify the product definition? Also STEP does not explain how an ECR is released. Indeed, in the current axalant™, the WfMS is part of the PDM system, thus it does not require exchanging ECR or ECO data with other PDM systems. Therefore, the enhancements only focus on how ECR and ECO are implemented in the axalant™ and how they are connected with workflow processes. In addition, EXPRESS and STEP physical files will be used in the interface for the exchange of workflow definition between axalant™ and the workflow modeling tool ProView.

3.3. Analysis of the WfMC standard

Workflow management is not new (Aalst and Hee, 2002). For example Skip Ellis was applying variants of Petri nets to enact office procedures in the seventies (Ellis 1979). Michael Zisman was also using Petri nets to model office procedures before the term WfMS was invented (Zisman 1977). Since then many people both in industry and academia have been working on process-aware information systems. In the early and mid-nineties a lot of WfMS were developed (Jablonski and Bussler 1996, Georgakopoulos et al. 1995). Since then the WfMC has been active in developing standards and establishing standard terminology (Fisher 2001, Fisher 2003, Lawrence 1997). WfMC is clearly dedicated to support the standardization of workflow applications, and therefore interesting for the design of an open PDM workflow architecture. The Workflow Reference Model

11

11

aims to design a uniform language for process modeling and presents the functional description of the necessary key software components in a WfMS that facilitate its interoperability. There are two categories of interoperability specifications: (a) specification for workflow modeling and workflow description and (b) specification for runtime interoperability (Sheth et al. 1999). Interface 1, but also language proposals such as Process Interchange Format (PIF) and many others, fall into the first category. Interface 1 was developed to support the exchange of processes definition data between different workflow systems. PIF focuses on the syntax of the modeling language rather than support specifications or descriptions of process semantics. Tools can interoperate by translating their native process description format to PIF, and vice versa. But PIF did not become an industry standard. Interface 4 falls into the second category. It focuses on interoperability issues rather than on a uniform design language. The interface for the exchange of workflow process definitions was specified in close relation to the corresponding Interface 1. The top level entities of the meta-model of the WfMC describe entities contained within a workflow process definition, their relationships and attributes. It also describes development of an interface for the exchange of workflow process definitions and the basis for the exchange of workflow data too. For a more detailed review of XPDL, the XML-based language of the WfMC for Interface 1, the reader is referred to Aalst (2003a) and Shapiro (2002). Besides the analysis of STEP and WfMC standards, the tool ProView has been selected for the workflows definition and integration with axalant™.

3.4. Workflow modeling tool ProView

The WfMC classifies workflow systems into two categories: process definition and process execution. Process definition tools may be supplied as part of a WfMS or as a separate. They help to model organizational processes graphically and other tools may help to see how improvements could be made. Where an organization model is incorporated into such tools the process definition will include organization roles. ProView is capable of modeling business processes. Since the focus of ProView is not to analyze business processes, we refer to this type of tool as Workflow modeling Tool rather than Business Process modeling Tool. We adopted ProView instead of the Aris Toolset because analysis showed it is better suitable to model workflows. ProView has an internal representation of the process model that includes objects such as roles, activities, hierarchies of roles sequences. For the seamless integration, axalantTM and ProView need to communicate. The WfMC has proposed corresponding standards. The problem of such a standard is the missing coverage of system specific characteristics. The WfMC started to define an interface to exchange workflow definitions using the Workflow Process Definition Language (WPDL). Unfortunately this definition was not finalized during the ongoing SIMNET (and it still suffers from many problems as pointed out in Aalst (2003a)). STEP was therefore used instead of the WfMC. Accordingly; a STEP schema has been defined that complies with WfMC. Next sections discuss the modifications performed on the WfMS of axalantTM.

12

12

4. DESIGN: SPECIFICATION OF THE DESIRED PDM WORKFLOW ARCHITECTURE This section describes how the functionalities of the desired axalant™ workflow has been extended taking into account the previous discussion.

4.1. Extension of the data model

Figure 1 gives an overview of the corresponding data model of the enhanced WfMS of axalant™. It shows two new classes: “Process” representing the process itself and “activity’ that can be assigned to a role.

Figure 1: Entities and relations of the extended data model of axalant™

The most important entities in this data model are the following

Entity EDB-WRK-REQ - the Engineering Change Request (ECR) - This entity did exist in earlier versions of axalant™. Among important attributes of this entity are: identification of request, version of request, description of request, purpose of request, release procedure, current status, type of request,

13

13

reference to activities. EDB-PROCESS respectively EDB-ACTIVITY can be attached to an ECR. A folder (entity EDB-PACKET) may be attached to an ECR to hold all products (e.g. documents) that are affected from the described modification. Documents (entity EDB-DOCUMENT) which describe the purpose of the engineering change can also be assigned to the ECR).Usually an engineering change is issued in the scope of a specific project (entity EDB-PROJECT). Finally, an ECR can be transformed to engineering change orders (ECO’s)

Entity EDB- WRK-ORD - the Engineering Change Order (ECO) - This entity did exist in earlier versions of axalant™. Among important attributes of this entity are: identification of order, analysis to request, adopted solution, release procedure, current status, type of order, reference to activities, and date of completion. A workflow process (entity EDB-PROCESS respectively EDB-ACTIVITY) can be attached to an ECO. If a folder (entity EDB-PACKET) is attached to ECR, it is also attached to ECO. The same applies for documents (entity EDB-DOCUMENT) and the project (entity EDB-PROJECT) which may have been assigned to the ECR.

Entity EDB-PROCESS - the workflow process – This is a new entity used to manage administrative data of a workflow process (e.g. creation date and author) and runtime information (initiation document to be used, execution priority, time limits to be checked, and persons to be notified). Compared with the meta-model of the WfMC, EDB-PROCESS corresponds to the entity “Workflow Process Definition”. A workflow process references of a list of activities (entity EDB-ACTIVITY). A distinction between a workflow process definition (template) and instances of such a workflow process definition is required. Since the attributes required to describe these two different types are quite similar (only the runtime information such as completion dates are added for the instances of a workflow process), the entity EDB-PROCESS is used to represent both types. From a functional point of view, we can distinguish four possible states (Figure 2).

Template CompletionExecution

Ad-hoc

DefinitionTemplate CompletionCompletionExecutionExecution

Ad-hocAd-hoc

DefinitionDefinitionDefinition Figure 2: workflow life cycle The process template refers to a process which is used as a template. The process definition phase refers to a process instance that has been created, or copied from a template, but has not been started yet; if no template is used, the process is ad-hoc. Process templates and ad-hoc are created to deal with workflow flexibility. The process execution refers to a process instance that has been initiated. But, not all activities have been completed. The process completion refers to a complete execution of a process. Among important attributes associated “EDB-PROCESS” are: process’ name, version of the process, description of the process, classification of the process, release procedure, current status, process template is valid from (is valid until), start date of the process, initiator of the process, icon for

14

14

graphical presentation of the process, time-limit, priority of the process, phase (Template, Definition...), responsible for process, completion date of the process, unique process-Id, action performed before completion, and after completion.

Entity EDB-ACTIVITY - the activities - This is a new entity used to manage the individual activities (process steps) and corresponds to the entity “Workflow Process Activity” in the meta-model of the WfMC. A process definition consists of one or more activities, each comprising a role. An activity represents work which will be processed by a role which is a combination of resources and/or computer applications. Other optional information may be associated with the activity such as: started (finished) automatically by the WfMS and priority relative to other activities. Usage of specific workflow relevant data items by the activity may also be specified (e.g. pre- and post-condition, transition conditions or workflow participant assignment). The scope of an activity is local to a specific process definition. An activity may have three forms: an atomic activity, a sub-flow (a complex activity) or specified as a loop. Therefore, entity EDB-ACTIVITY has many attributes. The most important are: sequence number of activity within list; hierarchy level; resources (e.g. a user or a role); list of required preceding activities; description of work item when activity becomes active; action performed before completion(or after completion); and type of activity (e.g. split, join). The sequence of the activities is modeled by predecessors. Each activity knows the predecessor to watch out for in order to start execution. This corresponds to the “Transition Information” in the meta-model of the WfMC. To comply with WfMC, seven new activity types have been defined for axalantTM. Figure 3 shows the basic building blocks of the language (Aalst and Hee 2002).

15

15

ActivitySplit-and

Join-andSplit-or

Join-or

Split-xor

Join-xor

ActivitySplit-and

Join-andSplit-or

Join-or

Split-xor

Join-xor

Figure 3: Representation of the seven activities in the enhanced workflow of axalant™

4.2. Organizational model

The organizational model references to a resource. It is similar to the entity Workflow Participant in the meta-model of the WfMC. Besides users, groups, distribution resources in axalant™ roles has been added. A role refers to single or a group of participants exhibiting a specific set of qualifications and/or skills. Moreover, besides the user work item and group work item the enhanced axalant™ covers role work item too. It refers to a work item that has to be executed by any user with a specific role. For this purpose the work item list has a new attribute that shows the name of the role. The next section describes the achieved implementation within axalant™ to comply with previously proposed enhancements.

5. CONCRETE REALIZATION IN AXALANT™ This section describes the enhanced workflow module of axalant™.

5.1. Workflow process

Four different forms (Figure 4.a) for the entity EDB-PROCESS have been defined, including process templates (Figure 4.b). The transition between the four different states of a process is performed

16

16

automatically. A new process can be created as a "template" or as a process instance with the status "in definition phase". The status "in execution" is set as soon as the workflow process is initiated. If the last activity has been completed, the process state will change to "completed". The availability of the process template enables to generate ad-hoc workflow and to integrate changes when needed.

a) Top menu to access the workflow processes

b) Form for a process template

a) Top menu to access the workflow processes

b) Form for a process template

Figure 4: Interface of the enhanced workflow processes & associated activities

17

17

5.2. Activities

To simplify the definition of a complete workflow process including the associated activities, a combined form allows easy access to both entities (process template and activities). Figure 4.b shows an example of a process template with seven associated activities. This figure also shows the selection of the corresponding activity type with the help of a field select menu. Activities cannot only be defined as entries in this list, but much easier with the help of the graphical modeling tool ProView by simple drag of entities. The interface for the exchange of process definitions allows for the import and export of workflow processes between axalant™ and ProView. Figure 5 shows the workflow editor of the engineering change process generated by ProView and executed by axalantTM. In this workflow process, the boxes on the left define the role resources of an activity, the boxes in the middle and to the right show single activities and their sequence. If the size of the process is too large, ProView does feature a navigator that help users to visualize a sub set of the process as well as the whole process (see small icon in the left down corner of Figure 5).

18

18

Figure 5: Graphical definition of a workflow process with ProView

5.3. Work item list & notification

Notification about pending work items occur into two ways: system internal notification (that is improved) and system external notification (which has been developed).

Internal notification: It represents an existing notification mechanism in axalant™ but has been improved. Axalant™ features group in-boxes and individual in-boxes. The in-box is similar to that of

19

19

an e-mail system. The user in-box shows all outstanding work items which the particular user has received. The group out-box and user out-box shows all work items which were send already but have not yet been processed by the recipient. Work items (internal mails) in axalant™ can be created and sent. For that purpose a form has to be filled in. It includes information such as a target (user, group or a distribution or role too), priorities, and a mail text. Some fields are filled in by the system. It is possible to attach a reference to an existing object (document) to a work item.

Integration of axalantTM with external e-mail systems: Electronic mail is useful to inform external partners about changes. For this purpose an integration of axalant™ with external e-mail systems (e.g. Microsoft Outlook) has been created. Since axalant™ is capable of managing addresses of companies and persons, the corresponding e-mail addresses can be started from several axalant™ modules: workflow, document management and other objects (project and items). The first two possibilities are necessary to adapt to the existing internal mailing function according to the WfMC, mailing items and project are required especially for the inter-company collaboration. The integration of external e-mails with the workflow allows automatic generation notifications about the status change of objects such as documents. The document subject to change crosses several statuses: being processed, being changed, and released. The integration of external e-mails with document management is also important, when it comes to exchanging data with partners that do not have access to the axalant™ installation. To do so, a user selects the corresponding document within axalant™ and applies the function “Mail Document” from the corresponding context menu. In the next step the user can choose a recipient from existing addresses in axalant™ or define the address interactively.

5.4. Specification and implementation of the interface between ProView and axalant™

Interface to exchange workflow definitions between ProView and axalant™ has been developed based on STEP physical files. The term Workflow Enactment Service (in the process definition interface of the reference model of WfMC may be translated into WfMS or workflow application. For bi-directional data transmission the proper file format must be understood by the two systems. The nature of this interface is the "STEP Physical File" format (standardized as an ISO Standard 10303-21) which is used for the data exchange. The nature of the interface is an interchange format and Application Program Interface (API) calls, which can support the exchange of process definition information over a variety of physical or electronic interchange media. The interface may support the exchange of a complete process definition or a subset - for example a set of process definition changes or the attributes of a particular activity within the process definition. The interface is termed the process definition import/export interface. Processors are developed that convert the axalant™ data to the STEP-File format and vice versa (Figure 6). These are launched by axalant™ and run without interaction of the user. The import (or export) of workflow definitions from ProView to axalant™ (or vise versa) are written according to STEP-File format. With the help of this ISO standard, the syntax and the contents of exchange files are specified in a schema definition. For the description of this schema the specification language EXPRESS is used. Figure 6 depicts the steps of importing a workflow definition

20

20

from ProView to axalant™. It describes all relevant data to be exchanged such as version of axalant™, ProView version to which the processor belongs, name of the STEP physical file from which the workflow data should be imported to axalant™, and other data related to workflow process (process name, activity names, predecessors, etc.).

ProViewAxalantServer

Database

1Axlant

STEPphysical

File

2Import

Processor

ProView

Axalant Server

Database

Axalant

12

STEPphysical

File

ExportProcessor

ProViewAxalantServer

Database

1Axlant

STEPphysical

File

2Import

Processor

ProViewProViewAxalantServer

Database

AxalantServer

Database

11Axlant

STEPphysical

File

22Import

Processor

ProView

Axalant Server

Database

Axalant

12

STEPphysical

File

ExportProcessor

ProViewProView

Axalant Server

Database

Axalant Server

Database

Axalant

1122

STEPphysical

File

ExportProcessor

Figure 6 : Architecture of the Interface between ProView and axalant™

6. CONCLUSION & PERSPECTIVES This paper has presented enhancements for the WfMS module of a concrete PDM system, but many of the observations can be generalized to other PDM systems. The main contributions of this paper are related to the workflow design and interoperability of axalant™ according to STEP and WfMC standards. Major achievements fall in the application of existing workflow concepts rather than workflow design innovations. Achievements are related to: (a) the new entity “process”, used to manage administrative data of a workflow process, (b) the additional attributes for the existing entity “activity”, (c) the new building block split- and join-operations, and (d) usage of roles as a resource for process activities. Moreover, enhancements allow to model and execute workflow templates as well as ad-hoc processes which add flexibility to the PDM. Accordingly, axalantTM allows easy modifications to combine tasks, rearrange and reuse processes, and rearrange resources allocation to tasks. In addition, a STEP-based interface for the exchange of workflow definitions has been specified and implemented between axalant™ and ProView. This interface allows the exchange of predefined structured workflows as well as ad-hoc workflows. The usage of STEP physical files, in combination with WfMC compliant schema guarantees the open character of the interface.

21

21

However, the paper should only be seen as the starting point for combining PDM and WfMS functionality in a comprehensive manner. The solutions provided still have several limitations. First, the enhancement of axalant™ introduces several missing functions in current PDM technology but does not solve issues such as security and dynamic sharing of design data. Second, the paper focuses on workflow design, i.e., Interface 1 of the WfMC, and did not consider other perspectives and control and management functionality. Note that security (Leong et al., 2003, Currie et al., 2004, Rouibah and Caskey 2004) and dynamic sharing of design data (Noel and Brissaud 2003, Currie et al., 2004, Rouibah and Caskey 2004) are two big challenges facing partners when they collaborate within a network. Since collaboration may involve competitors and require dynamic data sharing, how to grant access to data of suppliers and customers while leaving the data under their control? Leong et al. (2003) proposed a security workspace solution. However, it is limited to distributed PDM systems within a single company. This paper proposes to further investigate inter-organizational and concurrent workflow and to adapt the workspace concept for both dynamic data exchange and security in the case of customer/ supplier collaboration. As discussed, this research stresses the need for systems such as axalant™ to comply to the XML Process Definition Language (XPDL). XPDL has become an alternative to the usage of STEP physical files. This paper encourages complying axalant™ with XPDL for two main reasons. First, the effort for such adaptation is rather small. Second, even the standards of WFMC have not been adopted by workflow vendors; the number of those who comply is increasing (see www.WfMC.org) but still not produce satisfactory results. For example, in the assessment of existing standards, Aalst (2003a) observed that some of WfMS vendors can export to XPDL, but none of them can import XPDL from another system and still produce meaningful results since there is no consensus about used constructs. It should be noted that since the realization of the enhancement reported in this paper, new standards such as BPEL4WS, BPML, XLANG, WSFL, WS-BPEL and EDOC emerged. These standards allow workflow interoperability and efforts are initiated to converge these standards. It seems that BPEL4WS will become the de-fact standard in this domain. However, the focus of BPEL4WS is limited to control-flow and does not incorporate things like documents, roles, and people. Therefore, languages like BPEL4WS can only provide part of the solution.

REFERENCES Aalst W.M.P. van der (, 2003b): Don't go with the flow: Web services composition standards exposed. IEEE Intelligent

Systems, vol. 18, no1, pp. 72-76

Aalst W.M.P. van der (1998). The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers, vol 8, no1, pp. 21-66

Aalst W.M.P. van der, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros (2003). Workflow Patterns. Distributed and Parallel Databases, vol. 14, n01, pp. 5-51,.

Aalst W.M.P. van der, and K.M. van Hee (2002): Workflow Management: Models, Methods, and Systems. MIT press, Cambridge, MA,

22

22

Aalst W.M.P. van der, T. Basten, H.M.W. Verbeek, P.A.C. Verkoulen, and M. Voorhoeve (2000): Adaptive Workflow: On the Interplay between Flexibility and Support. In J. Filipe, editor, Enterprise Information Systems, pages 61-68. Kluwer Academic Publishers, Norwell,

Aalst W.M.P. van der. Business Process Management Demystified (2003a): A Tutorial on Models, Systems and Standards for Workflow Management. In Lectures on Concurrency and Petri Nets: Advances in Petri Nets. Volume 3089 of Lecture Notes in Computer Science, pages 1-65. Springer-Verlag, Berlin.

Anonymous (2001): Collaborative engineering through the supply chain. Strategic Direction, vol. 17, no9, pp. 30-33

Checkland, P. and Holwell, S. (1998), ``Action research: its nature and validity’’, Systemic Practice and Action Research, Vol. 11 No. 1, pp. 9-21.

Choi I., Park C., and Lee C. (2002): A transactional workflow model for engineering/ manufacturing processes. International Journal of Computer Integrated Manufacturing, vol. 15, no2, pp. 178-192

Chu X., and Y. Fan (1999), Product data management based on web technology, Integrated Manufacturing Systems vol. 10, pp. 84-88

CIMdata (1998): Product Data Management: The Definition, An Introduction to Concepts, Benefits, and Terminology, CIM-data

CIMdata: www.cimdata.com

Curbera F., Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana (2002). Business Process Execution Language for Web Services, Version 1.0. Standards proposal by BEA Systems, International Business Machines Corporation, and Microsoft Corporation.

Currie W.L., Wang X. and Weerakkody V. (2004) Developing Web services using the Microsoft.Net platform: technical and business challenges. The Journal of Enterprise Information Management Vol. 17, no 5, ·2004 · pp. 335–350

EDM (1999), Engineering Data Management Newsletter, Benefits of EDM/PDM in Manufacturing Industries, Vol. 9, No.3.

EDM (2000), Engineering Data Management Newsletter, UK PDM Survey, Vol. 9, No. 8.

Ellis C.A. (1979): Information Control Nets: A Mathematical Model of Office Information Flow. In Proceedings of the Conference on Simulation, Measurement and Modeling of Computer Systems, pages 225-240, Boulder, Colorado, ACM Press.

Fischer L., editor. Workflow Handbook (2001), Workflow Management Coalition. Future Strategies, Lighthouse Point, Florida.

Fischer L., editor. Workflow Handbook (2003), Workflow Management Coalition. Future Strategies, Lighthouse Point, Florida.

Gao J.X, Aziz H., Maropoulos P.G. and Cheung W.M. (2003): Application of product data management technologies for enterprise integration. International Journal of Computer Integrated Manufacturing, vol. 16, no 7-8, pp. 491-500, 2003

Georgakopoulos D., M. Hornick, and A. Sheth (1995). An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, 3:119-153.

23

23

Harris S.B., (1996), Business strategy and the role of the engineering product data management: a literature review and summary of the emerging research questions, Part B. Journal of Engineering Manufacture, Proceedings of IMechE, vol. 210, pp. 217-219

Jablonski S. and C. Bussler (1996). Workflow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, London, UK.

Kempfer L. (2000): PDM make the connection. Computer-Aided Engineering, vol. 19, no 4, pp. 26-30

Kim Y., Kang S., Lee S., and Yoo S., (2001), A distributed open intelligent product data management system. International Journal of Computer Integrated Manufacturing, 14, 224-235

Kumar R. and Midha P.S. (2004): A QFD methodology for evaluating a company’s PDM requirements for collaborative product development. Industrial Management + Data Systems, vol. 101, no3/4, pp. 126-132

Lawrence P., editor. Workflow Handbook (1997), Workflow Management Coalition. John Wiley and Sons, New York.

Leong K.K. Yu K.M. and Lee W.B. (2003): a security model for distributed product data management system. Computer in Industry, vol. 50, no2, pp.179

Liu T., and Xu X.W. (2001): A review of web-based product data management systems. Computers in Industry vol. 44, pp 251-262

Mansfield T., (2002): An easy-to-implement PDM. Machine Design, March, vol. 74, no6, pp. 84-85

Muehlen M. Zur. (2004) Workflow-based Process Controlling: Foundation, Design and Application of workflow-driven Process Information Systems. Logos, Berlin.

Noel F., and Brissaud D. (2003): dynamic data sharing in a collaborative design environment. International Journal of Computer Integrated Manufacturing, vol. 16, no, 7-8, pp. 546-556, October-December

Oh Y., Han S., and Suh H., (2001), Mapping product structure between CAD and PDM systems using UML. Computer Aided Design, 33, pp. 521-529

Philpotts M. (1996): An introduction to the concepts, benefits and terminology of product data management. Industrial Management & Data Systems, vol. 96, n04, pp.11-17

Puschmann T. and Alt R. (2003) Enterprise application integration systems and architecture – the case of the Robert Bosch Group. The Journal of Enterprise Information Management Volume 17 . N0 2 . 2004 . pp. 105-116

Rouibah K. & Caskey K, (2004), Managing concurrent engineering across company borders: a case study. International Journal of Computer Integrated Manufacturing, (forthcoming).

Rouibah K. and K Caskey (2003a), Change Management in Concurrent Engineering from a Parameter Perspective. Computers in Industry, vol. 50, no 1, pp 15-34

Rouibah K. and K Caskey (2003b)., An Engineering Workflow System for the Management of Inter-Company Engineering Processes. Journal of Engineering Design Vol. 14, no 3, pp. 273-293, September

Schmitz B. (1999): Steelcase reduces new part generation with PDM. Computer-Aided Engineering, vol. 18, no10, pp. 8-9 Shapiro R. (2002): A Comparison of XPDL, BPML and BPEL4WS (Version 1.4). http://xml.coverpages.org/Shapiro-XPDL.pdf.

Sheth A. P., Aalst W. A. and Arpinar I B., (1999): Processes deriving the Networked economy. IEEE Concurrency, , pp. 2-15, July-September

24

24

Siddiqui Q.A., Burns N.D. and Backhouse C.J., (2004): implementing product management the first time. International Journal of Computer Integrated Manufacturing, vol. 17, no6, , pp. 520-533, September

Smith A. (2004): Empirical exploration for a product data management system at a major telecommunication firm. Industrial Management + Data Systems, vol. 104, n0 5/6, pp. 513

WfMC (1999), Workflow Management Coalition: Terminology and Glossary. Technical report WfMC-TC-1011, issue 3

Wognum P.M. and Kerssens-van Drongelen I.C. (2001): Process and impact of Product Data Management implementation. CE 2001 held at Bremen Germany

Wohed P., W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede (2003). Analysis of Web Services Composition Languages: The Case of BPEL4WS. In I.Y. Song, S.W. Liddle, T.W. Ling, and P. Scheuermann, editors, 22nd International Conference on Conceptual Modeling (ER 2003), volume 2813 of Lecture Notes in Computer Science, pages 200-215. Springer-Verlag, Berlin.

Yeh S., and You C. (2002): STEP-based data schema for implementing product data management. International Journal of Computer-Integrated Manufacturing, vol. 15, no1, pp. 1-17, January

Zisman M.D. (1977): Representation, Specification and Automation of Office Procedures. PhD thesis, University of Pennsylvania, Warton School of Business

i Part of this work was done at the I&T department at the faculty of Technology Management, and fully supported by the EC project EP26780 SIMNET ii The classification used by the American consulting firm CIMdata, Inc., is referenced in a large number of scientific PDM papers. This classification is based on their consulting engagement with PDNM users and vendors iii For further information, refer to Special issue "business transformation through web services", vol. 17, no5, 2004, in Journal of Enterprise Information management iv For further information, refer to special issue "Enterprise systems integration and management", vol. 17, no1, 2004, in Journal of Enterprise Information management