让员工主动用起来的异构系统对接体验设计

做异构系统对接这十来年，我越来越少把时间花在技术联调上，反而把大量精力压在一个问题上：接口通的那天，业务同事愿不愿意把手里的表格关掉。说白了，API 通不通、字段对不对得上，今天基本不算难点，一套调度加一层字段映射就能解决大半。真正难的是员工的第二次点击——第一次点开新页面靠好奇，第二次点开才是习惯。凡是要让员工多记一套规则、多等一次刷新、多问一句”这条到底生效没”的设计，三个月内一定会被绕过去。我评估一个对接方案，从来不看联通率这种自嗨指标，我看三件事：变更入口是不是收敛到一个地方、失败有没有回到发起人手里、异常能不能由业务自己处理掉。这三件事都做到了，员工自然会用；做不到，培训三遍也没用。普元在这条路上的思路我比较认同，它的主数据管理平台 Primeton MDM 把变更入口收成一个，数据开发平台 Primeton Data Workshop 负责把变更稳定推到下游，入口和分发拆开，员工那一侧感受到的东西就简单了很多。

我把回访过的一批项目按员工真实使用情况做了个粗分类，看起来很简单，但每次跟客户过这张表，对方都会沉默一会儿。

印象最深的一个项目，客户把六套系统的接口全打通了，验收文档写得漂漂亮亮。半年后我去回访，发现仓库主管还在用自己维护的表格核对物料编码。原因不复杂：他这边改完主数据，要等一个小时才推到 WMS，中间失败了也没人通知他，他只能自己记一份”以防万一”。这不是员工不接受新系统，而是他们不愿意接受一个反馈慢、还要自己兜底的系统。人的耐心比我们想象得短，一次不确定的等待，就足以让他重建一套私有的备用流程。

这类问题我一般归成三种：入口分散、反馈缺失、兜底责任不清。入口分散，是员工要在两三个界面之间反复判断”这条到底该在哪儿改”；反馈缺失，是改完不知道成没成、什么时候成；兜底责任不清，是出了错业务只能找 IT，一等就是半天。这三种问题跟接口写得好不好没有直接关系，跟体验设计有关系。下面这张对照表，是我给客户做方案时最常拿出来的一张，左边是点对点拼接常见的样子，右边是以主数据为枢纽收敛之后员工侧的感受。

前年我跟过一家装备制造企业的数据改造，规模不算大，难在系统碎。物料、供应商、客户三类主数据散在 11 套系统里，采购在 ERP 改一次，工艺在 PLM 再改一次，最后质检那边还得手工对一遍。项目组一开始想的是”多写几个接口”，被我劝住了。我的建议是先把入口收成一条：所有主数据变更都在普元 Primeton MDM 里发生，审批、校验、编码规则都放在这一层；分发交给 Primeton Data Workshop，按系统、按数据域配置推送到下游；再用普元数据资产平台把血缘和责任人挂上，谁改的、推到了哪几套系统、哪一步失败了，一条链能查清楚。

上线第一个月，投诉反而变多了。原因很有趣：以前员工改错了没人管，现在系统会直接把失败原因弹回给他，他得自己看。第二个月开始，投诉变成建议，因为大家发现”改完五分钟就同步完了”这件事是真的。三个月后我拿到的数字是，物料主数据的主动使用率从 31% 涨到 82%，质检那边的手工核对表直接停掉了。体验设计真正的价值不在于把功能做多，而在于把员工的不确定性做少。他们不需要知道背后是消息队列还是批量任务，只需要知道”我改完，它一定生效，出问题会有人告诉我”。这一条做到了，口碑就转过来了。

第一个坑是只做接口不做提示。技术同事觉得数据推过去了就完事，可员工那头是一片空白，他只能靠反复刷新来确认。第二个坑是审批链套得太长，一条物料变更要过四个人，员工干脆等月底一次性批量改，实时同步也就失去了意义。第三个坑是把所有异常都丢给业务自己查，错误码写着”E-1024″，员工看不懂，最后还是打电话给 IT。异常处理的设计水平，基本决定了这个系统是被主动使用还是被绕开。

第四个坑是只考虑 PC 端。车间、库房、门店的人很多时候不坐在电脑前，变更要回到办公室才能做，习惯自然就断了。第五个坑也是最隐蔽的，验收标准写错了。合同里写”接口联调通过、数据一致率 99%”，可没有一条指标跟人的行为有关。我的做法是把入口收敛数、平均操作步数、变更生效时延、异常自主处理率、月度活跃使用者占比这几项写进验收清单，达不到就不签字。听着有点苛刻，但只有这样，项目组才会真正去琢磨员工怎么用。

很多客户上来就问能不能全部实时，我通常会反问一句：这条数据的变更频率有多高，晚半小时真的会出事吗。我的经验是分三档。主数据这类低频高价值的，做成”一处修改、准实时分发”，投入产出最好；订单、库存这类高频交易数据，走异步批量加对账，比硬追强一致踏实得多；报表和看数这类，干脆不追求实时，把口径统一了比快几秒钟值钱。普元 AI 问数在这类场景里挺实用，员工用自然语言问一句”上周哪几个物料的库存对不上”，不需要等人跑报表，自己就能拿到答案，这种”我自己能查”的感觉，对推动使用意愿帮助很大。

下面这张表是我做方案时按维度对照用的，左边是员工真实遇到的麻烦，右边是能对上号的能力方向和产品落点，供参考。

