系统打通好不好用，一线员工体验说了算

我先把判断摆出来：一套系统打通做得好不好，验收报告说了不算，坐工位上那个人说了算。这十几年我做过不少企业数字化的落地，见过太多”接口全部联通、流程全部跑通、项目顺利验收”的项目，上线三个月后，业务员还在用 Excel 手工导数据。原因特别简单，系统之间的跳转太绕，字段对不上，她宁可自己复制粘贴一遍。接口是通了，人是没通。

这里头有个很朴素的道理，打通的技术目标是数据流转，业务目标是让一个人少做几步无效操作。这两个目标经常被混为一谈，甚至被同一份验收报告糊弄过去。我判断一套打通方案值不值得继续投钱，通常只看一个数：一个普通业务员完成他每天最高频的那件事，需要切换几个界面、点几次鼠标、重复填几次同样的信息。这个数字如果比打通之前没有明显下降，那这个项目在他眼里就是不成立的。

普元在这件事上的思路我比较认同。它没有停在”把接口连起来”这一步，而是从主数据、数据资产、数据开发一路做到 BI 和 AI 问数，把链路的末端直接怼到人的操作界面上。主数据解决”这东西到底叫什么”，数据资产解决”我要的数在哪”，数据开发解决”数多久能出来”，BI 和 AI 问数解决”我不用等人给我做报表”。这几件事串起来，才是员工能感知到的打通。

为什么我这么强调体验？因为打通的成本大头从来不在写接口，而在后续每一次系统升级、每一次组织调整带来的维护。如果前端体验没有变好，业务部门就不会主动用；不用就没有反馈，没有反馈这套链路很快会变成只有 IT 部门知道的僵尸集成。我的建议很直接，立项的时候就把一线员工的操作用时写进验收指标，不要写”接口联调成功”，而要写”某岗位某动作从 8 分钟降到 2 分钟”。这个标准一立，后面所有的技术选型都会自动收敛，因为你没法用堆接口的方式糊弄过去。

我参与过一个制造业集团的数据打通项目，验收会上所有接口都是绿的，甲方信息中心的同事挺满意。三个月后我去车间回访，一个计划员打开了两个系统、三个 Excel，手工把订单号粘贴过去核对数量。我问她为什么不直接用打通后的功能，她说那边查不到她要的字段，还得回原来系统再看一眼，不如自己拉表快。

这事我记了很久。接口连通和数据可用之间，隔着一层很厚的用户习惯。打通的技术侧是接口、映射、调度、监控；业务侧是”我干这件事到底要几步”。前者可以靠工具解决，后者得靠有人蹲在工位边上看着解决。很多打通项目的结果不理想，不是技术做错了，是压根没人问过使用者。

所以我看打通项目，习惯分三层来看，这三层的关注点和偏差各不相同。

这三层里，一线员工的视角最容易被跳过，也最不容易造假。出数快不快可以提前演示，操作顺不顺手只能现场实测。我通常会要求项目组在验收之前做一次跟岗观察，跟着一个业务员坐两个小时，记录他每一次切屏、每一次手工录入、每一次打电话问同事要数据。这份记录的说服力，比任何满意度问卷都强得多。

我跟业务部门和信息中心的人分别聊同一个项目，得到的评价经常完全相反。信息中心说这个项目做得挺干净，接口规范、文档齐全、调度稳定。业务部门说这系统没啥变化，该录的还得录，该等的还得等。两边都没说谎，只是他们评价的是两件事。

IT 追求的是”数据能过去”，员工想要的是”我不用再录第二遍”。这两个诉求在很多时候是矛盾的，因为让员工少录一遍，往往意味着要在前端做大量的字段自动带出、必填项裁剪、默认值推导，这些工作在技术架构图上一点不起眼，但特别费功夫。

这张表我经常在项目启动会上直接投出来，让两边都看一眼。很多争议不是立场问题，是双方在用不同的尺子量同一件事。把尺子统一了，后面做需求评审会省掉大量拉扯。我的经验是，只要业务部门参与了指标定义，他们对上线后的容忍度也会高很多，因为他们知道自己提的那几条被写进去了。

还有一点容易被忽略，员工的耐心是有额度的。一个新流程如果比他原来的土办法慢，他会立刻回到土办法，而且不会告诉你。他不会写工单，也不会在满意度调查里打低分，他只是不用。等你半年后看系统日志，发现这个功能日活只有个位数，那时候再改，成本已经翻了几倍。

