【项目实践】Tableau高级应用之制造业“需求预测”-喜乐君-敏捷BI布道师

by 喜乐君（基于真实案例总结）

因为项目的原因，最近在工作之余阅读制造业相关的图书，偶然发现刘宝红老师的《供应链的三道防线：需求预测、库存计划、供应链执行》（京东链接），读完前言和第一章，我就惊叹：这可不就是客户当前遇到的问题嘛，在客户的需求指导下，我则用Tableau为之打造了一个“需求预测”的模版。

鉴于客户数据的敏感性，喜乐君仅就“需求预测”分析背后的需求、问题和难点做必要的阐述，帮助更多人制造业同行了解Tableau在该行业的高级应用场景。

一、尝试用数据的问题，解决“计划难”的问题

和快消零售行业不同，制造业的难点在于生产周期普遍较长，导致订单预测和生产环节的高度不确定性，因此高度依赖于计划和供应链协调。在刘宝红老师的书中，“计划是供应链的引擎”，供应链管理就是计划加三大执行职能（采购、加工、交付）。这个计划，这是很多制造业企业的普遍难点。

今年一季度，客户向我描述了他的困境和需求：

销售部门提供的订单数据不准确，导致生产部门排产波动大，库存长期挤压；有时候该发货了没有库存，有时候该生产了没有原料，很多订单都在频繁加急，库存居高不下。

能否通过Tableau做一个仪表板系列，既能帮助生产部门及时了解短期、中期的订单情况，又能让物流部门看到生产的排产计划以协调发货安排。最终，每个岗位的负责人都能清晰地知道何时应该“加油门”，何时应该“踩刹车”。

在客户的需求中，“订单预测不准”是首当其冲的问题，导致生产计划、发货计划都异常脆弱，不得不用大量人工对抗整个系统和流程的脆弱性。如果用刘宝红老师的话说，第一道堤坝（需求预测）就失控，导致了后面两道堤坝（库存计划、供应链执行）没有效率可言。

在我的初步构思中，我应该为客户构建一个“数据共享中心”角色的仪表板，它不仅包含每个部门需要的所有事实，而且包含未来预测数据的业务关系，可以给出初步的判断，比如未来一周A产品生产不足，不能满足发货需求；X客户的发货已经延迟，生产预计三天后方能下线。

在了解客户的销售、生产、物流业务之后，我很快就了解了业务对象、业务过程的基本逻辑，但业务规则往往要耗费更多的时间方能把握，从而把订单状态、延迟发货、退货补发、生产延迟等复杂的业务规则置于一个不断优化的模型系统之中。

只是，在预测不准的背后，隐藏着更多的问题亟待解决。

二、用数据的视角，拉通所有部门的数据要素

“计划是三分技术、七分管理”，再强大的工具如Tableau，也无法解决客户管理中存在的问题，这通常是我在分析项目中遇到的最大困难，这就要求我时常要以“咨询顾问”的身份为客户提供一些数据视角的建议。

1、数据的准确性、完整性、及时性，是需求预测的最大敌人

客户已经在多年之前上线了SAP B1的小型ERP系统，我本以为客户的销售订单、生产管理、库存计划都实现了全面信息化。了解之后才发现，系统中的数据既不完整、也不准确，这让订单阶段的数据偏差在后续环节被多次放大，直至仓库爆仓、生产计划性减弱。

为什么会有这样的问题？个人之见，大部分都是管理水平。比如预测阶段的订单数据变化频繁，而跟单员/销售员都强调系统限制了自己的工作效率，最后集体“倒戈”退回到了Excel的“温柔乡”，然后借用钉钉传递从而明确责任——只要最新订单计划文档在最后要求时限之前发出，责任就从销售人员转移到了生产计划人员。

假以时日，企业内部逐渐出现了两套系统：ERP为中心的生产记录系统、Excel为中心的数据传输系统。前者只用于记录（名义上实现了信息化），后者则用来确认、追责。殊不知，这种经验主义形成的“部门最优”最终成为“集体最优”的公敌，但只要强势部门不倒，落后方式就一直存在。

有时候，公司所有人都意识到了这个流程有问题，但也没有更好地方法替代，只能反复打补丁、不断强化昨日的错误方式。

2、不要相信人，而要相信持续优化的系统

在需求预测这个问题中，我给客户反复强调的是，一定要相信持续优化的系统，它可能起初不太完美（就像我做的第一版本的仪表板），但是随着数据日渐完整、准确，规则日渐清晰、完善，系统进化的速度远远超过人的进化速度。

这个系统是什么？本质上是一个“数据共享中心”，它吸收所有、奉献全部。关键在于，每个人都应该知道输入什么、获得什么。为此，我设计了一个称之为“AI猫”为中心的数据贡献中心和刘向关系图，并标记了每个部门应该向“AI猫”输入的数据。只有当所有人都确保数据录入正确，就可以从Ai猫这里获得想要的所有“智能”。比如最优发货计划、生产排产计划等等。

