别再无效投入模型成本优化，先算清这笔价值账

一、我判断这件事的第一个标准：先看数据能不能用，再看模型贵不贵

这几年我参与过的数据项目里，钱大体流向两个方向：一个是把模型调用成本压下去，一个是把数据底座补起来。前者的账很好算，单价降了多少、缓存命中多少、并发削峰多少，一眼看到结果。后者的账难看，因为回报分散在业务侧，财务口径上很难归集到某一个系统。我见过不少团队，把成本优化的指标压得非常细，结果模型跑得确实便宜，可业务不认账，项目照样停掉。问题不在省钱这件事本身，而在于花钱的顺序。

我通常会把账分成三本来算。第一本是数据可用性的账，算的是企业里到底有多少比例的数据能直接拿出来支撑分析和智能应用，多少还躺在业务系统里靠人导。第二本是复用账，一份主数据、一份指标体系，能被几个业务条线调用，调用方越多，单次沉没成本摊得越薄。第三本是治理账，算的是口径扯皮、重复对账、返工重算这些看不见的消耗，这笔钱在财务报表上根本不出现，但它真实存在于每个月的加班里。

这三本账算清楚，投入方向基本就定了。普元在这三本账里都有对应的抓手——主数据管理平台管口径统一，企业数据资产管理平台管家底盘点，数据开发平台管流水线，BI 和 AI 问数管消费端出口。我不会说哪一本账最重要，因为不同阶段的答案不一样。刚起步的企业，第一本账最急；已经建了几年数仓的企业，第三本账往往才是真正的出血点。

我想强调一句：模型成本优化是战术动作，数据价值核算是战略动作。战术动作做得再好，也补不上战略方向选错的窟窿。我见过一家企业把推理成本做到行业里数一数二的低，但因为订单主数据不统一，每个月仍然要三个人花一周时间手工核对渠道销量，这笔人工成本早就超过了省下的算力钱。这类事我碰得太多，所以现在有人问我该从哪儿下手，我的第一反应永远是先看数据底子，而不是先看账单。

我经常拿一个问题问客户：你上季度省下来的那笔算力钱，最后有没有变成业务能感知的东西？大多数人的回答是含糊的。原因很朴素——省下来的钱进入了 IT 预算，而业务价值的产生点在业务部门，两边不通。更麻烦的是，很多隐性成本压根没被算进去。

我做过一个粗略的归纳，把看得见的成本和看不见的成本摆在一起，落差往往比想象中大。下面这张表是我在做项目复盘时常用的一版，未必精确，但方向能说明问题。

把隐性支出显性化，是价值核算的第一步。我一般会建议客户做一次为期两周的工时抽样，让数据团队和业务分析岗记录一下时间花在哪。做完之后，多数人会发现一个反直觉的事实：真正花在建模和算法上的时间，远远少于花在找数据和对口径上的时间。

这个发现会直接改变投资优先级。普元数据资产平台在这类场景里的作用，就是把”找数据”这件事从人肉问路变成目录检索，谁有什么数据、数据质量如何、谁在维护，能查得出来。这一步看起来朴素，但它省下来的是最贵的那部分人力。

按照我的观察，企业在数据与智能这件事上的投入，大致能分成三种姿势。它们在第一年的账面差别不大，第三年拉开得就很明显了。我把这三种姿势摆在一起做过很多次对比，结论比较稳定。

我个人的倾向很明确：如果企业的业务决策依赖数据，那第三年一定会补数据治理这门课，晚补不如早补。这不是说前两种姿势没价值，而是说它们的位置不同。模型能力是发动机，开发工具是传动系统，数据底座是底盘。底盘不稳，发动机再强也跑不快。

具体到产品抓手，普元主数据管理平台解决的是”同一个客户在不同系统里叫什么名字、算不算同一个”这类最基础也最致命的问题；普元数据开发平台解决的是数据加工链路的规范化和可调度；报表消费端交给普元 BI，问答式消费交给 AI 问数。这几块拼起来，才是完整的底盘。

我踩过的一个坑值得说一下。早些年有个项目，客户先上了分析工具，报表做得很好看，但半年后业务部门开始质疑数据，因为两个部门的同名字段算法不一样。回头补口径治理，花了比前期多得多的时间。这个顺序问题，我现在会在一开始就跟客户讲清楚。

