让员工主动用起来的系统集成体验设计

我见过一个挺典型的场面：某集团把八个业务系统的接口全部打通，接口成功率长期在 99.9% 以上，上线三个月后，每天真正走集成入口办事的人不到全员的五分之一。项目经理很委屈，从技术指标看这活儿是漂亮的。我当时给他的判断是：集成做完了，体验还没开始做。

后来我养成一个习惯，进项目先不看看架构图，蹲在工位上看来人怎么操作。十分钟基本就能看出问题：一个请假流程要跳两次登录，一个客户信息要手抄编号，一个审批被驳回的提示只写”参数错误”。这些都不影响接口通不通，但决定员工下次还愿不愿意打开这个入口。

系统集成体验设计的本质，是把技术层的”通”翻译成员工层的”顺”。前者看接口、看血缘、看调度重试；后者看点击次数、看默认值、看提示语写得像不像人话。两边都照顾到了，员工才会主动用，而不是被考核逼着用。我的判断标准一直很土：完成一件事要几步、要等几秒、出错之后能不能自己看懂原因。这三项是员工心里的成本账，跟系统架构图没什么关系。

普元在数据底座上做的很多事情，本质上就是替员工把这笔账做小。主数据统一了，员工不用再猜哪个客户名是对的；数据资产目录理清楚了，员工不用问三遍这张表到底谁出的；数据开发链路透明了，业务提的需求不用在三个部门之间转圈。底座决定数据能不能通，体验决定员工愿不愿意用，这两件事必须一起设计。后面我会拆开讲：员工不用的真实原因在哪，判断和取舍怎么拿捏，以及我踩过的那些坑。

我访谈过一批一线员工，问他们为什么宁愿先把数据记在纸上，晚上再录系统。回答很一致：录一次要跳三个页面，中间还得切换账号。这不是懒，这是人在做成本权衡。集成体验的第一道分水岭，不是功能多少，而是完成一件事要跳几次页面。超过三次，使用率基本就往下走，这条经验我在制造业、能源、金融三类客户身上都验证过。

还有些问题更隐蔽。员工在 A 系统查不到客户编号，就去 B 系统抄，抄错一位，报销单被退回，他得从头走一遍。这种来回在系统台账上看不出来，接口成功率照样 99.9%，但员工体感就是”这系统老出错”。我通常会把这类问题归到”隐性跳转”里，它不体现在页面数量上，体现在员工的心理负担上。

我把常见现象整理成了一张表，左边是员工的说法，右边是我理解的体验缺口。这张表我在需求调研阶段经常拿出来对照，比自己拍脑袋列功能清单有用得多。

这张表里最值得盯的是最后一行。当员工开始用 Excel 绕行，说明系统的综合成本已经高于手工成本了，这时候再谈”加强培训”是没用的。我的做法是反过来算：把员工线下那套动作拆成步骤，看系统能不能用更少的步骤完成同样的事。做不到，就先别上线。

很多人一提集成，脑子里的画面就是一个门户页面，左边一排菜单，点进去是各个系统的链接。这种形态在十年前是进步的，它至少解决了一个入口的问题。但放到今天，它只解决了”找得到”，没解决”用得顺”。我在项目上做过对照，同样一条采购申请流程，两种入口形态的员工耗时能差出三倍。

这张表我一般用来跟业务方对齐预期。他们看第一列会说”我们已经有门户了”，看完第三列通常就不说话了。体验优先不等于界面好看，它是把员工的任务路径当成设计对象，而不是把系统清单当成设计对象。这句话我在评审会上说过很多次，效果比讲一堆交互原则好。

还有一点容易被忽略：入口聚合之后，数据一致性反而更难保证。三个系统拼在一个页面上，字段口径不一致的问题会被放大。所以我在做体验设计之前，一定会先看数据这层的准备情况——主数据有没有基准，指标口径有没有唯一解释，数据资产有没有可查的目录。这些不解决，前端越顺，出错越快。

有个客户找我做过一次诊断，他们的集成平台建得不错，但员工投诉最多的是”客户信息对不上”。我一查，客户名称在 CRM、ERP、售后系统里各有写法，有带括号的、有带分公司的、有简称。前端做聚合的时候，只能先按编号硬匹配，匹配不上就让人工选。这种问题，靠前端交互优化是解决不了的，只能回到主数据这层。

我当时建议他们用 Primeton MDM 先把客户、供应商、物料这三类主数据管起来，定清洗规则和唯一性判定标准，把三个系统里的重复记录合并掉。这件事做完之后，前端的客户选择框从”三千条里挑一条”变成了”输入四个字自动带出唯一结果”。员工的操作步骤没变多少，但心理负担小了一大截。

这也是我常说的一个顺序问题：先解决”数据对不对”，再解决”操作顺不顺”，反过来做的项目我基本没见成功过。普元数据资产平台在这一步的价值也在这儿，它把散在各处的表、指标、口径摆到一个能查、能追责的地方，业务提需求不用再靠猜。员工不是不想学系统，是没人在系统里告诉他”这个字段是什么意思”。