用这种方式，我旨在帮助客户中高至总经理，下至跟单员，都养成“用数据说话”的习惯。这就同步要求数据准确、更新及时。

实现实现上述的数据流，我和客户一起重构了“销售订单管理流程”，一方面把预测视同订单管理，短期发货需求（PO）和长期预测需求（PR）同出一处，避免二次开发和两个工作模块带来的工作负担；另一方面借助通过定期的订单拆分，动态地提高数据准确性——越靠近当下，数据准确性要求越高。

看上去，销售部门的工作量似乎增加了，还人为切断了使用excel熟练工具的“舒适之路”。但反过来看，销售只需要加强客户沟通，确保数据准确性和及时性就可以了，很多本不该属于销售部门工作的任务也大量被转移给了“AI猫”或者其他部门。比如：

过去销售要为生产部门发送的未来两周的发货计划（如今“AI猫”自动完成这个工作）
过去销售部门要制作发货单，并选择物料批次（如今“发货单”由“AI猫”完成，而批次管理则归物流部门）
延迟订单需要修改发货日期到今天（延迟不再修改订单，物流把延迟视为优先发货）

可见，我们需要重塑的不仅仅是数据的系统，还有业务的系统。归根到底，数据只是业务系统的反映（record），数据并没有创造新东西。

三、Tableau在制造业中的高级应用（DW+BI）

基于上述的完整业务流程优化和“数据共享中心”建立起来的数据认知，接下来的就是施展技术，把想法转化为仪表板，把假设转换为交互了。

1、“DW/BI”数仓和分析一体化——数据层的建设是中心

“AI猫“画起来容易，难点在于如何收集准确、完整、规范的数据。这就涉及到了数据库、数据表、数据查询的规范问题（之前“数据分析通识”有所介绍）。

数据表是业务的反映，是分析的基础，是承上启下的关键。根据数据表的特征，也可以分为物理表和逻辑表两大类，后者是数据仓库的关键场景。假设先不考虑每个表背后的复杂逻辑，就可以用如下的关系图来理解（草稿V0.2）。

在IT的支持下，业务用户可以从单表或者简单的多表关系展开分析。但是在真实的业务场景中，完整的业务事实表需要业务和IT一起重构，避免复杂多表模型影响分析层的稳定性；而且在这个过程中的业务规则，常常需要非常多的时间去验证。单单一个订单、发货、退货的场景，喜乐君就耗费了大量的时间梳理它们的逻辑关系。一个并非最终版本的数据关系图如下所示（最终版本不便分享）：

在整理此类关系图的过程中，最让人头疼的往往是那些号称“自研”“自开发”搭建出来的业务模块，它们看似是原来业务系统的“补丁”，其实更像是原有系统的“bug”。常常出现数据表不规范、外键引用不正确、业务逻辑不一致的情况，增加了系统的脆弱性。

正因为此，喜乐君特别提醒客户，在接下来即将上线的新ERP中，尽可能减少二次开发，特别是“开膛破肚”的外部数据写入和同步。我们要相信，系统本身是自洽的，是我们的认知短期内没有找到最佳的策略；在人和系统之间，要习惯于相信不断优化的系统。

2、探索性仪表板是最佳思路的落地

在准备好数据吧、数据模型之后，最后就是Tableau的实现了，这个过程是业务逻辑、技术、业务规则集中作用的区域，需要反复的改进和调整。借助于Tableau的多个优秀功能，跨业务主题的分析才变得更加容易。

数据混合：混合特别适合大跨度的业务主题整合，比如销售明细表、生产计划表、实时库存三个场景的临时整合。在Power BI或者SQL中，虽然类似Natural Join的“自然连接”也能达到类似的效果，但易用性完全不可比拟。这是宏大主题构建中不可多得的关键技术。需求预测中最后一步的计算，就是使用了多表混合方才完成。

参数、参数动作、集、跨表筛选等高级交互：仪表板的魅力在于交互，而不在于静止。跨主题的分析中，综合使用这些交互技术，可以满足不同角色、不同形式的数据交互需求，从而创造“一个底座、千万变化”的绝佳效果。
标准化的可视化样式：在我最终交付给客户的仪表板中，交叉表表、条形图、折线图占了70%以上的部分，辅以必要的直方图、散点图等中级图形。形式上尽可能简单，复杂逻辑尽可能在逻辑层计算实现。

基于上述的技术，仪表板中可以实现需求预测的大部分需求：

跟单员员/生产计划：查询特定日期或者日期区间，每个物料的计划发货数量、计划生产数量，考虑库存判断盈缺
物流人员：查看较短的区间中，每个物料的发货盈缺，并能计算当前库存能支持的发货周期

一个宏大的分析主题，是对业务逻辑、工具熟练程度、最佳技术路线的综合考验。相比IT用户，业务用户更容易成为这个行业中的专家。

Jul 9, 2023

了解喜乐君的更多信息

订阅后即可通过电子邮件收到最新文章。

【项目实践】Tableau高级应用之制造业“需求预测”