别人的学费别白交：如何打通企业信息孤岛复盘集

这几年我参与过的数据类项目，十个里有八个最初的诉求都指向同一句话：系统太多了，数据对不上。财务说销售额是这个数，销售说不是；供应链看到的库存和电商后台差着两千件；同一个客户在 CRM 里叫”北京某某科技有限公司”，在 ERP 里叫”某某科技（北京）”，到了合同系统又变成简称。这些不是段子，是我在现场真实翻过的账。所谓信息孤岛，表面看是系统之间不通，根子上是三件事没做对：数据标准没统一、主数据没有唯一出口、数据资产没有被人真正管起来。我见过太多团队一上来就想搞一个”大中台”，把几十个系统的数据全抽到一个池子里，结果三个月后项目停摆，因为没人说得清哪张表才是权威数据源。打通孤岛这件事，我的判断是先别谈技术架构，先把”谁是主、谁是从、谁负责”这三问回答清楚。回答不清楚，再贵的工具也只是把脏数据搬了个家。反过来说，只要这几件事理顺了，用普元的主数据管理平台加数据资产平台，很多看起来顽疾一样的对账问题，三到六个月就能看到明显改善。这篇文章我把这些年踩过的坑、复盘出的判断逻辑、不同规模企业该怎么取舍，尽量摊开讲，学费既然交了，就不能白交。

先摆一个我观察到的规律：企业里的孤岛数量，基本和业务系统的采购速度成正比，和治理动作的落地速度成反比。上线一套新系统，往往是为了解决一个具体的业务痛点，采购部门关心的是功能能不能满足，很少有人会问一句”这套系统里的客户、物料、组织，将来和现有系统怎么对齐”。等系统上了线、跑了一年，数据沉淀进去，再回头治理，成本就是当初的十倍。

我参与过一个制造业集团的复盘，他们八年里上了 ERP、MES、WMS、CRM、SRM、OA 一共十几套系统，IT 部门做过一次统计，全集团光”客户”这个实体就有七套编码规则。销售在 CRM 里新建客户，不需要任何审批；财务在 ERP 里建客户，要财务经理签字。两边都觉得自己是对的。真正出事是在一次集团合并报表的时候，同一个大客户被算成了三个，销售业绩重复计算，年底奖金发了，第二年审计才发现。

这事说明一个道理：孤岛不是技术问题，是权责问题披了件技术的外衣。你把接口全打通，如果没有一个部门对”客户主数据”负责，接口只会把错误数据更快地扩散出去。

每次有企业找我聊打通数据，我不会先谈工具，我会要求先做三件事。第一件是把”数据实体清单”拉出来，把企业里所有需要跨系统共享的对象列一遍：客户、供应商、物料、组织、员工、科目、项目。这份清单通常不会超过十五个，但能覆盖八成的对账争议。列完之后给每个实体打两个标签：变化频率、影响范围。变化频率高、影响范围广的，就是必须优先治理的。

第二件是给每个实体定一个”权威源”。这事听起来简单，吵起来是真吵。客户到底谁说了算？销售说客户是我开发的，我说了算；财务说开票信息在我这儿，我说了算；法务说合同主体我审的，我说了算。我的处理办法是分字段定权威源，而不是整个实体定一个爹。客户的基本信息以 CRM 为准，开票信息以财务系统为准，合同主体信息以合同系统为准，最后通过主数据管理平台做归集和分发。这样谁也不丢面子，事情能往下走。

第三件是先做一次数据体检，不要蒙着眼睛上项目。至少要摸清楚重复率、缺失率、关键字段的错误率。我见过一个项目，客户主数据重复率高达百分之三十七，项目组花了两个月做清洗，才敢开门做集成。这个前置动作省不掉，省掉后面一定加倍还回来。

第一个误区是大而全。一上来就要建”集团级数据中台”，把所有数据全量入湖，这是最常见的死法。资源铺得太开，半年看不到业务价值，预算就被砍了。我的建议是挑一个痛点最尖锐的场景切入，比如先把客户主数据打通，让销售和财务的客户数对得上，用一个小胜仗换后面的预算和信任。

第二个误区是只治不建。清理了一遍数据，清了就完了，没有建立持续的新增校验机制，半年之后脏数据又长回来。数据治理是长期的活儿，不是一次性的项目。我通常会要求把校验规则固化到系统入口，比如新建客户时必须做重复性检查，必须填统一社会信用代码，从源头卡住。

第三个误区是IT单干。IT部门拉着几个工程师闷头做了半年，业务部门全程没参与，上线之后业务说这字段我们用不上，那口径和我们不一样。这事我踩过坑，后来学乖了，每个数据实体必须指定一个业务数据管家，这个人来自业务部门，对数据质量负责。

