今天準備對于IT項目售前解決方案的制作，對于一個軟件企業來說，往往會針對自己的產品線和產品形成一整套的售前解決方案類材料，其中包括了售前方案PPT，技術方案建議書，產品功能介紹手冊等。但是實際我們看到對于不同的項目應標，往往仍然需要客戶實際的需求對標準的售前方案材料進行修改和匹配。

售前項目支撐概述

對于售前項目支撐和解決方案編寫，特別是基于甲方客戶標書發出的技術規范書內容，如何結合公司已有的產品解決方案快速的整理售前技術方案建議書，這個是每一個售前解決方案顧問必須要掌握的關鍵技能。

今天繼續整理最近幾年的售前項目支撐文檔材料，在整理構成中有些關鍵思考記錄如下：

售前交流準備

進行正式的解決方案交流時候，前期的初步溝通很重要，主要包括了對客戶企業信息化建設基本情況，系統建設和集成情況，當前業務和IT管理的關鍵需求和痛點，是否已經立項和計劃建設時間，是否考察對其它的廠商等，這些信息的了解可以讓我們售前方案更加有針對性并揚長避短。

一開始就直接進行售前交流，講標準的PPT材料往往交流效果都不會太好，你覺得亮點的內容客戶往往并不關心。這也是我原來經常會說到的實際上很難有一個售前方案PPT文檔能夠支撐所有售前項目的情況，基本都需要基于標準模板文檔+客戶需求進行修正。

同樣，對于一開始就將自己擺在強勢甲方位置上的企業，往往這種售前項目我們支撐下來基本沒有中標的，這也印證一個道理，只有企業對技術尊重，對乙方尊重，認識到是合作伙伴關系往往項目才能夠成功。

多個售前項目支撐下來我們發現一個規律就是，企業信息基礎越是薄弱的企業往往越是不懂裝懂，而真正大的企業信息化建設部門往往才是一種謙遜合作的態度。

售前方案的講解，一般不能是純理論和產品解決方案介紹，更是要結合實際在以往項目里面的成功應用案例來輔助說明，如果有和甲方企業相同的同行業企業實施案例往往講解效果會更加好。

即所有的理論和產品特性，最好的證明方式就是已經在多個以往項目里面成功的得到了應用，而且取得了很好的效果。這個往往也是客戶比較看重的一個方面，從我們售前項目支撐和丟標來看，往往都是不同行業項目實施案例會導致甲方評估時候減分。

售前方案材料

售前講解方案的發送最好是以pdf方式進行發送，如果做的再好一點應該是每一個發送的pdf文件都應該標準清楚是發給哪個客戶的。因為我們仍然會發現一些情況，就是我們的產品解決方案類材料會被放到互聯網上面，由于一個pdf沒有標記給到多個甲方導致也很難清楚究竟是哪個甲方導致材料泄露。

其次，對于材料發送個人建議是在正式應標前只發送ppt類材料，而對于詳細的技術方案建議書并不適合在應標就發送給客戶，特別是類似詳細的word文檔材料。因為我們也發現很多企業往往僅僅是為了要你的材料找你溝通，這種情況并不在少數，一個很簡單的判斷方式就是甲方給你電話溝通，也不問你們公司的規模案例，產品情況，就直接的找你要材料，很多時候都屬于上面這種情況。

售前支撐階段

對于售前項目當前狀態可以分為幾個階段，具體理解為

• 階段一：前前期，客戶僅僅是想了解下相關的產品和技術，有潛在的需求但是不明確

• 階段二：前期，客戶已經有項目立項計劃，在進行立項申報和產品選型，準備立項

• 階段三：中期，客戶項目已經立項，在進行供應商選型和產品交流，產品POC測試等

• 階段四：晚期，項目可以發標，可以在互聯網上搜索到客戶的發標公告

而對于這四個階段可以看到，最佳的是階段二和階段三，對于階段一實際離項目立項還有很長的周期，對于階段四本身由于你沒有前期介入已經被其它的供應商技術控制基本也沒有機會。

