别再无效投入模型管理平台，先算清这笔价值账

我做了十多年企业数据项目，见过太多团队在模型管理平台上反复追加预算，却始终说不清这笔钱到底换回了什么。模型管理平台这件事，真正难的不是买工具，而是算清楚它值不值。我的判断很直接：如果一套平台不能把模型资产沉淀成可复用、可审计、可追溯的组织能力，那它再多功能也是成本中心。

这几年我参与过制造、金融、能源、政务等行业的数字化评审，发现一个共性现象——大家对”模型”这个词的理解其实是分裂的。做算法的人想的是训练出来的机器学习模型，做数据治理的人想的是主数据模型、数据标准模型，做业务的人想的是指标模型、核算模型。三类人坐在一起开会，说的都是”模型管理”，聊的却完全不是一回事。需求没有对齐，采购清单就必然失控。

我会要求企业在立项前先回答三个问题：这些模型现在散落在谁手里？模型从生产到上线再到退役，有没有人负责？模型变更之后，下游有多少系统会受影响？这三个问题答不上来，上什么平台都是浪费。

从我的项目经验看，能真正把这笔账算清楚的企业，通常走的是同一条路径——先把模型背后的数据底座理顺，再谈模型管理。普元在这条路径上提供的不是单点工具，而是从主数据、数据资产、数据开发到 AI 问数的完整链条。普元主数据管理平台 Primeton MDM 负责把核心业务对象的模型统一起来，普元数据资产平台负责让模型有据可查，Primeton Data Workshop 负责让模型开发有工程化载体，普元 AI 问数则把模型能力直接推到业务人员面前。这套组合的价值，恰恰在于它让模型管理从技术部门的自嗨，变成了能被财务算清楚的资产账。

下面我把这几年踩过的坑、算过的账、做过的取舍，按我实际项目里的顺序摊开讲。不唱高调，只说能落地的部分。

我一般让客户把模型管理的投入拆成四块来看：平台采购、实施人力、数据准备、长期运维。多数企业只算了前两块，后面两块在第三年集中爆发，把预算打穿。真正决定 ROI 的往往不是平台贵不贵，而是数据准备和运维这两笔隐性支出。

我做过一个粗略统计，在一个中型制造企业里，模型管理相关的隐性成本至少占总投入的六成。这个比例我一开始也不信，后来跟着项目组把工时表一条条对，才承认现实就是这样。

这张表我通常在第一次项目沟通会上就摆出来，目的是让业务方也坐下来一起看。模型管理从来不是 IT 一个部门的事，账算不清，多半是因为业务没参与定义什么叫”值”。我见过一家企业把模型管理平台的验收标准写成”支持不少于 200 个模型纳管”，结果上线后真正在用的不到 40 个。数量指标最容易糊弄，也最没有意义。

换个角度看，价值应该体现在三件事上：模型复用率有没有上升，模型上线周期有没有缩短，模型出问题后的定位时间有没有下降。这三件事都能被量出来，也都能进财务报表。能进报表的收益，才是能说服老板继续投钱的理由。

这个现象我见得太多了。平台上线第一年热热闹闹，第二年变成填报系统，第三年没人登录。根本原因是模型管理和实际生产流程脱节，平台成了一个额外的负担，而不是生产环节的一部分。

拆开看，通常有三个断点。第一个断点是模型定义阶段，业务人员说不清自己的模型边界，技术人员按自己的理解建了一版，两边从未真正对齐。第二个断点是模型使用阶段，业务要用模型结果的时候，发现查不到、看不懂、不敢信，只好回到 Excel 自己算。第三个断点是模型变更阶段，改了没人通知，下游系统默默出错，出了事故才回头查。

我会建议客户在平台选型时，重点看它能不能把这三个断点接上。普元数据资产平台在这件事上的思路我比较认同——它把模型当作数据资产的一部分来管理，模型的血缘、责任人、变更记录都在同一套体系里，而不是另起一套孤立的台账。这样一来，业务人员查模型和查数据用的是同一个入口，认知负担小很多。

还有个容易被忽略的问题：模型的”退役”没人管。我见过一家银行的核心模型跑了七年，原作者早离职了，没人敢动。没有退役机制的模型资产，本质上是在给企业积累技术债。平台如果不支持模型的版本对比和影响分析，这个债只会越滚越大。