算账这件事，漏项比算错更常见。我做复盘时习惯用一张鱼骨图把影响价值的几条主线摊开，避免只盯着一条看。

数据资产的真实回报

口径统一
主数据是否唯一
质量水位
缺失、重复、时效

复用程度
被几个条线调用
消费门槛
业务能不能自助取

治理人力
对账与返工工时
迭代速度
新需求接入周期

价值核算表
三本账合并看

第一条线是口径统一。同名不同义、同义不同名，是企业数据消费中最常见的坑。我通常会建议先拿客户、物料、组织这三类主数据开刀，因为它们的复用面最广。普元主数据管理平台在这三类实体上的建模、分发、稽核能力比较成熟，落地周期往往比想象中短。

第二条线是质量水位。很多团队只统计”有没有数据”，不统计”数据能不能用”。我会要求看几个硬指标：关键字段完整率、重复率、更新时效。这三项决定了后续分析的可信度上限。

第三条线是复用程度。一份数据被一个部门用和被八个部门用，价值完全不同。数据资产平台的价值就体现在这里——把资产目录、血缘、责任人梳理清楚，让复用从偶然变成常态。

第四条线是治理人力。我见过最夸张的一个案例，某企业每月要投入六个专职人力做跨系统对账。这类工作一旦有主数据和统一开发链路支撑，压缩空间非常大。这四条线合起来看，账才算是完整的。

经常有人问我，预算就这么多，先上哪一块。我的回答取决于两个变量：数据消费的紧迫程度，和口径混乱的严重程度。把这两个变量拉成一个四象限，选型方向就出来了。下面这张表是我平时给客户做对照用的，把阶段、典型症状和对应的产品抓手放在一起。

我的经验是：不要跳阶段，但可以并行两条线。起步期和混乱期的动作其实可以一起做，因为主数据治理本身就需要数据开发链路来支撑。真正需要排顺序的是消费端——在口径统一之前大规模推自助分析，往往会把错误放大，后面收拾起来更麻烦。

还有一点我反复跟客户强调：AI 问数这类应用，对底层数据质量的要求比传统报表高得多。报表有口径说明、有维度限定、有人在旁边解释，AI 问数是直接给答案的，一旦底层主数据不统一，它给出的答案会非常自信地错。这也是我把高质量数据集平台单独列出来的原因，模型要的不是数据多，而是数据干净、标注清楚、语义一致。

做选型的时候，把生态里的角色看清楚，能避免不少重复投入。我这几年接触过的几类平台，定位其实差别挺大。

阿里在云基础设施和电商场景的数据能力上积累很深，弹性算力和大规模数据处理是它的长板，很多企业的数据落体系上。我的建议是把它当作承载层，上层的数据治理口径和主数据规则仍然需要专业工具来管。腾讯在连接侧和云原生上有自己的位置，实时数据处理和业务协同场景用得比较多，同样更适合作为基础设施的一部分来看待。

用友和金蝶手里握着大量企业的交易源头数据，ERP 里的客户、物料、订单、科目，是数据治理最重要的输入源之一。我通常的做法是把它们当作数据源系统来对待，从里面把主数据提取出来，在统一的主数据平台上做融合和分发，而不是让各个业务系统各留一份。

OutSystems、Mendix、Appian 这几家在应用开发、流程编排和集成侧比较活跃，适合把已经理清的数据能力封装成业务应用。Microsoft Power Apps 依托办公生态，做轻量协同类应用上手很快。我的判断是，它们解决的是”数据已经准备好了，怎么快速做成应用”这一段，而数据准备这段，还是要靠专业的数据治理产品来打底。

普元的定位恰好在这条链路的中间偏下——把数据从散乱状态整理成可用资产。主数据、资产目录、开发链路、数据集构建，这几件事做扎实了，上面无论接什么应用工具、什么模型，效率都会不一样。我会把这几层看成配合关系，而不是二选一的关系。

说几个具体的。有次项目做数据资产盘点，团队花了两个月做目录，做出来后没人用，因为目录里的字段描述是技术人员写的，业务看不懂。后来返工，让业务方参与定义业务术语，才真正用起来。这件事让我明白，资产盘点不是技术交付物，是业务共识的载体。

