1. 感叹国情

　　一个显而易见的事情浮出了水面。我们刚开始学习写程序的时候，那种流程图，实际上就是 Sequence、XOR-Split、XOR-join 这三种模式的组合。可见工作流的内涵并不只是业务流程而已。为什么要讲流程图呢？因为在我所接触的业务流程相关的开发中，一些没经过工作流训练，或者新手，通常就是直接的把业务流程和做算法设计的流程图对等起来。至今仍然有一些小公司自开发的工作流引擎，就是这种流程图模型。

我们可以做一个简单的对等，流程图中普通的矩形框就是 Sequence 模式，菱形框（条件判断）就是XOR-Split，而一个矩形框接受多个分支作为前躯的情况就是 XOR-join。首先我们在理论上注意到 XOR-join有一个限制条件，就是有且只有一个前躯执行，很明显只用 XOR-Split 就能很轻易的达到这个要求（这个结论有数学上的证明）。

这个事实有点令人沮丧，可以从一个侧面反映我们人才的断层，似乎做应用系统的只有程序员一种人。不过实际情况还没有超出控制，因为我们做的应用主要集中于政府采购，而对于现阶段的电子政务来说，这种流程图的方式应该是足以应付了。下面我们来看看为什么这三种模式形成的流程设计能适应我国电子政务的现状：

●政府部门各自为政，也就常说的"信息孤岛"。业务流程的主体基本上是同一个单位，无须考虑协作、沟通或并发的问题。

●政府部门不太关心业务流程的效率和质量，我们的公务员大爷也懒惰异常，他们宁愿漫长的等待，减少沟通和协作（退化成顺序模式），也不愿为了加快工作效率而增加工作量（并发执行，相互协作）。

●开发者兼任咨询顾问的这种普遍形式，鉴于并发所带来的问题，有意的将流程的设计退化，使之成为顺序+条件选择的方式。尤其是让一个政府机构内部的各个部门配合起来，要牵涉的多次会议、决策与红头文件，实在是对开发计划、周期和成本的一个重大打击。

●还有就是依赖于商务操作的一些小开发商，鉴于技术问题，也尽量引导业主回避并发的流程设计。

　　所以，总的来说，使我们工作流的水平还不到家，无论是分析设计水平还是开发水平。在电子政务能用到"并联审批"（AND-Split）这一概念的，已经能算是较为前卫。所以我们现在业务流程的设计，也多停留在这五种基本模式的应用上。

2. 应用

这5个模式较为明确，一般在流程设计中考虑，如没有可并发性工作的考虑，都能用 Sequence、XOR-Split、XOR-join这三种模式来解决。稍微高级点的就是"并联审批"这种业务，一般是采用 AND-Split 考虑。所谓"天下大势，分久必合，合久必分"，Split以后，一定要配合相应的 join 处理。尤其是考虑到并发以后可能出现的分支情况。

　　若不想出现难以预料的流程，则我建议是将其设计控制在特定的闭包范围内。譬如说 Sequence、AND-Split、AND-Join一个闭包，Sequence、XOR-Split、XOR-Join 一个闭包。在 AND-Split 与 And-Join 中，最好不要穿插XOR 关系，或者保证其嵌套层次不能交叉。

3. 应用实例

　　A. 汇签

　　需求：组织结构，三个部门，每个部门一个负责人，所有部门都向总经理负责。如果一个方案是涉及层面较广的（譬如工资改革方案等等），则由主管部门发起，首先普通员工草拟方案，给部门经理审批，再给其他部门的经理审批，再给总经理审批。这样，再主管部门经理给其他部门经理审批这一步，就产生了一个汇签的过程。

　　设计方案：

　　在没有更高级模式的支持下，这种设计方案似乎是较好的选择（以后的模式里面会有更好的解决方案）。这里有比较典型的 AND 合 XOR 应用，其中 XOR 判断的条件是执行者是否主管部门，如果是主管部门，那就已经审批过了，不参与汇签。

 　　PS：这里没有给出审批不通过的情况，但是这种设计加上审批否决的部分较为简单，这里就不再叙述。

　　现在考虑更为普遍的情况，泛化为N个经理的情况“并联会签”，怎么办呢？可以考虑这样设计：

 　　上面这一设计牵涉并发，可以看到引入了一个AND就使情况复杂了。为了表示方便，我把XOR-Join 和 XOR-Split 分开两个结点表示，一些工作流设计系统中可能只需要用一个结点就能表示了。

我们来看看具体流程：假设公司一共有4个经理，A、B、C、D。假设主管经理是A，然后审批方案后要交给B、C、D来汇签。其中 AND结点引入，保证了在参与汇签者的列表中取出参与汇签者以后实现“并联审批”，取 B 以后，就马上启动并发流程：寻找下一个审批参与者和 B执行审批动作，然后一直取 C、D，同理。注意流程的两个 XOR-Split，一个是判断审批完毕，一个是判断是否开始了审批，其中不尽相同。

　　思考：审批不通过的情况，该怎么办？国人的流程较为复杂，审批不通过的有可能是 B、C、D 其中 B 没有通过，但是 C、D不需要再次审批（这种情况通常是方案中有属于不同部门的描述，所谓的汇签，大家都只关心方案中与自己部门相关的部分就可以了）。也有的情况是任何一个人不通过，所有经理都要重新审批。更有可能是“民主制”，B、C、D之中只要2个通过就能递交到下一步审批。不过就目前来说，只有基本的5种模式还不足以表达这些多变的流程，因此技术平台无法支持更高级的工作流模式的情况下，我们作为应用开发人员只能编写代码来解决。更深层次的自省是：当我自己设计一个流程的时候，较多的用编写代码的方式来表达实际业务，还是较多的上升到工作流模型设计的层次来解决问题呢？我觉得如果是前者，那么就要小心谨慎了，多半是自己工作流设计的水平不足，或者选择的工作流引擎/平台的能力较低（前者自我水平不足，后者产品选型的决策偏差，若是自开发的工作流引擎则表明还有的缺陷，不能较好的支撑多变的业务，都不见得是好事情）。

　　这里给出的办法，只是用现有的工作流模式的实现，以后讲述的模式中有更为直接的组合来实现这个汇签模型。但是这些方案也可以给无法使用高级工作流模式的朋友们参考使用。
 　　
　　B. 代理审批

　　需求：领导外出，要找人来代替审批。我接触过许多流程的设计者都卡在了这个地方，思维都集中在了怎么去设计者个临时加一个权限进取，然后所带来的"动态权限"系统的复杂性。这种可能是程序员的惯性思维，需求结构直接影射到代码结构的一个典型吧。其实大可不必这样做。

　　设计方案：

　　这样就能很简单的解决代理审批的问题。

4. 总结

有心的读者都可以看出来，在设计这几个流程之中，我们试图把条件判断而产生的路径选择，独立出一个结点（或者几个结点），而每个有实际工作结点的本身都只负责条件判断和路径选择以外的实质性业务。这里涉及到流程设计的一个理念（我喜欢称之为个人哲学），以后另外有文章叙述流程设计的体会。

　　我这是我在实际流程设计中的一些经验，希望各位来指正批评。