以前只知道工作流也就是workflow，最近接触到企业管理软件中的业务流程管理BPM，觉得两者差不多，于是认真查了些资料，下面揭开工作流和BPM真相。

胡长城——
我对BPM认识之路

当我们感觉BPM似乎还很遥远的时候，BPM已经如洪水般的席卷过来了。有两个形容词一直伴随在BPM左右，形成了“BPM Wave”和“BPM Solution”，可见影响是巨大的。前些日子看到Phil Gilbert的在其Blog上大谈“未来十来年，BPM将替代ERP，成为企业信息化最为关注的领域”。
    早在2003年初，BPM这个领域就出现了一本比较有影响力的书：《Business Process Management(BPM):The third Wave》，可惜国内没有引入，好像也没有影印本。事实上，在Workflow和BPM两个领域内，好像国内出版社一直也没有什么新作，着实可惜。
金碟一直坚持做的Apusic，东方通坚持做TongLink，huihoo一直坚持开源事业······但是在整个BPM Wave中，国内做的还是太少。
    国内工作流的应用（不论从产品角度，还是市场角度）尚且处于起步发展阶段，流程化的应用成熟度还不够，更不要提“大范围的业务过程管理了”。
    国内的流程信息化，目前主要还是围绕“组织”来展开的。 大部分流程应用，在满足“组织关系和组织管理”的条件后才可能会涉及到“业务化”。 这也是为什么国内很多开发商在实施流程项目的时候，会在“需求调研”阶段浪费很多精力主要原因。
    这几年在国内流程应用中，一个比较普遍的现象就是：一个比较简单的审批流程实施，也会把开发商拖很久。可能我们用“流程设计器＋元数据维护＋表 单定义＋引擎”十来分钟就可以绘制和运行一个流程Demo的；但是即使拥有这些利器，一个只有十来个节点的审批流程，可能也需要相当长的实施时间。
      苦恼一：你们的产品有功能强大的C/S设计器，客户却提出要web操作的，而且简单就好；
      苦恼二：你们的产品提供了组织模型适配，客户却要引入一些非正常的组织关系线，而且人员要清晰的展示出级别关系等匪夷所思的特定化组织管理要求。
      苦恼三：你们的产品提供了对流程变更的版本管理，但客户却提出在运行过程中可变更，而不是更改定义重新发布，那样他们觉得太繁琐。
      苦恼四：你们的产品提供了回退、取回、会签、跳转等等高难度的功能，客户却要求能够某步骤之后多人独立运行。
      苦恼五：····· ·
    太多的苦恼围绕着国内开发商和产品提供商。国内目前工作流应用和市场的状态也有个好处，那就是 外来的工作流产品大多都在国内发展不顺利，纷纷挂出或转到BPM概念上 （比如Ultimus），甚至有些国外工作流厂商，进入国内后就打着BPM的旗号（比如华苓、K2workflow）。
    虽然国内的工作流应用还大多局限于“办公审批”，但是五六年来工作流应用市场的成长还是迅速的，也催生了一批不错的国内工作流产品厂商，这里面比较有代表 性的比如老牌的西安协同，新生的携创Joinwork等（哈哈，没有做广告）。因为在我印像中，国内真正掺乎工作流这个概念和应用，也仅是在2001左右 才进入实际的，倒不是说之前没有，上世纪九十年代末期的时候，国内就已经有厂商在做相关项目了，还不算早先那些用Lotus的。
    这五六年的普及，特别是在电子政务和办公协同领域，已经让国内目前的“信息化应用”离不开工作流支持了。相信目前国内采用“工作流浪潮（Workflow Wave）”来形容是非常贴切的。然而，为什么我们在报刊杂志上，在网络上看不到这样的宣传词语呢？好像这个IT世界现在已经大街小巷都是“ESB、SOA、Model Driven、BPM、BI”等等。如果此时有人还大肆鼓吹“Workflow Wave”，是不是会让大家觉得有些落伍和落后呢？希望不是这样。
    单纯从流程这一个角度来说，这五六的市场培育和发展，也着实诞生出一些不错的产品。甚至因为国内的特殊环境和客户需求，国内的产品支持功能要比国外的某些产品要强很多，我看过国外的一些工作流产品，仅从人工流程这一个角度来说，支持力度其实不不怎么样。


    华夏的复杂人文文化，也孕育了复杂的流程功能 。伸出十指数数：回退，任意回退，任意跳转、加签减签，会签，震荡，秘书星，主办协办流，多人独立······这些还仅仅只是比较明显的应用，真正项目实施应用中，某些客户其特殊的组织管理运作方式，官僚等级制度，会提出意向不到的复杂流程。—— 想来，如果Alast大师在国内搞几年工作流研究，估计Workflow Pattern就不只二十一种了。
    然而，面对目前“如火如荼”的国内流程应用需求，国内的工作流厂商却发展缓慢，甚至某些长期处于非营利边缘。每一个客户都会牵扯产品提供商很多精力，甚至很多单子都面对定制化的修改。—— 面对工作流需求，这是一个很大的蛋糕，却每一口都嚼的很艰难。

    首先说说国内工作流厂商所面对的内外夹击吧。没有想到信息技术的发展如此之迅速，也没有想到短短的两三年，国外相关厂商就在不同层面切了进来，而且发展迅猛。
    先说说外遇强敌吧。在整个BPM领域，国内软件厂商所面对的竞争是多面的，或者说是各个层面的。 首先是来自国外大型软件厂商狂轰滥炸 ，铺天盖地的SOA和BPM宣传。更况这样的宣传是来自于IBM、Microsoft、BEA、Oracle等国际大厂商门，他们引领着软件发展的方向，当然不用质疑的影响了相当一部分国内客户，特别是大型客户。

    在BPM与EAI领域，与这些巨型软件厂商有一定竞争能力（甚至有所超越），并 能够提供较为完备的整体BPM解决方案和产品的国外软件厂商 ，这两三年对国内EAI市场冲击很大，比较有代表性的如：TIBCO、WebMethod、Vitria等。


