目 錄

前言

2 如何做業務調研？

2.1 調研工作如何組織？

2.2 調研準備階段容易犯哪些錯誤？

2.3 調研準備階段容易犯哪些錯誤？)

2.4 調研準備階段容易犯哪些錯誤？

2.5 現場調研階段容易犯哪些錯誤？

2.6 現場調研階段容易犯哪些錯誤？

2.7 現場調研階段容易犯哪些錯誤？

2.8 現場調研階段容易犯哪些錯誤？)

2.9 現場調研階段容易犯哪些錯誤？

2.10 現場調研階段容易犯哪些錯誤？

2.11 調研工作方法推薦

2.12 接口調研背景知識(上)

2.13 接口調研背景知識(下)

2.14 調研后續工作落實階段

3 如何寫解決方案？

3.1 解決方案難寫在哪里？(連載十五)

3.2 壞的解決方案有哪些特征？(上)(連載十六)

3.3 壞的解決方案有哪些特征？(中)(連載十七)

3.4 壞的解決方案有哪些特征？(下)(連載十八)

3.5 寫好方案心得(上)(連載十九)

3.6 寫好方案心得(下)(連載二十)

3.7 方案分類及用途(連載二十一)

4 如何做產品演示？

4.1 什么是演示？(連載二十二)

4.2 演示的目的

4.3 售前演示為什么效果不好？(上)(連載二十三)

4.4 售前演示為什么效果不好？(下)(連載二十四)

4.5 售前演示工作應如何組織？(上)(連載二十五)

4.6 售前演示工作應如何組織？(下)(連載二十六)

4.7 如何準備標準演示套路？(上)(連載二十七)

4.8 如何準備標準演示套路？(下)(連載二十八)

4.9 如何進行現場演示(一)(連載二十九)

4.10 如何進行現場演示(二)(連載三十)

4.11 如何進行現場演示(三)(連載三十一)

4.12 如何進行現場演示(四)(連載三十二)

4.13 如何進行現場演示(五)(連載三十三)

4.14 如何組織演示后工作(連載三十四)

4.15 演示方案準備經常考慮的問題(連載三十五)

5 如何做用戶考察？

5.1 前言(連載三十六)

5.2 典型用戶有什么意義？

5.3 典型用戶應如何管理(上)(連載三十七)

5.4 典型用戶應如何管理(下)(連載三十八)

5.5 用戶現場考察應如何組織？(上)(連載三十九)

5.6 用戶現場考察應如何組織？(中)(連載四十)

5.7 用戶現場考察應如何組織？(下)(連載四十一)

6 如何做公司介紹？

6.1 前言(連載四十二)

6.2 哪些情況下需要公司介紹

6.3 正式陳述時常見錯誤？

6.4 口頭和會面介紹時常見技巧(連載四十三)

6.5 在客戶處進行公司介紹三個要點

6.6 如何對在公司考察客戶做介紹(連載四十四)

6.7 做好總部公司介紹的三個決竅

6.8 公司總部接待考察客戶要注意的細節

7.1 培訓工作在項目實施中作用(上)(連載四十五)

7.2 培訓工作在項目實施中作用(中)(連載四十六)

7.3 培訓工作在項目實施中作用(下)(連載四十七)

7.4 培訓工作應如何組織？(連載四十八)

7.5 培訓注意事項(連載四十九)

7.6 總部培訓

8 如何做現場推廣?

8.1 現場推廣工作可進行條件？(連載五十)

8.2 現場推廣工作為什么進展慢？

8.2.2 要推廣的業務流不完整(連載五十一)

8.2.4 沒有激發用戶的主動性(連載五十二)

8.2.6 邊界總在變更(連載五十三)

8.3 現場推廣工作如何才能做好？(連載五十四)

9 如何做項目驗收?

9.1 驗收工作應如何組織？(連載五十五)

9.1.3 主動溝通(連載五十六)

9.1.4 寫好備忘錄(連載五十七)

9.2 如何催款？

10 如何做項目團隊管理

10.1 前言(連載五十八)

10.2 好的項目團隊構建要求

10.3 好團隊的兩個特征(連載五十九)

10.4 如何看待項目經理在團隊中作用

10.5 團隊建設心得和誤區(連載六十)
1 前言

在IT行業，特別是管理軟件實施行業能夠成為一個成功的項目經理是非常困難的一件事情，一個成功的IT經理，被要求熟悉計算機軟硬件知識，精通企業業務背景，擁有良好的溝通技巧和說服能力，當然在項目團隊中還必須具有威信和執行力，這樣的人才簡直是完人。

一般人即使努力也不可能達到這樣的一個完美的項目經理的境界，如果相信自己努力就可以做到可能是受哪些成功書籍的毒害太深。

更多的項目經理是擁有崗位并非擁有崗位技能，但可笑的是，往往是一個人剛剛被發現具備這樣的潛質就會沒有多少機會實施項目，而是陷入另一種疲于奔命的狀態。

因為一個具有豐富實戰經驗的人對企業最有價值的場合不是深入實施某個具體的項目，而是進入售前。

管理軟件銷售是最合適顧問式銷售技術，但很難想象一個沒有實際實施項目經驗的顧問可以有效把握企業需求和打動對軟件供應商本質上都保持狐疑的潛在客戶，這些都只有通過經驗豐富的項目經理才可以做到。

如果一家軟件公司的問題還是生存的問題，這樣優秀的實施顧問最合理的選擇就是售前咨詢顧問。很多用戶往往在合作后感覺到售前和售后交流時存在巨大落差，就是因為售前你看到的是已經證明過自己的顧問，售后你看到的就是還需要證明自己的顧問。

筆者自己也是走過了這么一條路，所以現在想一想，做項目經理難，做管理軟件的項目經理尤其難，五年下來，忙得不亦樂乎。常常笑言自己是職業“三陪”，陪客戶交流，陪客戶考察，陪客戶吃飯。

不過和大量客戶交流也的確從另一個角度豐富了本人的閱歷，也對整個管理信息化事業的建設從另一個角度(售前)增加了新的認識，在本文本人將自己售前售后一些工作心得分為九種技能(業務調研，解決方案，產品演示，用戶考察，公司介紹，用戶培訓，現場推廣，項目驗收，團隊管理)，分別整理成文，希望能給在這個行業內拼搏的同道一些啟發。

2 如何做業務調研？

2.1 調研工作如何組織？

很多人認為調研工作極難，水平最高的人才能做好一次調研，軟件工程中也強調需求獲取是最難的事情。有的人要么認為不過如此，甚至是一個普通技術支持都可以做的工作。

現在有很多企業上管理軟件之前都希望軟件公司派人來了解情況，提出針對性建議。這其實給很多軟件公司銷售經理出了個難題，自己親自上企業不信任，而且也不專業，請公司派咨詢顧問過來資源難以協調，響應不及時用戶也不滿意，而且貽誤商機，隨便來一個技術支持又不能保證調研質量，在后續工作中也難以讓用戶信服。

其實難和不難，在于是否用正確的方法做事，經常用正確的方法做事人，眼里是沒有難事的。

雖然說調研工作質量和調研個人能力是直接相關的，有豐富經驗的人在很短時間內就可以完成高質量的調研，取得被調研用戶的認可，沒經驗的人花費大量時間在現場了解情況可能還是給用戶一個不懂行的印象。

但最有經驗的人也不可能了解所有的行業，他們對于一些陌生的行業一樣可以將調研工作完成得很好，我發現有經驗的調研人員和沒有經驗調研人員最大的區別是他們是否按照正確的過程組織調研工作，按照正確的方式做事自然會更容易取得成功，有無其它行業經驗只是成功調研的一個積極因素而已。

在一個有調研經驗的業務人員眼里，調研決不是現場調研這么簡單，無論是售前還是售后調研工作本身都可以分為三個階段。

第一個階段叫調研準備階段，這個階段要完成調研計劃的確認，調研背景資料的準備兩方面的工作。這個階段工作質量將對能否順利開展調研工作起到關鍵保障作用。

第二個階段就是現場調研階段，根據調研計劃完成各項調研工作，并取得用戶認同。

第三個階段就是調研后續工作落實階段，調研結束后往往要準備產品演示，技術交流，解決方案等工作，所以調研結束后一定要趁熱打鐵，把后續工作落實到一定程度才能再做其它工作，此時調研工作才能算結束。

這是很多人忽視的一點，以為調研成功事情就結束了，其實調研工作和后續工作往往不是同一個人準備，高質量調研信息如果不能及時有效完整傳遞到后續工作者頭腦中，調研工作實際上是更大的機會成本喪失。

從商務的角度來講，售前調研還存在一個時機問題，調研本身應該是商務策劃中的一個環節。

很多商務人員和用戶接觸以后，技術講不清楚，業務談不清楚，只好給一個模板化的方案給用戶，結果這種方案又沒有說服力，大家的方案高度雷同，用戶無法鑒別，往往提出一個請求：是否請安排貴公司業務人員做一個調研，然后再提供一個針對性方案？

有經驗的銷售人員還應該明白，調研是一個適當實際要去做的工作，不應該被用戶牽著走，應該是整個商務策劃中的一部分，不過這不是本文闡述重點，本文將重點介紹業務調研需要的技能。

2.2 調研準備階段容易犯哪些錯誤？

一般接到一個調研工作任務后，大家都會去編制一個調研工作現場工作計劃，同時進行一些調研準備工作。

根據我的觀察，在調研準備階段大家常常存在這么幾個錯誤。

2.2.1 第一個容易犯的錯誤：不清楚調研的的目的

很多人編制計劃，寫本次現場工作目的時往往是這樣寫的：“完成項目現場調研工作”。

其實完成現場調研工作不是計劃本次活動的目的，而恰恰是完成本次調研目的的有效手段。

那么調研的目的到底是什么呢？

真正的調研目的有三條：

對用戶：讓用戶認為調研者已經非常了解或者有足夠能力了解企業現有業務流程。

對競爭對手：如果是售前調研，還要隨時制造給競爭對手的門檻，了解競爭對手給我們設計的門檻。

對公司：調研獲得信息足夠讓后續者進入下一階段工作。

我們很多人認為調研時一定要搞清楚企業業務，可是一定要切記，能夠評價你是否了解企業業務的人不是你公司的成員，而是用戶。

如果用戶都認為調研者非常或者有能力了解他們的業務，他們自然也比較相信這個調研者的后續的解決方案或產品演示。

如果用戶都認為調研者非常或者有能力了解他們的業務，調研者說服或者高質量幫助公司的同事進行后續工作自然不在話下。

明白這個目的的人，在調研階段就會設計大量的機會不斷強化用戶對調研者的認同感。如果最終用戶認同了調研者，或者大量的用戶認同了調研者，無論是對售前打單還是售后實施就開始取得了最廣泛的支持，項目成功的機會就在不斷的增加。

有的企業業務非常復雜，企業用戶自己都可能搞不太清楚，不太可能在短期內了解全部業務細節，特別是售前調研階段，用戶不太可能有積極性花費大量時間配合進行調研工作，這個時候調研工作目的就是要能讓用戶充分信服調研者所在公司或團隊是有能力了解企業業務。有了這個信任基礎，后面很多工作也容易推進。

有的項目用戶同時安排幾家供應商在同一時間段，或者在很緊湊的一個時間段安排幾家供應商都用兩三天的時間做一個調研，此時所有供應商恐怕都很難立即對項目情況有一個完備的了解，這個時候與其說調研目的是搞完全清楚企業業務流程，不如說是讓用戶認為我們在這個領域最有經驗，最有可能搞清楚企業業務流程，進而給競爭對手制造進入門檻。

所以在調研工作中要通過規范的業務程序讓用戶感覺到我們作為一家大公司的風范，通過業務交流讓用戶認可我們在這個領域的專業知識和技能，通過業務需求確認突出我們強項，給競爭對手制造壓力，同時了解競爭對手給我們制造了哪些門檻，靈活化解，或者為后續技術交流工作提供可利用的信息。

我們調研工作質量越高，認同程度越高，對手壓力就越大。一般對手在壓力下出錯的機會就越多，我們了解充分準備也容易充分，這樣我們項目成功的概率就越大。

調研一旦結束，調研者還要清楚一個環節，調研后要做什么？是做解決方案還是做技術交流，還是做產品演示，還是做實施方案？
　　不管進行什么工作，特別是在后續工作是公司其它同事配合完成的情況下，調研者有責任有義務確認自己調研工作信息明確被需要獲知這些信息的同事收到并理解，并能很好開展后續工作。

做到這一點，調研工作才能算結束，否則調研者個人認為其調研工作質量很高，后續者如果對調研情況不認同或者對調研業務報告不理解，后續工作質量還是沒有保障，這個時候調研工作并沒有發揮作用，所以調研者就是從尊重自己工作的角度而言，也要安排時間讓后續人員認同和理解自己的業務調研內容。

實際上有效的團隊在調研過程中會隨時收集團隊成員對調研記錄的意見，不斷動態調整調研過程，而不是在最后調研結束時一骨腦讓團隊成員吸收大量信息。同樣有經驗的人員在規劃一個項目時也一定會考慮調研工作和后續工作的協同，提前要求各個階段人員及時溝通和配合。

2.2.2 第二個容易犯的錯誤：計劃不夠細致

很多人調研計劃落實具體活動的時候，往往只有這么簡要的幾句，某年某月某日，在某地某部門進行業務調研。

這樣寫計劃要么是不清楚調研從哪里下手，只好先這樣寫著，到現場再走一步看一步，要么就是自以為有一些調研經驗，知道如何處理，所以在寫計劃時為了糊弄內部分管領導，好歹也寫了，質量上偷工減料。

實際上我們寫一個計劃寫給誰看？計劃是我們給用戶分管領導確認的，用戶領導對你的工作內容了解越清楚，他幫助你安排工作就越方便。

用戶領導或者有時候是用戶協調人也一定希望我們在現場的工作緊湊合理，不浪費彼此的時間。但用戶并不清楚如何做這種調研，他們能做的就是按照我們意見盡量安排合適人員配合。

如果你的調研是某幾天要來你們這里調研的話語，實際上用戶領導可能會回答，拿你們先來，來了再說。結果現場大部分時間都在協調調研資源和等待上，大量時間都無價值的浪費掉。

所以一份好的計劃應該是可操作，可執行的，也可以讓用戶看明白的。

我個人建議計劃不妨細化到每天的上午下午分別調研哪個部門，需要怎樣資歷人員配合，需要配合多長時間，將了解哪些方面的業務問題，需要準備哪些相關資料。這樣也便于用戶領導配合安排。

而且一份詳細的計劃做為開始，正是恰到好處的體現了我們的專業背景和職業素養。還有什么比這更劃算的呢？我們只需要做一份合理的模板，每次多寫幾個字，就可以換來一個好的印象。

還有一點必須要明確的是，寫一份詳細的計劃并非一定要讓計劃時間變得很長。任何調研工作都不可能把所有情況搞清楚，調研并不是一次就可以結束的事情。

實際上在一個項目中要隨時有調研的意識，一旦發現新的事實和歷史調研不符合，我們馬上可以重新完善我們的調研結論，進行相關調整。

所以知道這一點我們每次調研都有一個成本的概念，調研的目的對內只是獲得可以進入下一階段工作的足夠質量信息即可。

有時候一兩天的調研也可以達到這個目的，調研同樣可以結束。

即使是一天的調研計劃同樣可以認真細致地準備。

2.3 調研準備階段容易犯哪些錯誤？

2.3.1 第三個容易犯的錯誤：計劃沒有在內部溝通

很多人接到調研任務，將計劃寫好，立即就開始和用戶溝通，工作精神很好，是不折不扣的行動派。

但是前面已經強調過，調研工作不是一個單獨的業務行為，調研是承上啟下的一個工作。所以我們的調研計劃一定要征求客戶經理，參與過調研其它人員意見，一些重點項目甚至是公司高管的意見，看看是否還值得推敲。

最關鍵的是，內部溝通計劃的過程是和其它部門約定后續工作配合的過程，通過內部溝通在完善調研合理性基礎上實際上確定如果調研工作結束，如何將我的工作移交給其它人，便于其安排后續工作。

調研者不要匆匆忙忙搞完一個調研，提交一份文檔，就投入另外一個項目。然后客戶經理過了一段時間又要求演示，然后演示準備者看著業務調研報告云里霧里的時候，又無法和調研者當面深入溝通一下業務，無法高質量開展工作。

所以做內部溝通的時候實際上也是調研者的一個自我保護，和別人約定階段工作的輸入輸出文檔和質量要求，那么做完這份工作，后續同事也就能夠獨立開展工作，而是是糾纏不清。

例如有的項目在調研階段就要同步準備演示方案，那么調研者最好在調研階段就清楚誰負責這個演示配置，并在調研期間約定和其有效溝通方式，便于在調研進行時可以考慮如何準備。

如果很明確要進行這類工作，但又沒有安排演示準備人員。調研者作為一個職業人員，我們至少要盡到提醒客戶經理去申請資源提前準備的責任。

幫助自己團隊成員少犯低級錯誤也是一個成熟職業經理人的心態，不管你的工作崗位有多么重要或者不重要。

此外在內部溝通時，如果是售前項目，要考慮和客戶經理溝通一個很重要的問題：調研的切入時機。

一般情況下不要輕易的做第一個調研者，做第一個調研者一定要安排能力強的人，在用戶關系不錯的情況下，經過調研做好工作，給后續對手制造壓力。

因為用戶如果發現后續者能力不強或者不夠職業會加強對第一個調研者的認同感。

但是如果你派的人能力不足，那就給對手超越的機會此時再次安排調研，已經很難挽回第一印象分。

不做第一個調研者除了規避這方面的風險之外，還有一個比較大的好處：不做栽樹人，要做栽果子的人。

很多用戶往往并不清楚他們要購買的軟件到底是什么東西，所以第一批調研者很多精力要花費在灌輸概念的工作上，如果基本概念不清楚，用戶往往不能提出有價值的需求，調研時往往沒有邊際。

第二個調研者再進行調研時用戶就會清楚很多事情，回答問題質量就比較高，同時我們也可以有機會了解對手的牌，進行針對性準備，后發制人。

當然何時切入調研應該更多程度上是客戶經理考慮的工作，我們調研者至少要知道客戶經理對這個問題是如何考慮的。此外調研一般要客戶經理到現場配合，所以調研計劃行程安排也一定要得到客戶經理確認，防止出現意外變化。

不過說實話在這個行業內，基本上客戶經理是很幼稚的，調研工作往往是盲目啟動，草草收尾。

2.3.2 第四個容易犯的錯誤：計劃沒有得到用戶確認

我們有的人把調研計劃做好，告訴用戶形成，就準備按計劃去現場了，這樣的調研者不及格。

有的人會提前發郵件或傳真給用戶，然后電話確認收到，然后確認時間無問題，然后再去，這樣的調研者60分。

有的人不但會確認計劃時間，還會認真了解計劃內容是否認同和有相關業務人員配合，得到肯定承諾后再去，這樣的人80分。

有的人還會準備一些前期調研文卷和資料準備清單，讓客戶經理配合落實后再去調研，這樣的人100分。

我們至少要做到80分！

計劃發給用戶后用戶一般是不會認真看和落實的，這是中國人做事的習慣，特別是一些地位不高的聯系人，可能連為這個事找領導這個協調的膽都沒有。

所以打電話確認的時候一定要請用戶確認是否可以按計劃進行，得到肯定答復后再出發，這樣第一計劃執行保障性會高一些，第二也給別人留下一個認真的印象。

這個計劃落實的工作也可以和客戶經理溝通后，請其利用其在企業的人脈落實。

最近我有一個同事就犯了一個這樣的錯誤，代理在合同簽訂后非常著急催促我們去現場落實調研工作，這位同事就立即制定計劃，并發送給代理，同時電話確認收到計劃，然后就立即按計劃動身。

結果到了現場，代理說用戶還沒有準備好，你怎么就來了？我們的同事也很郁悶，計劃上說如果有問題就打電話，沒有問題就不用打電話，既然沒有打電話反對當然是按計劃執行。結果雙方的開始很不愉快，這就是不了解中國人的辦事特點造成的，中國人是預期性的事情一定要口頭溝通確認，擔責任的事情一定要書面溝通確認。

2.4 調研準備階段容易犯哪些錯誤？

2.4.1 第五個容易犯的錯誤：沒有認真進行準備

調研要認真準備，但說來容易做來難，很多人調研前的準備工作其實都是很隨意的。

沒有經過認真準備的調研，到了現場很可能對各種突發情況措手不及。

從應付各種用戶刁專古怪的問題的角度而言，調研準備永無止境。

好的調研準備工作可以包括這么18個方面：

1、如果有的話，一定要認真閱讀商務合同和技術協議。

2、閱讀前期技術方案和各類備忘錄。

此點非常重要，不僅僅要閱讀，還要保證自己工作質量和規范和前期保持一致，一個行為高度一致性的公司是核心競爭力很強的公司。

此處有一個很重要的工作一定要向前期參加工作人員了解是否已經收集了一些資料，并想辦法獲得，已經搜集的資料和問題盡量避免重復詢問，這對用戶會造成巨大不滿。如果萬一前期資料不能獲得，也要另外提前準備好說法避免這種情況出現。

3、和項目前期人員(咨詢顧問、客戶經理和平臺主管)充分溝通。

聽取他們的建議，使自己調研更有針對性。

4、熟悉公司已實施的相近項目的情況。

他們企業業務調研報告和解決方案將對我們現在工作很有幫助，甚至在調研過程中給我們很多思路上的啟發。

5、熟悉相關軟件產品的功能及發展方向。

很多人在工作中不注意和規劃人員的溝通，其實在調研前確認自己了解產品的發展方向，現有和近期可實現的功能對調研時遇到一些很難回避的技術問題就可以做到心中有數，提前想好說法。當然最好的說法是這個功能我們已經實現了，在某某項目上也是這樣要求的。

6、了解企業所處行業的行業特點、競爭態勢、產品研發特點。

這些要從公司，特別是網上查詢資料分析，建立一個基本的業務原型，這樣在調研時可以讓用戶感覺到我們還是做了很多工作，對項目很認真。

7、準備同用戶交流時的軟件原型或交流PPT。

有的時候用戶在調研過程中提出要我們做一個培訓和軟件演示的要求，一般情況下我們應該避免在售前調研階段做這個工作，因為這些要經過精心調研仔細準備后再進行質量更高。

但在售后實施調研時我們可能要先主動做這個軟件演示和理念培訓工作，收斂用戶的思路，引導項目邊界，所以調研者也應提前對這些方面工作做一準備。即使是售前也很難完全避免這個情況，不但要準備，而且在語氣上還要有所區分。

8、準備企業業務調研問卷。不一定要給用戶，但一定可以讓自己不遺漏該問的問題。

9、設計業務調研方案。業務調研方案可以將自己調研經驗不斷積累，形成體系化的經驗，大家現在看到的文字就是我不斷完善業務調研方案的結果。

10、設計業務調研計劃。計劃一定要用心，用心才能做好。

11、準備業務調研培訓材料。

到現場調研時需要讓用戶知道我們的調研方法和思路，用戶才好配合，也認可我們的專業化程度，這個應該結合公司流程和自己體會進行準備。

12、軟件安裝盤和加密狗。有備無患。

13、電腦筆記本。IT農民的必備勞作工具，如果沒有就用筆記本解決問題，沒有電腦前麥肯錫一直是手記錄問題，現在他們還是提倡手記錄，因為方便。

14、WINDOWS2000/SQL SERVER/ORACLE安裝盤等常用工具軟件安裝盤。有時候很有用。

15、別的項目常用樣例及標準配置，用戶很難提供明確需求的時候，讓他們看看我們在別的企業成功樣例，有助打開思路，也體現我們給用戶帶去先進管理方式和成功經驗的合作初衷。

16、公司各種流程管理文檔。對于一些用戶了解我們公司內部問題的時候，如果搞不清楚該什么講的時候不要信口開河，翻翻資料再說。

17、可能涉及業務難點培訓資料和問題集。

用戶的問題千奇百怪，多準備一點沒錯，不斷積累這些問題就是一個個人知識完善的過程。

18、公司小禮品。

調研完成后送給調研對象一個小禮品是很容易給對方留下好印象的機會。如果有政策，一定不要浪費。

實際上我們每個做過調研的人捫心自問，調研準備18條我們到底做了幾條？

也許認真不認真就是我們一個工作到底有沒有質量的根本原因。

2.5 現場調研階段容易犯哪些錯誤？

調研計劃確認，抵達現場就需要進行調研工作。在調研工作階段我們常常容易犯以下錯誤。

2.5.1 常見錯誤一：立即進入調研狀態

很多人非常努力，一到現場，就開始按計劃進行調研工作。

其實調研計劃到現場第一件事情不是啟動調研，而是再次確認調研計劃。

這樣做的理由有三點：

第一雖然很多企業和你電話口頭認同了計劃，但只有調研者到現場了才會真的重視，所以我們必須要重新確認計劃，保證我們的計劃需要的調研配合資源已經落實；

第二確認調研計劃往往不是和協調人確認，要主動通過這個機會見一見企業負責的高管，很多時候企業也會安排這個一次見面。和高管見面要做好三件非常重要的事情：

一、匯報我們的計劃，請其再次確認，并請其協調資源安排人員配合。

記住給領導溝通最有效方式之一就是“多請示，多匯報”。根據我個人的經驗，一般領導看過的東西不如口頭匯報的東西印象深刻，匯報也是建立領導對我們認同的手段。

很多時候被調研人員不愿意配合我們進行調研，因為這樣可能會影響他們正常工作或者有其它顧慮，所以當調研工作是領導的工作任務安排，他們配合積極性就高了。

很多時候領導也不能立即協調完所有的工作，特別是這個時候可以要求領導配置一個專門的聯絡人，由他出進行聯絡工作，可能的話，也要求其全程參與調研，這樣的人會給調研帶來極大方便。

二、匯報我們的調研工作方法，讓高管覺得我們做事很有套路，同時請其提出意見，做相應客戶化調整。

在匯報計劃的同時要順便告訴高管我們調研工作方法，先做什么，后做什么，每天需要如何開始，要花費多少時間調研，花費多少時間在整理，是否要開一次業務分析會，需要哪些人參加。

領導明白你思路了，也就知道我們這些天工作量都會很飽滿，很有組織性，也就對調研工作有信心并積極支持。

此外領導可能提出一些要求，例如進行培訓或者其它要求，我們可以根據實際情況確定是否要進行或者不進行。此時就有可能需要調整計劃內容和時間。

三、借匯報機會領導了解他們上項目的初衷。

很多時候領導看待一個項目角度和高度和我們進行下層調研人員理解是不同的，這個時候和領導交流其對項目的想法，是有助于我們在調研工作進行時判斷一些業務需求是否真的符合企業領導的構思，并可以尋求更好的方案。

從調研的角度，了解不同人員對同一個項目的需求也是調研工作的一個內容。領導層往往是管理性思維，業務層往往是技術性思維，兩種思維達成一致才能設計一個好的方案。這些都需要通過調研獲得。

第三和高管見面要約定如何匯報工作的機制。

調研如果有一段時期，不可能天天找領導匯報，也不能不匯報，那么這個時候就可以請示領導每幾天安排一次當面匯報還是書面匯報。

多和領導見面，多用肯定語氣溝通，就會讓領導不斷強化對我們積極的印象，逐步將感情的天平傾斜到對我們有利的方面。

不過有一點，首次和高管匯報工作原則一定要言簡意賅，不要表現自己。

讓領導建立對自己個人專業認同感就可以說達到目的了，對于一個領導認為有專業技巧的人，見面的機會他是一定會繼續提供的，所以不要追求一次搞定，這都是極為有害的冒進思想。

低調切入，等調研過程中收集足夠事實了再根據情況確定是否逐步抬高調門，表現自己的思路，是更穩妥和合理的策略。

和高管見面可能存在一個時間不確定因素。所以在調研準備階段計劃確認時盡量先保證這個時間，如果到現場時間不能保證，必須留機動調整的可能，一般情況下可以進行企業歷史，企業現狀，網絡硬件，組織機構等方面的業務調研，也可以為領導見面提供溝通的素材。

此外高管并非一定是企業的最高領導，高管是依據企業規模和項目規模動態確定的，一般選擇匯報高管對象的原則是對項目直接負責的人上級或以上級別的人。

企業大了，高管并非只有一位，有的匯報必要時該重復就重復，不要給別人不尊重的感覺。

2.5.2 常見錯誤二：匆忙地進入調研狀態

計劃一旦得到領導確認很多人就立即著手調研，這個時候容易犯的錯誤就是匆忙地進入調研狀態。

進行具體調研業務前首先是和企業調研協調人確定今天一天的調研計劃和資源可以到位，如果萬一今天計劃所在配合資源不在，給企業調研協調人幾個替代性調整方案，其負責落實到位后才能放心的開展調研。這就避免出現上午調研完了發現下午沒有人配合了的情況。

這個提前預約時間，即尊重被調研用戶又讓被調研用戶有所準備，保證質量。

那么安排用戶配合調研工作在可能情況下一定還要得到其直接主管領導的確認，讓訪談者上司出面安排會面會保證調研者的積極性，他就不必擔心調研影響正常工作而導致直接領導不滿。

這些工作完成后還不以開始調研，而是針對所訪談的對象，再一次回顧自己要問的問題，理清發問的思路，不要想到什么說問什么。

想清楚后就可以開始調研了，但和被調研對象見面不要三句話不到就立即進入主題，必須有一點點鋪陳才能展開調研。

這個鋪陳包括三個方面，第一是自我介紹，有時候還包括公司介紹，調研者也是公司的活名片，第二是了解被調研者的背景，對其配合調研表示感謝，順便奉承一下，例如說能得到您這樣有經驗人員配合是我們非常高興的事情，讓其有一個好心情開始配合調研工作，第三是對調研總體內容和時間有一個說明，說明我們想通過調研能為其業務設計好的信息化支持手段，讓其配合時做到心中有數，樂于協助。

做完這些工作才不是匆忙展開調研工作。

2.6 現場調研階段容易犯哪些錯誤？(二)

2.6.1 常見錯誤三：不斷地問問題，唱獨角戲

很多人在開始進行調研的時候準備了一份業務調研問卷，所以在調研的時候就按照調研問卷開始提問，這個方法對剛開始做調研的人是很有用的，可以幫助他在對業務不熟悉的時候不至于無話可問。

但這樣調研的后果就是調研者在唱獨角戲。調研者不停的提出問題，被調研者不斷的再回答，好象成了一種審問和被審問的關系，這樣的調研狀態雖然可以收集大量信息，但從調研角度而言，不是最佳的選擇。

真正有經驗的調研者首先是先向用戶了解整個業務過程，在具體業務過程中順便了解我們想重點關心的問題。

被調研的用戶如果沒有經過精心準備是無法回答很多具體的問題的，他也不知道你為什么要問這些問題，這樣的問題問多了，用戶一定很厭煩，也會產生一些戒備心理。

但是所有用戶一定很熟悉自己每天進行的業務，并知道業務中他感覺比較痛苦的一些問題。所以調研的方式應該是站在用戶的角度了解業務，有了一個對業務的總體認識，再了解細節也就更深入和細致。

所以好的調研者要充分的讓用戶講話，自己只是在提話題，讓用戶有興趣有心情把自己知道的事情完整有序地講明白。

舉一個例子，我們做PDM調研的很多關心你用什么設計軟件，產生哪些格式，每月設計幾個項目，產生多少圖紙，但如果是一個個問題這樣問下去，對用戶而言的確是一種折磨。還不如問他你每天設計任務是如何獲得的，如何開始，需要哪些資料參考，做完了以后形成什么文檔，交給誰？在這個過程中您覺得什么地方不太方便？在整個業務調研過程不斷順便問一句，這樣的任務你每個月大概接多少，多的時候多少，少的時候多少，每次出圖量多少，用什么軟件設計為主之類的問題。

這樣交流的好處是用戶對熟悉的業務可以很自如的進行表達和溝通，而不至于讓整個交流變成一個單向的信息收集，交流的氣氛會越來越好，問題也會越談越深入，而不僅僅停留在一些準備的表面問題上。

而且很多問題在一次業務溝通中就交流完成了，不需要反復去問，增加被調研者的工作強度，也節約了調研者的時間。

一個小塊業務問題問完后立即要做的一個工作，也是很重要的工作：立即主動復述用戶所講的業務和過程，讓用戶確認你明白他所說的內容。

當用戶發現他說講的內容你可以理解并接受的時候，是很高興的，第一覺得自己沒有白講，第二他就開始認為你也是比較熟悉業務或者有能力熟悉業務的人員了，第三如果發現復述有什么不對，可以立即糾正。

所以調研不是調研人員的獨角戲，而是用戶為主介紹，我們只要起到引出話題，復述內容的作用即可。一個滔滔不絕的用戶應該是一個成功調研的特征。

調研結束后一定不要忘記的一句話就是感謝！

感謝之余還要請用戶有時間審核我們的調研記錄。

根據麥肯錫的建議，有些人在快結束會談時可以再提出一個相對敏感的問題，這個時候問題人容易放松，會有心情回答一些一開始不愿意回答的問題，這個辦法有時候可以試一試。

2.6.2 常見錯誤四：不注意收集異常的事實，挖掘背后的需求

很多人做調研，問問題很積極，溝通也很有技巧，但是就是缺少一些職業敏感，很多很有價值的信息用戶已經說出來了，就是不注意。

一般多次調研的人很容易發現很多業務在不同的企業都是一樣的，漸漸在調研中失去新鮮感，其實調研不是簡單了解企業業務流程，而是要找到業務流程中問題。用戶請我們來就是準確發現問題，然后再提供解決方案的。

可以如何發現問題呢？

問題往往是隱藏在意外事故之中的，如果聽到一件和流程不符合的事情，或者和管理預期不符合的事情，這些事實就是異常的事實，值得我們高度重視，深挖窮究。

為什么會產生這個事實？原因是什么？這個原因到底是什么產生的？一層一層了解下去，就象撥筍一樣，最后把事情分析得很透徹和明白了，問題的解決思路也就出來了。

比如有的企業更改非常多，很多調研人員就寫上一句，更改管理業務很重要。或者更改管理是要重點解決的問題，可以為什么企業有這么多更改呢？這樣一查下去，就會發現不同企業造成更改的原因是不同的，不同的原因自然要用不同的藥去診療，才能收效。

如果我們不關注細節，不收集大量支持我們的事實，等我們真有機會見高管的時候，我們又怎么讓企業領導相信我們這些相對年輕的人可以找到企業的病根，并有好的解決思路呢？

唯有事實，大量的事實會幫助我們說服企業的領導支持我們。

所以在調研過程中要隨時分析現有流程存在的問題，而且一定要找到事例證明問題存在，并事后分析可能存在的改進點。

打動用戶的力量就在在于你對其業務了解的程度！

2.7 現場調研階段容易犯哪些錯誤？(三)

2.7.1 常見錯誤五：每天調研工作時間太長

有的人有一個習慣，喜歡把調研工作都完成后才開始寫調研報告，認為這樣有整體感。有的人每天從早調研到晚，用個把小時整理下調研記錄。這些都是不好的調研習慣。

其實每天調研的時間一般不要超過四個小時！

對每個個體一次訪問的時間也不要超過兩個小時！

四個小時的調研內容是需要用同等長度甚至更長時間整理才能成型成體系的，所以在每天的調研計劃中，必須要和企業溝通好我們自己的工作方法，保障我們整理調研內容的時間。不要讓用戶以為我們每天沒有調研的時間沒有在工作，實際上為了整理四個小時的調研內容往往要用掉八個小時。

如果要想控制每次調研時間又不至于遺漏關鍵信息，比較好的方法有兩個。

第一是將要調研的問題結構化，建立結構化的問題可以方便自己快速把調研信息轉換成調研記錄，也容易防止遺漏問題。

