业务流程管理（Business Process Management，简称BPM）已经成为企业面临的重点课题之一。在中国，企业信息化的先锋联想与海尔都在进行公司层面的核心业务流程的梳理和再造，海尔甚至为其BPM项目的实施而停止了14个正在和准备开展的信息系统项目，并由集团副总裁亲自挂帅，可见其重视程度。我国现有很多的企业已经意识到，企业管理必须有一套切实可行的管理流程，靠人治的方法把企业做大、做强的可能性很小。

BPM价值的具体体现

一、固化企业业务流程增强执行力

       只要不是单个人独立完成全部工作的个人作坊性质，企业从它的诞生起，就存在着流程，并且随着企业的不断成长，其流程越来越多，越来越复杂。几乎每个企业都针对各类业务流程和事务流程有一套规章制度，随着管理的细化和规范化，企业的规章制度是越来越厚，而执行这些规章制度的人却越来越坠入谜团中。可想而知，这些影响着企业生命的核心流程的执行效果会怎样了。

       有些企业已经认识到了这点，甚至花巨资请专业的咨询公司来重新肃清流程、规划流程，但很多企业中由于人的原因，如碍于情面、越级审批、不照章办事等，而造成应用的失败。

       企业业务流程管理系统就能在应用的初期阶段达到这样的首要应用目标，通过系统固化流程，把企业的关键流程导入系统，由系统定义流程的流转规则，并且可以由系统记录及控制工作时间，满足企业的管理需求及服务质量的要求，真正达到规范化管理的实质操作阶段。

二、改善工作质量

       除了节省时间和成本的优点外，已经实施BPM的企业也发现了其它几项关键优点。首先，可以大幅降低甚至消除造成企业损失的错误，如丢失表格和文件或错误存档、遗漏重要信息或必要审查。其次，显著改善流程的可视化程度，所有参与流程者不仅被授权了解自己在流程中的角色，而且确切地了解流程在任何时候的状态。第三，有了可视化，也就明确了职责，所有人都完全清楚地知道什么时候应当完成哪些工作。不再有借口造成延误、误会或疏忽。最后，可提高一致性，公司内部和外部各方对工作都有明确的期望。结果使得员工、客户和合作伙伴都有了更高的满意度和向心力。

三、提高效率降低企业成本

       BPM是提供业务流程建模、自动化、管理与优化的准则与方法。一个成功的BPM方案包括正确商业领导和技术的组合，可以大幅缩短流程周期（有时高达90%）和降低成本。这种效果在跨部门、跨系统和用户的流程中尤为突出。从技术的角度看，一个独立的BPM系统能够轻易地与现有的应用软件如CRM、ERP和 ECM相集成，而无需重新设计整个系统。

四、实现企业业务流程自动化

       有人做过一个行为分析，发现一个流程的处理时间中90%是停滞时间，真正有效的处理时间很短。并且在流程处理过程中需要人员去用“腿”、用“电话”等其他手段去推进，不仅耗时耗力，而且效果差，时时有跟单失踪或石沉大海的情况发生。通过业务流程管理系统，利用现有的成熟技术、计算机的良好特性，很好地完成企业对这方面的需求，信息只有唯一录入口，系统按照企业需要定义流转规则，流程自动流转，成为企业业务流程处理的一个“不知疲倦”的帮手。

五、持续改进和优化企业业务流程

       流程在制定出来以后，没有人能保证这样的流程就是合理科学有效的，即使是当时合理科学有效的系统，由于我们身处的市场环境的变化、组织结构的随之变化、营销服务策略的随之变化，很难说能继续保持这种优势。一套好的业务流程管理系统不仅仅可以具备以上的诸多好处，而且随着流程的执行流转，系统能够以数据、直观的图形报表报告哪些流程制定得好，哪些流程需要改善，以便提供给决策者科学合理决策的依据，而不是单靠经验，从而达到不断优化的目的，呈螺旋式上升的趋势。

六、促进向知识型企业转变

       企业老板经常环顾员工下班后空荡荡的办公室，问自己我的企业还剩下什么，还值多少钱。而业务流程管理系统通过固化流程，让那些随着流程流动的知识固化在企业里，并且可以随着流程的不断执行和优化，形成企业自己的知识库，且这样的知识库越来越全面和深入，让企业向“有生命会呼吸”的知识型和学习型企业转变。如一个新进入公司的员工，他能够通过企业业务流程管理系统很快地熟悉企业及企业的业务处理，并且可以通过流程固化形成的知识库不断充实自己及提高处理流程的难度和水平。

七、实现和强化团队合作

       传统的职能式企业组织架构，自有它的应用范围和优势，但我们发现企业的很多流程不仅仅靠一个部门来完成，更多的是企业部门间的协同合作，特别是有些企业还存在着跨地域的合作，如采购流程，它涉及到生产部门、采购部门、库管部门、财务部门、商务部门、合同签署中的法律部门以及企业的高层管理部门。如果我们还以传统的职能部门的思维考虑流程，就可能患“近视眼”、注重部门利益忽视企业利益、重视部门上司的感觉忽视实效，并且还容易导致部门之间权责不清的灰色地带。而作为企业的业务流程存在着各业务部门的天然联系，其流畅的业务处理是需要各部门以企业的利益为最高利益，协同工作。

       业务流程管理系统以流程处理为面向，自动地串起各部门，即利用现在先进的互联网技术串起各地域，达到业务流程良好完成的目的，并且企业的很多高管人员的意识已远远超出一套业务流程管理系统，更多的希望凭借这样的系统，形成企业协同工作的团队意识，配合完成自己的企业文化。

题一：BPR实施是否结合我们企业的整体发展战略？

        企业改革不能为了BPR而BPR，应该结合企业的整体发展战略。因此，企业领导在启动BPR改革的时候，应该先问自己企业的整体发展战略是什么？BPR改革的目的是什么？希望实现的具体目标是什么？BPR如何支持企业的整体发展战略？只有搞清楚了以上问题，才能说企业实施BPR具有明确的目标和价值。

        在以往实施BPR的国有企业中就出现过盲目的问题，方案设计完毕时尚没有明确未来三年企业的整体业务发展战略以及根据市场预测期望达到的目标值，因此在方案设计过程中也就没有突出哪些改变重点结合了具体的改革目标。须知，设计方案的目标性不明确，犹如盲人摸象，这会直接影响到改革的效果。

题二：我们有无设计全员沟通方案？

       企业的领导人通常都认为改革成功的关键就在于是否将先进的管理方法和手段引入企业，但他们往往忽视了改革方案的有效执行也是改革成功的关键要素，而确保执行的一个重要手段就是沟通、沟通、再沟通。这是企业的领导人与员工思想互通的惟一途径，是发现问题、解决问题、达成共识的最佳手段。

        以往国内企业传统的沟通方法相对单一，更多的是遵循上传下达、服从上级，而比较忽视来自基层的声音。因此，科学的沟通过程应遵循自上而下和自下而上的原则，只有实现充分的双向沟通，尊重并综合来自各方面的意见和建议，领导人的决策才会更加尊重企业实际，更加具有可行性。

        研究显示，沟通遵循“3+7法则”，即对于同一信息通常只有30%的人完全接受，有70%的人只接受了部分信息。根据这一法则，领导人需要在不同层面、不同时间、不同地点与有关员工反复沟通，才能使同一信息多次刺激大脑，使员工充分接受，同时也才能真正理解来自员工的思想，最终做到思想统一、行动一致。
题三：参与实施BPR的部门领导有无切肤之痛？

       人们常说“痛定思痛”，只有企业自身真正感受到现在的痛苦，才会形成变革的强烈愿望，也才会痛下决心实施变革。BPR改革非常强调企业最高领导人的全力支持和强力贯彻，因为在改革过程中会出现一系列的阻力，例如由岗位调整带来的部门精简、人员下岗，由绩效考核指标带来的工作压力和收入减少，以及新业务流程在磨合过程中出现的部门冲突和不适应等等，这些改革过程中的问题都需要通过企业一把手的强力推进，顶住来自各方面的压力，把改革实施下去。

       因此可以想见BPR改革很大程度上是一项一把手工程，如果企业的最高领导没有切身感受到企业的病痛和改革的紧迫性，没有背水一战的必胜决心，很难将BPR改革坚持到底，那么改革的成果就会大打折扣，变成虎头蛇尾。

       当然，光有变革的主观能动性还不够，在BPR实施过程中应把工作层层分解到每个流程负责人的绩效考核指标上，并与激励机制相挂钩，做到不仅是企业的一把手，要让企业中的每一个人都把变革作为己任，并通过约束机制推动改革更加深入的实施。

题四：实施BPR的监控手段是哪些？

       BPR设计方案的实施实际上是一种变革管理，也是BPR改革成败与否的关键阶段，它要求项目执行者采取各种及时有效的监控手段推动项目沿着既定的轨道按部就班的实施。如果缺乏行之有效的监控手段，就容易造成执行力度弱、应付差事，监控松散、缺乏督导，最终导致改革流于形式，达不到预期效果或彻底宣告失败。

       在以往的国内企业BPR改革中，这样的失败案例已经屡见不鲜，究其原因，很多企业的失败都是由于没有在实施过程中步步严格监控改革进程，及时发现方案执行过程中的问题并加以解决或微调设计方案，往往重设计、轻实施，使理想的设计方案得不到有效执行，结果与成功失之交臂。

       在BPR实施中，一要明确实施的领导委员会，明确成员分工，将责任层层分解到具体责任人，并与绩效考核挂钩，使每位责任人兼负压力和动力，自身成为第一监控人；二要建立定期会议机制和确定与会人员，明确项目进度、每一阶段的具体目标的量化值和围绕目标所要开展的具体工作，根据每一阶段的目标值检查工作完成情况，再采取相应手段推进或改进工作；三要制定定期汇报材料的模板，使每一位具体责任人都能按模板中所需要的内容规范的向上级领导汇报工作进展；四要借助“第三只眼”，也就是借助咨询公司或研究机构从第三方的角度深入了解企业内部领导所不易察觉或基层不愿反映的问题并客观的加以分析，及时反馈给企业的领导，有助于提升改革的成效。

