MES实施中最可怕的是需求变更!

​​转载:http://www.51testing.com/html/00/n-3725700.html

  辛辛苦苦熬了几个月的通宵,终于确立了MES需求,规范了工作流程,系统配置也完成了,正准备按部就班MES系统上线时,企业用户突然改变了需求,不想这么做了,提出了新的需求。

  对于MES实施顾问来说,正如晴天惊雷,这也是所有MES顾问最感到恐怖的事情。因为有时候,用户只是简单的一句话,但是对于系统的调整来说工作量是非常大的。

1、需求变更:迁就or拒绝?

  从MES项目立项开始,需求就是MES实施顾问的心头之痛。随着对MES的深入认识、项目环境的变动,企业内外部多种因素都可能使客户对MES的需求不断改变。如果不能有效处理这些需求变更,项目实施进度必将一再调整,上线日期也会随之一再拖延,项目成员的士气也将越来越低落,严重的还会直接导致MES项目失败。

  需求变更,本应是客户的权力,但也是实施顾问的为难之处。如果确需变更,当然要满足客户需要。问题是不能让变更权力滥用,把一些无关痛痒的变更宠惯养成堂而皇之的变更。例如,我曾经在某MES项目中属于“谦虚型”,对于客户提出的变更,无论大小都给予解决,客户对此非常满意。然而,项目进度却拖得很长,项目一再延期。相比之下,在另一个项目上我显得稍有些“盛气凌人”,对于客户提出的需求变更,大多都不予理睬,客户对此不是很满意。不过,该项目的进度控制得较好,基本能按期完成项目。

  按后一种“盛气凌人”的做法,对客户的要求一概不理,自顾自地按照最初的需求和计划实施,很可能会由于没有用户的参与,使得MES系统与用户的需求相差甚远,导致验收通不过,收不回尾款而使公司利益受损。对于客户来说,达不到需求的满足也浪费了投资。事实上,客户不满意,则项目就不算成功,实施顾问辛勤劳动最后就只能落得个“没有功劳,只有苦劳”的份。

  但按前一种“谦虚型”做法,完全顺着客户的意见走,客户满意度就一定会高吗?其实也不一定。由于需求变更会带来工作量的大量增加,甚至可能会出现大量的无效劳动。而且,频繁变动的需求也会导致实施质量下降,留下许多隐患。因此,一味的迁就用户将会使进度一拖再拖,实施方案一改再改,变更越来越多,士气越来越疲,公司越来越不满意,用户越来越急。到最后,实施顾问会发现这个项目已经成为了一个“不可能完成的任务”。