問題結構化就是針對一類業務將一組相關問題形成一個開放性和封閉性的問題引導區，這樣在短時間內可以把一個業務快速搞清楚，被調研者也容易順著業務思路解釋。

第二就是盡量不要一個人調研，應該兩個人調研，如果兩個調研者中有一個是企業項目組成員就更好，因為大家可以一起在調研中互相補充可能會遺漏的問題。而且可以一個主問，一個主記，合理分工，提高單位時間內的調研生產率。

調研完成后要及時迅速把調研內容轉化成文字，而且要轉化為結構化文字，不是用戶說什么我們寫什么。這樣做有很多好處：

第一避免遺忘，好記性不如爛筆頭，調研過程中不停把信息記錄在本子上，但可能還是有一些遺漏，必須用一些時間趁著大腦有印象，趕緊補記下來。

第二寫記錄的過程就很容易發現一些自己感覺清楚但實際上并不清楚的內容，這些內容馬上可以形成第二天的問題進一步確認，把調研逐步推向深入。

第三每天寫清晰完整的調研記錄，可以立即反饋給用戶確認修改，用戶也會認可我們的職業精神和專業水準，而且每天都看到具體的工作內容記錄，工作成果也容易得到確認。

第四可以反饋給公司相關同事，讓他們立即提供反饋意見調整調研進程。

第五整理的過程就是對企業問題深入思考的過程，這是一個很有趣的腦力勞動。

有的人想在這些方面偷懶，不隨時注意整理調研信息，最終調研報告質量就不會太高，缺少深入的分析，也就不能為后續工作提供有價值的信息。

2.7.2 常見錯誤六：聆聽，而不是提供解決方案

有的人在用戶提出一個疑難點的時候，很希望把自己的產品特色展示出來，花了大量時間講自己的賣點和特色，給用戶做了大量啟蒙工作。

當然有些用戶還會對一些特色功能念念不忘，并拿來要求其它供應商提供。

其實在調研過程不是做解決方案的過程，調研就是為解決方案奠定基礎的，過早在調研過程中提供問題的答案有如下壞處。

沒有經過精心準備的演示可以有幾個亮點，但很難形成整體打動別人決定性力量，反而浪費了調研的時間，影響了為有價值解決方案制作的調研時間。

提供解決方案往往是臨時思考沒有經過全面分析，難免偏頗，為了表現能力而承諾一定可行的內容發現實際上并不是那么容易，導致后期實施騎虎難下。

做項目不是一個人在做，而是一個團隊在做，如果沒有溝通就向用戶提供了自己的思路，可能會給整個團隊的思路帶來干擾，解決方案一定要在內部達成一致才能提供給用戶。

一些的確非常成熟有特色的業務解決方案可能會提前泄露給競爭對手，對手可以針對性進行準備，導致殺手锏失靈。

所以調研過程中不要過多花費精力介紹我們的產品，而是做一個好的發問者和聆聽者，用耳朵去聽，用心去想，用大腦去分析用戶的信息，去發現有價值的內容。

2.8 現場調研階段容易犯哪些錯誤？(四)

2.8.1 常見錯誤七：沒有開業務分析會

很多人做完調研，就按計劃打道回府，準備后續工作，其實有經驗的調研人員還會多做一個工作，就是開一個針對企業領導、項目負責人和主要業務層面的調研工作匯報會。

我們說調研目的是讓用戶讓用戶認為調研者已經非常了解或者有足夠能力了解企業現有業務流程。

單個用戶是否建立這種認識我們是通過復述技巧實現的。但對于企業領導又如何知道我們了解企業業務呢？

有人說這些將在解決方案中完整體現，不過說實話，有幾個人相信我們這些管理供應商寫的多達百頁的文檔企業里會有三個以上的人看一遍？

都是在浪費紙張而已！

所以在調研完成之前，在調研計劃中調研者應主動安排或者創造這么一次匯報的機會，專門陳述我們對企業業務和要解決關鍵問題的認識，這個認識陳述好了，企業自然對供應商刮目相看，就算有一些偏差，也可以立即得到糾偏的機會。

這個匯報會時間不一定要很長，但可以讓企業領導真切感到我們調研工作的成效，我們對事實把握可靠程度，我們對企業業務了解深入程度，我們對問題分析細致程度，我們在該領域的專業程度即可。

有了這個階段性總結，調研工作就可以說順利完成了，可以進入下一階段準備工作了。

不過在業務分析會上一定要注意一點，不能用過高的姿態切入。

有的人經過調研確實發現了企業一些問題，也想到一些很好的解決思路。于是其在業務分析會上企圖指點天下，痛陳不足，確有嚴加改進必要的時候，就有可能犯一個大錯誤的時候。

有了表現欲，就容易昏頭。

業務分析會一個鐵的原則就是不要輕易說自己用戶的不足，即使要說，也應用一種委婉的方式表達；指出可進步的地方，而不是指出落后的地方。指出不受控的地方，而不是失控的地方，指出實現不方便的地方，而不是指出無業務管理覆蓋的地方。

這些都是做業務分析會要替自己客戶考慮到地方，不要隨意批評別人不足，也不要以為企業沒有人知道這些毛病，更不要以為他們不知道這些毛病該如何解決，有時候無非是外來的和尚無牽掛，好念經而已。

2.9 現場調研階段容易犯哪些錯誤？(五)

2.9.1 常見錯誤八：只重視正式溝通，不重視非正式溝通

調研工作特別是在正式調研活動中有些問題并不方便了解，所以調研工作還包括一些非正式場合，這些場合適合調研者問一些相對敏感或者自己有看法但沒有把握的問題。

所以調研不僅僅在工作計劃中所列走訪，座談，會議等形式中，也在和用戶一起聚餐等非正式溝通活動中。

只要調研計劃沒有結束，所有的時間都是為調研而準備的，走路，閑談，吃飯都是可以進行調研的機會，不一定要正式場合才能開始調研。

這種非正式溝通信息一樣很重要，而且往往是真實運行企業的信息，和正式調研得到的信息正好可以互相印證。

在非正式溝通中調研者還可以和企業一些人建立友好的關系，為今后工作也奠定了良好的基礎。

所以好的調研者不僅僅是一個專業人員，在非正式場合也是一個可以讓別人說話的人，這樣的調研行為才是完整的。

2.9.2 常見錯誤九：關鍵業務只詢問了個別人意見

一些業務在整個調研工作中是占據很重要分量，而且涉及多個業務部門，這個時候調研就要記住“兼聽則明，偏聽則暗”，一定要把業務涉及不同部門意見都聽到，也要把不同人對同一業務描述進行對比調研，從中能發現很多錯誤。

此時不可因為覺得調研內容很飽滿或者時間緊張而只做單點調研，關鍵業務一定要從其它人那里不斷得到印證。

不過再問第二個人的時候，就可以用主動復述業務的方式，請其重點指出不對的地方，加快調研進度。

2.9.3 常見錯誤十：調研時有選擇問問題

有的調研者在調研階段就非常小心，特別是在其對自己軟件不足的地方有足夠了解的時候，總想在調研階段引導用戶，接受自己的系統，繞過這些自己產品不足的地方，這也是一種錯誤的做法。

首先如果調研發現用戶迫切需要很有價值的問題是公司目前不能解決的問題，并不等于不調研就可以回避，無論將來在技術答辯還是售后實施，這個問題總是要冒出來，與其回避，不如主動搞清楚，匯報給公司，看看到底有什么辦法可以解決。

真正的問題都是回避不了，繞不過去的。

我個人意見，越是有公司明顯不能解決的問題，越要調研清楚，搞清楚來龍去脈，為公司今后產品發展提供完整的需求建議，作為一家負責任的軟件公司，首先要承認自己的軟件不可能解決所有的問題，但一定要在發展過程中逐步解決更多的問題，調研時都回避了，不就失去了公司產品發展的機會了嗎？

其次如果有選擇性問問題，就會遺漏一些關鍵性業務，這樣對調研整體質量有影響，在后續工作中容易被動。

至于不想將用戶一些天馬行空問題，或者的確不想引發他們高度興趣的問題回避的方法，不是不通過調研，而是認真記錄，但不提供在正式文檔的方式規避。

很多人很多需求都是一時靈感，沒有經過認真思考，所以口舌之快，過了也就過了，不形成文字記錄，他自己也不記得自己說過什么了。如果是真的關鍵問題，在后續復述，確認調研記錄還有業務分析會上還會提出來的，這個時候再確定寫入正式文件也不遲。

對于這些暫時不能滿足的需求和超出范圍的需求，可以另外整理一份內部文檔給公司分析。

2.10 現場調研階段容易犯哪些錯誤？(六)

2.10.1 常見錯誤十一：一次調研就企圖鎖定需求

很多項目啟動后轟轟烈烈進行了一次深入調研，然后開始配置開發實施，忙得不亦樂乎。好象把企業問題搞清楚了，就應該是實現和解決的階段。

實際上很少有人能夠在短短幾天內把企業的問題搞清楚，即使你努力進行了半個月甚至一個月的調研，在實施過程中你還是會發現對很多問題認識我們依然不夠深入，不夠完整。

這個時候我們應該意識到，我們依然還需要進行調研，切不可因為是大規模調研完成了，對此時的調研就隨意了，不留記錄，不進行確認了。

事實上這些調研信息要隨時記錄確認并最終完善到項目解決方案中，可以這樣說，信息化項目中始終要有隨時開始調研的意識，如果我們承認信息化需求是無止境的話，那么調研也是無止境的。

為什么不能通過一次調研鎖定需求呢？

正確的需求是系統成功的關鍵。預先鎖定需求的假設前提是用戶不經過系統上實踐的過程，用戶就能預先精確的提出所有的系統需求。

某些簡單軟件或者具有極高技術水平的用戶可能可以，但是一般情況是用戶只對其目標和需求最初只有模糊籠統的認識，許多細節都不清楚。要求一個只有初步設想的用戶或個別用戶負責人準確無誤地說出全部需求，顯然是不切實際的。

用戶為了證實和細化他們的設想，往往需要在某個系統上持續不斷學習和實踐的過程。特別是在大型管理系統軟件上。

即使經過深入細致的預先鎖定需求的工作，當人們實地觀察和使用了目標系統以后，也常常會改變原來的某些想法，對系統提出一些新的要求，以使系統更加符合他們要求，事先鎖定需求的方式其實也會經過多次反復，甚至完全失敗。

大型軟件的開發需要系統分析員、軟件工程師、程序員、實施經理、用戶領導、用戶負責人、具體用戶等眾多各類不同層次不同技術水平人員的一致協調努力，因此良好的通信和相互理解對于保證工程成功至關重要，傳統的需求鎖定方法假設使用適當的文檔可以做到項目參加者之間清晰、準確、有效的溝通。但是各種文檔本質上是被動、靜止的通信工具，通過它們來理解一個動態系統是困難的。

用戶變更需求是正常的，用戶沒有實際操作過軟件之前無論你怎樣描述都會有對軟件功能理解不一致的地方，可能是技術協議上書面文字表達一致但對實際軟件操作理解不一致，可能根本就是不用不知道哪里不適合自己的需求。

打個比方，就象買衣服，無論別人怎樣推銷，客人一般都會試一試覺得合身再買，我們一般比較大的項目都沒有讓用戶體驗過而且在推銷時說了很多動聽的話，自然期待高，失望也高，而且用戶為適應ISO認證或PDM/ERP系統必然伴隨組織機構和業務流程重組，這里面有很多反復的過程，對應的文檔，設計流程，對軟件操作提出變更是正常的。

我們的問題不再于要用戶不變更需求，而在于找到一種方法讓用戶認識到我們的軟件能發揮作用，當有新的需求時通過使用我們軟件建立的信任關系重新形成新的業務，這也是調研時要保持一種理念。

2.10.2 常見錯誤十二：調研工作表現不職業

有的調研人員工作很努力，但在現場很難得到用戶的認可，就是因為經常表現出一些職業不成熟的緣故，甚至有的表現是不道德的。

常見不成熟職業表現有：

1、 不征求用戶同意就翻看其資料(如果有的競爭對手敏感資料想獲得，也一定不要給別人看到)；

2、 調研過程中電話短消息不斷；

3、 在用戶現場上網工作時順便聊天看和工作無關的內容；

4、 沒有征求用戶同意使用用戶電話；

5、 用戶同意使用電話講起來沒完沒了；

6、 對用戶現有各方面狀態流露輕視的態度，例如認為用戶條件不成熟，管理不到位，表現出眼界高人一等的想法。

2.11 調研工作方法推薦

2.11.1 每日調研流程

1、提出調研內容，請企業項目組成員配合預約人員時間安排訪談；

2、訪談

3、當場復述內容，確認理解對方表達的問題

4、立即將整理訪談結果形成文檔記錄，確認需要繼續了解的內容和未清楚的內容

5、如果需要，安排時間請被訪談對象確認訪談文檔記錄，特別是一些關鍵名詞定義部分

6、和企業項目組成員配合約定下一時間段訪談安排。

2.11.2 訪談成功的九個要點

讓訪談者上司安排會面

調研前應向調研者介紹調研內容和時間大概安排，讓其心中有數

聆聽，不要發表指導意見，要靠和用戶交流發現問題核心所在

隨時收集和記錄事實，尋找異常現象，發掘管理改進需求，認真記錄并探討原因

盡量兩個人一起采訪，最好一個是企業項目組的成員

復述、復述再復述

一次不要問得太多

在結束會談后又提出一個問題

訪談結束后一定要表示感謝

2.11.3 良好的結構化調研順序

先了解企業基本情況和項目組成員情況，由此建立對企業初步認識，對項目有個初步判斷；

再了解企業組織結構和崗位設計，由此確定訪談對象；

再逐個按照業務口了解業務流，業務流要關心業務可以劃分為哪些階段，每個階段應該是相互獨立，彼此窮盡的。

每個業務階段要問清楚業務目的，輸入數據和輸出數據，過程步驟，每個步驟的負責人，什么時候開始，什么時候結束。

輸入數據其什么作用，有哪些信息傳遞到輸出數據中。輸出數據又起什么作用，是指導下游還是反饋上游。

業務流程調研質量評判標準就是能否清晰簡明畫出企業業務流程圖和數據流程圖。

2.11.4 售前和售后調研的不同

售前調研一般是為產品演示，技術交流做準備，同時調研過程要注意突出自己強項，給競爭對手制造門檻。

售后調研一般是為解決方案，項目實施做準備，同時調研過程中要注意尋求項目價值點，利用價值點置換項目邊界，盡量把項目邊界最小化，項目才容易成功和受控。

售前調研一般由商務主動和用戶協商時機，根據實際情況確定先調研還是后調研。售后調研必須盡快啟動，而且應該在項目啟動大會后展開調研。

售后調研前一般要和企業高管親密接觸，取得支持。在啟動大會上對調研方法和需要取得支持告訴企業配合人員后進行。

售前調研一般要協助拿項目，所以不要輕易發表對問題傾向性看法，要了解事實，用比較文飾的語言表達對問題的認識，通過對事物認識深度獲取支持。售后調研可以相對直接提出問題，擺事實，陳厲害，爭取最大范圍重視，進而獲得支持。

2.11.5 如何寫調研日志

調研日志有三個要求：工作過程清晰化，調研內容結構化，不明內容有后續計劃。

首先調研日志上要看出本日你調研了哪些部門，走訪了哪些人，用了多少時間，獲取了哪些業務的信息，這就叫工作過程清晰化。

然后調研內容不能是流水帳記錄，必須將被調研者的話組織成一個個合理的單元，這些單元獨立可以反映某個業務層面的情況，然后整體上構成一個業務調研報告的部分。

不同的信息結構化方法可能不太一樣，有的適合用表格，有的適合用文字段落，有的適合繪制圖形(例如框圖，魚骨圖等等)。

調研日志最后要說明今天調研中還有哪些問題，需要進一步明確，并有認真記錄。

2.11.6 如何寫調研備忘錄

調研備忘錄一般情況下并不是把自己調研日志的內容匯總重新羅列，因為調研日志和業務調研報告就是做這個工作的。

調研備忘錄和一般的備忘錄一樣，主要是說明本次現場工作進行了哪些工作內容，達到了怎樣的目的，和企業約定的下一步工作安排是什么，并得到企業負責人簽字認可。

備忘錄主要讓用戶看到我們做事的規范性，而且在今后合作中將不斷用同一格式備忘錄強化我們在規范上的一致性，同時備忘錄要讓用戶感覺到我們本次現場調研工作時間緊湊，內容豐富，層次清晰，讓用戶對我們形成良好的印象。

2.12 接口調研背景知識(上)

現在管理軟件項目中接口需求很多，很多項目接口實現得并不理想，原因就在于接口協議質量不高，而接口協議是和接口調研緊密相關的。一般接口調研和其它調研方法是一樣的，但要做好接口調研就必須具備一定的專業知識，這可能是能否做好接口調研的關鍵。

接口協議除一般性協議要素外，應該包括如下內容：

2.12.1 接口技術實現方式

接口方式最高級一種是主動式。

即通過直接對其它軟件的數據庫進行操作。這種方式因為涉及到對用戶數據讀寫操作，對于對方軟件而言，安全性是最大的問題，驗證的復雜程度也最高。主動式基本有兩種方式：

1)DATA方式，通過數據庫語言對數據庫進行直接讀寫。這種情況要求對對方數據有詳細認識。需要對方的人員可以提供數據庫的詳細資料。為了保障數據的安全，要界定對讀寫要求。一般和用戶自行開發的系統會比較多出現此類要求，商品化ERP很少提出這種方式。

2)利用其它軟件提供的工具。除了直接對數據進行讀寫外，有些軟件也提供了一些工具(可能是控件，函數，腳本等)。可以通過這些工具對數據庫進行操作。例如現在神州數碼易飛ERP就全部采用控件方式接口。

這種情況下要提供這些工具的詳細使用說明。

接口方式相對主動式的就是被動式開放。

同主動式對應，即開放軟件商自己的數據庫或開發接口給其它供應商讀取數據。這種方式涉及到軟件商提供的數據或開發程序。對方要我們的哪些數據，將成為了解需求的重點。按提供方式的不同可以分為以下四種。

1)DATA方式。即開方我們的文件或數據庫格式給對方。由對方軟件直接讀取數據。這樣的情況一般在企業有開發能力，而且只需要信息提取(不是寫入)時才使用。這種情況很少。

2)腳本方式。早期的腳本語言，多是一種專用高級編程語言。實現了基本的程序流程語句，簡單的數據結構，在此基礎上，提供訪問軟件內部數據的語句。通過這類專用語言，用戶可以對程序進行界面配置，實現簡單的功能擴展，給用戶提供了一定的靈活性。而只需用戶懂一點程序設計知識即可。這類語言的缺點是沒有通用性，功能有限，由于解釋執行，速度受到很大限制，并且應用軟件開發商實現專用編程語言及調試環境有較大難度。對于應用程序，需實現三個要求，就可擁有腳本語言編程接口：

A)應用程序的對象模型

B)適合應用程序對象模型的對象

C)腳本語言編程引擎

前面兩個方面，需要應用程序用組件對象模型的方式構造。采用組件方式，是軟件開發的發展方向，提供對象模型是一件很自然的事情。第三個方面，有通用腳本語言編程引擎供選擇，微軟的ActiveX腳本編程引擎可以免費使用，VBA腳本引擎需要購買。ActiveX腳本引擎實現了基本功能，沒有調試環境。VBA是一種通用編程語言，其核心就是應用廣泛的VB，擁有大量函數支持，窗口編輯能力，強大的調試環境。很明顯，微軟希望VBA成為應用軟件二次開發的通用語言。例如CAPP和國外PDM的接口就屬于這種開放方式。

3)鏈接庫方式。基于結構化的軟件，可以提供軟件內部使用的動態連接庫，供用戶使用。動態連接庫是速度最快的接口，應該說是一種很好的選擇，CAPP目前的二次開發接口就屬于動態連接庫方式。

但是動態連接庫在接口升級時會遇到麻煩，用戶程序難以和正在運行的應用程序進行數據交換。用戶也難以使自己的模塊(用戶實現的動態連接庫)嵌入應用程序。因為動態連接庫的通常首先實現的(至少要定義輸出函數接口)，而后才能使用動態庫。但應用軟件開發時，用戶實現的動態庫根本不存在，AutoCAD的ObjectARX用一種特殊的機制，才使AutoCAD可以使用用戶開發的動態庫。目前國內很多AutoCAD二次開發軟件，就是使用ObjectARX開發的，可以完全的嵌入AutoCAD。

4)COM組件方式。COM對象接口：基于組件對象模型的軟件，可以提供軟件的COM對象接口。組件應用程序由多個組件打包而成，組件之間的聯系是一種松散耦合，使其中某個組件的改變不影響其他組件，應用程序修改，改進變得方便。這就如同一臺復雜的機械設備的各種零部件用螺栓連接起來，零部件可以輕易更換。而傳統應用程序就像所有零部件都通過焊接連接的，如果要改進，只能重新做一個新的。組件程序由于由許多具有位置透明性(無需知道組件的位置)的組件構成，可以很容易實現分布式應用。組件架構強調實現對象模型，開發接口是基于對象的，符合用戶的思維方式，比動態庫提供的API，更易于理解，使用。組件是完全與語言無關的,任何過程性語言夠可以用來開發組件，根據不同的需求，可以輕易的用不同語言開發應用程序的不同部分，用戶可以選擇任何過程性語言做二次開發。通過COM的底層機制，可以訪問運行中的應用程序對象，實現與運行中程序交換數據。用戶組件也可以易于嵌入應用程序中。COM的主要問題是，運行速度比動態庫慢，特別是自動化接口；對系統穩定性要求高于動態庫，要求系統的COM平臺能正常工作。

最常用也是最安全，成本最低的接口方式是中間文件接口。

雙方的數據交流通過中間文件進行。這種方式由于比較靈活，接口雙方都比較明確工作。而且重要是的，接口雙方的軟件升級，對于接口本身(對方軟件本身)可以說沒有影響。是目前采用較多的接口方式。

如果是中間文件的還需要確定是全量式接口還是增量式接口。

接口本身是為了雙方數據可以保持交流和數據一致性進行的。一方提供數據，另一方根據對方的數據來更新自己的系統的數據。所以對于哪些信息是新加，哪些是刪，哪些是更新要進行判斷。從數據提供方而言可以提供以下幾種：

全量：按軟件數據內的數據提供全部的數據，不進行區分哪些是增，哪些是刪。這種方式需要用戶對比自己內部的數據進行區分哪些是增，哪些是刪。

增量：由數據提供方進行對比后，區分哪些數據是要更改的，哪些是要刪除的。對方軟件根據數據提供方提供的文件直接更新數據庫。這種方式的重點是要掌握同什么數據對比，得出增減記錄。另外，對不不同的記錄(增/減記錄)是提供不同的文件，還是在同一文件內對于不同的記錄做上標記也是要定義的。此時可能就要在接口字段上定義更改標識，更改單號，版本號等信息。

2.13 接口調研背景知識(下)

2.13.1 接口內容

接口方式一旦確定，就需要確定接口的內容。

接口內容首先要確定接口入口，從哪里開始匯總接口數據，接口數據每次包含多少對象，這些對象是如何聯系在一起的。例如接口數據每次都從一個完整的產品上開始匯總，或者從一個完整的工程任務上開始匯總，或者從任意零部件上都可以發起匯總。

第二接口內容要確定接口時機，要明確哪些字段由數據提供方(其它系統)寫，那些讀，在什么時候進行。也就是約定當數據達到怎樣的規定后才可以啟動接口輸出，此時也可以約定接口輸出負責人員。例如當產品結構發布，相關工藝數據也發布后才能啟動接口，如果有明確接口時機要求，接口程序應適當做校驗性判斷，防止提供不正確的數據給下游系統。

第三接口內容要確定接口格式。

接口格式包括明確數據交換提交的方式：是文件級還是數據庫級，然后明確交換文件的名字，存盤路徑。

明確文件的格式，包括文件或數據表包含的字段名，字段次序，字段類型，字段長度，分隔符(如是文本文件)，是否必填，默認值，下游系統對應含義，實際數據樣例，接口對應數據來源，該字段在實際操作中填寫規則。

第三接口內容要確定接口樣例。

接口技術協議附件必須包括用戶方提供的樣例數據，樣例數據必須具備典型特性，能夠覆蓋企業各種可能的實際數據情況，保證驗證樣例數據對接口測試的完整性；

如果一個樣例不能覆蓋可以提供足夠樣例數據，用戶方可提供多個樣例，直到可覆蓋各種可能情況為止。

用戶方要保證樣例數據的規范性。此時可能還需要針對接口樣例提供數據規范性錄入操作說明。

依據所提供樣例最終得到的接口中間文件將以完整實例作為驗證標準依據。如果有多個樣例，則需提供多個完整的接口中間文件實例。準備接口樣例將大大加快驗證時間和接口程序調整反復時間，也有利于企業，供應商快速就接口協議達成一致性理解，是看起來慢，實際上最快的有效接口方式。

2.13.2 接口數據一致性握手方式

接口數據的一致性通握手方式來保障。一致性分為靜態一致性，動態一致性，雙向一致性。

靜態一致性：如物料編碼信息，原始工藝設計信息。

動態一致性：如設計更改信息，在一個系統內的數據更新后，要求另一個系統內的數據也要進行相應的處理。握手方式即明確如何讓對方系統得到要進行更改的信息(也可能是依靠人員來進行手工操作)，這樣對方系統對接口文件進行處理。

雙向一致性：復雜的系統甚至要求，對方系統處理的數據結果要進行反饋。從而更新本身系統的數據。這里面也要對反饋進行定義。

2.14 調研后續工作落實階段

2.14.1 如何寫業務調研報告

調研結束后第一個必須盡快整理出業務調研報告，業務調研報告主體內容可以在業務分析會上得到用戶確認。

寫業務調研報告應該結合軟件供應商特點形成一個比較統一的匯報目錄模板，有了模板整理起來就快，不同軟件關心業務內容不同，模板也應該不一樣。

一般而言業務調研報告目錄可以分為三個大的部分，第一部分是業務基本情況介紹，第二部分是企業業務流程圖和數據流圖，第三部分是項目關鍵價值點。

凡是不設計業務流和數據流，但必須要描述的內容，例如企業的一些基礎數據情況，我們把其作為企業的基本情況介紹，例如企業概況，企業設計數據統計情況，企業工藝數據統計情況，企業標準化編碼規定等等，做基本情況介紹時要把握兩個原則：

第一是結構化，不要散亂，將相關性強的一組基本情況設計成表格填寫，這樣既方便填寫，又不容易遺漏。

第二是按照調研先后順序組織，和業務流順序盡量一致。這樣不但層次清晰，而且可以直接將每天調研日志內容復制修改就可以得到最終結果，大大提高工作效率。

業務流程圖和數據流圖有大量標準工具和方法指導，建議這里大家去找相關專門知識學習，本文不在這里展開。

第三部分項目關鍵價值點是非常重要的，項目價值點組織也必須符合結構化層次，不要將很大的價值和很小的價值并列排放，應該將最大的價值，可以相互獨立做為一層，然后將小價值分別歸類到不同大價值下，形成一個價值支撐體系，這個支撐體系也是解決方案的實現思路。

2.14.2 業務調研報告完成后續工作

業務調研報告完成后必須趕緊去找后續工作同伴，按照約定的工作計劃把調研報告交給他們，如果有時間，還可以安排一個內部業務分析會議，做一個全面的介紹。

幫助團隊成員可以準確理解調研報告，啟動后續工作才是一個調研的工作結束。

如果你能按照以上方法進行調研，相信你的調研質量一定很棒，這樣的話，不管后續工作是什么，我相信你都會得心應手的去完成，或者幫助你的團隊成員去完成。

這也就是調研最大樂趣所在。

3 如何寫解決方案？

3.1 解決方案難寫在哪里？

3 如何寫解決方案？

3.1 解決方案難寫在哪里？

很多人對寫方案非常沒有信心，一涉及到方案的事情，就束手無策，到處求人。

作為一個公認的方案打手，意思是寫方案就象打字員一樣，我覺得我在這方面確實是有絕活。

我基本上都是在方案提交前一兩天接到寫方案的任務，而我自己的事情一般又比別人多一點，也不能不做，只好心里大罵一句，罵完后就打電話搞清楚別人的要求，邊問就邊構思整個方案的推導思路和結構提綱。

因為你不敢讓你的同事知道你只能用很少的一點時間寫方案(基本上我真正動筆寫方案的時間都在2~4個小時以內)，讓他們擔心方案的質量和進度保證，進而對自己的后續工作質量沒有信心。所以我其實也特別緊張，注意力也特別集中，大腦也高速反應，基本上幾分鐘電話或面談完思路基本就有了，然后該干嘛干嘛，找一些零散的小時間把思路不斷推導一下，然后到了一個比較安靜和完整的時間段前才開始寫，這個時候基本上要寫的話都想清楚了，只需要不斷敲字，敲字的時候也是注意力也特別集中，大腦也高速反應，越寫思路越開，很快也就完工了。

寫方案不難，知道怎么寫才難。關于寫方案我只總結一點，結構化地去組織你的思想。

有結構就有思路，有思路就有方案。

另外真正寫方案的人，對自己寫過的方案是永遠不會滿意的，只有這樣，每次都會進步一點點，解決方案水平質量就會隨公司能力不斷增長。

當然我曾經問過很多人，你到底為什么寫不出好的方案呢？

基本上原因可以歸為四類：

3.1.1 第一種是沒有體系

一旦用戶要求提供關于PDM的方案，很多人大腦是一片空白，完全不知道從哪里下手。很多人說起自己的產品來，好象知道不少賣點，不過真要寫出來，又覺得無從下筆。

這種情況一般是寫方案者不熟悉自己產品體系造成的，知道一兩個甚至更多的產品賣點不難，但難就難在成體系，知識就是成體系的點構成的，而不是一句一句離散的說法構成的。

因為我們這個行業從業人員說句不客氣的話，大部分對所銷售實施的管理系統并沒有很深入的研究，都是半路出家，從頭開始，在學習過程中熟悉，在熟悉過程中領悟。所以一下子去駕馭一個整體方案是很痛苦的。只有當一個人對一個產品思路有體系以后，才能夠寫出完整的方案，否則就是一個單元也要費盡腦汁。

所以一個人要想寫好一個方案，首先要把自己產品的來龍去脈，功能模塊，適應領域，典型客戶實施情況有一個全面的了解，這樣才能建立一個完整的知識體系，然后逐步補充競爭對手知識和一些技術性知識，不斷深化自己的知識體系。

3.1.2 第二種是沒有思路

有很多用戶看多了模板化的方案以后，想看一些針對他們自己的業務的個性化內容，這個時候有的人按照標準方案模板修改還勉強能對付，但對于個性化內容針對性方案就速手無策了。

這種情況從根本上講還是寫方案者不熟悉企業業務造成的，寫方案，特別是針對性方案不僅僅要求了解企業的需求，而且要知道這些需求是在何種業務需求下產生的，用戶提出這樣的要求到底想解決什么問題，把這個問題找出來，一般針對性解決思路就有了，有了思路，自然可以很好的寫方案。

所以一個人要寫好方案，還需要了解下游客戶的業務，了解業務最有效的方法就是親自做幾次詳盡的業務調研，有了業務調研做基礎，在調研過程中把握用戶關注重難點問題，自然可以比較好的確定方案的個性化內容思路。

解決方案就是把客戶的利益和產品特性之間建立一個邏輯性的橋梁。

3.1.3 第三種是沒有素材

一般不經常寫方案的人，在寫一個方案的時候，即使有想法，有思路，但往往也會很累，就是因為缺少足夠的素材。很多項目現在都是投標，不同用戶可能有不同投標的要求，這樣很難用一個方案去適應所有的用戶，因此在每個方案中都有一些需要準備的內容。

這些內容基本上是通用的，但如果沒有足夠積累每次編制方案就需要花費大量時間去準備，造成方案完成周期過長。

所以寫好方案必須具備這三個條件，第一方案編制者對企業業務要很熟悉，或者有相關業務調研經驗，第二方案編制者對產品非常熟悉，至少對自己產品功能模塊作用很清楚，第三方案編制者手上有大量可公用的素材庫。

3.1.4 第四種是沒有層次

很多人剛和用戶接觸沒有多久，為了表現自己對客戶的重視，馬上表示要提供方案，當然有的客戶剛剛開始選型，也不知道到底要什么搞，也要供應商馬上提供一個方案。

結果拍胸脯容易，寫方案難，自己寫不出來只好求公司，公司沒有安排專人了解情況，只好按模板制作一個，用戶一看幾個供應商內容都差不多，覺得不好，又總結出一些個性化要求，于是大家有開始折騰第二輪方案。

其實方案編制在不同階段有不同策略，不要輕易提供方案。剛開始接觸是可以提供項目合作建議書，類似可行性報告，項目需要考察軟件技術，可以提供標準的產品技術白皮書，到了經過售前調研，有所準備，在演示前后階段和其它競爭對手刺刀見紅的時候，才在知己知彼的基礎上提供解決方案或者投標書。

過早提供方案只能匆匆了事，時間緊急，質量自然不高，自然也就覺得方案難寫。想急就又能解決問題的事情，本來就是一般人做不來的。

方案想要寫得好，一定要用心，用心就一定要耗時間，指望用幾個小時寫出一個高質量的方案是不可能的。如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，明白了這一點，大家都可以經過練習寫出好的方案。

3.2 壞的解決方案有哪些特征？(上)

3.2.1 第一個容易犯的錯誤：只有論點，沒有論證

不好的解決方案粗看起來非常厚重，其實都是功能羅列，象產品手冊摘要版，不象方案書。

不好的方案是一大堆內容，淹沒在一堆紙里面，也不知道想說什么，給你一個厚度，證明我們的工作質量很高。我們國內許多的企業客戶特別是大型企業都很在乎這點，認為可以從方案厚薄中看出對項目重視程度。

如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，有個金字塔式的寫做原理，也就是說文章一定是有結構的。

所以真正好的方案，不一定厚，但能看出你用心，你認真。

現在的解決方案一個不好的傾向是“長、厚、全”，看起來面面俱到，其實對決策者沒有幫助。

所有的方案無差異性，每家供應商都說自己能解決這些問題，而且都有成功案例。

結果所有的方案都無法給決策者簡明的判斷依據，不得不費更大勁去做產品演示和用戶考察。

其實很少有企業高管不知道自己的毛病，在企業你隨便去找一個人，對問題都能講一通，在企業你費很大勁可能都找不到一個人能告訴你這些問題可以怎樣去解決。

通觀這個方案并沒有研究為什么企業會產生這么多問題？問題是這些問題是什么產生的？為什么出這么多問題？而是不斷說“我能！我能！選我，選我！”。

如果不能找到解決這些問題的原因，簡單地去解決這些現象，就象治病不能治根一樣。這樣一個模板化，自我膨脹化的方案想打動用戶的心是非常困難的。

不好的解決方案最大的問題就象寫一篇議論文，能夠發現問題(這個也是模板化的，可惜中國企業大部分沒有意識到自己很多問題并不少見，總以為自己是特殊的一類企業)，提出答案(搞信息化)，但沒有論證(為什么搞信息化和企業管理進步有聯系呢？)。

沒有論證的東西不管內容陳列得多么繁復，名詞多么嚇人，但是無法打動用戶，特別是那種理性的用戶。

看到方案時候，其實很多用戶下不決心，他會感覺每家都差不多。

如果從沒看過方案的人，突然看到這幾個方案，你為什么會感覺某個方案寫得好呢，關鍵是有的方案圖畫的好，通過圖，通過表，會感覺這個公司還不錯，很規范。但對內容認可程度并不高，實際上沒看懂。

3.2.2 第二個容易犯的錯誤：業務解決方案成為功能列表

