BPM实施交流总结

最近陆续和朋友和客户交流了BPM产品和实施的内容，简单总结如下：

首先还是再次重申下BPM和传统工作流引擎的区别，BPM是跨了多个业务组织和业务系统的端到端流程建模和整合，其中既包括了自动化的业务流也包括了人工审批流。而工作流引擎往往是局限在一个业务系统内的单一的处理人工审批流的流程引擎。

对于BPM的成功实施有两个重要的前提，一个是需要有企业架构和流程建模思想的引入和导入，业务和流程驱动IT，从顶层的端到端流程逐步分解到四级和五级流程，再到业务架构和数据架构，最终再朝上追溯端到端的流程整合和集成。其次是BPM中的流程编排由于涉及到很多自动化的业务流，而这些业务活动节点需要调用底层业务组件可复用的业务服务能力，因此可复用的服务库积累又是一个重要基础。最后不论是BPM还是流程引擎，都需要人员，组织，角色权限等4A基础能力的提前建设和整合，这些也是在流程建模中需要使用的基础数据。

虽然很多厂商在给企业宣贯BPM，但是实际看到的情况上一个是厂商的产品本身只是传统的工作流引擎产品，一个是对于客户需求本身而言短期也仅仅是工作流引擎的能力。但是BPM和工作流引擎还是得分清楚，不能随便的偷换概念。对于工作流引擎而言，很多企业是存在流程引擎能力平台化和共享的需求，即形成统一的公共流程引擎平台，提供工作流的建模，执行和监控的统一能力。当前有不少企业的做法是对于工作流审批这块都统一迁移在OA系统中，借用OA系统的流程引擎在实现，这种做法短期也是可行的。但是从完整平台化的思想来看流程引擎能力不属于任何一个业务系统，而是属于企业内部的技术平台，属于共性的平台层能力。

企业内部的公共流程平台应该是属于PaaS平台的一部分内容，即bPaaS部分的内容，流程平台本身需要支持多租户架构，而实际的租户是各个业务系统。因此对于各个业务系统实际的流程建模和执行数据而言，是支持多租户隔离的，同时也支持超级权限账户对数据的完全共享。

有了公共流程平台，那么实际的统一审批和统一待办等能力自然就具备，而不像当前很多企业由于各个业务系统中采用了不同的工作流引擎，由于工作流引擎本身的模型或4A基础数据不一致。导致后期想在门户层实现一个统一待办和任务处理也需要大量的集成工作。

对于一个已经实施了信息化多年建设的企业来说，BPM引入的重点不是重头进行全新的端到端流程设计而抛弃原来已经在各个业务系统中的功能，而是通过BPM来解决端到端流程整合和监控的问题。如果一个企业是全新规划的IT应用架构和全新建设，那么就会看到BPM本身就可以来实现端到端业务流程，这部分能力的实现将不在任何一个业务系统内部，而是在业务系统上层的能力。

接上，如果在BPM系统中实现了具体的业务功能和流程流转，这类流程往往是跨越了多个业务组织和业务部门的，那么带来的另外一个问题是承载了多个业务部门能力的BPM系统往往是由IT部门在管理，而没有一个业务上的认责部门，这在后续BPM系统的实施和推广上将遇到具体的阻力和问题。因此对于这种情况下的实施，在业务上的基础要求是必须有专门的流程管理部门和作为认责方。

通过业务系统间数据服务和业务服务的集成，也可以实现企业内部跨多个业务系统的端到端流程的整合，而不是一定要说用BPM业务流程管理才能够解决端到端流程断点问题。基于BPM的流程整合更多的是解决端到端的业务流程监控和绩效分析问题。

BPM首先是一个业务问题，其次才是一个技术问题。如果期望从BPM软件和平台这个技术层面来逆向推动业务往往本身也是不现实的，没有业务驱动力的一个平台层产品不可能成功实施。

很多企业在建设和实施BPM的过程中出现一个典型的问题，即不论BPM这类的系统做在哪里都出现BPM系统越建设越庞大，流程和规则越来越复杂，后期越来越难以维护和可扩展。要注意BPM系统本章应该是调用底层业务组件提供的业务服务能力，本身并不应该承担业务，不要把业务组件全部放到BPM系统中去实现，通过服务来解耦上层业务流程和下层业务组件和模块是关键。这也是我常说的业务组件化，组件服务化的关键思维。

不论是厂商还是客户，在你们推广和实施BPM的时候，请首先想清楚业务场景和BPM提供能力的匹配。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密