很多人對寫方案非常沒有信心，一涉及到方案的事情，就束手無策，到處求人。
作為一個公認的方案打手，意思是寫方案就象打字員一樣，我覺得我在這方面確實是有絕活。
我基本上都是在方案提交前一兩天接到寫方案的任務，而我自己的事情一般又比別人多一點，也不能不做，只好心里大罵一句，罵完后就打電話搞清楚別人的要求，邊問就邊構思整個方案的推導思路和結構提綱。
因為你不敢讓你的同事知道你只能用很少的一點時間寫方案(基本上我真正動筆寫方案的時間都在2~4個小時以內)，讓他們擔心方案的質量和進度保證，進而對自己的后續工作質量沒有信心。所以我其實也特別緊張，注意力也特別集中，大腦也高速反應，基本上幾分鐘電話或面談完思路基本就有了，然后該干嘛干嘛，找一些零散的小時間把思路不斷推導一下，然后到了一個比較安靜和完整的時間段前才開始寫，這個時候基本上要寫的話都想清楚了，只需要不斷敲字，敲字的時候也是注意力也特別集中，大腦也高速反應，越寫思路越開，很快也就完工了。
寫方案不難，知道怎么寫才難。關于寫方案我只總結一點，結構化地去組織你的思想。
有結構就有思路，有思路就有方案。
另外真正寫方案的人，對自己寫過的方案是永遠不會滿意的，只有這樣，每次都會進步一點點，解決方案水平質量就會隨公司能力不斷增長。
當然我曾經問過很多人，你到底為什么寫不出好的方案呢？
基本上原因可以歸為四類：
一旦用戶要求提供關于PDM的方案，很多人大腦是一片空白，完全不知道從哪里下手。很多人說起自己的產品來，好象知道不少賣點，不過真要寫出來，又覺得無從下筆。
這種情況一般是寫方案者不熟悉自己產品體系造成的，知道一兩個甚至更多的產品賣點不難，但難就難在成體系，知識就是成體系的點構成的，而不是一句一句離散的說法構成的。
因為我們這個行業從業人員說句不客氣的話，大部分對所銷售實施的管理系統并沒有很深入的研究，都是半路出家，從頭開始，在學習過程中熟悉，在熟悉過程中領悟。所以一下子去駕馭一個整體方案是很痛苦的。只有當一個人對一個產品思路有體系以后，才能夠寫出完整的方案，否則就是一個單元也要費盡腦汁。
所以一個人要想寫好一個方案，首先要把自己產品的來龍去脈，功能模塊，適應領域，典型客戶實施情況有一個全面的了解，這樣才能建立一個完整的知識體系，然后逐步補充競爭對手知識和一些技術性知識，不斷深化自己的知識體系。
有很多用戶看多了模板化的方案以后，想看一些針對他們自己的業務的個性化內容，這個時候有的人按照標準方案模板修改還勉強能對付，但對于個性化內容針對性方案就速手無策了。
這種情況從根本上講還是寫方案者不熟悉企業業務造成的，寫方案，特別是針對性方案不僅僅要求了解企業的需求，而且要知道這些需求是在何種業務需求下產生的，用戶提出這樣的要求到底想解決什么問題，把這個問題找出來，一般針對性解決思路就有了，有了思路，自然可以很好的寫方案。
所以一個人要寫好方案，還需要了解下游客戶的業務，了解業務最有效的方法就是親自做幾次詳盡的業務調研，有了業務調研做基礎，在調研過程中把握用戶關注重難點問題，自然可以比較好的確定方案的個性化內容思路。
解決方案就是把客戶的利益和產品特性之間建立一個邏輯性的橋梁。
一般不經常寫方案的人，在寫一個方案的時候，即使有想法，有思路，但往往也會很累，就是因為缺少足夠的素材。很多項目現在都是投標，不同用戶可能有不同投標的要求，這樣很難用一個方案去適應所有的用戶，因此在每個方案中都有一些需要準備的內容。
這些內容基本上是通用的，但如果沒有足夠積累每次編制方案就需要花費大量時間去準備，造成方案完成周期過長。
所以寫好方案必須具備這三個條件，第一方案編制者對企業業務要很熟悉，或者有相關業務調研經驗，第二方案編制者對產品非常熟悉，至少對自己產品功能模塊作用很清楚，第三方案編制者手上有大量可公用的素材庫。
很多人剛和用戶接觸沒有多久，為了表現自己對客戶的重視，馬上表示要提供方案，當然有的客戶剛剛開始選型，也不知道到底要什么搞，也要供應商馬上提供一個方案。
結果拍胸脯容易，寫方案難，自己寫不出來只好求公司，公司沒有安排專人了解情況，只好按模板制作一個，用戶一看幾個供應商內容都差不多，覺得不好，又總結出一些個性化要求，于是大家有開始折騰第二輪方案。
其實方案編制在不同階段有不同策略，不要輕易提供方案。剛開始接觸是可以提供項目合作建議書，類似可行性報告，項目需要考察軟件技術，可以提供標準的產品技術白皮書，到了經過售前調研，有所準備，在演示前后階段和其它競爭對手刺刀見紅的時候，才在知己知彼的基礎上提供解決方案或者投標書。
過早提供方案只能匆匆了事，時間緊急，質量自然不高，自然也就覺得方案難寫。想急就又能解決問題的事情，本來就是一般人做不來的。
方案想要寫得好，一定要用心，用心就一定要耗時間，指望用幾個小時寫出一個高質量的方案是不可能的。如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，明白了這一點，大家都可以經過練習寫出好的方案。
不好的解決方案粗看起來非常厚重，其實都是功能羅列，象產品手冊摘要版，不象方案書。
不好的方案是一大堆內容，淹沒在一堆紙里面，也不知道想說什么，給你一個厚度，證明我們的工作質量很高。我們國內許多的企業客戶特別是大型企業都很在乎這點，認為可以從方案厚薄中看出對項目重視程度。
如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，有個金字塔式的寫做原理，也就是說文章一定是有結構的。
所以真正好的方案，不一定厚，但能看出你用心，你認真。
現在的解決方案一個不好的傾向是“長、厚、全”，看起來面面俱到，其實對決策者沒有幫助。
所有的方案無差異性，每家供應商都說自己能解決這些問題，而且都有成功案例。
結果所有的方案都無法給決策者簡明的判斷依據，不得不費更大勁去做產品演示和用戶考察。
其實很少有企業高管不知道自己的毛病，在企業你隨便去找一個人，對問題都能講一通，在企業你費很大勁可能都找不到一個人能告訴你這些問題可以怎樣去解決。
通觀這個方案并沒有研究為什么企業會產生這么多問題？問題是這些問題是什么產生的？為什么出這么多問題？而是不斷說“我能！我能！選我，選我！”。
如果不能找到解決這些問題的原因，簡單地去解決這些現象，就象治病不能治根一樣。這樣一個模板化，自我膨脹化的方案想打動用戶的心是非常困難的。
不好的解決方案最大的問題就象寫一篇議論文，能夠發現問題(這個也是模板化的，可惜中國企業大部分沒有意識到自己很多問題并不少見，總以為自己是特殊的一類企業)，提出答案(搞信息化)，但沒有論證(為什么搞信息化和企業管理進步有聯系呢？)。
沒有論證的東西不管內容陳列得多么繁復，名詞多么嚇人，但是無法打動用戶，特別是那種理性的用戶。
看到方案時候，其實很多用戶下不決心，他會感覺每家都差不多。
如果從沒看過方案的人，突然看到這幾個方案，你為什么會感覺某個方案寫得好呢，關鍵是有的方案圖畫的好，通過圖，通過表，會感覺這個公司還不錯，很規范。但對內容認可程度并不高，實際上沒看懂。
解決方案省事的一種方法就是將產品功能描述作為技術方案內容進行羅列，或者參照軟件用戶手冊羅列，這種解決方案不是按照用戶業務去準備的內容，而是按照軟件商自己的喜好去編制的解決方案是很難得到用戶認可的。
大凡按照功能列表組織的解決方案用戶會有一個體會，龐大而庸長，但要看到自己想看到的部分非常困難。
而且這種方案還有一個特點，一個問題反反復復的提，在業務背景中指出某個問題，講一通，在價值分析中又重點解釋一通，到了功能介紹時又將某個問題來龍去脈概要說明一下，給用戶感覺是一堆資料的堆積，哪里體現出了方案的針對性呢？
按功能列表準備方案的做法在很長一段時間內不會消失，這和我們普遍是4P銷售人員，還缺少SPIN(顧問式)銷售人員有關，在資源不足的情況下，要保證效率就只能提供功能列表方案了。
不好的解決方案最共性的毛病是結構不太好，沒有清晰的思路。
沒有思路的方案質量很低，用戶在審閱過程中也不會體會到和一個專人人士通過文字交流的樂趣，他不得不從供應商混亂的思路中發掘亮點，看看到底是誰能解決企業的問題，真是一件痛苦的工作。
一種常見的方案結構毛病就是重復的內容在不同的章節反復出現例如在第一章介紹了對某個問題的分析，提出企業的需求，這第二章介紹方案價值的時候又用不同語句組織類似內容，到第三章解決方案描述中還是要把問題描述一遍，給人感覺思路不連貫，結構臃腫。
這里有一個方案提綱的提綱，我們以這個提綱為例子說明結構不清晰的方案。
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層，就可以采取其它排版方式體現。
不好的解決方案還有一個毛病就是口語書面語混雜，遣詞造句不嚴謹。
有的人寫作時順著思路走，口語化成分很多，例如本人的行文基本是口語化的，也體現了這個毛病。當然大師級人物的確可以將文章寫得明白如話，但是對我們這些人而言方案是代表公司正式對外的文檔，一定不要出現口語和書面語混雜的情況。
例如太多的兒，的，我們，你們等等都是口語化語言，不應該大量出現在正式方案中。
有的人寫方案比較圖表現，喜歡指出用戶的不足，這個時候喜歡用很激烈的語言。例如缺少管理，業務失控，后果很嚴重等等語句，這樣的遣詞造句是不嚴謹的，方案用語不要追求“語不驚人誓不休”。而是理性分析，認真推導，句句講邏輯。
實在要用一些事實說明企業的問題，不要用刺激性強的語言，例如說企業業務存在問題，可以說業務有可改進的地方，例如說企業管理失控，可以說管理上存在很難受控的環節。
這樣的表達企業反而容易接受，不出問題。
不好的解決方案制造過程往往是找一個同類方案，然后主要工作是“CTRL+C”+“CTRL+V”。
很多人就圖快，省事，沒有很好的核對，結果往往容易出現如下幾種錯誤：
第一有些企業在一個方案中用了不同的稱呼(這個也要養成一個習慣在一篇方案中一個企業用一個簡稱和一個全稱)，替換不完整，結果在方案中出現了其它企業的名稱，非常不禮貌；
第二有時候替換過頭，把一些案例中類似的話也替換成為給用戶名稱，鬧出笑話。
第三只注意了文字替換，不注意圖形中的替換，結果文字是一個用戶的，圖片是另一個用戶的，感覺不尊重。
第四是只注意了文字替換，忽視了頁眉頁腳的替換，特別是注意了首頁或目錄的頁眉頁腳，沒有注意正文的頁眉頁腳。
第五是案例不對，明明是汽車行業的用戶，案例全部都是其它行業的，感覺在這個行業沒有經驗。
第六是聯絡方式不對，很多時候將別的營銷區域方案拿過來用，服務信息都沒有更正過來。
第七是存在大量技術硬傷，有時候為了突出軟件技術實力，將大量專家都不一定看得懂的詞匯大量堆砌，其實連軟件公司自己都搞不清楚采用了哪些。
企圖通過讓用戶對概念和名詞發暈進而對軟件產生信賴的方式已經過時，解決方案應該實事求是說明業務問題，不要在名詞上忽悠。
很多人寫方案大量出現“**軟件公司”內容，甚至每個產品都恨不得加上自家標識。在很多地方行文造句都是“我能，我行，我有…”等語氣。
這種方案很容易給用戶過度營銷的感覺。我們給用戶寫的方案在售前建議盡量用用戶做前綴，例如說某某企業PDM項目，不要總在說某某供應商PDM的話，給用戶一種相對的針對性，感覺這個方案的確是為用戶準備的。
在售后實施方案中軟件公司的名字只需要出現一次，后面就不需要反復出現，因為大家都知道是你的產品，何必反復體現，我們更應該把用戶的注意力集中到產品本身就應該具備的功能和支撐業務上，而不要形成某某可以，某某不可以的印象。
方案提交給客戶之前，一定要經過評審。
沒有開發點的方案，一般經過自評和互評即可，自評時，要重新審視整個方案的結構、問題描述、遣詞造句等方面，特別是用替換修改的企業名稱和營銷平臺等方面的內容，盡量減少低級錯誤。
自己評審過的方案一定要給一個其它的人評審。
互評時，要重新審視整個方案的結構、遣詞造句等方面的內容。
對于有開發點的方案，要經過公司的評審。提交給公司評審的方案，一定是已經過自評和互評的方案，而且要注明主要看哪些部分，以及編寫這些部分的背景知識。
一般人寫解決方案首先不是想著如何說清楚用戶的業務，如何在公司產品中體現出對業務的支持，而是想趕緊找一個模板，把這一關走過去再說，其實很多時候就是對每個階段工作沒有質量意識最后導致工作處處被動。
所以寫解決方案一定要根據公司最新產品功能認真組合功能實現企業業務，甚至可以考慮利用未來半年內會發布的功能認真組合，因為解決方案離正式實施往往需要半年甚至更長的周期。
很多時候解決方案一抄再抄，都是一兩年前的模板，自然缺少競爭力和說服力。
這個問題的核心是公司有沒有專人專崗負責對標準解決方案的維護和更新發布機制，其實比較好的一種做法結合典型項目技術公關推動解決方案水平不斷完善和提高。
一般情況下方案撰寫人只是按照別人要求提供方案，并非直接利用方案的人，所以在寫方案之前，問問需要方案的同事，甚至是用戶，聽聽他們對方案的想法和建議，對自己寫方案會有很大幫助。
很多時候方案準備完成方案接受者并不滿意方案的組織，需要返工修改，所以動筆前先打幾個電話，問問別人要什么，不但可以提高方案準備命中率，甚至可以獲得大量現成的思路建議，對自己寫方案大有好處。
一般寫方案最簡單的方式就是按照軟件自己的思路和功能模塊組織，因為有大量現成的材料可用。但這樣方案對用戶并非是一種最佳選擇，因為客戶要轉換到供應商的思維才能看懂方案字句之間的含義。
如果從以客戶為中心角度出發，方案應盡量讓用戶容易看懂，好理解，自然也就取得了幾個印象分。
我們方案就是要先仔細探討企業業務，不是將調研結論一羅列，而是從業務分析得出業務需求，最后描述技術實現手段。從這個意義上講，解決方案要按照簡明的操作手冊來準備。
不同類型的方案都有自己的套路，例如可行性報告，解決方案，建議書等等都有標準的套路，我們應盡量按照標準套路準備方案，不要自成體系，在套路下發揮，套路就體現了一種結構化體系化的思維模式。
關于常用套路我們另有一章說明。
很多時候方案準備時間并不充分，很多人接到任務，壓力之下立即開始動手，這往往是不好的工作習慣，有時候有模板，的確可以快速出活，但時間長了就養成一種惰性，替換方式抄方案還勉強，真要遇到有個個性化問題，因為在平時寫方案過程中思維始終不經過結構化思考的練習，真到方案模板沒有覆蓋的情況，就沒有辦法應付。
好的方案特點是：標題就是論點。結論做為標題馬上拿出來。
好的方案是觀點鮮明，立場明確，有理有據，有血有肉。
所以有方案要寫，一定不要急著寫，而是想自己的提綱，這個完整提綱目錄之間的邏輯聯系和業務銜接自己在心里面推導得比較有力和充分了，才開始動筆快速拿出提綱，有了提綱寫起來思路就不會斷電，寫起來才快。
好的方案一定是做了論點。
論點是假設的，例如說搞PDM有價值。
你說價值有三個方面，能降低成本，提高質量，能縮短交貨期。這都是你的假設。
你怎么知道成立？就要找些事實去證明它。
我們現在都喜歡找什么事實呢？你用了這個功能，所以你的論點就成立，因為你有這個功能，所以你的效率提高了。
這都是扯蛋！為什么用了PDM企業就能做到這幾點。根本沒邏輯推導。
不是還有大把企業用了ERP，用了PDM還不是該咋的咋的，錢都打水漂了。
假如你有好多論點，論點怎么組織呢？你比如我要搞信息化，信息化有大價值，小價值對不對？你要把它都列出來，列出后你還要想一想這個價值和那個價值是不是包容的關系？
好處一定是每個好處都是獨立，它是有層次，每層上的好處是平級的，大好處包含多個小好處，這些好處倒推出來就響應支持你的論點，這種方案看了以后別人就會理解并支持你。然后每個好處一定是在前一個好處的基礎上往前推動一步，最好得出一個強有力的論證過程。
所以好的方案必須是金字塔型的，論據論證最后構成堅實的基礎。
如果有條件的話，這個思路還應該和大家討論，特別是一些重要方案，一定要先反復討論提綱，大家各種意見和思路在提綱中統一了，再動手寫。這樣就不至于遇到寫了一半被人否定，推倒重來的痛苦了。
寫方案最怕中間不停被人打斷，這樣思路連貫性會很差。所以我無論接到多么緊急的方案編制任務，也不會急著去寫，而是把手頭該處理的小事情處理干凈，然后保證開始后的時間相對安靜和完整，這樣才能保證方案的質量。
而且寫方案一定要保證在一個時間段內初步拿出完整的推導思路和結構提綱才能結束去干別的事情，這樣以后就是逐步補充和豐富內容，不至于還在為結構苦惱，不清楚從哪里下筆，每次要花費大量時間從頭構思。
一個方案往往厚厚一本，更多是充點門面，領導是不會真看的。萬一要看，也就是看看包裝是否精美，和頭幾頁文字。
所以方案可以單獨附一份摘要，這是關于整個方案業務分析和解決思路的精華部分，當然也可以帶一點實施方法和典型用戶的介紹。
這樣就可以讓自己方案思路在短短幾頁紙中清晰描述和表達出來，這種提煉過的語言和文字往往更能打動人心。
一般寫一份厚方案只需要一天，寫一份薄方案需要一周，要求在三頁紙內說明問題需要一個月！能把書讀薄是能力的體現。
對于方案也一定要提供一份閱讀指引，告訴不同的人其關心的內容可以在哪些章節直接獲得，方便其閱讀。實際上我們觀察很多論文和書籍序言都有一段來說明這個文字的結構，其實這也是一個標準做法。
方案一定要注意排版，印刷要干凈，封面要隆重，裝訂要精美，方案就是一個公司的臉面，雖然不是說一份方案可以決定項目，但一份看上去都不好的方案一定很讓人懷疑公司的能力。
我們很多人見過外企的文字，一般都非常精美，排版很漂亮，大家一看就覺得是專業人士所為。
所以方案的文字和圖表內容最好請專門的美工設計一套標準的排版體系，對方案整體可讀效果會起到極大促進作用。
現在很多方案都是密密碼碼，內容是多，可以有什么用？
不如取巧，少寫一些文字，多在排版上動腦筋，實在想不出好的排版是什么回事的，去買基本暢銷書，你會發現可讀性好的書往往有一個技巧叫“留白”。
方案文字段落邊框之間保持適當距離，特別是邊框合理留白會讓一份方案可讀性大大提高。
象本文這樣的文字如果加上留白設計可讀性就會很不錯。
寫方案無論如何按照企業業務組織，基本上90%內容是相同的，不過是根據不同思路進行組織而已，畢竟軟件功能不會在短期內發生巨大改變，方案涉及功能也沒有理由發生大的改變，所以方案中很多素材是可以通用的。
包括一些公司通用素材，更是要隨時積累補充完善和歸類存檔，這樣在寫方案時才不會因為尋求這些基本素材浪費大量時間。
基本素材收集還要注意隨時和公司公開宣傳口徑保持一致，防止引用過期素材。當然標準素材最好由公司統一維護。
獲取其它素材的途徑比較多，主要有：
現場初步需求調研與交流
與熟悉類似項目的銷售經理、技術支持工程師、實施工程師溝通、了解
營銷平臺交流
企業網站
相關行業資料介紹
書刊
……
一般可以從企業網站獲取企業介紹。從網站獲取的企業介紹需經“角色轉換”和“內容篩選”，角色轉換是指站在公司的立場描述該企業的情況介紹，要把導師稱改為第三人稱。內容篩選是指主要介紹企業信息化的基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等內容。
目前，公司為客戶撰寫的方案分為：建議書、解決方案、投標書。技術白皮書應作為統一的資料提供。
建議書是用于動員客戶啟動項目，或者用于客戶初步選型階段的技術支持，以入圍；
解決方案是用于洽談技術協議和合同之前的技術交底，或者用于議標階段以技術和實施服務等優勢戰勝對手；
投標書是用于客戶招標的技術交底，以綜合實力戰勝對手。
一、建議書的基本結構
建議書的側重點是分析客戶實施某項目的宏觀和微觀形式、現存的諸多問題，提出實施該項目的必要性和緊迫性，再介紹相關產品和技術的發展現狀公司的產品特點和優勢，落腳點是公司已具備相當的實力，與公司合作成功率最大、風險最低。建議書的基本結構如下：
引言
現狀分析與診斷
相關技術的發展現狀
公司相關產品的特點
公司具備的實力和基礎
結束語
各個部分撰寫技巧如下：
引言部分
從全國、行業的信息化現狀分析入手，說明信息化是大勢所趨，再從本行業的產品特點出發分析信息化需要注意的關鍵問題，最后介紹企業的情況，特別是信息化的已有基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等，說明該企業已具備實施本項目的基礎。
引言部分可分為：
制造業信息化現狀
本行業信息化特點分析
信息化的基礎
現狀分析與診斷部分
從本項目所涉及部門的業務現狀描述和分析入手，找出問題，并提出相應的解決辦法。
現狀分析與診斷部分可分為：
業務現狀描述
問題分析與診斷
相關技術的發展現狀部分
主要介紹本項目所涉及的PDM/CAPP/CAD等技術產生背景、發展過程，以及發展趨勢等內容，并說明這些技術已是成熟的實用性技術。
相關技術的發展現狀部分可按軟件產品類別分別介紹，最后有一個小結。
公司相關產品的特點部分
主要介紹公司相關產品的主要特點，說明公司相關產品是符合其發展趨勢的先進和成熟的產品。
公司相關產品的特點部分可按軟件產品類別分別介紹，最后有一個小結。
公司具備的實力和基礎部分
主要從公司簡介、完整產品線、研發能力、實施與服務體系等方面，說明公司已有足夠的能力承接本項目，并以成功案例證明與公司合作成功率高、風險最低。
公司的實力部分可分為：
公司簡介
完整產品線
雄厚的研發能力
科學的實施與服務保障體系
成功案例
結束語部分
闡明公司愿與企業強強聯手，結為(戰略)合作伙伴關系，共同推進企業乃至本行業的信息化建設。
在結束語部分要明確提出合作建議內容，對于一些戰略合作伙伴關系不能輕易宣講和承諾，一定要經報公司批準之后方可承諾。
建議書的要求是簡短緊湊，內容詳實，便于用戶決策，可以在一份建議書中形成幾個可選方案，推動用戶決策。
二、解決方案的基本結構
解決方案的側重點是分析現存問題，提出功能需求及相應技術實現手段，并輔以實施保障措施，說明用戶需求是可以實現的。解決方案的基本結構如下：
引言
現狀分析與診斷
系統規劃與設計
系統技術方案
系統實施方案
服務內容及措施
典型案例
結束語
引言部分
從全國、同行業的信息化現狀分析入手，說明信息化是大勢所趨。再從本行業的產品特點出發分析信息化需要注意的地方。接著介紹企業的情況，特別是信息化的已有基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等，說明該企業已具備實施本項目的基礎。最后通過公司介紹說明有能力承擔該項目。
引言部分可分為：
制造業信息化現狀
某行業信息化特點分析
信息化的已有基礎
公司介紹
現狀分析與診斷部分
從本項目所涉及部門的業務現狀描述入手，分析出問題，并提出改進建議，得出實施系統的必要性和緊迫性，以及需要解決的問題
現狀分析與診斷部分可分為：
業務現狀描述
問題分析與診斷
系統規劃與設計部分
根據現狀分析提出的需求，對本系統從總體目標、指導思想、總體框架等方面進行總體規劃與設計?？傮w目標，是從企業已有明確的總體目標中，結合用戶需求提煉出來的，不能簡單照抄，還需適當調整與補充。總體框架包括體系架構、運行模式，以及其它企業關心的問題等。
系統規劃與設計部分可分為：
總體目標
指導思想
總體框架
體系架構
運行模式
……
系統技術方案部分
從基本功能介紹、關鍵問題解決方案兩個層面介紹具體的技術方案。基本功能介紹是對本項目所涉及的產品，在標準模塊功能基礎上適當補充各模塊的新增功能或用戶的特殊功能。關鍵問題解決方案是就企業特別關心的問題(包括管理和技術兩個方面)、企業特殊需求中有一定難度的問題，以及管理方面需要改進的問題等提出解決方案和建議。
系統實施方案部分
從本項目的預期效益入手，分析項目實施存在的風險，接著介紹公司規避風險的實施保障措施，最后給出初步實施進度計劃和培訓計劃。實施規劃要結合用戶的實施打算，如果系統規模比較大，可以結合用戶的需求適當進行目標分解，分期完成。
系統實施方案部分可分為：
預期效益
風險分析及對策
指導思想
指導方法
實施管理
實施規劃
實施進度計劃
系統培訓
服務內容及措施部分
從公司能為客戶提供全方位服務承諾入手，闡述公司技術支持與服務的保障措施，讓客戶無后顧之憂。
服務內容及措施部分可分為：
服務內容及承諾
技術支持與服務保障
典型案例部分
用公司典型用戶的案例進一步證明，公司提供的技術方案是先進的、實用的，形成一套科學的、可操作的實施方案。典型案例選擇的針對性表現在：行業、特殊需求、項目類型等方面有相似之處。
結束語部分
闡明公司愿與企業強強聯手，達成合作伙伴關系，共同推進企業乃至本行業的信息化建設。
解決方案注意業務分析，系統規劃，技術方案三部分不要反復出現重復的內容，或者為了表達自己技術方案是扣著業務需求而在系統規劃和技術方案中再次反復描述需求，如果發現有這樣的問題就要精心去組織方案提綱。
此外解決方案要避免浮夸和務虛的內容，要盡量讓用戶看到可操作的內容，例如在實施方案中用戶最關心的是在實施分幾個階段？每個階段相互配合工作是什么？誰去做合適？階段結束的標志是什么？每階段工作需要多長時間？根據企業實際情況有哪些風險？如何規避？基礎數據如何準備？歷史數據如何錄入？工作流程應用前后有何變化？這些是用戶真正關心的內容。
所謂實施方法論，實施原則，實施指導思想，實施團隊結構等看起來飽滿，其實是務虛的內容少寫，寫得越多用戶越不得要領，實施方案的要害是具備不具備可操作性。這里面的原則就是計劃越細化越具有可操作性。
三、投標書的基本結構
投標書是針對標書的解決方案，包含解決方案的全部內容，再增加公司優勢和相關附件。投標書總是原則是按照用戶提供的招標書要求準備，用戶要求如何提供資料就如何提供，不要任意發揮。
常見投標書的基本結構如下：
引言
現狀分析與診斷
系統規劃與設計
系統技術方案
系統實施方案
服務內容及措施
開目公司的優勢
典型案例
結束語
相關附件
開目公司的優勢
相關附件
相關附件按照招標書的規定組織附件。
為使方案具有鮮明的開目特色，方案必須具有一定的針對性。不同類別方案的針對性有不同的體現。
建議書的針對性體現在同行業的信息化特點分析，本企業已有的信息化基礎、本企業的現狀描述與問題分析等方面。
解決方案和投標書的針對性有相同的表現，主要體現在：同行業的信息化特點分析、現狀分析與診斷、總體目標、關鍵問題解決方案、實施規劃與進度計劃、典型案例等。
現狀分析與診斷部分、實施規劃與進度計劃部分，不能簡單把客戶名稱更改就變成另外一家的情況。
總體目標部分，有企業的個性，如果需要可以分解成近期、長期、遠期目標。
解決方案中可單獨把企業關心的關鍵問題單列為一部分，緊密結合企業的需求特點，不能簡單套用標準說法，必要時可以通過定制配置實現。
解決方案中的關鍵問題與投標答辯PPT中的關鍵問題有區別。投標答辯PPT中的關鍵問題主要是展示我們優勢部分，以攻擊對手的劣勢部分，但一定要有絕對的把握。
【轉載請注明出處】
浙公網安備 33010802003509號
杭州講師網絡科技有限公司
