1  PN SKU的組合爆炸災難

    眾所周知，PN、SKU、item No物料編碼在供應鏈中是最核心管理的master data主數(shù)據(jù)。從60年前開始MRP就是基于PN，BOM而誕生的，然而，隨著時代變遷，如今市場需求越來越紛繁復雜，PN、sku呈現(xiàn)指數(shù)級上升，料號的增加對庫存管理、供應鏈計劃、需求履約交付都產生重大負擔。

       BT君曾經見過剛上線的系統(tǒng)，物料齊套計算要跑70個小時！針對單一缺料對訂單的影響，又需要層層追溯，有超級BOM，有配置BOM，有替代料，有成組替代料，有不完全替代...........

     在庫存管理上，大量pn sku導致需求與供應匹配異常艱難，大量需要的sku缺貨，而大量呆滯的sku無法命中需求....最終陷入 高庫存與低交付的災難

      在計劃層面除了forecast預測、capacity產能、一些粗維度計劃可以按物料組來做，其他大部分都是細化到PN/SKU維度，計算量浩海，且計算邏輯在bom分解后會交叉指數(shù)級放大， 這種料號、bom，routing暴漲帶來的復雜度，似乎只能靠不斷上系統(tǒng)來解決，APS，AI，ML,再堆上更強悍的算力，內存計算，分布式計算，或者更迭新的算法圖神經網絡用異構計算.......在算力上不斷追求對SKU層級的最細顆粒度計劃

    回過頭來看，起源于60年前的MRP，當時的計算機功率還不如今天一個手機，工廠可以決定市場上可以賣什么。

     而如今，不確定性與復雜性不斷增長，黑天鵝頻發(fā)，確定性的邏輯似乎很難應對當前時代的挑戰(zhàn)？

2   ABP基于維度計劃的物料管理新思路   

    今天BT君看到一家供應鏈計劃公司十年前發(fā)表的理論，ABP（Attribute Based Planning）基于維度的計劃，介紹了用大量維度值組合來代替sku、pn這類長編碼的管理模式，

例如以電腦為例：

     如果按傳統(tǒng)的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 個維度值

大幅降低了管理復雜度！

       看到這，當然也很容易想到 這維度值沒啥特別啊，在傳統(tǒng)SKU下也有，打開ERP物料界面看看，100多個物料屬性吶........

        呵呵，關掉物料界面，到MPS，shceduling，各種Plan上找找，可以很驚訝發(fā)現(xiàn)，大部分屬性都沒有繼承到計劃層面，計劃層面還是基于詳細的sku、pn或者之上的物料組在進行。。。。

此外，ABP這種方法思路主要出發(fā)點是【供應鏈計劃】，在降低復雜度下更重要的貢獻是大大強化了供應鏈計劃能力

3   ABP在供應鏈計劃上的進步   

     從需求維度來看，客戶購買商品關注的都是【維度】，買手機看配置、看屏幕、看顏色，只有訂單管理上會出現(xiàn)物料編碼CY2K3057688 ！

    對需求來說，有意義的是維度屬性，而非編碼

   因此可以做如下兩件事

（1） 需求不落在SKU，而在維度上進行范圍定義

并非物料編碼CY2K3057688，

原始需求

-大屏：不定義詳細【尺寸】，>=14寸（對應料號可能）

-顏色靚：不定義詳細【顏色】，No 黑色、白色

-性能杠杠的：不定義主頻和【CPU型號】，跑分>=10000

 指定新增維度值要額外加錢！例如：外殼縫隙<=0.5mm（超出現(xiàn)行標準）

通過維度屬性創(chuàng)造新的客戶價值，并重新定價影響需求

（2） 供應按Attribute維度值定義邏輯庫存池

     按維度來定義每個料件以及半成品、成品，對于相似料件在維度屬性上會體現(xiàn)出相似性

例如外殼1和外殼2顏色相同，材質相同，在相應屬性上會體現(xiàn)

      此外，庫存統(tǒng)計也基于維度可以獲取，針對不同維度的庫存進行統(tǒng)計得到各種邏輯庫存

    有了如上的基于維度的需求，基于維度的供應，則供需匹配時可以針對【顏色】非黑色，白色進行引導，直接安排在供應最多的紅色身上，再結合供應計劃進行多維度組合給出配置建議，也就是Demand Shaping需求塑型過程。

（3） 供應鏈計劃進行供需匹配

     由于需求從明確的SKU變成了各個Attribute的范圍，更清晰地定義的客戶的訴求，因此在訴求之下有大量可以shaping的機會，在對需求進行承諾時候可以基于維度搜索所有供應邏輯庫存資源（包括在途，在制，在庫等）

    看到這個應該還有很多疑問，這種做法真的現(xiàn)實中可以落地么？沒有了SKU所有相關的資源模型、計劃模型全部都得重構?。˙OM、Routing、MPS、S&OP、Scheduling....）

    BT君現(xiàn)在從事云基礎設施行業(yè)，恰好是多年來完全按照無SKu拼attribute的方式在進行，雖然一直想拉回到SKU和BOM正軌上（沒錯，連BOM都沒有）然而終究被SKu爆炸這事給嚇退了，而且行業(yè)迭代速度非?？?，新的維度出現(xiàn)是以季度為單位在進行（如果是sku模式可能就是每個季度要多幾十萬了......）正是在這種模式中，享受了計劃上的便利，也感受到痛苦（SKU模式下所沒有的交叉驗證規(guī)則痛苦），偶然發(fā)現(xiàn)了ABP這種方法走的是同一個路子，不經頗為興奮，似乎是條正路

   由于筆者是從實踐中來，回頭去找理論支持，所以對ABP理論上也是剛接觸，有興趣的朋友歡迎一起探討。

  下一篇準備，介紹下實踐中是怎么應用十幾個字段拼接來做供應鏈計劃以及庫存這回事