际客项目切换总结

从17年年底开始,知道了要切换际客系统,然后到18年的9月25号正式切换。一路走来,从对供应链和仓储知识一无所知,到现在渐渐熟悉业务,了解供应链的内容。2018年,算是成长飞速的一年,也是跌跌撞撞的一年。由此,打算对本次系统的切换做一些总结,一方面是为了方便下一次对接新客户可以有所参考,另一方面也是对自己成长的一种总结与归纳。

切换前的准备

1. 渠道是关键

对于新客户的接收,WS这边主要是提供货物的管控(包含入库,出库,库内管理,退换货等),但是渠道这一块如果是际客或者是其他电商类公司,也许他们自己有对接的渠道,这样的话直接用他们对接好的渠道,然后客户自己预报好了渠道信息之后再通过接口反馈给我们,可以省下很多事情;如果是没有渠道的客户,需要我们根据发货地还有货品类型进行渠道的拓展和开发,这一部分会占据较多的时间。

渠道相关的信息除了简单的获取面单之外,还有一些渠道会有一些特殊规则,设计到面单的规格,打包的要求,货品的要求,还有交货时间的要求等等。也就是说对于仓库来说,或者是对于WMS系统来说,需要考虑到这些情况对于线下作业的影响。

2. 接口数据的准备

接口数据主要是CRM与客户进行交互,而关键性的信息主要就是货品信息还有订单信息,然后一些其他类的信息接口。

货品信息接口,比较占据时间的就是一些字段的要求,我们要接收哪些,哪些是必须要客户传送过来的;然后还有就是一个数据量的问题,如果货品信息太多,那么传送数据过来的时候,双方的系统是否可以搞定这种高并发的情况。

订单信息接口,主要是负责接收客户推送订单过来,然后根据推送的订单再下发到仓库系统中,这部分除了包含多种多样的订单类型之外,还有一些退换货的信息,或者是一些和订单有关的辅助类接口等。

其他类信息的接口,一般是指异常反馈接口,查询接口,指令下发等一些信息,具体需要多少个接口还是需要根据实际的业务场景来设定,但是总体上来说就是这几个大类。

3. 内部系统联调

客户一般会给出他们的业务模式或者是一些要求,然后这些要求和我们目前的业务逻辑并不匹配,例如这次切换的际客就是这样,际客的业务模式比一加复杂很多,而且要求也高很多,同时还会对我们提出一些数据要求或者是一时间我们业务不能接受的需求。这样的话,产品这边只能根据实际情况再结合目前的系统功能,进行功能的新增或者是调整,然后WMS这边调整了的话,CRM或者是WCS那边都需要相应的进行改变。

内部系统的联调是基于业务模式的改变而进行的,当然改变不一定是坏事,关键是这个改变是否可以适用于下一家我们需要对接的客户,所以我们对一些很奇葩的需求都进行了过滤,当然也有一些实在无法拒绝的需求,我们只能看情况进行开发。

总体上来说,需求的来源比较薄弱,意味着我们并不能很准确地判断这个需求是否适用于下一家客户,我们只能参考更多人的意见和其他系统更通用的解决方案,然后去评估这个东西是否具有通用性。

在这一块,产品的经验和能力显得尤为重要,如果对这一块比较熟悉的话那么对需求的拿捏把握就会更加准确,也更加的具有话语权。但是遗憾的是,我们公司目前的产品在仓储这一块都是新手,大家都是摸着石头过河,所以未来当我们成熟了之后,回过头看这一块东西,也许会感慨:当时怎么会这么蠢,去做这个功能呢!

4. 全线打通,准备切换

渠道搞定,接口对接好,内部系统也联调好了之后,就可以进行切换的工作了。切换的话主要是涉及到了要保证不能停太久的仓库作业,又要准确搞定所有数据的对接。所以关键点就是先将数据对接搞清楚,仓库提前停止发货,然后盘点所有的数据,给出数据到双方,然后将信息推送到WS的系统,当做是一个初始化的结果。

有了初始化的数据之后,际客就可以推送订单信息到WS系统中,然后就可以开始正常的作业,当然中途还是发生了很多小插曲,这部分我们放在下文中来说。总体来说,只要前期的功能搞定没什么问题,那么切换的时候也就是一些硬件或者是适配的问题了,所以这一次的切换总体上来说是没什么大问题的。

切换后暴露一切问题

1. 外部问题

外部问题一部分是体现在际客内部没有沟通清楚,有一些新的流程,新的处理方式,他们的业务或者是处理的人并不知道,还以为是和原来的业务一样的处理方式,结果导致仓库作业受到了很多困扰。

