an innovative framework of collaborative-based workflow in development chain management

Computers & Industrial Engineering 60 (2011) 845–862

Contents lists available at ScienceDirect

Computers & Industrial Engineering

journal homepage: www.elsevier .com/ locate/caie

An innovative framework of collaborative-based workflow in DevelopmentChain Management

Yuan-Ping Luh ⇑Institute of Manufacturing Technology, National Taipei University of Technology, Taipei 106, Taiwan, ROC

a r t i c l e i n f o a b s t r a c t

Article history:Received 28 November 2006Received in revised form 31 March 2010Accepted 25 January 2011Available online 1 February 2011

Keywords:CollaborationWorkflowProduct development

0360-8352/$ - see front matter � 2011 Elsevier Ltd. Adoi:10.1016/j.cie.2011.01.013

⇑ Tel.: +886 2 2771 2171x2088; fax: +886 2 27317E-mail address: [email protected].

Currently, most product development procedures have been characterized as unnecessarily complicated.To maintain a competitive edge and to simplify the procedures, joint efforts from different functionalgroups play such crucial role. Specifically, information from marketing, sales, engineering, sourcing,and manufacturing should be cross-referenced. In addition, adopting pre-defined workflows contributesto efficient collection of distributed information. Moreover, unlike traditional workflow, a collaborative-based workflow (CWF) in product development process boasts of complicated workflow forms with man-ifold views for a workflow execution. Traditional workflow solutions, for instance, can only transmit aworkflow form through different actors. Such workflow solutions merely offer modeling approval-basedworkflow (AWF), such as drawing reviews or absence applications.

This paper illustrates the framework of CWF solution and proposes its application in the model work-flow of a distributed product development system. This framework includes four interrelated modules.They are KM4, AS API, SmartForm, and Workflow Engine. In addition, four visual assistant modeling toolsare introduced and they are Data Designer, AppDefinition, Layout Designer, and CWF Builder. To fulfill thevaried business requirements, Data Designer, AppDefinition, and Layout Designer attempt to achieve adynamic and efficient construction of complicated workflow forms in collaborative workflow solution.Other workflow-related setups, such as defining status diagrams, correspondence persons, and applica-tory workflow forms, are accomplished in CWF Builder. The major contribution of this paper lies in theproposing of a framework for CWF and in the introducing of visual tools for CWF modeling. Comparedto the traditional hard-coding method, the construction time for CWF system can be reduced significantlywith the assistance of modeling tool. Time reduction on developing information systems, in this regard, isa very important issue for most modern industries. The concept in this paper can direct a global enter-prise to efficiently construct workflow management system for global collaboration.

� 2011 Elsevier Ltd. All rights reserved.

1. Introduction

Local development of marketing specialists has been limited byour market size and education system. Despite this systematicinadequacy, the engineering education in Taiwan has been suc-cessful in strengthening product design and development capabil-ities. Because of this particular development, Taiwan has a high-level of commitment to the product design and developmentsegments.

To maintain this competitive edge, companies in Taiwan need asystem to better execute their development capabilities. Specifi-cally, network should be well-connected to enable the exchangeof such information as marketing, sales, engineering, sourcing,and manufacturing. In addition, to gain a competitive edge in theglobal industry, it is common for companies to distribute their

ll rights reserved.

191.

development personnel in various locations. However, the dis-tances among these locations pose many serious communicationproblems.

In addition to the communication problem, heterogeneous dataintegration poses another threat to distributed product develop-ment operations. Different data management functions and solu-tion infrastructures may be needed to respond to differentorganization structure. Moreover, combining product data fromdifferent locations over the Internet is also a challenge.

To enhance communication efficiency, an innovative solution ofcollaborative-based workflow (CWF) is introduced. The key challengeof CWF solution lies in its deviations of different views for collabo-rators. To investigate the suitability of current workflow solutionsfor such requirement, previous studies on workflow are reviewedin Section 2. After literature review, the incompatibility betweenCWF concept and current workflow solutions is explained in Sec-tion 3. Furthermore, a new product development application is alsointroduced to illustrate the concept of actual CWF in Section 3.

http://dx.doi.org/10.1016/j.cie.2011.01.013

mailto:[email protected]

http://dx.doi.org/10.1016/j.cie.2011.01.013

http://www.sciencedirect.com/science/journal/03608352

http://www.elsevier.com/locate/caie

Fig. 1. Business process, collaborative-based workflow, and approval-basedworkflow.

846 Y.-P. Luh / Computers & Industrial Engineering 60 (2011) 845–862

According to the discussions in Section 2 through Section 3, toimprove CWF construction efficiency, an innovative framework ofCWF solution is introduced, and assistant modeling tools are devel-oped. Section 4 is dedicated to stating the architectural concepts ofmodeling CWF. In Sections 5–6, the assistant tools for CWF model-ing are illustrated. The procedure for constructing CWF system bythese tools is also outlined by modeling the new product develop-ment application in Section 3.

2. Previous studies on workflow

Workflow control is important for a competitive product lifecy-cle management. As mentioned by Stark (2005), well-controlledoverall product workflow contributes to the reduction of leadtimes, increased qualities, as well as decreased costs. Differentsolutions to workflow management have been developed to ensurea well-controlled workflow. A workflow management system(WFMS) is a software system that defines workflow models, gener-ates workflow instances, and monitors workflow operations(Lawrence, 1997; WfMC, 1995). The basic ingredients of a work-flow model are workflow form (user interface of reference dataand input fields) and routing (workflow sequence and applicatoryworkflow forms). Most workflow-related literatures (Bae et al.,2004; Kradolfer, 2000; Ngai, Cheng, & Lee, 2003; Liu, Zhang, &Hu, 2005) regard the terminology of ‘‘process’’ as a part ofworkflow. In these literatures, the workflow model is treated as aprocess model associated with organization (or actor group) con-cept. Basically, most studies related to WFMS have investigatedon workflow control innovation. However, few studies discussthe database structure for workflow form data storage. This isbecause of the identical database structure for most WFMS. Formost WFMS, the data values of workflow form are simply recordedin one database table with field names mapping to the form fields,and one record in this table represents the form data of one work-flow instance.

