专业好文：医药电商平台的商品设计

时间：2023-03-28 04:22:01 | 来源：电子商务

时间：2023-03-28 04:22:01 来源：电子商务

随着互联网的兴起以及网络技术的不断发展，传统医药与先进互联网技术相结合的医药贸易活动全过程电子化在全球已经成为大势所趋。为此，国家食品药品监督管理局分别在2004年和2005年发布了专门针对医药电子商务的《互联网药品信息服务管理办法》和《互联网药品交易服务审批暂行规定》，在医药市场竞争激烈的今天，网上药品交易的合法化给企业营销打开了新的市场通路。

医药电子商务平台是独立于买卖双方的中立服务组织，为买卖双方提供交易所需的各种服务的数字化平台，即提供药品信息发布、在线采购、在线交易、在线支付、药品跟踪、配合地面仓储和物流等医药流通全程服务，是实现信息流、资金流、物流高度协同的完整的医药电子商务服务模式，是公开、公平、公正的网上医药交易市场。

电商买药已经成为我们居民生活不可或缺的一部分， 但是很多人其实不知道， 咱们医药电商平台的打造， 就跟普通电商平台有本质的差别：

一、为什么先从商品模块开始讲而不是先讲整个系统的设计呢？

1. 从产品设计角度，相对于医药电商平台，我们的普通电商平台有三大特点

l 商品数据结构的不同，普通电商数据结构不能满足医药行业的特殊要求。所以医药电商的结构必须单独做出合适医药电商的商品设计。

l 订单流程非处方药基本跟普通的电商或者020流程没有很大的区别， 而处方药需要医师审核这么个流程基本上已经有成熟的解决方案，作为电商平台只是需要对接这些平台便可以完成审核动作。

l 支付方式除了我们正常电商的支付还会考虑到医保卡支付的问题， 而这个问题也是对接能够解决的，所以我们其实不需要细细展开去讲。

2. 从运营角度，医药公司未来希望可以提供给不同的系统平台进行对接，（包括资讯社区、问答社区、疾病库等等），作为自身的专业数据库建立自己的药品库。

二、重新搭建商品数据表结构

1. 取消“自定义SKU”机制，针对标准化类目建立标准产品与商品的强制关联关系；

2. 将基础产品库与商品库从结构上进行分离，并建立基础库和商品库中的各层商品基础信息映射关系，日后基础产品库会作为打通其他横向产品业务的公共库，而商品库则主要给到电商平台使用。

三、建立符合医药平台的商品发布机制

1. 在商品发布时，允许商家申请新增基础产品、允许商家修改基础产品信息提交审核，审核通过后基础产品信息自动入库；

2. 将商品发布与基础产品数据维护整合在一起，引入商家角色维护基础信息，节省内部维护人手。

四、新增多维度规格机制

如下图，增加“类型”与“通用规格”的逻辑，与类目关联，为同类型的商品增加多维度规格的维护。

五、优化用户体验

1. 优化各页面各功能的SQL查询，提升加载速度

2. 优化页面结构与界面UI设计

六、优化商品系统结构

系统级的设计从大到细一般分为四个层次，一般从我们平时做产品设计的时候，可能会比较多在#3和#4上，而如果培养自己习惯从#1和#2层开始去思考这个功能和界面的设计，往往设计出来的功能可执行性会更高，与程序猿撕逼的机会会更低：

1. 该系统与外部其他系统的关系（如何协作、功能边界）

2. 系统内底层数据库结构设计

3. 系统内应用功能逻辑

4. 系统内各界面层建设

（一）系统结构设计

一般的电商系统可以拆成好几块主要业务。订单、用户、商品、促销等等，对于第三方平台系统来说还有商家。一般的系统是按端来拆分的，像文章开始说的，PC端、移动端、平台后台、商家后台。各个端的逻辑是自己管自己的，所以从代码的层面每一个端都会有一套相对独立的订单、用户、商品、促销逻辑。这样子就会造成说，由于各种原因导致PC和移动端的处理逻辑可能不统一，不同模块之间的耦合度高，例如可能改一下商品的显示逻辑，可能会影响订单的和用户的，加大问题定位的难度。但是我们朗尊采用的是模块化系统的方案。优势是更加灵活、拓展性强，逻辑相对各模块独立对于问题的定位也更精准（尤其是以后有中台设计）。

我们设计是会充分考虑到商品结构首先先服务与医药电商的平台， 同时也考虑到日后其他第三方需要对接时的处理方式。（如下图）

（二）数据库底层设计

很多人说系统的设计归根到底就是管数据的，建立功能和逻辑来去管控这些数据的流转以及储存。这样的说法虽然片面，但也不无道理。建立一套系统，其实搞清楚其数据库表结构，就相当于搞清楚了它所管理的“对象”还有“对象和对象之间的关系”，这对于后续的功能设计是非常重要的。

