我不认为 AI 会让你的流程更快

原文：I don’t think AI will make your processes go faster

我感觉现在几乎每个组织都或多或少在关注流程优化。市场低迷时，这种事尤其常见。如今，这个话题又叠加了一层 AI 叙事，以及随之而来的那些不现实期待。

为了更好地讨论这个问题，我重新读了这个领域的两本经典：《丰田模式》（The Toyota Way） 和 《目标》（The Goal）[^1]。大学时我读过这两本书，但这次重读让我意识到，很多流程优化实践其实过于简单化，而且常常误判了真正应该关注的重点。

视觉上的瓶颈

我来说明一下。

这是一个用于演示的甘特图。通常你会看 BPMN，但这里用甘特图更容易说明问题。

看这张甘特图，你会立刻发现耗时最长的是软件开发。如果你的任务是提升项目吞吐量，第一站自然会是软件开发。而这个判断本身没错。

问题在于，我通常看到的做法是：往问题上堆人，或者直接假设 AI 会让它快得多。

人们通常不会继续追问：这件事为什么会花这么久？更重要的是，某个环节持续时间长，并不自动说明问题根源就在那里。

从上游解决问题

我们现在谈的是软件开发，但这同样适用于所有比预期更慢的流程。

每个软件开发者都知道，项目不可能只靠打字更快就变快。如果真是这样，我们所有人都该去上打字课。

软件开发的本质，是把一个问题转化为计算机能够理解并自动解决的方案。最好还要安全、可扩展。

要做到这一点，你需要完整理解问题。可以通过功能文档或范围文档来获得这种理解（如果你更偏瀑布式），也可以通过与领域专家持续迭代来获得（如果你更偏敏捷）。

真正拖慢软件开发的，往往正是这一部分：弄清一个只有标题、含糊不清的功能请求到底是什么意思。

“销售完成后给用户发邮件”到底是什么意思？可以，我们能发邮件。但邮件里应该写什么？如果销售流程中出了问题，还要不要发送错误邮件？什么时间点才算销售完成？

直接把 AI 扔进去

关于软件开发自动化（AI 生成代码），我经常听到一种说法：你可以直接绕过开发环节，让软件开发者变成项目经理。围绕 AI 软件开发的讨论，其实非常好地暴露了这个问题。

很多人期待 AI 开发带来的结果会是这样：

但事情不是这样运转的。在这里，我们会遇到和前面完全相同的上游问题。

没错，AI 可以很快生成代码（这是不是好事还可以讨论），但这并不意味着它生成的就是正确代码。

在人类开发和 AI 开发的比较中，人们总是忽略 AI 要做出可用结果所需的手把手引导。真实情况更像这样：

也许这种方式确实比旧的工作方式更快。但我认为，这种比较并不公平。这样工作要求领域专家和产品专家更深地参与进来，也意味着每个功能和每个 bug 修复都必须被写到极其细致的程度。

而这恰恰是软件开发者从这个职业诞生以来一直在请求的东西：请把问题是什么、最终结果应该是什么样子，清清楚楚地写出来。

如果你给人类开发者同样详细的功能/范围文档，你同样会看到生产力大幅提升。

真正加快流程

如果你想加快流程，就要确保真正执行工作的人拥有完成工作所需的一切条件。

这意味着，如果你的法务审批流程很慢，你应该先看启动一次法务审批到底需要什么。如果他们必须追着五个不同的人补齐不完整的文档，那么给部门增加更多律师，并不会让这个流程变快。

《目标》中的一条重要经验是：“瓶颈应该收到可预测的高质量输入”。

我认为，这才应该是流程自动化的第一站。