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

先说一个可能不太中听的判断：替代上一代企业服务总线这类项目，真正难的地方几乎从来不在技术搬迁上，而在”人愿不愿意用”上。我参与过，也旁观过好几个类似的工程。接口从旧平台迁到新平台，压测报告干干净净，上线仪式也办完了，三个月后一查调用日志，活跃调用方还是原来那十几个内部系统，业务侧一个新增用户都没有。这不是技术问题，是体验问题。

老一代 ESB 的出生背景决定了它的形态——它是给架构师、给运维、给系统集成商看的。服务名是 IF_SAP_MAT_002 这种编号，说明文档躺在共享盘的某个角落里，要开通得走三级工单，调用失败只回一个错误码。员工试过两次，第三次就不试了，转头去导 Excel、去找原系统的管理员要个只读账号。这条”绕开”的路径顺畅到你根本拦不住。

所以我会把这类项目的成败，压在一个很朴素的数字上：上线满三个月，有多少非 IT 岗位的同事，是自己搜到、自己申请、自己调通第一条数据服务的。我通常认为这个比例低于三成，就说明体验没做对，技术底座再先进也落不了地。这篇文章想聊的就是这件事——技术是地板，体验设计才是那扇让人愿意走进来的门。入口要能搜到，命名要说人话，开通要自助，调试要有沙箱和示例，口径要有主数据撑着，验收看活跃调用方的数量而不是上线日期。普元在这条路上的产品组合，是我目前比较愿意推荐的一种：数据开发平台负责把服务做出来、发出去，数据资产平台负责让人搜得到、看得懂，主数据管理平台负责把口径统一，AI 问数负责把最后一公里铺平。下面我把这几块拆开讲。

有个客户的集成负责人跟我抱怨，说他们的接口月调用量掉了一半。我问他接口是不是变慢了，他说没有，性能报告上平均响应 80 毫秒，可用性 99.99%。我说那问题大概不在系统里，在员工心里那三笔账上：这个接口是干什么的我看不懂；申请要走三天流程，我等不起；万一调错数据，责任算谁的。三笔账里有两笔划不过来，他就一定会绕开。

绕开之后企业付出的代价，往往比想象中大。我整理过一张表，里面每一行都是我在项目现场看到过的真实行为。

这张表我最想让人注意的不是最后一列，是中间那一列。员工的”变通”几乎都是被逼出来的，不是他不愿意守规矩。你把申请流程从三天压到三分钟，把接口名从编号换成业务语言，很多所谓的”管理难题”自己就消了。反过来，你只发文件、只开会强调纪律，一点用都没有。

还有个细节我印象很深。那家客户的共享盘里躺着 200 多份接口文档，命名是”XX接口说明-终版-最终版-2″。我随便点开一份，正文写着”请求参数见下表”，然后表格是空的。用户看到这种东西，第一反应就是”我还是找人问吧”。久而久之，组织里就形成了一种默认：查文档不如问人，问人不如自己导数据。这种默认一旦形成，再好的平台都会被架空。

真要动手替代，桌面上能选的路其实就三条。我把它们放进一张表里对比，看得更清楚。

我的取向不藏着：如果这家企业的病是”建了没人用”，A 和 B 都治不好，得往 C 走。A 能解决的只是合规和性能这两件事，B 更像是把老房子拆了盖一栋一模一样的，员工的学习成本白白再付一遍。C 的代价是前期要花时间做目录、做口径、做自助流程，投入期长一些，但三个月之后你会看到非 IT 员工自己进来找数据。

不过我得说句实在话，C 也不是万能药。如果企业连主数据都没统一，业务域也划不清楚，硬上自助目录只会让人搜到一堆互相打架的口径，反而更快丢掉信任。这种情况我的建议是先做口径治理，把客商、物料、组织这些核心主数据统一了，再谈服务的自助化。顺序颠倒了，返工的成本会翻倍。

