随着“互联网+”时代的电子商务发展, 促使着现代仓储、物流不断的变革和创新, 仓储配送的格局正在发生着巨大变化.仓储行业正集中精力创新传统仓库, 发展电商仓;信息处理方面, 大数据和智能化驱动着整体行业的发展[1].线上线下 (Online To Offline, o2o) 的发展是商业变化的大势所趋, 云仓储模式逐渐成为未来的刚性需求.

传统仓储各仓库库存、订单、物流信息不能实时传递, 形成信息孤岛, 需要用云计算技术解决信息不能共享的问题;在传统仓库中一般是没有订单管理系统的, 在电子商务, 质押贷款等新型模式发展下, 需要订单管理系统作为客户与仓库交流的信息载体, 同时作为仓库信息入口.设计了云仓储系统总体架构, 以订单管理系统为重点, 描述了订单管理系统与其他模块之间协作关系、结构设计及统一的第三方数据接口平台.

云仓储需要在重要区域中心建立分仓, 再由公司总部建立基于云计算的一体化仓储信息系统, 用仓储信息系统将各分仓联网, 进而实现商品、仓库、库位的合理调度, 配送网络的快速响应.在这种模式下, 商品可直接从分仓的分拣中心实现就近配送, 大大地缩短配送时间, 有效地提升客户体验[2].

云仓储系统设计思想可概括为:通过云计算、大数据、物联网等技术的紧密结合, 由系统对数据进行储存、分析、计算, 并对服务进行模块化、封装式的处理, 管理人员被赋予不同的权限, 在任意终端通过门户网站接入中心服务器, 获取权限范围内的、所需求的服务[3].

产业链扁平化是未来发展的趋势.云仓储管理系统在电子商务产业链中提供基础性服务, 将物流、商流、信息流、资金流“四流”有机结合, 利用云计算共享分仓资源, 完善电商仓储物流生态圈, 通过整合信息网、仓储网、干线网, 用大数据提升效率.消费者和工厂设计方、品牌商、农业产区将实现可视化的供需链接, 不论是电商平台还是传统零售, 渠道商如果还是靠买卖赚取差价获利, 这样的生存空间必定是越来越小.真正能够带来一体化的供应链增值服务的, 才是未来商业的核心.

图1 云仓储系统总体框架图Fig.1 Architecture diagram of cloud storge system   

云仓储管理系统利用“云”的概念将分散于不同区域的、与实体仓库相关的资源整合起来, 交由企业中心建立的仓储信息管理系统统一调度管理, 形成一个以分布式仓储为云, 核心信息管理系统为服务器的企业内部仓储管理平台[4].云仓储管理系统由订单管理系统、仓库管理子系统、综合管理子系统、物流管理子系统、大数据驱动子系统构成, 并在移动客户端上建立必要的应用支持.从接订单、仓库内部管理、采购、以及组织发货, 到进行数据综合分析以及业务综合管理, 提供一个有效的信息化管理平台, 为网络仓库的各个部门的业务开展与协同高效工作提供支持[5].

传统的仓储管理系统中是没有订单管理模块的, 在云仓储管理系统中需要处理普通消费者、商超、电商平台等订单数据.订单管理系统是仓储配送的初始环节, 客户需求及内部物流、资源状况、库存、数据分析、任务完成情况等都是通过订单来描述的, 云仓储系统的配送行为表现为围绕订单而进行的一个协调配置过程[6].

在订单管理系统中, 订单是管理的对象.云仓储管理系统中的协同订单处理从地域上横跨整个企业和供应链, 从时间上覆盖订单的产生一直到货物交付给用户的全部生命周期, 主要包括生成订单、订单协同处理、仓库调配备货、制单发货、物流跟踪这五个阶段[6].在生成订单阶段, 订单管理系统应该按照提供的统一接口接收订单信息, 然后进行录入和保存处理, 生成配货单, 同时生成物流服务需求订单, 并按照资源优化配置策略进行订单在物流企业的分配.配货单形成后, 协同仓库管理子系统中开始按照最优路径策略打包货物, 形成发货单, 在供应链子系统中对订单进行确认, 若分配的物流企业接受发货单, 则执行订单;若物流企业拒绝订单, 则供应链子系统根据资源最优调度策略对订单进行智能处理.物流发送货物后, 由物流平台提供的物流信息反馈到订单系统中, 再反馈到客户.云仓储系统各个环节进行协同运作, 并同客户、订单平台、物流企业进行双向信息交互, 提高仓储环节的柔性和反应能力.

