門戶專案特點以及專案策劃

1.1 門戶專案特點介紹

門戶平臺提供了使用者個性化，統一訪問應用、內容流程、人員資訊的單一入口功能，提供了整合的來自其 他 系統的內容和應用，以及使用者統一、協作的工作場所。門戶是一個 開 放、標準的平臺，主要以 Portlet 釋出各種應用，以配置方式組裝內容，提供安全、整合等服務。

從技術方面 講， 門戶平臺本身是一個標準的 J2EE Web 應用，是 J2EE 技術 的 綜合應用， Portlet 也是一個可被門戶平臺管理 的 小型 Web 應用。門戶平臺一般提供了 Portlet 容器和 WCM 功能，遵循的最新標準分別為 JSR286 和 JSR283 。

門戶專案是基於門戶平臺交付的專案，門戶專案是一個 以 整合為主的專案 ， 具有以下特點。

—  涉 及 眾多的業務系統和不同級別 及 崗位的使用者群體 。

—  門戶專案一般不針對具體的業務，對於系統功能終端使用者，無法提出明確和具體的需求，針對同一個功能需要彙集多方的訴求 。

—  門戶系統屬於 IT 能力提升型別，改善使用者對 IT 系統的體驗和業務創新，所以系統價值在於是否能吸引使用者使用門戶 。

—  門戶系統的建設一般由 IT 部門主導，門戶也逐漸成為 IT 建設的水平指標，所以門戶專案對 IT 部門的影響不容忽視 。

—  門戶系統建設也是一個漸進的過程，一般採取整體規劃、分步實施的策略。

因為門戶專案需求不明確、涉及技術眾多且需要靈活運用，面臨著技術和業務雙重風險 ，所以 需要對專案進度和成效進行多方面管控，需要積極地利用客戶、公司內部、第三方資源。門戶專案的經驗積累非常重要，如果積累比較少，則需要參考同行業內門戶建設的經驗，在門戶規劃中設身處地 地 站在使用者的角度思考問題，從實用價值出發，注意使用者的體驗。在技術方面，門戶平臺遵循的相關技術和標準也比較多，如安全方面，涉及 LDAP 、 JAAS 等； Portlet 開發方面 ， 則 涉及 JSR168 、 JSR286 、 WSRP 等規範。門戶平臺需要與第三方系統 進行 整合，涉及第三方各種架構的系統整合和整合，對人員 的 技術全面性要求比較高。同時 ， 整合架構設計時需要立足於現有 IT 設施 ， 儘可能採用簡單有效、後續擴充套件的架構實現，避免 採用 日後推倒重來的架構。綜上所述 ， 門戶專案對於分析規劃、設計人員的要求比較高，在門戶專案 的整 個實施過程中，需要重視人員的投入。

在專案管理方面，一般採用迭代方式，首先確定主進度計劃，對現階段的工作進行分解，制定可行的計劃。在專案實施中能預見各種風險和 提出 問題，提早 做 好準備。門戶專案涉及人員比較多，溝通非常重要，相關人員有企業高層、 IT 部門、關鍵業務部門、第三方開發商，將溝通記錄整理成文件，發給相關方確認。各方交流最好用文件形成最終記錄，以備後續呼叫。

門戶專案的實施成功與否，門戶平臺提供的能力是重要因素之一，但是更為重要的 是 利用該平臺，結合 客 戶實際情況，交付出貼 近 客戶需求、具有良好的使用者體驗、在專案成本預算範圍 內 的系統。門戶平臺採購只是門戶專案的開始，門戶平臺只是這個專案基礎，門戶專案的交付效果，最 終取決於 門戶專案的實施。因此 ， 門戶專案對人員 的 技能要求更高，需要按照一定 的 方法去實施專案 。

1.2 　專案策劃

專案中標通知書下達或者和客戶簽訂其 他 形式的合同，專案按公司過程管理規範後，正式在公司內部立項，由指定的專案經理負責專案策劃階段的所有工作。參與方有參與專案的售前人員、顧問團隊、專案的技術架構師、客戶方代表。專案策劃階段以專案成功啟動為結束標誌。 本章的一些內容在其他章節中已有體現，此處我們以系統的理論與操作實踐描述出來。

1.2 .1 　門戶規劃

