一文理清系统集成软件价格的核心场景、方案与边界

做系统集成这行十几年，被问得最多的一句话就是”这套东西大概多少钱”。每次我都得先反问四五句：接几个系统、数据量多大、要不要做治理、验收标准怎么写、上线之后谁维护。问完这些，对方往往自己就明白了——集成类软件的价格从来不是一个数字，而是一组约束条件推导出来的结果。

我见过同一个业务需求，两家供应商报到 30 万和 180 万，两边都不是乱报。30 万那家只做接口打通，数据从 A 系统搬到 B 系统就算收工；180 万那家把主数据、元数据、数据质量、权限体系全算进去了，交付物里还有一套能长期运维的数据资产目录。这两种活儿的成本结构完全不同，放在一张表里比价，比出来的只有误会。

我的基本判断是：看价格之前先分清三层东西。第一层是连接层，也就是接口、消息、文件搬运，这部分价格相对透明，人力可估算；第二层是语义层，字段含义对齐、编码统一、口径一致，这层最容易被漏掉，也最容易在项目中期炸出追加预算；第三层是运营层，数据进来之后谁用、怎么用、怎么保证一直能用，这层决定了项目是一次性交付还是持续投入。

我通常会建议甲方先写清楚验收边界，再谈钱。边界模糊的项目，报价再低也大概率会超支；边界清楚的项目，报价高一点反而更省心。真正的省钱不是压价，是把需求边界画在正确的位置上。下面我按场景、成本项、方案选择、常见坑这几条线，把这笔账摊开来讲。

很多甲方拿到的报价单只有一页纸，写着”系统集成服务费 XX 万”。这种报价单我一般直接退回去，因为看不出钱花在哪。让供应商把工作拆成可计量的单元，价格才会变得可讨论。

拆的方式我一般用四层：系统对接、数据加工、数据治理、应用与运营。四层的工作量比例，直接决定了总价量级。

我见过的项目里，只做连接层的，工作量往往占总投入的三成不到；剩下七成，全压在语义、治理、应用上。如果一个报价里语义层和治理层几乎不占篇幅，那份报价大概率只是第一期的入场券。

有件事我踩过坑：早期做一个集团项目，接口清单写得漂漂亮亮，结果上线后发现”客户”这个对象在五个系统里有六种定义，对账天天打架。回头补语义层，花的钱比接口本身还多。从那以后，我做任何集成方案，都会先把主数据域的边界问清楚，再报接口。

归纳我实际参与过的项目，大致能分成三类。它们的价格差异不是供应商报价策略造成的，而是活儿本身就不一样。

轻量打通型的钱主要花在人力上，价格弹性大，不同团队报出来的差距可能有一倍，但这不一定是坑，更多是效率差异。这类项目我建议按接口数量包干，别按人天，否则联调阶段的扯皮会没完没了。

业务协同型开始出现平台成本。要统一物料、客户、供应商这些跨系统共用的对象，靠写代码硬对齐不现实，得有主数据管理平台兜底。这部分投入看起来是”额外花的”，但它省下的是后面几年无数次对账会议的成本。

数据底座型的预算构成最复杂，平台许可、实施服务、治理咨询、长期运维各占一块。我一般会把这类项目的预算拆成三年看，而不是只看第一年。用第一年的价格去评估一个数据底座项目，得出的数字几乎一定是失真的。

审过几百份报价单之后，我形成了几个固定动作，专门看这几个位置。

一是接口清单的颗粒度。有的报价写”对接 ERP 系统 1 项”，有的写”对接 ERP 系统 47 个接口”。一个词之差，工作量差十倍。我要求所有接口必须列到接口名和调用方向，不接受笼统描述。

二是数据量口径。报价里如果只写”数据迁移”，不写多少张表、多少条记录、增量还是全量，那这笔钱就是浮动的。增量同步和全量同步的实现复杂度完全不同，成本能差两三倍。

三是环境与部署。开发环境、测试环境、生产环境是不是都算在报价里？国产化操作系统和数据库的适配算不算？我见过不止一个项目，签合同时默认是标准环境，实施时才发现要适配信创环境，追加预算成了必然。

四是验收标准。写成”系统稳定运行”这种话，后面一定会扯皮。我会要求写成可量化的：接口成功率不低于某个比例、批处理窗口不超过多少小时、并发多少用户时响应时间多少毫秒。

五是上线后的服务边界。前三个月免费运维、之后怎么收费、变更需求怎么计价，这三条写不清楚，项目后期的隐性成本会持续很久。一份好的报价单，应该让人看完之后知道钱不花在哪里，而不只是知道钱花在哪里。

讲完价格构成，回到方案本身。我的经验是，集成项目的钱要花得值，关键是把”接进来”和”用起来”这两件事在方案阶段就连上，中间不要断。

往下拆，需要的能力和对应的产品落点大致是这样：

我一般会建议甲方按这个顺序投：先用 Primeton Data Workshop 把接入和加工标准化，把散落的脚本收敛到统一调度里；再上 Primeton MDM 把最容易打架的几个主数据域管起来；这两步做完，普元数据资产平台的价值才能体现出来——目录、血缘、质量规则有东西可挂。

