起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識電商O2O后臺供應鏈系統實操記錄——采購模塊
本文主要寫作者在公司設計供應鏈系統的實操記錄，根據所在公司的業務模式，介紹供應鏈系統整個設計過程的思路、方法和核心要點。
電商、O2O行業的產品線中，后端的業務支持系統占據了很大的比重，比如訂單系統、供應鏈系統等。
不同于純線上的產品，電商、O2O領域的產品基本都是后端大于前端，這些后端產品覆蓋了公司的核心數據，作為公司業務運行的基礎。而且因為每個公司的業務形式不同，通常需要有一套自己的或者定制化的系統作為公司獨特的業務支持。
供應鏈系統是為公司提供商品進銷存業務的管理系統。大部分以交易為核心業務的公司，都有自己商品進貨發貨的供應鏈業務，而各個不同的行業和領域又有自己獨特的供應鏈業務形態。供應鏈系統通常包含采購、庫存管理、出入庫、物流等多個模塊，是公司后臺產品線重要的一環。
作為一個后端產品的產品經理，日常工作的核心在于深入地挖掘業務，梳理流程，產出模塊化的系統設計方案，和C端產品有著不小的差別。
本文主要寫我在公司設計供應鏈系統的實操記錄，根據我所在公司的業務模式，介紹供應鏈系統整個設計過程的思路、方法和核心要點。
由于供應鏈具體的業務和流程每個公司不一樣，這類后臺產品并不像C端產品那樣能直接用來參考，因此本文不是一篇介紹供應鏈系統應有的流程和功能的文章，核心在于思路和方法的分享，功能細節僅供參考。
一、業務背景和系統目標
首先介紹一下公司的基本業務。我們是一家做上門服務的O2O公司，不同于打車外賣等純供需匹配的模式，我們的服務體系是自營的，而且由于自身業務的特殊性，有自己的一套類似于電商的供應鏈業務。
我們的具體業務，首先是由上門服務人員領取倉庫的商品，用戶下單后，上門到用戶家里完成服務，根據訂單消耗商品同時產生廢品，完成服務。
商品來源于供應商的采購，廢料通過采購的逆向流程退回供應商。整體來說，我們的供應鏈和通用的電商供應鏈體系比較類似，有采購、庫存、出入庫模塊，只是沒有物流發貨的業務。
設計系統之前，第一步需要明確系統的目標。我們公司之前有一個1.0版本的供應鏈系統，但是舊版系統有很多業務流程的缺失，造成庫存數量不一致，很多模塊都是業務方在做手工帳，已不符合當下的業務發展。因此公司需要做一個2.0版本的新版系統來完整地支持業務。從產品角度來看，相當于從零到一的系統重構。
整個供應鏈業務的核心目標有三點，庫存一致，資金一致，一物一碼，分別是三個階段。一物一碼是未來的目標，資金一致需要和財務系統的體系打通，當前版本的目標即為從手工帳到系統庫存一致。細分下來，需要將所有業務模塊線上化，在每個業務模塊中，涵蓋所有環節的人和操作，即達到流程閉環。
二、什么是采購
采購，顧名思義，是從供應商手上批量采購商品到我們自己的倉庫。采購是供應鏈業務的頭部環節，作為公司庫存的源頭，又有著大量現金流，其重要性不言而喻。供應鏈系統的采購模塊對業務的價值主要有三點：
1. 不同角色之間的業務流轉和信息同步
采購會涉及到采購人員、供應商、倉庫、質檢這幾個角色，一項采購業務需要在每個角色之間流轉，各角色之間需要實時信息同步。這一點是基礎。
2. 數據分析的輔助決策
采購各環節中的數據分析，比如供應商的良品率、發貨時效，比如各個商品的采購滿足率等，在有業務流程的基礎上做數據分析。
3. 庫存和資金的一致性
采購是公司庫存和利潤的源頭，需要系統記錄每一筆庫存數量和財務的資金賬目。
供應鏈系統的采購模塊包括幾個部分：采購的主流程，即采購申請、下采購單、采購入庫這一系列流程；供應商管理，針對供應商信息、樣品和財務的管控；采購逆向流程，即供應商退貨。本文主要介紹采購采購的主流程。
三、采購主流程的業務對接
明確系統目標后，接下來就開始和業務方，即公司的供應鏈部門，進行業務的對接。
1、第一步，梳理流程，確定強流程節點，所有業務圍繞著這幾個節點進行
流程圖如下：
2、第二步，需要確定每個流程節點中，參與業務的人員角色
我們公司的采購業務有以下這幾個角色：
1）pmc，即物控計劃員，職責是根據訂單消耗情況，管控倉庫商品數量的計劃。在采購流程中，作為采購申請的發起者。
2）采購人員，根據采購申請，向和各家供應商下采購單。
3）供應商，外部角色，根據采購單發貨，并定期和公司進行采購結算。
4）倉庫，接受供應商發來的商品，并將良品入庫，不良品退回。所有貨物實體必須由倉庫操作收發貨。
5）質檢，如果采購來的商品需要進行質量檢驗，需要質檢參與進行檢測。
6）財務，進行采購單的審核，定期和供應商結算。
3、第三步，確定各流程節點的具體操作，梳理完整的流程
1）采購申請。由pmc根據計劃，或者其他倉庫提交上來的申請來統一創建、管理采購申請。采購人員收到采購申請后，將采購的商品和數量分配給多個供應商，針對每個供應商分別創建采購單。
2）采購。采購環節比較復雜，首先采購人員創建采購單后，需要與供應商核價，即確認報價。收到供應商的反饋后，采購人員再確定采購單并提交至財務部門進行審批，最后提交給供應商進行發貨。由于早期沒有給供應商的系統，需由采購將以上采購信息錄入系統。
3）發貨。發往每一個倉庫的采購單，供應商每個批次發貨時給出發貨數量和物流信息，同樣由采購人員進行錄入。
4）收貨。由倉庫人員清點從供應商收到的商品及數量，通過收貨操作錄入系統。
5）質檢。首先根據發貨倉庫是否有質檢人員來配置是否需要質檢的判斷。需要質檢的批次，通過質檢操作填寫質量檢測的結果。
6）入庫/退貨。根據質檢結果，倉庫人員分別進行入庫和退貨操作。在入庫環節發生庫存數量的變化。
7）結算。根據供應商的賬期，在一個固定的時間和供應商進行結算。因為這一步不是實時的環節，不算在主流程中。
根據角色和業務操作，我們可以將流程圖細化，如下：
四、業務場景、數據和關系的梳理
完成業務流程的對接后，接下來需要對接數據、單據等業務的細節，根據這些確定系統各子模塊的結構、關系等。
1、第一步，確定一個單子會包含哪些字段
首先是商品，即具體采購什么貨品，數量多少，價格多少。
然后是供應商。每個采購單都會有個目標供應商。
第三個，倉庫。一個采購單會發貨至不同的倉庫，因此倉庫也是一個重要的字段。
2、第二步，確定各環節之間的的關聯關系，一對一還是一對多，強關聯還是弱關聯
這一步是重點，直接決定了底層數據表之間的關系：
1）采購申請和采購之間：一對多關系，弱關聯。采購人員會對一個采購申請拆分多個供應商，分別下采購單，因此兩者之間是一對多關系。實際業務中，存在不通過采購申請，直接下采購單的情況，比如一些讓供應商補發的采購，因此兩者之間是弱關聯；
2）采購單和采購收貨之間：一對多關系，強關聯。
采購單詳情里有倉庫這個字段，所以一個采購單本身對應的就是多個倉庫的收貨。從收貨開始一直到最后，單據都是以倉庫為單位，但采購單中，倉庫字段被放在了在商品詳情里。為了方便各倉庫操作，在設計系統時，加入了采購子單的概念，即以供應商和倉庫為單位，將一個采購單拆分為多個采購子單，發貨環節依據采購子單進行發貨。
存在供應商對同一個倉庫的采購單進行多批次發貨的情況，比如采購單的周期為一周三批，供應商會在每周固定時間分批次發貨。因此采購子單和發貨是一對多關系。
發貨一定是根據采購單發的，因此強關聯。
3）采購發貨和采購收貨：這兩個操作使用的是同一項數據，收貨完全按照發貨進行。
4）采購收貨和質檢：同上，使用同一項數據，質檢完全按照收貨進行。
5）質檢和入庫/退貨之間：各自一對一，強關聯。收貨并質檢后，會根據質檢結果，將采購收貨的記錄拆分為需要入庫和退貨的部分，一個批次的采購收貨分別對應一個批次的采購入庫和采購退貨。
在這里有一個注意點：不能有多對多的關系，因為多對多關系會無法溯源。
舉一個例子，在設計系統時碰到了這樣一種情況：原本計劃在采購申請環節中，以倉庫為單位提交采購申請單，再交由采購。
這樣做的結果是，申請子單和采購單就是多對多關系了，申請子單是以倉庫為單位，采購單以供應商為單位，那么采購單的下一步發貨，每個供應商就只有發貨總數量，獲取不到分別給每個倉庫發多少貨了。除非把每一個供應商和每一個倉庫全部拆開，那樣一次采購得有上百個單子，根本不現實。
后來我們的做法是采購流程中不包含倉庫為單位的采購申請，只提供匯總的申請功能。
3、第三步，確定各個環節的關系，確定有哪幾個單據，以及每個單據的商品詳情字段
整個流程中，一共包含這五種單據：采購申請單、采購單、收貨單、入庫單、退貨單。
1）采購申請單：采購申請環節的單據，字段為倉庫、商品、數量。
2）采購單：采購環節，根據采購申請單創建采購單。以供應商為單位，詳情字段為倉庫、商品、數量和價格。供應商本身不計入詳情的字段中。
3）采購收貨單：收貨和質檢環節，根據采購單創建采購收貨單，以倉庫為單位，字段為商品、收貨數量、質檢通過數量和質檢不通過數量。
4）入庫單：入庫環節，同上。
5）退貨單：退貨環節，以倉庫為單位，字段為商品和數量。
4、第四步，確定各單據之間，商品數量是否有關聯關系
因為庫存數量是整個供應鏈系統的核心，所以需要確定商品數量的變動過程：
1）采購申請量和采購量：在實際業務上，采購量不一定等于采購申請量。因為采購申請是計劃入庫的數量，但給供應商下采購單時，需要考慮到供應商少發、質檢不通過需退貨的情況，因此采購數量通常會大于申請數量。兩者之間數量無關聯。
2）采購量和采購收貨量：下采購單后，供應商會有發貨數量不足、路上丟失等情況，所以收貨數量也不一定等于采購數量，無強關聯，收貨數量需要倉庫清點后填寫。
3）采購收貨量和采購入庫量/退貨量：這里很明顯，入庫和退貨是根據收貨的數量來的，所以數量之間有強關聯，入庫+退貨=收貨。
根據以上梳理得出的各環節關系結構圖如下：
五、界面和操作
最后一步，終于到了設計界面和操作，產出原型的時候。這時需要將業務轉化為界面顯示和功能，還有以下幾個事情要做：
1、界面
界面設置有兩種做法，一種是將一個單據作為一個界面，通過權限將操作分開；另一種是將每個流程環節作為一個界面，我們采用了這種方案，保證每個界面有唯一的角色。
2、狀態
狀態的設置需要參考當前所處環節和數量變動情況這兩個情況，給出用戶需要了解的動態描述。采購的狀態非常繁多，每一個獨立的環節都需要有單獨的狀態，而且需要根據每個商品，將狀態劃分為部分和全部。具體頁面的狀態如下：
1）采購申請：待采購、采購中、已完成；
采購申請是由pmc發起和跟進的，不關心具體的采購過程，只需要給出采購結果；
2）采購單：待采購，已發貨，部分收貨，全部收貨，已質檢，完結；
采購單是核心的環節，由采購人員對采購過程進行全程跟進，因此狀態需要精確到每個節點，和單據中的每類商品。
3）采購發貨/收貨：待收貨，待質檢，已質檢，完結；
收貨單是從發貨環節開始，由倉庫負責收貨以及后續的跟進；
4）質檢：待質檢、已質檢；
5）入庫：待入庫、已入庫；
6）退貨：待退貨、已退貨；
這三個環節只涉及到一個操作，比較簡單。
3、功能操作
功能操作是根據狀態實時變動的。將前文梳理出來的操作，對應到每個頁面的每個狀態節點中即可。
功能操作設計的核心，在于能最大保證數據準確性的前提下，盡可能提升操作的效率和體驗。首先，對于一個從0到1的系統來說，在系統上做類似于excel的數據操作一定是很難用的（尤其是沒有前后端分離的系統）。然后，有些功能會存在數據準確性上的風險，比如導入和批量操作。
部分業務環節的數據量會非常龐大，比如采購單的創建，詳情數據動輒上百條。
這時業務方會希望在ecxel中做這些操作然后導入系統，但是站在系統的角度，必須平衡數據風險和操作體驗，因為導入后系統很難一條條去監控數據的正確性，一旦excel里數據錯了又沒查出來，后果不小。
因此我們只能有選擇性地做導入功能，對于新增的數據支持導入，對于數據的修改則不支持導入。鑒于此，針對每個操作的設計都需要斟酌一番。
最后附上部分頁面和操作的原型圖。
1）采購申請頁面
2）采購單頁面
3）采購收貨頁面
4）采購商品詳情
5）創建采購單（包含導入和導入校驗操作）
6）批量發貨操作
7）收貨操作
8）質檢操作
相關閱讀
#專欄作家#
潘帕斯雄鷹，人人都是產品經理專欄作家，進擊、踩坑中的產品狗一枚，關注互聯網，寫過小說，看過哲學。簡書：潘帕斯雄鷹。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels ，基于 CC0 協議
采購單據沒有采購變更單么？如果采購過程中突然變更需求這個是怎么解決的？
樓主少考慮了一個十分重要的字段，時間字段，比如，計劃入庫時間，采購訂單創建時間，供應商承諾時間，到貨時間，入庫時間，這些很重要
您好 您寫的文章讓我受益滿滿，我之前也做過類似工作內容的工作 ，希望以后可以往這邊發展 方便加一下微信討教一下嗎
講的很全面思路也清晰，學習到了，干貨滿滿
干貨滿滿 點贊博主
已收藏，因為業務的后臺類似電商，最近也在瘋狂的 學習中?？戳艘槐檫€有點懵逼，大神原型分享學習一下，感激
學習了，思路很清晰，跟著過了一遍，感覺是自己經歷了一遍項目。感謝
請我有原型下載嗎
贊。我也是做供應鏈系統的，問個業務上的問題，采購單中的”地區”是指收貨倉庫么？如果是，為什么圖七中一個收貨單中會出現多個收貨倉庫呢？
非常感謝，寫的很詳細又全面
財務核算那塊實際可能不多，一般都是提前按照協議好的價格
思路講得清楚，參考價值很高，簡直就是教科書嘛，棒棒的
謝謝！一個采購單包含不同倉庫不同的產品比較復雜，提交倉庫無貨時或者只有部分貨處理