工作流的基本知识

什么是工作流管理系统（WFMS）

 

定义

工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。为了后面的描述，我们先定义一些基本的 术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。 都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和 工具之间主要的分歧。

为什么应当禁止使用术语“活动（activity）”...

 

流程定义通常用一些活动表述。我认为这是导致工作流领域所有混乱的主要原因。我告诉你为什么：因为术语“活动”混淆了状态（state）和动作 （action）之间的差异。在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态 完成了。比如，等待可进一步运行的认可。动作是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。比如，当状态分配给一个参与者时，发一封Email。你也能看出，状态 和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。

 

工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变 量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。

 

目标领域（Target usage）

 

使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构 （heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订 单、支付、资源计划等等。让我们称这些系统为专门应用（ dedi cated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每 当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方 法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。

 

可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务 流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是 相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就 是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

 

工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机 制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。

工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应 用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主 要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

 

The case for workflow

对于引入工作流的组织，能够在软件开发和业务两个层次受益。

 

方便开发-工作流管理系统能够简化企业级软件开发甚至维护。

降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。

实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。

加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。

 

业务流程管理 (BPM)

 

在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：

提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤

较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理

改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性

灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。

业务流程改进 - 对流程的关注，使它们趋向于流畅和简单

我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前 的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种 迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。

 

缺失的一环（Missing link）

 

我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种 系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流 程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程 来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一 个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。

 

A closer look

WFMS interfaces

 

一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休 假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下 来，以备监控管理。

 

Figure 2: Interfaces of a WFMS

 

定义 工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。

 

圈套（Pitfall） 许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开 发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的 机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应 该能够支持这种合作。

 

执行 执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。

 

应用 应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。

 

监控 管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。

这些是WfMC参考模型（reference model of the WfMC）中定义的五个接口中的四个.

工作流的十大特征
强调一下工作流的十大特征：图形化的工作流定义、角色（任务可指派给“角色”或“职能”）、规则、例外处理、监管、测算（产生工作流状态的报表）、仿真 （系统实施前可在单机上测试）、主动性（主动通知、催办和移交任务）、数据库连接、文档附件（可对文档的流转进行有效的管理，以支持关键流程）。 

    这十大特征将极大地帮助我们理解分辨何为真正的工作流，因为即使是“工作流管理联盟”的科学表述，好像也不能完全消除对工作流的某些误读。一种普遍的误解 认为，基于消息的群件产品是一种工作流管理方案。事实上，这是不完全的。基于消息的群件产品都具有工作流的概念，但并非完备的工作流管理系统。

    如果我们套用工作流的十大特征，将会辨清群件产品只是在“文档附件”方面具备工作流的特性，难以完全满足业务流程的自动化预测、监管等。

    对于工作流还有一种常见的分类，即分为“使能型工作流”、“引擎型工作流”、“特定应用工作流”和“通用工作流”。其中“使能型工作流”本质上不属于工作 流产品，但可通过增加逻辑和编码，建立工作流解决方案；“引擎型工作流”则可与其他系统结合，是当前研究的重点。正是从这个分类出发，也有人称群件产品为 “使能型工作流”，或者“单纯的文档型工作流”。

工作流基本功能

它的基本功能体现在几个方面：
　　(1)定义工作流，包括具体的活动、规则等，这些定义是同时被人以及计算机所能够“理解”的。
　　(2)按照工作流的定义创建和运行实际的工作流。
　　(3)监察、控制、管理运行中的业务(工作流)，例如任务、工作量与进度的检察、平衡等。
　　
    与以往已经被采用的企业 IT 应用体系，例如 MRPII 或 ERP 相比，WFM是一个相当重要的里程碑。从用户的角度，WFM带来(或将要带来)的变化是极其强烈的，甚至可以形容为一种用户“梦想”的实现。

    工作流管理 WFM 系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的 状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务 分派和任务的完成状态，可以被最大程度地电脑化和受到控制。
　
二、国产工作流系统的主要特点：
    与国外工作流系统相比较，国产工作流系统在汲取世界先进的工作流管理理念的同时，加入了许多适合中国国情的应用，功能更贴切中国用户的普遍需求，在操作上 更加简便、易用，并且结合了信息门户、即时消息等系统的应用。工作流系统往往是协同应用软件的血脉和经络，是调合协同软件各功能模块的重要应用部分，是协 同软件实现协同管理的基础。

    通过对位居前列的几家国产协同软件综合分析，国产工作流管理WFM系统已经具备与国际主流同类软件相媲美的先进功能，并且具有一些符合中国国情的显著特点，具体如下：
　　
