一套完整的電商新零售體系包含哪些基礎數據？醫藥基礎數據行業又有哪些特性？接着小Q的故事，為您講述電商新零售基礎數據平台設計攻略。

「 以下故事情節及人物均為作者杜撰，若有雷同，純屬巧合：

小Q：某醫藥互聯網公司後台産品經理，着手規劃重構公司的電商後台及供應鍊相關系統；

蘭姐: 質管部負責人，基礎數據平台的主要需求提出方，精通GSP法規。」

今天開始，小Q要着手梳理基礎數據平台的産品細化方案了，當然準備工作是做充足了的，絕非閉門造車。

除了拉着質管部的蘭姐對GSP（藥品經營質量管理規範）關于藥品和客戶的首營流程聊了個底朝天， 上周末向同樣做産品經理的好哥們阿輝也請教了不少，加上自己在網上的各種深挖，對基礎數據平台的設計已經有了一套完整的思路。

一、基礎數據平台整體設計思想

基礎數據之于電商系統的重要性，就像血液之于人體一樣，血液出問題了，人體也就香消玉損了。而基礎數據平台正如淋巴組織一樣，是重要的造血器官，所以基礎數據平台的搭建非常重要，不容小觑。

通過前期的梳理，小Q将公司與業務相關的基礎數據進行了彙總，集中設計到基礎數據平台中進行管理，分别是：

• 商品數據：管理公司售賣的所有産品，以及每一款産品的詳細信息，包括基礎信息、銷售信息、物流信息等。
• 商品分類數據：對商品進行分組管理的類目信息，主要用于前台搜索、不同業務的區分、以及庫房的區分管理等。在藥品體系中，分為病理分類、藥理分類。
• 客戶數據：管理公司所有發生業務往來的上下遊客戶，包含上遊采購供應商，以及下遊客戶企業。
• 地址庫數據：下單和訂單流轉過程中必不可少的省市區等區域數據，比如客戶下單、訂單分倉庫、物流配送等。
• 公司數據：管理集團下所有發生業務的子公司信息。所有的業務發生都需要有主體，不同公司發生的業務應該分開結算。
• 銷售渠道數據：整合不同的訂單來源渠道，比如自營電商平台、百度推廣、電視購物、外部合作平台等等。
• 門店數據：管理新零售業務開展中所有的線下門店，可以是自營門店，也可以是外部合作門店。
• 倉庫數據：管理公司所有開展業務的倉庫數據，此數據主要用作商品的庫存管理、訂單流程和财務結算。
• 物流公司數據：管理承接包裹配送的物流公司和承運商數據，主要用于訂單下發過程中物流公司的調配和配送過程管理。

在需求收集過程中，考慮到藥品行業的特殊性，蘭姐重點強調小Q注意幾點：

1. 藥品經營不同于普通電商，存在GSP法規約束，要求供應商和商品必須按照分公司進行首營建檔，故基礎數據平台在設計時，針對商品和客戶，需支持總部和分公司分别進行首營建碼，但為了統一管理， 還需支持同一商品和供應商，全集團總部和分公司的編碼和信息一緻性。
2. 在操作層面，大多數情況下，商品和客戶資料由總部首營建碼後，分公司需要時可從總部同步信息過去後再自行完成分公司首營流程；特殊情況下，分公司先行首營，待總部需要時，再從分公司進行同步。
3. 若某些商品和客戶僅在分公司需要，則總部無需同步，在分公司創建或修改的商品和客戶數據，僅下發當地分公司對應的倉庫/門店，無需全集團同步。
4. 其它基礎數據，均由總部創建完以後集中分發至各分公司系統，分公司僅有享用權，無權自建和修改。

小Q梳理完後的基礎數據管理情況如下：

新零售基礎數據

在系統設計上，整個集團使用一套基礎數據平台系統，并在商品和供應商管理模塊增加分公司維度的數據權限，總部員工隻能管理總部數據，分公司員工隻能管理分公司數據，有特殊權限的管理員可以管理所有總部和分公司數據。為減輕維護工作量，總部和分公司數據之間可以相互複制。（傳統ERP的做法是每個公司部署一套獨立系統，系統之間沒有關聯，總部無法統一監控和管理。）

基礎數據平台賬号權限設計

為了保證整個集團公司數據的一緻性，所有外圍系統中的基礎數據，均應由基礎數據平台統一對外提供服務，當有數據變動時，由基礎數據平台統一對外發布變更通知并同步至對應的業務系統中。

