作者：人月神话，新浪博客同名简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践今天准备谈下BPM业务流程管理系统的建设和实施方面的内容
首先还是从BPM的基础概念入手进行介绍，然后重点解释下BPM和工作流引擎的区别，最好谈下BPM软件的应用和实施场景
BPM业务流程管理概述业务流程管理是将生产流程、业务流程、各类行政申请流程、财务审批流程、人事处理流程、质量控制及客服流程等70%以上需要两人以上协作实施的任务全部或部分由计算机处理，并使其简单化、自动化的业务过程
20世纪90年代，Michael Hammer和James Champy的成名之作《公司再造》（Reengineering the Corporation）一书在全美公司领域引发了一股有关业务流程改进的汹涌浪潮
这两位管理学宗师在书中展示了这样一个观点——重新设计公司的流程、结构和文化能够带来绩效上的显著提高
但是由于缺少对变革管理以及员工变革主动性的关注，在很多致力于把他们的理论付诸实践的公司身上产生了反作用的结果
而如今，公司再次把业务流程管理——这种通过分析、建模和监控持续优化业务流程的实践，当作一种解决业务难题和帮助公司实现自己财务目标的系统方法
业务流程管理（Business Process Management, BPM）不是一个新概念，甚至不是一个新名词
它是从相关的业务流程变革领域，如业务流程改进（BPI）、业务流程重组（BPR）、业务流程革新中发展起来的
流程管理技术也是从早期的工作流管理、EAI、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的
从管理理论或战略的层面看，业务流程管理（BPM）就是在一个存在内部事件和外部事件的环境中，由一组相互依赖的业务流程出发，对业务进行描述、理解、表示、组织和维护
从具体实施的层面看，BPM 还可分为流程分析、流程定义与重定义、资源分配、时间安排、流程管理、流程质量与效率测评、流程优化等

