编辑导语：随着业务模式的成熟，业务所需要的支撑系统也需要不断改进。在电商管理中，会用到OMS，而随着新零售的发展，OMS需要进行升级的地方也有很多。作者总结了个人对于OMS的一些认识，与大家分享。

随着业务模式的成熟，支撑业务的信息系统也逐渐成熟，人力资源、OA、ERP、OMS、WMS等等各个领域的软件也都有了商业产品的佼佼者，今天，笔者把个人对OMS的一点点认识与大家一起分享，欢迎大家交换不同看法！

“接受客户订单信息，以及仓储管理系统发来的库存信息，然后按客户和紧要程度给订单归类，对不同仓储地点的库存进行配置，并确定交付日期，这样的一个系统称为订单管理系统。”

这是来自于百度词条“OMS”的描述，更多解释见百度OMS词条。

简单来说，就是商家用来管理订单，通过OMS系统对订单以及订单信息所关联的信息进行处理，从而实现库存管理、订单履约以及其他业务需求的信息系统。

如果看上面的概述很难理解什么是OMS订单管理系统的话，那我们就从实际的电商业务角度出发来理解一下吧！

作为普通消费者，我们在电商平台的购物流程基本上是：平台挑选商品——下单支付——等待发货——查看快递——收货取货

但是这个链路中，商家从商品采购到订单处理再到仓库发货、快递运输/派送的流程是不被我们感知的，商家要想让我们购买的商品能够顺利地到达我们手中，需要做大量的工作，在这大量的工作中，就要依靠OMS订单管理系统解决商品的管理、订单从平台的获取、发货仓库的分配、发货快递的选择、平台库存的同步等等一系列复杂的工作。

例如：

商家在多个平台的店铺中上架了上百个商品，那么各个店铺中商品的库存就需要与商家仓库中的库存保持实时同步，这样才能避免卖超，并且，不仅仅是库存同步，为了避免在各个平台都不超卖，库存在各个平台的分配也需要OMS来解决。

还有收货地址的变更、订单需要拆分从多个仓库发货的处理、发货快递信息的回传等等。

OMS的功能架构是从订单信息流的变化中抽象出来的，怎么理解“信息流的变化”呢？

这里从“信息流”和“变化”两个维度来理解：

例如，平台上的订单从平台通过API接口进入OMS，如果这个订单不需要任何修改，那么这个过程就只是一个信息的转移，虽然只是一个信息的转移，但是对于系统来讲，仍然需要配置店铺的基础信息、商品的基础信息、仓库/快递信息等来识别这个订单是来源于哪个平台，购买的是哪个商品，需要用哪个快递去配送。

另外，订单信息流中的商品信息、库存信息、仓库信息、快递信息都需要对应的功能模块来实现配置；

但是随着业务不断的复杂化，订单的信息在转移的过程中，发生了变化，例如：

这些场景在实际的业务中不胜枚举，OMS产品在发展过程中，为了系统性地解决在订单信息进行流转并发生变化的需求，形成了功能模块化的架构，通过近几年电商业务模式的成熟和OMS产品的发展，OMS中的功能模块也逐渐固化下来，成为了建设一个OMS系统所必需的标准功能模块。

功能模块拆解见下一小节脑图。

仅仅有一个OMS系统是不足以完成整个订单履约流程的，也不足以支撑企业的其他业务。

例如和OMS最密切的WMS系统就是订单发货的关键系统，承载着库存管理、出入库单的执行等任务；

还有需要和OMS协同进行订单对账的财务管理系统、用以分析销售情况的数据分析系统等等，都和OMS涉及到的信息流密切相关。

在传统的电商时代，OMS只需要能够对接平台处理订单就可以了，进入新零售时代，销售的渠道越来越多，订单履约的方式也越来越多，有布局分仓的，有工厂代发的，有直播带货的，还有门店自提的。

商业模式的变化，给OMS提出了更多的要求，也带来了更多的挑战，以往的功能模块可能无法再支撑新的业务了，新设计的业务好像又与原有的功能模块有太高的耦合性，产品人被困在了系统里……

作为供应链信息化中至关重要的一个环节，OMS承载着订单信息流能否顺利流转的重任，区别于WMS的功能专业性更强一些，OMS的功能更接近商业模式，所以很多种情况下大家把OMS称为订单中台，这也彰显了在企业业务中OMS的重要性。

笔者想要表达的是，B端从业者，无论是做平台产品，还是商业产品，或者是企业信息化支撑，我们都要拥抱上下游的业务，把知识面向订单的上下游延伸，这样有助于我们更好地理解商业，更好地服务产品。

然后，更有助于向供应链全链路的产品方向发展，做一个供应链方向的复合型产品人，像全栈工程师一样做一个供应链的全栈产品，我想，这应该是大多数B端产品从业者相同的努力目标吧！