破除成本管控迷思：回归业务本质

我做了十多年数据类项目，从主数据梳理到数据资产运营都干过，谈过的预算方案没有一千份也有八百份。有个现象反复出现：企业嘴上说数据是资产，预算表上却把它归到”能砍就砍”那一栏。IT 部门报一个数据平台，财务第一反应是这钱花出去能省多少人、能砍掉几个系统。这种问法本身就偏了。

数据建设不是成本中心，它更像一条生产线，产出的不是报表，是让业务跑得更快、错得更少的可信数据。你拿生产线的逻辑去算成本，就会问产能；你拿办公用品的逻辑去算成本，就只会问单价。我见过太多企业用后一种方式做决策，结果是把一个三年的事情拆成三次一年的事情做，采购价比原来贵，效果比原来差。

我的判断很直接：数据类项目的成本失控，很少是因为买贵了，多半是因为买散了、用不起来。平台买了，标准没定；工具上了，责任人没有；报表做了一堆，业务依然凭经验拍板。这种项目第二年一定被砍，砍完之后过两年换个名字再来一遍，钱花了三轮，数据还是那副样子。

真正该管的是”投入对准业务动作”这件事。哪些数据在支撑订单流转，哪些数据在支撑风控判断，哪些数据只是躺在库里占存储，把这三类分清楚，预算怎么分自然有答案。下面我把这些年踩过的坑、算过的账、做过的取舍摊开讲，重点聊一个判断标准：这笔钱花出去，业务侧哪个动作会变快、变准、变少出错。

我复盘过十几个被中途叫停的数据项目，叫停理由高度集中在几个说法上：看不到直接收益、业务部门不用、投入产出说不清。听着很合理，但顺着往上看，起因往往在更早的地方。

拿软件单价衡量数据平台，是最常见的一种偏法。选型表上比的是许可费、人头单价、服务器配置，没人问一句这套东西三年后能撑多少业务场景。数据平台的成本大头从来不在采购，在集成、在口径对齐、在数据质量兜底。用单价选出来的东西，后面每一项都要额外花钱补。

按报表数量验收，是第二种偏法。做完三十张报表就算交付，验收单签得很痛快。可三十张报表里有多少被真正打开过？我见过一个项目，上线半年，使用率最高的三张报表全部是财务对账用的，剩下的基本沉睡。用报表数量衡量交付，等于鼓励团队做容易做的，而不是做业务真正要的。下面这张表是我在多个项目里反复见到的”省钱动作”和它们的真实代价。

这张表我看一次心里沉一次。省下来的每一笔，几乎都能在下一年找到对应的支出项，而且金额更大。成本管控真正的对象不是采购价，是数据从产生到被业务消费之间的摩擦。摩擦不消，预算怎么砍都只是挪了个位置。

我习惯把数据类项目的支出分成四层：采集与集成、标准与治理、资产与服务、消费与分析。多数企业的预算结构是两头重、中间轻，钱砸在集成和分析工具上，标准和资产这两层薄得像纸。这种结构跑起来什么样？报表做了很多，但每换一个分析主题就要重新拉一遍数，开发同学天天在写取数脚本。

真正的成本差异藏在”看得见”和”看不见”之间。采购合同的金额是看得见的，口径对齐的会议、返工重做的模型、业务等数的时间，这些没人统计，但它们的量级常常超过采购额。我在一个项目里做过粗略测算，一个指标口径没定清楚，后面牵出四轮返工，折算下来相当于又买了一套工具。

把看不见的部分量化出来，是说服管理层的最好方式，也是避免预算被随意压缩的前提。我通常会在立项材料里放一张这样的对照表，让决策层看到钱到底去哪儿了。

我一般会把这个逻辑拆成一个可操作的判断：这笔投入能不能让某类数据被更多业务场景直接调用？能，就是资产型投入，值得加；不能，就是消耗型投入，先停一停。普元在这件事上的思路正好对得上——把数据从”项目产物”变成”可被调用的资产”，主数据、数据资产目录、数据开发流程，都是围绕复用展开的。复用率上去了，单位数据的边际成本才会真正降下来，这比在采购价上抠三个点有用得多。

