今天在给客户设计解决方案。在此过程中，重温了一下IATF 3.1。
正所谓“温故而知新”，还是很有道理的。
第一章里有一句话，摘录如下：
Essentially, organizations address IA needs with people executing operations supported by technology.
其实，把上面这一句话中的"IA needs"换成"business needs"也可以，换成其它的"needs"也多半可以。
接着就指出：
Of the three principal aspects of this strategy, the IATF focuses on technology and on providing a framework for providing overlapping layers of protection against cyber threats.
很多事情都是这样，比如说NOKIA经典的slogan：Technology Connect People.
人才是主角。
因此，这个解决方案围绕人——而不是技术——来展开。
很久没有写方案了。或者应该说，很久没有为特定的项目写方案了。
工作这么些年，看过很多人的方案或者项目建议书，有的出自高手，有的出自新手，看来看去，就有了以下这些想法。谨供参考。
做售前很辛苦，同时也有很多乐趣。
写方案是售前的主要工作之一，同样是苦中有乐。
好了，废话少说。
首先，要对解决方案有正确的认识。
解决方案是什么？用来做什么？应该包含哪些内容，不应该包含哪些内容？给谁看的？
以上这些问题，都必须能够回答。答案不是固定的，根据不同的情况有不同的结果，关键在于在开始写方案之前，必须要问自己这些问题，而且必须找到答案。
其次，要站在读者的角度去考虑。
解决方案的读者包括客户，客户经理，也许还有你的主管。在你写方案的这个阶段（销售的6个阶段之一）他们关注什么？他们将会如何使用这个方案？
最后，再问问自己，要写好这个方案，是不是靠自己就行了？如果需要同事的帮助，自己知道该找哪些人吗？方案中需要的资料，在哪里可以找得到？
闲聊就到这里。做售前很辛苦——如果你想做一个好售前；做售前很快乐——如果销售和客户认可你。
今天下午组织了一个会，讨论“问题确认与问题分解”。
售前咨询顾问的核心任务之一就是“解决问题”，许多其它任务都是围绕它展开的。
要有效地解决问题，还要高效地解决问题。
因此，问题确认和问题分解就非常重要了。
但往往我们做得不好。
今天的会只讨论了应该这么做，这么做有什么好处，但是没有讨论怎么做。
我们应该怎么确认问题，应该怎么分解问题？确认和分解到什么程度就可以停下来？
确认问题的方法有很多，我最常用的方法是复述。这是在《售前工程师呈现力培训》中强化的。在和客户交流的过程中和快结束时，我都会复述（通常是换一种说法）结论以确保双方理解一致。别看这么简单的技巧，却非常有效，而且有概率论的理论支持：假定对一种说法理解有偏差的概率是30%，对两种说法都出现偏差的概率就降到9%。所以，多说一句话能把沟通的一致性提高21%，值！
当然，用书面文字来描述问题并一起讨论是一种更正式，也更有效的方法。但这种方法会带来一定的开销，因此适用于重要问题。
确认到什么程度可以停下来？
其实很简单，只要你确信双方对问题已经有了一致的理解就可以了。如何来判断是否有一致的理解呢？可以请对方复述。
分解问题的方法也很多，通常在着手分解问题之前需要先摸清楚问题的内部结构。就象庖丁解牛一样，只有那样，分解才是最自然，最有效的，而且开销最小。这方面一种有效的工具就是WBS（Work Breakdown Structure）。详细信息可以参考有关项目管理的书籍。
分解到什么程度可以停下来？
这和问题确认相关。只要分解到双方可以很容易进行问题确认就可以了。
这是一个普遍的误解：把看上去能够唯一标识一条信息或者一件物品的数据当成该信息或者物品的Key，而往往这种数据到了另一方（在刚才这件事中是客户），具有同样数据的信息或者物品有太多（哪个客户每年不签一大堆合同？）。
7799是一个关于安全管理的标准，从我们现在的观点来看，7799只讲了安全管理有什么，而这些组成部分之间是什么关系讲得不多。虽然ISMS是基于业界最佳实践而提出来的，但却缺乏必要的流程。因此，在这方面ITIL正好提供了可供7799借鉴的东西。
今天又看《领导商数》（余世维），听到那句已经耳熟能详的话——投诉是第二次表现机会。
在很多人（也包括我在内）看来，“投诉”是一件很“可怕”的事。尤其是投诉的对象是自己或者自己的直接下属时。
其实，真的没那么可怕。当我以一种积极的心态来面对“投诉”时，我发现真的象余世维讲的那样，投诉是第二次表现机会。
余世缑先生还讲道，投诉只在下面三个条件同时成立时才会发生：
1、没有替代者；
2、不想放弃你；
3、想得到补偿。
让我有点奇怪的是，我自己极少被投诉。在公司工作3年了，我的主管通知我被投诉一共不到5次。回想一下上面这些条件，好象第3条总是不满足。因为投诉我除了对我可能造成负面影响之外，我的客户（也就是销售）不会得到任何补偿。
但是，这样带来很严重的一个问题：我得不到对我工作效果的反馈。
还让我感到奇怪的是，我们部门的成员也很少被投诉。直到前几天，一位销售才把对一位已经离职的同事在执行任务时犯的错告诉我。他们的情况稍有不同：第1个、第3个条件都不满足。
这同样也是问题：我的下属也得不到对他/她的工作效果的反馈。
怎么办呢？
很自然地，我第一想到的是要鼓励投诉。但这会带来一个问题，投诉太多了怎么办？带来的负面影响会更大。
想来想去，还就想到一个办法，鼓励直接对话。
曾经有位销售跟我说某下属的某些问题，我就跟他说，这些问题由我去转述反而不好，不如你直接和他沟通。基于我对你们两位的了解，相信你们一定会沟通得很好。结果效果不错：这两位现在彼此信任而且配合日趋默契。
但这种方法的推广却不是一件容易的事。结合昨天看《时间管理》一书的感想，得出一个结论：对任意两两组合，需要采用不同的处理方式。这里面的道理毛主席他老人家讲得已经很清楚了：具体问题具体分析。:)
今天晚上和客户讨论到2点，茶馆关门了还有点意犹未尽。
之所以会有这样的讨论是因为客户对我们提供的项目建议书不满。用客户的原话来说就是“当我仔细看完这份文档时，我发现其中只有两成左右的内容是可用的”。
为什么会这样呢？
这个问题其实已经思考了很久，也早就有了答案：客户的视角与顾问的视角不同。
作为咨询顾问，如果想把工作做好，就必须站在客户的角度来看问题。只有这样，客户才能理解我们的解决方案，才能体会其中的好处（如果有的话）。
但怎样才能站在客户的角度看问题呢？
在前一篇短文中，我提到要让客户和我们一起创新。今天我突然发现这种方法同样有利于我们站在客户的角度看问题。这还和Jordan在推荐《六顶思考帽》的那篇短文中强调的“平行思维”有相通之处。
其实就是这样，当客户说出他的看法时，我们千万不可以急于表达自己的看法。先好好想想为什么客户会有这样的看法，结合客户在组织中的位置，结合客户的环境体会一下，就会比较容易和客户的视角相近了。
可以多试试，其实就象六顶思考帽那样，没有想象中那么困难。
作为一个咨询顾问，要做的事情很简单，也很复杂。
把复杂的事情变简单，就是咨询顾问的价值所在。
如何才能把复杂的事情变简单呢？ 其中还是应该有技巧的。
技巧之一就是：让客户与你一起创新。
对于新入行的咨询顾问来说，最苦恼的事莫过于自己费尽周折想到的解决方案客户不理解。
不理解就不大可能支持，你怎么办？
方法一：不厌其烦地向客户讲解，直到客户理解并接受为止。
方法二：对方案进行改写，改善方案的可读性，直到客户能够看明白为止。
方法三：你还有第三种方法吗？
昨天开会讨论某个项目时谈到客户在准备汇报时需要我们配合。也就是说，需要配合客户写出汇报用的PPT 。于是脑中灵光一闪：这种方式何不用在我们的日常工作中呢？
对客户来说，解决方案是客户环境中某种程度上的创新。简单点，一份解决方案对客户来说是一份新东西。理解并接受新事物是需要付出一定努力的，这包括时间和精力。
对我们来说，客户肯投入在我们关注的项目上的时间和精力都是有限的，因此我们需要减少客户在这方面的开销，这样来提高客户的满意度。
和客户做一次交流，然后在规定的时间提交方案。这是常规的做法，也是效果最一般的方法。
如果想改善效果就需要改善做事方式。
和客户交流一次，然后每1~2 天把方案的中间结果提交给客户看，再电话确认一下客户对方案的想法（谦虚地请客户提意见）。这样渐进地把方案做好，在规定的时间提交给客户。这样客户总共投入的时间和精力都增加了。但是，当我们正式把方案提交给客户时，客户理解并接受方案所需要付出的努力却大大减少了。一来因为客户参与了“创新”的过程，方案中整合了客户的想法，当然更容易接受；二来客户在参与的过程中就已经一点点地积累了理解方案所需的背景知识，到正式提交方案时，理解起来已经没什么困难。
这便是咨询顾问的工作原则之一：客户参与。
Powered by Haiwit
