基于事例处理的工程项目工作流管理(1)

　　1、工作流管理系统

　　为了实施对业务过程的工作流管理，需要相应软件系统的支撑，这种软件系统可称为工作流管理系统。工作流管理系统的定义是：“工作流管理系统是一个软件系统，它完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。”

　　一般而言，工作流管理系统应包含如图1所示的三个组成部分： ①定义建模；②运行控制；③运行交互。

　　传统工作流管理系统的运作原理如下：相应的工作流过程定义对每个新的事例予以实例化，即为每个事例创建一个新的工作流实例。基于相应的工作流过程定义，工作流引擎计算对于该事例应Ji活哪些活动。 针对每个被Ji活的活动，将生成一个工作项并放入每个具有相应角色的用户的“工作夹”。 用户从其工作夹中选择工作项，并开始执行相应的活动等。尽管一个工作项可以出现在多个用户的工作夹中，但只有一个用户执行相应的活动。 当一个工作项被选中后，工作流管理系统将启动相关的应用程序并监控相应活动的执行结果。需要指出，用户只能看到在其工作夹中的工作项，并且当选择一个工作项时也只能获知与执行相应活动有关的信息[2～4 ] 。

　　2、基于事例处理的工程项目工作流管理的概念

　　工程项目可以看作是一项任务，有许多过程和活动构成，但与制造业等工业部门不同的是，工程建设过程具有高度的复杂性，而这种复杂性又可以在总体上分为弱结构化和变动性两个方面。正如同大约90%的工程建设信息是非结构化的文档信息，工程建设中绝大多数处理过程属于非结构化或弱结构化的工作过程。 对于这些非结构化或弱结构化过程的支持，根本无法采用传统的工作流管理技术。同时，工程建设领域也存在一些诸如设计变更、工程索赔以及招标采购等具备较高结构化程度的管理过程。这些管理过程尽管数量较少，但具有相当的重要性，有研究指出85 %的建设问题和过程有关而和产品没有太大关系，因此如何实现工程建设过程的管理工作流自动化仍然有着重要的意义。 但必须注意到，由于这些管理工作流具有一定程度的变动性，严重依赖于固定的事先过程定义的传统工作流管理技术，无法对其提供有效的支持。事实上，许多研究人员都指出：由于缺乏灵活性，传统的工作流管理技术在工程实践中经常以失败告终。

　　传统的工作流管理技术之所以缺乏灵活性，其关键原因在于路径是驱动工作流的唯一机制，即工作是基于预先固定的因果关系从一个工作夹流转到另一个工作夹。因此，所导致的过程模型或者过于简单或者过于复杂和非透明。 针对以上原因，近年来一些学者提出了所谓的事例处理系统（case－handling system），倡导一个根本性的思想转变：工作流的驱动不是通过预先确定的路径，而是应该通过事例。传统的工作流管理技术侧重于在一个工作流过程中“应该做什么”，而事例处理技术则侧重于为了取得业务目标“可以做什么”。作为一种新的工作流管理方法，事例处理技术为支持灵活的、知识密集的业务过程提供了新的可能性。事实上，事例处理原则的应用已经在荷兰一家名为海杰曼斯的大型建设公司的一些项目中获得了巨大的成功。

　　简单而言，事例是工作流过程的一个实例，是工作流参与人员所需处理的对象。 在工程建设领域，事例可以是一个具体的设计变更过程、一个具体的工程索赔过程以及一个具体的招标采购过程等。如果将事例看作是通过执行工作流过程所制造的产品（建设管理过程的产品是信息），则真正驱动工作流过程的是产品的特征。 通过关注产品的特征，可以将传统的面向“推”的路径（从一个工作夹到另一个工作夹） 转变为面向“拉”的机制（以关于一个事例的数据对象为中心） .为了进一步说明基于事例处理的工作流管理方法，通过统一建模语言（uml） 提出其相应的对象模型（图2）。

　　3、基于事例处理的工程项目工作流管理的过程定义

　　对于基于事例处理的工程项目工作流管理而言，同样需要进行过程定义。 传统的建设过程被认为是彼此分裂，在没有应用信息系统时，信息呈孤立状态，形成了“信息孤岛”；在信息系统应用后形成了一定的工作流；但是还需要应用过程管理思想对信息系统的工作流进行集成和优化，即在利用流程再造（bpr）工具进行业务过程重组和优化的基础上描述工程项目工作流的过程逻辑。过程定义所产生的过程模型是整个工作流管理系统的基础。许多工作流管理系统的开发平台均提供可视化的过程建模工具，使得用户能够以直观的方式对实际的业务过程进行建模，而且所建立的过程模型可以直接得到系统的支持。过程建模的方法有活动网络图、有向图、integration definition method（ idef3） 以及petri网等等，其中的petri网过程建模方法近年来最为学术界所重视[5 ，6 ] .

　　以下采用简化petri 网模型对任务管理过程予以建模。 在一般性的任务管理过程中，团队领导首先要求团队的某个成员完成一个任务。该团队成员基于自身能力和各种约束条件检查任务要求，然后发送一个答复给团队领导。如果该团队成员认为无法完成该任务，则团队领导需要物色其他合适的团队成员。如果该团队成员确认有能力完成该任务，则团队领导对任务进行详细描述，并将其发送给该团队成员。当该团队成员对任务的详细描述不理解时，他可以提出询问，直到该任务被理解并被实施。对于团队成员所提交的任务结果，团队领导将其与原来的任务状况说明相比较。如果认可，则提交工作成果。否则，团队领导将任务重新退回给该团队成员（图3）。

共2页: 1