International Journal of Computer Integrated Manufacturing

This article was downloaded by:[Kuwait University] [Kuwait University] On: 26 June 2007 Access Details: [subscription number 779290507] Publisher: Taylor & Francis Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

International Journal of Computer Integrated Manufacturing Publication details, including instructions for authors and subscription information: http://www.informaworld.com/smpp/title~content=t713804665

Combining workflow and PDM based on the workflow management coalition and STEP standards: the case of axalant First Published on: 24 January 2007 To cite this Article: Rouibah, K., Rouibah, S. and Van Der Aalst, W. M. P. , 'Combining workflow and PDM based on the workflow management coalition and STEP standards: the case of axalant', International Journal of Computer Integrated Manufacturing, 1 - 17 To link to this article: DOI: 10.1080/09511920600930038 URL: http://dx.doi.org/10.1080/09511920600930038

PLEASE SCROLL DOWN FOR ARTICLE Full terms and conditions of use: http://www.informaworld.com/terms-and-conditions-of-access.pdf This article maybe used for research, teaching and private study purposes. Any substantial or systematic reproduction, re-distribution, re-selling, loan or sub-licensing, systematic supply or distribution in any form to anyone is expressly forbidden. The publisher does not give any warranty express or implied or make any representation that the contents will be complete or accurate or up to date. The accuracy of any instructions, formulae and drug doses should be independently verified with primary sources. The publisher shall not be liable for any loss, actions, claims, proceedings, demand or costs or damages whatsoever or howsoever caused arising directly or indirectly in connection with or arising out of the use of this material. © Taylor and Francis 2007

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

International Journal of Computer Integrated Manufacturing, 2007, 1 – 17, i-First article

