电商核心系统整体分享

摘要：无论是交易订单、支付、库存管理，还是供应链协同、财务结算，一套高效、灵活且可扩展的电商核心系统是企业立足市场的关键。本文将分享电商核心系统的整体架构与关键模块，供大家参考。

无论是交易订单、支付、库存管理，还是供应链协同、财务结算，一套高效、灵活且可扩展的电商核心系统是企业立足市场的关键。本文将分享电商核心系统的整体架构与关键模块，供大家参考。

最近时间比较充裕，就把自己工作10+产品经验做一个整体分享，有中台、B端、C端等，内容涵盖：交易订单、支付、OMS、OFC、WMS、中央库存、开放平台、采购系统、SRM、财务系统（结算、核算等）、外部系统对接（含聚水潭ERP、用友NC65、万里牛WMS等）及爬虫数据分析（若有时间分享下如何用python等工具）。若有不对地方，辛苦指正，

一、整体结构图

二、每个模块大概说明

简单介绍下每个模块，后期会在专门文章做详细说明：

1. 交易订单中台

负责正逆向交易过程和单据凭证的生成，功能大概包括：订单创建、订单取消、订单售后（退货退款、换货、仅退款等）、订单查询（列表、详情、轨迹等）、订单管理（地址修改、修改仓、签收等）、订单轨迹，完成钱货转移。

交易订单中台，需要从多条业务线交易订单需求中抽象提炼共性需求做能力沉淀，将沉淀的能力复用到多条业务线从而实现公司降本增效，例如，我层主导过公司80+业务线升级到交易订单中台，升级完成后，公司做资源整合，降低了很多成本。中台设计比较关键的步骤：

需求收集、分析：收集多条业务线的交易订单需求，收集后做分析，例如，哪些是共性，哪些是个性，基于KANO模型产出一份需求分析表，定义出哪些是中台做，哪些是业务系统自己做，哪些当前做，哪些后期版本做等等需求建模：将需求还原到业务流程中，产出一份业务流程中，一定要详细说明哪些角色做什么事情功能list：基于需求建模抽象出大概功能list，例如，业务线都有下单功能、签收功能等功能分析：分析哪些功能是核心功能，哪些是附加功能，哪些是基础功能等，基于功能设计功能编排能力，例如，下单和退货属于核心基础功能，则，可以将编排退货换货能力，体现中台通过功能积木化搭建完成场景扩展确定系统域、系统边界、交互形式：详细设计每个功能，产出每个功能对应哪些系统域、系统边界及系统交互形式（同步、异步等）（可以采用DDD工具）流程编排设计：基于5产出系统交互后，可以分析出每个交互系统中对应的平行系统，例如，交易下单中，需要库存锁定、创建支付单等平行系统，则可以对这些系统抽象，编排普通下单、定金尾款、代扣等各种交易玩法，后续就可以配置就可以实现新玩法上线，不需要开发切流上线：因为需要让新业务逐个切换而不是一下子全部切换到新系统，如何平滑过渡到新系统，一般通过流量复制、双写、回滚等方式实现

除了设计步骤外，还需要考虑中台设计的一些方式，例如，链路编排设计、积木化设计等

2. 支付中台

支付中台解决的是给各个业务线提供统一收台产品：收银台、支付核心能力、风控、账户等，主要：

统一收银台：一般会提供3种：API形式(提供标准API，例如，支付方式查询等，业务系统自己设计收银台页面)、SDK收银台(SDK封装收银台，业务系统接入SDK就可以拉起收银台页面)、H5收银台（中台提供H5形式，业务系统传对应参数跳转到H5收银台），我们当时做时提供了上述3种，新业务接入收银台一般1天内就可以接入，确实成本降低了很多标准支付核心能力：收单能力一般会提供统一支付网关（限流鉴权等）（有些公司支付系统自己做，有一些是接公司统一网关），收单能力主要指支付单创建、支付流程引擎、渠道路由、资金处理等，支付可能对接不少渠道，渠道对接要屏蔽接入方且高效接入新增渠道。基于标准的支付核心能力，支付中台要包装出不同的支付产品，例如，话费充值，这个就类似支付宝或微信基于底层的支付核心能力（例如，订单创建等）包装出APP支付、H5支付等，说到底都是基于底层能力

风控系统：支持风控规则配置，拦截异常支付行为

账户：支持账户创建、管理等，这里的账户我们以前只是基于用户侧创建，商家、供应商相关账户一般在财务系统管理，例如，给供应商开设账户管理采购相关数据。

