视频图片

图片欣赏

20日分论坛之二:红色草原软件系统有限公司的方案总监陈亮先生——2012第四届中国服装行业供应链与物流技术研讨会

时间:2012-08-28 来源:本刊编辑 浏览:

 

陈亮:首先谢谢张总的分享,今天我要和大家聊的是服装行业在WMS项目实施的过程中如何进行管理。最近四五年来,在国内服装企业应用WMS的案例是越来越多了,就像森马的张总所介绍的,不同的企业会选择不同类型的WMS,在所有不同类型的WMS当中不同的厂商根据不同的客户需要会有不同的实施方法和过程管理,这些不同的方法和不同的过程管理都会带来一些不同的结果,我今天想跟大家分享的是我们红色草原在服装行业实施的过程中所碰到的一些问题以及如何成功地实施一个WMS。
 
        从一般的软件系统、IT系统项目管理的角度来讲,通常我们会说一个IT系统要实施无非就是在一定的成本之下保证一定的质量,然后在规定的时间点里把这个系统推上去,这就叫做保质保量保时间。如果从项目管理的过程抽离开来,从另外一个角度来看问题的话我们把整个实施过程讲究从供应商到客户的过程,也就是说这个软件、这个系统在实施之前它的所有,我们不是指财产上的所有,而是它的知识和它应用的方法基本上是在供应商这边的,在整个实施的过程中这种所有权应该逐步从供应商这一端转到我们的客户这一端,之所以提出这个主题是因为在实施的过程当中,因为我们的项目实施总是只有一个阶段,或许3-5个月,或许8-12个月,这个系统是归属于我们的客户的,除了在实施阶段定义我们的需求、定义我们的流程之外,在整个项目实施完毕之后我们还会应对我们未来的一些业务变化。对于这些业务的变化,我们的用户必须有能力利用系统来帮助自己应对这样的变化,所以整个项目实施的过程当中除了有一套我们想象当中未来的流程,我们想用系统、用WMS来实现我们的流程之外还有更重要的一点,那就是我们需要把我们系统的知识,关于如何实施一个WMS,如何让WMS能够帮助我们应对未来的变化,把所有的知识管理的权利和能力从供应商转到客户,这才是实施WMS另外一个重要的关注点。
 
        从WMS实施的角度来说通常分为这么几个阶段:项目的启动、流程的设计、从供应商到客户的转化阶段以及客户的拥有阶段,最后是上线阶段和上线之后管理的过程。
 
         服装行业有它本身的特点,相对于其他行业的仓储管理系统,服装行业的SKU通常来说是特别多的,在森马每年会有8万个新增的SKU,除此之外我相信还有一些退货,就是在仓储里或者系统级别当中需要管理的SKU是远远超过8万,甚至达到30万。我们在考虑WMS实施或者在考虑我们想用WMS来改进、管理我们的业务之时需要考虑的第一个业务就是我们自己的需求,先抽离WMS需要的流程或者仓库管理方面需要的流程,我们首先要分析我们的业务模式,比如现在在服装行业比较典型的两种模式,一种是门店营销类,通过订货会的模式Follow到配送中心,根据门店的计划往门店进行配送。另一种是电商式,就是我们现在在网上销售的一款。这两种典型的模式对于WMS,或者对于仓库的操作流程来说是完全不同的。基于此,再加上我们企业本身商品特性与它的流量波动特性,我们需要清楚地知道我们未来的流程需要什么样的,我们在WMS上线以后应该如何应对我们这种业务的模式。基于这样的考虑,我们会有对于未来流程的设想,包括张总刚才说的我们的拣货到底是用摘果还是用播种,我们的门店配送每天到底是多少个、多少次、多少天的配送,我们是否需要用WAVE做波次管理,还是仅仅按照订单去拣选就够了,基于这些因素我们才能得出我们需要用WMS来解决什么问题。从最基础的层面来说,我们仅仅需要WMS帮助我们解决货物和库位之间的关系,达到货物的准确率或者库存准确率的百分之百,或者需要WMS提高我的作业效率,包括从收货到分检的整个作业效率。在项目启动的时候我们需要考虑清楚我们需要WMS解决什么问题,这样我们才能列出像张总刚才介绍的国内能够提供WMS厂商的几大类,包括国际知名厂商、国内本土厂商和设备集成商覆盖的WMS,这三类不同的WMS所提供的功能和实施的团队所能提供的服务都是不一样的,所以知道了我们要解决什么问题,我们就知道了我们要找什么样的供应商,一旦确定了我们要找什么类型的供应商之后我们就能进入具体的供应商选择环节。在供应商选择方面我见过太多太多的误区,第一大误区就是我们现在企业好不容易决定投资在WMS,我们一定要选择一个最好、最强的,通常来讲大家会弄一个功能列表出来,你发给甲乙丙三家供应商,你的WMS从入货到出库所有的功能都列出来,大家再来比较一下,A供应商在100个里有70,B供应商在100个里有60,好象A比B好,但是我们认为这种方法是不行的,从客户的角度来说,在供应商选择阶段你的功能列表能够列到什么层级,因为市面上所有的WMS可以说百分之百都可以收货,可以做库存管理,可以做盘点,可以做出库,没有哪家是没有的,如果再往细了划分,比如收货的时候是不是能够提供配套的控制,是不是能够像服装行业一样,现在有些高货值的货物会采用序列号管理,你是不是有这样的功能,在非常细小的功能之下会涉及到一些具体的业务场景,并不是说在我们业务场景当中必须用这个功能来实现,而是我这个需求用什么方法来解决。在这个阶段你用功能列表的方式应该是选不好的,或者可以选到一个最强的,因为它的功能最多,但是你肯定选不到最适合你的。相对功能列表,我们更加注重我们产品本身的适用性。基于服装行业典型的换季典型特点,每年还有很多波段,并不是每个季节只有一个波段,这样会造成大量新增的SKU,同时由于换季的原因造成大量的库存移动。这或许是服装行业的一个特点,到每个企业来说要看你的行业是什么,还要看你所倾向的几个WMS是否能够在功能上满足你的特点,而不是说这个WMS到底有多少功能。第二大误区就是实施团队,大家会去看你的实施团队是什么,以前做过什么项目,做过什么项目当然是很重要的,这反映出一个厂商的经验,但更重要的是,我们知道一个WMS的实施一半是产品提供的功能,另外一半是这个实施团队的经验,他以前实施过什么样的企业,经历过什么样的业务模式,应对过什么样的环境,这种实施经验才是能够真正带给我们客户方的。那么相对而言,因为厂商的经验属于一种知识的积累,知识的积累首先在于个人,而不在于厂商,所以从我们的角度来说,我们会建议大家在选择WMS的时候注重产品的适用性和实施的匹配度。
 
        一旦我们选择好了供应商,我们就会进入第一个阶段项目实施的过程,叫做流程设计。流程设计主要的功能,或者说主要的目标是我们在这个阶段需要确定未来三五个月或者半年所有上线的流程。我们选择WMS一定是基于业务上出现的变化,现有的作业模式已经完全不能满足现在业务场景的需要了,所以我们的流程设计一定是新的,我们或许有50%,或许有60%跟原来一样,我们一定会有新的流程出来满足我们新的变化,要不然我们就不用费这么大的力气做WMS的实施了。这里很关键的一点,首先什么人需要参加这个流程设计,我们在以前的实施经验当中很容易看到客户方说我们要实施,我们现在仓库里就有这么一些人,现在就叫收货部的两个人跟你说一下这个收货流程是怎样的,如果是拣货的话就叫两三个人跟你聊一下这个东西是什么样的,到底怎么样来拣货,这种方式我们认为是不行的,因为现在的人员应对的是现在的业务场景,他的思维模式是在现在的业务场景下被框死的,所以参加流程设计的人一定需要对我们的业务模式和对我们未来的需要非常了解,需要在这种情况下根据现有的人员能力去构想他未来的流程,而不是现在的人员直接参与所有的流程设计。另一个问题是我们在流程设计阶段需要做一个业务总目标和所有流程工具的取舍,我们通常都会说我们好不容易做了一个WMS,我们所有的业务都需要搬到系统里做,系统并不是万能的,系统是有偏向性的,WMS需要解决什么问题,并不是做一个WMS就把原来仓库里所有手工作业的流程全部用系统记录,我们所关注的点是WMS需要解决出现的问题。对于一个二八原则,仓库当中80%-90%的业务量是用流程跑出来的,剩下10%-20%的细小流程,比如半个月、一个月会发生一次的,这种流程的数量很多,但是处理的业务量是非常小的,所以在这个时候我们需要做一个平衡,就是我们的WMS到底用来解决什么问题,我们是不是从一个最大的主流程到一个最细小的流程全部都需要处理,如果全部需要处理的话就会造成流程之间的不平衡,会造成用户的一些困难。还有一个考虑的问题就是流程需要细化到什么程度,从流程设计的角度来说,在WMS成功实施的情况下流程一定要细化,因为未来在系统当中需要做的所有事情都需要在流程设计阶段确定下来,因为系统是一个有逻辑的整体,目前你是这样的一个流程,那么将来需要做的细小流程没有实施,或者没有考虑进来的话用户方可能并不清楚软件系统逻辑的整体性,所以当你在未来上线以后提出一些新的业务需要可能会和你的整体有所冲突,主要是为了应对,或者为了避免这种冲突,我会建议在流程设计阶段尽可能把所有的业务场景全部提出来,全部在流程设计阶段设计出来,每一步要怎么走等等。在流程设计完毕之后我们有一个很重要的问题需要考虑,就像很多企业都在做一些关于流程的咨询方案,咨询方案都是落在纸面上的,它可以用文字来表达,或者用一种流程图的方式来表达,这种表达的方式或多或少都会造成一种沟通的障碍,因为对于同样的文字可能个人的理解不一样,现在的一些高端的WMS软件,或者一些套装的软件可以提供用户的能力就是我们在流程设计完毕之后可以迅速地在很短的时间内,比如三五天或者一个礼拜的时间内就可以把流程在软件当中实现,用户就可以在这段时间通过实际的软件操作来想象出我们未来的流程设计是什么样的,避免通过一种纸面、文字或者流程图的表达工具造成了双方理解上的不一致。
 
        因为流程设计是厂商和客户共同参与的,在设计完毕之后就会开始进行一个所谓的转化过程,这个转化过程分为两部分,第一部分是系统从一个会议室的模型,或者是一个简单的流程图方式往一个实际能够使用的方式转移,第二部分就是有关系统知识和使用方法从供应商往用户转移。从系统模型往实际转化的过程中需要注意的是这个时候可以同时开始一些系统设备的采购和系统的安装工作,这种设备的采购是需要基于一定业务量的估算,然后再结合一种系统本身的情况,由系统供应商提出一些设备的规格,这个时候这个系统的采购过程需要及时,设备到位已经可以开始一种系统的安装,同时我们相对于之前的软件工具表达未来的流程,只是在里面做了一个事例,我们做了200个SKU,只是演示一下这个流程是怎么转的,但是在这个转化阶段我们需要把我们仓库里所有的库位,比如你有2-3万个,把仓库里所有的库位全部配置到系统里去,我们有几万个SKU全部往系统里导入。在这个阶段有一个很重要的活动,就是我们的基础数据采集工作,在我们没有实施WMS的时候我们会对这样一种基础数据比较漠视,会觉得它不重要,因为一件服装我们认为只要有它的品名、编号、款式、颜色、规格就可以了,但是在应用WMS之后你会知道这件服装本身的标准装箱量,它的单件体积和重量,因为这会涉及到未来装箱、车辆各个方面费用的估算。我们见过很多WMS的实施在基础数据采集方面做得不是特别好,在上线以后数据并不是很精确,他们只是采取了某一个系列的,比如所有的夏装只要是T恤类都是一个商品体积和重量,所有的冬装只要是羽绒服类又是另外一个商品体积和重量,因为本来就十来个系列,只要自己除一除就出来了,但是冬装羽绒服有北方很多都是比较厚的,在南方就比较薄,有些是有袖子的有些是没有袖子的,在同一个系列之下不同的款式体积和重量是不一样的,未来WMS在运行之后多次指导用户拣货的时候你就会发现因为我们基础数据的准确性问题会导致系统算出来这个箱子原来可以装20件衣服,但是在用户拣货的时候发现装10件就满了,剩下的10件可能需要另外跑到很远的地方拿一个箱子过来。还有一种情况就是系统算出来能够放15件,系统也知道你放了15件,结果发现你放完之后箱子还有半箱是空的,在运输的过程中这半箱就会损失你的运费。在基础数据采集的时候,在没有WMS的业务流程之下运用新的WMS是一种非常大的转变。
    从供应商的支持往用户方的转移过程中需要关键用户参与进来,这个过程中需要知道系统是怎么配置出来的,包括基本的SKU配置和一些库位的配置,更进一步的层面是需要知道我的每一个业务场景系统是怎么实现的,比如我的收货,系统是否需要扫一个SKU输一个数量,一些高档的服装企业会把每个商品的每个条码进行扫描,这显然是在收货过程中的不同模式,我们的关键用户需要在这个阶段学习系统是如何支持这两种不同作业模式的。同时用户需要编写所有的测试场景,这个测试场景是相对于系统本身的,相对应的就是我们的业务场景,更进一步的就是我们的测试场景加上我们人工的作业环节就是我们的标准操作流程,所以说我们的关键用户一定是需要知道我们所有的业务场景。基于所有的业务场景,他需要知道在系统里所有的系统测试场景有多少,在每个场景当中系统需要表现出什么样的行为。比方说我们在收货的阶段,基于我们在不同供应商送货的时候有些企业可以说这次收货可以多收也可以少收,在某些企业我需要供应商严格的收货模式,不能多收也不能少收,这显然是一个业务上的场景。我们的关键用户,我们的各个部门领导需要知道在系统里应对这样不同的业务场景系统需要表现出什么样的行为,比如收货全部扫完之后是不是我的单据上只需要收20件衣服,在收到20件的时候系统会发出提示,或还者是全部收完之后再发出提示,我们的用户需要知道所有的测试场景,并且编写这样的测试脚本,需要列出在每一个业务场景下,在系统的数据场景下系统应该表现出什么样的行为。基于系统表现出的这样一种行为我们的用户才能知道接下来物理上需要怎样运作,比方说我们超收之后,供应商送货多了需要联系采购确认这个单子可以多收还是直接拒绝供应商,这就是我们把我们的业务场景转化为一种系统的测试场景。
 
        在我们的测试脚本编写完毕之后,我们可以在会议室里就把我们的关键用户测试场景在系统级别测试完毕。这还只是我们所有关键用户获取比较少的,也就是三五个,他们开始拥有这样的知识。在接下来的阶段我们需要把由关键用户拥有的这些知识推广到所有仓库的用户,这就是一个实际的拥有阶段,我们所有仓库的拥有都需要拥有相应岗位上的一些知识。在这个阶段有两个比较重要的事情,第一种我们称之为全流程的集成测试,第二种我们称之为压力测试,这两个阶段需要反映的主题和需要达成的目标是不一致的。在全流程集成测试的环境下需要达成的目标是一个WMS的系统实施,或者一个系统上线并不单单是一个软件,还会涉及到不同的设备,比如RF,或者仓库的自动化设备,比如分拣机、电子标签等等设备,在这个阶段我们需要知道我们的WMS软件和我们各个不同设备之间的联通性,它们之间的接口是不是完备,它们是不是覆盖到了所有的业务场景。最简单的几个例子,我们的仓库里是不是RF作业的,我们在仓库里布满了各种无线路由器,但是由于货架进去之后导致了对信号的干扰,还有不同的无线路由器之间由于区域重叠导致无线路由器之间信号切换的不一致,会不会导致我们的RF在仓库里有很多的盲区,在这些地方我们发现我们的RF是不能用的。再举个例子,在服装行业应用过程中都会有包装件的环节,就是分检出来把它实际包装到纸箱里面去,这个环节经常会被用户所忽视,因为从流程上,我们从各个地方拣货出来到了那个地方就打包了,打包之后就运出去了,这是一个自然的过程,但是在包装的过程中需要做复合和自检,我们需要去打印一些装箱清单,或许还需要去打一个运输标签出来,你会发现我的包装架上好象需要放的设备特别多,如果我放了一台PC又放了一台激光打印机再加上一台标签打印机,你的货物过来是不是还有空间?你的包装台占的使用面积是不是够放?你的人员是不是能够比较顺利地在拥挤的环境下进行作业?这些问题是抽离出WMS软件系统之外的问题,这些问题在WMS内部是永远发现不了的,WMS内部的测试永远是空的,但是在实物环节就会发现问题。所以在这个阶段我们需要在仓库里把所有点点滴滴的东西全部让用户自己来用一遍,由原来的纸验,或者在会议当中自己发现不了问题,在一个实物环节当中就可以发现,这就是全流程测试真正的目的和含义。
 
        在进行全流程集成测试之后就要进入压力测试阶段。什么是压力测试?压力测试主要想要达到什么样的目的?如果各位实施过ERP的话,在ERP实施的最后一个阶段都会有UAT阶段,就是用户接受度,通常针对单一工具用户接受度的测试就是我们所有的关键人员,或者我们的项目组把我们所有的流程全部都测试了一遍,测试完了以后现在要求我们所有的用户参与进来,我们就安排一天或者两天的时间让我们所有的用户你做一二三,他做四五六,做完之后就知道他们觉得这个怎么样,这就是用户接受度的测试。但是我们这边想强调的是,作为一个WMS,它的项目实施有着自己典型的特点,和我们普通的办公自动化或者ERP的实施是不一样的,这是一个很显著的典型特点。它的特点就是WMS是一个实物作业的系统,它的系统运行涉及到实物物理上的移动,而这种物理上的移动就会带来一个问题,它不太能够把它翻回去,也就是说如果我移动错了以后还要把它翻回去,不像一般的系统我只要做错了还要在系统层面点另外一个键系统就可以恢复了,如果我把这个货出去了显然不能再用回来,或者我把它从A库搬到了B库,现在你让我把它从B库搬回来,显然要耗费我的劳动力。所以WMS的特殊性在于它是一个人、设备、商品、库位和货物流向以及WMS与ERP之间数据流向的统一。在这个基础上,我们的压力测试需要达到的目的就是在这种统一的条件下,或者当我们达到统一要求之后如何证明我们的上线是没有风险的。我们通常会说在实施WMS,希望上线之后的1天需要出货3-5万件,多的甚至达到10-15万件,我们在WMS的基础上设计了新的流程,我们如何证明我们在未来上线的时候能够达到这个量?因为WMS的实施和上线是不可以重复的,也是不能够翻回来的,所以我们要证明我们这个上线是没有风险的,这才是我们压力测试的真正目的所在。通常来说,我们建议的压力测试方式必须是全员参与,就是仓库里的所有作业人员都必须参与进来。我们肯定会面临实际困难,比如我们的旧仓库还在作业,不可能让所有旧仓库的人员停止作业说我们来做一个月的压力测试,这个时候压力测试的组织方式就会变得比较关键,你可以说我们全仓库有200个人,每个波段抽出50个人过来做这个压力的测试来检验我们这个流程,我们这些人员在这种情况下能不能做到,因为50个人和200个人是不一样的,我们50个人是不是能够做到未来上线所需要1/4的量,至少通过这种方式我们需要证明,加入我们全员参与的话能够达到我们上线的业务要求,能够导致我们的上线没有风险,我们需要通过这种方式来证明。经过流程的设计和系统的知识转化,还有系统从模型往实际的转化,在经过所有用户案例的测试和我们的压力测试以后,我们是不是就准备好了上线?在上线切换的过程中有一个最常见的误区,客户会认为我们是在实施一个软件系统,客户会认为我们在实施一个软件,只要你的软件没问题你就没问题。我们会很容易地认为我们的人员没问题,我们的人员经过多少次搬仓,我们的人员平时都能够做多少业务量,我们的人员应该没问题。但事实的情况是这样的,软件本身或许有一些Bug,或许还有一些流程不顺畅的地方,这些问题都是我们在会议室,或者在测试环节当中可以去发现的,这些问题都是浮在水面上的问题,说实话这种问题是最容易去控制的,因为我们已经发现了这些问题,发现了问题就等于解决了一半,我们知道如果将来要解决这些问题我们需要怎么应对,我们或许有一个补充的方案来应对。真正的问题在于我们的用户,我们的物流中心通常都会有100-200个用户,这些人怎么在一起协同工作,这些人是不是真正完全掌握了他们SOP(标准作业程序)规定范围内岗位必须具备的一些流程和技能。用户通常会说我们没有底,这个系统用起来应该没有问题,这个时候我们需要仔细考察我们的用户,我们的用户是否能够真正应对我们的业务变化。从两个角度来考虑:第一,这些用户操作的熟练度是不是能够满足我们上线的需要;第二,在上线或者在未来应用的过程中出现了一些异常的情况,或者出现了一些比较细小的、例外的业务场景我们是不是能够去应对,我们的用户是不是能够去应对,所以在我们上线切换的准备阶段,针对用户的关注才是我们真正需要关注的点。还有就是我们的用户是不是真正准备好了去接受一套新的流程。基于此我们需要一个比较低风险的、平滑的上线方案,这个上线方案需要考虑以下几点:第一是需要我们所有的参与方确认,这个所有参与方并不仅仅是供应商和用户,从系统级别会包括我们的RF供应商、设备供应商,甚至是叉车货架供应商也需要参与进来。在内部IT和采购都需要参与进来,各个方面是不是都准备好了,我们通常会建议大家做一份所有上线检查表,每一个不同的岗位,每一个不同角色的人员需要准备什么,这些事情是不是全部OK了,全部都有签字确认。第二就是期望值的管理,我们不太建议客户的期望,或者我们在管理我们更大老板过程中对于上线之后的期望,我们好不容易历尽千辛万苦终于把这个系统弄上线了,我们终于可以大干一场了,原来1天2万件衣服出来,上线1个月的时间内1天就要拣出4万件,这完全是不现实的,或者完全是很难达到的,因为一个新的流程,一个新的作业,不管我们之前做了多少次测试,不管对用户做了多少次培训,对于用户来说它都是一个新的东西,对于他来说由于操作的改变会导致非常强大的不适应性,这种不适应性需要一个适应的过程,根据我们的经验,就像一个学习曲线一样,真正上线的前一个月,就是上线后一个月的阶段才是这个用户学习曲线知识和能力的急剧提升阶段,所以在这个阶段我们业务量的高峰一定会安排到我们用户学习曲线出现平滑的阶段而不是急剧拉升阶段,所以在上线的半个月或者一个月内是不适合安排业务高峰的,所以说这个期望值不管是领导还是所有的用户都是需要去管理的,因为基于不同的期望值在上线的过程当中会有不同的情绪出现,有些人会觉得比较烦燥,为什么还没有达到我们的业务量。这样我们就会推导出另外一个理论,上线的时间一定要在业务的低谷,并且要安排一个比较好的业务量爬坡的计划。
 
        除此之外,我们还需要做一个应急方案,如果出现某种情况我们应该怎么办。我们终于做好了上线切换方案,并且决定去上线了,在上线的过程中通常会碰到这样或那样的问题,这个时候我们会面临一些选择。首先是我们和期望值的差距,虽然我们是做了一个很好的上线的计划,我们或许也安排好了我们的门店,因为我们现在在上线,可能会导致业务在某种程度,某个方面上的不顺畅,一旦上线业务量出现和期望值的差距我们应该怎么去应对。这个时候我们的业务压力和我们在上线短时间之内,比如我们只有一个礼拜或者半个月之内的作业能力,出现实际差距的时候我们应该怎么去应对,这是一个非常艰难的选择,我们在所有服装类的客户实施过程中都面临这样的选择,这个选择我们事先就需要做好准备,这个选择会比较艰难。这个选择通常是这样的,我们正常的工作时间之内没有办法达到我们业务量的需求,无非就是两个选择,一个是加班,另一个就是对我们的业务部门说我们还处于刚刚开始的阶段,以后再把这个业务补回来。不管你做什么选择最后都会比较艰难,所以你需要做好准备,相关部门的沟通都是需要事先做好的。在上线的过程中我们还会碰到各种各样的小流程,或者基于我们之前的疏漏没有考虑到的流程,这个流程什么时候改进?是说上线第三天或者第七天就碰到一个新的业务需求,是不是马上要求××供应商把流程改成这样,通常来说我们不会建议这么做,因为在上线的时候你的流程还处于一个固化的阶段,只要这个流程能够走得下去,哪怕再艰难再累我们都会建议尽量先走下去,让我们的用户先熟悉这段系统,让我们整个流程先稳定下来,比如上线后一两个月的时间我们再做上线总结,我们再对所有的流程做一个比较细小或者某些环节的变化。我们还需要测量我们上线的成功,除了达到KPI之外还需要关注人,我们的团队经过这样一次项目的实施和成功的上线,我们整个团队的能力是不是得到了提高。虽然在静态的角度已经达到了原来规划的业务量,比如上线一两个月之内就可以拣出3万件,我们的团队是不是真正具备了拥有系统的能力,我们的团队是不是能力基于这个系统来应对我们未来的变化、未来业务量的增长和商业模式的变化,这对于衡量上线成功是一个更重要的因素。
 
       关于WMS整个实施的过程管理就跟大家分享到这里。谢谢大家!