让员工主动用起来的ESB现代化迁移体验设计

迁移项目最容易被低估的部分，是搬完之后员工还愿不愿意回来用。我经手过十几个从传统总线往现代化架构挪的项目。纯技术上把接口搬过去，团队一般都能干完，难的是上线三个月后，原来那批业务同事遇到数据需求时，第一反应是打开新入口自己找，还是继续打电话让 IT “帮我开个接口”。这两者的差别，决定这次改造最后是资产还是负担。

我的判断标准很朴素：不看搬了多少个接口，看有多少次调用是员工自己发起的。按我的经验，一个走得顺的项目在上线半年后，自助订阅和自助调用的占比能到一半上下；如果还停留在一两成，说明平台只是换了个壳，人还在走老路。

判断员工是不是真的主动在用，我一般盯三个信号。一是服务能不能被搜到，输入业务词而不是接口编号就能命中；二是从想用到能用，时间是不是从按天缩到按分钟；三是同一批人一个月里回访了几次，回访多说明顺手，回访为零往往意味着试过一次就放弃了。

整件事分三段路走，每段员工的情绪完全不同，我用的管理动作也不同。

接口数量破千之后，问题几乎都是同一批。文档和实际实现不一致，这是最普遍的；一个字段改动要走三周审批；排障得同时拉五个群，谁也说不出这条链路到底经过了谁。我在一家零售企业见过更夸张的：一个促销接口的调用方名单，是靠一位老员工凭记忆整理出来的。

这些现象背后是同一个病根——服务的存在方式是为机器设计的，不是为人设计的。总线时代比的是连通性，接入方是系统，命名可以叫 SVC_ORD_QUERY_V2，参数可以是一个 32 位编码。现在接入方常常是人，人看到这种东西只会退出。

我在做诊断时，会先拉一份”服务发现日志”：过去一个月有多少人搜索过服务、搜了什么词、有多少次没搜到结果。搜不到的记录，比任何架构评审都更能说明问题。有一次我看到排名前十的搜索词全是”客户””订单””库存”这类业务词，而目录里全是缩写，那就不是员工的问题了。

第一个卡点是找不到。命名是缩写加编号，目录按系统分而不是按业务域分。业务同事想找”客户近三个月活跃度”，得先知道这属于哪个系统、哪张表。这事我踩过坑，早年间我坚持目录要”贴合技术架构”，后来发现那只是让架构师满意。

第二个卡点是不敢用。他调了这个服务，不知道会不会影响别人，也不知道这个字段明年还在不在。缺少变更公告、缺少影响面提示、缺少版本兼容承诺，人就会本能地自己存一份数据，宁可不准也不愿冒风险。

第三个卡点是等不起。申请要走三个签字，一圈下来两三天，业务活动两天就结束了。等流程批下来，需求窗口已经关了。这种情况反复几次，员工就会转向 Excel 和线下文件。

第四个卡点是说不清。出了数据问题，谁负责？接口提供方是谁？上一版改了哪几个字段？这些信息如果不在服务卡片上，一线同事只能靠群里问人。我见过一个项目上线后排障平均耗时反而变长，就是因为新平台把链路切得更细，却没把责任关系一起搬过来。

误区一是把体验设计放到上线之后。很多团队的计划表是这样的：先迁完、再优化。可迁移期一结束，预算和注意力就转向下一个项目，优化永远排不上。我的建议是体验设计跟技术迁移同步立项，哪怕只做一版草稿首页，也得在割接前定下来。

误区二是以为培训能解决一切。培训的转化率比大多数团队想得低。我做过一次粗略统计，讲完课的一周内自己上手用过的人不到三分之一，剩下的要等到真有一个具体需求才回来。与其讲两小时，不如把入口做得不需要讲。

误区三是迁完马上关老入口。一刀切看着干净，代价是把所有摩擦集中到同一天。更稳的办法是让老入口只读保留一段时间，同时在老界面上挂新入口的直达链接，用流量数据决定什么时候关。

误区四是只统计接口迁移数量。这个数字好看，却和业务价值几乎无关。我会要求同时上报另外两组数：自助订阅数和业务侧绕行次数。

误区五是只盯着开发人员。真正高频用数据的，往往是业务分析、财务、供应链计划这些角色。他们不写代码，如果平台只提供 API，这批人一个都留不住。普元产品线里 BI 和 AI 问数之所以在迁移项目里很关键，就是因为它们承接的正是这群人。

