起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識構建數字化供應鏈：生鮮行業的基礎數據管理
之前有提到過我在后面的公司參與了ERP系統的搭建和前臺工具的實現。上一篇跟大家分享了前臺銷售工具（BD助手）的立項-結項的過程。從這篇開始，我會將之前負責的生鮮供應鏈ERP系統以我自己的理解逐步拆解出來，供大家參考?？赡軙泻芏嗬斫獠蛔慊蛘哌z漏掉的地方，請大家多多斧正。
供應鏈ERP系統很龐大，涉及到的板塊也比較多，我會拆分幾篇跟大家逐步分享下，初步計劃是以基礎數據-采購與供應商管理-訂單與配送-庫存管理-財務與結算-數據分析與決策支撐的幾個模塊跟大家分享。
生鮮行業本身是一個具體的業務方向，也有自己的一些特殊性，系統設計也會兼容這部分特殊性，所以從事不同業務方向的同學有疑惑或者有指正的地方可以在評論區留言，大家一起探討下。
感興趣的可以關注一下我，跟我一起從零到整拆解供應鏈生鮮ERP。
一、背景
老規矩，先講一下項目的背景。
最開始做這套生鮮ERP的主營業務方向是面向于批發客戶（主要是大B，政企單位）的食堂采購需求，旨在通過線上ERP系統管理采銷配過程中的各個環節，做到資金流/訂單流/物流三大流程的線上化，提升人效且規范化管理。
后期也借助這套生鮮ERP快速支持了新業務的拓展，也就是當前在做的面向小B的在線批發配送業務，可以說整體的架構設計還是比較合理的，后續也支撐了集團多業態業務的開展。
拆解供應鏈免不了要從基礎數據開始，基礎數據作為數字化供應鏈的基石，對整個生鮮供應鏈的運作都起到關鍵作用。
二、基礎數據
每個系統都有自己的基礎數據，支撐系統的正常運行，同時也因為業務方向的不同，基礎數據的種類也不同。
本篇分享的生鮮供應鏈ERP中主要包含的基礎數據種類有組織、商品、供應商、客戶、倉庫、物流等。
基礎數據中有些是涉及到全局使用的，比如商品編碼，必須全局統一，避免因商品編碼定義不同導致的系統單據流轉差異；有些數據又是局部使用的，比如商品銷售名稱，在不同業務或不同區域中允許存在不同定義，以適配不同的業務場景。
基礎數據的管理主要涉及到數據的增刪改查以及審核和下發，要確保數據管理的高效性、安全性和準確性，需要做到：
- 數據定義要清晰、明確，不存在歧義，數據類型要標準化。
- 規范數據的準入和更新流程，明確下發字段和下發及時性要求。
- 保障數據的質量，定期校驗數據準確性。
- 設計數據安全與權限策略，限制對敏感數據的訪問和編輯，追蹤數據的變更記錄。
- 定期備份數據，以防止數據的損壞或丟失。
基礎數據一定要在設計整套系統架構時考慮清楚，如果系統已經實施了大半或者已經上線后，才發現基礎數據的設計不足以支撐現有業務，那改起來是非常痛苦的，等于樓盤都交付了要去改地基。
我們現有業務在商品主數據方面就出了類似的問題，調整過程很漫長且難以落地。
三、商品主數據
1. 商品準入/作廢
我們公司的商品主數據是在SAP中進行維護的，商品準入是在OA申請商品主數據創建流程，補充商品的基礎信息，流程審批通過后創建成功，再依次下發到各業務系統中，作廢同理。
2. 商品的SPU/SKU/SN碼
根據使用場景和管理維度的不同，可以將商品用SPU/SKU/SN來代指。
- SPU（Standard Product Unit）： 標準產品單元。SPU是一組具有相似外觀、功能和用途的商品的標準標識。通常，同一SPU下的商品在功能和外觀上是相同的，只是細節上可能有所不同。
- SKU（Stock Keeping Unit）： 庫存量單位。SKU是對具體庫存商品的唯一標識，通常由數字和字母組成。每個SKU都對應著一個特定的商品，它可以是SPU的一個具體實例。SKU通常用于區分不同的商品屬性，如顏色、尺寸、包裝等。
- SN碼（Serial Number）： 序列號。SN碼是商品的唯一序列號，通常由數字、字母或二維碼組成。每個商品都有一個唯一的SN碼，通過這個碼可以追蹤商品的生產、流通和銷售情況。SN碼通常用于保障產品的質量追溯、售后服務以及防偽等方面。
一般來說一個SPU可能對應多個SKU，一個SKU可能對應多個SN碼，即
舉個例子，大家可能更好理解一些：
- SPU更多的使用場景是在銷售和運營層面，同時方便用戶的搜索和后臺的快速歸集及數據統計，制定商品策略等。
- SKU是具體的商品屬性的歸集，更多應用在價格和供應鏈層面，包含商品定價，出入庫管理，商品備貨，庫存管理等。
- SN碼也是供應鏈管理的維度，不參與銷售行為，更多的是庫存精細化管理的標記，一般應用于電子產品、汽車、醫藥等較多，要精確到某一個具體的實物身上，方便后續追蹤。
3. 商品屬性
上文中有提到基礎數據也分為全局使用和局部使用，可以拿商品基礎數據來拆解一下。
1）如果業務系統僅服務于一個業務體，不存在其他業務或不考慮復用性，那商品基礎數據可以全量維護在一個表單，商品準入后即創建成功。
這樣創建和維護比較簡單但局限性很大，基本只適合在后臺使用，前臺無法共用。如果有一些通用屬性相同，銷售屬性不同的，需要重新再維護一遍，工作量也比較大，且統計也比較難以聚合起來，統一分析。這種比較適合品類比較單一，不需要做聚合的企業。
2）如果考慮多業務體復用性，則可以根據商品屬性區分：
- 基礎屬性（全局統一）：①商品編碼 ②商品名稱 ③商品主分類 ④基礎單位。
- 銷售屬性（允許不同業務體定義值不同）：①商品銷售名稱 ②前端銷售分類 ③稅率 ④商品銷售單位 ⑤規格 ⑥標簽 ⑦商品圖片等。
這樣在商品準入時維護商品基礎屬性即可，銷售屬性在實際引用時維護，這樣可以做到系統在服務不同業務體的時候，同一商品僅需要建碼一次，在引用時通過維護不同銷售屬性加以區分可以靈活適配不同業務情況，同時也避免數據混亂或數據統計不完全，比較適合平臺型企業或品類較為復雜，涉及到的數據維度也比較復雜的企業。
4. 商品類目
商品類目是商品的一個重要組成部分，在內/外部系統中使用頻率都比較高。一般來說，商品類目有一級類目，二級類目，三級類目等。三級類目基本可以滿足多數系統的使用需求，但不排除有些業務有更精細化的要求，會分到四級類目，比如汽車零部件行業等。
1）商品類目可以拆分為后臺主分類和前端銷售分類。
商品主分類是所有商品的標準分類，通常是兩級到三級樹形結構，涉及到很多外部系統的邏輯，一般不會輕易變更。
主分類上還可以承載商品的基礎屬性，在維護商品時，選擇主分類后，可以將分類下的屬性帶出，節省維護商品數據的時間。
同時，后臺主分類也多用于商品數據分析的場景，輔助判斷商品的流通性、銷售趨勢、價格趨勢、庫存趨勢等關聯性。
2）前端銷售分類主要是用來促進銷售，有時具備一些營銷或節日屬性（比如今日促銷、產地蔬菜），且多是平鋪，方便客戶瀏覽查看。
前端銷售分類有時還會承載一種業務類型的規則聚集，以我們做的生鮮供應鏈為例，在發起售后時，不同品類（豬肉，蔬菜，雜百等）之間的售后審批流程，售后規則均不相同；這種不同類別的配置就是依靠前端銷售分類來區分的。
后臺主分類和前端銷售分類的對應可能是一對一，一對多，多對多的，主要還是看實際的業務場景配置。
5. 編碼
再跟大家分享下幾種編碼的使用場景：
- 商品編碼：一般是指SPU編碼，商品準入后自動生成，一般使用在系統內部，用于確定具體商品。
- SKU編碼：維護銷售屬性后生成，多用于供應鏈內部流轉，一般使用在系統內部，唯一性確定某一個商品。
- 商品條碼：一般稱為69碼，69碼的編碼規則包含20位數字，其中前14位是全球唯一的商品編碼，由全球唯一編碼機構（GS1）頒發；第15到17位是地區碼，表示商品在哪些地區銷售；第18位是包裝級別碼，表示商品包裝的級別；第19位到20位是校驗碼，用于檢驗前面數字的準確性。主要是用于倉庫出入庫掃描，識別SKU的依據。
- SN碼：商品出廠時印在商品包裝盒上的識別碼，同一SKU下的每一個實物SN碼都不同，一般用在商品價值比較高或需要全程溯源的行業。
四、客戶數據
1. 客戶主數據維護/作廢
同商品主數據，都是在SAP中建檔，流程通過后創建成功，作廢同理，流程的搭建更多是匹配公司業務規則，可根據實際情況配置。
2. 客戶信息
1）客戶基本信息，可直接獲?。?/strong>
- 包括客戶的名稱、公司法定名稱、聯系人等基本身份信息。
- 聯系方式： 客戶的電話號碼、電子郵件地址、傳真等聯系方式。
- 地址信息： 客戶的辦公地址、倉庫地址或者其他重要地址信息，特別是在涉及到物流和配送的業務中。
- 記錄負責該客戶的銷售團隊成員信息，跟進記錄等，以便協調溝通。
2）客戶消費信息，由平臺消費記錄獲得：
- 客戶購買歷史。
- 客戶支付記錄。
- 客戶參與營銷記錄情況
3）客戶用戶畫像，通過數據分析得出：
- 客戶生命周期。
- 客戶類型（普通客戶/VIP會員/分銷商/批發商等）。
- 客戶偏好（下單偏好及客戶售后偏好等）。
- 客戶層級。
3. 客戶結算
如果系統同時支撐多個業務主體，那么在建檔時可能會區分出幾種客戶類型，用以方便最后結算：
- 結算客戶：一般性的客戶類型，表示與公司有結算關系的客戶。這可能包括常規的銷售和采購活動。
- 一次性客戶：短期一次性的交易，不需要保留過多的客戶信息，通常不做建檔，統一放在同一個一次性客戶下。
檔口客戶：一個結算客戶下可能存在多個檔口客戶，在最終結算時均結算在一個結算客戶下。舉個例子：客戶中有學?？蛻簦瑢W校有多個食堂，每個食堂都有單獨的菜單，分開采購。這時候就可以建立一個學校主體作為結算客戶，多個食堂作為檔口客戶，檔口客戶之間可以分開下單，數據不互通，最后統一結算在學校這個結算客戶下。
五、供應商數據
供應商指能夠為組織提供工程、物資和服務的個人或企業。在決定其為供應商之前，通常會經過審查，符合審查條件的可以進入供應商準入流程，還會根據公司定義的供應商評級，為供應商賦予不同的合作層級。
1. 供應商準入/拉黑
圖1.供應商準入流程
圖2.供應商拉黑流程
2. 供應商信息
1）供應商基本信息，供應商的名稱、地址、聯系方式，企業法人，經營范圍，營業三證附件，統一社會信用代碼，營業期限等基礎信息
2）供應商財務信息，企業名稱、開戶行、開戶城市、開戶名、銀行賬號、稅號等。包括與供應商之間的財務交易，如賬期、付款方式等。確保與供應商的財務往來得以準確記錄和核對。
3）供應商合同，記錄和管理與供應商簽訂的采購合同。包括合同的起始日期、終止日期、合同金額、付款條款等內容。
3. 供應商評估
1）供應商資質審核，確認供應商的合法身份，評估供應商的財務狀況和經營能力。
2）供應商績效考核，通過內部績效考核規則和實際業務滿足率進行綜合評估，淘汰掉不達標的供應商。
3）供應商風險評估，分析供應商所處行業和地區的風險，比如在疫情期間，封禁區域的的生鮮產品運送不過來，需要提前考慮備選供應商。
4）供應商合規性評估，監控供應商的表現，一旦發現供應商存在交貨延誤、產品質量問題、違約行為或存在采購和供應商存在非法交易等，及時拉黑供應商，避免造成公司財產損失。
六、倉庫數據
倉庫數據主要是應用在供應鏈和倉儲管理中記錄和存儲的與倉庫運營相關的各種信息。
- 倉庫基本信息，倉庫編碼、倉庫名稱、倉庫類型、倉庫位置、倉庫負責人、負責人聯系方式、倉庫面積、倉庫層數、冷庫數量、營業時間、啟用/停用狀態等。
- 貨架和設備信息，貨架編碼、貨架類型、貨架容量和規格、設備編碼、設備信息、設備狀態等。
- 員工信息，員工工號、員工姓名、員工聯系方式、員工角色、工作權限等。
七、組織數據
組織數據中包含公司、業務線數據。
1. 公司信息
公司信息主要用于掛賬，做財務賬目往來。
公司基本信息，包含公司編碼、公司名稱、國家/地區、公司地址、企業法人、聯系人、聯系方式、公司銀行賬號信息、稅號、營業三證附件、統一社會信用代碼、啟用狀態、稅務信息等。
2. 業務線信息
業務線數據主要用于供應鏈系統中用于劃分業務范圍、管理業務流程的關鍵信息，同一公司下不同業務主體可以用業務線加以區分，靈活運用可以使系統同時兼容多種業務情況。
業務線數據，包含業務線編碼、業務線名稱、業務線分類、業務類型、所屬公司、啟用狀態等。
八、物流數據
如果物流是公司自建的，那需要維護的物流信息會比較齊全，包含車輛信息，司機信息，運輸路線，運輸模式等。
但物流配送行業本身要求專業性高、成本投入大且短期難以看到成果等，通常很多企業是通過三方物流配送公司完成履約，我們公司也是如此。
基于每家配送公司的履約效率，服務范圍和履約費用的不同，企業通常會選擇多個物流配送公司同時完成服務，那我們需要維護的就是物流公司常規屬性數據。
物流公司數據，包含物流公司名稱、注冊信息、法人、聯系人、聯系方式、配送方案、啟用狀態等。
九、總結一下
基礎數據的管理是數字化供應鏈系統的支柱，直接影響到企業的運營效率和決策水平。我們在做系統設計的時候，應該優先考慮基礎數據的建設：商品主數據，客戶主數據，供應商數據，倉庫數據，組織數據等，只有把基礎數據這個地基打好，系統才能在其之上穩步前行。
基礎數據的管理要確保數據的高效性、安全性和準確性，做到：①數據定義清晰，標準 ②數據準入流程規范 ③數據準確，質量高 ④數據安全，權限分離 ⑤數據定期備份。
總的來說，只有通過對商品、客戶、供應商、倉庫、組織和物流等多維度基礎數據的深入理解和科學管理，企業才能在激烈的市場競爭中立于不敗之地。
后面幾章，我們將深入探討采購與供應商、訂單與配送、財務與結算、庫存管理、數據分析與決策支持等關鍵模塊，共同構建完整的數字化供應鏈體系。
本文由 @安妮的日常生活 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
太棒啦 催更