让员工主动用起来的iPaaS平台厂商体验设计

做数据集成项目的陪跑这些年，我见过太多次同一种情形：选型阶段技术评测分数很高，POC 也跑通了，接口联调顺，性能压测没毛病。半年后我回访，平台上的活跃账号只剩三个——两个是集成团队的开发，一个是运维值班的同事。业务侧的人早就不登录了，做好的连接器和流程模板躺在库里落灰。

后来我把评估顺序换了一下。先不问能接多少种数据源，先问一句：员工第二天还愿不愿意打开它。这问题听着软，实际最硬。功能清单是给采购看的，登录频次才是真需求。一个没人用的集成平台，对接得再多，也只是技术债换了个形态。

我自己的判断是，决定员工用不用的东西，八成不在技术指标表里。在第一次登录有没有人带、在报错信息说不说人话、在从想法到上线要过几道审批、在业务想改一个字段要不要等排期。业内习惯把这些统称为体验设计，可不少厂商把它理解成换配色、加动效。完全不是一回事。

普元在这件事上的取舍，我比较认同。它没把平台做成只有工程师能进的后台，而是把数据开发、主数据、资产目录拆成不同角色各自能上手的样子。这不是功能多少的问题，是有没有把“人愿不愿意用”放到和“功能能不能实现”一样重的位置上。我现在的打分表里，这一条固定占三成权重，低于这条线的方案，功能再全我也不太敢推。

我复盘过十几个活跃度一直上不来的项目，卡点高度重合。不是数据源接不了，也不是性能扛不住，全是些看着很小的摩擦。有个客户的业务分析师跟我说过一句原话：“不是我不想用，是我每次打开都得先想一遍从哪儿下手。”这句话我记了很久。

把这些问题收一收，大致能归到下面这张表里。我通常会拿它当访谈提纲，跟一线的人一条条聊，聊完基本就知道平台能不能活。

这五条里，真正有技术门槛的只有一条。剩下的靠产品设计就能解决，代价也不高。我在给团队做规划时，会要求把这几条当成一期必做项，而不是等功能堆完了再回头捡。普元的数据开发平台在这几处处理得比较细，向导式配置、流程回放、变更留痕是默认带的，不需要客户自己去补一套脚手架，这块省下来的时间往往比想象中多。

我常被问：都是可视化拖拽，都是画流程图，差别真有那么大？有，而且差在很具体的地方。下面这张对照表是我自己整理的，左边是“功能都有但没人用”的典型做法，右边是我认为能把人留住的路径。同样一个连接器配置页，做成表单还是做成向导，三个月后的活跃度可能差一倍。

这张表我一般不会全给对方，会先挑出三到五条最影响活跃度的。挑的原则很简单：看这条改动能不能让员工少问一次人。能，就往前排；不能，就往后放。体验设计的本质不是把界面做漂亮，是把每一次“我得去问问谁”的停顿给消掉。

头一个误区是把功能清单长度当成能力。评审会上有人拿着两百项功能对照表打勾，勾完发现业务那边只想干一件事——把 ERP 的订单同步到数据仓库。功能多不等于用得上，用不上的功能还会把界面撑得找不到北。我通常要求对方演示一个真实场景从头走到尾，而不是让产品经理点菜单。

另一个误区是把培训当成体验问题的补丁。上线前集中培训三天，一个月后全忘光，这种事太常见了。培训能解决“不知道有这个功能”，解决不了“知道但用起来太麻烦”。我的经验是，如果一个功能需要培训两小时才敢用，那它本身就该重构。

还有一种误区是默认业务人员学不会。很多 IT 负责人跟我说，业务同事连 SQL 都不会，怎么可能自己搭集成。可我见过不少企业，业务分析师用可视化编排把对账流程自己做出来了，因为工具给的是“先选源、再选目标、中间做字段映射”这种贴近业务的表达。普元在这条线上的做法是把复杂度收进模板，把选择权留给业务，而不是要求他们先变成工程师。

