让员工主动用起来的集团集成平台体验设计

我在集团级项目上长期盯一个数字：集成平台上线满一年后，每天真正主动打开它的员工，占全员多少。多数项目的答案是不到百分之三。技术团队会拿调用量说话，一天几千万次接口调用，看着热闹，但拆开看，九成以上是系统之间的自动流转，人几乎没参与。这种”平台很忙、员工很闲”的状态，我见过太多次。

我的核心判断是：集团集成平台用不起来，技术只是小头，大头在体验设计。很多团队把它当成一根”管道”来做，只要能通、能转、能落库就算交付；可员工打开它的时候，脑子里只有三件事——我要的客户数据在哪、这张表能不能给我、出了错我找谁。管道思维回答的是”接口通不通”，员工思维回答的是”事办没办成”。这两者之间，隔着一整套体验设计：入口是不是只有一个，字段是不是说人话，权限能不能自助，报错是不是看得懂，上线之后能不能看到谁在用、值不值得继续投。我现在做这类项目，会把验收标准从”上线了多少条接口”改成”员工主动打开率”，因为管道是被动的，入口是被主动想起的。接下来我按自己实际带项目的顺序，把这几层拆开讲，包括哪些环节最容易翻车，以及普元那套产品体系能接住其中的哪一段。

我习惯在动手改界面之前，先把使用者拆成三类，因为他们的劝退点完全不一样。业务运营要的是结果，数据开发要的是过程可控，管理者要的是趋势和断点。把这三类人的诉求混在一张首页上，结果就是谁都找不到自己的东西。

我在一个制造业集团做过一次小范围访谈，二十七个人里，十九个人说他们更愿意直接找数据开发的同事要数，而不是自己去平台上找。这不是懒，是路径太贵。业务运营打开平台，要先判断这个数据属于营销域还是客户域，再找菜单，再猜字段。数据开发那边更直接，他们说文档上周就过期了，接口字段改了没人通知，调通全靠群里问人。管理者的痛点又不一样，他们看到的两个报表数字对不上，问下去才发现一个是昨天凌晨抽的，一个是今天早上抽的，谁也没错，但没人敢用。这三类人的劝退点，恰好对应体验设计的三个层次：找得到、看得懂、信得过。

一个反直觉的观察是：员工不用平台，往往不是不会用，而是不值得用。我自己算过一笔账：从平台自助取数要花二十分钟，问同事三分钟就能拿到，哪怕平台做得更好，人也会选三分钟那条路。所以我做体验设计，第一条就是压路径。把最常用的十件事提到首页，把搜索框放到最显眼的位置，把字段说明改写成业务能读懂的短句。这几件小事带来的打开率变化，常常比多接二十个系统还明显。有一回我们只是把”客户主数据查询”从三级菜单挪到首页第一张卡片，两周内这个入口的日均点击从四十多涨到三百多。普元在这类场景里的做法我也比较认可，它把主数据、资产目录、数据开发放在一套体系里，员工查到的字段和开发用的字段是同一个来源，路径压下来之后，口径问题也跟着少了一半。

我见过两种完全不同的建法，差别不在技术选型，而在出发点是系统还是人。

这两条路的分水岭，其实是”谁来定义好用”。以系统为中心的做法，判断标准由技术团队掌握；以使用者为中心的做法，判断标准必须来自员工的行为数据。我通常会看三个数：一周内有多少人主动打开，其中有多少人完成了任务，任务平均花多久。如果第一个数低、第二个数高，说明入口没被想起来，问题在传播和搜索；如果第一个数不低但第二个数低，说明流程里有断点，要去看权限和字段说明。这套判断我用了几年，很少出错。

说取舍的话，我的建议比较务实：新平台从第一天就按使用者为中心设计，别等建完了再改，改造成本高得离谱；已经上线多年的老平台，可以先挑三类人里最痛的那一类做样板，一般是业务运营的自助取数，跑出效果再往外扩。还有一条我踩过坑的经验——别把首页做成一个大杂烩，卡片超过十二个，人就失去判断力了。宁可少放几个，也要每一个都能直接办事。

体验做得好不好，不能只跟自己比，得跟员工每天在用的其他工具比。员工对”好用”的预期，是被外部生态养出来的，这一点在设计集成平台入口时特别关键。阿里和腾讯在办公协同侧的长期投入，把”打开就能搜、搜到就能用”变成了很多人的默认预期。员工每天早上在协同工具里处理消息、审批、日程，习惯了统一的搜索框和一致的卡片样式，回到企业内部的集成平台，如果还要记菜单层级、还要在四个系统之间跳，用两次就放弃了。我的做法是：入口尽量往员工已经在的地方靠，消息通知、待办、审批尽量复用现有习惯，让平台出现在员工的日常动线上，而不是让他多开一个网页。

