艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢

  在ERP项目中,要做到在项目实施的未雨绸缪,不会出现亡羊补牢的情况就需要项目管理和实施人员在项目推进过程中队下面的阶段进行预测,把握好发展的趋势,掌握项目的主动权。下面就提出一些建议,供大家讨论。希望对大家有用。

  一、要考虑每一个项目阶段普遍存在的问题

  ERP项目可以根据项目进度,分为项目立项、需求调研、业务流程重组、模拟运行、并向运行、正式上线等几个阶段。其实不同的企业,虽然有各自的特性,但是也存在着一些普遍的问题。有经验的项目管理员,对各个阶段普遍存在的问题有深入的了解。此时他们就可以预先采取措施,针对这些问题采取应对措施。而不会等到问题真的发生了,再来解决。掌握各个阶段所存在的普遍问题就是做好ERP项目未雨绸缪的首要工作。

  如以业务流程重组为例,可能存在着如下几个共性的问题。

  一是企业对于自身的流程过于自信

  由于缺乏外在的参考,用户会认为自己所采用的流程是合理的,要求系统的安全按照自己的流程来走,排斥业务流程重组。针对这种障碍,实施顾问该如何应对?笔者认为,实施顾问应该将企业现在使用的业务流程与系统的标准流程进行对比,向用户说明如果继续沿用企业现有的业务流程,可能存在这些风险。利用具体的数据来说话,而不是片面的强调让用户遵循系统的标准流程。企业管理者上ERP系统也是为了改善企业现有的管理水平。如果他们能够切实的认识到现有业务流程存在的漏洞,相信他们能够欣然的接受新的流程。

       二是新流程的从接受到熟悉需要有一个过程

  企业使用了ERP系统的新流程之后,由于不熟悉等原因,比较容易出差错。如果实施顾问能够意识到这个问题,那么就可以采取一些未雨绸缪的措施。如在模拟运行时,会有针对性的多设计一些新流程的业务。让用户多操练几次,以熟悉新的流程。在后续并向运行时,也会指导项目管理员,多多跟踪这些新的流程,以督导用户按新流程来操作,避免旧病复发。

       三是提醒用户更改原有的管理制度

  通常情况下企业在上ERP项目之前,已经有完整的业务流程文档。在实施ERP项目时,如果对原有的流程做出了新的调整,那么就一定要及时调整原先的业务流程文档,做到读、写、做一致。以免在后续培训时,出现互相矛盾的地方。

  以上提的这些内容都是在业务重组环节中容易出现错误的事情。项目管理员只要能够意识到这些内容,那么就可以在项目实施环节中,采取预防措施来避免这种情况。现在不少ERP软件提供商提出了标准化实施的口号。其实其核心的内容就是将每个环节必须要做的内容以书面的形式规定下来。与笔者谈的思想是一致的。

  二、与用户沟通时可能存在误解

  人与人的沟通,由于文化背景的差异,往往会存在误解。A说的话,B听起来可能是另外一种含义。在日常生活中,这种情况也非常普遍。针对这种情况,实施顾问或者项目管理员,应该采取什么样的未雨绸缪的措施呢?笔者认为可以采取如下应对措施。

       一是尽量采取更多的辅助证据

  如在需求调研过程中,用户会提出各种各样的报表要求。如果只凭用户说,实施顾问记,可能记不全,或者会对用户说的内容存在歧义。此时就应该采取更多的辅助证据。如用户已经有现成的报表了,那么可以像他们要一份。如果没有的话,那么可以让用户先在Excel表格中设计好然后再给我们。有时候用户说了一个小时,说的口干舌燥,还不如一份表格能够说明问题。

       二是说完后让用户进行重新确认

  在收集用户的需求时,即使对于同一个问题,大家你一言、我一言,会提出各自的需求。但是有可能会有相互矛盾的地方,或则说可能某些内容还没有考虑到。笔者在进行需求调研时,会将用户的需求都一五一十的记录下来,整理好。然后再让用户去签字确认。

  用户在签字时,会对自己所说的内容再梳理一遍。有不准确的地方可以进行及时修改或者有歧义的地方进行再次确认。这就相当于一个审核的过程。通过这个确认,可以在一定程度上消除沟通上的误区,让实施顾问了解用户内心的真实意图。

  本文中主要提出了关于ERP项目管理和实施的两大条建议,希望对大家有一定的帮助。

时间: 2024-11-26 10:48:41

艾伟也谈项目管理,ERP项目实施要未雨绸缪不要亡羊补牢的相关文章

艾伟也谈项目管理,敏捷实施中的常见错误

一些评论员写下了敏捷实施中一些常见错误和反模式.他们贴出了"Top X"列表,列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误. Target Process的Michael Dubakov写了两篇博文:"10个敏捷实施中最常见的错误"(Part 1; Part 2 ).他认为"许多公司在敏捷实施中再三犯同样的错误." 他的常见错误列表如下: 1. 从一个工具开始敏捷开发是不同的.一个工具不会立刻产生影响,不会由于这一工具的存在而解决多

艾伟也谈项目管理,项目经理成长日记(4)——态度决定一切

