0 引言

    ERP业务架构平台层的主要目的之一在于为基于业务流程建模为导向的、以大规模系统化复用为指导思想的、以组件组装及框架代码生成为主要方式的多团队协同开发提供有效支持。
    W.M.P.van der Aalst（2001）认为[1]：当前的工作流系统通常假定每个工作项（WorkItem）是由单个的执行者（Worker）完成的，故不能对团队协同方式的工作项执行提供支持。文献[2]对支持团队开发的企业组织模型进行了研究，给出了包含组织纵向和横向结构的组织元模型，通过将组织规则和组织结构的分离，实现在组织结构不变的情况下，通过修改组织规则以达到提高企业敏捷性的目的；文献[3]针对工作流系统对动态团队和不确定任务支持的要求，利用面向对象建模团队的组织结构，采用OCL语言规范化描述团队内部结构约束和团队－任务约束，用来解决团队对应的工作流任务不确定问题；Action Technologies公司提供的Action workflow着重支持以员工和/或团队间通信为主的过程[4]；文献[5]进一步对基于工作流的ERP系统开发与实施方法进行了研究。
    本文认为，现有研究中在对团队工作流与行业版ERP构建相结合方面还很缺乏，在对协同任务内容描述与集成领域也需做进一步的研究。通过简单集成现有工作流管理系统和群件产品尚不能对行业版ERP研发中各种协同活动提供有效支持。研究发现，适用于行业版ERP构建业务平台的工作流管理具有一些新的特点和需求，表现在：
    （1）行业版ERP构建工作流是项目驱动的，ERP研发项目任务、核心工作流中任务流及活动流网络在任务内容上具有分层递进性。任务及活动的输入、输出中涉及对复用资产库及软件制品的配置管理。
    （2）在行业版ERP系统的构建过程中，既存在大量的非结构化的、自发的沟通与协同活动，也存在一些结构化的、有组织的管理与控制过程，并且这些性质各异的过程和活动往往交织在一起。因此，能够有效支持行业版ERP构建的工作流管理平台必须具有较好的适应性。
    （3）行业版ERP构建任务的执行者在更多情况下表现为一组相互协作的团队，如：可复用组件的获取（生产）团队、组件使用团队、面向行业领域工程的需求获取团队、系统测试团队等。在面向特定行业构建行业版ERP系统的过程中，需要这些团队在各自的任务领域具有很大的决策自主性，可以灵活设置局部工作流程，并且这些流程在团队整体协同过程中经常发生调整。
    （4）项目团队成员具有动态性和不确定性，如：特定成员可以同时担当多个角色，参与到几个不同团队中，而且在不同阶段还可能发生角色的转换。这使得在工作流定义阶段任务指派规则难以确定，而过于精确的定义则缺乏灵活性和可操作性。其次，将不同性质而又有关联关系的任务指派给不同的协作团队、团队成员等去执行，会带来很多需要解决的问题，如：人员分工、安全维护、多用户数据管理等。
    （5）除了对开发团队资源进行集成外，还要体现对各目标行业业务知识、企业（行业）模型及其他各类软件组件的重用的考虑，以便对目标行业族ERP系统的整个生命周期进行有效管理与控制。

    1 面向行业版ERP构建的工作流协同开发平台框架总体考虑

    （1）对集成项目管理功能的考虑
    在工作流管理中集成项目管理功能是可行的[6,7]。项目管理用于描述协同产品开发的任务结构及过程控制，工作流用于描述协同产品开发的业务流程；项目管理的目标是在一定的时间、成本、质量等约束条件下，保证项目的顺利完成，工作流管理则通过业务过程的自动化及监控保障各子任务得到及时处理；项目管理关注协同开发所涉及的工期、资源、进度、成本、质量等内容，各子任务具有明确的开始时间和结束时间，属于企业管理范畴，而工作流管理关注业务流程的建模及运行控制，属于过程自动化范畴。可见，二者的管理层次、关注点是不同的，具有互补性。通过项目管理与工作流管理的集成，可将项目中任务的内部过程"可视化"，即将具体的产品开发业务过程与特定的项目管理相联系，及时获取项目的进展情况，提高协同开发过程的管理水平和管理效率。项目管理与工作流管理的集成可克服工作流中缺乏对任务工期优化、成本控制及多工作流系统之间的相互协调等不足。
    （2）对集成软件配置管理功能的考虑
    软件配置管理[8]（Software Configuration Management，SCM）是指一套按规则管理软件开发和维护其中各种中间软件产品的方法，它研究怎样在不同时刻标识软件系统的配置，以便系统化地控制配置的变化，以及在整个软件生命周期内维护配置的完整性和可追溯性，主要包括配置识别、变化控制、状态记录报告以及审计等4种活动。现有的软件配置管理支持平台，通常提供版本控制、项目管理、成员权限控制、BUG追踪、邮件列表等功能[9,10]，这些功能满足了项目开发的基本需要的最小子集，但功能之间呈现离散状态，相互之间缺乏有机融合。而借助工作流技术中的"流程路由"则可以有机整合这些离散的功能集，表现在软件开发过程支持上，就是可以实现集成的配置管理。同样地，可实现对复用库的集成管理。
    （3）对团队协同开发支持的考虑
    可通过综合多种途径实现对团队协同开发活动的支持：○1集成项目管理工具，实现对开发任务的分解，分解的结果体现为各开发团队（如：组件生产团队、行业ERP构建团队、管理团队）提供任务列表及关联约束信息；○2在工作流建模元模型层次，提供用于团队建模的支持元素，如：融入组织建模的相关概念（部门、团队、人员、角色等）、支持流程定义的逐步求精等；○3融入主流群件产品及工具，如：即时通讯工具、Email、BBS等，支持开发人员之间的消息发布与及时沟通。

    2 面向行业版ERP构建的工作流协同开发平台框架

    基于以上分析，现提出基于工作流的协同开发环境体系结构，见图1。

