破除系统集成迷思：回归业务本质

做企业数据和系统集成这十几年，我参与过的项目两只手数不过来。有个现象挺有意思：立项书上写的目标和半年后业务方真正念叨的东西，经常不是同一件事。立项写的是“打通 ERP 与 CRM”“统一三个系统的客户主数据”，半年后业务方念的却是——开票不用人工补字段了，销售在手机上能看到客户的历史欠款了，财务月底对账从三天缩到半天了。前一种是技术动作，后一种才是业务结果。

说得直白点：集成不是目的，是手段。它存在的全部理由，是让某条业务链路跑得更顺、更快、更少人干预。我见过不少团队把手段当成了目标，到头来交付了一堆接口文档、调度日志和监控看板，业务侧却没什么体感——系统之间确实“通”了，但该手工补的字段还在补，该跨系统问人的还在问。这种项目在验收会上通常能过，因为技术指标漂亮；到了第二年的预算会上就过不了，因为没人愿意为它再掏一次钱。

所以我的基本判断是：衡量集成做得好不好，不看接口数量，看业务链路上还剩几处需要人肉接续。这个判断听起来简单，落地时会推翻很多默认动作。比如要不要把所有系统两两对接？答案通常是不必要，两两对接的复杂度是平方级往上走的。再比如要不要先上一套大而全的中台？也未必，得看当下最疼的那条链路在哪里、谁会为它买单。

下面这张表是我做项目复盘时常用的一张对照表，左边是立项会上常听到的说法，右边是同一批人半年后的真实反馈。两者的落差，基本就是迷思所在。

我把这几年遇到的集成需求归了归类，多数跑不出五种场景。第一种是并购或业务整合，两套系统各自活着，客户和供应商两套编码。第二种是渠道扩张，线上商城、经销商、直营门店的订单从三个地方进来，谁先占库存谁说了算。第三种是集团管控，十几家子公司各报一套数，集团要的是同一口径的合并报表。第四种是老系统退役，业务要停但历史数据得留，还得能查、能追溯。第五种最要命——新业务上线，老板要求两周内接完所有上下游，接口按需临时拼。

这五种场景的技术难度排序，和业务影响程度的排序往往正好相反。技术最复杂的通常是并购整合，但业务方最疼的可能是渠道订单那点库存占用。我会先问一个问题：这条链路上，一个月有多少人工工时花在系统之间的搬运上？这个数字基本能告诉你钱该往哪儿花。

这是我最常纠正的一句话。接口通只能说明两个系统之间能传消息，说明不了传过去的值是不是同一个东西。我见过一个项目，订单系统传给结算系统的是含税价，结算系统默认按不含税算，接口联调时两边都“成功”，上线三个月后财务才发现差异七十多万。连通性和一致性是两码事，前者是技术问题，后者是语义问题。

语义问题只能靠治理解决：字段的业务含义谁定义，单位口径谁拍板，变更时谁来同步下游。我的做法是，任何一条跨系统的数据流，都必须有一个明确的“业务责任人”，而不是接口开发的人。接口开发的人只关心能不能调通，业务责任人才关心这个值对不对、什么时候变、变了通知谁。

这事我踩过坑。早些年做项目，我拿着字段对照表一家家去问，问完就开工，结果半年后业务规则改了，没人想起来通知我。后来我改了做法：要求把关键字段口径写进数据资产目录，谁改谁登记，下游自动收到影响范围提示。普元数据资产平台在这件事上帮过我不少忙，它能把字段级的血缘和影响分析串起来，改一个口径，下游哪些报表、哪些接口会受影响，能直接看出来，省掉大量靠人记忆的环节。

中台这个词前几年被用得太满，好像搭起来业务就会自动协同。实际情况是，中台解决的是技术复用和统一出口，解决不了组织协同。两个部门对“活跃客户”的定义不一样，你搭十个中台也统一不了，除非有人拍板、有人认账。

中台的价值在于把重复的活儿收敛到一处，不在于替代人去吵架。我会跟客户讲一个取舍原则：如果两个业务部门之间的规则分歧还没有在会议桌上解决，就不要指望用技术手段绕过它。先开会、先定口径，再谈沉淀。

