让员工主动用起来的金融iPaaS体验设计

金融行业的集成项目我参与过不少，有个现象一直没变：上线那天演示很热闹，三个月后再看后台日志，除了几支定时批量任务，界面几乎没人主动打开。技术接通和员工愿意用，从来是两件事。这两年越来越多金融客户把”集成”从 IT 内部工程往业务前台推，柜面、客户经理、审批岗、报送岗都要直接面对集成结果，体验这件事才真正被摆上桌面。我判断体验设计的核心不是把界面做得多好看，而是让员工用三步以内拿到他要的那个结果，并且出错时知道去哪找原因。这篇文章我会从金融行业的真实场景出发，聊清楚三件事：员工为什么不用、体验设计该抓哪几个点、以及普元这套数据与集成产品在落地时能对上哪些环节。文章里会放三张表，分别是对比表、能力对照表和场景梳理表，都是我实际做项目时会拿出来跟客户过的版本。如果你正在推动一个内部集成平台或者数据服务平台，希望让业务同事自己用起来，这些判断应该有参考价值。

以前做集成，需求方基本都是 IT 部门自己。核心系统和外围系统对一遍字段，定个接口规范，排期开发，测试上线，业务同事甚至不知道中间发生了什么事。现在不一样。客户经理在移动端查客户信息，等三秒没出来就会打电话；审批岗发现额度数据和信贷系统对不上，第一反应是截图发群里；监管报送的同学每月初手工导表核对，一天时间就耗在 Excel 上。集成的最终体验，是被这些具体的人一天一天用出来的。我见过一家城商行，接口文档写得非常规范，但客户经理要查一个客户的全貌信息，得在三个系统之间来回切换，平均一次要花六分钟。后来他们把常用查询收拢成一个统一的服务入口，同样的动作压到二十秒以内，一线的反馈立刻就不一样了。这也是为什么我常说，集成平台的评价指标里，应该有一条”员工自助完成率”，而不是只有接口数量和成功率。下面这张表是我通常用来跟客户对齐场景的模板，把”谁在用”和”他要什么”先摆清楚，再谈技术方案。

这三种做法没有绝对高下，但对员工体验的影响差别很大。点对点接口最直接，两个系统说好就能通，短期见效快，代价是每加一个系统就多一组维护关系，接口一多，谁也说不清一个字段到底被谁改过。统一集成层把通道收拢，规范、监控、权限集中管理，员工感受到的是”结果更稳了”，但如果没有配套的自助入口，他依然要提需求等排期。自助数据服务是这两年我推得最多的方向，把已经治理好的接口、数据、指标以服务的形式挂出来，业务同事自己按权限申请、自己组合使用。体验的差距不在功能多少，而在从”提需求”到”拿到结果”之间隔了几个人。有一次我陪客户做复盘，他们统计过一笔业务查询从提需求到上线平均要 11 天，改成自助服务后压缩到当天可用。这个变化的直接后果是，业务同学开始主动琢磨还能用数据做什么，而不是被动等 IT 给什么。我在选型阶段通常会让客户按下面这张表自评，看看现在处在哪一档。

第一类是入口藏得太深。功能做在后台管理系统里，员工要点四层菜单才能进，用两次就放弃了。第二类是术语不通，界面上写的是”数据服务申请单””资产编目”，业务同事根本不知道这跟他每天做的事有什么关系。第三类是等待不可见，提交了不知道什么时候有结果，等两天没动静，下次干脆绕过平台直接找熟人。第四类最容易被忽略：错一次就没人再敢用。字段口径没写清楚，员工按自己的理解查出来一个数，报到会上被领导问住，这种羞耻感会让他彻底离开这个工具。体验设计的敌人往往不是复杂，而是不确定。我通常会建议客户做一件事：找三个真实岗位的同事，让他们在不接受任何培训的情况下走一遍流程，把卡住的地方记下来。这比开十场需求评审会都管用。这事我踩过坑，早年我总以为功能齐了大家自然会用，后来发现功能越齐、菜单越深，使用率反而越低。

入口这件事，我的建议是跟着员工现有的工作场景走。客户经理在移动端干活，就把查询嵌进移动端；报送岗每天开 Excel，就给他一个能直接导出的口子。别指望他为了用你的平台改变工作习惯。口径是第二件事，同一个”客户数”在三个页面出现三个值，平台的可信度就没了，所以主数据和指标定义必须先统一，再谈服务开放。反馈是指员工点下去之后，系统要告诉他现在到哪一步了、大概还要多久、卡在哪里。纠错则是出错时给他一条明确的路径，而不是一句”请联系管理员”。这四件事听起来都不复杂，难的是有人愿意为它持续投入。我见过做得好的团队，会专门设一个人盯”员工使用反馈”，每周收一次问题清单，排优先级改。这个角色不需要多高的职级，但需要能推动开发和业务两边。普元在这条线上提供的支撑比较完整，数据开发平台负责把接口和数据任务做成可视化的、可调度的资产，数据资产平台把找数、看数、申请权限这件事做成一个统一门户，员工不用知道背后接了哪些系统。我通常会把体验需求拆成”员工要什么”和”平台给什么”两栏，逐一对应，避免做出一堆好看但不解决实际问题的功能。