图1 基于工作流的协同开发环境体系结构

    该协同开发环境体系结构以工作流建模与执行为核心，完全兼容工作流联盟给出的通用工作流产品结构[10]。通过扩展工作流定义工具的能力，提供协同建模管理器以支持对多团队、分布式、逐步求精的建模方式；通过软件总线整合其他协同开发的相关平台工具，主要有：项目管理工具、复用库管理工具、配置管理工具、外部应用、群件系统等，从而对基于软件资产复用方式的、以多团队协同方式构建行业版ERP系统提供全面的支持。面向行业版ERP构建的工作流协同开发平台框架主要涉及两项关键技术，包括：支持多团队协同开发的工作流建模技术，工作流管理与项目管理、软件配置管理的集成技术。

    2.1 支持多团队协同开发的工作流建模
    通过在现有的工作流建模工具进行扩展，融入对团队等基本建模元素的支持，可以弥补传统工作流管理系统对团队协同建模支持能力的不足。在文献[2,3]的基础上，现给出支持团队协同开发的工作流建模元素的静态结构模型，如图2。这里进一步给出相关的主要概念：
   

图2 支持协同开发的工作流建模元素的静态结构

    定义1 团队（Team）：为完成一项共同任务而建立的组织单元，该组织单元可以是临时性的、虚拟的，当任务结束后团队解体；也可以是永久性的，此时可类似于传统企业中的功能性组织部门。团队具有类型，通常具有职位结构，团队通常由多个团队成员组成，团队中的特定成员可以同时参加多个团队组织，从而可支持矩阵型组织类型。
    定义2 团队类型（TeamType）：是角色概念在团队层次上的扩展，描述团队使命、特征等意义上的分类。如：对行业版ERP构建组织而言，典型的团队类型有组件获取团队、行业版ERP系统开发团队、系统测试团队等。
    定义3 团队职位（TeamPos）：对团队内职位需求的描述。对特定类型团队而言，通常具有不同的职位结构，特定职位上需要的人员配置数量上也会有差异。如：对组件获取团队，通常会设置领域及行业工程顾问、需求获取工程师、组件封装与测试工程师，每一类职位需要的人数配置需求等。传统意义上的角色可看作是只包含一个职位的团队类型。
    定义4 任务（Task）：一个工作逻辑单元，通常任务是不可分割且必须完整执行。如果在任务执行期间发生任何错误，则必须采用"回滚"以保证任务的原子性。任务的不可分割性依赖于任务定义的环境。任务有手动、自动和半自动任务之分。
    为了满足分布式、分层次建模的需要，这里按照是否对目标任务进一步细化需要，把任务进一步分为原子任务（AtomicTask）和复合任务（ComplexTask）。复合任务是一类子任务的集合，可由原子任务和其它的复合任务构成。
    为解决多成员协同建模问题，文献[11]提出一种基于"条件分层有向图"的工作流模型。在该模型中，有向图中的节点可以表示活动节点、连接节点或子流程，有向图中的有向边表示节点间的依赖关系，整个工作流模型表示为一个层次网状有向图。由图2可知，这里建立的工作流建模元素的静态结构同样可支持这种层次网状图的工作流模型的建立。
    定义5 案例（Case）：指一项具体业务。如：下采购订单、入库等。每个案例都有一个唯一标识，有自己的生命周期，有一系列状态。
    定义6 工作项（WorkItem）：是案例（Case）和将要执行的任务的结合体。也可把工作项看作是被执行的实际工作块。活动（Activity）是工作项的实际执行。工作项和活动都与具体案例有关。
    定义7 工作流（workflow）：对业务过程的描述，工作流由任务和条件组成。工作流定义了案例的所有可能的执行路线，所有可能的状态，从而定义了案例的生命周期。
    2.2 工作流管理与项目管理、软件配置管理的集成
    （1）集成层次
    面向行业版ERP开发强调的是多团队协同工作方式。项目管理体现了软件开发的过程组织特点，软件系统是抽象的逻辑产品，软件的开发、维护、版本的升级等基本上都具有很强的项目性特点，可通过项目管理工具对行业版ERP构建及可复用资产的提取及维护任务进行任务分解。另外，在产品研发及可复用组件获取、分析、评价、封装、测试等不同阶段，不同子项目之间需要传递大量信息。如何根据各种业务流程来组织和控制行业版ERP产品构建或可复用资产获取等的高效运行便是工作流的研究重点，而在软件开发及组件开发的整个生命周期各阶段中的各业务流程中各项子任务的执行，都会涉及各类组件（制品）的创建、组装、访问及其各中间制品版本的记录与维护，而这正是软件配置管理关注的重点。鉴于此，本文在文献[6]的基础上，提出一种面向行业版ERP构建过程管理的层次模式，见图3。
    图3中，项目层位于协同开发过程的最高抽象层次，它直接服务与系统产品开发与实施的总目标；子项目层处于基于子项目任务集的群体协同工作方式的逻辑结构层，它从组织上保证产品协同开发的敏捷性和并行性；宏观业务流程层是从全局角度对子项目及项目过程组织的抽象与建模，面向协作群体的业务过程组织；微观活动序列层从细粒度上（如：特定开发团队）对局部流程进一步求精。整个协同产品开发过程管理由上层的项目管理和下层的工作流所组成，项目管理主要完成项目的"宏观过程"管理，工作流管理层主要完成"微观过程"的管理。软件配置管理活动则覆盖整个软件生命周期的各阶段，与项目管理层和工作流管理层都有联系。实际上，在各层次上都可引入工作流管理技术与工具，从而实现以工作流为中心的集成的管理与开发模式。
   

