KB奇遇记(6):搞笑的ERP项目团队

早在我们来之前,KB公司这边就已经组建了ERP项目组了,当时IT就仅仅有一个人。属网管出身。而关键用户分两种类型:专职关键用户和兼职关键用户。

专职关键用户组织结构上已经调动到信息部,常驻在项目组里工作。財务模块2个人,採购模块1个人。其它模块没有。兼职关键用户平时都是在各自部门里,平时该做什么还是什么。仅仅有ERP项目组有须要的时候才会让他们过来处理一下,几个小时之后然后就回各自部门了,每一个模块大概有1-2个人员组成。

后来我们入职了,開始扩充人员。因为KB公司极度压缩ERP项目的成本。连人员招聘都非常的困难。非常难得到批准,開始还能同意招有经验的人员,后面仅仅能考虑招经验较少甚至应届生的人员。到后来干脆不让招人了,仅仅能考虑从PC维修和网管里面内招。在2016年1月份的时候甚至还出现了要裁掉ERP项目组成员的现象,好在我们极力反对才作罢。ERP项目都还没启动呢。就要出现裁人的现象,也是醉了。因此到项目启动时,人员基本上稳定下来了。

信息部人员结构为:1个项目经理,1个信息副经理,4个开发者。3个关键用户。

在这4个开发者里,2个是从PC维修调过来的,1个从来没有接触过软件编码工作,1个有一些软件开发的基础毕业1年的人。

按道理来说。ERP项目组里也要有对应IT来负责对接模块的实施。这些IT至少须要有2-3年的经验,特别须要有业务经验。

但遗憾的是这些工作都被几个开发者给“兼”了,而经验比較足的项目经理和信息副经理尽管能够管几个模块。但毕竟精力有限。除了ERP项目组的事情,还要管其它项目如一卡通、加密系统、HR等以及本部门的管理工作。KB公司基本上非常多人都不愿意加盟到ERP项目组来。他们会觉得这样在本部门就失去了岗位和地位。觉得到ERP项目组里工作属于浪费时间。他们事实上没概念的是非常多ERP顾问都是业务出身的,比他们在本部门所得到的待遇高多多了。

以上就是ERP项目组人员组成,整个ERP组织架构最上头是ERP项目组组长,接下来是ERP项目组副组长。接下来是ERP项目经理。中间是由总经理级别的人员组成的管理团队。然后就是流程制度指导组,基本上都是由副总经理级别的人员组成。之后才是IT部。每一个模块的“兼职”关键用户。

内部的项目团队组成大概是如此,而乙方实施ERP项目的团队的组成也是非常奇葩:1个项目经理,1个前端业务实施顾问(负责销售、採购、生产、仓库、项目、设备模块),2个財务实施顾问,若干个开发顾问。

这样奇葩的ERP组织架构给兴许ERP项目的开展带来非常多的困难,主要问题有:

一、并不是一把手project:

流程图签核、业务方案制定、蓝图审核、物料主数据和编码等决策事项ERP项目组组长和其它人均无权限,而是要汇报给总裁做决策。

而跟总裁开会是要预约和开大会的那种,开会之前也要准备非常多的东西和文档。

这本身就给项目的推进带来非常多的困扰。我们常常说ERP项目一定要是公司一把手来直接负责,能够更方便调动各方面的资源和人员共同參与。但在KB公司里面,让“兼职关键用户”过来讨论流程常常性缺席和迟到。到兴许系统单元測试和模拟的时候,让“兼职关键用户”过来的时候他们都非常有怨气,非常排斥操作手冊的编写。非常多业务部门的主管高管根本就不把ERP项目当回事儿,在他们眼里,仅仅有自己的本模块的工作才是最重要的。ERP项目仿佛就是信息部自己的事情。他们仅仅是来帮忙的。

这就是非一把手project带来的灾难,非常少人重视。大部分都不当一回事儿。

二、内部团队组成不合理:

实际上关键用户并没有“兼职”和“专职”之分。

上ERP系统,都是要从每一个部门抽调课长级别或对应资深专员级别。在本部门至少工作了3年以上的1-2个人来组成关键用户。从头到尾跟着项目组一起实施,遇到流程、业务等问题可以及时沟通,充当ERP项目组和本模块高层沟通的桥梁。

