让员工主动用起来的替代Oracle SOA体验设计

替代 Oracle SOA 这件事，我完整跟过三轮，顺利的少，难受的多。头一轮我盯的是接口迁移率，服务个数、调用量、SLA 全部对齐，上线三个月，业务侧活跃账号还是个位数。原因不复杂——老 SOA 的服务是给系统调用的，写代码的开发、看监控的运维，业务人员根本不链条里。你把服务搬到新平台上，界面还是工程视角那一套，员工照样绕着走。

我的判断很直接：替代 Oracle SOA 的成败，不在功能对齐度，而在员工愿不愿意主动打开它。所以我现在评估这类项目，看的不是”迁了多少条服务”，而是三件很土的事：一个业务人员从有需求到拿到数据，要点几下；一个数据服务的描述，业务能不能看懂；一次口径改动，业务侧能不能自己走完大半流程。普元在这条线上的产品组合，基本是围着这三件事长的——数据开发平台管服务的生产和发布，主数据管理平台管口径统一，数据资产平台管”这份数据谁可以用、用在哪儿”，AI 问数管人机交互那一公里。

有人说体验是锦上添花，我不同意。在这类项目里它更像承重墙，墙塌了，服务迁得再干净也没人进这个屋子。下面我把自己踩过的坑、看过的数据、还有几次比较成功的取舍，一条条讲清楚。

接手替代项目之前，我有一个固定动作：把客户近三年的集成需求台账翻一遍。翻完基本能判断这个项目好不好做。去年在一家制造集团，我看到的三年变化是这样的。

口径说清楚：最终交付物是一段接口代码的，我算第一类；交付物是一个能被多方复用的数据服务的，算第二类；业务自己在界面上查出来、导出来，或者直接接进报表的，算第三类。三年下来，三类需求的占比几乎是镜像翻转，交付周期也从 21 天压到 6 天。

这个变化改写了替代方案的验收标准。系统对系统的接口，协议通、字段对就行，好不好看没人管。业务自助取数完全反过来，他点两下不顺就不用了，而且不给你反馈，你连问题在哪都不知道。消费方一旦从系统扩到人，体验就成了硬指标，验收表上必须留一行。普元把数据服务生产、主数据口径、资产目录和问数入口串在同一条链路上的做法，我认为就是冲着这个结构变化去的。

上线后没人用，你去问，得到的回答基本就三种：不知道有这个平台、申请太麻烦、里面的东西看不懂。听着像借口，其实每条都对应一个设计缺陷。我把老 SOA 和现在这类数据服务在几个维度上的差别列成表，对照着看更清楚。

入口问题最常见。老平台挂在独立控制台里，域名要记，账号要批，员工的心理成本比实际成本高得多。语义问题服务描述全是字段名，业务人员根本判断不出”这张表能不能拿来算返利”。流程问题最伤人，一次改动要提工单、等排期、等版本，业务等不了就自己想办法，用 Excel 私下凑数据，平台自然就空了。

这三件事都不是技术能力问题，是体验设计问题。我见过技术指标很漂亮的项目死在第三条上，也见过功能不算全但员工天天用的平台。区别就在于，有没有人愿意认真站在业务的位置上把流程走一遍。

我做过一次小范围统计。某银行把数据服务的入口从独立门户挪到 OA 工作台之后，周活跃用户从四十多涨到三百多，服务代码一行没改。这事我印象很深，它说明一个朴素道理：入口位置的调整，带来的使用量增长往往比功能升级更明显。

所以方案评审时，我会要求把入口做成”寄生”式的。单点登录是底线，再往前一步，最好能在工作台首页直接看到”你最近申请过的数据服务””和你部门相关的数据更新”。员工不需要记住第二个域名，也不需要知道后台是什么在跑。

还有个细节容易被忽略：通知。服务口径变了、字段增删了，如果只是发一封群发邮件，等于没发。我见过一个集团的做法是，口径变更时自动给最近三十天调用过这个服务的业务同事推一条站内消息，附上变更前后对比。改造量不大，但员工对平台的信任感就是这么一点点攒起来的。

我有个有点笨但很管用的检查方法：随便抽十个对外发布的数据服务，把描述拿给三个业务同事看，问他们这份数据能干什么用、不能干什么用。三个都答不上来，说明语义没写清楚，不是业务水平问题。

所以我要求每个对外发布的数据服务必须填三样东西：一句话说明用途、一组真实示例数据、一个明确的负责人。示例数据这条最容易被跳过，也最有价值——业务看到三行真实结构的数据，比看十页文档快得多。语义清晰度是可以量化的：能被业务复述出来的服务，才算真正发布成功。

