对于BPM一定是包括了自动化的业务流和人工工作流引擎两部分的内容，同时为了更好的处理在业务流程建模中的业务规则往往还需要有单独的规则引擎子系统或模块。一个完整的BPM系统往往包括了流程建模和设计，数据建模，界面设计，基础数据和权限设计，流程执行和监控，流程仿真，流程绩效评估多个方面的内容。由于BPM主要完成

     对于BPM一定是包括了自动化的业务流和人工工作流引擎两部分的内容，同时为了更好的处理在业务流程建模中的业务规则往往还需要有单独的规则引擎子系统或模块。一个完整的BPM系统往往包括了流程建模和设计，数据建模，界面设计，基础数据和权限设计，流程执行和监控，流程仿真，流程绩效评估多个方面的内容。由于BPM主要完成的流程组合和编排是是整个SOA架构的上层内容，因此一个完整的BPM系统设计和构建本身就是组件化和SOA服务化思想进行的。

    对于BPM软件的实施，我们从通过BPM系统全新构建业务应用和基于BPM系统进行流程整合两个场景来讨论BPM软件实施过程中的异同。

全新构建业务应用

    一个完整的BPM系统本身就可以理解为一个既开放，又相当封闭的SOA架构平台。开放主要是说该系统能够很好的集成和复用已有的SOA共享服务能力，封闭则是说BPM软件可以从设计建模，到测试，到部署上线端到端的完成一个业务应用的构建。可以看到全新构建业务应用相当来说反而容易，这个时候没有和企业内部遗留IT系统集成和协同的麻烦。在这种情况下4A基础数据完全可以以BPM系统为最初的源头，很多跨流程的业务单据信息也直接在BPM系统中进行建模和设计。对于界面和展现即完全利用BPM软件本身提供的一整套快捷开发工具进行，本身也不存在单独构建一个IT系统时候还需进行基础技术框架构建的问题。但是在这种场景下构建BPM，仍然存在一些问题无法解决，具体包括如下：

　首先对于业务系统，即以工单和流程驱动的系统，还有就是以核心共享数据为基础驱动的系统。前者类似OA，ITIL类业务系统；后者类似资产，资源管理等系统。注意对于后者我们期望的一个完整的全局数据模型，这个数据模型往往会应用到多个业务流程中，而不是简单的工单。在这种情况下采用BPM软件是很实现完整的业务功能的。因此BPM更多的还是适用于流程驱动的业务应用。

　其次，通过BPM软件构建出来的系统往往是跨越了多个业务部门的一个端到端业务流程管理，在这种情况可能并不会再具备原有的项目系统，采购系统，物流系统等严格的业务系统划分，而是这些业务都完整的实现在了一个短到短的业务流程上。那么这个BPM系统的业务管理和认责部门是谁？这个时候我们往往找不到一个主导的责任部门，那么这个BPM系统后续如何推广实施？靠IT部门的力量往往是很难真正落地的。这也是我们常说的BPM系统的推广难点已经不在技术上，而在于业务上。

　最后即使是流程驱动的业务系统，如果期望通过BPM软件提供的功能完全通过可配置和可视化设计的方式完全实现出来还是存在困难，即使有相关的规则引擎，但是仍然很难做到完全可配置的快速开发。这就自然涉及到了即使全新构建BPM系统，在BPM的底层仍然需要有实现核心能力和业务组件和技术组件，这些组件重点变成提供领域服务能力，而不是前台界面展现和协同。这个点必须要意识到，否则容易理解为BPM是万能的，啥流程都可以很简单的建模和配置设计出来，那就大大的犯错了。

遗留系统通过BPM来整合场景

　这个相当于前者来说往往更加困难，困难点就再在于期望通过BPM来解决原有的端到端流程中的协同断点，同时又需要最大化的保留历史遗留系统的IT资产。大家看SOA架构好像觉得这个问题已经很简单的解决了，即历史的遗留系统都会识别为组件，组件应该将遗留系统的业务和数据服务能力提供出来，然后通过BPM层对服务进行组合，服务进行编排，形成一个端到端的完整流程。但是这个本质问题还是BPM和遗留业务的关系问题。

