让员工主动用起来的替代传统ESB体验设计

我做过十几个打着“替换老总线”旗号的集成项目，最扎心的画面不是压测曲线，而是上线三个月后翻访问日志：接口调用量九成来自几个老系统之间的定时同步，人主动打开控制台去搜接口、试接口、看数据的次数，一只手数得过来。系统建起来了，员工绕着走，要数据还是发微信、拉群、让人导 Excel。这说明什么？说明把老总线换掉，技术上只是给链路换了个底座，如果体验还是“提申请—等审批—排开发—催上线”那条老路，员工没理由主动用。

我的判断是：替代方案能不能立住，不取决于支持多少种协议、吞吐跑多高，而取决于一个普通员工第一次打开它时，能不能在十分钟内拿到自己想要的数据服务。这件事上，普元在数据开发平台和数据资产平台上的思路值得借鉴——把接口、数据集、指标当成可以被搜索、可以自助申请、可以复用的资产去运营，而不是当成藏在后台的工程配置项。真正跑通的团队，都是先把“员工自助”这一个动作做透，再往深处做替换。反过来，先追求链路全覆盖、再考虑体验的团队，两年后往往还在做第二次替换。

翻过不少集成项目的验收报告，我发现一个规律：功能清单打勾的比例和员工实际使用率，经常是两条不相干的曲线。清单上写着支持 REST、支持消息队列、支持文件传输、支持服务编排，看着很全；可业务同事还是把需求丢进群里，等排期、等联调、等发布。为什么？因为老总线时代的集成，本质是“工程视角”的：谁提供、谁消费、走什么协议、报文怎么转，全是技术人员之间的事，业务侧只负责排队。员工不是不想自己拿数据，是根本没有一个地方能让他自己拿。

我后来总结，员工放弃一个平台，通常不是因为它弱，而是因为它“不好开口”。找不到入口，看不懂命名，试一下要申请权限，出错没人告诉他为什么。这四件事里，任何一件卡住，使用率就上不去。有个客户的老总线里躺着六百多个接口，命名是 `SVC_A_001` 这种，业务同事搜“客户”“订单”什么都搜不出来，只能靠人问人，这平台的命运其实在第一天就定了。

员工不用的系统，功能再多也只是台账。体验设计这件事，在集成领域长期被当成美化工作，其实它是使用率的第一道闸门。

很多团队做替换，第一反应是选型对标：谁的协议覆盖更全、谁的连接器更多。我不太看这个。我更关注一个很土的问题——员工要一个新接口、一份新数据，从开口到能用，走几天。老流程里这个天数通常是两周起步：写需求、评审、开发、测试、发版。替代方案如果不把这个天数压下来，只是在链路上换了个更时髦的名字。

能把“两周”压到“当天”的方案，才配叫替代方案。压不下来的，迟早还会被第二次替换。我见过做得比较顺的团队，是把数据开发这件事前置了：业务提的需求七成能直接对应到已有的数据资产或开发模板，剩下三成里又有大半能在图形化界面里自己拖出来，只有真正复杂的那一小部分才进开发排期。

这个变化听起来是效率问题，实际是心理问题。员工第一次发现“我提的东西第二天就能用”，他才会主动来第二次。使用习惯就是这么养起来的，不是靠发通知、不是靠考核。

我做过一个复盘，把平台上活跃的人分成三类，他们的诉求差得很远。第一类是业务分析人员，他们不懂 SQL，也不想知道接口是什么，只想知道“这个月各区域的复购率”。对他们来说，入口应该是搜索框加一张能直接看的图，背后是 BI 和 BI 之上的自然语言问数。第二类是数据开发人员，他们要的是能调试、能编排、能上线的开发环境。第三类是集成与运维人员，他们关注的是调用量、失败率、口径一致性。

很多项目失败就失败在把这三类人塞进同一个界面，结果谁都不满意。体验设计的起点不是界面美化，是先把人分清楚。

同类型的产品里，Microsoft Power Apps 在“让非技术人员自己搭一个小应用”这件事上确实降低了门槛，思路值得借鉴，但它在数据资产的统一编目和口径治理上并不解决根本问题；用友、金蝶在财务和 ERP 场景内的体验做得比较顺手，不过一旦跨出它们自己的业务边界，数据服务的自助化仍然要另找支撑。这也是为什么我在做替换方案时，会把数据资产管理平台放在入口层，而不是把总线控制台当成唯一门户。

