数据治理中的“临时方案”陷阱：为什么当初的

一、一个字段的十年

某企业ERP系统有一个字段叫“备注2”。系统上线时，实施顾问说这个字段可以留作应急，后续有临时需求可以先填这里，等正式字段建好了再迁移。十年后，“备注2”仍然是系统的一部分，被多个业务流程依赖。财务部用它记录发票的特殊情况，采购部用它记录供应商的临时要求，仓储部用它记录物料的特殊存储条件。同一字段，三种用法，数据格式完全不统一。没有人敢删它，因为不知道删了会影响什么。但它也几乎没有人能说清楚它的准确定义。

“备注2”不是孤例。临时编码、临时客户、临时供应商，类似的临时方案在每一个企业都存在。临时方案设计时只考虑当时的紧迫需求，不考虑长期的可维护性和数据一致性。时间一长，临时方案就变成了系统的一部分，没有人记得它是临时的，也没有人愿意为它的长期存在提供正式的管理和维护。

二、临时方案永久化的形成机制

机制一：紧急需求的频率高于正式方案的更新频率

系统上线初期或业务快速变化期，紧急需求频繁出现。业务部门说“今天就要用”，IT部门没有时间做完整的数据建模和流程设计，于是启用临时方案。紧急需求的频率决定了临时方案产生的速度，业务变化越快，临时方案越多。正式方案的设计和上线需要时间，在此期间临时方案已经投入使用。临时方案的使用时长超过正式方案的设计周期时，临时方案的使用者已经习惯了它的操作路径，切换意愿会降低。时间越长，切换成本越高。

机制二：临时方案的维护责任无人认领

临时方案是谁创建的？可能是多年前的实施顾问，可能是前任IT经理，可能是刚离职的数据管理员。创建人已不在，接手的人不知道这个方案是临时的，只知道系统里有一个“备注2”字段。创建人在职时没有设定退出时间表，接受人接手时没有收到关于临时方案生命周期的交接说明。临时方案在组织记忆中随时间推移而变得模糊，模糊程度与组织人员的变动频率正相关。

机制三：正式方案的变更成本掩盖了临时方案的维护成本

当临时方案的使用范围已经扩大，想把它替换为正式方案时，涉及的系统和流程太多。改一个字段要影响多个系统的接口、报表的查询逻辑、审批流程的触发条件。正式方案的设计和实施成本远高于临时方案诞生时的预期，变更成本的计算维度包括系统数量、接口数量、报表数量、流程数量。高变更成本成为了临时方案永久化的保护伞，业务部门的视角也倾向于停留在“目前能用”的阶段。

三、临时方案的类型与管理缺口

类型一：临时字段

"备注1""备注2""备用字段1""备用字段2"，这些字段是临时方案中最常见的形式。使用时没有统一定义，每个业务部门按自己的理解填写。数据格式不统一，有的填文本，有的填日期，有的填数字。查询时无法过滤、无法统计、无法校验。管理缺口在于：字段的创建缺少明确的业务用途说明，被创建后缺少生命周期管理的跟踪机制。

类型二：临时编码

"TEMP-001""TEST-002"，这些编码用于正式编码体系覆盖不到的场景。临时编码的数据质量不受编码规则约束，格式随意、属性缺失、分类错误。临时编码的数量随时间线性增长，正式编码的规则越来越形同虚设。管理缺口在于：临时编码与正式编码之间缺乏明确的映射管理机制，临时编码的创建缺少有效期设定和定期清理机制。

类型三：临时流程

"特殊情况走线下流程""紧急需求发邮件审批""数据异常手工调整"，这些临时流程绕过了系统，形成了双轨运行。系统里的流程不完整，线下的流程不归档。临时流程的执行依赖个人习惯，换一个人就换一套做法。管理缺口在于：临时流程与系统流程之间的边界没有被清晰地定义，临时流程的启用条件、退出条件和审批要求缺少制度性规定。

类型四：临时接口

"先用Excel导出导入""临时写个脚本同步一下"，这些临时接口是系统集成不完善时的过渡方案。数据在系统间的流转路径不清晰，谁导出、谁导入、频率多少、异常怎么处理，都没有规定。管理缺口在于：临时接口的使用没有纳入系统监控范围，运行状态和错误率无法被观测。

四、临时方案的退出机制设计

原则一：临时方案必须设定退出日期

每一个临时方案在创建时都需要附带一个退出日期，退出日期是基于正式方案的排期来确定的，可以是三个月或六个月。超过退出日期的临时方案自动触发审查，审查不通过的进入淘汰流程。创建临时方案的审批级别与它的退出日期挂钩，退出日期越长的方案需要越高级别的审批。

原则二：临时方案的状态需要定期审查

每季度审查一次系统中的所有临时方案。仍在使用的标记为“活跃”，超过退出日期的触发清理流程，使用范围扩大的触发正式化流程。审查的频率与临时方案的数量和使用范围有关，临时方案越多，审查的覆盖范围需要更广。

原则三：临时方案的正式化有独立通道

当临时方案的使用证明是必要的，启动正式化流程。临时方案转正需要走正式的变更流程，不是在原方案上继续打补丁。正式化的通道不需要重复经历完整的需求调研周期，但需要覆盖数据模型设计、编码规则制定、系统配置固化这三个环节。

五、新易编码中的临时编码管理

物料编码领域，临时方案的重灾区是“临时编码”“测试物料”“紧急编码”。新易编码在设计中内置了临时编码的识别和管理机制。

独立号段：所有临时编码使用独立的号段范围，与正式编码号段不重叠。临时编码的格式与正式编码不同，在查询时可以快速区分。独立号段确保临时编码不会与正式编码混淆，也不会在后续清理时影响正式数据。

自动过期：临时编码在创建时设定有效期，到期后自动冻结。需要延期的，走延期审批流程。临时编码的使用超过三个月的，自动触发正式编码申请流程。临时编码的有效期与它的使用范围关联，使用范围越广的临时编码，有效期越短。

使用范围控制：临时编码只在申请时指定的业务范围内可用，超出范围的调用会被系统拒绝。使用范围限制在源头切断了临时编码向其他业务流程扩散的路径。使用范围的变更需要走审批流程，与创建时的审批级别一致。

临时方案是业务系统的必要组成部分，紧急需求需要快速响应，正式流程需要时间设计。临时方案本身不是问题，临时方案永久化才是问题。

永久化使得临时方案失去了其合理性基础，变成了没有规划的长期存在。临时方案的退出机制需要与它的创建机制配套，不是在创建几年后才开始考虑退出。退出机制的触发条件应该与临时方案的实际使用情况挂钩，而不是与创建人的主观判断挂钩。每个临时方案都对应一个还没有形成的正式方案，退出日期就是正式方案承诺的上线日期。超过退出日期后，承诺失效，临时方案进入待清理状态。清理不是删除，是转正或归档。转正有通道，归档有标准，两者的执行都需要与临时方案的使用范围关联。使用范围越大，转正或归档的优先级越高。不清理也不转正的临时方案会持续累积，直到某个时间点累积到足以引发系统性问题。系统性问题出现时，清理的成本已经远高于当初设定退出日期时处理它的成本。退出机制的核心价值在于防止这个累积过程的发生。临时方案的管理缺口，本质上是对临时方案生命周期缺少整体设计的系统问题，而不是单个临时方案本身对错的问题。

 

如果您有物料编码相关的问题，欢迎咨询新易物料编码