工作流模式详解之流程控制模式(7)——Structured Synchronizing Merge

1. 理论模型

　　这一个模式是为了应付Multi-Choice 或者通常意义所说的 OR-Split 所产生的分支。

　　

　　首先这个分支的合并，需要了解上下文的关系。前面若是只产生了 A 分支，那么来到这里只需要 A 分支就可以触发后躯，B 分支亦然。若是 A、B 分支是并发的，那么注意标题中"Synchronizing"的字眼，这个合并必须等待 A、B 分支都完成了才能触发后躯 C。

　　顺便提到这一个"Structured"的字眼，在后续的工作流模式里面会常看到。遇到这个字眼多少意味着带有点条件判断的味道。就这个模式本身不能独立的决定合并方式，需要根据上下文的信息来适应不同的情况变化（如：这一个模式需要知道前面的 OR-Split 结点如何分支才能决定合并方式）。

2. 应用

　　在比较普遍的设计中，这一模式一般会与 Multi-Choice 配对出现。如：

　　

　　这种模式在早期的工作流引擎中难以实现，一般都会让二次开发人员编写代码来达到上下文相关联的效果。不过幸运的是现在 BPEL 和 XDPL 都能直接支持这种模式，现在的二次开发人员还是比较幸福的。

　　在一般的实际操作中，这种情况是很常见，若没有信息化支持，也是效率最低成本最高的一种。因为有一个部门/人员，要确定前述工序的状况，必须经历一个十分痛苦的信息收集过程。在有分支流程的情况则更为麻烦，财务人员深有体会：在核对不同的单据凭证时（譬如销售部门的采购订单、仓库的收货单），甚至有可能要深入的了解暂缓执行的收货发货（对月份的财务报表有影响）、货品质量、退货数量等等。假设一个采购流程，收货可能会产生两个并发分支：接收和退货，这两个部分可能同时发生，也可能只有一个发生，但是后续流程中财务部门需要知道这些信息，则可考虑设计：

　　

　　注意这一个设计的业务变化，不同的组合产生了不同的实际业务。如：全部收货，全部退货，部分退货，都可以反映在这一流程中。图中简化了很多的业务情况，譬如退货的流程可能会再交给质管部门再检测（一般制造企业在采购零件的业务，会有专门的质量检测负责部门），也有的情况是收货后的进仓流程。总而言之，没有信息化支持的情况下，一个财务人员可能要了解到这个收货过程的一些情况，才有可能核对各种记账凭证。

　　我所遇到过的另外一个种情况就是一些小件商品生产线的工人计件过程，财务上需要核对每个工人的产量以发放工资，这个时候，如果没有信息化的支持，可能需要相当多的人员参与这个计件过程。我觉得最为典型的是有200个工人的纺织企业，用差不多15个人来算这个产量，这几个人还要天天加班。工厂临时工人多，每个月要发放3、4次工资（许多临时工人一周发放一次工资），这样可见得只是计件一块，耗费的成本就非常之大。

3. 一点思考

　　根据实际的经验，这种业务流程的合并方式，若采用了信息化则可大大的降低成本。如上述所说的，财务人员不需要去深入其他部门的业务中，可以通过信息化终端直接获得各种信息，那么就省去了相当多的时间。

　　还有一种流程改革，则更为彻底。若存在这样的流程，尽可能让合并后的工作分担到各个分支上来，那样合并后的业务就相对简单多了，而其他工作因为分担到了各自的分支流程中，则效率更快。关于这一点以后还要专门的讲述（工作流技术与流程再造的关系，以后会再写一些文章介绍）。