这是“天枢系统”系列博客的第五篇，也是最后一篇。前四篇分别讨论了系统设计原则、数据清洗、预测模型和库存计划；这一篇不再讲算法，聊聊系统落地时会遇到的组织、流程和人的问题。

0. 算法不是最难的部分

前四篇把天枢系统的核心逻辑讲完了：数据清洗、物料分层、模型竞赛、库存计划。这些都有标准答案——公式是公开的，算法是成熟的，代码是可以写的。

但系统落地时，卡住项目的往往不是算法。

计划员不信任系统怎么办？销售不愿意提供促销计划怎么办？采购说供应商交期数据不准怎么办？管理层问“这个系统到底能省多少钱”怎么办？

这些问题的答案不在代码里，在组织、流程和人的协同里。

1. 落地要跨的三道坎

1.1 数据坎：历史数据没有想象中那么好

设计阶段，我以为数据是完整的、干净的、可用的。真正接入 ERP 才发现不是那么回事：

问题具体表现影响
取数不完整销售订单只取了部分组织，历史数据缺几个月模型训练样本不足，预测不准
数据质量差促销、退货、录入错误混杂在一起需要大量人工清洗
主数据缺失物料没有上市日期、提前期、MOQ 等字段物料分层和库存计划无法计算
口径不一致同一物料在不同系统里编码不同数据关联失败

我的做法是先做清洗，允许人工审核。不追求一次到位，先跑通最小闭环，用可用数据验证逻辑，再逐步补全缺失字段。

1.2 人坎：不做黑箱

天枢从设计第一天起就定了一条：不做黑箱。这句话要落地，就得让参与的人先懂这套系统怎么转。

培训的对象不只是一线的计划员。销售、采购、IT、管理层，每一个跟这套系统有交集的人，都得来。他们每个人输入的东西不一样，看到的东西也不一样。销售输入促销计划，采购维护供应商交期，IT 维护数据库和接口，管理层定服务水平目标。他们如果不知道系统怎么用他们的输入，他们就不会认真维护这些东西。

培训的目标就一个：让每个人知道，自己的那块东西在整条链路里是什么位置。具体怎么讲，放在后面落地路径第一步说。

1.3 组织坎：销售、计划、采购各自为政

预测系统需要跨部门协同，但现实中各部门往往目标不一致：

部门关注点与预测系统的冲突
销售冲业绩，希望多备货不愿意提供准确促销计划，担心被约束
计划库存周转率，希望少备货预测不准时，倾向于自己拍脑袋
采购采购成本，希望大批量不愿意维护小批量、多批次的参数
财务资金占用，希望零库存对安全库存有天然抵触

我的做法是用数据说话，让协同有依据。不追求一步到位，先解决最痛的场景，定期复盘，让各部门看到预测带来的实际改善。

但光靠数据和复盘还不够。得有一个固定的场合，让各方定期把话讲开。这个事放到后面说。

2. 落地路径：培训、试运营、再上线

不要试图一步到位。我分三步推进。这三步，刚好对上前面那三道坎。

2.1 第一步：全员培训（解人坎）

第一步是全员培训。讲的其实就是前面说的那道坎——让参与的人懂系统。

培训讲什么？讲六步链路：

天枢数据库（SalesForecast）
        │
        ├── 数据清洗 → 异常值检测与人工审批
        ├── 物料分层 → A/B/C/I 四级标签
        ├── 模型竞赛 → 9种模型验证，自动择优
        ├── 批量预测 → 冠军模型预测未来7天
        ├── 库存计划 → 安全库存、订货点、补货建议
        └── 导出模板 → 金蝶预测单 + 采购申请单

下面我以计划员为例，把六步完整走一遍。她每天打交道的，就是这条链路上跑出来的数。

我不会一上来就讲公式。先讲这条链路怎么走，每个环节为什么存在，这个环节出了问题后面会怎么崩。

数据清洗先讲为什么从销售订单取数，不从销售出库单取数。这个问题讲不清楚，计划员审核异常值的时候就会瞎审。有个真实的例子：某个物料订单量 1200，出库量 120，差了十倍。系统标记成疑似录入错误，但到底是不是录错，得人来看。计划员要是不知道“订单是需求，出库是供应”这个区别，他可能直接把 1200 当成真实需求保留下来，那这个物料的预测就全歪了。

物料分层，讲的是为什么分 A/B/C/I 四级。不分级，所有物料用同一套模型和同一个安全库存公式，结果是爆款备不够、长尾压一堆库存。分级之后，爆款用全套模型、备足安全库存，长尾用 Croston 或者直接按单采购。

