让员工主动用起来的云集成体验设计

我做过也看过不少云集成项目，技术验收单上通常全是绿灯——接口通了、时延达标、成功率 99.9%，可半年后回头看使用日志，日活个位数，剩下的人还在群里要数、在表格里手工对。这事我踩过坑。起初我以为是培训没做到位，连着做了三版操作手册，没人看。后来把几个真实用户拉到会议室，让他们当着我的面把活干一遍，问题一下就露出来了：入口藏在四级菜单里，字段是英文缩写，报错只给一行 HTTP 500，申请一个数据权限要等三天。换成谁都不会主动打开第二次。

我的判断是，云集成的验收线得往前挪一格。不是”接口通了”就算交差，而是”员工在没有任何人催的情况下会主动打开它”才算完。这两条线之间差的不是功能多少，是把集成结果重新组织成业务语言的那道工序。体验设计在我这里不是把界面做漂亮，而是把人、场景、数据、权限、异常这五件事，按一条真实的工作路径重排一遍。我见过太多项目在第三个月停摆，不是技术不行，是没人愿意多走那三步点击。谁能把这五件事理顺，项目才从”上线”变成”用起来”。

早几年做集成，甲方问的第一句是”能不能连上”。现在再聊，问题变成了”业务愿不愿意用”。这个变化挺关键。连得上是工程问题，愿意用是产品问题，两个问题的解法完全不一样。我用一句话概括这个转变：云集成正在从交付工程变成员工每天要打开的工作台。

有个集团客户让我印象很深。他们八条集成链路全通，报表口径也核对过，可财务每月依旧手工导一遍。后来没加任何新接口，只是把集成结果挂到了业务日常处理的页面上，字段换成中文业务名，异常数据直接在列表里标红并给出处理入口。使用率一个月内从 12% 涨到 61%。

我会拿这张表去问项目组：你们现在停在哪一格？大多数回答是”卡在可用期往好用期走”。这一格的跨越，靠的正是体验设计。

项目里最常见的分歧，是交付方和使用方对”成功”的定义不一样。交付方看的是接口调用曲线，使用方看的是自己今天这活干完没有。这两种视角错位，功能做得再全也白搭。

我的经验是，凡是只按左边一列验收的项目，使用率大概率上不去。不是团队不努力，是努力的方向离使用者太远。有一回我接手一个已经上线两次都没推起来的项目，改的东西其实很少：把入口从三级菜单提到首页卡片，把 26 个英文字段换成业务名并加上说明，把权限申请从工单改成按岗位模板自动下发。三周后日活翻了三倍多。技术架构一点没动。

所以我现在评估一个云集成做得好不好，先看右边这一列有没有人负责。很多时候，这个角色在项目组里是缺的。

把原因归到”员工不学习”上最省事，但我基本不信这个解释。我把碰到的场景归了归类，无非就这么几条。

一是找不到。集成结果散在四五个系统里，没人知道哪个是权威来源。二是看不懂。字段是 tech_ord_no 这种命名，业务同事第一眼就放弃了。三是等不起。一个自助取数要走五天审批。四是信不过。同一张报表两个系统两个数，谁对谁错没人说得清。五是不敢错。报错提示只有一串代码，出了事只能找人，出两次错就再也不碰了。

这五条里，只有第三条是流程问题，其余四条都跟体验设计直接相关。国外一些平台在这块有可借鉴的思路，比如 Microsoft Power Apps 主张让业务人员自己拼出能用的应用，把门槛压到非技术人员也能上手；OutSystems 在交互一致性上做得比较细，同一个业务概念在不同页面里的呈现方式基本统一。这些思路本身没问题，落到国内企业，还得跟数据治理和权限体系接上才行，不然做出来的东西好看但不敢用。

我的做法是列一张”放弃点清单”，把用户在真实操作中会中途退出的位置一个个记下来，然后再排序修。这活的收益比新增一个功能高得多。