题五：有无借力培训实现观念转变、技能转移？

       由于BPR改革很大程度上是人员思想观念的转变，改革成功与否首先也在于从领导到普通员工的观念是否成功转变，因此实现思想转变最为行之有效的方法就是培训。培训必须有系统、分层次的进行。

       首先企业的领导层应向全体员工做改革动员，表明改革的势在必行，领导层的决心和光明的前景；BPR方案设计小组应分层次向员工传播BPR设计理念和思路，努力使员工从思想上接受先进的理念；第三方机构可以传授BPR管理理念的发展和进化，以及为企业带来的优势和发展前景，从第三方的角度使员工从心理上信服并接受改革。

       BPR改革不仅需要观念转变，还需要提升员工的业务技能，因此通过企业内部技能培训和学习国内外同行的先进经验，都能够提升员工的实战技能，增强面向市场的作战能力。

题六：CEO是否真心实意地推动BPR实施？

       如上所述，BPR改革很大程度上是一项“一把手工程”，也就是说企业的最高领导人必须全力支持改革的进行。在改革过程中自然会遇到来自人情、制度、利益等各方面的阻力和压力，尤其在国有企业，各种矛盾很容易就反映到一把手面前，这时企业的最高领导必须要当机立断做出明确的决策，他们的改革决心和态度对于整场改革的士气都是至关重要的。

       如果领导人自身对BPR还存在不解和质疑，势必难以强力贯彻，遇到困难和阻力时就会出现犹豫不决，甚至退缩，那么改革的道路就会更加步履维艰，终将走向失败。

       因此在BPR改革中，企业的最高领导人/CEO必须作为最高负责人，具备坚定的改革魄力和信念，才能带领整个企业在改革中从成功走向更加成功。

      如果企业领导人对BPR的实施一开始就认定是应付上级要求、当作一项任务来完成，CEO就可能心猿意马，不会充分利用BPR的实施从根本上提升自身企业的竞争力。

        企业信息化普遍现象——投入很高，收效甚微

        随着经济的高速发展，企业对于自身快速适应环境、高效运作的重视程度越来越高，毫无疑义的，信息化会企业带来了这些方面的积极转变。于是，越来越多地IT应用系统在市场上出现，从最初的财务管理、人事管理、进销存到今天的ERP、HR、CRM等等。这些系统的出现让企业管理者眼花缭乱，有些管理者不惜重金，以数百万甚至上千万的价格采购一套又一套的IT系统。然而，结果怎样呢？

      “现在很多企业或多或少都有一些系统和IT项目，但是，这其中有30%～45%在完成前就失败了，而且失败的项目还都是管理层所看重的关键项目。再有就是一半以上的项目都超出预算和进度200%甚至更多。……在一项调查中，超过60%的企业经理认为，他们已经错误地应用了购买的软件包，并且只有极少有收益甚至是没有收益。当失败发生时，直接的损失不用说了，在业务上的总的间接损失要多得多。”

——美国加州大学信息系统教授贝内特

       早期安装MRPⅡ约1000套，花了80亿元，算是交了学费。

——2004年国内某统计资料

        北京三露——联想集成、哈药集团——Oracle、广州标致MRPII、许继集团——Symix公司，都是中国早期著名的ERP实施失败案例。

BPM的应运而生

        对于企业信息化成功率低的情况，国际著名管理咨询机构、IT厂商、企业管理者一直在思考并探索着解决方案，相应的思想和产品也层出不穷。而在这些思想中，BPM以从企业的根本出发、结合企业当前形势和未来发展的思路和方法站在了企业应用信息化潮流的最前沿。

       国际著名评估机构AMR曾断言，业务流程管理（Business Process Management，简称BPM）已经成为2004年之后企业面临的重点课题之一；而在中国，远洋、联想、海尔、都在BPM领域迈开了最重要而又坚定的一步，海尔甚至为其BPM项目的实施而停止了14个正在和准备开展的信息系统项目。

       BPM为什么有这么大的魅力？它给企业带来了什么呢？对于这个问题，企业流程管理的大师、BPM的提出人August-Wilhelm Scheer教授在一次采访中给出了答案，他认为，BPM为企业带来了5 个方面的实际利益：

    （1）固化企业流程：

       初期，企业通过BPM 系统固化流程，把企业的关键流程导入系统，由系统定义流程的流转规则，并且可以由系统记录及控制工作时间和工作进程，满足企业的管理需求及服务质量的要求，真正达到规范化管理的实质操作阶段。

    （2）实现流程自动化：

       通过 BPM 系统，利用现有的成熟技术、计算机的良好特性，很好地完成企业对这方面的需求，信息只有唯一录入口，系统按照企业需要定义流转规则，流程自动流转，成为企业业务流程处理的一个“不知疲倦”的帮手。

    （3）实现团队合作：

        BPM 系统以流程处理为面向，自动地串起各部门，即利用现在先进的互联网技术串起各地域，达到业务流程良好完成的目的，并且企业的很多高管人员的意识已远远超出一套业务流程管理系统，更多的希望凭借这样的系统，形成企业协同工作的团队意识，配合完成自己的企业文化。

    （4）优化流程：

        一套好的BPM 系统可以随着流程的执行流转，以数据、直观的图形报表报告哪些流程制定得好，哪些流程需要改善，以便提供给决策者科学合理决策的依据，而不是单靠经验，从而达到不断优化的目的，呈螺旋式上升的趋势。

     （5）向知识型企业转变：

        BPM 系统通过固化流程，让那些随着流程流动的知识固化在企业里，并且可以随着流程的不断执行和优化，形成企业自己的知识库，且这样的知识库越来越全面和深入，让企业向知识型和学习型企业转变。