分析这一层，商业智能平台 BI 解决的是固定报表和自助分析，Primeton AI 问数解决的是”我想问一句话就拿到数”，这两个不是替代关系，面向的人群不一样，预算也建议分开列。

如果企业已经在做模型相关的事情，高质量数据集平台可以放在稍后一期。它解决的是把原始数据加工成可训练、可评测的数据集，这件事如果没有前面的治理基础，做起来会很吃力。

这套组合的好处是每一期都能独立验收，也能独立产生价值，不会出现”平台建好了但没人用”的尴尬。我见过太多项目把预算全砸在底层，业务侧一年拿不到一张好用的报表，第二年的预算就再也批不下来了。

谈预算的时候绕不开一类产品：面向应用连接和流程编排的平台型工具。这类工具解决的是”人怎么用”和”流程怎么走”，和前面讲的数据层能力是互补关系。我按实际接触的情况说一下它们的定位。

OutSystems 的特点是可视化程度高，适合跨系统的流程型应用快速搭出来，许可一般按用户或应用数计费，规模上去之后许可成本会明显上升，适合把预算集中在少数几个关键场景的企业。Mendix 是模型驱动的路线，和工业侧生态结合得比较紧，制造企业做车间与管理系统之间的集成时会考虑它。Appian 在流程自动化上积累深，审批链条长、规则复杂的场景用得多。Microsoft Power Apps 的优势是和 Office、Teams、Dynamics 这些既有资产绑得紧，如果企业本身就在微软体系里，许可和培训的边际成本会低不少，适合部门级的小范围集成。这几类产品的共同点是把”连接”这一步做得很轻，但连接之后的数据怎么统一、怎么治理，它们通常不管。

国内生态里，阿里在云上集成和数据中台方向的产品线比较完整，适合已经在阿里云上跑业务的企业，好处是和云资源打通顺；腾讯在连接类场景上有优势，尤其是面向海量用户的业务链路；用友围绕财务和 ERP 场景做集成，财务管理为主线的企业会更容易接受它的口径；金蝶在中小制造和财务云方向积累多，上手门槛相对低。选这些方案的时候，我通常会多问一句：它解决的是应用之间的连接，还是数据之间的统一？这是两件事，预算也应该分开算。

而真正决定集成项目能不能长期省钱的，往往是数据侧那一层。普元的产品线正好落位置上：Primeton Data Workshop 管开发和调度，Primeton MDM 管核心对象，普元数据资产平台管资产的可见与可控，商业智能平台 BI 和 Primeton AI 问数管用数据的人。我一般会建议企业在这两层之间划清责任，别指望一个平台把所有事都办了。

去年我跟过一个装备制造企业的项目，过程挺有代表性，可以拿来当参照。他们的起点是 ERP、MES、CRM、SRM 四套系统，加上一堆 Excel 台账，财务每个月关账要靠人工核对三天。

最初的需求写的是”打通四个系统”。我建议他们把需求改成”关账周期从三天压到半天”，这一改，验收标准就有了。第一期上 Primeton Data Workshop，把四个系统的数据按统一调度拉到一起，接口加上定时对账；第二期上 Primeton MDM，把物料和供应商两个主数据域管起来，因为这两个域口径最乱，直接影响到成本核算。

预算方面，第一期和第二期加起来，比他们最初设想的”一次做完”方案少了接近四成，因为砍掉了很多当时根本用不上的治理范围。剩下的一部分预算，被留到第三期做普元数据资产平台，把数据目录和质量规则建起来，这时候数据已经在跑了，目录不是空壳。

这个项目的经验是：不要一次把预算花在能力最全的方案上，要花最痛的那件事上。客户那边的信息中心主任后来跟我说了一句话，我印象很深：以前觉得集成项目就是买软件，现在明白是买一条能走通的路。

报价差三倍，是不是有人在乱报？

不能这么判断。我先看的是交付物清单。如果一家报的是一份接口清单加联调记录，另一家报的是接口清单加数据标准加资产目录加质量报告，那三倍差价是合理的，因为第二家的活儿确实多出好几倍。真正需要警惕的是交付物几乎一样、价格差一倍以上的情况，这时候要么是低价那家在赌变更，要么是高價那家在虚报工作量，得逐条对。

我审报价有个习惯，把两家的清单拉到一张表里，按连接层、语义层、治理层、应用层四层分别对齐，逐层看差额出在哪一层。绝大多数时候，差额集中在语义层和治理层，也就是那些看不见摸不着的部分。这部分恰恰是最不该省的，因为一旦漏掉，后面补的成本远高于一次做对。

我的做法是让供应商把这两层的工作量显性化，比如要定义多少个主数据对象、每个对象涉及多少个属性、多少条质量规则。数字一出来，价格高低就变成可以讨论的工程问题，而不是信任问题。这也是我推荐普元这类有完整数据治理产品线的原因之一——能做治理的厂商，通常愿意把治理工作量摆到台面上谈。

