是什么在支撐著你每天心甘情愿早起晚睡？

    是什么在促使你奮力擠進地鐵在人海中掙扎？

    是什么在強迫你義無反顧的投身工作毫無怨言？

    是什么讓你忍受千般委屈還對老板不離不棄？

    是責任嗎？

    是夢想嗎？

    是信念嗎？

    No，是窮啊......  

        早上8:30的辦公室，還沒多少人到崗，和上班期間的熙熙攘攘相比，顯得格外清靜。人的惰性是個很神奇的病種，符合簡諧運動原理，會讓你的意志一點點被侵蝕，直到到崗時間無限接近于上班點。所以一般離公司越近的人起的越晚，到公司也經常卡點，縱觀公司前幾名到崗的員工，大多數是住的比較遠的，比如小Q。

        今天開始，小Q要著手梳理基礎數據平臺的產品細化方案了，當然準備工作是做充足了的，絕非閉門造車。除了拉著質管部的蘭姐對GSP（藥品經營質量管理規范）關于藥品和客戶的首營流程聊了個底朝天， 上周末向同樣做產品經理的好哥們阿輝也請教了不少，加上自己在網上的各種深挖，對基礎數據平臺的設計已經有了一套完整的思路。

01 基礎數據平臺整體設計思想

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

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

• 商品數據：管理公司售賣的所有產品，以及每一款產品的詳細信息，包括基礎信息、銷售信息、物流信息等。

• 商品分類數據：對商品進行分組管理的類目信息，主要用于前臺搜索、不同業務的區分、以及庫房的區分管理等。在藥品體系中，分為病理分類、藥理分類。

• 客戶數據：管理公司所有發生業務往來的上下游客戶，包含上游采購供應商，以及下游客戶企業。

• 地址庫數據：下單和訂單流轉過程中必不可少的省市區等區域數據，比如客戶下單、訂單分倉庫、物流配送等。

• 公司數據：管理集團下所有發生業務的子公司信息。所有的業務發生都需要有主體，不同公司發生的業務應該分開結算。

• 銷售渠道數據：整合不同的訂單來源渠道，比如自營電商平臺、百度推廣、電視購物、外部合作平臺等等。

• 門店數據：管理新零售業務開展中所有的線下門店，可以是自營門店，也可以是外部合作門店。

• 倉庫數據：管理公司所有開展業務的倉庫數據，此數據主要用作商品的庫存管理、訂單流程和財務結算。

• 物流公司數據：管理承接包裹配送的物流公司和承運商數據，主要用于訂單下發過程中物流公司的調配和配送過程管理。

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

     （1）藥品經營不同于普通電商，存在GSP法規約束，要求供應商和商品必須按照分公司進行首營建檔，故基礎數據平臺在設計時，針對商品和客戶，需支持總部和分公司分別進行首營建碼，但為了統一管理， 還需支持同一商品和供應商，全集團總部和分公司的編碼和信息一致性。  

     （2）在操作層面，大多數情況下，商品和客戶資料由總部首營建碼后，分公司需要時可從總部同步信息過去后再自行完成分公司首營流程；特殊情況下，分公司先行首營，待總部需要時，再從分公司進行同步。

      若某些商品和客戶僅在分公司需要，則總部無需同步，在分公司創建或修改的商品和客戶數據，僅下發當地分公司對應的倉庫/門店，無需全集團同步。

    （3） 其它基礎數據，均由總部創建完以后集中分發至各分公司系統，分公司僅有享用權，無權自建和修改。

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

▲新零售基礎數據

        在系統設計上，整個集團使用一套基礎數據平臺系統，并在商品和供應商管理模塊增加分公司維度的數據權限，總部員工只能管理總部數據，分公司員工只能管理分公司數據，有特殊權限的管理員可以管理所有總部和分公司數據。為減輕維護工作量，總部和分公司數據之間可以相互復制。

    （傳統ERP的做法是每個公司部署一套獨立系統，系統之間沒有關聯，總部無法統一監控和管理。）

▲基礎數據平臺賬號權限設計

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

        當然，在實際操作過程中，會有從外圍系統收集修改完數據后，反向同步回基礎數據平臺的情況，比如庫房在作業過程中通過倉儲系統對商品長寬高、體積、重量數據的收集等。遇此情況，小Q與眾架構師的一致建議是，由倉儲系統同步至基礎數據平臺的集團總部商品庫，再由總部商品庫同步至各分公司商品庫及外圍相關業務系統中：

▲基礎數據平臺信息同步

        另外，基礎數據不能隨意刪除，否則會對歷史業務數據產生影響，所以在設計基礎數據平臺時，基礎數據的刪除功能應做成邏輯刪除（在數據庫中仍然存有記錄，只是狀態變為“已刪除”）。

         大的設計原則確定了，再開始細化每一類基礎數據。這么龐大的基礎數據平臺，優先級該怎么排？為了保證項目工期，小Q決定先對相對簡單的基礎數據設計開工，這樣可以更快的出具產出物提交給技術，讓研發工作運轉起來。

02  地址庫基礎數據

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

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

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

▲全國四級地址庫

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

    系統核心功能：

• 【新增地址】

• 【修改地址信息】

• 【啟用、停用地址】

03 公司信息

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

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

       系統核心功能：

• 【新增公司】

• 【修改公司信息】

• 【啟用、停用公司】

04 銷售渠道數據

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

      渠道常規屬性：渠道編號、渠道名稱、啟用停用狀態、新增時間、最后修改時間。

      系統核心功能：

• 【新增渠道】

• 【修改渠道信息】

• 【刪除渠道】

• 【啟用、停用渠道】

05 門店數據和倉庫數據

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

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

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

      系統核心功能：

• 【新增】

• 【修改】

• 【刪除】

• 【啟用、停用】

06 物流公司數據

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

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

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

       系統核心功能：

• 【新增物流公司】

• 【修改物流公司信息】

• 【刪除物流公司】

• 【啟用、停用】

• 【物流不覆蓋區域維護】

 07 客戶基礎數據管理

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

        應GSP要求，公司要對所有上下游客戶進行首營建檔，針對不符合經營范圍的客戶，不應開展業務往來。小Q按照GSP要求設計了客戶首營建檔系統流程如下：

▲客戶首營流程

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

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

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

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

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

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

• 藥品客戶： 藥品生產（經營）許可證編號、 藥品GSP/GMP證書；

• 醫療器械客戶： 醫療器械生產/經營許可證、 二類醫療器械經營備案證書；

• 食品客戶： 全國工業產品生產許可證、 食品流通許可證；

• 食品保健客戶： 保健食品經營衛生許可證、 保健食品GMP證書。

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

      ①法人授權委托書；②營業執照有效期；③組織機構代碼證有效期；④藥品生產（經營）許可證；⑤藥品GSP證書；⑥藥品GMP證書；⑦醫療器械生產/經營許可證；⑧全國工業產品生產許可證；⑨食品流通許可證；⑩保健食品經營衛生許可證；保健食品GMP證書； 質量保證協議

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

• 正常：無出入庫限制，允許創建采購訂單，也允許銷售出庫；

• 鎖入：主要針對上游供應商。不允許向此供應商創建采購訂單，已創建的采購單要求在庫房進行入庫攔截；

• 鎖出：主要針對下游發生B2B業務的客戶。不允許對其創建銷售單。已生成的訂單要求在庫房發貨環節攔截；

系統核心功能：

• 【新增客戶信息】

• 【修改客戶信息】

• 【刪除客戶信息】

• 【客戶啟用、停用】

• 【客戶首營表格打印】

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

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

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

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