员工不是系统里的缺陷。问题可能出在软件上。

员工不是系统里的缺陷。问题可能出在软件上。

员工不愿意使用新的内部应用时，把原因归结为“抗拒改变”很省事。这样一来，当初的采购决定、需求和实现方式，就不用像使用它的员工一样接受审视了。

再发一封催大家登录的通知之前，先看看一个人真正想把工作做完时，会遇到什么。

他们可能需要培训。也可能是在绕过你花钱做出来的缺口，勉强维持业务运转。

上线会议上没人提到的那张表格

设想一家维修公司采购了新的工单管理应用。以下只是说明问题的假设场景，并非客户案例。

应用记录客户、设备和预约时间，管理层也能清楚地看到未完成的工单。但是，技术人员无法记录“一件替换零件已到货，另一件仍在采购中”。整个工单只能标成“等待零件”或“可以安排维修”。

于是，协调员另建了一张表格，记录这些缺失的细节。联系客户之前，要查应用、查表格，再查供应商发来的邮件。到了下班前，还得更新应用，让看板上的信息保持最新。

你可以说这是使用率不佳。但我更想知道：为什么公司指定的工具，连协调员每周二都要处理的情况也表示不出来？

禁止使用表格，并不会让缺失的功能凭空出现。它可能只是让这些工作变得更难看见。

能力不错的 AI 工具，也可能在使用过程中失去用户

微软在 2026 年 10 月 8 日发表了员工自助服务智能体的采用案例。其内部研究发现，仅靠技术表现无法解释员工是否愿意使用这项服务。有些人此前已经尝试过其他解决办法，却又收到重复的建议，而且不清楚怎样才能找到人工支持。

后续设计工作着重处理已有上下文、能力边界和转接流程。这是微软对自身上线过程的总结，并不能证明相同改动在另一家公司也会带来相同结果。

我的理解是，人们会根据从求助到解决问题的整个过程来判断体验。在一条令人沮丧的流程中途给出好答案，并不等于帮他们完成了任务。

普通业务应用也是如此。一个页面可以完全符合规格，但围绕它展开的实际流程，仍然可能很折腾。

值得研究的是那套额外流程

表格、复制的消息或纸条，可能暴露出应用无法保存的信息、无法完成的交接，或者一直没人定下来的业务规则。有时，它也只是反映了人们对熟悉方式的偏好。先观察，才能判断属于哪一种。

我会先找一位经常做这项工作的员工，请他用贴近实际、且得到妥善保护的数据完成一个有代表性的任务。让他照平时的方式操作，包括应用之外的步骤，再问清楚这些步骤为什么存在。

然后跟着工作走到下一个人那里。前一位用户少填一个字段，可能省了时间，却让同事花更多时间找答案。页面操作更快，并不一定意味着整个流程更快。

在维修公司的例子里，有用的发现可能很具体：把零件状态与整体工单状态分开，清楚显示还缺什么，以及谁在等它。这是值得验证的明确改进，并不意味着必须重做整个应用。

页面慢，可能需要优化性能；反复复制，可能需要系统集成；责任不清，可能需要管理层先做决定，再改代码。把同一种解决方案卖给这三类问题，是偷懒的咨询。

必要的控制步骤，也会占用人的时间

这不意味着所有不受欢迎的步骤都应该消失。二次审批、访问限制或必填记录，都可能在保护业务。大家习惯的捷径，也可能丢失信息，或者把数据暴露给不该看到的人。

关键在于：这个步骤是否有明确作用，软件是否让它变得不必要地困难。该保留的控制就保留，解释清楚，给合适的人相应权限，并尽可能消除周围的重复录入。

培训也要区分这两种情况。教会大家一个陌生但有用的流程，值得投入。教大家反复绕过一个本可避免的缺陷，只不过是把变通办法算进了培训预算。

给开发者一个能够验证的问题

单独一句“提高使用率”，太模糊，算不上有用的开发需求。对维修公司来说，更好的表述是：让协调员看清还有哪些零件未到货，并且不必核对另一张表格，就能安排预约。

提前约定怎样验证，包括分批到货、错发零件和更改预约的情况。修改完成后，再观察同样的工作，记录完成时间、纠错次数和应用之外的步骤，还要确认有没有把额外工作转给另一个人。

这些观察能帮助你决定下一步怎么做。仅靠登录次数，无法判断新流程是否更好，尤其是在员工被要求必须登录的时候。

我也会给临时并行流程指定负责人和退出条件。在核验数据迁移期间，同时运行两套系统可能是负责任的做法。但让所有人无限期维护两套系统，就需要给出理由。

开发者应当清楚说明缺口在哪里、建议怎么修，以及怎样知道改动起了作用。如果应用本来就支持这项工作，真正的问题是培训或尚未确定的制度，也应该如实得出这个结论。

把你们的变通办法告诉我们

Rosecraft 提供业务应用、系统集成和现有系统改进服务。如果团队一直在绕过已经买来的软件工作，先做一次聚焦问题的评估，可能比直接拿到替换方案更有价值。

准备好听听真正需要修复的地方，即使它会挑战原先的计划了吗？告诉我们团队想完成什么工作、应用在哪一步挡了路，以及大家现在怎么绕过去。描述流程即可，不要发送密码或客户记录。我们可以讨论一次范围明确的评估，以及问题实际需要的开发工作。

员工自行摸索出的变通办法，可能就是你手上最有用的需求文档。