如何设计一个基于Lotus的可配置的工作流
使流程具备可定制性的目标即是让用户体验搭建业务逻辑的能力与之匹配。对于开发人员而言，则需要专注于优化其工作内容与其相反的工作环节——将复杂的业务逻辑分解为模块化的组件结构。重点在于优化拆分环节以提高重组效率，在此基础之上再设计出既符合企业需求又具备灵活性多样的工作流工具链。
在明确我们需要完成的任务后，在开始执行任务之前
遵循了前述各项原则后
图1 简单流程图
粗略查看图1中的流程图，并暂且忽略复杂的部分。我们通常会认为流程是由环节和路径构成的。如果仅仅将流程分解为环节和路径这两个要素，则非常易于理解。接下来，则尝试基于环节与路径这两个要素构建可配置化的流程结构。首先大致拟定各要素所需表单应包含哪些字段：
1、环节文档：环节名称、处理人员
2、路径文档：路径起点环节名称、路径终点环节名称、流转条件
上述两个文件均为配置文件，在构建完整的作业流程系统时，则需额外搭建一套包含待审批的业务信息主文件（以下简称主流程文件），该主流程文件需与基础配置文件实现对应关联关系，在此过程中则需在主流程文件中相应记录基础配置文件相关信息内容；现初步拟定了如下相关内容框架：
3、主文档：当前环节、当前用户
在相关基础文档建立之后
图2流程流转过程
基本上实现了"配置化"的一个流程。接着来看实际情况如何？然后我们再用一个稍复杂的流程来评估这种方案的优势与不足：
图3 有重复环节和路径的流程图
观察图3可知，在这两个关键节点均出现过两次的情况下，“B领导审核”与“会计”之间的转换关系也发生了两次变化。假设当前处理流程处于“A领导审核”的阶段，则按照现有的操作方案进行调整后，在后续步骤中可能会导致预期效果受到影响：具体而言，“B部门审核流程结束后有两个可选出口”。为了避免这种状况的发生，“采取以下几种方法来规避这一问题”。第一种方案是优化现有操作逻辑；第二种方案则是重新设计相关业务流程；第三种方案则是引入自动化监控机制来实时追踪关键节点的状态转移情况
第1种：给两个“B级审核流程”分别赋予不同的名称；例如其中一个流程可命名为B领导审核2。
第2种：为环节文档增添一个位置字段, 以便区分同一环节名称在不同位置的出现情况, 其做法是将位置替代为环节名称作为该文档的关键字。
采用第一种方案虽然显得较为简捷，并不影响我们原有程序的代码结构。然而，在现有架构中设计者需要费尽心思为'第二名称'制定合理的命名策略。然而，并非所有人都会认可这种方法。为了避免由此带来的诸多不便，请考虑采用第二种方案
下面观察环节文档中增添的位置域所呈现的效果（见图4）。通过"位置"域这一核心字段，在主文件以及路径文件中同时增添当前位置域即可精确定位流程的具体方向。
图4 增加环节的位置信息
通过在环节文档中引入位置域的方法来解决环节名称重复的问题。然而，在系统管理的角度来看，我们仍然需要对相同环节名称但位于不同位置的两个环节各自创建两个独立的环节文档。这种做法存在明显的不足之处：因为每当需要更改这些重复文档中的任何信息（例如：人员配置）时，都会导致必须同时修改多个文档（可能导致遗漏某些变更）。因此，在优化现有系统架构的基础上进一步提升操作效率的需求下
角色文档（职位文档）：角色名称、处理人员
环节文档：角色名称、位置
此外需要做的就是将路径文档、主文档中的环节信息按照当前角色和具体的位置进行分类处理
路径文档：路径起点的位置、路径终点的位置
主文档：当前角色名称、当前位置、当前用户
解决了同一流程中重复环节的问题后,我们将流程继续延伸.此外,还将面临不同流程共享同一环节以及不同部门采用同一流程等挑战.通过类似的分析手段,在后续阶段仍需处理为各类配置文档添加区分字段以区分不同情况或进一步拆分为独立的配置文档的问题.如前所述,选择添加域或者拆分各有其不足之处.增强操作简便性可能有助于提升单个系统的易用性,但可能导致配置文件数量激增从而降低系统的可重用性水平.易用性和可重用性这两个核心特性往往是此消彼长的关系,如何在两者之间取得平衡就完全取决于我们的系统设计团队.为此,我们决定优先考虑操作便捷性的策略,并在必要时权衡两者的得失.图5展示的是这种设计理念下的具体数据架构.
图5 可配置的工作流的数据结构
我们先前已经采取了扩大流程并对拆分方案进行细化的方法。然而，在这一基础上我们将从另一个同样重要的角度继续这一进程即对流程环节进行增删改三个方面的优化工作。上文也曾提及过流程环节中的'修改'操作（涉及修改承办人员）通常情况下这些修改并不会带来困难但增加或删除某个环节可能会遇到一定的挑战我们需要进一步探讨为此我们在'A领导审核'环节和'B领导审核'这两个环节之间新增一个'C领导审核'节点并考察这是否会让我们的系统发生相应调整见下图
图6 增加环节
在增加新环节时：我们需要移除起始点至结束点之间的原始文件（起点位置为2至3），增添新文件以及从其他文件库中获取的新文件（起点位置为2至8）、新文件（起点位置8至3）。当当前环节是“A领导审核”的时候，在程序流转过程中仍会利用主文档中存储的位置信息去搜索相关的文件内容。这样一来，在原有基础上的结果可能会从起始点所在的位置移动到其他目标区域。同样地，这种设计也能够适应删减环节的情况。
注意，在对环节进行增删改运算时还存在一种特殊情形即删除或修改当前环节的情况下不仅需要更新流程配置文档还需同步更新主文档中的相关内容然而如果没有任何外部干预则且其处理人的变更及当前位置的变化不会自动同步因此必须借助其他机制来确保工作流能够完美地实现可配置的需求
就目前而言，在设计一个简单的、可配置的工作流方面已取得了一定进展（其结构与基于关系式数据库的关系式建模过程具有显著相似性）。通过这一过程,我们认识到IBM在其Lotus WorkFlow系统中所采用的工作流引擎（基于数据结构的技术方案）确实达到了相当高的技术成熟度。反复折腾后仍未能突破已有的框架（与仅对比Lotus WorkFlow的主要区别在于我们选择不将人员与角色分离的原因是为了避免重复配置现有的names.nsf用户数据）。不管怎样,从这个简单的可配置流程设计的过程中,我们还是获益匪浅,也深刻认识到一个再完美的工作流引擎也不可能成为普世真理,因为工作流的易用性和适应能力常常是矛盾的,不同的用户会提出不同的要求。因此,技术人员不必执着于技术不可自拔。