关键用户还必需要非常精通本部门本模块的绝大部分的业务,可以有专业合理的眼光来审核业务的合理性,可以提出改善意见。

而现在KB公司内部的其它模块的关键用户比方SD,PP等都没设置。绝对是非常不正常的事情。

在整个实施周期里,除了財务和採购这两个“专职”关键用户之外,其它的模块的人就仅仅有通知他们过来他们才会过来。因此到实施后期这些人基本上都不懂系统操作,不懂业务实现方案。甚至连开发的程序都没測过一次,操作手冊根本写不了。也谈不上兴许怎样培训终端用户了。

而信息部成员设置方面。人员明显捉襟见肘,特别是经验丰富的人员。

没办法完整分配相应模块的IT,开发能力严重不足。在实施后期仅仅能将部分开发转移到乙方开发顾问身上,又导致项目预算超标,这个是很艰难无奈的事情。

三、乙方团队组成不合理:

不知道是不是由于预算的原因。乙方的顾问设置竟然仅仅有1个前端业务顾问,1个財务顾问。销售、採购、生产、仓储、项目、设备就一个顾问在负责,基本上属于忙只是来的那种。更奇怪的是也不知道是不是由于项目预算问题。乙方实施顾问一周基本上来个3天左右,项目经理一个月都未必会来1天。平时和周末不加班。按我们之前做项目的经验,每一个模块都会有1-2个常驻的顾问在,一周5天,每天8小时,平时偶尔会加班,到后期周末更会加班。

在项目实施后期3个月里,乙方財务顾问总的来的天数不超过5天,基本上都是远程实施,简直前所未闻。这样导致了内部財务关键用户连开账怎么开都不懂!

而乙方项目经理,连上线的日子都没有过来看一眼。

后面暴露出许多的问题,本来须要他过来统筹规划协调处理。结果他仅仅来了一天。开了一次总结会议就又走了。

而甲方这边的高层和中层管理,在ERP上线的那段时间(2017.01.01)里基本上所有都休假去了!

无论项目死活!

或许一切艰难的根源都能够归结为项目的预算问题。钱没给到位,乙方实施公司自然也不会把项目放在重要的位置,派不出顾问也是正常。

也能够间接归结为公司高层对这个项目的重视程度,大部分都觉得这项目是信息部的事情。没人会在意和重视。ERP项目实施到中后期開始觉得很的艰难。之前排的计划一直Delay下去。甲方项目经理根本无力力挽狂澜。

写到最后,我想说的是,既然KB公司对这个项目这么不重视,给的预算和人力支持也不够,那何必要花这么多钱来上这个项目呢?不仅伤財还劳民!

更可怕的是,ERP上线了,做得不好但是会连累整个公司的业务正常运转。

所谓“慎始善终”,本来就没有慎始。何来善终?

时间: 2024-10-12 12:55:36

KB奇遇记(6):搞笑的ERP项目团队的相关文章

KB奇遇记(7):不靠谱的项目实施计划

在ERP项目启动前期,项目组两方项目经理和我等几个人单独跟总裁开会,讨论了初步的ERP实施计划,本来第一期上线只是考虑上其中一家工厂而已,结果临时加入了深加工的工厂.本来项目组预定计划是2017年1月1号上线的,结果到总裁那边就被裁定为2016年11月1号,足足提前了2个月.同时第二期上线要在明年半年的时间里上线剩余的分出全国不同地区的六家子公司,其中一家还是在海外.很惊讶的是甲方乙方的项目经理均对总裁提出的ERP上线日期并没有提出什么交涉和异议. 在我看来对于一家没用ERP系统,全部手工Exc

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

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

KB奇遇记(5):奇葩的用人制度

8月份入职,公司不给我们正式任命,导致了我们开展工作困难重重,基本上很少有人会鸟你,做事仿佛名不正言不顺.哪怕你是未来信息部的老大也一样,网管们根本不买你的账.所以做ERP选型,做旧OA的选型以及加密系统的评估都没有什么权限,也得不到很多应有的资源.后来我才发现KB公司的用人制度很奇葩:每年年末开一次年会,重点讨论来年的人事任命,并在年初对所有的管理干部重新做一次任命.也就是说今年你是总字辈,到明年就不一定了.而且人事的任命一般是一年期限,如果有新人半路入职,那他的任命也就是到当年的12月31号