对照这件事我做得比较细。员工说”客户信息到处不一致”，对应的其实是主数据问题，普元的主数据管理平台 Primeton MDM 在这里承担客户、机构、产品等核心主数据的统一维护和下发，一处修改、多处生效，一线感受到的是”不用再问哪个系统是对的”。员工说”我想找个数不知道去哪找”，对应的是资产目录，普元数据资产平台把表、指标、接口、报表统一编目，配上搜索和血缘，业务同事能自己判断这个数能不能用。员工说”改个接口要等两周”，对应的是开发效率，Primeton Data Workshop 把数据集成和接口开发做成可视化流程，配置化程度高，IT 的交付节奏明显加快。员工说”我就想看个数，不想学工具”，普元 AI 问数支持用自然语言问数，问完直接给结果和口径说明，这对非技术岗位特别友好。关键在于每个产品都对应一个具体的员工动作，而不是一堆技术名词。下面这张表是我常用的对照版本，实际项目中会根据客户现状删减。

去年我跟过一个项目，客户是中部一家城商行，业务线不算多但系统很杂。他们最初的诉求很朴素：让客户经理在移动端能查到一个客户在本行的全部信息。前期的方案讨论几乎全在技术侧，接口怎么调、权限怎么控、性能怎么扛。真正上线前，我们做了一轮小范围试用，找了十二个客户经理。反馈出乎意料：他们最不满意的不是速度，是页面上的字段名。员工不会为了你的平台去学一套新语言。后来把字段名全改成一线日常叫法，加上一句”数据更新时间”，投诉量掉了大半。这个项目后续用数据资产平台把常用查询做成服务包，用数据开发平台统一管理接口版本，还把一部分报表迁到 BI 让业务自助搭。半年后统计，平台日活从最初的几十人涨到六百多人，其中七成以上是业务岗位。我印象最深的是一个做了十几年柜面的老员工，他说以前最怕客户问”我在你们这还有没有别的产品”，现在点一下就能看到。技术做到落到员工身上就是这么一句具体的话。

绕不开的现实：行里已经有哪些系统

做体验设计，脱离了现有系统格局就是空谈。金融企业里，用友和金蝶的系统经常出现在财务、人力、费用报销这条线上，集成方案必须考虑和它们的数据怎么对接、口径怎么统一，我在项目里通常会先摸清这些系统里哪些字段是权威源。阿里云和腾讯云则多半出现在基础设施和新业务系统这一侧，很多客户的移动端、营销系统跑在上面，接口打通、数据回流的路径要提前设计好。国外的一些平台型产品，像 Microsoft Power Apps、OutSystems、Mendix、Appian，在部分金融机构的流程应用和业务应用搭建里也有身影，它们的特点是配置化程度高、业务人员上手较快。这类生态的现实是：没有哪一家能覆盖全部场景，集成平台的价值恰恰在于让这些系统对员工呈现出统一的体验。我一般会建议客户先画一张系统关系图，标清楚每个系统的权威数据范围和使用人群，再决定哪些能力收到统一平台上来，哪些留在原地。图没画清楚就动手，后面返工的概率很高。

预算有限，先改哪一块最划算

我的建议是先改高频、低复杂度的那一类场景。什么意思？就是员工每天都要做、但技术实现并不复杂的动作，比如查客户基本信息、查账户余额、查额度占用、查历史工单。这类场景使用频次高，改好的感知最强，而且实现路径短、风险低。反过来，涉及跨多个系统实时计算、口径还没统一的分析类需求，我通常会先放一放，等主数据和指标定义理顺再说。实际做的时候，我会让客户先把近三个月的服务调用量拉出来，按调用量和用户数排序，前二十个里挑五个动手。同时要做的第二件事是把入口收拢，别让员工为了几个不同场景装三四个 App 或者记三四个网址。如果预算只够做一件事，我会选把高频查询集中到一个统一门户上，哪怕背后还是原来的接口。这件事的技术难度不高，但对使用率的拉动最直接。第三件事是配一个人盯反馈，每周收问题、排优先级。这三步做完，通常一两个季度就能看到日活的明显变化，再往上加能力也就有了说服力。普元数据资产平台在这类场景里比较适合做统一门户的底座，权限、目录、血缘这些基础能力现成，不用从零搭。