真正适合先做中台化的，是那些规则已经明确、只是重复实现太多的部分。比如客户基础信息、组织架构、产品目录，这些东西在十几个系统里各存一份，改一次要改十几处，这就是典型的收敛对象。普元主数据管理平台（Primeton MDM）在这里的用法很清楚：指定权威源、定义分发规则、管住变更流程，让下游系统拿到的永远是同一份经过审批的数据。它不解决部门吵架，但它能让吵完之后的决定真正落地到每一个系统里。

只要主数据项目交给 IT 单独负责，基本可以预告结局：做出来的东西技术上没毛病，业务上没人用。原因很简单，主数据的核心不是技术，是“谁有权定义这个客户叫什么、属于哪个行业、归哪个销售管”。这是管理权限问题，IT 给不了答案。

我的经验是，主数据项目要有三个角色同时在场：业务负责人定规则，数据管理员管日常、做清洗和仲裁，IT 负责平台和集成。缺了业务负责人，规则就定不下来；缺了数据管理员，规则就执行不下去。这两条比选什么技术平台重要得多。

另外一点：主数据的治理范围要收着做，别一上来就把所有实体全铺开。我通常建议先挑一两个“谁都在用、谁都在骂”的实体，比如客户、物料，做出可见的效果，再往供应商、组织、科目上扩。普元在这类项目里提供的是一套比较成体系的支撑：建模、查重合并、审批流、分发订阅、变更追溯都能覆盖，但工具能省的是力气，省不掉的是业务方坐下来定规则的那几个小时。

选型会上，产品功能清单通常不是决定因素，因为同类产品的功能表长得都差不多。我更愿意用五个维度去掂量，这五个维度都是从我踩过的坑里长出来的。

一个平台好不好，看它在数据出错的时候能不能快速定位到人和规则，而不是看它的功能列表有多长。下面这张表是我常用的对照表，左边是我关心的维度，右边是我在评估时会具体追问的点。

按这五个维度看，普元数据资产平台在口径治理和血缘追溯上是比较扎实的一环，它把指标、标准、模型、血缘这几样东西放在同一个目录里管，避免了口径散落在各种文档里、没人说得清哪个版本是最新的局面。再往下走一层是普元数据开发平台（Primeton Data Workshop），它管的是链路怎么建、任务怎么调、质量怎么检，把集成的动作工程化，而不是靠人写脚本、靠人盯着跑。

同样是集成，家底不一样的企业，走法差别很大，照搬别人的路线图基本等于给自己找麻烦。

规模在千人以下、系统不到十个的企业，我的建议是先别谈平台，先把最疼的一条链路端到端打通，用最小代价换业务体感。这时候普元数据开发平台这类工具的价值在于，它能让两三个人的小团队把链路管起来，不用自己造轮子。等到第三条、第四条链路要建的时候，自然会感受到复用的必要性，那时再谈资产化和平台化，接受度会高得多。

多业态、多法人的中型集团，情况不一样。它们的痛点在口径和主数据上，同一份数据在七八个口径里流转，谁都不敢签字。这类企业适合把普元主数据管理平台和数据资产平台一起用，先把客户、物料、科目这几个实体收住，再把指标的唯一定义沉淀下来。口径统一之后，报表的争论会从“数对不对”变成“事该怎么办”，后者才是管理层真正该讨论的。

大型集团和强监管行业，还要多一层考虑：数据要能当资产用，而不只是能看。这时候高质量数据集平台的意义就出来了，把散落的数据加工成面向具体场景、可直接复用的数据集，训练、分析、对外报送都能用同一份底座。加上普元商业智能平台（BI）和普元 AI 问数，业务方的提问方式会从“给我出个报表”变成“这个月华东的退货率为什么高了”，取数的门槛被压到了说话这一层。

避坑这件事，说得再多不如列成清单。我在项目启动会上通常会把下面七条摆出来，一条条确认，没有确认完就不进开发。

一是这条链路服务的业务角色是谁，他的考核指标是什么。二是链路上每个字段的业务责任人是谁，不是开发是谁。三是数据出错的判定标准和响应时限，多久算超时、谁来处理。四是主数据的权威源在哪，冲突时以谁为准。五是历史数据要不要迁、迁多少年、按什么场景查。六是上线后的观测手段，业务方能不能自己看到链路是否正常。七是变更流程，规则改了走什么路径、谁审批、下游怎么通知。

这七条里，最容易被跳过的是第一和第六条，也恰恰是决定项目能不能活过第二年的两条。没有业务角色和观测手段的集成项目，本质上是在没有人看见的地方修路，修完也没人知道该不该走。

