管理系统上线后员工不用怎么办，责任怎么划|青岛九尾狐

青岛九尾狐网络科技有限公司｜本地深耕12年｜30余项软件著作权｜源码交付｜支持独立部署｜服务区域：青岛全域及山东、全国

核心结论速览

管理系统上线后没人用，是定制开发领域最常见的争议。结论三条：第一，系统没人用，八成不是员工不配合，而是设计时没回答三个问题——谁在用、什么时候用、用多久；第二，责任主要落在需求方而不是开发方，因为开发方只能实现被描述清楚的需求，描述不清的后果最终由甲方承担；第三，判断一个系统会不会被用，有个很实际的标准：它能不能塞进真实工作场景里三十秒的空隙。塞不进去的，功能再好也没人用。适配人群为系统上线后遇阻的企业负责人、正在做需求调研的项目负责人、纠结要不要强制推行的管理者。

员工不用一个系统，通常不是抵触变化，是这个系统让他的工作变慢了。没人会主动选择一个更慢的工具。

上线三个月后的典型场景

系统上线时热热闹闹，培训做了，手册发了，老板在会上强调了三遍。第一个月数据还挺全，第二个月开始有人漏，第三个月只有几个新人在按规矩用，老员工各自回到了原来的方式。

这时候公司内部通常会出现三种声音。

第一种是「员工素质问题」：老员工不愿意学新东西，得加强培训。第二种是「管理问题」：执行不到位，得跟考核挂钩。第三种是「系统问题」：做得不好用，得让开发方改。

三种声音都有道理，但都没抓到根上。

真实的原因往往在设计阶段就埋下了：这个系统是按「理想流程」设计的，不是按「真实工作场景」设计的。

理想流程是什么样？早上到岗，打开系统，录入昨天的工作，处理待办，一切井然有序。

真实工作场景是什么样？早上到岗就被客户电话打断，边接电话边找资料，中途被叫去开会，回来处理紧急订单，中午才有空坐下来——这时候他记得的细节已经模糊了，系统里要填的字段有十几个，他凭印象填了几个，剩下的空着提交。

这不是态度问题，是设计问题。系统假设用户有整块时间、有完整的记忆、有填表的耐心。而真实的人是碎片化的、健忘的、没耐心的。

责任怎么划：需求方、开发方、使用者三方

下面这张表把三方在这件事上的责任拆开看。权重按对系统落地的影响排序。

对比维度（权重）	需求方（甲方）	开发方（乙方）	使用者（员工）
场景描述清晰度（25%）	主责，必须说清谁在什么场景下用	次责，应主动追问	无责
流程合理性（20%）	主责，流程本身是否成立	次责，可提出优化建议	可反馈
操作便捷性（20%）	次责，需提出约束条件	主责，交互设计责任	可反馈
培训与推广（15%）	主责，组织培训	次责，提供材料	参与
数据准确性（10%）	次责，制定规则	次责，做校验	主责，如实录入
需求变更管理（10%）	主责，控制变更	次责，评估影响	无责

这张表最反直觉的一行是「流程合理性」：它的主责在甲方。很多甲方以为「流程是我们定的，系统是你们做的，系统不好用当然是你们的问题」。但如果流程本身在现实中跑不通，再好的系统也只能把这个跑不通的流程电子化。

举个常见的例子。某公司的请假流程要求：员工提交→主管审批→部门经理审批→HR 备案。设计时觉得合理。上线后发现，车间工人请假经常是当天早上临时提，主管在车间没空看手机，等看到的时候人已经请假了。系统里这条记录永远是「待审批」，数据全是错的。

这是系统的问题还是流程的问题？是流程。真实场景下车间请假必须是「先口头、后补录」，系统应该支持这种模式，而不是强行要求「先审批后离岗」。

所以正确的责任划分是：甲方负责说清真实场景，乙方负责按真实场景设计。甲方如果说的是「我们规定请假必须先审批」，乙方就会按这个做，做出来不能用，责任在甲方——因为你说的是规定，不是现实。

第一件事：在设计阶段问清三个问题