解決方案省事的一種方法就是將產品功能描述作為技術方案內容進行羅列，或者參照軟件用戶手冊羅列，這種解決方案不是按照用戶業務去準備的內容，而是按照軟件商自己的喜好去編制的解決方案是很難得到用戶認可的。

大凡按照功能列表組織的解決方案用戶會有一個體會，龐大而庸長，但要看到自己想看到的部分非常困難。

而且這種方案還有一個特點，一個問題反反復復的提，在業務背景中指出某個問題，講一通，在價值分析中又重點解釋一通，到了功能介紹時又將某個問題來龍去脈概要說明一下，給用戶感覺是一堆資料的堆積，哪里體現出了方案的針對性呢？

按功能列表準備方案的做法在很長一段時間內不會消失，這和我們普遍是4P銷售人員，還缺少SPIN(顧問式)銷售人員有關，在資源不足的情況下，要保證效率就只能提供功能列表方案了。

3.3 壞的解決方案有哪些特征？(中)

3.3.1 第三個容易犯的錯誤：結構不清晰

不好的解決方案最共性的毛病是結構不太好，沒有清晰的思路。

沒有思路的方案質量很低，用戶在審閱過程中也不會體會到和一個專人人士通過文字交流的樂趣，他不得不從供應商混亂的思路中發掘亮點，看看到底是誰能解決企業的問題，真是一件痛苦的工作。

一種常見的方案結構毛病就是重復的內容在不同的章節反復出現例如在第一章介紹了對某個問題的分析，提出企業的需求，這第二章介紹方案價值的時候又用不同語句組織類似內容，到第三章解決方案描述中還是要把問題描述一遍，給人感覺思路不連貫，結構臃腫。

這里有一個方案提綱的提綱，我們以這個提綱為例子說明結構不清晰的方案。

1 公司簡介及資質文件

1.1公司簡介
　　1.2 自有產品及代理產品情況
　　1.3 重點工程介紹
　　1.4 公司資質復印件
　　2 分項標價表
　　3 ***PDM系統技術解決方案
　　3.1 ***PDM系統技術解決方案
　　3.2 ***PDM系統具體功能模塊
　　3.3 報表及明細匯總
　　3.4 應用工具及封裝接口
　　3.5 用戶及權限管理
　　3.6 拼圖打印
　　3.7 編碼管理
　　4 實施計劃
　　4.1 實施步驟
　　4.2 實施計劃
　　5 培訓計劃
　　5.1 系統培訓對象
　　5.2 主要培訓內容
　　5.3 培訓方式
　　6 實施人員資質
　　6.1實施人員組成及工作職責
　　6.2實施人員資質說明
　　7 質量保證及售后服務
　　7.1 質量保證
　　7.1.1 工程技術力量的研發水平
　　7.1.2 工程技術力量的實踐經驗
　　7.1.3 管理水平
　　7.2 售后服務承諾
　　7.2.1 技術支持與服務的內容和承諾
　　7.2.2 技術支持與服務的保障
　　8 開目典型用戶
　　9 有關技術秘密的聲明
　　10 附件

這個方案第一部分、第二部分是用戶投標要求，必須如此，但第三部分技術解決方案應該是重點，這個部分結構就很奇怪。

一般好的方案結構標題就是論點，內容就是用事實進行論證，子目錄是上級總目錄論點的分論點，逐層論證下來，方案顯得邏輯性結構性很強，看看目錄就能看出方案的邏輯推導體系。這就是所謂金字塔文檔體系。

這個方案顯然不是這樣的，看起來一大堆內容，有經驗的人一看就知道是內容的羅列。

例如第三部分總標題是技術解決方案，結果第一個子標題還是技術解決方案，撞車！一定層次感都沒有。而且第一子章節技術解決方案后馬上是功能模塊，技術解決方案理論上包括功能模塊，不是一個層面的東西，技術解決方案應該和實施策略，服務策略平級的內容，所以一定要談談自己技術解決方案，不如用技術解決方案思路或者特色來表達，和功能模塊也就是一個層次分論點，統一支持技術解決方案這個大題目。

具體功能模塊后面跟著一大堆章節就更奇怪，里面每個都是具體的功能模塊，為什么成為和具體功能模塊平級的內容？應該設置為具體功能模塊子章節為妥。

很多人可能覺得用戶對這個點很關心，要重點突出，所以一定要單獨立一個章節，其實不必然，結構清晰的方案用戶看起來才不費心，反而想這個方案，將具體功能模塊，報表及明細匯總、應用工具及封裝接口、用戶及權限管理、拼圖打印、編碼管理列為同一層面內容，反而叫人看不出排列的思路，在厚厚一大本方案中尋找對應關心內容并不容易。

其實不如把技術解決方案分為兩大部分，一部分介紹整個方案的實現思路，對于工作比較忙的人可以看這塊中對企業業務和邏輯的分析是否到位，相當于整個方案的精華版；一部分介紹整個方案的技術支撐模塊，對于項目具體負責人就可以深入研究技術支撐和業務思路之間是否存在合理的組織關系。

在第二部分技術支撐模塊中根據業務邏輯或業務順序設計功能模塊的介紹。

例如一般企業是首先考慮靜態技術資料的受控管理，在受控的基礎上要求盡可能集成設計軟件中的信息，然后要對設計過程建立嚴密的動態控制體系，此外還希望得到一些設計過程的專業支持，例如變型設計，二級工藝路線管理等等，最后要求提供一些編碼，企業資源庫等等輔助工具。這就是我們實現企業需求的一個大的業務思路，在這個業務思路下我們可以將技術支撐模塊分為相應的五個部分。

到這里，整個方案大的框架就有了，我們需要設計一下分標題，使用戶一看就可以進入自己關心的內容，而且每個部分都是對所屬總標題的呼應支持，在業務環節上也是“相互獨立，彼此窮盡”的環節。

在標題的設計上不要過于簡單，例如技術資料管理，應該說有效的技術資料管理，因為有效才成為技術支撐模塊，進而呼應前面業務實現思路中的描述。

3.1 業務實現思路
　　3.2 技術支撐模塊
　　3.2.1有效的技術資料管理
　　3.2.2深入的數據集成
　　3.2.3嚴密的過程控制
　　3.2.4靈活的設計支持
　　3.2.5輔助設計工具

在上面這個思路基礎上，我們就開始結合企業業務和產品功能進行考慮分標題下級的結構，我們用第一有效的技術資料管理為例子。

有效的技術資料管理到底要解決哪些業務問題才算完整呢？我們現在就開始將企業管理技術資料的業務進行羅列，在業務思路中逐步說明。

企業管理技術資料是以產品為線索區分的，所以第一要說清楚產品資料如何管理；

產品下所有零部件是以特征為線索區分的，所以第二要說清楚零部件資料如何管理；

有些零部件還具有共圖共工藝的特征，所以第三要說清楚系列零部件資料如何管理；

進一步有的企業還有系列產品，所以第四要說清楚系列產品資料如何管理；

系列產品可能存在大量配置關系，所以第五要說清楚各種規則下產品配置資料如何管理；

有的企業產品配置型號在生產中還存在批次關系，所以第六要說清楚不同產品批次資料如何管理；

有的企業已經存在了大量歷史設計資料，所以第七要說清楚歷史產品資料如何入庫管理；

在資料入庫時有個問題每個人管理資料習慣不太一樣，全部統一成一種管理方式是必要的，但可能失去一些靈活性，所以第八要說明為個人自組織資料提供哪些支持；

最后要說清楚產品資料為什么入庫管理后是安全的；

我們現在總結一下，這些技術資料管理手段如果都提供了，應該是完整而且層次清晰的，這樣的話，第一個子標題下的分標題又有了。

3.2.1有效的技術資料管理
　　3.2.1.1 產品資料管理
　　3.2.1.2 零部件資料管理
　　3.2.1.3 系列零部件管理
　　3.2.1.4 系列產品管理
　　3.2.1.5 產品配置管理
　　3.2.1.6 產品批次管理
　　3.2.1.7 資料入庫管理
　　3.2.1.8 個人資料管理
　　3.2.1.9 資料安全管理

再看看這個標題和業務思路，這里面體現的一個結構化方式恰恰是“一句話一個意思，一層意思推動一層意思”，到最后就象剝筍一樣，層層剝開，問題解決思路也就步步清晰了，企業看起來也就很明白。

那么我們還可以繼續細分用戶提出的各種業務需求，把企業各種業務要求對號入座，例如下面有一組需求：

有的企業要求用戶訪問控制；有的企業要求提供角色權限管理；有的企業希望按產品目錄授權；有的企業要求全部存放在服務器的數據庫中；有的企業希望支持多數據庫獨立訪問； 有的企業要求提供備份工具等等。

我們現在看看這些業務是否都應該是關心資料安全的？所以應該放在資料安全管理目錄下，而且這些需求也可以分為不同層次，一些是和權限有關的，一些是和存儲和備份有關的，這樣很快又可以把子標題和分子標題設計出來了。

同樣我們可以推導出如下另外幾個部分的提綱：

3.2.2深入的數據集成
　　3.2.2.1 主流CAD的集成
　　3.2.2.2 CAPP的集成
　　3.2.2.3 和其它常用工具軟件的集成
　　3.2.2.4 數據挖掘統計工具
　　3.2.2.5 和其它PDM/ERP系統的集成
　　3.2.3嚴密的過程控制
　　3.2.3.1審核管理
　　3.2.3.2發布管理
　　3.2.3.3更改管理
　　3.2.3.4項目管理
　　3.2.4靈活的設計支持
　　3.2.4.1 變型設計業務支持
　　3.2.4.2 二級工藝管理業務支持
　　… …
　　3.2.5輔助設計工具
　　3.2.5.1 編碼管理
　　3.2.5.2企業資源管理器
　　… …

這個結構化體系一旦出來后，整個方案的思路是否清晰明了，下筆容易了呢？

結構化體系最大的好處是不亂，今后用戶提出任何業務需求，或者產品功能如何擴充，都很容易對號入座，或者擴充子標題。這也是體現了一種分類管理的思想。

當然這個分類思路根據不同業務特征允許存在多種可能，而且分類層次應不超過5級標題，否則文章的可讀性不佳。

如果一定要超過5層，就可以采取其它排版方式體現。

3.4 壞的解決方案有哪些特征？(下)

3.4.1 第四個容易犯的錯誤：口語書面語混雜，遣詞造句不嚴謹。

不好的解決方案還有一個毛病就是口語書面語混雜，遣詞造句不嚴謹。

有的人寫作時順著思路走，口語化成分很多，例如本人的行文基本是口語化的，也體現了這個毛病。當然大師級人物的確可以將文章寫得明白如話，但是對我們這些人而言方案是代表公司正式對外的文檔，一定不要出現口語和書面語混雜的情況。

例如太多的兒，的，我們，你們等等都是口語化語言，不應該大量出現在正式方案中。

有的人寫方案比較圖表現，喜歡指出用戶的不足，這個時候喜歡用很激烈的語言。例如缺少管理，業務失控，后果很嚴重等等語句，這樣的遣詞造句是不嚴謹的，方案用語不要追求“語不驚人誓不休”。而是理性分析，認真推導，句句講邏輯。

實在要用一些事實說明企業的問題，不要用刺激性強的語言，例如說企業業務存在問題，可以說業務有可改進的地方，例如說企業管理失控，可以說管理上存在很難受控的環節。

這樣的表達企業反而容易接受，不出問題。

3.4.2 第五個容易犯的錯誤：沒有認真檢查，存在大量硬傷。

不好的解決方案制造過程往往是找一個同類方案，然后主要工作是“CTRL+C”+“CTRL+V”。

很多人就圖快，省事，沒有很好的核對，結果往往容易出現如下幾種錯誤：

第一有些企業在一個方案中用了不同的稱呼(這個也要養成一個習慣在一篇方案中一個企業用一個簡稱和一個全稱)，替換不完整，結果在方案中出現了其它企業的名稱，非常不禮貌；

第二有時候替換過頭，把一些案例中類似的話也替換成為給用戶名稱，鬧出笑話。

第三只注意了文字替換，不注意圖形中的替換，結果文字是一個用戶的，圖片是另一個用戶的，感覺不尊重。

第四是只注意了文字替換，忽視了頁眉頁腳的替換，特別是注意了首頁或目錄的頁眉頁腳，沒有注意正文的頁眉頁腳。

第五是案例不對，明明是汽車行業的用戶，案例全部都是其它行業的，感覺在這個行業沒有經驗。

第六是聯絡方式不對，很多時候將別的營銷區域方案拿過來用，服務信息都沒有更正過來。

第七是存在大量技術硬傷，有時候為了突出軟件技術實力，將大量專家都不一定看得懂的詞匯大量堆砌，其實連軟件公司自己都搞不清楚采用了哪些。

企圖通過讓用戶對概念和名詞發暈進而對軟件產生信賴的方式已經過時，解決方案應該實事求是說明業務問題，不要在名詞上忽悠。.

3.4.3 第六個容易犯的錯誤：過于突出自我

很多人寫方案大量出現“**軟件公司”內容，甚至每個產品都恨不得加上自家標識。在很多地方行文造句都是“我能，我行，我有…”等語氣。

這種方案很容易給用戶過度營銷的感覺。我們給用戶寫的方案在售前建議盡量用用戶做前綴，例如說某某企業PDM項目，不要總在說某某供應商PDM的話，給用戶一種相對的針對性，感覺這個方案的確是為用戶準備的。

在售后實施方案中軟件公司的名字只需要出現一次，后面就不需要反復出現，因為大家都知道是你的產品，何必反復體現，我們更應該把用戶的注意力集中到產品本身就應該具備的功能和支撐業務上，而不要形成某某可以，某某不可以的印象。

3.4.4 第七個容易犯的錯誤：沒有評審。

方案提交給客戶之前，一定要經過評審。

沒有開發點的方案，一般經過自評和互評即可，自評時，要重新審視整個方案的結構、問題描述、遣詞造句等方面，特別是用替換修改的企業名稱和營銷平臺等方面的內容，盡量減少低級錯誤。

自己評審過的方案一定要給一個其它的人評審。

互評時，要重新審視整個方案的結構、遣詞造句等方面的內容。

對于有開發點的方案，要經過公司的評審。提交給公司評審的方案，一定是已經過自評和互評的方案，而且要注明主要看哪些部分，以及編寫這些部分的背景知識。

3.4.5 第八個容易犯的錯誤：沒有體現公司產品最新進展。

一般人寫解決方案首先不是想著如何說清楚用戶的業務，如何在公司產品中體現出對業務的支持，而是想趕緊找一個模板，把這一關走過去再說，其實很多時候就是對每個階段工作沒有質量意識最后導致工作處處被動。

所以寫解決方案一定要根據公司最新產品功能認真組合功能實現企業業務，甚至可以考慮利用未來半年內會發布的功能認真組合，因為解決方案離正式實施往往需要半年甚至更長的周期。

很多時候解決方案一抄再抄，都是一兩年前的模板，自然缺少競爭力和說服力。

這個問題的核心是公司有沒有專人專崗負責對標準解決方案的維護和更新發布機制，其實比較好的一種做法結合典型項目技術公關推動解決方案水平不斷完善和提高。

3.5 寫好方案心得(上)

3.5.1 動筆前先打一個電話

一般情況下方案撰寫人只是按照別人要求提供方案，并非直接利用方案的人，所以在寫方案之前，問問需要方案的同事，甚至是用戶，聽聽他們對方案的想法和建議，對自己寫方案會有很大幫助。

很多時候方案準備完成方案接受者并不滿意方案的組織，需要返工修改，所以動筆前先打幾個電話，問問別人要什么，不但可以提高方案準備命中率，甚至可以獲得大量現成的思路建議，對自己寫方案大有好處。

3.5.2 一定要努力按業務邏輯去寫。

一般寫方案最簡單的方式就是按照軟件自己的思路和功能模塊組織，因為有大量現成的材料可用。但這樣方案對用戶并非是一種最佳選擇，因為客戶要轉換到供應商的思維才能看懂方案字句之間的含義。

如果從以客戶為中心角度出發，方案應盡量讓用戶容易看懂，好理解，自然也就取得了幾個印象分。

我們方案就是要先仔細探討企業業務，不是將調研結論一羅列，而是從業務分析得出業務需求，最后描述技術實現手段。從這個意義上講，解決方案要按照簡明的操作手冊來準備。

3.5.3 按標準套路寫方案

不同類型的方案都有自己的套路，例如可行性報告，解決方案，建議書等等都有標準的套路，我們應盡量按照標準套路準備方案，不要自成體系，在套路下發揮，套路就體現了一種結構化體系化的思維模式。

關于常用套路我們另有一章說明。

3.5.4 先構思提綱，經過討論，最后動筆

很多時候方案準備時間并不充分，很多人接到任務，壓力之下立即開始動手，這往往是不好的工作習慣，有時候有模板，的確可以快速出活，但時間長了就養成一種惰性，替換方式抄方案還勉強，真要遇到有個個性化問題，因為在平時寫方案過程中思維始終不經過結構化思考的練習，真到方案模板沒有覆蓋的情況，就沒有辦法應付。

好的方案特點是：標題就是論點。結論做為標題馬上拿出來。

好的方案是觀點鮮明，立場明確，有理有據，有血有肉。

所以有方案要寫，一定不要急著寫，而是想自己的提綱，這個完整提綱目錄之間的邏輯聯系和業務銜接自己在心里面推導得比較有力和充分了，才開始動筆快速拿出提綱，有了提綱寫起來思路就不會斷電，寫起來才快。

好的方案一定是做了論點。

論點是假設的，例如說搞PDM有價值。

你說價值有三個方面，能降低成本，提高質量，能縮短交貨期。這都是你的假設。

你怎么知道成立？就要找些事實去證明它。

我們現在都喜歡找什么事實呢？你用了這個功能，所以你的論點就成立，因為你有這個功能，所以你的效率提高了。

這都是扯蛋！為什么用了PDM企業就能做到這幾點。根本沒邏輯推導。

不是還有大把企業用了ERP，用了PDM還不是該咋的咋的，錢都打水漂了。

假如你有好多論點，論點怎么組織呢？你比如我要搞信息化，信息化有大價值，小價值對不對？你要把它都列出來，列出后你還要想一想這個價值和那個價值是不是包容的關系？

好處一定是每個好處都是獨立，它是有層次，每層上的好處是平級的，大好處包含多個小好處，這些好處倒推出來就響應支持你的論點，這種方案看了以后別人就會理解并支持你。然后每個好處一定是在前一個好處的基礎上往前推動一步，最好得出一個強有力的論證過程。

所以好的方案必須是金字塔型的，論據論證最后構成堅實的基礎。

如果有條件的話，這個思路還應該和大家討論，特別是一些重要方案，一定要先反復討論提綱，大家各種意見和思路在提綱中統一了，再動手寫。這樣就不至于遇到寫了一半被人否定，推倒重來的痛苦了。

3.5.5 找一個安靜的地方和完整的時間段開始

寫方案最怕中間不停被人打斷，這樣思路連貫性會很差。所以我無論接到多么緊急的方案編制任務，也不會急著去寫，而是把手頭該處理的小事情處理干凈，然后保證開始后的時間相對安靜和完整，這樣才能保證方案的質量。

而且寫方案一定要保證在一個時間段內初步拿出完整的推導思路和結構提綱才能結束去干別的事情，這樣以后就是逐步補充和豐富內容，不至于還在為結構苦惱，不清楚從哪里下筆，

3.6 寫好方案心得(下)

3.6.1 認真準備閱讀提示和摘要

一個方案往往厚厚一本，更多是充點門面，領導是不會真看的。萬一要看，也就是看看包裝是否精美，和頭幾頁文字。

所以方案可以單獨附一份摘要，這是關于整個方案業務分析和解決思路的精華部分，當然也可以帶一點實施方法和典型用戶的介紹。

這樣就可以讓自己方案思路在短短幾頁紙中清晰描述和表達出來，這種提煉過的語言和文字往往更能打動人心。

一般寫一份厚方案只需要一天，寫一份薄方案需要一周，要求在三頁紙內說明問題需要一個月！能把書讀薄是能力的體現。

對于方案也一定要提供一份閱讀指引，告訴不同的人其關心的內容可以在哪些章節直接獲得，方便其閱讀。實際上我們觀察很多論文和書籍序言都有一段來說明這個文字的結構，其實這也是一個標準做法。

3.6.2 注意排版

方案一定要注意排版，印刷要干凈，封面要隆重，裝訂要精美，方案就是一個公司的臉面，雖然不是說一份方案可以決定項目，但一份看上去都不好的方案一定很讓人懷疑公司的能力。

我們很多人見過外企的文字，一般都非常精美，排版很漂亮，大家一看就覺得是專業人士所為。

所以方案的文字和圖表內容最好請專門的美工設計一套標準的排版體系，對方案整體可讀效果會起到極大促進作用。

現在很多方案都是密密碼碼，內容是多，可以有什么用？

不如取巧，少寫一些文字，多在排版上動腦筋，實在想不出好的排版是什么回事的，去買基本暢銷書，你會發現可讀性好的書往往有一個技巧叫“留白”。

方案文字段落邊框之間保持適當距離，特別是邊框合理留白會讓一份方案可讀性大大提高。

象本文這樣的文字如果加上留白設計可讀性就會很不錯。

3.6.3 注意積累素材

寫方案無論如何按照企業業務組織，基本上90%內容是相同的，不過是根據不同思路進行組織而已，畢竟軟件功能不會在短期內發生巨大改變，方案涉及功能也沒有理由發生大的改變，所以方案中很多素材是可以通用的。

包括一些公司通用素材，更是要隨時積累補充完善和歸類存檔，這樣在寫方案時才不會因為尋求這些基本素材浪費大量時間。

基本素材收集還要注意隨時和公司公開宣傳口徑保持一致，防止引用過期素材。當然標準素材最好由公司統一維護。

獲取其它素材的途徑比較多，主要有：

現場初步需求調研與交流

與熟悉類似項目的銷售經理、技術支持工程師、實施工程師溝通、了解

營銷平臺交流

企業網站

相關行業資料介紹

書刊

……

一般可以從企業網站獲取企業介紹。從網站獲取的企業介紹需經“角色轉換”和“內容篩選”，角色轉換是指站在公司的立場描述該企業的情況介紹，要把第一人稱改為第三人稱。內容篩選是指主要介紹企業信息化的基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等內容。

3.7 方案分類及用途

3.7.1 方案的種類

目前，公司為客戶撰寫的方案分為：建議書、解決方案、投標書。技術白皮書應作為統一的資料提供。

建議書是用于動員客戶啟動項目，或者用于客戶初步選型階段的技術支持，以入圍；

解決方案是用于洽談技術協議和合同之前的技術交底，或者用于議標階段以技術和實施服務等優勢戰勝對手；

投標書是用于客戶招標的技術交底，以綜合實力戰勝對手。

3.7.2 方案的基本結構

3.7.2.1 建議書的基本結構

建議書的側重點是分析客戶實施某項目的宏觀和微觀形式、現存的諸多問題，提出實施該項目的必要性和緊迫性，再介紹相關產品和技術的發展現狀公司的產品特點和優勢，落腳點是公司已具備相當的實力，與公司合作成功率最大、風險最低。建議書的基本結構如下：

引言

現狀分析與診斷

相關技術的發展現狀

公司相關產品的特點

公司具備的實力和基礎

結束語

各個部分撰寫技巧如下：

引言部分

從全國、行業的信息化現狀分析入手，說明信息化是大勢所趨，再從本行業的產品特點出發分析信息化需要注意的關鍵問題，最后介紹企業的情況，特別是信息化的已有基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等，說明該企業已具備實施本項目的基礎。

引言部分可分為：

制造業信息化現狀

本行業信息化特點分析

信息化的基礎

現狀分析與診斷部分

從本項目所涉及部門的業務現狀描述和分析入手，找出問題，并提出相應的解決辦法。

現狀分析與診斷部分可分為：

業務現狀描述

問題分析與診斷

相關技術的發展現狀部分

主要介紹本項目所涉及的PDM/CAPP/CAD等技術產生背景、發展過程，以及發展趨勢等內容，并說明這些技術已是成熟的實用性技術。

相關技術的發展現狀部分可按軟件產品類別分別介紹，最后有一個小結。

公司相關產品的特點部分

主要介紹公司相關產品的主要特點，說明公司相關產品是符合其發展趨勢的先進和成熟的產品。

公司相關產品的特點部分可按軟件產品類別分別介紹，最后有一個小結。

公司具備的實力和基礎部分

主要從公司簡介、完整產品線、研發能力、實施與服務體系等方面，說明公司已有足夠的能力承接本項目，并以成功案例證明與公司合作成功率高、風險最低。

公司的實力部分可分為：

公司簡介

完整產品線

雄厚的研發能力

科學的實施與服務保障體系

成功案例

結束語部分

闡明公司愿與企業強強聯手，結為(戰略)合作伙伴關系，共同推進企業乃至本行業的信息化建設。

在結束語部分要明確提出合作建議內容，對于一些戰略合作伙伴關系不能輕易宣講和承諾，一定要經報公司批準之后方可承諾。

建議書的要求是簡短緊湊，內容詳實，便于用戶決策，可以在一份建議書中形成幾個可選方案，推動用戶決策。

3.7.2.2 解決方案的基本結構

解決方案的側重點是分析現存問題，提出功能需求及相應技術實現手段，并輔以實施保障措施，說明用戶需求是可以實現的。解決方案的基本結構如下：

引言

現狀分析與診斷

系統規劃與設計

系統技術方案

系統實施方案

服務內容及措施

典型案例

結束語

引言部分

從全國、同行業的信息化現狀分析入手，說明信息化是大勢所趨。再從本行業的產品特點出發分析信息化需要注意的地方。接著介紹企業的情況，特別是信息化的已有基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等，說明該企業已具備實施本項目的基礎。最后通過公司介紹說明有能力承擔該項目。

引言部分可分為：

制造業信息化現狀

某行業信息化特點分析

信息化的已有基礎

公司介紹

現狀分析與診斷部分

從本項目所涉及部門的業務現狀描述入手，分析出問題，并提出改進建議，得出實施系統的必要性和緊迫性，以及需要解決的問題

現狀分析與診斷部分可分為：

業務現狀描述

問題分析與診斷

系統規劃與設計部分

根據現狀分析提出的需求，對本系統從總體目標、指導思想、總體框架等方面進行總體規劃與設計。總體目標，是從企業已有明確的總體目標中，結合用戶需求提煉出來的，不能簡單照抄，還需適當調整與補充。總體框架包括體系架構、運行模式，以及其它企業關心的問題等。

系統規劃與設計部分可分為：

總體目標

指導思想

總體框架

體系架構

運行模式

……

系統技術方案部分

從基本功能介紹、關鍵問題解決方案兩個層面介紹具體的技術方案。基本功能介紹是對本項目所涉及的產品，在標準模塊功能基礎上適當補充各模塊的新增功能或用戶的特殊功能。關鍵問題解決方案是就企業特別關心的問題(包括管理和技術兩個方面)、企業特殊需求中有一定難度的問題，以及管理方面需要改進的問題等提出解決方案和建議。

系統實施方案部分

從本項目的預期效益入手，分析項目實施存在的風險，接著介紹公司規避風險的實施保障措施，最后給出初步實施進度計劃和培訓計劃。實施規劃要結合用戶的實施打算，如果系統規模比較大，可以結合用戶的需求適當進行目標分解，分期完成。

系統實施方案部分可分為：

預期效益

風險分析及對策

指導思想

指導方法

實施管理

實施規劃

實施進度計劃

系統培訓

服務內容及措施部分

從公司能為客戶提供全方位服務承諾入手，闡述公司技術支持與服務的保障措施，讓客戶無后顧之憂。

服務內容及措施部分可分為：

服務內容及承諾

技術支持與服務保障

典型案例部分

用公司典型用戶的案例進一步證明，公司提供的技術方案是先進的、實用的，形成一套科學的、可操作的實施方案。典型案例選擇的針對性表現在：行業、特殊需求、項目類型等方面有相似之處。

結束語部分

闡明公司愿與企業強強聯手，達成合作伙伴關系，共同推進企業乃至本行業的信息化建設。

解決方案注意業務分析，系統規劃，技術方案三部分不要反復出現重復的內容，或者為了表達自己技術方案是扣著業務需求而在系統規劃和技術方案中再次反復描述需求，如果發現有這樣的問題就要精心去組織方案提綱。

此外解決方案要避免浮夸和務虛的內容，要盡量讓用戶看到可操作的內容，例如在實施方案中用戶最關心的是在實施分幾個階段？每個階段相互配合工作是什么？誰去做合適？階段結束的標志是什么？每階段工作需要多長時間？根據企業實際情況有哪些風險？如何規避？基礎數據如何準備？歷史數據如何錄入？工作流程應用前后有何變化？這些是用戶真正關心的內容。

所謂實施方法論，實施原則，實施指導思想，實施團隊結構等看起來飽滿，其實是務虛的內容少寫，寫得越多用戶越不得要領，實施方案的要害是具備不具備可操作性。這里面的原則就是計劃越細化越具有可操作性。

3.7.2.3 投標書的基本結構

投標書是針對標書的解決方案，包含解決方案的全部內容，再增加公司優勢和相關附件。投標書總是原則是按照用戶提供的招標書要求準備，用戶要求如何提供資料就如何提供，不要任意發揮。

常見投標書的基本結構如下：

引言

現狀分析與診斷

系統規劃與設計

系統技術方案

系統實施方案

服務內容及措施

開目公司的優勢

典型案例

結束語

相關附件

開目公司的優勢

相關附件

相關附件按照招標書的規定組織附件。

3.7.3 方案的針對性

為使方案具有鮮明的開目特色，方案必須具有一定的針對性。不同類別方案的針對性有不同的體現。

建議書的針對性體現在同行業的信息化特點分析，本企業已有的信息化基礎、本企業的現狀描述與問題分析等方面。

解決方案和投標書的針對性有相同的表現，主要體現在：同行業的信息化特點分析、現狀分析與診斷、總體目標、關鍵問題解決方案、實施規劃與進度計劃、典型案例等。

現狀分析與診斷部分、實施規劃與進度計劃部分，不能簡單把客戶名稱更改就變成另外一家的情況。

總體目標部分，有企業的個性，如果需要可以分解成近期、長期、遠期目標。

解決方案中可單獨把企業關心的關鍵問題單列為一部分，緊密結合企業的需求特點，不能簡單套用標準說法，必要時可以通過定制配置實現。

解決方案中的關鍵問題與投標答辯PPT中的關鍵問題有區別。投標答辯PPT中的關鍵問題主要是展示我們優勢部分，以攻擊對手的劣勢部分，但一定要有絕對的把握。

4 如何做產品演示？

4.1 什么是演示？

入行五年，售前售后演示最少也有兩百次，也算有一點經驗了，今天把我個人做做產品演示的體會做一總結，希望對所有想做好演示的人員提供一點幫助和指導。

產品演示不是演講，也不是答辯，更不是培訓。

盡管在很多表達和現場互動技巧上，演講，答辯，培訓和演示都有相通的地方。

演講更側重對某一個問題看法的陳述，主要是交換觀點，允許爭鳴，聽眾可以不同意你的觀點，但一定會捍衛你發言的權利。

除了常見的演講比賽外，很多時候演講者是受邀請，以一種被尊重狀態出場，是處于一種比較從容的心態下開始的。

演講的過程一般也是比較連續，不會被隨意打斷的。

答辯更側重對話雙方的交互，具有很強的考核目的，通過對答辯問題的反應答辯主持方來主動判斷他想獲取的信息。

答辯的過程一般是不連續的，隨時都可以中斷響應不同的問題，答辯的節奏和壓力也更為緊張，時間非常緊湊。

培訓更側重于傳授操作，此時被培訓者已經認可培訓者所在公司和產品，在過程中更多的是教學相長，形式可以多種多樣，根據不同培訓層次靈活組織。

演示不然，演示是有極強的目的性。演示往往是要在有限的時間內(比答辯要舒展)，面對一群不同心態或者不明心態的人快速把自己所在公司、公司產品和服務，包括自己最大范圍內推銷出去。演示過程中還要隨時準備開始各種技術答辯，應付各種刁難。

演示是主動影響客戶(用戶)的過程，售前演示也是主動和競爭對手競爭的過程，演示更是個人魅力展現的過程。

整個演示就是一場復雜的腦力游戲，看看我們有什么辦法在短短1到2個小時內更能抓住用戶的心！

4.2 演示的目的：

4.2.1 售前演示的目的

介紹公司，通過自己的言行和產品介紹展示公司的形象；

強化自己的優勢，給競爭對手設置一定的技術門檻；

講出自己能為用戶做什么，解決什么問題，愈是用戶關心的問題愈要主動溝通和交流，讓用戶對軟件產品技術和實施能力放心；

進一步判斷用戶關注的項目重難點，了解我們前期準備的不足，采取針對性后續對策。如果是這個項目一定要解決的問題，目前產品又無法實現的內容，必須盡快反饋給公司決策。

4.2.2 售后演示的目的

介紹公司和產品，讓廣大具體用戶認可公司，取得最大范圍品牌認同，減少實施阻力；

宣講對企業問題的認識，提出自己的業務解決思路，主動控制項目邊界；

通過現場互動進一步判斷用戶關注的價值點是否在項目邊界內，確認是否要調整項目邊界，盡快反饋給實施團隊或公司決策，

除了目的不同外，售前演示比售后演示更具有挑戰性，用戶更可能具備不合作性，演示沒有達到目的將可能導致不可挽回的局面。

一般在管理軟件售前項目中，產品演示效果不佳和典型用戶考察效果不佳兩個因素可以導致直接出局，沒有挽回的余地。所以產品演示一定要解決用戶對我們技術能力上的顧慮，保證得到進入下一輪篩選的機會。

所以本文重點將放在對售前演示工作的說明上，以下內容基本上都針對售前演示說明，售后演示可以參考并簡化部分內容進行即可。

4.3 售前演示為什么效果不好？(上)

坦率地說，我們業內大部分管理軟件演示總體來講不是特別理想，并沒有深入打動用戶。它為什么不理想呢？我個人認為有六個大的原因。

4.3.1 第一是演示沒有整體策劃。

成功的演示絕對不僅僅是兩個小時的精彩發揮，要保證這個精彩發揮，必須做大量的基礎工作才行。好的演示一般都有一個人在精心進行整個演示活動的策劃，是整個項目商務活動中必要的一環，而不是一個在孤立準備的活動。

商務人員往往期望有一個“高”人，到現場做一個精彩絕倫的演示，讓競爭對手甘拜下風，讓用戶眼前一亮，然后再四平八穩的把事情擺平，這種事情基本上不存在。

之所以某些人演示做的好一點，只是因為他準備的比別人多得多，如果演示者平時每天花半小時去演示，三個月后水平將是非常厲害的。

而現在許多人因為有某個單子才想起要準備演示，這個時候自己能演示什么呢？只好先看看誰能搞定這個事。這樣必然會導致某幾個人水平越來越厲害，而大家都不厲害，業務肯定做不好，都找這幾個人，這幾個人累死，而自己做業務總是束手束腳嘛，這不是一個很好的方法。

只要做好準備，每個人都能成功的做演示。要做好演示就不要隨意演示。

不要以為產品有幾個亮點，商務人員就想給用戶“鎮”一把。想這樣演示的，因為準備不足，或者沒有套路，結果用戶第一眼就看不中，會不斷的讓你演示，反反復復。

結果干了一件什么事呢？不斷給別人啟蒙，摘桃子的是別人。

即使在一次演示中效果很好也不意味著項目就是你的，而是在成功演示后安排大量后續工作。一般管理軟件項目周期很長，在短期之內，你不做太多投入把大單搞下來，但一定會有一個很密集的時間，投入了密集的資源做一系列的事，讓上上下下都認可你了，后面再按部就班進行。