BPM带来了软件行业新的变化

        传统的应用软件从为解决企业当前实际问题的角度出发，整个应用系统的基础是以功能为导向，虽然解决了企业当前的一部分问题，但缺乏持续长久的生命力，反而随着企业自身的发展，系统不可避免的背上了越来越重的包袱，严重的，甚至阻碍了企业的业务开展和管理改进。

       自从BPM面世以来，越来越多的开发商们认识到企业运行的根本基础在“流程”，作为企业管理重要的支撑和改进的利器，信息系统需要以流程为导向才能为企业提供最贴身的服务、最优化的价值和长久持续的服务。

       基于此，软件供应商们纷纷在自己的软件产品和解决方案中加入了BPM的元素。国际知名的软件供应商如IBM、微软、Oracle和SAP都已开发了各自的流程平台，集成了WorkFlow（工作流）、EADE（业务功能快速开发环境）、EAI（企业应用整合）和Portal（企业门户）技术，为企业提供越来越完整的BPM服务。并且，这些应用也被越来越多的企业接受并应用。

       未来，企业信息化因BPM而很美

       BPM为企业信息化带来的转变是革命性的，当采用了BPM解决方案之后，企业将会比竞争对手更快的响应市场，更准确地把握全局，更及时地看到公司重要事务开展的全过程，更好的产品质量，更高的整体工作效率，更多的知识积累；将不用再担心信息系统跟不上企业发展的脚步，不用再担心信息化无底洞般的投入而没有产出。

       拥有了BPM，信息化将会真正发挥他应有的价值，为企业的发展贡献强大的助力。

       每天中午去外面某些餐馆吃饭，进入餐馆无指引，好不容易找到位置半天没人来点餐，点了餐半天不给上，让催下菜每个服务员都觉得跟自己无关，到处一片繁忙噪杂的景象，而效率却极低。这个时候，我们都在纠结于为何不把流程捋捋顺？
       我们有多需要BPM？
       业务流程管理（Business Process Management，即BPM）不是一个新概念，甚至不是一个新名词。它是从相关的业务流程变革领域，如业务流程改进（BPI）、业务流程重组（BPR）、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、EAI、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。
      现在很多企业从流程管理中获得良好的效益。据Gartner的一份研究报告显示，在成功的BPM项目中有78%的企业获得的内部报酬高于15%，而有一些企业的这个数据达到了100%甚至是360%。这份研究还发现在业务流程管理越来越重视相关人员的参与，而不仅仅是系统与系统的整合。此外，企业除了可以获得财务上的回报，通过BPM的实施可以减少错误，改进服务水平与增加业务流程透明度的能力。因此，Gartner预测BPM的热度会持续上升，并且会成为企业提升管理的投资首选，BPM能够为企业带来竞争优势。
       应用的好就能从BPM中受益，反之，就会成为企业的痛。花了钱不说，还让人们对业务流程梳理这一本来好的事情留下心理阴影。因此，对于有些企业来说，推行BPM势在必行。那么，怎样推行BPM能够收到比较好的效果呢？

      积极推行BPM策略时应当采取的五个步骤，一是确定BPM项目的轻重缓急，二是确定BPM试点项目，三是成立亲和团体，四是进行必要的组织变化，五是赢得企业上下的广泛支持。

        流程是企业扩大规模或转型的“痛”

  
     “很多企业信息化失败的罪魁就是流程梳理不畅。”业内人士董女士说。“就我们目前所售卖的软件产品来说，就要求企业事先对业务流程进行梳理。一些用的不是很好，究其原因就是因为梳理的不好。”

        一般来说，企业只有在转型或者规模扩张的时候，才会重视业务流程，并期待对它进行梳理。而平时，业务流程很容易被忽略掉的。梳理流程是要做的第一步，只有梳理通畅之后，才会谈及优化。而优化才是对企业业务支撑最有推动力的。
 

      “目前，国内对BPM的需求还是很旺盛的。”王甲佳说。但是用一套几百万的系统似乎又有点不现实，因为国内企业似乎并不情愿投入巨资改善流程，除非流程确实阻碍了企业的发展步伐。但也并不是说国内没有这种应用需求，在一些大的外资企业里，一些改善型的企业里，还有一些更新型的企业里，会对BPM的需求迫切。
 

       在进行流程梳理时，国内企业一般会成立一个临时的流程小组来协调各部门对这项工作的配合和支持，而一旦流程梳理完毕，这个小组也就解散了。很少有像华为有专门的流程部门，或者合资企业有所谓的管理部。
 

       “流程梳理和优化是一个持续的系统化过程。通常要建立、简化、优化、固化这样一个过程，并且固化也不是一成不变的，而是相对企业的发展而言的。”马龙说。
 

      “阳光中的失落”在微博中提到，流程是制度的延伸，我认为BPM要发挥功效，有两点需要考虑，一是根据原有的制度，写出符合企业现实的流程，二是根据企业管理特点结合及国际化管理思路，给出符合企业需要的流程再造。
 
      流程是否需要实时动态调整？

 
      流程是否需要随时动态的调整，还是需要对调整好的流程固化下来？固化下来的流程是否需要二次调整？周期有多长？事实上，在目前的市场上，既有单独的BPM流程产品，也有固化在其他业务流程里的流程，那么，我们该怎样选择？

      “固化在系统的流程最大的优势就是省钱，同时它的弊端就是无法支持对新的系统的控制要求，无法快速响应新的流程变更需求，另外，它根本无法实现对系统间流程的控制。”美拓暴风说。

 
        我们刚才说了，一般对流程梳理有迫切需求的都是规模扩张型企业和大中型企业，他们一般“不差钱”，那么，是不是说，我们除了现有固化在某些业务系统里的流程之外，我们要支付额外一套流程梳理及优化系统，以满足企业敏捷发展的需要？

  
      “国内企业一般对流程梳理的意识不明显，而且他们也不愿意经常变化，对于梳理好的流程，他们还是希望能够固化下来一段时间。”王甲佳说。只有企业的核心价值链变了，一般才考虑对业务流程的变更需求。和当前市场情况对比，企业战略变了，导致业务逻辑变化，业务逻辑的变化导致业务流程的变化，而业务流程的变化将导致作业标准的变化。

  
       流程的变更，最终会牵涉到人员，以及利益的重新分配。值得一提的是，一般在一些大中型企业，明面上的组织架构并不能真实的代表企业的组织架构，都存在一个所谓的“隐性组织架构”。如果隐性组织架构搞不清楚，一般很容易失败。

1.  不能跟Exchange直连，无法自动化创建会议邀请
2.  不能无代码实现80%以上人工类流程
3.  不能与某个文档处理系统集成
4.  粗劣的统计和分析系统，而不是全面的业务流程考核
5.  流程和制度并存
6.  无法清楚地度量出出每个岗位为客户提供的价值
7.  我们的流程系统只为某个部门、或者某个业务服务

那么，表示这个企业的IT落后于中国企业的平均水平至少5年。

        市场很多供应商从最初的OA厂商而来，后来发展出了工作流系统，现在已经进入BPM时代。现在的技术，我们已经远远跨过了OA工作流的范畴。BPM是一个成熟的概念，未来将会有哪些可能出现的趋势，让我们在这里讨论下……
 

  1 科技汇聚——融入云适配器

        今天，主流的BPM已经成功地跟SAP、Exchange、K3、Siebel等系统集成。我们可以享受BPM套件给我们带来的便捷，BPM可以自动为我们在Exchange上创建“会议邀请”、与手机同步、自动生成“入库单”、运行SAP的“MIRO”……
       在不久的未来，在2015年以前，BPM将需要融入许多新的技术，比如：社交类网站、云计算等。事实上，在欧美，银行的IT系统已经与FaceBook等社交类交互网站；在中国，SAAS也开始为最需要保密的银行业提供解决方案。可以想象，一些大型的企业，甚至超大型的企业，可能在后台跑着SAP，前端的销售人员每天用着Salesforce，同时使用各种博客、社交网站与客户维持自己与客户的关系。事实上，我们已经看到大量的银行、保险代理商、管理咨询公司、律所等行业在使用博客和社交网站来进行宣传和营销，很明显我们的流程也将需要覆盖到这些领域。
 
2 动态的BPM

        BPM不像ERP，ERP一个标准成本的算法实施下去，可能几年都不会变；BPM则完全不同，可能这个月流程还是这么跑，下个月则可能连组织结构都变了。BPM最基本的要求就是要支持这种变化。实际上，这种对于变化的要求给BPM套件带来如下挑战：

1. 组件化：支持动态装配和卸载
2. 支持变更管理：包括完整的日志和符合塞班斯法案的变更管理
3. 贴近业务，支持快速的变更，而不是要写一大堆代码来实现某个流程
 
3 BPM变成长期IT投资

        今天，我们很多客户使用工作流套件来做OA应用。这种IT投资大都是短期的，平均投资周期是3年，一般最多不会超过5年。这种应用的是缺乏深度。

        现在越来越多的企业，已经意识到，行政类流程应用已经完全无法取得竞争优势，他们需要的更强大、更自动化的BPM套件，BPM套件将作为整个企业的基础部件之一存在于企业IT基础架构之中。这使得BPM投资将是一项长期投资，这对CIO来说，将会带来非常大的挑战。比如，我们有一系列的流程是与SAP集成的，现在公司要将MySAP 4.6升级到ECC 6.0，如何来进行平滑的升级；如果整个迁移项目周期非常长的情况下，这会新增哪些挑战；如果把BPM作为基础组建，BPM与各业务系统之间的关联关系管理，将会是一个非常复杂的工作……
 
4 更强的配置功能

      这是一个显而易见的趋势，更强大的配置能力意味着低实施成本、低维护费用和高可用性。很多功能，虽然通过代码是能够实现的，但是这意味系统是难以维护的，这会给业务造成不可估量的潜在风险。
 
5 企业间集成

       企业间系统集成，并不是简单的系统接口调用。这涉及到法律法规、数据的有效性验证、核算、自动化支付、实时性、业务监控等技术。
事实上，在中国国内市场，奥哲科技在为某上市公司实施自动化采购的流程中，就已经考虑到B2B的应用，并为该公司提供了整套的B2B技术方案，这包括：电子询价、带电子签名的电子合同、电子发票等。该类型方案，从业务、法律、供应链道口技术，在中国国内已经逐渐成熟，并在部分大型企业中应用。
Gartner估计2014年，35%的BPM应用将需要采用跨企业集成的方案。
 
6 以客户为中心的量化流程评估系统

        要实现流程改进，就要进行流程评估，尤其是图形化的评估系统。企业越来越需要按照产品、地区、组织、岗位、流程等多种维度来评估业务流程的效率。

       在整个公司实施了全面流程管理之后，企业就有能力去分析每个组织、岗位、员工为客户提供的价值。
Gartner估计2009年有6%的企业使用这样一个工具，2014年将增长到40%。

        事实上，这是一个非常具有挑战的话题，如何建立一个适合各个行业、各种业务的评估标准是件在管理学上还没有完全解决的问题。
 
7 集中化后时代
 
        在过去，我们看到一些集团企业，不同地区公司自建系统，或者不同业务采用同类型的独立系统，这给业务分析、改进和维护带来了巨大的麻烦。系统大整合的时代已经来临，在某些行业，比如银行业和保险业，大型企业已经完成了整个，现在已经开始了整合应用阶段。

        跨地区和跨业务整合对于BPM来说是一个挑战，如何让不同组织结构、不同业务逻辑、不同业务标准的一系列业务在同一台服务器上运行？
 
8 分层的流程模型

       无论厂商如何宣称无编码建模，但是事实已经证明，业务人员是不可能无编码建模的。业务人员与BPM模型之间的界限如何跨越？通过分层的流程模型。分层的流程模型还能够是为不同层级的流程制定专员提供特定的视图。
 
9 实时企业

        随着竞争的加剧，我们越来越多的客户要求提供实时性的解决方案。实时不但意味着系统是7×24的，而且意味着从流程跟踪、查询、跨系统同步、报表、KPI计算、佣金计算都必须是实时的。

        这在流动性非常大、市场变化非常快的的企业是必须的。典型的代表是房产中介类公司，一个新的政策可能会让一个中介公司瞬间关闭掉大部分门店，也可能会让一系列的贷款审批被取消或者调整……
 
10 人工、系统、文档和规则的大整合

        在过去，某些BPM善于系统间集成，他们在异构系统中传递消息和数据，但是人工交互能力很弱。另外一些BPM善于人工交互，尤其是从OA发展过来的BPM系统。还有一些BPM擅长于文档应用，比如：为设计院服务等。现在，逐渐开始兴起规则型BPM，这类BPM在保险公司和一些国外的石油公司大量采用。