很多人做云集成体验，习惯从数据出发——有哪些表、能拼出什么、然后设计页面。我会把顺序反一下。

第一步是定人，而且是定到岗位，不是定到部门。”给业务部门用”这句话等于没说，采购专员和采购经理要看的东西完全不同。第二步定场景，我会问一句：”你现在这活是怎么干的？”让对方描述一遍手工流程，包括打开哪张表、抄哪几个字段、发给谁。第三步才定数据，看哪些集成结果能替掉这条手工链路上的哪一环。

这个顺序的最大好处是能砍需求。我见过一个项目，原始需求清单 40 多项，按岗位和场景重新梳理之后，真正要做的核心页面只有 6 个，其余要么没人用，要么挂到已有入口即可。

还有一种情况要提前想清楚：跨云、跨厂商的环境。很多企业的集成链路一头在阿里云上，一头在腾讯云上，还有一部分数据留在用友、金蝶这类 ERP 里。用友的财务和供应链数据、金蝶的财务模块，经常是主数据的源头之一。这种混合环境下，体验最容易碎——员工得记住三四个入口。我的建议是做一个统一的业务视图层，底下的调用路径复杂没关系，员工看到的必须是一件事、一个入口、一套口径。这一层做不做，直接决定使用率的天花板。

把上面这些判断落到工具上，我在项目里更愿意选能力能连成一条线的方案，而不是东拼西凑。普元在这块的组合我比较熟悉，几个产品之间的衔接是顺着员工的使用路径来的。

最底下是 Primeton Data Workshop，负责把关系库、消息、文件、API 这些来源接进来，做清洗、编排、调度。这一步解决的是”连得上”和”跑得稳”。往上，普元数据资产平台把这些任务产出的表变成有目录、有血缘、有口径说明的数据资产，员工看到的不再是一堆表名，而是”供应商主数据””物料库存快照”这类业务说法。

再往上是我最看重的一段。普元 BI 和 Primeton AI 问数把资产变成能直接消费的东西。业务同事想看一眼某个品类的库存周转，用自然语言问一句就出结果，不用提单、不用等排期。这一层做通了，员工主动打开的概率会明显不一样，因为它是”立刻有答案”，而不是”提交需求等两周”。高质量数据集平台则在需要做分析建模、需要一份稳定可复用的数据集时接上，把散落的数据整理成口径固定、可反复调用的形态。

涉及客户、物料、组织这类需要在多个系统间保持一致的数据，Primeton MDM 来收口。主数据不统一，上层做得再顺，员工还是会碰到”两个系统两个数”的老问题，信任一旦崩了，体验设计全白做。

这套组合的价值在于，它把”数据进得来、讲得清、查得到、对得上”四件事放在了一条链路上，员工不用感知底下的复杂度。我在几个项目里按这个思路落地，员工端的日活和自助取数占比都有明显上升。

选型会我开得不少，最没用的问法是”你们功能全不全”。功能清单谁都能列一百条。我会换成下面这张表，逐项问具体场景，让对方拿案例说话。

这六项里，我最舍不得妥协的是自助消费和权限两项。前者决定员工会不会主动来，后者决定他敢不敢用。接入广度差一点，可以后续补；这两项不行，前期看着热闹，三个月后就冷了。

另外我还会问一个问题：你们的实施方法论里，有没有专门做使用率跟踪的环节？回答含糊的，我基本会打个问号。

说三个真实场景。第一个是制造企业，供应链部门原来天天导出 Excel 对库存。我们用普元数据资产平台把库存、在途、订单三类数据归到统一目录下，再用普元 BI 配了三张固定看板，只有三个入口。上线两个月，手工导出量掉了一大半。

第二个踩了坑。当时我图快，把两个业务域的权限合成一个角色，看着省事，结果销售能看到采购成本，第二周就被投诉，项目停了半个月。教训是权限千万别图省事，按岗位模板走，宁多几个角色，也别混着来。

