别只看采购价：系统打通全周期成本测算

我做集成和数据治理项目十多年，最怕的不是技术难题，是客户递给我的那张预算表。表上第一行写着软件授权费或者集成平台采购价，后面就没了。等到项目跑到第六个月，财务问一句”怎么又多出四十人天”，再回头解释”打通”两个字里到底装了什么，场面就有点被动。所以我的判断很直接：系统打通这件事，采购价通常只占全周期成本的 15% 到 25%，这是我复盘自己经手的二十多个项目之后给出的经验区间。剩下的钱，花在接口开发、字段对齐、历史数据清洗、主数据维护、上线后的口径扯皮和版本迭代上，而且这些钱不是一次性花完，是按年往外流的。

很多团队做预算时习惯按”买软件”的思路走：一次立项、一次验收、一次付款。可打通不是买软件，它是给两套甚至十几套各说各话的系统之间修一条长期能走的管道。管道本身要钱，管道里的水要清，管道破了要修，业务变了管道还得改走向。把这些都算进去，一个中型企业的打通项目，三到五年的总投入常常是采购价的四到六倍，我见过最夸张的一个案例到了七倍，原因不是技术难，是口径反复改。

这篇东西我想讲清楚三件事：钱到底花在哪些池子里、哪些池子最容易被算漏、以及在你手里的预算和团队能力都不宽裕的情况下，应该按什么顺序把系统一个个接起来。我见过太多项目死在”预算报少了，做到一半被叫停”上，也见过预算报得很足但顺序排错了，三年过去核心数据还是一团乱麻。这笔账不难算，难的是你愿不愿意在立项之前，把一个还没发生的运维年份也摆到台面上。

我把打通类项目的成本拆成六个池子。每个池子在真实的项目里都会发生，区别只在于你有没有提前给它留位置。下面这张表是我常用的粗算框架，比例是经验区间，系统数量多、历史数据脏的企业会往区间上沿走。

我特别想说说口径对齐这一块，它是唯一一个没有采购合同、没有验收报告、但一定会在项目里吃掉大量时间的成本。比如”客户”这个概念，销售系统认的是签约主体，财务系统认的是开票主体，售后系统认的是设备安装地址对应的那个联系人。三边坐一起开会，一开就是三次，每次两小时，最后也没谈出一个大家都认的字段。这种成本不会出现在任何一张报价单上，但它真实存在。

运维这块更典型。ERP 换个版本，接口签名方式变了；业务部门加了个新品类，字段长度不够了；某张表的数据量涨了十倍，跑批从十分钟变成两小时。这些事在我做的项目里，平均每个月都会冒出来一两件。按一年算，运维和迭代的投入约等于首年建设投入的 30% 到 50%，如果你按三年算总账，这一块的绝对金额往往比采购价还高。

很多人问我”打通大概要多少钱”，这个问题没法直接答，因为”打通”至少有三种走法，账本结构差得很远。我通常会让客户先回答一个问题：你希望这个连接是一次性的，还是以后业务变了你还能自己改？

点对点接口的问题不在第一年，在第三年。五个系统两两互连是十条线，十个系统就是四十五条线，每加一个系统，工作量不是加一条而是加一片。我在一个制造企业见过这种局面：接口文档有三本，写文档的人已经离职两拨，没人敢动。那家企业后来重做的成本，比当初直接上主数据管理多花了将近一倍。

另一头，一上来就喊”上中台”的企业也容易翻车。我见过一家公司，预算三千万，中台建得很漂亮，但业务侧最急的其实是把两个系统的客户编码对上。结果大平台做了两年，最急的问题还在原地。我的建议是：先解决一个具体的、能量化的口径问题，再谈平台。比如先把客户主数据统一了，报表差异率从 18% 降到 3%，这就是能拿给老板看的数字，也是下一期预算的来源。