从市场规模来看，从大到小排列依次是人工型BPM、系统型BPM、文档型BPM和规则型BPM。实际上，从BPM的发展顺序来看，也基本是符合这个顺序。

        目前，人工型BPM、系统型BPM都已经非常成熟，无论从性能、安全性、交互性、可配置性和可维护能力都已经非常成熟。文档型BPM方案方面，文档的安全性、格式转换、搜索、各种接入方式都基础功能都已经很成熟，但是对于符合业务需求的知识管理方案，则非常匮乏。规则型BPM，在某些特定领域也已经非常成熟，尤其在保险行业，整个解决方案和产业链都已经很完整。
很明显，这4类BPM系统将在未来进行全面的大整合。

        很不幸的是，在许多的软件开发和系统设计中，企业 “随需应变” 的要求并没有得到很好的满足。这也不能完全怪企业的CIO目光短浅，因为很多企业不断减少自己的IT预算，而要求却是大幅增加，企业的IT系统能够维持目前的现状已经是很不错了，哪里还有什么精力和资源去满足“随需应变”的要求呢。问题也不是程序开发人员的技术不能达到企业项目的要求，而是在于现在通行的软件开发（或者升级）模式根本就没有办法满足现代商业环境所提出的要求。

        具体的情况我们接下来详细的说明。传统的软件开发都是建立在这样的模式上面的：从用户那里把需求都收集在一起，制定满足这些需求的计划，并且在软件开发的过程中得以实施，然后通过结构化的设计模式和软件程序变更的方式来进行调整，以满足新的需求。但是这种传统的软件开发模式已经不能满足新环境下企业的需求：

        传统的开发模式不能全面地、正确地定义这些企业的需求，因为企业的需求是在不断变化的（一般来说，并不是企业自己要不断更改自己的需求，而是他们所面临的商业环境的变化迫使他们不得不做出相应的变化）；

        在高度不确定的环境中，企业甚至有可能在软件设计还没有结束的时候就要改变整个系统；出于紧急需要，变化的要求会不按平常规定的时间提出；

        面对激烈的竞争和不断变化的环境，企业几乎不会提供什么额外的设计时间或者计划来创建更多的参数选择，本来这些参数选择可以让业务部门能够有效的对系统进行调整而不需要IT部门的协助。

        事实上，企业及其IT系统面临的最大的挑战来自于企业的业务流程。所有的人都希望自己的系统能够自动的调整并且不断优化自己的流程，但是不考虑自己的流程是否内置于传统的应用里，还是为企业某功能（例如客户管理）定制开发的单一流程。

       对于企业的流程来说，高度的不确定性是其最本质的一个特点之一。现在，大多数企业的流程已经成为业务环境中的一个组成部分，这并不是企业经过周密的计划得到的，而仅仅是对做好事情的一个自然的反应。企业的流程一般都是贯穿于企业的系统之中的，通过流程加强系统与企业中的个体员工之间的联系。并且流程通常都是按照一定的规律来进行调整以便满足新的客户和新的业务环境的要求。对于开发人员来说，流程的这种改变并不像他们改变数据库查询条件那么简单。相反的，这些改变可能是关于工作的顺序以及由谁来负责完成的变化。事实上，企业对流程的关注可以从市场上流程平台——BPM产品热度的上升可以看出。
        有些人认为BPM是一种纯粹的业务模式，是指企业把自己的业务围绕关键流程组织在一起。也有一些人则认为BPM是一种技术，一种可以为流程建模、自动化、管理和优化的软件技术。我们认为，BPM是这两种概念的集合体，而不是仅仅代表其中的一种意义。

        BPM是业务（business）、流程 （process） 、管理 （management） 三个英文字母的首写字母的组合，但是对于不同的人来说却是意味着不同的内容。有些人认为BPM是一种纯粹的业务模式，是指企业把自己的业务围绕关键流程组织在一起。也有一些人则认为BPM是一种技术，一种可以为流程建模、自动化、管理和优化的软件技术。我们认为，BPM是这两种概念的集合体，而不是仅仅代表其中的一种意义。另外，BPM还代表了一种新的、可以产生满足企业“随需应变”的流程应用的方式，它让IT部门与企业的业务团队更加紧密的协作。而这一点正是众多的BPM成功的一个关键因素。同时，这也是我们很多人忽略的一个关键。

        一些企业因为具有很有远见的领导或者是因为幸运，成功地实施了很多具有高价值同时又具有高度适应性的流程。而其它的一些企业在传统的IT模式下面进行BPM实施，只得到有限的成功或甚至失败。为了更好的理解这些挑战，我们需要进一步来探讨BPM技术。

        BPM技术的核心是通过软件来管理企业的业务流程生命周期。它要求建立一个流程模式，通过这流程模式的实施，产生流程应用，使工作得以在系统和员工之间流转，并且通过这模式来管理运转中的流程应用，和在使用时对流程应用进行优化——无论是改善企业的核心流程或者是因业务条件变化做出调整。在流程生命周期的不同阶段，大部分的BPM解决方案都支持业务部门的参与，最普遍的就是它可以让业务部门开发出一个最初的流程模式，然后通过企业的IT部门来进行实施。

        一些BPM系统能够把企业流程生命周期管理的能力从IT开发部门转移到业务部门的用户手上，使得业务部门变得更加敏捷。一个很好的例子就是规则，在企业的业务流程中，规则是最常用的手段，企业可以用它来管理任务的分配以及执行的顺序。有一些规则，企业会常常使用，也有一些规则只会在一些特别的环境中应用。但是，它们通常也会不断的变更。一般来说，这种改变可能会是很简单的，例如“为某一个特殊的客户省略这检查的步骤”。在变化的过程中有一个原则是不会改变的，导致规则变更的原因都是来自于业务的特殊需求，所以，让业务部门的员工在管理流程的变更上承担更多的职责，这对于企业的IT和业务来说都是非常有利的。

        事实上，一个能支持对运营中的流程做职责分配的BPM系统， 为企业加强IT部门与业务部门的合作关系提供了很好的机会，可以加速流程实施、部署的速度，并且可以减少大量的开发要求，这些要求所导致的工作对于软件开发人员来说既不是一个挑战也不是一件激动人心的事情。但是要想很好地利用这种机会，关键在于理解企业业务流程的关键组成部分，企业需要确认适当的资源来管理那些关键组成部分，同时还需要组建一个由业务流程人员和IT专家们组成的BPM团队来贯彻执行。这些工作对于软件开发人员来说，他们可能不怎么感兴趣，但是如果分配给业务流程人员则可以大大增加业务的敏捷性。

        另一方面，Web Services（面向网络服务）以及SOA（服务导向架构）的发展可以让企业的业务“随需应变”，但是如果IT开发人员仍必须不断地以改写代码的方式来处理流程的规则、角色以及基本步骤的定义等等，“随需应变”的目标是不可能达到的。如果真的是那样的话，企业的业务敏捷性就取决于系统开发人员“to-do ”的单子的长度了，清单越短，业务才会有越高的敏捷性。业务人员有能力对流程的一些部分进行控制，企业的业务流程才能获得更高的敏捷性，同时IT开发人员的“to-do”单子才能更创新和有趣。 总之，现在企业的IT部门面临着为业务的持续性变化提供支持的压力，而且这个压力越来越大。BPM技术可以给IT部门满足上述目标的能力，同时还可以改善IT部门与企业业务的关系。当我们评估BPM技术的时候，一个非常关键的考虑是BPM 系统对职责分配的支持能力，满足企业组建一个BPM团队，一个其成员具备各种各样的能力，包括IT开发人员、业务分析员和业务管理人员的BPM团队。而且一旦人员到位，到底确认谁对流程的哪些方面的贯彻实施和变革负责就应该成为一个纯粹的商业决策，取决于资源和目标，而不应该受到技术的限制（例如，业务部门应该管理规则，但是在现有的系统对规则做改变对业务部门人员来说是太困难了，所以还是由IT来管理规则吧）。那些在这样的共享模式下运营的企业已经看到了巨大的利益，包括提供高商业价值，减少定制开发；更快的响应业务的需求，降低流程部署的风险；并且在企业内部提升了IT部门的地位。

        如果说可以将常见的有关业务流程管理的专家建议归结为一个简洁的成功定式的话，这个定式也许看起来会是这样的：BPM+CoE=A+。

　　当然了，CoE指的是“卓越中心”（这个缩略语还可以代表能源成本、工程总指挥、现金营运开支或者“早点离开”，但在BPM世界里，还是第一个意思用得最多）。

　　众口难调，尽管很难找到一个大家都满意的CoE的定义，这样的中心通常都是用来设立标准、定义最佳实践、提供BPM工具和模板，进行支撑并作为指南、专家知识以及技巧的来源。

　　为什么要关心卓越中心？

　　因为它们有效。实际上，Forrester研究公司把CoE称为最佳BPM行动的“秘密武器”。“我们已经找到了卓越中心与BPM成功的关联关系”，Forrester 研究公司的副总裁与研究主任Connie Moore说。反之亦然，她说：BPM的失败通常会伴随着卓越中心的缺失。

　　特别地，在Forrester的一项调查中，67%的调查对象报告说从他们具备正规CoE的BPM行动中收获了清晰和可衡量的好处。而在报告BPM失败的人群中，只有14%者拥有此类中心。