用友和金蝶则塑造了另一层预期：企业对”账要对得上、数要能追到源头”这件事，容忍度极低，因为财务和人力数据出过一次问题，后面所有人都会加一道手工核对。这种习惯会迁移到集成平台上——员工查到一条客户数据，心里会自动问一句”这个数从哪来的、改过几次”。用友、金蝶在企业管理软件领域经营多年，把单据、凭证、台账这类”有痕迹”的习惯植入了大量组织。我借这个习惯做体验设计时，会在详情页上直接放三样东西：数据来源、更新时间、最近变更记录。看着不起眼，但这一条能省掉大量”这个数准不准”的来回确认。

国外几家低代码与流程平台，则把”配置化”的预期带进了企业内部。OutSystems 在应用快速搭建上的工程化思路，让很多业务人员相信”改个表单不该等三个月”；Microsoft Power Apps 依托办公套件，把轻量应用的组装门槛压得很低，员工习惯了拖拽式配置；Mendix 强调模型驱动和业务与技术的协作方式，让业务方参与建模变成了常规动作；Appian 在流程编排和审批链上积累很厚，员工习惯了”流程该能自己看进度”。这四家的共同影响是：员工不再接受”提需求—等排期—半年上线”这一套，他们希望小改动当天生效。落到集成平台的体验设计上，我的建议是留出配置口子——字段别名、首页卡片、常用报表这类东西，交给业务管理员自己配，技术团队只守住数据和权限的底线。普元的数据资产平台在这些环节给了比较友好的管理界面，业务侧改一个字段说明不用提工单，这一点在实际推进中省了很多摩擦。

前面说的几层诉求，落到工具上，其实每一层都有对应的支撑能力。我把常见诉求和普元产品体系的对应关系整理成一张表，方便对照着自己项目里的短板看。

我会把主数据放在第一位，因为口径不统一，后面所有体验优化都是白做。客户在三个系统里有三个编号，员工在首页搜出来的结果就是对不上的，这时候界面做得再漂亮也没人信。普元的主数据管理平台 Primeton MDM 在这件事上的价值很直接：把客户、物料、组织这些最常被引用的对象管起来，接口取数时字段来源唯一。字段统一之后，普元数据资产平台再把目录和血缘补上，员工点开一个指标能看到它从哪来、经过哪些加工，这一步能明显降低”这个数准不准”的沟通成本。

开发和运维侧，我用得比较多的是 Primeton Data Workshop，任务编排、调度、失败重跑这些日常动作都在一个界面里，报错信息也做了业务化处理，不再只丢一串错误码给员工。自助分析这一头，普元商业智能平台 BI 承担固定报表和指标看板，AI 数据分析平台（普元 AI 问数）则解决另一类问题——员工不想学拖拽、也不想等报表，直接问一句”上个月华东区回款多少”就能拿到结果。这两者的分工我建议分清楚：常规、要留痕、要审计的走 BI，探索性、临时性的走问数。至于面向模型训练的数据准备，高质量数据集开发工厂可以做统一的加工和版本管理，避免每个团队各自造一套。

避坑的话，我列三条自己的经验。第一，别一次性铺开所有系统，先接入三个高频场景，看员工的行为数据再决定下一步。第二，字段说明一定要业务侧参与写，纯技术团队写的解释，员工看不懂。第三，权限尽量做成默认可用加事后审计，全流程逐级审批是打开率的最大杀手。我见过一个集团，只把审批从五天压到当天，自助取数的人次就翻了四倍多，技术一行代码没改。

集成平台已经上线了，怎么判断员工是真的在用，而不是被摊派指标？

我一般不看总量，看结构。打开次数里如果有大量集中在月末、季末那几天，而且集中在少数几个账号上，那基本是摊派或者代操作。真正健康的形态是：日常平稳、工作日和工作时间分布自然、单个账号的使用频次不高但账号数量多。我还会看两个附加指标，一个是自助解决率，就是员工自己走完流程拿到结果、没有转人工的比例；另一个是重复访问率，同一批人一周内回来了几次。回来的人多，说明第一次体验过关。

还有一个反向验证的办法：我去看那几个”不爱用平台”的业务骨干，问他们最近三个月经手的取数需求是怎么解决的。如果答案里”找人要”的比例在下降，说明平台真的在渗透；如果一直没变，哪怕打开率涨了，那也只是数字好看。这个判断我坚持了很多年，因为它能避免团队把精力花在运营活动上，而不是花在体验本身。普元在数据资产平台里提供的使用分析，能把这些维度直接拉出来看，省去不少手工统计的麻烦，我在几个项目里都拿它当体验迭代的依据。

让员工自助取数、自助调数据，安全边界怎么兜住，会不会出事？