第三个是数据口径问题。财务和业务各有一套客户编码，报表出来两边对不上。引入 Primeton MDM 把客户主数据统一之后，这个问题才从根上没了。这个项目让我确认了一件事：体验再好，也盖不住数据本身不可信。

顺带说一句，Primeton AI 问数是在一个零售客户那边用的。他们的运营同事习惯了问人，刚开始对”问系统”不感冒。我们没做培训，只是把问数的入口放在他们每天都要打开的页面右上角，两周后提问量自己就上来了。这个例子说明，入口位置有时候比功能本身还重要。

我的答案是从”放弃点清单”开始，不是从原型图开始。具体做法是找三到五个真实岗位的员工，让他们在你现有的系统里把日常活干一遍，你在旁边只做一件事：记录他停下来的位置。停下来可能是找不到入口，可能是字段看不懂，可能是等权限，也可能是看到数字不对在犹豫。这些停下来的点，才是优先级最高的改造清单。

很多人一上手就画页面，画完发现改的不是关键路径。我见过一个项目，团队花两个月重做了首页视觉，日活没动，因为用户真正的堵点在权限审批。反过来，先做放弃点清单，往往改两三个点就能看到曲线变化，投入产出比高得多。

清单排完序，我一般按”影响人数 × 退出概率 × 修复成本”三个因素来定顺序。影响人数多、退出概率高、修复成本低的先做，比如字段改中文名、入口提到首页，这类事情一两天就能改完，收益立竿见影。权限和口径这类修复成本高的往后放，但必须排进计划，不能一直挂着。

还有一点要提醒：这件事得有人长期负责。体验设计不是一次性的上线动作，是跟着使用数据持续迭代的。我在项目里通常会要求留一个看得懂数据又懂业务的人，每周看一次活跃和自助取数数据，看到掉就查原因。这个角色不需要多高的职级，但必须固定。没有这个人，再好的设计三个月后也会退化。普元的产品在这方面的好处是，使用行为、资产访问、问数记录这些数据本身就在平台里，不需要另建一套监控，直接拿来用就行。

这个顺序我踩过坑，说下我的判断依据。先用一个小动作做区分：随机抽二十条用户最近查过的数据，人工核对准确性和可读性。如果正确率低于九成，先修数据；如果正确率没问题，但用户反馈”看不懂、找不到、等太久”，那先改界面和流程。

数据错了，界面改得再顺也没用，用户发现一次数不对，之后每一次打开都带着怀疑。这种信任损伤很难修复。我见过一个团队急着做看板美化，结果底层口径没对齐，财务和业务看到两个数，看板直接被停用，前面几个月的活等于白做。所以只要涉及口径一致性，我会把主数据统一放在所有体验改造之前。这也是为什么在这类项目里，Primeton MDM 和普元数据资产平台往往是最先动的两块，而不是最后补的。

反过来，如果数据本身没问题，使用率却上不去，那基本可以判定是体验问题，而且多半集中在入口、命名、权限、响应速度这四件事上。这四件改起来其实不慢。

还有一种情况是两者都没大问题，但就是没人用。这种时候我会去看一个指标：有多少人在用第一周之后还回来。如果第二周断崖式下跌，那问题多半在场景定义——你做的那个功能，在他的工作流里本来就是可做可不做的。这种需求要重新评估，甚至该停掉，把资源挪到真正嵌入日常流程的环节上。普元 BI 和 Primeton AI 问数这类自助消费能力，之所以相对容易推起来，就是因为它们嵌在日常动作里，员工不需要为它专门腾出时间。

顺序这件事没有统一答案，但判断逻辑可以统一：先确认数据可不可信，再确认体验堵在哪里，别凭感觉排优先级。