Combining workflow and PDM based on the workflow management coalition and STEP standards: the case of axalant K. ROUIBAH{, S. ROUIBAH*{ and W. M. P. VAN DER AALST{ {Department of Quantitative Methods and Information Systems, Kuwait University, P.O. Box 5486 Safat, Code No 13055, Kuwait {Department of Technology Management, Eindhoven University of Technology, P.O. Box 513, NL-5600 MB Eindhoven, The Netherlands Product data management (PDM) current technology has several pitfalls such as lack of compliance of workflow modules to standards as well as lack of interoperability between these systems. This paper illustrates the extension of the current workflow management system part of the PDM system axalant to support engineering processes management. The extension was based on an analysis of the workflow management coalition and STEP standards and, through the extension described in the paper, now axalant complies with these standards. Because of this it is now possible to exchange workflow data with existing workflow systems on the market. In this paper the two standards are analysed, the required 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 axalant and ProView, which helps to generate graphical process definitions. Major achievements consist of the enhancement of process design through the creation of building blocks (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 axalant to handle changes, and axalant is able to generate workflow templates and ad-hoc processes and to communicate with external workflow systems. Keywords: Product data management; Workflow management system; Process modeling; AxalantTM; Proview; Web service; Process mining

1. Introduction Companies around the world are increasingly implementing Product Data Management (PDM) to improve their competitiveness. The software 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 2006. According to CIMdata (2006), PDM systems support management of both engineering data and the product development process during the product lifecycle. These

systems allow seamless interoperability between different departments and throughout the supply chain during product design. Participation/collaboration is especially eased by the use of the latest web-based systems (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 volumes of engineering data, and being flexible (Harris 1996). The term ‘engineering data’ includes geometry, engineering drawings, project plans, part files, assembly diagrams,

*Corresponding author. Email: [email protected] (Part of this work was done at the I&T Department at the Faculty of Technology Management, and was fully supported by the EC project EP26780 SIMNET.) International Journal of Computer Integrated Manufacturing ISSN 0951-192X print/ISSN 1362-3052 online ª 2007 Taylor & Francis http://www.tandf.co.uk/journals DOI: 10.1080/09511920600930038

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

2

K. Rouibah et al.

product specifications, bills of material, engineering change orders, etc. PDM systems have several benefits which have been well documented previously (Philpotts 1996, CIMdata 1998, EDM 1999, 2000 Anonymous 2001, Smith 2004), including interdisciplinary collaboration, reducing product development cycle time and data complexity, as well as improving project management. 1.1.

Focus of this paper

While PDM systems have several functions, workflow and interoperability functions are the central focus in this paper. The authors have focused on these two issues because 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% of respondents) as well as workflow and configuration management (70% of respondents). The Workflow Management Coalition (WfMC 2006) defines the term ‘workflow system’ as a 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 other tools and applications (other components/function of a PDM)’. Communication and notification functions are facilitated by an integrated mail systems. Over the last decade, literature has addressed several PDM issues including case studies about their benefits (Schmitz 1999, Anonymous 2001, Smith 2004), methods to design web-based systems (Chu and Fan 1999), application in specific industries (Hemeri and Nihtila 1998), implementation issues (Siddiqui et al. 2004, Smith 2004), description of specific systems (Mansfield 2002, Eynard et al. 2004), guidelines for implementations (Siddiqui et al. 2004), security requirements for distributed systems (Leong et al. 2003), identification of PDM requirements for collaborative product development (Kumar and Midha 2004), identification of risks and the key success factors (Littler et al. 1995), literature review and summary of research questions (Harris 1996), integration of PDM systems with other systems such as Enterprise Resources Planning (ERP) systems (Gao et al. 2003), and state of the art Product Lifecycle Management (PLM) functionalities (Abramovici and Sieg 2002). However, workflow enhancement within PDM systems and their interoperability have received little attention. An important question emerges: how to combine workflow and PDM in order to ease collaborative engineering processes? The aim of the current paper is to enhance the workflow module of the axalant developed by Eigner & Partners according to existing

standards.1 Enhancements are done to increase the current technology of PDM systems. This paper describes the trend, the open PDM-workflow architecture and the improvements done in terms of workflow interoperability, workflow module design and its ease of use. Specifically, this paper brings two main contributions. First, it enables axalant to comply with the standards of the workflow management coalition and STEP (Standard for the Exchange of Product) model data (ISO 2006) since few papers described such compliance. Second, it adds interoperability functions to workflow of axalant in order to facilitate exchanging workflow data with workflow modules of other PDM. Enhancement efforts were initiated within the European Communities project EP26780 SIMNET. Section 2 is an overview of current functions and limits of existing commercial systems. Section 3 describes the case of enhancing axalant. It presents the analysis phase including user’s requirements for an enhanced workflow module, the design phase that specifies the desired PDM workflow module taking into account the analysis phase, and the adaptation of the axalant workflow architecture. Finally section 4 summarizes the main ideas of the paper and points to 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 continue to emerge. They range from extensions of computer added design (CAD) systems into an independent system to PLM (Christmas 2001). According to CIMdata, PLM is a strategic business approach that applies a consistent set of business solutions in support of the collaborative creation, management, dissemination and use of product definition information across the extended enterprise from concept to end of life. PLM offers high and more sophisticated functions (Kumar and Midha 2004). 1.

2.

3.

Interoperability functions enable users to connect heterogeneous systems hosted by different partners (e.g. other PDM, or ERP systems or CRM systems) and ease data exchange between them (Kempfer 2000, Gao et al. 2003, Puschmann and Alt 2004). Inter-organizational business process management, communication and web integration functions link distributed teams over the supply chain (Liu and Xu 2001, Kumar and Midha 2004). Security functions ensure confidentiality of data exchange and all users are under controlled and managed corporation (Leong et al. 2003).

1 Eiger was acquired by its competitor, Agile (Agile 2006) leaving the Partner alone.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

Despite their numerous benefits, the potential of PDM systems is not yet achieved by current systems (Abramovici and Sieg 2002). Beside the fact that no single system available in the market provides all the previous PDM capabilities (Kumar and Midha 2004), there are several drawbacks of the current technology. First, there is a lack of interoperability standards between PDM systems leading to limited interoperability functions. A Dutch study (Wognum and Drongelen 2001) has shown that 50% of sampled companies do exchange data using PDM systems 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 collaborative engineering data and workflow data are distributed among partners, system integration and workflow systems interoperability are two critical issues for product lifecycle management. Several authors have raised similar issues. For example the study by Yeh and You (2002) 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 STEP based. Gao et al. (2003) presented another drawback. There is a lack of a generic standard for PDM system implementation. The authors proposed a model integration that is STEP based. Puschmann and Alt (2004) 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 stressed that the integration should not be at data-level but also at process level (workflow based). Since PDM systems have been developed according to different paradigms, their 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); and (c) use of UML (Oh et al. 2001, Eynard et al. 2004). Opposite to PDM, workflow systems interoperability may be achieved through other standards such as workflow management coalition. System integration is also an important issue in the area of Enterprise Application Integration systems (Puschmann and Alt 2004). According to these authors, organizations spend at least 40% of their IT budget for integration purposes. Sheth et al. (1999) reported Fortune 2000 companies spend 25% to 33% of their IT budget on system integration. Second, several workflow of PDM systems are very restrictive and inflexible as observed by Gao et al. (2003). In the engineering areas, processes are complex, dynamic,

3

subject to several changes, which require flexibility and adaptability. Workflow 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. This process encompasses emergence of a need for a change, request for a change, management approval of the change, implementation, and documentation where all impacted product data have been updated (Rouibah and Caskey 2003a). Flexibility could be added to PDM by complying workflow to existing standards. Moreover, the authors have surveyed papers related to workflow and PDM over the last 15 years in the ProQuest data base. This showed a scarcity of existing studies, except the study done by Kim et al. (2001). The author developed a dynamic and flexible workflow model that is STEP based. The main emphasis is placed on dynamic process adaptation (workflow-based) which is a requirement by product development. Choi et al. (2002) discussed and present a workflow model that satisfies requirements of engineering/manufacturing processes. Anonymous (2001) reported that DaimlerChrysler has used FastCar, a web based system for collaborative workflow and change management that enables it to reduce the engineering change from twelve weeks to a few hours. The company processes tens of thousands of engineering changes annually. However, the authors did not specify whether the system allows DaimlerChrysler’s partners to be involved or not. Third, other limits of current PDM 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). The next section describes how some of the drawbacks mentioned above were addressed through the combination of workflow and PDM in axalant.

3. The case of improving axalant 3.1. Necessity to combine workflow and PDM Combining workflow and PDM is relevant and noteworthy for both academicians and practitioners. For academicians it is an emerging research area since few papers focused on this issue (see section 1.1). It is also useful to allow integration of processes handled in different systems such as customer relationship management, supply chain management, and enterprise resource planning. Figure 1 shows the four areas where workflow and PDM may interact with each other. In particular it is expected that the merge will help to better achieve cross-company workflow coordination, ease inter-company engineering change management, facilitate system integration and ease

K. Rouibah et al.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

4

Figure 1.

Some contexts where PDM and workflow sit together during collaborative design.

configuration management. Cross-company collaboration between manufacturers and their suppliers is becoming a reality in many business fields. Manufacturers focused on their core business and outsourced most of their non core activities. This is shown in figure 1 by the main manufacturer who collaborates with three companies (a supplier B, an engineering partner A and a subcontractor C). Each has its own data and specific systems, but do share other data with other partners. Accordingly, roles, activities, sequence of activities their planning as well as authorities and responsibilities assigned to each role must be specified before carrying out any collaborative project. These processes may be supported either by a stand alone workflow system, or by workflow modules embedded in different PDM systems. During design, many engineering changes including engineering change requests and orders with specific deadlines take place due to the iterative nature of product design, and therefore many versions of the same product need to be maintained for the same design or for reuse in the future. These versions belong to a specific project, and required specific product items (Bill of Material (BoM)) with specific logical associations. The process of engineering change requests and orders must be undertaken with careful control in order to minimize their number. Product items subject to change are stored in

a different component of PDM systems such as document management, bill of material/item classification, parameter management, as well as within workflow modules. Versions of product items are managed by the configuration management module of the PDM system. When partners in a collaborative project work together, they may use different systems such as PDM, computer aided X (design, manufacturing, etc.), accordingly, integration requires identification of the process name, version of the system used, the name of activities supported by the system. Thus the combination of PDM and workflow is expected to ease the above process. Efforts to merge workflow and PDM systems are also important for practitioners and system developers. ‘There is high competition in the PDM market. Integration of our workflow module with other PDM systems is important in order to ensure its competitiveness’ quoted a product manager of a leading PDM company. The market opportunity is growing rapidly. According to ARCweb (2006) PLM is one of the most dynamic and fastest growing enterprise software markets. According to CIMdata (2006) the product lifecycle management market is estimated to exceed $20 billion by 2008 while it was $2.0 billion in 2000. With the increase of the market opportunities, companies are offering better solutions to cope with customers’ requirements, customer satisfaction and short

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

responsiveness. This concept was introduced by Blackburn (1992) in order to qualify proactive and vigilant companies who respond with appropriate actions to surpass competitors. From the viewpoint of practitioners (i.e. the business users’ view), the integration of workflow and PDM is a prerequisite to support inter-company collaboration along the product life cycle. The main reasons for collaboration on product development projects include satisfying customer requirements, taking advantage of market opportunities for which the firm lacks necessary skills and technical expertise, and responding to changes in technology. Integration of workflow and PDM is expected to ease the automation of engineering business process and to cut-down costs associated through early exchange of bids (preliminary engineering data) between suppliers and Original Equipment Manufacturers (OEM) at the very early stages of new product development. Furthermore, a case study performed within two European companies (Rouibah and Caskey 2005) has shown that the benefit of combining workflow and PDM enables companies to move from project-based to product-based in order to ease engineering change management. In the product design and engineering domain, workflow processes are not totally specified and require negotiation which lead to many ad-hoc engineering changes. Many studies have shown that the costs associated with these engineering changes are very high. For example, Boznak (1993) reported the annual engineering change processing cost ranged from $3.4 million to $ 7.7 million, Maull et al. (1992) found that engineering change may incur a cost of up to 10% of annual turnover and Watts (1984) found that it requires an average of 40 days to discover an engineering change, 40 days to process and approve it, and 40 days to implement it. In the same stream, Clark and Fujimoto (1991) found 20% to 40% of die development costs in vehicle development are caused by engineering change. Engineering change management is a process of three phases. The first phase initiation of an engineering change request (ECR) consists of identifying a change to be carried out. For example, modify the speed of a railway train. The second phase consists of studying the engineering change request in order to identify which product items (document, bill of material, parameter, etc.) are affected by change, who needs to be informed and what critical data are needed to be exchanged between affected people. Once all affected people agree on the request, the engineering change request is then transformed into an engineering change order (ECO). In the third phase engineering change order is executed and all changes are communicated to affected people in order to propagate the changes on the objects/items under their control. In this paper, it is argued that the link between workflow and PDM could help to improve and achieve earlier engineering change management, as well as to reduce cost associated with this process.

5

Combining workflow with PDM may enable to overcome two additional issues: heterogeneity and distribution. Heterogeneity, herein discussed in terms of different types of data, pertains to information use in different departments and partners. Distribution pertains to ways to deliver the right data to the right person in cases where there is change. The next section describes the analysis phase including user’s requirements for an enhanced workflow module. 3.2. Analysis and requirements collection Many perspectives characterize a workflow system design (Aalst et al. 2003). The desired workflow 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 the stand workflow management coalition. In the organization 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 (e.g. mechanical staff) and groups (e.g. sales department). Resources are allocated to roles and groups. The information perspective deals with control and production data. Control data are introduced for the workflow engine purposes. Production data are information objects (e.g. 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 the workflow domain addresses characteristics typically neglected by contemporary workflow systems. Among the desired functions, flexibility (e.g. see Aalst and Basten 2002) is of the utmost importance. A flexible workflow is a system that can be easily adapted to change. It allows users 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 to its complete restructuring. The concern of this paper is to improve the ad-hoc change. With regards to the above functions, the next section describes the weakness of axalant, and argues why improvements are needed.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

6

K. Rouibah et al.

3.2.1. The current workflow module of axalant and its limitations. Besides lack of interoperability with existing workflow technology, analysis of the workflow module shows two major disadvantages: 1.

2.

Axalant exhibits limitations with respect to workflow design and does not comply with workflow management coalition. With regard to process perspective, axalant exhibits several drawbacks. a. First, the user interface of the workflow module is part of the PDM system and cannot be separated. The PDM system does feature a workflow engine that executes workflows, but its capabilities are limited. b. Second, the workflow system is not user friendly enough (limited ease of use and accessibility and 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 modern complex business, most processes are not linear. Compliance with workflow management coalition requires adding the logic of control flow such as in a situation involving synchronization or choice (OR/AND split). Aalst et al. (2003) presented a detailed discussion of the design patterns workflow system should support. c. Third, workflow definitions are stored as a sequence of activities with associated organizational units. The role concept specified by workflow management coalition 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 analyse every single workflow activity, if the new user shall be privileged to execute this activity. The administration effort is enormous. d. Fourth, linked to previous, role specific work items are missing. Only two types of work items are available: the ‘user specific work items’ and the ‘group specific work items’ are successively executed. With regard to resource perspective, the workflow module of axalant exhibits only an internal notification service and does not support intra company communication. 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). With regard to this aspect, the workflow module exhibits three limits. a. 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 uses workflow templates (Aalst and Basten 2002). It is a standard design of common workflow process that lets designers reflect local differences and reuse common parts. b. Second, linked to previous limit, the workflow module does not allow users to change processes once they are designed, and to deal with unexpected situations. An example is when a deadline for a task expires or the person responsible is away. c. Third, the workflow module does not allow users to generate workflow processes on an adhoc basis, i.e. workflow processes whose structure cannot be predicted in advance. Since this paper deals with workflow interoperability, two categories of specifications are available (see workflow management coalition): (a) specifications for workflow modelling and workflow description (design time) and (b) specifications for runtime interoperability. Interface 1 of the workflow management coalition falls into the first category while interface 4 and STEP fall into the second category. Interface 4 defines the mechanisms that workflow product vendors are required to implement for one workflow engine to make requests of another. Since axalant exhibits a workflow module that is embedded in the PDM system, the focus is on the standard extensible markup language (XML) Process Definition Language (XPDL) of the workflow management coalition for workflow description, and STEP for runtime interoperability. The next sections describe how the existing workflow system can be extended, in order to meet these two standards. 3.2.2. Analysis of the STEP standard: allowing engineering change management. The reason for focusing attention on STEP is as follows. The STEP community copes mainly 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. The availability of these numerous software products is a reason for the 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 extend the functionality of PDM using for example the EXPRESS schemas. STEP (ISO 10303) is an international standard to facilitate the storage and exchange engineering data related to products. Two important parts of the STEP

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

receive particular analysis: the object-oriented modelling 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’ which define application specific objects. 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 AP 214 was the base for Engineering Change Request (ECR)/ ECO in axalant. ECR is an official request to carry out a specific modification, and ECO is a result of approving an ECR. ECO is usually required to perform any modification of released products. ECR and ECO have been used as an engineering change management template in the workflow of axalant. But STEP does not cover the workflow aspect of engineering change management that describes the execution of the modification such as: 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 workflow is part of the PDM system, thus it does not require exchanging ECR or ECO data with other PDM systems. Therefore, this research focuses on how ECR and ECO are enhanced and implemented in the PDM axalant. 3.2.3. Analysis of the workflow management coalition standard. In the early and mid-nineties a lot of workflow systems were developed (Georgakopoulos et al. 1995). Since then the workflow management coalition consortium has been active in developing standards and establishing standard terminology (Fischer 2003). Efforts undertaken by this consortium are clearly dedicated to supporting the standardization of workflow applications, and therefore interesting for the design of an open PDM workflow architecture. The Workflow Reference Model aims to design a uniform language for process modeling and presents the functional description of the necessary key software components in a workflow system that eases its interoperability. Interface 1 enables specification for workflow modelling and workflow description. This interface was developed to support the exchange of processes definition data between different workflow systems based on XPDL. 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 reference model 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. Aalst (2003) and Shapiro (2002) presented a detailed review of XPDL.

7

Besides the analysis of STEP and workflow management coalition standards, the tool ProView has been selected for the workflows definition and integration with axalant. The consortium workflow management coalition classifies workflow systems into two categories: process definition and process execution. Process definition tools may be supplied as part of a workflow system or as a separate software. 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. Since the focus of ProView is not to analyse business processes, this type of tool is referred to as a workflow modelling tool rather than a business process modelling tool. The authors adopted ProView instead of the Aris Toolset (IDS-SCHEER 2006) for three main reasons. First, ProView is developed by PiSA (PISA 2006), that is partly owned by the company that develops axalant. Second, analysis showed ProView is more suitable to model workflows and to represent organizational model based on the role concept. Third, ProView is capable of modeling business processes in a graphical way since it has capabilities to represent process model with objects such as roles, activities, and hierarchies of roles sequences. For the seamless integration, axalant and ProView need to communicate. This is achieved through STEP and XPDL (see section 3.5.2). 3.3. Design: specification of the desired PDM workflow architecture According to figure 2, the most important enhanced and new elements are related to workflow, integration of Proview and external e-mail, and workflow interoperability. The next section describes how the functionalities of the desired axalant workflow have been extended. 3.4. Enhancing the workflow through the extension of the data model Figure 3 gives an overview of the corresponding data model of the enhanced workflow of axalant. It shows three new classes: ‘process’ representing the process itself, ‘activity’ that can be assigned to a role, and ‘role’ that performs specific activities. The most important entities in this data model are the following. 1.

Entity ECR. This entity did exist in earlier versions of axalant. 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, reference to activities. PROCESS respectively ACTIVITY can be

K. Rouibah et al.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

8

Figure 2. Architecture of the new PDM system.

2.

attached to an ECR. A folder (entity PACKET) may be attached to an ECR to hold all products (e.g. documents) that are affected by the modification. Documents (entity 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 PROJECT). Finally, an ECR can be transformed into an ECO. Entity ECO. This entity did also exist in earlier versions of axalant. Among important attributes of this entity are: identification of order, request analysis, adopted solution, release procedure, current status, type of order, reference to activities, and date of completion. A workflow process (entities PROCESS and ACTIVITY) can be attached to an ECO. If a folder (entity PACKET) is attached to ECR, it is also attached to ECO. The same applies for documents (entity DOCUMENT) and the project (entity PROJECT) which may have been assigned to the ECR.

3.

Entity ‘PROCESS’. This is a new introduced 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-limit to be checked, and persons to be notified). Compared with the meta-model of the workflow management coalition, PROCESS corresponds to the entity ‘Workflow Process Definition’. A workflow process reference of a list of activities (entity 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 PROCESS is used to represent both types. From a functional point of view, four possible states can be distinguished (figure 4). a. The process template refers to a process which is used as a template.

9

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

Figure 3.

Entities and relations of the extended data model of axalant.

Figure 4.

Workflow lifecycle.

b.

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. c. The process execution refers to a process instance that has been initiated, but, not all activities have been completed. d. The process completion refers to a complete execution of a process. Among important attributes associated with ‘PROCESS’ are: process’ name, version of the process, description of the process, classification of the process, release procedure, current status, process

4.

template is valid from (is valid until), start date of the process, initiator of the process, icon for graphical presentation of the process, time-limit, priority of the process, phase, responsible for process, completion date of the process, unique process-Id, action performed before completion, and after completion. Entity ‘ACTIVITY’. This is a new introduced entity used to manage the individual activities (process steps) and corresponds to the entity ‘Workflow Process Activity’ in the meta-model of the workflow management coalition. A process definition consists of one or more activities, each comprising a role. An activity represents work which will be processed by a role. Other optional

10

K. Rouibah et al.

process template enables the generation of an ad-hoc workflow and to integrate changes when needed. The transition between the four different states of a process is performed automatically. 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 5 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 can be defined easier with the help of ProView by simple drag. To perform work item list, a notification mechanism about pending work items is used. This occurs in two ways: system internal notification (that is improved) and system external notification (which has been developed). Internal notification 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 an email 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 sent already but have not yet been processed by the recipient. Work items (internal mail) in axalant can be created and sent through a form which includes information such as a target (user, group or role too), priorities, and a mail text. Some fields are filled automatically by the system. External notification is achieved through integration of axalant with external email systems (e.g. Microsoft Outlook). Such integration is useful for the inter-company collaboration. Since axalant is capable of managing addresses of companies and persons, the corresponding email addresses can be started from several axalant modules including workflow, document management, engineering change management and project management. The integration of external emails with the workflow allows automatic generation notification about the status change of objects. When sending documents, axalant works the same way as a normal email system.

Many features have been implemented to enhance the PDM axalant. These are presented in the next section.

3.5.2. Interface between ProView and axalant. The interface for the exchange of workflow definitions between axalant and ProView has been developed in two phases. In the first one, integration was achieved through the use of EXPRESS and STEP physical files. Later on, in the second phase, such an interface has been adapted to XPDL. In the first phase, an interface has been developed based on STEP physical files. 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

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

information may be associated with the activity such as: started (finished) automatically by the workflow system 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). An activity may have three forms: an atomic activity, a sub-flow (a complex activity) or specified as a loop. Therefore, entity 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 workflow management coalition. To comply with this standard, seven new activity types, representing building blocks of the language (Aalst et al. 2003), have been defined for axalant, which are ‘Normal activity’, ‘Join-And’, ‘Split-And’, ‘Split-Or’, ‘JoinOr’, ‘Split-Xor’, and ‘Join-Xor’ Entity ‘ROLE’. This is similar to the entity Workflow Participant in the meta-model of the workflow management coalition. Besides users, groups, distribution resources in axalant, roles have also been added. A role refers to a 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.

5.

3.5.

Concrete realization

3.5.1. Enhancements of the workflow process. With regard to the workflow process, four different forms for the entity PROCESS have been defined, including process templates. 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

11

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

Figure 5. Interface of the enhanced workflow processes and associated activities.

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 These are launched by axalant and run without interaction of the user. 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 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.). Since XPDL has become a standard for data communication between heterogeneous systems (see WfMC 2002), the interface (intially STEP based) was adapted to XPDL. It is used to notify users about new work-items as well as to

exchange messaging between different workflow engines independent of the process definition language used. 3.6. Scenario illustrating the approach Let us assume two companies (A and B) are involved in a collaborative effort to design a new mechanical product (e.g. a rail way bogie). The two companies contribute to design a product according to figure 1. Each company holds data related to product design which are stored in their local PDM system (either the same with different versions) as well as in different CAD systems. Engineers need to optimize the design by considering a number of parameters (including geometrical, such as wheel diameter, brake power and total train weight). Such design involves decisions (activities) based on parameter specifications (see Rouibah and Caskey 2005). Some of them are known in advance. For example, ‘initiate parameter value’, ‘approve value’, ‘release value’, and ‘modify value’, while others are not known (e.g. who is affected by a parameter change, what other item-components are affected by the current change). Several roles originating from different departments are involved in the product design/ and to perform these activities. During the kick-off, members of the two companies collectively define a new collaborative project

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

12

K. Rouibah et al.

Figure 6.

Architecture of the interface between ProView and axalant.

that is managed by their PDM respectively. The project manager of the new project is nominated and the work breakdown structure is defined. This consists of splitting parts of the new product among the two partners. Users originating from different disciplines may participate in the product design. Each user may play different roles and take on different responsibilities. For example, a designer may be primarily in charge of decisions regarding a particular parameter value, but also be consulted about other parameter /component values that influence their decision. In Rouibah and Caskey (2003a), five roles were defined: the coordinator of a parameter is a person technically responsible for it and drives its elaboration or evolution. Collaborators are directly involved in the parameter elaboration, for example engineers from different partners working on the same interface parameter, but having a different view on it (e.g. people from mechanical and electrical departments). Reviewers includes all users that must be consulted about a parameter, but do not determine it, such as a production planner who must check whether a shaft with a certain length can be produced in-house or not. Subscribers can be persons wishing to be informed about the development of a certain parameter without being assigned to a category that works on it (e.g. a person from the marketing department). The supervisor is responsible for releasing a parameter. Users assuming the five roles and their privileges in charge of the parameter approach are appointed to the project within each partner. A design process starts when a supervisor instantiates a project container. The parameters of the project are

identified in ‘un-worked’ status. All these parameters must pass from un-worked to released status. Such upgrading is controlled by a workflow that involves seven activities. This process (see figure 7) could be easily generated with the help of ProView and executed by axalant at both sides. This workflow process shows the seven activities and their sequence. If the size of the process is too large, ProView does feature a navigator that helps users to visualize a sub-set of the process as well as the whole process. Such processes could also be altered or even extracted from a previous process if it exists previously. Moreover, the five roles appointed to initiate, approve, release, and modify the parameters can be easily assigned to this workflow. Since bills of material, product items, project items in PDM and workflow are combined, then it is possible to inform any role in case a modification takes place in any of these items. Different roles can be supplied with bids (preliminary information). Data are exchanged between roles across company borders until a consensus is reached. Such mechanism is described in more detail in (Rouibah and Caskey 2003b). The most important functions performed are the following. 1.

2.

The supervisor opens a session and requests collaborators to specify parameter values under their control. The collaborator selects a parameter, under his control, with status ‘un-worked’ and assigns a parameter range value (minimum and maximum).

13

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

Figure 7. Example of a scenario based on parameter approach.

3.

4.

The PDM system actively being worked upon, sets the parameter in status ‘in-work’, and generates automatic messages to coordinators in the engineering functions (both at companies A and B) and asks them to contribute to fix it (either to agree about its value or to request change). Once all involved roles agree on a value, communication between the two PDM takes place

according to the mechanism explained in this paper, then the parameter is promoted in status to ‘in approval’, and the PDM system generates messages to ‘reviewers’ and ‘subscribers’ from other business functions such as manufacturing and marketing who may express interest in the parameter. Product manufacturability could be the reason for participation of people from manufacturing department.

14

K. Rouibah et al.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

5.

6.

7.

8.

Once an agreement is reached among all five roles involved in the collaborative design, the PDM system compares different value ranges, generates the common consensus range value, and sets the parameter in status ‘in release’. The supervisor checks whether all the objections have been dealt with and taken into consideration, then he sets the parameter in status ‘released’. Once each parameter reaches this status it cannot be altered until a request of change is initiated. Changing customer specifications is a reason to initiate a request to alter a parameter value. In case there is a request for a parameter change after it has been frozen, the engineering change management module of the PDM system is used. An engineering change request is initiated and the supervisor requests collaborators and coordinators to study the request. In case it is accepted, the request is transformed into an engineering order, the parameter is set in status ‘in change’ and the PDM system sends an automatic message to all five roles including those in B. The same process is then re-iterated and the PDM system maintains versions of parameters under configuration management function. Users affected by such a change are identified in an ad-hoc manner, since they freely subscribed to these parameters, and they need to study the potential impact of the change on parameters under their control as well as possible document (under document management function), and other product items (under bill of material and classification functions). Each user will then create a list of affected parameters. A collective workflow process is then initiated for such a parameter, which is described elsewhere (Rouibah and Caskey 2003a).

4. Conclusion and perspectives This paper discussed the need to combine workflow and PDM. The main idea advocated in the paper is to achieve inter-company workflow coordination, ease inter-company engineering change management, facilitate system integration and ease configuration management. This is a promising area of research in the engineering field. The merge between workflow and PDM was preceded by the analysis of two well established standards: XPDL of the workflow management coalition and STEP. The first one was used to increase workflow integration and flexibility while the second one was used to achieve generic PDM design and to improve engineering change management. The main contributions of this paper are related to the workflow design and interoperability of PDM systems according to these two standards. Major

achievements fall in the application of existing workflow concepts rather than workflow design innovations as well as the improvement of other PDM components. In particular, these are related to: (a) the new entity ‘process’, used to manage administrative data of a workflow process such as the engineering change management, (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 system. The usage of STEP/ XPDL guarantees the open character of the developed interface. Enhancements undertaken have several benefits for companies willing to adopt PDM systems. 1.

2.

3.

4.

Engineering processes could be easily automated with the enhanced workflow leading to more benefits from the system. Engineering change management is improved and enables to track changes in a simple way allowing more and early communications between different designers involved in product development, and therefore will contribute to reducing the cost of engineering changes. Workflow module of PDM systems (e.g. axalant) is more flexible which allows easy modifications to combine tasks, modify and reuse processes, and rearrange resources allocation to tasks, and thus give users more flexibility to deal with ad-hoc changes that may occur in their business. The interface (STEP-based and later on XPDLbased) for the exchange of workflow definitions between axalant and ProView allows the exchange of predefined structured workflows as well as ad-hoc workflows.

XPDL was also used for the synchronization between different workflow engines located at different partners during inter-company collaboration. Designers can now define process templates graphically with higher capabilities compared to the sequential activities in the past, which allows reducing the complexity of current workflow processes. A notification service was implemented, that informs workflow participants about new work items which enables to ease intra and inter-company communication as well as engineering change management. This is useful for employees in collaborative design who do not have any PDM and would not learn that new work items had arrived. The enhanced PDM system can help to improve efficiency and quality of the work in companies with a lot of engineering effort and allows them to maintain close collaboration with suppliers, customers and engineering

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM

partners. Moreover, the merge of PDM and workflow is rather innovative and of interest for a community with a background in product development and product lifecycle management where a lot of costs can be reduced. Information system managers can also benefit from this paper since it calls for more attention to manage engineering changes in an intelligent manner in order to reduce the high cost associated with the frequent engineering changes. The approach presented here could be a starting point for a deep thinking on ways to reduce these costs. However, the paper should only be seen as the step towards combining PDM and workflow functionality in a comprehensive manner. The solutions provided should be considered in light of the four limitations. 1. 2.

3.

4.

The paper is very much focused on a specific commercial solution. The enhancement of axalant introduces several missing functions in current PDM technology but it does not solve issues such as security and dynamic sharing of design data. The paper focuses on workflow design based on the Interface 1 (XPDL-based) of the workflow management coalition and did not consider other perspectives of the workflow reference model. Even though XPDL has been promoted it has not been adopted by all workflow vendors and still does not produces satisfactory results but the number of those who comply is increasing. For example, in the assessment of existing standards, Aalst (2003) observed that some of workflow systems 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. During axalant improvement, strong focus was mainly on two standards.

To overcome the above limitations, this paper proposes to further investigate three research directions. First, it suggests continuing to explore the improvement of workflow and PDM in particular through exploration of a possible switch to web service. This paper stresses the need for PDM and workflow systems to comply with the two standards (XPDL oriented workflow and STEP oriented PDM). As indicated, XPDL is not satisfactory. As an alternative this paper encourages to investigate the web service paradigm that triggered the development of new and relevant standards. The functionality of web service composition languages (also referred to as ‘web service orchestration’) like Business Process Execution Language for Web Services (BPEL4WS), Web Services Flow Language (WSFL), and XLANG, which is very similar to traditional workflow languages. For example,

15

BPEL4WS is built on IBM’s WSFL 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. Wohed et al. (2003) provided more information about the evaluation of BPEL4WS, XLANG, and WSFL using the workflow patterns (Aalst et al. 2003). 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. Second, another research direction is related to the improvement of security within PLM system to support engineering collaborative process. Engineering collaboration that span company borders has become a must (Rouibah and Caskey 2005) Accordingly dynamic data sharing (Noel and Brissaud 2003) and security within distributed PDM system (Leong et al. 2003) are two challenges facing partners when collaboration takes place within a network. Since collaboration may involve competitors and require dynamic data sharing, how to grant data access and data modification based on the engineering change management process when the design involves suppliers and customers while leaving the data under their control? Third, experiences with the application of workflow management concepts in PDM show that development processes are much more dynamic and chaotic than traditional workflows encountered in banks, insurance companies, governments, etc. This puts high demands on making workflow management systems more flexible. Recently, improvements have been proposed and implemented to make workflow management systems more flexible (Rinderle et al. 2004). However, these improvements have not been realized in many commercial systems (FLOWer being one of the exceptions). Moreover, the nature of PDM will always be that people want and need to deviate from standard processes. Therefore, it is interesting to follow these deviations through process mining (Aalst et al. 2004). The goal of process mining is to extract models from audit trails of systems (e.g. PDM systems). These may be process models but also organizational models, social networks, decision models, etc. Moreover, process mining can be used to measure conformance. Process mining has shown its value in engineering-like processes with many deviations (Kindler et al. 2005) and is supported by mature tools such as ProM (Dongen et al. 2005).

16

K. Rouibah et al.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

References Aalst, W.M.P. van der, Business Process Management Demystified: A Tutorial on Models, Systems and Standards for Workflow Management. In Lectures on Concurrency and Petri Nets: Advances in Petri Nets. Lecture Notes in Computer Science, Vol. 3089, pp. 1–65, 2003 (SpringerVerlag: Berlin). Aalst, W.M.P. van der and Basten, T., Inheritance of workflows: an approach to tackling problems related to change. Theor. Comput. Sci., 2002, 270, 125–203. Aalst, W.M.P. van der, ter Hofstede, A.H.M., Kiepuszewski, B. and Barros, A.P., Workflow Patterns. Distrib. Parallel Dat, 2003, 14, 5–51. Aalst, W.M.P. van der, Weijters, A.J.M.M. and Maruster, L., Workflow mining: discovering process models from event logs. IEEE Trans. Knowledge Data Engng, 2004, 16, 1128–1142. Aalst, W.M.P. van der, Basten, T., Verbeek, H.M.W., Verkoulen, P.A.C. and Voorhoevem, M., Adaptive workflow: on the interplay between flexibility and support. In Enterprise Information Systems, edited by J. Filipe, pp. 61–68, 2000 (Kluwer Academic Publishers, Norwell). Abramovici, M. and Sieg, O.C., Status and development trends of product lifecycle management systems, 2002. Available online at: http://www. itm.rub.de/download/publikationen/Status_and_Development_Trends_ of_PLM.pdf (accessed May 2006). Agile 2006. www.agile.com Anonymous, Collaborative engineering through the supply chain. Strategic Direction, 2001, 17, 30–33. ARCweb 2006. www.arcweb.com. Blackburn, J.D., Time-based competition: white collar activities. Business Horizon, 1992, 35, 96–102. Boznak, R.G, Competitive product development, 1993 (Business One Irwin/ Quality Press, Milwaukee, WI). Choi, I., Park, C. and Lee, C., A transactional workflow model for engineering/ manufacturing processes. Int. J. Comput. Integr. Mfg, 2002, 15, 178–192. Christmas, A., CAD/CAM and PLM. Modern Machine Shop, 2001, 74, 110–112. Chu, X. and Fan, Y., Product data management based on web technology. Integr. Mfg Systems, 1999, 10, 84–88. CIMdata, Product Data Management: The Definition, An Introduction to Concepts, Benefits, and Terminology, 1998 (CIM-data). Available online at: www.cimdata.com. CIMdata 2006. www.CIMdata.com Clark, K.B. and Fujimoto, T., Product Development Performance: Strategy, Organization and Management in the World Auto Industry, 1991 (Harvard Business School Press: Cambridge, MA). Currie, W.L., Wang, X. and Weerakkody, V., Developing Web services using the Microsoft.Net platform: technical and business challenges. J. Enterprise Inf. Mgmt, 2004, 17, 335–350. Dongen, B.F. van, de Medeiros, A.K., Verbeek, H.M.W., Weijters, A.J.M.M. and van der Aalst, W.M.P., The ProM framework: A new era in process mining tool support. In Proceedings of the 26th International Conference on Applications and Theory of Petri Nets (ICATPN 2005), Lecture Notes in Computer Science, edited by G. Ciardo and P. Darondeau, Vol. 3536, pp. 444–454, 2005 (SpringerVerlag: Berlin). EDM, Engineering Data Management Newsletter, Benefits of EDM/PDM. Mfg Industries, 1999, 9, 1–6. EDM, Engineering Data Management Newsletter, UK. PDM Survey, 2000, 9, 6–10. Eynard, B., Gallet, T., Nowak, P. and Roucoules, L., UML based specifications of PDM product structure and workflow. Comput. Ind., 2004, 55, 301–316. Fischer, L. (editor), Workflow Handbook Workflow Management Coalition, 2003 (Future Strategies: Lighthouse Point, Florida).

Gao, J.X., Aziz, H., Maropoulos, P.G. and Cheung, W.M., Application of product data management technologies for enterprise integration. Int. J. Comput. Integr. Mfg, 2003, 16, 491–500. Georgakopoulos, D., Hornick, M. and Sheth, A., An overview of workflow management: from process modeling to workflow automation infrastructure. Distrib. Parallel Dat., 1995, 3, 119–153. Harris, S.B., Business strategy and the role of the engineering product data management: a literature review and summary of the emerging research questions. J. Engng Mf, Proc. IMechE, Part B, 1996, 210, 217–219. Hemeri, A. and Nihtila, J., Product data management exploratory study on the state-of-the-art in one-of-a-kind industry. Comput. Ind., 1998, 35, 195–206. IDS-SCHEER 2006. www.ids-scheer.com International Organization for Standardization, 2006, www.iso.ch Kempfer, L., PDM make the connection. Comput.-Aided Engng, 2000, 19, 26–30. Kim, Y., Kang, S., Lee, S. and Yoo, S., A distributed open intelligent product data management system. Int. J. Comput. Integr. Mfg, 2001, 14, 224–235. Kindler, E., Rubin, V. and Scha¨fer, W., Incremental workflow mining based on document versioning information. In Unifying the Software Process Spectrum: International Software Process Workshop, SPW 2005, edited by M. Li, B. Boehm and L.J. Osterweil, Revised Selected Papers, pp. 387–301, 2005 (Springer: New York). Kumar, R. and Midha, P.S., A QFD methodology for evaluating a company’s PDM requirements for collaborative product development. Ind. Mgmt Data Systems, 2004, 101, 126–132. Leong, K.K., Yu, K.M. and Lee, W.B., A security model for distributed product data management system. Comput. Ind., 2003, 50, 179–193. Littler, D., Leverick, F. and Bruce, M., Factors affecting the process of collaborative product development: a study of UK manufacturers of information and communications technology products. J. Prod. Innovation Mgmt, 1995, 12, 16–32. Liu, T. and Xu, X.W., A review of web-based product data management systems. Comput. Ind., 2001, 44, 251–262. Mansfield, T., An easy-to-implement PDM. Machine Des., 2002, 74, 84–85. Maull, R., Hughes, D. and Bennett, J., The role of the bill of materials as a CAD/CAM interface and the key importance of engineering change control. Comput. Control Eng. J., 1992, March, 63–70. Noel, F. and Brissaud, D., Dynamic data sharing in a collaborative design environment. Int. J. Comput. Integr. Mfg, 2003, 16, 546–556. Oh, Y., Han, S. and Suh, H., Mapping product structure between CAD and PDM systems using UML. Comput. Aided Des., 2001, 33, 521–529. Philpotts, M., An introduction to the concepts, benefits and terminology of product data management. Ind. Mmgt Data Systems, 1996, 96, 11–17. PISA 2006, www.pisa.de. Puschmann, T. and Alt, R., Enterprise application integration systems and architecture – the case of the Robert Bosch Group. J. Enterprise Inf. Mgmt, 2004, 17, 105–116. Rinderle, S., Reichert, M. and Dadam, P., Correctness criteria for dynamic changes in workflow systems: a survey. data and knowledge engineering. Special Issue on Advances in Bus. Proc. Mgmt, 2004, 50, 9–34. Rouibah, K. and Caskey, K., Change management in concurrent engineering from a parameter perspective. Comput. Ind., 2003a, 50, 15–34. Rouibah, K. and Caskey, K., An engineering workflow system for the management of inter-company engineering processes. J. Engng Des., 2003b, 14, 273–293. Rouibah, K. and Caskey, K, Managing concurrent engineering across company borders: a case study. Int. J. Comput. Integr. Mfg, 2005, 18, 509–521. Schmitz, B., Steelcase reduces new part generation with PDM. Comput.Aided Engng, 1999, 18, 8–9. Shapiro, R. A Comparison of XPDL, BPML and BPEL4WS (Version 1.4), 2002. http://xml.coverpages.org/Shapiro-XPDL.pdf.

Downloaded By: [Kuwait University] At: 12:35 26 June 2007

Combining workflow and PDM Sheth, A.P., Aalst, W.A. and Arpinar, I.B., 1999, Processes deriving the Networked economy. IEEE Concurrency, July–September 1999, pp. 2–15. Siddiqui, Q.A., Burns, N.D. and Backhouse, C.J., Implementing product management the first time. Int. J. Comput. Integr. Mfg, 2004, 17, 520–533. Smith, A., Empirical exploration for a product data management system at a major telecommunication firm. Ind. Mgmt Data Systems, 2004, 104, 513. Watts, F., Engineering changes: a case study. Prod. Inventory Mgmt J., 1984, 25, 55–62. Workflow Management Coalition, Workflow Process Definition InterfaceXML Process Definition Language, 2002, WfMC-TC-1025. Available online at: www.wfmc.org.

17

WfMC 2006, www.wfmc.org. Wognum, P.M. and Kerssens-van Drongelen, I.C., Process and Impact of Product Data Management implementation. Bremen, Germany, 2001. Wohed, P., van der Aalst, W.M.P., Dumas, M. and ter Hofstede, A.H.M., Analysis of Web Services Composition Languages: The Case of BPEL4WS. In 22nd International Conference on Conceptual Modeling. Lecture Notes in Computer Science, edited by I.Y. Song, S.W. Liddle, T.W. Ling and P. Scheuermann, Vol. 2813, pp. 200–215, 2003 (Springer Verlag; Berlin). Yeh, S. and You, C., STEP-based data schema for implementing product data management. Int. J. Comput. Integr. Mfg, 2002, 15, 1–17.