工作流？BPM？云中的流程？这是个问题

 

本书关注于 IT 里的流程产品。面对市场上品种繁多的流程产品，很多人的困惑是：这些流程产品究竟能够帮助企业做出哪方面的改进，这些产品背后的理论基础又是什么？同时，很多人对 IT 产品的宣传也存在着困惑，最多的就是：工作流技术和 BPM （业务流程管理）技术究竟存在着什么区别？为什么很多原先的工作流产品现在都改称为 BPM 产品？本书将对这些问题都进行一定的讨论，一个事实是 IT 流程系统将在企业的改进方面发挥越来越重要的作用，但是不可否认的是，就目前而言，这些系统还存在着很多的局限，如果一个流程产品的思想是流程自动化，那么很大程度上这个产品是不符合企业发展需要的。

提到流程，第一个问题就是流程的历史。 18 世纪英国经济家学亚当 · 斯密在《国民财富的性质和原因的研究》中提出 “ 劳动分工原理 ” ，提出分工有利于提高效率、增加产量，其理由有三：第一，劳动者的技巧因业专而日进；第二，分工可以免除由一种工作转到另一种工作的时间损失；第三，简化劳动和机械的发明使一个人能做许多人的工作。亚当 · 斯密的分工论蕴涵了最朴素的流程理念。流程产生于一系列的分工。

维基百科里 对业务流程进行了如下定义：业务流程是为特定的对象（客户）创造价值的过程，这一过程由一系列相关联、有组织的活动或任务组成。企业和组织中，业务流程一 般被划分为三种基本类型：管理流程，对企业运行进行管理、协调的流程；运行流程，构成核心业务和创造基本价值的流程，如采购、制造、市场销售等；支持流 程，支撑管理流程和运行流程的流程，如会计、招聘、技术支持等。

接下来我们关注工作流技术的历史。工作流技术发端于 1970 年代 中期 办公自动化 领域的研究工作，但工作流思想的出现还应该更早， 1968 年 Fritz Nordsieck 就已经清楚地表达了利用信息技术实现工作流程自动化的想法。 1970 年代与工作流有关的研究工作包括： 宾夕法尼亚大学 沃顿学院的 Michael D. Zisman 开发的原型系统 SCOOP ， 施乐帕洛阿尔托研究中心 的 Clarence A. Ellis 和 Gary J. Nutt 等人开发的 OfficeTalk 系列试验系统，还有 Anatol Holt 和 Paul Cashman 开发的 ARPANET 上的 “ 监控软件故障报告 ” 程序。 SCOOP, Officetalk 和 Anatol Holt 开发的系统都采用 Petri 网 的某种变体进行流程建模。其中 SCOOP 和 Officetalk 系统，不但标志着工作流技术的开始，而且也是最早的办公自动化系统。

 可以看到，工作流最初出现的思想和要解决的问题即是实现工作流程的自动化。但是这带来了工作流技术应用的局限：第一是在企业里存在着很多关键的业务流程，这 些流程自动化的成本太高，无法自动化；第二是很多流程并不需要自动化，自动化反而会降低这些流程的执行效率，典型的在一个企业里，请假往往需要一定的审 批，在这种情况下，直接面对面的交流往往比通过工作流提交表单更有效率；第三是自动化流程往往意味着流程的柔性降低， 比如制造企业都有设备维修业务过程，基本步骤如下：故障维修申请 － > 审批 － > 派工 － > 领料 － > 维修 － > 验收 － > 维修数据记录。这样的一个维修过程如果用工作流实现，工作流引擎会严格按照这样一个顺序执行，但是车间随手换了一个备件，可能只需要 5 分钟，而从提交申请到维修结束，走这样一个繁琐的过程，恐怕不是信息系统服务于人了，而是人服从信息系统了，再比如，紧急情况下进行的维修，可能直接进行维修、验收、记录维修数据三个步骤，可能连派工都来不及了。此时，自动化流程就会严重影响执行效率。

 

