业务数字化后的最大变化，即留痕与规范，而这一变化容易让系统操作者有所不满，并将数字化系统带来的 " 不便 " 归咎为系统 " 不好用 "。怎么去理解并解决数字化系统的 " 不好用 " 呢?这篇文章里，作者尝试梳理数字化系统 " 不好用 " 的 4 个真相，一起来看。

系统是业务的数字化的表现形式。

有系统之前，沟通基本靠吼，对规则的弹性极高，没有规则可以现定，有规则可以通融，这是人和人之间的游戏。

有系统之后，哪怕同事就坐在你旁边，你们也要通过系统来交换信息，且交换的是系统定义好的标准信息。

留痕，规范，这就是业务数字化后的最大变化。

这也是系统操作者心生不满的来源，留痕看上去有追责嫌疑，而规范就是没事找事。

把数字化等同于管理层不知道民间疾苦，只为追逐热点的项目，主观上把所有和系统有关的事情，都总结为 " 不好用 "。

意愿上不想用，吐槽说系统不好用。

使用系统带来的路径变长，管控变严，归纳为不好用。

交互体验上的反人性，也说不好用。

一系列的不好用反馈到公司，对管理层实施数字化的信心是严重的动摇。

今天我们一起来抽丝剥茧，认清 " 不好用 " 的四个真相，以此对号入座，夯实信心。

真相 1：数字化势必带来受益方和损益方

系统的操作者，通过使用系统产生数据，让公司内部得以留存数据，利用数据。

但对于操作者本身，由于受制于系统约束和业务限制，大概率会增加工作量。

无论系统再怎么重视用户体验，简化步骤，他们的工作就是比之前增加了，成为这次数字化损益方。

数字化是一次改革，势必有受益方有损益方，受益方说好用是自然的，损益方吐槽说不好用也是自然的。

对此我们要有心理预设，" 无痛数字化 " 只是理想的伊甸园，说不好用再正常不过，它也不应该成为数字化信心的减弱器。

有一个小办法可以快速让你识别出受益方和损益方。

完整列出数字化过程中涉及的所有角色。

以角色做区分，列出每个角色使用系统前后的工作步骤、工作规范、所花时间。

前后对比，列出受益方和损益方，且按照损益多少对损益方进行排序。

心中有数，未来损益方角色的声浪再大，也不会轻易动摇。

真相 2：数字化过程往往会忽视其工具价值

数字化会产生损益方，但确实又需要损益方操作系统，怎么让他们心甘情愿?

有人说，靠命令，靠规范，靠管理。

就个人经验来说，这些方式在一定程度内，有用，但不好用。

这些 " 外力 " 凌空而来，在执行层眼里就是短期要应付的事情。

下命令说每日要录入数据，但没有持续的检查机制，就会变成：检查就做，不检查不做。

什么时候管理者不再检查，录入就慢慢停止了。

而管理者的精力分配，来自于高层的关注方向，这就导致，数字化需要公司从上到下时时刻刻紧盯，成为了一个管理成本、执行成本极高的项目。

所以我们应该考虑另一种形式的驱动力——内力，让员工自发的使用系统。

把数字化作为辅助员工工作的工具，换句话说，就是 " 赋能 "。

例如 SCRM，通过统一企业内部的资料、话术，赋能销售更好的触达客户，并通过数据及时看到客户对资料的反应，调整销售策略。

这实实在在地为销售提供了帮助，解决了在销售过程中的遇到的不少问题，自然也比传统的 CRM 更受销售欢迎。

多说两句，数字化的初衷往往是为了解决数据问题，让管理者能实时准确的看到数据，更好地作出经营决策。但如果你的目标是数据价值，你就不能只考虑数据价值。

数据价值的前提，是员工操作系统来获得线上化的数据。而寄希望员工于操作系统，不可能只靠强制推行，势必要提升系统的工具价值赋能员工，也需要在过程中重塑流程改造协同价值。而这一切改造的最终结果，不仅是管理者得到了数据价值，也能形成更佳的客户价值。

真相 3：交互体验是蛋糕上的樱桃

有领导会说：数字化既然有损益方，那我们就要更重视用户体验，给他们提供好的使用感受。

然而在我做企业内部数字化的数年间，发现大家对于体验的要求是——没有要求。

不管是做管理模块，做工具模块，做数据模块，大家提出的都是功能需求而非体验需求。

不同于 C 端的产品，由于有同类型的产品映衬，用户对于那些 " 不同的 "" 多了一个步骤的 " 操作非常敏感。

在内部数字化系统中，绝大多数人对于体验既不敏感，也不追求。

和各个角色深度交流，引导着去聊和 UI、交互相关的内容，次次都是相顾无言。

大家使用系统的目的很简单，就是要完成某件事情，这里点一下，那里点一下，次数多了就成为了膝跳反射，还谈什么体验呢。

如果是 SaaS 产品，可以在产品后期，适当投入精力在交互体验上，但如果只服务于内部用户，交互体验只应该是蛋糕上的樱桃，做好蛋糕比放樱桃更加实际。

真相 4：缺少流程再造，线下流程直接生搬

业务数字化，直接照搬线下流程到线上，看上去合理，但实际问题很大，甚至可以说最大的不好用就来源如此。

正如前文所言，线上的系统化是代码工程的产物，它规范，它非此即彼，它控制人的行为，它改动起来成本不小。

线下有弹性的的方式搬到线上，都要收敛为一套合乎系统逻辑的严丝合缝的操作规范。

如果业务本身就不合理，又没有适应系统作出改动，只会放大这样的不合理。

所以，使用系统做业务，势必要经过对业务流程的重新设计。

在这一过程，我们可以用：0-100-1000 的三段式来进行流程重构。

0，是第一个阶段，是归零。

重新看待要线上化的业务，去梳理业务流程中涉及的角色，角色需要做的操作。

这一步可以由业务负责人操刀，无需考虑线上要怎么做，线下是怎么运行的，如何运行最合适就怎么写。

100，是第二个阶段，把所有场景分支重新补全。

这一步可以由产品经理和业务人员，通过现场重勘，面谈，问卷等方式，补齐线下可能遇到的各种异常场景。

1000，就是重新定义使用系统上要做什么事情。

这一步以产品经理为主，把一切角色，流程，操作落实到系统层面，并和业务达成一致。

思考：

哪些角色是必须的?哪些可以省略?

每个角色的操作和查看权限如何界定?

哪些操作是必须的?哪些可以省略?

哪些操作结果是需要验证的?是事前验证、事中验证还是事后?

这些操作是否要被管理和监控?是否涉及审批、风控等其他角色?

这些操作是否有批量处理或者提升效率的诉求?自动化、AI 等能力是否可以支持或者替代?

最后呈现出每一个角色的新 SOP，具体是什么职责，需要在哪些页面，以什么标准，做什么操作一目了然。

0-100-1000 是一个简单的流程再造的步骤，需要产品经理和业务人员一起参与，业务上给全信息，陈述规则，产品上贴近系统，延续业务目标，考虑到系统的限制和优势，去重新进行流程设计。

以业务为核心，彼此做擅长的事情，尊重理解，这是业务流程再造的必要分工。