On the other hand, some literatures (e.g. Kobayashi, Tamaki, &Komoda, 2003; Ulrich & Eppinger, 2003) utilize process model todescribe the framework of product development and supply chainoperations. McGrath (2004) states the next generation of productmanagement is driven by information technology. Such manage-ment systems are named Development Chain Management (DCM)systems. It is clear that the meaning of the ‘‘process model’’ inWFMS differs to that in DCM. Currently, most WFMS studies haveaddressed small scaled workflow management, such as review con-trols and document revision controls. This kind of workflow issuesdo not require complicated information to make decisions. How-ever, the workflow solution used in a distributed concurrent engi-neering environment requires substantial deviations of differentviews for collaborators. Hence, for DCM workflow, complicateddata structure with multiple database tables is utilized to store dataof workflow forms in general. Rouibah and Caskey (2003) presentthe benefits, distinctiveness, and challenge of workflow solutionsused in a distributed concurrent engineering environment.

In summary, traditional WFMS solutions can not fully supportthe workflow requirements used in DCM. In DCM, the workflowsolution used in a distributed concurrent engineering environ-ment, named CWF, requires substantial deviations of differentviews for collaborators. Currently, few studies have been done onconstructing workflow solutions for DCM. Without a proper CWFframework, the DCM concept can not be accomplished.

3. The concept of collaborative-based workflow

Most literatures merely indicate ‘‘work order’’ when it comes toprocess and workflow and they do not specify the differencesbetween the latter two concepts. Given the lack of appropriate

methodologies, it is very difficult to manage processes or work-flows in different scales by the same techniques. For example,the complexity in the management of new product developmentprocess is very different from that of an absence applicationworkflow. Therefore, to propose the CWF framework, someterminologies used in the DCM, such as ‘‘process’’ and ‘‘workflow’’,have to be clarified in advance.

3.1. Overview

In this paper, the terminologies of business process (BP), collabo-rative-based workflow (CWF), and approval-based workflow (AWF)are defined to clarify three different management issues relatedto ‘‘process’’ and ‘‘workflow’’. In this paper, both process and work-flow contain organizational concept, and therefore, unlike most lit-eratures’ opinion in Section 2, ‘‘whether executable or not’’ is notthe key factor to tell the differences between process and work-flow. Alternatively, this paper utilizes ‘‘model’’ or ‘‘template’’ to de-scribe the definitions of a process or a workflow, and ‘‘instance’’ todescribe the execution activities of a process or a workflow.

3.2. Characteristics of BP, CWF, and AWF

To clarify these three terms, Fig. 1 shows the concepts of BP,CWF, and AWF, and describes the relationship among them asfollows:

As shown in Fig. 1, these three terms are closely related. To clar-ify these three terms, new product development is a good example.To develop new products by project teams, most companies maydefine their own suitable BPs in advance. The main characteristicof BP is that a BP consists of multiple phases. For example, theBP for generic product development consists of planning, conceptdevelopment, system-level design, detail design, testing andrefinement, and production ramp-up (Ulrich & Eppinger, 2003).To complete each phase, many tasks should be accomplished con-currently or consecutively. Furthermore, a phase gate (i.e. mile-stone) has to be defined to represent the completeness of each

Y.-P. Luh / Computers & Industrial Engineering 60 (2011) 845–862 847

BP phase. It is noteworthy that in real practice, many tasks are exe-cuted concurrently to shorten the process time. Moreover, no se-quence restriction among tasks should be considered by BPdefinition. For example, the tasks of a phase may be initialed priorto the task ‘‘final phase review’’ of previous phase due to projecttime limitations. Furthermore, in most cases, the starting time ofindividual task is identical to the corresponding phase initial time,and the necessary (but not sufficient) condition to start individualphase is the accomplishments of all the required tasks (but not alltasks in the previous phase), which are utilized to define phasegate in the previous phase.

Even though no sequence restriction is defined by BP, in a busi-ness process, certain consecutive relationship may be among sometasks in the same phase or different phases. Many consecutive rela-tionships in a business process can be defined according to require-ments of content control or schedule control in general. As shownin Fig. 1, sequence among Task #1.4 in Phase #1, Task #2.2 in Phase#2, and Task #3.1 in Phase #3 is defined. Such sequence can be uti-lized to form a workflow. This kind of workflow is named CWF inthis paper.

There are two types of CWF, one is schedule controlled and theother is content controlled. For schedule controlled workflow man-agement, only starting time and finishing time of individual taskare planned and monitored. But for content controlled workflowmanagement, the real challenge is in transferring content fromone task to the other tasks and keeping content in uniform andconsistency. It is noteworthy that in real practice, the required con-tent in each task is closely related yet each of which varies dramat-ically in most cases. The paper mainly focuses upon the contentcontrolled CWF.

To better explicate CWF concept, the Engineering Change (EC)process is introduced that includes four different forms, namedEngineering Change Proposal (ECP) form, Engineering Change Re-quest (ECR) form, ECO (Engineering Change Order) form, and ECN(Engineering Change Notice) form. Detailed description on EC pro-cess can be explored in much literature (e.g. Stark (2005)). As sta-ted by Saaksvuori & Immonen, 2004, EC management is closelyrelated to workflow. Moreover, due to the system limitations, mostEC practices currently focus only on approval, comment, inspec-tion, or notification, but not collaboration. Such solution may besufficient for small scaled companies. However, for global and dis-tributed enterprises, EC process should be jointly accomplished bysuch specialists as inventory manager, financial officer, designengineer, and customer service specialist around the world. More-over, the essence of such EC practice is collaborative communica-tion in truth. In real practice, different mission and extensiveinformation must be cross-referenced in each task. In addition,each specialist requires significant different information to finishhis own obligation. Therefore, for EC practice, it is not feasible bymerely unifying all data fields to a single data source without sig-nificant view difference. To support EC collaboration, other thantraditional workflow solution, the collaborative-based workflowsolution is required. The key challenge of CWF solution lies inthe substantial deviations of different views for collaborators.