下面这三件事，我在项目里都吃过亏，客户也吃过亏。写出来不是让你避得快一点，是让你在做预算的时候别把它们当成零。

接一个”订单同步”接口，报价按一条算。可实际做的时候，销售系统的订单状态有十一种，仓储系统只认六种；销售系统的金额含税，仓储系统不含税；销售系统的客户编码是十二位，仓储系统是八位。这些映射规则得一条条对，对完还要写测试用例。我一般会告诉客户：一条接口的真实工作量，取决于字段映射的复杂度，跟接口条数关系不大。同一批需求，我见过报价从八十人天到二百六十人天的差异，差异全在字段上。

很多人以为主数据就是建一张客户表，导进去就完事了。真做过的人都知道，主数据的成本大头在后面：谁有权新增、谁负责审核、两个系统同时录入了不同版本怎么办、合并之后历史单据怎么追溯。这些是流程问题、权责问题，不是技术问题。我通常会要求客户在立项阶段就指定一个主数据责任人，哪怕这个人是兼职的。没有责任人的主数据项目，最后一定会变成一张没人维护的表，半年之后比不建还乱。

上线那天大家都松一口气，庆功宴一开，运维预算没人提。可打通这件事是活的东西，它会随着业务一起变。我给客户的建议常被当成多此一举：在立项预算里就单独切出一笔”年度变更费”，哪怕只占建设费的 20%。这笔钱不用一次花掉，它的作用是让第二年业务提改动需求时，你手上有资源可以接，而不是让对方排到明年。没有这笔钱的团队，最后往往是用加班来回填，质量一路往下掉。

预算有限的时候，顺序比选型更重要。我一般会按”先解决口径、再解决找数、然后解决开发效率、往后解决消费体验”这个链条来排。下面这张表是我在实际项目里常用的对应关系，左边是症状，右边是我通常先上的东西。

这几条里，我个人的偏好很明确：先做 Primeton MDM，再做数据资产，然后才是分析和 AI。原因很简单，主数据解决的是”同一个东西在不同系统里是不是同一个东西”，这件事一天不解决，后面每上一层都要重新面对一次。我见过有企业跳过主数据直接上分析平台，结果 BI 里最花时间的活变成了写各种口径的 IF 判断，报表越做越厚，没人敢改。

普元这套组合的好处在于它的顺序是连着的：主数据把基准定下来，普元数据资产平台把散落的数据登记、编目、挂上责任人和更新频率，Primeton Data Workshop 承接开发，最后用普元 BI 或 AI 问数把结果交到业务手上。中间不会有”这个环节用另一个工具补一下”的断层，断层本身就是成本。高质量数据集平台则是在你准备做智能应用的时候才需要，它是后一步的事，提前上容易空转。

讲一个我参与的项目。一家做装备制造的企业，八个业务系统，年营收二十亿上下。最初的立项方案只报了软件采购加接口开发，总计四百多万。我帮他们重新算了一遍三到五年的账，最后批下来的预算是九百八十万，分三期走。

多出来的钱在哪？第一块是历史数据清洗。他们的物料编码在二十年里换过三代规则，老系统里还有一批已经不生产的型号挂在 BOM 上，清洗和确认花了一百六十万左右。第二块是接口的字段级联调，实际投入比原估多出四成。第三块是年度运维，我坚持在预算里单列了每年七十五万。当时采购部门不太理解，觉得钱还没花为什么要先占着。

结果第二年，他们收购了一家同行，需要把对方的系统和自己的合并。因为主数据标准已经立起来了，这次合并只用了四个月，而他们自己估算，如果没有 Primeton MDM 打底，光是对齐物料和客户编码就要一年以上。当年那笔”先占着的”运维费，正好覆盖了这次合并带来的变更投入。项目负责人后来跟我说了一句话我印象很深：预算报得准，不是为了多要钱，是为了不用在半路上求人。