2、需求变更为什么总是做不完?

  在MES实施过程中,实施顾问所要面对的将是一系列和多方面的考验。经常发生而又最令人头疼的恐怕就是需求变更了。客户变更需求是MES项目与生俱来的特性,也是一个无法避免的事实。需求变更的表现形式是多方面的,如客户临时改变想法、项目预算增加或减少、客户对功能的需求改变等。它会导致MES实施过程中成本增加、进度拖延等风险,而且越往后的变更产生的风险将越大。

  以笔者参与的多个MES实施项目的实际经历来看:需求变更泛滥是非常可怕的事,尤其是到了项目实施后期,客户不断对移交的MES系统提出修改意见,甚至有时刚刚重新完成的更改,客户又要求改回去或改成另一种模式。需求变更越来越多,实施顾问只能疲于应付。“无底洞”是大部分实施顾问进行MES项目的共同感觉。

  实施顾问作为项目的承担者,在规定时间内利用有限资源保质保量的完成项目,让客户和公司都满意是最终目标。但是让客户满意就是不断满足客户无穷无尽的需求吗? 我们分析一下出现需求变更的根源:

  ① 合同签订马虎,没有真正明白客户需求

  签订合同时缺乏对客户需求认真对待,导致需求描述不清,为后期的实施工作带来困惑。MES销售顾问为使客户能够快速的签订合同,往往草率决定和片面同意客户提出的需求。当客户提出新的需求时,往往是销售顾问一看“应该”只是一个小小的修改,没有太大的影响,所以直接答应能变更。

  该问题的关键是合同签署的太烂,没有把需求明确再签合同,而且也没有把需求变更的流程写入合同。如果在合同时把客户需求弄清楚,后期就根本不需要频繁的变更需求。签订合同时明确定义项目需求的范围,可以为以后各项实施工作的开展奠定深厚的基础。

  ② 研时没有深入理解客户需求

  在MES上线前的需求调研分析阶段,项目组成员和客户的深入交流是减少频繁需求变更的关键阶段之一。但是由于双方的误解通常使需求交流难以进行。更严重的是,实施顾问只根据用户提出的描述性、总结性的短短几句话去制定实施方案,没有真正挖掘和按客户的需求去制定实施计划。当客户头脑一热或领导一拍脑袋提出新的需求时,实施顾问往往也就不能区分客户真正需求和镀金需求。如果项目组对客户需求的细节了解不充分,双方对需求的理解就会产生差异,就会导致移交MES系统时才使问题暴露出来,客户只能频繁的提出需求变更。

  ③ 没有明确的需求变更管理流程

  没有明确的需求变更管理流程,就会使需求变更变得泛滥。并不是所有的变更都要修改,也不是所有变更都要立刻修改,需求变更管理的目的是为了决定什么类型的变更需要修改和什么时候修改。

  比如MES界面风格问题,就可以先不修改,或者规划一下修改的时间待到以后进行优化。另外,对于核心模块的修改没有严格把关流程,有些小需求看起来工作量不大,但是实际上实施顾问和开发顾问要耗费比较长的时间去完成这些销售顾问或者客户没有考虑到的细节问题。

  ④ 没有让客户知道需求变更的代价

  对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的,应该要评估变更的代价和对项目的影响,要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价,对实施顾问的辛苦就会难以体会。在评估代价过程中,可以请客户一起做判断:“我可以修改,但您能接受后果吗?”。

 3、如何有效控制需求变更?

  需求变更对项目成败有重要影响,既不能一概拒绝客户的变更要求,也不能一味地迁就客户,所以实施需求变更之前必须做好控制。例如授权、审核、评估和确认,在实施过程还要进行跟踪和验证。有句通俗的话说得非常好:“需求变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。”

  用户需求的变更总是不可避免的,所以我们要以积极的心态去接受和控制用户的需求,而不仅仅是埋怨。对待客户频繁的需求变更,应采取有效办法应对,避免事态蔓延,不让客户养成随意变更的毛病。

  ① 合同约束

  需求变更给MES实施带来的影响是有目共睹,所以在与用户签订合同时,可以增加一些相关条款,如限定用户提出需求变更的时间,规定何种情况的变更可以接受、拒绝或部分接受,还可以规定发生需求变更时必须执行变更管理流程。

  虽然MES项目合同很难在签订之初就能够精确定义每项需求,单靠合同是帮不上忙的,但也不能忽视合同的约束力。有一个笑话,就是许多销售顾问都开玩笑说他们都是清政府。为什么是清政府?清政府的特点之一就是丧权辱国的条约太多。

  ② 建立需求变更审批流程

  要明确需求变更审批环节、审批人员、审批事项、审批流程等。目的有两个:一是将客户下达变更的流程尽可能地规范化,减少张嘴就来的非必要、非紧急、非合理、非高层领导意图的“无效变更”。二是留下书面依据,为今后可能的成本变更和索赔准备好“变更账”。凡未履行审批程序的“变更”,一律是无效变更不予受理。

  有效的需求变更流程应该包括确认变更、评估变更的价值、分析变更对项目的影响,以及提交给双方高层进行评价以确定是否执行变更。变更请求必须有书面材料,当用户发现由于业务变化而引起的需求变更,需要提出书面申请。这样对所有的变更,双方的项目负责人都能做到心里有数。而且用户在递交书面变更申请时比较慎重,一般都在内部经过讨论后进行,这样减少了因用户内部看法不同导致的反复变更。

  ③ 对于零星变更,集中研究、批量处理

  每周或每两周甚至每月召开一次需求变更专题会议,集中研究处理这些零碎变更事项,主动控制好工作节奏,尽量避免由于处理零碎变更而影响项目运行的总体进度。例如向客户正式提交一份各阶段需求变更的完成计划,注明变更引起的时间、成本、工期的代价和增加的工作量。要求客户配合需求变更计划,确定变更时限,控制变更规模,过时变更不候,离谱的变更不做,保大局弃小变。

  ④ 评估各种需求变更的影响

  客户的需求是永远不会满足的,可能一天一个样,为了达到控制频繁的需求变更。需要将需求变更后产生的成本进行评估与量化,形成分析报告提交双方领导。否则,一味的妥协只会让项目进一步恶化,实施顾问需要掌控客户及公司的进度成本,把客户的每一次需求变更进行成本分析。确认哪些需要收费变更,哪些可以免费配合客户。这样既可以维护客户关系,又不致造成公司无谓的损失。

  ⑤ 确认客户是否接受变更的代价

  要让客户认识到变更都是有代价的,要和客户一起判断需求变更是否依然进行。例如,变更是没有问题的,但是要明确客户能否接受由此引起的如进度延迟、费用增加、效率下降等问题。一般来说,如果客户认为该变更是必须的(不是其上级领导拍脑袋提出的)就会接受这些后果,通过与客户的协商,项目组可能会得到回报或者即使没有回报也不会招致公司和客户双方的埋怨。

  如果客户认为该变更虽然有必要但是可以暂缓,双方签署备忘录后留待以后解决。如果客户认为该变更可有可无,多数情况下会取消变更。这样即可防止频繁变更,也让客户认识到不是所有的需求都需要变更,更不是所有的需求变更都需要立刻修改。客户一般对MES不甚了解,他们认为很简单的事情,但可能解决起来会很复杂。以笔者的经验来看,一般来说用户的镀金需求可以延期解决甚至不考虑。用户的新增需求如果不是影响到核心业务的实现,也可以安排在现有功能的完善之后。