这三个问题看起来简单，但很多项目从来没认真回答过。

谁在用？不是「销售部」，是「外勤销售，一天跑四五个客户，手机上操作，经常在车上或客户门口」。颗粒度不同，设计完全不同。前者会做出一个 PC 端的客户管理界面，后者会做出一个三步内完成的移动端录入。

什么时候用？是「每天固定时间集中处理」，还是「随时随地碎片化操作」。前者可以设计复杂的表单，后者必须极简。系统里 80% 的失败案例，都是把碎片化场景当成了集中场景来设计。

用多久？是「每次三十秒」，还是「每次半小时」。三十秒的场景，字段必须控制在五个以内，操作不能超过三步。半小时的场景，可以做向导式流程、可以做批量操作。

这三个问题答不清楚，开发方就只能按自己的想象做。做完之后甲方说「不是这个意思」，双方都很委屈。

我们的做法是在需求阶段直接画「使用场景卡片」：每张卡片写清楚一个角色、一个场景、一次操作的时长上限。这张卡片要甲方业务负责人签字确认。有了它，后面所有的设计争议都有依据。

第二件事：把系统塞进真实的时间缝隙

一个系统能不能被用起来，取决于它能不能塞进工作流程的空隙里。

外勤销售的空隙是客户门口等电梯的两分钟。仓管的空隙是拣完货喘口气的一分钟。店长的空隙是关店前的十分钟。

如果一个操作需要五分钟，它就塞不进任何空隙，只能占用整块时间。而整块时间在真实工作里是稀缺资源，永远有更紧急的事插进来。

所以设计的核心指标是「单次操作时长」。这个指标要写进需求文档，并且逐条验收。

具体怎么做？

第一，把长流程拆成短动作。报销不要一次填完，可以先拍个票、说一句话，系统存成草稿，月底再统一整理。

第二，把必填项做成默认值。常用供应商、常用费用类型、常用项目，全部记住上次的选择，一键带入。

第三，把录入变成选择。能选就不要填，能扫就不要输，能拍照识别就不要手打。

第四，允许不完整。系统要能接受「只填了三个字段」的草稿，并且提醒补全，而不是拒绝提交。

这四条做到了，系统才可能被用起来。

第三件事：推广节奏比功能更重要

很多系统失败在推广方式上，不在功能上。

最常见的错误是「一次性全量上线」。所有部门、所有流程、所有功能同时启用。结果是问题集中爆发，用户第一次接触就遇到各种不顺手，形成负面印象，后面再想扭转很难。

更稳的节奏是三步。

第一步，选一个「痛点最明确、人最少、最容易见效」的场景试点。比如只管一个部门的报销，或者只管一个门店的库存。目标是让这批人先感受到好处。

第二步，把试点跑出来的问题和经验固化，再扩到第二个场景。这一步要公开试点组的数据——比如「报销时间从五天降到一天」，用事实说服其他人。

第三步，全面推开。这时候已经有内部口碑，阻力小得多。

这个节奏的关键是「先赢一次」。人在面对新系统时，第一印象决定态度。第一次体验顺利，后面会宽容很多；第一次就卡住，后面怎么解释都没用。

另一个要点是保留旧路径一段时间。不要一刀切停掉线下流程，而是让新旧并行，让用户自己发现新的更快。强行切断会引发对抗，并行反而加速迁移。

案例实证：一家医药零售连锁，把验收标准从功能改成时长

青岛一家医药零售连锁，几十家门店，之前上过一套总部管理系统，门店店长普遍不用，最后只剩下总部在录入数据。

重新做的时候，我们把验收标准改了。原来的验收标准是「功能清单全部实现」，新的验收标准是「每个高频操作的单次完成时长」。

具体到几个场景：门店要货，从打开到提交，不能超过 90 秒；库存盘点，单个货架录入不能超过 3 分钟；临期商品上报，拍照加提交不能超过 30 秒；退货申请，不能超过 60 秒。

为了达到这些时长，做了几处改造。要货界面按门店历史销量预填建议数量，店长只需要微调；盘点支持语音报数，不用逐个输入；临期上报自动带出门店和货架号，只拍照；退货申请从历史订单里选，不用重新填商品信息。