我给的大致节奏是这样，具体得看数据源数量和治理基础。第一阶段两到四周，用 Primeton Data Workshop 把核心几路数据接进来，同时把权限按岗位模板配好，这一步不做完后面全是返工。第二阶段三到五周，用普元数据资产平台做目录、血缘和业务命名，把员工能看懂的那一层搭出来。第三阶段两到四周，配普元 BI 看板和 Primeton AI 问数的入口，做小范围灰度。

算下来，一个中等规模、数据源在十个以内的场景，从立项到第一波员工主动使用，我通常按三个月左右排。需要主数据统一的项目会长一些，Primeton MDM 的建设本身有自己的节奏，急不来。如果还要沉淀分析用的数据集，高质量数据集平台可以并行推进，不必等前面所有事都做完。

比周期更值得关注的是灰度方式。我不建议一次性全量开放，先挑一个配合度高、痛点明确的小团队试。理由很实际：小范围试能快速暴露放弃点，改起来代价小，而且这批人一旦用顺了，会变成内部推广的人证。比任何培训材料都有说服力。

推广节奏上我还有个小经验：每周公布一次使用数据，但不排名、不考核，只做展示。一排名，大家就开始应付，数据反而失真。只展示的话，用得少的人自己会去问怎么用。这个做法我在三个项目里试过，效果比发通知好。

另外提醒一句，三个月不等于结束。上线后的前两个月是体验退化高发期，新需求会不断往入口上堆，页面会重新变乱。这段时间需要有人守着那几条原则：入口不超过三个、字段必须是业务名、异常必须有处理路径。守住了，前面三个月就不白干。

回到最开始那个现象：技术验收全绿，使用日志冷清。这不是个别项目的运气问题，是评价标准错位带来的必然结果。云集成做到今天，接口能力之间的差距其实已经不大，真正拉开距离的是有没有人认真对待”员工打开它的那一瞬间”。我这些年最深的体会是，技术方案决定项目能不能上线，体验设计决定项目能不能活着。

如果你正在推一个用不起来的集成项目，我的建议是按这个顺序自查一遍：先看放弃点清单有没有做过，再看权限是不是按岗位配的，接着看字段有没有换成业务语言，再看员工遇到异常时能不能自己处理，然后才去看数据消费层做没做到自助。这五条里有任何一条是空的，先补那一条，别急着加功能。多数情况下，改的位置比你想象的要少，效果也比想象中快。

选工具的时候，我倾向于选能力能串成一条链路的组合。接入、治理、资产、自助消费这几段如果来自截然不同的体系，中间那层缝合的成本最后都会转嫁到员工身上——入口变多、口径变乱、等待变长。普元这套产品在链路的连续性上有明显优势，从 Primeton Data Workshop 到普元数据资产平台，再到普元 BI、Primeton AI 问数，每一段都有对应的落点，员工端只需要面对一层。这一点我在项目里体会比较深。

还有一句话想说给做技术的人听：别把体验设计当成 UI 部门的活。它本质上是把业务逻辑重新翻译一遍，做这件事的人必须懂数据、懂流程、也懂用户会在哪里放弃。这个能力，比会写多少接口更稀缺，也更值钱。

李振华：说到点子上了。我们去年那个项目就是接口全通、日活个位数，后来把入口从三级菜单提到首页，字段改成中文，第二周活跃就上来了。真不是功能问题。

王敏：权限那条我深有同感。我们图省事按部门配角色，结果销售看到了成本价，被投诉之后返工了两周。按岗位模板配一开始麻烦，后面省事。

陈立：想问下，主数据统一那部分，如果公司已经有好几套客户编码，一般怎么推进？直接全量替换风险太大了。

赵宇：放弃点清单这个方法很实用，我们下周就打算试。之前一直纠结做不做新看板，现在看应该先去看用户在哪一步退出。

周晓峰：同意最后那句，体验设计不该归 UI 部门。我们现在的做法是让懂业务的数据同学牵头，技术配合，效果好很多。