一、解決方案難寫在哪裡？

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

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

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

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

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

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

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

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

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

1.1 第一種是沒有體系

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

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

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

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

1.2 第二種是沒有思路

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

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

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

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

1.3 第三種是沒有素材

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

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

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

1.4 第四種是沒有層次

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

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

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

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

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

二、壞的解決方案有那些特徵

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 公司簡介及資質檔案

1.1公司簡介 1.2 自有產品及代理產品情況 1.3 重點工程介紹 1.4 公司資質影印件 2 分項標價表 3 ***PDM系統技術解決方案 1 ***PDM系統技術解決方案 2 ***PDM系統具體功能模組 3 報表及明細彙總 4 應用工具及封裝介面 5 使用者及許可權管理 6 拼圖列印 7 編碼管理 4 實施計劃 4.1 實施步驟 4.2 實施計劃 5 培訓計劃 3.1 系統培訓物件 3.2 主要培訓內容 3.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 附件

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

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

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

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

具體功能模組後面跟著一大堆章節就更奇怪，裡面每個都是具體的功能模組，為什麼成為和具體功能模組平級的內容？應該設定為具體功能模組子章節為妥。

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

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

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

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

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

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

1 業務實現思路 2 技術支撐模組 2.1有效的技術資料管理 2.2深入的資料整合 2.3嚴密的過程控制 2.4靈活的設計支援 2.5輔助設計工具

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

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

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

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

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

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

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

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

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

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

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

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

2.1有效的技術資料管理 2.1.1 產品資料管理 2.1.2 零部件資料管理 2.1.3 系列零部件管理 2.1.4 系列產品管理 2.1.5 產品配置管理 2.1.6 產品批次管理 2.1.7 資料入庫管理 2.1.8 個人資料管理 2.1.9 資料安全管理

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

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

有的企業要求使用者訪問控制；有的企業要求提供角色許可權管理；有的企業希望按產品目錄授權；有的企業要求全部存放在伺服器的資料庫中；有的企業希望支援多資料庫獨立訪問；有的企業要求提供備份工具等等。

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

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

2.2深入的資料整合 2.2.1 主流CAD的整合 2.2.2 CAPP的整合 2.2.3 和其它常用工具軟體的整合 2.2.4 資料探勘統計工具 2.2.5 和其它PDM/ERP系統的整合 2.3嚴密的過程控制 2.1稽核管理 2.2釋出管理 2.3更改管理 2.4專案管理 2.4靈活的設計支援 2.4.1 變型設計業務支援 2.4.2 二級工藝管理業務支援 … … 2.5輔助設計工具 2.3.1編碼管理 2.3.2企業資源管理器 … …

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

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

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

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

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

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

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

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

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

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

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

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

相關推薦