（图片摘自TIBCO BPM Solution）
 
    如果说这些“巨型航母”和顶级EAI/BPM方案提供商们的定位，可能暂时只会影响特定领域内的大型客户，比如电信、金融行业等。那么 国外那些中小型的BPM软件提供商 ， 则在一步步围攻国内中型客户。这些厂商的产品功能总体来说与国内很多工作流产品类似，功能也主要从工作流应用的三方面出击，但是先进的管理体系和充分的研发投入，产品各个方面要比国内相应产品细腻完善。目前在国内比较有代表性的可能要数K2Workflow和华苓Agentflow了。
      （图片摘自K2Workflow和华苓产品）
    相比较而言，国内的工作流产品，则要“瘦弱”多：多则十来人，少则三四人的研发团队成为产品无法迅速蔓延膨胀的内在障碍之一。但前面也说过，单纯从流程运转角度来说，国内的流程产品并不比国际上的一些工作流产品要弱，甚至在人工流程操作领域，更有一些特定应用场景的优势。
    上一篇讲道国外BPM厂商在三个层面冲击国内应用市场，那么面对强劲的国外厂商挑战，国内的工作流产品厂商似乎有些麻木。不知道是因为主动规避市场竞争，还是因为没有在意BPM的发展趋势，抑或是已经占据了特定的应用市场，反正到目前为止， 国内工作流产品厂商对BPM所提及甚少 。比如在最新发布的西安协同SynchroFlow4.0和杭州信雅达Sunflow3.0产品中宣传和特性中，对此概念提及甚少，而是大量的篇幅展现在流程处理功能支持上，只是在“流程监控”方面稍稍提及有此方面功能支持。
    其实国外那些中小型的BPM软件提供商（诸如K2Workflow和华苓Agentflow等），他们在workflow/bpm层面积累的经验年限也不是很长，他们所提及的BPM概念也比较浅，事实上依然还是围绕“流程的定义、运行、监控”这三个方面，只是 他们的产品相比较国内工作流产品而言，要细腻很多。这细腻方面的优势主要在于：框架结构要更为复杂，功能组件要更多，对第三方应用的支持要更容易，对流程监控与统计功能要更强大。
    但是， 唯独在一个方面，这些厂商的流程产品比国内的工作流厂商要弱，这个方面就是“人工交互节点”及流程运转模型上的支持能力 。
      这几年国内工作流主要依托于电子政务和协同办公系统的发展，所以在“与人协作”方面的能力，那绝对是国外工作流厂商所无法比拟的，所需要应对的流程应用场景也相对复杂很多。
      简单举个例子，在SynchroFlow4.0种，增加了“异步活动组”的支持功能；而Sunflow3.0种，则引入了“动态活动”节点。
      
      （信雅达Sunflow的动态节点示意图）
 
