KB奇遇记(9):艰难的上线_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > KB奇遇记(9):艰难的上线

KB奇遇记(9):艰难的上线

 2017/1/30 5:32:58  梦心  程序员俱乐部  我要评论(0)
  • 摘要:经历了非常多的磨难,系统也“如约“在2017年01月01日勉强上线了。尽管我认为它还不到上线的程度,条件不具备,但上头的指令下来和计划便是在这一天。整个上线过程从2016年3月8号开始到上线日,扣除中间荒废无为的1个月半,实际上实施的周期只有7个月半。当然,这实施周期并不算短,但要是考虑到2016年10月1号上了OA系统,期间还有地磅系统,条码系统上线;除此之外还有信息部各种系统要维护如一卡通,机房,电脑管理,加密系统等;还有甲方乙方两边项目团队人员严重不足,素质不佳
  • 标签:上线

      经历了非常多的磨难,系统也“如约“在2017年01月01日勉强上线了。尽管我认为它还不到上线的程度,条件不具备,但上头的指令下来和计划便是在这一天。整个上线过程从2016年3月8号开始到上线日,扣除中间荒废无为的1个月半,实际上实施的周期只有7个月半。当然,这实施周期并不算短,但要是考虑到2016年10月1号上了OA系统,期间还有地磅系统,条码系统上线;除此之外还有信息部各种系统要维护如一卡通,机房,电脑管理,加密系统等;还有甲方乙方两边项目团队人员严重不足,素质不佳,每周顾问只来3天;甲方项目经理还要提防不懂技术的人背后在领导耳边吹风等伎俩,这些诸多因素的考虑进去,其实这7个月半的时间里实际上是很短的

      按之前我上项目的经验,蓝图汇报之后会做需求的客制开发,之后就是各种单元测试,到最后也有必经之路的集成测试。这集成测试就是针对企业各种业务模式,模拟实际上用户作业的方式从需求源头开始,每个部门都会处理,业务一直流转到后续财务端开票和结算成本等,也是一次非常重要的职责明确和规模最全的业务测试。但是在KB公司,居然把这么重要的环节给漏掉了!只有让“兼职”关键用户过来模拟本部门的操作流程,仅此而已。关键用户根本就不知道他做的这个东西有啥用,前后业务有啥串接,更别说对业务和ERP模块有很清晰的认识。这些情况的出现也跟“兼职”有关!

      ERP项目组并没有召开所谓的上线切换会议,制定切换策略,包括基础和未清数据导入计划、在制品处理、成本滚算、开账、基础数据缺漏补录方案、基础设备准备等等,还需要发布一份上线公告。上线动作是整个ERP项目的实施的最后环节,上线策略好坏决定了ERP上线期间的质量。过去的项目中对这个环节是很重视的,甚至需要跟高层做开会研究决定,列出可能出现的情况并逐一约定解决。但是在KB公司的上线里,并没有这个环节。顾问们只是在QQ群里跟关键用户互动而已,在现场只是跟信息部IT做沟通,根本没有一份非常清晰明确的上线计划文档,让我觉得很吃惊。很多时候,除了我,其他IT和关键用户,甚至包括甲方项目经理都摸不清楚顾问的想法。

      于是乎,2016年12月31日那天信息部和顾问都留下来加班,但是关键用户基本上都缺席了,特别是生产的。加上之前培训效果并不理想,所以导致了这次上线的时候很多用户根本就没有办法处理。2017年01月01日ERP算是正式上线了,但暴露的问题非常多,比如客制程序错漏很多、生产模块业务流程问题、报表打印问题、跟OA系统对接的问题、库存和基础数据不正确、APP条码错误等,这些其实可以在实施周期预测得到并解决的,很遗憾,甲乙双方均没有效规避,特别是乙方顾问,上了这么多的系统,按道理来说经验极其丰富了,没想到他们如此的不上心,也可以侧面说明他们能力水平并不理想。上线一周内暴露了非常多的问题,而乙方的项目经理居然不在场,也是让我觉得完全不能接受的。虽然每天上班结束之后我都会去收集暴露的问题明细,但并没有再开一次会来每天总结和处理问题。因为很多时候问题并不是IT和关键用户可以解决的,需要上升到项目层面。比如生产模块的玻璃换包装的问题,木箱换裸包的业务当初顾问就是没有考虑到,但实际上发生了这个业务的时候,顾问并没有很尽心去补救,反而模棱两可,给出一个让人很难接受的方案来,根本没有经过很严格的推敲和测试。很多方案的制定太随意了,然后随意在后台随意修改数据,跟SAP系统的严谨性形成两级对比!还有一个比较大的问题就是库存值一直不准,因为生产连续性的特点,不可能停线,所以库存一直在入,一直在出。所以手工帐越来越多,到最后就要每天一直在补数据。库存值不准导致了销售那边出货的问题。

      开始顾问还会加班,但一周之后居然缺席了,但那个时候问题还是很多的。顾问们居然周末也放假休息了,只留下一个根本没有带过项目的顾问在。而上线期间里,顾问支持度也不够,拿技术开发人员当业务顾问使唤。记得在QM办公室,一个技术人员跟QM的关键用户就打印软件的合理性做讨论。严格来说,项目组顾问连需求都没有调研清楚,但那个技术顾问只会说有问题请找项目组顾问,对QM关键用户提出的很多合理而明确的需求视而不见。我真心觉得,资深的技术开发顾问在业务水平上还真的远远不如一个关键用户呢!

      至今回想起来,上线过程还是挺惊心动魄的,真的一度认为它要上不去了。你或许体会不到当顾问们都缺席不在场而销售、生产、质检、库存那边问题一大堆暴露出来的绝望。这种系统上过一次就真的不能再碰了,在做SAP起家的我,对这种系统的严谨性深深表示鄙视!这次艰难的上线给了我很多警示,除了对顾问的挑选之外,对系统的选型也是非常的重要。

发表评论
用户名: 匿名