這就要求要提前規劃演示，一般商務人員要提高半年或一年判斷大概在什么時候演示比較合適。

策劃什么呢？

第一要演示哪些東西讓用戶很接受。

如果要想知道這個事，首先要通過接觸對企業基本業務做個判斷，判斷以后安排技術工程師，或總部協調資源進行一次到位的調研，然后提前半年、一年準備，做一個相對來說比較和企業個性化特征吻合的配置，這叫技術準備。

第二，如果安排演示，一定要考慮演示達到目的了，后續最理想的工作安排是什么？是不是可以馬上安排用戶和公司考察，這樣他會在一個很高的情緒下不斷認可公司實力。

一定要考慮，演示以后效果好怎么，效果不好怎么辦？我們往往是演示了就完了，其實這個事根本沒完。

第三，演示給誰看，一定要保證這個人到位。

演示的時間寧可推遲，一定要保證你希望來看的人一定要到場，如果不在場，就不要演示，沒有意義。

4.3.2 第二是演示沒有套路。

很多人對軟件理解不同，喜歡按照自己的思路去發揮，每個人都進行發揮，結果導致整個公司的演示沒有統一的套路。

如果沒有統一演示套路，演示行為就無法標準化，沒有標準化的東西在管理上很難受控，也就很難保證質量，很可能某幾個人演示很不錯，大部分人演示不到位，那就趕緊把這幾個人的套路標準化并推廣。雖然企業有很多差異，但還是可以尋求共性，無非是針對不同類型多準備幾種統一的套路。

套路是一致的，但并非是說所有的人都在背臺詞，而是說所有的人用比較一致的思路去討論問題，談問題的實現方案，特別是一些共性的問題。

4.4 售前演示為什么效果不好？

4.4.1 第三是套話理念太多。

在策劃演示套路時要更多考慮一個問題，不是我們有什么功能，而是這些功能按業務能不能串起來。在考慮演示內容時，不要空談理念，在講到一個業務線的時候，把想法拔高一下，在合適的時候自然地帶出來。

如果大量在談理念，一是低估了用戶的知識面，二是提高了用戶的期望值，三是大量時間并沒有讓用戶看到實在的東西，誰也不會下決心購買概念，用戶特別是技術型用戶更愿意看到實際的內容，對于高管，在交流時談談理念可能更合適。

演示不能單調的只是將PPT的內容念出來而已，PPT的內容要簡單，主題明確，而演講者腦子里的東西則一定要充分口語化表達。

4.4.2 第四是演示時機不好。

過早演示往往是演示效果不佳的一個重要原因，很多客戶經理其實缺乏銷售管理軟件的經驗和從容自信，也缺少業務內涵，因此當發現一個項目信息后，他們往往不知道下一步可以做什么，要么被動地隨著用戶要求走，要么就積極主動創造調研和演示的機會，期望通過一次良好的演示或者用戶考察達到他們想要的目的。

實際上一個大的管理軟件項目售前周期是很長的，匆匆忙忙去調研演示，效果往往不好。我本人發現在長期跟蹤的項目上，往往是早起的鳥兒沒蟲吃。不要怕耽誤一個月兩個月時間，可以按部就班進行，當然那些客戶經理自己都沒有跟蹤，主動找上門來的緊急客戶項目例外。

為什么呢？一般客戶不可能一開始就完整知道這個概念和自己的業務需求，經過很多供應商多輪次攻關后，客戶才能比較清楚一些概念和自己的業務需求關系，也就比較容易看懂演示，演示也能達到目的。

大項目上是不會有太多的演示機會的，特別是在多競爭對手情況下，寧可等到公司準備就緒，確定演示策劃和實現計劃后，才能客戶預約，哪怕耽誤一些時間也不用擔心，給客戶解釋清楚，一般都會理解的。越是急著演示越可能成為用戶啟蒙者，而不是簽單者。

4.4.3 第五是演示人員能力不足。

演示這個工作不是誰都可以做的，它對人員綜合能力有極高的要求，顯然這種能力人員在任何一個公司都是稀缺資源，但是幾乎每個大項目都需要進行演示，在擁有能力的人員不能到位的情況下，只好用能力不足的人員去做演示，自然效果不佳。

4.4.4 第六是演示準備周期太長

很多項目用戶提出要求演示，客戶經理為了表示對項目的重視，也為自己爭取到一個表現的機會，一定是滿口應承。

應承過后很多客戶經理就會陷入困境，遲遲不能調度到演示人員去現場演示。如果讓自己或技術支持去講，肯定是講不清楚，達不到效果。

如果讓公司顧問來講，顧問太少，單子太多，都不知道什么時候才能輪到自己這里，即使來了一個顧問，也是沒有什么準備，匆匆忙忙，效果也不一定好。

當用戶發現供應商對答應的演示時間一拖再拖，就容易懷疑供應商的組織能力和產品實際水平，最終演示時也不能足夠重視，結果參與人員不足，自然難以達到效果。

所以作為一個軟件企業要想辦法讓演示組織工作程序化，演示套路標準化，有一個團隊在全力支持演示各個環節工作。軟件企業讓可能要進行演示的人員不斷練習，保證每個人演示可以達到一個基本的質量，保證企業隨時具備四到五個可調度，能清楚演示自己主導產品人員是非常重要的基礎工作。

4.5 售前演示工作應如何組織？(上)

一個好的演示是需要經過大量復雜精心準備的系統工程，是團隊合作的產物，是反復演練的產物。演示工作是有一定的內在規律的。

演示工作一般分為演示準備，演示，后續跟進三個環節，每個環節工作側重不同，但應該有一個總體演示工作組織策劃人。

演示策劃人未必一定就是演示者本人，但一定要是可以對項目可以長期跟蹤負責的人，而不是臨時的外部成員(例如從總部借調的咨詢顧問資源)。

很多時候總部顧問只是策劃人達到演示目的可通過合理方式調度的資源，有了專人負責，演示過程才能有策劃，忙而不亂，進退有序。

很多項目跟進半年來，還沒有任何關于演示的策劃，一直要等到客戶通知才匆忙通知準備，一切都沒有計劃性，或者用客戶工作突發性強為借口回避自己工作不到位。

從這個角度出發，我個人認為演示策劃人應該是一名有經驗的商務人員，在整個售前項目生命周期內策劃一次或幾次(對于大型項目可能是必要的)成功的演示本來就是商務人員的本職工作。對于沒有經驗商務人員接手的項目，其直接主管領導需要負責，并同時傳授和指導相關操作經驗，以便下次其可以獨立操作。

一般售前演示工作準備包括以下幾個環節。

4.5.1 和客戶建立比較緊密的商務聯系

在進行演示工作之前，一般情況下應該建立了良好的商務工作基礎。

例如了解企業組織結構，決策模型，和決策層建立比較充分的聯系和良好的第一印象，為演示工作創造一個良好的認同氛圍，讓大家可以帶著認同和學習的心態去看演示。

也要了解是否有競爭對手進行了演示，效果如何，用戶對哪些內容比較感興趣，哪些感覺不夠展開，以便我們進行針對性準備。

我們在商務上容易犯的一個錯誤是客戶經理不知道如何去打動用戶，面對用戶提出來的業務需求又無法滿足，只好承諾先調研，后演示，通過這些工作驅動項目往有利于我們的方向進行。

其實客戶經理未必要有很好的技術背景，但在商言商，無論你賣什么，讓客戶信任你所在公司才是商務工作的本質。客戶經理應該主動考慮我如何讓用戶建立對公司的信任，演示工作是整個信任工作中建立技術信任的一個環節。在此之前，客戶應該對客戶經理本人已經建立基本的認同，才能進行后續工作。

4.5.2 申請有能力的人進行業務調研

好的演示是針對重點(業務流)和難點(用戶極度關心的技術問題)演示，針對用戶的痛處演示，針對用戶的層次演示，而不是羅列我們功能的演示。

要做到這點，一定要安排時間做用戶的需求調研和業務分析，實際上大部分用戶也會主動要求我們做這個工作。

要得到能對演示起到指導作用的需求調研和業務分析，關鍵就在于演示策劃人一定要安排具有相應能力的人，或者調研者在有相應能力的人指導情況下去做業務調研。

一個能力或經驗不足的人調研結論對演示并沒有實際意義，這個時候用戶就會比較失望，花費了大量時間調研但居然演示內容針對性不強，這樣的演示效果可想而知。

所以成功演示前往往有一次比較到位的需求調研和業務分析過程。

業務調研有兩個可選擇的策略，如果客戶提供的時間很短，一定要協調派能力強的人，甚至就是演示者本人來調研；

如果時間比較充分，人力資源又比較緊張的情況下，可以派一般的技術工程師和實施工程師多花一點時間，按照公司調研套路和演示者要求將問題搞清楚，再讓演示者準備演示方案。

4.5.3 進行內部溝通

好的演示是團隊的產物，是群策群力的結晶。沒有人是全能和面面俱到的，每次成功的演示往往都經過了營銷人員，咨詢顧問、規劃經理、公司高管、還有實施項目經理的充分交流和討論，形成對問題的共識后做到的。

一旦確定要給用戶進行演示，就有很多內部溝通工作要做，第一件事情是按公司流程申請到合適的資源進行演示準備，并安排足夠的時間準備，且保證客戶可以接受演示時間。

資源的協調和計劃的落實是演示策劃人的職責所在，這就是售前的項目管理重要內容。如果是賣產品，銷售經理能勝任，如果賣項目，就必須是懂項目管理和策劃的人才能勝任。

要協調的資源可能很多，包括演示人員，配置人員，開發人員，甚至高管。這些都必須在一個完整商務策劃中體現，形成一個攻擊波團，不要一下子來個演示，然后又沒有跟進工作安排，要在一個比較短的時間內給客戶一些組合拳有力地打動他們。

落實資源后演示策劃人要讓公司上下人員對演示思路和準備工作達成共識。

共識包括三個方面：

第一選擇怎樣的產品線或模塊組合，很多管理軟件系統是很復雜的，在短時間內全面演示是不現實的，所以一定要合理選擇產品線組合或功能模塊組合，爭取在最短時間內讓用戶明白我們產品能力邊界。并準備對應產品線的演示思路和說辭，很多公司這些標準產品都有標準的演示套路可借鑒，適當調整即可。

第二建立對產品能力的信心，管理軟件實施成功率不高，很多客戶經理在銷售時心理是發毛的，底氣不足，這樣的狀態很難要求他充滿自信的演示，一旦在演示過程中遇到一些刁難，心理素質不過硬的人可能就提前崩潰。所以演示前要一定要讓演示者充分看到產品能力，建立共同的信心。

第三確定是否要協調資源快速開發某些功能點或者按照用戶數據建立演示環境。

大部分演示就是按照標準套路進行，畢竟很多企業存在共性的內容，并不需要一個企業準備一套東西，這樣成本很高。

但對于一些重要的項目，在演示前一定花費時間做定制配置，不做樣板化的介紹。用用戶的數據，用戶的言語，用戶的報表演示，還是值得的。

定制配置的要害就是一定要在項目資金允許的情況下，公司決策層認可的情況下，規劃方向認同的情況下，開發資源接受的情況下(這些都內部溝通的內容)，演示出用戶最想看的內容，而不是我們最有心得的內容。

要達成這些共識，不經過大量溝通是不可能的，沒有溝通，很容易出現演示前后同一公司不同人員說法口徑不統一的情況，對項目并沒有好處。

4.6 售前演示工作應如何組織？(下)

4.6.1 編制演示方案

內部溝通完成，達成共識后就可以進行演示準備，演示準備這個環節就是要按照共識來準備一份演示方案。

有了演示方案，演示時才能心中有數，讓別人提意見時也有了一個參考的依據，今后演示方案也可以作為公司知識積累，和業務持續改進基礎。

完整的演示方案應包括三個部分：

第一是演示產品線和其它軟件環境，包括操作系統數據庫和演示時要調用的其它應用程序或各種資源(例如動畫，動態庫等等)；

第二是演示的思路，演示一定有一個整體思路貫穿，這個思路根據演講的內容、聽眾的特點和演講的環境而且盡可能按照企業業務準備，而且簡明扼要說明了自己是如何按照業務思路連串軟件功能模塊達到支撐業務模塊的目的。

演示思路要考慮你想告訴聽眾什么？先要確定演講的目的。準備工作的每一個步驟始終要圍繞這個目的進行。只有這樣，才能保證你的演示方案有針對性且高效率。

第三是演講詞和配套操作順序，要寫清楚什么操作提供怎樣的說辭，操作的時間在哪里，哪些需要提前操作或打開界面，提高演示效率，哪些操作可能需要較長時間等待(例如匯總)，需要準備更充分的說辭，操作進入界面和數據位置，哪些操作在演示時不能做，這些都要逐段落實寫明。

一般認真準備了詳細的演示方案，現場演示就不會失去思路，操作也不會零亂，往往可以達到很好的效果。

演示方案的準備應該是公司級的行為，經過長期積累完善的演示方案就是一份積累了全公司業務經驗和產品功能的解決方案，可以成為實施標準配置，產品規劃需求和理念來源(準備售前演示過程也經常可以發現軟件不足和可以改進的地方)；測試的標準業務測試大綱，培訓的標準軟件平臺，咨詢顧問部也可以按照這個演示套路定制解決方案，形成幾個精練友好的業務解決方案范本。

這樣的話軟件公司可以通過演示方案把高管到基層員工，從外部業務部門到內部業務部門，從銷售前期到實施后期，通過這個售前演示技術準備活動達成了高度統一，大家的經驗和知識就有了一個共同的積累平臺。

4.6.2 反復排練

如何在現場進行一個好的演示，我的建議只有一條：練習，練習，再練習！

只有這一條沒有別的捷徑。

成功的演示無論演示者經過多少實戰，必要的針對性練習還是非常重要的。

如果是理念演講為主，沒有太多的操作，排練1~2次，基本效果是有保障的，如果是產品演示，特別是需要多人配合的話，至少要練習3輪以上。

如果是產品演示經驗少于10次的人，建議至少在內部演練5次以上。

建議：為每小時的演講作10小時的準備，隨著你的經驗日益豐富，你會發現所需準備時間會逐漸減少。

試講次數越多越好。如果你對自己有信心，聽眾就會相信你。

演講的時間包括使用視聽工具和回答聽眾提問的時間，因此試講中要留出這些時間。

每次試講都要逐漸脫離講稿。

試講過程可以對著鏡子練習，而且盡量大聲。

試講練習到一定時間可以安排錄音或旁聽，這樣可以發現很多自我感覺良好下無法發現的問題。

排練是一定要確認自己對所要介紹PPT的內容或者演示操作內容非常了解，起碼要做到看到一頁(步)就能想到其后三頁(步)所要演示的內容。

內部演練一定要有2個以上比較有經驗的人站在用戶角度上評點，讓他們充分提出改進意見，根據意見馬上調整。

內部評點還有一個工作是模擬真實用戶問題刁難演示者，對一些關鍵問題提前準備說辭也是排練時要完成的工作。

怎么挑毛病呢？基本上你在講時下面坐的想打瞌睡這種演示肯定是失敗。坐在下面眼睛還能睜著，感覺你講的有一二點收獲，這種排練就比較有感覺了。

如果演示是定制配置，更由于可能存在新開發功能，產品穩定性還沒有完整測試，此時演示前一定要反復進行操作排練測試，確保不出意外。

內部排練有兩個經驗：第一經過排練一定比沒有經過排練強；第二排練過的人現場講演效果一般比練習效果強，沒有排練過的人現場講演效果一般比練習效果差。

一個人經過反復排練以后往往有種壓抑的欲望需要渲泄，把這種渲泄的欲望放到現場，效果一般都不錯。而不練習的人一到現場就畏懼感加重，最后也無法正常發揮。

如果一些相對演示經驗比較豐富的人都認為這個演示方案有說服力，演示效果沒有大的問題，對對手、企業各種情況都進行針對性預演答辯通過，就可以準備上戰場。

4.6.3 約好演示時機和用戶

產品演示是目的性極強的工作，就是要通過演示打動用戶，促成其選擇或實施我們的軟件。

產品演示一般也要經過大量時間準備，成本很高。如果參加演示的人不到位，演示再好成效也不大，將不得不再次安排演示，這種反復將導致工作成本急劇增加，反復演示也未必也能保證演示資源和效果。

因此產品演示對象一般要追求參加人盡可能多，讓對軟件選型有影響的人員盡量參加，特別是技術類型人員，爭取都能參加。

因此演示前演示策劃人一定要和用戶詳細約定，在商務工作做到一定基礎之上后，利用相互的信任關系使得用戶愿意配合，調動一切應該來也可以來的人員參加產品演示會，保證演示的效果。

要做到這一點，就是在確定公司可安排的演示資源后，立即和用戶做大量溝通，確定應參加人員，可參加人員，比較合適的時間段，場地和設備，在這些條件都具備情況下安排演示。

如果演示條件不具備，寧可和用戶反復解釋，也不輕易安排演示，演示講得就是“一擊必中”，如果沒有這個效果，就不如多花一些時間在預約工作上。

4.7 如何準備標準演示套路？(上)

4.7.1 售前演示工作要不要標準化？

有人認為演示時企業實際情況千變萬化，難有一定之規，自然也很難準備標準化的演示套路，而且企業業務情況不同，用標準化的套路去應對效果可能達不到，應該采取定制演示。

這個說法看起來有道理，但實際上無法操作，定制演示的前提是比較詳細的需求調研，如果每個項目都做如此投入的話，供應商根本無能力負擔，而且需求調研即使很到位也未必能保證產品演示就能準備到位。

其次定制演示對演示者個人能力要求很高，一個企業不可能大量存在這種強人能人，定制演示要么人力資源響應不到位，只能用比較低水平人員去演示，要么演示準備周期過長，這兩種情況都是無法接受的。

從另外一個角度看，企業業務雖然千差萬別，但是以機械行業為例，生產模式也不過是單件、多品種小批量、大批量三類，設計模式往往也就是新產品研發、變型設計、系列化設計幾種常見類型，完全可以用統一的平臺來支持，相應演示套路也可以針對不同企業類型標準化。可以說業務是標準化的，定制一般也不過是數據是個性化的。

如果精心準備了完全按照實際典型企業業務運行的標準化演示套路有很多好處：

可以結合準備標準化演示套路工作將一個公司在不同行業企業業務經驗有效總結和抽象出來，形成指導產品發展的業務規劃模型。

對營銷工作而言，我們業內的營銷人員是不會去總結研究產品細節的，也不太熟悉企業的運做模式，這樣推銷管理軟件時有很多困難。一旦公司層面準備一個條理分明，思路清晰，亮點突出，操作固定的演示套路，營銷人員將大大降低對公司產品學習和掌握的成本，并能夠培養出一批能夠按照公司要求介紹產品特色的人員，解決售前演示資源瓶頸問題。

售前演示準備必須根據企業業務走。演示套路內容應是從實際實施工作中總結出來的，一般能在企業實施得很好的業務演示效果也不錯，而且可以代表產品目前可實施的最高水平。那么對實施工作而言，這樣的演示套路對實施人員打開思路，提高配置水平有很強的導向和示范作用。

對產品規劃工作而言，通過精心準備業務演示套路時就容易發現一般軟件產品不是功能過少，而是很難連續串起來支撐某一方面的完整的業務。在售前演示準備過程中由于按照完整企業內在業務邏輯準備，就可以提前發現產品在規劃方面的問題，可以及時和不斷改進我們產品中一些不足。

對產品測試工作而言，測試也可以按照售前演示套路準備實際業務測試大綱，提高功能測試外的業務測試覆蓋率，可以解決很多實施人員抱怨測試人員不了解實際業務，測試工作和實際業務脫節的問題，而且可以在標準演示套路基礎上編制自動化測試腳本。

對于咨詢顧問部而言，定制解決方案時候可以按照標準演示套路支持的業務模式來準備，這樣售前方案和售后實施可以極大保持思路一致性，不至于售前一套說法，售后一套說法，用戶感覺上當受騙。

對培訓工作而言，企業所有培訓也應圍繞標準演示套路，商務人員要能自如按照標準套路操作和演示，實施人員要能結合業務調研完成標準套路配置、實施和培訓，測試人員要能理解演示套路中體現企業業務邏輯，發現軟件不友好的地方，規劃人員可以通過演示套路判斷產品對企業業務模型支持是否足夠，應如何改進。這樣培訓平臺就是全公司統一的。

這樣的話一個公司從高管到基層員工，從外部業務部門到內部業務部門，從銷售前期到實施后期，通過這個售前演示標準套路準備活動達成了高度統一，大家的經驗和知識就有了一個共同的積累平臺，企業對用戶就真正具備了廣泛的一致性。

有了這樣的平臺企業才可以真正積累公司層面的知識管理，避免大量的發散性行為。很多公司并沒有認識到一個可培訓可操作的演示平臺比大量繁復的文檔更有利于工作，更有利于培訓，更有利于產品進步，更有利于公司知識積累。

很多公司的策略是做產品，既然是產品就應該可以形成相對固定的套路去服務不同類型的客戶，也就意味著公司可以形成相對固化的套路，這個對公司形成統一的認識非常重要，公司往往不是缺想法，而是這些想法不系統，不深入，更多的是靈光一現，不能積累和繼承。

個人以為標準售前演示套路準備意義重大，需要一步步通過演示工作去強化公司層面的工作導向，將其意義最大化，效益最大化，工作協同價值最大化，積累成本最小化，專人專崗長期制度化負責。

