經過小Q和浩子兩人從周末開始，每天晚上加班到10點的奮力拼搏，系統劃分和交互流程終于在周三前全部梳理完畢。周三下午 17點，還是上周五的會議室，技術部核心骨干如數到位，小Q約了今天給云老師和各位技術骨干匯報藥健康后臺系統規劃的系統流程設計方案。飛哥因為會前臨時被倉儲部門同事拉著聊了一個需求耽誤了2分鐘，按照會議慣例，乖乖發了200紅包給參會者，小小福利給大家帶來了無限歡樂，匯報會就在一片喜悅中開始了。

01 電商后臺系統功能概述

        “按照上周五會議上的決議，我們會根據業務條線將后臺系統劃分為多個子系統來規劃，這是確定的系統方案，大家再回顧一下。”，小Q先對上次說結論做了累述，并讓大家回顧了一下整體系統規劃方案：

   ▲一個典型電商新零售的產品架構（參考）

         “小Q，你能給我們講講這每個系統的主要工作職責嗎？”，公司的元老阿紳指著架構圖提問道。很多從傳統行業出身的同事，都是一套ERP走遍天下，對這種互聯網式的打法不太了解。

         “好的，那我們就對著圖逐個說明吧！”，小Q拿起桌子上的激光筆，對著PPT上的系統逐一描述。

         “1.基礎數據主要用于咱們日常所有的基礎數據的創建和維護，并對公司其它系統提供唯一數據來源服務，這是所有業務溝通以及業務子系統開展的基礎。比如商品和供應商的首營建碼、商品分類、倉庫、門店這些信息等等，一個公司不應該有多個地方都在維護基礎數據信息，容易發生信息亂套。”；

         “2.電商平臺是咱們公司搭建的直接可以供用戶在線下單購藥的洽談平臺，也是我們業務的門面和主要的銷售渠道。很多人以為電商平臺就是全部，殊不知電商平臺上所有展示的商品、價格、庫存、折扣促銷、下單邏輯均來自于后臺各系統提供的服務。”；

         “3.中央庫存是統一管理全國各倉和各門店庫存的中央處理器，對上管理電商平臺的可銷售庫存，對下管理各地的實物庫存，并根據業務規則為訂單智能匹配最合理的發貨倉/門店。商品的庫存數是整個供應鏈業務的核心，是業務能順利流轉的基礎，所以設計中央庫存時一定要保證庫存數的實時性和準確性。”；

         “4.運營系統主要用于電商平臺日常的運營，為營銷部提供各種營銷工具，以便最大力度的獲取用戶、提升訂單轉化率和提升平臺GMV(成交總額）。運營平臺搭建的好壞直接影響電商平臺的經營好壞”；

         “5.工單系統是記錄、處理和跟蹤公司內部問題和任務流轉的工具，是各部門工作推進的紐帶。”

         “打斷一下，工單系統和咱們現在用的郵件有什么區別？”，阿紳問道。

         “雖然郵件系統也是用以工作信息流轉，但郵件更加偏向于日常的工作交流和文件傳輸用，不具備信息存儲和統計功能；工單是專門針對日常問題和任務的推進和跟蹤，更加關注流程的順暢和問題處理的進度，針對性更強。在前期咱們研發資源不夠的時候可以先用微信、郵件代替。”小Q面對阿紳解釋道，見阿紳點頭示意已經明白了，繼續講道。

         “6.訂單系統是處理客戶銷售訂單履約和退貨換貨的系統，對上承接銷售平臺訂單上下傳，對下對接各地倉庫和門店，并在訂單、退貨單流轉過程中調用外圍系統的服務完善訂單履約數據，是整個訂單下傳和下傳的調度中心。”；

           "7.采購系統是協助采購部日常做采購計劃、管理供應商、維價、退供應商的工具，專門為采購部門量身定做。”；

         “8.客服系統是客服部門日常用于管理客戶、處理客戶問題、記錄客戶事件的工作臺。”；

         “9.倉儲系統是處理日常商品的庫內日常作業的系統，用以提升庫房的作業效率和精益性，降低差錯率。一般倉儲部和質管部使用比較多。等未來業務做得更大了，會搭配PDA、電子標簽、立體倉庫、機器人等智能設備一起使用。”；

         “10.配送系統用作商品的配送環節的支持，一般分為3PL和自營配送兩種模式。3PL模式下，主要體現為分配物流公司、獲取物流單號；自營配送模式下主要涉及自有配送體系的收貨、分揀、派車、配送等業務支持。當然自營配送模式太重，不是一般公司能支撐的起的，所以3pl還是主流。”；

         “11.零售系統用于線下門店的日常運作管理。在新零售模式下，體現為兩大塊：一塊是傳統線下的POS售賣；另一塊是線上訂單導流到門店，由門店發貨配送或者用戶上門自提。”；

         “12.財務系統統管公司所有的與資金相關聯的業務，是公司資金進出的最后一道屏障。主要用于支持財務人員日常賬務處理、資金往來、發票管理、財務核算等業務。”。

          "以上就是我們規劃的所有業務系統的主要功能概述，當然在實現的時候會圍繞核心功能與各對接業務部門深入溝通，按照我們的業務現狀出具最小可用模型，然后持續迭代”。

        小Q說完以后，感覺口有點渴，拿起身邊一只陶瓷水杯喝了一口，彼時，杯身印著鮮紅的“工作讓我快樂”6個大字正對著云老師和飛哥等一行人，紅字下面是戴紅軍帽敬禮的卡通毛主席圖像......這是上周末逛街的時候，在一個創意小店里婉柔親自給小Q挑選的，硬把那只用了兩年的保溫杯給換了下來，原因是：太-油-膩~~

 02  電商新零售后臺系統使用部門及功能劃分

       “按照前面的系統劃分，我們簡單羅列了一下每個系統最主要的受眾部門和對應的系統功能，大家請看！”，小Q往下翻了一頁，用激光筆對著功能劃分腦圖對大家又一番陳述。

▲電商新零售后臺使用部門及功能劃分

         "首先看采購系統，主要使用部門是采購部，常用功能是采購詢價及維價、采購單創建及審核、退供應商、供應商績效管理。同時，系統還會結合大數據分析提供銷量預測和補貨建議功能，以供采購部更好的實施采購。"

         “再看客服系統......”，小Q就這么一路介紹完了所有系統分工，眾人似懂非懂。

   03  供應鏈業務系統主流程

         “通過單個系統看，大家可能還不能很好的將系統和業務結合起來，我畫了一張圖，將主要業務流程和系統操作串聯了起來，這樣大家會清晰很多。”，聊完功能劃分，小Q又一一解答了大家的提問和疑慮，然后開始講解主流程。

    （對業務流程感興趣的朋友可參見《產品經理如何從0到1規劃新零售供應鏈核心系統（中篇）》）

▲電商新零售系統整體流向圖

       “【商品及供應商建碼流程】當公司決定平臺上準備售賣某新藥A，采購會先進行談判、比較，找到最合適的供應商，然后在基礎數據平臺對供應商進行首營建碼，然后在基礎數據平臺對新藥進行首營和建碼；

         【采購入庫流程】有了供應商和商品信息以后，基礎數據平臺會同步給外圍系統比如采購系統，這樣采購部就可以在采購系統中創建采購計劃并經過審核以后下發倉儲系統；庫房待供應商送貨到達以后，在WMS里完成入庫的全流程。上架完成以后，商品就有可用于銷售的實物庫存了，同時同步給中央庫存。

         【電商出庫流程】一旦中央庫存有可售賣物庫存了，運營同事就會在運營系統中將商品在電商平臺上架（當然，如果有預售或者虛庫存的情況下無需等有實物庫存了才上架）。商品上架顯示了，用戶就能進行搜索和下單；生成的訂單下達訂單系統，由藥師電話回訪并審核通過，訂單系統待訂單分倉、分物流后，根據中央庫存分配的訂單出庫地點，將訂單下達對應的倉儲系統或者零售系統，在倉庫或門店完成訂單的揀貨復核和打包發貨；如果是需要配送的訂單，會交接給物流公司，包裹在配送過程中，配送系統會全程跟蹤包裹流向，直到訂單安全送達客戶手中并簽收。

        【客戶退貨流程】如果客戶對包裹拒收，或者有售后問題需要退回，先聯系客服，客服在客服系統中進行跟進并記錄事件，然后在訂單系統中根據原始訂單創建退貨單（這里也可以由訂單系統提供服務，在客服系統中創建）下達商品退回的庫房/門店；待倉儲/門店收到貨以后，在倉儲/零售系統中操作完退貨入庫。如果涉及退款，財務會在商品入庫以后，原路將款項退還用戶。

        【退供應商流程】根據和供應商的合同約定，采購會定期將滯銷品退回供應商，先由采購在采購系統中創建退供應商單，經過審核后下達倉庫進行退供出庫。門店商品若需要退供應商，需先將商品退回倉庫，再由倉庫統一退出。

       以上所有的流程在系統層面都會圍繞基礎數據、庫存處理和財務核算三大核心功能展開，這三大核心也是整個供應鏈系統的核心所在。若能有效的管理好基礎數據、庫存（物）和財務（錢），則整個供應鏈體系成矣！”。

   04  供應鏈核心業務系統流程詳解

      趁大家討論的間隙，小Q再次喝了一口水，這回故意把杯面的幾個大字面向了飛哥，還用手指敲擊了兩下，并偷偷對飛哥使了個賤賤的眼色。突然轉頭發現旁邊云老師也在盯著自己的杯子看，于是立馬收起了自己的玩世不恭，正色道：“最后，我再給大家詳細介紹一下新系統規劃下幾大核心供應鏈業務流程的系統流向”。

（1）供應商及商品建碼系統流向

        “首先請看，商品及供應商建碼的系統交互流程如下：”

▲供應商及商品建碼系統流程

      “供應商和商品建碼有依賴關系，先有供應商資料了，再創建該供應商下的商品資料。資料創建或修改完以后，生成正式有效的系統編碼，并由基礎數據平臺對外圍系統統一廣播分發”。

       “其它基礎資料如：倉庫、門店、物流公司的創建比較簡單，由集團總部在基礎數據平臺中統一創建完后分發各業務系統即可，若考慮到數據安全風險，可以增加一級審批流程。”

（2）采購入庫業務系統全流向

“以下是采購入庫業務的系統交互全流程：”

▲采購入庫系統全流程

       “以上財務流程僅展示了正常月結方式下的財務流程，若為預付款方式，區別在于采購做完采購計劃后，先向財務申請打款，待財務付款以后，供應商再發貨，其它環節處理基本無差異。”

（3）電商出庫業務系統全流向

    “下面看公司最復雜的一塊業務，電商銷售出庫業務：”

▲電商出庫系統全流程

         “一張客戶訂單從下單到簽收一般經過電商平臺、運營系統、訂單系統、中央庫存、配送系統、倉儲系統/零售系統等多個系統的交互處理后才能完成整張訂單的履約，在此過程中，訂單系統起著整體的調度和監控作用，就像是人體的大腦、電腦的CPU一樣重要。”

           “因為咱們公司配送以3PL為主，主要依靠四通一達等快遞公司，在月末結算的時候，財務對在線支付訂單和貨到付款訂單分別與支付寶/微信/銀行和物流公司之間的對賬也是一個很重要的工作，這里要衍生另一個系統：統一對賬平臺，因為不涉及供應鏈主流程，所以不在此次規劃范圍內。‘’

（4）客戶訂單取消系統全流向

         “再來聊聊訂單取消流程：”

   ▲客戶訂單取消系統全流程 

         “訂單取消是個比較復雜的流程，系統需要判斷當前訂單正處于在哪個環節，不同的環節的處理邏輯不同。按照我們的業務現狀，商品從庫房發出以后就不能再取消了，但如果我們的配送系統能夠與各大物流公司系統打通實現聯動，或者我們的自營配送足夠強大了，那么就可以實現訂單在派件之前的任何環節都可以將訂單取消并攔截回來，節省物流成本。”

（5）客戶退貨退款業務系統全流向

        “下一個流程是客戶退款退貨流程：”

▲客戶退貨退款系統全流程

      “從一個完整的電商閉環來設計，有正向出庫，就必然會有逆向退貨退款流程。系統在處理退款時，咱們要遵循兩個原則：一、一定要確保商品完整的返回庫房以后才能退款，如果是貨到付款的包裹拒收引起的退貨流程，是不需要退款的；二、退款要按原路返回，這樣可以有效規避某些客戶故意用信用卡套現等風險，當然，如果是物流公司代收的貨款，而咱們跟物流公司之間又是以月末對賬結算的方式合作的情況另當別論了，這時需要和客戶商量一個有效確保雙方利益的退款方式。”

（6）退供應商業務系統全流向

        “下一個是退供應商流程：”  

▲退供應商系統全流程

        “退供應商的場景和電商出庫流程略有不同。電商出庫一般包裹較小，需要合并多張訂單為一張批揀單，按批揀單分發成揀貨任務揀貨出庫；但退供應商一般是大批量藥品一次性退出，所以不需要批揀，流程相對簡單。在系統設計的時候，我們可以考慮功能復用，但兩類業務系統功能層面最好分開，不要相互混淆。”

（7）門店請貨系統全流向

▲門店請貨系統全流程

         “門店請貨其實是一種調撥行為，因為不涉及商業行為，所以從財務成本來看屬于平進平出。在門店成本計算層面有兩種方式，如果門店有自己的成本核算需求，那就按照請貨出庫時倉庫的成本價與門店在庫成本價進行加權平均算得門店商品的新成本，否則都以集團總部倉庫的成本價為準。

        因為在請貨過程中存在商品的庫存變動，為保證集團總部能集中監控所有庫存，中央庫存中應該設置一個在途庫存功能，記錄這部分在途的數量。”

（8）門店返倉系統全流向

▲門店返倉系統全流程

        “門店返倉一般發生在總部需要從門店調貨，或者門店的商品過多需要退回總倉的情況。從系統層面按照請貨的逆向操作處理。”小Q講完最后一套系統流程后，看了一眼時間，2個小時已經過去了，云老師又讓小Q將PPT翻回前面幾頁，提了一些疑問點，然后大家各自討論開了......

   05  戰爭才剛剛打響

           從會議室出來，已經快晚上8點，方案最終受到以云老師為首的所有技術同仁的認可，大家都對未來充滿了信心和憧憬，一致要求這個項目要盡快向前推動落實。下一步就要對每個系統需求進行細化了，對產品經理來說，這將是比整體方案更大的挑戰，無論從人力還是從精力上。

           小Q和浩子去樓下吃了個煲仔飯，然后在珠江邊溜達著談天說地。夜幕已經開始降臨，天邊晚霞由紅色逐漸變成了暗藍色，似是在向今天的余暉揮手謝幕；路燈已經開啟，人從路邊榕樹下經過，雙方影子像皮影戲一樣動靜結合，融為一體；打著各種廣告的珠江夜游輪渡一艘艘由遠及近緩緩駛來，船上的燈光和游人的倒影在江面隨浪花起舞，船底掀起的浪紋嘩啦啦涌向岸邊并連續撞擊著岸邊墻石，激起的浪花在空中劃過一條完美的弧度又沉落江中，配合著遠處傳來的陣陣渾厚的船鳴聲，像是天公在演奏著一首戰爭題材的交響樂，而樂譜，就是這美好夜色下的萬萬千千，包括正在悠悠哉哉閑扯的二人。

       戰爭？沒錯，對小Q和浩子來說，本階段工作雖然告一段落，但接下來數十個的系統規劃這場大仗，號角才剛剛吹響……