寫給客戶看的材料

寫給客戶的報告必須有一定的針對性，在背景要求越明朗的情況下就越能切中要害。加之每個人理解的程度不同，導致話傳話後就失真了。舉個例子，我被抽調去跑一個項目，要求是向客戶證明他們確實需要開一個預調研項目，以便於後期項目的開展。經過幾天的奮鬥寫了一個報告，可是到了現場之後，客戶說這個東西已經決定給我們做了，然後列出了提綱類的東西說結構已經定了，讓我展示一下具體的方案。這就比較扯了，準備的內容就沒用上，這種提綱類的東西也是現場第一次看到，內容也沒準備，只能告訴客戶會後我們再去研究。這種事情的發生一方面是售前人員不懂客戶究竟是什麼意思，也許在他們的字典里只有報價，另一方面是由於他可能真的想領悟客戶的意思，但是由於缺乏一些技術背景，傳遞錯了話。當然，也可能我就理解錯了。無論怎麼樣，我們都需要承認的是，信息傳遞的失效性，你以為你聽懂的東西，其實你並沒有明白。如果在有傳話人，就會添加一些個人感情因素進去，其結果就複雜了。有意思的是，相同的話即使讓不同的人朗讀，重音的位置稍有變化，理解也會變，這都是小學知識，只不過很多人在即使到了不惑的年紀也還搞不清楚。我的做法是，講一個東西，先把一些背景概念澄清，諸如某些TERM，避免專業領域不同導致理解的差異。然後在敘述事件，最後分配任務的時候在明確每個人的職責，一事不二分，必須有交期，交不出來也必須寫一個頂。SMART原則在很多時候都會有比較實際的效果，很多人呢也是學習過概念，用的時候就隨心了。我個人覺得兩個東西真的很有用，一個事SMART，一個是金字塔原理，這樣的好處是做什麼都很清晰，別人也好理解。

下一個說說給客戶的報告：

背景是這樣的：銷售能夠提供客戶的基本資料，諸如：工廠類型，產品類型，產能數據，產線組成，具體訴求（希望改進什麼，上什麼系統，未來期望），參會人員組成，特別是關注點

基於以上的背景，可以大致猜出來這已經不是第一次拜訪客戶了，得到的信息已經比較全面了，而且客戶對我們也給予了比較高的期望，那麼我們應該準備什麼樣的資料。如果是純第一次，那就完全是拼一下公司背景和實力了。在第一輪的交鋒後，客戶會提供一些更重要的信息，不管出於什麼目的啊（1. 真的想要供應商做 2.套一下供應商的方案然後自己做3.拿供應商的方案去套預算），我們都認為客戶是真心人。套路基本是這樣的。多說一句啊，文無定法啊。做事千萬別鑽牛角尖。

文章一般採用六段論的方法，盡量全面的闡述，

１.　我們的公司有實力　－－－　公司高層非常重視，秀秀肌肉

２.　你們的現狀是這樣　－－－　有問題啊，不做死定了

３.　根據我們了解到的情況和我們的行業經驗，你們將來會是這個樣子　－－－　此處為重點展開，涉及業務粗流程，系統架構

４.　我們計劃這麼做－－項目周期，每個節點做什麼，多久完成，項目輸出

５.　我們的團隊有力量－－團隊成員組成，都是經驗豐富的人

６.　感謝致辭並請客戶提意見

基本上２，３點要重點描述的，客戶希望的是你要懂我，千萬別寫成，我們之前這麼做，現在你們公司這麼做也會有同樣效果。類似的東西可以放到後面作為參考案例，讓客戶覺得不是空穴來風，不是小白鼠就好。核心是客戶現在的狀態，比如，有什麼樣的部門，誰是這次項目的關鍵用戶，離散還是流程行業，幾條線體，多少種類型的設備，大致的產品及工藝流程，周邊系統比如已經存在的控制系統有哪些，現有的系統間交互是什麼樣子，有什麼樣的功能部署，在初期溝通時候獲得的客戶請願（客戶想開一個項目內部肯定有討論過發生的問題的），將所有的這些整理成幾頁PPT就好。這就是要表明，我們是下了功夫的，我們懂現在發生的事，你們呢也有一些訴求。下面輪到我告訴你要怎麼改了。