　如果基于BPM是来实现一个完整的端到端流程，这个端到端流程在构建过程中确实可以调用遗留系统的服务能力，但是这个端到端流程是否涉及到单据和数据的产生，是否涉及到人工流程的处理？如果流程会产生单据和数据信息，那么根据原有IT架构这些业务单据仍然应该产生和存储在遗留IT系统而不是BPM系统，对于人工流程的处理同样的道理，仍然应该是在原有业务系统中统一处理而不是在BPM系统。

　这个一分析清楚我们就容易理解，遗留系统场景下BPM进行整合，不能凭空的再找出一个BPM系统出来，BPM的重点是将原有业务系统中的单据和流程整合和集成起来，而不是替代原有系统的能力。最终集成的效果可以通过Portlet形式展示到门户，而不是新增加一个业务系统。把这个理解清楚了，就清楚在这种场景下BPM实施的重点应该是由业务系统提供完整的领域服务层能力出来，而BPM重点是来统一实现界面层和展现，实现各个业务系统中服务能力的组合。即使再这种情况下都还需要考虑如何解决门户层应用功能和原有IT系统间功能的统一工作台展现，这个问题没有解决好就会变成业务部门人员需要两处处理业务，现在在实施层面是很难推广的。

　实施BPM有个很重要的内容，就是4A系统或者叫模块的实施，已经原有的工作流引擎是否已经成功实施。如果这些没有实施，那么BPM将作为为4A和工作流的基础支撑，如果已经实施那么就存在如何同步原有的4A数据，是弃用原有各个业务系统不统一的流程引擎还是保留资产进行整合的问题。对原有的IT资产保留的越多，你会看到BPM本身在实施过程中能够用到的能力越是减少和退化。

     对于一个已经相当成熟的内部IT来说，BPM还存在哪些价值和意义。

　第一个方面是通过BPM来实现端到端流程执行的监控和流程绩效评估，注意这本身在完整的应用架构里面就是在执行层上面的事情，这样可以减少和已有的业务系统之间的功能性冲突。

　第二是对于企业内部的很多职能管理部门，如审计部门，风控部门，流程管理部门等，这些部门本身不承载核心业务价值链上的单据产生和业务，而重点是基于已有业务系统能力进行的IT管控和治理，因此对于这些部门新建设的业务系统是最适合通过BPM工具来完成的。对于BPM本身在进行流程建模设计的时候，也要注意到最好采用子流程的模式进行分层建模和设计，即对于BPM流程的顶层重点是自动化的端到端业务流，而对于下层才是人工审批流流程，否则一个完整的端到端BPM流程将很难进行后续的执行监控。

　当前很多企业就IT成熟度来说都没有到能够理解和实施BPM的程度，这也是为何很多企业的BPM实施仅仅变成了一个企业内部的统一工作流引擎平台实施的原因。

　个人认为对于一个BPM项目的成功实施，最重要的就是分析和建模方法的转变，如果仍然是按照传统的方法已经将业务分解到多个业务系统，那么面对的又将是遗留系统流程整合问题，而不是直接通过BPM+SOA方式来构建业务系统的问题。流程驱动IT是分析建模中的一个重要点，从流程开始自顶向下分析和分解，划分组件和识别服务；在从组件开始自底向上进行服务组合和编排，形成应用或流程。这是一个完整的闭环路线，没有前者我们就很难真正的保证我们最终划分的组件，识别的服务能够真正应用到后续的服务组合和编排上面。

　不应该太早的进入到业务系统的概念，对于SOA整个咨询和建模方法论里面的，我们是弱化业务系统的概念，而是进一步强化了业务组件和技术组件的概念。这样做的目的主要是在SOA参考架构里面原有的业务系统已经变成一个弱边界，业务系统仅仅是多个组件的灵活组合或组装；其次当我们以业务系统出发进行考虑的时候，我们思维里面仍然是纵向架构模式，但是当我们以组件，服务和流程角度来考虑的时候，思维里面是一种横向分层架构模式。对于横向架构模式本身重要的目的就是要打破传统业务系统纵向的强划分。