4.8 如何準備標準演示套路？(下)(

4.8.1 如何準備標準演示？

準備標準化演示并不難，不同公司產品不一樣，演示套路和側重也不會一樣，但都可考慮按照以下思路進行。

第一要成立專人負責的崗位和相應制度，否則能準備一次不錯的演示，但總不能隨著產品發展和實施業務創新而不斷更新演示套路。一般這個工作可以讓咨詢顧問兼任。

第二要清楚演示給誰看，不同人員關心重點不太一樣，因此建立可以準備側重政府領導，專家教授，企業高管，技術人員四個層面的演示體系。

第三要讓公司能力最強的人參與到標準演示套路中來，直接準備演示套路的人應該是對企業業務了解，配置水平最高的人，這樣才能最快有效把公司知識積累到標準演示套路中，并定期請規劃、開發、實施、測試、銷售、咨詢各方面精英人員參加內部組織的演示套路評估，提出基于各類業務的改進要求，不斷完善和改進產品功能和演示套路。

第四要形成和標準演示套路配套的標準演示方案和常見問題解答指南，演示方案要口語化，強調可操作性，類似于表演時的劇本。

第五要讓演示準備工作和規劃、開發、實施、測試、銷售、咨詢各個部門培訓工作主動銜接起來，定期根據標準演示套路進行不同側重點的部門培訓，快速把能力擴散出去。

第六要讓咨詢顧問和實施顧問根據標準套路準備標準解決方案和實施方案，形成一致性。

個人以為完成以上六個方面的工作才是一個完整有質量可結束的標準演示工作。

4.8.2 不斷結合實際情況總結演示套路

實際進行演示的時候演示者臨場自由發揮成分還比較多，演示完全不發揮不可能。

首先應要求演示者能按照標準演示套路照本宣科進行，這樣可以保證最基本演示質量，然后在大量實際練習中把產品功能和企業業務能夠融會貫通，最后才能夠在現場高度自由發揮。這三個階段不能逾越，否則現場一人一個樣，總結標準套路的工作就會失去意義。

既然有發揮就有好也有不好，所以公司還必須總結每次實際項目，特別是售前演示效果，無論成敗總結得失，并將意見反饋到演示準備部門，持續完善，持續改進，每天都能進步1%的對手才是最可怕的對手。

一般反饋意見可以從以下幾個方面改進和考慮：

如果是功能上對手具有我們沒有的特色，應反饋給產品規劃部門跟蹤業務規劃改進；

如果是操作過程演示層次不清晰，不連貫，應考慮如何結合業務形成更有效演示方式和表達語言；

如果是產品性能不足，導致演示時拖泥帶水，應反饋給測試部門作為缺陷加以改進；

如果是人員表達不到位，導致產品特色沒有清楚講解出來，應考慮逐步加強培訓，加快知識擴散周期。

4.9 如何進行現場演示(一)(

4.9.1 建立演示心態：

作為一個演示者，要有一個平和，自信，積極的心態。相信自己可以取得成功和得到用戶的認可。

好的演示心態天線在自我定位，重視和敢于挑戰對手，臨場發揮三個方面。

好的演示心態下演示者是不會心浮氣躁，上來就攻擊對手，指望一棍子打死別人，搞定客戶；

好的演示心態下演示者不會看到強手就害怕發虛，看見對手實力不強就輕視，是遇弱我強，遇強更強，勇于面對壓力和挑戰，正常甚至超常發揮；

好的演示心態下演示者在演示過程中不會遇到一點挫折就心灰意冷，會做好多次反復交流的準備，這個多次反復交流就是客戶對你還有興趣的一種表現；

好的演示心態下演示者對自己精心準備的套路和功能也不會過于自信，用一種平和的語調和對事業執作的激情感染用戶，打動用戶，讓客戶相信我們是一幫想做事，肯做事，會做事的人，演示時無論得分失分都不要高調，肚子沒有貨的人才喜歡炫耀；

好的演示心態下演示者在演示過程遇到設備和軟件操作意外一定不會緊張，緊張就讓別人看笑話。即使是出現很嚴重地低級軟件錯誤，也會不慌不忙重新開始，不需要做太多沒有必要的解釋，一定要解釋也應該是幽默的方式。用自己的從容鎮定感染用戶，建立用戶對自己的信任，對公司的信心。

根據個人經驗一個好的心態演示者往往是哪些對自己的公司，對自己的團隊，對自己的產品，對自己的能力有充分自信的人才能上陣，不要用那種對公司沒有認同，對產品表示懷疑的人去演示，他們在演示過程中抗擊干擾和打擊的能力往往不好。

很多人在第一次演示或者頭幾次演示時很難克服一種恐懼心理，這種心理誘因很多，但往往是越害怕越想，越想越害怕，還沒有開始講，自己就先崩潰了。

對于恐懼心理最有效的方法就是轉移注意力和積極的心理暗示。把注意力集中在演示內容本身上，而不是別人對于你演示質量的評價上，并不斷提醒自己一定可以做到比對手更好。

這里有一些標準放松方法可以提供給大家使用：

對著鏡子試講，想象你面前是你的聽眾。

可能的話，在實際演講會場進行試講。

確保你一直可以清楚地看到你的筆記或小字條，讓自己覺得就算是忘詞也可以看到下一步該講什么。

深呼吸，并保持微笑。

4.9.2 準備演示環境和檢查設備

準備環境事先可考慮以下要點：

后勤方面：誰在組織者這次演講？(了解詳細情況)

交通如何安排？(計劃并檢查旅行安排)

會 場：會場大小和形狀如何？(向組織者索取一份樓面布置圖)

可用那些設備？(弄清你要用什么設備，避免用不熟悉的設備)

時 間 表：誰在你之前發言？(弄清你是否有機會聽他們發言)

誰將把你介紹給聽眾？(一定要事先向介紹人做簡要介紹)

實地檢查：在演示前最好能夠提前到演示場地檢查，并提前調試設備。

場地和設備檢查一般要注意這么幾個環節，演示場地大小，座位分布，光線明亮度，由此確定自己演示時應站的方位和投影的方位。

如果有擴音系統要提前測試一下，確定自己發音大小。

測試投影系統和網絡連線是否正常，電源開關是否可用，線路長度是否足夠，如果有問題應提前解決。

如果現場有自己不熟悉的設備，盡量不要在演示時使用，或者提前請人調整好。

演講位置光線是否充足，能方便為其它人所看到，沒有視線阻擋物。必要時要調整座位分布以有利于演示進行。

如果是有重要領導和專家檢查的大型匯報演示還要注意這么幾個環節：

給領導和專家設置貴賓座和領座牌；

在演示場地內外布置歡迎牌和標語；

在演講桌上布置鮮花等修飾品，體現專業和隆重程度；

在主要就坐位提前放置飲料和相關資料，并且注意資料飲料排放前后左右一字對齊。

4.10 如何進行現場演示(二)(

4.10.1 演示時要注意的一些細節

4.10.1.1 如何注意演示姿勢

演示站位也有技巧，一定要正面面對大家，盡量看到最多的人。

如果圍著一個圓桌，你應該靠在最前面，你能看到所有人，但是你應該站在主要人物的對面。

聽眾的數量對你組織演講的方法有很大影響。聽眾人數少，你和聽眾就有充分機會進行交流。你可以邊演講邊回答聽眾提問，也可以就有關問題征求聽眾的意見。聽眾人數多，你與聽眾的溝通只可能以單向交流為主，發言方式就應完全不同。

有時候演示只來了二三個人，不一定要大張齊鼓的講，可以考慮一下，是不是大家坐在一個距離比較近的方式去溝通會更好一些。

人比較多的時候站起著講，人比較少的時候坐著講，站起來講的比較容易觀察每個人的反應。

如果是選擇站立姿勢身體站直，兩腳稍稍分開，體重均勻地分布在兩腳上，手臂在身體兩側自然下垂。這是最無明確表態的姿勢，是中性的身體語言。如果你了解不同姿勢的含義，你就可以在此基礎上創造不同的印象。例如，身體稍微前傾，顯得積極友好——好像你在邀請、鼓勵聽眾。反之，身體稍作后傾，就顯得消極，還可能有點挑釁意味。

演示過程中可以恰當使用手勢，一般人使用手勢最大問題是有一些不好習慣性動作會出現，解決這種不良動作最有效方法是看演示過程錄象。

4.10.1.2 要不要派發名片

演示前可以不派名片，要派就全部要派。

而且派發時由領導沿一定順序分發，不應跳過某人再分發，也不應先發普通人再發領導。

領導沒有入場之前可以先給其它人發，領導入場后根據情況決定是否分發名片。

4.10.1.3 演示前等待時間怎么辦？

演示前等待時間是很尷尬的時間，所以一般演示者可以請其它人去檢查設備，自己找一個安靜地方考慮思路，等到時間差不多時再入場，避免這段真空時間。

如果用戶沒有及時到場，主要演示者要體現一定專家身份，可以安靜等待，人數不多時可以適當交流。這個時候商務人員可以適當活躍氣氛，讓大家不覺得等待時間過于尷尬。

4.10.1.4 演示著裝

演示衣服最好是正式的，特別是正式演示，而且所有人著裝應該統一，最好是西裝。

西裝最好是一個顏色，灰色或者藍色，這是標準職業裝。

4.10.1.5 關閉手機

演示期間一定要保證無手機鈴聲，最好的方法是直接關機。所以應提前告訴你的同事你的工作時間，防止干擾。

如果確實有緊急事情不能關機，請其它同事演示時間內代管。

4.10.2 演講開始時緊張什么辦？

即使是很有經驗的演講者，每次開始演講的時候都有一些緊張，而且在演講的時候必要的緊張是需要的。必要的緊張會使人注意力高度集中，大腦在快速緊張地思考，從而可以更好的把演講思路搜索出來，并根據用戶反應進行內容和言語上的調整。

但是有的演講者一緊張就忘詞，結果開始時就有一些不流暢，結果越來越緊張。這種情況就需要大量的進行演示練習和試講。練習和試講可以消除演講者由于對內容不熟悉造成的緊張，而且大量的試講會累積一個人的發表欲望，經過多次準備的人會逐步對自己演講建立一些信心，并有發言的欲望，整個過程就容易有激情，不那么畏懼。

很多時候緊張就是因為對自己講演的內容不熟悉，沒有信心，導致擔心自己發揮不正常影響整個計劃，越怕鬼越鬧鬼。

此外演講開頭人總是有些緊張的，這個時候演講者可以多注意觀察會場，通過目光交流發現有興趣的用戶，看到用戶有興趣了，自己就逐步有一些信心，慢慢就不緊張了。

此外設計一個輕快有趣的開場白也是一個有效的手段，如果在一開始用戶對你的開場白就有了興趣或者發出了笑聲，這個時候演講者一般都可以松弛下來，進入一種良性的演講狀態。

最后注意語速，用中等偏慢的語速介紹內容，也是逐步釋放緊張的一種方式。很多人一緊張，講話就會無意識加快，一快聽眾就更不容易明白，不明白就沒有興趣，這種表現會反饋到演講者身上，進而形成演講者的焦慮，焦慮的演講者這個時候往往不自覺越講越快，這個過程陷入高度緊張惡性循環不能自拔。

4.11 如何進行現場演示(三)(

4.11.1 演示過程中聽眾感覺厭煩或注意力不集中怎么辦？

很多時候即使你做了精心準備，到了實際上陣卻發現好象感興趣的聽眾并不多，這個時候演示者往往比較受打擊，有的人就比較緊張，覺得用戶對自己的內容不感興趣，腦袋一緊張就不靈光，能把事先準備的內容講完就一頭大汗。

一旦發現用戶對內容不感興趣，演講者要緊急判斷是自己準備的內容對用戶的針對性不夠還是演講時間安排在一個比較容易疲憊的時間段，如果是前者演講者要立即改變演講的話題，逐步將內容往用戶感興趣的方向上引，如果是后者演講者就要發揮語言技巧，增加互動，提供一些幽默的段子調動大家的興趣。

本人曾經參加了一次國產軟件鑒定會，來的都是企業的領導和信息化負責人，整個上午領導和專家用學術性語言做了冗長的匯報，上午的會議一直12點半才開始吃飯，到了下午1點半就要開始我們的產品介紹會，這時來參加會議的人幾乎全部都昏昏欲睡，我們前一個介紹人員又座在椅子上講了半個小時的理念，一看大家幾乎都要睡了，也很機警，請我上來講。

我上來以后并沒有就坐，而是站在離大家比較近的地方開始，第一句話就是說：“各位上午開了一上午的會，肯定很疲勞了，我呢想結合我們實施工作講一些比較實際的東西，談談我實施工作中一些小故事”。

這里我就使用了兩個技巧，第一是站立，當你近距離站立在別人面前的時候，由于別人是坐著，出于禮貌就不得不抬頭看你，一抬頭精神就不一樣了，一勾頭就肯定繼續睡下去了；第二一直在聽各種理念，肯定很厭煩，我主動說將一些實際的故事，大家就有了一些興趣，有了興趣，自然就容易進入聽演講的狀態。

在后面的演講中我就放棄了用技術語言介紹的原計劃，全部用一個又一個實施過程中的酸甜苦辣的小故事和用戶交流，在用戶一陣陣笑聲中交流就取得很好的效果，到了演講結束，用戶紛紛主動索要我們的名片。

要避免出現用戶厭煩的局面，第一在演示準備前弄清楚對象，確保你所講的內容切題且適合他們特點，不然就砍掉。

第二演講者整個演講過程要有激情，很多時候用戶并沒有記住太多內容，但記住了那個演講很不錯的人，和那個人所代表的公司。這個時候聽眾記住的可能只是那個演講者的精神面貌狀態而已。

你積極的態度、活力和熱情將增強你演講的說服力。演講的具體內容或許會被忘記，然而你的態度、活力和激情將深深地印在聽眾的腦海中。

第三演講過程中語言要抑揚頓挫，千萬別只有一個語調，并和聽眾保持目光接觸，目光接觸要注意隨時看到整個會場所有人員，并保持微笑，讓他們感覺到你很重視他的表情反饋。很多操作性演示者為了確保自己操作不失誤，往往花費大量時間看電腦進行操作，這是不對的，整個演講過程中聽眾注意的中心只能是演講者本人，不是軟件操作，只有當演講者覺得用戶需要看操作的時候才主動引導用戶注意觀看軟件操作。特別是在一些需要大量時間操作的環節，如果將注意力集中在操作上，會讓用戶產生軟件很慢的感覺，其實在實際操作中速度并不慢，但由于在這個特定的場合用戶往往會形成這樣一種心理印象。

第四演示過程中演示者不要經常無意識挪動鼠標，來回拖動界面，分散用戶注意力。界面不應反復切換，應該一個界面一個界面把軟件思路和業務流程配合關系講透，再切換下一個界面或PPT。

第五控制一次演示的時間。成年人集中注意力的時間限度約為45分鐘。在這段時間內，他們只能吸收演講內容中的三分之一，最多七個概念。將演講要點限制于三到四個，并在演講開始與演講中加以強調，最后再加以重復。盡量用一個有吸引力的標題來概括你的演講，但不要太概括或太含糊。

4.11.2 演示過程氣氛不積極怎么辦？

演示者發現聽眾精神狀態不夠好的時候，首先要把自己精神狀態調整過來，不要受影響。我們許多人是很容易受打擊的，很容易受環境的影響。一定把這個勢氣調動起來。演示者有了精神狀態就有激情，有了激情就會感染別人，哪怕你講的不好，別人也認為這是個想做事的人，他對你的演講也會一定程度上認可。

此外為什么演示效果不好呢？讓大家跟我互動的時候，演示者經常會問一些問題，很多問題并不需要聽眾回答，而是讓聽眾進入思考，讓聽眾跟著演示者思路去思考：“我們企業里里有沒有這個問題呢？這個事有沒有解決呢？”

然后演示者再告訴聽眾怎么做，所以演示者不要光談功能，談概念，而是先談企業的常見問題是什么，原因是什么，如果解決了好處是什么，然后告訴聽眾怎么做，這時聽眾就會有興趣。要不斷地問問題調動他，然后不斷的講好處，你的業務線自然就串起來了，因為你是為了一個好處，解決一個問題，又帶一個問題，又解決了。這就叫完整的解決方案。

在成功的演示里，好處太多就沒有重點，一般只需要歸納出三個好處即可，多了記不住。

演示時，應該讓觀眾有一種參與感，就象講相聲一個吹、一個捧一樣。不要一個人唱戲。

應該適當地在演示時向觀眾提一些問題，比如企業的產品、任務情況，對軟件的了解情況，是否使用過相關軟件等。

也可以順便拉幾句家常，使氣氛活躍起來。講某些概念，比如對象、配置、參數化，要把概念講通俗一些，使觀眾能夠聽懂。

4.12 如何進行現場演示(四)(

4.12.1 投影儀連不上什么辦

在做演示之前，一定要檢查好硬件設施。但即使這樣也會出現無法提前檢查或者意外發現演示廳里的投影儀接不到筆記本上的情況。

此時關鍵是不能著急和冷場。在演示時應準備一些公司的簡介和客戶關心信息，并進行口頭介紹，將時間拖到投影儀接好。

然后在隨后正式介紹中弱化這一部分的介紹，將耽誤的時間趕回來。

本人就曾經遇到這么一次情況，投影儀突然罷工，結果就按照業務思路不慌不忙一口氣在沒有電腦情況下做了一個小時交流，客戶聽得很深入，一個小時后投影儀修復，再看軟件，客戶理解得很快，對我們產品很認可。

4.12.2 演示中客戶的主要負責人總接電話怎么辦？

領導接電話，一定要等，人少時直接停下來表示尊重，或者繼續用比較慢的速度講，然后等領導停下來說“某總，剛才我給大家介紹了一下什么內容，”快速補過，給足面子又不冷場。

4.12.3 多個公司連續演示，你排在后面，此時客戶已經開始聽覺疲勞怎么辦？

演講很多時候不是你最先講，那么別人講得好的內容要能立即化入你的過程中，巧妙利用別人烘托自己，也無形中讓客戶將別人亮點記到你的頭上。

別人講得大家昏昏欲睡時，可以先準備一個笑話和有趣的PPT給大家刺激一下，用一個輕松的心態進入交流的氛圍。

有一個有趣的開場白是很不錯的選擇，不過如果講一個大家都知道的笑話或者和演講內容沒有關系的笑話卻不是一個好的主意。

4.12.4 演講過程準備好的配置突然死機或者不能出來怎么辦？

第一不要緊張，繼續進行你的陳述，就當操作是正常的。

第二馬上同時手工調整，如果正常，可以繼續說剛才我介紹的“***功能，現在大家可以看一下”

第三如果實在問題嚴重，無法快速解決，解釋一下原因，例如機器中毒了，很多突發問題。所以計算機安全很重要。

第四自我解嘲，進入下一個功能介紹，還是不當回事。你越緊張用戶越懷疑。

打動用戶更多的是你陳述，而不是一時半會無法領會的界面和操作，有點問題你不在乎，用戶也就不會認為是大問題，至少你的鎮靜可以為你撈回印象分

第五強調一下筆記本機器配置不好，或者裝了太多系統，我經常拿著3年前本子做演示，速度慢一點用戶反而理解。

4.12.5 演示時有人打叉怎么辦？

當你在演示時，頻頻有人打叉，問出各種各樣的問題，有可能是某人非常迫切希望你跳躍性介紹他關心的內容。

也有可能是提出對演示者非常不利的問題，甚至是攻擊的問題。

因此在演示軟件時，要注意重點突出，不重要的例子可以根據觀眾的要求適當調整或者不演示。不管何種情況，您可以這樣回答“請允許我花20分鐘先介紹一下軟件的基本功能，再回答您關心的問題”來保持正常的演示順序。

對于觀眾提出的問題，可以表示贊許“您這個問題提得很好，我們開目軟件已經考慮到了”，“您的建議非常好，我會向公司領導匯報，考慮您的建議”，“您可能有些小小的誤會，其實這個功能是有的”。

對于確實是刁難性的問題，可以說“關于這方面的問題，我們可以在演示完以后再詳細討論”，“這方面的情況我不太清楚”，“這方面您是專家”，“軟件的優勢不是絕對的，有些軟件確實在某些功能上比我們方便一點，但在與***有關的主要功能上，我們是非常方便的”等，再約私下進行討論。

對于一些刁難的人，大多數情況他是想表現一下自己，多奉承一下，讓他獲得心理上的滿足即可，沒有必要與之爭論太多。當然，對于少數確實是故意為難的人，也可以明確作出回答，爭取大多數人的支持。對于關鍵的決策人，要始終保持溫和的態度。

4.12.6 演示時用戶臨時表示時間不夠怎么辦？

“我沒有時間，你不用演示了，我們這兒對軟件熟悉的人很多，只要留套軟件，留份資料，我們看一看就行了”

可以回答“我的演示很快，不會占用您太多的時間”，“我們這個軟件與其他軟件相比，有很多優點，值得您花一些時間看一下”，“我可以簡單地把功能和特點演示一下，相信您會大開眼界的”。

不過，給領導留一份詳細的資料的十分必要的。

4.13 如何進行現場演示(五)(

4.13.1 演示過程用戶要求改變主題怎么辦？

演示者在演示的時候一定要有激情，有好的狀態，但是千萬別太自信，要能應變。

萬一聽眾聽著聽著說：“這些東西我不想聽，你直接講是什么東西”，突然來這么一下怎么辦？可能聽眾里就有對手的釘子，故意難看你一下。

這種事情無法避免，只能預防，首先在排練的時候，自己人要給自己人發難，在內部排練時盡量模擬真實極端情況。應變也是練出來，多經過幾次實際演示也會積累很多經驗。

真正有經驗的演示者，在一個演示方案中可以從幾個地方作為開始，多設計幾條路，萬一客戶不愿意聽還可以從其關心的點切入，等其接受了還是逐步展開我們完整的解決方案思路。

4.13.2 演示過程如何答辯？

一般軟件產品演示完成后用戶會主動安排，或者臨時提出一些問題，這個時候就比較考驗演示者的快速反應能力，也能體現一個公司的綜合實力。

特別是在一些競爭性項目上部分聽眾會帶有挑釁的口氣向你提出責問，這個時候如何有效應對，從容自如完成答辯也是非常重要的演示得分環節。

本人的經驗在演示過程中遇到疑問甚至是刁難都是正常的，不要畏懼，把這個工作當作演示工作中的一種常態。

用戶問得問題越多，是對你的產品有興趣的一種表現，大家應該高興的去解答問題，而且這個解答過程中無論用戶處于什么心態，我們要保持微笑和認真聆聽的態度。

針對答辯有幾個重要的技巧：

第一對于一些比較復雜的問題，或者一個用戶提出了多個問題，首先不要急于解答，要先用筆快速記下來，邊記邊尋求最合理的解釋，也可以防止遺漏用戶的問題，以免用戶發現你遺漏后再提一次，感覺你在回避問題，我們畢竟不是外交場合，是技術交流，技術問題不應回避。

第二在回答問題前，可以把一些復雜問題或多個問題復述一遍，即請用戶確認，又為自己爭取思考的時間，但對于有些很簡單或者明確的問題，要立即肯定積極自信的回答，例如用戶在演示時沒有注意到他關心的一個內容，這個功能有的確是軟件常規功能，我們可能就沒有重點介紹，這個時候要立即和肯定告訴他，這方面我們沒有問題，不能猶豫磨蹭。

第三回答問題反應要快，針對問題本身不做發揮，言簡意賅。一般答辯時間不會很長，時間寶貴，不要對于某一個問題長篇大論，用結構化思路或回答套路，快速扼要讓用戶聽到答復，并禮貌性問一問不知道這樣回復您覺得滿不滿意之類結束。如果對一個問題解釋過多，可能也不是一下子能解釋清楚的，反而會越解釋越懷疑，越覺得累。

第四有些用戶問的問題可能帶有惡意，或者的確是軟件的軟肋，此時不應回避，要迎著問題解答，可以通過介紹我們正在開發的產品或正在規劃的思路來肯定性回答，越是自己不強的內容，越是要在演示時講透我們的業務思路，反而用戶會少在答辯時提問題，越是在演示時回避越容易被提出來并刁難。

而且這個時候我們可以用：“你這個問題很好；你說出了很多用戶關心的問題；你這個問題的確很有難度，看來您對***很有了解？”之類開頭緩和氣氛，拉進距離，增加思考的時間。

第五如果企業內部有我們的支持者，不仿先設計一些有利于我們的問題讓他們提向我們和競爭對手，這樣也是一個有力的武器。

最后對于一些純技術性問題可以要求用戶會后進一步單獨交流，避免出現不得不花費大量時間解釋一些大部分人不感興趣的問題。

如果有條件，是多人參加演示的話，可以就個人專長對問題回答提前做一分工，準備一些可能要回答問題清單并提前設計回復，這樣在演示現場時也可以互相配合，快速有序完成任務。

答辯考核的是一個公司和個人的綜合能力，所以真正答辯的精髓不在現場快速反應，而在平時對企業管理業務、產品規劃、業務知識、實施理念多個環節的知識積累，答辯優秀的人往往也是在知識面和深度上下工夫最多的人，這才是成功答辯的秘訣。

4.14 如何組織演示后工作

4.14.1 爭取約見重要領導

演示結束后，如果有機會演示團隊一定要和參加演示主要領導，甚至是沒有參加的重要領導。

不要放過這個有利的時機和重要領導溝通的機會，建立印象分，在演示過程中可能更多用業務的思維講產品技術能力，但和領導溝通的時候更多的用管理的思維講產品技術能力，這兩種溝通往往不能在一次演示中兼顧到位，但可以主動創造機會在后續活動中實現。

當然和重要領導見面機會并非可以有軟件供應商控制，但和重要領導溝通的工作意識隨時保留，飯桌上就是很好的場合。

4.14.2 提供備忘，后續跟進

演示無論實際效果如何，一定要留專業的備忘錄，一定要和用戶約定后續工作計劃，并按照備忘的承諾推進后續工作。

所以重要項目現場演示過程中應安排專人記錄，將演示過程和過程中大家提出的問題和回復逐一記錄，對于一些暫時無法清楚解釋的問題約定后續解釋工作安排。這種專業備忘整理能力是很能反映一個公司職業能力和職業水平的。

商務工作在演示達到目的的情況下，就可以更加良性的運做，包括馬上根據這次情況和對手反饋準備解決方案，公司考察，用戶考察，選型方案，招投標方案和答標演示等等。

在沒有達到目的的情況下，更要進行權衡，是否進一步加大投入，扭轉局勢，還是無力回天，集中精力做其它項目。

4.14.3 總結演示得失，形成反饋文檔

演示結束后，要針對演示實際效果形成反饋評估文檔，針對演示者個人能力，針對標準套路組織水平，針對產品技術能力結合競爭對手和用戶意見形成反饋意見，這將形成有力的產品規劃動力和演示準備改進動力。

很多項目在一開始接觸時就可以發現一些現有產品無法滿足的部門，如果在售前系統演示后用戶還堅持要實現的功能，如果此時提前給公司評估和規劃，在未來實施時就贏得了時間的主動權。

永遠要比對手多走一步，才能贏得最終的勝利。

4.14.4 一流演示的效益

每次好的演示都可以培養出一個能戰斗的領隊型，策劃型人才，每次都能讓客戶經理認識到公司強大實力和產品能力，對自己未來工作充滿信心。

每次通過售前充分的演示準備和排練可以培養團隊作戰的感覺，建立一個強有力的集體，這樣的項目售前演示最容易凝聚人心，建立信心。

演示工作最失敗的不是一個項目得失，而是內部成員對公司和產品信心喪失。

4.14.5 失敗演示的特征

沒有演示策劃

沒有進行需求調研，演示時無法用客戶能理解語言溝通

過早的進行了演示

沒有認真評估演示產品線或模塊

演示沒有套路

演示沒有就用戶可能的提問做準備

沒有后續工作跟進

4.14.6 一流演示人員應有哪些素質

實際項目實施經驗

良好的口頭和書面表達能力

表現欲

豐富的知識面

快速業務調研能力

快速學習能力

快速反應能力

4.15 演示方案準備經常考慮的問題

4.15.1 聽眾分析

會有多少人來聽演示講？

聽眾的平均年齡是多少？

聽眾的男女比例怎樣？

聽眾了解你的主題嗎？

聽眾是自愿來的還是別人要求他們來的？

聽眾有何共同點？

聽眾有何先入之見？

聽眾有何文化特點？

所有的聽眾或某一些聽眾是否認識你？

評估聽眾的可能對問題反應情況。

4.15.2 根據聽眾人數，調整演講方法

4.15.3 演講的結構類型與材料相適應

4.15.4 使用敘述法

敘述的基本技巧在于使發言有一個明確的開始、中間部分和結束。這種技巧最常用于講故事。你要成功地演示，遵循這一基本格式來組織演示是很重要的，演示的引言就是開始部分，中間部分就是演示的中心主題和觀點(用你認為最適合的結構類型提出)，而結束部分則由你的結束語構成。在結束部分重提核心主題，如有必要，再回答聽眾的提問。記住：重要的是在演示各階段的開始時和結束時，向聽眾提供明確的有關線索。

4.15.5 編制簡化提綱

準備一份書面的演示提綱是很有幫助的。在書寫提綱的過程中，組織演示的方式會逐步明朗起來。在演講過程中，帶可用提綱來提醒自己。將你的三四個要點標上“一”、“二”、“三”和“四”，然后在它們下面分別寫上二級標題(1、2、3)。如有三級標題，就用A、B、C標出；如此等等。提綱要寫得簡單，使之一目了然。

4.15.6 設計開場白

要想在演示一開始就給聽眾留下好印象，最好的辦法是你顯得堅定而自信。

有經驗的演示者總是每次設計開頭的兩句話，這樣就可以把注意力集中在如何打動聽眾上，而不必過于關注該說些什么。

一個成功的開場白會概略地說明你將作的演示，簡要地告訴他們你將提出的觀點。講些趣聞軼事，以親切友好的方式來活躍氣氛，并吸引聽眾的注意力。但要牢牢記住：在演示剛開始時，聽眾的注意力并不最集中，因此要在演講開始幾分鐘之后再提出你最有力的觀點。

4.15.7 聽眾注意力的持續時間

以45分鐘的演講為例，聽眾在演示剛開始時注意力很集中，10分鐘后達到頂峰，到30~35分鐘，注意力消退。最后，當演示快結束時，注意力又增強。所以演示方案中要設計關鍵內容和聽眾注意力之間的對應關系。

4.15.8 設計過渡詞

用清晰的線索來貫串演示是很重要的。安排好觀點與主題思想的邏輯順序，讓聽眾輕松地跟上你的演示。當介紹新的內容時，要將前后觀點緊密地聯系起來。

因此不同演示點之間一定要設計易于接受的過渡詞，幫助聽眾把思路聯接起來。

4.15.9 運用重復

演示時作扼要的重述，是強調要點的有效方法。組織演示內容時，在每個要點的結束部分及在整個演示的結束部分安排一些重復。但是，簡單地重復你前面講過的話是不夠的。要用不同的措詞，使你的觀點聽起來既新鮮又熟悉。

4.15.10 難忘的結尾

一個好的結束的重要性不亞于一個好的開頭。示意聽眾演示已近尾聲，是十分重要的。用“我要講的最后一點是……”或“總而言之……”等使聽眾注意到你就要總結你所說的話了。他們會很高興有機會補聽他們可能漏聽的觀點。

4.15.11 強調觀點

強調演示的要點相當重要。強調要點的方法可以是：先向聽眾提供演示“目錄”資料，然后討論你所提出的問題，最后通過作總結來結束。

4.15.12 撰寫口語化講稿

要注意，把書面材料以口頭方式告訴聽眾時，聽起來會有很大不同。要學習以自然的口語方式寫講稿，這樣，你的講稿就符合平時的說話習慣，并適合作口頭演示。

4.15.13 將演講方案濃縮為提示卡

如果你想使用提示來演示，首先要寫出完整的演示稿，包括所有要點和用來闡釋、說明這些要點的例子。以這個稿子為起點，你可以將演講內容濃縮為提示。將從稿子中選出的關鍵詞或短語清楚地寫在編過號的卡片的一面。一張卡片上不要寫得太多，要保證住處的簡潔和明確。

準備講稿：確定了演示的結構，而且組織好了收集到的材料后，將發言完整地寫出(或打印出)。編輯、修改這個稿子，直到讀起來覺得通順而有節奏時為止。

準備提示卡：從最后一稿中抽出要點，寫到編過號的卡片上。為清晰起見，每張卡片上的提示應不超過兩個。

可以用黑墨水寫絕對必要的內容，而可以刪除的內容則用其他顏色的墨水寫。

4.15.14 注明演講的節奏

想一想是什么因素促使演講成功，那通常是時間的安排。演講的無聲部分即停頓在傳達演講內容的過程中與說出來的話同樣重要，因為它們是聽覺上的標點符號。在撰寫講稿時，要考慮聽眾聽起來會感到怎樣。不管你演講時用提示卡還是完整的稿子，在你覺得必要的地方，例如在需要強調的觀點旁邊或在兩個完整的觀點之間，寫上“停頓”兩字。試講時也要使用這些停頓。使用沉默需要有勇氣：一個注明的停頓應持續三秒左右，這比平時說話時的停頓要長一些。

5 如何做用戶考察？

5.1 前言

5.1 前言

入行五年，做了一些相對成功的項目，而且所做項目離公司總部比較接近，因此經常有機會接待客戶提出的典型用戶考察請求。其實每個業內成功的項目經理都有一些售前的經驗，甚至在售后出色的人才會主動被抽調到售前，也許是有經歷的人的話更能打動客戶的心。今天把我個人做典型用戶考察接待的體會做一總結，希望給大家提供一點幫助。

5.2 典型用戶有什么意義？

一個項目在技術上決定成敗有兩個重要環節，一是產品演示，二是用戶考察。兩個環節都很重要，而且往往在很短一個時間段內完成(相對整個項目跟蹤周期)，所以典型用戶考察工作不能不認真對待，甚至要作為售前售后最關鍵的工作來對待。

現在很多用戶非常怕被軟件供應商忽悠，對考察工作尤為重視，甚至不通過供應商引見，自己去打電話暗訪明查，有的擔心我們提供電話是經過事先聯系形成默契的，還主動多打電話問幾個人，了解軟件應用情況到底怎么樣。

因為無相關行業用戶應用示范，或者因為典型用戶考察效果不好導致項目無法拿下的情況是非常常見的。

好的典型用戶對售前項目有多大的輻射意義，并不需要去強調，做商務的人都明白這一點，但典型用戶不僅對售前有意義，對實施規劃都有更大的意義。

一般典型用戶應用比較深入，往往累積了很多成功的經驗，這些經驗往往是比較成熟的套路，可以總結推廣到其它相關類似用戶身上，獲得比較快的實施效益。應該說每個典型用戶身后都對應一套完整可推廣業務實現實施模型，值得很好總結。

典型用戶應用比較深入，往往能提出更多更有價值的需求，這些需求對產品發展有很好促進作用，典型用戶一般又愿意和我們長期合作，通過詳細解剖典型用戶需求和業務模式，可以縮短軟件供應商了解行業業務的時間，形成有效產品規劃指導產品發展。

典型用戶還是一個公司營銷開發團隊是否有信心的關鍵，一般公司開發人員無法直接關心用戶，但營銷和實施不一樣，如果一個公司到處都找不到典型用戶的話，這個公司營銷和實施工作開展也不會順利，人員流動將非常頻繁，大家對公司也沒有足夠的信心。如果一個公司擁有一批成功用戶，所有員工基本上就會把精力更投入到業務中，因為大家會覺得既然別人能成功，我應該也有機會成功，而不是一致責怪公司這里不行，那里不到位，導致事情沒法做。

5.3 典型用戶應如何管理(上)(

和產品演示一樣，典型用戶管理也是一個系統工程，不是通過突擊就可以實現的。要想管理好典型用戶，就應該在公司層面有專人定崗定責進行管理，沒有專人管理典型用戶信息，業務一定會出問題。

典型用戶管理應該經過三個層次：

5.3.1 典型用戶確認

首先要將對公司市場工作最有利的典型用戶篩選出來，這些用戶其實在售前跟蹤時就可以通過客戶ABC分類加以明確，這樣即使某些客戶在第一次合作時項目金額并不大，也可以在在項目實施過程重點保障資源，重點投入。

一般選擇典型用戶名單考慮以下七個因素：

1) 應用效果，有三類用戶可以做典型用戶。第一是成功進行了大量應用的用戶，最好的典型用戶是實際業務每天都要大量人員利用系統進行工作的用戶，而且在實施過程中有很好的參考作用的用戶，這樣有實際應用效果的用戶最能讓其它用戶相信軟件公司的能力；第二是一些應用面還不夠大，但基礎數據都基本錄入，典型業務流都可以實現的用戶，第三是非常有特色的用戶也可以作為典型用戶。當然實際應用效果是選擇典型用戶首要因素。

2) 商務關系，所謂典型用戶，就是希望能夠替公司提供宣傳的用戶，這些用戶論高管還是中層干部或者基層操作人員應該認同軟件公司產品，愿意推薦軟件公司的產品，如果沒有好的商務關系，用戶甚至對軟件公司還存在意見，即使應用情況不錯，也要考慮是否適合做典型用戶。典型用戶的商務關系應該一直有專人負責跟蹤和維護，僅僅靠客戶經理和實施經理維護是不夠可靠的。

3) 行業影響力，影響力越大越好，一般情況下行業影響力大的用戶公司應在商務和實施時區別對待，重點投入，而不要簡單受項目金額大小左右，否則可能造成服務資源不夠，做臭一個，丟掉一片。

4) 業務應用豐富，以技術信息化軟件而言，要考慮典型用戶至少能覆蓋有設計有工藝，無設計只有工藝兩種研發模式，有設計無工藝的可以直接看有設計有工藝的類型。否則用戶考察時會提出感覺沒有看到自己想要的內容。有設計的用戶應該覆蓋到一種三維軟件，一種二維軟件。這樣的考察效果才能達到全面完整，業務類型豐富，而不是一個用戶實施比較成功，參觀就一定有好的效果，要選擇一個業務應用盡量豐富的企業。一般隨生產模式(單件，多品種小批量，大批量)不同，業務應用豐富的企業也要選擇幾種類型才能適應不同生產類型用戶考察需要。

5) 地域輻射力，典型用戶地理位置應該交通方便，不然會增加客戶交通成本，也增加公司接待成本，而且無法起到長期輻射作用。一個全國性公司一定要考慮在全國建立可參觀考察的典型用戶網絡，僅僅只有幾個典型用戶參觀考察對用戶本身也是一種巨大的騷擾，而且對很多地域性用戶，不方便出省考察的客戶是很難做到有效輻射。

6) 服務資源，典型用戶并非一定是所有問題都解決了的用戶，往往是經常性需要服務的用戶，因為應用深入，需求比較多，而且系統不能停，一停就容易出問題，但很多時候典型用戶要協助軟件公司做一些參觀考察工作，這個時候往往需要提前解決一些軟件應用問題，以便讓典型用戶在考察前有一個好的狀態，這樣典型用戶如果完全沒有服務資源往往會出問題。

7) 介紹資源，典型用戶接待客戶參觀時效果一個重要因素是企業有無能交流，并把業務和信息化實施過程問題介紹清楚的人員，如果有一個這樣業務能力比較突出，又全程參與項目實施過程的人員能介紹項目實際情況是最好不過。

典型用戶確認未必一定要以現在是否可以立即參考考察做依據，而是應該綜合以上因素以后確定名單，然后通過一系列工作努力讓這些用戶成為可以參觀考察的用戶。

5.3.2 典型用戶分級，確定服務模式

典型用戶名單確定后立即要根據典型用戶可考察參觀實際效果情況對典型用戶分級。

第一類典型用戶是可以隨時安排參觀考察的典型用戶。

第二類典型用戶是可公開宣傳，但不方便或不愿意接待參觀的典型用戶。

第三類是可以在售前非公開資料和口頭介紹的用戶。

第四類是千萬不能公開介紹和宣傳的用戶，一些典型應用不佳用戶。

第一類用戶應加強商務聯系，簽訂宣傳合作協議，保障定期走訪服務，讓典型用戶和我們長期合作，心情舒暢；

第三類、第二類典型用戶要根據情況確定是否可投入資源使其向第一類，第二類用戶逐步轉化，一個公司第一類典型用戶多了，市場口碑就起來了，甚至服務價格就可以提高了。

一、二、三類用戶都要明確詳細的服務模式，并落實到具體實施部門或區域團隊管理，并定期檢查服務工作是否完成和質量，這樣才能形成一個閉環的管理體系，不至于口頭重視，實際上因為沒有利益(國內目前大部分項目服務是無法收費的)保障而無資源投入。

第四類用戶也很重要，有些用戶在業內或當地知名度極高，但軟件公司在這里遭遇了滑鐵盧，所以公司一定要動態審查在方案、公司介紹、對外提供典型用戶名單上盡量不要出現此類用戶名單，避免被潛在客戶咨詢或提出參觀要求時被動。

