网上到处都有一篇被称为《优秀的工作流殷勤的144个标准》的文章，文章写的很全面，但其对实际应用的满足程度还是需要改进的，我在此抛砖引玉的对其做了写评价和扩展，在我的《面向业务开发应用》博文中有部分体现。希望网友有所借鉴。

一般性功能 (General Functions)
1. 免程序开发(No Programming or Scripting)  
  评论：很多工作流厂商都在狂吹自己的零代码特性，但实际应用却需要大量脚本，所以他自己也达不到，很多事前/事后动作要免程序就必须引入“自动执行步骤”的概念

2. 可处理大量流程工作 (Volume Transaction Processing)
评论：这与应用场合有关，用友的ERP 20多个用户就十几万元，服务器的负载比上千用户工作流可能都大。
       在架构上，如果是常规的B/S，只能通过服务器群集解决大用户量接入问题，但如果能够将业务处理的计算工作分配到客户端，将会是另一个世界。

3. 三层式弹性化架构(Three Tier, Scaleable Architecture)

4. 稳定的信息传递架构(Robust Message Transports)

5. 流程反向回传/抽单(Process Rollback)
   评论： 国内的叫法是回退流，但回退操作复杂，易对业务流程造成很大伤害，很多国际大牌产品并不支持，真正的操作应是撤销失效。

6. 支持LDAP 目录服务

7. 支持企业级数据库 (Support for Enterprise Databases)

8. 动态用户授权(Active User Licensing)
    评论：有关系统授权数的问题，还应该具有一种功能为预约授权，如如果授权数有限，则大老板必须具有登录能力，这个坑一直要给他留。