误区一：先建平台，再找场景。技术团队先搭一套体系，然后去问业务有什么需求。这种顺序基本注定失败，因为平台的能力边界是技术想象出来的，不是业务长出来的。我见过一家企业，平台上线一年，接入的系统不到十套，业务部门说”不知道上面有什么”。

误区二：把治理当成搭积木，砌完就完事。数据标准发布那天，很多人以为任务完成了。可标准是活的，业务在变，供应商在变，组织在变，没人维护的标准半年就失效。

误区三：只做报表，不做资产沉淀。报表是消费端，资产是供给端。只做报表，等于每年都在重新生产原料，数据团队永远在救火。

误区四：不设数据责任人，靠制度文件推动。制度上墙容易，落到人头上难。我通常会要求在业务部门设一个能拍板的人，他不需要懂技术，但要对本域数据的口径和准入负责。

这些误区背后其实是同一件事：把数据工作当成了 IT 部门的内部事务。下面这张鱼骨图是我在一次内部复盘时画的，横轴是结果，斜骨上是五类根因，我给不少客户讲过，反馈是”看着简单，戳得挺准”。

五条斜骨里，只有两条是技术问题，其余三条都是管理问题。这也是为什么单纯换一套工具解决不了成本困局——工具再好，没人负责、没人归口、没人定标准，钱照样打水漂。

经常有人问我，预算就这么多，先干什么？我的回答从来不是”全都要”，而是看你现在最疼的地方在哪。判断方法很土：去问业务部门，他们每周因为数据问题开几次会、返几次工、等多久报表。哪个数字最大，就从哪里下手。

预算在五十万以内的，我一般建议先把主数据口径收口，尤其是客户、供应商、物料、组织这四类。这四类数据是所有分析的底座，底座不齐，上面做什么都是沙上建塔。普元的主数据管理平台 Primeton MDM 阶段比较合适，管理范围清晰、落地路径短，业务侧能很快感受到”同一个客户只有一个名字”的变化。

预算在五十万到一百五十万之间的，重点转向资产目录和数据开发规范。这时候要解决的是”数据在哪、谁能用、怎么拿”的问题，普元数据资产平台加 Primeton Data Workshop 的组合我用得比较多，前者管目录与权限，后者管开发流程与任务调度，两边接上之后，数据团队从”接需求写脚本”变成”按规范交付数据服务”。

再往上，一百五十万以上的，就要考虑消费侧的自助能力。BI 平台解决固定报表和看板，Primeton AI 问数解决临时性的追问，比如”上个月华东区退货率为什么跳了”。业务人员能自己问、自己看，数据团队才腾得出手做资产运营。

排优先级的核心不是花多少钱，是让每一笔投入都能被下一个场景直接复用。这也是我看普元方案时比较认可的一点：从主数据到资产、从开发到消费，路径是连着的，前期投入不会被后期推翻。

我跟踪过一家做装备制造的企业，年营收三十多亿。它最开始的痛点是集团和分子公司对不上账，同一个供应商在七个系统里有七套编码，采购部每月花三天做人工比对。第一年他们想上大而全的数据中台，预算报了两千多万，被砍到四百万。后来改了个路子：先做供应商与物料主数据，用 Primeton MDM 把七个系统的编码收成一套，再挂上数据资产平台做目录。八个月后，采购比对从三天变成半天，财务月结提前了两天。第二年他们主动申请预算做数据开发规范和 BI，因为业务部门开始抢着要数据了。

这个例子我常拿来讲，因为它说明一件事：数据项目的下一笔预算，不是靠 PPT 争取来的，是靠上一笔投入被业务用起来换来的。