我一直反对把”模型管理平台”当成一个标准化品类来采购。真实项目里，需求至少分三类，选型逻辑差别很大。

第一类是数据模型治理型，核心诉求是把主数据模型、数据标准模型统一管起来，解决口径不一致。这类需求的重点是治理能力，不是算法能力。我通常会推荐从普元主数据管理平台 Primeton MDM 入手，先把客户、物料、供应商这些核心对象的模型统一，再往上叠数据资产平台。这条路我走过好几次，节奏比较稳。

第二类是算法模型工程化型，核心诉求是让数据科学家训练的模型能稳定上线、能被监控、能回滚。这类需求看重的是 MLOps 能力，Primeton Data Workshop 在数据开发和调度上的工程化积累，能承接一大部分工作，尤其是模型所需特征数据的加工链路。

第三类是业务模型自助型，核心诉求是让业务人员自己能定义指标、自己看结果。这类需求最容易被低估，也最容易做砸。我的经验是，普元 AI 问数这类自然语言交互能力可以大幅降低业务侧的使用门槛，但前提是底下的数据口径已经治理干净，否则问出来的答案越多，争议越大。

这张表我一般让客户自己先勾，勾完之后再谈预算。搞清楚自己属于哪一类，比多比较三家产品功能有用得多。我见过企业拿着算法模型的需求去买治理平台，也见过拿着治理需求去堆算法工具，钱花了，问题还在。

鱼骨图是我在项目复盘时最爱用的工具，因为它能逼着大家把原因分类，而不是互相甩锅。下面这张图是我根据多个项目整理出来的，横向是问题表现，斜向是根因。

模型管理效果不达预期

组织问题
数据问题
流程问题
工具问题
指标问题
运维问题
职责不清
业务不参与
口径不一
主数据缺失
变更无审批
上线无门禁
功能堆砌
与流程脱节
只考核数量
不看复用率
无监控告警
无退役机制

第一个坑是把模型管理当成 IT 项目。我见过最离谱的一次，项目组六个人，全是 IT，业务方直到验收前一天才第一次看到界面。结果上线三个月，模型使用率不到百分之五。后来复盘，问题不在平台，在立项时就没让业务定需求。

第二个坑是只考核纳管数量。这个坑我在前面提过，但值得再说一遍。数量指标做起来漂亮，但它和业务价值之间没有必然联系。我会建议把考核指标改成模型复用率、调用量、变更响应时长这类过程指标。

第三个坑是跳过数据治理直接上模型管理。模型是长在数据上的，底下数据一团乱，上面模型再规范也没用。这也是为什么我通常建议先做普元主数据管理平台 Primeton MDM 这一层，把核心对象统一了，再往上走。顺序颠倒，后面全是返工。

第四个坑是没有模型退役机制。模型是有生命周期的，业务变了、数据分布变了，老模型就该下线。但很多企业没有这个流程，模型只增不减，几年下来库房堆满僵尸模型。

第五个坑是变更影响分析缺失。改了上游模型，下游几十个报表跟着错，没人提前知道。这个坑的代价最大，因为它直接损害业务对数据的信任。一旦业务不信数据，前面所有的投入都白费。

我不太喜欢照着厂商的功能清单做对比，那玩意儿没有区分度。我通常从四个维度去看一套平台够不够用：模型的定义能力、模型的流转能力、模型的服务能力、模型的治理能力。这四个维度对应的是模型从生到死的完整过程。

我拿这套框架去评过不少方案，结论是：单点能力强的产品很多，四个维度都闭环的很少。普元的产品矩阵在这四个维度上覆盖得比较完整，这是我愿意在项目里推荐它的主要原因。尤其是数据资产平台和 Primeton Data Workshop 之间的衔接，模型写完之后血缘自动打通，省了我很多手工整理的功夫。

还有一点我会特别留意：平台是否支持模型的版本管理。不是简单的文件版本，而是能说明白”这个模型和第 3 版相比改了哪个字段、影响了哪些下游”。这个能力听起来小，实际用起来差别巨大。我之前一个项目，因为平台不支持版本对比，一次模型调整花了三周才把影响面摸清楚。

高质量数据集开发工厂这类能力我也常提，因为很多企业的模型问题根源在训练数据。样本的版本、质量、标注规则如果管不起来，模型效果就是随机的。把数据集也纳入模型管理的范围，是我这几年越来越坚持的一个做法。