1.强大的工作流引擎：
    工作流引擎是工作流管理软件的核心功能，主要用于负责解释、执行各种工作流程，调度、分发和管理任务。 
　　
2.工作流程的自由定义： 
    国产工作流管理 WFM 系统，已经做到任意定义单个员工、部门、事务的工作流程，并且可以定义群组的工作流程。采用流程代码的设定方式，使系统的灵活性和扩展性大大加强。工作流程步骤不受限制，工作流程的事务不受限制。
　　
3.灵活的组织、员工设定和权限管理：
    工作流管理 WFM 结合用户管理模块，可以快速定义和修改企业的组织结构、人员协作关系，并设定用户的角色和权限。 
　　
4.以任务为管理线索：
    所有的工作，都可以分解为单项或者组合任务，每一任务可以自由设定内容。工作流管理 WFM 用户只需打开事件任务中心，就可以查看、管理所有的待办事宜。根据任务的执行情况，可以对任务的责任部分和个人，进行绩效考评和过程改进建议。
　　
5.多种消息提醒方式：
    工作流管理 WFM 中的相关消息，包括待办任务、请示批复等消息，可以采用Email、系统短消息、手机短讯等方式提醒，并将提醒和处理结果自动反馈到工作流管理数据中去。

协同系统中的应用

具体表现在：
　　◆信息沟通
　　主要依靠邮件系统，电子邮件作为企业宝贵的知识资源，目前分散在各个PC终端中，缺乏集中统一的管理，检索、共享、交流不方便，邮件的可靠性没有保证，造成沟通效率低，信息安全无法保障；
　　◆文件档案管理
　　企业知识资产没有有效地管理，大量文档资料散落在集团的各个部门，共享、学习、利用程度低，部门之间知识交流和共享缺乏有效的工具和平台。
　　◆协同办公
　　日常办公流程、收发文管理目前采用纸质文件、手工传递的方式，无法满足高效、无空间办公的需求，无法形成效的团队的协作和知识的沉淀和积累；
　　◆信息集成
　　建立了大量的信息系统，人员组织架构不统一，系统之间的关联少，数据交流不畅，缺乏贯穿整体的业务流程管理和协作机制；
　　◆信息管理
　　信息的深层次加工比较初级，对信息的挖掘、分析不够，大量数据缺乏深层次的加工。


工作流管理系统的分类
一、目前在市场上可以见到的工作流系统从技术角度可以分为下面几个类型：
1. 基于Domino的工作流管理系统
    由于Domino在群件市场上的普及率，加上莲花公司对工作流概念的大力宣传，人们很容易误认为Domino是一个工作流系统。实际上这种观点是完全错误 的。Domino充其量是一个可以编写带有流程的应用的编程和运行环境，其本身并不具备一个工作流管理系统的特征，如图形化的工作流定义、独立的工作流引 擎、清晰的工作流访问接口等。应用程序所需要的每一个工作流特性，都需要自己手工编写。为了弥补Domino的不足，国内一些OA厂商在Domino上添 加了用其他语言编写的图形化工作流定义组件，但这仍然不能叫做一个工作流管理系统。
    基于Domino的工作流管理系统的典型例子实际上还是莲花公司推出的，叫做Domino Workflow™。它运行在Domino平台上，为开发工作流应用提供了很大的便利。当然，人们只能在Domino平台上使用它。在为其他平台开发应用 时，人们必须求助于别的工作流管理系统。
2. 基于消息中间件的工作流管理系统
    这方面的典型代表是IBM公司的MQSeries Workflow。它通过MQSeries将不同的应用集成在一起，并形成业务流程。它没有一个集中的工作流引擎。当进行分布式的应用系统的集成时，它是 一个不错的选择。但当你需要为运行在单一服务器上的应用提供工作流功能，而且不想因此而购买一大套消息中间件的时候，你必须考虑别的选择。
3. 基于微软平台的工作流管理系统
    这方面的典型代表是Ultimus和微软公司在BizTalk中提供的工作流组件，它们为基于微软平台的工作流应用提供支撑。
4. 基于J2EE的工作流管理系统
    这类系统是我们本文讨论的重点。随着Java技术的日趋成熟和应用面的扩大，绝大多数企业级的应用系统开始基于J2EE技术来设计，对在J2EE平台上的 工作流系统的需求也越来越大。这种工作流系统应用能够充分发挥J2EE技术的优势，提供高度的可靠性、可扩展性和安全性。E-way workflow™是属于这种类型的系统。

转载于:https://my.oschina.net/abcijkxyz/blog/722148