超仔刚刚推门进来,屁股还没有碰到他的椅子上已经让人感觉到他欢喜轻飘的神色,我抬头望着他眼睛,神色中洋溢的满是欢快.我看着他那兴奋的样子,微微笑着问道:"签完了?结果还可以吗?" "还不错!" "能满意就可以,继续努力." "嗯." 我知道超仔刚刚和公司签了新的合同,在新合同里他的工资有了一定的提高,这些都是因为对于他去年的绩效考核成绩还不错应该得到的结果. 年底对于我来说,可真是多事之秋,因为我需要在年底前完成对我团队这些人的

艾伟也谈项目管理,项目经理成长日记(7)——说是细,做的粗

估计绝大部分的公司都在提倡一个口号:"注重细节."但是往往是口号容易喊,行动却是千辛万苦,何谓细节?也就是自身工作的每一个环节.每一道流程的琐碎小事,而这些小事又常常容易被人忽略.有很多人有雄才大志,内心中充斥着舍我其谁的非凡气魄,但其眼高手低,小事不屑,大事难成,最终只落得一事无成的悲哀. 软件开发亦是如此,提倡了许久的注重细节,更有甚者许多公司标榜自己的优势在于:"我们更注重细节."然而如果说我们要做到和自己提出的口号一致的时候,我们该如何去做?该做什么的事情才

艾伟也谈项目管理,项目经理的思维批判

想做好项目经理,就一定要改变你的思维方式.这对于技术出身的朋友尤其重要. 清末人们自以为天朝,他国皆为蛮夷.结果如何呢?丧师辱国,自己沦为病夫.其根本莫非自己脑筋不对头?后来又搞洋务运动,以为洋人只是工具好,其他都不如我们,师夷长技以制夷就可了.而事实却告诉我们,感情我们又错了. 做技术出身的项目经理,就仿佛清末的国人.技术第一的概念已经深入骨髓,说是做管理,其实还是把自己的技术看做天朝上国,管理当做蛮夷丑类,或者只是把管理当做一种工具来学习学习.这么做,果真能做好项目管理吗? 从技术走向管理是

艾伟也谈项目管理,项目经理要如何看待技术?

当上项目经理后,技术人员往往对自己的定位失去了感觉.其中最令人困惑的就是自身原有的技术标签,撕了也不是,因为技术还不能丢,贴着也不是,因为个人的成败往往决定于自己对团队的管理,而不再是自己的技术. 想要从这种困惑中摆脱出来,首先就要搞清楚下面几个问题: Question 1--项目经理职位对技术到底有什么要求? Answer: 想把项目管理工作做到点子上,两个观点要明确: ①技术不是必须项.项目经理个人技术很重要,但这不属于必须项,属于有了更好的东西,当然越高越好.因此,在工作中,固然出任项目经

艾伟也谈项目管理,项目的故事

这是关于一个项目的故事,与其它项目相比,既不非常复杂,也不是很简单: 一个应用程序与数据库以及其它两个系统通信.这在技术和架构角度都是主流,而在管理角度则是标准情况: 所有工作都应该在昨天完成,但还有很多没有完成的.简而言之,"这很难!" (这是开发者经常表达的一种情绪,但是谁都不会太大声地把它喊出来.) 为此我们创建了团队.雇佣了四十位员工并指定了他们的角色.我们把团队分为小组,并在不同的小组之间设置了一种契约.每个小组负责应对特定类型的要求.这样就形成了要求的流程.指定的小组会承受

艾伟也谈项目管理,项目经理要向唐骏学习

中国人性喜围观,然而在中国,大部分新闻并没有围观的价值,这未免让人失望.但是,只要是加上"唐骏"这个名字,新闻总是能让我们围观者觉得值,觉得得到某种满足,从这一点上来讲,唐骏牛!真的很牛!! 这一次,唐骏给大家带来的是"假文凭事件",整个事件的发展,真是一波未平一波又起,可谓波澜壮阔,最后发展成为事关"诚信"的大事件. 我不得不说,唐骏,你太牛了!!! 唐骏本身并不是坏人,也不是没有能力,到现在我还十分佩服他.而且我还想维护他,因为事情发展到现在

艾伟也谈项目管理,项目做完了,总结一下

在连续封闭N个月以及再后来的N个月的加班后,项目终于以延期N个月的结果结束了.不管曾经发生过什么,不管项目是否延期,重要的是项目结束了,所有的项目成员都可以松一口气了.曾经和同事开玩笑说:在我经过过的失败项目中多了一个项目,以后就能避免同样类型的失败了.同事们听了,都笑了.在那段时间里,很久没有听到过同事们畅快的笑了. 现在,我以我目前的知识水平,总结一下项目中存在的问题,这些问题的出现也不是一两个因素造成的.当然,专业水平太低,也总结不出什么高深的内容.不管怎么样,也算是对项目的总结吧.这里先

艾伟也谈项目管理,项目时间估算

大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来.到了企业之后,实际时间是估算时间的两到三倍也是很正常的事,这还是在需求明确到85%以上的情况下,需求不清的情况下,时间就海了去了. 项目开始时,客户简单的描述需求,开发方便豪言壮语一个时间(有时这个