門戶規劃主要從宏觀的角度確定專案將交付 的 內容，即門戶專案的建設內容。根據客戶的 IT 戰略規劃、終端使用者的訴求、客戶 IT 環境 ， 結合行業形勢及企業發展規劃，為客戶描繪系統藍圖，引導客戶 有 正確 的 門戶建設思 路（見圖 4-1 ） 。

 

圖 4-1   典型的 Portal 規劃 思路

門戶規劃需要達到以下目標 。

（ 1 ）透過了解企業近、中、遠發展目標，以及企業的業務、 IT 系統現狀，確定可能的企業門戶平臺解決方案。

（ 2 ）制定門戶整體和長遠規劃、分階段實施的內容、平臺建設和擴充套件建議。

（ 3 ）制定本期專案的內容、分步實施的策略及實施細則、功能實現及擴充套件建議。

（ 4 ）制定本期專案的產品選型和建議、總體技術方案和軟體拓 撲 架構。

（ 5 ）制定門戶平臺建設規範和相關整合標準的建議。

1.2 .1.1 　客戶初級調研

1 ．企業概況

主要了 解 企業行業特性、人員規模、發展戰略 ， 收集營運和社會影響資料。主要來源於客戶的外網公佈的資料 ， 如果是上市公司， 則 可以參閱釋出的財務報表 ； 如果有可能 ，則 可以查閱企業內部的年報、月度報告、領導的講話稿等，但是需要注 意 客戶資料的保密。需要 關 注客戶辦公場所，透過公告板或電子報釋出出來的資料。

企業概況的調研主要為門戶展示設計提供依據， 比 如 KPI 、企業所有人員重點關注的資料，如該企業 的 安 全生產天數、產量等 ， 以及門戶資訊釋出，如企業公告、通知、關注新聞的型別等。

透過查閱企業的領導報告對 IT 建設的思路、上級機關對企業的資訊化建設要求和目標 ， 瞭解企業既定的資訊化建設規劃 、 同行資訊化建設情況 ， 特別 關 注同行門戶建設的相關資訊，爭取到同行或相關單位參觀和交流。如果 是 國企或央企， 則 需要關注國資委對企業的資訊化考核指標 ， 需要重點細讀招標書的內容 。 以上資料可以作為修正和細化建設內容的依據。

透過以上資料和分析，得出門戶建 設 的側重點和方向，全面把握企業資訊化建設思路， 為 後續與客戶 的 關鍵交流打好基礎。

2 ．目標調研  

主要透過對關鍵人員的訪談，如 CIO 、資訊中心的技術骨幹 、 關鍵業務部門負責人， 瞭解 企業對門戶建設的思路、定位 和 期望。

透過上述瞭解，門戶建設內容與重要干係人 的 期望不偏離，同時也期望在建設過程中得到他們的更多支援和配合。門戶專案更多 的 是從上而下推進的專案，企業高層 的 支援和業務部門的配合非常關鍵。

目標調研主要分析和論證企業門戶應該建設的內容，提出企業門戶建設應達到 的 目標和 效 果，突出門戶系統未來的投資回報。

3 ．業務系統調研

主要訪談納入整合系統的建設部門、 IT 部門、主要使用部門 ， 瞭解整合系統的架構、應用規模、環境等。 在取 得客戶的許可 後 截一些關鍵的圖（需要將敏感資訊 做 模糊處理），討論粗粒度的整合需求。具體的需求見 4.6 節的“ 業務系統 基礎資訊 表 ”和“ 業務系統整合需求表 ” 。

業務系統調研立足於承載企業的核心業務流程系統， 以 及企業日常使用的系統，如 OA 、郵件等。完成業務系統調研後，需要提交業務系統與門戶整合專案可行性及價值分析。

1.2 .1.2 　門戶發展規劃

根據初級調研狀況、企業 IT 建設規劃 ， 為企業提供近 期 （本專案）、中期、遠期門戶發展規劃，或者 1 ～ 3 年內門戶分期建設的建議報告。根據實際情況，規劃中修正原招標書的建設內容 ， 使本期門戶專案成效顯著、成本 低 、兼顧後續建設，在門戶建設中爭取主導權。

1.2 .1.3 　確定本期專案內容

門戶發展規劃報告經 過 客戶方認可後，根據規劃報告、招標書、前期調研概況，確定本期建設目標方向、中心內容。 在 本期專案內容 中 ，主要系統大模組為描述點 ， 需要闡明內容的背景、目標、業務價值、具體的子功能、建設概要方案。本期專案內容需要 與 招標書相呼應。

