工作流？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 走在了最前面。

工作流？BPM？云中的流程？这是个问题相关推荐

《Activiti/Flowable 深入BPM工作流》-什么是流程变量?
<Activiti/Flowable 深入BPM工作流>-什么是流程变量? 一. 问题: 1. 什么是流程变量? 2. 什么是glob ...
再分享本工作流的书《流程的永恒之道》
上次分享了本书: 工作流入门链接+分享本书<Activiti实战> 今天又看到了另一本工作流的书: <流程的永恒之道:工作流及BPM技术的理论.规范.模式及最佳实践> 不过这本 ...
工作流+BPM+BPMN
工作流+BPM+BPMN 一.工作流 1.工作流(Workflow) 工作流(Workflow),指"业务过程的部分或整体在计算机应用环境下的自动化".是对工作流程及其各操作步骤之 ...
协同工作流引擎，开启流程优化新纪元
2019独角兽企业重金招聘Python工程师标准>>> 协同工作流引擎(Synchro flow)是业界领先的企业业务流程自动化的基础平台产品以及企业流程再造的核心产品,提供以业务建 ...
如何在Epower工作流平台（企业流程管理平台）上建立OA系统
写这篇文章之前,要在这里感谢博客网带来的这个机会,上周末发布了关于工作流技术及企业流程管理平台介绍的文章后,QQ已经加入了很多朋友,大家一起探讨这个平台的一些功能特性,其中大家问得最多的是如何 ...
java如何开发bpm系统_java工作流bpm开发ERP实例
今天看了一个java工作流bpm开发ERP的例子,文章介绍:http://tech.it168.com/a2009/0507/275/000000275294_14.shtml 增加数据块一路照做就 ...
快速开发工作流_03_集成在线流程设计器_内置用户免登录
接上一篇:快速开发工作流_02_集成在线流程设计器 https://gblfy.blog.csdn.net/article/details/103676784 文章目录八.内置用户免登录 8.1. ...
快速开发工作流_02_集成在线流程设计器
接上一篇:快速开发工作流_01_简单流程案例https://gblfy.blog.csdn.net/article/details/102881983 文章目录七.流程设计器 modeler 7.1 ...
工作流审批平台-审批流程-审批权限
工作流审批平台-审批流程-审批权限
java 流程引擎_java工作流引擎Jflow父子流程demo
关键字驰骋工作流引擎流程快速开发平台 workflow ccflow jflow .net开源工作流 2.定义一个流程A的一个节点,因工作的需要调起另外的流程B,A就叫父流程,B就叫子流程.如 ...

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

工作流？BPM？云中的流程？这是个问题相关推荐

最新文章

热门文章