對于階段二往往是介入的一個關鍵點，而且可以做到很好的引導客戶，體現我們產品的優勢和實施能力，同時協助客戶完成技術規范書編寫增加我們的技術亮點并體現差異化，回避我們產品的弱勢能力等。由于階段二到最終發標之間還有一個很長的周期，務必要做好的就是市場人員對客戶和項目的持續跟蹤，對中間過程引入的變化因素的判斷和決策，類似中間過程有其它的供應商必選進入等。

對于階段三也是一個很好的介入點，但是更加重要的就是很好的市場和客戶關系，如果沒有很強的客戶關系在階段三介入往往機會也不太大，除非是客戶在階段二本身就沒有相關的競爭伙伴參與過交流和引導。如果甲方強勢的推薦你，在階段三接入往往沒有任何問題。個人理解如果客戶或甲方沒有明確的表示過強勢的挺你做這個項目，基本都代表客戶有其它意向人選，你可能是去陪標。

那么最終客戶發標后是否投標也就簡單了，你可以從最終的技術規范書來分析和判斷，你提交過的技術材料和優勢能力是否在規范書有體現，還是說規范書全部體現的競爭對手的技術指標。如果是第二種情況那么基本沒有機會中標，也沒有必要再進行應標和售前投入。

售前方案PPT材料的制作

對于軟件類項目售前方案交流和講解相對重要，一個是宣講的材料，一個是宣講過程兩者都不能少。針對售前交流我原來一直的觀點就是對于初次交流不要講解PPT材料，先做非正式的溝通，溝通的目的是了解對方業務需求，存在的問題，項目建設的背景等信息，只有了解了這些才能夠有針對性的準備售前方案材料。

對于售前方案的準備，主要應該包括如下關鍵步驟：

1. 標準售前材料PPT材料準備

首先還是要先準備標準版本的PPT宣講材料，首先是統一標準的模板和呈現風格，其次是按照不同的產品，平臺或系統分別準備不同的PPT宣講材料。對于這類標準材料里面主要包括了公司簡介，項目概述，業務解決方案，系統解決方案，實施方案，項目案例幾個章節。

每個PPT宣講材料應該做到可以拿出去獨立講解用，比如對方只關心MDM主數據產品，那么MDM的宣講材料就能夠獨立講解。即使前期沒有了解客戶的詳細情況，也可以對標準版本的PPT材料進行講解而不需要做任何額外的補充。

2. 需求+受眾

不僅僅是針對售前方案PPT材料，對于所有的PPT宣講材料的準備都必須要清楚的理解需求和你的目標聽眾。否則你講解的內容很可能不是客戶最終希望聽到的或者想要的內容，而導致售前交流效果很差。對于需求部分，前面講了可以先進行一次非正式拜訪和交流，了解清楚客戶真正關心的內容，希望解決的問題，然后再有針對性的進行材料準備；當然如果不方面，也可以先準備一個簡單的調研問卷或問題收集，或者電話溝通等了解對方真正關心的內容。

其次是受眾，究竟是誰聽這個材料？

對于業務部門人員，信息化部門的CIO還有信息化技術人員，不同的受眾關心的內容差異很大。業務部門會更多關心方案解決的業務問題，達成的業務目標；CIO關心的是方案體現出的IT部門價值，關鍵功能特性，包括后續的管控和接維，而下面的技術人員關心的則是是否采用了先進技術，技術架構和技術優勢等。

所以我們在準備材料的時候一定要注意最核心的受眾是誰，要讓誰滿意或認可方案。

3. 關鍵匹配：客戶需求-》解決方案

這一步我始終認為是準備一個PPT方案最為關鍵的內容，即如何從客戶需求映射到解決方案上面，因為到解決方案中的模塊組件本身就是我們已有標準模塊化素材的組裝，沒有太多要調整改動的地方。但是從客戶需求到解決方案則是不同的客戶，不同的項目都需要重新準備。

即基于項目背景，闡述我們對客戶問題或需求的理解，然后基于該理解給出一個解決方案。同時也可以詳細說明如何從需求轉到該解決方案的，或者解決方案如何能夠解決最終的業務需求和目標的。首先要讓客戶理解這個大框架，這個理解清楚了再將解決方案里面的模塊逐一展開進行描述。

