|
ERP Vs WF 应用ERP系统实现制造业企业的管理信息化这也成为人们的共识，传统ERP为制造业企业产供销人财物的管理提供了一整套优化企业资源利用，集物流、信息流、资金流为一体的现代化管理工具。但是它在过程集成和企业间集成方面存在不足。 1.ERP是一个面向功能的事务处理系统。它为业务人员提供了丰富的业务处理功能，但是每个业务处理都不是孤立的，它一定与其它部门、其它人、其它事务有关，这就构成了一个业务流程。传统ERP对这个业务流程缺乏有效的控制和管理，一些业务流程被写死在程序里，非此及彼，必须按其执行，否则就要修改程序。许多流程是由人工离线完成的。并且企业领导放在了系统之外(搞笑一下,只要一将领导牵扯进来,就是大事,言下之意就是告诉领导,WF非上不可,于是新的项目就又来了，一般售前顾问都要善于如此忽悠,可惜WF这东西一旦实施不好就会变成WC-茅厕)。 2．固化的业务流程，这非常不利于业务流程的改变。大家都知道，我国企业正在从计划经济向市场经济转变，从区域经济向世界经济转变，由传统制造向敏捷制造、虚拟制造发展。为了应对激烈的竞争环境，企业要不断地改进自己的管理，实施流程再造。这一切都意味着企业的业务流程是不断改变的。所以传统ERP系统必须是功能可重构、流程可改变、高度柔性的系统。为此将工作流管理技术引入ERP系统就成为必然的结果。 工作流的基本概念和定义 1993年工作流管理联盟成立，制定了相关的系列标准，同时给出了工作流的定义是："工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行"。 工作流管理系统的定义是："工作流管理系统是一个软件系统，它完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行"。工作流系统不同于ERP系统。ERP系统是面向功能的事务处理系统，更大程度上要满足企业的业务操作功能（带有部分固定流程模式，灵活性欠缺），具体解决某个或某些领域的问题，提高事务处理的效率和水平；工作流管理系统的着眼点是面向市场、客户，是在企业的整个业务层提高企业的业务处理水平，强化企业的市场意识 设计理念中，“工作流自定义”就是一个模块，企业可以自定义一个工作任务，在这个任务中要进行什么样的工作行为（即工作内容是什么），这些行为的先后（并列）次序是怎样的，相互的关联又是怎样（比如审核行为必须在输单行为之后，订单传入后自动发送到A、B、C部门等等）全部是可自定义的，并完全采用图形化拖放式操作，使用者不会感到自己在编程，而只是在画工作流程图，系统呈现的只是在这个基础上所预设的一个建议性的工作流程模板。 工作流成为协同软件核心 协同软件(Collaboration Software)是指那些以团队协作为目标的协作软件工具，主要包括群组协作管理，如：工作流管理、项目管理等等；各种通信软件，如E-Mail、即时通信、VoIP等。网络、通信技术的发展和用户全球化等新需求的提出，对协同软件概念也赋予了新的含义，可以这样认为：协同办公、协同政务、协同商务等协同应用，以及工作流管理、项目管理、知识管理、信息门户等协同平台，电子邮件、即时通讯、远程视频、流程编辑器等协同工具，组成了我们现在意义上的协同软件。 与国外工作流系统相比较，国产工作流系统在汲取世界先进的工作流管理理念的同时，加入了许多适合中国国情的应用，功能更贴切中国用户的普遍需求，在操作上更加简便、易用，并且结合了信息门户、即时消息等系统的应用。工作流系统往往是协同应用软件的血脉和经络，是调合协同软件各功能模块的重要应用部分，是协同软件实现协同管理的基础。 工作流的几个重要术语 工作流 根据 WfMC 的定义，工作流（Work Flow）就是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。
简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。我们可以将整个业务过程看作是一条河，其中流过的就是工作流。 工作流管理 工作流管理（Workflow Management, WFM）是人与电脑共同工作的自动化协调、控制和通讯，在电脑化的业务过程上，通过在网络上运行软件，使所有命令的执行都处于受控状态。在工作流管理下，工作量可以被监督，分派工作到不同的用户达成平衡。 根据WfMC的定义，工作流管理系统（Workflow Management System, WFMS）通过软件定义、创建工作流并管理其执行。它运行在一个或多个工作流引擎上，这些引擎解释对过程的定义，与工作流的参与者（包括人或软件）相互作用，并根据需要调用其他的IT工具或应用。
总体来说，实际企业中运作的工作流管理系统，是一个“人-电脑”结合的系统。它的基本功能体现在几个方面： 定义工作流，包括具体的活动、规则等，这些定义是同时被人以及电脑所“理解”的。 遵循定义创建和运行实际的工作流。 监察、控制、管理运行中的业务（工作流），例如任务、工作量与进度的检察、平衡等 业务过程（business process）就是活动的集合，这些活动均关联于特定的托付事项（commitment），为过程的产出增值。相对于“工作流”，业务过程是一个更一般化的统称，而工作流这个词，则已经不能仅从字面含义或原理上去理解，它已经被赋予了更深一层的特定含义——专指基于信息技术规划、运作、管理的业务过程。 监察（Monitoring）与控制（Contorl）是工作流系统的重要功能与特征。这不仅包括对正在发生的业务过程（工作流），还包括它的定义或改变（比如BPR的过程）。这是工作流系统带给我们的明显好处之一。 标准化 工作流的概念被明确提出并得到重视的同时，人们就认识到了“标准化”在其中的重要性，有关工作流的标准开发和推广，基本是与“工作流”的开发和推广同步进行的。在这方面目前的权威性机构，是“工作流管理联盟”（Workflow Management Coalition, WfMC）。它成立于1993年8月，目前已拥有 130 余个成员，成员包括工作流产品的供应者、应用者，有关大学和研究机构和个人，是一个国际性的非赢利组织。在最近的投资成员（Funding members）清单中，可以看到诸如 Baan, HP, IBM, Microsoft, Oracle, Peplesoft, SAP AG, Xerox 等机构。 “自动” “自动”（automate）是工作流的一个特征，但这主要是指它自动进行的特征，而不是说没有人的参与。工作流实际上是一个人-电脑协调的混合过程，在一个实际的工作流中，通常总有些步骤是人完成的。协调是工作流管理的一个目标或者特征，这包括了人与人、人与电脑，电脑（软件）之间等多种层面的含义。 工作流与BPR 从逻辑上，对工作流的关注和研究可以看作是对业务流程重组（BPR）的一种深化。BPR的观点，要求我们将眼光投向实际业务进行的过程，但这个过程应当是什么样的，怎样分析、构造？工作流就是一个具体的、操作性的答案，它可以令我们从神秘的、难以预测和控制的“头脑风暴式”的“艺术的”业务过程创造，变成解析的、技术的、可控制和预测的工程化过程。 工作流与 BPR 的概念，已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织，即国际工作流与重规划协会（ Workflow And Reengineering International Association, WARIA）。 工作流与企业工程 无论从理论、方法上，还是对象、内容上，我们都有理由将“工作流”看作是企业工程的一部分。实际上，已有的关于工作流体系的描述，本身就是一个通用的业务模型框架。仅仅囿于工作流是不够的，必须对整个体系的目标及所有相关要素综合考虑——这正是企业工程。 工作流与IT应用体系 与以往已经被采用的企业 IT 应用体系，例如 MRPII 或 ERP 相比，WFMS是一个相当重要的里程碑。（ERP的概念并不确定，我这里仅指其基本或较早期的含义而言）。从用户的角度，WFMS带来（或将要带来）的变化是极其强烈的，甚至可以形容为一种用户“梦想”的实现。 在一些老的“模块化”的产品中，系统的设计是通常是基于任务分割的，作业项目之间是分裂的。面向对象的技术，并不能直接解决这个的问题，相反，往往使系统变得更加混乱和琐碎。从操作上，典型地，我们必须不断地在层次结构的功能表（比如下拉菜单）或对象之间“进进退退”，或者在“神出鬼没”的对象以及相关菜单中捉迷藏。 工作流管理系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。 现在的典型工作流产品是客户-服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化工具，依照业务过程实例的情况定义相应工作的安排。 业务流程管理发展趋势 信息技术已改变了企业内部和企业之间的业务流程。越来越多的工作流运行依赖于流程模型驱动的信息系统， 难以想象与流程无关的企业信息系统。尽管运用信息技术来帮助业务流程的管理早已被咨询顾问和软件开发人员炒作，但一个更基本的方法则却被忽略了。直至90年代，研究人员才开始研究业务流程管理系统的基础。结果有许多问题有待解决。此外， 网络服务（Web Services）之类的新技术发展也引出了新问题。 为了将工作流管理置于合适的环境来讨论，先看看它的发展趋势。60年代，信息系统基于小型的操作系统，功能也有限。由于既无通用，也无领域相关的软件，这些系统主要由特定的应用程序构成。从那时起，每年都有提供新功能的软件产品出现。如今的操作系统比60年代提供了更多的功能，数据库管理系统提供了定制应用的功能。 这种趋势导致从注重程序设计转向复杂软件系统的集成。挑战不再是单个模块的编程，而是把四个层面的软件模块连接，使其协同工作。另一个趋势是从数据到流程的转移。70和80年代是数据驱动的方法占主流，信息技术主要用作存取信息，结果数据建模成为信息系统构造的始点。 业务流程的建模经常被忽视，流程不得不适应信息技术。业务流程重组等管理理论的发展体现了对流程的重视，使得系统工程师更趋向流程驱动的方法。最近值得提及的趋势是从仔细规划设计转向重新设计和组织增长型的方式。由于因特网及其标准的无处不在，信息系统也不断变化。很少有系统从头构建。已有的部分应用经常会在新的系统中使用，使得软件开发更加动态化。 业务流程管理系统是一种面向流程的信息系统，即超越单个任务自动化的系统。如工作流管理系统Staffware、MQSeries和 COSA，案例处理系统FLOWer。值得注意的是主要的ERP系统也提供了工作流管理的模块。SAP、Baan、PeopleSoft、Oracle和 JD Edwards的工作流引擎可被视为集成的业务流程管理系统。 把业务流程的管理独立成一个单独的组件的思想是与以上三个趋势一致的。业务流程管理系统可避免把工作流固化在定制的应用程序中，支持从程序设计到应用组装的转变。此外还支持面向流程、流程再设计以及组织增长（organic growth）。目前的工作流管理系统可用来集成已有的应用，支持通过仅改变流程图的流程变化。 工作流管理系统 尽管工作流管理联盟（WfMC）做了很大的努力，但基于不同范例（paradigms）的工作流管理系统仍使用多种语言和概念。大多数的产品使用专用而不是一种工具无关的语言。一些工作流管理系统是基于Petri网的，但增加了产品相关的扩展和限制。其他的系统使用了一种完全不同的机制。如IBM的MQSeries工作流使用主动和被动的线程，而非拖肯（token）传递。不同的工具的差别是明显的。导致工作流规范不能达成共识的原因之一是业务流程的描述方式的多样化。 缺乏通用的组织“理论”和标准商务流程建模概念解释了工作流语言间差别的合理性。更重要的是，不同工作流产品的比较更多促进产品的发布（dissemination），而非对工作流语言能力的指责。在艾恩德霍芬工业大学（Eindhoven University of Technology）和昆士兰州工业大学（Queensland University of Technology）的共同努力下，一个新的用来比较和评价工作流的系统被开发。这个框架基于一个全面的模式（pattern）集，考虑了对工作流管理系统更客观的评价。 15个主要工作流管理系统包括COSA、Visual Workflow、Staffware、Verve Workflow、I-Flow、InConcert、Changengine、 SAP R/3 Workflow、 Eastman和FLOWer。 网络服务组件语言（Composition Languages） 在电子商务领域同时出现了两个趋势，它们引发了实现跨组织业务流程自动化的机遇和压力。一个趋势是技术的推动力，产生于基于XML的标准和因特网的使能技术。另一个趋势是从商务角度改善流程效率的需要。网络泡沫后，通过自动化跨企业的业务流程来充分利用因特网技术的潜力变得紧迫起来。网络服务的目标就是利用XML和互联网集成能在web上发布、定位和调用的应用。 一个网络服务的典型实例是Galieo系统，它将42,000多个旅行代理连接到37个汽车租赁公司、47,000个旅馆和350个旅游承办商。为了真正集成跨企业流程，利用标准的消息和协议支持简单的交流已不能满足需求。商务交流需要由直观的流程模型驱动的长时间（long-running）交互过程。这就需要Web Services组件语言，如BPEL4WS、WSFL、 XLANG、WSCI和 BPML。 采用网络服务组件语言的开发主要是由IBM、Microsoft、Sun、BEA、 SAP和Intalio等软件提供商驱动的，结果出现了许多功能重复的标准。当更仔细地考虑这些标准时，它们很明显都基于现有的产品，如WSFL基本上是IBM的Flowmark/MQ Series工作流语言的复制品。许多软件供应商参与的标准往往是不同观点的一种妥协，这样的标准导致不精确以及不必要的复杂。如工作流管理联盟的XPDL使软件供应厂商有各自的解释标准（使标准变得毫无用处）。BPEL4WS融入了WSFL和XLANG两种标准，使得这种语言十分复杂。 BPMI是提出网络服务组件标准的组织之一。BPMI.org定义了业务流程建模语言BPML (Business Process Modeling Language)和业务流程查询语言BPQL (Business Process Query Language)等开放的规范，它们利用即将推出的企业流程管理系统BPMS(Business Process Management Systems)，促进电子商务流程标准化管理，就象SQL使用现有的数据库管理系统实现了企业数据的标准化管理。 类似SQL的网络服务标准是雄心勃勃的目标。如历史展示的那样，这样的标准不会在厂商推广自己产品的过程中出现。想当初Chen提出的实体-关系模型（Entity-Relationship model）和Codd的关系模型（Relational Model）促进了SQL等语言的产生。虽然存在集表示、简单、形式语义（Petri网和过程代数）于一体的流程建模技术(比较.Petri网和过程代数)，软件行业却忽略这些技术。结果世界面临着太多的标准，它们主要由具体产品和/或商业利益驱动的。结束这种状况的唯一途径是忽略那些不使用已有流程建模技术的标准提议。这使软件提供商重视实际问题而非产生新的问题。 工作流之大局势 工作流(WorkFlow)发展的三个阶段: ﹡ EDF(电子数据流)阶段 ﹡ TPF(事务处理流)阶段 ﹡ IMF(信息管理流)阶段 工作流技术属于较新的一个,它现在仍处于标准的制定阶段,目前已有的标准按采用的技术分为两大派别：基于XML技术和基于Web服务技术。 基于XML技术的流派 ﹡ XPDL（Xml Process Definition Language） 在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，它成立于1993年。1994年11月，wfmc发布了工作流管理系统的参考模型。参考模型提出了五类接口，有关过程模型的定义则构成了接口一的核心内容。接口一早期的标准为WPDL（Workflow Process Definition Language），后来,这一接口的规范变更为XPDL。XPDL是至今工作流领域最为重要的一个标准,目前大多数工作流引擎是依据该标准设计开发的。 ﹡ BPML(Business Process Model Language) WfMC和BPMI在2002年6月26日宣布将合作制定业务流程和工作流标准，即采用BPML来描述工作流过程，同时采用XPDL所定义的工作流模型。 ﹡ OMG的Workflow Management Facility 基于Web服务技术流派 ﹡ WSCI 2002年6月26日，BEA,Intalio,SAP,Sun四家公司提出了基于xml的WSCI规范，推动Web服务进入了一个全新的阶段。这个规范主要描述了一个参与和其它服务进行协作交互的Web服务所交换的消息流。 ﹡ ebXML ebXML是一组支持模块化电子商务框架的规范。ebXML支持一个全球化的电子市场，它使得任意规模的企业通过交换基于XML的信息，不受地域限制地接洽和处理生意。ebXML是联合国（UN/CEFACT，贸易促进和电子商务中心）和OASIS（结构化信息标准发展组织）共同倡导、全球参与开发和使用的规范。 ﹡ BPEL 2002年8月9日，Microsoft, BEA, IBM, SAP & Siebel联合提交发布了BPEL规范。此规范描述如何处理输入的消息，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。此规范重点在Web Service。 开源工作流引擎简介绍 ﹡ OFBiz OFBiz最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。其中包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。OFBiz先前的工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言,也就是说,它是支持太子XPDL的,而且和十三爷OMG的关系非常之好。OFBiz新版的工作流引擎采用Shark工作流引擎,我们不建议再去学习OFBiz自身的工作流引擎。 ﹡ OBE OBE 是由Adrian Price主持开发的一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE主要基于J2EE实现。OBE的接口1实现得非常好,可惜,OBE的载体公司Zaplet已经于前不久被合并，合并后的公司没有继续发展OBE的打算。 ﹡ Shark Shark是完全根据WFMC规范实施的，可扩展功能的工作流引擎，它利用xpdl来定义流程，同时还包括服务器端的用于活动节点执行的WFMC工具代理API。Shark中的每个组件例如持久层，事物管理器，脚本引擎，流程库，都是可以按照标准实施运用的，而且还可以被具体项目的模块扩展和替换。 ﹡ OpenebXML OpenebXML项目致力于提供一个ebXML框架，主要支持 UN/CEFACT和OASIS发布的ebXML规范2.0版。 ﹡ Bonita Bonita是一个符合WfMC规范、灵活的协同工作流系统。Bonita基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。 ﹡ Twister Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。 ﹡ ActiveBpel ActiveBPEL引擎是一个于今年7月发布的健壮的运行时环境,它能执行用户按BPWL4WS规范编写的业务流程。ActiveBPEL引擎由Active Endpoints公司开发和维护,该公司同时在它的多个商业产品中使用了该技术。 ﹡ OSWorkflow OSWorkflow的最大特点是灵活 ﹡ OpenWFE OpenWFE是一个开放源码的Java工作流引擎。 它的思想来源于 Scheme，包括可升级的三个组件：引擎、工作列表和Web界面。 ﹡jBpm jBpm是tom baeyens编写的一个灵活可扩展的工作流管理系统。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。国内目前有部分人研究jBpm。 | 作者：Tom Baeyens 缺失的一环（Missing link） 我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这 样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP 软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管 理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，…这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文 后面的列表中选择一个。 A closer look WFMS interfaces 一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个 报价、…之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管 理。 定义 工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。 圈套（Pitfall）
许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开 发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的 机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应 该能够支持这种合作。 执行 执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。 应用 应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。 监控 管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。 这些是WfMC参考模型（reference model of the WfMC）中定义的五个接口中的四个。 流程定义的四个层次 在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用 的基本思想。流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。 状态层 所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业 务流程中不是使用命令而是使用状态作为基本元素。 在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。 流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列 表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算 使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在further reading section提到的“工作流应用中的组织管理”（ ‘Organizational Management in Workflow Applications’）。 流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联 合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。 UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺 少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移 （transitions）到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。 在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化： - 在用图形表述业务流程时，只建模状态层（状态和控制流），不要包括动作。这意味着图形中的矩形都是状态而不是活动
- 如果多个迁移到达一个状态，缺省定义为不需要同步的合并（merges）
在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流 程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务 列表。 上下文层 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。 注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。 和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程 中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有相关联的数据 项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。 程序逻辑层 如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的 组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。 用户界面层 一个参与者通过向流程变量中填充数据的事件，来触发结束一个状态。比如，在请假的例子中，老板提供“同意”或“不同意”数据到流程中。某些工作流系统允许 指定哪些数据可以填充到流程中，以及它们如何在流程变量中存储。通过这些信息，可以生成从用户收集信息的UI表单。基于流程定义生成用户提交表单的Web 应用例子，可以访问the jBpm online demo。 工作流全景 可执行流程与工作流管理系统的比较（Executional processes versus a WFMS） 当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声 明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。 在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别： - 基 于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这 样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。
- 流程实例ID与消息相关处理：可执行业务流程的复杂性之一来 自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流 程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。
- 工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。
学术界 学术界对工作流的研究可以回溯到上个世纪七十年代。在当前，研究领域趋向于认为petr 网是所有流程定义语言之母。关于petri网已有大量先进的分析技术，去年在 2003 conference on Business Process Management上我有幸会晤了Petri教授。对于大部分人能够访问和理解的有关Petyri网最好的研究之一是工作流模式(workflow patterns)。工作流模式比较了大量的工作流管理系统并以petri网的术语表述了通用流程建模概念。 | SAP毕竟是ERP软件的龙头，其工作流作得也相当不错，和其业务系统集成得相当好。 SAP Workflow template在底层就贯穿于各模块！
SAP的工作流中，WorkItem的类型有很多，其中一种是Dialog WorkItem，用于人工参与的任务。其任务的状态分类，也许值得我们设计工作流引擎参考。如下：
SAP 业务工作流是 SAP R/3 提供的一个重要的业务工程工具。它被设计成跨应用模块的并支持集 成事务。因此，它提高了现有的标准应用系统的功能。它特别适合于满足公司的特殊需要，自动地处理和控制跨应用模块的业务。SAP 业务工作流集成和补充了标准 R/3 系统尚未包括的业务。SAP 业务工作流可以实现在 SAP R/3 环境中的 JIT 打印。如果我们能成功地把打印定义 为整个工作流中的一个步骤（活动）(当然，在正确的时间，正确的的打印机完成正确的打印输出)，开发 JIT 打印和开发 SAP 业务工作流是十分相似的。
|