标签:解决 计算机 客户 方法 稳定性 责任 就会 处理 三层
本人进入软件行业已经有5个年头了,主导实施和参与过的大大小小的项目有20余个。其中有些项目做的非常好,提升了客户企业的管理水平,也规范了企业的业务操作水平,优化了企业的流程,客户非常认同我们实施的价值;也有的项目实施效果一般,客户在应用软件前后没有明显的效果,唯一的成果就是计算机代替了人来汇总一些报表数据;还有的项目实施到一半便被叫停了。被叫停后往往会走向两个极端,一个是更换实施策略和方法重新实施,重新实施后最终效果有可能好也有可能坏。另一个极端便造就了所谓的烂尾工程,造成项目无法交付。
为什么在实施过程中有的项目就能做的非常好,有的项目应用效果就非常差?原因在哪里?下面本人就从下面几个方面进行分析:
1、什么是项目?
2、在ERP软件行业项目应该怎么做?
3、为什么项目会失败,失败的原因?
4、怎样最大程度避免项目失败?
1、什么是项目?
项目可以理解为是一种任务,个人理解项目一般包括三层含义,即:什么时间或周期、调用哪些资源、完成什么任务并达成什么目标;
项目的概念并不是只在软件实施过程中存在,其实现在各种各样千差万别的项目多种多样,如:对A企业进行产品的销售,这就是一个项目。其特点是销售人员通过一定时间面对客户的中高层通过对功能的演示和讲标,完成最终销售的目标;一个新产品的研发也可以视作为项目,其特点是是N个开发人员要通过N个月的研发完成一个产品的最终成形;如北京五环路的贯通也一个项目,其特点是多少个施工人员要通过多少天的奋战,动用多少的机器以完成道路的通车为目标;再如唐山曹妃甸要进行招商引资,招商引资也这是一个项目。项目的种类多种多样,在此不再举例。
2、在ERP软件行业项目应该怎么做?
1)严格制定项目的实施周期和计划及方案
在项目实施开始之前,一定要根据每个客户不同的情况,制定出相应的实施计划、实施方案并规划出实施周期来,这一点是非常重要的。没有实施计划就无法预知项目何时完成,使人找不到目标感,对于一个没有目标的项目来说这将是非常可怕的事情。
2)项目要获得甲方高层的足够重视
所有项目无论大小都应该获得甲方高层的足够重视,成功的项目往往都是企业一把手直接抓的工程。一把手工程的好处为:领导讲话具有权威性、下达指令后各部门执行力比较强、抵触项目推进的部门少。因此一把手项目非常有利于项目的推进。
3)严格的按照项目实施计划进行实施,并监控项目是否按照计划正在进行
实施计划制定后,双方人员都要按照既定的目标去努力,如果发现实施过程中与计划出现了偏差,需要马上对实施计划进行变更,并分析出现偏差的原因和改善方案,亡羊补牢精神是最可贵的。
4)对于大型项目可以分成几个阶段,按阶段进行实施
对于大型和超大型的项目,往往实施周期会有一年或几年。长时间的项目实施会使人找不到终点,因找不到终点而失去动力。而把项目分成几个阶段后,每个阶段都会制定出阶段性想要达到的目标,这样给人的感觉是距离项目的目标非常接近,工作也就有了动力。
5)与客户商定明确的需求和范围,确定项目验收的目标
实施范围的确定是实施过程中的重中之重,实施范围没有界定或界定模糊,会造成客户需求无穷无尽,需求不断增加的后果就是项目无法按期交付,甚至项目暂停或退货。为了避免这种情况最好的方法就是君子约定,在项目开始时就书面确认乙方做哪些内容,做哪些功能,达到什么样的效果后项目就可以验收,这样做对项目的双方都是有利的。再者一定要吃透需求,书面确定需求的内容,目前在实施过程中因需求双方理解存在偏差而导致项目返工的情况还是比较常见的,偏差太大的情况下往往会返工多次。
6)建立有效的项目沟通的机制,保证甲乙双方沟通顺畅
这种沟通尤其是在项目出现危机时尤为重要。
7)建立健全的文档机制
目前实施的大项目都是多个人共同协作来实施的,每个人每天做了什么内容,有哪些成果或针对项目进展有哪些规划等,除了自己之外其他人都不清楚。这样情况怎么避免?最好的方法是编写项目文档,每一步都要有操作文档来支撑,比如今天我对产品增加了某个功能、对哪些资料进行了完善、需要谁来协助哪些事情、对客户的哪个方案进行了更新。这些文档都要记录下文档的版本号是多少,是谁在哪个时间段更新的等,以方便项目组人员的协作;
8)项目组成员稳定性的保障,尤其是双方核心项目组成员的保障
一个项目要培养中一个合格的核心人员,需要这个人员不仅要对企业业务流程十分精通,还要对软件操作流程十分熟悉,并能够处理软件中常见的一些问题。而这样的人员的培养需要几个月甚至更长的时间。而如果在关键的时刻核心人员的离职会给项目的推进带来毁灭性的灾难。
9)明确项目奖励和惩罚制度
怎样避免人才的流失?怎样让员工对项目充满激情?怎么避免软件实施过程中员工的不公平对待造成的情绪化?(干多干少都一样)怎样最大程度的防止错误的发生?这些内容都要有一定的机制来保障和约束,那么最有效的方法就是建立起项目奖惩制度。
10)基础资料编码的规范化和扩展性规划
要盖一座高楼大厦就必须打好根基,对于ERP系统来说基础资料就是这座高楼大厦的根基,基础资料的重要性可想而知。
11)20/80原则
目前很多项目中20%的需求在实施和开发的时间占到了整个项目总工作量的80%,对于这样的需求要进行讨论再讨论,确定最优解决方案或屏蔽某些不重要不合理的需求。
12)业务流程反复测试和校验
任何产品都是存在BUG的,像微软这样的软件帝国都不敢说他的产品没有BUG,所以必须在实施方案确定后按照实施方案来跑产品,尤其是核心流程的反复测试和优化。
13)项目资源的保障
资源主要来讲还是人的保障,如果只购买了产品而没有人来实施和开发,项目不可能做好。
14)加强项目核心人员的培训和培养
客户方核心项目成员一但培养出来后,他就可以支撑起客户方业务的一片天,一些实施业务便可交由他来做。这样无论对客户方人员的成长及后续的维护都是有好处的。
15)基层操作人员的培训培训再培训
基层操作人员经常反馈的问题是产品不好用。为什么不好用呢,无非是操作习惯的变更和操作方法的问题。所以培训一定要贯穿项目实施的始终,改变操作员的习惯,认知我们的产品为企业带来的好处,不能用局限的眼光来看待产品。
3、为什么项目会失败,失败的原因?
当一个项目失败后,失败原因这个皮球往往就会踢来踢去。 销售人员说实施人员水平低、在项目上不努力、要是更换一个水平高的实施人员也不至于项目失败;实施人员说销售人员过度承诺、客户需求无止境、产品BUG多、开发团队的支持跟不上等,要不是这些因素,项目也不会这样子;开发人员说客户需求不明确,造成开发出来的产品改来改去,多次返工。
问题到底在哪里?到底是哪个环节出了问题?是单纯的某个人的责任吗?或者是单纯的某个部门的责任吗?答案是:“不是!”
那么问题到底出在了哪里?答案是:“甲乙双方各打10大板,双方都有责任!”
首先是客户方的问题:A系统上线之前业务的梳理和优化时业务部门不参与,上线后瞎起哄;B项目经理没有实权,下达的指令业务部门不执行;C各业务部门经理不重视;D核心目标及需求不清楚;E信息化基础弱,底子薄,没人来统筹管理;F新上软件后改变了基层操作人员的操作习惯,面对新的软件不愿意接受,提高企业管理水平对他们来说都天方夜谭; G 高层领导假重视和瞎指挥;H各部门的利益冲突;I团队核心成员频繁更换等;
其次是实施方的问题:A实施方团队更换频繁,我接触过的项目有的最多换了10任项目经理;B项目没有资源保证,实施人员今天3个人在现场实施,明天就有可能1个人单独奋斗了,拿1个人当3个人用;C销售人员为了签单和业绩,承诺再难的需求我们也能实现;D为了保证按时上线,在业务理解不深,需求没有吃透,理解了差不多的情况下就开始了实施过程; E同工不同酬,消极怠工;F项目经理控制不住客户的需求,导致客户的需求越来越多,产品很难交付;G产品BUG问题。
4、怎样最大程度避免项目失败?
要避免项目的失败必须从失败的案例中吸取教训,要从客户方和实施方两个方面着手:
1、客户方在上软件之前一定要先知道自己上软件要做什么?是为了充一下门面还是想达到一个什么样的目标,实现什么样的功能?
2、客户方高层必须重视项目,客户方项目经理在企业必须有权威或权力,能够保证每一项下达的指令各个部门都能贯彻执行;
3、客户方有一个稳定的项目团队,并有1到2个精通业务和产品的核心成员;
4、实施方在实施之前先评估项目情况,划出一个实施范围的圈圈来,确定验收标准;
5、三分软件七分实施,实施人员的水平对于项目的交付也有很大的关系,不一定要派出最好的顾问到客户现场,一定要派出最合适的顾问到项目现场;
6、按照计划来实施项目,按章办事,一步一个脚印的来实施,不要想一口吃成个胖子 ;
7、保持双方项目经理的持续有效的沟通,出现问题即时反馈并处理;
8、实施方人员的保证,坚决不能出现因为实施或开发人员不在现场而导致的暂停状态;
如果在实施过程中客户方和实施公司双方都能够达到上面所说的几点,我不敢说项目一定会成功,但项目一定不会失败!
以上就是本人从事ERP行业实施顾问5年来的一些项目管理经验,说的是否正确,仁者见仁智者见智,如有不同意见,欢迎予以指正和批评!标签:解决 计算机 客户 方法 稳定性 责任 就会 处理 三层
原文地址:https://www.cnblogs.com/ciey/p/10392747.html