企业规模做大以后,意识到要推动流程标准化从而建立流程部门。这个部门会被期待1. 建立流程体系;2. 推动企业的流程标准化;3. 帮业务部门提效。
三个目标是渐进式的关系,调研业务、梳理制度、访谈部门、发布流程文件是常态。难点从流程标准化的落地开始。企业期待的流程标准化到底什么样,根本没有一套标准答案 - 流程文件齐全,流程图统一,流程线上化,还是同一类业务在不同部门、不同单位之间,能够按相对一致的规则运行。
这个问题没有讲清楚,流程工作只能变成“先把能做的做了”:流程体系先画出来,流程文件先发布出去。久而久之,画流程体系就被等同于推动流程标准化。
但这两件事不是一回事。
流程标准化本质上是化繁为简,让同一类业务能够按照相对一致的方式运行,并通过标准化的业务执行获得更高效、更高质量的业务结果。
流程文件、流程图和系统都只是手段,不是结果。
流程标准化要做实,先要分清几层东西。
制度文件 描述的是业务原则和管理边界。它规定哪些事项要审批,哪些事项要备案,什么金额对应什么权限,哪个部门承担什么责任。制度不会,也不应该,把所有操作动作都写进去。
流程文件 把制度里的要求拆成事项、节点、角色、输入材料和输出结果。它比制度更接近执行,描述的是业务“应该怎么做”。
系统流程 把流程文件里写的“部门负责人审批”,到了系统里要变成具体角色;文件里写的“材料完整后提交”,到了系统里要变成字段、附件和校验规则;文件里写的“重大事项升级审批”,到了系统里要变成金额条件、风险等级和分流路径。
系统流程、业务口径、执行规则不做到99%的透明统一,流程标准化只能停在文件层面。

有些企业制度写得很完整,但流程文件没有把制度要求转成可执行的事项。制度里写“重大事项需审批”,流程文件却没有说清楚什么算重大事项,哪些材料能够支撑判断,哪些岗位有权提出升级。
有些企业流程文件发得很多,但系统没有承接住。文件里写了风险分级,系统里只有一个通用审批流;文件里写了异常处理,系统里没有异常类型字段;文件里写了退回补充材料,系统里只能退回到发起人,无法区分到底缺什么。
这些如果没有想明白,流程标准化甚至到不了执行阶段,就已经开始变形了。
实际的流程执行,是流程标准化落地之后的真实反馈。
很多企业的系统流程看起来是完整的。业务人员先在线下把事情沟通完,再回系统补流程,审批记录是完整的,流程状态也是闭合的,但系统记录的只是事后补录,不是实际决策过程。
管理层看到的是流程完成率、平均审批时长、节点状态都符合要求,实际业务现场处理的却是材料不齐、规则不清、责任不明和系统不适配。

这里面有一个很容易被忽略的问题:流程标准化的管理颗粒度。
企业最终想以什么颗粒度做管理,流程文件和系统设计就应该尽量以什么颗粒度表达。只在流程图上写一个“部门审批”,管理颗粒度就只能到部门;如果需要区分金额、风险、材料完整性和异常类型,流程文件和系统字段就要把这些东西提前表达出来。否则,流程文件写得再完整,实际执行还是会回到线下判断。
标准化的落地不仅取决于流程文件是否发布、系统是否上线,还取决于流程图中的每一步,能不能支撑真实业务稳定运行。但更重要的是,企业到底能否知道真实的业务流程到底是如何被执行的。
80年代电脑和Excel普及以后,管理层已经习惯用数据看销售、库存、财务、客户和利润等经营结果。流程挖掘在2010年代之后被更多企业关注,补上的正是用数据观察流程执行过程。
过去企业复盘流程,主要看制度、流程文件、流程图和访谈。制度能看到要求,流程文件能看到设计,访谈能听到经验,流程挖掘则把流程治理推向了事实和数据驱动。

它看一笔业务从哪里开始,经过哪些节点,在哪里停留,被退回几次,是否重复提交,是否走了非标准路径。这样一来,流程讨论就不再只停留在文件和访谈里。
这层数据的价值,不是替代流程部门,而是让流程部门有机会验证前面的工作。
制度要求的路径,实际有没有发生;流程文件里的例外,系统有没有承接;业务经营中沉淀下来的小技巧,是否应该被纳入标准流程;反复出现的绕行路径,到底是合理变通,还是管理漏洞。

只有看到并分析了流程数据,企业才能知道流程标准化是否真正落地,还是只是完成了又一批无人问津的流程资产。
四、流程标准化要回到真实执行里验证
见过太多流程部门推动了流程体系搭建,最后除了上千页的流程文件和PPT,拿不出实际的业务结果。
流程体系可以先画,流程文件应该发布,信息化系统也该上。但这些工作不能直接等同于流程标准化。它们只是把企业对流程的理解表达出来。表达之后,还要回到真实执行里验证。
流程文件发布了,也不代表流程真的被执行了。系统上线了,不代表流程真的标准化了。当企业愿意把制度、流程文件、流程设计和执行日志放在一起看的时候,流程标准化才算真正开始。