流程回滚到底咋用？别让审批卡死在半路上

老实讲, 当我最初开始去接触OA系统的那个时候, 心里认为所谓的“回滚”, 不就是简单地点一下那个“退回”按钮。究竟谁又会做不到?

然而, 当你真切遭遇那种情况, 即审批已然进展到半途, 却发觉先前填写有误, 再不然业务已然出现变更, 又或者领导陡然宣称“这个流程存在差错, 必须重新进行修改”之际——你便会明白, 回滚绝非是那般轻而易举就能达成的事儿。

让人更为尴尬的是, 存在着一些系统, 它们根本就不支持进行回滚操作。一旦流程被发起之后, 要么就会一直持续下去直至结束, 要么就实行强行终止并重新发起, 而这样一来所有的数据就都没了。其中包括已经填好的表单, 已经上传的附件, 还有写过的备注, 这些都会通通被清空掉。

你是什么感觉？想砸电脑。

所以, 今天就来聊一聊这个“流程回滚机制”, 是指“407”的那种, 究竟要怎样去设计, 才能够达成业务不会陷入困境、审批不会出现混乱状况、数据不会有丢失情况这样的结果呢。

很多企业的流程设计，其实是“单行道”。

你先是由A处朝着B处行进, 接着又朝着C处前行, 随后再朝着D处走去, 然而之后却发觉A处存在错误。抱歉, 难道你只能自D处转向A处返回吗? 不是, 你不得不自D处退出来, 重新从A处开始再次进行一遍。

如此情形恰似: 你驾乘车辆驶上高速公路, 遂发觉竟是忘记携带钱包, 此时系统却指令你径直驶开车回到起始的地点, 并非准许你于最近的出口处进行掉头操作啰。

这合理吗？

不合理。

由于业务具备复杂性, 填单之人有可能遗漏填写某一个字段, 审批之人有可能看错某些数据, 业务环境有可能忽然发生变化, ——这些并非是“谁对谁错”的相关问题, 而是“流程应当拥有灵活性”的问题。

所以，一个成熟的流程回滚机制，至少得满足三件事：

能不能只回滚到某一步？而不是回到起点。

回滚之后，已填写的数据还在不在？还是全清空？

回滚了，谁需要重新审批？是所有人还是只有改过的那一步？

很多系统回答不了这三个问题, 或者回答得很勉强, 说是能回滚, 其实只是“退回重填”, 跟重新发起没区别。

你有没有遇到过这种情况：

一个采购流程, 起步于“申请人填单”, 继而发展至“部门经理审批”, 接着演进到“财务审核”, 最后终结于“总经理审批”, ——怎料结果到了总经理那里, 他瞅了一眼讲: “你们这个部门的预算额度似乎不太对, 回去跟财务核查一番。”。

现在需要回滚到哪里？

倘若回退至“申请人填单”, 那么全部审批意见就都不复存在了, 于财务审核阶段的备注同样也遗失了, 申请人还必须再一次填写一回全部信息。

要真是回滚到了“财务审核”这一步, 那财务先前给出的审批意见还会不会依然存续着? 这种情形下需不需要再次去过审。

要是仅仅回滚至“部门经理”此一步骤, 那么部门经理能够修改些什么, 能够修改金额吗, 修改之后, 财务那里的数据又该如何处理?

这些都是真实业务里会碰到的坑。

泛微e启营那个地方的流程引擎, 我先前见到过一种设计思路, 这种具有可按节点回滚的特性, 这是什么含义呢?

具体而言之, 你能够进行这样的指定操作: 以当前所处节点为起始点, 逆向回退至流程里的任意存在过的历史节点之上。并且, 在完成该回滚动作之后, 处于那个被回滚到节点位置的处理人员能够查看到在此之前的完整范围内的数据信息 , 这其中覆盖了后续节点所产生的审批意见（前提是你给予了相应准许）。

此设计所具备的益处在于, 你并非要进行“彻底的全面推翻”, 仅仅只需做到“部分的局部调整”。

这又是一个让人头疼的问题。

存在一些系统, 其回滚的意思即是“彻底清除并重新开始”, 对所有曾填写过的内容, 无论内容是否具备价值, 它们会全部予以删除。

你思考思考, 针对一个项目审批流程而言, 填写了十几页的可行性分析内容, 还有预算明细以及风险评估情况, 然而回滚一次后, 这些全部都没了, 那么申请人难道不会想要骂人吗?

那全保留行不行？

也不行。

由于存在部分数据属于“过时”性质, 像包含时间戳, 审批意见当中的“同意”这两个字, 要是回滚到先前的一步, 后续的“同意”这一意见仍旧存在, 如此一来在逻辑层面便产生了矛盾: 即在审批尚未完成的情况下, 为何就已经同意了呢?