订单处理状态迁移如图1所示.

在订单协同处理阶段, 主要包括以下四个基本环节:订单录入、订单审批、订单跟踪、结单管理, 还包含两个异常订单处理环节:撤单管理和急单管理以及一个历史订单综合查询环节[7].在订单协同管理四个基本环节中, 对录入的合格订单进行订单分批, 资源分配及制单执行计划, 对不合格的订单进行调整, 给与客户反馈.用户、企业、创客可以对处于未审核状态下的订单做撤单处理, 在撤销订单后, 完成退款、取消配货单、物流服务单等操作.在急单管理中, 首先获取订单并进行优先审核, 如果审核通过, 订单被直接提交给仓库管理子系统, 如果审核未通过, 向用户提供急单作废通知, 急单的整个业务处理过程都是通过开辟专用通道 (即提高订单响应级别) 来实现, 同时也要求仓库管理子系统对急单开辟专用通道并进行紧急处理[7?8].用户、仓库操作员可以根据业务需求利用各种查询条件对作废订单和成功订单进行实时查询, 查看订单目前的状态, 进行跟踪[8].系统对各种性质的订单进行相应的统计, 交给大数据驱动子系统, 并依据成功、撤销、加急订单详细信息做出业务分析和预测.

云仓储管理系统中的订单管理模块涉及到一整套的订单处理过程, 从提出需求到接受订单, 订单审核, 订单状况跟踪、运输等[9].具体管理内容包括:订单的定制及传送;订单的确认接收;订单合同管理;订单计划定制;订单相关资源管理;订单相关关系管理;订单执行情况的跟踪监控;订单出错及变动处理;订单状态查询;订单后勤管理;订单财务管理;订单协调管理[9,10].

由于订单状态是最直接的信号, 因此不合理的订单管理所导致的信息波动、延迟甚至错误, 会导致订单处理的运作效率低下, 严重时甚至使其陷于瘫痪.为了减小订单信息波动性, 提高运作效率, 各子系统必须达到高度信息共享.为了保证订单一致性, 云仓储管理系统中的各个组成模块间必须协调良好, 保证各方合作的顺利进行.订单管理系统结构图如图2所示.

图2 订单管理系统体系结构Fig.2 Architecture diagram of the order management system   

订单管理系统会接受多种平台的订单, 需要统一的订单接口, 规范订单数据, 对不同来源的订单进行数据管理.如淘宝、京东、当当等商务平台, 通过与电商数据交换服务程序, 获得指定电商订单数据, 为其准备相应的贴牌、配送服务;同时对库存、物流等信息, 提供给电商平台及创客, 以使其获知商品存量;对于自有商城或者APP的商户, 按照指定接口与订单管理系统进行数据交互, 提供给订单系统请求数据, 以便仓储系统根据这些数据进一步处理[11].

以安卓平台为例, 用java代码实现, 图3为第三方平台与订单管理系统的交互流程.实线表示消费者或电商平台对订单管理系统的请求, 虚线表示订单系统与商户系统之间的信息反馈.

第4步:调用订单接口:这一步就是将商户签名后的订单信息传递给接口中的OrderTask对象, 调用order方法, 此方法后续会唤起订单检查、库存检查操作, 订单信息格式具体见表2订单参数说明.

第5步:提交订单请求:saveOrder对象将会按照商户客户端提供的请求参数发送提交订单、保存订单的请求, 唤起订单分批、商品装配等后续工作.

第8步:接口返回支付结果:商户客户端在第4步中调用的订单接口, 会返回最终的订单保存结果 (即同步数据库完毕的通知) .

