一个开了四次会还没结论的问题
先讲个真事。今年3月，我在浙江一家做注塑机的工厂驻场，他们上预测性维护平台已经半年，卡在了一个听起来特别离谱的问题上：设备数据归谁管？
设备部说：传感器装在我的机器上，数据当然是设备的，我们要拿它做保养决策。IT部说：数据进了数据中台，采集链路、存储、权限都是我们维护的，凭什么你们绕过我们直接取数？两边吵了四次协调会，总经理都出面了，还是没个结果。项目就这么耗着。
你可能觉得好笑，但踩过这个坑的人都懂------这是绝大多数制造业数字化项目的必经之路。技术问题都有文档可查，组织问题才是真正的硬骨头。
争议的根源：不是数据，是权和责任
说白了，数据ownership之争的本质是两件事：改数据的权力，和数据出问题的责任。
我举个具体例子。那家工厂的振动传感器采样频率，设备部想从1kHz提到5kHz，因为厂里新上的高速主轴需要更高分辨率。但采样一提，数据量涨5倍，IT部的存储和带宽预算立马超了。谁有权做这个决定？没有答案，所以谁都不敢拍板。
再比如数据质量。上个月设备部发现某台机的历史数据有一段异常，想让IT部清洗掉。IT部的说法是：我们只知道数据在传输层面是完整的，传感器漂移导致的偏差我们没法判断，这该你们设备部提标准。设备部说：我们提了标准，你们得执行。然后就没有然后了。
有意思的是，这两个部门吵的其实不是同一个问题。设备部吵的是"数据好不好用"，IT部吵的是"系统稳不稳、成本可不可控"。鸡同鸭讲，能吵出结果才怪。
我们趟出来的和解路径
后来我们帮他们设计了一套方案，核心思路是"数据分层、责任共担"。跑了一年，运转得还行，我把框架分享出来。
第一层：定义数据的"业务归属"和"技术托管"两个角色。业务归属归设备部------他们定义数据的含义、质量标准、使用场景；技术托管归IT部------他们负责采集链路、存储、权限和安全。听起来像废话？不，关键在于我们把这个写进了正式的《数据管理办法》，盖了章，和绩效挂钩。开会吵一万遍，不如落一条制度。
第二层：建一个两部门各出两人的数据委员会，月度例会。所有跨域变更（比如提采样频率）必须在会上提案，委员会两周内给结论。决策慢一点，但不踢皮球了。
第三层，也是最实操的一层：元数据目录。我们用Apache Atlas搭了个简易的数据地图，每张表都标清楚"业务Owner"和"技术Owner"两个字段。谁的数据出了问题，一查便知，扯皮空间大幅缩小。
yaml
# 我们数据目录里一张振动数据表的元数据示例
dataset: vibration_raw
business_owner: equipment_dept.li_wang # 设备部李工，负责口径与质量标准
tech_owner: it_dept.zhou_ming # IT部周工，负责管道与存储
sla:
completeness: 99.5%
latency_max: 5s
quality_rule: "采样值超出±50g视为传感器异常，由设备部确认后标记"注意这里有个细节：quality_rule这一条写得越具体越好。我们最早写的是"异常数据需要清洗"，结果两边对"异常"的理解完全不一样，白吵一场。后来改成量化的规则，争论少了八成。
一个反直觉的建议
很多咨询顾问会说：让一把手拍板不就行了？说实话，一把手拍板只解决"谁说了算"，解决不了"谁干活"。领导指定数据归设备部，IT部照样可以消极配合，管道三天两头出问题，最后项目还是死。
我的观点是：别追求一个"最终归属"，把ownership拆成业务和技术两个维度分别落实，比争出一个赢家有效得多。数据不是资产吗？资产的产权从来都是一束权利，不是单一所有权，工厂里的数据也一样。
最后说两句
写这篇文章的起因是上个月一个老同事打电话问我同样的问题，我发现三年过去了，这个问题还是新项目最常见的死因。
技术人会本能地想用工具解决一切，但数据治理这个事，工具最多占三成，剩下七成是流程和共识。如果你正在做预测性维护项目，我的建议是：在买第一个传感器之前，先把"这份数据谁管"这个问题写在立项文档里，逼着两部门当场谈清楚。晚谈，代价只会更大。