图3 面向团队协同的行业版ERP构建过程的层次管理模式

    同时，这种层次型管理模式，实现了软件开发的项目规划、应用逻辑和过程逻辑的分离，从而可以在不变更项目目标或内容的前提下而只需修改任务模型即可改变项目的执行流程，提高了过程管理的柔性。

    （2）集成框架
    通过以上分析，现进一步提出一个集成项目管理、工作流管理和配置管理的集成框架，如图4。

图4 项目管理、工作流管理与配置管理的集成框架

    这里采用共享数据库的方式实现信息集成，其功能集成则通过任务执行调度组件及与外部应用的接口组件实现。任务调度组件既是项目管理中任务流的执行引擎，同时又是工作流系统中的流程执行调度组件，项目管理与工作流管理的集成是通过任务执行调度中间模块接口及对调度规则知识、工作流执行相关数据、工作流模型库中流程定义等信息的共享实现的；工作流管理与软件配置管理的集成是通过在工作流流程定义阶段建立各种配置和变更管理工作流[9]，并加入对各类配置管理对象的任务描述，这样，在任务执行阶段，相关配置管理任务项在工作流引擎的控制下被路由到相关管理及开发人员，进而在与外部应用接口组件的支持下，以自动或手工方式激活相关外部应用的工作界面以实施配置管理活动或访问外部复用库，进而根据执行后的状态更新工作流相关数据，从而实现工作流管理与配置管理的集成。
    （3）集成的实现途径
    上述讨论可知，这里采用共享数据库的方式实现项目管理、工作流管理与软件配置管理的集成。基于数据库的信息集成不仅可以为集成对象提供方便、快捷、高效的数据调用，而且易于保证数据的一致性。图5进一步给出了主要数据库表及其关系。
   