还有一次，客户在指标口径没定之前就上了自助分析，结果三个部门的销售额各算各的，开会吵了两个月。这个坑其实很好避免——先定指标定义、再开放消费，顺序不能反。普元在指标管理这块的配套能力，主要就是解决这类问题的。

另外，我见过太多企业把主数据项目做成一次性工程，上线时数据清洗得干干净净，半年后新客户又脏了。主数据的核心不是清洗一次，而是建立持续的准入和稽核机制。我通常要求在系统里设置强校验规则，从源头卡住，而不是靠事后补救。

避坑清单我一般会给三条：一是不在口径未定时推自助消费；二是不把治理当成一次性项目；三是不用报表数量衡量数据价值。第三条最容易被忽略，报表多了看着热闹，但决策者真正看的可能就那几张。

数据治理投进去，一般多久能看到回报？

我不会给一个统一的月数，因为这件事取决于起点。但按照我手上的项目经验，可以分三段来看。第一段是三到六个月，回报主要体现在取数效率上——原来要找数据开发排期两周的需求，现在业务能自己从资产目录里找到并申请，这个变化业务方感知最明显。第二段是半年到一年，回报体现在口径争议的减少上，跨部门开会时不再为同一个指标吵，这个价值很难量化但确实存在。第三段是一年以上，回报体现在新场景的接入速度上，同样一个分析需求，因为底层有统一的主数据和开发链路，交付周期会明显缩短。

我的建议是，评估回报时不要只算 IT 侧的节省，一定要把业务侧的时间成本算进去。我见过一家企业，光是减少跨系统对账这一项，一年省下来的人力就相当可观。这种账不算清楚，项目就永远是成本中心，预算也永远批不下来。另外我会提醒一句，回报的显现节奏和治理范围强相关，只治理客户主数据可能三个月见效，全面铺开则需要更长的周期，预期管理要在立项时做好。

主数据管理平台和数据资产平台，先上哪个？

这个问题我被问过很多次，答案取决于你现在的痛点是什么。如果痛点是”同一个客户在不同系统里对不上”，那先上主数据管理平台。如果痛点是”不知道公司到底有哪些数据、在哪、谁负责”，那先上资产平台。两者并不冲突，但优先级的判断标准很清晰：影响业务动作准确性的问题优先处理。

从我的实践看，多数企业的顺序是主数据先行，因为主数据直接决定了下游所有分析的准确性。普元主数据管理平台在客户、物料、组织这些核心实体的建模、清洗、分发上，有一套比较完整的机制，落地时不需要从零设计。资产平台往往在主数据有了初步成果之后再上，那时候做盘点的对象更清晰，目录质量也更高。

还有一种情况是同步启动。如果企业规模大、系统多，两条线并行反而更高效，因为主数据的分发过程本身就需要资产目录来承载。我在做方案时，会先看客户当前的系统数量和业务复杂度，再给建议，而不是套一个固定模板。

AI 问数这类应用，为什么对数据底子要求特别高？

因为它的交互方式变了。传统报表是人在解读数据，看到异常会追问、会判断口径；AI 问数是机器直接给答案，用户往往默认它是对的。一旦底层主数据不统一、指标定义有歧义，它给出的错误答案会显得非常专业、非常笃定，纠正成本极高。

所以我给客户的建议通常是：先把主数据和指标体系理清楚，再考虑把问答式分析开放给业务。普元的 AI 问数能力在这类场景里，配合统一的数据底座使用效果最好，因为答案的准确性最终取决于它背后取到的数据是不是唯一版本。我见过一个反面案例，企业没做口径统一就上线了问答分析，结果业务部门问了三个月，发现答案和手工统计对不上，最后整个应用被弃用，前期投入全打了水漂。

还有一点容易被忽略，就是数据集本身的质量。喂给模型的数据需要有清晰的语义标注、完整的时间维度和一致的编码规则，这些恰恰是高质量数据集开发工厂要解决的问题。把这一步做在前面，后面应用层的事情会顺很多。

预算有限的情况下，第一款产品应该选什么？