當然，在實際操作過程中，會有從外圍系統收集修改完數據後，反向同步回基礎數據平台的情況，比如庫房在作業過程中通過倉儲系統對商品長寬高、體積、重量數據的收集等。

遇此情況，小Q與衆架構師的一緻建議是：由倉儲系統同步至基礎數據平台的集團總部商品庫，再由總部商品庫同步至各分公司商品庫及外圍相關業務系統中。

基礎數據平台信息同步

另外，基礎數據不能随意删除，否則會對曆史業務數據産生影響，所以在設計基礎數據平台時，基礎數據的删除功能應做成邏輯删除（在數據庫中仍然存有記錄，隻是狀态變為“已删除”）。

大的設計原則确定了，再開始細化每一類基礎數據。這麼龐大的基礎數據平台，優先級該怎麼排？

為了保證項目工期，小Q決定先對相對簡單的基礎數據設計開工，這樣可以更快的出具産出物提交給技術，讓研發工作運轉起來。

二、地址庫基礎數據

地址庫會在很多系統中使用，且各系統之間會存在信息交互。比如電商下單、運營系統中的包郵設置、中央庫存的分倉、配送系統的物流配置等，若各系統中的地址信息不同，業務數據就不能很好的流轉。

小Q從下載了一份國家标準地址庫，并根據公司的業務需要，保留了四級地址（省/直轄市-市-區/縣-鎮/街道），計劃在上線前初始化進基礎數據平台。

基礎數據平台中保留了物流部對地址的更新功能：若國家地址庫發生了調整，可在此進行同步調整，調整完成後，由基礎數據平台将變更信息同步至外圍訂閱地址庫數據的業務系統，保持數據的一緻性。

全國四級地址

地址庫常規屬性：地址編号、地址中文名、上級地址、當前第幾級、啟用停用狀态、新增時間、最後修改時間。

系統核心功能：

• 新增地址
• 修改地址信息
• 啟用、停用地址

三、公司信息

由于成立了分公司獨立開展業務，故在基礎數據平台中需要對所有分公司數據統一管理。

公司數據常規屬性：公司編碼（必須）、公司名稱（必須）、法人、公司地址、公司銀行帳号、稅号、啟用停用狀态、新增時間、最後修改時間

系統核心功能：

• 新增公司
• 修改公司信息
• 啟用、停用公司

四、銷售渠道數據

銷售渠道管理是為了更好的管理公司的業務來源，以便在系統中分類統計和按渠道指定響應營銷策略等，此信息一般由技術部維護即可。訂單在下發時，根據不同的來源在訂單中記錄下渠道信息。

渠道常規屬性：渠道編号、渠道名稱、啟用停用狀态、新增時間、最後修改時間。

系統核心功能：

• 新增渠道
• 修改渠道信息
• 删除渠道
• 啟用、停用渠道

五、門店數據和倉庫數據

從商品的流向來看，門店和倉庫均是為商品提供進銷存管理的場所；從系統功能上看，門店和倉庫均被當做一個發貨點為訂單提供出庫服務，故門店和倉庫可以放在一套數據中進行管理，用類型加以區分。

在新零售模式下，根據承接的業務形态不同，各倉庫/門店支持的配送方式是不一樣的，例如倉庫一般不支持客戶自提，而門店可支持包裹配送和自提兩種形态。由于面積和設施的差異性，各倉庫/門店支持的物流公司也不一樣，庫房可以支持多家物流公司配送，而門店一般僅支持一到兩家。

門店/倉庫常規屬性：庫房編号、庫房名稱、庫房地址（四級地址 詳細地址）、所屬公司、庫房類型（倉庫 or 門店）、支持的配送方式（配送、自提，支持多選）、支持的物流公司（可多選）、作業起止時間、庫房面積、聯系地址、聯系人、聯系電話、啟用停用狀态、新增時間、最後修改時間。

系統核心功能：

• 新增
• 修改
• 删除
• 啟用、停用

六、物流公司數據

若為自有物流配送，則隻需要維護自有物流信息；若通過第三方承運商承接配送，則需要将所有合作的物流公司基本信息均維護進基礎數據平台。

因為每個物流公司的網絡覆蓋廣度不同，所以并不是所有的物流公司都可以覆蓋全國地區，故而為了更精準的分配物流，最好能将每個物流公司無法覆蓋的區域維護進來，若技術實力足夠，也可以和物流公司打通接口實現信息同步。

物流公司常規屬性：物流公司編号、物流公司名稱、聯系人、聯系電話、無法配送的區域、啟用停用狀态、新增時間、最後修改時間。

系統核心功能：