In developing new products, workers with more experiences areusually assigned to ensure the correctness and fitness of task out-comes. Other than CWF, such quality assurance activities are clas-sified into AWF concept in this paper. The key feature of AWF lieson transmitting a workflow form with slight changes through dif-ferent actors. That is, different actors may have different authori-ties to execute workflow functions, edit form fields, or view forminformation. As shown in Fig. 1, Task #3.2 is accomplished bydefining a three-step specified workflow, which is named AWFfor its ‘‘approval-based’’ functionality. In real practice, AWF aimsto control outcome quality and is best explicated by the approvalof technical documents and drawings. In most product data

management (PDM) systems, revision control is one of the mostfundamental functions. However, revision control cannot informauditors to actively check technical documents and drawings.Assisted by AWF, auditors can receive notifications right aftermanipulations, and can then begin to approve, comment, andinspect related documents and drawings.

Based on previous explanation, it is clear that CWF and AWF aredifferent in many aspects. Similar to the functions of ‘‘collabora-tive’’ and ‘‘approval’’, CWF combines different tasks to collaboratein sequence, and AWF approves task outcome in sequence beforeits issuance. In most cases, workers in different CWF steps have dif-ferent professionals, and workers in AWF steps have identical pro-fessionals of varying scales. Put shortly, different workflow formsthat represent task outcomes should be designed for different pro-fessionals. In real industrial operations, the modeling of EC uponAWF may generate arguments among professionals and even dis-organize business operations. For example, in most companies,financial executives may reject direct manipulation of the ECP bydesign engineers. However, it is not professionally justifiable forthese financial experts to decline such engineering efforts. In orderto better execute cross-division management, information shouldbe gathered from different divisions, and then final decisions couldbe made by one authorized personnel.

3.3. Practice of collaborative workflow

Previous discussion clarifies the concepts of BP, CWF, and AWFand describes the relationship among them. To help readers betterunderstand the complicatedness of a CWF, an example of thedevelopment collaboration in new product development processis illustrated. Fig. 2 shows analysis results of relatives of workflowstatuses, named status diagram, for mechanical design and samplerequest collaboration:

In Fig. 2, the entire 11 statuses and 12 workflow functions aresketched. The status diagram describes the collaborative activitiesand status change relations on mechanical drawing and sample re-quest between development team and factory.

When on different statuses, additional forms have to be de-signed for other users to obtain relative feedback data, whose con-struction requires consulting efforts on identifying all the requireddata. Figs. 3 and 4 show partial analysis results of sample workflowforms for mechanical design and sample request collaboration:

Fig. 3 illustrates a proposed form, named Mechanical DrawingReview Form, which is utilized by developers in combination withMechanical Submitted status (see Fig. 2). In Mechanical DrawingReview Form, two workflow functions, named Reject and Approve,are provided. As shown in Fig. 3, this form is divided into three re-gions, named Header Information, reference data, and mechanicaldrawing. Many hyperlinks to other references, which are the re-sults from the previous stage of new product development processon marketing and design collaborations, are shown in referencedata region. These hyperlinks include Control Drawings, RenderingDrawing, Product Introduction Calendar, ID Confirm 3D ModelFiles, and Sketching Drawings. In Mechanical Drawing Region,two data operators, named View and Discussion Board, are usedto review and comment on the related mechanical drawings.

Fig. 4 demonstrates a form, named Sample Request Initial Form,which is utilized by developers in combination with the activatedMechanical Approved status (see Fig. 2). In this form, one workflowfunction, named Create SRF, is provided. As shown in Fig. 4, SampleRequest Initial Form is divided into five regions, named HeaderInformation, Engineering BOM, Cost BOM, Style Setup Sheet, andDrawing Packages. Developers can better prepare sample requestsby providing related BOM information and cost information fordifferent modules, and by manipulating Style Setup Sheet. Other

Fig. 2. Status diagram of collaboration.


references for preparing Sample Request Initial Form are providedin Drawing Packages region.

The example shows that significant changed workflow forms areapplied for different workflow statuses. It is noteworthy that in aCWF, the data source behind distinct workflow forms for differentstatuses is identical. For CWF solution, along with unifying all datafields to a single data source, substantial deviations of different userinterfaces (i.e. workflow forms) for collaborators must be offered.On the contrary, the key feature of AWF lies on transmitting a work-flow form only with slight changes through different actors.

3.4. Discussions on variations

A workflow template (for AWF or CWF concept) is comprised ofdefinitions of steps (or tasks), flow rules between steps (or tasks),and views (i.e. workflow forms) for different steps (or tasks). Un-like workflow template, a process template (for BP concept) doesnot define execution sequence as does by flow control rule inworkflow template. The elements in a BP include definitions ofphases, phase gates, tasks, and task outcomes. Moreover, the taskexecution sequence in a BP is described by defining multiple CWFs.The advantage of isolating CWF from BP lies in the reduction ofmodeling complexities.

