上游思维

一句话定义

上游思维（Upstream Thinking）是在问题造成损失之前，从反复出现的事件往前追，找到持续制造这些事件的系统条件、早期信号和可干预位置，把资源从“处理这一次”逐步转向“减少下一次发生”。

核心判断

一个问题如果不断回来，就不能只问“这次怎么解决”，还要问：什么机制在持续制造它？最早什么时候能看见它？哪里可以提前干预？

与系统思考、S'FOCUS的边界

上游思维先把问题处理的时间位置从“事后”前移到“事前”；系统思考解释结构怎样持续生成结果；S'FOCUS / TOC 再判断当前限制系统目标实现的核心约束。最上游的因素，不一定就是瓶颈。

适合用在

• 客户投诉、销售掉单、交付返工、人员流失等同类问题反复出现。
• 团队长期依赖老板或一线员工救火，却没有形成预防机制。
• 想从滞后结果指标转向领先指标、早期预警和最小干预。

不要这样用

• 急性危机仍应先止损；不要为了“上游”暂停安全、现金流和重大客诉处置。
• “发生得更早”不等于“因果更根本”。
• 预防不一定更省钱，要同时看预防成本、误报和副作用。

来源与证据边界

Dan Heath 在《Upstream》中把重点放在“preventing problems rather than simply reacting to them”，并讨论阻碍上游行动的三类障碍与七个关键问题。本页把这些思想操作化为企业经营诊断流程，不把它写成万能根因法。参考：Dan Heath — Upstream；官方一页总结。

七步上游检查

1. 固定一个反复发生的结果，记录频率与损失。
2. 确认它是模式，不只是一次偶发。
3. 沿时间轴向前追：发生前重复出现过什么条件、决策和交接？
4. 找系统条件：哪些规则、信息、激励或资源配置让它持续发生？
5. 找最早的可靠信号与可干预位置。
6. 设计一个小范围、可逆的预防实验，同时保留下游兜底。
7. 用“问题发生率＋副作用＋预防成本”验证是否真的有效。

关键问题

• 这个问题过去90天到底发生过几次？
• 每次发生前，有没有重复出现的信号？
• 哪个条件不改，换一个人以后问题仍会回来？
• 最小可验证的上游动作是什么？