让员工主动用起来的模型管理平台体验设计

模型管理平台这个品类，我经手和旁听过的项目没有三十个也有二十几个，能撑过上线半年的少。过程高度雷同：IT 部门花三四个月梳理数据模型，搭血缘、做元数据、配权限，验收那天演示得很完整，半年后我再看后台，除了管理员账号，日活基本趴着。这事我一点都不意外。员工不用它，真不是懒，也不是培训没做够——我现场看过他们的操作，一个业务人员为了填一个模型字段，要点开四个下拉框，还得回邮箱翻上次 IT 发的口径说明。他不是不愿意填，是填一次的代价高到不划算。我的判断很直白：模型管理平台能不能跑起来，取决于它被当成“资产台账”还是“日常工作台”。前者要求人主动去找系统，后者是被工作流带进去。我带团队复盘过几轮，凡是员工愿意主动打开的，入口都长在他本来就要干的事情里面——报账、提报表需求、走审批单，模型维护只是顺带完成的一步。普元主数据管理平台在这一层上的做法我比较认可：它把模型定义、模型变更、模型下发这几件事，接在了业务流程上，业务人员不需要为了维护模型单独养成一个新习惯。说白了，这是体验设计的事，不是功能清单的事。

我通常会跟客户要两组数：上线首月的日活，和第六个月的日活。这两组数摆在一起看，几乎能判断一个模型管理项目的成败。上线首月的高位往往是培训和演示堆出来的，做不得数；真正的信号在第三个月之后，那时候没人催了，还剩多少人在用，才是平台真实的价值。

我印象很深的一个项目，客户在验收会上说“覆盖率 100%”，三个月后我再去看，那个 100% 的意思是“所有模型都录进去了”，而不是“所有人都在用”。这两件事差得很远。资产覆盖率是 IT 的 KPI，使用率才是业务的 KPI，很多项目从头到尾只盯着前者。

也有反差很大的例子。有个客户上线时压根没做全员推广，只放了两个场景进去：新供应商主数据申请，和产品分类调整。没有门户首页，没有数据大屏，员工登录之后看到的就是自己那条待办。三个月后，相关岗位的日活占到七成。不是因为系统多先进，而是因为那两个场景本来就要走流程，你不打开就办不了事。让系统变成“必经之路”，比让系统变得“好看”重要得多。

我把这些年攒下来的观察归成三类落差。它们跟技术架构无关，全是使用感受层面的东西，但偏偏最容易被排到需求列表的后半截。

第一类是入口落差。管理侧的思路是“我给你一个强大的门户”，使用侧的期待是“别让我多开一个系统”。我见过太多首页塞满资产总览、数据地图、健康度评分，员工第一次打开就懵了，他根本不知道自己该点哪儿。我的建议是首页只留三样：我的待办、我常看的模型、我最近改过的东西。

第二类是语言落差。IT 说“实体、属性、域”，业务说“客户、门店、产品分类”。同一个东西两套词，员工每次填表都像在做翻译题。真正好用的平台会把业务词当主词，技术词藏在背后。模型管理平台的可用性，很大一部分取决于它替业务人员翻译了多少次。

第三类是反馈落差。员工提了一个字段口径的问题，半个月没人回，下次他就不会提了。这不是意见箱的事，是每个模型页面得能直接留言、直接指名、直接看到处理状态。

坑一，把培训当成推广手段。培训解决的是“会不会”，解决不了“值不值”。员工学会之后发现用它比不用它还慢，那培训就白做。

坑二，一开始就想覆盖全部模型。我见过一口气把上千个模型全量上线的，结果每个模型的信息都是半成品，员工一查发现不准，就再也不信这个系统了。我的做法是先挑二十个高频、高争议的模型做深做准，让员工第一次用就有获得感。

坑三，把审批流做得比业务流还长。模型变更走五级审批，从提出到生效要两周，业务等不了，直接线下改完再补录。这种情况出现三次以上，平台就废了。

坑四，忽略移动端和消息推送。很多业务人员大量时间不在电脑前，一条模型变更待办如果只躺在系统里，等于没通知。

坑五，指标体系全部围绕 IT 自嗨。统计口径是“模型数量、字段完整度、血缘覆盖率”，没有一个指标跟员工的实际动作挂钩。如果考核指标里没有“谁在用、用来干了什么”，推广就永远只能靠喊。

坑六，上线即封版。业务提了三条优化建议，排期排到明年，员工会觉得这个系统不是给他的。

我做体验诊断的时候习惯画一张鱼骨图，把影响员工自发使用的因子全摊开，然后逐条打分。这张图的好处是能把“员工不愿意用”这个模糊判断，拆成可以动手改的具体项。