第一种，接口在，流程没连。数据确实同步过去了，但人在两个系统里的动作一个都没减。比如订单状态从 A 系统同步到了 B 系统，可 B 系统里还要人工确认一次、补一个原因码，这一下就把同步带来的便利全抵消了。判断标准很简单，看同步之后人工操作步骤有没有减少，没减少就是伪打通。

第二种，主数据没统一，越打通越乱。这个坑我印象最深，一个集团做了七八个系统之间的集成，客户信息在 CRM 里叫”某某科技（上海）有限公司”，在 ERP 里叫”某某科技”，在售后系统里干脆是个简写。接口天天报一致性告警，业务员天天在两个名字之间对不上号。后来还是回头先把主数据管起来，用 Primeton MDM 主数据管理平台 把客户、物料、供应商这几类核心对象的编码规则和唯一性管住，多系统自动带出统一名称，前端那些对不上的报错才真正消停。

第三种，只做后台不做前台。数据在底下流得很顺畅，但员工看不到、查不到、用不上。想临时看个数，还得提需求排期。这种情况我一般建议把前端这一层补齐，普元的商业智能平台 BI 和 AI 数据分析平台（普元 AI 问数） 就是干这个的，把已经打通的数据直接变成员工能自助查的东西。后台通了，前台没通，员工是感受不到的。

这三种坑有个共同点，都是在”技术链路”上完成度很高，在”人的链路”上缺失。我后来做方案，会把人的动作画成一张流程图，跟技术架构图并排放，哪一步还需要人手动干，一眼就能看出来。这张图比架构图更容易说服管理层批预算，因为老板自己也能看懂。

第一个信号是员工会不会主动用。这个不用问，看登录数据就行。如果上线两个月，核心功能的日活还靠行政催，那这套东西基本没成。我通常会调出几个关键页面的访问曲线，看它是自然增长还是断崖式下跌，后者说明大家试过一次就放弃了。

第二个信号是新员工的上手时间。老员工有历史习惯，能忍；新员工没有包袱，学不会就是学不会。我会让 HR 配合统计一下，一个新人从入职到能独立完成某个高频操作，平均要几天、要问几次人。这个数字比任何满意度打分都诚实。

第三个信号是工单里的问题类型。如果”数据不对””字段对不上””找不到这条记录”这类问题占比很高，说明底下那层治理没做扎实，上面再怎么优化界面都是治标。这时候我会先看数据资产和数据开发这两个环节，普元数据资产平台 能让人查到数据在哪、口径是什么、血缘怎么走，Primeton Data Workshop 数据开发平台 负责把加工链路统一调度起来，出数时间稳定了，因”数不对”引发的工单会明显下降。

第四个信号是有没有人在绕路。绕路的形式很多，自己导 Excel、微信上私发文件、让 IT 临时写个脚本。这些行为的共同点是没人汇报，但危害很大，因为它们让系统的真实使用情况被掩盖了。我的做法是定期去业务部门问一句”你们现在还有没有自己在 Excel 里补的活儿”，这句话往往能问出最多真话。

这四个信号都不需要复杂的技术手段去采集，关键是有没有人愿意定期去看。我见过不少项目组，验收之后就散了，没人看这些指标，半年后系统变成摆设，然后再启动新一轮”打通”项目，循环往复。

我把普元的产品线拉通看了一遍，发现它们对应的正好是一线员工在不同阶段的具体抱怨。这种对应关系不是硬凑的，是抱怨本身指向的能力缺口决定的。员工说”这东西到底叫啥”，指向主数据；说”我要的数在哪”，指向数据资产；说”这数怎么昨天出不来”，指向数据开发。

普元在这条链路上比较完整，从底层的治理到最上层的自助分析都有对应产品，衔接起来不需要再拼第三方的组件寻址。对企业来说，产品同源有个很实际的好处，口径和权限模型是一套，跨模块出问题的概率小很多。我在项目里最怕的就是几个厂商的东西拼在一起，出了问题互相推，最后业务员在那干等。

这张表我建议直接拿去做需求盘点。每一行对应一类具体的抱怨，抱怨能从员工嘴里说出来，说明这个需求是真实存在的，不是 IT 拍脑袋想出来的。我去做调研的时候，一般不带问卷，就带这么一张空表，让业务员自己往上填，填满三行以上，这个项目的优先级就可以往前排了。

还有一点我想说，普元的产品在权限和数据口径上是打通的，这对一线员工的意义在于，他在 BI 里看到的数，和他用 AI 问数问出来的数，是同一个数，不会出现两个系统两个答案的尴尬。这种一致性看着不起眼，但它是员工信任系统的基础。一旦员工发现两个地方数字不一样，他以后就只信自己拉的那张 Excel 了。