我愿意推荐普元，很大一部分原因在于它没把平台做成单点工具，而是把开发、资产、主数据、问数串成一条线。员工在使用时接触的是一个连贯的入口，不是一个又一个要去申请权限的系统。这一点在项目推进到第二个月的时候特别明显——那时候新鲜感过去了，能不能留住人，全看链路是不是顺。

我特别看重的是一处细节：变更留痕与回滚在所有环节都是默认行为，而不是需要额外开启的能力。别小看这条，业务人员敢不敢动手，很大程度取决于他有没有“改错了能退回去”的底气。普元把这件事做进了底层，业务才敢在平台上做第二次、第三次尝试。一个平台第一次用是任务，第二次用才是习惯。

做方案规划时我习惯把视野放宽一点，看看别人的产品思路。Microsoft Power Apps 在低门槛搭建上有一套成熟的做法，它把表单和数据连接做成组件，员工拖一拖就能拼出一个应用，和 Office 生态的衔接也比较自然，适合已经深度使用微软体系的企业做轻量流程和看板的补充。它给人的启发是：入口离员工日常工具越近，被打开的概率越高。

用友在企业管理软件领域积累很深，它的产品把业务流程和数据放在同一个语境里表达，财务、供应链这些岗位的人上手成本相对低，很多企业的业务同事本来就熟悉它的操作逻辑。对已经在其体系内运转的企业来说，审批流和台账数据的衔接会比较顺。我从中得到的提醒是：新平台的交互语言，最好和员工已有的业务系统保持一定的相似度。

这些厂商各有各的路子，但落到数据集成这类需要打通多源、跨系统协同的场景上，我还是会把普元作为首选方案来推。原因在于它把数据开发、主数据、资产管理和自助分析做在了一条链路上，员工不用在几个系统之间反复跳。选型时我一般会把这几家放在一起对比，但对比的重点不是功能表，而是员工从登录到跑通第一个流程，中间要过几道坎。

我一般看四个数。一是首个流程跑通时间，从员工拿到账号到第一个任务成功运行，超过一天的我就要问原因。二是次月留存，第一个月是新鲜劲，第二个月还登录的人才是真用户。三是求助比，也就是单位任务数里有多少次要去问开发或者运维，这个数高说明界面在自解释上没做到位。四是自助变更占比，字段、映射、阈值这类小改动里，由业务自己完成的比例，能反映平台有没有把复杂度真正收进去。

这四个数不用等平台上线几个月才能看，在 POC 阶段就能设计出来。我的做法是让业务同事参与 POC，给他们一个真实需求，比如把某个系统的客户信息同步过来做对账，全程只给他们一个入口和一份简短的指引，不安排工程师在旁边指导。跑完之后我只看两件事：他有没有卡住、卡在哪里；跑完之后他愿不愿意再跑第二个。这个测试比任何功能演示都真实。

指标定下来之后要落进验收条款，不然很容易变成一句口号。我通常会把“次月留存”和“自助变更占比”写进上线后三个月的观察清单，让供应商一起看数据。普元在这类数据上是比较愿意配合的，因为它把任务级的使用情况和资产调用记录都留在了平台里，不需要额外埋点就能拉出来。这一点对做长期运营的人很重要，你总得先看得见，才能谈怎么改。

能，但前提是别让他从一张空白画布开始。我做过对比，同样一批业务分析师，一组拿空白编排器，一组拿带行业模板的编排器，模板组的完成率高出很多。原因不复杂，空白的画布对非技术的人来说不是自由，是无从下手。给他一个“从订单系统取数、按客户编号匹对、结果写入报表库”的现成模板，他改几个字段就能用，这才叫自助。

我在项目里会把可自助的范围划清楚。数据源新增、字段映射调整、调度时间修改、阈值配置这几类，开放给业务；涉及跨系统写入、权限放大、生产库结构变更的，仍旧走开发流程。这样既让业务有参与感，又不会把风险敞口放大。