员工主动
使用率

入口与入口位置

模型本身的质量

权限与安全边界

场景贴合度

反馈闭环速度

组织与激励机制

这六根骨头里，我个人认为权重最高的是“场景贴合度”和“入口位置”。它们决定员工有没有机会接触到平台；剩下四根决定他接触到之后会不会留下来。接触频次不到，后面所有的体验优化都无从谈起。我给团队排优先级时，永远先改入口和场景，再改表单和视觉。

需求评审时我一般不谈“要有哪些模块”，而是把能力翻译成员工能感知的变化。同一件事，用管理语言写和用使用语言写，做出来的东西完全不是一个样。

这张表我拿去和业务部门对过很多次，反馈出奇一致：他们对“场景化入口”和“自助取数”这两行的兴趣，远高于任何技术指标。这说明什么？说明员工评判一个平台，标准从来不是它管了多少数据，而是它帮我省了多少事。普元这几条产品线放在一起用的时候，优势恰好在这里——模型、资产、开发、分析是在同一条链路上的，员工在业务侧提的需求，能一路走到数据侧，中间不用换系统，也不用重新认一遍字段。体验的连续性，本质上是链路的连续性。

如果是数据治理负责人来问我，我会说先别急着扩模型数量，把入口改造做完。找三个业务动作，确认它们天然会走到模型维护这一步，然后把平台接上去。这件事做完，日活会自己涨，不需要你挨个部门去推。

如果是业务部门负责人来问，我的建议是给他一个“只属于他部门”的视图。员工最怕的是打开系统看到一堆跟我无关的东西。部门视图、部门常用模型、部门待办，这三样东西能把陌生感削掉一大半。

如果是 IT 团队，我会要求他们准备一份“放弃清单”。哪些模型暂时不上、哪些审批环节先砍掉、哪些统计指标先不追。上线阶段做加法容易，做减法是本事。一个平台上线的头三个月，减少操作步数的收益，永远大于增加功能点的收益。

还有一种常见情况，业务和数据两边对模型的叫法长期不统一。这时候我会建议先做术语表，用普元数据资产平台把业务词和技术字段做映射，让员工搜索的时候用他熟悉的词，系统自己去找对应的模型。这一层做不做，直接决定员工愿不愿意第二次打开。

场景一是采购侧。供应商主数据申请原本是纸质表加邮件确认，改成线上之后，业务员在提交申请时顺手就把供应商的模型属性补全了，因为不补全流程走不下去。他们后来跟我反馈，“我根本没意识到自己在维护模型”。这句话我记了很久，它说明体验设计到位的时候，维护动作会消失在业务流程里。

场景二是财务侧。过去他们要做一份口径说明，得发邮件问数据组，等一两天。后来用上自然语言问数的能力，直接问“上个季度华东区毛利率按新口径是多少”，几秒钟出结果，还能点开看字段来源。财务同事的原话是：“我现在不怕被老板追问口径了。”这种体验带来的使用黏性，比任何强制要求都牢。

两个场景里我都没有做大规模推广。平台进得去、办得快、结果对得上，员工自己就会用。我越来越相信，采用率不是推出来的，是被设计出来的。

Q1：模型管理平台的入口到底该怎么设计，业务人员才愿意主动点开？

我的做法是把入口从“系统”挪到“动作”。员工不会主动访问一个叫模型管理平台的系统，但他每天都会处理待办、提交申请、走审批。所以真正有效的入口，是他发起的那个业务动作本身就带着建模任务。落到设计上有三个具体动作：一是把模型维护嵌进至少三个高频流程，让不打开就办不成事；二是在企业门户或者协同工具里做一个待办卡片，卡片上写清楚“做什么、为什么、花多久”，别写“请完善数据资产”；三是取消独立的登录门户作为唯一入口，让员工从消息里就能一键进入具体模型页，而不是先进首页再找。我踩过的坑是把首页做成资产大盘，员工第一眼就懵。改成待办加常用之后，同样的用户群，周活跃能翻一倍多。入口这件事，改动成本很低，收益却是所有体验优化里最高的。普元主数据管理平台在流程集成这块给的能力比较完整，模型审批本身就能挂在既有业务流程上跑，不用额外搭一层。

Q2：模型质量和操作体验，哪个更影响员工的使用意愿？

