当前市场和产品的混乱

申请免费试用、咨询电话：400-8352-114

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

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

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

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

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