比如一個大的平臺建設項目，基于前期調研溝通，我們發現了客戶存在基礎數據不一致，接口混亂無法關聯，端到端流程存在斷點無法貫通，接口改造在多方聯動的時候經常導致問題而回退，業務人員在處理業務的時候不清楚一個完整的業務流走到哪里了？可能還有很大問題。

我們經過分析后給出了一個完整的平臺方案，里面包括了技術平臺，MDM主數據平臺，SOA集成平臺，BPM流程平臺，門戶和4A管理幾個大的組件。那么就需要講清楚這些子模塊是如何銜接起來的？其次要講清楚客戶的需求或問題是如何通過提供的子系統解決掉的。這個整體解決方案客戶理解清楚后，客戶就有了一個完整的概念和框架，然后再展開詳細描述就容易了。

如果這個大框架都沒有理解，一下就過渡到你自己的產品講解，那給客戶最大的感覺就是賣產品，而且和客戶的需求脫節。對于賣數據庫，中間件等產品類售前可以這樣，但是對于實施項目售前這樣操作就完全達不到預期目標了。

4. 搭建整體架構和框架目錄

前面想清楚后可以詳細細化整體PPT的框架目標，注意仍然是要根據客戶實際情況進行調整，大致仍然應該是包括了項目背景和概述，整體解決方案，產品解決方案，實施方案，項目案例這幾個關鍵內容。對于項目背景概述，整體解決方案是需要重新編寫或者做出較大調整的內容。同時通過解決方案將需求和后續的產品解決方案有效的銜接起來。

整體解決方案很重要，后續的內容分解也完整遵循金字塔原理的思路進行分解。

因此整體解決方案中的各個子系統或組件如何集成？關系如何，以及整體解決方案如何解決目標和問題的，都需要在整體解決方案部分闡述清楚。

5. 細化和揉合完整方案PPT內容

到了最后一步，重點就是基于構建完整的框架和目錄結構填充內容。這個時候原來我們準備的很多標準材料內容就可以完全拷貝過來了，也正是這個原因最好所有的售前材料都采用標準的PPT模塊格式，防止拷貝過程中再去做格式的調整。基于經驗實際上需要新寫和調整的內容應該是20%左右，而80%的內容都應該可以復用以前的材料。

在以前的材料拷貝過來后，仍然需要根據目標聽眾的情況來考慮哪些內容要刪減，哪些地方可能還需要根據客戶實際情況進行1-2頁的細化補充。這些都屬于內容細化和揉合必須要考慮的問題點。

再簡單點來說，最終一個完整的售前PPT需要回答兩個關鍵問題，其一是我們提供的解決方案可以有針對性的解決企業的問題，達成企業目標；其次就是公司本身產品，技術和團隊積累優勢，同時說明提供的實施團隊經驗豐富能夠完全勝任項目。

售前解決方案框架搭建舉例

在這里以自己準備一個完整的ESB服務總線解決方案售前材料舉例來說明。這類解決方案既是以產品為核心，但是又不是單純的一個產品介紹PPT材料，讓客戶意識到產品本身是解決他們問題的，而不是單純的賣產品。

因此要準備這個PPT材料，往往首先就需要搭建完整的內容框架，這個內容框架的搭建可以直接在PPT里面進行，也可以通過Word文檔或思維導圖進行。在整個框架的搭建過程中，我們基本就會將每個大章，每章節里面的每個小節或者細化到每頁要談哪些內容都考慮清楚。

01-概述和導入部分的內容

Page1：企業集成場景的出現

企業業務本身是連貫的，但是支撐業務的IT系統為了建設方便往往會拆分為多個IT系統，這些系統之間必須集成和協同起來才能滿足業務需求。集成一種是橫向業務流程的協同集成，一種是縱向的數據能力共享集成。

已有的IT應用架構下，當存在新系統建設和規劃時候一定存在集成，從橫向業務流來看一種是前端系統，一種是中端系統，一種是后端系統；從縱向來看，一個是數據共享和分發，一個是數據采集和分析。而這些都需要通過集成來解決。

正因為這個原因，企業內集成主要是業務集成和數據集成，存在實時和非實時，存在大并發，大數據，大文件等不同的集成場景。這些都是在集成時候需要考慮的問題。

Page2：企業當前集成的做法和問題

