ABP基于维度计划1-传统物料编码SKU/PN的死亡？

1  PN SKU的组合爆炸灾难

    众所周知，PN、SKU、item No物料编码在供应链中是最核心管理的master data主数据。从60年前开始MRP就是基于PN，BOM而诞生的，然而，随着时代变迁，如今市场需求越来越纷繁复杂，PN、sku呈现指数级上升，料号的增加对库存管理、供应链计划、需求履约交付都产生重大负担。

       BT君曾经见过刚上线的系统，物料齐套计算要跑70个小时！针对单一缺料对订单的影响，又需要层层追溯，有超级BOM，有配置BOM，有替代料，有成组替代料，有不完全替代...........

     在库存管理上，大量pn sku导致需求与供应匹配异常艰难，大量需要的sku缺货，而大量呆滞的sku无法命中需求....最终陷入 高库存与低交付的灾难

      在计划层面除了forecast预测、capacity产能、一些粗维度计划可以按物料组来做，其他大部分都是细化到PN/SKU维度，计算量浩海，且计算逻辑在bom分解后会交叉指数级放大， 这种料号、bom，routing暴涨带来的复杂度，似乎只能靠不断上系统来解决，APS，AI，ML,再堆上更强悍的算力，内存计算，分布式计算，或者更迭新的算法图神经网络用异构计算.......在算力上不断追求对SKU层级的最细颗粒度计划

    回过头来看，起源于60年前的MRP，当时的计算机功率还不如今天一个手机，工厂可以决定市场上可以卖什么。

     而如今，不确定性与复杂性不断增长，黑天鹅频发，确定性的逻辑似乎很难应对当前时代的挑战？

2   ABP基于维度计划的物料管理新思路   

    今天BT君看到一家供应链计划公司十年前发表的理论，ABP（Attribute Based Planning）基于维度的计划，介绍了用大量维度值组合来代替sku、pn这类长编码的管理模式，

例如以电脑为例：

     如果按传统的PN、SKU来定义，通过不同段组合得到，假设10种颜色，3种尺寸 5种材质..........组合下来

颜色*尺寸*材质*电源*硬盘*内存*CPU*显卡*屏幕 =10*3*5*2*4*5*20*20*5

=1200万料号、BOM、routing

   按照ABP基于维度的办法管理，则需要管理的维度枚举值

颜色+尺寸+材质+电源+硬盘+内存+CPU+显卡+屏幕 =10+3+5+2+4+5+20+20+5

=75 个维度值

大幅降低了管理复杂度！

       看到这，当然也很容易想到 这维度值没啥特别啊，在传统SKU下也有，打开ERP物料界面看看，100多个物料属性呐........

        呵呵，关掉物料界面，到MPS，shceduling，各种Plan上找找，可以很惊讶发现，大部分属性都没有继承到计划层面，计划层面还是基于详细的sku、pn或者之上的物料组在进行。。。。

此外，ABP这种方法思路主要出发点是【供应链计划】，在降低复杂度下更重要的贡献是大大强化了供应链计划能力

3   ABP在供应链计划上的进步   

     从需求维度来看，客户购买商品关注的都是【维度】，买手机看配置、看屏幕、看颜色，只有订单管理上会出现物料编码CY2K3057688 ！

    对需求来说，有意义的是维度属性，而非编码

   因此可以做如下两件事

（1） 需求不落在SKU，而在维度上进行范围定义

并非物料编码CY2K3057688，

原始需求

-大屏：不定义详细【尺寸】，>=14寸（对应料号可能）

-颜色靓：不定义详细【颜色】，No 黑色、白色

-性能杠杠的：不定义主频和【CPU型号】，跑分>=10000

 指定新增维度值要额外加钱！例如：外壳缝隙<=0.5mm（超出现行标准）

通过维度属性创造新的客户价值，并重新定价影响需求

（2） 供应按Attribute维度值定义逻辑库存池

     按维度来定义每个料件以及半成品、成品，对于相似料件在维度属性上会体现出相似性

例如外壳1和外壳2颜色相同，材质相同，在相应属性上会体现

      此外，库存统计也基于维度可以获取，针对不同维度的库存进行统计得到各种逻辑库存

    有了如上的基于维度的需求，基于维度的供应，则供需匹配时可以针对【颜色】非黑色，白色进行引导，直接安排在供应最多的红色身上，再结合供应计划进行多维度组合给出配置建议，也就是Demand Shaping需求塑型过程。

（3） 供应链计划进行供需匹配

     由于需求从明确的SKU变成了各个Attribute的范围，更清晰地定义的客户的诉求，因此在诉求之下有大量可以shaping的机会，在对需求进行承诺时候可以基于维度搜索所有供应逻辑库存资源（包括在途，在制，在库等）

    看到这个应该还有很多疑问，这种做法真的现实中可以落地么？没有了SKU所有相关的资源模型、计划模型全部都得重构！（BOM、Routing、MPS、S&OP、Scheduling....）

    BT君现在从事云基础设施行业，恰好是多年来完全按照无SKu拼attribute的方式在进行，虽然一直想拉回到SKU和BOM正轨上（没错，连BOM都没有）然而终究被SKu爆炸这事给吓退了，而且行业迭代速度非常快，新的维度出现是以季度为单位在进行（如果是sku模式可能就是每个季度要多几十万了......）正是在这种模式中，享受了计划上的便利，也感受到痛苦（SKU模式下所没有的交叉验证规则痛苦），偶然发现了ABP这种方法走的是同一个路子，不经颇为兴奋，似乎是条正路

   由于笔者是从实践中来，回头去找理论支持，所以对ABP理论上也是刚接触，有兴趣的朋友欢迎一起探讨。

  下一篇准备，介绍下实践中是怎么应用十几个字段拼接来做供应链计划以及库存这回事