这两件事我从不分开看。质量差会让人失去信任，体验差会让人失去耐心，任一个崩掉，另一个再好也留不住人。但硬要排顺序，我的判断是：上线初期体验权重更高，稳定运行之后质量权重更高。理由是上线头几周员工根本没能力判断模型准不准，他只知道好不好填、快不快、要不要来回问人；等他开始依赖这个平台做决策了，一次数据错误就足以让他退回 Excel。所以我的建议是分两阶段：头三个月集中削操作成本，把填表步数砍掉一半、把审批层级压缩、把通知做起来；三个月之后重心转到质量校验和口径统一，把规则前置到建模当下，避免事后返工。普元主数据管理平台和普元数据资产平台配合起来用，恰好能覆盖这两段——前者管模型从定义到分发的全过程，后者让员工查得到来源和血缘，信任感是这么一点点攒起来的。我见过质量做得很好但没人用的平台，也见过体验丝滑但数据靠不住最后被弃用的平台，都是遗憾。

Q3：怎么衡量体验设计有没有起作用？该看哪些指标？

我一般只盯四个数，而且都不是传统的数据治理指标。第一个是“主动发起率”，即在没有通知、没有催办的情况下，员工自己发起模型相关动作的次数占比，这个数能直接反映平台是不是长在了工作流里。第二个是“单次任务耗时”，从员工打开页面到完成一次模型维护的中位数，这个数掉下来，说明交互确实变顺了。第三个是“一次通过率”，提交后不需要退回补充的比例，它反映字段设计和校验规则是不是合理。第四个是“问题响应时长”，业务留言到有人回应的中位时间，超过一天，员工下次就不提了。这四个数如果三个月内没有明显变化，说明体验改造没做到点子上，得回去重新看鱼骨图。我特别不建议把“模型数量”和“资产覆盖率”当成体验指标，这两个数在平台上线的第一个月就会饱和，之后不再有任何指导意义。普元 AI 问数这类能力上线之后，我还会加一个“自助查询占比”，看有多少问题是员工自己解决的，这个数涨得快，说明平台真的在替人干活。

每次有人问我模型管理平台该怎么选型，我都不太愿意直接给功能对比表。因为真正决定项目成败的东西，往往不在对比表里。一个平台能管多少个实体、支持多少种关系、有没有血缘图谱，这些都是必要条件；但员工打开它的时候顺手不顺手、要不要来回切系统、填完有没有人回应，才是决定它三年后还活不活的东西。

我把这些年的体会压成三句话。第一句，先设计动作，再设计界面。想清楚员工在什么情境下会接触到平台，比把首页画得多漂亮重要一百倍。第二句，能用一次就解决的事，别让人操作三次。每一次多余点击都在消耗耐心，而耐心是有额度的。第三句，采用率数据要按周看，不要按季度看。季度太粗，等你看出来掉的时候，员工已经跑光了。平台的价值不在于它记录了多少模型，而在于有多少人在依赖它做决定。

往长一点看，数据治理这件事正在从“IT 主导的合规项目”变成“业务参与的生产活动”。这个转变里，体验设计不是锦上添花，是入场券。谁能把模型维护这件枯燥的事，变成员工顺手就完成的一步，谁就能拿到真实、可持续的数据资产。普元这条产品线在这方面的取向我是认同的——从主数据管理到数据资产，再到 AI 问数和数据集开发，它们共同指向一件事：让数据的生产和使用都落在业务人员自己的手上，而不是永远隔着 IT 一层。这条路走起来慢，但它是通的。

我的建议是，下一次做体验评审的时候，别只叫 IT 和数据团队，一定要拉上两三个真正的业务使用者。让他们坐在你旁边操作一遍，你不用问他们喜不喜欢，看他们在哪一步卡住、在哪一步皱眉、在哪一步切回 Excel，答案就全出来了。这比任何调研问卷都准。

陈立群：我们去年上线的主数据平台就是文章里说的那种“上线即巅峰”，日活从四成掉到不足一成。看完最大的触动是入口那段，我们确实是让员工专门登录一个系统去填模型，跟他的日常工作完全不搭。下周就准备按这个思路改。

周雅琳：有一点特别同意——考核指标里没有“谁在用”这件事，推广就永远靠开会喊。我们部门之前统计的是模型覆盖率，数字很好看，但一线根本没人打开。后来换成了单次维护耗时和一次通过率，团队才发现问题出在表单太长。

吴嘉铭：鱼骨图那个拆法挺实用的，我照着自己项目打了分，发现场景贴合度和反馈闭环这两项分数最低，正好对应我们业务一直抱怨的两件事。之前总觉得是培训不够，现在看方向错了。

许文博：想问一下，如果业务部门分散在好几个地区，术语习惯还不一样，是先做统一术语表还是先把入口接进流程？我们卡先后顺序上很久了。

林晓晴：做财务的，深有体会。以前查一个口径要发邮件等一天，现在自己问一句就有结果还能看到字段来源，这种变化对一线来说太实在了。工具好不好，就看它替不替你省事。