工作流与审批流

公司采购了一套流程引擎K2，据说嫌贵，采购的是阉割版。
由于公司内部多半只是简单的审批流，加上内部的一些KPI导向，又再次封装（阉割）了一般，内部叫BPMS。 并且领导要求，以后所有流程必须使用BPMS。此为背景。
但这时的BPMS其实已经被阉割的只能做简单审批流了。

而笔者遇到一个需求，属于复杂的工作流。悲剧由此开始。

审批流和工作流的差异在哪？ 我的理解是，如果业务价值是在审批完成后产生的，那它就是一个审批流。
如果每一个动作本身就能产生业务价值，那它就是工作流。

举个例子，一个请假要经过A、B、C多个审批节点，不管中间反复驳回多少次，业务上都不关注，唯一有价值的就是这个请假流程最终被审批通过后，需要通知人力系统将年假额度扣减，如果是事假，可能还需要扣减工资等。 所以请假是一个典型的审批流。

再看一个房屋报修维修的例子。房屋报修后产生一个维修单，派单给维修工；维修工可以接单，也可以拒单；维修完成后继续流转到验收岗；验收通过后正式交付给报修人验收；报修人不满意可以再次要求返修；等等。 这个例子里的每一个动作（派单、接单、返修）本身都具有业务意义。它是一个典型的工作流。

当然，技术上不区分什么工作流、审批流，派单接单相当于同意，拒单返修相当于驳回。 审批流、工作流原本都是业务上的抽象。如果从技术上去设计，可以做一套很全面的引擎去同时支持两种场景。 但是从实际使用的角度（用户体验）出发，可以针对起业务上的核心关注点（业务价值）的不同，分别在使用上做一些简化以提高易用性。

开头所说，我司即是针对审批流来做了一些简化。简化到已经无法完成一个正常的工作流。
举个例子，一个工作流5个节点，分别是 1、2、3、4、5 。 2同意到3，和4驳回到3，要能区分开来，这已经是最基本的需求了吧？ 4驳回到3，和5驳回到3，要能区分开来，不过分吧？但是现在它就是区分不了到底是4驳回的，还是5驳回的。

其实我觉得这个简化也没啥毛病，毕竟内部90%以上的需求都是简单的审批流，那当遇到剩下的10%的工作流的时候，就让开发人员自己来搞定呗。

特么又非要一刀切，非要用bpms不可。跟他们解释，他们要么仗着职位比你高，一句“别争论了，就用bpms”；要么假装问你是有什么问题解决不了？bpms不支持的地方都可以安排人去再加上。
但这就不是技术问题，这是成本问题。
技术问题最终都可以解决，用各种方式来绕过。但软件架构、技术选型，最终的目标都是以最低的成本来实现系统功能。

另外这还牵扯到一个产品定位的问题了。 你bpms到底定位是什么？如果你搞bpms目标就是简化审批流，那工作流就别硬用。
不能因为手里有把锤子（BPMS），就看什么都是钉子呀，什么都非要用BPMS来做。
如果你遇到复杂工作流的时候，又去把简化掉的功能重新加回去，那不就又搞成原版的k2了吗？你搞bpms的意义在哪？

如果你觉得本文对你有帮助或不错，可略表心意，请我喝一杯冰可乐。 ☕