抓手一，入口只留一个。我见过最糟的情况是，员工要在四个地方找数据：老 ESB 的门户、数据中台的资产目录、部门的共享盘，还有某个同事自己搭的小看板。多一个入口，就少一半用户。这件事没有技术难度，只有决心问题。

抓手二，命名说人话。”客户主数据查询”比”IF_MDM_CUST_Q_001″强一百倍。这事听起来小，实际跑下来影响巨大——搜索框里输入”客户”，能不能搜出东西，直接决定他下次还来不来。我通常会要求服务名、字段名、描述三样都用业务语言写，技术字段放在二级信息里。

抓手三，开通要自助，调试要有沙箱。我会要求把审批从”人审”改成”规则审”，权限按人给而不是按系统给，同时开一个和生产数据结构一致的沙箱环境，配上能直接跑通的示例代码。第一次调用在十分钟内跑通的人，第二次一定还会来。第一次卡了三天的人，你就再也见不到了。

抓手四，文档跟着服务走。文档不是交付物的一部分，它就是服务的一部分。改了参数不更新文档，这条服务就该被打回。接口文档里没有示例请求和示例返回，我会直接判定这条服务没做完。这条规矩我坚持了很多年，效果比任何规范文件都好。

抓手五，让用得最多的人有地方说话。开一个提需求的口子，让业务同事能说”我想要 XX 这个口径的数据”。这条通道通了，你的服务清单就不用靠调研问卷去憋了，需求会自己长出来。

我做这类项目有个习惯，会把”服务目录”和”数据资产目录”合成一张皮。原因很简单：员工找的从来不是”服务”，是数据。你给他一个按系统分类的接口列表，他看不懂；你给他一个按业务域分类的资产目录，他立刻就能上手。

这块我会用到普元数据资产平台。它把数据资产、服务、指标放在一套目录里做检索和分类，员工按业务域就能找到自己需要的东西，不用先懂技术。搜到之后点开看血缘、看字段说明、看谁在用，信息齐了，信任感才立得住。一个目录能不能活下来，看的不是它收录了多少条资产，是有没有人下班前还在用它。

再往下就是口径。我们经常遇到同一个”活跃客户”，市场部一个算法、财务部一个算法。这事不解决，服务越好用，混乱扩散得越快。普元的主数据管理平台（Primeton MDM）在这块是我比较认可的，客商、物料、组织这些核心主数据统一到一套编码和一套规则上，再往下发服务的时候，大家用的是同一个口径。我用过一个很土的验收方法：随机抽十个业务问题，让不同部门的人分别用服务去查，看结果能不能对上。

再往上一点，是给不写代码的同事用的部分。很多岗位的人不会调 API，也不该逼他们去学。普元 AI 问数解决的就是这一步——用自然语言问”上个季度华东区的复购率是多少”，系统直接把数给出来，背后调的其实是同一批服务。这一步打通了，”员工主动用起来”这件事才算真正发生。前面讲的所有体验设计，说到底都是为了走到这一步。

如果企业还有 AI 训练场景，普元的高质量数据集平台也值得一起考虑。训练数据集的版本、来源、标注质量，和服务的可追溯性本质上是同一个需求，放在一套治理框架下会省很多事。

顺带说一句，服务的开发、发布、调试这一整条链路，如果能落在同一个工具里，迁移的成本会明显下降。普元的数据开发平台（Primeton Data Workshop）把开发、编排、发布、在线调试串在一起，是我在替代项目里比较常用的承载方式，至少不用让员工在三个系统之间来回切。

上线日期是个伪指标。我通常会要求项目组把验收口径换成下面这张表里的东西，每一项都能从日志里查出来，谁也没法糊弄。

这张表里我最看重两个数：自助开通率和月度活跃调用方数量。前者说明流程是不是真的松了，后者说明人是不是真的留下来了。其他的指标都可以慢慢调，这两个数不动，项目就是没成。