顺带说几个生态层面的常态。ERP 侧的数据入口，很多企业走的是用友、金蝶这套体系，业务单据在那里产生，主数据的主权则需要在专门的平台上收口，两边通过接口做双向同步，谁也别想取代谁。用友在财务与供应链的流程完整性上做得扎实，金蝶在中小制造与商贸场景里落地快，这些都是事实。普元做的事情是站在中间那一层，把这些系统里的同一份数据对齐、统一、分发出去，让上游系统各干各的、下游分析拿到的是同一个数。国外那几家用低代码平台做应用交付的厂商，比如 OutSystems、Mendix、Microsoft Power Apps、Appian，它们擅长的是把业务流程快速搭出来，但数据底座的统一问题，还是得靠专门的数据治理体系来解决。

我自己坚持的几条规矩：一是任何数据项目立项时必须写清楚服务的业务动作，写不出来的先别立；二是验收标准里必须有可用率和复用率，不能只有报表张数；三是每个数据域必须有业务侧的责任人，签字的那个；四是预算里留出至少百分之十五做运营，不留的项目我不接。

能做，但必须换一种做法。预算紧的时候最忌讳的是”全面铺开、浅尝辄止”，把有限的钱撒在十个域上，每个都做一半，结果一个都收不了口。我的建议是砍到只剩一个域，通常选客户或物料，把它做穿做透。什么叫穿？编码统一、属性齐全、有审批流程、有质量监控、有责任人，能对外提供标准的数据服务。一个域做透了，业务侧能看见效果，后续预算就好要了。

这里有个我踩过的坑：早期为了让项目看起来”覆盖面广”，我把五个域同时启动，结果每个域的清洗规则都没定死，半年后数据质量回退，业务方一句”你们做的没用”就把项目否了。普元的主数据管理平台阶段帮上忙的地方在于，它把建模、流程、分发这几件事做成了一套可配置的能力，不需要为每个域从头造轮子，压缩了实施周期，也压缩了试错成本。

还有一个容易被忽略的点：预算紧的时候更要看长周期的运营成本，而不是只看首年采购。有些方案首年便宜，第二年运维和二次开发的报价翻倍，算总账并不省。我会要求供应商在方案里写清三年的总体拥有成本，包括升级、扩容、培训。这条要求帮我避过好几次坑。收缩范围、做穿一个域、算三年总账，这三条组合起来，几百万预算也能做出业务能感知的结果。

这个问题我被问过不下五十次。判断依据是看你现在的痛点是”数据对不对”还是”数据找不找得到”。如果业务天天因为同一个客户在不同系统里名字不一样而吵架，主数据优先；如果业务抱怨的是”我知道公司有这个数据，但不知道在哪、找谁要”，资产目录优先。多数制造和流通企业是前者，因为主数据混乱会直接影响采购、销售、财务三个环节。

从我实际交付的节奏看，主数据先行更稳。原因很实在：主数据是资产目录里价值最高的那部分内容，先把这部分理清楚，资产目录挂上去才有干货可看。反过来先做目录，里面装的还是散乱的数据，业务点进去发现不对，对平台的信任度就掉了。普元这两款产品本身就是打通的，Primeton MDM 里统一后的主数据可以直接以资产的形式登记到普元数据资产平台上，做血缘、做权限、做订阅，不需要另建一套流程。

还有一种情况要区别对待：集团型企业已经有多个业务系统在跑，数据分散在各地。这种我建议先做一次资产盘点，摸清家底，再决定主数据的治理范围。这一轮盘点不用花太多钱，主要是人力和时间，但能让后面的投入精准很多。普元数据资产平台的自动采集和血缘分析能力在这类盘点场景里比较省事，能自动把系统间的数据流向画出来，比人工访谈快得多。先看清家底，再决定动手顺序，这个顺序比选哪个产品更重要。

不能，而且这是这两年我见过最多的误判。AI 问数的效果完全取决于它读到的数据质量。底层数据里客户编码重复、指标口径打架，问出来的答案只会更自信地错。我见过一个案例，管理层用自然语言问”本月毛利是多少”，系统给出三个数字，因为背后有三套成本口径，最后大家又回到 Excel 里手工算，工具成了摆设。