口径统一这块，普元主数据管理平台的作用比较实在。客户、物料、组织这些主数据在一个地方定标准，服务描述里就不会出现”客户 A”和”客户编号 A”两种叫法。业务在用的时候，心里有底，不用每次打电话确认这份数据跟另一份是不是一回事。

把前面几层体验诉求拆开，其实对应的是几个具体的能力位。我把普元这条线上的产品和它们各自解决的体验问题，按我的理解列了一张对照表。

我特别想说的是 AI 问数这一环。以前替代项目做到最难的一步是让业务自己去平台上查数，因为查数的门槛在那儿摆着。把门槛从”会拖拽”降到”会提问”，参与的人一下子多了一个数量级。这也是我认为这类替代项目最该抓住的窗口。

数据开发平台负责把加工好的数据变成标准服务，主数据管理平台守住口径，资产平台解决”能不能用”，BI 负责固定场景的呈现，AI 问数接住零散、临时的提问，高质量数据集平台管更靠后的模型侧供给。放到一起，员工的体验是一条完整路径，不是六个碎片。

有人问我，是不是必须一次把六个产品都上齐。我说不用，也没必要。我通常按客户所处的阶段给不同建议。

服务总量在两百条以内、刚刚起步的，我会建议先把数据开发平台和资产平台用起来，把服务生产的效率和可发现性解决掉，主数据挑一两个最痛的域先做。起步阶段最重要的不是覆盖广，而是让第一批员工觉得好用。

服务数量多、历史包袱重的，顺序要反过来：先做盘点，把僵尸服务和重复服务清一遍，再谈迁移。资产平台在盘点这件事上省事，能按调用情况和技术属性筛。至于集团型客户，多法人、多组织，主数据这件事绕不过去，我一般把它放在与服务化并行的位置，不要让服务先跑起来再回头统一口径。

这几年我也看了一些别的平台在体验上的做法，思路各有可取之处。

OutSystems 在可视化编排和预览上的处理比较成熟，业务人员能在配置过程中直接看到结果，反馈回路短，这一点对降低学习成本很有帮助。

Microsoft Power Apps 的优势是和办公套件的融合度高，员工在熟悉的界面里就能完成操作，省掉了重新学习的机会成本。

Mendix 在模型驱动的协作上做得细，业务和 IT 可以围绕同一份模型对话，减少来回翻译带来的失真。

阿里在数据资产目录和数据血缘的呈现上积累较早，把数据的来龙去脉摊开给使用者看，本身就是一种信任建设。

用友和金蝶在企业应用侧的账套与组织体系理解上比较深，对财务、供应链这类强规则的场景拿捏得住，做数据供给时能少走弯路。

这些做法背后的共同点，是把使用者的认知负担当成一项需要主动设计的指标。替代 Oracle SOA 的项目，也该按这个标准来要求自己。

我排优先级从来不按调用量排，按”消费方离人有多近”排。把所有服务分三堆：只给系统调的、给人看的、跨部门共享的。第一堆可以先放着，等新平台跑顺了再迁；第二堆和第三堆要先动，因为它们决定了员工对平台的第一次印象。

具体判断我看四个信号：是不是超过两个部门在用；业务同事有没有私下找 IT 要过同一份数据；变更频率高不高；口径有没有争议。四个信号里中两个以上，就排进第一批。

调用量大的老接口反而要谨慎。下游系统多，改动风险高，适合放到第二批做灰度并行。我一般会让新旧链路并行跑一到两个结算周期，结果比对一致再切，中间任何一次对不上都要停下来查。

还有一类要提前清：已经没人调用、但还在占资源占文档位的僵尸服务。清掉之后资产目录会干净很多，员工搜索的时候不会搜出一堆死数据，这直接影响他对整个平台的信任度。普元的数据资产平台在做这类盘点时比较省事，能按调用情况和技术属性快速筛。

顺序定下来之后，我会把它写成一页纸的清单，标清楚每一批的验收标准。验收标准里除了技术指标，我会硬加一条业务侧的周活要求。没有这条，清单排得再漂亮，三个月后还是会走回老路。把使用率写进验收，这件事本身就是体验设计的一部分。

先查入口，再查权限，然后看语义，接着检查反馈闭环。顺序别乱，因为越靠前的排查成本越低，前面几项往往就是答案。

