医药电商新零售基础数据平台设计攻略

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

    是什么在促使你奋力挤进地铁在人海中挣扎？

    是什么在强迫你义无反顾的投身工作毫无怨言？

    是什么让你忍受千般委屈还对老板不离不弃？

    是责任吗？

    是梦想吗？

    是信念吗？

    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逃到楼下抽了根烟放松放松，顺便思考一下基础数据中最复杂的商品库的设计思路，正用手机关注着娱乐圈闹得沸沸扬扬的某明星逃税事件，突然发现项目组微信群里有人@自己，点开一看，又好气又好笑，原来是阿黄发了一个段子引起了大家的共鸣：

       “产品经理失踪了 程序员第一时间到警察局报警。警察对程序员说：你先冷静一下，你这样一直笑没办法做笔录！”

       被一众程序员当众挑衅，是可忍孰不可忍，赶紧关了新闻灭了烟头，专心加入到了产品经理和程序员们的口水战中......