歷時乙個星期的××地稅資料倉儲投標書從昨天開始受到了各位領導嚴重批評，總體來說我寫的方案一無是處，只能作為陪標的乙份標書。心裡很不是滋味，一周的辛苦白費不說，給領導留下的印象一定是能力極低。
思前想後，覺得各部門領導們的意見還是很有道理的，從不同的高度，用不同的方式看待乙份投標檔案應該具備的內容，側重點在**，哪些客戶最關心，哪些應該具體描述。總結一下，死也要死個明白：
首先再說一下為了盡量改進一下我的標書，昨天上午臨時新增了乙份點對點應答書，書中對於投標要求中的所有問題一一進行了簡單的描述，很多都是「見標書 xx 小節」，因為時間的關係。在寫這份點對點應答書的時候，就發現一些問題在我的投標書中沒有對應的描述，或者沒有很明確的回答。所以在以後做投標書的時候，乙份點對點應答書是必須的： ü
可以檢查你的方案是否涵蓋了需求書中全部的內容 ü
可以最直觀的反映出方案中你用什麼技術、方法來實現這些具體的問題 ü
也許因為問題沒有連貫性，所以如果在投標書中體現的話，整個標書的結構會很散，所以單獨乙份點對點應答書是必要的
下面總結一下投標書應該包含的內容： ü
總體目標
每個專案都應該有乙個明確的目標，業務上的，技術上的。目標應該是高層次的，概括的。乙個專案的目標可以有多個，比如業務和技術的目標就是兩個，技術是為業務服務的，分開寫會顯得比較專業。每個目標都應該用一句話就可以說明白，要精練到只用一句話描述每乙個目標。 ü
總體規劃
規劃就是你打算如何實現這個專案。在下面有乙個詳細的實施規劃，總體規劃應該是實施規劃的概括，比如說計畫分 n 步 實施，每一步都要達到什麼效果，實現什麼目標或者子目標。在投資料倉儲的專案時，因為客戶對資料倉儲的認識和使用本身就是乙個逐步認識、體驗的過程，所以 資料倉儲一般會包括資料倉儲基礎平台的建設（資料集中、資料規範、資料質量等等）、報表、關聯查詢、主題、資料探勘、決策支援這些步驟，對每乙個步驟的認 識、應用、和實現都可以是由簡到繁的，可以把幾個步驟合在一起，先進行簡單的實現，然後在通過使用過程中隨著認識的加深，再通過迭代的方式重新實現。提到 重新實現，就會出現兩種方式：推倒重來還是在上次的基礎上更新。這就是下面體系架構應該考慮的問題。 ü
業務分析
怎麼分析業務呢？其實我也不知道，業務分析對我來說是木桶理論裡面最短的一根。對於現在我經常遇到的稅務行業的資料倉儲專案來說，每個專案都會出現大量的報表，這些報表大多都是稅務徵管系統（ oltp 系統）中報表，一般是按照功能模組分類的。業務分析也許應該包括兩大部分：客戶的日常業務需求和用於統計分析的業務需求。 n
日常的業務需求在需求報告裡面都可以得到，這也是客戶最熟悉的，怎麼分析，那真要業務很熟練才行，瞎編可不行！我就沒編，所以領導們都看出業務需求分析這部分我寫的非常不夠，沒錯！我是真不知道怎麼分析。 n
統計分析的業務需求，現在稅務行業主要是各種主題分析，指標分析，再多說點就是怎麼利用資料探勘來挖掘和**新的需求和行業變化。
上 面都是和業務直接相關的，還有重要的一點要說明的是要明確方案建議書和投標書的區別，文件的目的不同，導致文件中要突出的重點不同。個人感覺投標書比起方 案建議書來說，目標更加明確，專案的範圍界定比較清楚，所以在進行上述三點描述時側重點不一樣。投標書應該緊緊圍繞著需求書中的具體需求來寫，與點對點應 答書中的答案相對應；方案建議書就可以略微天馬行空一些，但一定應該是熟悉業務人來行空才行！
下面應該是和技術相關的內容： ü
技術架構
n整體架構
最 近一段時間寫的都是和資料倉儲相關的建議書和方案，其實從資料處理的角度來說，資料倉儲技術只是處理資料的一種手段，它採用的技術和一般的業務系統（事務 型業務系統）不同，所分析的資料的資料結構也和業務系統不同。但是它應該是和業務系統並列的，對於客戶來說，它們完成的是不同的業務需求。從技術角度來 看，它和其他業務系統一樣，都要有一些基礎的、共享的基本架構。 ²
二層架構 ²
三層架構（ jsp + servlet 或者 j2ee ） ²
安全架構 ²
日誌、審計架構 ²
監控架構
我這次寫投標書把這部分忘了，雖然以前做了 n 年的三層架構，也許是因為公司以前的資料倉儲建議書裡面沒有寫這部分，需求裡面寫了，但我看了沒有引起太多的注意。
資料倉儲好比是魔術大變活人裡面最後變出的美女，而這些基礎架構就是魔術中使用的其他道具，每個人都期望變出不同的東西來滿足自己不同需求，不管是金錢、美女還是野獸。
n資料倉儲架構
這部分相對來說是最容易掌握的，對於喜愛技術的人來說。在設計資料倉儲架構之前，應該清楚的了解現在客戶面臨的實際的技術難點是什麼，要解決和擔心的問題是什麼。資料倉儲涉及的技術問題無非就那麼幾種： ²
架構上的： edw 還是資料集市、 ods 還是非 ods 、實時的、準實時的還是不帶實時帽子的 ²
設計上的：資料整合、資料規範、資料的處理、資料流程的定義、元資料的管理 ²
效能上的：抽取的速度、抽取的資料量、資料倉儲儲存的資料量 ²
安全上的：資料的質量、資料的監控 ²
模型上的： molap 、 rolap ²
展現上的：圖表、儀錶盤、鑽取、旋轉、切片
在 描述這部分的時候，非常容易寫的比較原理化，俗話說先禮後兵嘛，對於不很了解資料倉儲的客戶這部分多寫一些，通俗一些，我覺得挺好。但是如果寫的是投標書 的話，那麼應該把如何實現說清楚，因為需求中會有清楚的要求和建議，希望做到什麼程度，希望你用什麼來實現，希望到達什麼效果。但是與點對點應答書相比， 如果按照點對點應答書的順序或者思路來描述的話，可能在結構上會比較鬆散。我覺得還是應該按照上面的分類來描述，把如何實現放在每部分的內容中去。
**並茂效果最佳
先在頭腦裡面把這些問題想清楚，在頭腦中逐漸形成大致的輪廓，落實在紙上用圖的形式體現，要能從圖中清楚的表達你的意思。圖可以分多個層次， high level 的， low level 的，整體的，描述某一部分的。曾經看過一遍報道，講乙個華裔的聯合國 it 職員，他在寫系統的使用者手冊時，手冊的第乙個讀者是大廈的清潔工，如果清潔工明白了，手冊就算通過了。當然聯合國的清潔工也許學歷也滿高的呢。圖畫出來了，文字圍繞圖來運籌，就能讓讀者看著明白，讀著舒心。以終為始，這句話真好。不過說的容易，做起來要多練才行。
ü實施規劃
實施的規劃如同方案的編寫，同樣都是從需求入手、分析需求、整理規範、設計、開發、測試、維護，再加上如何進行專案管理，突出管理的重要性，因為其他的部分前面都描述過，只要條理清楚就行。 ü
案例介紹
以前還真沒好好想為什麼寫案例，如何寫好案例？這次通過寫方案得出的教訓是案例不是湊數的，是有目的的。目的是告訴客戶你不光有能力寫好方案，還曾經做好過類似的專案。所以案例分析除了介紹案例的業務、技術、環境、專案過程等情況，還要分析已經做過的專案和現在要做的專案的異同，也應該從業務、技術、環境、專案過程來分析。所謂突出重點，這就是重點。
其他還可能包括： ü
專案預算
ü產品清單
ü技術支援和服務
再說說寫方案、標書時應該注意的幾點習慣和方法：
寫方案、標書最大的威脅之一，就是拷貝貼上。拷貝貼上的目的是為了節省時間，不是為了迷惑客戶。在拷貝貼上前要清楚這些內容是完全符合你的要求、還是部分符合你的要求、還是帖不帖都一樣、再不是就是為了迷惑客戶使他不清楚你在講什麼。有的時候是因為時間緊，或者沒有太好的詞語表達自己的意思， copy 沒有什麼過錯，錯在不知自己在 copy 什麼，知道了就沒錯了。
替換也是在修改方案時會用到的操作之一，千萬不要完全替換，除非你非常有把握，否則浪費的不止是時間，還可能使你的內容變得千瘡百孔，面目猙獰。
就像河間的驢肉燒餅、天津的煎餅果子一樣，蓬天的方案和標書在業界是有名的優秀，要深度有深度，要厚度有厚度，希望大家集思廣益，說出自己的心得體會，努力維護和發揚蓬天公司特色中的特色。
解決方案怎麼寫
網路安全解決方案 寫方案不難，知道怎麼寫才難。關於寫方案我只總結一點，結構化地去組織你的思想。有結構就有思路，有思路就有方案。另外真正寫方案的人，對自己寫過的方案是永遠不會滿意的，只有這樣，每次都會進步一點點，解決方案水平質量就會隨公司能力不斷增長。當然我曾經問過很多人，你到底為什麼寫不出好的方案呢...
投標方案應該怎麼寫？
我寫這個可不是為了傳授或布道哦，我寫過一些投標方案，但是總想聽聽大家是怎麼寫的，都注意些什麼。所以，兄弟我先扔塊磚，大夥兒有玉的砸過來 前面幾天在寫乙份投標方案。連續幾天搞到晚上10 00以後，週末還搞了個通宵，昨天去投了。總算乙個包袱卸了下來，結果怎麼樣也顧不上了，大家都說 盡人事，聽天命吧。呵呵...
備品管理方案怎麼寫 產業園區規劃方案怎麼寫？
眾所周知，做產業園區規劃，最重要的是寫好產業園區規劃方案。那麼產業園區規劃方案怎麼寫?今天給大家分享專業人士的產業園區規劃方案文字知識，給大家做個參考。一 前期調研 綜合運用各種理論分析工具，從當地實際狀況出發，充分考慮國際國內及區域經濟發展態勢，對園區產業發展的定位 產業體系 產業結構 產業鏈 空...