1970 年 代人们对工作流技术充满着强烈乐观情绪，研究者普遍相信新技术可以带来办公效率的巨大改善，这种期望不可避免的落空了。人们观察到这样一种现象，一个成功 的组织往往会在适当的时候创造性的打破标准的办公流程；而工作流技术的引入使得人们只能死板的遵守固定的流程，最终导致办公效率低和人们对技术的反感。 1970 年代工作流技术失败的技术原因则包括：在办公室使用 个人计算机 尚未被社会接受， 网络 技术还不普遍，开发者还不了解 群件 技术的需求与缺陷。总结一下，工作流应用失败的原因有两点：第一点是自动化流程的柔性低；第二点则是限于当时的技术原因。

进入 1990 年代后，随着 IT 技术的发展、个人计算机的普及，工作流技术开始重新进入一个新的热潮，这个热潮完全是技术驱动的，这时候出现了大量的工作流技术应用。需要注意的是，工作流技术不仅仅是指专门的工作流管理系统，同时也指拥有工作流特征的各种应用系统，例如各类企业管理软件（ ERP ）和协作软件里有具有的相应流程组件。工作流技术的应用使得很多应用软件的开发得到一定程度的简化（同时，可以观察到工作流产品的采购客户往往会是系统集成商）。需要注意的是，此时工作流要解决的问题域依旧是实现工作流程的自动化，由此带来的应用局限并没有发生变化。

 

与此同时，新的管理革命正在发生。

