【供应链分析】从敏捷仪表板到业务流程优化

Dec 23, 2023 写于SHA>HKG航班

前几天有人引用董宇辉的话说“能力决定下限，机会决定上限”，对于分析而言，业务思维限制了分析师能力“下限”，优秀工具则决定了表现的“上限”。

很多人认为业务需求难理解、敏捷分析入门难，喜乐君特此介绍案例一则，分享敏捷BI如何即时解决业务问题，数据思维如何增进业务理解和洞察力。

一、敏捷分析的应用案例

今天在机场候机时，我的制造客户领导问“能不能做个发货明细表，销售把发货单给物流，物流部门有时候来找生产，生产却不知道要发货”（大意如此）。

我之前整理并发布订单和发货关系模型时，预先在发货明细行之后关联了拣货单（PickingList），现在，需求来了。好的数据模型（data model）不仅满足当下需求，而且应该预留其他人、其他场景使用的关键业务字段；正如我在《数据可视化分析（第2版）》中所说，“数据模型是在最为详细且有业务意义的级别的预先匹配”，它是先于业务需求和分析场景的。

我打开电脑，在机场登机口的吧台桌上，登录客户tableau server，在浏览器中找到这个数据模型（CustermerOrder-DeliveryRow-Model），创建工作簿、新建两个工作表：

• 不同交货状态的拣货单数、发货数
• 各个交货单明细信息（计划交货日期、交货状态、对应订单号、物料名称、客户信息、发货数量）

考虑到大家的关注焦点是“未发货的拣货单”，特别是延迟未发，因此在仪表板（如下图，脱敏处理）中，“拣货单行状态”字段作为筛选器，默认只保留“2计划发货”，用户可以按需选择“3已交货”和“6已到货”等其他类型。同时，计划发货日期（RowDeliveryDate）放在第一列，把延迟最久的拣货单置于最前面。

不出一刻钟时间，我就把草稿发给了客户确认。客户很高兴，她知道我会很快，但没想到是今天此刻。客户给我截图并标记了几个单据号，说“这几个采购原料才到，今天做出来才能发货”。

喔，既然如此，我应该让大家看到发货物料对应的当前实时库存，并标记出来哪些是因为库存不足而引发的延迟——督促生产跟进（虽然我不认为生产应该看发货单，后面详说）。

于是，我接入了另一个事先发布的数据源“物料的实时库存明细表”（PartBalanceList），以数据混合的方式加入“库存量”聚合字段，之后创建即席计算“sum（发货量）<sum(库存量)”并加入颜色，从而标记库存充足、库存不足和没有库存的情形（这里先不考虑同一物料多次发货的特殊情况），略做格式调整。

一个基于多主题数据的即时仪表板就亮相了。不管是销售，还是物流，抑或生产，都可以看到接下来要发货哪些拣货单（时间在今天之前的为延迟，优先发货），颜色区分了库存可用性（大部分延迟是缺货导致的），生产则可以据此紧急单优先安排。

客户很高兴，我也乐见其成——能在半小时之内帮助客户实现从无到有的分析展现，这可是证明tableau敏捷分析能力的绝佳机会。

大部分分析师一方面受限于业务熟悉度（特别是跨主题的业务关联），这可以借助于数据准备来改善，另一方面受限于工具本身（只有烂熟于胸，方可举一反三，遇到业务问题如庖丁解牛、游刃有余），这就要平时多练、多看书了。

二、拣货单的“责任归属”及其对数据的影响

拿破仑说，“不想当将军的士兵不是好士兵”，咨同理，询顾问不能仅仅以“交付仪表板”为己任，而应该随时多问为什么，找到困扰客户的真正根源，然后提出改进建议。

ONE MORE THING…

为什么会有这样的分析需求？ 难道不应该是物流部门对发货了无指掌吗？生产部门怎么还要去看拣货单，不应该按照“订单驱动”或“库存驱动”确保足额生产就好吗？物流为什么早不说没货，等到发货才“人间清醒”？

这又说到企业的具体情况，根源在于拣货单是销售部门做的，物流部门只是见单发货。在这个分工之下，万一纸质拣货单子丢了，物流就说没有收到通知；而既然物流部不生成拣货单，也就对特定物料的库存有无缺乏感知，犹如“守株待兔”之人，只需见单发货、没货骂娘即可。

本来，按时、足额发货本应是物流的责任，这样，“准时发货”的大部分压力就转到了销售部门和生产部门那里，。

你看，一个职责的归属可以对业务产生非常明显的影响——积极的，或消极的。

