如果你不知道从何入手，答案只有一个：不要急于系统化。先思考哪些环节可以被消除。
此前我曾写过一篇关于系统开发失败是结构性问题，而非高管缺乏知识的文章。基于这一结构，本文将探讨客户实际应该采取的第一步。在不确定时选择“直接系统化”，是你能做出的最昂贵的决定。 如果顺序搞错了，你只是在花钱自动化低效的流程。
■ 误区：“系统化 = 解决方案”
在与客户咨询时，最初的诉求几乎总是一样的：“我们的运营效率低下，所以想引入一套系统。”然而，仔细审视后发现，大多数案例中都存在本可以在引入任何系统之前就解决的浪费。
例如，考虑一家公司的报价流程。他们允许销售人员在新系统中创建报价单，但内部审批仍需打印纸质表格并物理流转。审批通过后，员工必须手动将数字报价中的金额重新录入纸质表格。尽管已经“系统化”了，整体工作流却增加了一个步骤：“在系统中创建，复制到纸上”。根本原因在于，在构建系统之前，没有人问过：“我们能取消纸质审批流程吗？”数百万资金被投入其中，但由于自动化了本该削减的浪费，大部分成本实际上都打了水漂。
■ 先削减，后添加
商业改进中有一个长期原则叫做 ECRS：Eliminate（能否移除？）、Combine（能否合并？）、Rearrange（能否改变顺序？）、Simplify（能否简化？）。只有在彻底考虑这四个维度之后，才应考虑 Automate（系统化）。
许多项目经理跳过这个顺序，直接跳到“自动化”。结果，那些本该被消除的任务、可以合并的双重录入以及可以简化的审批流程，都被直接固化到了软件中。最终得到的是一个更快、更准确地执行无用任务的系统。 讽刺的是，因为他们觉得自己已经“系统化”了，没人注意到潜在的浪费。
这与我之前的观点一致，即系统开发失败是结构性问题，而非无知所致。跳过 ECRS 序列正是这种有缺陷的结构的一部分。
■ 决策时的四个问题
在考虑系统化之前，请按顺序问自己以下四个问题：
- 这项任务是否可以完全消除？ (Eliminate)
- 多个任务或部门的工作流是否可以合并？ (Combine)
- 仅通过改变顺序或职责是否就能实现改进？ (Rearrange)
- 方法本身是否可以简化？ (Simplify)
只有回答完这些问题后剩下的任务，才是系统化的候选对象。反之，如果在未考虑这四个问题的情况下就进入需求定义阶段，失败的种子就已经埋下了。
■ 应对对速度的渴望
你可能会争辩说：“我们没有时间深思熟虑；我们需要快速实施系统。”然而，ECRS 分析通常只需要几天或几周的时间。相比之下，如果仓促上线的系统后来需要重做需求定义，你会损失几个月的时间。 欲速则不达。
另一个反对意见是：“我们的运营太复杂，不适合外部框架。”但 ECRS 并不需要深厚的运营知识。了解细节的人是前线员工；ECRS 只是一系列问题，促使他们去问“这能去掉吗？”或“这能合并吗？”它无需专业知识即可立即使用。
■ 明天你可以做什么
不需要大规模的组织变革。挑选一个你目前想要“系统化”的任务，回答上述四个问题。通常，第一个问题（Eliminate）会揭示出你未曾考虑过的选项。
“不知从何入手”的真正原因，通常不在于是否要系统化，而在于不知道在系统化*之前*该分析什么。 如果遵循正确的顺序，决策并不困难。
下次，我将针对高管们最普遍的痛点：“人员流失”进行探讨。我们将讨论离职率背后的组织结构。
如果有兴趣，请通过此链接私信我。
■ 相关过往文章