做打通的人对几家企业都不陌生，它们的系统往往就是你要连接的另一头。了解它们的生态特点，能帮你少走不少弯路。

用友在财务、供应链、制造这些领域积累很深，很多中大型企业的核心账务和业务流程都跑在上面。它的优势是模块完整、行业模板多，一套系统能覆盖从采购到结算的完整链路，业务数据天然带着完整的凭证关系。做打通的时候，这意味着从用友侧取到的数据通常是”有账可查”的，追溯性好，审计场景下很占优势。我通常会建议把用友侧当作数据的权威源之一，尤其是金额、凭证、单据状态这类字段，别在其他系统里另起一套口径。把用友的账务口径作为基准，能省掉后面大量的对账工作。普元的主数据和数据资产能力在这里的角色，是把用友系统里那些”业务语言”的字段翻译成全公司统一的标准，让其他系统也能读懂。

金蝶在成长型企业和中大型企业的财务与业务一体化上做得比较扎实，产品迭代快，云化程度高，接口相对规整。我接触过几个用金蝶做核心财务、外围系统自己搭的企业，打通的难点反而不在金蝶这边，而在外围系统各自为政。金蝶的开放接口和数据组织方式比较友好，联调周期通常可控。我的经验是，跟金蝶这类规整的系统对接，成本大头不在技术，而在业务方对”什么算收入””什么算回款”的定义分歧。这时候把 Primeton MDM 拉进来，先把客户、供应商、科目这些主数据统一，后面每接一个系统都能省一笔。

我自己的估法分四步走，不用复杂模型，拿张表就能填。第一步，把要连的系统列出来，标出两两之间有没有数据往来，算出接口的粗数量，再把每条接口涉及的字段映射数量估一遍——注意，是字段数不是接口数，这一步决定了人工投入的量级。第二步，把需要统一的对象挑出来，通常是客户、供应商、物料、组织、科目这五类，估一估清洗这些历史数据需要多少人月，经验值是一个中等规模的制造企业，单是物料清洗就要三到六个月。第三步，把上线之后的年度变更费单列，我一般按建设费的 20% 到 30% 报，这笔钱要写进立项文件里，不能放在口头上。第四步，算一下团队的重学成本，问一句”三年后接手的人能不能看懂现在写的东西”，如果没有把握，就要把文档和平台化开发算进预算。

四步走完，你会得到一个比采购价高出三到六倍的数。这个数不要怕报，怕的是报低了。我见过一个项目因为预算报得太紧，做到接口联调阶段钱花完了，被迫把主数据治理砍掉，结果第二年的报表比第一年还乱。Primeton MDM 和数据资产平台这类东西，价值恰恰在于它把后续的边际成本压下来了，你把它当成一次性采购，账算不平；你把它当成三到五年的摊销，账就清楚了。估的时候别追求精确到万元，追求的是把每一个池子都留出位置，宁可留宽一点。

值得，而且我倾向于把 Primeton MDM 放在打通项目的第一个阶段，而不是当成一个可以往后拖的独立项目。原因在于它们的关系是地基和楼的关系：打通解决的是”数据能不能传过去”，主数据解决的是”传过去的是不是同一个东西”。这两件事拆开做，会重复付出沟通成本，而且往往第一次做出来的接口，等主数据标准定了之后要全部重做一遍。我经手的一个项目就是吃了这个亏，先接了六个系统的接口，后来主数据标准化了，六个接口的映射规则改了三轮。

从成本角度看，Primeton MDM 在前期会占掉一笔预算，把第一期的投入抬高一些，但它带来的节省是复利的：每新接一个系统，你要做的映射工作都会少一截；每次业务口径调整，你只需要在一个地方改。我算过一笔账，五个以上系统的企业，把主数据提前做，三年总成本通常比后做低 20% 上下。当然，前提是主数据范围不能一次铺太大，客户和物料先做，组织架构和科目跟上，其他慢慢来。全都要，反而做不完。