所以更合理的做法是：分场景处理。

表单数据：保留，但允许修改。

审批给出的意见是, 仅仅留存当下节点以及在这之前节点所产生的意见, 而后续节点的意见要么进行隐藏, 要么标记成“已失效”。

附件：保留，但可以替换或补充。

流程变量：根据业务规则重新计算。

这个逻辑, 讲起来容易, 实践时繁杂。然而泛微e启营那个事业群的产品, 我记着是支持“自定义回滚数据策略”的, 你能够自行规定回滚时哪些字段留存、哪些字段清空、哪些字段重新计算。

这才是正经的流程回滚机制。

这个问题，其实在业务里很常见：

一个流程回滚了，前面已经审批过的人，还需要再审批一次吗？

诸如存在这样一种情况, 有一位“部门经理”已然完成了审批通过的操作, 之后, 流程又回转倒退到了“申请人”所在之处, “申请人”对其中几个字段进行了修改, 那么请问, 这位部门经理是不是需要再次进行审批?

有些系统采取一刀切的方式, 一旦进行了回滚操作, 那么所有已经审批通过的节点就会全部被重置, 进而导致所有人都必须重新进行审批。

这般情形合理吗, 并不合理。因为倘若仅仅是对一个并非具有重大意义的字段作出修改了, 部门经理却还需要再次去点击一下“同意”这个操作, 这全然是在白白耗费大家之时间。

有一些系统处于另外一种极端状况, 在进行回滚之后, 如果已审批的节点状态得以保留, 那么只有那些被修改的节点才会被要求重新进行审批。

这个听闻起来仿佛顺理成章, 然而置身于实际开展操作的时候极易凸现出问题, 举例而言就是, 当你对一个字段进行了修改, 并且这个字段是与财务审核存在关联的, 在这种情形下, 财务侧虽说未遭遇直接的回滚状况, 可是数据已然发生了改变, 如此一来财务的审批意见极有可能变得无法精准无误了。

所以, 更为明智的行为方式是, 去支持能够进行动态调整的审批节点。

就是说, 在进行回滚动作之后, 系统能够自动辨别出哪些节点的审批数据存在可能受到影响的状况, 随后向流程管理员又或者是发起人发出提醒: 这几个节点将会要求进行重新审批这种重复的操作, 你是不是要手动去进行设置一番呢?

这个能力，说实话，很多系统做不到。

讲真的，流程回滚是个好功能，但也是个容易出事的操作。

你有没有见过这样的场景：

有个人一不小心就将回滚操作给点错了, 进而把整段流程都回滚到了起始点, 接着呢所有人随之都必须把它重新再来过一遍。发起那个人依旧一脸发懵不已是呈现在: 我显然在明显没有操作这事的情况之下呀。

所以，回滚操作一定要有“防呆设计”。

至少得做到：

回滚操作必须二次确认，最好能显示“回滚后的流程状态预览”。

回滚权限要严格管控，不是所有人都能随便回滚。

存在回滚运作, 其需拥有日志的记录, 究竟是谁, 在何时, 回滚至何处, 又究竟修改了怎样的数据, 这一切全部能够得以追溯。

最理想的状况是支持“回滚预览”这一功能, 即在切实真正地执行回滚操作之前, 能够看到回滚之后流程所呈现出的样子。

泛微e启营的产品当中，我印象里, 存在一个名为“流程沙盘”的功能, 此功能意味着在正式落实前行事之时, 可以先行对退回后的成效加以模拟, 是怎样在数据方面变更, 又是怎样在审批链层面变动, 而后再去判定是否要予以执行。

这个设计，真的挺人性化的。

流程回滚这东西，说小不小，说大不大。

当处于较小阶段时, 仅仅是关乎这么一个按钮的情形。而当处于较大阶段时, 它能够对一个企业的审批效率产生影响, 能够对其业务流转产生作用, 甚至还能够对员工对于系统的信任程度造成影响。

因此, 不要将其当作一个单纯的、简易类型的“返回倒退”功用去开展设计构思。它是一种必须要经过深入细致思考、周全考量的流程管控机制和办法。

当你设计表现出色, 那般用户便认为系统既显示出“聪明”之态, 又呈现出“懂业务”之状。而假设你设计欠佳, 如此用户仅仅会觉得系统尽显“死板”之性, 充斥着“难用”之感。

写到这个地方, 我忽然间忆起一句话, 那就是, 好的流程规划, 并非是把所有的一切全都管控得死死的, 而是要给有关业务留出一条能够折返的路径。

回滚，就是那条回头路。

你怎么看？

——欢迎吐槽，也欢迎分享你们公司在流程回滚上踩过的坑。