如下图所示，喜乐君曾经绘制过从销售、发货到开票的销售流程图，其中的背景可以理解为订单、货物、资金，不同部门各司其职。很明显，销售部门制作拣货单、签字单据送到物流部后见单发货，如此的业务流程很明显并非最佳实践（best practice），为什么会这样呢？

因为客户新上线ERP系统，系统应用尚不熟练，订单还常常存在准确性和及时性的问题，加上之前SAP时就有销售部门做拣货单的历史背景（甚至还需要指定批次），于是，为了降低错误发货的风险，在领导的协调下，销售部门重新担负起了拣货的责任，相当于借此二次确认短期订单的准确性。这种短期妥协的策略，慢慢暴露了上述分析的天然弊端。

在很多企业，销售部门都不得不独揽大权，因为他们直接对客户负责，又拿到业绩提成中最大的一部分，习惯性地承担最后的责任。但“部门最优”的策略和初衷，往往导致“全局次优”的结果。

上面就是短期行为，就应等到各部门对ERP软件日渐熟练、销售人员跟单准确性提高，就应该切换到标准流程了。

三、如何理解物流和数据流的关系materials and data flow

至此，我们就理解了这个“发货仪表板”的业务背景，也了解了销售负责拣货单的负面效应，那如何从数据角度，理解不同部门的责任归属呢？

一个基本逻辑是：销售对订单负责（围绕客户、不见实物）、仓储物流对交付负责（围绕实物和交付，莫等他人调遣），生产对产出成品负责（围绕生产流和产出，不问订单之前、成品之后），各司其职，方可整体最优。

换句话说，销售部门只负责客户沟通及订单准确性，它们是“云端办公一族”，借言语辞令、扬我司威名，于纵横捭阖之间，争取到客户的需求，最后表示为ERP的一条条订单（represent as customer order）。他们活在人际关系中，活在数据世界。

物流部门则在仓库和实物打交道，他们看到云端传来的Order，顷刻间人间清醒、拉铃催促，小叉车跑起来、小托盘翘起来、库区库位找起来、一二三数起来……看得见、摸得着的物料交付（physical material delivery），应该是物流仓储部门的职责，莫等他人来催，更无需一排领导签字的三联单做发货“暗号”，见订单、按日期准时发货即可。——只有连订单信息都做不准的落后企业，才需要用联名签字、三联复写的方式来确认责任。

仓库没有货了怎么办？仓库管理员把隔壁一群人摇醒，半成品快快送过去，于是生产设备叮叮当、生产班组嘿呦呦，如同魔法把一堆半成品、必要劳动凝结为生产成品。成品生产、质检合格后，送给楼下仓储部门，从此井水不犯河水，更不应该看发货拣货单…也就是说，生产部门只应该负责半成品到成品的加工过程，为什么做销售负责，送哪里去物流负责。

如果各司其职，企业自然效率倍增，难在每个部门时常有权力扩张的欲望，又要逃避责任的本性，如同政府一般。这就产生了诸多矛盾，成为绩效的陷阱。

企业中，绩效陷阱大多集中在部门之间的“中间地带”（White Space on the Organization Chart），这催生了流程优化、流程改造理论和实践。其中，我最喜欢的就是Rummler拉姆勒、Brache布拉奇合著，王翔老师翻译的《流程圣经：让流程自动管理绩效》，中文译名抽象过多，英文名称更切中主旨， Improving Performance：How to manage the white space on the organization chart。我的大多数业务流程知识，都来自于这本书和王翔老师的培训指导。

如何填补部门之间的绩效陷阱？

一种策略是强势一方侵入其他部门的领地，上述销售做拣货单就是此种逻辑，这样会导致责任错位，激发更多潜在冲突，部门之间的沟壑只是右移一点而已，有时候新矛盾甚至比旧矛盾更多（不过，往往短期内产生老矛盾解决的假象）。

另一种策略是借住ERP等软件加速数据流转，充分发挥“数据流快于物流”，更快于单据的优势。在各司其职的前提下，“数据共享中心”和敏捷分析可以相当程度上填补部门之间的沟壑，让更多人知道我就要做什么，现实如何，如何改进。

我在客户项目中最倾向于完成的工作是结构化分析和跨主题的数据整合分析。前者代表业务分析的深度，后者代表业务分析的宽度。比如销售、生产和库存的“成品需求平衡”，“库存、生产和采购的采购半成品需求平衡”，借助于tableau敏捷的关系模型与数据混合功能，业务分析师既可以满足高频分析需求，又能完成临时分析需求。

在数据的世界中，我们才能体会另一种自由。

2023/12/23 航班
2023/12/25 Hongkong Revise