• 新增物流公司
• 修改物流公司信息
• 删除物流公司
• 啟用、停用
• 物流不覆蓋區域維護

七、客戶基礎數據管理

客戶分兩類：上遊客戶和下遊客戶。上遊客戶也就是采購供應商，是為公司提供商品供應的上遊企業；下遊客戶是公司作為供應商為其供應商品的下遊客戶。當然，有的供應商既可以是上遊客戶，也可以是下遊客戶。

應GSP要求，公司要對所有上下遊客戶進行首營建檔，針對不符合經營範圍的客戶，不應開展業務往來。

小Q按照GSP要求設計了客戶首營建檔系統流程如下：

客戶首營流程

客戶數據需要按照不同的分公司獨立創建，故需要按公司對客戶數據設置數據權限，總公司采購部、質管部和财務部和分公司采購部、質管部和财務部獨立完成自己所轄範疇下的客戶首營，新增或修改核心屬性後，走完各自的審批流程。

按照不同部門關注和管理的屬性不同，梳理各部門重點關注屬性：

采購/營銷關注屬性：合作商名稱、 合作商屬性（商業公司/批發/診所/醫院/藥房…）、聯系人、聯系方式、聯系地址等；

質管關注屬性： 供應商經營範圍（藥品/醫療器械/食品/食品保健/其它）、 合作範圍（不能超過經營範圍）、 法人授權委托書、營業執照和期限以及年檢期限、稅務登記證和期限、經營/醫療許可證和期限、組織機構代碼證和期限、醫療器械許可證和期限、保健食品許可證和期限、質量保證協議和期限、GMP/GSP證書和期限、精神和麻醉許可證和期限、醫療機構許可證和期限；客戶質量體系評價預警日期等。

财務關注屬性：開戶行、開戶名、銀行賬号、稅号、 資信額度、結算方式、賬期等。

其中，針對不同合作範圍的客戶，需要管理的資質略有不同：

1. 藥品客戶： 藥品生産（經營）許可證編号、 藥品GSP/GMP證書；
2. 醫療器械客戶： 醫療器械生産/經營許可證、 二類醫療器械經營備案證書；
3. 食品客戶： 全國工業産品生産許可證、 食品流通許可證；
4. 食品保健客戶： 保健食品經營衛生許可證、 保健食品GMP證書。

若供應商即将到期，基礎數據平台需及時提醒，以下任一證件過期了，采購系統中應 采購禁止單創建，以免出現法律風險：

1. 法人授權委托書
2. 營業執照有效期
3. 組織機構代碼證有效期
4. 藥品生産（經營）許可證
5. 藥品GSP證書
6. 藥品GMP證書
7. 醫療器械生産/經營許可證
8. 全國工業産品生産許可證
9. 食品流通許可證
10. 保健食品經營衛生許可證
11. 保健食品GMP證書
12. 質量保證協議

特别情況下，需要對客戶的經營狀态進行控制，主要包括正常、鎖入、鎖出：

1. 正常：無出入庫限制，允許創建采購訂單，也允許銷售出庫
2. 鎖入：主要針對上遊供應商。不允許向此供應商創建采購訂單，已創建的采購單要求在庫房進行入庫攔截
3. 鎖出：主要針對下遊發生B2B業務的客戶。不允許對其創建銷售單。已生成的訂單要求在庫房發貨環節攔截

客戶基礎數據系統核心功能：

• 新增客戶信息
• 修改客戶信息
• 删除客戶信息
• 客戶啟用、停用
• 客戶首營表格打印

忙活了幾個小時，感覺眼睛特别幹澀，小Q逃到樓下抽了根煙放松放松，順便思考一下基礎數據中最複雜的商品庫的設計思路，正用手機關注着娛樂圈鬧得沸沸揚揚的某明星逃稅事件，突然發現項目組微信群裡有人@自己，點開一看，又好氣又好笑，原來是阿黃發了一個段子引起了大家的共鳴：

“産品經理失蹤了，程序員第一時間到警察局報警。警察對程序員說：你先冷靜一下，你這樣一直笑沒辦法做筆錄！”

被一衆程序員當衆挑釁，是可忍孰不可忍，趕緊關了新聞滅了煙頭，專心加入到了産品經理和程序員們的口水戰中……

客戶數據梳理完畢，由于篇幅關系，商品及商品分類數據設計放置下一篇文章講解，敬請期待~

若對供應鍊全流程或者小Q的故事感興趣，可參考前序文章：

作者：木筆，産品一俗生，深耕于供應鍊領域，公衆号：供應鍊産品筆記

本文由 @木筆 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部