1.2 .1.4 　界定專案範圍

依 據 調研結果，按 照跟 客戶確定的本專案建設內容後，和客戶人員共同商定專案範圍。交流物件主要 有 建設承擔部門負責人、資訊中心負責人、技術核心人員。主要工作內容 如下。

（ 1 ） 將功能需求 具 體化，招標書的需求描述比較抽象，需要從業務場景進行復述 ， 轉化為粗粒度的業務需求。

（ 2 ） 對 於 專案需求，如果產品無法實現或技術難度比較 大 ， 則 說服客戶 以 其 他 方式或 在 下 一 階 段 處理。

（ 3 ）確認 專案實施範圍，如門戶目標使用者範圍 、 整合的系統等 。

專案內容一般可以從以下方面 進行 分類，並且由此確定範圍，整理出門戶建設需求規劃，並且需要標識出優先順序。

1 ．系統部署

根據 客戶環境搭建 APS 系統，包括資料庫、 LDAP 伺服器或 AD 、伺服器叢集、 Apache 前端快取等。

2 ．資料初始化

門戶專案安裝和佈署系統，需要初始化系統資料，如組織、使用者、角色後設資料的定義和初 始 化資料。按門戶規劃配置站點框架 ， 為各站點配置資料夾、頁面、 Portlet ， 並完成許可權的初始化。

3 ．資料遷移

資料遷移主要指門戶系統上線後，門戶功能代替原有系統功能 ， 需要將原有系統的資料遷移至門戶中，最終廢棄原有系統功能。 比 如 ， 原 有系統 具有資訊釋出功能， 用 WCM 代替，需要將原有功能遷移 到 APS 中。注：原有功能遷移需要引導客戶重新開發功能或者整合。

4 ．應用開發

基於門戶平臺按 照 客戶需求開發業務功能，主要採用 Portlet 方式釋出，利用門戶提供 的 介面或元件，快速實現符合客戶的業務功能。 比 如開發會議管理系統，利用門戶安全介面獲取使用者、組織資料，在使用者互動層利用門戶提供 Web 元件。

5 ．系統整合

介面整合 ：透過門戶整合該企業整合 W eb 業務系統的功能，將業務系統 的 常用功能納入門戶框架內，在門戶中提供業務系統的入口連結、常用功能操作連結，使用在門戶框架內完成檢視和操作其 他 業務系統的資料。

資料整合 ：將來自各個業務系統的資料進行適配、轉換、過濾、載入、彙總 ， 將資料形成上下文變成資訊，再透過門戶將資料用豐富直觀的方式進行展示。

應用整合 ：利用業務系統提供 的 資料介面，透過企業服務匯流排封裝成標準 Web Service ，門戶在此介面基礎上開發人機互動功能。應用整合還包括業務系統單點登入實現。

流程整合 ：按 照 某一業務主線處理流程將業務系統提供 的 介面串接起來，實現資料跨系統、跨組織流動。

6 ．二次定製開發

二次定製開發主要 指 門戶提供的功能不能滿足客戶需求，或者客戶需要按企業的業務模式進行定製化開發， 比 如門戶的使用者管理， APS 產品提供基本管理功能，特殊的功能如人員兼職處理、人員排序等。

7 ．相關文件

實施難度和風險比較大的 門戶 專案，需要有比較完備的專案實施過程記錄，除了專案管理文件外，還需要提供門戶建設規劃、相關整合規範、運維管理制度、培訓文件等。

1.2 .2 　專案評估

對專案的需求和目標確定以後，需要對專案進行各個層面的評估，主要包括技術路線、工作量、假定和約束評估，為專案計劃制訂和人力資源安排提 前做好 準備。

1.2 .2.1 　技術 方案設計

技術路 線 評估主要確定本專案 所 採用 的 技術框架、採購的第三方軟體、重要模組的軟體架構、與第三方系統整合的技術 ， 需要說明技術的複雜度、風險、難度。如果需要技術 預研 ， 則 需要特別說明。

1 ．總體技術架構

門戶專案方案一般是基於 SOA 的 IT 架構原則進行設計的，採用松耦合的面向服務的設計，以便於支援後續系統的發展。總體技術方案一般採用層次關係，可以分為基礎設施、中介軟體、應用系統、整合支援軟體等，確定每一層的架構作用。

2 ．系統軟體邏輯架構