KB奇遇记(4):困难重重的选型

在以往的工作经历中,虽然也会出现公司的一些规章制度,但我鲜少与其打交道,也极少听说.但是来KB这里,突然发现公司居然并没有给我配备电脑!!原因是制度上并没有写IT人员入职需要配备电脑,尔后通过特批流程才申购了一台笔记本,此时我已经入职了半个月了.这半个月期间里我一直用的是我自己的电脑,因为加密系统的缘故,我既看不了文档,也登陆不了OA系统,基本上没啥作为.后续有新同事入职,只能在OA上申请借用电脑的方式来使用,一旦你需要申购电脑,就要跑很长的流程,特别是对价格的审批,这一点后续会重点讲到. 我们

KB奇遇记(3):IT现状

2015年8月3号,终于告别了过去来到了KB. 公司给安排的住房是一间套房里的小房间,小的简直连坐的地方都没有了,中间一个大床将房间隔了两边,显得特别狭小.由于是刚来,我也不好要求太多.但就这个小房间,我几乎住了快一年! 尔后上班,终于了解KB公司的糟糕的IT环境,简直难以想象:  1.垃圾HR系统: 这个HR系统是用的ASP.NET系统,没有提供源码,公司内部IT没有介入运维.每当人事部门有新需求的时候就会委托厂商远程连接到服务器上做相应的调整,每年都会缴纳好几万块钱的维护费用.而这HR系统只

【BZOJ】【3157】&【BZOJ】【3516】国王奇遇记

数论 题解:http://www.cnblogs.com/zhuohan123/p/3726933.html copy一下推导过程: 令$$S_i=\sum_{k=1}^{n}k^im^k$$ 我们有$$ \begin{aligned} (m-1)S_i &= mS_i-S_i \\&=\sum_{k=1}^n k^im^{k+1}-\sum_{k=1}^n k^i m^k \\&=\sum_{k=2}^{n+1}(k-1)^i m^k-\sum_{k=1}^n k^i m^k \

bzoj3157国王奇遇记(秦九韶算法+矩乘)

bz第233题,用一种233333333的做法过掉了(为啥我YY出一个算法来就是全网最慢的啊...) 题意:求sigma{(i^m)*(m^i),1<=i<=n},n<=10^9,m<=200 别人的做法: O(m^2logn),O(m^2),甚至O(m)的神做法 学渣的做法:矩乘+秦九韶算法,O(m^3logn),刚好可以过最弱版本的国王奇遇记的数据 (极限数据单点其实是1.2s+,不想继续卡常了-bzoj卡总时限使人懒惰-如果把矩乘的封装拆掉可能会快点吧,然而人弱懒得拆了...

linux内核奇遇记之md源代码解读之十五bitmap原理

转载请注明出处:http://blog.csdn.net/liumangxiong 为人不识陈近南,走遍江湖也枉然.做raid不识bitmap,通通都是走过场. 那么bitmap究竟是何许人物,能够在raid5的场子里混得风生水起呢?话说最早raid5是没有bitmap这位门客的,突然有一天跑raid5的系统异常掉电了,客户发现异常掉电之后再写数据就出现了数据不一致的情况.查来查去发现raid5本身设计就有一个缺陷:raid5每次写至少要写两个磁盘,写过程中异常掉电的时候就会发现一个磁盘写完成而

linux内核奇遇记之md源代码解读之十四raid5非条块内读

转载请注明出处:http://blog.csdn.net/liumangxiong 如果是非条块内读,那么就至少涉及到两个条块的读,这就需要分别从这两个条块内读出数据,然后再凑成整个结果返回给上层.接下来我们将看到如何将一个完整的bio读请求拆分成多个子请求下发到磁盘,从磁盘返回之后再重新组合成请求结果返回给上层的. 4097 logical_sector = bi->bi_sector & ~((sector_t)STRIPE_SECTORS-1); 4098 last_sector =