用户的需求大概分为两部分：一部分是整个项目完全基于工作流来搭建开发，这也是很多工作流厂商患有“平台压迫症”的原因；另一部分是将工作流作为业务组件加入已有的项目中，推动业务的“审批”流转。

前者的要求显然更高，但也意味着有更多的利润。其实这一部分的用户又可以进一步的细分：一是技术能力比较差的公司，他们通过层层外包接到项目，而又没有实力自己开发，于是想通过采购工作流加上几个刚入门的程序员来完成整个项目的开发（这类用户往往也是业务平台最大的客户群），他们想着是一整套的开发解决方案，甚至包括业务分析；二是对业务编程的需求，他们需要流程引擎能够侵入业务编程的内部，对业务的状态和生命周期进行灵活的管理，从而最大程度的简化开发或者说满足一些复杂业务编程的需要。

 后者的需求则比较简单，多是某一行业的项目公司，突然碰到有审批的需求了，采用工作流多是满足人工“审批”的需要，以及部分的统计分析。

需要承认，工作流其实与最终用户还差得很远，也就是说在众多厂商的网页上，那副著名的业务流程生命周期其实是一句空话。一句话说，就是那个什么流程设计器是给程序员用的，至于用户，哪凉快哪去。也就是说现在的工作流还不能给最终用户提供价值。OK，既然工作流的价值是提供给集成商的，集成商就会考虑成本，于是工作流能否提供一个完整的开发解决方案就成了最重要的考量。

 最后说说市场。工作流其实有着很大的市场，只不过这个市场被开源工作流和平台瓜分掉了。因为目前的工作流不能给最终用户提供价值，所以集成商在遇到审批的需求时，首先想到的会是开源的工作流引擎，从jbpm、osworkflow的流行也可以看出这一点，并且知识的积累确实比购买工作流来的划算，同时很多公司通过积累也会有自己的流程组件，这并没有太大的难度。难度留给技术能力一般的公司，他们首先想到的会是一整套解决方案而不仅仅止于流程服务，于是平台出现了，平台说：“灰壳显灵，银弹来了。”

关于平台，有一个很时髦的流行词汇，叫“业务应用基础平台”，稍候待续。