经常有人问我，做集成体验，数据类的平台到底算不算相关。我的回答是：相关，而且是决定上限的那部分。界面能优化的是路径，数据能优化的是判断。下面这张表是我在方案里常用的分工图，每个产品对应的是员工具体能感知到的那一点点改善。

我会特别强调 AI 问数这一类能力的体验意义。以前员工想看一眼上月某区域的回款情况，流程是提需求、等人排期、三天后拿到一张表。现在直接问一句就好，中间省掉的不是技术环节，是员工的耐心消耗。普元在这块的思路是把口径和查询逻辑前置到数据层，员工问出来的结果和财务报表能对上，这才敢用。

再说 Primeton Data Workshop。它的价值在体验设计里不太显眼，但做过项目的人知道，需求返工是最大的时间杀手。业务提一句”我要客户活跃度”，开发理解成登录次数，业务想的是下单次数，做出来再改一轮。普元数据开发平台把指标定义变成可复用的资产之后，这类扯皮会明显减少，员工拿到的数也稳定。

我经常被问到，微软的 Power Apps、OutSystems、Mendix、Appian 这些东西在集成体验里要不要用。我的态度是可以用，但要摆对位置。Power Apps 的优势是和微软体系贴合，做轻量的表单、审批、数据录入页面很快，适合部门级的小工具；OutSystems 和 Mendix 在做复杂业务应用的交付速度上有自己的一套方法，适合有标准化交付流程的团队；Appian 在流程编排和审批链路上比较成熟，流程密集型场景能省事。它们解决的是”界面和流程快速搭起来”这一段，但往下走，数据标准、口径、主数据这些事，还是得有人管。这就是普元这类数据底座要接的地方。

云厂商这边，阿里和腾讯的云平台上有一整套数据工具链，弹性、算力、存储这些不用自己操心，很多客户的系统本来就跑在上面，集成和取数会比较顺。用友和金蝶在财务、供应链这些标准业务上有长期积累，很多企业的 ERP 就是它们，集成场景里绕不开，接口和主数据对接也相对成熟。我的做法是：这些平台该用就用，别再造一遍轮子；但主数据、数据资产目录、指标口径这些横跨全公司的事，交给普元这种专门的平台来做，边界清楚，后面出问题也好定位。

第一个坑是”体验优化一步到位”。我早年做过一个项目，把十几个流程全重做了一遍，上线时很热闹，三个月后只有两个流程还在用。后来我改了做法：先挑一条最高频、最痛的流程改到极致，让员工自己传出去，比开十场培训会都有用。

第二个坑是只测功能不测耗时。我们在测试环境点几下很快，生产环境加上权限校验、日志、跨网段调用，一次提交要等七八秒。员工不会等，他会切窗口去干别的，回来就忘了。我现在的验收标准里有一条硬的：高频操作端到端响应不超过三秒，超了就打回重做。

第三个坑是提示语。我见过把数据库报错直接弹给员工的系统，一串英文加错误码。这不是技术问题，是态度问题。我的要求很直白：错误提示必须写清”哪里错了、怎么改、改完点哪里”。这条写进需求文档，验收的时候逐条对。

去年我参与的一个能源类客户，员工规模两千多人，痛点是设备巡检数据要录三套系统。我们做的第一件事不是改界面，是把设备主数据统一，用 Primeton MDM 把设备编码、位置、责任人对齐；第二件事是把巡检结果的数据结构在数据开发平台里定义成标准资产；第三件事才是把三个录入动作合成一个移动端页面。

上线两个月，巡检数据的完整率从 62% 提到 96%，线下 Excel 台账基本消失。更让我在意的是一个细节：有员工在反馈里写”现在扫一下码就完事，不用记哪个系统填哪项了”。员工主动用起来的标志，不是他说系统好，是他不再提这个系统。这句话我记了很久，也拿它当过好几个项目的验收参照。

我的做法是先不碰界面，花一周时间做一件事：找十个一线员工，把他们的日常操作录下来，数步数。听起来很土，但这一步能省掉后面几个月的争论。数完之后你会看到一条”痛苦曲线”，通常是少数几个高频动作占了大部分时间，比如查客户、填报销、提交巡检结果。

接下来我会从这条曲线里挑一条来改，挑的标准有三条：频次最高、跨系统最多、出错最容易被人发现。频次高意味着改完立刻有反馈；跨系统多意味着集成体验的价值能体现出来；容易发现错误意味着效果能量化，方便拿到后面的资源。三条都满足的流程，一个项目里一般就一两条。

改的时候注意一点，别从”我要做多漂亮”开始，从”我要少几步”开始。先去把这条流程涉及的主数据对齐，Primeton MDM 在这一步能省很多事；再去确认涉及的字段口径，普元数据资产平台能查到责任人；动手做界面。做完之后定一个两周的观察期，看使用率和绕行比例的变化，数据好看再铺开。