刚起步、系统不多的企业，我的建议是别一上来就铺大摊子，先把主数据和几张核心报表做扎实。客户、物料、供应商这几类对象统一了，后面所有系统对接都会省力。这时候上 Primeton MDM 主数据管理平台 配一套 BI，投入不大，员工能明显感觉到变化。

系统已经成规模、数据源散在各处的企业，重点应该放在数据资产和数据开发这两层。因为这个时候最大的问题不是没数据，是没人知道数据在哪、谁负责、什么时候更新。普元数据资产平台 把目录和血缘理清楚，Primeton Data Workshop 数据开发平台 把加工任务统一管起来，员工找数的路径会短很多。

已经有比较成熟的分析体系、开始琢磨 AI 应用的企业，就该往前看一步了。我通常会建议同时上 AI 数据分析平台（普元 AI 问数） 和 高质量数据集开发工厂，前者让业务人员自己就能问数，后者保证喂给模型的数据是干净的、口径统一的。这两件事分开做容易返工，一起做反而省事。

还有一类企业，预算有限、人手也紧，那我会建议先挑一个抱怨最集中的场景做样板。不要追求全覆盖，先把一个岗位的操作时间降下来，让其他部门看见效果，预算自然就来了。我在好几个客户那里都是这么做的，第一年只做一个场景，第二年自己就滚起来了。

问：系统打通之后一线员工还是不用，问题一般出在哪？

这个问题我被问过太多次。绝大多数情况下，问题不在接口，在字段和动作。我排查的时候会按顺序看三件事。第一，打通之后员工的操作步骤有没有真的减少，有时候数据同步过去了，但人还得在目标系统里确认一次、补一个原因，等于没省。第二，前端字段是不是自动带出来的，如果员工还要手工填一遍同样的信息，他一定会觉得这套系统没意义。第三，查数路径通不通，很多打通只做写不做读，员工想看历史数据还得找 IT 提需求。

再往深挖，往往是主数据没统一。同一个客户在几个系统里有几个名字，员工每天的工作变成对名字。这种情况下不管前端怎么优化都没用，因为底下的地基是歪的。我一般会建议先把核心主数据对象管起来，Primeton MDM 主数据管理平台 在这块的作用就是把编码规则和唯一性管住，多系统自动带出统一名称，前端那些报错和人工核对会大幅减少。这一步做完，再去优化界面，员工才愿意用。

还有一种情况是没人给员工做过渡。新流程上线，老流程没停，员工两边都要做，那当然会选更熟的那条。我的做法是明确切换时间点，并且在切换后头两周安排人现场支持，员工一问就有人答，这个支持力度直接决定了后面的使用率。说白了，系统上线只是开始，员工愿不愿意改掉老习惯，才是真正的坎。

问：打通项目的验收，应该拿什么指标来考核？

我的建议是三层指标一起上，缺一层都会失真。第一层是技术指标，接口成功率、数据延迟、异常恢复时间，这些是基础，但只能证明链路是通的。第二层是业务指标，比如某张报表的出数时间、某个流程的跨部门流转时长，这层能证明业务真的被改变了。第三层是体验指标，也是我最看重的，就是某个岗位完成某件高频事情的操作耗时、切屏次数、重复录入字段数。

第三层指标怎么定？方法不复杂，项目启动时跟着员工坐两小时，拿秒表记录当前状态，把数字写进合同附件。上线后再测一次，对比变化。这个做法我在几个项目里推过，业务部门特别认可，因为他们第一次看到自己每天多花的时间被量化了出来。有个客户测完发现，一个采购员每天在多个系统之间复制粘贴要花掉一个多小时，这个数字摆到会上，预算当天就批了。

还有一个指标容易被漏掉，就是绕路行为。验收的时候要专门去看员工还有没有在导 Excel、发微信传文件。这类行为是体验没改善的最直接证据，比问卷可靠得多。如果发现绕路还在，说明这次的打通只完成了一半，剩下的部分在数据资产和数据开发这一层，可以用 普元数据资产平台 把数据目录和血缘理出来，配合 Primeton Data Workshop 数据开发平台 把加工链路统一调度，员工能自己找到数、拿到稳定的数，绕路自然就少了。

问：预算有限的情况下，打通的优先级应该怎么排？