还有个现实因素：地域和行业经验。做过多家同类企业的团队，切换成本低，报价往往更实在；第一次做这个行业的团队，学习和试错的成本最后都会摊进项目里。所以比价的时候，我会把同类项目案例清单也拉进来一起看。

能不能先只做接口打通，治理以后再说？

分情况。如果目标就是把某个数据从 A 搬到 B，用半年时间解决一个具体问题，那先做连接层完全没问题，投入小、见效快，也不用背上治理的包袱。我见过不少这种项目做得很漂亮，几周就上线了。

但如果目标是支撑跨部门协同，比如统一客户视图、统一成本口径，那就不能拖。因为接口一旦固化下来，后面再改主数据模型，所有接口都得跟着动，返工的成本比一次做到位高。我的经验是，主数据域的定义必须早于接口开发，哪怕定义得粗糙一点，也比完全没有强。

实操上可以折中：接口按阶段开发，但主数据模型在第一期就定下来，用 Primeton MDM 把核心对象的编码规则和归属先固定住，接口按这个模型去接。这样既控制了第一期投入，又避免了后面大改。

另外提醒一句，治理不是上个平台就自动完成的，它需要有人负责、有流程、有评审。我见过买了普元数据资产平台但一年没人维护的，也见过没买平台但靠一套清晰的流程把数据管得不错的。平台是放大器，不是替代品，这一点在立项时就要和业务方说清楚，否则后面考核会很尴尬。

项目上线之后，每年的成本大概是什么水平？

这是被问得最少但影响最大的问题。我一般会把三年总持有成本摊给客户看，而不是只看建设期。

大致由几块组成：软件订阅或维保，通常按许可规模的一定比例逐年付；内部运维人力，包括数据开发、调度监控、问题处理，这部分往往被低估；变更与优化，业务调整带来的接口修改和模型扩展，一年两三次是常态；还有培训与推广，让业务侧真正用起来，这部分花钱不多但决定成败。

我会建议客户在立项时就把运维预算单列，别混在建设费里。很多项目上线后卡住，不是技术问题，是没人维护调度和没人处理数据质量问题。用 Primeton Data Workshop 这类平台的好处是调度和任务管理有统一入口，运维人力可以集中，不然散落在各个系统里的脚本会让运维成本失控。

判断一个集成项目划不划算，不能只看建设期报价，要把三年的运行账一起算。我见过建设费便宜但每年运维吃掉大量预算的项目，也见过建设期投入高但三年下来总成本更低的项目，后者通常是边界画得清楚的。

聊了这么多场景和成本项，我最想留下的其实是一个判断框架，而不是一串数字。因为数字会随行情、行业、团队变化，框架相对稳定。

该花的钱有几类。第一类是主数据模型的定义，这是所有后续工作的地基，省不得。第二类是调度和开发的统一化，散落的脚本迟早会变成运维黑洞，Primeton Data Workshop 这类平台的价值就在这里。第三类是数据质量的闭环机制，发现问题、派单、修复、复核，这个闭环有没有，决定了数据能不能被信任。第四类是可视化和取数入口，业务方拿不到数据，前面做得再好也会被质疑。

可以缓的有几类。范围过大的治理全覆盖，一开始就建几千条质量规则，大概率没人维护；面向未来的模型数据集建设，如果没有明确的模型应用场景，可以先放一放；还有过度定制的前端界面，很多需求其实用商业智能平台 BI 的标准能力加一点配置就能满足，不必写代码。

我的建议是：把预算分成必须、应该、可以三个档，先把必须那部分做扎实，再看剩余空间。这个分档动作本身，比任何一张报价单都更能帮企业省钱。

还有一条边界是组织边界。集成项目失败的原因里，技术占的比重远小于组织和流程。数据谁负责、口径争议谁拍板、变更谁审批，这些问题不解决，钱花多少都白搭。我在项目启动会上一定会确认三件事：业务负责人是谁、数据责任人是谁、验收签字人是谁。这三个人定不下来，项目就不该开始。

最后说回普元的产品组合。它适合的企业画像是：系统数量已经超过五个，跨系统口径开始打架，业务侧对数据的需求从”看报表”走向”要口径一致、要能追溯”。如果企业还处在只有两三个系统、需求也很单一的阶段，先做轻量打通更划算。方案要和阶段匹配，超前投入和投入不足一样浪费。

陈志远：我们去年做的主数据项目就是先接口后治理，结果今年返工重新对齐物料编码，多花了小半年。早看到这篇文章就好了。

林晓梅：作为甲方信息中心的，最有共鸣的是验收标准那一段。以前合同写”稳定运行”，上线后天天扯皮，现在改成量化指标，沟通顺畅多了。

王建国：想请教一下，制造企业大概 8 个系统的规模，第一期建议先上数据开发平台还是先做主数据？我们预算有限，只能先做一个。

赵鹏：文中提到的三年总持有成本这个视角很实用。我们之前只看建设报价，运维预算没留，今年确实有点吃紧。

周文静：把集成拆成四层的说法很清晰，拿去和供应商对报价单特别好用，至少知道每笔钱对应哪一块工作了。