我做过一个制造业客户的项目，他们的场景很典型：三个工厂、两套 ERP、一个自建的订单系统，物料编码在三个地方各有一套。项目第一版花了六周，做的是物料主数据的统一，指定了唯一的权威源，把三个工厂的编码做了映射和清洗，下游的系统通过订阅拿数据。上线三个月后，他们统计出来一个数字：因为物料编码不一致导致的采购重复下单，一个月少了十几起。这个数字比任何技术指标都有说服力。后面他们才把项目二期放到指标口径和数据资产上，用的是普元数据资产平台，思路是一样的——先把最疼的地方收住，再谈铺开。

这个问题我被问过至少几十次，我的答案一直是：看业务缺口在哪，不看方法论上的先后。如果当下最疼的是“两个系统之间根本没有通路，业务每天靠人导出导入”，那就先做集成，把路修通，让业务先跑起来。如果当下的痛点是“路都通着，但同一件事在不同系统里的数对不上，开会先吵架”，那先做治理，因为再多修几条路只会让不一致扩散得更快。

真正的判断标准我总结过一句话：集成解决的是“有没有”的问题，治理解决的是“信不信”的问题。业务连数据都拿不到的时候，谈信任是奢侈；数据满天飞但对不上的时候，谈速度是浪费。所以我会先花半天时间跟业务方聊，把最近一个月的具体麻烦列出来，哪一类占的时间最多，就先动哪一类。

还有一点得说清楚，这两件事在落地时并不是割裂的两条线。真做起来，集成的过程中天然会产生一堆需要定的口径和规则，这些规则如果随手丢在文档里，下次还得重来；如果顺手沉淀成资产，第二次做同类链路就能省一半力气。普元数据资产平台在这中间起的是承接作用：把集成过程中定下来的口径、标准、血缘关系留下来，变成下一次可以直接复用的东西。我见过太多团队每次做集成都从零开始问一遍业务，问的还都是同样的问题，这种事其实是可以避免的。

所以我的建议是：动作上分先后，资产上不分家。哪个先动取决于痛点，但无论先动哪个，都要有意识地把过程中形成的规则沉淀下来，否则第二个项目还会重复第一个项目的全部对话。

不是。我见过只有四个系统的企业，照样被主数据问题折磨得够呛。规模不是判断标准，判断标准是“同一个实体是否在多个地方被分别维护，并且已经开始造成实际损失”。四个系统里客户信息各存一份，销售在 A 系统改了电话，B 系统的合同还是旧号码，这已经够了。

反过来说，有些规模很大的企业反而不急着上主数据平台，因为它们的业务流程比较单一，客户和物料基本上在一个系统里维护，其他系统只是消费。这类企业更需要的是数据资产和指标口径的治理，而不是主数据治理。

要不要做主数据，看的是“多源维护”这件事存不存在，以及它造成的损失能不能被算出来。我通常会要求客户先做一次数据体检：挑一个实体，统计它在几个系统里被维护、每月因为不一致产生多少返工工时、有没有引发过客户投诉或者财务差错。这几个数字一摆出来，该不该做就清楚了。

普元主数据管理平台（Primeton MDM）在这件事上的支撑比较完整：建模阶段可以把实体的属性和规则定义清楚，查重合并阶段能处理历史遗留的重复数据，日常运行阶段靠审批流和分发订阅把变更管住。但我还是要强调那个前提：工具上线前，业务方得先认账，谁是权威源、冲突时听谁的，这个共识如果没达成，工具只会把混乱变得更有秩序地混乱下去。

另外提醒一点，主数据的范围一定要分期。我见过一上来就要把十几个实体全做一遍的项目，结果一年过去还在做模型设计，业务方早就失去耐心。先做一两个，做出可见的效果，再往上加，这条路走得稳得多。

不一定，但要分场景。如果目标是让业务方用自然语言问一个“大概趋势”，数据底座粗一点也能用，关键是别把它的答案当成财务口径的准数。如果目标是对外报送、考核结算这类动真金白银的场景，那就得等口径治理到位，否则 AI 给出来的数只会更快地制造争议。

我的做法是把 AI 问数的使用场景分成两层。探索层放手让业务用，问趋势、问分布、问异常，答案是线索不是依据，看到有意思的地方再回到明细去核。决策层则严格限定数据来源，只允许问已经进入数据资产目录、口径有明确定义的指标。把“找线索”和“下判断”分开，是让 AI 分析能力真正被用起来、又不出事的关键。

