数据模型建好了、主数据标准定了、自动触发场景跑通了——看上去一切完美。

然后三个月过去了。你去翻一下资产台账，发现"存放地点"字段里多了"后面仓库""以前的办公室""不知道"——自由文本的深渊又开始了。

这是必然的——没有数据治理，数据质量一定会退化。 这不是人的问题，是系统运行的自然规律：脏数据会不断产生，如果没有机制去清理和拦截，数据质量只会越来越差。

根因一：源头没有校验。 使用部门的同事在系统里录入资产信息——"型号"字段写了一段描述性文字而不是标准型号，系统也没有拦截。半年后统计时发现这个字段完全没法用。

根因二：变更没有同步。 设备跨部门调拨了，EAM系统里更新了使用部门，但没有同步到财务系统。财务继续按原部门计提折旧。等到月底对账发现不对的时候——已经过了两个月。

根因三：边界没有清理。 资产处置了，但处置单没有关联到资产卡片。卡片状态还是"在用"——实际上设备已经卖了两个月了。年底盘点时"有账无物"——不是实物丢了，是卡片忘了注销。

这三个根因，任何一个不解决，数据质量都会持续下降。

很多企业一谈数据治理就想到"大项目"——上数据中台、建数据湖、搞数据治理委员会。然后因为太复杂，拖了半年没人启动。

数据治理不需要从"大"开始。可以从"最小可行产品"开始——第一个月做什么？

第一周：确定三类关键数据的所有者。 不需要治理所有数据——只需要治理影响决策的"关键数据"。资产主数据的Owner是谁？财务参数的Owner是谁？运行数据的Owner是谁？确定下来。

第二周：建立源头校验规则。 选取录入频率最高的问题字段——"资产类别"、"使用部门"、"状态"。在系统里把这几个字段从自由文本改为下拉选择或自动带入。这是投入产出比最高的一个动作——改了源头，后续所有流转自然干净。

第三周：针对自动触发场景做"数据准入校验"。 验收通过触发入账的——验收单必须有哪些字段？工单关闭触发费用归集的——工单必须填写哪些信息？把这些校验规则配置到系统中，不满足的不允许触发。

第四周：建立一个月度数据质量检查机制。 月末关账前，系统自动检查以下六个维度的数据质量：完整性——关键字段有没有空值；一致性——同一资产在不同系统中的数据是否一致；及时性——业务事件发生后数据是否被及时更新；准确性——数据值是否在合理范围内。六项检查结束后自动生成一份数据质量报告，推送给数据Owner。

第一个月的目标不是"数据质量100%完美"——是"建立了数据治理的节奏和习惯"。

数据治理不是IT部门一个人的事。它需要三个角色的协作，任何一个缺位，治理都做不起来。

数据Owner——业务部门的人。 负责该领域数据的准确性和完整性。资产主数据的Owner是设备部的资产管理员。他知道资产的状态、位置、责任人——他不是懂IT的人，他懂的是设备。

数据Steward——IT或数据部门的人。 负责数据标准制定、数据质量问题处理、系统配置优化。Owner说"这个字段的录入方式不方便"，Steward负责改系统配置。

数据User——所有的数据录入和使用者。 录入时保证数据质量，使用时反馈问题。Owner和Steward的改进建议，来自User的一线体验。

三个角色的职责边界清晰之后，关键是责任到人。Owner是谁，写在岗位说明书里。Steward是谁，写在数据治理制度里。User的责任——录入错误纳入部门质量考核。

数据质量标准。 每一个核心字段定义质量标准。完整性——不允许空值（必填字段）。一致性——同一资产在三个系统中的状态必须一致。及时性——业务事件发生后48小时内数据必须更新至最新状态。

数据质量考核。 每个季度统计各Owner负责的数据域的质量得分。得分低于阈值的——Owner需要在下一季度提出整改方案。连续两个季度低于阈值的——纳入个人绩效评估。

数据变更流程。 非Owner角色修改主数据必须经过审批。Owner批量修改数据必须事前申请。所有修改留痕、可追溯。

数据治理不是终点。它的目标是让所有人都忘记"数据治理"这四个字。

当数据录入已经标准化到"系统不做第二次确认"——因为第一次录入的数据、格式和完整性已经被系统验证通过了。当数据流转已经自动到"没有人需要在两个系统之间搬运数据"——因为所有同步都是事件触发的。当数据质量已经稳定到"管理层不需要在开会前讨论'这个数准不准'"——因为所有人都知道数据是同一个口径的。

到这个状态——共同体系才算真正建立起来了。

作者：白杨，十余年设备资产管理从业经验，EAMX产品负责人。