　　“把你的核心业务流程改进技巧放进一个集中化的组织里面，过分强调其重要性是很难的”，她说。最终，一个CoE能帮助组织进行流程技能的改善和扩展，从而也能加快接受BPM的步伐。

　　在布道宣扬CoE的价值的阵线上，Forrester不是一个人在战斗。Gartner的分析师同样提到了创建CoE并选择适当的专家去领导该中心，把它当做BPM的最佳实践。埃森哲的流程架构部门的资深经理Asim Akram把CoE描述为BPM短期活动与战略性的、长期方针之间的桥梁。

　　“尽管很关注战术需要，组织却有忽视某些领域的倾向，包括流程所有权和治理、角色和职责、服务水平及标准等一切与任何流程活动有关的东西”，Akram在最近为BPMInstitute.org撰写的一篇文章 中写道：“BPM卓越中心在这一切领域都能有所帮助”。

　　如何开始，何时行动

　　创建一个CoE无疑是件重要的工作，但不尽然就得是一件庞杂的事情。Moore说：“我认为有时候我们把它弄成了这样一个可怕的东西，但它不是说就得这样的”。

　　在引入你的CoE之前，有些专家建议首先成功实施三两项BPM行动。其思路是：那些早期的成功将能帮助该中心梳理出案例，并影响到那些非常重要的企业赞助商主管，或者说你可能业已实现的东西能打消其犹豫不决、有所顾虑的东西。那些首次行动同时还可能令你得到CoE的初始员工和资源。Moore解释道：“你的首个项目及其工作团队可以转换成卓越中心，然后你就可以根据需要对其进行扩张，这取决于你的BPM计划的大小。”

　　一家小公司或者对BPM不熟悉的公司也许只需要2到6人参与到CoE就够了；一个大型的组织或有多项大规模行动者则可能需要数十个参与者。专家说，高效的中心包括有业务和IT专业人士。初始的CoE可能会包括有几名开发人员、一个业务分析师、一名企业架构师，可能还有一位BPM工具方面的专家以及一位CoE经理或主管。另一方面，一个全球化或高度离散的组织也许会有多个CoE，每一个CoE都拥有自己的专门的员工。

　　中心应当集中化而不是相互隔离，专家说。CoE的员工不仅应该相互协作，还要跟参与BPM行动的业务单元的员工进行协作。这样做为中心提供了更宽广的知识和专家经验范围，有助于在整个更大的组织范围内传播流程技巧。

　　最后我想说的是：某些公司发现自己可以通过转换或扩展一个已经在用的、由员工运营、为员工所熟悉的资源来创建CoE。考虑一下TD Banknorth这个例子，该机构是一家大型的北美银行和金融服务公司，希望在整个组织范围内扩展其BPM的应用。

　　据Forrester在该项目的一项案例历史，TD Banknorth已经在维护着一个集成能力中心（ICC），可帮助管理各类遗留系统的集成。在其技术副总裁及SOA企业架构师的领导下，TD Banknorth成功地将ICC转化为BPM的CoE。利用已有的资源“最终减少了文化的改变以及与此类改变有关的混乱的产生”，Forrester研究公司对此作出注解。因此好好看一看你的组织吧：你的卓越中心的基石也许已经搭建好了。

　　企业和云目前处在什么样的位置？

　　Kaplan：正如你可能意识到的那样，进出任何机场你都不可能看不到兜售云计算商业好处的横幅广告或别的什么展示。

　　实际上，这一术语是如此的流行和普遍，以至于苹果已经付诸行动，推出了iCloud，此外还有各种其他面向客户的解决方案是推销“云”这个术语的。跟在企业世界的增长一样，这一术语的流行已经帮助了其在商业世界的发展。

　　所以我们看到企业无论规模大小都很感兴趣。几乎每一个市场研究机构都确认了这一点，即其调查中高达75到85%的企业高官对采用某种基于云形式的服务来帮助其实现企业目标感兴趣。

　　公司在寻找和走向云的时候所面临的一些最大障碍是什么？

　　Kaplan：很难全盘托出。因此对于许多公司来说其首要问题是定义什么是云，以及因此云能够为我们做些什么。

　　当然，第二个问题则是围绕着云安全和数据隐私方面的。那个问题仍旧萦绕在市场的心头，尽管尚未有任何已知的对主要云供应商产生影响的重大入侵事件的发生。

　　不过我担心的是，由于缺乏云相关的控制， IT和业务决策者的确有理由担心，或者至少是不能够确定在数据保护和数据隐私方面云究竟意味着什么。

　　下一个问题是必须要处理好可靠性。过去一年间，像Google、Amazon、微软乃至于Saleforce这样卓越的公司都出现了两三个值得关注的服务中断，在有限范围内的中断。不过其运行中断和服务中断只会带来困难，在大多数情况下，跟多数组织运营的重大中断是截然相反的。

　　不过，对于大多数组织来说，最重要的问题是一旦你开始实施之后，就要面临着集成的问题。他们试图将这些服务集成到已有的运营当中，试图接入到传统的系统和数据源甚至应用里面。因此集成可能仍然是当前企业环境当中最突出的实施实践障碍。

　　你怎么看云对于BPM本质的改变？

　　Kaplan：BPM正成为为改善组织内部的业务流程而部署云解决方案的其中一个最热门的领域。

　　这并不是说现在但凡采用[Software as a Service （SaaS）]或别的基于云的应用，其原因就是为了改善内部流程，不一定。仍然有相对少量的BPM应用被当做SaaS或云解决方案来兜售。相反，我们所见到的，是BPM被嵌入到越来越多的各种企业应用当中，因为那些情况下的SaaS或云供应商意识到BPM是应用部署成功之必须。

　　我给你举个例子。在提供CRM解决方案和服务管理解决方案时，Salesforce.com意识到，有一个嵌入式的BPM工具帮助治理其主要应用职能对于他们的企业客户来说越来越重要。因此，他们把BPM的嵌入在CRM和服务管理平台中铺开，以确保那些应用部署不仅能在那些组织内部增强且还能改善BPM。

　　云会如何改变组织使用BPM的方式？

　　Kaplan：它在组织内正变得愈发无所不在。BPM过去常常是主管才会去关心和干涉的东西。现在，由于它嵌入到了应用本身里面，且由于那些应用在用户中的可达性更广，在业务经理的可见性更高，能够在共享使用活动级别和行为模式的信息，这使得人们不仅能够更好地管理业务流程，还能够更好地评估其效能。

　　因此，随着BPM工具在各种规模的企业中变得越来越普遍，那些企业就能够以一种更加有效的方式来跟踪行为，报告性能，并因此改进那些业务流程。

　　随着时间的推移，BPM工具供应商将能够找到将数据融合进客户群的方式，并提供统计指标数据供公司用于与对手的比较—当然，那些家伙担心的私有数据不在考虑之列。

　　你对云及云端BPM的前瞻还有哪些？

　　Kaplan：我认为我们即将看到其更多的快速增长，总体基于云的解决方案也会更多。随着这一领域的BPM开始走向成熟，以及第一波的成功故事的流传，那些早期的成功会充当其他人学习的典范。你将会看到更多的企业高管寻求复制那种成功，也会在自己基于云的BPM部署上面跟进。

　　因此我们在这一市场会出现加速，真正变得更加主流，通过从这些解决方案中提取出最佳实践来帮助赋予新用户更多的采纳这些解决方案的信心。

　　现在一种普遍的理解，即把BPM理解为一个IT术语或一类 IT产品，这是不全面的。在BPM中，业务应当占据主导地位，软件或说技术占辅助地位。从业务角度说，完整的BPM应该覆盖企业战略管理、战略流程定义、业务构建、业务流程定义、业务服务定义和编排、业务执行和监控、业务流程优化改进以及战略调整等几乎企业管理的方方面面。从IT角度说，BPM所集成的一系列软件和专业技术要能够支持上述的业务生命周期落地。最重要的是，这些软件和专业技术必须是面向业务人员的，即要由业务来驱动BPM的建设，由业务人员来主导整个业务流程管理体系的建立，而不是由IT来驱动。

　　BPM市场和产品的混乱

　　与其他革命性的IT变革一样，我们需要从方法、架构和实现技术三个方面去理解和掌握BPM产品。

　　方法对应产品的设计目标企业的管理理论和相应的实施方法论，架构意味着对软件产品的设计如何匹配设计目标，实现技术则意味着采用何种IT技术去实现相应的设计目标。三者缺一不可，然而长久以来，人们习惯于用实现技术去分辨和解释BPM，以至于到现在为止，人们仍然无法正确理解BPM。由此也造成了BPM 市场和产品的混乱。

　　其实这个问题并不是BPM独有的。举例来说，笔者在培训面向对象的分析和设计方法时发现，相当大比例的程序员，即使他已经工作了很多年，即使他拥有丰富的项目经验，同时也精通一门或多门面向对象的语言，但实际上他们却没有真正地掌握面向对象的方法。掌握面向对象方法的关键不在于是否采用了面向对象的语言和工具(如UML)，也不在于是否掌握了面向对象的编程技巧(如设计模式)，而是从需求到分析设计，再到编码实现，你是否真的在用面向对象的思维去思考。

　　SOA也面临同样的问题。是否掌握了SOA，其关键不在于是否采用了支持SOA的应用架构(如 WebSphere Application Server)，也不在于是否把某些代码逻辑封装成了符合SOA规范的服务(如Webservice)，而是，你是否真的采用面向服务的方法去分析需求、设计架构、抽取服务，把业务服务化。从项目开始到结束的整个过程都应该是面向服务的，而不仅仅是针对产出物的。