9. 统一的登入ID 与密码(Unified ID/Password)
原意： 使用者在进入上述系统时，不需要以不同的ID登入两次
评论：实现SSO有多种方式，其一是第9点所提，比如AD集成就是一个很常见的实现途径，但由于很多企业没有AD集成，就需要采用另一种方式，即自动登录：系统通过识别登录人的主机、客户端ID等复合条件自动判断是否允许其登录，自动登录往往结合了系统启动自动运行（比如QQ的模式），但由于绝大部分工作流产品都是B/S架构，实现起来很滑稽(系统启动后自动谈出个IE来，客户一巴掌关掉就像拍死支苍蝇）。

10. 使用者网域安全性(User Domain Security)
  评论： 安全接入考虑的是认证过程的安全（通道加密，认证流程的可靠性等），在企业内部工作不需要太多限制，而异地接入一方面可采用诸如一次性密码等方式，还需要有能力对登录用户的异地访问权进行限制。甚至对业务流程进行异地操作限制。这点很多产品做不到。

流程与窗体设计功能 (Designer)
11. 图形化工作流程图(Graphical Workflow Maps)
评论： 现在绝大部分的产品都是用图形化流图，但都是单一流图，稍微复杂些的流程会产生大量的交叉，可读性还不如配置方式的好看，根本的解决方法是多视角流程图。目前没有哪家厂家提供。

2. 基于角色的路由(Role Based Routing)
原意：基于角色的路由不同于以员工姓名为依据，如果职务发生变化(这在企业是屡见不鲜的常事)，流程设计不需变动。
评论： 目前工作流产品都是仅加入角色允许操作选项，这种功能会造成很多麻烦，比如我想实现除A以外所有K角色的人都可操作，只能设置一个K‘角色，然后新增人员时还要小心翼翼的处理K与K’，根本的方法是增加拒绝的选项

13. 平行会签(Parallel Routing)
原意：企业内部有许多作业必需平行处理以提高效率，举例来说：有 5 位部门经理需要提出年度预算报告，每一部门之报告为独立提出，故可将五位经理定义在同一步骤内，各自处理后再统一送到下一步骤。
评论：诸多会签可有另一种处理方式：各个签收业务是总签发业务的从属业务，启动总签发业务后会自动根据要求签收的成员创建签收子业务，每个签收子业务可以独立运行，总签发业务在所有签收子业务完成后进入下一步骤。

14. 基于关系的路由(Relationship Based Routings)
原意：大部分企业流程是构建在从属关系上的：申请差旅费需由部门经理核准、员工绩效由上级主管评定…等等。如果通过指定某人向某人汇报来实现关系路由显然不科学（对大的企业也不可能），所以能依据从属关系来决定流程传递方向的功能更显重要。
评论：在实际企业中经常存在一个员工有两个上级的情况，此时的“关系路由”会非常错乱，解决的途径就是要使系统的组织管理部分支持“多身份管理”，如余责成以副站长身份时上级是吴站长，而以潜伏间谍身份时上级是xxx。

15. 工作队列(Queues)
原意：在企业内经常有“多人处理同一种工作”的情况。为提高工作效率，合理分配工作量，对于这种队列工作方式而言，合理的处理方法不是直接传送给特定个人，而是传送至Queue，Queue 的成员一旦有时间，便可向Queue
要求接收新的工作。
评论：采用队列的方式，引擎内部不可避免的要进行轮询运算，这种轮询运算是非常耗资源的，另一种解决方式是“等待信号"模式，即客户端完成手头工作后立即发出空闲信号，系统将新业务传递给它处理，这种模式的效率会非常高，但由于基于B/S的架构是短链接的无模式体系，实现起来非常困难，解决的途径就是抛开基于web的 B/S架构，直接使用基于长连接的新的通信架构。

16. 图形化数据路由(Graphical Data Routing)

17. 动态会签(Dynamic Routing)

18. 条件化步骤(Conditional Steps)

19. 条件化步骤跳跃(Conditional Jumps)

20. 条件化取消流程(Conditional Aborts)
评论：除了取消流程操作支持，还需要有删除记录的支持，比如对于一些不需要保存的临时授权审批记录，在关闭时自动删除记录会节省数据库空间，加快系统的运行速度

21. 条件化退回(Conditional Returns)

22. 条件化收件人(Conditional Recipients)
原意：在许多企业环境里，工作的分派是依照各人的职责或它的专长。因此，工作流程自动化软件必需提供依实际状况决定分派工作给谁的功能。
评论：目前很多产品支持步骤定义“静态”的操作人，通过流转条件到对应流转步骤时，操作人可以处理业务，对于动态操作，目前仅有“自由流”或“群组”支持，而缺乏更加灵活的操作设定 ，如下一步操作人是由以前交互操作，甚至计算出来的人员。因此很多应用场景仍然无法支持。

23. 条件定义清单(Event Condition Tables)
原意：现代企业组织内，每天都要面对各种例外状况与特殊事件。因此，逻辑判断与例外处理功能是否强大，是决定工作流程软件优劣的重要指标，它可以依照企业内的规范，以及个案的特殊状况，聪明地将工作传递到正确的处
理人员手上。
24. 条件定义清单与其它步骤互动(Status Variables in Event Condition Tables)
愿意：在许多情况下，我们必需由其它步骤的处理状况(或现况)来决定工作/决策的未来动向。应该要求软件实现提供其它步骤目前的状况信息，工作流设计工具能使用其它步骤的现况资料，来定义此步骤条件清单以控制资料的流
向。
23，24评论： 使用链表式工作流引擎的架构（如PETRINET,FSM等），对于分支的处理都是采用子链方式解决，一到跨链流转就歇菜，因此对于复杂的流转及例外，这种引擎体系是病根，根本的解决途径是采用网状流转引擎

25. 退件(Return Step)

26. 动态定义群组(Dynamic Groups)
原意：“群组”（或我们熟知的“项目小组”）常常是为了完成特定工作而成立的编组，而工作流软件必须能定义并使用动态编组功能以适应这种业务需求。所谓“动态”是指能在流程执行时动态指定群组成员，而非在流程设计时。用户可以直接输入群组的成员名单、或由数据库读取名单或从数据库读取名单。
评论：这是很重要的一项功能，但貌似不少国内产品并不提供这种功能，就该功能还需要扩展，及群组需要有运算能力，如流程中定义的A组，B组，在执行P步骤时要求执行人是A+B.

27. 整合智能型窗体设计工具(Integrated Intelligent Forms Designer)

28. 表格透过服务器端连接数据库(Server-Side Database Connectivity for Forms)

29. 表格通用变量(Global Variables in Forms)

30. 电子签章(Signatures)