Parallel and sequential tasks are two common practices in manybusiness operations, such as development chain collaboration.Solutions on solving parallel and sequential tasks at a time havebeen proposed by some scholars (e.g. Bae & Kim, 2002). Most stud-ies follow traditional AWF concept to achieve workflow instanceexecution by means of intricate control engines. On the contrary,this paper introduces BP and CWF concepts, other than AWF con-cept, to fit the operational requirements. Obviously, adjustmentson such workflow control engine are not the key issue for handlingcomplicate development chain collaboration on business becauseof the different natures of AWF and CWF. Many tasks in a businessoperation require promptness or spontaneity without any se-quence restriction and have difficulty in being modeled by work-flow-based solutions. In addition, even though traditional AWFsolutions are sufficient for such workflow like drawing reviews

or absence applications; however, many other business operations,such as product development collaboration, require manifoldviews for executing a CWF instance.

4. Innovative framework of collaborative workflow solutions

To accomplish a customized CWF template instantaneously,this paper introduces an innovative framework of CWF. In thisframework, the dynamic and efficient construction of distinctworkflow forms on an identical data source is essential. As men-tioned in Section 2, for most current WFMS, the data values ofworkflow form are simply recorded in one database table with fieldnames mapping to the workflow form fields. Moreover, one recordin this table represents the form data of one workflow instance.Even though this kind of data structure is appropriate for AWF;however, such data structure is not suitable for CWF. In a CWFtemplate, different workflow forms with significant view differ-ence are assigned to different steps. Even though they are differentforms outwardly; however, the inside data among these forms aretightly correlated. Therefore, the workflow form modeling in CWFis most likely of constructing an information system.

Currently, the favorite architecture for information system con-struction is the three-tier architecture. The three-tier architectureseparates a system into data layer, business layer, and presentationlayer. Similarly, in this paper, to model complicated workflowforms in a CWF, the mechanism e-forms that follows the three-tierarchitecture to generate distinct workflow forms on an identicaldata source is introduced. The framework of CWF is shown inFig. 5 as follows. It is noteworthy that the purpose of separatinga system into three-tiers is to produce multiple views for one datasource more straightforward.

As shown in Fig. 5, this framework includes four major modulesand one supportive module. The four major modules are Smart-Form, AS API, KM4, and Workflow Engine, and the supportive mod-ule is System Administrator. The major CWF template setups, suchas defining status diagrams, correspondence persons, and applica-tory workflow forms, are accomplished in Workflow Engine. Themodules of SmartForm, AS API, and KM4 are the software programs

: :

:

:

:

:

:

Fig. 3. Mechanical design review form.


in the e-forms mechanism to achieve a dynamic and efficient con-struction of complicated workflow forms in CWF template. SystemAdministrator module manages fundamental information of usersand user groups, which would be the correspondence persons inCWF template.

After understanding the positions of different modules in CWFframework, in the succeeding sections, discussions are concen-trated on the improvement of CWF template construction by theassistant tools for modeling workflow forms and defining work-flow routing. Nevertheless, the development details of those mod-eling tools are not explored in this paper.

5. Assistant modeling tools in the e-forms mechanism

To accomplish a customized CWF template instantaneously, thedynamic and efficient construction of workflow forms is essential.The dynamics points to the distribution of different views to differ-ent organization groups when jointly operating a CWF. Achievingefficiency requires minimum customized programming effortsand assistant tools to construct workflow forms. Therefore, assis-tant modeling tools for complicated data integration are integralfor CWF template.

To improve the efficiency of workflow form generation by the e-forms mechanism, three assistant modeling tools for different lay-ers were developed, as shown in Fig. 6:

The purpose of separating a system into three-tiers is to pro-duce multiple views for one data source more straightforward, asmentioned in Section 4. Fig. 6 shows that the assistant tools fordata layer, business layer, and presentation layer are Data Designer,AppDefinition, and Layout Designer, respectively. The ingredients ofthese three modules are described as follows. The data definitionand transformation between each level are defined in differentmodeling tool. In each level, the modeling tool can visually assistworkflow form designers to key in requisite parameters. It is note-worthy that the intention of developing such assistant tools is toprovide common environment for different professionals whiledoing requirement analysis (RA), system analysis (SA), and systemdesign (SD). The output of RA is the input of SA and the output ofSA is the input of SD. Traditionally, the formats of RA, SA, and SDoutputs are not the same. Such format inconsistence may causeserious communication gaps among system clients, business con-sultants, and system designers.

5.1. Data layer: Data Designer

For most information systems, database design is very compli-cated and is the major task for data layer. To design a database,the comprehensive review on data requirement of a system isneeded. Currently, the most popular database type of an informa-tion system is the relational database. In addition, the E-R model

Fig. 4. Sample Request Initial Form.


Fig. 5. CWF framework.

Fig. 6. Three-tier architecture of e-forms mechanism.


is the best way for system designers to describe the data model ofsuch information system. The details of relational database designand E-R model can be reviewed in most database related textbooks(e.g. Post, 2002; Watson, 2002). Even though most system design-ers and programmers can draw E-R model straightforwardly; how-ever, the E-R model is too difficult for persons such as businessconsultants and system clients. It is noteworthy that to make surethe compatibility of requirements and design results, a businessconsultant must be capable to reveal E-R diagrams. Hence, to elim-inate such difficulty, an innovative data modeling scheme named‘‘Triangle’’ is introduced.

The fundamental scheme of KM4 kernel is Triangle. As shown inFig. 7, there are four Triangle types: Complex Triangle, Simple Tri-angle, Relation Triangle, and Application Structure (AS) Triangle. Itis noteworthy that an AS Triangle represents the data structure ofan information system in the innovative framework.

The association properties utilized by the Triangle model in-clude Hierarchy, Inheritance, Pointer, and Template/Instance.These properties are described as follows.

(Should specify the ‘‘origin’’ of the following descriptions: bywhom and from what books).

� Hierarchy: Data Hierarchy refers to the systematic organizationof data in a hierarchical form. It is an arrangement of data con-sisting of sets and subsets such that every subset of a set is of alower rank than the set. This can be translated to a parent–childrelationship. Complex Triangle shown in Fig. 7 contains Hierar-chy properties.