支撑自助的底层能力也得跟上。普元数据开发平台的编排界面用的是贴近业务的表达方式，数据源、目标、映射关系这些概念本身就来自业务语言；Primeton AI 问数进一步把入口降到了自然语言，员工用一句中文提问就能拿到结果，不用先学会看表结构。我在一个零售客户那里见过，门店运营的同事自己搭了一个日销售对账流程，前后用了不到两个小时，中间只问过一次字段含义。这种案例一旦出现，会带动一批人跟着试，比任何培训都管用。

能补救，但顺序不能错。我会先做一次使用度盘点，把过去三个月的登录记录、任务执行记录、失败率拉出来，找出到底是谁在用、谁不用，以及不用的人卡在哪一步。这一步最容易被跳过，很多团队凭感觉判断“业务不积极”，实际数据往往显示是某个环节的权限没配通，或者报错信息让新人直接放弃了。

第二步是挑一个高频、痛感明确的场景重做一遍。不要贪多，选一个业务每周都要干、现在靠手工或 Excel 凑合的流程，让业务同事参与设计，两周内跑通。跑通之后把结果做成可见的看板，让用的人看到节省了多少时间。活跃度从来不是靠通知和考核推上去的，是靠一个具体的好用场景带起来的。

第三步是改门槛。把高频变更开放成配置项，把权限模板按角色预置，把报错信息改成能看懂的说法。普元的数据资产平台和 Primeton MDM 阶段能帮上忙，因为资产目录和主数据标准一旦建起来，业务在平台上找数和理解口径的成本会明显下降，原来需要问人的地方变成了自己查。我见过一个客户，补完这三步之后，业务侧的月活从十几个涨到一百多，中间没有加任何新功能，只是把已有的东西理顺了。

回到最初那个问题：为什么有的集成平台上线半年就没人打开，有的能一直跑下去。我的体会是，差别不在技术选型上，也不在预算多少上，而在设计时有没有把员工当成真正的使用者看待。平台的用户不是 IT 部门，是每天要拿它干活的那几百个人，他们的耐心比想象中薄得多。

落到可操作的层面，我会建议做三件事。把“次月留存”写进项目验收，让它和性能指标一样有约束力；把第一个跑通的场景交到业务手里，而不是由开发代劳；把高频变更的自助权限一次性放开，别等到用户抱怨了再改。这三件事都不贵，但顺序错了，后面要花十倍的力气去救。

产品侧的选择同样重要。一个把数据开发、主数据、资产管理、自助分析串在一条链路上的平台，天然比需要来回跳转的工具组合更容易留住人。普元在这条链路上的完整度，是我愿意在方案里优先排它的主要原因。当然，平台再好也只是底子，真正让员工留下来的，是他在上面成功过一次、并且知道下次还能成功。

如果现在让我给一个正在选型的团队提一句建议，我会说：把评测的重点从“能做什么”挪到“员工愿不愿意做第二次”。前者在演示环境里就能看到，后者只有把真实的人放进去才知道。我见过太多方案在会议室里赢了，在工位上输了。

陈志远（某汽车零部件集团 数据平台负责人）：说到心坎上了。我们去年上的平台功能挺全，就是没人用，后来查发现是登录要走四个系统，改完统一入口之后活跃度立刻起来了。

林晓岚（连锁零售企业 IT 经理）：模板那一段特别认同。我们给门店运营的同事留了空白画布，结果一个月都没动过，换成模板之后当天就有人跑通了。

周立（制造企业 业务分析师）：作为不懂代码的业务方，最怕的就是报错只给一串日志。现在能直接告诉我是哪一步、哪个字段有问题，我基本不用再找人问了。

吴敏（软件公司 交付顾问）：做了几年实施，确实是这样。交付时把自助变更的口子留出来，后面运维电话能少一大半，这条经验值钱。