让我们穿越时空，回到赤壁之战。草船借箭发生的前夜，孔明正在中军账里拿着笔疯狂的计算......

东吴周瑜提出，“限十天，造十万支箭。”--这是一条时间和数量都非常明确的要货订单，同时也是一个几乎不可能完成的任务。

时间紧，任务重，孔明先生如何在这么短的交期内，给出这么多的成品货？况且物料（竹子、翎毛、胶漆）还被捏在周瑜这个恶意供应商手里。

智冠天下的孔明军师通过分析局势，想出了草船借箭，增加供应商的妙计，我们今天以供应链的视角来看，各势力关系如下图：

 不难发现几个问题：

• 曹操会射多少箭？转化到船上草人身上的又有多少箭？万一达不到10万只怎么办？

• 每艘船能承受的最合理数量大概是多少，箭射太多船沉了怎么办？

• 在什么时间“收货”最为合理，能保障收货量最优？

• 其他的天气、时间点、兵力等问题

所谓运筹帷幄，需要的是海量数据和算无遗策的计算与计划准备。

我们以上帝视角来看东吴战场上的军备准备：

第一步：供应商选择

A.周瑜操控的东吴军械制造厂。这个供应商肯定会拖延物料，不会让孔明按时按量生产，但是顾及脸面，肯定也不会不让生产，可以生产些箭矢作为安全库存储备，防止交货风险。

B.曹操军队的现有库存。曹操作为非默认供应商，此时正好可以拿来应对供应风险，曹操本人生性多疑，会射出不少货。

第二步：运作计划制订

1.销售目标VS销售计划

A.销售目标：“市场部”周瑜反馈，“军情紧急，十天后业务需求箭矢数量十万只，一天一万。”

B.销售计划：“供应链”孔明评估，“根据曹操的开战习惯，三天后就需要备齐十万只，一天两万。”

2.供应计划

此处因为要货数量确定（订单拉动）不涉及采购计算

A.曹操“供应商”产能预估。根据曹军兵力分布，射箭准确率，射箭波次，可以预估曹军“交货数量”。

交货数量=曹军兵力*射箭波次*射箭准确率*天气影响系数

B.周瑜“供应商”产能预估。取max（10w-曹军计划交货数量，0）作为安全库存。防止曹操秒射一波就停止造成的“交货”风险。

3.到货计划

孔明承诺：“三日后江边取箭”，即3天后货物到达东吴港口，周瑜此时的下属鲁肃作为仓储管理人员负责保障入库，需要提前调集人手。

4.库存计划

鲁肃收货后，十万只箭放在哪些仓库，更方便吴军最大效率取用，同时也保障不会存在放不下，或放太少不够用这种问题。

第三步：运作计划执行

1.曹军计划射箭数量VS曹军实际射箭数量

A.计划：数肯定是数不过来的，猜想军师借用草船称象的原理，提前根据船吃水线标记控制每艘船的“交货数量”，到了一侧最大承重后的应掉头时间（需要考虑雾散了怎么办，要严格控制时间）就掉头；

B.实际：根据实际“交货数量”，留出一定的buffer时间做实际操作调整，只要能在雾散之前收到预期的箭矢数量，计划就跑通了。

2.曹军产能VS吴军产能

计算所有船只的实际交货数量，取max（10w-曹军实际交货数量，0）作为东吴供应商要货数量，集中调配到江岸。

3.到货计划

这就是鲁肃的问题了：

A.选择相信孔明（会有人手调度、仓库库位成本）。提前根据各个营地历史箭矢需求，计算未来箭矢需求量，考虑营地仓库容量约束，调齐人手高效执行，快速入仓。

B.不相信孔明（不相信计划，按照自己预期准备）。结果真的十万只箭矢来了，手忙脚乱再去放，一是收货慢跟不上打仗消耗，二来后续也会造成仓库之间调拨的问题。

4.库存计划

这还是鲁肃的问题，不过很大程度上是周瑜造成的，周瑜原本是想搞孔明，虚报需求量。结果现状是，仓库里本来就很多箭矢。

