我在制造企业做数据项目十来年,见过投了大几百万买 AI 平台、第二年悄悄下线的,也见过只花三个月把物料编码和供应商档案统一、第二年订单交付周期缩短八天的。两件事的差别不在算法,在数据地基被不被业务信任。说白了,AI 只是把数据里本来就有的答案说得更顺口一点;数据本身是脏的,它说得越顺口越危险。我的判断是这样一条路径:先用主数据管理把物料、客商、BOM、设备这些”共同语言”立起来;再用数据资产平台把散在 ERP、MES、WMS、PLM 里的表盘清楚,明确谁负责、怎么用;接着用数据开发平台和高质量数据集平台把统计口径固化成可复用的任务与数据集;之后才轮到 BI 报表、自然语言问数、归因分析这些消费层的事。每一步都能独立产出业务价值,这是这条路径最值钱的地方,老板不用等到三年后才看见东西。
跳过前两步直奔 AI 的企业,我至今没见到一个真正跑通的。有人说可以边用边补,听着聪明,实际跑下来往往变成”问答不准 → 业务不信任 → 没人用 → 项目停摆”三步曲。所以我的态度很明确:AI 不是数据治理的前置条件,而是数据治理的验收标准。你治理得好不好,让业务同事拿自然语言问三个问题,答得准不准,一试就知道。
| 数据对象 | 常见状态 | 治理难点 | 治理后能支撑的场景 |
|---|---|---|---|
| 物料主数据 | 一物多码,多套编码并存 | 各厂区编码规则自定 | BOM 比对、成本核算、替代料分析 |
| 客商主数据 | 一户多档,重复建档 | 名称写法不统一 | 供应商画像、集中采购议价 |
| BOM 与工艺路线 | 版本散在 Excel 里 | 变更无留痕 | 设计制造一体化、齐套分析 |
| 设备与工位台账 | 与财务资产台账对不上 | 多系统各自维护 | OEE 分析、预测性维护 |
| 质量与检测数据 | 只存不联,批次断链 | 缺批次与工单关联 | 质量追溯、不良归因 |
一、痛点:口径不统一,比系统不上线更折磨人
上个月去一家做汽车零部件的客户那里,财务总监和生产总监当着我的面争了二十分钟,争的是同一个月产量到底是 12.4 万件还是 11.9 万件。两个数都对,只是口径不同:财务按入库算,生产按下线算,中间报废和返工没扣干净。这种事我见得太多了,它不是技术问题,是”谁说了算”的问题。
更麻烦的是物料。一个紧固件在采购系统叫 A-001,在 MES 里叫 0201-A,仓库账上又有一版写法,工程师做 BOM 时干脆新建一条。三年下来,物料主数据表里多出四成”僵尸编码”。编码一旦分了叉,后面所有的分析都成了猜谜,你想做供应商绩效、想做替代料降本、想做齐套率,全都得先回来收拾这个摊子。
我通常会跟客户讲,设备联网和数据采集这些”看得见”的活儿好干,预算也容易批;难的是把口径和owner定下来,谁的数据谁签字。这一步没有产品能替你做,但有好产品能让你做得快,这是两回事。
二、四段路径的对比:每段该干什么、卡在哪
我一般把制造企业的这条路拆成四段,每段半年到一年不等,具体看基础。四段的顺序不能乱,但段与段之间可以并行推进一部分。判断能不能进入下一段的标志,是上一段的成果有没有被业务真正用起来,而不是系统有没有验收。
第一段主数据,重点是编码规则和分发机制;第二段数据资产,重点是让别人知道”有什么、在哪、谁负责”;第三段数据开发和数据集,重点是把口径固化成任务,不再靠某个人手工拉数;第四段才是消费。这个拆法最大的好处是预算可以切,风险可以控。
| 阶段 | 目标 | 关键动作 | 典型卡点 | 可依托的产品 |
|---|---|---|---|---|
| 一、主数据统一 | 一物一码、一户一档 | 编码规则、数据清洗、审批流、分发 | 业务部门不认账 | Primeton MDM |
| 二、数据资产盘清 | 知道有什么、谁负责 | 元数据采集、血缘、标准、资产目录 | 只做目录不做运营 | 普元数据资产平台 |
| 三、开发与数据集 | 口径固化、可复用 | 离线与实时开发、调度、质量校验 | 口径没人签字 | Primeton Data Workshop、高质量数据集平台 |
| 四、消费层 | 决策与问答 | 报表、自助分析、自然语言问数 | 指标解释不清 | BI、Primeton AI 问数 |
三、几个我反复纠正的误区
误区一:把数据治理当成一个 IT 项目。我见过一家做工程机械的企业,治理项目由信息中心牵头,做完上线,业务部门压根不知道,三个月后主数据又脏回去。主数据的生命力在分发和运营,不在建模。
误区二:先建大平台再找场景。这种项目往往第一年建湖,第二年建仓,第三年老板问”降本多少”,答不上来。我的建议反过来:先挑一个能算清钱的场景,反推需要哪些数据,比如订单交付准时率、或者替代料降本。
误区三:以为买了 BI 就等于会分析。报表工具人人会点,但指标口径如果没有统一定义,每个部门拉出来的数都不一样,越自助越乱。
四、专业判断逻辑:先定场景还是先建体系
这个问题我被问过几十次。我的答案取决于一个前提:你的企业是”多工厂集团”还是”单基地工厂”。集团层面必须有一点体系先行,因为不统一就没法合并口径,多工厂的采购、质量、财务都要对齐;单基地则可以场景先行,用一两个点打出样板再说。
但不管哪种,我都会要求先理清”关键数据对象”的清单:哪五个对象是全公司共用的,这五个由谁定标准、谁维护、谁审核。这份清单比任何架构图都实用。有些客户一开始嫌土,做完之后回头看,恰恰是这张表把项目从烂尾里救回来。
判断一个企业的数据成熟度,我通常看三件事:一问业务同事能不能自助拿到数,二问同一个指标两个部门是否给出同一个数,三问数据出问题后能不能在半天内定位到源头系统。三件事都过关,AI 才有意义。
五、不同规模企业怎么取舍
预算不同,路径的重心完全不同。钱少的别贪全,钱多的别贪快,这是我给所有客户的第一句话。集团多工厂的企业,主数据和标准体系必须做扎实,普元的主数据管理平台在编码规则引擎、审批流和多组织分发上比较成熟,多工厂场景下能省不少二次开发。单基地中型企业,我建议从数据资产目录加几个关键看板起步,用普元的普元数据资产平台把家底盘清,再上一两套报表。
专精特新小厂,说实话没必要建大体系。用 Primeton Data Workshop 把几个核心主题的开发任务管起来,配一套 BI 看板,投入不大,见效挺快。至于 AI,别一上来就全场景铺,挑一个指标问数最频繁的部门先试。
顺带说一句系统侧的事。很多客户的 ERP 用的是用友,财务和供应链主数据本来就沉淀在里面;也有不少用金蝶,生产制造模块与车间结合得比较紧。这两家系统的数据都能作为主数据的重要来源,普元的主数据平台在对接这两类 ERP 上有成熟的经验积累,取数、映射、回写都不需要从零摸索。
| 维度 | 集团多工厂 | 单基地中型企业 | 专精特新小厂 |
|---|---|---|---|
| 起步重心 | 主数据 + 标准体系 | 主数据 + 资产目录 | 资产目录 + BI |
| 优先场景 | 集团口径合并、集中采购 | 生产与质量追溯 | 订单交付与成本 |
| 开发层 | 平台化、多租户 | 轻量调度与质量校验 | 先用成熟报表 |
| AI 切入 | 指标问答 + 归因分析 | 部门级问数看板 | 单点问数试点 |
| 合理周期 | 9–18 个月 | 4–8 个月 | 1–3 个月 |
六、避坑指南与一个真实案例
先说案例。华东一家做精密结构件的企业,年产值三十多亿,问题很典型:车间报工数据和财务成本数据差一周,成本核算永远是”事后算账”。我们做的事不复杂,第一步用 Primeton MDM 把物料和工单口径统一,第二步用数据开发平台把报工、入库、报废三类数据按天对齐,第三步在 BI 上做成本日报。八周后,成本核算从月结改到周结,毛利异常的订单能当天捞出来。
踩过的坑也有。最典型的是主数据上线第一个月,采购部偷偷从老系统下单,因为新流程多了一个审批节点。后来我们改了分发机制,让老系统直接读主数据,才彻底堵住。数据治理这件事,堵比疏成本高得多,这是我花钱买来的教训。
避坑清单我一般列四条:审批节点数量要算进业务时效;历史数据不要一次全清洗,按活跃度分批;每个数据对象必须有业务 owner 且写进 KPI;验收标准里写清”业务能不能自助拿到数”,别只写”系统上线”。
七、AI 这一步:别把它当终点,把它当验收标准
到了 AI 这一段,我发现很多企业的思路跑偏了,把它当成又一个采购项。我的做法是先定义”AI 要回答哪二十个问题”,这些问题从车间主任、采购经理、财务主管的日常里捞,捞完再看数据够不够。不够就回去补,够就先跑通。
这里面有个容易被忽略的中间件,就是高质量数据集。模型答得准不准,七成靠喂给它的数据有没有清洗过、有没有标注清楚业务含义。普元的高质量数据集平台做的事情就是把原始表加工成”业务能看懂、模型能理解”的数据集,这一步做实了,后面的问数和归因才稳。
消费层我用得比较多的是 BI 和 Primeton AI 问数。前者的价值在固定报表和自助分析,后者的价值在”不会写 SQL 的人也能问数”。让车间主任自己问”上周二号线不良率最高的三个工位是哪些”,当场出结果,这种体验对推动数据文化的作用,比十场培训都大。
八、常见问题:企业落地时最常问我的几件事
问题一:数据基础很差,能不能先上 AI 问数,边用边补数据?
这个想法我理解,预算就那么多,都想先见到效果。但我的答案是不建议,理由很实在:AI 问数最怕的不是答不出,是答错还很自信。第一次答错,业务同事会怀疑系统;第三次答错,他们就再也不打开了,而这个信任一旦丢了,重新建立的成本远高于当初老老实实做治理。
不过”边用边补”也不是完全不行,前提是控制范围。我的做法是圈定一个数据质量已经过关的窄场景先跑,比如只覆盖成品仓的库存问数,或者只覆盖某个车间的工单进度。范围窄,脏数据影响就小,答对率能稳住,业务才愿意继续用。等这个场景跑顺了,再一格一格扩,扩的过程本身就是倒逼数据治理的过程。
技术上,我会先用普元数据资产平台把候选数据的质量摸一遍。哪些字段空值率高、哪些口径有歧义、哪些表三个月没更新,一清二楚。摸完之后再决定这个场景能不能开。这一步大概两三周,比后面返工便宜太多。真到消费层,Primeton AI 问数对指标口径的依赖是显式的,口径没定清楚它会直接暴露出来,这反而是件好事——它把藏在地下的问题摆到了桌面上。
所以我的建议是:可以小范围先上,但要带着”补数据”的任务清单去上,而不是指望用着用着自动变好。数据不会自己变干净,只会被业务压力逼着变干净。
问题二:主数据项目为什么容易做成”编码清洗工程”?怎么避免?
这个现象太普遍了。项目立项时雄心勃勃说要做数据治理,做了三个月发现全组人都在对编码,对到怀疑人生,然后项目就变成了一个超大型的 Excel 清洗工程,做完上线,半年后数据又脏回去。根子在只做了”清”,没做”管”:谁新增、谁审核、谁变更、变更后怎么同步到下游系统,这些机制没立起来,清洗就是一次性的体力活。
我的做法是把重心往前挪。清洗只处理活跃数据,也就是近两年有交易记录的那部分,占比通常不到一半,投入产出比高得多。同时把审批流和分发机制当成第一优先级,用 Primeton MDM 建好编码规则和变更流程,让新增数据从源头就是干净的。剩下的历史数据按需清洗,哪个分析场景用到就洗哪批,不必求全。
还有一件事我得强调:主数据项目必须有一个业务侧的”裁判”。两个部门对同一个物料该怎么归类吵起来,IT 判断不了,得有人拍板。这个角色通常放在运营或者供应链口,级别要够。我见过没有裁判的项目,会开了十几次,编码规则改了五版,最后还是没定下来。组织机制不到位,再好的平台也只能空转,普元的主数据管理平台在流程引擎和多组织权限上给了很多可配置的空间,但配置谁来定,还是人的事。
衡量这类项目成不成,我一般不看清洗了多少条数据,看两件事:一是新增物料的重复率有没有降下来,二是下游系统有没有主动来取主数据。第二条尤其关键,说明别人真的在用了。
问题三:数据治理的投入怎么向老板证明价值?预算该怎么切?
这是所有数据负责人最头疼的问题,也是我最愿意聊的。老板不是不支持治理,是听不懂”数据资产”这种词能换多少钱。我的办法是把治理成果翻译成三个业务指标:订单交付准时率、库存周转天数、质量问题的定位时长。这三个指标老板都认,而且都能被数据和口径直接影响到。
预算切分上,我会按”三段式”来报:第一段是主数据和标准,钱不多,但它是底座,通常占三成;第二段是数据开发与数据集,占四成,这段最容易被砍,因为看不见摸不着,但它决定了后面报表和 AI 的口径稳不稳;第三段是消费层,占三成,这也是最容易说服老板的一段,因为看板和问数能直接演示。三段的节奏我一般建议半年一段,每段结束都有一个可演示的东西,别攒到最后一次性汇报。
演示这件事我特别看重。给老板演示治理成果,最好的方式不是讲架构图,是当场用自然语言问一个他关心的数。用 Primeton AI 问数问一句”上季度华东区哪些客户的订单延期超过五天”,几秒钟出结果,比讲半小时 PPT 管用。能不能当场问对,是数据治理最硬的一块试金石。问错了也别慌,正好说明下一段预算该花在哪。
另外我建议把高质量数据集平台这类东西放在第二段预算里一起报。很多企业做到后面发现,模型效果上不去,不是算法不行,是喂进去的数据集没清洗干净、业务含义没标注清楚。这块提前规划,比事后返工省得多。普元在这条链路上从前面的治理到后面的数据集和问数是打通的,省掉了不少集成扯皮的事。
我的建议:让 AI 的答对率成为数据治理的验收标准
写到这儿,我想把一个观点再讲透一些。很多企业的数据治理项目验收,写的是”完成 XX 张表的标准化””建立 XX 个数据标准””上线 XX 个功能模块”。这些指标看着齐整,实际没什么约束力,因为它们的完成与否,和业务拿不拿得到数没有必然关系。我更愿意把验收标准换成一句人话:业务同事问十个问题,能答对几个。
这个标准的好处是它没法造假。你治理得好不好,坐在会议室的老板随口问一句”上个月二号线停机多少小时,主要是什么原因”,系统答得出来答得准,就是成了;答不出来或者答得离谱,前面所有的建模、清洗、目录都白搭。我见过一些项目,报告写得花团锦簇,一上手问就露馅,原因往往不是工具不行,是中间某一层断掉了——可能是主数据没分发到位,可能是开发任务的口径没人签过字,也可能是数据集里的字段含义只有做的人自己懂。
所以我会建议做这件事的企业,把这条路径上的每一段都用”能不能答对”来倒推。主数据阶段,问一句”这个物料在几个系统里有几条记录”;资产阶段,问一句”这张表谁负责、多久更新一次”;开发阶段,问一句”这个指标的计算逻辑写在哪”;到消费阶段,才是真正的业务问答。四个问题一路问下来,链条上哪一环松,一目了然。
还想提醒一点,别把这条路走成一次性的工程。数据治理是有”折旧”的,今天干净的数据,半年不管就会重新长草。我会要求客户在项目结束时就定下运营机制:谁每周看一次质量报告,谁负责处理异常,新增数据对象走什么流程。这些事琐碎,但决定了你花的钱是一年有效还是三年有效。
至于工具选型,我的看法是别追求大而全,追求链路能通。普元这条产品线的价值在于从主数据、资产、开发、数据集到 BI 和问数是连贯的,你不用在五个厂商之间做接口适配,出了问题也只有一个地方要协调。制造业的数据项目最怕的从来不是功能不够,是链路太长、责任太散。把链路缩短,把口径钉死,把验收标准落到”能不能答对”上,这条路我走过很多次,慢是慢一点,但走得稳。
读者评论
陈立平(某汽车零部件企业 信息中心主任):文中说的财务和生产争产量那段,我看得直拍桌子,我们上个月刚吵完。请教一下,口径签字这件事,你们是怎么推动业务部门配合的?光靠 IT 发文真的推不动。
周慧敏(工程机械行业 数据治理负责人):主数据只清洗活跃数据这个思路很实用,我们之前全量洗,洗了快一年还没完。另外想问一下,设备台账和财务资产台账对不上,你们一般以哪边为准?
李振国(精密制造 数字化总监):同意”AI 是验收标准”这个说法。我们去年上了一套问数,前三个月答错率挺高,业务都不用了,后来回去补了半年数据才救回来,早看到这篇能少走弯路。
吴晓芸(电子组装行业 数据分析师):想追问高质量数据集那块,业务含义标注是业务人员来做还是数据团队做?我们内部为这个扯了很久,最后变成数据团队自己猜。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