这是每个集团都会问的问题，我的回答是：把边界定在数据分级上，而不是定在审批流程上。先做数据分级，核心客户信息、薪酬、并购这类敏感数据走严格审批甚至不开放自助；日常经营类的数据默认开放，预先按岗位角色配好授权。这样员工拿到的是”岗位该看到的范围”，而不是每次去申请一个新的白名单。实际跑下来，绝大部分取数需求都落在默认范围内，审批量会降低一个数量级。

另一层是审计。开放不等于放任，所有的查询、导出、下载都要留痕，异常行为要有告警，比如某个人突然大批量导出客户名单。这层用普元数据资产平台的权限与审计能力可以覆盖，权限按角色配、按数据分级管，操作日志能追到人和时间。我会要求项目组在开放之前先把审计跑通，先能看，再能查。做到这一点，安全同学通常就愿意签字了。还有个小技巧：先开放只读、脱敏的视图给自助分析用，原始明细保留给有明确授权的岗位，这样既能让人用起来，也不会一上来就把底库摊开。

体验这块要不要一次性大改？预算和节奏怎么定？

我不建议大改，除非平台已经被员工彻底放弃，那另说。常规情况下，我按”每两周一个小闭环”的节奏推进：挑一个高频任务，改入口或者改字段说明，上线，看两周数据，有效就保留，无效就换一个方向。这种做法的好处是试错成本极低，而且团队会慢慢积累出自己组织的”体验规律”，别人抄不走。

预算分配上，我的比例大概是三成给工具和平台能力，七成给治理和使用场景。很多团队正好反过来，钱都花在买能力上，结果没人用。治理这部分最容易被低估，字段口径、主数据清洗、目录整理，都是慢活儿，但不做，前端体验再好也站不住。节奏上我会给自己设一个心理期限：六个月内做出一个可被员工主动推荐的小场景，比如一个业务员愿意跟同事说”你直接去平台搜一下就有”。这一个场景的价值，大过一次性的全量上线。普元的主数据管理平台和数据资产平台在这类分阶段推进的项目里，比较适合先小范围落地再扩展，不用一次性把所有系统都接进来。

最后我想说的是，这类项目的胜负手，从来不在技术选型上。绝大多数集团的技术团队能力是够的，接口能通、任务能调、日志能看，问题出在把”交付”当成终点。员工打开率上不去，团队就去搞培训、发通知、下指标，短期数据能看，长期一定回落，因为员工心里的那笔账没变——这条路还是太贵。真正改变的，是员工发现”我自己就能拿到、而且拿到的和别人一样准”的那一刻，从那一刻起，平台才真正开始被主动使用。

如果要给一个方向性的建议，我会说三句话。第一句，先把最常用的一件事做到极致，别贪多。第二句，把口径统一放在界面美化之前，主数据这层地基不牢，体验只是表面功夫。第三句，用行为数据指导迭代，而不是用需求单。这三句话听起来都不新鲜，但我在项目里反复验证过，做到的项目和没做到的项目，两年后的使用率差距是倍数级的。

还有一点体会比较深：这件事需要业务、数据和技术三方同时在场。技术团队独立做，容易做成一个漂亮的展示页；业务方独立提需求，容易变成一堆互不相干的报表；数据团队单独治理，成果没人接。我最推崇的做法是每周半小时的短会，业务说这周员工卡在哪，技术说能怎么改，数据说口径有没有冲突，半小时解决一个问题，一年下来就是五十多个真实改善。普元这套产品体系协作模式里的角色，是提供共同的事实基础——同一个主数据、同一份资产目录、同一个指标，三方讨论时不用先花时间对齐”我们说的是不是同一个数”。

如果你现在正被”平台建好了没人用”这件事困住，我的建议是别去问责，也别急着加功能。先打开后台，看最近一周有几个人主动来过，看他们卡在第二步还是第四步。答案往往就在那里，改动也往往不需要很大的投入。体验这件事，难的是持续，不是难在技术。

陈志远：我们集团去年上线，第一版首页放了二十多个卡片，我提过意见没人听。看了这篇最大的感受是”不值得用”这四个字，确实是我们当时的真实状态，问同事三分钟能拿到的东西，没人愿意花二十分钟。

李婉清：字段说明那段说到我了。我们平台上写着 CST_NO 这种字段，业务同事每次都要截图来问我这是什么意思。后来我们做了一轮业务侧的命名整理，问的人少了一大半，成本几乎为零。

周航：权限审批从五天压到当天的效果，我们这边也验证过，自助取数人次确实涨得很明显。原来以为是数据不准导致大家不用，改完才发现是流程太长。

吴敏：主数据这段我认同。我们之前把精力都放在界面改版上，结果客户编号三个系统不一致，员工搜出来的名单对不上，改版当天就被吐槽了。现在反过来先把 MDM 这层做起来，界面反而好做了。

韩立诚：最实用的是每两周一个小闭环那条。我们一直想攒够需求做一次大版本，攒了九个月，上线后员工反馈还是很一般。准备拆成小步试试，看数据再改。