（协同SynchroFlow异步活动组示意图）
 
    上面说到的SynchroFlow和Sunflow也仅仅只是一个代表而已。 事实上，国内工作流产品大多都在多年的积累之后，在解决一些“特殊化”人工参与流程处理的应用场景方面，都有一套处理方式及相关功能支持。而这方面的功能应用，则是国外软件厂商所不能超越，也大多不支持的 。
 
    但是“ 成也萧何，败也萧何 ”， 满足人工交互的复杂应用场景，这既是国内工作流产品的优势，也是这几年国内工作流发展速度缓慢的绊脚石 。因为特殊应用场景太多，而国内工作流厂商本身在这方面的技术交流和沟通也很少，使得国内工作流厂商耗费了大量的研发精力来满足这些功能，而对于“整体框架、战略布局”等方面，则心有余，而力不足了。
 
    所以当国外BPM厂商进入国内市场后，且不说那些航母型软件供应商和整体BPM解决方案供应商，单说那些国外中小型的BPM厂商，他们在进入国内市场后，在短时间就在市场和应用方面，与本土工作流厂商形成了鲜明的对比。他们所提供的较为完备的“设计、监控、第三方集成、统计”等应用，正好与国内工作流产品拉开了距离，满足了一定国内客户群的应用需求。
    面对国外厂商的各个层面的竞争，国内本土工作流厂商，也包括部分平台应用提供商，都在寻找自己的应用对策。
    虽然2006年国外BPM厂商出现咄咄逼人的趋势，但是对于国内工作流厂商来说，市场发展还是比较稳健的。这是由于如下几方面影响的：
（１）  航母型的软件供应商如IBM、BEA其SOA/BPM架构产品都基本是定位在高端。这个层面的市场是国内工作流应用厂商所不能够涉及的，也就无从谈起丢失或被瓜分了。
（２）  全方位BPM/EAI应用解决方案供应商，在2005、2006年大多都在进行战略布局（如TIBCO并购Staffware）、架构调整（转向SOA架构）等等。对国内市场还未进行纵深，当然，这个未来是很可怕的。
（３）  高端BPM/EAI厂商这两年在进入国内市场后，相当一部分都因用本土化措施不够，扩张过于迅速，并且缺少稳健的市场铺垫，而在今年集体爆发了“雪崩”。比较有代表性的要数WebMothods和Vitria。目前这两家企业在国内的市场发展都存在大幅度的下滑。
（４）  国内老牌工作流厂商大多都已经有自己的稳固的客户群和行业定位，比如杭州信雅达SunFlow偏向于金融行业，而协同的SynchroFlow则偏向于电信行业等。并且本土化的应用特色和人脉关系也依然庇佑着国内厂商
（５）  电子政务市场和协同办公市场依然在大幅度的发展，政策性的信息化应用依然偏重于国内产品，这两方面的因素决定了短时间内国内的工作流应用市场还有较大的上升空间。
 
    然而，现在稳健发展的国内工作流市场，事实上是隐藏着巨大的危机的。
