面对这样的客户我应该怎么办？

醉眼看世界

1、产品严重不成熟

2、顾问严重不专业

3、企业严重不规范

4、根本不懂项目管理

这样的项目不死就对不起老天爷！

SUSHAOCHENG

猫的话,很尖锐,但很中肯.我喜欢,有性格

古雨

能否开一个 初入行顾问的 专版？？？

醉眼看世界

原帖由 liuqing112 于 2008-12-9 21:05 发表
支持猫，坚决贴猫的条，报猫的警

我那么多车，随便你帖，累不死你

fishes00

原帖由 醉眼看世界 于 2008-12-8 14:26 发表
1、产品严重不成熟

2、顾问严重不专业

3、企业严重不规范

4、根本不懂项目管理

这样的项目不死就对不起老天爷！

这样的项目坚持做着。。。希望可以看到新的局面。

fishes00

原帖由 古雨 于 2008-12-9 20:55 发表
能否开一个 初入行顾问的 专版？？？

支持。。。

paul_1982

说明两点:1.你没能完全了解客户的整个业务流程,所以在客户在提出相关需求的时候,你不能够判断这些需求是否应该修改程序,还是客户想当然的做法。
            2.客户对于自己的提出的需求不负责任，没有对自己所提出的需求做一个深入的思考，需求是否满足工作的需要，能够提高工作的效率。
这两点导致客户经常变更需求，你也说不出拒绝的理由

亭华龙哥

原帖由 醉眼看世界 于 2008-12-8 14:26 发表
1、产品严重不成熟
2、顾问严重不专业
3、企业严重不规范

这样的项目不死就对不起老天爷！

这样的项目不好好做,就真对不起老天爷了.

楼主的问题,实际上对一般规模的软件公司和一般规模的客户,
是很常见的事情.

1. 做顾问遇到这样的事情.应该要感谢老天爷. 二楼的hnpywj说要j跳槽！ 这么好的机会要白白的浪费?
为啥?
我刚刚开始做项目的时候,也经常遇到很多烂客户, 还经常要接手许多烂项目,帮人擦屁股.
我也经常向老大投诉,为什么总给我做烂项目? NND.

老大如何说:
KAO, 龙哥,你应该要感谢上天,感谢党和人民对你的信任.
这是一个绝好的机会, 其它人我还不给他们机会涅

因为,公司不但给你工资, 还给你天底下最烂的项目, 不经风雨,如何见采红.
这要面对多大的挑战, 天天要和客户打仗,和客户顶嘴....天天和客户勾心斗角.

所以,
楼主,第一步先要感谢上天给你机会, 别人出钱来让你乱搞的机会不多.先不要想走路,
而是转变心态.
老子,做完这个项目这要走了,.但今天我就狠狠的做做这个烂项目,老子,要走之前不但要赚工资,还要狠心狠狠的赚经验,  我今天就要树立强势,老子今天我要做一个强人....

NND, 客户与我顶牛,我就灭谁,什么破需求,什么破流程...死一边去.反正老子做完这个项目这高就了, 破斧沉舟....

心态好了,就能放轻松.
(实际上,当你做好了这样的烂项目,你已经成长了,公司当你是宝了)


2. 项目管理技术加强.
辛辛苦苦熬了几个月的通宵，终于确立了ERP需求，规范了工作流程，系统配置也完成了，正准备按部就班ERP系统上线时，企业用户突然改变了需求，不想这么做了，提出了新的需求。这对于ERP实施顾问来说，正如晴天惊雷，这也是所有ERP顾问最感到恐怖的事情。

所以,先不要埋怨,要先自强.
KAO,老子要骂人,也应该要有理由.SB式的骂大街,谁不会呀? 问题是要骂处让别人心服口服.


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

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


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

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


4. 需求变更为什么总是做不完？
    （1）合同签订马虎，没有真正明白客户需求