A.鲁肃选择相信孔明：起码入库环节是没有问题的，但是因为后续消耗太慢，库存居高不下导致一部分箭头生锈无法使用；

B.鲁肃开始就没选择相信孔明：从入库环节开始就是乱的，入库、收货、各仓库的库存放置，后续的调拨整个就乱套了。

故事到这里结束，不难看出，上述计划指导运作的整个链路中，有以下关键节点：现状分析->计划制定->计划推演->计划实施

草船借箭这种一次性事件，或许到这里就够了；如果最后吴军不喊那声“谢曹丞相赐箭”，也可以再对计划进行分析，趁着下次大雾更准确的偷鸡摸狗。

但是对于电商供应链这种特殊场景，上万个商品的销售、供应、库存和到货计划都要精确管理，仅靠人力就跟不过来了。

基于以上背景，供应链计划系统应运而生，期望能够通过提供数据分析、数据计算、数据建议及模拟仿真的可视化产品工具，为供应链销售&运作计划（S&OP）提供一套成本效率全局最优的解决方案。此处立足于“严选模式”下的供应链管理业务需求，分享几点数据产品如何驱动供应链业务的设计思考。

1.数据产品的首要能力

数据产品首先要提供的就是用户关注数据的查看能力，并提供全面多维的监控分析能力。在严选的供应链计划场景中（如下图），通过提供可视化的数据，可支持用户快速洞悉数据情况，包括历史对比、未来趋势的分析，同时也能够对业务关心的核心风险做清晰明白的指标计算，帮助用户快速了解风险，制定行动方针。

2.数据产品的智能化过渡

数据分析的目的是为了得出行动结论，能够在计划的决策链路根据约定规则计算默认建议，可以辅助用户快速制定决策,同时基于建议告知用户执行的影响结果，也可由用户再进行调整确认。如下图，对于解决电商多sku的商品的采购下单场景，数据产品可以基于约定算法，给出建议默认值，业务可基于默认值二次修改也可直接选择相信结果进行系统间联动执行，对采购下单环节做到了明显的效率和效能提升。

3.数据产品的自动化推动

分析数据，看到决策建议，其实还面临另一个问题。如果是孔明现在告诉刘备，什么时间该做什么事，刘备大概率会做的。但是如果显示屏告诉刘备，你应该xxxx，他八成是不相信的。在严选的补货模块中也存在类似的问题，用户看到的一开始是冷冰冰的数据，天然会相信人脑经验而排斥数据。

如何去解决这个问题？从结果倒推过程，我得出了这样的一种设计思路。

想要获取用户信息，首先要让用户了解并参与过程。我们把计算逻辑中的核心特征参数开放给用户，用户可以对参数进行调整，来控制未来对业务的不同预期影响。让用户从看到建议、了解建议，再到调整建议、相信建议，最终参数比较稳定的商品就可以朝着自动化的方向走，且这一自动化过程是有人工修正的良性循环；固定的逻辑和参数控制也方便业务管理层对执行进行宏观管理。如下图，用户可调整参数并看到未来的库存水位（低频补货，高库存水位->高频补货，低库存水位）仿真结果。

4.数据产品的闭环优化

计划总是赶不上变化，即便所有的事务都已经安排好，总还是会有预期之外的情况。供应链业务的情况尤为显著，用户端未来需求会剧烈波动，供应商生产也会延期，随着物流在供应链上的流通各种计划外风险也被逐级放大，这时候就需要按计划行事，同时机动调整。

（销售计划完成情况（测试数据））

“计划不够，执行来凑”，需要能够在计划的基础上给出可预见的、动态更新的风险预警。特别对于供应链这种提前期相当久的业务运作，需要能够根据当前的现状，不断根据近期历史更可信的数据进行调整，来对未来的预警进行更新；帮助业务不断发现问题、处理问题并解决问题。

免责声明：本文来源网易有数，仅供读者交流学习，版权归原作者所有，且仅代表作者个人观点，侵删。