沟通的故事（2）

场景1：

         某个项目定了下来，做一个管理系统，接到这个项目后，我们组建了项目团队，派出了需求分析人员从事需求开发工作，但客户只提供了几页纸，并且告诉我们这就是最详细的需求了，这也是项目需求开发中经常碰到的问题，于是我们就开始发挥我们的专业能力了，首先是根据这些蛛丝马迹为客户分析其业务流程，并将业务流程充分规格化，转化为系统模型，然后是Step by Step的与客户进行确认，走访了相关的多个部门，了解了该企业目前的运作方式和工作流程，经过长达1个多月确认之后终于形成了需求规格说明书，轰轰烈烈的需求开发完成了。

         在给客户确认需求规格说明书时，发生了严重的问题，客户说：“说明书我看懂了，但不是我们需要的东西”。理由是客户期望借这次项目机会，对现有流程进行调整、优化，而不是将当前工作流程简单电子化，虽然当前的工作流程在需求中描述准确无误，但是，这不是客户期望的东西。

         结果很简单，但也很复杂。简单的是需求规格说明书并不需要太大的调整，只是局部修改；复杂的是一个系统要上马，关系到原有工作习惯改变、管理制度改变，并不是一个电子化系统的需求那么简单，后来经牛人指点，配合一系列的“操作规程”使系统顺利上马。

看来，客户要求的不是一个系统那么简单，客户要这个系统给他带来点改变。

        

场景2：

         某客户要上ITIL了，这次应该是上上下下都动员起来，而且是“不成功则成仁”下了决心要做好。但是光靠客户自己是做不好的，这一点客户也知道，所以聘请了大名鼎鼎的某公司做咨询，要从头理顺其工作流程，让ITIL真正实施起来，发挥其“应有”的作用。

         于是我们作为实现ITIL的供应商参与到了该项目中，并且是从一开头，咨询阶段，就加入到了这个过程中。这个项目如果我们仍然是采用场景1中的“专业方式”，估计也会失败得很难看。我们在实施过程中，一定不能作这样的假设：只要将业务理顺、把可实现自动化的内容实现了就是成功。因为客户的“业务”是由咨询公司刚刚为其建立起来的，甚至于客户都还没有真正认识到这就是他的业务，在这样基础上去实现的系统，是不容易说清楚到底是没实现好还是咨询公司归纳的业务与企业不顺应。

点评：

场景1中，从一开始，我们就本位的认为需求只要弄清现在流程是如何，并且将其合理的或者优化的实现系统自动化就可以了。这个问题比较复杂，我们在这个场景中仅从沟通的角度来看，真正掌握这个思路或者说对系统要求有话语权的人，我们并没有接触到，沟通的层面高度不够，或者说，正是因为有这样建设思路的人一般职位较高，我们很少能在没有任何基础的情况下去找他沟通“建设思路”，所以我们就先放过他，去准备资料、调研需求，真正向他反馈时，他告诉我们走错了方向，不是因为较低层面的工作人员糊弄我们，而是本身较低层次的人员也对系统建设没有方向感，只能告诉我们现在是怎么样的。这种现象在大企业更加明显。项目经理在项目管理工作中，必须与客户方一定高度层次的人员保持良好沟通，以书面等正式方式和电话、面谈等非正式的形式保持于客户方向性的一致。

在场景2中，只做实施是不够的，我们还必须在咨询阶段就做好“务虚”的工作，和客户一起探讨业务优化方案，并借机与客户高层次人员保持沟通的习惯和渠道，并在咨询公司退场后，借助于这个渠道和客户一起结合实际规划ITIL落地的方案，而不是让客户认为，咨询做完就万事大吉，并且认为实施很简单。要把客户统一到同一条战线上，真正让客户将咨询成果利用起来。与场景1相同，这个项目中，客户要的不是一个ITIL实现方案那么简单，我们在实施的同时，还要与客户一起制定为系统保驾护航的“操作规程”，用规程、制度为系统的应用扫清道路，让系统能良好运行起来，才是本次项目真正的成功。