如何从0到1设计商家系统

电商行业正在快速发展，提到电商系统，我们可以立马想到一些耳熟能详的C端产品，例如淘宝、京东等。但是实际上一个电商平台的运行是依赖多产品协同的，除了服务于C端的购物平台，还包括服务于B端的商家系统。

本文将通过回答如下三个问题：

1. 什么是商家系统，在电商中它的业务目标是什么？
2. 商家系统需要遵循怎样的设计思路，才能实现业务目标？
3. 商家系统是由什么组成的？

上述的三个问题其实就对应着：Why？How？What？了解这三个问题的答案，就能为从0到1设计商家系统奠定基础。

一、什么是商家系统

要了解商家系统，首先要回答的是什么是商家系统。

商家系统有很多不同的称呼，比如后台、商家后台、商家工作台、商家端，不同的角色在称呼这个系统时会有不同的偏好。

目前各大互联网平台为了商业化，先后都开始了电商的布局，如果聚焦在几个头部平台的商家系统，不难发现他们对于商家系统的定义是相对统一的。

不同电商平台的商家系统都有使用到“一站式”的概念，也就是商家在经营中所需要的全部工具、服务都可以在商家系统找到。当消费者在C端App上浏览、加购以及下单，那么对应也有商家在商家系统完成发布商品、营销设置、订单履约、客服接待等等相关操作，以向用户提供对应的服务。

在上述的论述中，我们一共提到了两个角色：消费者和商家。

伴随各种电商模式的兴起，也衍生出了更多的角色。但是核心角色还是消费者和商家。对于电商平台而言，就是通过平台来链接由商家和消费者形成的供需两侧。

其实在这一点上，电商平台和其他平台型的互联网公司内核是一致的，无论是美团（链接本地商家和消费者）、滴滴（链接司机和乘客）、快手（链接内容创作者和用户）。所以按照经济学中最朴素的道理来讲清楚电商平台的商业模式，如果O是提高GMV ，那么可以拆分出3个核心的KR:

• KR1：提高供给侧的规模
• KR2：提高需求侧的规模
• KR3：提高供给和需求两者之间的匹配效率

也就是说当供给和需求都能无限大时，平台链接供需之间的效率不断趋近100%，那么在电商平台就能产生无限大的交易额。值得注意到是KR1中提到的供给侧的规模并只是指商家规模，而是平台侧的供给能力，商家、商品、服务都是供给能力的重要组成。

我们对【商家系统是什么】进行一个总结：商家系统则是实现KR1中的系统工具，核心的业务目标就是实现供给规模的提升，从而实现平台商业化目标。系统只是工具，作为产品设计者，需要谨记系统背后的业务目标，一切的产品设计都需要围绕着业务目标开展。

二、商家系统的设计思路

介绍什么是商家系统后，那么接下来将介绍商家系统是如何围绕着【提高供给规模】来进行产品设计的。上文已经阐述了商家系统是商家的一站式经营平台，而商家系统又可以拆分为各个功能模块。

此时我们就不得不提到“组件化”的概念，简单来说组件化就像是搭积木，我们解耦复杂的系统，将他们划分重组，以此更好的适应业务的发展，在系统更具有可扩展性。

伴随着电商行业的不断发展，商家系统为了实现业务目标，也不断进行衍生，商家系统也是非常复杂的系统。我们可以按照不同的维度，对商家系统进行定义和划分，通过各个功能模块来组成不同的商家工作台。

下面将举一个角色工作台的例子，来帮助大家更好来理解组件化的概念。

电商平台有多种角色，对于KA商家，要维持一个店铺的经营，分工是精细化的，一般会存在：店长、运营、客服、美工、财务、仓储配送。

如上图所示，不同的角色在店铺日常经营中所负责的工作是差异化，所以他们在工作中对商家系统各模块的使用也是差异化的。

那么如果我们去搭一个搭建不同角色工作台的时候，就是利用的组件化的思维，如同搭积木一样，将各个模块组合，根据不同角色的诉求来实现工具的组合。我们试图还原一个电商店长的一天：

阿伟是一家女装淘宝店长，每天打开电脑第一件事情就是看昨天的数据。

昨天晚上尝试了用直播间发布新品的，发现销售数据没有达到预期，分析了数据，主要是客服接待效率没有跟上，直播间用户的咨询量没有及时得到回复，用户的满意度较低，导致了转化效率未达到预期。

马上618了，阿伟开始思考，怎么结合利用618这个流量爆点，让销售数据更上一楼。

正好千牛的消息中心弹出了一则消息，正是淘宝官方邀请报名参与618的平台活动。

阿伟看了下官方活动的规则，认为本次平台的补贴力度较大，可以报名参与。

因此，阿伟拉会和同事讨论618的活动方案，根据平台官方的公布的活动节奏，确定活动的选品、促销力度、店铺装修、客服人员配置的方案等等。

确定分工后，阿伟及其团队就开始了有条不紊的工作，势必要在这次618达到销售目标。

透过阿伟的视角，我们简单勾勒了一个店长角色的用户地图：阿伟作为店长，在日常工作中制定店铺的经营策略，这就导致了他在使用商家系统时会因为他的工作角色而存在偏好。

在阿伟的例子中，他使用了数据模块、客服模块、消息中心模块、营销模块的系统功能。但是，如果我们切换一个角色，比如财务、客服，他们的用户地图可能就和阿伟大相径庭。