1990 年迈克尔 · 哈默在《哈佛商业评论》上发表了题为《再造：不是自动化改造而是推倒重来》 (Renglneenllg work ： don"t automate ， obliterate) 的文章，文中提出的再造思想开创了一场新的管理革命。 1993 年迈克尔 · 哈默和詹姆斯 · 钱皮在其著作《企业再 造：企业革命的宣言 )(Reengineering the Corporation ； a Manifesto for Business Revoiution) 一书中，首次提出了业务流程再造 (BPR ： Business Process Reengineering) 概念，并将其定义为：对企业业务流程进行根本性的再思考和彻底性的再设计，以取得企业在成本、质量、服务和速度等衡量企业绩 效的关键指标上取得显著性的进展。该定义包含了四个关键词，即： “ 流程 ” 、 “ 根本性 ” 、 “ 彻底性 ” 和 “ 显著性 ” 。

 

以此为标 志，形成了新的业务流程理念，并伴随着对传统企业金字塔式组织理念和管理模式的反思，新的理念强调企业以业务流程为中心进行运作、打破传统的部门隔阂、增 加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈现出扁 平化、网络化的特征。

新的管理理念催生新的 IT 产品， BPM 产品孕育而生。可以说一个好的 IT 产 品总是对应有相应的理论基础，那种简单的对现有工作方式的复制化是没有生命力的（一个小的而典型例子是电子印章软件，从布局到排版都很逼真。可是现实中印 章的设计是为进行文件的状态确认，非常直接，但是在电脑上摹仿这种印章，不但用着别扭，看着也十分难过，更重要的是，明明通过工作流的控制已经能够确认文 件的状态，却一定要通过电子印章来生硬模拟。）。很多技术人员以 XPDL 和 BPEL 来区分流程产品是工作流还是 BPM ，认为 BPM 更为强调软件的系统集成能力。实际上，工作流软件与 BPM 软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。

工作流软件解决的问题域是流程的自动化，而 BPM 软件解决的问题则是业务流程的优化 。

因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。实际上很多 BPM 软件的前身即是工作流产品，从技术角度上理解，工作流软件和 BPM 软件是没有区别的， BPM 软件是工作流软件发展的结果，只是开发商出于市场的考虑换上一个不同的标签而已（非常类似于当前的药品市场，同一种成分换个名称就变成新药）。然而从处理问题的角度考虑，区别两者则又是必要的。

但是 BPM 软件面临的问题依旧存在，因为很多 BPM 软件解决问题的思路并不正确，很多 BPM 软件依旧是通过自动化流程来实现业务流程的优化，这再次回到工作流软件所面临的问题：企业很多业务流程很难自动化、自动化流程的柔性很低。对于这些问题， BPM 软件试图通过简化编程（快速开发、 SOA 思想）和系统集成来尽可能自动化多的流程，通过增强流程定量分析能力来尽可能的增加流程柔性。这实际上是在用正确的方式做错误的事，因为解决问题的思路从一开始就决定了这并不是一条正确的路。

相比而言， Nimbus 的 Control-ES 软件则选择了另外一条道路，它并不强调流程的自动化，它是从咨询软件发展而来的，这决定了其解决问题的另外一种方式：强调对现有流程的评估和重构而非自动化。在 Control-ES 里，流程是作为企业财产保存的，仅仅文档化。这几乎立刻扩大了其对业务流程的描述能力，但是其的咨询背景也决定了它的局限性：无法实时获取业务流程执行的数据（完全依靠咨询人员的工作），于是 Control-ES 更多是作为咨询人员的工具而存在的。从某种意义上说，流程改进本来就是一项咨询工作，很多 IT 厂商甚至没有任何业务领域经验，拿出其 BPM 软件就宣传能够实现客户流程的优化是一件很搞的事情，很多所谓的流程梳理实际仅仅是对现有流程的复制再现，没有任何改进可言。

          一种更好的方式是文档化所有业务流程，然后通过系统集成能力实时获得关键的数据信息，实现以流程为中心的数据撮合，关键的流程执行和改进则交由人去灵活执行。对这种实现思路我们将在本书的最后部分进行讨论。可以看见的是，流程优化从来也不应该是 IT 系统能够完成的事情， IT 系统所要做的是为流程优化撮合必需的数据，做为支撑系统而存在。

          说完 BPM 软件，最后我们需要关注的一个方向是云计算。越来越多的企业将其工作放置到了网上，典型的如 Google 提供的各种在线服务，文档、邮件、 Excel 等，这种趋势触发了新的业务模式，云中的工作流即是其中一种，通过提供在线的工作流程自动化，将各种在线服务通过流程粘合起来。在这方面， Cordys 走在了最前面。

 

xpdl和bpel有什么本质上的区别吗？

实际上，企业和用户最终并不会关心这些概念，而会综合各个方面的意见，取自己所需要的东西，并且无论是BPM还是WF开发厂商都会很现实，很现实的来开发适合市场需求的产品。。所以我们无论是宣称什么产品概念，都必须从很实际的技术应用做起，脚踏实地，简单的方法就是走一步看一步，摸着石头过河。。。我相信BPM和WF之间不存在什么真正的壁垒和隔阂，而应该是在实际应用中相互学习，互相借鉴，以后的工作流技术或者BPM技术会融合在一起，我坚信这点。。。

谢谢你的意见！

我认为从概念上进行一定的区分是必要，因为每个产品都有其理念和想解决的问题，了解一个产品最好的方式就是看它的历史和要解决的问题。

另外，我也同意你的部分观点，从技术上讲，大部分BPM都是从工作流发展而来，它们之间从技术实现上说并没有明显的差异。可是如果依旧以工作流的方式来解决BPM想解决的问题，这是存在问题的。

其实我对BPM的概念并不是非常了解，可以说还比较模糊，希望老大能够多转帖点关于BPM概念的文章，让我们学习学习

无论是什么XPM还是XPDL，始终要运行，一旦运行起来，其控制运行的系统就成为整个系统的核心部分，前面的XML定义语言就没有什么作用了，而我看无论是BPM还是XPDL这些规范都是在说流程设计过程的规范，而从来没有看到过在后期运行控制方面的问题？ 是否请楼主提示下

这些规范本身就只是规范对流程进行xml建模的，你说的运行期的管理和控制属于其他的范畴，这个我认为倒不大可能形成规范，因为涉及的内容太多，只能从大的方面进行约束，例如工作流系统的5个接口、组成等等。

就我目前看来，前一个阶段基于对流程设计阶段的XML规范标准的这个门槛，已经在国内失去它应有的作用了，那么今后一段时期对工作流产品市场的竞争，将在什么领域，什么层次上面展开，请各位老大一起来讨论下。。。。

我想很多工作流产品开发企业现在都面临市场上同类型产品的激烈竞争，上面的这个问题也许值得我们认真思考。。。

XPDL中对流程数据的定义，有些显得过于冗余，一般来讲，完全可以根据自己的业务需要自定义一个XML规范。。。

BPM如果能够在工作流系统的基础上面增加一些东西，比如说流程运行上面的管理，流程的效率方面的控制，关键是如果能够增加流程与其它应用平台的接口，那么BPM与WF的这种结合是非常有利的。。。