关于数据库底层结构很多产品经理会觉得这是开发经理和架构师所需要沟通和建立的事情，产品经理主要还是在业务逻辑和界面上来策划，这也没有错，但是为了更好地掌控开发出来的系统质量，产品经理参与到数据库表结构建设的工作来会更好，下面几张图是我基于产品逻辑上的理解对各种商品管理系统中涉及到的“对象”和“对象与对象之间的关系”而制作的图表。其实这些图表均不复杂也不“技术”，是产品经理力所能及的事情，但很有助于开发以及测试还有各方干系人更好地理解系统，这样后面设计出来的功能逻辑和界面也会更加清晰。

（三）功能逻辑结构

一般的第三方平台型的商品管理系统都会有几个固定模块，商品发布、商品管理、商品上下架、商品审核，这几块的流程以及管理功能都是商品管理系统所必须的。而由于医药类目的商品都是属于高度标准化的商品，而且对于信息准确性的要求非常高，市场上的所有药品、医疗器械、保健食品、化妆品等都必须在中国国家食品药品监督管理局登记在册，而且对于该类商品而言，有规范化的参数与标准，包括批准文号、通用名称、功能主治等所有信息都以在国家药监局注册的为准，所以我们在设计商品管理系统的时候需要建立产品库，并与商品库分开，另外在工作流上需要将产品库的信息标准掌握在平台管理员手中，而限制商家修改这部分信息的权限。

在功能逻辑这一层，除了考虑到功能点之外，也需要考虑到工作流，每一项功能的工作流，什么角色在什么权限下能够做什么样的操作，需要做怎么样的判断，判断正确和判断错误分别会进行什么样的操作和提示什么样的信息，这样的流程会让项目里的所有人（包括开发、测试、业务方）都能清晰每一件事情的走向，也对产品经理在后续检验自己的策划是否有错误，也对后续项目上线后的验收或者使用有很大的帮助。

一般商品管理系统的流程主要是发布商品、审核商品、上下架的规则判断等，而在我们的医药系统设计上，还会加入基础产品信息发布和维护，以及因为基础产品信息维护而影响商品状态的流程和同能。这一点大家可以根据自身的平台需求来进行设计。在流程上标识好每一个节点即可。

台管理系统的设计上除了功能和界面之外，权限流、工作流和日志流也是非常重要的，但这往往我们在设计后台功能的时候会忽略，尤其是经验不足的时候。在项目策划时期，尽量把每一个场景、每一个数据、每一句的提示都覆盖到，把需求做细做精，其实是能够节省大量在项目中期撕逼的情况（虽然还是免不了要撕逼，:）。下图是当时做的原型文件中的页面：

七、看不见的需求

除了以上看得见的需求之外，还有一部分需求是看不见的。

1. 上文讲到的权限管理。作为后台管理系统，用户角色权限系统管理都是必要的功能模块。由于要兼顾旧有平台的使用，以及避免要管理两套用户权限，所以这一期商品管理系统的权限管理是直接使用接口的方式跟旧有平台进行同步。

2. 上文讲到的日志管理。要是并没有考虑到日志操作管理，导致我们在后面遇到因为数据同步还有程序出现问题的时候，我们没有办法非常有效和及时地定位出问题。日志操作管理是为了方便管理和跟踪业务处理过程，并依据业务系统使用活动过程记录的信息，分析系统的使用情况、存在问题和对任意业务处理的过程追踪管理。而如果一开始忘了，后面要补可能是一个相对复杂的过程。

3. 商家ERP接口对接。 由于医药集团一般都会采用ERP 去处理订单，所以我们系统会做好标准的Open API， 以方便对接。

八、界面应用层设计

界面应用层的设计是大部分产品经理每天都做的工作了，主要需要考虑到的就是用户体验方面的功能。这次的商品管理系统，界面只有后台界面，用户分别是平台各部门的同事以及商家。我认为后台系统的界面或者说用户体验是否好，主要考察的是两点，提高效率，降低出错。

除了页面布局和UI界面以外，其实对于控件使用统一性、适量清晰的提示、数据加载的时间、动画的流畅度、出错时的提示等等这些都属于用户体验的一部分，这些都非常有助于提升用户操作的效率以及降低其错误率。界面这一块我就不多说了，还是要多看看其他人的设计，多用心站在用户立场试用，后期多搜集用户意见就能够清楚了。

可能还有朋友会问到为什么写到商品，却没有关于库存的？关于库存的医药平台跟其他的电商平台也不会有特别大的区别， 而且库存管理是一个比较大，而且值的后面细细展开的议题，所以我们以后再形象分析。

以上只是基于以往我们做过部分的医药平台的经营的一点感想。具体到每个项目实施会有更复杂的流程， 例如客户原来已经有医药平台，或者销售电商销售的平台等等的各种状况，作为一个产品经理第一还是以实质需求出发做成符合业务场景的项目。