系統軟體邏輯架構為系統軟體拓樸圖，在總體架構圖的基礎上，按 照 未來軟體部署模型，將各層 所 採用 的 軟體及主要功能模組， 以及 與其 他 層的互動關係用線條描繪出來 ， 用來指導系統的應用設計和軟體選型，並且對於關鍵技術點的實現原理進行詳細描述。

3 ．系統擴充套件和資料容量設計

在技術方案中，門戶專案一般都具有延續性需求，需要重點提到系 統 功能擴充套件方案，如二級子門戶的擴充套件、待辦功能新加入系統擴充套件及應用擴充套件等。同時 ，在 門戶系統執行後， 需要進行 資料增長估算，計 算 重點模組的資料增長量，確定儲 存 空間大小以及擴充套件方案。

4 ．實施建議

除了技術 方面 外，還需要重 點 考慮實施方面的問題， 比如 在需求收集、規範制定、內容優先順序、大概的時間安排、資源投入計劃及相關注意事項。 在 建議中需要突出快速、有效。

1.2 .2.2 　工作量評估

根據需求規劃，對工作進行細粒度分解，並且對工作進行說明。進行分解後，需要標明產品是 否 可由門戶產品或第三方產品提供、需求的符合度、是否要開發、實施等， 然後 做工作量大體估算。

1.2 .2.3 　假定和約束評估

門戶 系統整合具有很多制約因素，如第三方配合、硬體資源、環境準備等。例如，在門戶專案實施 中 ，企業正在同時實施相關係統，並且需要與門戶做整合。在專案計劃制定中，不明確的並且有時間依賴的，先和干係方預先假定時間，供後續專案計劃跟蹤、風險控制 做 參考。

專案實施來自成本、時間、範圍等 ， 主要 是 專案各時間點 、 客戶承受範圍等。

1.2 .3 　團隊組建

在 整個專案中，需要多個角色和崗位投入門戶專案實施中。因為門戶涉及多種架構的系統， 所以 要求整個團隊 的 技術和業務能力比較高。

門戶專案的專案經理是比較關鍵的角色，需要具有 比 較豐富的專案管理經驗，同時具有一定的技術開發相關背景，具有較好的溝通協調能力。

門戶專案需要級別比較高的主管來 做 專案總監，協調專案經理無法協調的資源，同時也是直接面對客戶相應級別領導的直接溝通者。

專案成員中儘可能 有 具有門戶專案經驗的人員，省去前期的培訓，加快專案的進度，有效地減少返工率。

在 門戶專案實施過程中，可能會遇到很多突 發 情況，需要預先儲備好業務和技術顧問團隊。

1.2 .3.1 　專案組織架構

典型的 Portal 專案組織架構圖如圖 4-2 所示。

 

圖 4-2 　典型的 Portal 專案組織架構圖

1.2 .3.2 　　甲方專案成員

1 ．專案經理

由甲方提供業務和技術骨幹人員 ， 對專案總體工作負責，監控專案實施進度，控制專案風險，為專案組各項工作協調相關資源，協調相關整合系統供應商。

2 ．系統管理員

由甲方 提供 系統管理 員 ，專 門 協調處理硬體、網路、作業系統、資料庫、防火牆等相關事務，為門戶系統的安裝、整合更新提供便利的條件。

3 ．業務介面人

由各個關鍵業務部 門 提供業務骨幹 ， 並且 具 有一定 的 IT 運用技術基礎 ， 支援相關業務功能 ，提供 專業業務知識諮詢支援。

1.2 .3.3 　乙方專案成員

1 ．專案經理

由乙方提供專案經理，負責門戶專案的管理，如溝通協調、進度管 理等 。

2 ．專案顧問

由乙方提供高階技術顧問 ， 對門戶藍圖規劃提供技術支援 ， 對系統開發和整合提 供 支援。

3 ．架構師

由乙方提供架構 師 ，負責整個專案的系統架構，指導開發 工 程師進行系統開發和專案實施。

4 ．開發工程師

由乙方提供 開發工程師 ，負責門戶系統的開發。

5 ．人機體驗工程師

由乙方提供 人機體驗工程師 ，負責門戶系統介面風格設計 、 功能模組的人機互動設計。

6 ．測試工程師

由乙方提供 測試工程師 ，負責系統的功能測試和效能測試。

7 ．配置管理員

由乙方提供 配置管理員 ，負責專案組文件和程式碼的配置管理、系統的持續整合。