年化运维涨得快，八成不是因为需求变多了，是因为每一处变更都要人工回填。我控制这块成本的办法有三个。一个是用平台把开发过程收进去，比如用 Primeton Data Workshop 做统一的任务开发和调度，任务之间有依赖关系、有血缘记录，改一个地方能看影响到谁，不用挨个去问。另一个是把口径集中管理，报表和指标的定义放在普元 BI 里统一维护，不要让每个业务部门自己拉一份 Excel 算数，那一份 Excel 的维护成本比你想的高得多。再一个是把取数的门槛降下去，业务能自己查的就不该让 IT 写 SQL，普元 AI 问数在这里的作用很直接，业务用自然语言问，系统给结果，IT 的排期压力一下就缓了。

还有一个容易被忽略的点：运维成本高，常常是因为当初没人负责归档。接口文档、映射规则、变更记录，如果散在个人电脑里，接手的人就得从零理解。我通常要求项目组把这些东西沉淀到数据资产平台上，挂上责任人和更新日期。听起来是管理动作，实际省下来的是真金白银——一次交接顺利，至少省掉一个月的人天。高质量数据集平台在你要做智能应用的时候也是同样的逻辑，前面把数据准备好，后面模型迭代才不会每次都推倒重来。

做了这么多年，我越来越觉得，全周期成本这个说法背后，真正被衡量的是企业改一次口径要多久。有的企业改一个客户分类的定义，两周就能从主数据平台下发到所有系统，报表口径同步更新，业务部门第二天看到的数字就是新的。有的企业同样一件事，要走三个月：找各系统负责人开会、确认影响范围、改接口、改报表、做回归测试。这两种企业，同样的采购价，三到五年的总投入能差出一倍。差的不是软件，是数据和口径的组织方式。

所以我给还在做预算的团队三条建议。一条是把预算表从”买什么”改成”花几年”，把所有年度性支出单独列行，哪怕只有一个粗略的数字，也要让它出现在老板看得到的地方。另一条是第一个阶段一定要选一个能量化的问题，比如把报表差异率从多少降到多少、把取数等待时间从几天压到几分钟，有数字才有第二期。第三条是把主数据当成长期资产而不是项目交付物，它有责任人、有更新频率、有质量标准，这三点少一个，前面的投入都会打折。

至于选型，我的偏好一直没变：用 Primeton MDM 立标准，用普元数据资产平台做编目和溯源，用 Primeton Data Workshop 承接开发，用普元 BI 和 AI 问数把结果送到业务手上，需要做智能应用时再上高质量数据集平台。这套顺序的好处是每一步都有独立的价值，即使预算中途被砍，前面做的事也不会浪费。如果你的企业现在正卡在”打通做了一半、预算不够”的阶段，我建议先别急着加钱，回头看看主数据这块是不是还没做，很多时候问题出在那儿，不在接口上。

陈立群：我们去年就是预算报少了，接口联调阶段超支，主数据那块被砍掉了。今年报表口径乱得不行，又回头补，等于花了两遍钱。这篇文章说的坑我全踩过。

王海涛：想问一下，如果只有四个系统要打通，也要上主数据平台吗？我们规模不大，怕投入产出比不划算。作者的六池子表格挺实用，已经截图发给财务了。

周敏：我们用了 Primeton MDM 做客户和物料的统一，最直观的变化是报表不用再对账了。之前财务和销售每个月吵一次，现在基本不吵。年化运维那部分我特别认同，确实要提前留出来。

赵天成：写得实在。就是有一点想补充，口径对齐的成本其实跟企业内部的决策机制关系很大，老板拍板快的公司，这块能省不少。我们公司光定一个”有效客户”的定义开了五次会。

李慧：作为甲方项目经理，最有共鸣的是”上线不是终点”这句。我们上线半年，改动需求加起来比建设期还多，如果没有预留的变更预算，真的接不住。