与其它革命性的IT变革一样，我们需要从方法、架构和实现技术三个方面去理解和掌握BPM产品。方法对应产品的设计目标——企业的管理理论和相应的实施方法论；架构表示软件产品的设计如何匹配该设计目标；实现技术则表示采用何种IT技术去实现相应的架构设计。三者缺一不可，然而长久以来，人们习惯于用实现技术去分辨和解释BPM，以至于到现在为止，人们仍然无法正确的理解BPM。由此也造成了BPM市场和产品的混乱。

其实这个问题并不是BPM独有的。举例来说，作者在培训面向对象的分析和设计方法时发现，相当大比例的程序员，哪怕他已经工作了很多年，哪怕他拥有丰富的项目经验，也精通一门或多门面向对象的语言，但他们并没有真正的掌握面向对象的方法。掌握面向对象方法的关键不在于是否采用了面向对象的语言和工具（如UML或java），也不在于是否掌握了面向对象的编程技巧（如设计模式），而是，你是否真的在用面向对象的思维去思考，从需求，到分析设计，到编码实现。它体现在项目的整个过程而不是仅仅是结果的表象。

SOA也面临同样的问题。是否掌握了SOA，其关键不在于是否采用了支持SOA的应用架构（如WebSphere Application Server），也不在于是否把某些代码逻辑封装成了符合SOA规范的服务（如Webservice）。而是，你是否真的采用面向服务的方法去分析需求、设计架构、抽取服务、把业务服务化，从项目开始到结束的整个过程都应该面向服务的，而不仅仅是产出物。

回到BPM产品上来，如果仅从实现技术去理解，人们就会陷入这样的混乱： BPM与工作流有什么差别？都有流程引擎，都可以自动化运行，都有流程编排器，也都能对流程进行监控。凭什么工作流就不是BPM？如果辩解说BPM能比工作流能做更多的事，比如服务编排和集成，工作流会说只要是开放的通讯标准，不论是WebService还是JMS，工作流同样可以集成第三方服务，BPM可以做的，工作流同样可以做到，无非只是技术实现的方式不一样而已，并不是本质的差别。你还可以争辩说BPM是面向业务的，而工作流不是，但你如何解释什么是业务？难道BPM里一个审批申请的活动是业务，工作流里一个审批申请活动就不是业务？什么道理？ 同样的混乱还有很多，例如ERP会争辩说ERP也有其内部的工作流，也可以把客户的业务流转起来，ERP也是BPM；办公协同类软件也会争辩说BPM不就是资源共享和工作协作么？从这个角度说，我也是BPM，有何不可？

而客户就更加混乱了。从通过流程来实现一项业务的实际需求出发，上述的任何一门技术似乎都可以实现他们的需求，怎么选择？何况凡是带个流的，都说自己是BPM，似乎谁谁也差不到哪里去。至于那些花了大价钱进行了流程梳理的企业，费了牛大的劲梳理出来的流程却停留在Visio里，写在word文档里，有什么用？以至于许多客户最终消极起来：我只知道我得审批信用卡，我得处理投诉，只要管用好用就行，只要能解决我现在的问题，是不是BPM又有何妨，who care？ 看，一旦陷入这样的技术细节比较，就是比上个三天三夜，吵个天翻地覆也不会有结果，市场继续混乱，产品继续混乱，客户继续混乱……