企業當前一般采用點對點網狀集成的模式，在這種集成模式下存在接口不規范，無法復用，開發工作量大，接口管控運維困難等諸多問題。因此首先要對問題進行分類：

• 接口需求問題：接口需求的分析，復用的判斷，服務目錄規劃和梳理等。

• 接口開發問題：接口設計和開發，接口測試等層面的問題。

• 接口管控問題：涉及到接口安全，日志監控分析，變更影響分析困難，運維困難等。

• 標準規范問題：接口實施標準的方法論，規范標準模板定義（需求規范，開發規范，接入規范，消費規范）

Page3：企業內集成場景分析

還是要單獨說下企業內的集成場景，包括了業務集成和數據集成，包括了實時和非實時，大并發和大數據等不同的集成場景。這個我們在前面專門做過企業內集成場景分析的一頁PPT。

正是由于存在不同的集成場景，因此就存在類似ESB(WS服務+JMS）, ETL或ELT，MFT文件傳輸等不同的集成工具和集成技術和實現方法。在這里要把這個說透徹，即針對不同的集成場景需要采用不同的集成技術，而不是一種技術或工具來解決所有問題。

由于需要有不同的集成技術，我們就需要一個提供一個完整集成技術和工具的產品，而不僅僅是需要一個單獨的ESB服務總線即能夠解決問題。

Page4：完整的SOA集成平臺解決方案

完整的SOA集成平臺應該解決和覆蓋所有的集成場景，因此應該是提供一個完整集成解決方案（包括ESB能力，ETL能力，文件集成能力），同時包括服務目錄提供和最終能力的開放，包括SOA治理和管控。同時能夠滿足企業大數據，大并發的集成需求。

注意在這個解決方案里面，ESB不是全部，而僅僅是SOA集成平臺的一部分。所以我們當前的SOA整體產品方案是完全能夠滿足企業多方位集成需求的。

Page5：建設和實施SOA集成平臺為企業帶來的價值

價值的闡述應該從業務和技術兩個方面來進行闡述和說明。

• 從業務層面：業務協同更加連貫，業務系統響應業務變化更加敏捷，原有業務斷點減少，數據不一致減少。

• 從技術層面：實現IT集成架構標準化，IT服務資產顯性化，IT管控治理可視化，業務和IT匹配可跟蹤化。

原有的IT掌握在業務系統建設廠商手里面，實施SOA后新的IT架構掌控在IT部門手里面，IT部門要打開原有廠商黑盒，實現關鍵服務能力的暴露和管理，正在銜接好業務和IT協同的中間層次。比如一個端到端的流程優化項目，IT部門完全有能力在中間起到這種協同作用，業務驅動IT，IT只有明白了整體架構才知道如何更好的和企業端到端業務協同和服務。

02-SOA產品解決方案

Page1 產品整體架構介紹

前面第一部分講解完成后直接進入到產品介紹，那么這里首先就要有一個關鍵過渡，即前面講到的接口需求類，接口開發類，接口管控類，接口運維類四類關鍵需求如何對應到SOA整體產品架構上面。

給出SOA產品架構，里面分子系統和模塊，然后將關鍵需求和這些子系統和模塊對應上。接口開發類的更多對應到ESB引擎和設計器能力，接口管控對應到服務全生命周期管理和自服務流程，接口運維類對應到SOA整體監控運維解決方案，而接口需求對應到我們整體前期服務規劃，咨詢中的服務識別和定義。

Page2 產品的關鍵特性說明

產品如何講？

應該從三個方面來講比較合適，一個是產品關鍵的技術能力有哪些？一個是產品對服務全生命周期管理和實施過程的支撐，一個是產品對后期SOA管控和治理方面的支撐。

Page3 產品的關鍵技術能力（可以有多頁）

在這里只拿ESB產品來說明如何對關鍵技術能力進行描述，這里需要描述的關鍵技術能力仍然是基于標準的ESB產品功能架構展開，對里面的核心技術功能進行描述。

• 適配器（支持DB，JMS，SOAP，Rest各類適配）

• 協議轉換和內容轉換能力（協議的轉換能力，消息格式的轉換能力）

• 大數據集成能力（包括大數據集成，大文件集成能力）

• 消息集成能力（單獨提，包括消息1對多，消息發布訂閱場景等）

• 安全能力（戶名/密碼，Token，IP控制，傳輸安全，數字證書）

• 服務代理（即傳統說明的服務透明）

• 服務路由（對服務靜態路由的支撐，動態路由的支持能力）

• 日志能力（記錄服務詳細運行日志）

• 大數據集成（類似基于大數據平臺技術的大數據實時采集和集成能力，需要新增，特別是對MES集成）

Page4 產品的服務實施過程支撐能力（可以多頁）

服務開發和實施整個過程是如何的？原來的服務實施方法論流程圖可以進一步簡化，先把服務實施整個流程說清楚，接著再說明服務實施整個過程，當前的的集成平臺是如何支撐的自動化和自服務化。如何支撐服務定義，服務設計，服務開發，服務測試，服務部署上線的完整過程管理。

• 服務定義過程（服務元數據管理，服務目錄，服務查詢，服務視圖瀏覽等）

• 服務接入過程（服務如何自服務的接入，服務接入申請，服務自動化測試，服務部署和開通）

• 服務訂購過程（服務訂購，訂購后服務開通）

• 服務變更過程（服務版本管理，服務變更，服務變更后的測試和上線等）

Page5 產品提供的管控和治理能力（可以多頁）

管控和治理能力包括后期的服務監控和運維能力，實際上很多大的SOA產品套件這塊都是獨立的子產品。因此對于這部分內容需要單獨進行描述。

• 服務日志查詢（詳細的服務日志查詢能力）

• 服務運行分析和統計（服務運行次數，運行時間，并發數，服務運行異常情況）

• 流量控制能力（提供完整的流量控制能力）

• 服務監控預警（監控策略設置，監控告警，告警通知等）

• 服務報表能力（各種服務可視化的展示圖，包括設計器圖表和服務運行圖表）

03-SOA實施方案和流程說明

對于原來我們偏重的SOA實施方案需要做調整，即給出一個適合客戶自己進行的快速實施解決方案和實施方法。第一步的重點仍然是先將接口統一管理起來，其次再次考慮接口本身的粒度和復用性。要講清楚，當前產品支持兩類方式實施和接入，一種是契約先行模式下的，一種是歷史接口直接接入和發布。

Page1 產品實施工作流程

產品實施究竟包括哪些工作，其中包括了SOA平臺的安裝和部署，環境安裝后的驗證，產品的培訓，各種典型服務開發的示例和說明。SOA實施流程和規范，標準化流程的指導，整個SOA管控治理體系的建立等。

Page2 產品部署架構

產品的安裝和基礎環境搭建，講清楚部署架構，需要的軟硬件資源準備。建議的硬件服務器和資源準備，部署架構需要進一步描述產品的高可用性架構，產品本身的可擴展性。

Page3 產品交付文檔清單

產品最終的交付文檔清單，包括了產品開發手冊，產品運維手冊，服務技術標準規范體系等。同時也包括SOA技術標準規范，SOA服務實施方法論一系列文檔（服務規范，服務開發和接入指南，服務消費指南，服務設計規范，服務測試規范等）。

Page4 產品培訓

產品培訓說明，講清楚會做哪些培訓？同時說明針對不同場景都會做一個Case案例方便客戶快速掌握。其中包括了SOA基礎培訓，服務開發和封裝接入培訓，SOA管控和運維培訓等。

產品成功案例介紹

實際上應該是一個代表性的案例詳細介紹，其余只給出客戶名稱和粗略的表格式介紹即可。

售前方案Word材料框架和匹配案例分析

以要做一個智慧校園的解決方案材料來進行說明下，背景是我原來做企業內部信息化開發和需求工作，主要涉及到CRM客戶關系管理系統，熟悉軟件工程和軟件生命周期，對ERP也較為熟悉，有過需求分析和調研經驗，做過CRM軟件項目的售前解決方案并進行過宣講。可以看到這不是要給完全跨新領域的工作，而是一個已有IT領域的延展性新工作。

第一步思考：破題-不破不立

首先要考慮的仍然是破題，即智慧校園解決方案 = 智慧和信息化+校園業務+IT解決方案。

即以上三個方面的內容都了解清楚后你才可能做出一個完整的智慧校園IT解決方案，而實際經過初步分析得出的就是我只有IT解決方案經驗，而沒有智慧校園方面的經驗，即我們要做這個事情還是存在技能和經驗差距的。那這個時候的匹配就是：

業界做法+我已有的知識經驗=》達成目標的完整框架邏輯

對于業界做法很簡單，需要的就是網上搜索和瀏覽大量的資料，這里面本身包括兩個方面的資料

• 智慧校園的解決方案材料

• 校園信息化和主要業務的資料

大量資料瀏覽后需要的就是對比，拆分出各個資料里面的關鍵項目，最終再去考慮如何基于我們自己的目標整合為一個完整的方案。

我已有的經驗是基于IT解決方案的，即對于寫一個IT解決方案一般會涉及到項目背景和概述，總體解決方案，實施方案幾個方面。有時候對于總體解決方案本身又分為業務解決方案，技術解決方案。對于技術解決方案本身又分為技術架構設計，功能架構設計等更加細化的內容。

不論是哪種，我們對于IT解決方案經過總結和歸納后會形成一個關鍵經驗點，核心思路即：

1. 提出問題（背景，問題和現狀分析）

2. 總體設計（建設的目標是什么？這個目標達成的總體架構設計是如何的？）

3. 詳細實現（我們的解決方案是如何解決和達成目標的，詳細過程和思路是如何的？）

可以看到，這個通用的IT解決方案的思路對于做智慧校園IT解決方案的時候也適用，那么我們需要做的事情實際很簡單，即：

將搜索到的業界做法和網上參考材料整合到你前面形成的大框架中。

同時可以看到，這個跟做CRM解決方案時候有兩個大的陌生點，其一就是校園本身的業務究竟是如何的我們并不清楚？其次就是一個校園信息化的整體框架我們應該如何搭建？只有這兩個問題都想清楚后我們才能夠形成初步完整框架。

可以看到只要我們大IT解決方案思路和邏輯清楚，要做智慧校園解決方案并不是難事，我們需要學習和補充知識，同時由于本身又做過需求收集和分析方面的工作，因此要學習和熟悉校園業務也很容易。

第二步思考：搭建大框架和結構

什么叫搭建大框架和結構？

簡單點來說就是一個新的陌生領域你需要基于搜集的業界做法加上你已有的知識經驗快速的搭建一個概念模型，這個概念模型就是梳理清楚一件事的關鍵框架和結構，把核心的內在邏輯，演進和推導關系想清楚，確保框架中的每項內容是承上啟下，相互銜接為一個整體的。

金字塔原理說清楚很簡單，但是實踐起來卻不容易，你需要的就是先從大框架開始就把結構想清楚，確保邏輯完整。

實際上大部分人在做解決方案的時候沒有把這點想清楚和透徹，更多看到的場景是網上搜索到一個或二個智慧校園的IT解決方案，就開始簡單的拼湊和組合，最終交付一個解決方案，而里面的內在邏輯是如何的自己也講不清楚，這種解決方案沒有太大的價值，也經受不住拷問，同時更加不利于自我的學習實踐和技能提升。

下面我們來看下如何搭建這個框架結構出來。我們先分析網上搜索的一些材料

材料1

• 總體建設思路（現狀和問題分析，智慧校園和傳統校園信息化區別，建設目標，演進路線）

• 技術方案（重點是總體架構設計，包括了業務層面和技術層面總體架構）

• 應用方案（主要是基于技術方案架構模塊展開的各個子系統詳細介紹和說明）

材料2

• 概述（現狀和問題，建設目標）

• 總體建設方案（建設思路，建設原則，頂層設計（業務，技術，數據等方面））

• 子系統介紹（各個子系統的詳細介紹）

• 實施方法論（項目實施方法，進度，資源投入，風險管理）

材料3

• 建設思路（政策背景，核心理念，建設目標，建設內容）

• 建設內容（應用系統建設，共享數據中心建設，云平臺建設，保障和運營機制建設）

• 建設成效（應用展示，建設收益分析）

收集和學習資料的目的就是要綜合對比這些資料，并結合我們已有的做IT解決方案的思路，給出一個做智慧校園IT解決方案的整體框架。

由于我們是做一個通用性質的解決方案，因此初步考慮并不會去分析某個學校實際經過調研后的現狀和問題，因此基于前面的分析和歸納，應該理出一個大的框架邏輯。

1. 提出問題

2. 總體設計（建設原則，業務總體架構，技術總體架構，集成架構，管控架構）

3. 詳細解決方案（分解后的各個子系統介紹，最后再增加子系統間協同介紹）

4. 實施方案（重點介紹標準的實施方法論，各個實施階段的關鍵工作和內容）

這里面關鍵還是要把校園業務搞清楚，包括各個業務之間的關系，同時搭建總體架構要考慮分析，可以基于平臺+應用的思想來構建一個總體框架框架，如（基礎云資源層，平臺層（共享數據中心，服務總線平臺，流程平臺），應用層）等。到了應用層再按理解清楚的校園業務將信息化分解為各個大的業務子系統和功能模塊。

1. 現狀和問題要通過建設思路映射到目標上，實現問題和目標的匹配

2. 目標的達成要分解到具體的架構設計中的各個模塊上，實現目標到實現的匹配

3. 各個子模塊實現要詳細描述清楚，回答交互邏輯和可實現性

以上內容都做到了，你就會發現整個解決方案的各個部分會形成一個相互銜接的整體，每部分內容都不散而且是相互集成在一起并承上啟下的，這就是搭建總體框架形成的關鍵概念模型。

實際上到這個步驟，你對于里面的類似在線學習，教學評估各個子系統并沒有詳細深入去了解，但是這個不影響你搭建出上面的這個大框架。

第三步思考：逐層求精，層層匹配

在第二步大框架搭建完成后，其實你心里就應該有底了，即整個方案應該如何做出來，包括其內在邏輯是如何的。但是要成為一個完整的方案還有很多工作要做，里面的很多點你都還需要進一步去分解和落地，即通過詳細解決方案和實施方案真正解釋清楚你規劃的總體架構和頂層設計是可以落地的，所以你必須要把how to 如何做，如何落地方面的事情講清楚才行。

那么如何解決如何做層面的匹配呢？

這個匹配是我們完成一個新領域的第二個關鍵所在。搜索很多時候解決的都是目標到目標的匹配，而這里我們要解決的是如何通過詳細的過程和步驟達到目標的匹配，即：

Process（Step1->Step2->....->Stepn)==>Goal1