上文说到，作为商家系统的产品设计者，我们要时刻聚焦在商家系统如何帮助商家提效上，完成KR1来实现公司的商业目标上。在这节就是在回答我们的用户是谁？他们是否有差异？怎么样对他们来说是提效？

商家系统是一个非常复杂的系统，我们可以看到不同的角色在使用系统的差异性，那么在产品设计也需要差异化的考虑不同角色在使用商家系统的效率。比如阿伟作为一个店长，我们就需要考虑把他经常使用的系统模块前置到他能快速找到的位置。角色工作台也就根据角色的诉求，让系统解耦再组合成这个角色最需要的样子。

除了按照角色来拆分之外，还有按照业务场景（虚拟、实物、到店等），按照商家的生命周期（按照新商、老商）等等。由于电商的业务足够复杂，在实现产品提效这个目标上，需要注意到用户的差异性，在产品设计上能够通过组件化的形式来快速打造出商家所需要的“刀枪棍棒”。

三、商家系统的组成

组件化只是一种产品设计思路，核心要解决的如何适应电商复杂的业务场景，使得差异化的商家用户能够更高效的完成日常的经营工作。第二部分核心表达的是：作为商家系统的产品设计者，我们需要充分了解到商家系统复杂性，在不同的场景、角色、阶段，我们对于提效的定义也是不同的。基于这个理解，那下一步需要明确的是，商家系统到底有哪些模块？也就是我们手中的“积木”有哪些？

在头部的电商大厂，会按照系统模块来划分组织架构。比如说，商品模块的系统将会有独立负责商品的运营、产品、研发和测试。无论是在系统架构还是人员架构上都进行了组件化的拆分，实现在面对复杂的业务场景时，可以保持系统的可扩展性，以较少的开发周期实现商家提效的目的。我们可以用一张图来描述商家系统的搭建逻辑。

上图所展示的是一般POP（三方）商家系统的产品架构，我们从产品视角去理解商家系统时，大致有五层，分别为业务场景、终端、功能模块、系统层、底层能力，具体说明如下：

• 第一层：业务场景，最上层是业务场景。由于业务场景的复杂程度较高，可以不同的维度去拆分商家系统，实现精细化的运营。
• 第二层：终端，可以理解商家系统的展示形态。由于业务场景的差异化，因此行业内的商家系统会出现APP、Web、PC、iPad、小程序等各种形态，以此去满足商家的日常经营需求。
• 第三层：功能模块，也就是商家经营中使用的订单、商品等功能。在商家全链路经营中会存在多个模块，包括：招商入驻、店铺管理、商品管理等等，模块下又可以细分功能点。这些服务的提供方可以分为官方和三方，其中三方的服务是商家自行通过服务市场这个B2B平台购买。
• 第四层：系统层，为了减少系统的耦合程度，在进行技术设计时，会区分各个系统，根据功能、代码量等因素，来去拆分各中心。在推进一个项目时，通常需要多个中心之间交互，通过接口、消息、读数据等形式来实现系统之间的信息交换。
• 第五层：基础底层，在系统层之下就是基础底层。对于商家系统会需要有大量基础能力，为了避免重复建设，大厂在组织架构上会拆分出这些底层能力，一般有技术中台来提供标准化的能力接口，而商家系统作为其中的一个调用方。举个例子，在商家系统的不同功能模块会使用文字识别技术：比如说在【入驻】需要卡证的文字识别，商家上传营业执照或者相关资质之后，能直接获取卡证相关证号，避免了商家二次填写并可以直接按照证号规律进行校验；再比如说在【结算发票】需要财务票务的文字识别，当商家给用户开完发票，需要在系统中上传发票时，会解析上传发票额内容；而通常这些文字识别能力都属于底层接口能力，商家系统会使用这些底层接口能力来搭建功能。

四、总结

让我们回到开头说的那三个问题，希望在读完全文之后，能够给到大家答案：

• 什么是商家系统，在电商中它的业务目标是什么？
• 商家系统需要遵循怎样的设计思路，才能实现业务目标？
• 商家系统是由什么组成的？

其实无论是B端还是C端的产品设计，作为产品设计者在设计之初，最先要考虑的就是产品所需要达到的业务目标，【为什么做】比【怎么做】是更重要的问题。所以对于刚开始接触B端产品设计的同学，需要先明确商家系统在电商中所起到的作用，平台的作用就是拉动供给和需求，同时提高供给和需求侧之间的匹配效率。商家通过商家系统完成日常经营，商家系统承担着供给侧业务目标的系统表达。

由于电商的业务场景的复杂程度较高，所以要求商家系统具有足够可扩展性，因为商家系统的产品设计需要探索组件化的设计思路，使得商家系统中的每个模块或者细分到功能点，都能如同积木一样拆分和重组，使得系统能够快速复用和扩展，从而减少开发周期。

遵循这样的设计思路，以POP的商家系统为例，进行了产品架构的五级拆分：业务场景、终端、功能模块、系统层、基础底层。对于一个产品设计者而言，一定要对系统有整体的认知。在实际的项目推动中，业务可能会跟你描述一个业务场景，需要你在产品上支持这个业务场景，那么在实际的项目推动就可以遵循着五级顺序来识别问题，去逐层拆分，来明确需求的范围。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！