（１）  目前高端和大型集团化的BPM应用，会逐渐在未来几年内向低端***；未来集团化的信息应用，也逐渐会由主枝BPM/ESB向二级、三级组织机构扩展。
（２）  目前国内的绝大多数工作流应用都只在解决“流程的信息化处理”，即帮助客户应用信息化技术实现流程处理，但是很多都只站在“客户操作的角度”，而忽略了“客户管理的角度”。
 
    想来，国内工作流应用厂商也都意识到了“未来的危机”。所以部分国内工作流厂商已经在寻找“突围口”了。—— 可惜，没有看到哪家考虑考虑BPM战略。但是这种简单的从“有纸化往无纸化迁移”虽然可以在一定程度上提高处理效率，但是并不能大幅度改善企业管理层的信 息化应用收益。—— 看来过些日子，可以考虑做个专题：国内工作流厂商眼中的BPM，也许能够看得更加清晰些。—— 现在说这句话的时候（“没有看到哪家考虑考虑BPM战略”），只是自己的感觉。
    面对“狼来了”的BPM应用，国内厂商是矛盾的。首先是没有厂商能准确把握“客户对BPM的理解和期望”，所以厂商不敢轻易投入这方面的研发；其次，国内工作流应用的市场未来几年内还存在大幅度的增长，需要在workflow产品的功能支持和销售上投入人力物力。
    单纯从工作流角度来说，国内这些厂商还是在努力发展和打拼的。而他们所激烈竞争的市场是国外厂商短时间内很难进入的。
 
    老牌国内工作流厂商都看到了“红红火火的集团化应用”市场，所以不约而同的在2006年发展了对此有支持特性的产品：SynchroFlow推出对支持ESB的支持，SunFlow推出对集群和负载均衡的支持等等。
    而对于那些年轻的国内工作流产品厂商，则要保守的多，2006年对他们来说，打的是一场“守住市场的战争”。产品的修改多以满足客户某些小需求为主，大多没有大版本的变更。代表厂商要数Joinwork和华创动力MatrixFlow。
    国内工作流厂商的“突围”还是以“生存”为主要目标的，而“发展”则需要以一些先进理念为原则的，可惜这依然是国内厂商很难逾越的。