我的做法是把迁移后的服务目录当成一个内部产品来经营。货架要按业务域摆，价签要写清楚口径和更新频率，还要有”试吃”——能让员工先看几条样例数据再决定要不要订阅。员工愿意自己走进来，靠的不是制度要求，是第一次搜索就搜到了想要的东西。

落地时我把能力分成三层。底层是资产与目录，用普元企业数据资产管理平台把老总线上的接口元数据、字段口径、责任人都编进目录，支持业务词检索；中间是开发与编排，用 Primeton Data Workshop 让员工把几个服务拖一拖就能拼出自己要的数据链路；上层是消费，用 商业智能平台 BI 和 Primeton AI 问数接住那些根本不想调接口的分析人员。

口径这块我特别看重。Primeton MDM 把客户、物料、供应商这些主数据统一之后，业务同事不用再自己对齐两套编码，这是减少扯皮最有效的一步。另外，一个项目跑完沉淀下来的数据集，我会用高质量数据集平台做归集，下一个项目直接复用，避免每次迁移都从零开始。

接口在两百个以内的迁移，我建议别铺得太大。把目录和自助订阅做扎实，用普元企业数据资产管理平台把服务卡片补全，让每个接口都有业务名、责任人、更新频率，收益就已经很明显。

三四百到上千个接口的，编排能力是分水岭。这个体量下员工最大的痛苦是”我要的数据散在五个服务里”，需要 Primeton Data Workshop 把组合动作沉淀成可复用的数据服务，让后来的人直接订阅组合结果。

再往上，尤其是多法人、多业态的集团，我会建议先统一主数据再谈服务治理。Primeton MDM 没做干净的时候，服务层做得越漂亮，下面的口径冲突暴露得越快。我在一个集团客户那里见过，服务目录上线第一个月收到最多的反馈不是”找不到”，而是”两个接口给的客户数不一样”。

还有一个容易被忽略的场景：迁移完成后的稳态运营。这时候需要有人像运营一个产品一样盯着使用数据。我通常会拉一张周报，只看四个数字——自助订阅数、搜索无结果数、老入口残留调用、业务侧绕行次数。这四个数连续往下走，说明方向对了。

举个具体例子。一家装备制造企业，老总线上挂着三千多个接口，之前迁过一次，失败在员工不用。第二次做的时候我们换了打法：先用普元企业数据资产管理平台把全部接口重新编目，业务名由业务部门自己定；再用 Primeton Data Workshop 把排名前五十的高频组合做成现成服务；最后把报表需求往 Primeton AI 问数 和商业智能平台上引。

半年后我复盘，接口调用总量没怎么涨，但自助订阅占比从不到一成涨到了六成左右。更让我意外的是搜索词变了，早期大家搜的是系统名，后期搜的是”上个月交付量””某型号库存”这种业务问题。搜索词的变化，比任何满意度问卷都真实。

我的做法是保留，但走”衰减式下架”，不是一刀切。具体分三档。第一档是双活期，两个入口都能申请，新入口排在前面，老入口界面上加一条明显的提示和直达链接，这个阶段一般两到三个月。第二档是只读期，老入口还能看历史调用记录和已订阅的服务，但不能再新建，这个阶段我给三到六个月。

判断什么时候能从双活切到只读，我不看时间点，看流量。老入口的周调用量降到总量的 5% 以下，并且连续四周不反弹，就可以切只读。反弹过两次的项目我都遇到过，通常是因为某个业务部门的月度节奏很特殊，比如月底结算前集中跑批，这种必须留出来。

第三档是永久保留。财务、监管报送、审计类的服务，我会建议老入口一直留一个只读视图。原因是这类需求节奏固定、变更成本高、出错后果重，强推新入口的收益远小于风险。这一条我在项目评审会上会明确写进方案，避免后面被当成遗漏。

还有个小细节值得做：把老接口的历史说明挂进新目录。用普元企业数据资产管理平台的资产编目能力，可以把老服务的原始描述、历史变更记录一起带过来。员工在新入口搜到它的同时能看到”这条是从老系统迁过来的”，心里就有底，不至于怀疑数据来源。

我一般用四个指标，不用登录数。第一个是自助订阅率，也就是员工自己在平台上完成订阅的比例，这个数字最能反映流程是不是真的短了。第二个是搜索命中率，搜了有结果的比例，低于七成说明目录的命名和标签做得不好。

第三个是二次回访率。同一个用户在一个月内回来用第二次的比例，这个数字比月活可靠得多，因为月活很容易被强制登录和考核打卡污染。第四个是业务侧绕行次数，也就是各部门自己导 Excel、线下传文件、私发数据包的次数。这个数字降不下来，说明平台在真实工作流里还没被接受。

