跳至正文

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

标签:

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高级应用之制造业“需求预测”》有1个想法

  1. Pingback: 【项目实践】传统制造企业如何应对数字化转型 - 喜乐君

评论已关闭。