初识BPM，原来竟是一场误解


    2003年3月，当BPEL1.1发布的时候，我还在捣鼓一个基于FSM模型的公文审批流转产品。可想而知，那时候对BPEL是没有任何意识的，可能稍稍有些感触地，就是那时候，BEA的weblogic workshop7中的流程定义语言JPD。
    可惜那时候主要精力都在国内的电子政务和办公自动化流程应用上，所接触的场景，是国外那种面向“自动化”流程所不能够支持的。
    那时候，即使面对刚发布不久的WfMC的XPDL，也有很多不理解和不认同。这在我2003年底写的《工作流模型分析》中有所阐述。
 
    但随后不久的BPEL/BPEL4WS与BPEL却是“芝麻开花——节节高”。之后的两年时间里，尝试跟了跟BPEL的规范及相关产品，但是终因没有实际应用而多次放弃。毕竟BPEL所阐述的应用场景和应用思想，在那个时候还是过于超前的。
 
       2005年中的时候，为当时所在的公司（USE）写完一个工作流引擎之后，回首一思索，突然觉得自己，不能再被当前的workflow技术所困扰了。面对发展迅速的BPEL和BPM概念和应用，应该跟进了。
      虽然看到了BPM未来的发展趋势和势头，但是究竟什么才是BPM呢？这个问题，在当时的我来说，是无法回答的：业务流程、整合、web服务······等等，所有这些都将业务流程执行语言（BPEL）推到了BPM的前头。
 
    现在想在，那时候最大的错误，就是把“BPEL”与“BPM”做了几乎的等价，以为只有采用BPEL规范，才是BPM的解决之道。—— 我也相信，这两年，甚至现在，也依然有很多人，还在坚守着这样的“误解”。——　国内没有什么文章把这两者区分开来分析和阐述，再看看当时那些支持 BPEL规范的厂商吧：IBM，Microsoft，BEA，Oracle。对这些厂商来讲，BPEL是一个核心，所有的整合和执行、交互、交换都需要围 绕这个业务流程执行语言展开。
 
    正是在这样一种误解之下，我觉决定从BPEL去开始对BPM的理解。这是一个错误的开始，但是比较幸运的是，这个错误的开始并没有持续多久便结束了。
       2005年中，公司项目某项目组可能需要给一个客户采用IBM WBI实施业务流程管理，于是我便申请从平台部门调到那个项目组负责这方面的预研。很显然这个预研是围绕BPEL的实践展开的。
 
     通过那段时间的预言，让我对BPEL语言有了一定的了解，但是更多感触则是，BPEL只是这些大厂商的EAI/BPM解决方案中的一个小部分而已，或者说是一件单调的外衣。这套外衣必须有大量的点缀：Transformer Service,Adapter Service等等。
 
    可惜我没有太多的机会去解决更深层面的概念和技术。不久这个项目就被客户取消了，我又重新调回到平台部门，继续那个不痛不痒的Platform研发。
 
    接下来，一年时光很快就晃荡完了。虽然BPM这个疑问依然还在我脑海中萦绕，却再没有碰到这样的项目，对BPEL似乎也渐渐的淡忘了。


    按照我最初的设想，这篇文章本不应该写Workflow与BPM的区别的，但是世界总是变化这么快。前几天给公司内部的期刊写了篇介绍工作流的文章，之后就有很多同事询问Workflow与BPM的区分问题。于是不得已就写了点这方面自己的看法，现摘录如下：
    对Workflow和BPM，没有严格的概念界限区分。
    首先让我们回顾到上个世纪九十年代，诞生了“Process Reengineering”，可惜那个时候只是一阵风，因为技术跟不上，所以大多都只停留在管理层概念。但是，在九十年代，workflow技术却蓬勃发展，可谓是百家争鸣，蒸蒸日上。
    2000左右，工作流技术应用已经非常成熟，数据集成，应用集成也发展迅速。随之也推动了业务过程管理、整合、统计、优化等方面的应用需求。于是就诞生了“BPM”这个概念。
如果Workflow是早期人们为了解决“办公自动化”“流程自动化”而诞生的应用技术和解决方案的话；那么BPM则是为了“对全局性的业务分析、整合”，以及“能够基于这些分析提供对上层管理决策的支持”的一种应用技术和解决方案。
    事实上，如何去描述业务过程“Business Process”，一直还是个争论不休的话题，也因此存在几种标准。主要是以WfMC为代表的XPDL，OASIS为代表的BPEL，OMG为代表的BPMN和BPDM。
    虽然描述过程“Process”的标准并不一样，但是在圈定以：过程定义、过程执行、过程监控、过程分析、过程优化这几个方面为核心的BPM Solution ，这一方面各家几乎都是相同的，只是实现技术不同。
    当然，随着SOA浪潮的到来，BPM基于SOA已经是一种必然趋势。
我们都知道，BPM是由工作流（Workflow）和企业应用集成（Enterprise Application Intergration）逐步融合而发展起来的。在个人的观点中，目前国内依然还是以工作流应用为主导，同时伴随着企业应用集成的深入和发展。至于BPM应用，目前还只是一小部分零零散散的应用，当然BPM肯定是未来趋势。




（注意：部分内容直接来源于网上文章，如作者对本文内容有异议，请发邮件到fangliang0417@hotmail.com，本人将立即删除相关内容，谢谢！）