一、分析问题
首先分析下老板为什么会提出这个要求。
在我做过的售前支持里，客户的诉求往往并不仅仅是要一两套系统那么简单，他们需要的是一套完整的解决方案，能帮助他们解决各种痛点。
虽然每个系统都能单打独斗，但数据各不相通，甚至要付出很多“定制”的费用，客户自然是不满意的。
好的系统应该是具有良好的扩展性和可维护性，对于同一家公司的不同产品，他们之间一定要有统一的标准接口，而这并不需要让客户来额外买单。
所以老板提出这个场景，也是合情合理，理所当然。
二、分析背景
目前公司内部有产品TMS，YMS，WMS，BMS等，每个产品都发展得很好，适用于多种业务场景。
但唯独缺少了OMS，之前的OMS都在各个项目里，并没有做产品化处理。
为什么当初不做OMS呢？其实大多数原因跟公司定位有关，公司起步较晚，更多的精力会放在怎么赚钱，完善业务系统，毕竟业务系统是客户真正能看得到的，并且是经常使用的。
另外OMS的部分功能也确实可移植到WMS里，让OMS的用户也能在WMS里使用。
但随着WMS业务越做越复杂，功能越来越强大，用户作业数据量也越来越大。当一旦涉及订单系统的功能（例如与上游系统的对接）稍作修改，需要紧急发版时，自然会影响到现场的仓储作业。
对于小的仓库其实无关紧要，但是对于一些大的仓库，一些电商仓，这些就相当致命了。
仓储作业是有时效性的，说白了就是有KPI考核机制，经常发版对运营人员也是很头痛。
所以我们务必要将发版的影响较低到最小（最好是微服务），也就需要降低系统与系统之间的耦合度。
此外增加了OMS这一层，可对接多种WMS，将不同仓库的订单与库存数据汇聚在OMS，更加方便进行管控和查看，可在出库计划单下发时，更清晰的了解到各仓的库存，实现精准的订单分配。
三、参考业界做法
业界普遍采用OTWB单独产品研发。OTWB是唯智公司在2010年最早提出，现在已经被业界公认的一种物流软件系统搭建框架。
O是指物流订单管理系统，即物流订单的全生命周期的管控，它如同物流系统中的大脑。
T是指运输管理系统，管控运输订单的每个环节，包括前端取货、干线、零担、整车、中转发运、落地配等的管控。
W是仓储管理系统，实现在仓库四堵墙之内的精细化管理，涵盖了货物的收、发、盘、补、移以及内部管理的流程。
B就是物流财务控制系统，是对于运输、仓储各种费用进行计费，通过对于前台各类订单数据的抽取，调用相应费率表以及计费引擎进行结费计算。
从信息流的角度看，由ERP或电商系统产生的订单会下送至OMS模块。
由OMS重新组织、分配后，根据指令性质分别发布至负责仓储管理的WMS以及运输管理的TMS系统。
WMS接受订单后会发送一系列仓内指令，比如商品收货、上下架、出入库安排、库存变记录等等。
同时在规则引擎的指导下，仓内商品的调拨、库位优化、库存报警等也是WMS的系统功能或者说是系统责任。
另一方面，TMS在接到订单后，会立刻做好调度安排，在商品出库的同时Kick in，开始从WMS手中接管物流任务，从运单调度、配载分单、到在途监控、末端配送，直至回单签收等运输链路的全部过程都交给TMS负责。
在完成一系列的物流指令后，会进入结算阶段，BMS的主要作用就是做仓配费用的结算管理。
四、得出结论
经过一番紧锣密鼓的讨论，得到以下的系统流程图。
简单总结就三句话。
1、OMS必须做，因为可以更好的串联整个供应链系统。
2、前期可先轻量化的运作，后续跟随项目进行逐步完善产品功能。
3、WTY系统之间的交互同样存在公用场景，可将场景抽离出来纳入到产品功能里，根据实际业务场景，调用不同的接口达到系统之间的数据联动。
五、怎么做OMS
要做OMS，自然需要深刻理解OMS是什么，应该具备哪些基础功能，它的用户群体有哪些，做完后我们能实现什么效果（获得什么收益）。
1、什么是OMS
OMS即订单管理系统（Order Management System），在不同公司，不同领域有不同的定义。大家对「订单」这个词的定义是有区别的，例如说点外卖也叫做订单，滴滴打车也叫订单，寄快递也叫订单，然后在淘宝、天猫、京东电商平台购物也叫订单。
在海外仓的订单管理系统，主要是来自电商平台的订单，无论是直接从API推进来的，还是从ERP接进来，亦或者是手动创建/导入进来的，本质上这些订单都是来自于Amazon，eBay，Wish，Shopify等电商平台，所以很多订单数据结构和操作方式等都是相似的。
OMS与ERP的最主要的区别在于，OMS的侧重点是在仓储端的精细化作业，而ERP则是全流程、全业务面的覆盖，我认为可以理解OMS是瘦身版的ERP。
我之前写过一篇 "为什么WMS要配套OMS”，其中就重点介绍了OMS的核心价值和核心功能。
2、它的核心功能是什么
1) 智能规则策略
可提供多仓多货主的订单拆合单，自动分仓，自动分配承运商、自动审单，节省人工干预和手动处理的时间。
2) 订单全链路监控
联通上游电商平台、ERP、自建商城和下游WMS、TMS、快递等系统，实现订单全生命周期的管理，从接收订单到订单履约完成，实现订单的全链路可视化监控。
3) 整合数据资源池
基于横向汇总和纵向全流程的数据提取，拥有了丰富的数据资源，基于这些资源，可实现多维度、多层次的不同报表统计分析需求，满足客户不同角色和场景对报表的要求。
OMS起着承上启下的作用，需具备对接多个上游平台的能力，对下可支持不同的WMS和TSS专业系统，支持横向和纵向扩展。
3、用户群体
常用的OMS用户群体主要包括，货主、供应商、客户、客服人员。
1） 货主
对于代销型零售企业来说，OMS系统还需要管理不同品牌商或货主委托的商品，接受和执行货主下达的配送指令，并反馈销售和库存信息。
这也需要OMS系统向货主开放某些用户访问权限，通过界面显示委托商品的相关信息。
在其委托商品的销售和库存信息查询与反馈，非特殊情况下对其他非相关数据无访问权限。
2） 供应商
常规情况下，供应链的采购部门需要向供应商发出采购订单，确认商品的供货时间和数量，以保证仓储和销售环节的商品供应。
供应商也需要通过OMS系统查询和确认采购订单的状态，并更新订单执行情况，这需要OMS系统提供供应商端的用户访问界面。
供应商用户主要需要采购订单管理相关功能，以完成与企业的商品采购交互。
3） 客户
OMS系统需要直接面向客户接受和处理销售订单，并在订单执行过程中与客户进行交互，更新订单状态和物流信息等。
这需要OMS系统开发客户使用的用户界面，如APP、小程序、PC端网站等。
客户用户需要访问更加丰富的功能，如订单跟踪、物流查询、增值服务等，以满足其零售消费需求。
4） 客服
客服人员可根据客户的反馈，进行工单管理，通过找到对应的订单，分析作业情况，登记工单，指派工单，处理工单（移交、定责）。
甚至是对订单登记拦截商品数量，提供更多的订单工单的增值服务。
4、OMS还能做什么
1）全流程的订单履约分析
制定每种订单的时效性，对履约情况进行分析统计，可看出哪些环节（采购、仓库作业、配送）薄弱点，对供应商、仓内作业、承运商提供绩效考核的数据依据。
2） 分单分仓，可延伸至采购
以仓位核心，通过甚至全仓/单仓的库存上下限，结合OMS自身库存，设置好对应的补货策略，结合前置时间，可计算出向供应商采购的数量，对接供应商系统，记录好在途数，定期向供应商发起补货指令。
3） 做全流程的工单管理
客服人员使用OMS的工单管理，可更好的处理客户反馈的情况，统计出哪些订单容易出问题，从而分析出供应链管理的薄弱点，对薄弱点进行加强管控，从而提高客户的满意度。
4） 提供简单的计费统计
OMS应以仓配为核心，可提供核算其成本支出，但利润这块还是建议以BMS计算为主，BMS对不同货主出具应收应付账单，实现相关数据统计。
5、有哪些坑需要考虑
1） 统一主数据
由于「OTWB」的存在，多个系统间其实有很强的业务关联性，必然就会有很多数据是冗余的，例如说货品资料，货主资料，仓库资料，承运商资料，还有一些基础信息（国家/地区，省州，城市，地址，币种，汇率等）。
这些信息在OMS中，在BMS中有，在WMS中也可能有，有些数据需要在多个系统保留多份副本，不便于后期的维护和管理。一些常用的字段，例如名称修改，要么需要通过接口处理，要么需要在每个系统手动去改，显得很是麻烦。
于是就可以抽离出一些公共的数据对象，将其放在中台系统中，提供给多个系统使用。例如货主资料只要在中台系统创建一次，然后OMS，WMS，BMS则会自动同步拉取，避免在多个系统维护相同的数据。
这块之前我设计过，大致思路是用OMS去对接中台系统，获取对应的统一编码，然后将统一编码作为OMS编码，通过下发至各个业务系统，业务系统若发现是中台系统的编码，则从中台系统里去获取其他数据，同时修改后，也调用中台系统接口，始终保持主数据的统一性。
后台保持一个JOB，每隔一段时间与中台系统同步基础数据（也可增加按钮立即同步），从而达到主数据的统一。
2） 统一SSO用户管理
很多公司为了节约成本，就想放在OMS进行统一维护，虽然这样也没太大的毛病。但是OMS毕竟也有他自身的用户群体。
一套系统里同时维护两套用户管理，感觉也挺奇怪的。
所以我认为SSO用户管理放在中台系统较为合适，通过统一的SSO用户管理、应用系统授权，最终下发至各业务系统进行真正的免密登录。
至于该用户登录到业务系统能看到哪些菜单能使用哪些功能，就由各业务系统自身去授权，达到用户的系统+功能权限的处理。
3） OMS与BMS对接
我认为OMS没太大必要和BMS对接，虽然BMS的用户也有按货主进行统计应收应付账款。
但BMS整体时效性要求不如其他业务系统高，可在BMS配置不同的数据源，让BMS也可访问OWT系统，获取相关的业务数据，来进行账单计费处理。
还有一种思路，就是每天固定时间，使用定时存储过程动态抓取业务系统数据，同步到BMS数据库里，方便统一处理。
具体选择哪种思路，就看业务具体的情况了。
6、设计OMS需考虑的点
因时间有限，简单梳理下相关核心功能的关键点，后面有机会的话，再做详细更深入的分享。
1） 货品
其实等同于WMS的SKU，即最小库存计量单位。与电商平台所展示的货品不同，电商一般的SPU。
有兴趣的朋友可以看看我的另外一篇文章，里面详细介绍了，什么是SKU、什么SPU、SN等。
货品信息往往常见字段有，SKUNO, 货品名称、尺寸、重量、型号、图片、备注、品牌、包装信息等。
货品信息一旦创建好，可以按需分发给WMS。在常规情况下，TMS/BMS并不需要单纯的货品信息，它们需要的往往在订单上获得，即使没有，也可自行访问主数据库进行获取。
在权限控制方面，经OMS下发的商品，WMS一般只有查看权限，无编辑权限，仅需限制只能对仓内所需的信息进行编辑，可做一些控制策略。
货品信息同步存在两种方式，货品随订单下发与货品资料直接同步。这两种方式，产品版本都应该支持。
2） 入库
OMS的出入库单更多是打通上下游，上游是第三方ERP或电商平台、下游是WMS/TMS。
明细上不仅仅有SKUNO，货品名称、计划数量。更有包装信息，甚至有箱号、托号与其他商品批属性等。
为什么需要托号、箱号呢？
那是因为WMS收货时，为提升仓库收货效率，并不只是按数量收货，也可支持按托、按箱收货，特别是跨境电商收货。
这就反向让供应商出库前，将货品打包成托号、箱号，在出库时并告知OMS，OMS下发给WMS，也就能更好的进行按托、按箱收货了。
相应的状态有草稿、待审核、处理中、部分收货、已收货、已取消。
功能主要是审核和下发，从操作上考虑，可做自动审核并下发功能，简化流程操作。
这里有一个概念需要说明下，在OMS中，有一个在途库存，即还未入库但可以预估未来的一段时间内增加的库存量，在WMS上架后该库存会变成可用库存。
另外在途库存也是会占用资金成本的，因为对客户来说，也是给了钱（预付或已付）供应商才发货的。
3） 出库
这里需注意平台订单与OMS出库单的区别。
“平台订单”和“OMS出库单/发货单”是两个不同的单据，是一种解耦的做法，也是一种主流的做法。
平台订单和OMS出库单的实体关系应该是1对1或者1对多的，一个平台订单可以拆分成1个或者多个OMS出库单，拆分可能是通过仓库，通过物流或者是通过商品结构等原因来拆分，具体示意图如下所示：
和入库明细类似，明细依然有SKUNO，货品名称、计划数量、包装信息，箱号、托号、其他商品批属性。
状态包含草稿、已审核、已分配、处理中、部分出库、已出库、已取消。
功能上包括审核、分配、下发。比入库多一个分配，因OMS本身是有库存的，可提前预判仓库是否有相应的库存进行处理，若没有则不会再下发给WMS。
但OMS的分配是按SKU来分配的，并不会像WMS那么复杂，不需要制定太多规则。
4） 库存
说到OMS的库存结构，主要包括SKU库存。与WMS库存相比，它的力度较粗。
不同系统的库存差别。
OMS库存里核心的几个字段包括，实际库存、锁定库存、冻结库存、可用库存、在途库存。
这里也许有小伙伴问，OMS是否就完全不关心库存批次了吗？
我建议还是保留，我们在处理OMS库存分配时，确实是按SKU来进行分配的，但实际出入库后，WMS可将库存批次告知OMS，OMS可将该批次信息保留，以供它自己的用户群体查询和统计。
与WMS一样，相应的库存流水也需要体现主要包括如下。
5） 退货功能
关于OMS的退货功能，我咨询过一些大佬，达成如下共识，退货可以做，但不能太过精细化。
因为相对于正常流程，退货是较少的，如果耗费太多人力物力去做，供应链部门也可能会用得很少。
建议实现方式，在原有出入库单上增加特殊类型，标记退货入库单、退货出库单。
增加仓内拍照、录入退货原因的环节，相关信息反向写入到OMS上可让客服、供应商、货主进行查阅。
在出入库时应备注这些货物的处理方式，如退供应商、二次加工、维修、销毁、重新上架，最后将这些信息回传给上游系统。
六、WTY的系统交互
WMS/TMS/YMS直接的交互点，主要是运输计划同步、预约月台同步、完成作业同步。
各个业务系统的信息相互同步，会让作业效率显著提升，以前全靠人工沟通操作的事，全部交给系统自动完成，变相的提升了作业效率。
在实现方式上，我们可通过OMS单号作为关键字段，串联起各个业务系统找到对应单据，从而做相应的操作。
具体我就不再详细和大家深入探讨了，后面有机会再和大家详细分享，大家可自行对照着查看脑图和流程图。