limingjie_0513在logclub论坛上贴了个MA的WMS功能介绍,然后引发了一大波专业人士出来讨论,郭总评论说,这里最少有两个至尊级别的WMOS强人,殿堂级WMS顾问,应该是目前大中华区中最强的两个WMOS高手,或最少是最强的三个里面的两个。LMJ应该是从DE去了DHL的吧?能跟两个高手辩论,看来WMOS的本领还不错。。。很快LMJ你就能接触RP Discrerte了,因为某家国际物流公司已经在大概7、8月份的时候决定新仓库一律实施RP。。。到时候就能比较比较两套全球主流独立评论机构评论出来的最强的WMS了。公平的说,WMOS和Discrete都很强大,各领风骚,并非浪得虚名,你有这些强项是我没有的,可是我也有一些强项是你没有的,日后要拼的就是实施服务了。
MA WMOS产品功能很强大,总结一下心得,有如下几个模块,大家参考一下是否还有比这更厉害。。。。。。理论上不会有,但难保会有黑马。废话少说,简单描述一下,
大的模块:
1.月台/堆场管理
2.入库管理
3.库存管理
4.任务管理
5.出库管理
6.零售
7.运输管理
8.系统管理
9.其他集成解决方案。
WMS常见的基本功能不详叙,只讲高级一点的功能。
1.月台堆场管理。
出入库时,包括月台预约,进入仓库大门的检查放行,月台可用性时间,月台分配,车辆从Yard库位到月台的移动,月台之间的移动,离库检查放行等,基本就是模拟现场车辆进出涉及的流程。
2.入库管理
a.预收货,可采用PO或ASN或盲收方式。
b.收货,按托盘收,按箱收,收货过程可以实现分配替换(收入的货箱与系统已出库分配,未拣货的货箱一致,那么可替换库位货箱,直接用刚收的货箱出库),快速流转(对门店配送时,收货时可直接配送),交叉转运(收入的货箱刚好满足某张订单,直接出库),SORTING(收货的货箱可能需要按特别条件整理,比如希望码成整托盘再入库),即刻需求(对收到的货品或订单等有特别的处理要求,比如质检,VAS等)
c.上架,包括手工和系统指示,系统指示时有逻辑,有区域随机,零拣按库位容量先补充原有库位,再分配新库位,存储库位可合并货箱或指定新库位,或者按指定库位指示上架,或者按特定库位,围绕其附近上架。。。。所有上架顺序是可定义的。
d.VAS, 增值服务包括入库时按客户要求处理,比如贴标,打包,质检等,通过即刻需求在收货时实现。质检时系统可提示问题让操作回答确认。。。
3.库存管理,包括批号跟踪,循环或物理盘点,库存跟踪(批号,商品属性,多包装,序列号,重量,货箱属性),孵化期(入库商品存储一定时间才能发货,比如食品),商品召回管理(库内下架),质检,补货,存储库存移动(比如存储库位之间移动,存储库位不满整箱货品合并成整箱),工单,序列号跟踪。库存对账
4.任务管理,灵活配置,确定仓库仓库人员执行过程及权限,范围。
波次订单需求补货,也就是按出货的量多少补货。
库位临界值补货,比如某个库位最多放100,少于100会触发补货。这个动作可波次触发,也可人工触发。2 L. J* r$ V# l8 I2 a/ @* a
闲时特定库位补货。人工触发。与2类似) v' h5 e W+ r. i" b5 e
区域存放优先级补货,比如某个区域最少放50,少于50那么会从其他优先级低的区域把货补过来。& I! Z9 z" }- q/ R7 L6 @
/补货优先级方法:
按时间增加阶段逐步提升优先级。比如每过1小时提升优先级一个档次。0 X* X: d+ P. V: ^
按补货库位数量的变更提升优先级,比如最大容量的库位,少于50提升一个优先级,少于20再提升一个优先级等等。
按补货库位关联的维度自定义提升优先级。比如某个商品,某个库位等等。
同优先级任务,分配到具体用户为高,现场临近当前区域为高,任务生成时间较早为高。
5.出库管理,波次功能,包含拣选波次,装车计划(生成装车),包装波次(包装站分配),订单集货,路线波次,出库VAS
其中拣选波次核心的拣货方法如下:
a.普通的按订单拣货:
A.用RF设备系统指示库位拣货,实时扣账。可以一次组车拣多张单,也可拣一张单。
B.无RF,打印纸张拣货,按纸张提示信息,拣完到工作台扣账。
b.批量拣货
主要针对动态拣选库位,订单波次拆分成拣货标签,如果标签在拣选区作业,一般每张标签多个商品,那么多张订单的标签可以用RF实时扫描生成任务,按最佳路径拣选,至于非拣选区的标签,可以单拣,也可以组车获取最佳路径。所有拣完的商品按RF提示集货。
c.先周转箱拣选多个汇总订单,然后从周转箱拣出各自的订单,与摘果+播种类似。这个也是针对拣选区。
d.多张订单汇总拣货,拣出的商品上架到拣选区库位,然后再执行每张订单的拣选,这个类似摘果+摘果。
e.分区拣选,就是每个区按照波次生成的任务各自拣,拣完后按系统提示汇总。
f.PTS/PTZ,就是订单汇总拣选,拣完后按门店播种,一个门店对应一个库位,比较好定位,适合门店配送。
g.CROSS DOCKING,入库时如检测到出库需求就提示出库,针对单品订单。
h.快速流转,针对门店拣选,入库时发现有需求即刻提示出库,并播种到相应门店。
i.随机替换,入库的商品如果和波次分配的商品恰好一致,那么避免下架的过程,入库商品立刻可替换成被分配的商品出库。
j.小推车拣选,按照小推车的容量限制,如体积,订单数等,系统生成小推车任务,员工推着车子就可以拣选。
所有这些方法与任务和标签结合,在仓库可以形成各种各样,形形色色的作业模式。
6.零售,主要针对门店配送,PTZ,PTS,零售装车及路线分配
7.运输管理,按承运商分零担,整车,包裹,提供各自优化的路线计算,费率计算,分配最佳运输方式。高级功能有动态路线分配,Zone Skipping and LTL Pooling(零担,包裹先集中发运到集货中心,再分别运往各自目的),Rate Shopping (计算各种运输方式费用,择优选择)
8.系统管理
9.其他集成解决方案。包括TMS(运输管理),BM(记账管理),LM(劳动力管理),DOM(分布式订单管理),PM(绩效管理),Slotting Optimization。支持RFID,MHE, PTL,Voice Picking......
下面开始讨论了:
questions:
电商行业常用的播种流程,WMOS怎么做?WMOS只能是Put To Store, 不可能把所有的Cusotmer都放到Store Master表里面吧。
还有VNA通道常见的需要控制一个通道内的叉车数量,WMOS只能控制拣货的,如果把补货/上架/盘点的加在一起呢?
limingjie_0513回答
先摘播种可用pick to tote 和Pack from Tote,也可结合设备做PTL的播种。。。。。至于控制巷道任务操作人数也是OK的
猜测你接触到这个产品:
Work Area Master可以指定工作组工作区的任务优先级,比如上架到某一中转区域后希望得到尽快处理,那么可改变任务后续优先级。
Work Group Proximity定义工作区之间距离,如果任务完成,系统自动分配临近区域任务。
Travel Aisle 定义某个巷道最多操作的人数,防止拥塞。
Task Priority Determination 可根据时间段来更新任务优先级或释放任务
? 0 - Update Priority
? 1 - Change to Original Priority
? 2 - Release Task
? 3 - Release Task & Update Priority
Replenishment Task Priority Bumping用来根据情况调整补货任务优先级,例如库位库存低于某个数量级
questions: Pack from Tote 没有库位哦,不能系统指示库位分配,没法优化播种路径,carton随机 摆放!控制巷道任务操作人数也是可以的? 哪个配置可以啊
limingjie_0513:任务模块Travel Aisle 定义某个巷道最多操作的人数,防止拥塞。
Pack from Tote 没有库位哦,不能系统指示库位分配,没法优化播种路径,这个确实如 此,但是你可以稍作开发定制,,,,,比如最后不要提示一大串出库箱号,改成提示 虚拟库位或2位数的标志符就OK了
questions: 呵呵,客户化出来了。另外,你说的通道人数限制,那个只是针对补货,整托盘出库之类的,拣货没在里面,而且那个控制是从任务角度的,就是说一个时间点上是一个任务,而不是从设备角度。
另外,对于双深度的叉车作业,如何指示用户一次叉两个托盘呢? 还有,看你写的包装站分配, 猜测你说的是Chute这玩意。这东西能用吗? MA在国内的项目,包装站上的不都是那个客户化, 或者用RF Audit Carton吗?
纯学术探讨。。。虽然不愧为一套不错的系统,但功能缺失也是蛮多了,说强大就不必了。 另外 问一句,你去MA了? :-)
limingjie_0513:控制是从任务角度的,就是说一个时间点上是一个任务,而不是从设备角度。-
设备也可以包含于任务中来控制,殊途同归嘛。。。。存储库位可以控制,拣选库位用动态拣选也可以达到这个效果吧。。。一次性取两个托盘有何难,可以在一个任务包含两个明细不就OK了。。。。
Chute这玩意。这东西能用吗?
可以用呀,目前用不上是因为自动化跟不上产品的速度,本土不够高级不能怪系统太高级吧。。。。换个思维思考。。。。。MA国内项目虽然没用,那是用不上这么高级的东西。。杀鸡不用牛刀,,一个小客户化就可以满足需求了,何须用这个。。。。
questions:呵呵,上架之前,那个任务还没生成出来呢,我一个双深度叉车,要一次性拿两个托盘去上架。隔壁的同事是单托盘的。你要说我事先生成好任务,那又是另外一个场景了,那样的话,系统就要指示用户去拿具体的哪个托盘,这时候又会出现用户拿不到的情况,又做一个客户化,让系统在这里可以替换托盘,呵呵
巷道的人数限制,你确认动态拣选库位可以? 你可以看WMOS在这个上面的设计思路,INT1, 2, 11,100。。这些是可以控制的,他的想法是我帮你控制一个通道内的叉车司机数量,但是同时又有人在那个通道用托盘拣货呢?
关于Chute,您的意思是,如果不用自动化设备,那Pack Wave + Packing Station 就是个摆设?
随便再来两个吧 。。。
现在都是一个物流园区里面几栋建筑,一辆卡车卸货的时候要停靠好几个建筑的月台门,WMOS怎么指示卡车按照什么顺序停靠呢?
还有生产物流上常见的容器管理,排序件。。。这些东西呢?
不想抬扛,只是实事求是的说而已。产品功能的不足一靠客户化,二靠顾问流程设计的能力。我认为关键还在第二点上。
limingjie_0513:如果是你用了系统的DROP 库位,就应该知道可以随便取2个托盘,并且任务也是生成好了的。。无需客户化OK。。
从设计角度来讲,一个巷道既有叉车又有人这是应该避免的,因为安全第一,作为优秀的产品自然要考虑这些,总不能你现场怎么操作就得按你的来,毕竟产品提供的是最人性化,最科学的服务。
动态拣选用在拣选库位,一般不会和叉车在一起。。。这个当然可以控制人数,因为他的原理是基于人数来分配任务。。。
关于Chute,当然是主要为有自动化设备仓库提供的,,毕竟比不支持好,国内不用那是时机未到
现在都是一个物流园区里面几栋建筑,一辆卡车卸货的时候要停靠好几个建筑的月台门,WMOS怎么指示卡车按照什么顺序停靠呢?月台是有优先级的吗,月台和月台之间是可以移动的,功能上肯定支持,有规则系统才能指示,,,乱停当然指示不了,,,,
容器管理如果仓库流程够标准化,系统办法也有,就怕现场一团糟,就指望系统
排序件无非就是任务明细排序,,,提供个排序字段就OK了
至少看下来对这些需求不至于绝望
questions:呵呵,很好。功能不足用顾问的能力来弥补,您走到我常用的那条路上去了 :-) 我回头给您一份市面上流行的各WMS功能比较列表吧。最后说两句,一是您对排序件的理解太简单了,不是简单的库位排个顺序就可以的,另外,您不觉得我是在说WMOS的优点吗?这么多功能都有,只是小细节上需要客户化而已。 忙去了,Byebye。
questions:
听朋友说这个帖子热了( 2012-10-25)!回来瞅瞅,原来是行业大拿JK(郭总)来了。说实在的,这种功能比较没啥意思,就算抛开顾问的实施能力,单纯比较软件产品,也需要从软件的核心架构上去比较,要看这个产品从什么行业起家的,这个最初始的架构决定了整体的拓展空间,而不是弄个功能列表来比较。
MA WMOS最开始的名字是PKMS - Picking Mangement System,是从仓库拣货优化开始的,所以你可以看到关于PickTicket的设计以及相关的拣货优化是相当丰富,拓展空间也够。但是,后来转向零售,强行增加了Distro的功能,而这个设计又必须遵循PKT的原理,说实话,在这一块的功能并不够理想,不是不想增强,而是加不进去了。我不认为楼主说的那个Pack Carton From Tote很容易加库位进去,这个是结构性的,不是补丁性质。更不要说针对生产制造领域的那些需求了。
另外一个是最初始的设计就是按照功能参数配置来实现需求,而不是通过脚本配置。这带来系统极强的封闭性,只能在自身的参数范围内做配置,只要是没有的参数,就需要客户化。而不是用户通过编写脚本,系统通过解释来执行非系统提供的功能。这也是为什么MA在国外的项目动辄20几个客户化,而且每一个都不轻的原因,在国内,由于固定费用,客户不对新增客户化付费,所以MA的顾问都有超强的说服客户接受系统最佳实践的能力,其实是被逼的,你以为顾问不知道哪个流程最适合客户啊,呵呵。
WMOS快要寿终正寝了,马上转向Platform,这倒是一个值得期待的产品。和Discrete的MOCA,以及HighJump的可编程去比比看。
limingjie_0513:
好有高度。。。佩服。。。不过有些不同看法,PKMS确实是PKMS - Picking Mangement System,是从仓库拣货优化开始的,但是你说“后来转向零售,强行增加了Distro的功能,而这个设计又必须遵循PKT的原理”听这个意思貌似这个遵循有问题,试问仓库基本功能就是存储和发货,在零售这一块充分利用优势PKMS有何不可。何况DISTRO支持两种方法,一种与正常发货差别不大,另外一种就是PTS/PTZ,除此之外,市场上其他软件也没有其他的方法了吧,甚至很多连这两种都支持不到。Pack Carton From Tote加个虚拟库位有何难,根本不用涉及核心功能,无非就是对TOTE的出库箱标识一个易区分的名称,比如用随机的虚拟库位号,或者2,3位的序号,只是个简单的存储过程外带RF显示的增强,比这复杂的客户化市面上多的去了。
“另外一个是最初始的设计就是按照功能参数配置来实现需求,而不是通过脚本配置。”此言差矣,任何软件都是都是参数和脚本配合的方式,不管是Discrete的MOCA,还是HighJump,都有参数。问题的根源不是参数或脚本,而是可配置的灵活性,这个灵活性才是决定你客户化的根源。WMOS很显然是基于配置的,行业老大的位置不是那么容易得来的。每个产品都有客户化,MA也不例外,另外MA有一个优势,那就是基于行业的积累不断把这些客户化变成BASE功能。所以随着时间推移,客户化会越来越少。这是其他产品难以企及的。
“WMOS快要寿终正寝了,马上转向Platform,”换个名字而已,,不是寿终正寝吧。
可编程重要还是配置灵活性重要?配置的灵活向本身包含了编程的思想。。。。如果纯编程,对一般的用户来讲很难的去使用,必须依仗原厂商,不知道要花多少钱呢。。。呵呵。。
bchyuan:
Questions讲的问题确实是MA的最大问题。从软件实现的体系架构的设计思路上讲,基于参数的配置既是MA立身市场,保持优势的法宝,同时也是其在发展上的最大绊脚石,目前MA在中国市场上的WMOS和Scale都受限于此。
MOCA给原先封闭的WMS市场带来了新的开放性,可以说这是在中国市场上出现的第一个真正意义上面向SOA的WMS平台。其Script中所描述对象是真正意义上的仓库对象,在其易读性同参数配置不相上下的同时,灵活性和开放性要远远大于参数配置。这种体系架构上的优势,对于原厂商和合作伙伴积累行业经验,发展开发各行业模板带来更大的利便性和灵活性。相对于把各个行业的所有功能都集成进BASE,这是更加符合目前IT发展趋势的。
SOA不仅仅指接口本身,更在于其开放性和可管理性,所以CORBA和WEB Services并不是核。核心是Business Objects, 逻辑语言,和可配置的高度灵活的集成平台,目前在中国销售的WMS中,做到所有这些的只有Discrete
questions:
你很快就会用到Discrete的MOCA了,所以呢,现在也不用过多的去比较功能,参数配置这些层面的东西,相对于纯SOA的平台而言,这些参数,配置都是浮云。我相信你们高层也是看到MOCA给3PL带来的灵活性,才会在全球用Discrete替换WMOS的。等到一个项目原来估计要20个客户化,用MOCA以后,发现只需要2个的时候,我们再来讨论架构于物流业务(注意,不单是WMS,而是整个供应链)抽象层面的Business Objects给用户带来的灵活性,开放性和参数配置的局限性和封闭性的问题。
可以闲扯WMOS的历程,从90年代末期采用CORBA中间件以后,WMOS一直以功能强大,参数众多著称,长期市场占有率第一,也正是这种老大的地位限制了它的发展,害怕产品结构变动带来的稳定性等问题,对于10年前开始兴起的SOA架构一直处于想换而不敢换的心态。直到几年前开始被迫提供少量WebService,而这种WebService其实是系统开放出来的API,和SOA不是一个概念,功能局限性很大,效率也很低,所以在项目中的实际应用很少,偶尔在项目中迫于用户的压力,在接口层面采用WebService调用而已。Platform不是简单的WMOS升级,而是完全的架构转换,这是全新的基于SOA架构的产品。WMOS 2011xr是这个产品的最后一个版本,所以说WMOS寿终正寝并不过分,只不过PlatForm在国外也找了几个客户实施了一年多了,产品稳定性一直有问题,毕竟全新架构嘛。至于啥时候进中国,我个人判断应该很快了,毕竟不能到了2013年继续卖2011版本吧。