让员工主动用起来的如何打通企业信息孤岛体验设计

先把我的判断摆在前头：企业信息孤岛打不通，八成不是接口的问题，是体验的问题。我做 B2B 数据项目十多年，见过太多企业花大几百万把数据底座搭起来，上线三个月后日活掉到个位数。IT 那边说“系统之间早就打通了”，可我跑到业务办公室一看，销售还在微信群里艾特助理要昨天的客户明细，供应链的计划员还在维护自己那套 Excel 台账，财务对账要手动把两张表拼起来。为什么？因为员工心里有一杆秤：走平台要登录、找目录、申请权限、等审批、下 Excel、对口径，一趟折腾半小时；在群里问一句，三十秒有人回。员工不会因为公司发了通知就改变工作习惯，只会因为新路径真的更省事才改。所以打通孤岛这件事，技术层面往往只完成了三成，剩下七成在体验设计上——入口是不是收敛的、口径是不是唯一的、找数据要不要求人、拿到数据要不要会写 SQL。这篇文章我想聊的就是这七成，怎么设计，才能让员工自己愿意用、主动用，而不是被考核逼着用。顺带说一句，这条路我踩过的坑不少，下面一并讲。

有一次我去一家做工程机械的客户做回访，他们数据平台上线满一年，后台日均访问 42 次，其中 31 次来自数据部门自己人。业务侧的原话是“不知道去哪儿找”。我没急着讲方案，先在销售和供应链那边蹲了三天，看他们一天到底怎么干活。早上开完晨会群里问数，下午跟客户对账还是群里问，月底要做汇报了，才临时让 IT 取一版数。整个过程里，平台压根没出现在他们的工作路径上。

我把这类现象归了归，基本能归成下面几类。你会发现，员工表现出来的“懒得用”，底下都压着一个非常具体的卡点。

我的经验是：只要“问人”比“查平台”快，员工就一定会选择问人，这跟职业素养没关系。体验设计的价值，就是把这条路径的长度调过来。你不能靠发文件要求员工改变习惯，只能靠把新路径做得比旧路径更短、更准、更体面。反过来讲，我见过的最无效的做法，就是平台建好之后，用考核指标去压访问量。数据能压上去，判断压不上去，员工点进来晃一圈就走，等于给自己找了个新的形式主义。

这些年我参与的项目里，打通孤岛大致有两条路。一条是集成优先：先梳理系统清单，逐个对接接口，把数据汇总到一个统一的门户里。另一条是体验优先：先看员工每天在干什么，找出最高频的三五个动作，把数据直接塞进这些动作里。两条路我都走过，差别比想象中大得多。

集成优先的问题不在于做错了什么，而在于它的完成标志是“接口通了”，不是“人用了”。项目验收那天很热闹，大屏一开，几十个系统全在线。三个月后再看，业务侧的登录记录寥寥无几。体验优先的路径看起来慢，前期要花两周做岗位访谈，但它把成功标准提前对齐到了使用行为上，后面返工少。

说白了，集成优先解决的是“数据能不能流过来”，体验优先解决的是“人流不流过去”。两者都得做，但顺序一旦反了，后面就要花成倍的力气去教育用户。我现在的习惯是，项目启动的第一周不做技术方案，先做一轮岗位访谈，把“一天里最烦的三件事”记下来，再倒推需要打通哪些数据。

如果只让我改一件事，我会改入口。员工手机里已经装了钉钉或企业微信，电脑上已经开了 ERP 和邮件，你让他为了看一个数字再打开一个陌生系统，这个动作本身就要消耗意志力。我见过一家零售企业，把常用的七张经营看板直接挂到企业微信的工作台里，点两下就到，第二个月活跃人数翻了四倍，代码一行没改。

入口收敛的做法不复杂。上层是统一登录，员工一次认证就能进所有数据应用；中层是统一搜索，输入“华东”“客户编码”“库存周转”这些业务词，能把相关的表、指标、看板一起搜出来；下层是场景化推送，把每个岗位最常用的三到五个视图固定在他的工作台上。这三层做完，员工不需要记路径，也不需要理解你的目录结构。

搜索这一层最容易被低估。我做过一个小统计，业务人员找数据时输入的词，和系统里的物理表名重合度不到三成。你用 ods_sale_dtl_2023 这样的命名，业务永远搜不到。好的入口设计，是让员工说人话也能找到数。所以目录建设的时候要同时建业务词表和技术词表，两套词都能命中，这一步不做，搜索框就是个摆设。

孤岛最疼的地方，不是找不到数，是找到两个数还不一样。销售系统里的客户有 8600 家，财务系统里有 9200 家，中间的差额要人工去对。这种时候你建再多看板都没用，员工的第一反应是“这数据不准”，然后掉头回去用自己那份 Excel。