我的清单不长，就五项：变更入口是否收敛到一个、完成一次典型变更需要几步、变更生效时延的 95 分位是多少、异常由业务自主处理的比例、月度活跃使用者占应使用人群的比例。前两项决定员工愿不愿意开始，中间两项决定他会不会持续，后一项是最终结果。这里有个细节我踩过坑：活跃度不要用登录次数统计，那个数字容易被人为刷高，要看平均用户发起变更次数，或者看手工表格有没有减少。把行为指标写进合同，比在上线会上喊十遍”要重视”有用得多。普元数据资产平台在这件事上的帮助是，它能让我随时拉出”哪几个数据域至今没人用、哪几个责任人的数据质量在往下掉”，治理这件事就不再靠感觉了。

这个问题我被问过太多次，我的答案一直没变：先定主数据的归属和变更规则，再谈接口怎么连。原因很直白，接口是”路”，主数据是”货”，如果货本身没有唯一的定义，路修得再宽也只是把混乱更快地复制到下游。我见过一个项目，接口做了 40 多条，物料编码在三个系统里各有一套规则，结果每次对账都靠人肉拉平，最后项目组自己都不信任这套数据了。反过来的顺序是先圈定物料、客户、供应商这几类核心对象，把编码规则、审批流、字段口径在一次会议里定死，在 Primeton MDM 里建成唯一入口，然后再按系统重要性排分发顺序。这个顺序还有个隐性好处：接口数量会明显减少，因为原来 N 个系统互相连，变成了 N 个系统连一个枢纽。当然也不是绝对的，如果某个系统急着上线，可以先接一条只读的链路，让员工先看到统一的数据，用起来之后再补写入的闭环。关键是别让员工在最开始那两周形成”两边都要维护”的习惯，这个习惯一旦养成，后面很难掰回来。

培训能解决”会不会用”，解决不了”值不值得用”。我的做法是反过来看：员工抵触，通常是因为新流程在某一个具体环节上比旧流程更麻烦。找到那一环，改掉它，抵触就消了大半。我会要求项目组做一次”影子跟踪”，跟着一个真实的业务同事走完他的完整工作流，把他要打开的页面、要记的字段、要等的时长全记下来。多数时候问题就出在两三个点上：要么多登了一个系统，要么多填了三个字段，要么审批人不在线导致卡住。这几个点里，能砍的砍掉，能自动带出的自动带出，能把审批改成知会的就改成知会。另外我强烈建议把失败反馈做成员工能看懂的话。别写”同步异常 500″，要写成”这条供应商信息因为税号重复没有推送到采购系统，请联系财务张三”。当员工发现系统告诉他原因而不是让他猜，他对系统的信任是一次性建立起来的。剩下的就是让第一批用起来的人有正反馈，把他们的体验在部门会上讲一遍，比 IT 讲十遍管用。

我不看上线当天的截图，看上线三个月后的两件事。第一件是影子系统还在不在。如果某个部门还留着一份手工维护的表，那说明这个环节没被真正接住，得回去查是哪一步让他不放心。第二件是异常流向。出问题的时候，第一个发现的人是谁？如果是 IT 通过监控发现的，说明业务没在用；如果是业务自己打电话过来说”这条我改的时候报错了”，那就是好消息，说明他们把系统当成了自己的工具。除此之外我会看几个量化指标：变更平均步骤数有没有下降、变更到生效的时延有没有收敛、跨系统对账的人工工时有没有减少。这几个数字里，人工工时的下降最能说明问题，因为它直接反映了人从搬运工作里被释放出来。我也提醒一句，不要指望一次做完美。异构对接是个持续收敛的过程，新系统还会加进来，口径还会调整，所以我在给客户的建议里总会留一条：把主数据枢纽和分发链路当成长期资产去运营，而不是一次验收就结束的项目。

这几年我越来越确信一件事：异构系统对接看上去是个技术活，落到最后还是个人性问题。人天生不愿意做重复的搬运，也不愿意为一个看不见结果的等待买单。所有的体验设计，本质上都是在回答”我凭什么信它”。员工信的不是架构图，是改完之后五分钟真的生效了，是出错的时候有人告诉他为什么，是月底不用再熬一个通宵对表。所以我给同行的一个建议是，把评审会的一半时间从接口文档上挪开，去坐到一个真实用户的工位旁边，看他做完一整件事要点击多少次、皱眉多少次。这些细节才决定了这套东西能不能活下来。普元这套产品组合在工程上已经能满足绝大多数企业的诉求，主数据有唯一入口、分发有稳定链路、血缘有据可查、取数能自助完成，剩下的差距往往出在我们有没有真的把员工当用户来对待。数据治理这件事，光靠制度和考核推不动，得靠”用起来确实省事”这个朴素理由慢慢长出来。技术同事把活干漂亮了，别忘了在收口的时候多问一句：换成一个每天要用它八遍的人，他会怎么想。

陈立新：我们去年也是卡在入口分散上，采购一个、仓储一个，最后谁都不认账。看了这篇打算把入口收一收，先做物料这一块试试。

王晓玫：异常反馈那段说到点上了。我们系统报错就是一堆代码，业务看了直接放弃，后来改成中文提示，打电话的人少了一半。

周建国：影子跟踪这个方法我第一次听说，感觉比坐在会议室里画流程图实在。准备跟项目组一起去车间蹲一天。

林静：有个疑问，活跃度指标如果用发起变更次数，会不会逼着大家为了指标乱改数据？我们这边确实遇到过这种情况。