管理ERP项目关键用户的需求变更.docx

精品资料，欢迎大家下载！管理ERP工程关键用户的需求变更如果让我谈对ERP工程的感受,我脑子里冒出来的第一个词就是“变更〞.似乎不出问题的工程不能称之为工程,无论什么类型的工程,唯一不变的就是“变化〞.业务〔或流程〕变更、工程成员离职等因素都有可能是工程范围扩散、进度延期、本钱超标、质虽下降的因素.乙方的工程经理往往非常害怕这类变更,由于一旦处理不好,工程就会失控,但现实情况是工程变更是常态.ERP工程实施过程中工程经理如何管理“变更〞呢？调整ERP工程经理的心态我在面试工程经理的过程中会问的一个问题是：你如何处理客户在工程验收阶段提出的新需求？相当一局部人的答案是：先和客户谈一下,能不做就不做.如果从企业方角度来看这个问题,我相信大多数IT经理的答案是：如果需求不做,我们一定不会验收工程.由此可以看到,工程变更往往事关甲乙双方关系.前面这些工程经理的答复反映了典型的乙方心态.为了工程的进度与回款,不加选择地对客户进行拒绝〔虽然有的时候拒绝得很有技巧〕,而乙方工程经理在采取这个方法解决问题时,往往没有考虑到客户满意度和工程质虽,对于最终结果来说工程只实现了单赢一一进度,而放弃了工程的双赢——质虽与进度.从客观角度来看,回避解决不了根本问题,如同前面所说,工程就是在不断的变更过程中不断推进的.即便是在项目的验收阶段客户提出了新需求,乙方的工程经理也一定要正视客户的需求,分析需求变更的原因,并对由此引发的相关影响进行评估,最终和客户明确应对策略.分析ERP工程变更类型工程实施过程中变更是正常的事情,但是否可以理解为工程变更就是一件合理的事情呢？首先要分析工程变更原因,然后根据工程的具体情况判定是否合理.工程中引起变更的原因通常有如下几类.范围变更〔What〕:工程要实现什么〔What〕发生了变化.比方说某ERP工程的试点原方案是深圳和广州,但由于业务开展需求,需要把北京纳入到工程中,这就是典型的项目范围变更.这一类的范围变更相对容易处理.还有一类的范围变更那么更为复杂一些,比方说原本工程约定梳理现有业务流程之后实现ERP系统的上线.但企业突然发现自己的业务流程不够清晰、岗位责任不明确、考核制度不完善,就想由乙方ERP参谋对企业管理进行诊断之后再实施ERP毕竟业务流程梳理也是ERP厂商的责任之一.这时乙方往往会认为这超出了ERP工程实施范围,涉及到了企业管理咨询的范畴,这类的范围变更是否合理,那么就需要看前期合同的约定了,但这无疑是许多ERP工程发生重大争议的原因.工程目标变更〔Why〕:为什么〔Why〕要做这个工程也就是工程目标发生了变化.在ERP工程实施的过程中,许多人以为工程目标只是老板一句话的事,而且这个目标往往非常虚,是落不到实处的,但却不知ERP工程的目标,是随着企业信息化进程的深入、企业高层对于信息化的认识的深入、企业外部竞争环境的变化、企业业务开展的进程动态发变化的.干系人变更〔Who〕:谁〔Who〕来完成这个工程有了变化.比方说由于工程小组成员离职导致的干系人变更,这种变更在工程实施过程中较为常见,在工程经理看来是在可控范围之内的变更.但还有一种变更让人头疼,如我们最近在实施的工程,乙方公司整体被收购了,该工程的出资方发生了主体变更,工程出现了重大的干系人变更,工程就只能进入暂停状态,未来是否能够重启还是未知数,这也是风险最高但概率最小的干系人变更了.工程主体变更〔Where〕:在何地〔Where〕完成工程的约定发生了变更.这类的工程变更较少见,但在集团化运营企业中还是会存在的,比方说我曾经实施的某工程：原本约定ERP工程的试点是在集团总部+北京公司,但后来考虑到ERP工程实施的风险等问题,就将ERP工程的实施只放在了北京公司.进度变更〔When〕:何时〔When〕完成工程的约定发生了变更.这也是工程中的常见变更类型,比方由于工程实施过程中企业有重要订单需要紧急交付,必须把ERP工程小组的关键用户都投入到业务生产中,而不再有精力顾及ERP项目实施工作时,企业方就有可能提出工程进度变更,从何使得工程延期完成.而进度的变更也往往受制于其它几类的变更,如干系人变更、目标变更、范围变更.需求变更〔How〕:如何〔How〕完成ERP工程实施工作的变更.需求变更对于工程所带来的风险相对于上述五个W来说要小许多,需求变更是在蓝图方案的框架之下讨论如何实现的问题,在这个环节更需要关注的是技术可行性、实现代价〔投入与产出〕等问题.ERP工程变更引发的后果基于上述不同的工程变更类型,我们需要思考工程变更给工程带来的后果.如果从工程管理的“黄金三角形〞来看,工程变更一般有如下几种后果一一工程本钱变化〔增加或减少〕：这里的工程本钱是指ERP产品模块的购置费用、ERP产品的用户许可费用、ERP参谋投入的人/天费用、甚至是由此引发的差旅费用等,而工程成本的变化往往导致工程双方重新进行商务谈判,基于上述基础签署补充协议.工程进度变化〔提前或延期〕：这是工程变更之后最常见的后果了,无论是哪种变更,导致的直接后果往往是工程进度延迟,而许多ERP工程就是由于一次乂一次的延期,最终在人疲马乏的情况下最终不得不宣布工程失败.工程范围变化〔增加或减少〕：工程范围不断扩散〔或者是变化〕的主因就是工程主体变更、工程目标变更或是项目范围变更,工程范围的扩散同时也可能导致工程本钱增加、工程进度延期.工程范围变化未必是件坏事,由于工程范围的扩散还有可能导致工程的质虽提升〔客户满意度提升〕.所以,不要对工程范围变化产生抵触情绪,凡事有利有弊,在工程上同样也是这个道理.工程质虽变化〔提升或降低〕：这一项为哪一项在工程变更之后大家提及非常少的一点,原因之一是ERP工程实施过程中的质虽标准非常难以衡虽,所以大家在谈到ERP工程变更的时候,可以很清晰地识别到范围、本钱与进度方面的影响,但质虽这块根本无论深入进去讨论.再者,在面临着强势客户的压力时,乙方工程经理面临着范围扩散问题,但本钱与进度层面得不到有效支撑时,就只好牺牲工程质虽了.制定工程变更流程与策略通过前文的讨论,我们已经清晰了ERP工程实施过程中存在的几类工程变更,以及由工程变更引发的后果〔或者是影响〕,那么我们可以据此制定一个工程变更流程与应对策略了.首先看看工程变更流程.提交变更申请：工程团队中的任何人都可以提交变更申请,对工程的变更内容说明包括变更描述、变更原因、变更利益、变更本钱、变更带来的影响、支持性文件.在这里需要说明的是,如果是企业方提出工程变更就一定需要说明变更所带来的利益和本钱支出；如果是乙方参谋在向ERP厂商提出ERP工程变更,其变更利益有可能就是企业方的变更成本支出,而乙方的变更本钱就可能是企业方的变更利益,其实这就是一个等价交换过程.审核变更申请：由变更经理对变更申请表进行审核,以决定是否需要一份充分的可行性报告以供变更审批小组做决策.识别变更可行性：决定是否变更的标准大致为实施变更给工程带来的风险、不实施变更给工程带来的风险、实施变更对工程产生的影响〔时间、资源、财务、范围等各个方面〕.批准变更申请：变更审批小组可以做出拒绝变更、需要与变更相关的更多信息、批准变更申请、在特定条件下批准变更等决策.实施变更申请：全面实施变更申请,包括变更进度、成本等工程控制基线,并按新的基线进行工程推进与执行.流程相关人员：上述流程中涉及的变更工作可以由工程中的变更经理来负责,ERP工程的变更经理有时需要由企业方的ERP领导小组成员来承当,需要对工程中所有的变更进行接收、记录、监测和控制.而决定是否接受变更,那么可以由变更可行性小组来决定,通常这个小组在ERP工程中也是ERP工程小组,其主要责任是通过模拟来研究变更可能带来的本钱、利益影响,对变更申请进行审核并给出专业意见.以上资料仅供参考，如有侵权，留言删除！。