IT市场上BPM产品你方唱罢我上场，各色产品、各种概念粉墨登场。虽然百花齐放，但真正有志于实施BPM的客户却被这乱花迷了眼，实在搞不清楚BPM到底是什么，最终失去对BPM的信心。
　　
　　BPM的设计目标决定，BPM必须要和企业运营紧密结合在一起，是企业管理运营的直接映射。企业需要的是可以直接将业务变成可执行流程的技术，需要由业务人员直接建立、管理、优化流程，希望流程管理系统建设后可以直接在执行过程中监控企业绩效，更希望企业的战略意图可以直接与具体的执行层联系起来。
　　
　　要满足这样的需求，BPM工具必须彻头彻尾地面向业务人员而不是IT人员，用业务语言去建模而不是IT语言，由业务人员驱动BPM的建设而不是IT驱动。
　　
　　换句话说，如果有一个所谓的BPM产品，它被设计为面向IT人员，靠IT人员定制开发而不是业务人员建模，它的设计无法对接企业战略和执行层面，它的设计是针对业务执行问题而不是业务管理本身问题的，即可怀疑为伪BPM或说是不完整的BPM。
　　
　　最容易混淆的便是工作流与BPM、OA与BPM、ERP与BPM。
　　
　　伪BPM的设计带来两个明显的局限：
　　
　　系统的建立尽管使得工作效率有所提高，但对于衡量企业的整体绩效来说，这些系统内容是一个黑盒子，无法在执行过程中监控并得到企业整体绩效乃至战略的反馈；
　　
　　由于架构和设计的方向不同，业务人员被排除在流程的建立、管理、监控、调整之外，必须通过IT人员来进行。这使得业务敏捷成了一句空话。
　　
　　真正的BPM需要提供面向业务人员的业务流程的建模语言、建模工具、管理工具和监控工具;需要屏蔽掉业务人员弄不懂的IT语言与实现；需要强大的集成能力可以贯通分散于各个业务部门各个平台上的异构系统以实现企业整体业务流程管理和绩效监控；还需要业务流程当中的活动可以与企业战略挂钩，使得业务流程的运行直接反馈战略执行状态。
　　
　　Ⅰ BPM必须横跨业务和IT两个部分。它必须很好地支持业务用户采用业务语言来建设业务流程，同时又必须能够支持IT人员使用IT语言来整合IT资产以实现业务流程。这要求一个BPM产品必须同时具备业务设计能力与IT设计能力，并且能够将两种模型统一为一个完整的模型。
　　
　　Ⅱ 一个BPM产品要能够管理一个业务流程（BPM资产）从创建到测试、模拟、部署、运行、监控、改进、变更、升级、归档的整个生命周期。与以前纯IT产品不同，企业的运营流程与BPM产品里的资产应该是高度同步的。当企业的业务变更发生时，这些变更不需要等待从业务翻译为IT资产的周期，而是由业务人员直接将其转化成BPM资产，这些BPM资产则应快速响应业务变更。
　　
　　Ⅲ 与单纯的某一类专业IT产品(如HR、财务、CRM等)不同，BPM更注重于跨部门、跨IT系统、跨业务甚至跨组织的综合业务需求。BPM的价值在于它能够在整个企业应用架构中更高的层次上整合业务，能够与企业战略相结合。这要求一个BPM产品要能够使用粗粒度的服务来快速构建应用程序而不是从零开发。
　　
　　Ⅳ BPM必须具备更强的扩展能力，能够容纳、扩展、整合各种各样的企业应用，以BPM为核心形成应用生态圈而不是仅仅是孤立的业务问题和流程问题。这要求一个BPM产品必须基于开放的标准和平台，要能够具备跨平台、跨应用的整合能力，可以扩展和被扩展，以满足企业各种各样的业务需求和应用环境。
　　
　　综上，要辨别真假BPM，我们还是得回到方法和架构上来。
　　
　　如果一个产品的设计理念和相应的架构不是针对BPM的（例如工作流、OA），即使其加入了符合BPM的某些技术实现特征（例如流程监控、流程生命周期管理），它仍然不是一个BPM产品，它只是能够额外做一些BPM所需的功能而已；另一方面，如果一个产品的设计理念和相应的架构是针对BPM的，即使其加入了其它一些技术使得它能够支持诸如工作流或OA的应用，它也不会因此就变成工作流或OA产品。它只是扩展了更多的支持而已。
更多BPM的新闻资讯尽在http://articles.e-works.net.cn/bpm/

资讯来源：http://articles.e-works.net.cn/bpm/