工作流管理工具工作流管理( 二 ) _工作流

因此，所导致的过程模型或者过于简单或者过于复杂和非透明。针对以上原因，近年来一些学者提出了所谓的事例处理系统(case- ) ，倡导一个根本性的思想转变:工作流的驱动不是通过预先确定的路径，而是应该通过事例。传统的工作流管理技术侧重于在一个工作流过程中“应该做什么” ，而事例处理技术则侧重于为了取得业务目标“可以做什么” 。作为一种新的工作流管理方法，事例处理技术为支持灵活的、知识密集的业务过程提供了新的可能性。事实上，事例处理原则的应用已经在荷兰一家名为海杰曼斯的大型建设公司的一些项目中获得了巨大的成功。简单而言，事例是工作流过程的一个实例，是工作流参与人员所需处理的对象。在工程建设领域，事例可以是一个具体的设计变更过程、一个具体的工程索赔过程以及一个具体的招标采购过程等。如果将事例看作是通过执行工作流过程所制造的产品(建设管理过程的产品是信息) ，则真正驱动工作流过程的是产品的特征。通过关注产品的特征，可以将传统的面向“推”的路径(从一个工作夹到另一个工作夹) 转变为面向“拉”的机制(以关于一个事例的数据对象为中心)。为了进一步说明基于事例处理的工作流管理方法，通过统一建模语言(UML) 提出其相应的对象模型(图2) 。
3、基于事例处理的工程项目工作流管理的过程定义对于基于事例处理的工程项目工作流管理而言，同样需要进行过程定义。传统的建设过程被认为是彼此分裂，在没有应用信息系统时，信息呈孤立状态，形成了“信息孤岛”;在信息系统应用后形成了一定的工作流;但是还需要应用过程管理思想对信息系统的工作流进行集成和优化，即在利用流程再造(BPR)工具进行业务过程重组和优化的基础上描述工程项目工作流的过程逻辑。过程定义所产生的过程模型是整个工作流管理系统的基础。许多工作流管理系统的开发平台均提供可视化的过程建模工具，使得用户能够以直观的方式对实际的业务过程进行建模，而且所建立的过程模型可以直接得到系统的支持。过程建模的方法有活动网络图、有向图、( IDEF3) 以及Petri网等等，其中的Petri网过程建模方法近年来最为学术界所重视[5 ， 6 ]。以下采用简化Petri 网模型对任务管理过程予以建模。在一般性的任务管理过程中，团队领导首先要求团队的某个成员完成一个任务。该团队成员基于自身能力和各种约束条件检查任务要求，然后发送一个答复给团队领导。如果该团队成员认为无法完成该任务，则团队领导需要物色其他合适的团队成员。如果该团队成员确认有能力完成该任务，则团队领导对任务进行详细描述，并将其发送给该团队成员。当该团队成员对任务的详细描述不理解时，他可以提出询问，直到该任务被理解并被实施。对于团队成员所提交的任务结果，团队领导将其与原来的任务状况说明相比较。如果认可，则提交工作成果。否则，团队领导将任务重新退回给该团队成员(图3) 。
4、基于事例处理的工作流管理系统的体系结构通过上节的分析，图4给出了基于事例处理的工作流管理系统的体系结构，该体系结构与工作流管理联盟所提出的参考模型基本一致[7] 。系统的逻辑设计包括过程定义、用户的角色分配、数据处理设计、表单定义、事例的授权与分配等方面。工作流执行服务中的工作流引擎是整个系统的核心，主要负责工作流过程实例的执行、事例活动的状态控制、用户事例列表的维护以及对外部资源的访问等工作。管理监控工具对运行过程中过程实例的状态进行监控与管理。工作流引擎通过代理，可以访问过程数据、用户信息和文档信息等数据库资源。客户端应用程序为用户提供一种手段，以处理过程实例运行过程中需要人工干预的任务。而被调用的应用程序是指工作流执行服务在过程实例的运行过程中所调用并对应用数据进行处理的外部应用程序(比如文档管理模块)。图中的几个WAPI () 依赖于确定的开发平台。根据该体系结构，可以通过Lotus / Notes 中的Flow2 Mark 工作流开发平台来予以实施。

工作流管理工具 工作流管理( 二 )

工作流管理工具工作流管理( 二 )