要把這個搞清楚就必須進入到事物內部的運行機制和運轉邏輯了。

舉個簡單的例子，客戶需要爆米花，你給出了一個爆米花機那么就是最簡單的目標匹配，而下一步你需要回答的就是爆米花機如何將玉米+白糖變化為一個個爆米花的。要回答這個問題你就必須知道和清楚爆米花機內部的運轉機制。

在第二步搭建總體架構的時候我們更多的是采用了靜態分析和架構搭建的思路，而到了這個步驟更多的就需要用動態分析的思路，解釋清楚流程，包括如何通過流程達到目標。

即這個步驟的關鍵是動態分析，而動態分析的關鍵是流程分析，而流程分析本身又必須要把關鍵活動，活動的輸入和輸出搞清楚，即流程的各個階段和活動節點本身是相互銜接和無縫集成的。

舉例來說，當我們開始講在線學習子系統的時候，我們就需要考慮E-Learning系統本身內部各個模塊之間是如何動態協同完成最終的業務目標的，從課件準備，到學員學習和培訓，再到后面練習，最終的考試評估如何形成一個完整的閉環體系。

這個理解清楚了那么我們的整體系統內部運轉機制就理解清楚了，再通過這個動態分析分解出培訓子系統，學習子系統，考試子系統，知識庫等各個子模塊就有理有據。

如何在第二步我們是以自頂向下的思路完成了總體框架的搭建，那么到了第三步我們可以用自底上的思路將搜集到的各種材料，學習到的內容安裝目標要求進行組合和整合，形成一個完整的整體。先組合和整合完各個子件，然后再將各個子件最終集成和裝配到完整的總體架構設計框架上面。

即搭建整體框架的時候是從樹木到樹干的分解和梳理過程，而到了詳細解決方案的時候是從各個細枝末節組合到樹干上的裝配過程，兩種最終銜接好就完成了一個高度整體的解決方案。