⑥ 每月变更记录上报双方领导

  最后,实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案,可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权,逐步让不合理的随意频繁变更,成为客户不好意思开口的尴尬事件,尽快形成正常的项目执行氛围和良好的工作习惯,也为可能受到变更所带来的责任问题留下伏笔。

  最后,要特别提醒,要在MES项目开始就对项目组和客户进行宣传和培训,让所有成员都理解变更控制的重要意义。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,470评论 6 501
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,393评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,577评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,176评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,189评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,155评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,041评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,903评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,319评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,539评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,703评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,417评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,013评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,664评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,818评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,711评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,601评论 2 353

推荐阅读更多精彩内容

  • PMP第五版考点汇总冲刺版 第一章引论 P2:《PMI道德与专业行为规范》详细描述从业者在责任、尊重、公正、诚实方...
    文小梦阅读 20,735评论 5 102
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,651评论 18 139
  • 话题:我理想中的一天应该如何度过? 【工作日】 早上自然醒,五点。在床上伸展四肢,清醒几分钟,起床,拉开窗帘,打开...
    考拉NANA阅读 541评论 0 0
  • 2016年12月,小兽过了二十周岁生日,莹莹灿灿的烛光和欢笑过后,跟年纪不太搭的落寞接踵而至。 小兽不叫小兽,她只...
    秦小小兽阅读 319评论 1 0
  • 两种构造器 Swift中为确保类在创建时每个属性都会被初始化,定义了两种构造器,分别为指定构造器(designat...
    WhisperKarl阅读 261评论 0 0