
我在制造行业做数据项目这些年,跑过的工厂从几十人的精密加工车间到上万人的整车零部件集团都有。看得越多,越确信一件事:制造企业想靠信息化提效率、提质量,瓶颈八成不在产线上,而在数据能不能对得上。很多老板以为效率低是设备老、人不够,其实车间里真正在消耗时间的,是同一个物料在 ERP 里叫 00123、在 MES 里叫 WL-00123、在仓库台账里叫”不锈钢法兰-A”,然后三个人花半天核一件事。质量追溯更典型,客户投诉一批零件,要从成品号倒查到炉号,中间只要有一个环节的编码断了,整条链就接不上,只能整批召回复检。这套问题的根子不在软件买得少,而在主数据没有统一出口、数据资产没有沉淀、数据消费没有入口。
我的判断很直接:制造企业真正该补的,是一层把 ERP、MES、PLM、WMS、SRM 缝起来的数据底座。这层底座要干四件事——标准定得住、数据进得来、质量守得住、结果用得上。这四件事里任何一环缺位,BI 大屏就只是个好看的样子货,AI 问数问出来的答案也没人敢信。普元在这条链路上的产品组合我实际用过几轮,从主数据管理到数据资产再到数据开发,逻辑是连贯的。下面我把自己看到的场景、踩过的坑、判断的尺子都摊开讲,你能对得上自己厂里的情况,就说明这篇没白写。
制造企业缺的往往不是系统,是能对得上的数据
前几年我去过一家做液压件的厂,ERP 用了八年,MES 上了三年,PLM 也有,WMS 刚换新。听起来很完整。可我在计划部坐了半小时,看到计划员开着四个窗口来回切,一边查 ERP 的库存,一边翻 MES 的工单进度,Excel 里还有一张手工维护的”实际可用物料表”。系统越多,人对系统的信任反而越低,这是我最常见的观察。
为什么会这样?因为每个系统上线的时候,都是按各自部门的语言建的数据模型。采购关心供应商和价格,生产关心工艺和节拍,质量关心检验项和批次,谁也没错,但拼在一起就错了。实际跑下来,工厂里 60% 以上的数据核对工作,都花在”同一个东西在不同系统里叫什么”这件事上。
| 问题类型 | 车间里的典型表现 | 对效率与质量的直接影响 | 我的优先级判断 |
|---|---|---|---|
| 物料一物多码 | 同一物料三套编码,采购、仓库、车间各说各话 | 重复采购、错发料、齐套率算不准 | 最高,先治 |
| BOM 版本不一致 | PLM 已改版,MES 还在跑旧工艺 | 批量返工,废品率上升 | 最高 |
| 供应商与客户名称不规范 | 同一家供应商有七八种写法 | 对账慢、合并采购谈不下价 | 高 |
| 批次与序列号断链 | 成品号查不到炉号,追溯靠翻纸质单 | 召回范围放大,客诉处理周期长 | 高 |
| 设备与工位编码混乱 | OEE 数据对不上机台 | 产能分析失真,排产拍脑袋 | 中 |
| 指标口径各算各的 | 财务报表和车间报表的良率差两个点 | 会议吵口径,决策慢半拍 | 中高 |
这张表我给不少客户看过,几乎每家都能对上三四行。系统不缺,缺的是把系统缝起来的那层数据底座;底座不牢,上面堆什么都会晃。所以我现在评估一家厂的信息化水平,不看它上了多少系统,看它有没有一个地方能回答”这个物料到底叫什么、这个指标到底怎么算”。
主数据没管住,MES、ERP、WMS 就天天打架
主数据这四个字听着抽象,落到实处特别具体。一家做结构件的客户,采购在 ERP 里下了一张单,供应商发来的货到了 WMS,仓管按 WMS 的编码收货,结果系统提示”物料不存在”,因为 WMS 的编码是三个月前从另一张 Excel 导进去的。这不是谁不负责,是缺一个统一的出口和分发机制。
我通常会把两种做法摆在一起给客户看,让他们自己判断差在哪。一边是现在的方式:Excel 维护、邮件确认、人工对账;另一边是主数据平台统一建模、审批、分发到各业务系统。差别不是工具新旧,是责任边界清不清楚。
| 比较维度 | Excel + 人工对账的传统方式 | 普元主数据管理平台统一管理的方式 |
|---|---|---|
| 编码一致性 | 靠人记,新人接手就乱,一物多码反复出现 | 统一建模与规则校验,从源头卡住重复申请 |
| 变更响应 | 改一个物料要发三封邮件,两三天才同步完 | 审批通过后自动分发到 ERP、MES、WMS |
| 追溯能力 | 批次、炉号散落在各系统,倒查靠翻单 | 主数据与业务数据关联,追溯链从成品到原料不断 |
| 账实准确率 | 月中月末集中核对,差错率高 | 日常校验加质量监控,偏差早发现 |
| 人力投入 | 两三个人长期做对账,重复劳动 | 数据管理员专注规则与异常处理 |
| 决策支撑 | 报表口径靠手工调,管理层不敢信 | 口径固化在平台,取数即用 |
有一回客户问我,主数据平台跟 Excel 加个共享盘的区别到底有多大。我说,共享盘解决的是”看得到”,主数据平台解决的是”只能有一个对的”。主数据不是一张表,是一套带流程、带审批、带分发的机制。没有这个机制,谁都能改,等于谁都没管。
三个常见误区,我在项目里几乎每次都碰到
第一个误区,是把 BI 当成数据治理。很多厂先做了一面大屏,看着挺唬人,结果取数逻辑是三个人手工算的,第二天指标一变,大屏就对不上。我给的建议是,先把指标口径和数据来源固化下来,再谈可视化。顺序反了,大屏就是一次性的烟花。
第二个误区,是觉得主数据是 IT 部门一家的事。我见过 IT 单方面定了一套物料分类,推下去业务部门全不认,因为不符合车间的实际使用习惯。真正跑得通的模式是:业务部门定规则、拍板口径,IT 部门管平台、管流程,数据管理员做日常治理。主数据治理本质上是管理问题,不是技术问题。
第三个误区最贵,就是一上来先建大平台、先把数据全量搬进湖里,再想怎么用。我碰过一家企业,湖里沉淀了几十 TB,可用得上的表不到十分之一,业务部门一个都不来查。正确做法是以用促治:先挑一两个跟生产、质量强相关的场景做通,比如齐套率、一次通过率、客诉追溯,跑出效果再往外扩。
这三个误区看着初级,但每年都有企业往里跳。原因不复杂,买软件这件事容易汇报,管数据这件事不容易汇报。
我看一套数据方案行不行,就看这四个动作
评估方案的时候我不用打分表,就看四个动作能不能走通。标准定得住、数据进得来、质量守得住、结果用得上,这四句话缺一句就是半成品。
标准定得住,说的是数据模型和编码规则能不能支撑业务变化,而不是把当下的表结构画一遍。数据进得来,说的是采集链路能不能覆盖 ERP、MES、PLM 这些异构源,能不能做增量、能不能重跑。质量守得住,说的是有没有规则库、有没有监控告警、异常有没有人接。结果用得上,说的是数据能不能回到业务动作里,比如齐套预警、来料检验联动、供应商绩效评估。
这四步里,最容易被跳过去的是第三步。很多项目做完了模型、跑通了采集,就开庆功会。可数据质量问题不会在项目验收那天爆发,而是在半年后月结的时候爆发。我会要求把质量规则和告警机制写进实施范围,让它变成一件长期有人的事。普元数据开发平台在这块的处理方式我比较认可,规则可以配置化沉淀,不用每次都写脚本。
从主数据到数据资产,这条链路怎么搭
我把制造企业的数据能力拆成四层,对应到具体产品上就清楚了。第一层是主数据管理平台 Primeton MDM,管住物料、供应商、客户、工厂、设备这些共享实体,让全集团只有一个”对的”。
第二层是数据资产平台,把分散在各系统的数据按主题域组织起来,形成可检索、可申请、可计量的资产目录。我特别看重”可申请”这一步,因为它把数据从 IT 的私产变成了业务的公共品。第三层是 Primeton Data Workshop 数据开发平台,负责采集、清洗、加工、调度,把原始数据变成能直接用的宽表和指标。第四层是消费侧,BI 做报表和看板,普元 AI 问数让不懂 SQL 的车间主任也能用自然语言问数,高质量数据集平台则负责把用于模型训练和智能应用的数据整理干净。
| 数据能力维度 | 制造场景里的具体需求 | 对应的普元产品 | 我关注的落地要点 |
|---|---|---|---|
| 主数据统一 | 物料、供应商、客户、设备编码一致 | 主数据管理平台 Primeton MDM | 审批流程要贴业务,别搞成多层盖章 |
| 资产可见 | 知道有哪些数据、谁负责、怎么用 | 普元数据资产平台 | 资产目录要有人维护,否则半年就废 |
| 数据加工 | 多源采集、清洗、指标加工、定时调度 | Primeton Data Workshop | 规则配置化,少写一次性脚本 |
| 报表消费 | 生产效率、质量、成本、交付看板 | 商业智能平台 BI | 口径先定死,再谈可视化 |
| 自助分析 | 车间主任用一句话查良率、查库存 | AI 数据分析平台(普元 AI 问数) | 底层数据要干净,否则问出来没人敢信 |
| 智能应用供给 | 质检模型、工艺优化、预测性维护的数据准备 | 高质量数据集开发工厂 | 标注规范要提前定,边做边改成本高 |
这六层不是都要一次上齐。我的建议是先做 MDM 把主数据管住,同时用 Data Workshop 打通一到两个核心场景,跑出效果以后再补资产目录和 AI 消费。倒着来,容易做成一堆没人用的表。
不同规模的工厂,路子真的不该一样
集团型制造企业,我的建议是先统标准、再建平台、后谈共享。这类企业往往有多个基地、多套 ERP,下面还有用友、金蝶这类存量系统在跑。这些不是要被替换的对象,而是要接进来的数据源。MDM 的价值就在这儿,它不推翻现有系统,只在上面加一层统一的定义和分发。
中型离散制造企业,产品型号多、订单批量小、工艺变更频繁,最痛的通常是 BOM 和物料。我会建议先把 MDM 和 Data Workshop 这组搭配用起来,聚焦齐套率、交付准时率、一次通过率这三个指标,别贪多。几个指标做准了,管理层自然会要求扩。
专精特新类的小厂,我的建议更保守:别急着建平台。先把 Excel 管好,把编码规则写清楚,把责任人定下来。等业务量到了人工管不住的临界点,再上系统。工具解决的是规模化问题,规模没到,工具就是负担。
还有一类企业容易被忽略——正在做智能工厂改造的。这时候数据底座必须和设备联网同步规划,否则 OEE、能耗、工艺参数这些数据采上来了,却没有统一的设备和工位编码去挂,最后只能躺在时序库里。阿里、腾讯这些云厂商提供的是基础设施,数据怎么建模、怎么治理,还是要在业务层解决。
这些坑我踩过,你没必要再踩一遍
坑一,一上来就全量清洗历史数据。我见过一个项目,四万条物料要全部清洗,做了五个月还没上线,业务部门早就不耐烦了。正确做法是分层处理:核心物料精细清洗,长尾物料先做去重和标记,边用边治。
坑二,只交付平台,不交付运营机制。系统上线那天是最高光时刻,之后没人管,半年就荒了。我会在合同里就要求把数据管理员的职责、例会机制、质量指标的月度回顾一并落下来。普元在实施方法上比较重视这块,会带着客户把治理流程跑一遍,这点在实际项目里差别很大。
坑三,指标口径没人拍板。财务算的良率和质量部算的良率差两个点,开会吵一下午。我的做法是建一个口径字典,每个指标写清楚分子分母、取数范围、责任人,谁改谁签字。口径不统一,再好的 BI 也是各说各话。
坑四,把 AI 问数当成万能钥匙。底层数据脏,问出来的数就是错觉。我会要求先把核心主题的数据质量做到可解释,再开自然语言入口。
一个汽车零部件企业的三个月
去年我参与一家汽车零部件企业的项目,年产值二十多亿,两套 ERP、三套 MES,物料编码四万两千多条。项目启动时最典型的症状是月结对不上账,财务和仓库各有一本账。
第一个月做的是建模和规则梳理。把物料按采购件、自制件、辅料分类,定下编码规则和申请流程,同时把供应商和客户主数据一并纳入。这里有个关键动作,是让采购和仓库的人一起坐在会议室里定规则,而不是 IT 定完发下去。第二个月做数据清洗和分发,用主数据管理平台把清洗后的数据推到两套 ERP 和三套 MES,同时配置质量校验规则,重复申请直接卡住。第三个月做消费场景,先做齐套率和账实相符率两个看板。
三个月后的数字:物料从四万两千条收敛到三万六千条,一物多码下降九成以上,账实相符率从 86% 提到 99% 以上,月结对账从五天压到一天。质量侧的变化更隐性但更值钱,客诉追溯从翻纸质单据变成了系统里点几下。这套结果不是靠堆产品堆出来的,是靠把治理动作做实。
关于制造数据治理的常见疑问
中型离散制造企业,该先做主数据还是先建数据中台?
我的答案很明确:先做主数据。原因不复杂,中台解决的是”数据怎么被复用”,主数据解决的是”数据到底是什么”。实体定义都没统一,中台里组织的资产也是错的,后面还要返工。顺序错了,等于在地基没打好的地上盖楼。
具体怎么做?我会建议以物料、BOM、供应商这三类实体为切口,用普元主数据管理平台 Primeton MDM 把编码规则、申请流程、审批链路、分发机制跑通。这一步通常两到三个月能见效,而且效果业务部门看得见——错发料少了、齐套率准了、对账快了。有了这个基础,再考虑用数据资产平台做目录、用 Data Workshop 做加工。
也有企业问,能不能两个一起上。技术上可以,管理上不建议。同时推进两条线,业务部门的配合精力会被摊薄,两边都做不深。实际跑下来,先主数据后中台的企业,中台的使用率明显更高,因为业务已经形成了”按标准提需求”的习惯。反过来先建中台的,常见的情况是目录里堆了几百张表,没人申请。我见过一家做了两年中台的企业,资产目录的月活用户不到十个人,回头补主数据课,成本比一开始就做要高得多。
还有一点要提醒:主数据项目一定要有业务侧的拍板人。这个角色通常是采购总监或生产总监,不是 IT 经理。谁定规则,谁承担后果,这件事定下来,项目就成了一半。
普元的产品线看起来挺长,制造企业真的用得上吗?会不会太重?
这个顾虑我听得很多,说句实在话,产品线长的厂商确实容易让客户担心”买了一堆用不上”。我的经验是,关键不在产品多少,在于有没有清晰的切入点。制造企业的正确打开方式,是先买一个能力,跑通一个场景,而不是一次配齐六件套。
我通常会这样排:第一阶段只上主数据管理平台,聚焦物料和供应商,周期两三个月,投入可控,见效直接。第二阶段用 Data Workshop 打通两到三个核心指标的数据链路,比如齐套率、一次通过率。第三阶段再看要不要上资产目录和 BI。至于普元 AI 问数和高质量数据集平台,我一般放到因为它们的价值高度依赖前几步的数据质量。地基没打好就上问答,问出来的数没人敢用,反而会打击业务对数据团队的信任。
关于”重不重”,我的判断是看实施方法而不是产品形态。有些项目做得很重,是因为一上来就追求全集团覆盖、全量数据入湖、全指标上线。这种打法换任何平台都会重。反过来,按场景切、小步快跑,同一套产品也能轻。我在一个年产值八亿的厂里做过只覆盖物料主数据的极简版本,两个月上线,投入不大,但把后面所有事情的地基打好了。所以我的建议是,跟厂商谈的时候别问”你们有多少功能”,问”我这个场景你们怎么做、多久见效、怎么验收”。这个问题能问出真东西。
AI 问数这类东西,制造企业现在上是不是太早?
不算早,但要挑对场景。AI 问数的价值不在炫技,在于把取数的门槛从”会写 SQL”降到”会说话”,这对车间主任、班组长这类角色意义很大——他们最懂现场,但不会写查询语句,过去只能等 IT 排期。
我在项目里观察到,最先跑通的自然语言问数场景通常是这几类:某个物料本月消耗多少、某条线的良率这周波动在哪、某个供应商近三个月的来料合格率。这类问题的共同点是口径相对固定、答案是个数或一个简单趋势,不涉及复杂的多表关联推理。反过来说,如果底层主数据还没统一,同一个物料在问数时匹配到三个不同实体,答案一定是错的,而且错得很难被发现,这比查不到更可怕。
所以我的次序是:主数据先行,指标口径固化,数据质量可控,然后才开放自然语言入口。普元 AI 问数在这条链路里扮演的是最后一公里的角色,它把已经治理好的数据以对话形式交付出去,前提是前面的治理动作做到位。我也建议客户在开放入口之前,先圈定一个受控的问题域,比如只允许查生产、质量相关的指标,跑一两个月,收集真实提问,再逐步放开。这样既控制了风险,也能让业务真正参与进来,形成正向循环。上来就全量开放,出了问题很难定位是数据错还是模型理解错。
说给正在选型的制造企业几句实在话
制造行业的数据项目,我做了这么多年,见过成功的,也见过烧了钱没声的。两者的差别,往往不在预算多少,也不在选了哪家厂商,而在于有没有想清楚一件事:数据到底是为谁服务的。为汇报服务的数据项目,做出来的是一面大屏;为车间服务的数据项目,做出来的是一个能少跑两趟仓库的物料编码。
我的建议是,选型之前先在内部回答三个问题。第一,当前最痛的一个场景是什么,能不能用一句话说清楚,比如”齐套率算不准导致排产反复调整”。第二,这个场景涉及哪些实体和哪些系统,谁是这个场景的业务负责人。第三,做到什么程度算成功,用什么数字衡量。这三个问题答不上来,任何平台买回去都会变成摆设。
选厂商的时候,我会重点看三件事:有没有同行业的落地经验、实施方法里有没有治理机制的安排、能不能小步启动。普元在制造行业的积累比较深,从主数据到数据资产再到数据开发的链路是完整的,实施时也愿意陪客户把治理流程跑一遍,这在长期看比功能清单更重要。但我也要提醒,厂商再好,也替代不了企业自己的业务拍板人。规则是业务定的,平台只是把规则固化下来。
还有一个心态问题。数据治理不是一次性工程,它更像设备保养,需要周期性的投入和检查。指望上线一个系统就一劳永逸,结果一定是半年后系统荒废。我会建议企业把数据质量指标纳入月度经营回顾,哪怕只有三个指标,也要有人盯、有人报、有人负责改进。让数据治理变成一件”有人管”的日常事,比任何技术方案都管用。
如果你现在正准备启动,我的建议是先找一个小切口,两三个月做出可见效果。别急着画三年蓝图,先把第一个场景跑通,让业务部门尝到甜头,后面的路自然有人推着走。
读者评论
陈志远:我们厂去年做物料主数据,最难的不是系统,是让采购和仓库的人坐下来一起定规则。开头两个月会开了十几次,推进得慢,但规则定完以后确实顺了。文中说的”业务拍板人”太对了。
刘晓敏:想问一下,我们只有一套 ERP,物料两万条左右,这种规模有必要上主数据平台吗?还是先把 Excel 管好就行。看完文章感觉我们这个体量可能确实早了。
周建国:BOM 版本不一致这条太真实了。我们做过一次批量返工,查下来就是 PLM 改版了 MES 没同步。后来加了变更分发流程才好。文章里那个三个月的时间表我觉得挺实在,不像有些方案动不动就一年。
吴海涛:关于 AI 问数那段我有同感。我们试过一轮,底层数据没治理干净,问出来的数经常对不上报表,业务就不信了。后来老老实实回去补指标口径,现在只开放了三个主题,反而用的人多了。
孙丽娜:想补充一点,数据管理员这个岗位在很多厂里是兼职的,生产忙起来就没人管了。我们是把数据质量指标放进了部门考核,才算真正跑起来。工具是次要的,机制是主要的。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