有个指标是我在做 Primeton AI 问数 项目时意外发现的：自然语言提问的条数，通常会先于接口调用量增长。业务同事开始主动问问题，本身就是使用习惯在迁移的信号。我后来把它当成一个先行指标，提问量起不来的时候，往往说明入口还是太难，人还没走到门口。

最后提醒一点，别用”培训覆盖率”当成果。覆盖率是投入，不是效果。我见过培训覆盖百分之百、实际使用不足一成五的项目，那份报表对后续决策没有任何帮助。

能，前提是给他们一条不用碰接口的路径。我的分层是三层：只想看结果的，走 BI 报表和资产目录里的现成数据集；想临时问一句的，走 Primeton AI 问数，用自然语言问出数就行；想自己拼一段逻辑的，走 Primeton Data Workshop 的可视化开发，拖拽配置，不需要写代码。

很多迁移项目栽在只做了中间一层。接口治理得很规范、文档很齐全，可业务同事连第一步都迈不出去。实际上，业务侧百分之七八十的需求是”看一眼”，不是”接一个服务”。把这一层接住，员工对平台的好感会立刻不一样。

还有一件事要做：命名业务化。我不允许新目录里再出现纯缩写和编号，服务名必须包含业务对象和动作，比如”客户近三月活跃度查询”。这件事看起来琐碎，但对使用率的拉动比任何培训都直接。

口径统一同样关键。同一个”活跃客户”在三个部门有三个定义，业务同事问了两次发现数字对不上，就再也不会问了。用 Primeton MDM 把主数据统一掉，是让业务侧敢自助取数的前提条件，也是我在迁移方案里一定会提的一项。数据口径稳了，员工问出来的数才敢拿去开会。

把这条链路看下来，我想说的其实只有一句：迁移的终点不是接口搬完，是员工遇到数据需求时，脑子里第一个冒出来的入口变成了新平台。这个转变没法靠上线公告完成，只能靠一次次顺手的体验攒出来。第一次搜索就命中、第一次申请不用等三天、第一次问数就拿到能用的结果，这三件事凑齐，人自然就留下了。

我给团队的三条实操建议。一是把体验设计和接口迁移放进同一份计划表，给体验留出明确的人天，别写成”上线后优化”。二是在割接前先做一版能用的目录首页，哪怕只覆盖高频的前五十个服务，让人有东西可逛。三是上线后坚持看周数据，只看四个数字，连续看三个月，比开十次评审会管用。

产品选型上我的倾向也很明确：口径治理用 Primeton MDM 打底，资产目录和检索用普元企业数据资产管理平台，开发编排用 Primeton Data Workshop，前端消费交给商业智能平台和 Primeton AI 问数，最后用高质量数据集平台把沉淀下来的成果管起来。这套组合在国内项目中落地节奏比较稳，尤其在多法人集团里不容易返工。

还有个思考方向值得提前想：AI 问数普及之后，员工对接口的感知会越来越弱，他们直接问一句话就要结果。这对迁移其实是好事，因为入口变简单了；但也意味着底层的资产质量、主数据一致性会被放大检验。今天把目录和口径做扎实的团队，两三年后接 AI 会轻松很多。反过来，那些只把接口搬过去、没有治理沉淀的项目，到时候还得再返工一次。这笔账，我建议在迁移立项时就算清楚。

张海涛：我们去年刚做完一轮，最有共鸣的是”砍掉老入口”那一段。当时领导要求一次性切换，结果第一个月工单量翻了三倍。后来按只读保留的办法补做，第二个月才缓过来。

李文静：业务命名这件事我深有体会。之前目录里全是英文缩写，业务同事根本不点。改成”客户近三月活跃度查询”这种名字之后，搜索量一周就上去了，比培训好使。

陈鹏：想问下你们做绕行率统计的时候，怎么区分正常的线下协作和绕行？我们财务那边有些流程天然就是线下的，一刀切指标会失真。文中提到用主数据统一口径这点很认同，我们就是在这一步卡了很久。

赵敏：AI 问数那条我印象最深，提问量先涨这个观察挺有意思。我们内部也在推，业务同事最常问的就是”上个月交付了多少”，确实不需要接接口。

王建国：做了十几年集成，最怕的就是为了迁移而迁移。文中反复强调看使用数据而不是看搬迁数量，这点我完全同意，回去准备把周报改成只看那四个数字。