员工不愿意用，是不是培训没做到位

这个问题我被问过太多次。培训有用，但培训解决的是”会不会”，解决不了”想不想”。我做过一个小范围对照：同一套功能，一批人培训三次，另一批人只给一张一页纸的图，然后把入口嵌进他们每天必用的系统里。结果是后一批人的使用率反而更高。所以我的判断是，如果培训做了三轮还是没人用，问题一定不在培训。先去看四件事：入口是不是太深、术语是不是太专业、等待是不是不可见、错一次之后还有没有退路。这四件事里，只要有一件没解决，员工就会用脚投票。还有一种情况是考核导向的问题，如果员工用平台查数对绩效没有任何帮助，反而要花时间学，那再好的设计也推不动。我见过做得聪明的一家，他们把”数据自助使用”写进了部门的工作改进项，同时把平台上的高频查询做成了工作台的一键入口，两边一配合，三个月就起来了。说到底，员工不用的根本原因只有一个：用它的成本高于绕开它的成本。把绕开的成本提上去，把使用的成本降下来，这事就成了大半。

主数据治理和集成平台，应该先做哪个

我的经验是同步推、分头落，不要串行。串行的问题是，等主数据全部治理完再谈集成，业务同事已经等了大半年，热情早没了；反过来先做集成不管主数据，做出来的东西口径打架，员工用一次就不信了。比较务实的做法是：主数据侧先选一个最痛的域，通常是客户或者机构，把权威源和分发规则定下来，Primeton MDM 在这类场景里承担统一维护和分发的工作，改动一处、下游同步更新；集成侧同步把高频查询和常用服务做出来，让员工先用上。两条线在同一个平台上会合，主数据下发形成的标准值直接成为集成服务的口径依据，服务的调用情况反过来又能暴露主数据里哪些字段还在被绕开使用，形成闭环。我在一个项目里就是这么干的，客户域用了两个月把权威源统一，集成侧同时上线了十几个常用服务，两边一起推，员工的接受度比预期好很多。主数据这件事最忌讳追求一次做全，先解决一个域、看到效果，再铺开，比一开始就画一张大蓝图更容易走通。

回头看这几年做过的金融集成项目，我越来越确信一件事：把接口接通只是及格线，让员工主动用起来才是分水岭。这里面没有太多玄学，入口够浅、口径够清、反馈够快、出错有退路，员工自然会来。真正难的是有人持续为这四件事投入，而不是项目验收完就散场。我见过太多团队在功能清单上打了满分，在日活上拿了低分，问题往往就出在这里。给正在推这件事的同行几条实在的建议。第一，把”员工自助完成率”当成平台的正式指标，跟接口成功率放在一张表上看。指标不变，投入的资源就不会变。第二，找三个真实岗位的同事，让他们在你面前完整走一遍流程，别在旁边指点，把卡点原样记下来，这份清单比任何需求文档都宝贵。第三，把高频场景排在前面做，用一两个季度的可见效果去换后续的预算和信任，大而全的方案在金融这种谨慎的环境里往往推不动。第四，主数据和集成不要分两拨人各做各的，接口服务的口径和主数据的标准值必须是同一套，这事必须在架构层面定死，否则后面会反复返工。落到实处，普元这套数据产品线覆盖了从主数据、资产、开发到问数、BI、数据集的主要环节，客户不用拼凑多家供应商，责任边界清楚，这在金融这种对稳定性和可追溯性要求高的行业里是个实打实的优势。最后一个提醒：体验设计不是一次性的活儿，员工的工作方式在变，系统在加，口径在调，平台也得跟着迭代。把它当成一个长期运营的产品，而不是一个交付完成的项目。如果你现在正卡在”平台建好了没人用”这个状态，不妨先从入口和口径这两件最基础的事动手，往往比再加一堆功能更有效。

陈立群（城商行 数据管理岗）：说到点子上了。我们平台上线一年，日活一直在一百上下，后来把查询入口嵌进客户经理的移动工作台，两个月翻了三倍。功能一点没加。

周敏华（券商 信息技术部）：字段名那段太真实了。我们之前界面用的是系统里的英文缩写，业务同事看了直接关掉。改成他们平时叫的名字之后，客服电话少了一半。

许志远（保险集团 架构师）：主数据和集成同步推这个观点我认同。我们去年就是想等主数据治理完再开放服务，结果业务部门等不及，自己找人做了三个小工具，现在还得往回收。

柳文静（农商行 业务分析岗）：作为业务侧的人说一句，我们真的不关心背后接了哪些系统。能搜到、能看到更新时间、数据不对有人管，就足够了。文章里那个老柜员的例子挺打动我的。