5.4 典型用戶應如何管理(下)(

5.4.1 宣傳模式規劃

典型用戶的輻射效力體現在四個領域：

售前主動介紹(文字和口頭介紹)

客戶現場參觀考察

媒介(新聞性媒介和專業期刊)

行業或政府主辦經驗交流會議

所以典型用戶分級后，應根據這四個輻射效力領域分別設計相應的套路，針對不同典型用戶提供組合管理方案。

首先要為典型用戶提供在公司網站介紹材料，公司宣傳手冊，公司各種方案材料，公司售前PPT，公司內部培訓材料保持一致的宣傳介紹材料。

完整的典型用戶宣傳介紹材料應包括以下幾個內容：

企業LOGO

企業廠區或典型產品照片

企業概述(有地位突出地位，無地位突出業務特色)

企業應用軟件情況介紹

企業應用現場或鑒定現場照片

企業高管或項目負責人對項目一句簡短而經典的評價

企業應用效益

項目獲獎情況(是否獲得國家省部市級信息化建設項目獎勵，或者進入863主題計劃)

其次典型用戶現場參觀考察工作需要組織的第二個方面，下文專門另文介紹。

第三典型用戶媒介報道也非常重要，第一種是商業性媒介報道，主要是重要客戶簽單，取得階段性驗收，最終結項，通過重要機構鑒定和獲獎應及時在公司網站，合作媒體上發布新聞材料，這類消息軟件公司要有很強的主動宣傳意識。

除了直接商業報道外，還有一種軟媒介報道，就是和典型客戶項目負責人合作就項目實施特色應用或者實施經驗發表專業學術性文章在專業刊物上，擴大知名度同時也為很多企業項目負責人解決很多實際問題。

最后應用良好的典型用戶經常有機會參加政府行業或者集團內部主辦的經驗交流會或者鑒定會，軟件公司在申報項目的時候也經常需要請典型用戶合作作為項目用戶單位，并需要配合蓋章，因此我們應建立典型用戶的資料庫，隨時備雙方做匯報材料準備用。

如果有，以下材料一般都應保留：

詳細的企業情況介紹(企業概況、行業地位、產品系列、人員組成、聯系方式)

企業信息化總體規劃方案

企業項目招標書(選型評分表)

企業項目投標書或者項目售前解決方案

企業實施解決方案

企業對外項目實施經驗總結或成果匯報材料(文字和PPT)

軟件公司內部實施經驗總結(突出業務特點和功能應用特色)

項目雙方主要負責人員簡歷(應每年保持更新)

其它值得管理的資料

完成這三個層次的工作，典型用戶管理應該說就是比較完整業務過程。

5.5 用戶現場考察應如何組織？(

一般信息化項目用戶都會提出現場考察典型用戶的要求，那么如何組織用戶現場考察工作呢？

典型用戶考察組織有三個層面：

5.5.1 第一是公司層面

軟件企業對于已明確可以現場考察的用戶應要求建立考察模式，并由專人負責維護，一般就是項目實施團隊負責設計項目現場考察行程地點，業務介紹套路，實施應用介紹套路和相關PPT，并和企業接待人員充分溝通，就交流必須向潛在客戶講到的亮點，保證前來參觀用戶可以看到項目實施過程中的功能特色或實施特色，不虛此行，也是對潛在客戶的一種尊重。

公司還要提前和典型用戶溝通，確認現場實施狀態，評估項目可考察性，確定是否需要一些服務資源投入或者請典型用戶進行專門準備。

公司還要注意和典型用戶約定考察參觀方式和考察頻率，了解典型用戶安排方式是現場參觀，還是投影集中介紹，還是在某個業務地點集中介紹；典型用戶一個月希望接待幾批考察對象，本月是否有重要任務，不方便接待考察等情況。這些情況要提前通知到各地客戶經理知情，方便對潛在用戶進行介紹。

公司還要收集整理不同考察用戶關注的針對性問題或者考察評分表，形成問題集和參考評分表備案，這些內容將可以成為公司規劃產品發展，了解用戶功能需求和實施要求的重要渠道，也是向其它潛在用戶提供如何考察的素材資料，對于一些共性問題還可以形成公司級標準解決方案，有利于各個方面人員和客戶溝通。

最后公司要協調項目實際負責實施人員，或者對項目情況比較熟悉，業務能力很強的顧問型人員在考察期間全程陪同，至少要保證現場有軟件商的實施人員陪同。

這些工作一般有公司或者級別較高主管部門協調組織落實。

5.5.2 第二是客戶經理層面

具體到某個項目考察，這是客戶經理應該負責的工作。

首先客戶經理接觸到一個項目，應該要主動判斷是否安排用戶考察，用戶考察是否和公司考察放在一起進行，還是在本地典型客戶處安排考察，在什么時候進行為妥。

根據這個判斷客戶經理再根據企業業務特點和需求和公司提前溝通，確定可參觀用戶對象，請公司相關典型用戶負責人員提供若干典型用戶相關資料，以備用戶查問。

一旦客戶提出考察要求，要提前和典型用戶或通過公司和典型用戶預約時間。注意盡量避開用戶負責人不在，公司陪同參觀介紹人不在，企業休息日，或者拉閘限電(這個是近年中國特色)等情況，緊急響應，安排行程和場地，并把前來考察用戶詳細情況(人數，性別，級別，行程，關注點)形成文檔提交公司。

客戶經理還需要了解潛在客戶關注的問題，很多用戶會提前設計一系列針對性考察問題，這些問題要提前發送公司典型用戶負責人準備，并通過公司或親自和典型用戶溝通，介紹前來企業情況，前來人數和時間，希望考察內容，可能要問的問題，以便讓典型用戶自我介紹時更清楚情況，能夠達到較好的考察效果。

考察過程原則上客戶經理應全程陪同，客戶經理在陪同過程中要做三件事情：

1、隨時和公司內部溝通，通報情況和提醒注意

一般前來考察的客戶需要通過客戶經理介紹給相關人員，并單獨和相關考察接待人員溝通，說明一些文字描述可能遺漏或者不容易寫清楚的情況。整個考察過程中要隨時注意進行這類溝通，保持公司一致性。

2、親自安排好客戶的衣食住行

客戶經理讓客戶感到親切認同就是成功，這些都是通過接待細節中體現，所以客戶經理要親自做好這些工作，為今后商務工作奠定感情基礎。

3、寫備忘錄

客戶經理全程陪同最重要目的是隨時了解客戶在考察過程中交流思路，判斷項目技術或商務側重點應該是什么，便于進行下一階段商務和技術公關策劃，很多交流內容不是當事人是無法清楚表達和了解的。因此一定要利用這個機會充分了解用戶想法，甚至趁熱打打邊鼓，促進客戶下決心。

考察完成后客戶經理要主動幫助用戶準備一份考察備忘錄。一般企業出來考察回去是要寫匯報材料的，但大部分人出來考察因為行程緊張并沒有立即組織材料，只是簡單記錄，這樣一輪考察下來，再去組織準備工作量也不小，而且信息遺忘可能很大。其實很多人并不擅長寫文檔，如果這個時候有一份可參考的資料對這些用戶該是多么方便的事情。

所以客戶經理要主動在用戶考察完成后寫一份記錄考察過程的備忘錄，備忘錄可以分這么幾個內容，考察日程安排，考察用戶情況介紹和應用情況介紹，考察過程交流關鍵內容及回復記錄。這樣的備忘錄將非常有利于我們后續工作，有這樣現成的素材在，難免用戶會直接引用，一引用匯報給領導就給我們增加了成功概率，特別是當競爭對手都沒有做這個工作，就體現了我們的用心。

認真做事只能把事做對，用心做事才能把事情做好，就是這個道理。

備忘錄體現了我們對考察后工作的間接控制，保證考察印象能有效傳遞，但備忘錄有一個原則，客觀中立，可以回避弱點，但不能夸大粉飾。

5.6 用戶現場考察應如何組織？(中) (連載四十)

5.6.1 第三是考察顧問層面

一般情況下客戶考察應安排一個顧問型人員在考察期間全程陪同，因為用戶在考察期間是最容易進入實際環境感受，容易看到別人實施過程，思索自己項目規劃的時機，如果能得到高水平咨詢顧問交流和指點的機會，會給軟件公司增加很多印象分。實際上考察走馬觀花能看到什么？有的企業比較有經驗，能深入了解一些情況，大部分企業考察看不出太深的內容，只能說在考察過程中誰能在短短幾個小時內了解到客戶的擔心和疑惑，并合理通過考察行程展現出來

此外很多典型用戶自己用得不錯，但缺少系統的總結，介紹時沒有層次，而且他們一般也不太清楚參考企業到底關注側重點是什么，介紹時容易突出自己的特色，但沒有考慮參觀企業到底想看到什么，這個時候顧問就要巧妙利用自己豐富實施經驗和判斷力，以及和典型用戶良好人際關系引導介紹交流思路，讓參觀用戶看到東西，學到東西。

無論能否成功合作，潛在用戶花費成本考察，我們就應該盡力讓他們了解項目實施效益和風險，以后他們在信息化建設過程中可以少走一些彎路。

所以一個好的考察顧問往往是整個用戶考察的真正靈魂，有沒有一個這樣的高水平顧問對整個考察效果質量是兩個檔次，明白這一點客戶經理也應該清楚要讓自己的考察達到效果，有沒有這樣的一個人是非常重要的，一定要盡量協調好時間，讓考察顧問有充分時間陪同，如果公司沒有這樣的人員，考察過程就只能聽天由命，讓典型用戶自己發揮。

但這樣的考察最大的可能問題是，很多項目業務和潛在用戶實際不一樣，潛在用戶總覺得和自己類型不相似，總是想看到一個和自己一樣的企業而且成功實施，這樣就比較放心。

且不論用戶這樣的認識是否正確，但的確一個軟件供應商也很難讓若干典型客戶代表所有的企業業務情況。如果一個軟件商有如此足夠實力擁有全面可考察的典型用戶自然最好，但實際上這是理想情況，而且很多用戶行程安排又決定他們沒有足夠時間去考察其它類型用戶，所以很多用戶考察完后總有顧慮，覺得自己想看到內容沒有看到，這個問題如果有經驗豐富顧問彌補介紹是一個補救的辦法。

當然作為公司盡量在各個地區培養不同類型的用戶是非常重要的工作。

5.6.1.1 考察顧問應該注意的三個環節

考察顧問和客戶在一起一般要完成三陪工作，第一是陪交流，第二是陪考察，第三是陪吃飯。

客戶在去考察典型用戶之前，一般會先安排和公司顧問做一個交流，那么這個時候顧問要充分介紹自己產品特點，回答用戶關心的問題，了解用戶關注問題，快速判斷是否可以在要考察的典型用戶里看到和說明，如果看得到自然最好，如果看不到，就要考慮相應說辭，從而能夠很好地在考察時候讓用戶得到一個滿意的回復。

這個時候顧問要低調親切溝通，給客戶建立一種專業沉穩的可信賴印象，在現場考察的時候才容易發揮出彩。

顧問和用戶交流往往存在幾個難題，第一是原來不認識，比較陌生，如何快速讓客戶進入狀態；第二是顧問對企業往往也比較陌生，如何快速了解企業情況，進而合理提供建議。對于顧問應在用戶來之前做一些案頭工作，查看售前相關資料和上網了解企業產品是很好的辦法。

能否快速讓客戶進入狀態一是顧問應有一定商務知識，善于制造溝通氣氛，最重要的是顧問能很快讓用戶覺得自己比較專業，進而有溝通的興趣。

要做到這點一般顧問應該也是一個實施經驗很豐富的人員，否則顧問只是名義上的顧問而已。

一個有豐富經驗的顧問，在陪同考察和吃飯時才能有效說服用戶，建立信任。而且一個有豐富經驗的顧問，不僅僅是業務經驗豐富，還應該有一些雜的知識面，例如在行車路上，顧問就是一個導游，講環境，講發展，講文化，讓用戶可以先輕松一下，也建立一個好的氣氛。

5.6.1.2 現場考察三原則

盡量讓用戶自己介紹，顧問只在關鍵時候點題，或者在局面不利時候出馬，不要喧賓奪主；

介紹情況不可任意夸大，實事求是，不要怕客戶看到不好的方面，應該真誠和客戶戶探討如何才能實施好項目，取得用戶的信任。甚至在客戶來到現場之前多鋪墊一些低調的話。

只介紹功能，不介紹實施。有的用戶對技術非常感興趣，對實施難度不夠重視，這樣的用戶要在技術上讓其放心后，合理感覺到實施方面的難度，進而認同找到一家好的供應商合作才能成功的道理。

5.7 用戶現場考察應如何組織？(下)(連載四十一)

5.7.1.1 現場考察介紹技巧

用戶用得不好，看功能。不好就是不好，可以不主動談，但可以通過功能介紹說明軟件應有的能力。

用戶用得好，看應用，看每天有多少人建立多少數據，事實比任何數據都有說服力。

介紹軟件功能要用講效益的方式去講，用比較精練的話去引發用戶的興趣。

例如我介紹一個用戶用KMCAPP編制工藝的好處用了一句話，在這個企業80%工藝數據不是手填的。很多用戶就很感興趣，這樣我就有充分時間展開如何合理規劃工藝數據，建庫查表自動計算廣播等等，通過實地演示讓用戶感受到信息化的好處。

講實施過程要用講故事的方式去講，例如我介紹一個用戶實施過程，用了四上四下，說同志搞革命三上三下，本人做這個項目四上四下，通過介紹四上四下說明項目一把手作用如何體現，項目團隊應該有怎樣品質人組成，一個項目成功最重要的要素是什么，這樣用戶在聽故事的同時就不知不覺接受了你的理念。

講故事還要追求輕松幽默。例如我和客戶講企業實施磨合痛苦的過程，就用了一個方輪的故事。

有一個用戶給我講，原來沒有用電腦，好象每天走路上班，感覺也很好；后來上了電腦，就象騎自行車，每天輕松了許多；現在單位上了這個先進的ERP/PDM，高興得不得了，因為開上汽車了，車型款式還特別漂亮，一看儀表系統就知道是進口貨，各種駕駛信息一目了然，原來自行車是沒法比，但一摸方向盤，一踩油門，就是無法啟動，下車一看，天啊，咱們這車輪子是方的！

這樣客戶就很輕松在笑聲中明白就跟兩口子新婚一樣，所謂實施，關鍵在磨合。所以搞信息化一定要做好長期磨合的心理準備，沒有這個準備，離婚率一定會大大上升。

再如我講實施上線的難度，就提了一個走不完的20米，說我們企業系統管理員，在項目上線最繁忙的時候，每天從辦公室走到廁所這20米是無法走完的，每次還沒有到廁所就被兩邊部門人員喊進去解決問題，只能等別人下班吃飯趕緊沖到廁所去解決問題，這樣的故事在笑聲中就把很多不好說也不容易說清楚的事情和意思表達出來了。

但是講實施風險的話題要慎重，體現難度大的事情也可能打消用戶實施積極性，要慎重講，到了氣氛再講。

講故事還要將一些具體實施思路和做法體現出來，讓用戶對我們經驗和專業水平表示認可。有的用戶對信息化軟件基礎數據錄入不夠重視，也不清楚如何推廣軟件，這個時候我就會講一個三毛錢的故事。

我講我們開始軟件安裝到位，大家都不愿意用，說是軟件不能用，結果企業就下令3毛錢一條數據，結果就有人開始錄，還真得到了錢。這個時候我往往開玩笑說我們當時開發人員要求去現場實施，協助錄入數據，以我們水平一天錄入1000條數據很容易，這可就是300元的收入了！

大家一看有錢拿，就紛紛錄入數據，這個時候領導就把政策停了，大家剛想責問，領導說，原來各位說產品不能用，所以不能錄入數據，現在發現你們都可以錄入數據了，總不是各位給錢就配合信息化工作，不給錢就不配合信息化工作吧？

這樣在大家都掌握基本操作后進行一次考試，考試過90分的企業每人獎勵500，過80分獎勵300，這下子大家積極性都調動起來了，一個月后領導宣布進行第二次考試，這次80分以上都獎300，并宣布兩個月還要進行考試，不及格要處分。果然兩個月后再考試，90分以上獎300，不及格罰200。

通過三次考試，就達到了拔尖，鼓勁，鞭策的目的，而且將軟件操作和應用一層層擴散出去，最終形成大面積使用的不可逆轉的趨勢。

很多人聽了這個故事對項目管理，目標驅動，激勵效應就有了更深的認識，自然也對顧問，對顧問所在公司多了一份信任。

5.7.1.2 飯桌上再燒一把火

一個好的顧問在陪同考察完畢，一定記得如果安排一同就餐，在飯桌上還得根據客戶情況繼續燒一把火。

不過既然到了吃飯時間，工作就不應該是主題，這個時候比較好的方式是可以從介紹公司文化逸事或者發展思路方式嘗試用更高的思維層次和客戶溝通，不要再糾纏過多在技術細節上，這樣客戶可以比較輕松邊吃邊聊，將一些感興趣問題又提出來和我們交流，進而繼續獲得影響客戶的機會。

記住：客戶前來考察是最脫離自己企業環境可獨立思考的時間，也是最容易接受別人的時間，整個考察工作如果精心準備和規劃，自然能給客戶留下深刻的印象，對項目成功起到關鍵的作用。

6.1 前言(連載四十二)

入行五年，經常碰到需要和各種人等介紹公司的情況，特別是在公司總部接待重要貴賓考察，積累了一些經驗，今天把我個人做公司介紹的體會做一總結，希望對所有需要介紹公司人員提供一點幫助和指導。

6.2 哪些情況下需要公司介紹

公司介紹是用比較短時間內讓客戶對公司業務能力有一定了解，甚至是深刻印象，為今后合作開一個好頭。

一般公司介紹有這么幾種類型：

第一是正式陳述，在重大招投標答辯場合，產品演示場合，一些公開會議上，這個需要很正式地介紹公司基本情況和實力。

第二是口頭介紹，在商務和實施工作中，碰到一些人關注或者不了解，在沒有特意安排的情況下進行口頭介紹。

第三是會面介紹，一般是和客戶約定會面時間，在會面的機會介紹自己的公司和產品。

第四是參觀介紹，客戶或客戶到總部來參觀，在參觀過程中介紹公司文化和發展等各方面情況。

不同情況下介紹公司的要求是不一樣的，所以下面我分開介紹。

6.3 正式陳述時常見錯誤？

6.3.1 反復介紹原來介紹過的內容

正式介紹是一個很正規和重要的場合，而且是在雙方進行各種接觸到了一定程度的時候才有機會進行的工作，因此可能有很多人對軟件公司已經有很多了解，因而來聽陳述的重點內容不是軟件公司基本情況，而是軟件功能或者項目實際情況。但對一部分人可能對軟件公司不太了解，因此在正式介紹時根據已經介紹過的內容確定取舍，不要反復講以前很多次介紹過的內容，而是要突出公司競爭優勢點，其它內容在沒有明確要求的情況下盡量一帶而過，不要擠占重點內容介紹時間。

我個人經驗介紹內容一定要結合客戶關心部分強調幾個點，一般就是三點公司優勢，例如可以介紹的內容一般是規模，地位，實力，客戶數，行業經驗，規范性，服務能力，研發能力，完整的解決方案，自主版權，公司發展速度，最新情況通報等等內容，但不要面面俱到，效果反而不好，要選擇最能打動人的關鍵點組織。

把力量集中反而印象深刻。

6.3.2 介紹速度過快

正式介紹一般有時間限制，公司介紹又必須首先進行，有的人很想在正式介紹時把公司情況盡量完整進行說明，又擔心用時不夠，為了解決此問題，就用比較快的節奏介紹公司。

但參與正式介紹場合的人往往也是有一定級別的人，習慣用一種比較舒緩平穩節奏聽取匯報，而且用很快的語速開始會給人留下緊張，不夠大氣的印象，進而對公司印象也不佳，而且短時間內的灌輸也不見得有效果。

所以寧可裁剪內容，也不要介紹公司內容時過快。

6.3.3 一些細節用時過多

有的人在介紹公司時覺得有一些很重要的內容，例如公司歷年獲獎情況，一張張把證書慢慢放給客戶看，如果不是客戶要求的話，這樣的介紹方式并不好。

站在客戶的角度，這是一種包裝手段，不是實質性內容，這些內容介紹多了容易給人不實在印象。

此外大家可能都有一個經驗，看電影的時候片頭時間越長越煩，最終讓我們記住電影名字的還是電影本身內容。

在做公司介紹時沒有重點，把一些自認為重要的細節講得過多，都是對客戶時間的浪費。

6.3.4 資料無更新

我經常看到很多人不注意和公司相關部門溝通，總是用自己習慣的PPT或者材料去介紹公司，到了2005年了，公司材料上的成就和案例還是停在2003年，這樣給用戶的感覺是不是這兩年你們公司沒有什么發展了？

所以一定要注意資料更新，而且資料一定要保證所有公開資料的一致性，特別是介紹內容和公司宣傳資料一致性。

為了彌補資料不夠及時的問題，在介紹時可采用一個技巧，可以用通報方式補充說明，例如可以在介紹時非常自豪的講：“下面我向大家通報一個好消息，我們剛剛在***”，簡短說明意思即可。

6.3.5 介紹定位過于自戀

很多公司自我介紹一個典型感覺不象是寫給客戶的，倒象是寫給公司老總的自我陶醉的文字。

公司介紹材料充滿自我炫耀，自我膨脹，自我肯定，就是沒有站在公司能為客戶提供什么產品和服務內容的角度去組織材料。

好的介紹是告訴客戶我能為你做什么，不是因為我有多么好，快來選擇我吧，同樣的內容用不同的方式組織介紹效果也自然不一樣。

6.3.6 沒有激情

特別是對于經常正式介紹公司的人，還有一種情況，可能因為講的次數過多，對重復的內容沒有感覺，缺少激情。

一個人介紹公司時沒有自信，沒有一種在此從業引以為榮的自豪，又如何讓客戶從你個人身上感覺到你所在公司的成就？

從容自信，充滿感情介紹公司是一個職業人必須能調整自己情緒做到的一點基本素質。

6.3.7 采用危險的表達

有的商務人員對一些內容不太清楚，在介紹時犯一些常識性錯誤，例如把CMM說成是通過三級認證，ISO存在認證，CMM沒有認證，只有評估，對內行這是錯誤說法。

例如過于強調我們人員多，有360多人，可能現在正式提供給公司手冊上人員已經是260人了；

又例如習慣性強調我們的EAIP平臺和電子政務等內容，其實這些部門或業務已經整合調整不再進行了。

這些介紹硬傷是一種危險表達，會讓用戶覺得我們不真誠或不專業。

另外就是為了獲得競爭優勢，采用一些危險的提法，例如強調我們國內第一，我們實施成功率最高，我們最有行業經驗，我們可以現場開發等等說法。誰能證明你是第一或是最優秀呢？

在用戶沒有實際了解之前，不過是虛夸，用戶實際了解后，可能更認為你言過其實，更加不信任你。

我們有個項目例如強調我們某個產品發展歷史很悠久，但實際上發展時間只有三年，版本升級很快，結果客戶私下打電話了解相關用戶，有的用戶告訴他用的版本很老，一直沒有升級，有的用戶告訴他用的是新版本，剛發行但不穩定，很快客戶決定放棄我們這家公司。

沒有誠信，不會長久。

6.3.8 沒有專人管理正式材料

有的商務人員說我也不想有介紹硬傷，我也想知道公司的最新進展，但哪里去找呢？

因此隨時更新公司介紹材料，提供標準說法并下發應該有專門人員負責和維護，否則很容易在細節上吃虧出問題。

6.3.9 著裝隨意，不統一

參加正式介紹人員著裝正式統一應該是個很基本要求，也是對客戶的尊重。

一旦一個人要介紹公司，就一定要注意，不可在隨意和過于放松情況下介紹自己的公司，因為過于放松狀態下介紹公司難免給人一種對公司不太認同的印象，既然談到公司，無論在什么時候，都不是私事，就應該打起精神開始。

6.3.10 隨時練習

有人以為自己介紹公司很多次，經驗一定很好，就不注意準備，但在現場就發現要么容易沖口而出，要么羅里羅嗦講個沒完，又抓不住重點。

練習，練習，不斷改進，這才是真理。

6.4 口頭和會面介紹時常見技巧(連載四十三)

口頭和會面介紹一般都是在一種相對非正式場合進行，例如辦公室面對面進行一些匯報時寒暄內容之一。

這個時候介紹公司內容和正式介紹類似，但要注意時間不要太長，一般三分鐘內為佳，用戶有興趣再展開。

但這個時候交流往往有很多意外情況，所以我覺得自己事先一定要有準備幾個版本的說法，應付不同情況，同時保持自己的不卑不亢。

6.4.1 不知道型

例如有的時候你一講我是**公司某某某的時候，客戶來一句：“**公司，沒有聽說過，干什么的？”。

沒聽說型的客戶是很正常的，這個時候可以說：“*工，請允許我用三分鐘簡單給您介紹一下，具體內容略”。

6.4.2 反感型

比不知道的情況更糟糕的時候客戶會說“聽說你們在某某項目上很不成功，是不是這么回事？”

面對這種用戶的挑戰，千萬不要急于否認，只會增加反感，也不要緊張，失敗的案例大家都有，不要因為拿出一個不成功的例子就覺得沒有希望。

我們可以先承認，后化解，“看來*工了解過一些我們的情況，的確我們有一些項目沒有做到位，在很多行業，其它地區，我們還是有很多成功的合作，例如在某某，如果您不反對的話，我想介紹一下我們公司最近的一些情況。”

6.4.3 我知道型

有的用戶一聽我們公司名號就說你們不就是那個做CAD的嗎，這個時候我們就要順藤摸瓜，夸獎客戶：“看來先生對我們公司很有一些了解，不如我給您介紹一點最新情況”，也可以用化解誤解方式進行“看來先生對我們公司很有一些了解，其實我們不但CAD做得有很大影響，這幾年我們發展得還不錯，在CAPP/PDM領域我們也是國內最好的供應商之一，所以今天希望有機會給您詳細介紹一下”。

6.4.4 領導型：

有的用戶很忙，也很緊張，根本沒有時間聽你講太多東西，我們可以開門見山：“我們是國內最有經驗的CAD/CAPP/PDM供應商，聽說您的企業有****問題，我們正好有這方面的經驗，所以過來和您一起溝通一下，看看有什么我們可以幫上忙的地方”不過這樣舉問題有一定風險，所以可能的話應有所調研了解。

6.5 在客戶處進行公司介紹三個要點

無論是正式陳述還是口頭介紹公司，有三點一定要講到：

業務講到：我們能為您提供什么，做什么，如何合作。

實力談到：和我們合作為什么可以放心。

案例說到：我們不是在說大話，有很多用戶和我們一起取得了成功，并有案可查。

這三點沒有說到，就不是一個完整清晰的公司介紹，換句話說無論介紹時間長短和場合，都可以介紹完成這三點內容就是好的公司介紹。

建議公司介紹思路組織可以用以下順序組織：

1)公司業務面—2)產品體系—3)組織架構和服務體系—4)合作建議—5)成功案例—6)發展歷程和榮譽

對于公司業務面介紹可以設計一些具體問題，引發興趣；

對產品體系介紹要突出重點，強調完整解決方案，可以用案例說明我們在具體項目上給用戶成功的解決方案，包括自己的產品，也包括和別人產品的集成；

組織結構用圖說話，強調研發體系和服務體系的規范管理，可以列舉一些數字，例如我們軟件測試人員和開發人員比例關系，我們某些產品自動化測試覆蓋率，我們每年一個工程師服務工作日等等。

合作建議關鍵是要有針對性，不要泛泛而談，讓客戶感覺客戶經理只是在講套話。

成功案例一突出用戶多，二突出合作雙贏效益，三突出我們和用戶長期合作，共同發展的服務思路。

發展歷程介紹要快速精練，給人感覺蓬勃向上，富有朝氣，對于公司歷史榮譽重點顯示最新榮譽，其它一帶而過，可邀請客戶訪問公司網站，了解公司最新動態和文化。

6.6 如何對在公司考察客戶做介紹(連載四十四)

對來公司參觀考察型客戶介紹公司是有技巧的，一般這樣的客戶對公司基本情況都有所了解，而且都是公事公辦的正規介紹，來到公司，很多人又不清楚客戶的來路，別的不敢講，只好把公司情況又熱情介紹一遍，甚至接待人，主管領導輪番轟炸，客戶礙于情面，心理上其實已經反感了。

其實客戶到總部來了，反而要少談公司，少介紹產品(一般技術問題還有專門交流時間)，多看特色。一般客戶對軟件公司是很好奇的，又不生產物質產品，很難和其產品線比較，因此沒有什么考察經驗可以參照。要通過介紹讓用戶留下深刻印象并不容易。

我個人經驗這個時候介紹公司有三講：

第一是講故事，我們這個時候不要呆板的介紹公司，而是要講故事，例如我們談公司人數可以請用戶看老照片，結合老照片講公司創業艱辛到發展壯大歷程，邊講邊和客戶互動，看著老照片，聽著開目人創業的故事，客戶就容易從心理上喜歡這個樸實認真的公司了，而不是簡單被一個漂亮裝潢的大樓打動。

第二是講特色，特色主要指公司管理上特點，一般管理上特色是結合組織機構介紹進行的，要給用戶生動介紹我們的組織機構，我們可以和企業類比的方法，一般我講研發部就和用戶說這是我們的生產車間，請他們看源代碼管理工具，看安全保密條例，到測試組就和用戶說這是我們的質檢車間，請他們看軟件自動測試工具，這些是客戶很少見到，但見到后有很容易認可軟件公司規范可靠的細節，而且有新鮮感。

第三是講文化，我們給客戶在公司做介紹，不僅僅要介紹公司經歷和管理特色，還要通過這些內容突出我們公司積極向上，勤懇努力的文化。

在發展上獲得用戶認可，在管理上獲得用戶贊賞，在文化上和客戶形成共鳴，這就是在總部進行公司介紹的目的。

6.7 做好總部公司介紹的三個訣竅

根據公司的發展歷程和組織布局設計標準套路的介紹詞，保證每次介紹質量。

精心設計介紹流程和路線，讓用戶在每個部門都可以看到他們關注的內容，例如在實施部看項目管理體系，在研發部看規范代碼控制過程，在質控部看軟件質量保障體系，在營銷部看公司獲獎榮譽。

找一個熟悉公司的人員專門接待，熟能生巧，并定期請其匯報介紹工作改進意見。

6.8 公司總部接待考察客戶要注意的細節

準備熱情的歡迎牌，注意歡迎牌一定不要把幾個客戶單位并在一起，寧可多寫幾張紙；

如果總部不能抽煙，提前告訴用戶，請求理解；

一定盡量安排高管接待，以表重視，高管如果忙，可以事先說明，接待時間短一點；

和客戶交流時準備精美的宣傳資料，記錄交流問題的紙和筆；

請客戶參觀我們的獲獎陳列室；

安排一次體現當地特色的餐飲；

如果時間充足，安排到旅游點參觀；

臨走記得送用戶一些土特產禮品；

全程安排好用車計劃，不要出現用戶長時間等車的情況；

整體接待不要過于殷勤，要在用戶關心考察內容上下工夫，接待工作原則是得體大方親切，不犯低級錯誤。

7.1 培訓工作在項目實施中作用(上)(連載四十五)

7.1.1 培訓工作的目的

在IT管理軟件實施項目中，培訓是貫穿整個項目過程中，從一開始介入項目，就有培訓，在業務調研階段，我們可能要答復用戶一些概念性問題，在現場驗證推廣階段，可能我們要花費大量時間傳授軟件功能，在輔導上線階段，更是要隨時解答用戶疑難問題。

好的培訓可以讓用戶熟練掌握實施方法，自主推動項目，增強對項目認同感，可以大大減少軟件公司現場服務難度和時間，效益十分顯著。

作為一個IT項目經理，一個很現實的問題就是，很難一個人在一段時間內只負責有限個項目，越是商務能力強，單子越多的公司，這個問題越突出。

很多IT項目經理或實施人員不得不周旋于多個用戶，忙得焦頭爛額，疲于奔命，用戶并不領情，因為用戶覺得你對他不夠重視，服務質量并不高。

一個很有意思的情況就是，很多用戶強烈要求我們要保證項目的人力投入，要求派實施人員長駐現場，我們很多實施人員也的確長期在用戶現場蹲點，但事實上這樣效果好象也不明顯，很多項目推進依然并不順利。

要是一個人同時負責兩個在進行項目，蹲點必然是治一經損一經。往往因為不能經常性服務一個項目，導致一些小問題會積累成大問題，最后即使去現場推動成本也很高。

一個項目經理或實施人員，應該強迫自己考慮這么一個問題：一個人到底可不可以同時負責3~6個項目？到底有沒有辦法做到這一點？

如果一個人負責多個項目思路可行，而且服務質量還能被認可，大概在目前業內你才有可能獲得相對理想的收入，否則實施生涯就是一場痛苦混亂的經歷。

有的人說：當然可以，你給我配置3_{6個人，我就可以同時負責3}6個項目。

沒錯！這個思路實質上是說如果你在一個項目中有替代者，通過替代者幫你行使一些相對容易的工作，你就可以集中精力多做一些復雜的工作。這幾乎是唯一的辦法，至于形成一個團隊，三個蓋子五個杯，通過調度讓每個杯子都能蓋一會只是一種補救管理調度手段。

這種調度能力會隨著蓋子和杯子絕對數量增加而變得脆弱不堪。而且一個項目人員如果經過不具備穩定性，信息溝通失靈，信息不對稱現象將非常突出。

如果軟件公司不能給你配置或調度替代者的話，怎么辦？

答案就只有一個出路，在企業培養替代者。

如果我們充分重視用戶培訓工作，讓用戶也成為可以獨立實施我們軟件的人，不也就一樣達到了配置人員進行實施的目的？這樣就象我僅僅只需要給我的替代者一定時間指導，前期可能現場多一些，后期可能電話多一些，有了替代者，同樣可以達到管理項目的目的。

所以我個人經驗就是在項目中培訓工作的根本目的是讓用戶在很短時間內可以自己獨立實施項目，而不是僅僅會用某些操作。

如果僅僅是會用某些操作，當項目遇到大量困難的時候，用戶還是會找軟件公司，希望通過軟件公司的手推動很多事情，但是別忘了，當企業自己本身沒有或者找不到推動一件事情的動力的話，很難想象軟件公司有多大的作用。

不過有意思的就是，很多用戶高管非常贊同我的想法，培訓的目的就是讓企業可以自己推動信息化工作，不能總是依賴軟件公司某個人或軟件公司。

一個實施人員和用戶系統管理員的差別到底是什么？

我們強在軟件技術全面，而用戶系統管理員只需要知道和他們相關內容部分維護即可；

我們強在靠體系化方法推進項目，而用戶系統管理員更善于利用企業實際潛規則推進項目；

我們強在一些思路理念比較清晰，但用戶系統管理員更了解企業實際情況和業務特點。

所以如果我們能把我們的技術、方法、理念傳遞給用戶核心成員，或者是系統管理員的話，我們就可以在企業培養一個有效的替代者，這個替代者如果有足夠動力被激發，能發揮作用和能量可能比我們自己都要大。

讓用戶控制項目，我們提供軟件工具和智力幫助，這將是現階段中國IT服務的有效生存之路，如果服務可以收費，用戶且愿意外包，才可以主動替代用戶實施推進項目。

實施人員對培訓目的要有一個清楚的認識：幫別人就是幫自己。

要想少出差，就得讓用戶在現場能獨立工作。

實施工程師最好的選擇就是讓用戶可以自己實施常規功能，而且要灌輸一個重要理念軟件公司的工作只是保障項目所運行業務需要的產品功能完整可用，而不是幫助企業利用軟件做業務錄入數據，那是企業自己的事情，而且只有企業自己也可以獨立實施維護軟件了，軟件的實施才是真正成功和有保障。

7.2 培訓工作在項目實施中作用(中)(連載四十六)

7.2.1 用戶能不能培養成替代者？

有的人說，用戶怎么可能在很短時間內就具有獨立實施項目的能力？

第一用戶不象我們有專門時間學習和培訓，第二用戶不象我們有足夠動力和壓力。

我自己個人在項目實施中體會是不要低估用戶的智力和毅力，的確不是所有項目用戶都具有被培養的潛力，但在很多項目中，從來就不缺乏能夠培養成為一個好的實施者的用戶，而且這樣的人只要一個就足夠了，只是我們自己并沒有花時間去找到一個大家認可這樣的一個人而已。

用戶雖然沒有太多時間學習培訓，但衡量我們培訓工作的質量標準，就是看培訓有沒有做到在很短時間內將一個人快速培養成材，可獨擋一面。

我們很多培訓并沒有達到這個目的，那說明我們還需要在培訓工作上想辦法，動腦筋，而不是簡單將事情歸結為復雜，只會說一件事情復雜的人不如說自己無能更妥當一些。

更何況在單個項目上用戶對很多操作可以不必知道，學習工作量并不象完整培訓一個實施人員那么大。

第二用戶也有業務上壓力，項目上壓力，也有自我突破，學習新技術的動力，未必不愿意配合我們工作，何況我們只是找一些核心的用戶，有心的用戶進行高強度培訓，不是要求所有的人都有同等能力。

我們再看一看一個軟件公司新進人員在多長時間內必須獨立去現場工作？最多三個月。短短三個月為什么他就可以去現場工作呢？就是因為培訓。

另外再想一個問題，這三個月他一直在接受培訓嗎？顯然不是，好象只是簡單培訓了一段時間，可以入門了，然后就通過查閱資料和請教方式去自我成長。

其實學習軟件很少有靠人手把手教出來的，基本上高手都是摸出來的。而且在摸的過程中往往是在一段時間內高密度的研究一個軟件，直到明白。以后即使這個軟件功能上有什么擴展和發展，學習成本將非常低。

在最短的時間內做最大量的事情，這就是成功將用戶培養成替代者的秘訣。

成功的培訓周期一定不長，一定是在最短時間內不斷反復強化某些業務環節操作，形成習慣。

不要指望用戶自己會自動自發地在一段時間后掌握操作，而是在一段時間內大量練習，強化掌握后再逐步琢磨如何應用，逐步熟練后達到一個很高的境界。

很多用戶并不缺乏IT知識，只是不太清楚具體軟件操作和對框架的理解，由于熟悉業務，對軟件和業務工作結合點價值點的認識和理解可能比我們自己還要強。

對這樣的用戶，換句話說我們已經弄懂的東西傳授給用戶恐怕并不需要三個月。我們一個項目實施周期短的話也要半年，長的話要兩三年，這么長的一個周期內，居然一個實施人員安排不出來時間給用戶培訓，而且培訓到可以達到獨立實施的能力。

這種現場自我反省，更多的是我們在工作意識上，工作方法，甚至我們自己對軟件理解操作熟練程度上有欠缺，所以導致我們軟件能力無法傳遞給用戶，也得不到認可。

就我本人實施工作實際體會，無論是國營企業還是民營企業，無論是大企業還是小企業，絕大部分都可以培養用戶實施者。的確有的企業做這件事情難度大些，成本高些。

但無論怎么樣，我們有無極強烈意識在企業建立一個項目團隊，讓項目團隊得到資源保障，讓項目團隊關鍵人員推動項目實施，一旦發現項目中這種情況和局面不存在，就想千方百計去做到這一點？

這就是我們能否培養替代者的關鍵意識。你認為可以，可行，你就會去做。

7.3 培訓工作在項目實施中作用(下)(連載四十七)

7.3.1 培訓工作為什么質量不高？

坦率的說，我們現在整個行業培訓工作質量是不高的，至少是參絲不齊的。我個人認為主要原因有四：

第一缺少高質量的按業務組織的培訓教材。

很多軟件公司，特別是管理軟件公司并沒有一套完整的結合業務的培訓教程，更多的是功能手冊和配置手冊，這樣的內容很難理解，更不能傳授能力。

很多對軟件有興趣的人并不需要太多時間指導，但一定要給他很容易上手的教程。所以國內很多人都可以自學復雜的CAD軟件或三維設計軟件，坦率的說這些軟件操作比任何一個管理系統還要復雜，但很多人就是可以自學，和教材豐富有關。

第二培訓者的能力缺少驗證。

我們很多軟件實施工程師強在技術能力，弱在業務理解力和表達能力，到對得上一句俗語，茶壺煮餃子，有貨倒不出。對于技術型人員主動培訓用戶在心理上也是一種挑戰。

可能有的人是心里明白，就是說不清楚，讓人看著著急。

心里明白，表達能力不足還好，更糟糕的是很多人心里也不明白，或者是半瓶醋，在那里裝明白，典型的小黑蒙大黑，最后用戶說天下烏鴉一般黑。

在標準業務教程沒有到位的情況下，要對培訓者培訓工作進行主動考核和管理，才能保證培訓質量。

其實辦法很簡單，學校招老師是如何進行的？試講！如果你還沒有準備好手冊，并不等于不可以傳授知識，那么就請你講內部公開課，沒有達到清晰明白講清楚軟件功能和業務的人員首先自己加強培訓。

第三不重視培訓工作。

很多實施人員總覺得培訓很多細節給用戶很麻煩，我把所有配置都調整到位，系統到了一個可用的狀態，然后你要掌握的操作就是那么幾步，我把這些都教給你，不就完了？然后我再提供一個業務手冊，你參考看看，不就行了？干嗎要花費大量時間和精力在現場培訓，又不是沒有事情做？

甚至有的人可能還在想，軟件還有問題，我精力應該放在解決問題上，而不是培訓。

結果無論人在現場不在現場，大量時間都是一個人在忙碌的配置調試，然后請用戶檢查驗證。然后好早點走人，去下一個現場解決問題。

欲速而不達，這樣的項目越是到了大規模推廣時實施人員越頭痛，根本不能走開，一走開就出問題，大量的出問題，別的項目要是同時推廣，實施人員的行程幾乎就是難以兼顧，自己就不要做任何休息了。

是否重視軟件培訓，千方百計想辦法讓用戶會用，好用，愛用軟件，是一個好的實施人員的價值。

第四忽視軟能力培訓。

很多軟件培訓工作，特別是管理軟件培訓工作不僅要培訓功能，還要傳授實施方法。

要告訴用戶遇到問題如何分析，是需求還是缺陷？分別如何處理？

要告訴用戶如何判斷實施阻力，軟件實施到哪一步可能會有什么困難，如何化解？

要告訴用戶你應該如何培訓其它的同事，如何將能力傳遞擴大？

如何界定一個項目邊界和近期目標，并逐步實現，所有實施人員都應具備的軟能力，這都是要傳授給用戶的，這樣用戶才可以真正起到一個管理控制者的作用，這樣的用戶才能獨擋一面，也會通過項目實施得到在企業內部的肯定和認可，也就有實施的動力。

7.4 培訓工作應如何組織？(連載四十八)

要準備一次成功的培訓，要考慮一下幾個工作，首先是培訓內容策劃，然后培訓計劃編制和確認，然后是具體培訓組織工作，最后是培訓考核和反饋。

7.4.1 培訓內容策劃

培訓前要根據不同培訓對象，不同培訓內容，不同培訓階段，不同培訓師資進行內容策劃。

要針對用戶層次，實施階段設計培訓主要內容。

想好每個階段目標用戶應掌握的內容，作為自己實施目標中一部分，并通過相關培訓活動達到。

一般培訓內容可分為：

業務調研培訓，重點在告訴用戶我們工作方法和相互溝通配合方式；

解決方案培訓，重點在告訴用戶我們軟件業務模型和整體實現思路；

功能驗證培訓，重點讓項目組或系統管理員掌握軟件基本操作，進行功能驗證；

輔導上線培訓，重點在讓一般用戶掌握相關部分業務操作，讓系統管理員可以掌握常見配置和維護工作。

培訓策劃還包括選擇培訓對象，不是企業每個用戶你都要培訓的，而是選擇一個或幾個重點用戶培訓，確定其掌握基本能力，然后輔導重點用戶培訓別的用戶，逐步擴大影響。

如果企業比較大，還需要策劃分幾批培訓，分別培訓什么內容。

培訓策劃還包括如果將培訓工作成果匯報給企業，并形成共識。

而且一旦有重點用戶可以在實施人員輔導下獨立培養別的用戶操作了，或者進行了大面積普及操作培訓并達到目的，要立即給企業領導匯報，除了匯報成績確定項目進入一個新的里程碑外，匯報一方面要求企業主管領導表揚這樣的用戶，保護其積極性，一方面也要企業領導知道，我們是真的來做好項目，所以我們不但提供軟件，還在真正為企業培養自己的信息化實施人才，別忘了這是很多項目招標時的要求。

