前言

我们从事的几乎所有的 B端数字化改革项目，都有涉及流程问题，不幸的是，笔者从业多年，却很少看到一个企业的流程能够被梳理的非常清楚的，更少有称职的工具来支撑企业流程。

那么，流程的定义是什么？复杂性在哪里？我们又如何去支撑这些复杂性？这些问题值得探讨。

怎么定义流程？

我们每一个人的日常生产生活中，都在有意识或无意识地参与、组织、管理各种流程，比如：

每天早上，我们起床后都会先刷牙，再洗脸，然后换衣服、吃早饭，来上班；
去医院看病，要先挂号，再付钱，再排队看医生；
做研发工作，要先做需求分析，形成用户故事或交互原型，再以此设计UI稿、数据库结构、对外接口，然后再进行编码工作，等等。

那么，流程的定义是什么？什么样的事物可以称为流程？

流程的概念兴起于第二次工业革命时期的工业流水线。到目前为止，不同的组织、学者对流程的定义略有不同，较权威的有以下几种：

迈克尔·哈默（20世纪90年代杰出的管理思想家）：流程是把一个或多个输入转化为对顾客有价值的输出活动。
达文波特（流程再造专家）：流程是一系列结构化的、可测量的活动集合，并为特定的目标产生特定的输出。
ISO9000：流程是将输入转化为输出的相互关联和相互作用的活动。

从上述流程的权威定义不难发现，流程具有三个鲜明的特点：

流程包含了一组互相关联的活动。
流程具有输入和输出。
流程一般具有价值属性，即流程需要对客户产生价值。

此外，一般认为流程包含六个要素：输入、若干活动、活动间的互相作用、输出、顾客、最终创造的价值。拿起床这件事举例，六要素：

输入：半睡半醒的你。
若干活动：刷牙、洗脸、换衣服、吃早饭。
活动的相互作用：刷牙洗脸换衣服的速度决定早饭在哪吃。
输出：精神饱满的你。
顾客：你是被什么唤醒的？
最终创造的价值：做好准备开始新的一天。

B端流程的复杂性在哪里？

中大型组织的流程，在当前普遍的数字化、智能化改革背景下，除了流程本身的定义和要素之外，还有一些共性的特征：

强调时效：对每一个节点都有时效要求，并附有超时惩罚机制。
强调闭环：闭环往往体现在两个方面：一是有输入也有输出；二是有评价反馈机制。
多跨协同：组织的流程往往面临跨地区、跨部门、跨系统、跨层级的协同问题。
流程重塑：流程重塑的过程很难一蹴而就，一个打破原有的部门壁垒，有价值、有生命力、能落地执行的流程是不断试用、讨论、迭代、修改出来的。在产品推进过程中，流程是不断变化的。初期调研形成的流程，和最终落地执行的流程，往往差异很大甚至南辕北辙。

这些特点使得支撑流程的工作变的比较艰巨。

以一家中型企业一位项目经理同事（化名小张）发起一次项目上的供应商产品采购流程举例类比。

初始的采购流程

这是一个简化后的，最简单的流程。

由项目经理小张发起采购申请，项目中心进行审批，审批时可编写备注，指出申请单、合同中存在的问题，退回修改，审批通过后，流程结束，并抄送给采购部老张。

流程的输入是潜藏着合规风险的采购申请单，输出的是审核修改过的合规的采购单。下面的章节，我们为这个流程逐步加入时效、闭环、多跨等特性，对这个流程进行改造。

为了简化，下面章节的流程图省略各个审批节点的采购申请单图示。

加入处理时效

假设一个这样的场景：公司需要对项目中心的审批时效进行考核，采购申请单滞留超过12小时，就扣除项目中心的考核分1分。

加入处理时效后，流程分支一下多了不少（标黄部分）：

在小张发起采购申请后，需要同时启动一个倒计时装置，当倒计时结束后，需要扣除项目中心的考核分，同时通知小张。
当项目中心对申请进行审批时，需要考虑是否要停止倒计时。

思考题1：
公司的需求发生了变化，要求倒计时结束前2小时发飞书消息通知项目中心，倒计时结束前1小时发短信通知项目中心，流程要怎么设计？

思考题2：
公司的需求发生了变化，要求考核规则可配置，扣多少考核分和审批超时的时间挂钩，流程要怎么设计？

加入评价闭环

上述场景运行一段时间后，发现了一个问题：

多位项目经理向项目中心反馈采购申请审批速度慢，虽然没有超过12小时，但经常花很久才审批，并且经常遗漏采购合同中的问题，审批质量很差。

于是公司决定再对流程进行升级：

向项目经理授权，可以对审批进行评价（1-5颗星），对于3星以下的流程，有权退回重审。
对于审批结束的流程，输出审批后的合同附件及相关信息到公司项目管理系统，进行备案。

加入评价闭环后，又多了一个流程分支（标蓝部分）：目前看起来都还好，流程还不算太复杂，但现实中的需求往往更复杂，比如：

小张对流程进行评价后，直接结束流程，但是可以重新发起这个流程；
流程的评价和项目中心的考核挂钩，对于0星、1星、2星的流程进行对应的扣分处理，对于4星、5星的流程进行加分处理；
使用流程的人较多，采购管理系统是个老系统，无法支撑频繁的系统调用，需要考虑优化方案；

加入多跨协同

上述流程运行一段时间后，由于公司规模扩大以及业务差异，总部和各地分公司各自使用符合属地政策要求的，互相独立的采购管理系统。

小张作为总部项目中心的员工，下沉到X市分公司短期任职。

由于系统互相独立，但又需要在流程上互相协同，于是产生了多跨协同场景：

由于编制在总部，小张只能使用总部的采购系统发起申请。
小张需要采购承德当地供应商的产品，这个供应商在X市分公司的采购系统供应商名录里。
采购流程首先需要承德分公司项目部审批。
审批通过后，需要总部项目中心及承德云栖分公司负责人联合审批。
联合审批同时通过，流程结束，同时通知各分公司采购系统，更新采购产品名录。
联合审批若有一人不通过，则审批不通过，退回重审。

为了支撑上述场景，需要对流程进行大幅改造：

可以看到，为了支持这个跨层级、跨地区、跨系统的多跨场景，流程变复杂了许多（标红部分）。

同时，为了实现供应商数据的互联互通，需要将各个分公司采购系统中的供应商名录经过清洗后归集到统一的供应商专题库，再将这个专题库提供给总部及各分公司的采购系统使用。

这是一个较简单的多跨场景，在实际政务环境下，多半会遇到下面这些问题：

X市分公司对流程对接比较消极，两个系统不能打通。
X市分公司采购系统的ISV维护期已过，无法进行技术改造，对接在技术上遇到困难。
X市分公司采购系统的ISV不提供技术文档，技术人员更迭频繁，对自己的系统也不熟悉，对接过程相当艰难，后端工程师小李坚持了一个月后提出想回老家休息一段时间。
多个分公司不愿意开放采购系统数据库权限给总部，供应商专题库建设进度缓慢。
X市分公司项目部和总部项目中心内部各有审批子流程。
。。。

小结

通过本文的推演，相信大家对B端流程的复杂性有所了解了，目前也有飞书、钉钉，和一些专注于流程开发的企业，提供了强大的流程设计、管理工具，但仍然难以良好地支撑上述场景，本文抛砖引玉，希望能有更多的朋友提供好的想法、建议和产品。

浅谈中大型组织流程的复杂性

前言