模型竞赛这一步，重点讲双标准择优：MAPE 要低，ME 要接近零。有一件事得说透——为什么 MAPE 低的模型也可能是坏模型。一个总是高估 5% 的模型，MAPE 可能很小，但长期下来让你多备 5% 的库存。所以要加 ME 这道闸。

批量预测和库存计划，讲预测区间和安全库存的关系。预测区间宽，说明这个物料波动大，安全库存要多备；区间窄，可以少备。这条线拉通，计划员才能理解为什么同一个服务水平下，不同物料的安全库存差那么多。

导出模板最直观，讲天枢输出什么、金蝶接收什么、计划员在中间做哪道审核。

六步讲完，每个人会知道自己那块东西在哪。

这一轮培训不考试。就是把逻辑讲明白，允许打断，允许质疑。培训周期不会短，手册也不会一遍写完。但方向定了：参与的人都要懂，不是只有我一个人懂。

2.2 第二步：试运营，案例教学（解数据坎）

第一轮培训讲的是“系统怎么转”。试运营的时候讲的是“这个数为什么是这么来的”。

试运营不全量跑，先挑一批物料——爆款挑几个、长尾挑几个、有促销的挑几个、季节性明显的挑几个，覆盖几种典型场景。每周跑一遍，结果拿出来，跟计划员一起看。

看的时候不看结论，看过程。

比如某个爆款，系统这周选了 Croston 而不是 SMA。为什么？我们把这个物料最近一年的数据调出来，看它的零值占比，看它的间歇性特征，看其他八个模型在验证集上的 MAPE 和 ME。看完大家就明白，不是系统随机选了一个，是数据摆在那儿。

比如某个长尾物料，系统用了泊松分布法而不是标准安全库存公式。为什么？看它的零值占比到了多少，标准公式在什么情况下失效。看完大家就明白，不是系统算不出来，是它主动换了一个更适合的方法。

这个过程里最重要的一件事是：让大家看到系统在哪里出错，以及出错之后怎么办。

系统一定会出错。某个物料有突发促销，模型没学到，预测偏低。这种时候我不藏，直接把错误摆出来，一起看是哪一步出的问题——是促销信息没提前输入，还是模型池里没有能接住这种波动的模型，还是验证集窗口选得不合适。

但有时候问题不在模型，在数据。某个物料预测总是偏，查下去可能是主数据里的上市日期填错了，或者历史取数漏了一段。这些事在设计阶段看不出来，到了具体物料上才暴露。所以试运营还要做一件事：把数据问题和模型问题分开。数据问题回去补数据，模型问题才动参数。

计划员在这种场景下会慢慢建立起一种判断力：系统给的数不是圣旨，是有前提的。前提成立的时候，这个数可以信；前提不成立的时候，这个数要改。

这就是案例教学的意义。不是要大家一起学统计学，是教他们在具体场景下知道该信什么、该改什么。

2.3 第三步：上线，同时立起 S&OP（解组织坎）

目标：系统直接生成预测单和采购申请单，计划员只处理异常和例外。

这一步的前提是前两步已经建立了足够的信任。计划员愿意让系统自动下单，是因为他们已经验证了系统建议的可靠性。

但光有信任还不够。系统装好了，计划员信了，前面说的那道组织坎还没解决——销售答应提供促销计划，采购答应维护交期，真到忙的时候可能就忘了。这不是靠一次培训能解决的，也不是靠系统报警就能倒逼的，报警多了人会麻木。

得有一个固定的会。

这就是 S&OP。销售、计划、采购、财务，每个月坐下来一次，把需求和供应对齐。销售说未来几个月卖多少、有什么促销；计划说产能和库存能接多少；采购说交期和成本什么情况；财务说资金能撑多少。说完了形成一个统一的计划，往下执行。

有了天枢，这个会才有事实基础。以前开会靠拍脑袋，销售凭感觉报个数，计划凭经验砍一刀，最后各说各话。现在天枢每周跑一次，出来的是预测和补货建议，会上吵的是“这个数对不对、要不要调参数”，不是“我觉得应该多少”。吵的东西不一样了。

反过来，光有天枢，数也是死的。系统装好了，没人用，预测和实际执行的偏差没人看，参数该调的不调，跑几周就没人信了。

S&OP 的第一次会，得在系统上线之前就开起来。

