工作流模式详解之流程控制模式(6)——Multi-Choice

1. 理论模型

　　这一个模式就是通常意义所讲的 OR-split 了。

　　

　　这个模式的初衷是可以让使用者任意选择后趋的路径，若选择了两个或以上的后续路径，则是产生并发运行的分支。细心的可能会发现，这个模式是 XOR-split、AND-split 更为泛化的一个模式（所谓的"泛化"，是概括、继承的意思）。

2. 应用

　　该模式既然是 XOR-split 和 AND-split 的泛化，那表示他的最终表现可能会像 XOR 或者 AND 那样子，只是这里留给了一个用户选择的余地。譬如一个审批流程，基层员工可能会根据其内容的重要程度，选择来交给部门负责人，或者主管副总，或者同时向两个汇报。

　　这种情况来说，在一种以项目驱动的组织里更为常见。这种组织，其工作的重点就是承接不同的系统化项目而赚取收入（一般是一个业务单，就成立一个项目组），而内部项目组具有临时性，诸如常见的策划、咨询、软件开发、会计、审计等等公司回大量出现这种情况。我个人从事软件行业，就以软件行业为例，一个开发人员，在垂直的组织结构上隶属于开发部，但是在特定的时间段里，又同时对一个项目组负责。这样开发人员就具有两个BOSS：部门主管和项目主管。这样，一个开发人员在内部流程中，就需要选择性的汇报：如果自省觉得所获得的任务限期过于乐观，要申请放宽交付日期，则需要同时向两个BOSS 汇报；而一些业务，譬如项目中的一个任务单元完成，则只需要向项目经理汇报。

3. 一点思考

　　现在企业内部管理，层次扁平化，沟通网络化的倾向越来越明显，以往树状多层次的管理结构逐渐失去了她所应有的光芒。而业务逐渐倾向于个性化、规模化、系统化，这样的市场需求更是使得企业为此而作出了许多重大的变革。对于这些企业的流程设计，可能因为许多自由选择的分支而形成一个复杂的网状流程，在我的个人经验看来，这样对工作流引擎所支持流程模式的要求越来越高。如果工作流引擎不支持这种模式，那怎么办？如果引擎支持前面所讲的5种基本模式，或许可以这样：

　　

　　这个模型在理论上同构于 OR-Split，但是估计没有人会这样设计。所以一般开发人员遇到这样的情况，则更多的选择编写一些代码来解决这种需求，而不是通过模型直接反映。可以看到，一个工作流模型对模式的支持，是对业务流程设计与开发有着相当重要的影响。