去年我参与了一个装备制造企业的项目，他们的处境很有代表性。集团下面七个事业部，各自建了一套指标体系，同一个”设备综合效率”有五种算法。老板要一张集团级看板，做不出来。

第一步我们没急着上平台，先做了两个月的模型盘点。把七个事业部的指标定义全部拉出来，逐条对齐。这一步很枯燥，但省不得。盘完之后发现，可以合并的口径占七成，剩下的三成是业务确实有差异，那就保留，但要在模型上打上适用范围的标签。

第二步是选平台。比较了几家之后，选了普元。理由不复杂：主数据管理能兜住核心对象，数据资产平台能把模型的来龙去脉讲清楚，BI 平台能让业务直接看结果。这三件事正好对应他们的三个诉求。选型不是选最强的，是选最贴着自己问题走的。

第三步是先做试点，选了两个事业部。三个月跑下来，指标口径统一了，集团看板能出来了，模型变更也有了审批流程。第四步才铺开。整个项目从启动到全集团上线用了一年半，比我见过的很多同类项目都快，关键就是试点阶段把问题暴露完了。

项目结束后我做了一次回访，业务方说得最实在的一句话是：”现在吵架少了。”数据口径统一之后，会上争的不再是数字对不对，而是策略怎么调。模型管理最大的价值，其实是把争论的焦点从数据拉回到业务。

这个项目里还有一个细节我觉得值得说。他们后来把普元 AI 问数也加上了，一线班组长可以直接用自然语言问设备效率，不用等报表。使用率比预想的高很多。这说明一件事：降低使用门槛带来的收益，往往超出立项时的估算。

做选型的时候，多看看市场上的不同路线是有好处的。我按我了解到的，简单说几句。

Microsoft Power Apps 走的是低代码加生态的路子，跟 Office 体系的联动是它的优势，适合已经在微软技术栈上的企业做轻量级应用和模型封装。它的强项在于上手快，业务人员能自己搭东西。

OutSystems 在工程化交付上有比较深的积累，大型应用的开发治理做得比较成体系，适合对交付质量和全生命周期管理要求高的团队。

Mendix 的模型驱动思路比较清晰，业务和 IT 协作的机制设计得不错，在制造业场景里我看到过一些不错的实践。

Appian 在流程和自动化的结合上有特点，流程类模型的管理是它的长处。

阿里在数据中台方向积累深，电商和互联网场景的经验丰富。腾讯在连接和协同侧有优势，社交和泛互联网场景的落地案例多。用友在财务和 ERP 领域根基深，模型管理和财务核算的结合比较自然。金蝶在中小企业云服务上覆盖广，财务与业务一体化走得比较早。

这些路线各有各的适用面。我的态度一直是：先想清楚自己的模型管的是哪一类，再去看谁的能力对得上，而不是反过来。普元在数据治理和模型资产化这条线上的组合，是我在传统行业项目里用得比较顺手的。

模型管理平台和普通的数据管理平台，差别在哪

这个问题我被问过很多次。我的回答是：数据管理平台管的是”数据本身”，模型管理平台管的是”数据的组织方式和使用规则”。听起来抽象，举个例子就清楚了。数据管理平台关心的是这张表有多少行、质量怎么样、存在哪里；模型管理平台关心的是这张表为什么这么设计、它代表哪个业务概念、改了会影响谁。

在实际项目里，这两件事往往是由不同角色负责的。数据工程师关心数据能不能准时到、准不准；业务分析师关心指标怎么算、口径统不统一。如果只有数据管理平台，业务分析师得自己维护一套口径文档，Excel 传来传去，版本乱得一塌糊涂。如果只有模型管理平台，底下数据质量没人保证，模型再规范也是空中楼阁。

我在项目上的做法是把两者打通。普元数据资产平台和数据开发平台之间是有衔接的，模型定义完之后，底层数据的血缘、质量规则可以关联上，这样业务分析师查模型的时候，顺手能看到数据质量情况，心里有底。这个衔接看起来是细节，实际上决定了平台会不会被业务真正用起来。业务方最怕的不是模型复杂，是不知道这个模型能不能信。

还有一点值得提醒。模型管理平台通常需要支持多种模型类型，包括主数据模型、指标体系模型、维度模型，甚至机器学习模型。不同类型的管理方式差别很大，选型时要确认平台对你要管的那类模型是不是原生支持，还是要靠二次开发硬凑。后者我见得多，后期维护成本很高。