� Inheritance: Data Inheritance is defined as a relationship amongclasses, wherein one class shares the structure or behaviordefined in one (single inheritance) or more (multiple inheri-tance) classes. Inheritance defines an ‘‘is-a’’ hierarchy amongclasses in which a subclass inherits from one or more general-ized super classes; a subclass typically specializes its super

classes by augmenting or redefining existing structure andbehavior. Complex Triangle shown in Fig. 7 contains Inheritanceproperties.� Pointer: A Pointer is a variable that holds the address of another

variable or the address of a core storage location. It can be iden-tified as the object ID and Name. The pointer can be used topoint to data both internally and externally, where data isdefined as an attribute or collection of attributes (i.e. layer ofTriangle). Both Simple Triangle and Relation Triangle shown inFig. 7 contain Pointers properties.� Template/Instance: A Template/Instance applies a set of template

arguments to a template name, creating a specific function orclass. Each template argument is matched with a templateparameter; arguments can be explicit, or they can be deducedfor a function template or supplied by default arguments for aclass template. All Triangle types (Complex, Simple, Relation,and Application Structure) have Template/Instance properties.It is noteworthy that an individual Triangle may consist of onlyone, or any number of combinations of the above properties. Forexample, Complex Triangle shown in Fig. 7 contains both Hier-archy and Inheritance properties.

A Triangle is a data modeling scheme intended to realize high-level business concepts. The main purpose of proposing KM4 is toconvert traditional relational ‘‘E-R model’’ into object-oriented‘‘Triangle model’’. Specifically, KM4 enables a data model to be de-scribed by the unique object-oriented way during system analysisand system design. Fig. 8 shows a comparison example of the Tri-angle model and the E-R model. It shows that for the identicalinformation system, the data model expressed by the Trianglemodel is much clearer than by the E-R model. Such advantage ofthe Triangle model can assist experts such as business consultantto make sure the compatibility of system requirements and systemdesign results easier.

To provide visual support for Triangle model construction, theassistant tool ‘‘Data Designer’’ is developed, as shown in Fig. 9:

The background mechanism of Data Designer is KM4. With vi-sual assistant of Data Designer, Triangle models can be constructedeasier, and communication gaps among system clients, businessconsultants, and system designers can be eliminated. In Data De-signer, the name of an AS Triangle is assigned, and the relatedparameters are also defined. To constructing workflow forms fora CWF template, an applicatory AS Triangle can be defined by refer-ring the name of AS Triangle in the modeling tool of business layer.

In summary, a Triangle model represents the data entities andthe relationships between them. Each Triangle is a set of complexdata that has both internal and external relations with other trian-gles. The advantages of modeling logical data model by Trianglemodels include:

� Each level in a Triangle represents an entity and is directlymapped to a database table.� It provides sophisticated object-relational (OR) mapping tool for

optimization.� When properties of an entity are modified, effects to other enti-

ties can be easily identified. It will result in a more dynamic andstable system.

5.2. Business Layer: AppDefinition

To operate a relational database, database programmers mustdefine database operations by Structural Query Language (SQL).The details of SQL manipulation can be reviewed in most databaserelated textbooks (e.g. Post, 2002; Watson, 2002). To manipulate aSQL statement, the data structure must be recognized in advance.However, for a database with numerous tables, typing errors may

Fig. 7. Triangle model (a) complex (b) simple (c) relation (d) application structure.


be occurred; and such errors may diminish the system develop-ment efficiency. The abovementioned difficulty can be reducedby the assistants of visual tools. In the proposed framework, App-Definition in business layer can assist database programmers visu-ally to manipulate SQL statements. The applicatory data structurefor constructing SQL statements is defined in Data Designer.Fig. 10 shows sample interfaces of AppDefinition:

In AppDefinition, AS API is developed for modeling workflowforms of CWFs. To model application operations, multiple and cor-related mechanisms with pooled inputs and outputs are defined inAppDefinition. The mechanisms used in CWFs are mostly related todata manipulation. In AppDefinition, related mechanisms in datamanipulation, include data query, addition, modification and dele-tion, and are written by AS Application Programming Interface

(API). Such database programs can be defined prior to model work-flow forms. Therefore, no extra program codes will be written toexpress data manipulation during design-time of CWFs.

It is noteworthy that it is not possible to manipulate suchdatabase codes in advance without separating database structurefrom SQL. As mentioned in the previous section, applicatorydatabase structure can be modeled by an AS Triangle. The nameof AS Triangle can be referred by AppDefinition for workflowform construction.

In the innovative framework, for an AS Triangle, the correspond-ing class library, named AS API, is designed to replace SQL state-ment in pre-defined program codes. The object classes in AS APIinclude ‘‘appStructureDAO,’’ ‘‘CacheEBox,’’ and ‘‘QueryParam.’’In brief, database programmers can construct an object

Fig. 8. Data modeling (a) by triangle model (b) by E-R model.


Fig. 9. Sample page of data designer.


‘‘appStructureDAO’’ to define database operations of query, addi-tion, modification, and deletion. Objects ‘‘CacheEBox’’ are utilizedto store database operation results for further utilizations. In con-trast, objects ‘‘QueryParam’’ are used to manipulate conditions ofdatabase operations. The functions associated with objects‘‘appStructureDAO’’ are ‘‘query(),’’ ‘‘insert(),’’ ‘‘delete(),’’ and‘‘update()’’. The functions associated with objects ‘‘QueryParam’’are ‘‘addValue()’’ and ‘‘setOperator().’’ The comparison of codeswritten by AS API and SQL is illustrated in detail by Lin (2006).Lin (2006) showed that database programmers can easily and obvi-ously write codes by the assistance of AS kernel (combination of ASTriangle and AS API). Such pre-defined database operations, namedApplication Structure (AS) code, can be translated to SQL state-ments by AppDefinition automatically. In AppDefinition, the nameof an AS is assigned, and the related parameters are also defined. Toconstructing workflow forms for a CWF template, an applicatory AScan be defined by referring the AS name in the modeling tool ofpresentation layer.