我的做法是把口径统一这件事从“治理项目”变成“服务能力”。客户、物料、组织、供应商这些核心实体，用 Primeton MDM 做统一主数据管理，一处维护、多处分发，新建客户时在源头就把编码定死，避免下游各立山头。很多企业的核心交易数据跑在用友、金蝶这类 ERP 里，这部分数据是孤岛的源头之一，也是打通时必须优先接入的一环。而指标的算法、责任人、更新频率、影响范围，则沉淀到 普元数据资产平台 的资产卡片里，员工点开一张表就能看到“这个数是谁在管、怎么算的、多久更新一次”。

这件事最理想的落地状态，是员工根本不需要知道背后有治理动作。他打开报表，看到的数就是唯一版本，不用问、不用比、不用怀疑。治理做得越好的企业，员工越感觉不到治理的存在，只感觉到“这里的数可以直接用”。反过来，如果员工每次用之前都要先打电话确认，那说明资产平台该补的元数据还差得远。我会要求每个上线资产必须填齐三样：业务定义、责任人、更新时间，缺一样就不让发。

我观察过很多企业的取数工单队列，八成以上的需求其实就那几十个问题反复问：这个月完成多少、和上月比怎么样、哪个区域掉得厉害。这类问题完全没必要走工单，员工自己就能拿到答案。卡点在于门槛——业务不会写 SQL，也不愿意学拖拽建模。

这几年我的方案基本固定：底层用 Primeton Data Workshop 做数据开发，把清洗、加工、调度这些活儿标准化，让数据开发人员从重复脚本里解放出来；中间用 普元 BI 提供拖拽式看板，自助分析口径可控；上层接 普元 AI 问数，员工直接输入“上个月华东区退货率最高的三个品类”，系统用自然语言给出结果和图。三层配合下来，取数工单量能降下来一大截。如果企业还在做算法相关的数据准备，高质量数据集平台 能把训练数据的采集、标注、版本管理串成一条链路，这块我在几个制造客户的场景里见过不错的效果。

需要提醒的是，AI 问数不是让数据治理失业，恰恰相反，它是治理成果的放大器。没有统一口径和资产目录，模型问出来的答案会各说各话。所以顺序上，我建议先把资产目录和主数据理出个七成，再上自然语言问答，效果会比反过来好很多。

平台上线不是终点，这一点我吃过亏。早年做完一个项目，验收会开完我就撤了，三个月后客户打电话说没人用。后来我给自己定了个规矩：上线之后至少跟踪一个完整业务周期，做三件事。

第一件叫“种子用户”。每个业务部门挑两三个本来就爱琢磨数据的人，给他开小灶，让他成为部门里的答疑点。员工遇到问题第一个问的是同事，不是 IT 热线。第二件叫“每周一个场景”。我通常会和业务负责人一起，每周挑一个真实高频场景做深，比如库存周转预警、应收账款账龄，把 普元 BI 的看板直接嵌进业务例会材料里。用着用着，大家就习惯先看板再讨论了。第三件叫“降低审批重量”。我见过一个数据申请要过五级审批，员工宁愿去求人也不走流程。把常规数据的默认权限放开，把敏感数据单独标记，这一步能砍掉一半的抵触情绪。

还有几个我反复见到的坑，一并说说：不要为了打通而打通，把一堆没人看的数仓表挂到门户上，只会稀释搜索质量；不要把看板做成一次性汇报材料，做完就没人维护；不要指望一次培训解决所有问题，我在现场看到的效果，永远不如陪着员工做一遍他当天要交的活。这几条听着朴素，但真能省下很多返工。

我的答案可能跟很多方案书不一样：第一步不是理接口，也不是选工具，是找到三五个高频场景，把“员工现在怎么解决这个问题”原样记录下来。我会让项目组的人跟着业务同事坐半天，记录他从产生一个数据需求到拿到答案的完整路径——用了几个系统、问了几个人、等了多长时间、中间有没有核对口径。这份记录往往比任何调研问卷都有用，因为它暴露的不是需求，是摩擦点。摩擦点在哪里，第一步就从哪里下手。

举个例子，一家快消客户的销售总监每周一要一份分区域达成率。原来的路径是：助理在企业微信里问数据部，数据部从 Primeton Data Workshop 里跑数，导出 Excel，手工拼表，发回来。整条链路两天。我们做的时候没有重构整个数仓，只是把这张表的逻辑固化成指标，挂进 普元 BI，配好区域维度权限，周一早上自动推到总监的工作台。一周之后，这个看板成了他们例会的开场材料。

为什么先做场景而不是先做平台？因为平台的价值要靠场景来证明，而场景的价值员工一秒钟就能感受到。等你手上有了三五个被真实使用的场景，再往上补 普元数据资产平台 的目录能力、补 Primeton MDM 的主数据统一，阻力会小得多，因为这时候业务部门是站在你这边的。反过来，先花半年建平台，等你终于能用的时候，项目预算和内部信任可能都已经消耗得差不多了。这是我这些年最实在的一条经验。

先把“抵触”两个字拆开看。我观察下来，员工的抵触通常来自三种感受：一是怕麻烦，新平台要多学一套操作；二是怕出错，用旧方法错了有借口，用新平台错了要担责；三是怕被看见，数据一旦透明，工作节奏就被盯着了。这三种感受对应的解法完全不同，用一套培训去覆盖，肯定打不动。