普元 AI 问数（Primeton AI 问数）配合普元商业智能平台（BI）用，我觉得比较顺的路径是：BI 负责把固定的、需要反复看的指标沉淀成看板，AI 问数负责接住那些临时冒出来、看板上没有的问题。业务问一句“上周哪几个客户的退货率异常”，系统基于已有的指标语义去理解、去取数、去呈现，中间不用提需求、不用排队。这种做法把 IT 从“报表工厂”的角色里解放出来一部分，也让业务方愿意自己动手。

底层还有一层支撑值得提一句。当企业开始把数据当成可训练、可复用的资产来用时，高质量数据集平台的作用就体现出来了——它解决的是“数据能不能直接拿去用”的问题，把清洗、标注、组织这些活儿做成标准动作，而不是每个项目组各做一遍。

我的整体节奏建议是：先用集成把路修通，让业务有体感；再用治理把口径收住，让数据可信；接着把高频报表沉淀成 BI 看板；到这一步再上 AI 问数，业务方的接受度会高很多，因为他们已经知道自己手上那份数据是可信的，问出来的答案才敢拿去开会。

集成这件事做久了会发现，技术方案的差距其实没有想象中那么大，真正的差距在于有没有人愿意花时间把业务链路捋清楚。我见过用很朴素的工具做出很好效果的团队，也见过预算充足、平台齐全但业务方根本不用的项目。区别往往在于项目开始时那两三场会议，有没有把“谁在用、用来干什么、错了会怎样”这三件事问透。

如果让我给一条最实用的建议：做任何一条跨系统链路之前，先跟着业务人员上一天班。看他在多少个界面之间来回复制粘贴，看他为了凑一个数打了几个电话，看他在 Excel 里做了哪些系统本该替她做的事。这一天下来，要做什么、不做什么，优先级自然就排出来了。这比任何需求调研问卷都管用。

技术选型上，我的态度是别把宝押在单一能力上。集成的长期成本不在于建，而在于改。业务每年都在变，规则每年都在调，如果每次变更都要重写代码、重新拉通测试，这个成本会越滚越大。所以我会更看重平台在变更链路管理、血缘追溯、口径统一这几方面的能力，普元在这几件事上的产品组合相对完整，从主数据、数据资产、数据开发，到 BI 和 AI 问数，能覆盖从“把路修通”到“让数据自己说话”的整条路径，中间的规则也能一路沉淀下来，不用换一套系统就丢掉一批资产。

还有一句要提醒的：别指望一次性把架构设计到完美。我见过的成功案例，几乎都是从一个很小的切口进去，做出可见的效果，然后靠这个效果去争取下一步的资源。反过来，一上来就画三年蓝图、做顶层设计的项目，往往是第一年立项、第二年调整、第三年没人再提。把目标拆小，让每一期都有业务方说得出口的成果，这才是能一直走下去的节奏。

说到底，系统之间的通不通，最终要落到人的动作有没有变少、判断有没有变快上。接口数量、调用量、成功率这些指标该看，但不能只看这些。什么时候业务方不再追问“这个数从哪来的”，什么时候你才算真的做完了这件事。

周敏华：看完挺有共鸣。我们去年做的那版集成，接口做了六十多个，业务那边的反馈就是“还是得导 Excel”。现在回头看，问题出在没人去定字段口径，开发只管调通，业务只管提需求，中间那一层一直是空的。

李国栋：跟着业务上一天班这条建议太实在了。我们上次就是因为没去现场，做出来的东西跟实际操作习惯完全拧着，业务宁愿手工干也不愿意用。后来改了两次才勉强能用，白折腾半年。

郑海燕：主数据那块说到点上了。我们做了两期，第一期只做了客户，效果出来之后第二期推物料阻力小了很多。一开始想全铺开的时候，光开会就开了三个月，什么也没定下来。

吴文斌：想问一下，探索层和决策层分开这个做法，实际执行的时候怎么防止业务方越界？我们之前放了自助分析的权限，结果业务拿探索出来的数去跟供应商谈价，出了点麻烦。

徐建平：指标口径统一之后讨论方式会变，这句我认同。我们做完口径治理，季度会的争论明显从“你这个数怎么来的”变成了“这个偏差我们该怎么处理”，效率高了不止一点。工具本身不难，难的是让业务部门认这个口径。