一套完整的電商新零售體系包含哪些基礎數據？醫藥基礎數據行業又有哪些特性？接著小Q的故事，為您講述電商新零售基礎數據平臺設計攻略。
「 以下故事情節及人物均為作者杜撰，若有雷同，純屬巧合：
小Q：某醫藥互聯網公司後臺產品經理，著手規劃重構公司的電商後臺及供應鏈相關係統；
蘭姐: 質管部負責人，基礎數據平臺的主要需求提出方，精通GSP法規。」
今天開始，小Q要著手梳理基礎數據平臺的產品細化方案了，當然準備工作是做充足了的，絕非閉門造車。
除了拉著質管部的蘭姐對GSP（藥品經營質量管理規範）關於藥品和客戶的首營流程聊了個底朝天， 上週末向同樣做產品經理的好哥們阿輝也請教了不少，加上自己在網上的各種深挖，對基礎數據平臺的設計已經有了一套完整的思路。
一、基礎數據平臺整體設計思想
基礎數據之於電商系統的重要性，就像血液之於人體一樣，血液出問題了，人體也就香消玉損了。而基礎數據平臺正如淋巴組織一樣，是重要的造血器官，所以基礎數據平臺的搭建非常重要，不容小覷。
通過前期的梳理，小Q將公司與業務相關的基礎數據進行了彙總，集中設計到基礎數據平臺中進行管理，分別是：
- 商品數據：管理公司售賣的所有產品，以及每一款產品的詳細信息，包括基礎信息、銷售信息、物流信息等。
- 商品分類數據：對商品進行分組管理的類目信息，主要用於前臺搜索、不同業務的區分、以及庫房的區分管理等。在藥品體系中，分為病理分類、藥理分類。
- 客戶數據：管理公司所有發生業務往來的上下游客戶，包含上游採購供應商，以及下游客戶企業。
- 地址庫數據：下單和訂單流轉過程中必不可少的省市區等區域數據，比如客戶下單、訂單分倉庫、物流配送等。
- 公司數據：管理集團下所有發生業務的子公司信息。所有的業務發生都需要有主體，不同公司發生的業務應該分開結算。
- 銷售渠道數據：整合不同的訂單來源渠道，比如自營電商平臺、百度推廣、電視購物、外部合作平臺等等。
- 門店數據：管理新零售業務開展中所有的線下門店，可以是自營門店，也可以是外部合作門店。
- 倉庫數據：管理公司所有開展業務的倉庫數據，此數據主要用作商品的庫存管理、訂單流程和財務結算。
- 物流公司數據：管理承接包裹配送的物流公司和承運商數據，主要用於訂單下發過程中物流公司的調配和配送過程管理。
在需求收集過程中，考慮到藥品行業的特殊性，蘭姐重點強調小Q注意幾點：
- 藥品經營不同於普通電商，存在GSP法規約束，要求供應商和商品必須按照分公司進行首營建檔，故基礎數據平臺在設計時，針對商品和客戶，需支持總部和分公司分別進行首營建碼，但為了統一管理， 還需支持同一商品和供應商，全集團總部和分公司的編碼和信息一致性。
- 在操作層面，大多數情況下，商品和客戶資料由總部首營建碼後，分公司需要時可從總部同步信息過去後再自行完成分公司首營流程；特殊情況下，分公司先行首營，待總部需要時，再從分公司進行同步。
- 若某些商品和客戶僅在分公司需要，則總部無需同步，在分公司創建或修改的商品和客戶數據，僅下發當地分公司對應的倉庫/門店，無需全集團同步。
- 其它基礎數據，均由總部創建完以後集中分發至各分公司系統，分公司僅有享用權，無權自建和修改。
小Q梳理完後的基礎數據管理情況如下：
新零售基礎數據
在系統設計上，整個集團使用一套基礎數據平臺系統，並在商品和供應商管理模塊增加分公司維度的數據權限，總部員工只能管理總部數據，分公司員工只能管理分公司數據，有特殊權限的管理員可以管理所有總部和分公司數據。為減輕維護工作量，總部和分公司數據之間可以相互複製。（傳統ERP的做法是每個公司部署一套獨立系統，系統之間沒有關聯，總部無法統一監控和管理。）
基礎數據平臺賬號權限設計
為了保證整個集團公司數據的一致性，所有外圍系統中的基礎數據，均應由基礎數據平臺統一對外提供服務，當有數據變動時，由基礎數據平臺統一對外發布變更通知並同步至對應的業務系統中。
當然，在實際操作過程中，會有從外圍系統收集修改完數據後，反向同步回基礎數據平臺的情況，比如庫房在作業過程中通過倉儲系統對商品長寬高、體積、重量數據的收集等。
遇此情況，小Q與眾架構師的一致建議是：由倉儲系統同步至基礎數據平臺的集團總部商品庫，再由總部商品庫同步至各分公司商品庫及外圍相關業務系統中。
基礎數據平臺信息同步
另外，基礎數據不能隨意刪除，否則會對歷史業務數據產生影響，所以在設計基礎數據平臺時，基礎數據的刪除功能應做成邏輯刪除（在數據庫中仍然存有記錄，只是狀態變為“已刪除”）。
大的設計原則確定了，再開始細化每一類基礎數據。這麼龐大的基礎數據平臺，優先級該怎麼排？
為了保證項目工期，小Q決定先對相對簡單的基礎數據設計開工，這樣可以更快的出具產出物提交給技術，讓研發工作運轉起來。
二、地址庫基礎數據
地址庫會在很多系統中使用，且各系統之間會存在信息交互。比如電商下單、運營系統中的包郵設置、中央庫存的分倉、配送系統的物流配置等，若各系統中的地址信息不同，業務數據就不能很好的流轉。
小Q從下載了一份國家標準地址庫，並根據公司的業務需要，保留了四級地址（省/直轄市-市-區/縣-鎮/街道），計劃在上線前初始化進基礎數據平臺。
基礎數據平臺中保留了物流部對地址的更新功能：若國家地址庫發生了調整，可在此進行同步調整，調整完成後，由基礎數據平臺將變更信息同步至外圍訂閱地址庫數據的業務系統，保持數據的一致性。
全國四級地址
地址庫常規屬性：地址編號、地址中文名、上級地址、當前第幾級、啟用停用狀態、新增時間、最後修改時間。
系統核心功能：
- 新增地址
- 修改地址信息
- 啟用、停用地址
三、公司信息
由於成立了分公司獨立開展業務，故在基礎數據平臺中需要對所有分公司數據統一管理。
公司數據常規屬性：公司編碼（必須）、公司名稱（必須）、法人、公司地址、公司銀行帳號、稅號、啟用停用狀態、新增時間、最後修改時間
系統核心功能：
- 新增公司
- 修改公司信息
- 啟用、停用公司
四、銷售渠道數據
銷售渠道管理是為了更好的管理公司的業務來源，以便在系統中分類統計和按渠道指定響應營銷策略等，此信息一般由技術部維護即可。訂單在下發時，根據不同的來源在訂單中記錄下渠道信息。
渠道常規屬性：渠道編號、渠道名稱、啟用停用狀態、新增時間、最後修改時間。
系統核心功能：
- 新增渠道
- 修改渠道信息
- 刪除渠道
- 啟用、停用渠道
五、門店數據和倉庫數據
從商品的流向來看，門店和倉庫均是為商品提供進銷存管理的場所；從系統功能上看，門店和倉庫均被當做一個發貨點為訂單提供出庫服務，故門店和倉庫可以放在一套數據中進行管理，用類型加以區分。
在新零售模式下，根據承接的業務形態不同，各倉庫/門店支持的配送方式是不一樣的，例如倉庫一般不支持客戶自提，而門店可支持包裹配送和自提兩種形態。由於面積和設施的差異性，各倉庫/門店支持的物流公司也不一樣，庫房可以支持多家物流公司配送，而門店一般僅支持一到兩家。
門店/倉庫常規屬性：庫房編號、庫房名稱、庫房地址（四級地址+詳細地址）、所屬公司、庫房類型（倉庫 or 門店）、支持的配送方式（配送、自提，支持多選）、支持的物流公司（可多選）、作業起止時間、庫房面積、聯繫地址、聯繫人、聯繫電話、啟用停用狀態、新增時間、最後修改時間。
系統核心功能：
- 新增
- 修改
- 刪除
- 啟用、停用
六、物流公司數據
若為自有物流配送，則只需要維護自有物流信息；若通過第三方承運商承接配送，則需要將所有合作的物流公司基本信息均維護進基礎數據平臺。
因為每個物流公司的網絡覆蓋廣度不同，所以並不是所有的物流公司都可以覆蓋全國地區，故而為了更精準的分配物流，最好能將每個物流公司無法覆蓋的區域維護進來，若技術實力足夠，也可以和物流公司打通接口實現信息同步。
物流公司常規屬性：物流公司編號、物流公司名稱、聯繫人、聯繫電話、無法配送的區域、啟用停用狀態、新增時間、最後修改時間。
系統核心功能：
- 新增物流公司
- 修改物流公司信息
- 刪除物流公司
- 啟用、停用
- 物流不覆蓋區域維護
七、客戶基礎數據管理
客戶分兩類：上游客戶和下游客戶。上游客戶也就是採購供應商，是為公司提供商品供應的上游企業；下游客戶是公司作為供應商為其供應商品的下游客戶。當然，有的供應商既可以是上游客戶，也可以是下游客戶。
應GSP要求，公司要對所有上下游客戶進行首營建檔，針對不符合經營範圍的客戶，不應開展業務往來。
小Q按照GSP要求設計了客戶首營建檔系統流程如下：
客戶首營流程
客戶數據需要按照不同的分公司獨立創建，故需要按公司對客戶數據設置數據權限，總公司採購部、質管部和財務部和分公司採購部、質管部和財務部獨立完成自己所轄範疇下的客戶首營，新增或修改核心屬性後，走完各自的審批流程。
按照不同部門關注和管理的屬性不同，梳理各部門重點關注屬性：
採購/營銷關注屬性 ：合作商名稱、 合作商屬性（商業公司/批發/診所/醫院/藥房…）、聯繫人、聯繫方式、聯繫地址等；
質管關注屬性： 供應商經營範圍（藥品/醫療器械/食品/食品保健/其它）、 合作範圍（不能超過經營範圍）、 法人授權委託書、營業執照和期限以及年檢期限、稅務登記證和期限、經營/醫療許可證和期限、組織機構代碼證和期限、醫療器械許可證和期限、保健食品許可證和期限、質量保證協議和期限、GMP/GSP證書和期限、精神和麻醉許可證和期限、醫療機構許可證和期限；客戶質量體系評價預警日期等。
財務關注屬性：開戶行、開戶名、銀行賬號、稅號、 資信額度、結算方式、賬期等。
其中，針對不同合作範圍的客戶，需要管理的資質略有不同：
- 藥品客戶： 藥品生產（經營）許可證編號、 藥品GSP/GMP證書；
- 醫療器械客戶： 醫療器械生產/經營許可證、 二類醫療器械經營備案證書；
- 食品客戶： 全國工業產品生產許可證、 食品流通許可證；
- 食品保健客戶： 保健食品經營衛生許可證、 保健食品GMP證書。
若供應商即將到期，基礎數據平臺需及時提醒，以下任一證件過期了，採購系統中應 採購禁止單創建，以免出現法律風險：
- 法人授權委託書
- 營業執照有效期
- 組織機構代碼證有效期
- 藥品生產（經營）許可證
- 藥品GSP證書
- 藥品GMP證書
- 醫療器械生產/經營許可證
- 全國工業產品生產許可證
- 食品流通許可證
- 保健食品經營衛生許可證
- 保健食品GMP證書
- 質量保證協議
特別情況下，需要對客戶的經營狀態進行控制，主要包括正常、鎖入、鎖出：
- 正常：無出入庫限制，允許創建採購訂單，也允許銷售出庫
- 鎖入：主要針對上游供應商。不允許向此供應商創建採購訂單，已創建的採購單要求在庫房進行入庫攔截
- 鎖出：主要針對下游發生B2B業務的客戶。不允許對其創建銷售單。已生成的訂單要求在庫房發貨環節攔截
客戶基礎數據系統核心功能：
- 新增客戶信息
- 修改客戶信息
- 刪除客戶信息
- 客戶啟用、停用
- 客戶首營表格打印
忙活了幾個小時，感覺眼睛特別乾澀，小Q逃到樓下抽了根菸放鬆放鬆，順便思考一下基礎數據中最複雜的商品庫的設計思路，正用手機關注著娛樂圈鬧得沸沸揚揚的某明星逃稅事件，突然發現項目組微信群裡有人@自己，點開一看，又好氣又好笑，原來是阿黃髮了一個段子引起了大家的共鳴：
“產品經理失蹤了，程序員第一時間到警察局報警。警察對程序員說：你先冷靜一下，你這樣一直笑沒辦法做筆錄！”
被一眾程序員當眾挑釁，是可忍孰不可忍，趕緊關了新聞滅了菸頭，專心加入到了產品經理和程序員們的口水戰中……
客戶數據梳理完畢，由於篇幅關係，商品及商品分類數據設計放置下一篇文章講解，敬請期待~
若對供應鏈全流程或者小Q的故事感興趣，可參考前序文章：
題圖來自 Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
