客户是一家有四个生产基地的制造企业，OA 中沉淀了 137 条审批流，由三位已离职的同事在八年间断续搭建。没有人能完整说清每条流程的适用条件。
梳理之后发现：121 条流程遵循同一个模式——发起、部门审批、金额阈值分支、财务复核、归档。差异在于阈值、审批人角色、以及是否触发合同评审。真正结构不同的只有 16 条。
模式 + 参数
我们把流程拆成两个层次：模式定义节点与连线的拓扑，参数定义阈值、角色与触发条件。121 条流程收敛为 1 个模式与 121 组参数。参数以数据形式存储，业务管理员可以在界面上调整，不需要开发介入。
维护成本的变化是直接的：过去新增一个基地需要复制并修改 30 余条流程，现在只需新增一组参数。上线四个月，客户自行调整了 47 次阈值与审批人，没有产生一次变更请求。
剩余的 16 条
结构特殊的 16 条流程被保留为独立定义，但它们共享同一套节点库与审计机制。这里没有强行归一——为了统一而扭曲业务语义，是这类治理项目中最常见的错误。