（2）调研时没有深入理解客户需求
（3）没有明确的需求变更管理流程
（4）没有让客户知道需求变更的代价
对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对实施顾问的辛苦就会难以体会。在评估代价过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。


5.  如何有效控制需求变更？
需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。有句通俗的话说得非常好：“需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”



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

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

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


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

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

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

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

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

fishes00

原帖由 亭华龙哥 于 2008-12-11 09:13 发表


这样的项目不好好做,就真对不起老天爷了.

楼主的问题,实际上对一般规模的软件公司和一般规模的客户,
是很常见的事情.

1. 做顾问遇到这样的事情.应该要感谢老天爷. 二楼的hnpywj说要j跳槽！ 这么好的机会要白白的浪费?
为啥?
我刚刚开始做项目的时候,也经常遇到很多烂客户, 还经常要接手许多烂项目,帮人擦屁股.
我也经常向老大投诉,为什么总给我做烂项目? NND.

老大如何说:
KAO, 龙哥,你应该要感谢上天,感谢党和人民对你的信任.
这是一个绝好的机会, 其它人我还不给他们机会涅

因为,公司不但给你工资, 还给你天底下最烂的项目, 不经风雨,如何见采红.
这要面对多大的挑战, 天天要和客户打仗,和客户顶嘴....天天和客户勾心斗角.

所以,
楼主,第一步先要感谢上天给你机会, 别人出钱来让你乱搞的机会不多.先不要想走路,
而是转变心态.
老子,做完这个项目这要走了,.但今天我就狠狠的做做这个烂项目,老子,要走之前不但要赚工资,还要狠心狠狠的赚经验,  我今天就要树立强势,老子今天我要做一个强人....

NND, 客户与我顶牛,我就灭谁,什么破需求,什么破流程...死一边去.反正老子做完这个项目这高就了, 破斧沉舟....

心态好了,就能放轻松.
(实际上,当你做好了这样的烂项目,你已经成长了,公司当你是宝了)


2. 项目管理技术加强.
辛辛苦苦熬了几个月的通宵，终于确立了ERP需求，规范了工作流程，系统配置也完成了，正准备按部就班ERP系统上线时，企业用户突然改变了需求，不想这么做了，提出了新的需求。这对于ERP实施顾问来说，正如晴天惊雷，这也是所有ERP顾问最感到恐怖的事情。

所以,先不要埋怨,要先自强.
KAO,老子要骂人,也应该要有理由.SB式的骂大街,谁不会呀? 问题是要骂处让别人心服口服.


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

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


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

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


4. 需求变更为什么总是做不完？
    （1）合同签订马虎，没有真正明白客户需求
（2）调研时没有深入理解客户需求
（3）没有明确的需求变更管理流程
（4）没有让客户知道需求变更的代价
对变更的影响没有评估是需求变更泛滥的根本原因。变更都是有代价的，应该要评估变更的代价和对项目的影响，要让客户了解需求变更的后果。如果客户不知道需求变更付出的代价，对实施顾问的辛苦就会难以体会。在评估代价过程中，可以请客户一起做判断：“我可以修改，但您能接受后果吗？”。


5.  如何有效控制需求变更？
需求变更对项目成败有重要影响，既不能一概拒绝客户的变更要求，也不能一味地迁就客户，所以实施需求变更之前必须做好控制。有句通俗的话说得非常好：“需求变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。”



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

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

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


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

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

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

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

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

谢谢[亭华龙哥]，一筐热泪啊。。。。。不仅将问题分析到点上。。。还有具体的方法。学习中。

亭华龙哥

原帖由 fishes00 于 2008-12-11 10:23 发表

谢谢[亭华龙哥]，一筐热泪啊。。。。。不仅将问题分析到点上。。。还有具体的方法。学习中。

KAO,不用这样吧
做ERP顾问一味让客户是不行的.

不要怕拒绝客户.
我写过一个帖子说,如何拒绝客户, 如何对客户"说不"你可以参考一下.