接手时，一张客户表有七个版本
老陈入职星空合作的一家制造企业时，岗位名称叫数据管理员，实际上更像“表格消防员”。销售部有一张客户跟进表，售后部有一张服务记录表，财务部又按开票信息维护了一份客户名录。三张表都叫“客户主数据”，可字段数量、命名方式、必填要求全不一样。最典型的是客户名称：销售填简称，售后填合同名，财务填开票抬头，同一个客户在三张表里能出现三种写法。
老陈没有急着建系统。他先做了一件看起来很笨的事：把三张表并排打印出来，用不同颜色的笔标注同义字段和冲突字段。两周后，他拿着一份“字段对照草稿”去找三个部门核对。星空在数据管理栏目里反复强调一个观点：归集的第一步不是技术导入，而是让各方看见差异在哪里。老陈这份草稿后来成了全公司字段标准的雏形。
字段标准不是定出来的，是谈出来的
很多人以为字段标准是数据管理员关起门来写一份规范文档，然后发下去执行。老陈的经历恰好相反。他先约销售内勤聊了两次，发现销售表里的“客户等级”其实混用了两个概念：一个是成交规模，一个是回款速度。售后表里的“服务状态”又掺进了合同履约信息。如果不把这些业务含义拆清楚，字段名统一了也没用。
老陈的做法是给每个关键字段配一张“说明卡”，写清楚三件事：
- 这个字段回答什么业务问题，比如“客户等级”只回答成交规模，不回答回款快慢；
- 取值范围和空值规则，比如客户名称不允许为空，且必须与营业执照名称一致；
- 维护责任人和变更记录，谁改了规则、为什么改，都要留痕。
这套说明卡在星空的数据管理实践中被证明很有效：字段标准只有落到“谁维护、怎么填、错了怎么办”这三个问题上，才可能被执行。老陈前后改了四版说明卡，每一版都拉着业务口的人逐条确认。第三版时，财务部主动提出把“开票抬头”和“合同名称”拆成两个字段，归集逻辑一下子顺了。
校验规则要卡在录入环节，而不是事后清洗
字段标准定下来之后，老陈遇到第二个难题：历史数据怎么处理，新数据怎么保证不跑偏。他最初的想法是每月导出来集中清洗一次，结果发现清洗速度永远赶不上新增脏数据的速度。星空在数据质量话题里多次提醒，校验规则前置比事后补救更省力。老陈后来把规则拆成两类：
- 硬规则放在录入端，比如客户名称必填、统一社会信用代码位数校验、手机号格式校验，不通过就不允许提交；
- 软规则放在归集端，比如同一客户在不同表中的地址不一致时，系统标记出来由责任人确认，而不是直接覆盖。
这套机制运行半年后，新产生的客户记录重复率明显下降。老陈说，关键不是规则多复杂，而是每条规则都有人认领。星空在数据归集方法中强调责任到人，老陈的做法正好印证了这一点：没有责任人的校验规则，最后都会变成摆设。
口径分歧收口靠的是“对账底稿”
归集到最后，老陈发现最难的还不是字段和规则，而是口径。销售部说活跃客户数是“近三个月有订单”，售后部说是“近半年有服务记录”，财务部又按开票周期算。三个数放在经营会上，谁也说服不了谁。老陈没有去争谁对谁错，而是做了一份“口径对账底稿”，把每个口径的计算逻辑、数据来源、时间窗口和排除条件列清楚，让三个部门坐在一起逐条确认。
这份底稿后来成了星空数据管理方法里的一个常用工具：口径不一致时，先别改报表，先把底稿摊开。老陈的底稿前后更新了六版，每一版都附上变更说明。三年下来，公司客户主数据从七张分散表归集成一张统一底表，字段标准、校验规则和口径说明都能追溯到具体责任人。老陈说，数据管理没有什么一劳永逸，无非是把笨功夫做在前面，让后面的人少返工。