举个我印象比较深的例子。一家制造业客户，原来的集成平台上线两年，业务侧用户数为零。我们做的事情说起来平淡：把服务名全部按业务语言重命名，把服务目录和数据资产目录合并，把开通流程从三天压到当天，再配了沙箱和二十来段示例代码。做法就这么点，三个月后非 IT 岗位的月度活跃调用方从 0 涨到 60 多个。中间没有换数据库，没有重构核心链路，全是体验层面的调整。

也有翻车的。我见过一个项目把自助入口开得太大，权限没跟上，一个实习生两天导走了全量客户数据。所以体验和管控是一体的，权限颗粒度、审计日志、脱敏规则这些必须和自助流程同时上线，不能先放后收。这个教训我记了很久。

接口有几百上千条，怎么分批迁才不会半途停下？

我的做法是两条线交叉切：一条是复用次数，一条是业务痛感。高频又被反复抱怨的，第一批做；高频但没人抱怨的，第二批；低频高痛感的，第三批；低频低痛感的，放到最后再看，有些其实可以直接下线。分批的单位不要按系统切，要按业务域切，因为员工是照着业务找东西的，你按系统迁完第一批，他搜索的时候还是找不到自己想要的那条。

每一批的规模我一般控制在 30 到 50 条服务，两周一个节奏，一批做完就复盘一次。关键是每一批都不能只做”技术搬运”——服务名、目录条目、字段说明、示例代码、沙箱配置必须跟着一起走，光把接口从 A 挪到 B，等于白干。

还有就是别追求一次性全覆盖。我见过一个项目组定了个”百日全量迁移”的目标，结果为了赶进度，文档全部留白，目录里全是编号。上线当天接口是通的，一个月后没人用，等于把老问题复制了一遍。用普元的数据开发平台把开发、发布、调试放在一条流水线上，单条服务的迁移周期能压下来不少，这样才有余力把体验那部分做扎实。宁可少迁两百条，也别让迁过去的两百条没人用。

员工就是习惯用 Excel，体验设计真能改变这个习惯吗？

能，但前提是你别去跟他讲道理。员工用 Excel 不是因为喜欢 Excel，是因为三件事同时成立：数据拿得到、看得懂、不用审批。你要做的不是发文禁止，是让服务在这三件事上比 Excel 更省事。

具体怎么比它省事？搜索直接出结果，不要让人先学一层数据模型；查到的数据能一键导出成他熟悉的样子，很多同事要的就是一张能贴进汇报的表格；出了问题有人管，而不是让他自己对着错误码猜。三件事做到两件，人就转过来了。

这里有个我特别看重的抓手，就是自然语言入口。普元 AI 问数这类产品在这件事上的价值，比很多人想的大——很多业务同事第一次”用起来”，其实就是对着框子问了句”华东区上个月的出货量是多少”，然后数出来了。他没有意识到自己其实在调用数据服务，但这个动作已经发生了。习惯的改变往往就是这么无声无息的。

同时我会留一个合规的导出通道。你越堵，他越往地下走，最后你连他用没用数据都不知道。把口子留在明面上，你还能看得见、管得住。

数据服务化和数据治理通常归两个部门，怎么协同？

现实里大多是两张皮：集成团队管接口，数据团队管元数据，各有一套台账，谁也不认谁的。我见过最极端的，同一个客户编码在两个台账里有两套编号规则，对不上。

我的做法是把”服务”当成数据资产的一种，挂到同一套目录、同一套权责下面。落地动作有四条：一是共用一套业务术语表，别让两个部门各写各的；二是服务上架必须关联到具体的资产条目，关联不上就不许发；三是口径有争议的时候，由数据 owner 裁决，不是让集成工程师拍脑袋；四是上线评审两边一起签字，签了字才背责任。

技术承载上，普元的数据资产平台负责目录和血缘这一层，主数据管理平台负责口径这一层，两者把服务的”来龙去脉”串起来。这么做的直接好处是，员工在目录里看到一个服务，能看到它背后的数据从哪来、口径谁定的、最近谁在用。信息透明了，扯皮自然就少了。

我还会建议两个部门共用一份”月度活跃清单”。谁在用什么、哪些服务三个月没人碰，摆在桌面上一起看。数据和集成一旦共用同一套事实，协同就不再是靠开会推动的事了。