這里面通過匯報也對企業領導進行了培訓，灌輸了我們是工具，我們是智力支援者，不是實施主體的理念，如果軟件有問題，我們來解決，如果軟件沒有問題，企業要自己用軟件功能在我們指導下主動解決問題。

而且讓領導知道了如果遇到問題可以請企業自己中誰負責解決，實際上也幫重點用戶提高了在領導面前的曝光率，肯定有好處。

培訓策劃還要考慮培訓的地點和成本，包括人力成本和時間成本，一定要合理安排，高效緊湊。

7.4.2 培訓計劃

培訓策劃的階段成果是培訓計劃，培訓前要將培訓計劃制定好并通知到最終參加培訓的用戶，這是很重要的工作。

培訓計劃應該先在內部經過大家確認，落實資源后才能提交用戶。

一份完整的培訓計劃要確定培訓目標，詳細分解培訓時間、培訓內容、培訓師資，說明培訓地點、簽到方式和考核方式，讓用戶提前做到心中有數，方便準備。

7.4.3 培訓組織

培訓計劃編制前要和相關培訓資源進行溝通，確認是否可按時間進行培訓工作，同時要檢查培訓場地是否足夠，是否有足夠資源上機練習，是否有其它必要設備，等這一切就位后還要和用戶確認最終培訓人數，時間安排和其它相關可能工作。

如果用戶是到軟件公司培訓，還要落實用戶的餐飲安排，住宿安排，接送安排，參觀安排，訂票安排，禮品安排，并列計劃報公司批準認可后執行，這些都是一次成功培訓組織中要考慮的工作。

培訓組織要特別重視培訓環境的質量，高質量的培訓環境應提前準備好相關軟件環境，并調試通過，不要等用戶開始上機才進行安裝。

培訓組織中最重要的工作是完成培訓教材的編制，并提交審核或主動安排審核。

審核培訓教材的方法有兩點，一是確認教材思路是否清晰，細節是否完整，二是看培訓者講解是否易懂，和教材一致。其中對講解能力的驗證要更強于教材的驗證，沒有教材一樣能做好培訓，沒有好的輔導講解能力，很難做好培訓。

基本上很多公司對這個工作是忽視的，也是沒有人負責的，這是一個很大的問題，這種事情驗證成本并不高，因為可以采用認證資格的方式進行，一個好的培訓人員，對其培訓能力的驗證在一段時間內只需要驗證一次就行，而這個能力至少可以在一年內發揮巨大的作用。

本人親自檢查過很多對軟件的講解，說個不中聽的話，這樣的培訓能讓用戶明白我們是干什么的都難，別說讓他跟著你走，按共同的意圖推進項目。

此外培訓教材中數據錄入規范也是培訓重點內容，這個講解倒不難，實施人員要結合企業實際精心準備是關鍵。

數據錄入規范準備要點有三條：

1、 習慣填寫方式說明及樣例

2、 正確填寫約定及樣例

3、 常見問題處理方法

7.4.4 培訓考核和反饋

培訓效果如何要從兩個方面去驗證，一是對用戶掌握程度的了解，這就要通過培訓考核去完成。

一方面要了解我們培訓的質量，這就要通過培訓學員的反饋來了解。

任何集中完整培訓工作都要提前結合企業實際業務準備適當難度培訓考題，這也是培訓審查工作內容之一。

培訓成績原則上要反饋給個人和企業相關組織單位，這樣才能形成一個反饋激勵機制，我們可以采用“優秀鼓勵，落后不提，以先進示范帶動整體提高”的策略促進培訓深入開展。

第二培訓完成后，要請學員填寫培訓效果反饋表，這樣對培訓老師形成一個反約束，為了讓培訓學員有一個好的效果反饋，就不得不精心準備培訓工作，而不是敷衍了事。

考慮到實現成本和實際能力及企業情況，考核和效果反饋表可能不太容易操作，但從長遠來看，有沒有培訓考核和反饋的培訓工作質量一般是兩個檔次以上的差距，這也是一個客觀規律。

培訓效果反饋表要提交給培訓老師和公司相關培訓管理部門，由其安排進行培訓改進工作。

7.4.5 好的培訓行為習慣

隨時隨地隨人隨事的培訓

培訓的工作并非一定要專門的時間專門的地點進行，實施人員要利用一切機會用各種易于接受的方式將思路、操作或配置傳遞給用戶，并隨時從用戶處獲得反饋，改進內容。

在培訓中互相學習

培訓過程一方面注意傳授內容給用戶，也要抓住一切機會向用戶學習業務知識，業務知識越多，今后培訓準備也就越到位，培訓內容也就越生動。

隨時記錄培訓中發現的問題

培訓過程中會經常出現一些用戶提出的問題，很多都是很好的改進建議，要立即記錄，并反饋給公司對軟件進行持續改進。

7.5 培訓注意事項(連載四十九)

一定要事先準備好業務手冊或者培訓教材，沒有教材的培訓工作質量無法保障；

培訓過程中比較好的講解思路是：

先講業務后講思路

先講思路后講操作

先講操作后講配置

先講配置后講維護

培訓過程中如果沒有投影可以充分利用各種工具軟件實現同步教學，例如“NETMEETING”工具實現多臺電腦同步放映。

上機輔導一定要有人陪同，主動答疑。

培訓操作要先手把手操作示范一次，示范后立即要求用戶練習幾次，確定用戶掌握后才能結束一次培訓輔導。

在培訓中要及時大膽誠懇鼓勵用戶的每一個進步，在培訓過程中完成軟件思路和管理理念灌輸和培訓方法的灌輸。

傳授用戶如何記錄軟件缺陷和分析缺陷的方法，讓用戶可以按照要求提供此類數據，減少自己為了一個小問題去現場的概率。

傳授用戶用各種遠程協助工具進行軟件輔導的方法，讓用戶適應在線輔導，減少出差成本。

7.6 總部培訓

7.6.1 為什么要考慮到總部安排培訓？

有的時候現場培訓用戶經常受工作干擾，無法連貫進行培訓活動，有的時候用戶主動希望到軟件公司進行培訓，總部培訓也是培訓策劃中一個內容，是安排到總部培訓還是在現場培訓，是要根據用戶重要程度和效益來評估的。

對于一些大型項目，特別是用戶執行力不夠，現場培訓效果不佳的項目，安排一次緊湊合理的總部培訓會收到很好的效果。比起在現場反復培訓，每次培訓效果都不到位，一次緊張有序的總部培訓往往成本更低。

而且在軟件公司培訓用戶換了環境，可以協調更多人和用戶交流，用戶此時更容易接受我們的管理思路，并達成一致，有利于后續工作推進。

在總部培訓還可以和商務進行協同，搞好接待工作，有利于建立個人交情，用戶也愿意在后續工作中配合我們開展工作，了解我們工作流程，按照我們制度配合，而不是簡單埋怨責怪。

所以總部培訓是很好的一個培訓組織方式。

7.6.2 總部培訓經驗

很多用戶要求到總部培訓，實施人員或者客戶經理只給公司一個通知，人就送過來了，用戶到總部培訓，至少要做好三個準備工作：

和公司培訓負責人事先排好計劃，溝通資源，確保到位

和客戶經理一起安排好接待工作，盡管很多用戶我們不負責住宿餐飲游玩，但從中國實際情況出發，在成本接受范圍內，適當安排一些招待游玩，根據用戶報銷水平落實好用戶賓館和訂票，這些細節會極大提高用戶對我們認可程度。

確保培訓工作有實施項目組成員參加，總部培訓一個重要目的不是簡單讓用戶掌握操作，而是讓用戶變成項目主體實施者，也就是自己人，所以無論是現場培訓還是總部培訓，項目組一定要有人和用戶泡在一起，只要用戶還沒有走，就必須時刻有人輔導和培訓。

我們有的項目培訓實施人員沒有親自參與，或者晚上用戶上機練習，自己因為遠就先回家，都是因小失大，你如何對待別人，將來在項目中用戶也是如何對待你。

總部培訓結束后，一定要做好培訓備忘錄，讓用戶回去對其公司負責人有個明確交代，至少要說明我們的工作質量是沒有問題的。

8.1 現場推廣工作可進行條件？(連載五十)

如何通過現場推廣讓用戶項目快速上線，是很多實施工程時關注的問題。如果一個項目非常簡單，和以往工程基本類似，那么輔導上線就非常輕松，根據企業業務和產品特點做好業務手冊和應用規范，直接安裝調試，驗證無誤就可以大面積推廣，實施周期可以大大縮短。但對于很多大型項目，有很多不確定性或個性的內容，要進入現場推廣階段需要做很艱苦的工作。

在一個項目實施過程中，如果要想讓現場推廣工作快速有效進行，其實是需要做大量高質量的前期工作，現場輔導系統上線應用不過是一個很自然的結果。

現場推廣工作可以進行在具備四個條件情況將非常順利：

1) 經過充分現場功能驗證，確定產品功能基本能連串起一個或幾個基本業務流，并得到用戶項目組書面認可；

2) 產品的穩定性和性能在可預見并發環境下性能能達到可使用要求；

3) 針對基本業務流的業務操作手冊全部編制完成，并對相關用戶完成培訓；

4) 用戶和軟件公司都可以投入一定資源，主要是用戶方有可獨立推廣資源。

軟件功能能不能支撐一個業務是進行現場推廣的最必要條件，很多人為了項目交差或者應付用戶，匆忙裝機、配置和輔導，最終用戶發現用起來不是很順利，經常出現BUG，或者對業務支持并不能達到要求，對軟件就失去信心，再來推廣，阻力就大，非常困難。

功能可以支持的情況產品穩定性和性能也很重要，如果產品穩定性和性能不足，項目往往也容易陷入停滯。

至于業務手冊和用戶推廣資源也是順利進行現場推廣的必要條件。

實際項目實施過程中，往往是這些條件都不能滿足的情況必須進行現場推廣，否則無法將項目推進到一個階段，得到用戶認可，以便驗收回款，但實際上效果并不見得容易達到。

我個人體會現場推廣順利不順利，其實不在現場時間長短，而是你為現場推廣準備工作細致程度關聯性更強。要想出差少也能控制項目，就必須尋求合理的項目控制策略。

8.2 現場推廣工作為什么進展慢？

很多項目在快速完成業務調研和基本配置之后，就好象進入了一個平淡期，業務已經似乎清楚了，配置也按要求完成了，但用戶好象就是沒有什么用，大部分人也沒有積極性，項目進入了一個僵持期，為了推動項目企業項目組或信息化負責人不斷催促我們實施人員進入現場，推動項目。

而我們的實施人員也非常努力地在現場推動，推動，再推動，直到推不動，項目成為一個胡子工程或者是拉面工程。

項目現場推廣時間無限延長對用戶，對軟件商，對實施人員都是一種極大的傷害和折磨，我們認為項目推廣時間無法確定或者確定后無法結束恰恰是一個項目失控的癥狀。

泡現場其實是典型的項目失控特征之一。

我們可以分析為什么經常出現用戶要求實施人員來泡現場？

從實施的角度來看，無非是以下幾種原因或原因的綜合。

8.2.1 軟件總是出問題

很多項目從一開始到現場推廣是一段痛苦的經歷，在推廣過程中簡直就是軟件捉蟲記。不斷往前進一步，不斷發現新的嚴重影響使用的BUG，導致項目停滯，去解決BUG，往往要耗費大量時間，然后再費盡力氣再進一步，再發現BUG，再暫停，再去解決BUG，如此形成一個惡性循環，項目走走停停，周期不斷延長，用戶失去信心，而且覺得我們工作質量太低，慢慢不相信我們，對我們充滿抱怨。

軟件存在問題是客觀的，沒有不存在BUG的軟件，無非是多少嚴重程度的問題。這應該是一個理智實施人員開始工作的限定條件：用可能存在BUG的系統解決問題。

但是我們往往犯的一個錯誤，人總是有意識無意識假定軟件就應該是沒有問題的。無論是用戶還是實施人員都有這樣的心態。

如果軟件總是存在BUG，規劃在干什么？開發在干什么？測試在干什么？那么多管理流程和制度為什么不能保障？在我們的宣傳往往又是穩定可靠的情況下很多人對這些事情就有了一種反感和抵觸的情緒，進而認為自己現場工作不順利，都是公司的錯，都是軟件的問題，我是無能為力的，出現這樣的心態才是最大的問題。

其實我們現在已經明確了，軟件發現BUG是肯定，這是我們可以預見的項目風險。我們作為一個實際項目控制者，必須采取主動的項目控制對策，才能有效管理項目。

這個時候最有效的方法就是加強對軟件的驗證，根據自己項目業務過程，不斷測試，發現是否存在嚴重問題，并采取相應的對策解決。

如果不是嚴重問題，可以先尋求替代方案(尋求替代方案可以是群策群力的過程)，不影響項目實施進度，然后讓公司規劃部門將其納入可接受的版本規劃時間，如果公司響應能力不足，我們將要把其作為項目風險提前和用戶溝通，尋求支持和理解。

如果存在嚴重問題，肯定影響項目進展，就應該全力在公司推動解決BUG，然后再去現場更合適。

否則到了現場問題響應不及時，被用戶指責之下非常容易被動，失去對項目的控制權。這個時候實施人員要么只好無原則承諾我們開發會解決來轉移自己的壓力，然后讓公司承擔大量開發響應申請，要么只好表示我們一定來解決問題，大量時間在現場推動一些無關重要的細節。

真正明智的實施人員一定會自覺花費大量時間做業務流驗證，確保項目功能可用夠用，能夠支撐一個或幾個完整業務流，沒有重大程序隱患才會去現場推廣。

在軟件某些業務存在極大問題的時候項目團隊不應該去現場，而是推動這些問題解決完成才能去現場，去現場時間多少不會成為用戶是否認同我們的標準，去了能否解決問題才是用戶是否認同我們的最后標準。

可以少去不去，但是每次去之前一定很清楚自己能解決什么問題，哪怕是很小的一個問題，解決問題完成培訓，落實用戶自我計劃就可以回來。

如果軟件發現還有問題卻一定要去現場，前提就是你還有其它可選擇的業務方案或管理行為要去解決，這些問題可以和發現的問題獨立存在，無關緊要。

有的實施人員可能抱怨，為什么一定要我在公司推動這些事情，其實這倒未必，一個好的實施人員發現一個項目存在問題，可以及時反應到公司，通過軟件配置管理和開發流程解決，但一定要按照配置管理要求把項目情況反映到位，如果反映不清楚才需要到公司協助，多出來的時間就可以多響應一些項目，這樣一個實施人員同時響應兩到三個項目是很容易做到的。

8.2.2 要推廣的業務流不完整(連載五十一)

很多項目也做了一些驗證工作，到了現場隨著業務的展開，還是不斷發現BUG。這就說明我們并沒有建立一套可獨立推廣的完整的業務流，只能說在項目實施過程中我們只就部分業務流進行了驗證，到了現場才發現實際業務情況并非如此，因而又陷入困局。

而能否拿出完整的可操作業務流推廣方案是項目調研質量緊密結合在一起的，項目調研完成后，一定要可以拿出完整實現的業務流實施思路和方案，這也是自我評判實施調研工作是否完成的一個尺度。如果調研完成了，只有一堆細節信息，卻沒有完整的業務流框架，這個調研對實施而言就不能算成功，這個階段工作也就不能算結束，還要花時間搞清楚為止。

但我們在調研過程中未必一定要搞清楚所有業務流和實現方案才能往下走，我們可以先解決完一個業務環節再往下走，把企業復雜的業務流程化整為零，形成相對完整的部分，用一個清晰效益目標牽引或做為愿景，促成企業一個業務流程一個業務流程不斷前進。

但對于單個業務流程而言，配置一定要完整，一定可以看到用這個系統把企業實際中哪一件事情真正走完了，然后還比較方便，甚至是前期不方便，但可以完整實現。

如果實施不能得到這樣的幾個業務流方案，并反復站在用戶的角度推想可能存在哪些問題，驗證的質量就不會高，也不可能在現場順利推廣。

如果每個項目都能做成一個完整業務流，只要有10個成功的項目，軟件在很多方面就會達到非常優化好用的狀態，再進行推廣經驗的移植效益將極大發揮。

8.2.3 和用戶就推廣實施方案沒有達成一致

有的時候，實施工程師也拿出來一些業務實施方案，但一進入推廣，用戶并不認可，要求按自己的思路來，這樣經常是邊推廣，邊爭論，然后不斷調整推廣目標，下面的人就等待觀望，我們不得不調整部署，重新開始實施過程，甚至是軟件配置和功能驗證過程。

這樣看來有清晰的業務實施方案也未必就能順利推廣，業務推廣還必須和用戶項目組達成一致意見。要和用戶達成一致，并非是某個業務可用不可用，而是我們是否可以找準用戶也可以認可的價值點。

舉一個例子，我們很多項目要求用戶入庫數據，以方便今后圖檔的管理和查詢。很多用戶一實施就不認同，反而要我們上工作流或項目管理。這樣就項目推廣目標沒有達成一致，結果就容易反復，反復后用戶可能發現沒有基礎數據工作流和項目管理也跑不好，最后還是搞基礎數據錄入，但一上一下的折騰過程中，大部分用戶可能已經不看好項目實施。

為了讓用戶認可推廣目標對應的業務流，我們往往要想好關于業務價值的說辭，這個說辭推導要有力，而且有數據事實證明，而且有可清晰看到的價值，這樣的業務才可能有人跟著走。

換句話說，你想讓別人做什么事情，一定要有一個可以看得到或者想象得到的效益可期待，否則業務推廣目標很難達成一致，即使用戶同意按你的思路去做，最終也一定反悔。

就以我們說圖紙是否可以方便查詢是很重要價值點為例，如果僅僅強調這一點用戶開始可能還不覺得，一旦錄入數據開始就覺得怎么信息化盡是干苦力活？積極性很快就會演變成阻力。

所以要推廣自己的業務流一定要和用戶項目組就推廣目標達成一致，達成一致才能快速推廣。

事實上我們要先和用戶分析如果圖紙不好找有什么后果？能舉幾個真實的事例嗎？如果好找真的有效益嗎？為了這些效益值得我們投入這么大成本去做嗎？如果遇到阻力領導會支持我們嗎？

這些效益和目標經過反復設身處地的換位思考，和用戶項目組達成一致了，才能成為項目推廣順利進行創造條件。

目標明確了只能說是大方向的事情落實了，和用戶項目組要達成一致的事情還包括具體的策略，如何做才能保障這個目標實現？這個思路也要達成一致。

還以圖檔管理為例子，原來的圖紙不好找，需要解決，這個目標認同了，不等于事情可以啟動了，還要和用戶組就如何管理的方案達成一致。

那么在系統如何管理圖紙呢？我們可以以產品結構建立樹狀視圖，我們可以根據各種特征建立分類視圖，我們可以根據階段建立項目階段輸入輸出視圖，我們可以根據文件類型建立關聯視圖等等，這些思路也要先和用戶項目組達成一致，讓他們覺得這些思路和方案不但能夠解決問題，而且以往管理上的一些優點也可以被繼承，這樣的方案才比較有推動力。

管理的思路明確了，如何去做也要考慮清楚，而不是走一步看一步。

我們是安排專人錄入數據，大家去利用，還是安排每個人都錄入一些數據，逐步積累，我們是從新產品開始積累，還是把老產品數據也立即錄入系統，我們每個人每天可分配工作時間大概是多少，這個時間段經過培訓可以錄入的數據量是多少，這樣按一周數據錄入量計算全部圖紙錄入完成大概需要多長時間，能否在系統實施可接受周期內，如何保障每個人的數據錄入時間，如何組織培訓，確保每個人都可以掌握操作。

這些工作細節都需要溝通確認，而且計劃分解得越詳細，執行力越強。因為所有最復雜的事情都變成了很簡單很小的獨立工作，每個工作完成需要的技能都很單純、時間很小，在落實時阻力就小。

如果思路得到確認，我們就可以和用戶項目組一起建立一個計劃，落實我們的設想，再發動大家按計劃運行。

一旦計劃確定，要立即行動，我們應按計劃高質量完成工作，然后就是催促用戶項目組按照計劃完成他們的任務，并提供技術支持，這個階段我們要明確技術支持階段我們就不需要大面積現場工作，除非有系統不能解決的問題

如果用戶按計劃在執行，我們還需要不斷主動了解進度，形成一種進度反饋，根據進度快慢采取適當措施保障項目目標在實施周期內實現。

實際上通過和用戶就實施方案達成一致，我們也就傳授了一個很重要的項目管理套路：認同目標，明確策略，建立計劃，立即行動，不斷反饋。可以說任何事情只要這樣做，就很難失敗。

8.2.4 沒有激發用戶的主動性(連載五十二)

一般情況下現場推廣很多用戶認為主要是靠軟件公司來落實，的確在很多企業由于體制觀念的原因，在這些方面需要軟件公司多做很多工作。

但實際上一個項目大量依賴軟件公司人員推動，這個項目失敗概率會比較高，越是成功的項目，用戶主動性越強，用戶才應該是項目實施的主體。用戶自己的項目不是用戶自己實施，卻要依賴我們實施，這樣的項目我們如何成功？

我們之所以推廣失敗往往是我們把自己思路給用戶一描述，甚至沒有什么描述，就悶頭大干，用戶不知道如何參與我們工作，只好去監督我們，成為項目的監工，而他們又不清楚系統的思路和實施套路，只能按照領導意圖來給我們施加壓力，而不是和軟件公司一起分擔壓力，這樣進行的項目自然難以受控。所以我們這樣做的都是事倍功半的工作。

把用戶，至少是用戶項目組變成可實施的力量，并幫助他們推廣實施項目，而不是依賴個人力量推動實施，把他們由項目監工變成項目執行者，我們成為監工和顧問，這樣的實施才輕松有趣。

讓用戶真正參與項目實施工作，雖然用戶累一些，但大家有了團隊的感覺，心情反而更愉快，說個套話：往往在這個階段和用戶建立了戰斗的情誼，為今后驗收回款參觀都奠定了牢固的基礎。

所以我們在項目推廣方案中要反復強調和貫徹這一思路，并得到用戶認可，在實際工作中落實，而且用戶掌握的技能要清晰寫進備忘錄，這樣就可以請他們中具有相關技能的人去解決問題。

例如軟件安裝，我們可以和用戶約定，我只示范裝3臺，然后安排用戶方面的人裝3臺，我們在旁邊看，如果連續三次都成功，我們認為基本上問題不大，其它的都可以交給用戶處理，我們只需要處理意外問題。

又例如進行某個業務操作培訓，我們先要經過講解示范，確定用戶項目組明白，立即請用戶項目組操作，確定他們掌握了操作，那么后面的培訓可以主動邀請用戶項目組成員講解，我們提供技術咨詢，今后培訓工作策劃組織都可以逐步傳授給用戶項目成員負責，最后一般問題基本不需要我們出馬，大面積基層用戶都習慣和自己人交流解決問題，我們只負責解決軟件的疑難雜癥，而且某個業務被大部分人熟練掌握后，我們的工作主要就是新的業務流推廣方案驗證設計規劃，還有保障項目進度的相關管理活動。

這樣一輪輪循環，就可以讓用戶項目組慢慢成為實施的主體，而且在這個過程中用戶項目組成員可以得到極大能力成長和進步，他們也會感謝我們的幫助。

一到現場工作，任何時候都要確定這個游戲規則：

實施推廣以項目組為主，我們負責技術支持，負責推廣實施能力的傳幫帶；

一旦實施能力轉移了，我們并不需要經常來現場工作，因為我們來現場工作成本極高；

一般情況下我們只需要在現場解決問題，培訓技能，達成后續工作計劃，完成本次業務目標就必須返回。

我們不能解決問題的時候，我們會全力促成問題解決，一旦解決我們第一時間安排現場響應，但如果我們解決不及時不順利我們會第一時間通報，也請用戶理解支持。

不過坦率的說，很多實施工程師本身也不知道如何做這件事情，思路也是亂的，也不會做計劃，這樣的話去激發用戶就缺少個人魅力和行動能力，就只好親力親為，被動響應，這個時候為自己能力不足付出代價也是沒有辦法的事情。

8.2.5 光打雷不下雨，缺少高管支持

很多時候僅僅和用戶項目組達成一致意見還不夠，還要和用戶高管達成一致。否則在項目遇到阻力的時候，得不到更多資源響應。

達成一致的實施方案要給用戶高管匯報，匯報要點不在軟件功能實現和配置細節，而在于目標是否認同，資源投入計劃是否可行，可能會有哪些風險，采取了哪些措施保障，如果出現一些項目阻力，需要提前得到領導哪些授權或政策支持。

特別是要向領導匯報取得認同的工作就是，將和信息化相關的基礎工作(例如數據錄入，業務執行)變成有制度保證的崗位要求和流程要求，這樣信息化工作推進才有制度保障。

取得高管支持最有效手段是建立和高管的匯報機制，這樣才能夠讓高管清楚知道項目進展和需要給予的支持，項目組成員也會因為可以經常得到高管授權和肯定而努力推動項目。

給高管匯報要注意的是，每次匯報應該準備一些積極的內容，值得肯定的內容，的確有進步的內容為好，否則僅僅是訴苦匯報，是不用指望高管對一個無能的團隊給予更多的支持的。

8.2.6 邊界總在變更(連載五十三)

有的項目實施過程中，用戶不斷提出一些新的要求，希望我們能夠給予解決。

這個時候我們有的實施人員頂不住用戶的壓力，被迫承諾答應解決，結果就導致項目的邊界總在變更，項目目標在一次次變更中不斷變形偏離游離，最終模糊不清，項目也就陷入不斷開發，不斷提出新問題的循環之中。

用戶提出需求要進行分析，一般用戶需求有三種情況：

第一種的確是軟件規劃沒有合理解決的問題，而且無法繞過去，或者繞過去對用戶項目就沒有什么合理的價值了。

這類需求在業務調研階段就要主動思考和確認，在功能內部驗證配置業務流時就要發現，并向公司反饋，強力推動解決，不要等到現場推廣時讓用戶去發現，然后再去改，這樣可能浪費了好幾個月寶貴的時間。

第二種是軟件易用性和穩定性或者性能方面的問題，但的確有替代方案或者暫時可以接受。

對于這些需求我們應該給予解決，但要和用戶解釋這些需求必須納入統一版本規劃實現，不可能今天提出要求，明天就改好，這樣開發管理快是快，但長遠可維護性一定很差，所以在功能驗證階段要主動和用戶項目組提出項目推廣過程中哪些功能可能會產生問題，需要大家提前做好溝通工作和說辭，一旦出現應用者不滿意的情況，我們還可以想辦法提前打預防針，心里有數的處理疑問，不至于被動響應，甚至自己都沒有發現用戶提出的缺陷或者種種問題。

如果處理得好，在一個長周期項目內(例如半年或者一年)，如果能夠提前識別這些需求，納入規劃開發響應，那么最終項目驗收的時候這些問題也就比較順利地得到解決。

第三種是用戶應用后產生一些新的業務思想，希望也通過計算機加以解決，這些業務需求可能包含很有預見的需求，也可能是靈光一現，也可能是將其它系統需求要求我們系統也加以實現。

這類需求對內我們可以反饋給公司相關規劃人員去合理討論，但堅決不能給用戶任何承諾，超出合同邊界的需求在一個項目中是絕對不可以輕易響應的，否則開個一個口子，就無法拒絕用戶各種合理不合理，但都不在本項目邊界內的需求，項目也就越做越長，無法收場。

這種需求最簡單的方法是以合同為準，按合同辦事。

比較好的處理流程如下：

a) 先要詳細搞清楚用戶業務需求到底是什么，核心要解決的問題是什么？很多用戶表達的問題和要解決的手段往往是分離的，我們不要把解決問題的手段和問題混淆在一起，另外有時候要解決的問題是因為另一個問題不方便造成的，要先分析清楚；

b) 和用戶項目組溝通協調，確定問題的確存在，且需要解決，且能確定解決的需求；

c) 和項目經理溝通，判斷該問題是否在方案價值點覆蓋范圍內，而且影響主導業務正常運行，如果是提交需求建議和缺陷報告給公司規劃評審；如果不是先要和用戶溝通，看其是否愿意作為后續合作內容，或者另外追加費用解決，不和本項目目標混淆在一起；

d) 如果用戶堅持要開發，要及時向公司匯報，并堅決執行公司意志。

8.2.7 做人不好

有的項目存在嚴重人員溝通問題，用戶對我們不放心，寧可把我們關在現場不回來，生怕我們走了不再來了。

這種原因就是實施人員沒有建立足夠誠信，往往是一個階段工作沒有做完，沒有確定到應完成的里程碑點，就不得不做其它工作，甚至就是不夠認真負責，敷衍了事。

用戶聽信實施人員下次來解決問題的承諾回家，結果實施人員在多個項目現場奔波中并沒有投入精力解決軟件問題，或者促進公司解決問題，下次不得不被迫過來又沒有真正解決問題，用戶并不滿意。

有的時候調度周轉不靈，版本發布推遲，用戶不能看到我們按計劃兌現承諾，也會不相信我們的工作，采取要求派人現場長期遵點解決的要求。

其實如果問題不能解決，遵點是沒有用的，如果問題能夠解決，往往是雙方溝通協調后在軟件公司先解決然后再到現場解決的，軟件公司資源一般都很緊張，將人壓在現場，幾乎讓自己問題陷入無人催動的境地。

所以我們一定要做好最壞的打算，和用戶慎重承諾，說到做到，有問題全力保障問題及時解決，給用戶兩個印象，第一我們很認真守信，第二我們時間珍貴，我們每次只能解決關鍵問題，實施還是靠用戶自己解決。

8.3 現場推廣工作如何才能做好？(連載五十四)

作好現場推廣工作關鍵在于前期各項工作質量。

8.3.1 第一要組織高質量的業務調研

業務調研階段在產品比較熟悉的情況下，可以邊調研邊建立原型測試，這樣在現場調研時對可推廣業務設計和驗證，構思業務流程操作手冊，數據規范手冊和各種樣例，到了真正推廣的時候思路早就經過反復推敲，非常可靠；

8.3.2 第二要對關鍵用戶組織成功的培訓

培訓就是讓用戶自我進行推廣，我們軟件公司協助配合，要相信用戶的積極性，主動性和能力，要不斷激發他們在這些方面的潛力。

a) 從一開始到現場工作就要反復安排大量精心組織的培訓活動，讓用戶理解我們的思路；

b) 項目解決方案或思路一定要組織各種類型會議在現場反復講解，達成一致，非常關鍵問題不要回避或模糊化，例如產品管理的思路。但一些技術細節可以淡化，例如表格格式或者匯總時一些小要求，不要糾纏這些細節；

c) 培訓的時候在操作上應該準備實例化的內容，應該讓主導用戶操作后自我評價掌握程度，直到熟悉為止；

d) 培訓思路站在業務流的高度規劃，讓用戶相信你對他們業務理解和描述非常準確到位，打消用戶顧慮憂。

8.3.3 第三要提前做充分的內部業務驗證

內部業務驗證一定要自己親手測試，而不是等測試部門結論。

因為我們通過業務驗證推導我們業務流程實施思路是否可行的過程，這個工作別人是無法取代的。

測試部門只能按照功能驗證，不能按照業務驗證，可能有一些業務上操作瓶頸無法覆蓋，但我們到現場用戶一定會發現，因此造成用戶滿意度下降，進而要返工開發，導致公司管理成本上升。

而且驗證過程中我們要發現軟件是否有易用性，性能和功能上問題，要盡快提供給公司相關部門，直到尋求到替代解決方案或者列入可接受的版本實現計劃中，這樣才能保證在現場出現任何我們心中有數，即使是承諾可實現周期也比較有底，不會亂跳水。

此外作為項目經理和實施工程師必須對自己拿到現場實施產品功能了如指掌才能說是在業務上合格，不可能想象一個對新功能，新版本不熟悉的人去現場指導用戶實施；這個只能通過內部驗證來保證操作熟練程度，以及準備新功能培訓教材和升級數據等相關指導教材。

在內部驗證不是要讓產品沒有缺陷才能去現場，而是通過自己驗證充分評估產品對主要業務線的支持程度，有多少是可以通過溝通克服的，有多少是無法克服的，必須解決后才能去現場的，有多少是必須解決但可以暫時忍受的。并及時和規劃開發溝通，達成一致的解決意見，才有面對用戶的智慧。

最終做到在現場用戶發現缺陷之前，我們心中有底，有對策，有替代方案，可以承諾用戶我們大致解決時間，并按時間兌現，進而建立用戶對我們來現場工作的期待感和信任感，而不是抱怨我們拿著有問題的版本來，只會引發新的麻煩，進而導致項目失控。

8.3.4 第四要做現場驗證。

現場驗證就是讓用戶項目組充分評估新版本的好處和不足之處，確定是否升級，一旦升級出現用戶不滿就可以事先采取對策克服，而不是到處救火；

如果驗證結論是不能滿足要求，就千萬別到處裝機推廣，那是自尋死路，寧可回去改好再來，也不能強行壓。

現場驗證過程也就完成對用戶的培訓，讓用戶項目組承擔起實施責任，軟件功能是否滿足要求是軟件商的責任，通過驗證實施就是用戶的責任，這個工作要做得好還需要建立和用戶項目組充分信任的關系。

所以現場驗證要做好推廣風險評估，提前采取對策，此外要找到用戶實施推動人，協助他們推廣項目，最后驗證通過給領導匯報，取得支持，召開項目推廣啟動會，這個時候再進行推廣工作就很容易了。

8.3.5 選擇適當的推廣邊界

一般情況下推廣應用要考慮解決完一個業務環節再往下走，把繁復的企業業務化整為零，設計為相對完整的幾個部分，一個部分一個部分實現。

而且每個部分一定要有一個清晰效益牽引或做愿景，這樣大家才有跟隨實施的信心和熱情，并在一個臺階達到以后，再上一個臺階，逐步擴大應用范圍，每個階段實施難度實際上就降低了。

記住：只要某個業務流用起來了，往往就可以驗收了，此時項目推廣內容和合同邊界未必等同。

8.3.6 建立和用戶的個人友情

為了推廣順利實施人員也可以和用戶一起吃飯娛樂，增進感情，也是有效的團隊建立策略。

當然建立友情未必就是靠請客吃飯造就的，請客吃飯一般不會建立深厚的友情，友情是項目中同甘共苦中建立的。

9.1 驗收工作應如何組織？(連載五十五)

實施項目最快樂的事情就是項目驗收，可是經常是沒完沒了的信息化，不見不散的項目組，驗收之路何其漫漫。

我在整個項目經理技巧中都反復強調任何工作達到成效，并不在一時一地事情做到位，而是在平時工作積累中將事情細節做完善，做到位，很多想要的結果就自然達到了。

項目驗收就是我們最想要達到的結果，一旦項目驗收對很多人還意味著一件現實的事情就是，我們可以回款了，可以獲得項目提成收入了，同樣項目驗收也是一系列細致工作完成到位的結果，而不是某個點的成功或者個人能力就可以促成的事情。一個項目的驗收，未必是一次性活動，而是由一系列驗收準備工作組成的，在最終驗收之前，我們已經將很多階段工作細化并得到認可執行，項目驗收就是一個水到渠成的事情。

下面我們就一起討論一下如何進行項目驗收。

9.1.1 項目驗收的條件

很多人會奇怪，這個問題還需要談嗎，肯定是按照合同和技術協議驗收。

其實在業內目前項目合同和技術協議現狀是一個項目，不管金額大小，個性化開發多少，軟件功能模塊，幾乎是一個不少，用戶要求我們承諾的服務內容也是一個不少，供應商在競爭壓力下的營銷過渡承諾很難完全避免杜絕，如果要以完成合同和技術協議為標準進行驗收，業內的大部分項目個人以為達到預期要求的可能非常之少。