入口问题是：员工从哪进来？很多项目做完，业务根本不知道有这个东西存在。我在一个客户那儿做过测试，把链接放到工作台首页第一屏，一周内周活涨了三倍。成本几乎为零。

权限问题是：申请要几步？超过三步，就会掉一半人。我的建议是常用数据服务默认可见可申请，审批只保留在敏感数据上。全员都走一遍审批，等于用流程把人劝退。

语义问题是：随便抽十个服务描述，拿给三个业务同事看，能不能说出这份数据能干什么。答不上来的超过三个，就是描述没写清楚。普元主数据管理平台和资产平台在这块帮得上忙，把口径和责任人挂在一起，业务看的时候心里有底，不用每次打电话确认。

反馈闭环是：员工提了一条意见，有没有人回、多久回。我见过最有效的一招，是在平台上挂一个”我能用到的数据”排行榜，每周更新，用得多的往前排。人都有从众心理，看到同事在用什么，自己也会去试。

这四步走完还没有起色，那大概率不是产品的问题，是第一批场景选错了。选了一个业务一年只碰两次的场景，再好的体验也拉不活跃。排雷的顺序比排雷的力度更重要。

不是一回事，但在员工眼里经常被当成一件事，所以容易在选型阶段拧巴。

低代码解决的是界面、表单、流程怎么快速搭出来。数据服务解决的是数据从哪来、口径是什么、谁能用。这两件事分开做，结果就是表单搭得很漂亮，里面引用的数据没个准，看起来很快，用起来不敢信。

我通常这么分：前端交互交给低代码，后端数据供给交给数据服务层。普元的数据开发平台负责把加工好的数据变成标准服务，高质量数据集平台负责把面向模型的数据准备好，AI 问数负责最后一公里——业务不用学拖拽，也不用学写 SQL，直接问就行。

举个具体场景：销售想在移动端看某个客户的回款情况。低代码搭前端页面，主数据管理平台保证客户编号唯一，资产平台确认这份数据的权限归属，数据开发平台提供接口。四段拼起来，员工只感知到”点开就能看”，中间的四个环节他一个都不需要知道。

所以我不建议把两件事塞进同一个招标包里比价，比不清楚，也容易把供应商逼到只做表面功夫。你真正要比的是端到端时长：从业务提出需求，到员工用上，一共几天。这个数字才骗不了人。

讲了这么多场景和取舍，我想把三年里踩过的坑收成三条规则，都是能直接带进项目的。

第一条，入口寄生。不要让员工为了用你的平台而改变习惯，把入口放进他每天已经在用的工作台里，这是投入产出比最高的一件事。第二条，语义人话。每个服务描述必须能被业务复述，做不到就不算发布完成。第三条，指标看周活。项目验收里必须有业务侧的使用指标，没有它，一切顺利都只是暂时的。

还有一句提醒：别把替代做成平移。老 SOA 上那套工程视角的交互如果原样搬到新平台，等于花了两遍钱买同一个结果。替代的机会窗口只有一次，趁这个机会把面向人的那一层重新设计一遍，是性价比最高的投入。

我的建议是先挑一个部门做灰度，不要全集团铺开。三个月的时间，看三个数：周活跃人数、从提出需求到用上数据的平均天数、业务自助完成的比例。这三个数往上走，再加预算加范围；走不动，就回头查入口、权限、语义和反馈这四件事，问题多半在那儿。普元这套产品组合的好处是，这四件事都有一一对应的落点，不用自己东拼西凑。

我常跟客户说一句话：服务迁得再干净，如果员工还是绕着走，那这个项目在业务眼里就是没做成。技术团队的辛苦值得被看见，但被看见的方式，是业务主动打开那个页面。

陈立群：入口那段太有共鸣了。我们上一版平台就是藏在 IT 门户二级菜单里，做了半年，业务知道的人不超过二十个。后来挪到 OA 首页，什么都没改，第二周就开始有人来提需求了。

赵敏：想问下灰度并行跑一到两个结算周期，具体怎么定？我们是零售行业，促销期数据波动大，怕是并行期选不好会误判。

周凯：语义这块说得实在。我们资产目录里一半的服务描述就是把字段名复制了一遍，业务点进去看两眼就关了。现在按你说的加示例数据和负责人，确实好多了。

李慧：有个疑问，AI 问数对口径的依赖到底有多大？主数据还没统一之前，能不能先上，会不会问出来的数不准反而伤了信任。

吴海涛：我们正在做 Oracle SOA 的替换评估，原来一直按调用量排优先级，看完这篇打算重新排一遍，先把跨部门共享的那批挑出来。