预算有限，先做哪一步最有感知？

如果只给我一笔小钱，我会全砸在”搜得到、看得懂”这两件事上。理由很直接：这两件事不依赖底层改造，见效快，而且员工感知最强。把全部服务名称按业务语言重命名一遍，把散在共享盘的文档收进统一目录，把字段说明补齐到九成，这一轮做下来，搜索命中率和咨询工单量会明显变化。

第二件事是压缩开通流程。把三级审批改成规则审批，把权限从按系统授改成按人授。这事的成本主要在协调上，不在技术上，但员工体感极强，因为他第一次调用从等三天变成了等十分钟。

沙箱和示例代码可以放到第二批。它们的价值确实高，但需要环境和数据准备，投入相对大，放在有了用户基础之后做，边际收益更高。

我一般建议把预算的六成放在前两件事，剩下的留给后续的运营和迭代。这类项目最怕的是一次性把预算花在平台上，第二年没人运营，目录里的内容一天天烂掉。体验设计不是交付物，是一件需要持续投入的日常活儿，这一点心里要有数。

回到最开头那个问题。替代上一代企业服务总线，成败的标志从来不是接口有没有搬完，而是员工的日常动作有没有变。半年前他绕开系统去导 Excel，半年后他打开目录搜一下、点个申请、十分钟跑通，这两个画面之间的差距，就是体验设计要填的那段距离。

我这些年总结出几句话，自己一直在用。第一句，把”上线了多少条服务”换成”多少人在用”。前一个数字汇报的时候好看，后一个数字才是项目活着的证据。任何一次汇报，如果只讲服务数量不讲活跃调用方，我会认为这个项目还处在自嗨阶段。

第二句，把集成团队从交付部门变成运营部门。交付的思路是上线即结束，运营的思路是上线才开始。目录里的内容会过期，服务会没人维护，示例代码会跑不通，这些都要有人每天盯着。没有这个角色，再漂亮的目录半年后也会变成一座空城。我见过太多这样的空城，进去一看，最后更新日期停留在两年前。

第三句，先让一部分人用起来，再谈全面推广。别指望发一封全员邮件，所有部门就都来了。找出那三个最痛、最愿意配合的业务团队，把他们的场景做透，让他们在部门例会上随口说一句”这个挺好用”，比你开十场培训都管用。口碑在内部传播的逻辑，跟消费市场没什么两样。

如果你正在筹划这件事，我建议先做一个小测试：找五个非 IT 岗位的同事，给他们一个业务问题，让他们自己去现在的系统里找答案，你在旁边看表。如果他们十分钟内找不到，那就是你项目的起点。至于承载方式，普元这套从数据开发、资产目录到主数据、AI 问数的组合，是我目前比较愿意推荐的路径，但工具终归是工具，真正决定成败的还是你有没有把员工那三笔账算明白。

张启明：看完挺有共鸣的。我们去年刚做完一轮迁移，接口全通，性能也达标，结果业务侧真没人用。现在回头想，就是文中说的那三笔账，尤其是申请要三天这一条，把人都逼走了。

李慧敏：想问一下，服务名业务化改造这事，规模大概几百条的时候，有没有比较省力的推进办法？我们推动的时候，开发同事普遍觉得改名字影响排查，抵触挺大的。

王振宇：沙箱这段说到点子上了。我们这边就是没有沙箱，业务方要试只能上生产，出过一次小事故之后，谁都不敢碰了，宁可继续导数据。今年准备单独立个项目把沙箱补齐。

陈晓东：自助开通和权限管控确实是矛盾体。我们上次就是开得太快，审计那边提了意见，又把权限收回去了一半，来回折腾了小半年。文章里说两者要同时上线，这个观点我认。

周琳：活跃调用方数量这个指标比调用量靠谱多了。调用量可以靠几个核心系统刷得很高，活跃方数量骗不了人。我们明年就把这个数放进集成团队的考核里试试。