第12步:异步发送保存订单信息通知:云仓储管理系统会发送异步通知消息给商户服务器端.因为是异步发送, 第12步可能在7~11步之前完成, 但是一定是在第6步订单保存成功后发起.

订单管理系统中提供order接口方法供外部调用, 此接口接收两个参数String类型的orderInfo, 表示商户的订单信息, key=“value”格式, 以&连接;另一个参数是Boolean类型参数isShowLoading, 表示商户提交订单后, 是否唤起一个loading.order方法可以触发订单管理系统里的其他流程, 如库存检测、货物调拨等.重要实体类及关键代码示例见表1.

一个完整的安卓平台调用过程与代码是 (1) 将安卓应用的Activity实例传递给OrderTask构造方法, 实例化OrderTask对象:OrderTask orderTask=new OrderTask (Activity) ; (2) 将订单数据封装到OrderInfo实体内:OrderInfo orderInfo=orderTask.order (String, Boolean) ; (3) 检查订单数据规范:orderInfo.check () ; (4) 订单管理系统保存订单:orderTask.save (OrderInfo) .Order接口接收的String订单信息格式见表2.

图3 第三方平台与订单管理系统交互流程Fig.3 Interaction between the third party platform and the order management system  

表1 订单相关实体类Tab.1 Class associated with orders     

表2 订单参数说明Tab.2 Specification of order parameters     

为简化订单接收以后在仓库中的流转过程, 需要对订单做分批处理, 在系统中引入基于知识库的订单分批策略, 这种策略是去检索历史订单明细数据, 按照式 (1) 的约定, 依据案例推理 (Case-Based Reasoning, CBR) [12]引擎产生最优分批策略.订单在系统中的分批, 流转的方案, 是依据历史订单知识库决策的.基于知识库的案例分批策略分为两部分, 一部分是被处理过的订单收集模块, 另一部分是订单分组生成模块.第一部分由云计算子系统提供存储、更新、检索的功能, 第二部分集成到订单管理系统中, 如图4所示展示了此策略的循环图.

CBR是以过去解决的类似问题的案例来寻求解决当前新问题的推论方法.CBR引擎是把每一次做出决策的一批订单作为一个案例, 也就是所谓的“case”, 典型的CBR引擎运行过程分为四步, 依次为检索、修正、重用、保留.具体是从订单收集模块检索相似的订单, 进一步修正, 以满足当前订单分批的需求, 订单分批问题与检索数据相似性满足以下公式:

式中的sim (f) 是本次案例与历史案例的相似函数, wi是本次案例与历史每次相似属性的权重.在订单分批过程中, 把相似值S最高的历史订单分批方案作为本次的分批方案, 选中的解决方案还需要修正、核对以适应当前的需求, 最终把最新的分批方案再作为历史方案存储到收集模块.

图4 基于知识库的订单分批策略循环图Fig.4 Knowledge-based order batching decision cycle  

假设拣货员都是60名, 订单量依次增加的情况下.在前人实验基础上[13], 对比先到先服务、节约算法、粒子群算法, 结果如图5所示.可以看到基于知识库的订单分批策略只是在订单量较少时处理时间大于粒子群算法, 当订单量继续增加, 则优于其他三种订单分批算法.

图5 订单分批算法对比图Fig.5 Comparison between order batching algorithms

1) 通过分析云仓储管理系统的特点, 设计了云仓储管理系统架构.传统仓库可依靠此系统改造成服务于电子商务的云仓库, 形成仓储配送一体化的新物流模式, 解决了多仓库信息无法共享和协同工作的问题.

2) 订单管理系统工作在云仓储管理系统之上, 提供统一的订单接口, 接收来自不同平台的消费者订单, 统一了云仓储内部订单数据结构便于大数据分析.面对不断变化的消费者需求和海量的订单数量, 基于知识库的订单分批策略在订单管理系统中的应用, 加快了订单处理速度, 提高了收益率和仓库的吞吐率.