　　回到BPM产品上来，如 果仅从实现技术去理解，人们就会陷入这样的混乱： BPM与工作流有什么差别?都有流程引擎，都可以自动化运行，都有流程编排器，也都能对流程进行监控。凭什么工作流就不是BPM?如果辩解说BPM比工作流能做更多的事，比如服务编排和集成，那么也可以辩解说只要是开放的通信标准，不论是WebService还是JMS，工作流同样可以集成第三方服务，BPM可以做的，工作流同样可以做到，无非只是技术实现的方式不一样而已，并没有本质的差别。你还可以争辩说BPM是面向业务的，而工作流不是，但你如何解释什么是业务?难道BPM里一个审批申请的活动是业务，工作流里一个审批申请活动就不是业务?什么道理?

　　看，一旦陷入这样的技术细节比较，就是比上个三天三夜，吵个天翻地覆也不会有结果。

　　从方法和架构入手

　　要辨别一个产品是否是BPM产品，我们还是得回到方法和架构上来。我们得承认这样一个事实：业务驱动架构，架构驱动技术，而不是相反。判断一个产品是不是真正的BPM，应该从源头往下看，看它的设计目的是不是为了解决业务流程管理，看它的架构是不是从业务流程管理方法论当中推导出来的，是不是符合业务流程管理方法规范，其针对的用户是不是业务用户。而不是看它是否包含了BPM的某些技术特征，也不是看它是不是能做到一些BPM声称应该做到的事情。

　　一方面，技术的堆砌无法形成架构(技术架构必须指向特定的业务领域，解决特定的业务问题)，拼凑出来的所谓架构也无法完整的解决业务问题。能够做到某些事情并不表示它就是解决这类问题的恰当的工具，比如，扳手和锤子都可以用来砸钉子，但扳手本身不是锤子，二者被设计服务于不同的业务领域。另一方面，同样的方法和架构允许不同的实现技术。例如，如果你的架构就是要解决砸钉子的业务问题，由于某种原因无法使用锤子，必要时，你可以把扳手集成进来，作为一种可能的实现技术。

　　这有两层含义。其一，某种技术手段的加入不能决定或改变其所针对的业务领域，更不能改变其本质。上述例子中，扳手是为砸钉子设计的，其设计目标并不会因为产品具备了扳手的某些特征就变成了修水管的工具。因为扳手在这里明确地指向砸钉子的业务问题，产品会忽略掉其他与砸钉子无关的扳手的其他特征。其二，不能因为某项技术最终解决了某个业务问题，就认为该项技术就是针对该业务问题的正确工具。上述例子中，在解决砸钉子业务问题的工具里，扳手是一种可能的实现办法，但它仍然是扳手，不能够说因为扳手也可以砸钉子了，所以它就是锤子。

　　我为何要如此纠结于一个产品到底是不是真正的BPM呢?只要能解决实际问题不就行了吗?我要如此较真的原因在于，业务驱动架构，架构驱动技术，这是一套符合科学方法的体系：首先提出问题，然后分析问题，最后解决问题。从方法到架构到实现，它是一套自洽的、能自我发展完善的体系。随着问题的深入和变化，整个体系也会随之修改或者进化，但始终是一套完整的处于相应理论指导下的体系，直到该问题不再有价值时被抛弃或者被另一套更好的体系或理论所替代。在整个产品生命周期中，其目标始终清晰、体系始终完整、进化始终有序。所以，如果它是真正的BPM，意味着该产品会随着整个BPM理论和体系进化，获得稳定的、可靠的升级和改进;如果它只是披着BPM的马甲，通过勉强的改造或挪用某些技术手段去解决BPM的问题，则意味着该产品无法针对业务流程解决方案提供有效和持久的改进。因为对一个软件来说，如果一个软件设计的最初目标与应用目标不符，而硬逼迫它往应用目标变更和定制，该软件必然变成打满补丁的袍子，总有一天它不但再也无法解决这些业务问题，恐怕连它的本职工作都无法再胜任了。

　　是，还是不是BPM，真的是问题的关键!

　　BPM产品甄别标准

　　BPM的设计目标决定，BPM是一个IT工具，必须要和企业运营紧密结合在一起，是企业管理运营的直接映射。企业需要的是可以直接将业务变成可执行流程的技术，需要由业务人员直接建立、管理、优化流程，希望流程管理系统建设后可以直接在执行过程中监控企业绩效，更希望企业的战略意图可以直接与具体的执行层联系起来。

　　要满足这样的需求，BPM工具必须彻头彻尾地面向业务人员而不是IT人员，用业务语言去建模而不是IT语言，由业务人员驱动BPM的建设而不是IT驱动。换句话说，如果有一个所谓的BPM产品，它被设计为面向IT人员，靠IT人员定制开发而不是业务人员建模，它的设计无法对接企业战略和执行层面(是否对接战略和执行的简单判断标准是，是否能够说明和测量流程中的某一个活动针对哪个战略目标，某个实例贡献值如何)，它的设计是针对业务执行问题(需求从基层来)而不是业务管理本身问题(需求必须自顶向下)的，即可怀疑为伪BPM或说是不完整的BPM。最容易混淆的便是工作流与 BPM、OA与BPM、ERP与BPM。

　　非针对BPM的设计带来两个明显的局限，其一，系统的建立尽管使得工作效率有所提高，但对于衡量企业的整体绩效来说，这些系统内容是一个黑盒子，无法在执行过程中监控并得到企业整体绩效乃至战略的反馈;其二，由于架构和设计的方向不同，业务人员被排除在流程的建立、管理、监控、调整之外，必须通过IT人员来进行。这使得业务敏捷成了一句空话。

　　总结下来，辨别一个产品是否是真正的BPM产品，可以从以下几个关键特征出发：

　　1.该产品是否具有极强的导向性，面向价值增值(战略目标)而非仅仅实现当前业务。

　　此特征意味着每个业务流程和每个活动都可以明确地指出其针对的战略目标，并可以用指标衡量其价值贡献(相对于战略目标)。BPM的建设成功与否可以用企业最为熟悉的商业价值评估体系来评判并优化调整。

　　如果一个所谓BPM产品不能够直接实时地提供业务执行时对战略目标的贡献值，仅能够提供IT级别的运行测量结果，或者只能通过滞后的报表统计，再通过诸如BI工具等来估算业务效益。它将无法支持BPM的价值。

　　2.该产品是否以端到端的业务流程为中心而非仅仅用于实现局部业务。

　　此特征意味着流程梳理是BPM建设的前提条件。BPM实施的同时必然带有流程梳理、测量、优化或改造等活动，基于片断化的、局限于部门内部的所谓BPM建设难以获得BPM带来的价值。

　　如果一个所谓的BPM产品从建模到实施到管理，仅需要或仅支持局部的业务需求，在必要时，只能通过其他技术手段(如WebService、JMS、 Rest)来与其他部门或系统做散列的点状集成，而不是像真正的BPM那样需要端到端的流程梳理结果作为必要条件，在建模过程中没有所谓的“与其他集成” 的概念，所有活动都是端到端流程中一个自然的节点。那么，它将无法支持BPM中的战略落地。

　　3.该产品是否由业务人员驱动而非IT驱动。

　　此特征意味着业务人员的角色将不只是单一被动的需求提供者和业务流程执行者，还将是更积极主动的业务流程构建者、业务流程监控者、业务优化者和业务流程管理者角色。

　　如果一个所谓的BPM产品仅面向IT人员，业务人员不能深度参与业务流程建设，只能将业务需求翻译为IT语言再实现，那么很难做到IT资产与真实业务流程的高度同步。该产品将无法支持BPM的业务监控、改进、优化等管理需求。

　　4.该产品的流程实现是否支持粗粒度的服务编排而非从头定制开发

　　此特征意味着BPM产品必须支持通过编排粗粒度的服务集成并整合利用企业资产(包括IT和非IT)，以快速、敏捷的建设和变更业务流程，从而有效支持业务敏捷和业务改造。

　　如果一个所谓的BPM产品在项目中需要大量的定制开发，其架构不支持服务编排或者只能通过外挂的标准协议调用服务而不是架构的一个有机整体，那么它将无法支持业务敏捷和快速的业务改进。就目前IT界的技术来看，产品是否全面支持SOA甚至直接架构在SOA上，是判断是否符合此特征的重要依据。

　　解决哪些核心问题

　　真正的BPM需要提供面向业务人员的业务流程的建模语言、建模工具、管理工具和监控工具;需要屏蔽掉业务人员弄不懂的IT语言与实现;需要强大的集成能力可以贯通分散于各个业务部门各个平台上的异构系统以实现企业整体业务流程管理和绩效监控;还需要业务流程当中的活动可以与企业战略挂钩，使得业务流程的运行直接反馈战略执行状态。

　　因此，一个真正的BPM软件要解决的是以下一些核心问题：

　　1.BPM必须横跨业务和IT 两个部分。它必须很好地支持业务用户采用业务语言来建设业务流程，同时又必须能够支持IT人员使用IT语言来整合IT资产以实现业务流程。这要求一个 BPM产品必须同时具备业务设计能力与IT设计能力，并且能够将两种模型统一为一个完整的模型。

　　2.与以前纯IT产品不同，企业的运营流程与BPM产品里的资产应该是高度同步的，这些资产映射了真实的业务流程而不是需要翻译的IT资产。当企业的业务变更发生时，这些变更不需要等待从业务翻译为IT资产的周期，而是由业务人员直接将其转化成BPM资产，这些BPM资产则应快速响应业务变更。这要求一个BPM产品要能够管理一个业务流程 (BPM资产)从创建到测试、模拟、部署、运行、监控、改进、变更、升级、归档的整个生命周期。