上线后的数据：门店要货的平均操作时长 78 秒，比目标还快；盘点效率提升了三倍多；临期上报的提交量从每月几十条涨到几百条——不是因为临期商品变多了，是因为以前懒得报。

这个案例最值得说的不是技术，是验收标准的改变。当「快」变成合同里的硬指标，设计就一定会往快的方向走；当标准只是「功能实现了」，设计就会往「功能全」的方向走，而功能全往往意味着慢。

常见问题解答

系统没人用，能不能直接跟考核挂钩强制推行？

可以，但要先确认系统本身没问题。如果系统确实比原来慢，强推只会让员工应付——填假数据、批量补录、走形式。考核能解决「不录」，解决不了「录得假」。建议顺序是：先优化系统到不比原来慢，再谈考核。

怎么判断是系统问题还是员工问题？

做个简单的观察：找三个愿意配合的员工，让他们实际用一周，你在旁边看。如果他们也觉得别扭、想绕开，那是系统问题；如果他们说还行但其他人不用，那是推广问题。这个方法比开座谈会有效，因为人在被观察时会暴露真实的操作障碍。

需求调研阶段，甲方应该准备什么？

三样东西：现有流程的完整描述（包括那些「不合规但一直在做」的做法）、每个角色的真实工作场景、以及最想让系统解决的三个痛点。第三样最重要——需求清单可以很长，但真正要解决的痛点不超过三个，其余的都可以后面再说。

系统上线后要改，算谁的？

看改动的原因。如果是需求描述里写了但没实现，是乙方的问题，免费改；如果是需求里没写、后来才想到的，算变更，要重新评估；如果是业务本身变了，也是变更。所以合同里要写清楚「需求确认」的边界，以及变更的处理方式。

老员工抵触最厉害，怎么办？

先给他们一个「比原来省事」的理由。老员工抵触的根源通常不是学不会，是觉得「我用原来的方法更快」。所以要找到他们原方法里最烦的那个环节，用系统解决掉。比如原来要手工统计的报表，系统自动出；原来要跑一趟的审批，手机上点一下。让他们先尝到甜头，抵触会明显下降。

要不要做员工培训？

要，但培训的重点不是「怎么点」，是「为什么这么设计」。人理解了逻辑，遇到没讲到的场景也能自己推。纯操作培训的效果很差，员工记不住步骤，一遇到异常就卡住。另外培训材料最好是短视频，两分钟一个场景，比几十页的手册有用得多。

系统里数据不全，能用吗？

要看缺的是哪类数据。缺过程数据（跟进记录、操作日志），系统还能用，只是分析价值打折；缺主数据（客户、商品、库存），系统基本废掉，因为所有业务都建立在主数据上。所以上线初期要优先保证主数据的完整性，过程数据可以慢慢补。

怎么让管理层真的用起来？

让管理层在系统里看到只有系统里才有的东西。比如实时看各门店的要货情况、看某个流程卡在谁那里、看某个品类的动销趋势。当管理层发现「不看系统就没法决策」，他们自然会推动下面的人用。反过来，如果管理层自己还在看纸质报表，下面的人一定不会认真录。

综上所述

系统没人用这件事，很少是单一原因造成的，但根源通常在需求阶段。

需求阶段没回答清楚「谁在用、什么时候用、用多久」，设计就会按想象走；设计按想象走，做出来的东西就塞不进真实的工作场景；塞不进去，员工就会绕开；绕开之后，再多的培训和考核都是补救，而且往往补不回来。

责任划分的意义不在于追责，在于找到能改的那个点。如果是场景没描述清楚，那就重新梳理场景；如果是操作太长，那就优化时长；如果是推广节奏不对，那就改成试点先行。找错了原因，改多少次都没用。

最实用的一条建议：把「单次操作时长」写进验收标准。这个指标一旦成为硬约束，整个设计的方向就会变。功能可以少，慢一点都不行。

青岛管理系统开发上线员工不用，责任在谁