　上面谈的是BPM实施中相当关键的一点，把这点想清楚了就清楚了BPM流程建模的真正意义。在流程建模过程中我们是按照流程驱动的思路在分解流程，在规划流程应该涉及到的流程环节和活动节点，在设计每个流程节点应该业务自动化和人工化处理的事情，在考虑相关的流程节点是否应该有前台的展现和交互界面，表单所涉及到的数据对象结构；这块想通了我们才会进一步考虑这些需要的数据或业务规则逻辑处理能力究竟应该由下层的哪些业务组件或技术组件来提供这些服务。

　上面这句话如何理解？即就业务组件或技术组件本身来说还是按业务域，数据或技术域分开的，底层是组件化和服务化的，但是这些组件本身更偏服务能力提供，这些组件并不关系前端对应了什么流程，应该有什么样的人机界面交互，这些组件的职责相当简单，就是提供业务或技术服务能力而已。但是在组件或服务的上层，我们最终涉及完成的前端或业务流程流转所需要的界面却是不分业务组件或系统的，其本身就是流程化和一体化的，这些前端界面，交互和展现不属于任何一个业务系统，而应该属于BPM系统。

　这就是一个理想化的BPM构建的方法和思路，把这个思路想明白后做过传统IT系统开发的就比较容易理解为啥BPM系统实施如此困难，为何BPM系统实施看到的很多都是单纯的HWF人工工作流引擎的实施。这个的本质就是分析和建模思路没有转变，没有从传统围绕业务系统为核心转换为横向的围绕组件和服务为中心来思考。

BPM构建和实施层面

　当前各个国际大厂商的BPM工具和产品套件已经相当成熟，但是在这里要说明的是BPM软件产品虽然可以灵活的通过配置和可视化建模设计和方式来构建业务系统前端流程，但是其配置的繁琐和复杂程度往往超过了直接写代码的模式。也就是说很多时候可配置的方法虽然开似很美好，能够灵活的应对业务的变化，但是很多时候往往开发配置效率是降低的，同时对于BPM本身新设计完成的流程仍然涉及到需重新发布的过程，也远远无法达到我们期望的零部署模式。

　一个BPM建模和执行工具平台，更多的是从服务层开始流程整合，而不是从遗留系统的界面层。如果已经有成熟的业务系统和前端功能界面，那么实际问题仅仅是两个系统的两个功能间的业务或数据交互问题，这类问题是不需要用BPM工具来解决的，直接用到ESB服务总线这层就足够了。对于BPM平台一定要注意到其擅长的并不是单个业务系统内部的功能构建，如果一个业务系统本身不涉及到外部交互，仅仅涉及到内部功能或数据流转，我们其实强烈不推荐采用BPM产品和建模方法，能够有人工工作流引擎就足够了。一个稍微复杂点的业务如果全部用BPM可视化建模和配置来实现出来，超过几十个节点是常事。这种BPM建模文件文件维护的难度反而不如逻辑清晰的源代码。不要把BPM产品理解为快速开发平台，虽然很多BPM产品想朝这个方向走，但是确实不是BPM擅长的事情。

　真正BPM产品最擅长的还是在跨系统的业务流程场景出现的时候，这种业务场景显然放在任何一个已有的业务系统都不合适，但是这种端到端流程本身在业务上又需要统一管理和管控。在这种场景下是最需要BPM的能力，即前端交互和流程流转统一规划和设计，原有的业务系统仅仅为上层提供数据和业务服务能力。

　大家可以考虑下，如何我们要构建一个企业电商的客户自服务平台，这个自服务平台需要能够方便客户实现对从订单到交互的全流程跟踪和管理。这种平台往往本身并不产生大量的基础数据和存储逻辑，而是需要大量的调用或系统企业内部已有的CRM系统，ERP系统，PDM系统，MDM系统的能力。对于这些遗留系统能够提供的能力根据客户需求和流程的需要进行组合和编排。同时基于这些能力，重新设计端到端的前端界面交互和流程流转，这就是一个BPM相当理想的实施环境。从这个层面来说企业内部常见的风险管控系统，合同端到端跟踪系统，财务共享服务平台等都是比较适合BPM的应用场景。