5.3. Presentation layer: Layout Designer

The basic way to build a web page is Hypertext Markup Lan-guage (HTML). Currently, many visual assistant tools, such asFrontPage and Dreamweaver, have been invented to build HTMLpages. However, such HTML-based web page is static. To build adynamic web page, additional database programs are required.

In the proposed framework, Layout Designer in presentationlayer can assist page programmers visually to build web page lay-outs with additional support on visual selections of database oper-ations. As mentioned in Section 5.2, database operations can bepre-defined by AS codes; and applicatory database structure of aCWF template can be modeled by AS Triangles. With Layout De-signer, substantial deviations of different workflow forms forCWF operations can be produced visually. Different forms on topof an AS Triangle can be created by different page layouts withproper pre-defined AS codes. Fig. 11 shows a sample interface ofLayout Designer:

The background mechanism of Layout Designer is SmartForm.In Layout Designer, a web page consists of many containers, com-ponents, fields, and parameters. Layout Designer with SmartFormkernel provides page programmers with the capability to create aworkflow form layout more quickly and efficiently. Additionally,with the help of KM4 and AS kernel, it is easy to extract and manip-ulate data from different database tables on a single workflowform—a capability vital to the usage of complicated data in CWFs.It is noteworthy that field values in a page can be determined byvarious ways. For example, the database operation results withoperation variables from certain field values may be assigned tothe other fields. Furthermore, a field value may be the computa-tional result of other field values from the same page or otherpages. Such elucidation can be defined by a set of field parametersin Layout Designer.

A workflow form generated by SmartForm can be operated aspart of a workflow. Different users can sign in and work on thesame workflow through different workflow forms of varyingbehaviors in accordance with workflow status and user’s authori-zation. Topics related to workflow status and user’s authorizationwill be discussed in Sections 6.

To illustrate the capabilities of Layout Designer, Fig. 12 shows alayout example:

This layout example consists of three container instances,named container #t1, #f1, and #t2. In Layout Designer, there aretwo kinds of containers, one is Table Container and the other isFlow Container. Components in Flow Containers will be displayedon a page in sequence, whereas components in Table Containerswill be displayed on a page arranged by a pre-defined table format(row number and column number). In Fig. 4, Containers #t1 and#t2 are containers of Table Container type, whereas Container#f1 is container of Flow Container type.

As shown in Fig. 12, different SmartForm components areembedded in different containers. For example, container #t1 con-sists of two components: one Form Component and one ImageComponent. A component denotes any number of reusableelements in the user interfaces (UIs). Some good examples are

Fig. 10. Sample pages of AppDefinition.


Fig. 11. Sample page of layout designer.

Fig. 12. Concept of layout designer.



Table, Image, Button, and Textbox. There are also many otheradvanced SmartForm components, such as Form component,Checkin-Checkout component, Tab component, and XY Trackingcomponent, which is designed for constructing forms. Fig. 13shows Table component and XY Tracking component for readers’reference.

To control the behavior of components and fields, parametersare utilized and defined in Layout Designer. Different containers,components, and fields require different sets of parameter to func-tion properly. This paper mainly focuses upon the framework ofCWF template construction; and hence, only logics of parameterassignment of generic importance are given here.

There are two basic types of parameters to be defined in LayoutDesigner for web presentation. The first type determines whatbusiness data should be displayed in web pages, and the secondtype describes data format as shown in web pages. As previouslymentioned, the presentation layer of a workflow form is designedto connect to business layer directly. Therefore, correspondingparameters of AS operations must be assigned. Assisted by AS ker-nel with proper AS parameters, business data can be retrieved cor-rectly from databases to web pages, which are then inserted intodatabases.

In Layout Designer, the name of a form is assigned, and the re-lated parameters are also defined. Some simple format controls,such as number of column displayed, boarder width, or cell spac-ing, can be directly assigned by a number. More complicated

Fig. 13. Example of SmartForm comp

format controls can be pre-defined in style sheets and then as-signed by corresponding parameters in Layout Designer. To con-structing a CWF template, applicatory workflow forms can bedefined by referring the form names in the CWF modeling tool.

6. Assistant modeling tools for workflow routing

The basic ingredients of a workflow model are form and routing.In Section 5, the assistant modeling tools for workflow form con-struction are illustrated. This section introduces the assistant toolCWF Builder for workflow routing setups. CWF Builder provides vi-sual assistant for defining status diagrams, correspondence per-sons, and applicatory workflow forms.

6.1. Status diagram modeling

CWF Builder provides visual assistant for defining status dia-grams. Fig. 14 shows the status diagram modeling of sampleCWF based on Fig. 2 by CWF Builder:

In CWF Builder, a status diagram is modeled by the definition ofstatus, status type, function, and function type. Status type is usedto control selected status that is either activated or not based onincoming events. Function type is used to describe status changeby executing selected function. Some conceptual representationsof status diagram are shown in Fig. 15:

onents (a) table (b) XY Tracking.

Fig. 14. Status diagram modeling.

Fig. 15. Concept of status diagram.


In Fig. 15, the circle objects represent different statuses and thearrows represent directions of status changes. It is noteworthy thatstatus changes are driven by functions. Case (a) in Fig. 15 showsthe simplest condition of status change. In this case, arrows #a1,#a2, and #a3 can be used to represent workflow functions of ‘‘ap-proval’’, ‘‘decline’’, and ‘‘amendment’’, respectively. It is notewor-thy that a function is not always represented by single arrow. Allthe status types and function types assigned in case (a) are named‘‘Sequence’’.