三个阶段不是严格线性的。有些物料可能很快进入第三步，有些物料可能长期停在第二步。这很正常，接受不同物料的成熟度差异。

3. 培训的终点：知道参数怎么调

培训做完，有一个很实的检验标准：参与的人，知不知道参数应该怎么调。

天枢的参数都在 SystemConfig 表里，没有一个硬编码。IQR 系数、Z-Score 阈值、MAPE 阈值、服务水平、默认提前期、默认补货周期，全是可配的。

这些参数不能只有我一个人会调。如果只有我会调，那这套系统又变成了另一种黑箱——只不过黑箱不在模型里，在我脑子里。

所以培训到最后，我要让每个角色知道自己关心的那几个参数是什么意思。

计划员要懂服务水平对应的 Z 值。95% 对应 1.64，99% 对应 2.33。服务水平定得越高，安全库存越大，资金占用越多。这是一个取舍，不是越高越好。这个取舍谁来做？不是我做，是管理层和计划员一起定。

采购要懂提前期 L 和补货周期 R 怎么影响订货点。供应商交期从 30 天变成 45 天，安全库存要涨多少，订货点要提前多少。这些数字给到采购，他才知道跟供应商谈交期的时候，交期缩短一天到底值多少钱。

计划员还要懂 CV 降级阈值和零值占比分界。一个物料 CV 超过 3.0，系统会自动把它从 A 降到 B。这个降级合不合理，计划员得能判断。系统只是执行规则，规则合不合适，是人的事。

培训的目标，不是让大家会写存储过程。是让大家知道，系统是在什么假设下给出这个数的，以及当假设变了的时候，该动哪个参数。

4. 组织协同：谁该做什么

一个预测系统要跑起来，从来不是一个部门的事。它需要多个角色协同，也是一次组织能力的提升。

角色职责关键交付物
计划员审核异常值、确认预测结果、维护补货参数清洗后的数据、确认的预测值、补货参数
销售提供促销计划、新品计划、市场变化信息未来促销日历、新品上市计划
采购维护供应商交期、MOQ、价格、分批交货协议供应商主数据、采购协议
IT维护数据库、API 对接、系统稳定性、用户权限可用的系统环境、数据接口
管理层确定服务水平目标、推动跨部门协同、审批资源投入服务水平目标、资源支持

关键原则：不要让计划员既做数据清洗，又做预测审核，又做库存决策。分工要清晰，每个角色只做自己最擅长的事。

5. 我们会遇到什么挑战

培训手册写完，不等于大家就懂了。试运营跑起来，不等于计划员就信了。上线之后，还有几件事是现在就能预见的。

第一，培训完了，行为不一定变。计划员可能在培训时点头，回到工位还是按老习惯拍数字。案例教学就是为了堵这个——不是讲一遍就完，是每周一起看具体物料，看系统为什么这么选，直到她自己能判断。

第二，参数放开之后，可能被乱调。服务水平从 95% 调到 99%，安全库存涨一截，资金占用跟着涨。这个权限给出去，得有人盯着调完之后的影响。不是不信任，是任何参数改动都要有记录、有复盘。

第三，S&OP 开着开着，可能变成走过场。会开了，人到了，还是各说各话，或者会上不吵会下吵。这种事太多了。能不能开成一个真对齐的会，靠的是有没有一个共同的、能追溯的事实基础——这正是天枢要做的事。

这些挑战都不是技术问题。技术问题相对好解决，存储过程跑不通，改代码就行。人的习惯、部门的惰性，改起来慢得多。

天枢能做的，是把数摆到桌面上。剩下的，得靠大家信这套新玩法，并且坚持一直做下去。

系列回顾

篇次标题核心内容
第一篇我做了一套预测系统，但它还没上线——聊聊数据工作的第一性原理系统设计哲学与核心原则
第二篇数据清洗不是技术活——一个供应链预测系统的数据治理实践数据清洗、异常检测、需求异常与供应异常
第三篇9 种模型同台竞技——一个供应链预测系统的模型设计哲学物料分层、九种模型、双标准择优
第四篇从预测到补货——一个库存计划引擎的设计逻辑安全库存、订货点、建议订货量、外购件与自制件
第五篇从设计到落地——一个预测系统的组织协同与工程实践培训、试运营、组织协同、S&OP、挑战
天枢系统，是一个基于 SQL Server 的销售预测与库存计划引擎。它从金蝶 ERP 取数，经过数据清洗、物料分层、九模型竞赛择优，输出未来 7 天的销量预测和库存建议。项目尚未上线，正在持续迭代中。