　　3.与单纯的某一类专业IT产品(如生产、财务、客户关系管理等)不同，BPM更注重于跨部门、跨IT系统、跨业务甚至跨组织的综合业务需求。尽管它在解决企业应用架构中较低层次的执行问题方面也是利器，但BPM更大的价值在于它能够在整个企业应用架构中更高的层次上整合业务，能够与企业战略相结合。这要求一个BPM产品要能够使用粗粒度的服务来快速构建应用程序而不是从头开发。

　　4.BPM必须具备更强的扩展能力，能够容纳、扩展、整合各种各样的企业应用，以BPM为核心形成应用生态圈而不是仅仅是孤立的业务问题和流程问题。这要求一个BPM产品必须基于开放的标准和平台，要能够具备跨平台、跨应用的整合能力，可以扩展和被扩展，以满足企业各种各样的业务需求和应用环境。

　　企业可以从以上四个方面来评估一个BPM产品是否符合自身的需要。

　　 同时， BPM的实施是一个循序渐进的过程，它必须与企业当前的BPM成熟度、业务规模、人员素质等相匹配，同时也与BPM产品的复杂度息息相关。显然，一个刚刚接触并开始采用BPM的企业，不可能掌握从战略到执行的方法，不可能建立完善的从战略目标到活动的指标体系，也无法在短时间内在管理上疏通各个业务职能部门。直接实施一个庞大的BPM计划，引入一个复杂的BPM产品，将会使企业充满挫败感：每走一步都极为艰难，周期长，难见成效。许多邀请咨询公司做了业务流程梳理但却难以落地的企业对此应深有体会。

　　每个企业内部都有很多遗留系统(Legacy System)，但这些遗留系统对于企业的运营具有非常重要的影响，其中包含了大部分企业的关键业务流程。要重新开发这些关键系统需要付出很大的人力、财力成本，因此，充分利用这些关键业务系统是毫无疑问的。而企业内部和企业之间的各种系统可能采取不同的技术和标准实施，这些异构系统之间需要互相通信，除了技术上的通信，更重要的是业务流程之间的交互。

　　为了解决异构系统之间的通信问题，提出了中间件的概念。中间件是位于平台（硬件和操作系统）和应用之间的通用服务。中间件主要关心的是数据层集成，这就意味着这些系统不提供任何能吸纳更高层集成的功能。而企业之间的应用集成应该包括技术层面和流程定义层面，需要各个业务应用能够以相互可以理解的格式和上下文来交换语义层的信息。

　　建模方法的改进

　　传统的工作流模型将业务过程与企业资源绑定，业务模型与组织和资源模型结合过于紧密，不适应企业的动态变化和发展的要求；传统的工作流管理系统一般限于企业内部，对跨组织的工作流支持不够。因而需要探讨新的能够灵活、方便、高效地实现企业业务的工作流技术手段。

　　面向服务体系架构(Service-Oriented Architecture，SOA)的思想将企业应用看成是由一些能够跨越企业边界、自我描述、实现某一特殊功能的服务集合所构成。通过标准化的机理，能够将这些服务注册于公共数据库之中，并被感兴趣的请求者发现;通过标准化的方法，服务者和请求者之间能够进行动态绑定和直接交互，实现一定的企业功能逻辑。

　　SOA并不仅仅是一种技术架构，虽然服务需要由技术组件支持，但是业务流程本身比支持它的服务更重要。SOA的基本原则是：业务驱动服务、服务驱动技术。SOA关注业务流程和使用标准接口，为流程开发或组合应用。以服务组件的方式实现流程中的任务或活动。使用工作流技术可把简单服务聚集为更复杂的服务，服务可链接在一起以执行较高级别的业务功能；同时可以将SOA看作是一个良好的工作流环境，基于SOA的工作流技术可充分利用其松散耦合、位置透明、协议独立等特点，解决异构性、互操作性等问题，高效地利用或重组企业现有的应用资源，适应业务和资源动态变化的需求。

　　跨组织业务流程的SOA集成

　　基于SOA集成的优点是，它能把各个应用的功能抽象成服务，通过请求/服务的方式来获取跨应用系统的功能调用和数据获取。服务一般只实现了功能和数据的互相集成，而没有对整个业务流程支持。但是，就像没有乐谱和指挥的交响乐团不能协同演奏出动听的音乐那样，如果不引入业务流程管理(Business Process Management，BPM)的技术来管理企业内部的不同应用提供的服务，就不能协调这些服务，完成企业的应用集成。

　　BPM是基于计算机网络技术、工作流技术、企业应用集成和可扩展标记语言(eXtended Markup Language，XML)技术等，从业务过程的角度对企业进行全方位的管理，并支持业务过程的持续改进，其核心思想是为企业内及企业问的各种业务过程提供一个统一的建模、执行和监控的环境。与传统的应用系统不同，BPM以超越功能模块的方式来保证业务跨部门、用户和组织的边界运行。BPM建立在已经从个人用户和部门生产力所获得的价值上，并把它们扩展到一个组织范围。

　　SOA将核心业务逻辑和流程控制逻辑分离开采。需要注意的是，这里的核心业务逻辑和流程控制逻辑都是由数据和动能组成，只是组成的方式不同，并不能像数据和功能那样简单分开。有时，难以确定业务规则表示核心业务逻辑，还是流程逻辑。评判的标准通常取决于业务规则的复杂程度。如果是简单的业务规则，最好将其归为流程控制逻辑的一部分，但如果规则非常复杂，则应划分为核心业务逻辑类型。相关的核心业务逻辑通常构成单个服务。这些服务的粒度相对比较大，采用松耦合（或者相对独立的）方式，不含复杂接口f但可能封装非常复杂的逻辑片段。特别是表示核心业务逻辑的服务控制自己的事务，不参与由外部控制的、周期可能很长的事务。鉴于底层事务的短期性，与表示核心业务逻辑的服务的交互通常是OLTP形式。表示核心业务逻辑的服务可能参与BPM或以流程为中心的服务编排的复杂流程。

　　流程控制逻辑与核心业务逻辑不同，很多流程是动态的，经常变化，需要与流程参与者进行复杂协调。管理流程控制逻辑的服务(如以流程为中心的服务)一般不包含应用程序状态，但它们包含与流程本身相关的状态。流程状态包含的信息有：流程参与者（人员和服务）、参与者的输入、在流程中的实际位置以及基本规则。以流程为中心的服务高度依赖于其他服务，特别是那些表示核心业务逻辑的服务。它们将核心业务服务整合在一起，协调跨越多个人、多个重要业务实体、跨地域或者维持较长时间的复杂活动。

　　将流程控制的逻辑与核心业务逻辑分开。是保持企业架构敏捷性的关键一环，对于企业而言，进行跨组织流程管理的目标是：(1)通过企业间的信息与流程连接，提高交互效率和柔性；(2)通过跨组织知识共享，利用丰富的知识和智力资源，促进技术创新；(3)通过网络化的电子市场降低原材料采购成本、交易成本。最终形成具有卓越的价值传递能力的价值链系统，提高客户的满意度。

　　企业间的应用集成包括三个层次：数据层集成、应用层、业务流程层。在SOA体系架构中，服务的粒度和层次取决于实际需要。服务可以仅仅是一个数据库的读取操作，也可以是一个业务流程的执行，比如订单处理流程。这也正是SOA的灵活和柔性的体现。通过将一个个流程封装成服务，流程之间的调用就体现为服务的调用，从而最大限度的提高已有系统的利用率。根据流程的复杂性和重要性，也可以将一个流程分解成多个服务，这也是SOA的灵活性的体现。

　　企业通过将其业务流程按照一定的标准封装成一个个的服务，存储在服务库中，通过Intemet对外公开。合作伙伴通过企业服务总线(Enterprise Service Bus，ESB)调用已经封装好的服务，而不需要考虑该流程是建立在何种平台上，采用什么语言实现，而只需要通过公开服务库中提供的服务接口直接调用。这种架构对于战略合作伙伴之间的系统整合非常有效，即使企业之间采用的操作系统平台、商业软件完全不兼容。

　　根据分析师及顾问的说法，BPM治理的问题同时存在概念层和颗粒层，前者是设想的BPM项目需要提供支撑实施的治理计划，后者则发生在实施期间与实施之后，对于提议或计划的东西，后者是极其重要的，因为可确保其实际有效且真的实现。

　　Forrester Research的资深分析师Clay Richardson说，这个专题最大的挑战在于，有关BPM治理由什么构成并没有一个统一的定义。按照Forrester的说法，流程治理，或BPM治理，包括了为实现持续流程改进项目和计划而建立的方法论、技能以及最佳实践。

　　在最近对45家公司进行有关BPM实践的调查中，Forrester的研究者发现，这些企业都报告说有许多项目机会，但是却没有办法衡量哪一个项目能获得最好的结果。“治理的一的部分工作就是想出方法论以及选择BPM项目的关键指标，” Richardson说。类似地，Forrester发现许多公司都有已完成项目的组合，但却没有为获得的利益定义评估指标。

　　治理的最佳实践

　　“治理的一部分工作是制定最佳实践指南，” Richardson说。指南可能包括选择诸如为新的BPM项目设定标准，为项目排列优先级等最佳实践。其建议最好反映了领导层的支持，并考虑到业务和IT的关切。Richardson说：“这是关键部分，也是往往被忽略的部分。”

