提到，需要对WHWW模型做一次修正，以优化客流源不稳定带来的库存倒挂局面。至此，思路是很清晰的：让安全库存随着客流源（即需求）而波动，问题就能迎刃而解。所以，本篇并不打算花过多的笔墨去介绍为什么要引入动态库存（DynamicSafetyStock，DSS），而是着眼于如何实现动态库存。
此处必须引入一个新的概念：销售预测（SalesForecast）。通过预测，我们建立需求波动模型，还是以这家餐厅为例，我们假设存在午高峰和平峰期，经统计高峰期每2分钟销售一屉，平峰期10分钟/屉，相差5倍：
再结合上次的安全库存图（为了区别，此处称为静态安全库存，StaticSaftyStock，SSS）
两相比较后，就能看出问题的根源在哪：原本设置的6~20屉的安全库存，在平峰期可以满足60~分钟的销售，而在高峰期仅能应对12~40分钟。
至此我们就可以反问自己一个问题：我们最初设立安全库存的目的是什么呢？库存本身并没有价值，只会带来成本，客户需求的满足才是价值。所以从这个角度讲，我们用MTS的根本原因之一还是为了在一定的可接受的成本范围内，实现价值的最大化。不忘初心，我们不必太拘泥于安全库存的“刚性”，大可动态的调整，而调整的依据，就是能覆盖多少时间段的需求！
所以，我们大可按照满足多少分钟的客户需求，作为安全库存的设置条件，而不是机械地固守某一组设定值。对于本餐厅的小笼包这个SKU，我们假设安全库存是不低于30分钟的销售量，但最多不超过60分钟的销售量，如此一来把安全库存值从固定数量变成了覆盖时间，安全库存就有趣的多了：在11点的时候，我预期未来每2分钟卖掉一屉，所以安全库存上下限应该在15~30屉之间，但是到了下午2点以后，10分钟才卖掉一屉，所以这段时间，其实只要维持3~6屉，就足以应付客人需求，修正后的系统如下图：
从图2到图3，我们成功地将安全库存的上下限值的设置，和需求波动绑定起来，需求的增减，自动调整我们的安全库存的增减，漂亮地解决了原本依赖于WHWW系统计算下，高峰期没包子卖而平峰期包子过多的尴尬场面，修正后的系统，由于引入了Forecast这一变量，为了以示区别，更名为FWHWW系统。这一回合，FWHWW系统从店长手里抢回了老系统丢掉的运营指挥权！
截至目前为止，干得漂亮！那么，还有问题吗？下集预告：《快餐店里的MTS之四--Whattomake深究》让我们回过头去，看看到底哪些要做库存，是否如之前首篇文章里一笔带过的那么简单。
后记1，让我们记住一些术语：
SSS，StaticSafetyStock
DSS，DynamicSafetyStock
库存覆盖时间：当前库存可以覆盖未来需求的时长
后记2：
有朋友提示，MTS是Levelling，是均衡。诚然，两者有一定的交叉，关于这个话题，本就在我的写作列表中，以后会和大家一起讨论。感谢朋友们的讨论，期望更多交流
联系电话：