溝通的故事（2）

情境1：

         某個項目定了下來，做一個管理系統，接到這個項目後，我們組建了項目團隊，派出了需求分析人員從事需求開發工作，但客戶只提供了幾頁紙，並且告訴我們這就是最詳細的需求了，這也是項目需求開發中經常碰到的問題，於是我們就開始發揮我們的專業能力了，首先是根據這些蛛絲馬跡為客戶分析其商務程序，並將商務程序充分規格化，轉化為系統模型，然後是Step by Step的與客戶進行確認，走訪了相關的多個部門，瞭解了該企業目前的運作方式和工作流程，經過長達1個多月確認之後終於形成了需求規格說明書，轟轟烈烈的需求開發完成了。

         在給客戶確認需求規格說明書時，發生了嚴重的問題，客戶說：“說明書我看懂了，但不是我們需要的東西”。理由是客戶期望借這次項目機會，對現有流程進行調整、最佳化，而不是將當前工作流程簡單電子化，雖然當前的工作流程在需求中描述準確無誤，但是，這不是客戶期望的東西。

         結果很簡單，但也很複雜。簡單的是需求規格說明書並不需要太大的調整，只是局部修改；複雜的是一個系統要上馬，關係到原有工作習慣改變、管理制度改變，並不是一個電子化系統的需求那麼簡單，後來經牛人指點，配合一系列的“操作規程”使系統順利上馬。

看來，客戶要求的不是一個系統那麼簡單，客戶要這個系統給他帶來點改變。

        

情境2：

         某客戶要上ITIL了，這次應該是上上下下都動員起來，而且是“不成功則成仁”下了決心要做好。但是光靠客戶自己是做不好的，這一點客戶也知道，所以聘請了大名鼎鼎的某公司做諮詢，要從頭理順其工作流程，讓ITIL真正實施起來，發揮其“應有”的作用。

         於是我們作為實現ITIL的供應商參與到了該項目中，並且是從一開頭，諮詢階段，就加入到了這個過程中。這個項目如果我們仍然是採用情境1中的“專業方式”，估計也會失敗得很難看。我們在實施過程中，一定不能作這樣的假設：只要將業務理順、把可實現自動化的內容實現了就是成功。因為客戶的“業務”是由諮詢公司剛剛為其建立起來的，甚至於客戶都還沒有真正認識到這就是他的業務，在這樣基礎上去實現的系統，是不容易說清楚到底是沒實現好還是諮詢公司歸納的業務與企業不順應。

點評：

情境1中，從一開始，我們就本位的認為需求只要弄清現在流程是如何，並且將其合理的或者最佳化的實現系統自動化就可以了。這個問題比較複雜，我們在這個情境中僅從溝通的角度來看，真正掌握這個思路或者說對系統要求有話語權的人，我們並沒有接觸到，溝通的層面高度不夠，或者說，正是因為有這樣建設思路的人一般職位較高，我們很少能在沒有任何基礎的情況下去找他溝通“建設思路”，所以我們就先放過他，去準備資料、調研需求，真正向他反饋時，他告訴我們走錯了方向，不是因為較低層面的工作人員糊弄我們，而是本身較低層次的人員也對系統建設沒有方向感，只能告訴我們現在是怎麼樣的。這種現象在大企業更加明顯。專案經理在專案管理工作中，必須與客戶方一定高度層次的人員保持良好溝通，以書面等正式方式和電話、面談等非正式的形式保持於客戶方向性的一致。

在情境2中，只做實施是不夠的，我們還必須在諮詢階段就做好“務虛”的工作，和客戶一起探討業務最佳化方案，並藉機與客戶高層次人員保持溝通的習慣和渠道，並在諮詢公司退場後，藉助於這個渠道和客戶一起結合實際規劃ITIL落地的方案，而不是讓客戶認為，諮詢做完就萬事大吉，並且認為實施很簡單。要把客戶統一到同一條戰線上，真正讓客戶將諮詢成果利用起來。與情境1相同，這個項目中，客戶要的不是一個ITIL實現方案那麼簡單，我們在實施的同時，還要與客戶一起制定為系統保駕護航的“操作規程”，用規程、制度為系統的應用掃清道路，讓系統能良好運行起來，才是本次項目真正的成功。