除了操作人员的问题之外,还有就是程序上的BUG导致了仓库作业的问题,本来约定好用A模式可以完美解决,但是因为一些BUG,变成了B模式了,没办法大家只能尽快修改,然后导致耽误了仓库的作业时间,还好大多数业务来说其实都是用数据库的形式来搞定。

最后是一些业务需求太奇葩或者是不按规矩出牌,导致了系统其实不支持这种操作模式,但是客户那边非要这样处理,那么解决办法就是,要么妥协后期给他加上这个功能,要么就是拒绝他,让用户乖乖按照约定好的流程和需求来走。

2. 内部问题

内部问题算是家丑了,但是不可避免的是我们自己确实也有一些做的不够的地方,最明显的点就是效率没有跟上,导致最后的工期还没做完功能,只能走一步算一步地把核心东西丢上去,这样的话一些场景的代码都没有开发,自然用起来的时候就会出问题了。

除了功能没有开发完导致的BUG之外,还有性能缺陷,前期需求沟通不到位,测试不到位,业务场景梳理不够全等问题。

性能缺陷主要是指产品数据没有导入成功,19万的数据,但是花了好几天最后只导入6万条,导致作业的时候还是有一些问题需要手工处理;

需求沟通不到位是因为有一些东西经过了几个系统或者几个人之后,慢慢地失真了,大家的理解都有失偏颇,导致最后只能临时修改,索性不是什么大问题;

测试不到位一部分原因是时间不够,很多场景没有一个一个去模拟,然后就有一些遗漏在实际作业中就暴露了,还有一部分原因是测试人员对需求和业务的理解不够统一一致,导致测试的时候忽略了一些很关键的信息,然后就上到正式环境了;

业务场景梳理不够全,这部分主要是产品的问题,产品没有把握清楚核心的需求和业务场景,导致遗漏了一些东西让现场作业的时候发现这个东西压根没有解决方案,这一部分也给产品提了一个醒,让以后的产品工作要更加的全面,谨小慎微不出差错。

3. 问题就是迭代的激励

虽然大家都害怕遇到问题, 但是如果毫无问题出现,想必这种情况更加让人感觉害怕。前面说过了,在仓储系统这一块,产品是新人,没有经验也没有多少指导性东西辅助,都是自己探索。那么问题的暴露,就是产品收集需求并且加以迭代的动力源泉了。

这次去仓库线下支持,遇到了不少的问题,但是有一个东西让我感觉印象深刻,就是如果作为一个产品,很久没有去线下感受那种作业的情形,同时也没有实际去参与使用自己的产品,那么这个产品做出来的东西会越来越不踏实,越来越偏离实际情况。

当我做一个东西没有灵感或者不知道是否值得做这个时候,我就会去回忆当我在线下实际作业的时候,我观察到了什么,感受到了什么;当然这种感觉会越来越薄弱,越来越不清晰,所以我会让自己尽量多频次的去线下仓库,同时与线下仓库的人员接触,让他们反馈他们当下最真切的需求,这一部分对我做好WMS这个系统具有很关键的影响。

所以,我并不畏惧出现问题,因为问题就是我迭代系统的激励,我畏惧的是,一个重复性的问题一再出现,而我却没能解决好它。

最后一点点感触

随着做产品的时间一点点的累积,我想到的,看到的,写出来的东西也越来越多,也越来越全面。对于本次切系统来说,如果要从很细的角度和方向去阐述,那么我可能会有很多点子或者是感悟,我可能会有一些抱怨,一些遗憾,一些失望,也有一些惊喜和欣慰。但是如果从大一点的角度和方向上来说,这个项目是我工作生涯的一个铺垫,他只是有点难,让我有点难以应付,同时也让我感觉到沮丧,失落与无助而已,可是最终的结果还是好的,因为我最后还是搞定了这个东西。

对于一个项目,当我深陷其中,在意所有细节,思考所有场景,计较一切项目进度的时候,我是偏执且脆弱的,一旦我想要的东西没有按照我的设定来走,我会感到失落,感觉到彷徨,甚至会迁怒与别人。

但是这个项目做完了,却让我感受到,做产品不仅仅是那些条条框框的理论和方法论,更多的学问是如何与团队沟通协作。因为空有创意和想法,在这个时代是一文不值的,如何将自己的创意想法,通过更加融洽的方式,让团队一起协作我完成这个产品,最后交付给用户,这才是我更加需要修炼的东西!

「设计的目的不是为了好看,而是为了解决核心问题,好看只是解决问题的路径之一,而不是目的」,那么我也认为「产品有时候偏执,不是为了体现权利与自我,而是为了更加完美地解决问题而表达清楚自己的立场与要求,偏执也只不过是解决问题的路径之一罢了」

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%