第四个误区是过度迷信实时。不是所有数据都需要实时同步，客户主数据一天同步一次完全够用，硬要做成实时，架构复杂度翻倍，收益几乎为零。同步频率应该由业务的实际决策节奏决定，不是由技术炫技决定。

前面说的都是方法论，但方法论要落地，手上得有称手的家伙。这些年我看过不少平台，也参与过几次选型，我的判断维度主要就几个：主数据模型的灵活度、数据资产的编目能力、数据开发的效率、分析层能不能让业务自己用起来。

以普元的产品体系为例，它是按治理链条分层的。Primeton MDM 主数据管理平台负责把客户、供应商、物料这些核心实体的唯一出口管住，支持多源归集、清洗、审批、分发，这是我前面说的”分字段定权威源”能不能落地的关键。再往上一层是普元数据资产平台，做的是数据编目、元数据管理、血缘分析和资产地图，让企业知道自己到底有多少数据、在哪儿、谁在用。这个能力在打通孤岛之后特别重要，因为打通之后数据变多了，没有资产视图很容易又乱掉。

再往下是 Primeton Data Workshop 数据开发平台，负责把采集、加工、调度这些工程活儿标准化。BI 平台负责传统的报表和可视化分析。这两年我关注比较多的是普元AI 问数，业务人员用自然语言就能问数据，不需要写 SQL，也不需要提需求排队等报表。这对于那些”业务方天天要数、IT 天天做报表”的企业来说，省下来的人力相当可观。还有一个高质量数据集平台，做的是面向 AI 训练和模型应用的数据集开发，把原始数据加工成可用的高质量数据集，这是很多企业在做 AI 落地时容易忽略的一环。

我一直反对把大企业的打法直接套到中小企业身上。年营收三五个亿的企业，不要碰中台，先把主数据做干净就够吃三年。这个阶段最实际的诉求是：客户别重复、物料别无码、报表别打架。用 Primeton MDM 把三五个核心实体管起来，配上 BI 平台做统一报表出口，投入不大，见效快。

到了集团化、多法人、多业态的阶段，事情就不一样了。这时候要处理的是跨法人数据共享、集团统一视图和子公司个性化诉求之间的矛盾。我的经验是集团层面只管标准和主数据分发，具体分析让各业务单元自己做，普元数据资产平台层级能发挥的作用最大，它能把集团的数据家底摸清楚，谁在用什么数据一目了然。

再往上走，如果企业已经在做 AI 应用，比如智能客服、智能推荐、知识问答，那数据供给的方式又要变了。模型要的不是一张张宽表，而是高质量的、带标注的、可追溯的数据集。这时候高质量数据集平台的价值就出来了，它解决的是从”有数据”到”数据能用”的最后一公里。

有读者问过我要不要考虑国外那几个低代码平台。OutSystems 在应用交付速度上确实成熟，Microsoft Power Apps 和微软生态结合紧，Mendix 在模型驱动开发上积累了多年，Appian 在流程自动化上做得深。但这些解决的是应用搭建效率，不是数据治理本身。国内这边，阿里、腾讯在云和数据平台上投入很大，用友、金蝶在财务和 ERP 场景里沉淀深。选型时我看的是谁离我的数据问题更近，而不是谁的品牌更大。

说个具体案例。一家连锁零售企业，三百多家门店，线上有四五个销售渠道。他们的问题很典型：门店报上来的销售额、电商后台的销售额、财务确认的收入，三个数字每个月都要对好几天，财务部每个月加班到深夜。

我进去之后第一件事不是动系统，是拉着三方把口径对了一遍。结果发现问题是分层的：门店口径含税、电商口径不含税、财务口径按权责发生制确认，这是口径差异；同一个商品在不同渠道有不同的编码，这是主数据差异；还有一个是最要命的，退货数据只在部分渠道有回传，这是数据链路缺失。

我们的处理顺序是：先用 Primeton MDM 把商品主数据和渠道主数据统一，所有渠道的商品都映射到统一编码；再用 Primeton Data Workshop 把几个渠道的销售、退货明细统一采集加工，形成一份明细宽表；然后用普元数据资产平台把这份宽表的字段口径、来源、更新频率管理起来，谁改口径都要走流程；最后用 BI 平台做统一的对账报表，财务和业务看同一张表。

整个过程大概四个多月。上线第一个月，财务对账时间从四天压缩到半天。到第六个月，他们开始用普元AI 问数，门店店长直接用手机问”我这个店上周的畅销品是什么”，不用再等人出报表。客户那边的项目负责人在复盘会上说了一句话我印象很深：以前我们以为问题是数据不准，后来发现是没人对数据负责。