Gartner Inc．给出的BPM的定义是：BPM是一个描述一组服务和工具的一般名词，这些服务和工具为显式的流程管理(如流程的分析、定义、执行、监视和管理)提供支持
业务流程管理是跨业务组织结构，跨业务系统，跨应用的软件和方法论,从而实现自动化管理,优化动态业务,产生真正的业务价值
更多体现的是跨业务域，端到端业务流程的管理和整合
BPM和HWF人工工作流引擎企业信息系统构建本身就应该遵循流程分析，业务建模，子系统划分，系统功能建模的逐步分解过程
由于企业内职能部门的划分，而业务系统往往又需要一个归宿的主导部门，在企业发展大后一个业务系统也很难完全支撑到企业所有业务流程和业务活动
因此不可避免的导致了企业在各个业务域衍生了多个业务系统，业务系统主要实现价值链的一个核心业务域，但是业务系统必须要整合和集成才能够满足端到端流程的整合
端到端流程整合出现断点或流程不畅通，一方面是业务系统本身的分解有问题，一方面则是业务系统之间集成有问题，业务部门各自为阵导致了系统集成这种中间地点没有一个主导部门去管理和负责
业务系统本身分解问题主要体现在没有一开始就从企业架构和应用架构出发来考虑业务系统建设，业务系统建设不是从上向下的，而是完全根据业务部门需求各自建立
系统间集成问题则主要体现在了完全不考虑集成的标准规范，集成的方式，集成本身的可复用性，导致大量重复建设
流程建模遵循高端建模逐层分解的思路，高端流程往往正是我们关注的业务流程，高端流程跨越了多个业务域，多个业务活动，多个业务对象和单据实体，最终完成了一个端到端业务
如供应链端到端，涉及到采购需求，采购计划，采购策略和实施，采购订单，采购执行诸多环节和业务对象
高端业务流程中采购订单生成只是一个业务活动或子流程，而采购订单制作和生成本身又需要根据订单类型或金额设计不同的审批流程，而采购订单拟制后的审批流程才是我们经常所说的工作流，人工工作流或审批流
那么从这个意义上很容易看到业务流和工作流的区别如下:业务流往往会跨多个业务系统，而审批流往往主要涉及到一个系统
业务流会涉及到多个业务功能，多个业务对象，而审批流往往只涉及到一个业务对象
业务流涉及到的是不同业务单据之间的流转，而审批流往往是同一业务单据状态的变化
业务流中既包括了人工活动也包括了自动的业务活动，而审批流一般为人工审批活动
而对于BPM业务流程管理系统和工作流管理系统，可以再进行下分析
我们看到现在很多BPM软件也从工作流管理软件发展而来
不论是哪种，基本都包括了流程建模，流程执行，流程监控，流程分析等基本功能，也包括了表单建模和数据建模，权限管理等扩展功能
可以讲一个完整的系统基本上可以实现简单的以审批流为主的简单业务功能模块的配置化开发
通过表单设计工具制定一个表单界面，绑定数据对象，挂接上自定义的流程模板，一个功能即开发完成，只要没有太多复杂的业务规则，基本上完全可以通过配置实现，这也是这类工具可以在类OA应用中大规模使用的原因
对于流程建模，BPM关注的是业务流程建模，基于BPMN或BPEL进行，而工作流软件关注的是审批流建模
BPM建模需要考虑业务人员对建模需求和可用性，但是不可避免又导致建模的内容无法很好的落地
而工作流建模本身已经细化到一个功能模块中的审批流，相对来说简单很多而容易实施执行
BPM业务流程往往跨越了业务系统，跨越了多个业务单据，需要处理不同的业务规则和逻辑
而工作流软件活动节点往往仅仅处理审批和会签任务，和外界交互相对较少
而BPM业务流程中由于存在业务活动和业务规则，而这些又需要外界提供数据支持，因此不可避免的在BPM流程建模中需要通过SOA服务方式调用各种可复用的服务来处理和转换数据
工作流软件发展到今天，我们看到也可以在表单建模，工作流设计过程中调用外部的SOA服务，这是一个很好的进步，使工作流软件不仅仅能够简单进行审批处理还能够增加较为复杂的业务规则判断
业务流程建模中会出现业务规则，常规的工作流软件处理方式一般支持脚本代码进行简单业务规则的处理，而发展到BPM后为了保证规则本身的复用性和独立维护性，引入了规则引擎，规则引擎形成统一的规则创建和维护库，BPM本身不再负责规则的创建和维护，而仅仅是按需消费
这个分离本身意义也很重大，要知道业务规则又明确的业务系统开发商和业务主管部门，放到BPM系统中通过定制方式管理规则显然是很困难的
传统的软件工程方法从业务流程分析到形成子系统和功能模块，有一系列的分析和设计过程，最终形成各个功能模块和协同应用
而BPM系统试图通过简单的业务流程建模和BPMN就能完成一个复杂业务流程到功能模块的转化，这是一个相当困难的事情
虽然BPMN2.0使这种转化成为了可能，但是要看到对于跨系统，跨多个业务对象实体的长流程，BPM系统可以进行流程建模和设计，但是很难直接转化为可实现的模型
这是到现在BPM系统也很难去解决的问题，如果该问题没有解决，BPM系统又沦落为一个业务人员建模的工具而已，BPM和实际的业务系统仍然是脱节的
BPM重点是流程整合，而流程整合是多个业务系统中多个业务功能模块之间的协同，如果一开始想用BPM去实现这些业务功能，那么往往是适得其反，BPM切入的第一步仍然是在于跨业务系统的流程集成，而流程集成重点又在于流程间的数据传递
知道这个重点后BPM的关注点应该放到流程协同和监控上，而子流程或某个独立的业务模块实现仍然在原有的业务系统中，通过端到端流程整合实现了业务模块之间的系统，这个一方面最大限度的利用了已有的IT资产，又实现了流程整合的需求
业务流程整合一定是涉及到自动化的业务流和人工工作流，原有的BPEL很难融入HWF导致BPEL只能应用到流程整合的一些点上而无法真正实现理想状态下的流程编排，最多算上服务编排
而引入人工工作流使BPM有了做端到端流程整合的能力，但是已有业务系统已经有工作流引擎或审批流实现，要完全抛弃已有的流程引擎又是一个很麻烦的事情
那是BPM来整合已有的流程引擎，还是流程引擎引入BPM的关键要素又成为一个需要考虑的问题
BPM之所以困难，不在于思路上，而在于实践和落地上，如果是全新构建业务系统还好办，特别是已有业务系统的IT环境改造
即使实现了流程整合，那么流程整合后的认责部门是谁？流程整合后对已有业务系统有哪些影响都需要考虑，而不是简单的想流程整合后放到门户系统了事
HWF人工工作流引擎在这里先谈下我们常说的人工工作流引擎，这个其实是现在大多数应用系统都必须具备的基本业务管理功能
正是由于每个系统都需要该功能，那么每个系统如果都单独建设必然带来重复的成本投入，同时带来了各个业务系统间的工作流交互标准语言不统一
在谈企业私有云PaaS平台建设的时候我们谈到了，基于平台+应用的构建思路，企业流程平台作为底层技术平台统一建设
企业内部的统一流程平台建设，不仅仅是功能的迁移，更加重要的是数据的迁移，对于流程来讲我们所说的数据即是流程建模数据和流程执行数据的迁移
在统一流程建模和统一流程执行的基础上，提供统一的流程监控和流程绩效管理
很早我们就在谈流程不能脱离组织，岗位角色，权限等基础而存在
进行组织，人员，岗位权限等基础主数据的管理和整合又是建立内部统一流程平台的基础
因此我们可以看到内部的主数据管理，组织引擎和权限引擎等内容
这些都是为流程平台做准备
流程建模全统一在统一流程平台进行，因此BPM需要有统一的组织，人员和权限数据，这是各个系统能够完全互通的基础
在流程建模的时候，不仅仅涉及到常用工作流模型中的串行，并行，条件分支，聚合，子流程，回退等基本流程功能
更加重要的我认为还是流程活动节点和组织权限内容的结合，否则流程很难适应组织权限调整带来的影响和变化
粗一点的流程建模可以只控制到表单级权限，而细化点的流程建模则可以控制到表单输入的每一个数据项的权限
流程活动节点往往很多时候都具有条件判断，条件判断往往又涉及到外部调用，因此流程活动节点支持脚本代码的编写，支持对外部接口和服务的调用又是最基本的功能
工作流产品本身的设计包括了静态数据建模和动态数据建模两方面的内容
涉及到流程模板，活动节点，连接弧，分支判断，流程图形化展示元数据等多个方面的内容
动态数据建模又涉及到流程执行实例数据的记录，这方面的内容后续单独描述
统一流程平台需要实现的就是统一流程建模，统一执行和统一监控，只要是涉及到流程建模和执行的数据都不在原有的各个业务系统中，而是全部集中到统一流程管理平台进行管理
按这个思路自然带来新问题即BPM系统如何与原有的业务系统集成
业务系统和BPM的集成最佳的效果就是对于用户感受不到BPM系统的存在，不能因为系统内的集中化和云化带来用户使用上面的差异
简单点的描述，使用具体包括如下几个方面的内容：1.各业务系统单独的多租户账号登录BPM系统，进行系统流程建模，BPM系统已有在各个业务系统完全统一的组织，用户和权限数据
这个不统一BPM系统无法真正落地
2.在流程建模完成后，对于每次流程建模系统会建立单独的流程模板ID供业务系统使用
3.业务系统各业务表单使用统一的流程启动接口调用BPM系统提供的服务启动工作流
4.BPM系统中的流程待办，流程已办，流程处理等各个关键业务功能用UI组件的方式形成UI组件后内嵌到各个业务系统中使用
在这里又需要企业内业务系统间实现统一认证和SSO单独登录
5.BPM系统提供流程执行，流程监控，流程查询等多个服务接口供业务系统使用
统一流程平台首先要实现的是替代原有业务系统内的人工工作流引擎，实现流程的统一管理，同时在组织，用户和权限集中的基础上，形成系统基础管理，权限管理和流程管理的通用语言
这样就很容易过渡到跨系统间的流程整合，在这种情况下的跨系统流程整合只需要再考虑如何与标准的BPEL进行集成，使流程整合即具备人工审批流节点，又具备根据业务规则自动进行处理和流转的自动化业务节点
基于工作流引擎的接口服务集成业务组件和工作流的集成包括了服务集成和界面集成两部分的内容
对于服务集成则是将工作流平台组件提供的工作流管理能力服务统一接入到SOA服务总线，并供业务组件在使用时候调用；对于界面集成主要是对于工作流平台实现的可复用界面直接通过单点登录的方式进行集成
对于服务集成，主要包括的接口服务有：启动进程 startProcessInstanceByQueue获取实例信息 getProcessInstance静态启动工作流 createProcessInstance进程查询 listProcessInstance删除进程实例 deleteProcessInstance在与流程平台的集成中，一方面是通过流程平台暴露的服务接口进行程序集成；一方面是通过流程平台提供的标准UI组件进行界面集成
可以看到对于待办，已办，流程监控等核心界面不适合下放到各个业务组件自行开发，而是应该通过抽象后统一有流程平台来实现，业务组件在使用过程中通过界面集成的方式进行嵌入
具体可以考虑的界面集成内容主要包括：我的待办和我的已办功能集成图形化流程查看界面集成流程监控界面集成（暂停、重启、终止、完成）流程流转和处理信息界面集成任务处理信息界面集成BPM和HWF人工工作流引擎很早以前在谈BPR业务流程重组的时候，其要点就在于打破职能部门界限，形成跨越业务职能边界的端到端流程
而对于BPM同样道理，即在业务职能部门各自为阵建设自己业务系统的情况下，需要跨越业务系统边界进行端到端业务流程的整合
BPM首先是一个公司管理问题，其次才是一个业务问题，其次才是一个系统问题
抛开了业务和管理，企业本身组织架构和战略来谈BPM基本都是无法落地，有时候期望通过BPR和BPM来改善公司管理和组织也是适得其反
根深蒂固的职能部门边界，利益和绩效KPI不可避免的会导致流程割裂，业务流程衔接点成为三不管地带，没有谁来关心端到端流程，更谈不上来系统化思考全流程的优化和改进
在这种情况下出现了流程管理部门，专门负责公司流程改进和优化，流程管理部门独立在业务部门之外，这种情况下虽然可以全局的思考流程问题，但是流程优化结果如何落地，流程管理部门不存在具体的业务KPI，而各业务部门有各自利益，虽然有很好的流程优化和改进，但是没有强有力的执行力仍然难以解决落地问题
组织，战略和业务目标来推动业务流程改进，业务流程改进推动IT的建设，流程和IT融合，IT建设和实施过程中又进一步固化流程，通过IT系统的建设和实施加快流程和标准规范的落地
先固化，再优化，持续改进
华为公司推行实施的ISC和IPD，中兴推进的HPPD和项目化运作基本都是这种模式和思路
在面对市场竞争需要快速高质量交付的时候，必须有整合高效的端到端流程，在端到端流程下没有割裂的部门，更没有割裂的系统
BPM的推进和建设任重道远，因为其本质是一个业务问题，而非系统问题
BPM系统实施的两个层面对于BPM软件前面已经谈到过一定是包括了自动化的业务流和人工工作流引擎两部分的内容，同时为了更好的处理在业务流程建模中的业务规则往往还需要有单独的规则引擎子系统或模块
一个完整的BPM系统往往包括了流程建模和设计，数据建模，界面设计，基础数据和权限设计，流程执行和监控，流程仿真，流程绩效评估多个方面的内容
由于BPM主要完成的流程组合和编排是是整个SOA架构的上层内容，因此一个完整的BPM系统设计和构建本身就是组件化和SOA服务化思想进行的
对于BPM软件的实施，我们从通过BPM系统全新构建业务应用和基于BPM系统进行流程整合两个场景来讨论BPM软件实施过程中的异同
01-全新构建业务应用 一个完整的BPM系统本身就可以理解为一个既开放，又相当封闭的SOA架构平台
开放主要是说该系统能够很好的集成和复用已有的SOA共享服务能力，封闭则是说BPM软件可以从设计建模，到测试，到部署上线端到端的完成一个业务应用的构建
可以看到全新构建业务应用相当来说反而容易，这个时候没有和企业内部遗留IT系统集成和协同的麻烦
在这种情况下4A基础数据完全可以以BPM系统为最初的源头，很多跨流程的业务单据信息也直接在BPM系统中进行建模和设计
对于界面和展现即完全利用BPM软件本身提供的一整套快捷开发工具进行，本身也不存在单独构建一个IT系统时候还需进行基础技术框架构建的问题
但是在这种场景下构建BPM，仍然存在一些问题无法解决，具体包括如下：首先对于业务系统，我前面分过类，即以工单和流程驱动的系统，还有就是以核心共享数据为基础驱动的系统
前者类似OA，ITIL类业务系统；后者类似资产，资源管理等系统
注意对于后者我们期望的一个完整的全局数据模型，这个数据模型往往会应用到多个业务流程中，而不是简单的工单
在这种情况下采用BPM软件是很实现完整的业务功能的
因此BPM更多的还是适用于流程驱动的业务应用
其次，通过BPM软件构建出来的系统往往是跨越了多个业务部门的一个端到端业务流程管理，在这种情况可能并不会再具备原有的项目系统，采购系统，物流系统等严格的业务系统划分，而是这些业务都完整的实现在了一个短到短的业务流程上
那么这个BPM系统的业务管理和认责部门是谁？这个时候我们往往找不到一个主导的责任部门，那么这个BPM系统后续如何推广实施？靠IT部门的力量往往是很难真正落地的
这也是我们常说的BPM系统的推广难点已经不在技术上，而在于业务上
最后即使是流程驱动的业务系统，如果期望通过BPM软件提供的功能完全通过可配置和可视化设计的方式完全实现出来还是存在困难，即使有相关的规则引擎，但是仍然很难做到完全可配置的快速开发
这就自然涉及到了即使全新构建BPM系统，在BPM的底层仍然需要有实现核心能力和业务组件和技术组件，这些组件重点变成提供领域服务能力，而不是前台界面展现和协同
这个点必须要意识到，否则容易理解为BPM是万能的，啥流程都可以很简单的建模和配置设计出来，那就大大的犯错了
02-遗留系统通过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实施仅仅变成了一个企业内部的统一工作流引擎平台实施的原因
BPM系统实施演进思路对于通过BPM工具并结合服务层来实现端到端流程监控这个话题，前面文章已经提到过了，这个相当来说比较容易实现，即这种最终编排出来的BPM流程视图更多的都是通过服务读数据而不会涉及到写操作
同时原有的各个业务流程还是在各个遗留的业务系统里面，对业务系统本身的改动也相当较小
那现在的问题还是，对于一个完整的业务能否全部依赖BPM产品提供的能力来实现，各个大型厂家的BPM产品基本都覆盖了流程建模设计，流程执行监控，UI和权限建模等各个方面的内容，基本已经是一个完整的基于流程驱动的快速开发平台
但是实际的情况往往则是这种大而全的平台在实际的实施应用中效果并不太理想
对于这点主要的原因包括了如下几个方面的内容：其一：企业在引入BPM的时候往往已经建设了大量的IT遗留系统，这些业务系统基本已经承载了企业核心业务流程和业务功能
而在BPM引入后如果要通过其来做完整的业务流程，往往都存在对遗留的业务系统改造相当大的问题
要明白对于传统系统基本是烟囱式纵向建设模式，而SOA+BPM的思想是横向从组件-》服务-》流程-》界面展现的横向分层建设模式
新的架构思想往往会导致遗留系统要完全下沉为独立的业务组件并提供服务能力，而这个架构层面的改动和影响企业往往没有魄力去做，当然其本身带来的改造量也相当大
其二：我们在和企业交流过程中可以看到，究竟有多少人真正需要端到端的业务流展示？要明白即使原有的端到端流程虽然分散在多个业务系统的业务功能单元中进行了功能支撑，但是本身端到端流程还是完整的，只是没有一个端到端流程全貌而已
而本身企业内的业务部门在进行职能划分后，往往业务部门本身关心的也是自己业务部门的业务流程和功能，而不会太关心端到端流程，这是我们原来在理想化思考的时候没有考虑到的问题
即一个企业在管理层都没有启动端到端流程优化和整合，或者没有相应的流程管理类部门的时候，是不太会有明显的对BPM业务诉求的
即我强调过的端到端流程即使存在断点，也不是一定要上BPM，往往通过ESB服务集成就能很好的解决流程集成和业务协同的问题
其三：即使到今天很多人对BPM还是有很大的误解，将很多单纯的工作流引擎产品错误理解为BPM，或者将统一的工作流引擎平台产品理解为BPM，在上了这种产品或平台后，虽然解决了审批流层面的问题，但是往往对于端到端流程整合和监控问题并没有解决掉
当然这也不是单纯的工作流引擎产品的重点
其四：哪个部门需要BPM？要明白BPM产品最终做完的BPM业务流程和界面功能往往会横跨了多个业务部门，那么这个产品最终的主导和认证部门往往很难决定是谁？如果仅仅是靠IT部门的能力去推一个BPM产品是存在相当大的难度的
因此前面也说过，如果企业有类似于流程管理部门，往往还相当容易找到一个认责的主体
其五：各大厂商对BPM的宣传有很多夸大，导致客户认为BPM是一个无所不能的产品，什么东西都可以灵活的设计和配置出来
上了BPM产品后流程方面的问题就全部解决掉了
而实际上我们看到的情况上，即使BPM产品本身能力再强，由于企业本身核心价值链业务的复杂性，单纯的靠BPM产品进行配置和开发当前来说还是不现实的，也很难做出让客户满意的效果
基于以上的分析，那么在一个企业的BPM实施里面究竟应该如何做是一种相当理想的方式？在这里我们主要谈几点关键性的实施步骤和内容
01-流程建模流程建模还是最重要的一个步骤，即基于企业架构包括ARIS流程建模的思路对业务流程进行建模，在业务流程建模过程中通过流程逐层分解，对业务对象，业务活动，人工审批，自动处理等各种业务节点进行识别
对于BPM提供的流程建模平台，不管是否基于BPMN2.0标准，最终的建模文件都是很好的衔接真实业务流程和最终的系统实现之间的一个关键点
02-服务识别其中包括了组件识别，要明白最终的业务活动和交互集成最终都需要调用底层业务系统和组件提供出来的服务能力
基于跨系统交互流程分析的思路才能够分析和识别出能够用来做上层BPM功能的核心服务能力
这些服务能力最终还是由底层的业务系统或组件提供
或者简单来讲，这种方式带来的是以后业务系统重点是提供服务能力开放，而是不管最终展现和集成
那么原有业务系统逐步下沉为业务组件，但是其核心业务能力还是在各个业务组件里面
03-数据建模这块是要做，但是要注意不是在BPM里面进行核心业务对象的数据建模，数据建模还是要参考原有的方法进行，最终数据对象还是沉淀在业务组件里面
要明白核心业务对象是不可能存储在BPM系统里面的，这个也不合适，BPM更多的还是服务组合和编排串联，而不是承载核心数据对象能力
对于各大厂家给出的BPM产品中的数据建模能力要慎用
04-界面建模这块也是导致BPM很难实施好的一个重要原因，即我们总是想理想化的通过BPM工具进行界面表单建模，但是对于服务的业务流程和业务功能这块很难真正实现
那么真正好的做法还是展现层的开发需要通过实施重新做一套框架，里面可能会有一些界面配置但是不是全部
核心的界面展现和设计可能还是涉及到的自己定制开发，这块没必要借用BPM产品的能力
但是唯一要注意的就是在展现层开发的时候，最终的功能界面数据的查询和存储等都需要使用服务层提供出来的可重用的服务能力
这也是我们常说的应用层变轻和变灵活的一个原因，即应用层界面展现已经没有太多的业务规则和逻辑提供，而更多的是使用开放的服务能力
05-集成整合上面几点思考清楚后，剩下的关键事情就是自己开发定制的功能界面和BPM流程模型，和服务层服务之间的协同和整合，形成一个完整的整体
由于我们将界面和数据建模的抽离可以看到，我们需要自己来实现和流程层的集成和整合，包括和底层工作流引擎的整合，我们需要根据流程引擎本身的能力来考虑整个业务流程执行过程中流程模型中的状态节点的同步流转
把以上几点都想清楚了BPM实施落地才有了一个基础
BPM产品本身不是万能的，BPM产品的实施也不是去颠覆各个遗留IT系统，如何找到一种衔接和融合点才是真正的关键
BPM端到端流程整合案例一个工程项目或一个合同管理的端到端，往往在企业内部跨越了多个业务系统，涉及到诸多的业务协同，业务单据对象和不同业务对象的状态流转
正是由于在这个业务流转中出现了业务流，出现了多个不同的业务对象实体的转换和映射，也就出现了1对多，多对多的业务对象关系
类似一个项目涉及到多个采购合同，一个合同往往涉及到多个订单，一个订单又可以分多次进行接收
而端到端业务流程监控的难点也正是在这个地方
在梳理完成端到端业务流程后，我们可以进一步梳理业务对象的关系图，该梳理将有助于我们在BPM系统中进行业务对象和数据建模
分析完端到端流程，可以看到跨系统的端到端流程往往涉及到多个业务系统间的接口交付和集成，因此需要进一步分析接口交付和集成关系，如下：基于前面分析，我们可以开始使用BPM工具进行详细的业务流程建模，其中包括了主流程，也可以包括了子流程，既包括了业务自动化流程节点，也包括了人工工作流处理节点
如下
监控的可视化流程图不同于BPM建模和设计中的复杂流程图，因此该流程设计往往只需要支持最简单的串行流程，并行流程即可
因此在监控流程的状态流转设计往往并不复杂，而较为复杂的是对于流程中每一个状态点我们需要查看到的业务对象信息的设计，界面的设计
为了简化这个系统的实现过程，对于服务提供部分我们采用在系统外单独来实现，即监控中需要查询和查看的数据都单独做成各种web service服务，可以在流程设计中进行调用
而界面的可视化设计相当简单，即仅仅是需要将界面控件的数据源和各种web service数据服务提供端进行简单的绑定即可
要注意流程监控类系统的状态流转不同于工作流引擎系统，其状态本身的定义就是大的业务流程阶段和管控点，这些状态点的触发往往是事件触发模式
因此对于该流程中的状态流转需要引入EDA事件驱动架构和消费发布订阅机制，在业务系统中完成某些业务后需要发出相应的业务事件，在流程监控实例中接收事件，并根据事件响应进行状态的流转
在整合完成后，我们可以将最终的内容作为一个独立的portlet配置到统一门户上面，用户登录门户后即可以看到自己关注的项目的端到端流程和当前状态信息
端到端流程监控平台还可以用来整合企业已有的工作流引擎，即端到端流程监控平台往往监控的是企业内跨多个业务系统的端到端流程，但是监控到某一个活动的时候往往就下钻到了单一的业务系统和单一的工作流引擎实例执行，而对于这部分的内容相当也很简单，即从业务流监控-》单个工作流实例的监控，能够实现逐层进入的监控和查看模型即可
欢迎关注@人月聊IT 分享SOA，微服务，DevOps平台规划和建设

（图片来源网络，侵删）