Other than sequence type, cases of different function types canalso be defined. For example, both cases (b) and (c) in Fig. 15 rep-resent the similar conditions of single-to-multiple status changes.In these two cases, function #f1 contains arrows #a1 and #a2.The difference between these two cases is on the functional rulebetween arrows #a1 and #a2, and is defined by function type offunction #f1. Case (b) holds ‘‘or’’ rule and case (c) holds ‘‘and’’ rule.Case (b), whose status #s2 or #s3 is activated, is selected by re-sponder of status #s1 at run-time. In case (c), both statuses areactivated while workflow function #f1 is executed. The functiontypes of function #f1 in cases (b) and (c) are named ‘‘ExclusiveChoice’’ and ‘‘Parallel Split’’.

In addition to sequence type, many other status types can beapplied in different situations. Given the similarity between cases(d) and (e) in Fig. 15 in their status diagrams, the difference be-tween these two cases lies in the activating rules of status #s3.,which is modeled by status type of status #s3. In disregard of itsactivated or non-activated status, case (d) is determined by re-sponder’s choice of status #s3 at run-time. Automatically acti-vated, status #3 in case (e) follows executing both arrows #a1

and #a2. The status types of status #s3 in cases (d) and (e) arenamed ‘‘Exclusive Choice’’ and ‘‘Simple Merge.’’

Abovementioned workflow control mechanisms are supportedby Workflow Engine. At CWF run-time, Workflow Engine controlsthe status changes induced by workflow function executions. Inaddition, for each status, the correspondence person andapplicatory workflow form are assigned in CWF Builder at CWFdesign-time. Consequently, Workflow Engine can also notify thecorrespondence persons to finish the right workflow forms atCWF run-time.

6.2. Authorities of workflow form for different views

At design-time, a workflow form may be assigned to associatemultiple statuses of a status diagram. However, such assignmentdoes not specify which functional group will take care of whichpart of business data in this workflow form. Therefore, organiza-tional concept is introduced here to illustrate authority setup ofCWFs. The fundamental concept of authority setup is: for differentstatuses, different functional groups are assigned to take differentviews and operations on top of a workflow form.

As mentioned in the previous section, many SmartForm compo-nents are designed to construct workflow forms for CWFs. There-fore, it is reasonable that authorities be assigned to eachcomponent and each field. Fig. 16 shows the authorization matrixutilized to define different form views for different organizationgroups at different statuses:

In Fig. 16, the x-direction shows different organization groups,and the y-direction lists different components, fields, and

Fig. 16. Authority setup.


corresponding data operators. By selecting a status, authorities canbe applied to either Smart Form components or individual datafields. In Tab, image, or Button component, only data operator‘‘View’’ can be assigned. Moreover, in Form component andindividual field, data operators ‘‘View’’ and ‘‘Edit’’ can be selected.Further, in Table component, Data operators ‘‘View’’, ‘‘Edit’’,‘‘Insert’’, and ‘‘Delete’’ can only be selected. This authority setupcan be used to construct multiple views of a workflow form tofulfill the requirement of CWF in terms of its ‘‘dynamic’’ and‘‘efficient’’ way to construct a workflow form, as mentioned inSection 3.

Referring to Fig. 14, with authority setup, Figs. 17 and 18 dem-onstrate the sample workflow forms for developers at ‘‘New’’ sta-tus and ‘‘Mechanical Approved’’ status, respectively:

Fig. 17 presents only one tab named ‘‘Mechanical Drawing.’’.However, Fig. 18 illustrates a total of four tabs and shows that nomodification authority is granted on those fields in MechanicalDrawing tab. As shown in these instances, it is clear that multipleworkflow forms can be configured with significant differences, andmultiple views of a workflow form can be further defined. Suchcapability is very important for controlling collaborative activitiesamong value chain partners.

7. Discussion and conclusions

The major contribution of this paper is to present an innova-tive framework and to introduce assistant tools for CWF model-ing. As for product development application, a simple exampleneeds to be modeled so as to illustrate practical requirements.For most small scaled companies, development data may be

manipulated by one or two persons, and no collaborative issuesare involved. Hence, CWF may be too complicated, and AWF solu-tion is good enough for such companies. However, for most globalenterprises, CWF is so important to build a collaborative platformfor different specialists around the world. Such requirements can-not be fulfilled by traditional workflow solutions with simpleworkflow form.

In terms of software technology, the main difference betweenCWF and AWF lies in the complexity of workflow forms. For CWFsolution, along with unifying all data fields to a single data source,substantial deviations of different user interfaces (i.e. workflowforms) for collaborators must be offered. Besides, to accomplish acustomized CWF template instantaneously, the dynamic and effi-cient construction of workflow forms is essential. The dynamicspoints to the distribution of different views to different organiza-tion groups when jointly operating a CWF. Achieving efficiency re-quires minimum customized programming efforts and assistanttools to construct a workflow form. Therefore, assistant modelingtools for complicated data integration are integral in an innovativeframework for CWF template. The intention of developing suchassistant tools is to provide common environment for differentprofessionals while doing requirement analysis (RA), system anal-ysis (SA), and system design (SD).

This paper illustrates the procedure to construct complicatedworkflow forms in a CWF by visual tools (Data Designer, AppDefi-nition, and Layout Designer) with software kernels (KM4, AS API,and SmartForm). In KM4, an innovative data modeling schemenamed ‘‘Triangle’’ is introduced. The Triangle model can eliminatecommunication gaps among system clients, business consultants,and system designers. With Data Designer, Triangle models can

Fig. 17. Page view for developers at ‘‘New’’ status.


be constructed easier, and communication gaps among systemclients, business consultants, and system designers can be elimi-nated. With AppDefinition, by separating database structure from

Fig. 18. Page views for developers at

