为什么业务部门永远觉得系统不好用？

一、一个几乎每个企业都发生过的对话

系统刚上线不久，业务部门开始反馈：

“这个系统不好用。”

IT问：“哪里不好用？”

业务说：“操作太复杂，流程太多，不如以前方便。”

IT回应：“这是规范流程，这是为了控制风险，这是标准做法。”

最后双方的结论都很一致：业务觉得系统不好用，IT觉得业务不理解系统。

项目进入一种熟悉的状态：表面上线，实际对抗。

二、“不好用”到底是什么意思？

“系统不好用”是信息化项目中最高频的评价之一。

但这句话本身很模糊。因为不同角色眼中的“好用”，完全不是一回事。

业务部门眼中的好用，往往是操作简单、步骤少、速度快、最好和以前一样。本质是是否方便完成当前工作。

IT眼中的好用，往往是流程规范、数据完整、权限清晰、可控可追溯。本质是系统是否满足治理要求。

管理层眼中的好用，往往是数据可统计、过程可监控、风险可控制。本质是系统是否提升管理能力。

三种好用，背后是三种目标。目标不同，评价自然不同。

三、为什么矛盾是必然的？

很多项目把不好用理解为界面问题或体验问题，但现实中，很多“难用”其实来自管理约束。

系统的本质之一，就是约束。

系统上线后，不能随意跳步骤，不能随意改数据，不能绕开流程，不能只靠口头沟通完成工作。

从业务角度看，原来的灵活性减少了，自然会觉得不方便。

但从企业管理角度看，正是这些约束让流程变得可追溯、数据变得可信、风险变得可控。

信息化的本质，是从人治走向结构治。这个过程一定会触碰原有工作习惯。

四、很多“好用”，其实是无序

没有系统时，很多工作看起来很方便。

Excel可以随时改，微信可以随时沟通，流程可以私下协调，领导一句话可以临时处理。

这些方式短期看很灵活，但长期看存在三个问题：不可追溯、不可复制、不可规模化。

企业规模越大，这种灵活性的代价越高。

系统上线之后，原来隐藏的步骤被显性化，原来依赖人的规则被固化，原来模糊的责任被清晰化。业务感受到的不是简单的工具变化，而是工作方式的变化。

五、几个典型冲突场景

1. 流程变多了

业务说：“以前一步就能完成，现在要三步。”

但真实情况可能是，以前另外两步只是没有记录，或者靠人工私下完成。系统只是把这些隐形动作显性化了。

2. 字段变多了

业务说：“以前填一个字段，现在要填五个。”

但背后可能是财务需要核算，风控需要校验，管理层需要统计，后续系统需要集成。一个页面承载的是多个部门的管理需求。

3. 效率变低了

业务说：“系统上线后反而慢了。”

这需要分辨，是操作设计确实低效，还是流程更完整之后带来的局部成本上升。

很多时候，局部效率下降，是为了换取整体效率和管理可控。

六、真正的问题在哪里？

系统不好用，通常是三类问题叠加。

第一类是认知错位

业务期待方便，系统提供规范，双方对系统价值的理解不同。

第二类是设计问题

确实存在过度复杂、不必要校验、页面不合理、流程绕远等情况，这些需要优化。

第三类是推进方式错误

很多项目没有解释为什么这样设计，没有让业务参与流程设计，也没有给用户适应时间。

当业务只看到操作变复杂，却没有看到管理价值时，抵触就会产生。

七、如何让系统既能用，又能管？

第一，区分必须复杂和可以简化。

不是所有复杂都是合理的。监管要求、内控要求、数据要求带来的复杂必须保留；历史遗留、设计过度、重复录入带来的复杂则应该优化。

第二，做分层设计。

普通用户看到简洁操作界面，管理人员看到完整分析数据，系统后台保留完整规则逻辑。复杂性不应该全部压给一线用户。

第三，给业务适应时间。

上线不是结束，而是开始。培训、答疑、优化、迭代，都是上线后必须持续做的事。

第四，让业务参与设计。

参与不只是提需求，而是一起讨论流程、规则和例外场景。业务参与越早，上线后的抵触越少。

八、企业实践建议

企业可以建立用户体验评估机制，但不要简单用好用或不好用评价系统，而要拆解为学习成本、操作路径、错误率、完成时间和满意度。

也可以建立持续优化机制，把上线后的问题纳入版本迭代，而不是把所有反馈都当成抱怨。

更重要的是，要形成一个共识：系统的目标不是让所有人都觉得方便，而是在可控的前提下，让业务尽可能顺畅。

九、写在最后

“系统不好用”这句话本身并不重要。

重要的是，它背后反映了企业内部不同角色之间的认知差异。

如果只停留在表面争论，问题会反复出现；如果能看清背后的流程、权责和管理逻辑，系统才有可能真正发挥价值。

信息化从来不是一场工具升级，而是一场关于规则、权力和效率的重新分配。

在这个过程中，不好用有时不是问题，而是变化正在发生的信号。

3. 为什么业务部门永远觉得系统不好用？