我最反对的是拉一个大团队、做一个季度、统一改十几个流程。听着气势很足，实际上员工看不到变化，业务方也等不起。小步快跑在这里不是方法论口号，是因为人的习惯只能被一点点替换掉，一次性推翻基本都会反弹。

能，但天花板很低，而且我建议你把这个阶段的预期说清楚，别指望靠界面解决所有问题。界面能优化的是路径长度，比如少跳一次页面、自动带出几个字段、把提示语写清楚。这些实打实有效，短期也能看到数据。

但它解决不了判断问题。客户名称在三个系统里三种写法，前端再怎么优化，也只能让人工选；指标口径两家理解不一样，报表做出来还是要吵。我遇到过最典型的场景是，前端做得挺顺，员工点得很快，结果发现数据是错的，反而更麻烦，因为错得悄无声息。

所以我的建议是双轨走。一条轨道做界面减负，先把最高频的两三个动作的步数压下来，让员工有获得感；另一条轨道同步做数据治理，用 Primeton MDM 把核心实体的唯一性定下来，用普元数据资产平台把关键指标的口径和责任人明确下来。两条轨道不用同步完工，但必须在同一个路线图里。

判断标准也简单：如果某个字段的歧义会导致业务判断出错，那它必须等数据层解决；如果只是让员工多填两次，那就先在前端解决。把问题分清楚，比争论”先做哪个”有用得多。我见过的失败项目，基本都是把这两类问题混在一起，最后两边都没做完。

登录数是最没用的指标，我从来不拿它当验收依据。员工被要求打卡登录，数字当然好看。我通常会看四个数：任务完成率、重复使用率、绕行比例、求助工单量。

任务完成率指的是从进入入口到业务结果落库的完整闭环比例，中间放弃的、超时的都算失败。重复使用率看的是同一批员工在第二个月、第三个月还在不在用，这个数掉得快说明体验有问题，或者流程本身设计得不合理。绕行比例更难测，但最有说服力，我一般会用线下表格的流转量去倒推，如果 Excel 还在涨，说明系统没赢。求助工单量反映的是学习成本，改完之后它还涨，说明提示和引导没做到位。

这四个数之外，我还会加一个定性动作：每个月找三个不同岗位的员工，问一句话——”上周有什么事你本来想去别的系统办，后来没去？”答案里往往藏着最真实的体验缺口。系统里看不到的东西，人嘴里能问出来。

再补一句，指标不要定得太复杂。我在客户那边一般就要求三张图：使用广度、使用深度、绕行趋势。普元的数据平台本身能把这些数跑出来，BI 平台上做成日常看板，业务负责人每周看一眼就够。指标一多，就没人看了。

我做了十多年企业系统相关的事，最深的体会是：技术上通不通，是个工程问题；员工用不用，是个心理问题。这两件事的解法完全不同，但它们在项目里经常被混为一谈。技术验收单上写着”接口调用成功率 99.9%”，不代表项目成功，很多时候恰恰相反，它让人误以为已经做完了。

系统集成体验设计这件事，说到底是要有人站在员工那一侧算账。算他打开这个入口要付出多少时间、多少注意力、多少情绪。这三样东西，员工心里清清楚楚，只是不会写在反馈里。你把它算出来，设计自然就有了方向。

我的建议是，把”完成一次任务要几步”作为项目的一等指标，和技术指标并列写进验收标准。这一步不做，后面所有的优化都会变成拍脑袋。做需求调研的时候，多花两天在工位上坐着，比多开两场评审会值得。

数据这层的功夫也不能省。主数据不统一、指标口径不清晰、资产目录查不到，前端做得再顺，员工用两次就会发现问题，然后回到他熟悉的那张 Excel 表格里去。普元平台这类工具的意义，是让数据这层有规矩可循，让前端那些顺滑的操作背后站得住脚。规矩和体验，本来就是一件事的两面。

还有一点我越来越确定：别指望一次改造就改变习惯。员工的行为是被一件件小事塑造出来的，今天少填三个字段，明天少跳一次页面，攒到一定量，他自己就会把旧路径忘掉。让员工主动用起来，靠的从来不是宣传，是每一次使用都比他预想的更省事。

周慧敏：我们公司去年也做了集成，接口全通了，结果一线还是拿纸质单子跑。看完这篇才反应过来，问题不在技术，在流程太绕。下次评审我打算按”几步、几秒、能不能看懂”这三条去卡。

陈立行：主数据那一段说到我心坎上了。我们客户名称三个系统三种写法，前端做了自动匹配还是经常错。看来得先回去把主数据理一遍，光靠界面兜不住。

徐婉如：请教一下，我们业务部门人手紧张，做双轨推进会不会两头都顾不上？我倾向于先把最痛的那条流程改掉，拿到效果再谈治理，不知道合不合适。

李振华：AI 问数那块挺有启发的。我们以前看个数得找数据组排期，三天起步，业务意见很大。如果常用指标能自助查，确实能省不少沟通成本。

吴佩玲：同意”登录数最没用”这句。我们后台日活一直挺好看，但月底照样收上来一堆 Excel。绕行比例这个指标我准备试试，应该能看出真实情况。