MTO/MTS 是 ERP 里非常基础的概念，但越基础的问题，越容易被一句话带偏。很多资料把 MTO 解释成“接到客户订单后再生产”，这句话从业务层面看不能说完全错，但放到 SAP 系统层面，就远远不够。
因为从系统角度看，真正的问题并不是“有没有需求才产生供应”。MRP 本来就是根据需求产生供应。真正需要判断的是：供需平衡按照什么维度做，成本按照什么维度归集，追溯和特殊库存要做到什么程度，以及后续变更调整的代价有多大。
为什么这么基础的问题还会让企业纠结
有些企业上线几年后，为了更好的“追溯”，把 MTS 调整成 MTO；也有些企业上线后，为了减少调整、避开 MTO 的复杂性，又把 MTO 调整成 MTS。
这两种调整本身不一定错，问题在于很多决策是在没有真正理解 MTO/MTS 的情况下做出的。它影响的不只是生产模式，还会牵涉产销协同、库存归属、成本核算、计划策略和系统配置。
业务说的“按单”和系统里的 MTO 不是一回事
业务人员说“按单生产”或“按单采购”，很多时候只是说：有需求才生产，有生产需求才采购。但在系统里，这并不自动等同于 MTO。
举个简单例子：成品计划模式设置为 MTS，不做预测、没有额外库存，直接创建销售订单，此时生产确实可能按照销售订单需求产生。销售订单要多少，系统就建议生产多少。从业务语言看像“按单”，但从系统策略看仍然是 MTS。
再比如成品采用 MTS，也可以有预测。预测驱动半成品和原材料备料，销售订单再驱动最终生产，这在系统层面仍然可以是 MTS，而不是因为销售订单参与了生产，就自动变成 MTO。
关键点在这里：业务语言描述“为什么需要供应”，系统语言决定“在哪个维度做供需平衡”。这两件事不是同一件事。
更有用的判断维度
第一是供需平衡的维度。供应是按销售订单隔离，还是可以在多个需求之间共享？是否需要特殊库存？哪些需求可以互相消耗？这些才是 MTO/MTS 选择里最重要的问题。
第二是成本核算归集的维度。采用 MTO 可以让标准成本和实际成本的分析更细，但它也会带来库存、变更、替代料、执行调整等一系列管理后果。
一个很典型的误会
有些业务部门说“原材料是按单采购的”，意思只是：生产不需要，我们就不会采购。顾问如果直接接一句“那原材料用 MTO 吧”，这两个人其实不在一个维度上对话。
前一句是在讲业务纪律，后一句是在改系统计划逻辑。把这两层混在一起，项目很容易引入不必要的复杂性，却没有真正解决追溯、成本或计划问题。
所以，MTO/MTS 不是一个口号式选择。它应该在业务目标、系统供需维度、成本影响和后续调整代价都讲清楚之后，再做决定。