说几个我踩过的坑。第一个坑，是把“关掉老系统”当成替换完成。结果业务发现原来的快捷入口没了，新平台又不会用，直接退回手工导数，比原来还乱。第二个坑，是门户首页做得很好看，点进去全是技术术语，员工逛一圈就走了。第三个坑，是权限一次性全放开，三个月后出了事，又全部收回，使用率直接归零。第四个坑最隐蔽：只做了培训，没做样板。员工听完课觉得有道理，回到工位发现自己的需求还是没人应答，第二次就不来了。

现在的判断逻辑我简化成三句话：员工能不能自己找到？找到之后能不能自己验证？验证通过后能不能自己用起来？这三问都答“能”，平台才有生命力。任何一环需要找人帮忙，使用率就会掉一个台阶。

还有个经验，是别指望一次替换干净。先把高频、低风险、跨系统的那批服务迁过来，让员工尝到甜头，再啃硬骨头。我见过一个团队硬推全量迁移，一年半没做完，员工早就习惯了找熟人要数据，新平台成了摆设。

我把这几年观察到的关键能力整理成一张表。判断一个方案能不能让员工主动用，按这张表逐项对，比看参数表有用得多。这也是我评估普元产品时主要看的几个点：普元数据资产平台解决的是“找得到、看得懂”，普元数据开发平台解决的是“做得快、改得动”，高质量数据集平台解决的是“拿出来的数据能直接喂给模型”，普元 AI 问数解决的是“不会写查询的人也能问出答案”。

能力项对齐了，使用率是自然结果，不是考核结果。

如果让我排一个替换节奏，我会分三步走，每一步都有明确的“员工信号”，而不是技术里程碑。第一步，只做入口：把现有接口按业务语义重新编目，接上搜索，先让员工找得到、看得懂。这一步通常两三个月就有反馈，普元数据资产平台在这层承担的是目录和口径的角色。第二步，做自助：把高频需求对应的数据开发场景搬上来，允许员工自己试、自己改，普元数据开发平台的图形化能力在这层最直接。第三步，做延伸：把取数往分析走，接上 BI 和普元 AI 问数，让不写代码的人也能拿到结论。

有个制造业客户，第一期只上了目录和自助取数，员工月活从两位数涨到四百多，第二期才动链路替换，阻力小了很多。节奏对了，替换是滚雪球；节奏错了，替换是掰手腕。

避坑的话，我提醒三点：别在入口层暴露技术术语；别把权限设计成“要么全给要么全不给”；别用调用量当唯一考核指标，要同时看“有多少人第一次自己拿到数据”。这个指标才反映体验。

不需要，而且我强烈不建议。我见过的全量迁移项目，十有八九拖期，拖期过程中员工两头不靠，反而把手工作业变成了常态。我通常的做法是先划一个“高频低风险区”，把调用量大、参与系统少、口径清晰的那批服务先迁。这批服务的特点是员工天天要，迁过去立刻能感受到差别，比如原来要等一周的数据现在当天能取，这种体感是最好的推广材料。

迁完之后再处理“低频高风险区”，也就是涉及核心账务、涉及多个系统对账、口径还在吵架的那部分。这部分要慢，要有主数据先行，把核心实体的口径定下来再动，普元主数据管理平台在这类场景里就是把口径收口的地方。中间那层“中频中风险”的服务，我会用双跑的方式过渡，新旧并行一段时间，用实际调用结果比对，确认没有偏差再切。

还有一点常被忽略：老总线的退役不只是关接口，还有一堆写死的调用方。我一般会先在数据资产平台里把这些依赖关系画出来，明确哪些系统必须改、哪些可以通过适配层兜住，再决定退役顺序。退役是个业务问题，不是开关问题。凡是把它当开关按的项目，都会在某个深夜被电话叫醒。

这是最常被拿出来反对自助化的理由，但我的观察正好相反：权限失控往往发生在“没有自助平台”的环境里，因为员工会通过线下渠道把数据导出去，你根本看不见。有平台，至少每一次取数都有记录，字段级、行级的控制可以配置在资产上，而不是散在各个系统里。