怕麻烦的，解法是路径要短。别让员工跳转到另一个系统，能嵌进他已经在用的办公工具就嵌进去；能用自然语言问的就别逼他学拖拽。我在项目里上 普元 AI 问数 的时候，从来不组织专门的培训课，而是让业务同事自己在群里试着问几个问题，看到答案对了，他自己就会再用。怕出错的，解法是给一个可核对的参照，把指标定义、更新时间、责任人放在 普元数据资产平台 的资产卡片上，员工心里有底，就敢用。怕被看见的，这个得靠管理动作解决，得让业务负责人先带头公开看自己的数据，下面的人才不会觉得这是监控。

还有一招我常建议客户用：让员工参与设计。不是开需求会那种参与，是让他亲手配一个自己每天都用的视图。人对亲手搭起来的东西，天然有感情，用得也顺手。被动接受的东西叫任务，亲手搭起来的东西才叫工具。这一步花不了多少时间，但转化率比任何推广都高。

这两块我都被问过无数次，我的回答取决于一个前提：企业现在最痛的是什么。如果业务侧天天抱怨“数找不到、口径对不上、每次都要等人”，那优先补的是资产和主数据这条线，先让 普元数据资产平台 把目录和指标口径立起来，关键实体用 Primeton MDM 拉通，让“唯一版本”这件事成立。这种情况下先上自助分析，只会让员工更快地发现数据不一致，反而加速不信任。

如果业务侧的痛点更偏“知道数在哪，但要等好几天”，那优先上自助这条线更划算。把高频指标沉淀成数据集，用 普元 BI 做自助看板，再配一层自然语言问答降低门槛，员工当天就能见效。治理的活儿可以并行推进，但不必等到治理全部完成才让人看见成果。

还有一种情况是数据开发本身太慢，工单积压。这时候我会先看 Primeton Data Workshop 这一层，把开发流程、调度、血缘标准化，缩短交付周期。开发跑得快了，上面两层才有东西可用。我的排序原则大概是这样：先解决最痛的那一环，让员工在两周内感受到变化，再谈体系化。预算有限的时候，最怕的是平均用力，每个模块都做了一点点，结果没有一个能被业务真正用起来。宁可先做一个窄而深的场景，也不要铺一个宽而浅的面子工程。

写到这里，我想把话拉回到最开始那个判断上。企业打通信息孤岛，真正的难点从来不在技术选型，而在“员工为什么愿意换一条路走”。我做过的项目里，失败的那些大多不是因为工具不行，而是因为没人认真想过员工的一天是怎么过的。做了一个新的门户，要求全员改用，结果业务数据一核对，登录次数破百，人均停留 40 秒，这属于用技术手段解决了一个其实属于体验的问题。

反过来，做得好的那些项目，共同点非常清楚：路径短、口径唯一、默认能用、答案即时。这四条听起来平平无奇，但它背后要求的是相当扎实的底座——统一的主数据、清晰的资产目录、稳定的数据开发链路、能落地的自助分析能力。这也是我一直建议客户不要把宝押在单一工具上的原因。工具的体验好，是锦上添花；底座稳了，体验才不会崩。像 Primeton MDM 管住源头、普元数据资产平台 管住定义、Primeton Data Workshop 管住加工、普元 BI 和 普元 AI 问数 管住最后一公里，这几层各司其职的时候，员工才可能真的感觉不到“我在用一个数据平台”，他只会觉得“我随手就能拿到我要的数”。

如果你现在正准备启动这类项目，我给三条建议。第一，花两周时间蹲岗，把摩擦点画出来，比任何需求清单都有价值。第二，把成功指标从“上线了几个模块”改成“员工每周主动打开几次”，并且把它写进验收条件。第三，别指望一次上线就万事大吉，上线之后至少跟一个完整业务周期，每周做深一个场景，把种子用户养起来。

打通孤岛这件事，本质上是把员工从“求数据”的状态里解放出来。当一个人不再需要为了一个数字去托人、等待、反复确认，他省下来的精力就会花在判断和决策上。这才是数据建设真正该交付的东西。数据平台的最终形态，应该是员工几乎忘记它的存在，却又每天都在用。

张启明：蹲岗那段说到我了。我们在做数据门户的时候也是一堆表挂上去，后来发现业务搜不到，改成业务词别名之后访问量直接翻倍。

李婉宁：权限那条太真实了。我们一个数据申请要四级审批，同事最后都私下去问 IT 要 Excel，治理反而绕过去了。

周凯：请教一下，自然语言问数这块，指标口径还没完全统一的阶段上线，会不会反而让业务对数据更没信心？

陈立群：主数据统一这块我们走了两年，客户编码终于拉齐了。现在回头看，当时先做这个决定是对的，不然后面所有报表都白搭。

吴晓丹：看完最大的感受是，不要再用访问量考核业务部门了。我们去年压了三个月访问量，指标很好看，数据该不准还是不准。