转自：产品经理与电商后台产品架构
2017-12-08
刘志远 [互联网er的早读课]
随着智能手机的普及，互联网以汹涌之势融入我们的生活，上到花甲古稀的老人，下到总角之年的小朋友，都或多或少用过一些应用，对一些产品有各种见解，越来越多人开始讨论产品。对产品经理来说这是最好的时代。
但是产品同质化越来越严重，用户体验却难以量化，马太效应在互联网行业如同魔咒，流量被巨头掌握，中小企业难以突破流量黑洞。对产品经理来说这同时也是最坏的时代。
大部分用户根本感知不到后台产品的存在，会觉得后台产品颇为神秘。业内人一般认为做后台产品很难，因为产品的逻辑复杂。在大家天马行空的畅想之后，后台产品经理会想着怎么落地，后台系统能不能支撑？什么样的产品方案可以满足需求？
很多人接触电商都是从淘宝（天猫）、京东开始，也仅限于前端商城，很少有机会了解后台。如同骨骼之于人体，后台对于电商业务的支撑起着至关重要的作用。一开始接触后台产品，会觉得异常困难，因为后台不是某个独立系统，而是多个模块组合，并且之间还有信息交互。后台重逻辑、重业务，对产品经理的要求很高，令许多人望而却步。不过当我们慢慢梳理清楚业务，弄清楚系统之间的信息流转，就能逐渐成长，甚至在逻辑自洽中找到做后台产品的乐趣。
1、什么是电商后台
“前端用户的一小步，后台系统的一大步。”相信接触过后台一段时间的产品经理都会发出这样的感慨。
平常我们用的最常见的功能，比如购物车、优惠券等，看似很简单，用户在使用时也就是点一下，实际上在后台要经过很多条件的校验、多系统间的信息流转。
电商后台对大部分用户来说很陌生，平常几乎接触不到。后台与前端是相对的，对普通消费者来说，商家系统和平台管理系统都属于后台；对平台上的商家而言，商家系统就是后台系统；对平台来说，平台的管理系统属于后台，针对C 端的APP、H5 商城和针对B 端的商家管理系统都属于用户端。
电商后台系统，其实也不能叫做一个系统，可以称为后端支撑产品线，一些公司将其拆分为很多子系统，阿里更将其发展成了中台事业群（商品中心、搜索事业部、共享业务平台等）。后端一系列系统支撑着公司各种业务的进行和发展，当前端展示、业务处理（订单、售后）、库存变动等业务正在进行时，后端各系统间则互相调用接口进行数据更新。
电商行业的许多业务与传统零售业类似，构建后台系统的过程实际在做信息化供应链。做电商产品经理，一定要读供应链管理的相关书籍，用专业化的理论来理解业务。
在漫漫人类历史中，商业以各种形态已存在千百年，现代供应链管理理论发展已近百年，供应链的信息化自计算机诞生后就不断在推进。
电商行业不同于其他互联网领域，已经有许多成熟的商业理论可以应用。电商后台产品线的大多数工作是 将线下的供应链体系搬到线上，比如采购、仓储、供应商管理、库存管理、商品、 售价管理等，这些领域在传统制造业、零售业已有一套成熟的理论和应用。 现在很多电商企业会选择自主开发电商整套系统，系统却很“土”，只在意从 0 到 1，却忽略从 1 到 100 的优化。以库存管理为例，商品库存仍是囤货策略，没有从 科学的角度去考虑库存周转期、安全库存、补货策略等已经很成熟的东西。图 1 所 示的是马士华老师在《供应链管理》中的供应链管理体系构建总体模型。可以发现， 电商后台产品的许多业务都在这张图中有所体现。电商公司的采购、仓储、服务、 物流、订单等工作都在供应链管理中有所涉及。比如 Push/Pull 方式就经常用在电商 的库存管理中，双 11 的促销就是 Push 的方式，先备货，然后通过促销来增加需求。 电商后台的许多工作是将供应链流程信息化，以系统的方式来控制业务。当然电商 产品中也有许多独有的内容，如在线商城、内容管理（CMS）等。
以客户下订单为例来介绍业务信息在各系统之间的流转，涉及主要的信息交互如图2 所示。从用户选择商品、生成订单到订单出库、物流配送、用户签收、退货退款，信息在多系统中流转更新数据。
从图2 中可以看出，前端用户简单的下单动作，需要后台系统多系统模块之间的配合。对于产品经理来讲，理清各系统之间的业务逻辑，特别是当商品类型多样（包括服务商品、实物商品、服务加实物商品等），业务复杂（包括预售、代销、代发等） 时，各系统模块的隔离、设计时考虑扩展性非常必要。
在电商企业中，后台系统主要的作用是业务支撑、优化服务流程、提高服务效率， 还可以提供数据分析参考，进而为业务调整提供参考。
2 电商后台产品架构
电商后台是业务要求较高的产品，当前台产品或业务人员提出需求时，有经验的后台产品经理第一时间想到的不是画原型、设计功能，而是分析要实现需求涉及哪些模块，需要协调哪些子系统对接。所以优秀的产品经理一定是对产品整体架构比较清楚，能从系统整体角度考虑功能的合理性，在平台层面为未来可能的业务发展进行规划和设计。
好的产品架构对于一个企业来讲是非常重要的一件事情，决定了是否能够承载业务的发展，就如同地基之于高层建筑。由于商业性质决定了电商业务支撑系统必须具备稳定性、可扩展、操作便捷、安全性强等特点，产品经理在设计产品架构时， 应充分考虑到业务发展需要，尽量将各模块隔离，比如以商品模块建商品中心，以订单模块建订单中心等。只有在产品设计上有模块化思想，具有前瞻性，技术在开发时才会考虑业务隔离，当业务调整、功能新增时，开发可迅速进行，避免牵一发而动全身的事情反复发生。
产品架构的可扩展性非常重要。很多时候会听到开发讲“不要写死”——写代码讲究“可复用、可扩展”。对于产品架构来说同样如此。产品经理在设计产品架构时，要思考未来产品迭代的方向，可能会增加哪些模块，从一开始就给以后的发展留下可能性。如果新产品还没迭代几个小版本，增加一些功能就需要整个页面层级或技术架构推倒重做，那肯定是产品经理的问题。以网易云音乐为例，从2013 年云音乐的1.0 版本开始，一直更新到现在，APP 的信息架构和页面层级基本没发生太大变化。好的产品架构能够支撑业务拓展，降低维护成本。
电商后台产品架构设计要求产品经理非常懂业务。对于系统逻辑思维、整体业务认知以及发展的前瞻性，不同行业、不同用户群的产品经理在做产品整体架构时思路也会不一样。
针对一般电商业务，笔者简单画了一张产品模块示意图（如图3 所示），基本一些中小型电商公司的产品架构大致如此。除了图中所示，现在很多电商公司开始转型社交电商，采用UGC 模式或直播电商，在产品架构上会新增资讯系统，实现资讯与商品的高度融合。
（1）商品中心：
主要管理SKU( 最小库存单位)、SPU（标准化产品单元）、属性（关键属性、非关键属性、销售属性）、类目品牌、价格等有关商品的数据。
（2）订单中心：
管理订单类型、订单状态，收集关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据，进行库存更新、订单下发等一系列动作。
（3）支付中心：
管理支付数据，调用第三方支付平台接口，记录支付信息（对应订单号、支付金额等），支付对账。
（4）会员中心：
主要管理用户等级、用户权益、积分、卡券等会员相关信息， 通过一系列满足用户心理、提高黏性的方法来实现开发新用户、增加用户活跃度的目的。
（5）调度中心：
将订单信息转化为发货通知单，以及其他出入库单，调度仓库和物流进行发货。
（6）促销中心：
主要管理活动相关，优惠券、满减、专场活动、促销专区等。促销工具的开发对电商尤其重要。促销活动的滥用易造成的用户疲劳，怎样推陈出新， 给电商产品经理造成了很大挑战。
（7）内容管理系统：
主要是对用户端进行页面配置（Banner、ICON、Tab）， 配置首页，自定义活动页面，设置生效时效。
（8）评价中心：
管理商品评价和用户反馈。这并没有想象的那么简单，涉及一些敏感词和敏感图片的筛选，以及回复内容管理。
（9）采购中心：
管理SKU，当库存预警时，及时生成采购单进行入库。有供应商管理模块，主要进行供应商管理评级，发展新供应商等功能。
（10）财务管理：
主要管理订单、采购系统相关的财务数据，数据准确性要求较高。还需要负责对账、清账、统计等业务。
（11）WMS 系统（仓库管理系统）：
主要包括入库、出库、盘点等模块。WMS 主要和调度中心进行数据交互，反馈出入库状态和库存变动。
（12）物流中心：
主要包括运费模板，负责运费管理（前端订单、真实物流成本）、物流状态保存查询（包括快递100、菜鸟等关联业务）。如果是跨境电商，还涉及和海关总署的对接，进行报关操作。
（13）风控中心：
主要利用大数据进行用户信用建设、反欺诈，避免恶意评价、刷单退款等操作，构建安全的电商购物环境。
（14）客服中心：
主要管理退货退款、售后服务等操作，包括呼叫中心、在线客服等，与之对应的是工单系统，将客服任务进行队列管理，分配给相应的客服。
（15）店铺管理：
功能庞杂，相当于提供给B 端用户一个Saas 管理后台，提供管理商品、营销、订单一系列功能，主要针对一些有对B 端业务的电商开放平台。
对电商公司来讲，
最核心最难做的有三部分：商品、订单、库存。商品与店铺、营销、评价等相关；订单与会员、营销、支付、库存、物流等相关；库存与订单、采购、WMS、营销等相关。系统之间业务逻辑和交互异常复杂，规则多样。
对电商后端支撑线各模块的业务功能有初步认知之后，可以看到的是，平常手机中的一个电商APP，背后是若干子系统在支撑着，亦是许多技术和产品人员在辛苦付出。
每个子系统不是孤立的，通过产品架构相互关联，定义其功能范围。产品架构与技术架构相辅相成，产品架构决定需求和设计，技术架构决定技术框架与性能。
产品架构将这些不同用途的功能进行聚类整合，将电商后台拆分成多个子系统， 明确业务边界，尽量减少系统之间的耦合，高效支撑前端业务。
3后台丰富度的权衡
对于电商后台，初创小公司用几十个开发人员就能满足需求开发，维持业务流转，大公司则需要几百甚至上千个开发人员来进行开发维护。这就涉及后台系统复杂度的问题，除了业务范围的区别，还有业务量的因素。
如图4 所示，以商品模块为例，在业务量逐步增长时，为了高效便捷地服务用户，会慢慢拆分多个模块。如图上所示，在系统上线初期，整个后台系统融合在一起，商品部分只是后台系统的一个模块。随着业务量的增长，将商品中心独立为子系统；接着随着业务继续增长，库存模块从商品中心中独立出来，单独成为库存中心；再接着发展下来，价格模块从商品中心独立成价格系统；再后来，价格系统根据需要拆分为价格管理系统与价格监控系统。从这个例子中我们可以看到，系统都是从简单到复杂，随着业务慢慢迭代。
图4商品模块系统进化过程
对产品经理来说，并不是要把系统做得大而全，也不是小而精。前面提到过， 产品经理要做现实的理想主义者，根据实际情况来制定产品迭代计划，不求一步到位。
在产品开发初期，为了尽快上线、降低开发成本，会优先开发主需求，后期随着业务发展慢慢迭代。很多后台产品在上线一段时间后，随着业务增长处理起来会变得越来越吃力。各系统模块杂糅在一起，耦合度高，还有可能出现牵一发而动全身的情况。后台产品经理的能力很大一部分在于对业务的梳理能力，越到后台发展中后期，业务逻辑会越复杂。对业务进行拆分，定义产品架构，支撑中长期的业务发展，极其考验产品经理的能力。
本文选自《电商产品经理宝典》，书中详细介绍了电商后台产品线中的各系统模块以及跨境电商产品的不同点
- 本文仅做学习分享，已标明文章公众号出处（详见1），不做任何商业使用