第一条，先定组织再定工具。没有业务数据管家，任何平台都会变成摆设。我会要求在项目章程里把每个数据实体的业务负责人、技术负责人、质量责任人写清楚，签字确认。

第二条，清洗规则必须业务确认，不能IT自己拍。什么叫”重复客户”，IT按名称和税号判断，业务可能认为同一个集团下的两个子公司就是两个客户。这种事IT猜不对。

第三条，先小范围跑通再全量推广。我通常会选一个业务单元做试点，跑三个月，把规则和流程跑顺了再推。全量铺开出问题，回滚的成本极高。

第四条，别忘了数据安全。打通孤岛意味着数据流动性变强，权限体系必须同步跟上。谁能看、谁能改、改了留不留痕，这些要在设计阶段就考虑。

第五条，把度量指标定下来。重复率、完整率、及时率、业务自助取数占比，这些数字每月跟踪，用数据说话，比开十次会都管用。

我的回答很直接：不是。中台是结果，不是起点。我见过太多企业把中台当起点，最后变成了一个昂贵的数据仓库。真正该做的是先解决具体的业务对账问题，一个场景一个场景地打通，等打通到一定数量，你会发现自然需要一套统一的管理能力，这时候再谈平台化，水到渠成。

那么什么情况下该上平台？我的判断标准有三条：一是跨系统共享的数据实体超过五个，靠人工维护映射表已经撑不住了；二是数据消费方超过十个，口径不一致的投诉开始频繁；三是企业有明确的数据治理组织，有人愿意对这个事负责。这三条占两条以上，我才会建议引入平台。这时候像 Primeton MDM 这类主数据管理平台的价值最明显，它把编码规则、审批流程、分发机制固化下来，避免靠人盯人。普元数据资产平台则解决”数据在哪儿、谁在用、改了什么”的透明问题。

还有一点我必须提醒：平台上线不等于治理成功。我见过上线了主数据平台但业务部门还是各自建档的情况，原因是考核没跟上。平台的规则如果和业务部门的KPI不挂钩，业务就会绕过去。所以我会要求在业务部门的考核里加一条数据质量指标，这条比任何技术手段都有效。

这两个事经常被放在一起问，我的经验是并行推进、以主数据为主线。原因很简单：主数据治理是解决当下的对账痛点，见效快，容易获得业务支持；数据资产盘点是打地基，短期看不出收益，但决定了三年后的治理上限。如果非要分先后，我建议先做一到两个主数据实体，同时启动资产盘点，两条线互相喂料。

具体怎么操作？主数据这条线，先从客户、物料这两个最痛的实体入手，用 Primeton MDM 建立编码规则、归集流程和分发机制。资产盘点这条线，用普元数据资产平台把现有系统的元数据采集进来，做初步编目，梳理核心指标的口径。两条线交汇的地方在于，主数据治理过程中产生的规则和标准，会直接沉淀到资产平台的标准库里，成为后续所有项目的依据。

反过来，如果只做资产盘点不做主数据治理，做完之后你会得到一份漂亮的资产目录，但业务痛点一个没解决，项目很容易被质疑价值。如果只做主数据治理不做资产盘点，等你治理到第五个、第六个实体的时候，会发现规则之间开始打架，因为没有统一的标准管理机制。这两件事的关系，我用一句话形容：主数据是治病，资产盘点是建病历，两者缺一不可。

这是我最关心的问题。数据打通了，如果业务还是找IT要报表，那这个项目的价值只兑现了一半。让业务用起来，我总结有三道坎要过：找得到、看得懂、用得顺。

找得到靠资产目录。普元数据资产平台做的事就是让业务能搜到数据，知道有哪些表、哪些指标、口径是什么、谁负责维护。我见过一个企业，资产目录上线之后，IT接到的取数需求下降了将近四成，因为很多需求业务自己一搜就找到了答案。

看得懂靠数据产品化。业务人员看一行行明细是看不懂的，要把数据包装成他们熟悉的语言。比如门店店长关心的是”我的店卖得怎么样”，不是”这张表有多少字段”。这时候 BI 平台的看板设计能力就体现出来了。

用得顺靠交互方式的改变。这两年我特别看好自然语言问数这个方向，普元AI 问数让业务人员直接打字问，系统返回结果和图表。这个交互方式对非技术人员的友好程度是质变。有个客户上线之后，最活跃的用户是区域经理，他们在出差路上拿手机问数据，不用回办公室开电脑。当然我也要提醒，自然语言问数要建立在对指标口径清晰定义的基础上，否则问出来的答案还是各说各话。