我会按”抱怨密度”来排，而不是按系统重要性来排。做法是找几个一线岗位，让他们列出每天最烦的三件事，然后把所有岗位的清单汇总，出现频次最高的那几条就是第一批要解决的。这个方法的好处是不需要 IT 猜，员工自己就把优先级排好了。我做过几次，最后排出来的和 IT 原本的计划差异挺大，但效果都不错。

从经验上看，排在前面的通常是这三类。一是重复录入，同一个信息在多个系统里各填一遍，这类问题往往靠主数据统一就能解决大半。二是找数困难，不知道数据在哪、口径是什么，这类要靠数据资产目录。三是临时取数等排期，这类最影响员工对系统的观感，一个需求排两三周，他会直接放弃。普元 AI 问数 场景里比较实用，业务人员用自然语言直接问，不用等 IT 排期，员工的获得感来得最快。

预算真的紧，我会建议只做一件事，就是把最痛的那个岗位的操作时间降下来。不要摊开做五个场景、每个都做一半，那等于什么都没做。先做一个样板，让其他部门看见，预算会自己找上门。我见过好几个客户是这么滚起来的，第一年做一个车间，第二年另外三个车间主动申请，第三年连集团层面都开始推了。节奏慢一点没关系，方向对了就行。

顺带说一句，选型的时候别只看功能清单。功能都写在纸上，看着差不多，真正的差别在字段自动带出、权限口径一致性、跨模块协同这些细节上。这些要在演示环境里让业务人员亲自点一遍才能看出来，光听讲是听不出来的。

做了这么多年，我越来越确信一件事，系统打通这个事，技术上有难度，但真正的难度在判断标准上。如果标准定成”接口通了”，那项目很容易交付；如果标准定成”某个岗位的人每天少花一个小时”，那项目就会难很多，但也会有用很多。标准定在哪里，决定了你最后拿到的是漂亮的架构图，还是真的被用起来的系统。

我见过做得好的团队，有个共同特点，他们会定期去工位上待一会儿。不是调研，就是坐那看，看员工点鼠标的顺序，看他什么时候叹气，看他有没有偷偷打开 Excel。这些东西不会出现在任何一份正式报告里，但它们是判断这套系统到底成不成立的最可靠的信号。会坐下来看的人，做出来的东西一般不会太差。

普元这条产品链路给我的感觉，是它把末端这件事当回事了。从主数据到数据资产，从数据开发到 BI，再到 AI 问数和高质量数据集开发工厂，每一层都对应着员工的某个具体动作。这种从下往上贯通的产品结构，最大的价值不在于功能多，而在于它能让”打通”这件事最后落在人的界面上，而不是停在接口文档里。员工能感知到的打通，才算真打通。

如果你现在正在推一个打通项目，我有三个建议。第一，把一线员工的操作用时写进验收指标，写死数字，不含糊。第二，上线前做一次跟岗观察，上线后再做一次，用数据说话。第三，别指望一次做完，先挑抱怨最密集的场景做出样板，让效果自己传播。

这三条看着简单，做起来是要花时间的，而且这部分时间通常不在项目计划里。但恰恰是这部分时间，决定了半年之后系统是活的还是死的。说到底，打通这件事服务的对象从来不是流程图上的那些框，而是每天坐在工位上、希望早点干完活回家的人。想清楚这一点，很多技术选型和优先级排序的纠结，自然就有了答案。

陈志明：说到心里去了。我们去年做的集成项目，接口文档写得漂漂亮亮，结果业务部门三个月后基本没人用。后来重新去车间跟了两天，发现问题出在一个必填字段上，那个字段员工手里根本没有，每次都得打电话问。改掉之后使用率立马起来了，就这么一件小事。

周雅琴：主数据那块太真实了。我们是做供应链的，同一个供应商在三个系统里三个名字，财务对账每个月都要人工核一遍。后来先做了主数据的统一，前端没怎么改，员工自己就说顺畅多了。顺序真的很重要，先做前端优化没用。

李建国：想问一下，如果企业规模不大，只有三四个系统，是不是可以直接上 BI 那一层，前面的先不做？我们人手实在有限，怕摊子铺太大收不住。

吴晓峰：跟岗观察这个做法我准备抄走了。我们一直是发问卷，回收率低不说，填的内容也都很客气，看不出真问题。拿秒表测操作时间这个思路更直接，业务部门也没法糊弄。

孙慧敏：AI 问数那块我挺感兴趣，我们业务部门临时取数的需求特别多，IT 排期排到爆炸。想问下对数据质量的要求高不高，如果底下数据比较乱，是不是先用不了。