SQL and by applying AS API, database programmers can manipu-late database programs in prior to model workflow forms morereliable and easier. Consequently, substantial deviations of

‘‘Mechanical Approved’’ status.

Fig. 18 (continued)


workflow forms for CWF operations can be visually constructed inLayout Designer. Such practice fulfills the CWF requirements of‘‘dynamic’’ and ‘‘efficiency’’ in the construction of a workflow formwith minimum programming efforts.

Besides workflow form construction, this paper also illustratesthe procedure to setup workflow routing by visual tool CWFBuilder with software kernel Workflow Engine. With CWF Builder,status diagram, correspondence persons, and applicatory workflowforms can be visually accomplished without programming.

This paper shows, by adopting modeling tools, system admin-istrators can configure the workflow forms of a CWF in a moredynamic and efficient manner. Compared to the traditionalhard-coding method, the construction time for CWF system canbe significantly reduced with the assistance of modeling tool.Time reduction in developing information systems is graduallygaining interests among researchers in most modern and upcom-ing discoveries on industries. The value of modeling architecturein this paper lies in developing CWF management systems whichfacilitate efficient product development and overcome the obscu-

rities from next generation. When applied globally, this conceptcan help construct a workflow management system in achievingfuture collaboration.

Acknowledgements

This research is partially sponsored by National Science Council(NSC94-2213-E-027-034), R.O.C. The author is deeply indebted tomembers of the R&D Department from OLE Technology, for theirconstant assistance and support.

References

Bae, H., Hu, W., Yoo, W. S., Kwak, B. K., Kim, Y., & Park, Y.-T. (2004). Documentconfiguration control processes captured in a workflow. Computers in Industry,53(2), 117–131.

Bae, H., & Kim, Y. (2002). A document-process association model for workflowmanagement. Computers in Industry, 47(2), 139–154.

Kobayashi, T., Tamaki, M., & Komoda, N. (2003). Business process integration as asolution to the implementation of supply chain management systems.Information and Management, 40(8), 769–780.


Kradolfer, M. (2000). A workflow metamodel supporting dynamic, reuse-basedmodel evolution. Ph.D. thesis. Switzerland: University of Zurich.

Lawrence, P. (1997). Workflow handbook. New York: Wiley.Lin, S.-J. (2006). An e-system development architecture based on application

structure. Master thesis. Taipei, Taiwan: National Taipei University ofTechnology (In Chinese).

Liu, J., Zhang, S., & Hu, J. (2005). A case study of an inter-enterprise workflow-supported supply chain management system. Information and Management,42(3), 441–454.

McGrath, M. E. (2004). Next generation product development: How to increaseproductivity, cut costs, and reduce cycle times. New York: McGraw-Hill.

Ngai, E. W. T., Cheng, T. C. E., & Lee, C. M. Y. (2003). Development of a web-basedsystem for supporting sales in a mineral water manufacturing firm: A casestudy. International Journal of Production Economics, 83, 153–167.

Post, G. V. (2002). Database management systems (2nd ed.). New York: McGraw-Hill.Rouibah, K., & Caskey, K. (2003). A workflow system for the management of inter-

company collaborative engineering processes. Journal of Engineering Design,14(3), 273–293.

Saaksvuori, A., & Immonen, A. (2004). Product lifecycle management (2nd ed). Berlin:Springer-Verlag.

Stark, J. (2005). Product lifecycle management 21st century paradigm for productrealisation. London: Springer-Verlag.

Ulrich, K. T., & Eppinger, S. D. (2003). Product design and development (3rd ed). NewYork: McGraw-Hill.

Watson, R. T. (2002). Data management: Database and organizations (3rd ed.). NewYork: John Wiley & Sons.

WfMC, Workflow management Coalition (1995). Workflow reference model.<http://www.wfmc.org>.

Glossary

Collaborative-based workflow (CWF): A WFMS in a distributed concurrent engi-neering environment that can link different professionals to collaborate insequence

Workflow management system (WFMS): A software system that defines workflowmodels, generates workflow instances, and monitors workflow operations

Workflow form: A user interface that presents reference data and input fields forworkflow operations

Routing: The definition of workflow control rules, such as workflow sequence andapplicatory workflow forms

Development Chain Management (DCM) system: A software system that managesproduct development activities throughout cooperative corporations andbusiness units

Business process (BP): A description that defines phases, phase gates, and tasks forcompleting a routine business operations

Approval-based workflow (AWF): A WFMS that can notify supervisors to verify andapprove outcomes in sequence

Schedule controlled CWF: A WFMS that plan and monitor starting time and finishingtime of individual task

Content controlled CWF: A WFMS that transfer content from one task to the othertasks and keeping content in uniform and consistency

Status diagram: The graphical representation of workflow sequence which definesrelatives of workflow statuses

e-Forms: A mechanism that combines data from one or multiple database tables togenerate distinct workflow forms

KM4: A software kernel that provides functions for modeling metadata of anapplication

Triangle model: A graphical representation that illustrate data model and datarelations

Application structure (AS): A way of describing operational logics of an application.AS defines the data structure and database operations applied to a userinterface

AS API: A software kernel that provides application programming interface (API)functions for programming operational logics of an application

SmartForm: A software kernel that provides utilities for constructing user interfacesof an application

Workflow Engine: A software kernel that provides control mechanisms for workflowoperations.

Data Designer: A visual software tool designed to assist workflow form designersdescribe metadata of an application

AppDefinition: A visual software tool designed to help workflow form designersdefine operational logics of an application

Layout Designer: A visual software tool designed to assist workflow form designersconstruct user interfaces of an application

CWF Builder: A visual software tool designed to assist workflow modelers drawstatus diagram and assign user authorities for a CWF

http://www.wfmc.org

an innovative framework of collaborative-based workflow in development chain management

Documents