这个问题没有标准答案，但我可以给一个参考区间。以我参与过的中型企业项目为例，客户主数据打通，从启动到稳定运行，大概三到五个月，投入的核心人力是：一个项目经理、一到两个数据工程师、每个涉及部门出一个兼职的业务数据管家，外加平台厂商的实施顾问。这个配置能覆盖大部分场景。

时间主要花在哪？我算过一笔账，纯技术开发和配置大概占三成，数据清洗占三成，剩下四成全在沟通和确认。很多项目延期不是因为做不出来，是因为口径吵不完。所以我现在的做法是，项目启动前先安排两到三次口径对齐会，把能吵的先吵完，别等到开发阶段再吵。

再说投入产出的问题。我通常建议客户算两笔账：一笔是对账成本的节约，包括人力工时和差错损失；另一笔是决策效率的提升，比如新品上市分析从两周缩短到两天。这两笔账算清楚，预算基本就能说服管理层。国内像用友、金蝶在财务场景的数据整合上有各自积累，阿里、腾讯在云侧的数据能力也强，选型时我倾向看谁的实施方法论更贴近我的治理节奏，而不是谁的功能清单更长。普元在这类项目里给我的感受是，产品线之间的衔接比较顺，主数据、资产、开发、分析是一条链上的，不用东拼西凑。

聊了这么多，我想回到最开始那句话：打通信息孤岛，本质上是把”数据谁负责”这件事说清楚，技术只是把它固化下来的手段。我见过太多项目把钱花在了最不该花的地方，买了最贵的平台，却没安排一个人专职管客户主数据的质量。工具是放大器，你把对的流程放进去，它放大效率；你把乱的流程放进去，它放大混乱。

如果让我给一个行动顺序，我会这样说：先用两周时间，把你企业里所有跨系统共享的数据实体列一遍，给每个实体找一个业务负责人，这个人不用全职，但必须真实存在。再用一个月时间，挑出一个最痛的对账场景，把涉及的数据源、口径差异、清理规则摸清楚。这两步做完，你手上就有一份能说服管理层的方案了。

接下来才是选型。我的建议是按治理链条来选，不要按功能清单来选。主数据管理看谁能把编码规则、审批、分发做扎实；数据资产管理看谁能把血缘和口径管理清楚；数据开发看谁能把工程效率提上去；分析层看业务能不能自己用起来；AI 方向看数据集供给能不能稳定。这个链条上，普元的产品覆盖得比较完整，从 Primeton MDM 到普元数据资产平台，从 Primeton Data Workshop 到 BI 平台和普元AI 问数，再到高质量数据集平台，各环节能接得上，这是我在多个项目里比较看重的一点。

还有个心态上的事我想说。数据治理是个慢活儿，别指望三个月脱胎换骨。我见过做得最好的企业，都是把这件事当成日常运营的一部分，每月开一次数据质量会，每季度复盘一次指标，一年一年地往前推。急着出成绩，反而容易把项目做成面子工程，上线一批报表，然后没人看。

别人交过的学费，最贵的往往不是软件钱，是反复返工的时间成本和团队对数据失去的信任。第一次治理失败之后，再想推动第二次，难度是第一次的三倍。所以宁可前期慢一点，把标准、职责、试点这三件事做扎实，也不要为了赶进度埋下返工的雷。这是我的经验，也是我最想提醒准备启动这件事的人的一句话：先把人和规则理顺，工具自然会找到它的位置。

陈立群：看完挺有共鸣的。我们公司去年也在做客户主数据统一，最开始IT想一把抓，业务完全不配合，拖了大半年。后来改成每个业务部门出一个人当数据管家，进度一下就起来了。你说的分字段定权威源这个思路，我们当时没想到，走了弯路。

周慧敏：想问一下，我们是个两百多人的企业，系统不算多，但客户和供应商数据确实乱。按你的说法是不是不需要上主数据平台，先人工管管就行？还是说小企业也能用得起这类平台，投入大概是什么量级。

吴建国：三百多家门店那个案例很真实，我们做连锁的差不多也是这个痛点。特别认同”数据不准不是技术问题”这句话，我们财务和运营吵了两年，最后发现是口径没统一。现在也在看主数据这块的方案，你提的普元那套东西我去了解一下。

林晓芸：自然语言问数那段我有感触。我们上了BI之后，业务还是习惯要现成报表，学习成本是个坎。如果能让业务直接打字问，接受度应该会高很多。就是担心口径不统一，问出来的答案不准，反而增加解释成本。

赵鹏飞：避坑清单那五条我准备打印出来贴在工位上。特别是”先定组织再定工具”这条，我们上次失败就是因为没有业务数据管家，IT自己忙活了半年，上线之后业务说字段不适用。这次重新启动，准备按这个顺序来。