设为首页加入收藏
设计攻略:电商新零售基础数据平台 (来源:环亚娱乐app)
作者:环亚娱乐app    发布于:2020-06-08 18:33    文字:【】【】【


     

  一套完整的电商新零售体系包含哪些基础数据?医药基础数据行业又有哪些特性?接着小Q的故事,为您讲述电商新零售基础数据平台设计攻略。

  今天开始,小Q要着手梳理基础数据平台的产品细化方案了,当然准备工作是做充足了的,绝非闭门造车。

  除了拉着质管部的兰姐对GSP(药品经营质量管理规范)关于药品和客户的首营流程聊了个底朝天, 上周末向同样做产品经理的好哥们阿辉也请教了不少,加上自己在网上的各种深挖,对基础数据平台的设计已经有了一套完整的思路。

  基础数据之于电商系统的重要性,就像血液之于人体一样,血液出问题了,人体也就香消玉损了。而基础数据平台正如淋巴组织一样,是重要的造血器官,所以基础数据平台的搭建非常重要,不容小觑。

  通过前期的梳理,小Q将公司与业务相关的基础数据进行了汇总,集中设计到基础数据平台中进行管理,分别是:

  商品数据:管理公司售卖的所有产品,以及每一款产品的详细信息,包括基础信息、销售信息、物流信息等。

  商品分类数据:对商品进行分组管理的类目信息,主要用于前台搜索、不同业务的区分、以及库房的区分管理等。在药品体系中,分为病理分类、药理分类。

  地址库数据:下单和订单流转过程中必不可少的省市区等区域数据,比如客户下单、订单分仓库、物流配送等。

  公司数据:管理集团下所有发生业务的子公司信息。所有的业务发生都需要有主体,不同公司发生的业务应该分开结算。

  销售渠道数据:整合不同的订单来源渠道,比如自营电商平台、百度推广、电视购物、外部合作平台等等。

  仓库数据:管理公司所有开展业务的仓库数据,此数据主要用作商品的库存管理、订单流程和财务结算。

  物流公司数据:管理承接包裹配送的物流公司和承运商数据,主要用于订单下发过程中物流公司的调配和配送过程管理。

  药品经营不同于普通电商,存在GSP法规约束,要求供应商和商品必须按照分公司进行首营建档,故基础数据平台在设计时,针对商品和客户,需支持总部和分公司分别进行首营建码,但为了统一管理, 还需支持同一商品和供应商,全集团总部和分公司的编码和信息一致性。

  在操作层面,大多数情况下,商品和客户资料由总部首营建码后,分公司需要时可从总部同步信息过去后再自行完成分公司首营流程;特殊情况下,分公司先行首营,待总部需要时,再从分公司进行同步。

  若某些商品和客户仅在分公司需要,则总部无需同步,在分公司创建或修改的商品和客户数据,仅下发当地分公司对应的仓库/门店,无需全集团同步。

  其它基础数据,均由总部创建完以后集中分发至各分公司系统,分公司仅有享用权,无权自建和修改。

  在系统设计上,整个集团使用一套基础数据平台系统,并在商品和供应商管理模块增加分公司维度的数据权限,总部员工只能管理总部数据,分公司员工只能管理分公司数据,有特殊权限的管理员可以管理所有总部和分公司数据。为减轻维护工作量,总部和分公司数据之间可以相互复制。(传统ERP的做法是每个公司部署一套独立系统,系统之间没有关联,总部无法统一监控和管理。)

  为了保证整个集团公司数据的一致性,所有外围系统中的基础数据,均应由基础数据平台统一对外提供服务,当有数据变动时,由基础数据平台统一对外发布变更通知并同步至对应的业务系统中。

  当然,在实际操作过程中,会有从外围系统收集修改完数据后,反向同步回基础数据平台的情况,比如库房在作业过程中通过仓储系统对商品长宽高、体积、重量数据的收集等。

  遇此情况,小Q与众架构师的一致建议是:由仓储系统同步至基础数据平台的集团总部商品库,再由总部商品库同步至各分公司商品库及外围相关业务系统中。

  另外,基础数据不能随意删除,否则会对历史业务数据产生影响,所以在设计基础数据平台时,基础数据的删除功能应做成逻辑删除(在数据库中仍然存有记录,只是状态变为“已删除”)。

  为了保证项目工期,小Q决定先对相对简单的基础数据设计开工,这样可以更快的出具产出物提交给技术,让研发工作运转起来。

  地址库会在很多系统中使用,且各系统之间会存在信息交互。比如电商下单、运营系统中的包邮设置、中央库存的分仓、配送系统的物流配置等,若各系统中的地址信息不同,业务数据就不能很好的流转。

  小Q从下载了一份国家标准地址库,并根据公司的业务需要,保留了四级地址(省/直辖市-市-区/县-镇/街道),计划在上线前初始化进基础数据平台。

  基础数据平台中保留了物流部对地址的更新功能:若国家地址库发生了调整,可在此进行同步调整,调整完成后,由基础数据平台将变更信息同步至外围订阅地址库数据的业务系统,保持数据的一致性。

  地址库常规属性:地址编号、地址中文名、上级地址、当前第几级、启用停用状态、新增时间、最后修改时间。

  公司数据常规属性:公司编码(必须)、公司名称(必须)、法人、公司地址、公司银行帐号、税号、启用停用状态、新增时间、最后修改时间

  销售渠道管理是为了更好的管理公司的业务来源,以便在系统中分类统计和按渠道指定响应营销策略等,此信息一般由技术部维护即可。订单在下发时,根据不同的来源在订单中记录下渠道信息。

  从商品的流向来看,门店和仓库均是为商品提供进销存管理的场所;从系统功能上看,门店和仓库均被当做一个发货点为订单提供出库服务,故门店和仓库可以放在一套数据中进行管理,用类型加以区分。

  在新零售模式下,根据承接的业务形态不同,各仓库/门店支持的配送方式是不一样的,例如仓库一般不支持客户自提,而门店可支持包裹配送和自提两种形态。由于面积和设施的差异性,各仓库/门店支持的物流公司也不一样,库房可以支持多家物流公司配送,而门店一般仅支持一到两家。

  门店/仓库常规属性:库房编号、库房名称、库房地址(四级地址+详细地址)、所属公司、库房类型(仓库 or 门店)、支持的配送方式(配送、自提,支持多选)、支持的物流公司(可多选)、作业起止时间、库房面积、联系地址、联系人、联系电话、启用停用状态、新增时间、最后修改时间。

  若为自有物流配送,则只需要维护自有物流信息;若通过第三方承运商承接配送,则需要将所有合作的物流公司基本信息均维护进基础数据平台。

  因为每个物流公司的网络覆盖广度不同,所以并不是所有的物流公司都可以覆盖全国地区,故而为了更精准的分配物流,最好能将每个物流公司无法覆盖的区域维护进来,若技术实力足够,也可以和物流公司打通接口实现信息同步。

  物流公司常规属性:物流公司编号、物流公司名称、联系人、联系电话、无法配送的区域、启用停用状态、新增时间、最后修改时间。

  客户分两类:上游客户和下游客户。上游客户也就是采购供应商,是为公司提供商品供应的上游企业;下游客户是公司作为供应商为其供应商品的下游客户。当然,有的供应商既可以是上游客户,也可以是下游客户。

  应GSP要求,公司要对所有上下游客户进行首营建档,针对不符合经营范围的客户,不应开展业务往来。

  客户数据需要按照不同的分公司独立创建,故需要按公司对客户数据设置数据权限,总公司采购部、质管部和财务部和分公司采购部、质管部和财务部独立完成自己所辖范畴下的客户首营,新增或修改核心属性后,走完各自的审批流程。

  采购/营销关注属性:合作商名称、 合作商属性(商业公司/批发/诊所/医院/药房)、联系人、联系方式、联系地址等;

  质管关注属性: 供应商经营范围(药品/医疗器械/食品/食品保健/其它)、 合作范围(不能超过经营范围)、 法人授权委托书、营业执照和期限以及年检期限、税务登记证和期限、经营/医疗许可证和期限、组织机构代码证和期限、医疗器械许可证和期限、保健食品许可证和期限、质量保证协议和期限、GMP/GSP证书和期限、精神和麻醉许可证和期限、医疗机构许可证和期限;客户质量体系评价预警日期等。

  若供应商即将到期,基础数据平台需及时提醒,以下任一证件过期了,采购系统中应 采购禁止单创建,以免出现法律风险:

  忙活了几个小时,感觉眼睛特别干涩,小Q逃到楼下抽了根烟放松放松,顺便思考一下基础数据中最复杂的商品库的设计思路,正用手机关注着娱乐圈闹得沸沸扬扬的某明星逃税事件,突然发现项目组微信群里有人@自己,点开一看,又好气又好笑,原来是阿黄发了一个段子引起了大家的共鸣:

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

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

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。


脚注信息
版权所有 Copyright(C)2009-2015 环亚娱乐app(上海)实业有限责任公司