當然這和技術協議架構方式有關，一般最開始技術協議只談服務內容和實現目標，很籠統，結果在實施過程中很容易出現業務需求爆炸的情況，軟件商難以應付。

這種情況下軟件商就開始逐步細化產品功能點，按功能點確定軟件細節，只要功能點滿足，理論上就應該滿足用戶業務需要，用戶就應該驗收，至于業務能否運行，更多的是用戶的責任，這里面更多的體現了軟件商的自我保護。

實際運做時無論技術協議多細致，對用戶而言根本沒有太大的參考價值，用戶只會考慮其業務是否真的在運做，并以此作為檢驗我們項目是否可以驗收的標準，當然有的項目可以通過商務運做，在業務實現不太好的情況下也能驗收。

所以現在一般的模式管理軟件項目是按照服務內容分幾個業務目標，完成一個業務目標就完成一階段驗收，收取一部分實施費用。

所以項目驗收的最小條件是一個或某幾個基本業務面能夠開始大面積的應用。

這些基本業務面是不是很簡單，或者是不是很穩定，或者人員是不是一定全部都上線，或者業務面上功能是否存在可改進功能都不一定，但只要用戶看到這些基本業務面可以運行并承認這個可預期的結果就可以了。

9.1.2 確定里程碑

我們現在知道如果要真做好一個項目，完成項目驗收條件，是以業務是否可用為考量角度。不是一定得實現所有用戶的需求，也不是只有將一些所謂的技術難點解決用戶就可以用起來并驗收，而是我們可以完成一定的階段應用業務目標。

所以要想成功驗收，不是我們什么都承諾，什么技術問題都實現項目才能做好，而是和用戶溝通，代表公司和用戶就項目業務實施目標達成一致。

因此我們從進行業務調研的時候就要主動控制項目的業務邊界，將一個一個業務流根據企業實際情況合理組織實施順序，形成我們項目實施計劃中的里程碑點，明確達到里程碑點的條件，并得到雙方一致正式認可。

在中國管理軟件售前工作和用戶還無法建立長期合作關系，面對不是很成熟的用戶和瘋狂的競爭對手，我們在生存壓力下可以先和用戶建立合作關系，一旦能合作，就相對容易和用戶建立信任關系，有了信任就可以慢慢教育用戶，用戶一旦理解很多事情的復雜性不是軟件單方面可以控制的，反而會理性地和我們一起解決問題。

因此我們要相信用戶是理性的，他一定會坐下來和我們一起談：那到底怎樣解決問題呢？最終可以達成合理的結果，然后我們全力去沖刺每個里程碑。

里程碑的好處第一是將復雜的業務目標分解為一系列簡單的目標，即降低了難度，又使每個階段實施重點突出，精力集中在一點上，自然可以更有效解決問題。第二里程碑界定目標包含了一個一個相對獨立應用臺階，可以促進用戶項目一個臺階一個臺階往上走，用戶只要達到了一個里程碑，項目在這個業務實現臺階上就可以進入不可逆轉的狀態，不會走走停停，經常從頭開始。

在具體項目中，這些里程碑內容都可以設計，在每個項目中成功設計里程碑的關鍵就是最小化項目邊界，然后和用戶高管和中層干部，甚至在某些項目上還要和基層達成一致。

我們控制邊界的前提是我們自己要有可置換的因素，這就是用價值換邊界。

我們必須在深刻了解用戶業務基礎上提出我們的業務目標，闡明項目價值所在，讓用戶接受業務目標，并按照這個業務目標去實施，而不是糾纏在有什么功能沒有什么功能。

功能很重要，但考慮用功能如何支撐業務流程更重要。

所以一個人在項目中最大的力量往往源自對業務深刻而理性的把握。

成功項目驗收的核心就是邊界的確定。

沒有雙方高度達成一致的里程碑認可，也就是沒有項目目標約定，沒有目標約定的項目實施計劃一定會經常變更內容、變更初始設定目標，導致計劃不可控制，更談不上驗收。

很多人希望通過詳細解決方案來定義項目要實現的內容和業務目標，這是很有必要的，但解決方案得到認可并非是通過用戶審核就可以的結果，應該想辦法讓用戶一起參與解決方案思路思考，變成用戶自己推導出來的業務實施目標，未來才不容易變形。

因此我們建議在確定里程碑的時候和不同層面人員大量溝通目標，確定達成一致，在產品比較成熟的情況下，能否就項目邊界達成一致是最關鍵的工作，一旦這個目標達成，就很容易制定計劃執行和落實。

確定每個里程碑后續工作可以參考下面的標準流程。

9.1.3 主動溝通(連載五十六)

一般項目業務目標清晰后，就可以按照業務目標分解相應工作，逐步落實，在落實過程中有一個很重要的工作是很多實施人員會忽視的，就是主動溝通。

項目中一定要有溝通策略，和高管如何匯報工作進展，取得支持？和中層如何就業務目標不斷確認，逐步清晰？和基層如何就項目應用操作模式達成一致，持續改進？都需要通過溝通反饋完成。

溝通的作用對于高管是讓他們清楚我們一直按照項目目標前進，每個階段工作進展是否順利，影響項目正常運做原因是什么，需要哪些資源幫助。和高管溝通比較多的話，第一個好處高管經常聽匯報就知道項目進展程度，可以安排反饋檢查，看是否具備象我們所說進展，這樣一旦認可了各個階段目標后，最終要求高管簽字結項也就順理成章。

第二個會哭的孩子有奶吃，一把手工程核心就是高管支持項目運行，而做到這一點關鍵就是通過合理匯報讓高管對一個逐步前進的工作進行業績的承認，高管一旦認為某個事情比較容易成功了，反而容易追加資源保障完成，這就是信息化的：“馬太效應”。

一個工作高管經常性不知道進展，怎么會支持呢？當然誰去匯報可以在項目中界定是企業還是我們軟件實施商，但一定要和高管主動匯報。

給高管匯報技巧就是簡潔明了，真實客觀，有理有據分析問題，提出對策建議請其決策即可。

中層往往是項目主要的推動力量和實際執行者，也往往是對具體業務需求最主要要求者，他們對企業實際運做過程最清楚，提出要求最具體，而且項目驗收與否沒有中層的同意往往也是不太容易做到的。

要達到項目的目標沒有中層的配合也是非常困難的，和中層的溝通往往是不斷動態調整項目目標，逐步清晰化項目目標和細節的過程。

往往通過前期業務調研只能對企業項目目標有一個大的，宏觀的認識，但如何細化并最終落實并非是一步到位的過程。因此在整個項目過程中，雙方項目組要不斷溝通，特別是企業中層溝通，才能逐步認識越來越深刻，最終達成一致。

和基層的溝通主要體現對最終用戶的關懷，定期主動和最終用戶溝通，消除一些怨氣，讓用戶能堅持用下去，這個時候我們往往發現很多用戶真的是非常可愛，盡管軟件還有很多值得改進的地方，但他們一旦認可我們團隊，反而會盡心盡力幫助我們推動。

個人以為一般在項目中要堅持每個月到一個半月寫一份詳盡《情況簡報》，分別通報企業項目負責人，部門負責人，項目組成員。

《情況簡報》應先發郵件，然后一定電話落實收到并口頭簡要匯報，特別是高管層，千萬不要以為發了就等于別人會去看，一定要口頭跟進匯報一次，保證企業各方面負責人對項目進展做到心中有數。

另外實施工程師無論是否在現場，保證每周至少和操作用戶、系統管理員溝通一次，主動和用戶接觸，不要等到用戶有問題再來找我們解決。

這樣反而可以逐步釋放用戶一些火氣，真要救火的時候我們反而有一些從容周轉的時間，一回生，二回熟，到了驗收的時候也好說話。

9.1.4 寫好備忘錄(連載五十七)

在一個漫長項目周期中，很多工作做了也就做了，認可了也就認可了，時間一長也就忘記了很多承諾和約定，到了驗收的時候就翻出來重新要，這種事情很多人可能都經歷過，明明說得可以先不做的內容最終驗收的時候又成了必要條件。

所以在一個項目中要順利驗收，一定要寫好備忘錄，把平時項目過程中重要階段點雙方達成的共識詳細記錄下來，以備查詢。

項目組在每次現場工作都必須要寫備忘錄，備忘錄必須注明現場工作天數，按時間段寫清楚工作內容，性質和時間長度。

例如培訓工作要寫清楚培訓人員名稱，培訓內容，培訓小時數，培訓掌握效果；

例如裝機工作要寫清楚裝機軟件，裝機臺數，是否可正常使用等等細節。

每次備忘錄要口頭交流認可后才打印簽字確定階段性工作成果。下次工作則根據前次備忘錄的雙方約定繼續進行，保障項目在每次工作基礎上不斷前進，并用備忘錄約束雙方的行為。

備忘錄標準的寫法是先簡要匯報階段工作中內容，要用積極肯定性的文字給自己前一段工作或者一些提法給出正面結論，這樣大家看了才有信心。

這個工作內容往往是上一階段約定要解決的內容，而且在這次現場工作中得到解決的內容，要考慮和上一次備忘錄約定工作內容的呼應，很多人寫備忘錄，純粹是為了備忘而備忘，備忘錄三大功能，第一是備忘，第二是繳功，第三是約定后續工作安排，推動事情繼續前進。

所以寫備忘錄首先要講上一次我們約定什么工作，這次是否完成，完成質量如何，沒有完成是什么原因造成的，是否納入下一次解決的內容，這樣的文檔才有體系，也能體現出一個人整個項目過程中的脈絡，否則寫這么多備忘有什么用？

結論出來后后備忘錄要詳細描述自己所做工作細節，細節越詳細越好，讓項目組彼此認可工作內容和質量，而且對服務工作量可以有一個客觀的評估。

而且在寫備忘錄時發現自己大量時間并非在有效溝通或者在推動項目實施上，那么意味著項目已經是在失去控制路上，應該立即引起警覺并采取措施解決。

備忘錄最后還要約定下一階段雙方工作安排，在后續工作中嚴格按照備忘錄設計自己的工作計劃，了解企業項目組進展，如果企業項目組方面配合出現問題，在下次備忘錄中要明確指出責任承擔方，給用戶形成一定的壓力，從而更好推動項目走向前進。

一些重要的項目目標約定或者驗收意見可以單獨寫備忘錄，在最終驗收時可以作為依據。

這樣一個備忘錄一個腳印推動項目向目標前進，每個備忘錄都在前一階段工作上有一點點進步，最終項目驗收就是水到渠成的事情。

除了實施備忘錄外，實施人員最好給每天工作做詳細記錄，實施備忘錄個人認為只是一個工作進度大概描述，而且可能會有水分，因而需要有一個每天工作的詳細記錄用于自己或者團隊成員準確把握項目脈搏，及時發現問題，個人也能隨時做項目回顧，用戶的反復也能隨時記錄在案，如果出現項目延誤，也能有理有節和用戶應對。

9.1.5 精心準備一次成功的匯報

如果項目準備驗收了，一般要安排一次驗收鑒定，這個鑒定可能是要請專家來看，可能是企業內部組織，也可能就是幾個人認可簽字即可。

因此如果要驗收，最后鑒定這個工作質量要高。

要準備好一套模擬現場環境的演示環境，要有足夠真實的數據，要設計一套體現應用特色介紹流程，要準備一套詳實匯報材料和相應PPT。

要保證驗收大會順利通過，其實是在驗收大會前將相關匯報工作和現場應用情況和企業領導做過匯報，并得到充分認可。

9.1.6 平時做人的積累

對于項目一個實施人員要為公司考慮節約成本，同時也兼顧客戶利益，是比較難以決策的。

特別是在一個多可能同時負責多個項目的時候，想每個項目都應該全力以赴是很困難的。這樣難免讓用戶覺得我們響應不及時，有問題不解決，特別有些問題不是我們一個個體能夠解決的，長期下來用戶可能會積累很多的怨氣。

因此實施人員平時做人要講誠信，講原則，無非是三條：

做不到的事情千萬別隨意承諾；

承諾的事情一定要努力做到；

每次做到的事情都進步一點點。

有這三條用戶會慢慢接受稍微長一點的響應周期，也會用更多積極性眼光看現在的問題，也相信問題一定有人響應，也一定可以得到解決。

我們很多人做項目遇到困難在公司內部沒有想盡辦法去解決，認為我自己這么努力，承受這么大的壓力，而別的同事好象沒有什么壓力，心理不平衡，就容易回避放棄。拖，拖，拖，拖到無法再拖的時候在用戶那里就沒法抬頭，只能被動挨打。

如果按照以上三條原則做事，反而簡單，不做做不到的，當然這個做到做不到不是個人判斷，而是和公司內部協調達成一致后的意見，做得到的一定按承諾做好，項目就會簡單。

實施過程中可以留一手，有些好功能或者便利的地方，可以不全部告訴用戶，畢竟在合同邊界中沒有涉及，在驗收前可以作為條件和用戶去置換。

9.2 如何催款？

首先要主動提出回款要求，這是很多實施人員最難做到的一點，不知道如何開口，擔心開口后被動。

其實要錢這個事情最難的就是開口要，開口要了就簡單了，為公司催款是天經地意的事情，你是在為公司生存催款，也是為了有錢才能提供更好的服務，要理直氣壯的去要錢。

就象很多人催別人還自己借給他的錢一樣，難就難在自己的心理顧慮上。

不管項目實施地好不好，一開頭要錢，用戶馬上就會提出不合適，這個時候我們要趁機了解，現在不合適，具備什么條件就是合適？立即和用戶約定回款條件，有了回款條件，等于給自己清晰約定了雙方工作目標，那么這個回款條件馬上寫進備忘錄，達成一致意見。

所以項目中只要覺得具備一定條件，就要主動提出驗收，驗收速度取決于對驗收目標是否達成一致。

不斷提出驗收要求，就可以不斷就項目目標進行清晰定位，反復三次后，驗收目標就清楚了，這個時候雙方項目組就該解決的問題就盡快解決，不能解決的就想辦法，例如進行價值置換，或者追加資源投入，或者緊急開發，或者變更合同等等。

回款條件也不要立即寫成備忘錄，先不斷提出各種可行回款條件，，逐步選擇最合理的條件以加深印象，并不斷利用各種匯報的機會 明確，最終寫到備忘錄中成為未來驗收工作開展依據文件。

一旦目標一致清晰后，實施團隊要全力保障回款條件實現，一旦達到回款條件，還別忘了請商務人員做去商務工作，個人也不是萬能的，搞技術的可以催錢，但不要去要錢。

10.1 如何做項目團隊管理之前言(連載五十八)

入行五年，做了一些項目，現在最大的體會發現目前整個管理信息化實施盡管每家公司都提供了很多方法去指導，提供了很多流程去約束，但效果不大。

為什么呢？因為管理軟件實施需要一個人在四個方面都必須很強才能順利推動，這四個方面是企業業務，管理理念，軟件功能，人際溝通。實際上一個好的實施人員必須是一個能力非常強的知識復合型，精通項目管理技巧的人才。

在產品基本成熟后，一個成功的項目是靠個人能力去保障的，流程和方法論只能給有潛力的人行動啟發，而不是指南。這就是目前的現狀。

而這種人才的獲得是非常偶然或者是需要長時間積累的，但整個IT行業是一個年輕人的事業，大量不足30歲又沒有多少行業經驗的人活躍在一線，項目服務整體質量不高在所難免。

IT人注定是奔波勞碌命，一個現場趕往另一個現場的奔波中，知識的更新和積累非常緩慢，不如說是吃老本更合適，而IT公司為了應付用戶需求也是招架不及，成本難以控制，更不可能在業務培訓上下功夫，結果就是一大批有潛力不職業的實施人員在IT業浪費了青春。

通過高薪吸引高水平的項目管理型人才或實施人員進入IT管理軟件實施工作，其實是一個偽命題。毫無疑問當前一個具備以上技能的人員在IT業可以獲得的回報是遠遠少于其它行業，是不可能吸引多少人才加盟的，可能每家公司都有一些高人，與其說是為利益最大化，不如說是和愛好重疊，在工作中有樂趣。

但一個公司高人是有限的，不可能讓這個高人去應付所有的工作，否則這個高人只能給每個項目一點點精力，還不如一個花費大量精力在某個項目上的能力低一點的人的效果。我們在高度競爭的情況下，不太可能引進高人去實施，成本無法承受，也不能讓一個高人去面對所有的項目，讓高人崩潰。

根據我的觀察業內很多忙人，共同的特點是售前售后一肩挑，幾乎是一個突發事件跟一個突發事件，沒有喘氣的機會，最終的結果只能是黯然引退。

所以解決這個矛盾必須尋求另外的出路。

我個人的建議是，公司第一要做好知識管理，并通過IT產品為核心整理自己的知識，將對企業業務和管理理念支持通過連貫的功能體現在產品中，并形成售前售后一致的標準實施和演示方案，并不斷完善。

此外就是建立項目團隊，通過團隊能力組合去彌補個人能力不足，在團隊中建立學習型文化，通過親自示范傳遞很多軟能力技巧，也許是目前擺脫困境的辦法。

10.2 好的項目團隊構建要求

一個好的項目團隊絕對不是一種性格一種單一能力的人的組合。任何一個人想做項目經理，實際上從一開始就要考慮如何構造你的項目團隊。這些考慮包括如何建立實施能力的合集，形成共同的價值觀和行為模式等方面。

項目經理在建立項目團隊時容易發生兩種誤區，第一要求別人有團隊精神；第二是指望別人有為項目目標犧牲自己時間的精神。

這樣建立團隊只能說是期望值過高，最終團隊很難一起長期合作。

個人有沒有團隊精神不是關鍵，而是你建立的團隊對不同的人是否有包容精神，發揮他們的長處，抑制他們的短處。

要做到這點就是通過合理的利益機制去保障，不要指望用什么精神力量去長期維護一個團隊的斗志。

要知道很少有能在半年內結束的管理軟件項目，所以也不要指望個人一開始就愿意為了項目成功去犧牲自己的利益。

個人認為建立好的團隊把握住兩個方面就容易，第一是團隊成員價值觀接近；第二是團隊具有合理的利益分配機制。

一個能成功合作的團隊最好的方式是選擇具備同樣價值觀的人加入團隊。

國內項目很難做好的一個重要原因就是信息化長期艱巨性和企業需要立竿見影的效益之間的矛盾。

這個時候無論個人能力多么強，恐怕都無法立即滿足很多用戶的期望值，因此團隊必須要有長期抗戰的心理準備，這個時候肯承擔責任的人非常適合加入團隊。

作為一個管理軟件實施項目，一定要選擇那些有耐心，有韌勁，有擔待的人去負責項目，這樣的人才能把項目做好。

因為一個人肯擔責任，就會努力去解決問題，在解決問題過程中其技能一定會在很短時間內得到很大提高，這個人業務能力怎么樣是可以解決的問題。

但一個人不肯承擔責任，不肯努力解決問題，問題就永遠停留在原處不被解決，即使開始技能不錯，后來也不能適應項目需要。

很多項目往往因人而成，因人而廢。這個現實告訴我們很多時候我們必須花費足夠精力去選擇這樣的人。個人認為現在中國這么大，選擇40~50個認同這樣價值觀，對待遇要求也可以接受的人員一定有，只是我們沒有去發現，總是通過一大堆其它條件去選擇人員有關。

例如我們總是要求一個實施人員有計算機軟硬件知識，良好制造業背景，對信息化管理軟件實施有深刻認識，對軟件功能熟練掌握。

這些都是對人硬能力硬指標的要求，但是無法衡量一個人的軟能力，而在項目實施中軟能力是最重要的。所以我們在選擇成員的時候要和人力資源部門有力協調，不要選擇大量硬指標的人，第一是難找，第二是不好管理，難以協調一致和產生認同感。軟能力的衡量要考慮最大方面就是價值觀，而不是現成的業務技能。

根據個人觀察，能夠快速在項目中獨立擔負責任的人，從一開始他對這個行業一無所知到可以獨立完成任務，在有人指點的情況下一般只需要半年，甚至更短。

所以完全不必擔心這些新員工能否成長，而是應該擔心新員工能否得到良好的指點。

選擇好團隊人員只是一個開始，一個團隊一起協同工作一定是可以通過工作獲得相應的回報，這個回報一定要有一個大家認可的合理分配機制。沒有這個合理的機制，團隊也會因為失去激勵和公平而人心渙散。

做到合理的分配機制在項目控制過程中非常難，因為國內同樣規模和難度的項目，有的企業金額80萬，有的企業40萬，甚至有20萬，軟件公司為了解除現金流壓力，最后都會承諾去做。這些項目要做好都需要消耗同樣的項目人力資源。

如果一個人做了一個80萬的項目，一個人做40萬的項目，可能工作量差不多，但項目提成收入可能差距就是一倍。這個問題也就是存在所謂“肥單瘦單”的說法。

即使兩個人做的同樣是40萬的項目，項目復雜程度可能差別很大，工作量差距也是好幾倍，提成收入又差不多。

就算是兩個項目金額復雜程度差不多，付款條件不一樣也會對可預期收入產生直接影響。根據不同公司的政策往往實施人員更樂意或者不樂意選擇首期款比例高的項目。

還有一種常見情況，一個項目大家一起做才能完成，兩個人在項目中花費工作量不一樣，解決問題難度也不一樣，這個時候如何平衡兩個人的提成收入分配也很關鍵。

開始合作的時候大家往往比較容易齊心協力解決問題，但如果到了利益分配的時候大家覺得受到不公平待遇，估計你的團隊也就開始瓦解。

解決這個問題的辦法我覺得很難，從兩個方面入手也許容易做一點，一是在團隊內公平透明，優先獎勵符合我們價值導向的人，第二是必須認識到這個是一個項目經理管理團隊最需要花費精力的地方，必須保證時間去思考和解決這個問題。我們中國人一不缺智商，二不缺情商，但比較缺錢商，孟子說：民不患寡而患不勻，大概是我們可以參考的一個思路。

實際上我認為建立一個實施團隊不要照搬那些管理理論的理想描述去做，關鍵就是這兩個問題，有沒有一致的人，有沒有合理的分配機制。

10.3 好團隊的兩個特征(連載五十九)

一個好的團隊一定是分工明確的團隊。

很多IT管理軟件項目，要么是一堆人泡現場，要么是孤膽英雄。

因為遇到事情的時候用戶的感覺是沒有人真的去負責，這就說明在項目中沒有真正的項目經理，

這就是在一個團隊中沒有明確誰對項目負責，如何負責，技術問題誰負責，商務問題誰負責，管理問題誰負責，到了真有事情，每個環節都忙，但響應和處理效率并不高。

實際上用戶愿意選擇能夠解決問題的人，而且愿意解決問題的人合作。但這個人往往是項目經理，因為項目經理一般實戰經驗豐富，技能不錯，而且對項目最終負責，壓力最大，結果項目經理就成為這樣的人。但項目經理一般要負責多個項目，每個用戶都喜歡他，他很快就在多個項目中變成每個用戶都不喜歡的人，這就象一個人的情人不能太多，太多也難應付。

所以合理分工的原則是幫助項目經理充分發揮自己價值，讓團隊成員能力能充分體現。一般項目經理應該強在對企業業務把握能力，能快速發現項目的價值點，進而通過良好的溝通技巧在團隊內和用戶處就項目目標達成一致，并形成可執行的后續計劃。

這也就是所謂計劃，組織，控制三步曲。

項目經理不應該讓用戶認為是一個技術很強的人，當然項目經理技術可以很強，否則用戶會不認可實施人員的能力，反過來要求項目經理到位，而團隊成員技術能力也會因為沒有足夠實踐機會而成長緩慢。

不能成功讓用戶接受自己團隊成員能力的項目經理，注定是疲累不堪和失敗的項目經理。

此外項目經理技術性比較強，而且在管理軟件實施過程中要帶一些顧問的性質，這樣的角色最好不要和回款直接掛鉤，可以出面提醒用戶按期支付款項，但不應該直接去要錢，這些工作應該通過商務經理完成。一個人上來談目標，下來談收錢，會給用戶一種不真實的感覺，是否你為了回款而設置比較低的目標？

所以一般在一個團隊中應該有項目經理，實施經理，客戶經理三種角色。

項目經理，項目經理最大的作用是控制項目邊界，代表項目組和用戶就項目目標達成一致，然后組織資源保障項目得以實現。項目經理要保證為了達到預定時間內的目標，可以配置資源和時間去完成這件事情，而不是到處救火，親自去解決問題。

實施經理主要是從技術上保障項目順利運行的配置實現，并保證讓用戶可以獨立應用并推廣軟件，在積累一定經驗后可以獨立完成解決方案編寫和產品完整演示。

客戶經理是當項目達到合同約定條件時，負責催款和回款相關的商務工作。

個人認為實施經理和項目經理最大區別不就在于一個同時只能搞定一兩個項目，項目經理可以同時搞定5~6個項目。

項目中三種角色缺一不可，每個角色在自己能力范圍內發揮作用，互相協調配合一致非常重要。而且項目經理要讓用戶清晰知道遇到何種問題可以如何和我們項目組聯系，我們會如何解決，大概需要多長的時間。

這樣的團隊最大的問題是是否遵守同樣的行動規則，也可以理解為對外是否具有一致性。這也是一個好團隊的特征。

有的項目商務經理為了便于回款或者簽單，容易過度承諾，給后期實施制造極大障礙，有的實施人員在現場發現一些新的問題，容易犯個人英雄主義，自己去承諾解決，但并不先和項目經理溝通，有的實施人員如果不是特別安排，基本上不會去主動和用戶交流，有的實施人員幾乎每天都和用戶電話聯系，有的項目經理經常和用戶聯系，實施人員反而不去聯系，這些都是行動規則不一致的表現。

在一個團隊是否遵守同樣的行動規則，首先是價值觀一致。

例如我們是否都認為如果用戶現場出現各種問題，我們應該先全力促進解決問題，再來談問題的責任，而不是一開始就說這不是我的錯，這個不歸我管？

我們是否認為為了讓用戶滿意我們必須隨時準備犧牲自己的時間和精力？

這些都是很重要的問題。

第二是養成事先溝通的習慣。不要自己去決定所有的事情，也許你的決定沒有錯，比別人去做也會效果更好，但是在沒有得到明確授權范圍內的事情，一定要先在內部達成一致后行動，否則容易出現做了別人也不領情的情況。

很多事情也很難一開始就形成規范或者文件指導，但只要我們清楚這些事情應該先內部達成一致，總是有辦法，對于一些規律性的東西就慢慢形成慣例，可以減少溝通的成本，這也就是所謂團隊默契的形成。

第三是每個人的溝通頻率在一個項目中各個階段保持一致，關鍵溝通信息應互相清楚，不同角色溝通頻率節奏要合理搭配。

第四是對項目邊界和不同角色責任承諾對用戶說法要一致，這個是通過內部溝通達成一致后要和用戶明確的。

10.4 如何看待項目經理在團隊中作用

IT業流動率高，做實施的流動率相對開發可能更高一些，一個項目最怕中途換人，但這種情況在業內非常常見，用戶非常擔心自己的項目出現這種情況，往往要求在合同前期指定項目實施人員，這是一種無奈也無用的做法。

所以軟件公司應該將自己業務上比較優秀的人提拔出來，給予項目經理的職責，培養其管理意識，而不僅僅是技術意識，給個人比較大的成長空間和較好的待遇，這樣有利于核心員工的穩定，再由核心員工帶領團隊去做一個項目，這樣項目因為人員流失造成項目中斷的風險就最低。

所以對于公司而言項目經理不能是一個一般性崗位，是一個具備能力核心員工才能擔任的崗位，這個崗位能讓核心員工在比較長時間內穩定開展工作，并通過項目經理帶領團隊實施，促進團隊能力提升，保持團隊隊伍穩定。這對于一個項目可能是非常重要的一點。

從項目實施角度來看努力去負責一件項目是很不容易的事情，特別是這種管理軟件實施，所以一個項目團隊中必須有一個項目經理。

項目經理就是無論是其責任心還是職責規定都是那種尋找努力促進事情發生，從不輕易放棄的人。

項目經理是一個團隊的精神領袖，他的言行直接對團隊起到一種示范作用。

一般認為項目經理未必一定是一個團隊的技術領袖，但實際在目前國內要想成功控制管理軟件項目項目經理至少得是一個業務精通者。

一個對企業業務不熟悉，對管理軟件不熟悉的人擔任項目經理更大的可能是造成一場災難，盡管也許他具備很好的項目控制能力。

總之項目經理要成為一個讓用戶和團隊成員都信任和放心的人，這種精神領袖的地位是靠項目經理能力和個人魅力逐步得到大家認可后在一個集體中放大和加強的。

10.5 團隊建設心得和誤區(連載六十)

10.5.1 加強溝通保持一致

項目管理強調團隊達成一致再行動，但達成一致的關鍵是先在內部廣泛達成一致，再對外溝通。

這個原則有兩點在操作中很容易出現問題的地方，第一是項目經理事無巨細都需要了解和溝通，協商成本太高，導致溝通效率很低。

內部溝通非常必要，但也沒有必要事事溝通，反而打擊團隊成員工作積極性。項目經理應該實現和團隊成員約定不同類型事件溝通方式和頻率，保護團隊成員工作主動性，同時保障項目始終受控。

第二項目經理自認為能力很強，按照一些項目管理理論說法項目經理先和客戶達成一致目標，然后協調資源完成目標，內部資源不聽調度就非常惱火。

現在一個出色的項目經理一般都無法專心做一個項目，所以項目中主要實施工作還是要依賴其它團隊成員完成，因此在一個團隊中對于軟件實施有不同認識和意見是很正常的，項目經理一定要先多花一些時間在內部溝通，千萬不要以為內部一致性很容易達成。

我們員工更習慣的思維模式是既然你都已經決定了，我照你的做就是，還問我意見干什么？如果員工覺得項目經理思路不對，他們可能不是優先考慮執行，而是想證明自己是對的，這也是知識型員工的特色。所以寧可先多花一些時間告訴項目經理自己的判斷，最后和用戶會談達成的結論會比較順利地傳遞成為團隊共同認識。

10.5.2 參與和顧問式領導方式

很多項目管理書籍告訴我們領導有方的項目經理從來不教人如何工作，由項目成員自己決定怎樣完成任務。

我個人認為項目經理工作恰恰是要給新員工示范正確的做事方式，只要條件許可，還要親自示范，在項目需要受控的時候多一點獨斷專行，少一點成員自由發揮是非常重要的事情。

項目經理的示范只需要一次，通過示范讓項目成員感覺到正確的做事方式可以有效達到目的，這也是項目經理建立權威的自然時機。

在中國缺少職業教育的高學歷人群比比皆是，如果相信這些擁有高智商的人能夠順利完成工作就大錯特錯，高學歷的人把很多簡單的事情搞得無比復雜的情況到處都是，很多人自以為是，自作聰明，最后還是要別人去開屁股。

也許在國內項目經理不需要過于精細的管理，但在國內不能確定團隊成員工作方式和能力之前，項目經理還是要多做示范，保證團隊成員工作方式是按照基本的職業方式進行后才能讓他們自主發揮。

10.5.3 控制過程還是目標管理

很多管理理論總是強調不要僅僅重視結果，要注意過程，沒有過程質量的保障，最終的結果輸出也是偶然的，不可靠的。

這個理論一點都沒錯，不過問題是實際上項目經理在過程控制上花費的時間越多，花費的精力越大，項目反而越難以控制。

因為管理軟件實施對人的綜合能力要求太高，當一個人的能力還不能達到業務要求的標準的時候，最需要的是培訓和示范，而不是責問為什么你的工作不到位？

就象本人寫前八章一樣，能夠把這些事情正確執行方法知道的人都不多，有實際經驗的人更少，對能力不足的人去控制過程，還有控制的必要嗎？

這個時候最重要的是建立業務規范，在業務規范大家有能力執行的情況下，再去考察業務規范符合度，加強過程控制才有效。

我們很多軟件企業不斷強調自己的流程和方法論，但員工經常流失，很多新員工在現場工作的時候，什么方法論都不管用，他們充滿恐懼的想：我到底該做什么，我該什么做。

過于強調過程管理最大的一個體現就是匯報多，層次復雜，增加了很多管理活動，但又看不出這些管理活動的價值。結果是很容易重復匯報或者多頭匯報。口頭匯報完成的工作還要書面匯報，日常匯報過的工作還要專門總結匯報，現場記錄的工作還要單獨匯報。

經常反復匯報在項目管理的理論中也有說明：這是打擊團隊士氣的有效方法。

本人建議匯報突出兩點，壞消息先匯報，例如不能按照計劃完成的工作要匯報，需要緊急協調資源的消息要匯報，這些隨時發生，隨時搞清楚原因，隨時匯報，隨時采取行動。

第二與其反復了解進展，不如提供清晰的目標管理。

也就是說項目經理接受和交代任務的時候，一定要清楚自己任務的范圍，質量要求，進度要求。

對任務理解是否達成一致的最簡單方法就是請任務接受人當場復述。任務接受人如果不清楚任務的內容，進度和質量要求，一定要問清楚才能去執行，如果不清楚怎么做，也要立即溝通請教，不能先好好好，回頭告訴別人我搞不定。

本人曾經給一個員工布置一個修改方案的任務，電話里說了6點修改意見，問他清楚了嗎，非常自信的回答，我知道了，放心。

本人很不放心的又問一句，給我復述一遍。很流利的說了四條，然后問我，哎呀，還有兩條呢？

所以在接受任務的時候還要一個職業習慣：好記性不如爛筆頭。

在國內目前項目實施水平現狀下，個人以為目標管理，嚴格的目標考核機制遠遠比過程控制更能達到管理目的，只有當大面積的人可以按照目標完成項目的時候，過程管理才能發揮不可替代的優勢。

10.5.4 信任團隊成員

項目經理一般都是業務能手，很多時候看到項目成員做一些很簡單工作都做不好，馬上親自動手，先搞定問題，否則項目耽誤不起，但常此以往，項目經理就是眉毛胡子一把抓，活該累死。

項目經理要信任和授權成員獨立完成任務，既然都在一個團隊就要用人不疑，疑人不用。堅決大膽要求團隊成員努力學習獨立掌控局面，項目經理逐步演變為對目標進度的控制者。

當然這個時候項目經理要加強對員工工作的指導，但項目成員往往分布在不同的現場，項目經理要結合不同項目拜訪計劃的時機采用走動式管理。在現場不斷并親自驗證成員的工作方式，立即指正和改進，加以示范。

信任不是放任自流，以信任的名義對團隊成員的工作放任自流是項目經理失職和偷懶。

而且項目經理要時時考慮讓讓用戶成為團隊中的一份子，從一開始就全力培訓用戶是減少實施成本的最有效方式。

團隊成員一個比較共性的問題就是：很多人會問沒有資源沒有人我怎么開展工作。這樣的團隊成員可能會辜負項目經理的信任。

這是很大的一個誤區，一個人有能力的表現就是能做別人認為很難做到的事情，如果事事有資源你才能把工作做好能說明什么？這種事情誰都能做。

而實施工作就是在各種縫隙里尋求合理的答案，項目經理在信任團隊成員的時候也要讓團隊成員建立承受壓力，迎接挑戰的心態，也就是所謂情商吧。

10.5.5 建立向上的團隊文化

項目經理一般都是個性很強的人，不太可能用同樣的方式約束項目經理的做事方法，當然越是成功的項目經理，行事方法越具有共性。

而項目團隊成員和項目經理的互相認同對一個團隊成長非常重要，也是工作能否快速進展的關鍵。

項目經理要及時認可成員工作，隨時用進展鼓舞團隊士氣。對很多人而言，物質獎勵的預期是很清楚的一件事情，國內的項目經理一般也沒有多大空間去對項目成員工作進行物質獎勵，因此在這樣的邊界條件下我們更要尋求利益機制以外的團隊合作方式。