谈BPM系统实施

前面已经写过很多BPM和工作流，BPM和SOA关系的文章，在这里主要谈下一个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的价值重点体现在两个方面。

第一个方面是通过BPM来实现端到端流程执行的监控和流程绩效评估，注意这本身在完整的应用架构里面就是在执行层上面的事情，这样可以减少和已有的业务系统之间的功能性冲突。第二是对于企业内部的很多职能管理部门，如审计部门，风控部门，流程管理部门等，这些部门本身不承载核心业务价值链上的单据产生和业务，而重点是基于已有业务系统能力进行的IT管控和治理，因此对于这些部门新建设的业务系统是最适合通过BPM工具来完成的。

对于BPM本身在进行流程建模设计的时候，也要注意到最好采用子流程的模式进行分层建模和设计，即对于BPM流程的顶层重点是自动化的端到端业务流，而对于下层才是人工审批流流程，否则一个完整的端到端BPM流程将很难进行后续的执行监控。

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