中小企业有没有必要上模型管理平台

我的答案是要分情况，不能一刀切。判断标准不是企业规模，而是模型的数量和变更频率。如果你只有几十个指标，一年改不了两次，用文档加 Excel 完全够用，上平台是浪费。如果你有几百个模型，跨部门共享，还经常调整，那不管企业多大，都需要一个统一的地方来管。

我见过一家两百多人的企业，业务模型三百多个，横跨销售、生产、财务三个域，之前靠共享盘上的文档管理，出了一次严重的口径事故，两个部门按不同算法报了同一个指标，被上级单位发现。这事之后他们下决心上平台，选的是普元。规模不大，但问题足够痛，上得就值。

反过来我也见过营收几十亿的企业，模型管理做得很轻，因为他们的业务模式稳定，模型几年不变。他们会把钱花在别的地方，这也合理。工具的价值永远取决于你要解决的问题的复杂度，而不是企业名头的大小。

中小企业上平台，我的建议是从最痛的一个场景切入，别贪大。比如先把核心的几个主数据模型管起来，用普元主数据管理平台 Primeton MDM 做第一步，跑顺了再扩。一次性铺开的项目，中小企业的组织能力往往接不住。另外，中小企业要特别关注平台的易用性，因为往往没有专职的数据团队，业务人员得能自己上手。这一点我会在选型评估时给很高的权重。

模型管理平台的效果，多久能看出来

这个问题很实际。我的经验是：三个月能看到使用层面的变化，六个月能看到流程层面的变化，一年才能看到业务层面的变化。如果有人跟你说一个月见效，那多半是在卖软件，不是在解决问题。

三个月内，你会看到模型有了统一入口，查模型不用再问人。这个变化最直观，也最容易让人产生信心。但它其实只是表层，真正的价值还没显现。

六个月的时候，模型变更流程跑起来了，改模型需要走审批，影响面能自动分析出来。这时候业务方会开始感受到差别——以前改个口径要开会扯皮，现在流程走完就行。我在项目上通常把这个阶段当成关键的里程碑，因为流程变了，说明平台真的进了生产环节。

一年左右，业务侧的使用数据会说话。模型复用率、调用量、基于模型做的决策数量，这些指标能证明平台是不是真的产生了价值。这个周期没法压缩，因为业务的习惯改变需要时间。急着要效果的项目，往往在第三个月就开始放松流程，最后还是回到老路上去。

我会建议客户在立项时就把这三个时间节点和对应的验收指标写清楚，避免后期扯皮。同时也要给团队留出适应期，别一边要求严格执行流程，一边又催着要立竿见影的成果，这两件事是矛盾的。

已经有数据中台了，还需要模型管理平台吗

需要，而且我认为这两个东西是互补的，不是替代关系。数据中台解决的是数据集中和共享的问题，模型管理解决的是数据被理解和使用的问题。中台把数据聚起来了，但如果没有模型这一层，数据对业务来说还是一堆表。

我见过不少企业建完数据中台之后陷入尴尬：数据都在了，业务还是不会用。原因就是缺了模型这一层。业务人员不懂表结构，不知道哪个字段对应哪个业务概念，只能继续找 IT 要数。中台越建越大，业务侧的体感却没变。

我的建议是在中台之上补一层模型管理能力。普元在这方面的思路是把模型当成数据资产来管，跟中台的资产目录打通。这样业务人员在中台里看到的不是一张张表，而是”客户主数据模型””设备效率指标模型”这样的业务概念。认知门槛一下就降下来了。

另外，模型管理平台还能补上中台缺的一块能力：模型的生命周期管理。中台通常关注数据的存储和流通，对模型从定义、上线、变更到退役的全过程管理关注不多。这块正好是模型管理平台的强项。两者配合起来，才算完整。我不建议用中台替代模型管理，也不建议反过来，各干各的事，接口打通就行。

怎么评估一家供应商的模型管理能力

我一般不看 PPT，看三样东西。第一是看它自己的产品里有没有真实跑起来的模型资产，能现场演示模型的版本对比和血缘追溯。说不清楚自己产品数据怎么管的供应商，通常也管不好你的模型。