支付中台设计方法论和交易中台没啥区别，不再赘述

3. OMS

订单履约系统，只按照履行约定（例如，时效等）将商品（可以是实物，也可以是虚拟等）交付用户（例如，实物签收，虚拟加入到用户账户等），为了完成这一目标需要调度各个系统完成，例如，WMS、TMS等，本质OMS是供需关系管理的系统，基于用户需求及目前供应侧资源，既要考虑用户体验，又要考虑成本，例如，OMS通过和中央库存交互完成仓库分配这个为了降本，但是又要考虑履约承诺，例如，48小时送达，这块就需要一定的履约策略支持

OMS主要功能：订单创建、订单分仓、拆分、审核、物流分配、订单取消、订单拉回、订单全程跟踪、订单信息修改等

我主导过2个大公司OMS系统重构，行业差异很大，但是底层方法论相同，如何设计OMS扩展性特别好OMS系统后续我进行分享

4. 中央库存

拆解成‘中央’+‘库存’，中央是调度中轴，库存就是存放在各个仓库和门店的实物库存，所以说，中央库存就是对各个存放在门店或仓库的库存统一调度分配的系统。所以，中央库存会提供基础数据管理（例如，仓库门店数据）、库存同步、智能分仓、渠道库存分配等能力，这块后续会详细说明如何设计，包括底层表（例如，基础表、流水表等）

5. 开放平台

在2家大公司主导过开放平台0-1整体设计，开放平台拆解下：开放+平台，意思就是将平台开放，开放包括数据、功能等，开放给谁呢？一般分几类：（1）平台内角色，例如，商家，供应商等，这些角色有些有自研能力，注册成开发者获取订单数据等（2）ISV：帮助商家等提供基础数据、流程管理等能力，例如，巨益OMS帮助商家从淘宝、京东等平台拉取订单。

开放平台大概包括：API管理后台（将平台能力发布管理）、API网关（对API管理，例如，限流鉴权等）、开放平台门户网站（开发者在这里注册、API订阅、开发、测试等，会提供各种工具辅助开发者开发）

6. 采购管理系统

主要针对供应商采购流程的管理，包括询价、采购流程管理（采购单创建、供应商接单、入库等一些列流程）、退供（货退给供应商等流程管理）、调拨管理等

采购管理系统一般有供应链运营使用的采购系统及供应商使用的供应商协同系统组成，涉及到采购单、发货单等相关单据底层设计、状态机设计等，采购管理系统也要考虑采购流程编排，支持不同供应商不同的采购流程，例如，有一些供应商需要提前提交预约入库时间，有一些不需要，都需要考虑如何编排不同的采购节点。我们编排过10+采购流程，当然，采购核心流程是一致的，只是在某些节点不同，如何编排这块后续详细讲解。

7. SRM：供应商基础管理系统

主要包括供应商入驻管理、合同管理、供应商运营管理（例如，商品等），这块后续会产出详细的页面原型及和其他系统的相关关系

8. WMS

仓库管理系统，底层是出入库设计，支撑采购入、销售出等10+业务场景，因为，设计的WMS一定需要有很好的扩展性，快速扩展不同的出入库场景。除了出入库场景扩展外，也要支持出入库节点编排，例如，不同单据的出库，仓库作业节点可能不同，后续，我都会详细说明，单据有哪些，关系是什么，状态机怎么编排等等

9. 财务管理系统

我以前的经验财务管理系统主要的内容有2部分：供应商结算、商家结算、成本管理、财务核算等，其他没有做过。

供应商结算：主要包括账户管理、账单管理、发票管理、结算管理等，通过SRM配置的账期，生成对应台账账单，通过后续的账单确认、发票上传及最终通知财务中台（一般走银企直联）完成资金的转移商家结算：和供应商结算比较类似：也包括账户、账单、结算等流程，一般是履约完成后，系统完成清结算，再通知财务中台完成资金转移成本管理：通过成本管理计算总成本及单位成本，进而对成本精细化管理，包括数据获取，数据清洗、成本计算（可能采取不同成本计量模型，例如，移动加权平均法或个别计价法等）、成本应用（例如，报表或提供给WMS等使用）财务核算：进销存过程的一些关键节点都需要推送给专业财务软件，例如，NC65进行记账的，例如，采购完成、履约完成、出库完成等，那么，财务核算需要讲这些关键节点都应的关键单据转化为专业财务软件需要的数据进行记账,后续会详细说明如何设计财务管理系统