图5 基于数据库的项目管理、工作流管理与软件配置管理的集成机理

    通过在项目管理数据库的任务表中引入任务执行条件，在相应的工作流定义表及流程路由规则表中可建立对项目任务相关信息的参照关系；在工作流执行阶段，通过跟踪确认所定义的工作流中各任务的实际执行时间信息、所处状态、执行异常情况等，可实现对项目进度的监控。另外，通过在工作表单（Form）模型中加入配置管理的需求信息、配置管理对象（如各类目标软件制品）信息、相关的外部系统模块及接口信息等，这样，在相应的外部应用接口组件的支持下，可实现与配置管理平台工具或复用库管理工具的集成。而且，借助工作流管理系统，可改善现有配置管理平台对流程管理能力的不足，真正实现基于流程的配置管理策略，能够保证针对特定配置工作流只有特定人员才能访问到特定资产。
    这里实现集成的关键是对任务模型和工作表单模型的设计。任务是项目管理层次的一个基本操作单位，同时又是工作流管理层次上对工作流定义的重要依据；工作表单既是工作流中实现基于文档协同的主要媒介，也是传递配置管理需求、外系统模块及接口描述信息的重要数据结构，是进一步基于外部应用接口组件实现与外部平台工具（如配置管理平台工具、复用库管理系统平台）集成的关键。
    根据系统集成管理的要求，这里把任务属性进一步分为基本属性、控制属性和上下文属性等三类属性。常见的基本属性有任务名称、任务标识、任务目标、任务类型（如原子任务、复合任务）、任务编号、任务优先级等；任务控制属性，如：执行者、执行者角色、时间信息（计划周期、计划开工时间、计划完工时间、实际开工时间、实际完工时间等）；任务上下文属性，如：所属项目、输入信息、输出信息、所需资源、应用软件、过程规则等。控制属性用于描述项目管理系统所涉及的参数等上层项目管理所必须的一些基本信息；任务上下文属性描述工作流定义时所需要的相关参数，如：任务隶属的项目名称及类型、任务执行所需的各类资源、任务执行所需的各种应用软件、任务路由决策的过程规则等。过程规则用于指导建立工作流模型中的任务路由路径空间，涉及的资源分配、信息流向、组织角色选择、操作信息对象等组成工作流的基本要素。

    3 结束语

    行业化是ERP发展的重要研究方向之一，行业版ERP的研发对于解决目前商品化ERP产品本身及ERP实施过程中存在的诸多问题提供了一个新途径。ERP的自身特点决定了行业版ERP系统的构建过程是一个多群体的协同过程。本文建立了一个面向行业版ERP构建的、以工作流管理系统为核心的、集成项目管理和软件配置管理的、支持多团队协同开发的平台框架，并对该框架的关键技术进行了深入研究，希望能对行业版ERP构建研究起到一定的借鉴作用。

    参考文献
    [1] W．M．P． van der Aalst，A．Kumar．A reference model for team-enabled workflow management systems[J]．Data & Knowledge Engineering, 2001,38: 335-363
    [2] 朱海平，李培根，张国军，等．支持团队工作的工作流技术研究[J]．计算机集成制造系统-CIMS，2003，9(8): 635~640
    [3] 杨东，张申生，江志斌．基于UML OCL、支持团队开发的企业组织元模型[J]．高技术通讯，2004，6:60~64
    [4] Wil van der Aalst , Kees van Hee．工作流管理--模型、方法和系统[M]．北京：清华大学出版社，2004．
    [5] 黄双喜，范玉顺．基于工作流的ERP系统开发与实施[J]，计算机集成制造系统－CIMS，2004，10（2）：139-143
    [6] 孔建寿，张友良，汪惠芬，等．协同开发环境中项目管理与工作流管理的集成[J]．中国机械工程，2003，14（13）：1122－1127
    [7] 彭毅，吴柞宝，张珂殊，等.并行工程产品开发过程的建模方法学[J].系统仿真学报，1996，8(3):14-18
    [8] Anne Mette，Jonassen Hass．Configuration Management Principles and Practice[M]. Addison Wesley Professional，2003
    [9] Brian A．White．Software Configuration Management Strategies and Rational Clearcase [M]．Addison Wesley Publishing，2000
    [10] David Hollingsworth．The workflow Reference Model(Issue 1.1)．workflow Management Coalition，Document Number TC00-1003.
    [11] LI Feng, GUO Yuchai, LIN Shouxun, etal. Dynamic modification in workflow prototype system--AWFlow. In: Proceedings of 4th International Workshop on CSCW in Design. Compiegne, France :111-114