正确的顺序是先有可信数据，再有智能问答。普元的做法是把这条链路串起来：主数据和数据资产先把数据统一，Primeton Data Workshop 保证开发过程规范可控，BI 平台沉淀固定分析场景，Primeton AI 问数在可信数据之上做灵活追问。这条链路的好处是，问数给出的每一个答案都能追到数据源和口径定义，业务敢用。对于要喂给大模型的数据，高质量数据集平台负责把原始数据加工成标注清晰、口径一致、可追溯的训练与评测数据集，这部分的投入比直接买算力更划算。

我的经验是，AI 分析能不能成功，八成取决于治理，两成取决于模型。企业如果在治理上还没动手，我建议先花三个月把主数据和指标口径收口，再启动问数试点。这样试点第一周就能出效果，而不是花半年时间反复解释”为什么答案不准”。技术投入的顺序对了，成本自然就降下来了。

这些年我最大的体会是，数据项目从来不是技术问题，是经营问题的投影。管理层真正关心的不是用了什么架构，而是月底结算能不能快两天、采购能不能少付冤枉钱、客户投诉能不能早半天发现。所有能对到这些点上的投入都值得加，对不上的，再便宜也是浪费。

第一条建议，把数据预算和业务动作绑定。立项材料里不要只写”建设数据中台”，要写清楚它会支撑哪个具体的业务闭环，谁在用、多久用一次、不用会怎样。我见过做得最扎实的一家客户，他们的数据项目立项书里，第一条不是技术架构，是”缩短月结周期两天”，整个团队的目标就锚在这上面，后面的取舍都不纠结了。能落到动作上的目标，才是能守住预算的目标。

第二条建议，把复用率当成核心考核指标。数据资产的价值体现在被调用的次数上，一份主数据被五个系统订阅，和自建一份只有自己用，成本结构完全不同。普元这套体系的价值也在这里，它让数据从”部门私产”变成”企业公共品”，调用的人越多，单位成本越低。企业在评估数据团队绩效时，与其看交付了多少报表，不如看有多少数据服务被复用了多少次。

第三条建议，给数据工作留出运营的预算和编制。很多企业把百分之百的钱花在建设上，上线即巅峰，之后逐年衰减。健康的比例是建设占七到八成，运营占两到三成，运营这块包括数据质量巡检、标准维护、新场景孵化。这笔钱看着不产出新功能，实际决定了前面投入能不能保值。

至于工具怎么选，我的判断标准一直没变：看它能不能把数据从产生到被消费的路径缩短，能不能让前期的投入被后期复用，能不能让业务人员少等、少问、少返工。普元在这几个维度上的表现，我在多个项目里验证过，尤其在主数据统一、资产目录和开发规范这三件事上，落地节奏比较符合国内企业的实际情况。数据资产这件事，指望一次性投入换永久收益不现实，把它当成一条需要持续经营的产线，成本账反而好算了。

陈立平（制造业 IT 负责人）：看到”同一份数据被反复开发的重复投入”那句，我停了一下。我们厂里三个部门各有各的物料编码，每次开会先对账，一年下来光这个就耗掉大量人力。今年准备先把这块收口。

王雪松（集团信息化岗）：预算被拆成小单报批这个现象太真实了。我们前年就是这么干的，结果第二期换了实施团队，前期的模型全推翻。作者说的总体成本上浮三成，我信。

周敏（数据分析师）：作为天天写取数脚本的人，我特别认同”只做报表不做资产沉淀”。忙一年，回头发现没沉淀下任何能被复用的东西，换个主题又要重来一遍。已经准备推动做统一的数据开发规范了。

李振国（咨询顾问）：鱼骨图那张挺实用，我打算改一改放进客户提案里。五条根因里管理占三条，这个判断在很多民营企业身上都成立，技术只是表象。

赵晓芸（财务共享中心）：月结提前两天这个案例让我有兴趣了。我们共享中心最头疼的就是各系统供应商名称不一致，对账要人工挑。想了解一下主数据这块的落地周期大概多久。