1.2 .4 　專案計劃

完成上 一個環節後，由專案經理和客戶負責人一起設定主要 的 專案里程碑 ，然後 再製訂第一階段的迭代計劃，細化實施和開發實施細 則 。同時 與 客戶方 和 第三方制 訂 溝通計劃 ， 制訂風險計劃。

1.2 .4.1 　里程碑

里程碑計劃 指 按 照與 客戶達成 的 共識將專案劃分為幾個階段，設定各階段的時間點、工作目標、相應的產品、工作制品（主要相關文件） 。 常見的劃分可以參考 以 下設定，需要 做 相關的說明。里程碑 計劃 的週期最長不超過 2 個月 ， 每個里程碑結束後，需要對工作進行總結，向各干係人彙報工作狀況。

1 ．專案初始

該階段為專案的 第一階段 ，主要完成門戶規劃、需求開發、系統設計、驗收標準、相關規範的制定及專案管理產出文件。同時 ， 專案組在駐場之前可以協調幹系人，可以針對技術進行預研、設計工作。

2 ．快速見效

該階段為專案的第二階段，主要工作為系統環境搭建、資料初始化、資料和功能遷移 ， 立足於門戶產品自帶的功能和元件，優先整合第三方開發商 的 配合比較到位和積極、工作量和風險小的系統。系統目標達到使用者體驗效果。

3 ．豐富應用

該階段為專案的第三階段，主要 是 擴大系統整合規模，同時定製開發業務功能上線，達到系統 可以 試執行 的效果 。

4 ．專案收尾

該階段為專案 的第四 階段，主要對系統進行最佳化，將試執行 時 發現的問題進行修正 ， 制定相關的運維制度和標準，對使用者進行培訓，提供系統的執行資料，為專案驗收 做 準備。

5 ．專案驗收

專案驗收是整個專案的重要環節。在驗收過程中，需要更加註重過程管理。首先 制訂 驗收計劃 ， 列出文件清單（ che c klist ） ， 組織客戶方或第三方進行驗收 ，提供 系統測試報告。在驗收會上提交系統運維報告、客戶準備工作報告、專案組負責技術報告、領導總結等。最終需要客戶在驗收報告 上 簽字 ， 制 訂 付款計劃。

需要準備 的 資料 如下

—  《 門戶專案工作報告》

—  《 門戶專案技術報告 》

—  《 門戶系統執行報告》

—  《 驗收專案彙報 PPT 》

—  《 現場測試報告》

1.2 .4.2 　迭代計劃

按照專案的里程碑定義，首先制訂第一迭代週期，主要是專案初始階段的工作。讓專案成員清楚下一步的工作計劃，瞭解個人的工作職責和內 容 。同時也發給客戶專案經理，按 照 實際情況對計劃提出修改意見，或 者 提前做好相關準備工作，如專案啟動發文、宣傳、協調等。

1.2 .4.3 　溝通計劃

溝通是所有專案成功 的 基本需求，專案經理 的 主要職責也 包括 與各 方 進行有效的溝通。溝通計劃是保證溝通 的 重要措施。溝通計劃分為對外溝通和對 內 溝通。在溝通方式 上 ，可以 選擇 電話、郵件、會議等方式。需要確定溝 通 形式 、 頻率 和 內容。

1.2 .4.4 　風險管控計劃

風險管理是專案管理的重要內容，門戶專案的風險比較大，需要對風險進行有效管理，確保專案成功。在專案啟動前，需要 針對 已經分析和識別的風險制定應對措施，後續的管理形成既定的模式。

1.2 .5 　專案啟動

完成團隊組 建 和專案計劃後，即可 在 公司內部和客戶方正式啟動專案 ， 主要 是 凝聚士氣，正式宣佈專案開始運作。

1.2 .5.1 　內部啟動

內部啟動最好先於客戶 方 啟動 。 內部啟動主要是售前團隊和專案實施團隊的工作交接 ， 售前 團隊 介紹專案的背景、目標、建設內容 及 售前總結等。由專案經理介紹項 目 策劃情況，主要是介紹團隊、專案計劃 、 相關事宜 等 。

1.2 .5.2 　客戶方啟動

客戶方啟動，客戶方的企業高管、相關部門代表、第三方系統開發商代表、雙方專案組主要成員 需要 出席專案啟動會 （如有必要可請公司領匯出席） ，以突出公司對專案的重視。