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

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

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

“这个系统不好用。”

IT问：“哪里不好用？”

业务说：

操作太复杂
流程太多
不如以前方便

IT回应：

这是规范流程
这是为了控制风险
这是行业标准做法

最后双方的结论都很一致：

业务觉得：

系统不好用

IT觉得：

业务不懂系统

项目进入一种熟悉的状态：

表面上线，实际对抗。

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

“系统不好用”这句话，在信息化项目中几乎是最高频评价。

但问题在于：

这句话本身，几乎没有信息量。

因为“好不好用”，在不同角色眼中，完全不是一回事。

业务眼中的“好用”

操作简单
步骤少
速度快
和以前一样

本质是：

是否方便完成当前工作

IT眼中的“好用”

流程规范
数据完整
权限清晰
可控可追溯

本质是：

是否满足系统治理要求

管理层眼中的“好用”

数据可统计
过程可监控
风险可控制

本质是：

是否提升管理能力

问题在这里开始显现：

三种“好用”，本质是三种完全不同的目标。

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

很多项目把“系统不好用”理解为：

设计不合理
体验不佳

但现实是：

很多“难用”，其实是“必须如此”。

1. 系统的本质，是“约束”

系统不是为了让人更自由，而是为了：

控制流程
固化规则
限制随意性

所以一旦系统上线：

不能随意跳步骤
不能随意改数据
不能绕流程

从业务角度看：

自由减少了

自然就会觉得：

不好用

2. 信息化，本质是“从人治到结构治”

在没有系统之前：

可以灵活处理
可以人为判断
可以临时调整

但系统上线后：

所有规则必须明确
所有流程必须固定

这意味着：

原本依赖经验的空间，被系统替代

对很多人来说，这不是“优化”，而是：

失去控制感

3. 很多“好用”，其实是“无序”

有些被认为“好用”的方式，例如：

Excel手工处理
口头沟通
私下协调

看起来高效，但问题在于：

不可追溯
不可复制
不可规模化

系统一旦介入：

这些“隐性效率”被打破。

四、几个典型的冲突场景

场景一：流程变多了

业务反馈：

“以前一步，现在要三步。”

但真实情况是：

以前有两步是“隐形”的
只是没有记录

系统只是把这些步骤显性化了。

场景二：操作变复杂了

业务认为：

“以前填一个字段，现在要填五个。”

但背后是：

管理层需要数据
财务需要核算
风控需要校验

系统承担的是：

多角色的需求叠加

场景三：效率变低了

业务感觉：

“现在反而更慢了。”

但需要分辨：

是操作变慢
还是流程更完整

很多时候：

局部效率下降，换来整体效率提升

五、真正的问题在哪里？

说到底，“不好用”并不只是体验问题，而是三类问题叠加：

1. 认知错位

业务期待的是：

方便

系统提供的是：

规范

2. 设计问题

确实存在一些情况：

过度复杂
不必要的校验
不合理的流程

这些属于：

可以优化的问题

3. 推进方式错误

很多项目：

没有解释为什么要这样设计
没有让业务参与设计
没有过渡方案

导致业务只看到：

结果，而不是原因

六、如何让系统“既能用，又能管”？

这才是信息化项目最核心的能力。

1. 区分“必须复杂”和“可以简化”

不是所有复杂都是合理的。

需要明确：

哪些是监管要求
哪些是历史遗留
哪些是设计过度

2. 引入“分层设计”

例如：

普通用户：简化界面
管理人员：完整信息
系统层：完整逻辑

不同角色看到不同复杂度。

3. 给业务“适应时间”

系统上线不代表完成，而是开始：

培训
调整
优化

很多项目的问题是：

上线即结束

4. 让业务参与设计

不是让业务提需求，而是：

参与流程设计

这样可以减少：

认知冲突

七、企业实践建议

建立“用户体验评估机制”

但评估维度不是简单的：

好用 / 不好用

而是拆解为：

学习成本
操作路径
错误率
完成时间

建立“持续优化机制”

系统不是一次性产品，而是：

持续演进的工具

明确一个共识

系统的目标不是：

让所有人觉得方便

而是：

在可控的前提下，让业务尽可能顺畅

八、写在最后

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

重要的是：

这句话背后反映的，是企业内部不同角色之间的认知差异。

如果只停留在表面：

问题会反复出现

如果能够看清本质：

系统才有可能真正发挥价值

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

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