都知道沟通在项目中的重要性。既然重要，就必然要慎重对待。可是，如何慎重对待？怎样才算是有效的沟通？怎样才能做到有效的沟通？
首先要明确沟通的目的。对于实施顾问来讲，在SAP实施项目中，沟通的目的无非是下面几点。
第一，管理客户对系统的期望值，维护客户关系，达成用户的满意。系统实施是个服务性行业，客户满意是工作的终极目标。要想达到客户满意，就要让客户对项目有合理的期望值。不然的话，天王老子也无法无休止地满足用户。
第二，了解、确认和控制客户需求，以便对系统进行适当的定制。这是达到客户满意的重要途径。这里特意提到了控制客户需求。因为仅仅了解和确认客户的需求，那是初级顾问做的事；高级顾问应该学会控制，或者说引导客户的需求，说服客户剔除不合理需求，这才是重点和难点。
第三，将必须的知识传授给客户（说白了就是培训。培训也是沟通的一种形式）。系统设计再好，用户不会用，仍然会产生抱怨。如果产生这方面的抱怨，对顾问来讲是很不合算的。因为前期工作投入都很大，最后一环熄火，临门一脚踢不进去，相当于一切都白费了。
或许你可以列出其他的目的。但我对此不想再多说了。
明白了沟通的目的，就要有针对性地想办法来达到这些目的。沟通不是你说别人听，也不是别人说你听，不是被动的传授与接受，而是双方互动的过程。拿培训来讲，很多时候，顾问把操作讲了几遍，用户那里还是懵懵懂懂，实际操作仍然是一塌糊涂，这种就叫作低效的甚至是无效的沟通。了解客户需求的工作做完了，最终系统也定制完了，突然发现原来了解到的信息不是客户的真实意思表示，也意味着原来的沟通是低效的甚至是无效的沟通。沟通是要花时间的，是需要技巧的。
本人认为，要达成与客户的有效沟通，要从以下几个方面努力。
第一，充分重视。
有句话流传甚广：怎么说比说什么更重要，或者说，说话的方式比说话的内容更重要。做SAP项目实施，从根本上说是一个与人打交道的事情，而不是一个与系统打交道的事情。所以说与客户的沟通才是重中之重。做多了项目就会发现，在实施过程中发现的所有技术上的问题，最终都被证明并不是问题。因为技术是为人服务的。你把人搞定了，技术上有所限制，并不是什么可怕的事情。更重要的是，技术上的问题，往往是因为人的思路不清晰，不合理导致的。帮助客户把道理讲明白，把思路理清楚，技术上的问题经常会自动地消失。客户的一个不合理需求，如果你不能通过沟通来说服客户，而是强行通过技术来实现的话，那就是在做费力不讨好的事情。所以，最重要的原则就是，顾问要明白自己将要做的事情中最重要的是什么：不是技术，不是对着电脑不断地测试和写文档，而是与客户沟通。
说这话不是叫你放弃对技术的研究，只是强调与客户沟通的重要性。你要专门断章取义地看，不再学习技术了，将来遇到问题别来埋怨我。
我印象颇深的一件事是这样的。有一次，某客户要求我实现一个功能。我知道这不是标准功能。但我还是去做了。费了大概两天时间做出来了，但是有一些限制条件。要实现这个功能就必须舍弃另外一些东西。拿给客户看，客户不接受。正好我的领导来了。跟客户随意地谈起来，说到了这件事。领导一听他的需求就知道这不是什么好事，就跟用户忽悠了一阵子，后来用户自动放弃了这个需求。我心里那个郁闷啊……如果我能在客户提出的时候，用心引导，加强沟通，会有这两天的浪费么？
第二，以诚相待。
不是有人说嘛，你可以一辈子欺骗一个人，也可以在某一段时间欺骗所有人，但你不可能永远欺骗所有人。……我怎么感觉自己在上思想品德课啊？但话说回来，以诚相待，的确是有效沟通的不二法门。有人说，SAP顾问的薪资水平与忽悠能力成正比。事实上好象也是这样。就看你对忽悠两个字怎么理解。忽悠也有真诚的忽悠和虚假的忽悠之分。一味地为了自己省事，忽悠客户说这个也不能做，那个也不能做的顾问，或许是在一段时间之内欺骗所有人，但不可能永远欺骗下去。也就是说，忽悠一定要建立在诚实的基础上。这种忽悠，有个更中性一点的词，叫沟通技巧。如果建立在不诚实的基础上，也有个词，叫欺骗。
以诚相待，可以更好地取得客户的信任，建立良好的客户关系。在这个互相信任的基础上，做事情有往往会有事半功倍的效果。这里也举一个例子，是我永远无法忘记的。想起这位客户，心里总是暖暖的。
这位客户用到另一个产品与SAP挂钩，这个产品也有他们自己的业务人员。由于这个产品比较小，客户不太信任。工作安排上，我们需要紧密地合作。有一次那位业务人员向客户推荐了一种方案。当然在此之前他们也已经跟我讲过，我也测试通过了。用户要求他们解释的系统的逻辑，可能是因为太专业了，用户听不明白，怎么都说不通。后来我跟用户说，其实系统逻辑就象个黑箱子，它里面是啥你们不用理会它了，只要它出来的结果是你要的结果就行了。我们的SAP系统不也是这样的吗？这么大的系统，不可能明白它所有的逻辑的。用户本来是坚持要搞清楚系统逻辑的，听了我的话，想了想说：听X顾问的吧（指我），他没骗过我们的。
就是这一句话，让我更深层次地理解了什么叫回报。我对这个客户一直是以诚相待，认真帮他们解决问题。正因为如此，他们才能放心地相信我。仅仅因为我“没骗过”他们，他们就放弃了对系统逻辑追根问底的要求。我也见过一些对客户能敷衍就敷衍的顾问，也见过他们留下的一些项目。基本上，一个顾问从头敷衍到尾而不被识破的，我还没见过。用户开始对系统不懂，你说啥就是啥；但往往项目没结束，用户就已经清楚了每一个顾问是真是假是好是歹。以诚相待，永远是取得用户信任的法宝。要管理客户的期望值，对客户说不，剔除客户不合理需求的时候，如果已经取得客户信任，事情往往会象顺水推舟一样平稳；但如果让客户感觉你在敷衍他，你一旦说个不字，他会跳起来。起码也会让你摆出可信服的理由，给你增加很多工作量。
第三，学会倾听。
很多讲人际关系处理方面的书籍都会谈到倾听。倾听，表示你对对方讲的事情很在意，很重视。SAP实施顾问在做项目期间，一定要学会倾听。只有倾听，才能让你明白客户想要什么，不想要什么。一味地向客户宣传或者传授SAP的系统标准行为，或许对一部分客户是有用的，那就是想学SAP知识的人；但对于大部分其实对SAP并不感兴趣的用户来讲，他们关心的是他们的业务，并不是SAP本身。顾问要做的，就是了解他们的业务需求，结合SAP系统给出用户一个个适当的解决方案。这些都需要顾问认真地倾听客户的声音。
倾听，一定要真诚。仅仅做出一个倾听的样子，比如直视对方的眼睛，不时地点点头，发出嗯嗯的声音，偶尔发问等等，是必要的，但不是充分的。认真听取客户的意见，哪怕这个意见自己认为是极不合理的。用户出于对SAP系统的不了解，以及业务流程的不规范，往往会提出一些顾问没有想过的方案。有时候，这些方案是很离谱的。但是顾问要做的，仍然应该是倾听。先听客户把观点讲清楚，认真地思考他们提出这些离谱的方案是真的很离谱，还是自己先入为主的成见导致自己的想法其实并不高明。SAP顾问出于对系统标准的理解，对于客户提出的不合标准的业务会有天然的排斥感。在倾听客户声音的时候，一定要注意压制自己的这种排斥感，不然的话有可能陷自己于被动。
本人曾经有过这方面的教训。客户提出一个方案，听前几句就感觉很离谱，是根本不可能实现的，或者是根本完全不合理的方案。但是出于礼貌，认真听完之后发现，其实其中有若干方面是很合理的。或许整个方案不合理，但经过一些修正之后，往往是符合业务需求的正常的意见。这时不禁感觉要出一身冷汗：如果在客户刚刚说几句自己感觉不对路时，就打断客户，告诉人家这个不行那个不行，那将是多么愚蠢的行为？即使听完之后经过缜密思考，发现客户提供的言论的确根本是不靠谱的，也会因为仔细思考了客户的描述而掌握客户隐藏在背后的想法，从而在引导客户的时候占据主动。客户也会因为你确实表现出对他的意见的重视，从而对你的意见也表现出充分的重视。互相理解互相配合的环境就是这么搭建起来的。
第四，做好准备。
SAP系统是庞大的。没有人能保证了解SAP的所有标准行为。而作为顾问，面对客户的时候却又必须扮演专家的角色。客户有关于SAP系统行为的问题提出来，而你不能当场回答，且不说你如何掩饰，仅从工作效率上来说，将是一种浪费。尤其是在一次人数稍多的讨论会上，顾问作为专家回答不上某个特定的问题，将会影响进一步的讨论，影响沟通的效果。尤其在蓝图设计讨论的时候，顾问提出的意见往往会遭到质询。如果你仅仅考虑这个意见本身，而没有充分考虑到其他可能出现的意见，就有可能被当场噎到。相信我，那感觉是相当难受的。顺便说一句，这个时候，忽悠的能力就相当重要了。你要尽量表现出自己的专业，但又不能欺骗客户，如何为自己争取时间争取主动，就靠忽悠了。
但是谁也不能保证回答所有的问题。SAP顾问要做的，就是在一些特定主题的讨论前做好准备。在沟通的过程中，会有哪些问题出现，要事先做好计划。
在客户需求调研阶段，有效沟通显得尤为重要。如果不做好调研前的准备，客户一旦提出一个稍稍偏离你预先设定的范围的实际需求，你就无法去针对这个需求进行完整的调研。你的问题清单问完了，但还有一些问题你当时没有想到，还要准备进行下次调研。这就会浪费大家的时间。同时，如果你针对某一个问题反复地问客户，东一鎯头西一棒锤的，也会给客户不专业的感觉。
话又说回来，没有人能事先考虑到所有的状况。很多时候重复调研是不可避免的。顾问要做的就是尽量减少其发生的概率，事先做好准备。在这个方面，经验的积累和清单显得非常重要。最淡的墨水在记忆方面能胜过最强的大脑。
第五，注意反馈。
本人曾经做过不少失败的培训。把PPT打开，那口水犹如黄河之水天上来，飞流直下三千尺，一节课讲完了，发现有不少人睡着了。另外的一些人在打着瞌睡。还有一些看似很认真的，简单问一下懂了没有，都不懂。再问，人家说，你讲这么快谁能听得懂啊？
这就说明了一点：作为沟通形式之一的培训的过程中，注意受众的反馈是多么重要。培训是一种特殊的沟通，如果愿意的话，可以单独放一个章节。培训主要是一个传达与接受的过程。传达，不是目的，只是手段。最终的目的是要接受。如果传达的渠道受阻，受众无法接受，就应该停下来排除障碍。
所以在培训中，每讲一小段，一定要反复地问用户：明白没有？这时要注意大家的反馈。如果有人茫然不知所措，有人点头，有人摇头，那就危险了。一定要搞清楚他们的真实状况。如果绝大部分人懂了，可以接着进行（当然关键的受众不懂就要重来）。问大家是否明白的时候，要注意，点头或者不说话，不代表真正懂了。一定要他们自己发出声音！咱中国人一旦聚起群来，往往会群龙无首，没有人先说话。反复地问，要求他们说话，才知道他们是不是真正理解了。
第六，慎重说不。
对客户说不，是不可避免的事情。SAP顾问需要管理客户的期望值，需要剔除客户的不合理流程，需要坚持自己的专业意见，这些都导致对客户说不是很常见的事情。
然而，人们都不有希望听到不字的情结。我也有。谁说我的文章写得不好，我肯定不高兴。客户也一样。当你对他的意见说不，他会不高兴的。怎么办呢？
以诚相待，学会倾听，这些都会使SAP顾问更容易地向客户说不。因为你站在他的立场上考虑，真诚地替他分忧解难，让他感觉你跟他在一条战线上。战友之间的劝诫总比两个公事公办的人互相说不让人更容易接受一些。所以SAP顾问要尽量让客户感觉到你是他的战友，最起码不要让人感觉你是一个需要去对付的敌人。这个是理念上的事情。
具体说来，要注意，说不要委婉。有可能的话，不要当场说。可以说我再考虑考虑，迟些再答复你。另外，即使是非常不合理的需求，也要听清楚后，认真思考，想明白客户为什么会这样要求，他的想法有没有其他的可替代方案，用可替代方案来代替直接说不。
有时候，可以引导客户自己否定自己。因为自己对自己说不，总比听到别人对自己说不更容易接受一些。本人就曾经遇到过这种例子。客户坚持某个意见，有位顾问就说，行，我们来分析一下。这样做需要哪些方面配合，需要做哪些调整。顺着客户的意见，有意地突出其不合理之处，以及这种不合理会导致系统必须做哪些变更，这些变更是不是符合逻辑的，是不是被其他人接受的，是不是从时间上费用上考虑是可行的，是不是最优的。由于客户的想法本身不合理，讨论了一会儿，客户自己就感觉到这么做的不合理性了。不合理的东西毕竟有它不合理之处。但是由顾问直接指出来，和由顾问引导客户自己发现，就完全不是一个概念了。
另外，在向客户说不的时候，要特别特别注意的一点是：千万不要在你不确切地知道的时候说不。几乎每个项目都会有以前自己没有遇到过的新需求。而SAP系统很庞大，这种新需求SAP是否能满足，有时候顾问是拿不准的。这个时候，千万不要图省事，直接对客户说不。因为客户是会学习的。如果两天后，他找到了系统标准的解决方案，哪怕是user exit，BADI，只要能解决他的问题，他会认为你很不专业。再加上如果你不能让他信任你，他会觉得你在敷衍他。这就很麻烦了。你有没有面子都是小事，以后的工作开展起来会遇到来自于客户的重重审查。他不再相信你说的“不可能”了。你以后需要用非常确凿的证据来证明你说的每一个不字。所以，在这种时候一定要给自己留有余地。其实，在任何时候都不要把话说得太满。因为，基本上在SAP里很少有你能百分之百确定的事情。如果有的话，那也是一些基本得不能再基本的东西，客户也不会在这方面产生异常需求。有争议的，往往在SAP里不是绝对不可行的。
总之，沟通是SAP项目中非常重要的一环。沟通能力的高下，其实至少在一定程度上决定了顾问的水平。牢记这一点：SAP实施顾问做的不是技术活儿。
至于是否精通企业实际运作也是SAP顾问的一个重要衡量指标，另议。