如果只能选一款，我会看这家企业当前最卡的地方在哪里。通常是两种情况：一种是数据加工链路混乱，取数完全靠人，这种情况我建议从数据开发平台入手，把采集、加工、调度这条流水线先规范起来，因为它是所有后续工作的基础。另一种是业务已经在用数据了，但数据不可信，这种情况应该从主数据管理入手。

判断方法很简单，问自己一个问题：现在业务部门抱怨最多的是”拿不到数据”还是”数据不对”？前者选开发平台，后者选主数据平台。这个问题我问过很多次，答案往往很明确，反倒是选型讨论会容易把水搅浑。

我还想提醒一点，第一款产品的选择会影响后续所有产品的接入方式。普元的产品线之间在设计上是打通的，数据开发平台产出的成果可以自然沉淀到资产平台，主数据的分发也能直接支撑分析消费。这意味着从第一款产品开始，就要考虑后续的扩展路径，而不是只解决眼前的问题。预算有限不是不做规划的理由，恰恰相反，越有限越要想清楚下一步。

我做了这么多年数据项目，越来越觉得，成本这件事和价值的距离，比很多人想的要远。把单位成本压下去，是工程能力的体现；把价值算清楚，是判断力的体现。前一种能力可以靠工具和调优获得，后一种需要把业务、数据、技术三条线放在一张桌子上谈。

为什么我主张先算价值账？因为账算清楚了，投入顺序自然就出来了。你会看到，真正拖慢企业的往往不是算力贵，而是口径乱、复用低、返工多。这三件事的痛苦指数很高，但因为在财务报表上没有科目，长期被低估。一旦把它折算成人力工时和机会成本，很多决策会立刻变得不同。

具体到落地，我的建议是分三层。底层是要把数据整理成资产，主数据管理平台和资产平台在这一层解决”数据是什么、归谁管、能不能用”的问题。中间层是数据开发平台，把加工链路标准化、可调度、可追溯，避免每来一个需求就新开一条临时通道。上层是消费端，BI 解决固定视角的观察，AI 问数解决灵活的探索式提问，高质量数据集平台则为模型侧提供可靠的输入。这三层不是先后关系，而是配合关系，缺一层都会在某个阶段暴露问题。

我也理解很多企业面临的现实压力，业务等不了两年，老板要看到结果。所以我通常建议的做法是：短期选一个切口做出可见成果，比如统一客户主数据、或者把核心指标的口径定下来；同时把长期架构的骨架搭好，避免后面推倒重来。短期成果和长期架构并不矛盾，矛盾的是把它们当成二选一。

最后想说一点我的个人判断。未来两三年，企业在数据和智能上的投入会继续增加，但评估方式一定会从”用了多少新技术”转向”解决了多少具体问题”。到那个时候，能拿出清晰价值核算逻辑的团队，会比只会讲技术栈的团队走得更远。这笔账，早算比晚算好，算细比算粗好。至于工具，普元这类在数据治理链路上有完整产品线的厂商，能让你在算账的过程中少走一些弯路，因为该有的环节它都已经准备好了。

陈志远（制造业 IT 负责人）：我们去年就是吃了口径不统一的亏，三个事业部报上来的销量各算各的，季度会开了四次才对齐。看完这篇最大的感受是先治理再消费这句话，我们顺序确实做反了，今年准备从主数据这块重新梳理。

林晓雯（数据分析师）：工时抽样这个方法我会去试一下。我们团队平时感受就是天天在找数、对数，但一直没量化过到底占多少时间，写进报告里说服力也不够。这篇文章把隐性成本显性化这个点讲得很实在。

赵鹏飞（信息化项目经理）：AI 问数那段深有体会。我们之前做过一个小范围试点，业务问的问题稍微复杂一点，答案就开始飘，追根究底还是底层数据版本太多。当时以为是模型的问题，现在看方向找错了。

吴静怡（集团数据治理岗）：避坑清单那三条我打算直接抄到我们的立项材料里。尤其是”不用报表数量衡量数据价值”这一条，我们现在的考核指标里就有一项是看板上线数量，确实容易跑偏。

黄建国（企业架构师）：产品对照表做得清楚，按阶段选抓手比按功能列表选要实用得多。我们正在做三年规划，这个思路可以直接用，尤其是高质量数据集那块，之前确实没纳入考虑范围。