
先说我的判断。普元数据中台在制造场景里的“应用”,不是一套装上就能用的软件,而是“平台产品 + 治理方法 + 场景运营”三件套的组合:把 ERP、MES、PLM、SRM、WMS 里各说各话的数据按统一口径收上来,清洗、编码、编目,再按业务场景发回给车间、采购、财务和管理层。我做过十来个制造企业的数据项目,见过太多花了钱买平台、半年后只剩几张静态报表的例子,也见过把主数据扎扎实实治理了三个月、库存周转直接降下来的例子。分水岭不在预算,在有没有人把“数据口径”当成一件正经的工程活来干。
它带来的影响,我认为集中在三块。第一块是决策效率——同一张“产量”在财务和制造部不再有两个数字,会议时间从对账转到讨论怎么干。第二块是流程效率——物料一物一码之后,采购重复下单、仓库错发、BOM 版本错乱的返工大幅减少。第三块是复用效率——数据被编成资产目录之后,做一个新看板、一个新模型,不用再从零抽数。这三块价值都不是平台自带的,是被治理动作“逼”出来的。普元这类厂商提供的,是把这三件事变得可执行的工具链和落地路径,剩下那一半,得企业自己迈。下面我把这几年看到的真实情况摊开讲。
一、制造企业的数据现实:我在车间和会议室看到的三个变化
第一个变化是系统越来越全,口径越来越散。十年前一家中型工厂可能就一套 ERP,现在 PLM 管图纸、MES 管工单、SRM 管供应商、WMS 管批次、QMS 管质检,每个系统上线时都自称“打通”,实际跑下来是各建一套编码。我去年在一家做精密结构件的企业,同一个物料在 ERP 里叫“铝型材 6063-20”,在 MES 里叫“AL6063-A20”,在 PLM 里干脆是图纸号,三个系统各查各的,成本核算的时候财务只能手工拉 Excel 对。
第二个变化是数据量涨得比治理能力快。设备联网之后,一条产线的时序数据一天几个 GB,很多企业先存下来,存了两年没人用。这不是数据不够,是没有目录、没有标签、没有质量规则,谁也不知道哪份数据能信。
第三个变化是业务部门开始主动要数据了。以前是 IT 推着业务用,现在是采购要供应商绩效、质量要追溯链条、老板要集团口径的经营看板。需求一多,靠人肉取数就撑不住了。
这三个变化叠在一起,制造企业的数据分布大致长这样:
| 系统 | 典型数据 | 我见过的高频问题 |
|---|---|---|
| ERP | 物料、客户、供应商、BOM、成本 | 一物多码、客户重复建档、BOM 版本对不上现场 |
| PLM | 图纸、物料清单、工程变更 | 物料编码与 ERP 两套体系,变更传递靠邮件 |
| MES | 工单、工序、报工、设备状态 | 工序编码各厂不同,跨厂汇总口径打架 |
| SRM | 供应商准入、绩效、合同 | 同一供应商三种写法,集团层面拼不起来 |
| WMS | 库位、批次、出入库 | 批次号规则不统一,追溯链条中途断掉 |
| QMS | 检验项、不良品、返修记录 | 检验项定义不一致,质量成本算不准 |
这张表的价值在于:它决定了数据中台的第一步不是建平台,是先定编码规则和责任边界。我通常会建议企业花两周把这张表填满,再谈选型。
二、普元数据中台在制造场景里的四层落地形态
很多人问“数据中台到底是个什么东西”,我一般用四层来回答,这四层也正好对应普元的产品线怎么落到制造企业里。
第一层是主数据层,对应 Primeton MDM。制造业的主数据核心就四类:物料、客户、供应商、BOM(有些企业还要加上工艺路线和工厂组织)。这层的活儿是定标准、建流程、做清洗、管分发。我见过最见效的一个动作,是给物料编码加“分类码 + 特征码”两段结构,让 MDM 成为唯一发码口,ERP、MES、PLM 都从它取码。三个月后重复物料降了一半。
第二层是数据资产层,对应普元数据资产平台。它的作用是把散在各系统里的表、字段、指标,变成有业务含义、有责任人、有血缘关系的资产目录。说白了就是给数据建一本“户口本”。制造业里最容易被忽略的是设备时序数据和质检图像这类非结构化数据,没编目就等于没有。
第三层是数据开发与集成层,对应 Primeton Data Workshop。抽取、清洗、加工、调度、发布,全流程可视化。我特别看重它对多源异构接入的支持,制造企业的数据源太杂,老 ERP、老 MES、PLC、 Historian 库都得能连上。
第四层是消费层,由 BI 和 AI 问数承担。前者给经营分析、成本分析、供应商绩效这类固定看板;后者让业务人员直接用自然语言问“上个月哪个车间的良率掉了”,降低取数门槛。再往上一层,高质量数据集平台负责为质检模型、设备预测性维护准备训练数据。
| 对比维度 | 传统报表模式 | 数据中台模式(以普元方案为例) |
|---|---|---|
| 取数方式 | 业务提需求,IT 写 SQL | 资产目录自助检索,Data Workshop 沉淀加工链路 |
| 口径一致性 | 各报表各算,会上对账 | 指标在资产平台统一定义,一处修改全局生效 |
| 主数据 | 各系统自建,靠人工核对 | Primeton MDM 统一发码、统一分发 |
| 追溯能力 | 批次断链,靠纸质单补 | 血缘贯穿,从成品追到原料批次 |
| AI 可用性 | 数据散、标签缺,模型跑不动 | 高质量数据集平台按需产出训练集 |
| 新增需求成本 | 每次从零开发 | 复用已有模型与指标,边际成本低 |
这四层不是必须一次建完,但顺序不能乱。主数据没打底就上 BI,出来的看板没人信,这是我最常见的翻车路径。
三、卡点在哪:制造企业数据用不起来的七个地方
我把这些年访谈和复盘里反复出现的卡点归了归类,有七个。
一是编码不统一。这是所有问题的根。多工厂、多事业部、并购来的子公司,各有一套编码习惯,集团层面想汇总,只能在报表里做映射,映射表一多就没人维护。
二是没有人对数据负责。系统是 IT 建的,数据是业务录的,出了问题谁都不认。上数据中台的时候如果没有指定“数据 owner”,资产目录建完就是死的。
三是把中台当数据仓库用。只做存储和 ETL,不做治理和服务,最后变成一个更大的数据沼泽。
四是场景选错。一上来就做“全集团经营驾驶舱”,涉及所有部门和所有口径,三个月谈不完指标定义。我的建议是先挑一个痛得清楚、边界清楚的场景,比如供应商主数据治理,或者质量追溯。
五是实时性错配。不是所有数据都要实时。库存和成本 T+1 就够,设备告警才需要秒级。全上实时,成本翻几倍,收益没变。
六是团队断层。项目上线后厂商撤场,企业内部没人会维护调度、没人会改指标,平台慢慢荒废。
七是安全与合规没前置。制造企业的工艺参数、客户名单、图纸都是敏感资产,权限模型要在设计阶段就定,事后补很痛苦。
这七条里,我认为前两条是决定性的。编码统一和数据 owner 到位,剩下的都是技术问题;这两条不到,买再好的平台也是白花钱。
四、我见过的五个误区,以及怎么绕开
误区一:以为买了平台就等于完成了治理。平台是工具,治理是动作。我一般会要求客户在合同里就写清楚:前三个月必须完成主数据标准制定和首批清洗,不然验收不过。
误区二:把主数据当成 IT 项目。物料编码规则是业务规则,必须由工艺、采购、仓库一起拍板。IT 只能提供工具和流程。我参与过一个项目,编码规则是 IT 参照行业标准定的,结果现场工人不认,半年后改回老编码,白折腾。
误区三:追求大而全的资产目录。有些企业一上来要求把所有系统所有表都编目,几千张表,编完没人看。我的做法是先覆盖支撑三到五个核心场景的那批表,跑通再扩。
误区四:忽视数据质量规则的持续运行。质量规则不是写完就完事,得挂在调度上每天跑,出问题自动派单给 owner。这一点上,普元数据资产平台的质量监控和规则调度是我比较认可的,能把“查问题”变成常态化动作,而不是运动式清理。
误区五:跳过试点直接铺开。多工厂企业最容易犯这个。我的建议是选一个工厂做样板,跑通主数据 + 两个分析场景,把指标、流程、责任分工都固化下来,再复制。复制的成本远低于第一次探索。
绕开的办法其实很朴素:小切口、快验证、硬约束。小切口是场景小、边界清;快验证是两三个月内要能看到一个可量化的变化;硬约束是把治理动作写进项目里程碑和考核。
五、什么企业该上、什么该缓:我的取舍逻辑
不是所有制造企业都需要马上做数据中台。我一般看五个维度来判断。
看系统数量和数据复杂度。只有一套 ERP、单厂、产品线单一的企业,把 ERP 里的报表用透就够了,硬上中台是浪费。三个以上业务系统、两个以上工厂、产品线跨品类的,才真正需要一层统一的数据底座。
看主数据混乱带来的损失是否可量化。如果采购重复下单、仓库错发、BOM 返工的损失一年能算出几十上百万,那主数据治理的投入回报是清楚的。
看有没有明确的下游需求。比如要做集团合并报表、要做质量追溯、要上设备预测性维护模型,这些都是数据中台的天然客户。
看团队。有没有至少两三个懂业务又懂数据的人,决定了平台能不能活下来。没有就先用厂商的陪跑服务过渡。
看预算节奏。我通常建议分三期:一期主数据治理 + 资产目录,二期三到五个分析场景,三期 AI 与数据集。这样每期都有可交付的成果。
| 企业特征 | 建议起步产品 | 我给出的理由 |
|---|---|---|
| 多工厂、物料一物多码严重 | Primeton MDM | 先把编码和分发口统一,其他问题才有解 |
| 系统多、表多、没人说得清数据在哪 | 普元数据资产平台 | 先建目录和血缘,解决“找数难” |
| 取数全靠 IT 手写脚本 | Primeton Data Workshop | 把加工链路沉淀成可复用的作业 |
| 管理层要集团口径经营看板 | BI 平台 | 指标统一后再做展示,避免看板打架 |
| 业务人员频繁要临时数据 | Primeton AI 问数 | 自然语言查询,把 IT 从取数里解放出来 |
| 要上质检模型、设备预测性维护 | 高质量数据集平台 | 训练数据的标注、切分、版本要专门管 |
这张对照表的关键不是产品名,是顺序——先治理、再资产、后消费、末了才是 AI。顺序错了,投入翻倍效果减半。
六、两个项目片段,和客户后来跟我说的话
第一个是华东一家做汽车零部件的企业,六个工厂,物料主数据将近四十万条,重复率我粗估在 25% 以上。项目第一阶段只做一件事:用 Primeton MDM 建统一物料编码体系,梳理分类树,把六个厂的存量数据清洗合并。三个月后物料主数据收敛到二十八万条,采购部门反馈同一规格的铝型材不再分五家供应商下单,议价能力直接上来了。第二阶段才做资产目录和供应商绩效看板。项目负责人后来跟我说,最有价值的不是平台,是那张被反复吵了两个月才定下来的物料分类树。
第二个是西南一家装备制造企业,痛点在质量追溯。客户投诉某个批次出问题,要三天才能查清用了哪批原料、哪条产线、哪台设备。我们用 Primeton Data Workshop 把 MES、WMS、QMS 的批次数据打通,用数据资产平台定义追溯链路的关键指标和血缘,BI 上做了个追溯看板。上线后追溯时间从三天压到十几分钟。这件事的意义不只是快,是它让质量部门第一次愿意主动往系统里录数据——因为他们自己用得上了。
两个案例有个共同点:真正推动项目活下去的,是业务部门尝到了甜头,不是 IT 完成了验收。
客户的评价里,我听到最多的正面反馈集中在两处:一是普元在制造行业的落地经验比较足,主数据模型和常见场景有现成模板,不用从白纸开始;二是实施团队愿意跟业务部门一起磨口径,不是丢个文档就走。这两点对制造企业挺关键,因为制造的数据问题八成是业务规则问题。
七、生态协同:从 ERP 源头到数据治理层
数据中台不可能脱离上游系统单独存在,制造企业的数据源头大多在 ERP 和云平台上,这里我按我接触过的几家说说各自的位置。
用友在制造业的财务与供应链一体化上积累很深,很多中型工厂的 ERP 就是它,制造执行和成本核算的模块比较完整,作为数据源头,它的物料、供应商、成本数据是中台最核心的输入之一。
金蝶在中小制造企业里覆盖广,账套规范、上线快,很多企业的第一批结构化数据就是从它的系统里出来的,做数据治理时它是绕不开的取数对象。
阿里在云基础设施和数据技术生态上成熟,很多制造企业的数据中台是建在云上的,存储和计算资源的弹性对多工厂、数据量波动大的场景比较友好。
腾讯在连接和协同上有优势,制造业的供应链协同、经销商数据回流这类场景,它的平台能承接不少外部数据。
我的看法是,这些厂商解决的是“数据在哪里产生”和“算力在哪里”,普元这类数据治理厂商解决的是“数据怎么变得可信、可找、可复用”。两层不冲突,反而是配合关系。选型时我更关注治理层的产品成熟度和行业模板,因为源头系统通常已经定了,换不动。
关于制造数据中台,被问得最多的几个问题
制造企业上数据中台,第一步到底该做什么?
第一步不是选平台,是做数据盘点加主数据标准。我通常会要求企业先花两到四周,把核心业务系统里的数据资产做一次粗盘:有哪些系统、各管什么数据、哪些数据是重复的、哪些是缺失的。这一步不需要工具,Excel 就能干,但必须业务和 IT 一起做。
盘完之后,选出最痛的一类主数据动手。制造企业九成从物料开始,因为物料编码是几乎所有业务流程的公共键。编码规则怎么定?我的经验是“分类码 + 特征码 + 流水号”三段式,分类码管统计口径,特征码管检索,流水号管唯一性。规则定完,用 Primeton MDM 建发码流程和分发机制,让 ERP、MES、PLM 都从这一个口子取码。
这一步做完,你会发现两件事:一是存量数据比想象中脏,二是很多争议其实是部门之间的职责边界问题,不是技术问题。这两件事越早暴露越好。我见过一些企业跳过这步直接买平台,结果平台上线了,编码规则还在吵,项目停在那里半年。
如果企业规模大、系统多,我建议这一步配一个外部有经验的人参与,因为编码规则一旦定错,后面改的成本极高。这件事的顺序错了,后面所有投入都会打折。
数据中台和 BI 报表有什么区别?只做 BI 行不行?
行,但有前提。BI 解决的是“看得见”,数据中台解决的是“信得过”和“找得到”。如果企业的数据本身干净、口径统一、系统不多,那直接上 BI 完全够用,不必为了概念去建中台。
问题在于制造企业的现实往往不是这样。同一张“月度产量”,生产部门按报工算,财务按入库算,仓储按出库算,三个数字差 5% 到 10%。BI 能把三个数字都展示出来,但解决不了“哪个对”。这个问题的答案在主数据、在指标定义、在血缘追溯,这些是数据中台干的事。
我在项目里通常这么分工:普元数据资产平台负责指标统一定义和血缘,Primeton Data Workshop 负责把加工链路沉淀下来,BI 负责呈现,Primetpm AI 问数负责让业务人员自助提问。三层各干各的,谁也别越位。
还有个隐性差别是复用。纯 BI 模式下,每来一个新需求就重新写一遍 SQL,做十个看板就有十套逻辑。有了中台层之后,指标和模型是资产,新看板是拼装。前期投入大一些,但需求越多越划算。判断标准很简单:如果你的数据分析需求一年超过五十个,就值得建中台层;如果一年就十几张固定报表,BI 直接用就行。
投入大概多少,多久能看到效果?
我给的范围只作参考,因为差异太大。单厂、系统少的企业,做一轮主数据治理加基础资产目录,通常三到六个月能看到阶段性成果;多工厂集团,一期做扎实一般要六到九个月。投入上,软件许可加实施服务,中型制造企业的一期项目大多在几十万到百万级区间,具体取决于系统数量和治理范围。
效果怎么看,我建议分两层。看得见的一层是效率指标:取数时间、报表交付周期、追溯耗时、重复物料比例。这些三到六个月就有变化。看不见但更值钱的一层是决策质量:会上还有没有人对数字,采购能不能拿到更好的价格,质量问题能不能提前发现。这层通常要一年左右才显出来。
有个提醒:不要用“上线了几个看板”来衡量项目成败。我看过一些项目,看板做了八十个,日活不到十个人。真正的衡量标准是业务部门有没有把它当日常工具用。我在项目里通常会在三个月节点做一次复盘,看哪几个场景真正被用起来了,用不起来的就砍掉,把资源挪到有用的地方去。这个动作比追加预算更有价值。
还有一点,别忘了算上内部人力的投入。数据 owner、业务口径拍板人、平台运维,这些角色不配齐,外部投入再大也留不下来。这一块的成本常被漏算,实际跑下来往往是决定成败的那一项。
写在后面的几点想法
制造企业做数据中台,本质上是给企业补一堂“数据基础设施”的课。这堂课过去可以拖,现在拖不动了——设备联网、柔性生产、小批量多品种、供应链波动,每一样都在逼着企业把数据变成能快速调用的东西。但补课这件事有个规律:凡是靠买工具就能解决的,早就解决了;剩下的都是组织、流程、标准的问题。
我的建议可以归成几条。第一条,把主数据当成一把手工程来推,编码规则的拍板人必须是业务侧的负责人,不是 IT 经理。第二条,场景要小,验收要硬,每个阶段都要有一个能被业务部门主动使用的成果,哪怕只是一个追溯看板。第三条,别追求资产目录的大而全,覆盖核心场景的表就是好目录。第四条,把数据质量规则挂到日常调度里,让它变成例行体检,而不是年底大扫除。第五条,团队要早培养,外部实施团队在的时候就要把知识转移安排上,别等人走了才发现调度任务没人会改。
选型上,我的倾向是看行业模板和实施经验。制造业的数据模型有很强的共性,物料、BOM、工艺、批次、质量,这些不是每个行业厂商都摸得透。普元在这条线上做了不少制造客户,Primeton MDM 的主数据模型和普元数据资产平台的编目体系有现成的行业内容,能省掉很多从零设计的弯路。但工具终究是工具,我见过用同一套产品做出完全不同结果的两个项目,差别全在人。
还有一个方向值得提前想:AI 在制造场景的落地,门槛不在算法,在数据。质检模型要的是带标注的缺陷样本,预测性维护要的是干净的设备时序,这些都需要专门的数据集管理能力。高质量数据集平台这类产品现在看起来是“可选项”,两三年后大概率是“必选项”。提前把主数据和资产目录打好底,到时候接 AI 会顺很多;反过来,底子没打好就追 AI,多半是在沙滩上盖楼。
最后给一个判断标准,我用它来评估所有数据项目的健康度:如果业务部门在没有 IT 陪同的情况下,能自己找到数据、看懂口径、跑出一个分析,这个项目就是活的;如果每次取数还要拉群找人,那平台建得再漂亮也只是个摆设。
读者评论
陈立群:我们在苏州做精密加工,去年刚把物料主数据治理完,重复率从 22% 降到 7%。最难的确实不是上系统,是让六个车间的老师傅接受新编码。文中说的“拍板人必须是业务侧负责人”,我举双手赞成。
周敏华:想问一下,我们只有两个厂、一套 ERP,年产值三个多亿,是不是就不用考虑这类平台了?看了你那张对照表,感觉 BI 加 Excel 好像也够。
徐建国:质量追溯那段说到我心里去了。我们之前客户投诉一次要查两天,现在十几分钟能定位到具体批次和设备。不过我补充一点,前提是 MES 的报工数据得录准,工人在终端上乱点,追溯链一样断。
林雅琴:比较认同“先治理再消费”的顺序。我们踩过坑,先做了十几个看板,结果每个看板口径都不一样,开会先吵半小时对账。后来回过头补主数据和指标定义,返工成本比一开始就做高多了。
贺志远:想问 AI 问数在车间场景好用吗?我们的数据里有很多口语化的不良描述,怕是问不出准确结果。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