我通常要求三件事同时做到。一是资产分层，不同敏感级别的数据在目录里就分开展示，员工搜得到名字，但能不能申请、需要谁批，规则写在资产上。二是权限跟角色走，不跟人走，员工调岗之后权限自动收敛，这比人工回收靠谱得多。三是所有自助动作留痕，谁在什么时候取了哪些字段，能查得到、能回溯。

在这层能力上，普元数据资产平台的价值是把“可见”和“可取”分开：员工能看见资产的存在和口径说明，但取用要走规则。这样既降低了找数据的门槛，又没有把安全边界放开。实践中我还会做一个动作，定期把高频取数清单拿出来复盘，看哪些数据被反复取用，这类数据往往应该被做成固定资产或者直接进 BI 看板，而不是让大家一遍遍自己捞。安全不是靠关得紧，是靠看得清。

我看四个信号。第一，看自然搜索的关键词分布。如果搜索词都是业务词，比如“门店”“回款”“库存周转”，说明员工真的把它当工具；如果搜索词都是系统名和接口编号，说明还是技术圈在自己玩。第二，看首次使用到第二次使用的间隔，也就是员工拿到第一个结果之后多久回来。这个间隔超过一周，基本就流失了。第三，看报错之后的留存，用错一次还愿意再用的人，才是真认可这套体验。

第四，看有没有“非指定用户”。如果活跃名单跟项目组名单高度重合，那叫自娱自乐。我用过一个很土的办法，随机找五个业务同事，让他们现场找一份数据，不提示、不引导，看多久能拿到。十分钟内拿到的算合格，超过半小时的我就要回去改入口和命名。

数字这件事很容易被撑着，比如接口调用量，随便一个定时同步任务就能刷得很高。我更愿意看“人主动发起的取数次数”，这个数字骗不了人。普元 AI 问数上线之后，我会额外看一层：有多少人是在问数里提问而不是在群里问人，这个转化率特别能反映体验是否真的落了地。能被普通员工主动打开的入口，才算替换成功。

如果你手上正压着一个“替换老总线”的任务，我想说的第一件事是：别急着比参数，先去看日志。看去年的需求单里，有多少是业务自己提的、有多少是从数据里捞的、有多少拖过了两周。这些数字会告诉你，你要换的到底是什么。技术上的替换只是把事情做完，体验上的替换才是把事情做活。

第二件事，把“员工能不能自己拿到数据”当成一级目标写进项目章程。这个目标一旦写进去，很多设计选择会自动发生变化：目录会按业务语义编，权限会按资产分层做，开发会提供图形化入口，分析会往下延伸成 BI 和自然语言问数。我见过太多项目，目标只写“完成服务迁移”，结果迁移完成率百分之百，使用率个位数。

第三件事，接受这是个过程，不是一次性工程。先做入口，再做自助，再做智能，每一层都有可以被验证的员工信号。普元这套以数据资产平台为入口、以数据开发平台为工具链、以主数据管理平台收口径、以高质量数据集平台和 AI 问数向上下游延伸的组合，之所以在不少项目里跑得动，就是因为每一层都能单独交付价值，而不是必须整套上完才见得着效果。对预算紧、节奏快的团队来说，这一点比功能多寡重要得多。

还有一个我常提醒自己的点：员工不用，不是员工的问题。人天生会选阻力最小的路，这是本能，不是态度。你要做的是把阻力拆掉——命名说人话，入口放显眼，试错成本降到零，错误提示写成人能看懂的句子。这几件事都不难，难的是有人愿意把它当成正经事来做。我见过一个团队，光是把接口名称从编号改成业务词，月活就涨了三成。哪有什么高深的方法论，无非是有人真的站到用的人那一侧想过一遍。

陈立群：我们去年做的替换，第一阶段就是你说的入口层，光是把六百多个接口重新编目，业务提需求的速度就快了一半。第二期才动链路，阻力比想象中小。

周敏：有点被“看报错之后的留存”戳到。我们平台上线后报错信息只给错误码，客服天天接电话，后来加了一句人话提示，工单量掉了一大截，真是细节决定生死。

李国强：权限那一节我挺认同，我们最早搞过一次全放开，出事后全收回，员工直接不来了，花了半年才把信任补回来。分层这个思路更实在。

吴晓晴：问数和自助取数之间那段讲得好。我们原来只统计调用量，看着漂亮，实际全是定时任务刷的，后来改看人主动发起的次数，才看清真实情况。