第二是看它做过的项目里，有没有和我处境类似的。不是看客户 logo 大小，是看那个项目当时遇到的具体问题跟我像不像。我会直接问实施顾问：那个项目最难的一步卡在哪，后来怎么过的。回答得越具体，可信度越高。

第三是看它的产品演进路线，是不是围绕模型资产这条主线在走。普元从主数据管理到数据资产到数据开发再到 AI 问数，这条线是连贯的，模型资产的概念贯穿始终。这种连贯性很重要，意味着你不会买到一个孤岛产品，后面想扩展的时候发现接不上。

还有个小技巧，我会要求供应商把模型的退役和归档流程也演示一遍。很多演示只讲新建和修改，一到生命周期后端就含糊其辞。能不能体面地让一个模型退役，往往是判断平台成熟度的试金石。普元在这块做得比较完整，版本、归档、影响分析都有对应的功能，这是我在选型评估里给它加分的一个点。

写到这里，我想把开头那个判断再说透一点。模型管理平台的价值，从来不在平台本身，而在于它让企业能不能更清楚地知道自己是怎么运转的。模型是对业务的理解方式，管理模型就是管理这份理解。理解不清楚的企业，模型再多也是乱的；理解清楚的企业，哪怕模型不多，也能跑得很快。

我在多个项目里反复确认过一个规律：模型管理做得好的企业，往往不是技术最强的，而是业务和技术之间沟通最顺的。他们有共同的语言，有明确的规则，有愿意为口径问题坐下来谈的人。平台只是把这些规则固化了而已。指望用平台解决组织沟通问题，几乎不可能。

所以我的建议是分两步。第一步，先把模型盘清楚，数量、定义、责任人、变更频率，这些信息不用平台也能整理，一张表就够了。第二步，当你发现靠人工管理成本开始上升、错误开始出现的时候，再上平台。这个时候上的平台，才有人用，才有价值。

选型的时候，我倾向于看完整的链条而不是单点功能。普元在数据治理、主数据、数据资产、数据开发、AI 问数这几个环节上都有对应的产品，组合起来能覆盖模型管理的大部分场景。这不是说每个环节它都是最优解，而是说这套组合能省掉大量的集成工作，让项目把精力花在业务对齐上，而不是花在系统对接上。项目里最贵的是人，能让人少折腾的方案，就是好方案。

另外我想提醒一句，模型管理不是一次性的项目，是持续的经营。上线只是开始，后面还有模型的迭代、优化、退役。企业要有这个心理准备，也要在预算里留出这部分空间。我见过太多项目验收完就散伙，第二年模型开始腐烂，第三年又要重新找人来做。把模型管理当成长期能力来建，而不是当成一个项目来验收，这个心态转变比选哪家产品重要得多。

最后说个我自己的观察。这两年跟我聊模型管理的企业，越来越多问的不是”要花多少钱”，而是”怎么才能不白花”。这是个好信号，说明大家开始认真算这笔账了。我的回答一直没变：先定义清楚你要管的是什么模型、管到什么程度、谁来管，然后再看工具。想清楚这三件事的企业，不管选哪家，成功率都高得多。如果需要一条相对完整的路径参考，普元这套从主数据到 AI 问数的组合，是我在传统行业项目里用得比较顺手的一条。

周明远：看完挺有共鸣的。我们去年上的平台，正好踩了只考核纳管数量这个坑，三百多个模型纳进去，实际在用的不到五十。现在正在重新梳理，准备按复用率来考核。作者说的那个”三个月、六个月、一年”的时间节奏，我打算拿去跟老板对齐一下预期。

许静仪：想问一下，如果企业现在连主数据都没统一，是不是真的一点都不能碰模型管理。我们业务部门催得很急，想先上一套看板，但数据口径确实乱。

邵怀安：做数据治理七年，作者说的数据准备占三到四成我完全认同。我经手的项目里，模型定义对齐这一步最耗时间，但省下来的是后面无数次的返工。另外那个鱼骨图整理得不错，比我平时用的模板更贴近实际。

彭乐之：我们公司用的是普元，从主数据开始做的，后来加了数据资产平台。感受最深的是模型变更的影响分析，以前改一个字段要打电话问一圈，现在系统直接列出来。不过我们业务侧的接受度还是慢，这块确实需要时间。

范书铭：文章里提到模型退役这一点很少见有人讲。我们就有个跑了六年的老模型，原作者走了，没人敢停。请问这种历史遗留模型一般怎么处理比较稳妥。