　　Taraneon Consulting Group的联合创始人Thomas J. Olbrich警告说，正确地设立和实践治理包不仅仅括草草记下建模框架和一般建议。还包括了高要求的组织工作，需要的不仅是对于特定交付物具备清晰责任的人，还包括获得授权去执行和实施的人。

　　许多公司希望被视为具备流程治理的企业，不过实际上他们并没有采取任何的治理措施，这样的例子太多了，Olbrich说。他还援引了若干原因对此不平衡做出说明。

　　首先，完全白手起家启动一项BPM计划是很少见的。“大多数情况下，你已经有流程在那里了，然后在此基础之上进行治理，” Olbrich说：“这要么会是一次不完全的妥协，以免造成破坏，要么就是很抽象，根本没有实际的目的。”

　　另一个问题涉及到哪一个流程要进行治理。“我们常常会看到进行治理的地方大都是考虑流程操作的事情，并没有扩展到早期的色合计和实现的生命周期阶段，” Olbrich说。

　　这一事实也许反映出这样一种感觉，也即治理通常被视为一种稳定、甚至是僵化的手段，难以应用到更加不稳定和动态的开发阶段。而实际上，Taraneon在其Process TestLab中进行的预实现流程是实践设计治理的一种努力，Olbrich说：“似乎这是越来越多的企业都缺乏的一种感觉。”

　　流程不同，治理各异

　　然而，仅有治理但不能付诸实践，有时候甚至是强制执行的话，这样的治理最终也会是无效的。“实践治理的方法是将需求与流程要求绑定在一起，” Olbrich说。

　　比方说，相对于单步、在本地运行的流程所需的治理，如果你有大量高度分化的流程，你就得有不同的治理类型。此外，许多公司仅为其核心流程定义治理，而不是最终延伸至其他流程。“不过，当然，他们永远都不会做，” Olbrich说：“挑战在于治理本身亦是流程，由于其目标所然，使得其对流程管理的要求相对于其他流程的更高。”

　　简单地从治理开始也会是个挑战。比如说，“我们知道，一般的流程再造项目需要把40%的项目时间花在（流程）发现上，找出当前流程是什么，它们是如何工作的，” Olbrich指出。一旦你在记录情况上面投入了如此大的精力，在治理上花还要多的时间就说不过去了。

　　治理的阻碍

　　在Olbrich看来，BPM治理的另一种断裂是：授权文件的问题。比方说，流程生命周期每一阶段的文档不断涉及到不同的内容。设计文档因操作文档不同而各异—如果后者的确存在的话，员工通常也会选择去篡改或忽略设计阶段规定的方法。“我们有一个案例，几年前，我们在一家金融机构进行流程审计时发现，90%的（实际）工作实践与文档规定的流程不符，” Olbrich说。

　　还有，Process TestLab里面进行的审计表明，92%的被测试流程含有逻辑错误，平均每个流程约有120个错误，Olbrich说：“这就是流程无法有效工作或实现的120个理由。”

　　即便那些错误被纠正了，一旦未来的流程用户被允许试用流程时，“往往会导致发现对流程设计的种种误解，”他说。

　　不幸的是，在严格测试缺位的情况下，往往会发生“这些东西要么是实现过程中发生的，要么是实现之后出现的，使得修正这些错误代价极其高昂，花费时间巨大，” Olbrich说。这会令不愿意信任流程方法或对流程治理之类的事情进行投资的高管产生幻灭感。同样地，他说，出于本能，员工可能对任何涉及重大变更的项目不信任，因为他们相信，基于以往的经验，此类努力并不能真正带来改进。

　　让治理不断前行

　　如果这还不足够引起深刻思考，那么还有让BPM治理拥有生命周期框架的愿望。据Forrester的Richardson说，谈到BPM治理的生命周期时，你得有计划，从设计到建设到部署等都要考虑周全。

　　治理需要把“促进”包括在内，跟采用激励手段一道来让其维持生命力，Alyssa G. Martin说。Martin是位于西南达拉斯的独立认证公共会计机构Weaver的主理合伙人。她把促进定义为推进流程的方法以及为改进性能提供指导性监控。

　　“促进是治理的一部分；与治理要实现的东西有关，”她说：“流程改进的想法在其完全被采纳之前是无法真正实现的。治理必须树立权威，把监控的要素吸收进去，以便确保BPM获得所需的好处—这样其成功方能持久。”

　　确保可持久性的一个手段：“在实施之后的一段时间内继续团队在发布BPM项目时的职责，大概4到6个月的时间，”Martin建议。那种情况下，团队成员仍将监控并帮助实施流程改变。一旦特定结果实现了，你甚至还可以考虑犒劳一下这支行动团队。

　　“我发现团队会犯的一个错误是，当他们就改变进行沟通时，他们以为自己已经完成了。或者当他们展开培训时认为自己已大功告成，”Martin说。但是们这些只是实施的万里长征第一步，不是最后一步，她继续说：“将改变植入到工作流当中，然后衡量采纳程度，跟踪改变效果—这时候才能说大功告成。”

　　SOA与ITIL

　　如今，有越来越多的企业开始实施ITIL来应对在优化流程，提供IT服务上的压力。ITIL活动是由上至下而驱动的。它需要得到企业管理高层的支持与推动，结合评估、战略和规划多方面的角色，以最合理的成本来满足商业部门的需求。

　　SOA与ITIL在这方面相类似，成功的SOA也同样需要得到管理层的支持，梳理商业目标和资源，而不只是专注于部门层面的服务部署战略。鉴于这一原因，CIO则成为了SOA部署的关键，他们对最佳实践的判断和投资决策可以改善企业过渡到服务导向型架构的成功几率。

　　IT将他们所提供的服务视为一系列技术的组合，而商业部门将服务视为一种表现形式。填补两者间的断层，以及拓展商业服务的范围，要求与企业管理层密切联合。

　　SOA是一种战略

　　SOA并非简单的技术部署方式，而是一种IT与商业部门之间关联方式的转变。SOA深深改变了企业IT投资和支持的方式，并要求企业内各部门间实现更畅通的沟通。

　　大多数在早期成功部署SOA的企业都在治理方面经历过巨大的压力。譬如，大部分的SOA价值都源自于服务重用。一旦有多达五至六个部门在同时使用某种服务，而导致绩效下降，那么由谁来添加额外的服务器？谁来追踪服务的使用情况？谁来控制安全访问？何时需要变更服务？诸如此类的治理问题还有很多。

　　一旦企业认识到SOA不只是光谈技术，那么投资ITIL及其它最佳实践也就不再有障碍。ITIL可考虑为成功实施SOA的基础。如果在IT里没有明确的流程，那么随着时间的发展，跨商业部门之间的协作就变成了一种负担，而SOA成功所必须的商业战略变更也无法有效执行。

　　降低风险

　　对于那些成功使用SOA来部署应用的企业而言，降低风险是最主要的回报。如果你的大部分软件项目都失败，那么风险就会随着项目的发展而逐步放大。专家发现，在成功的软件项目中，小型项目通常都占多数，而大型项目所占的比例却很少，而SOA恰恰可以弥补这一点。

　　SOA本身是一种模块性质的架构。当一款应用以模块的方式来开发，那么它就等于是由一系列的小型项目所组成。这种灵活的开发方式在过去几年中发展很快，当它与某种基于服务的架构合而为一时，就能改善应用部署的质量和成功率。

　　战略CIO

　　IT管理人员有多种方式来改善企业SOA活动的成功机会，例如：

　　由点到面——大部分成功的SOA实施都是从管理层开始入手，进行研究来发现重用、松耦合和模块化的目标，这是SOA增加商业价值的三种主要方式。

　　然后他们逐步推广SOA到各个商业部门的管理人员，结合商业部门的实际情况来设定预期，解决潜在问题，展现回报。这些活动帮助IT与商业部门之间搭建了互通的桥梁，同时也让非IT管理人员参与到整个流程中，体验到SOA对他们的影响，并对企业贡献价值。

　　发挥机动性——SOA的一大特征是机动性。这也是金融服务行业成为SOA主力军的原因所在，SOA活动能让他们的商业灵活性提升到一个新的等级。

　　这些公司中的管理人员充分了解商业部门的要求，能够引导IT去找出合适的方法来解决持续的变革问题。就降低软件部署上的成本和风险来说，SOA是一种绝佳的选择。

　　设定预期——我们常听到，在SOA部署的初始阶段是一种“烧钱”的活动。它需要大量的成本来更改软件基础架构，将现有应用平滑过渡到一个模块化的环境中，并培训开发人员来编写代码。不管是重新规划，还是拟定治理流程，都要求IT与非IT人员投入额外的时间与精力。

　　而当服务重用走上正常轨道，随着软件开发可预测性的提高，以及治理流程所创造的新秩序，商业部门就可以看到预期的回报开始逐步展现。

　　切合实际——SOA要求强大的技术能力，优秀的项目管理，管理层的支持，以及完善的商业流程。缺乏其中任何一环，都会抑制SOA的成功。

　　SOA的成熟也需要良好的服务开发、可重复使用的流程，畅通的跨部门沟通，以及高于平均水平技术管理自动化能力。在其中，CIO负责判断在某个指定部门中，SOA回报是否大于风险。SOA当然不是万能药，但如果战略合理，部署切合实际环境，那么它就能发挥将IT与商业部门连结到一起的优势，并提高IT的能力，提供更具成本效益的服务，延伸可持续性。