ａｓ　ｔｏ　ｂｅ是常用的一個標題項，方式是對比，有什麼樣的問題結合什麼樣的對策，問題多了對策也會多，這些對策的集合都會在我們的系統里有對應，結論是，引入我的系統，你的問題能夠解決。這樣就順利成章的把自己的產品推了出去。當然這樣不排除客戶不想要整體解決方案而是要點對點的解決，這個部分就另說了。

在接下來就是要說我們是有一套方法論的，也就是一套完整且有效規範的項目管理方式用於確保項目按質按量按時完成，學過PMP的因該都清楚，５個過程組，十大知識領域，都有模板可以抄的。這部分的重點是把項目周期表達清楚，也就是多久能做完，每個節點的時間，產出物是什麼，畢竟還沒拿到項目，也不必太細。MES項目的實施逃不出幾個方面。以下是拿到項目後才幹的事。

１.　需求調研產出設計藍圖，這個是最高級別的概述。Blue　Print

２.　根據藍圖進行細節，生成用戶需求文檔，URS，這就要畫具體的流程圖了，系統交互圖，軟硬體架構設計等

３.　結合自有產品進行設計，生成FDS，這裡最重要的多的就是每個功能的用戶界面和介面描述

４.　然後就是正式進入開發了，當然也有按模塊並行走的。客戶一般會要求儘快上線，如果能接受按模塊簽字，那麼也可以按模塊開發，如果收款節點是按整體簽字來看，那麼我們就要小心了，因為就算開發完了，由於某個小點沒簽，損失就是自己的。這個時候就要聯合銷售去搞客戶了，項目經理在這個時候是比較痛苦的。

單元測試，集成測試，上線測試，ｔｒａｉｌ　ｒｕｎ，這幾輪搞完，項目也就差不多該簽字驗收了。

就項目實施而言有得多說一點：關於測試部分，在現實開發中，測試一般是被認為是浪費時間的操作，從個人到整體都是草草了事，這個倒是很符合國人急功近利的觀點，因為整個項目最容易壓的時間就是這個。相對外國企業還是做的比較好的，國人借用後會走樣但是好歹也是遵守了流程。質量是生命這就是個口號，到了出貨節點什麼都是浮雲。有時候只能嘆息，處於成本和各種壓力考量我都能理解，但是並不贊同。言語中透露著無奈和一種悲涼。

轉回話題，六段論的組織是個學問，PPT的畫法也是，有人說一副好圖勝過千言萬語，但是有的客戶就是喜歡看干條條，條條寫明白了，他覺得白紙黑字最清楚，而一副飽含內容的圖是靠講的人發揮的，取決於講的人的水平。寫材料的核心在於所表達的思想，而不在於長度，當然我也遇到過認為篇幅太短代表態度不端正沒有下功夫寫的說法，這玩意就見仁見智了。

到了一個環境，就要融合到這個環境，行業不同，從業人員的知識水準也不一樣，大家的習慣也不一樣。寫的好壞也確實能一下看出來，而我們的目標也就是向這個方向努力。為了完成工作，一般方案就是拼湊+有針對性的創作，不要重複造車輪是原則，如果有什麼能直接借鑒的，一定拿過來，然後修改。全抄是非常不可取的，一定要對標自身項目要求，該替換的一定要替換掉，其中也必須有那麼少量幾頁是原創，不然會被嘲笑的。

最後，PPT怎麼畫的好看是另外一個話題了，我想表達是內容組織結構是我們最需要關注的，你可能畫不出好看的圖出來，但是干條條列的清晰，明了，層次遞進很有節奏，哪怕是沒圖，一樣能表達出自己的觀點。材料的展現方式只是手段，讓聽的人真的明白你的意思才是真正重要的。多看看金字塔原理吧，我覺得還是非常有用的。

噢，在多說一點。最近和一位領導聊了一下對MES的看法，我們的想法還是蠻一致的，就是MES本身已經是明日黃花了，他也不看好MES了，雖然我們還是在做MES.做這個系統的內涵是分析，由分析來帶領決策，藉助MES及相關係統分析出有用的結果，才是我們的關注點。