1.3 計劃控管 - AWS 方案指引
概觀最佳實務常見問答集其他步驟

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

1.3 計劃控管

概觀

計劃控管可保護與高階主管、主要利益相關者、雲端計劃團隊和 OCA 團隊之間的整合一致性。它還定義了變革加速活動的擁有權、決策權，問題管理和升級過程。

使用控管來達成下列目標：

  • 啟用變革加速計劃的明確、決定性的領導力和責任。

  • 提供品質保證和呈報問題和風險的途徑。

  • 指定程式的決策權架構。

  • 將工作流程結構與現有專案、計劃和整個組織的控管結構保持一致。

  • 建立會議和Scrum 典禮的節奏，這些典禮對應到其他節目節奏和報告機制。

最佳實務

與建立明確結構和控管的計劃相比，成功的機率更高。這是因為圍繞決策權的決策和擁有權通常是延遲雲端計畫的主要因素。治理會建立決策權，並提供有關雙向大門決策 （可在低風險的情況下快速做出，且可輕鬆反轉） 和單向大門決策 （由於無法輕鬆反轉，因此需要更多思考和沉思） 的指引。

為了有效控管程式，請遵循本節所述的最佳實務。

建立組織變革加速團隊結構

建立描述報告關係和高階責任的高階結構，如下列範例所示。 

OCA 團隊結構和領導協調檢查點範例。

定義 OCA 團隊的角色

定義組織變革加速團隊的角色。提供每個角色的高階責任，如下列範例所示。

OCA 角色描述範例。

這些角色和責任可能包括下列項目。

OCA 必要角色：

  • 執行 OCA 委託人/顧問：與 PMO 合作，並確保發起人和執行領導者的參與，以協調執行利益相關者、指導領導者履行文化變革領導責任，以及建立雲端領導功能、與執行發起人合作，以實現變革影響決策。

  • OCA 計畫/工作流程負責人：以深厚的領域專業知識領導day-to-day計畫。管理工作流程策略和交付項目的執行、開發指標和追蹤，以確保計劃成功、核准和驗證變更策略和藍圖，以及管理和追蹤風險。

其他 OCA SMEs：

  • 通訊專家：為所有利益相關者群組建立詳細的通訊。如果業務開發的規模和複雜性超過基本角色的工作容量，或需要更深入的領域，則需要此角色。理想情況下，會識別此角色的客戶利益相關者。

  • 訓練專家：制定詳細的訓練策略和藍圖。如果參與的規模和複雜性超過基本角色的工作容量，或者需要更深入的領域，則需要此角色。

  • 文化、人力、領導專家：這些角色著重於文化、人力或領導積壓活動。只有在互動的規模和複雜性需要任何這些網域區域的更深入區域時，才需要它們。

定義組織中的 OCA 角色

定義組織中相關 OCA 角色的高階責任，如下列範例所示。

OCA 專案的客戶任務描述和資源範例。

這些角色和時間承諾可能包括下列項目。

執行發起人 (25%)

  • 指導委員會的成員

  • 對重大問題做出決策的執行角色

  • 與 OCA 顧問合作進行變革策略和決策

  • 檢閱和核准範圍變更

  • 檢閱和核准專案和計劃

  • 提供最終專案核准

組織變革加速領導 (100%)

  • 與 OCA 合作，共同開發和交付變革評估、策略和藍圖

  • 協助識別利益相關者群組、業務目標、風險、封鎖程式和協同作用

  • 提供主動和可見的變更領導

  • 擔任組織變革擁護者

程式/參與潛在客戶 (100%)

  • 協助研討會記錄和文件

  • 協助安排評估面試

  • 做為呈報的第一個點

  • 可交付項目的檢閱和評論

  • 專案計劃的檢閱和評論

業務單位擁有者 (50%)

  • 與 OCA 團隊合作定義業務需求

  • 參加研討會和面試

  • 提供專案部分的主題專業知識

  • 可交付項目的檢閱和評論

訓練和通訊SMEs (30%)

  • 與 OCA 訊息共同開發，以建立意識和參與度

  • 提供簡訊標準和指導方針

  • 提供翻譯支援

  • 在溝通策略和藍圖上與 OCA 團隊合作

HR 業務合作夥伴 (20%)

  • 與 OCA 團隊合作，在需要時 （轉換前後） 提供目標人力資源支援

定義風險識別和緩解策略

制定策略，持續識別可能阻礙雲端策略和價值實現的人員並變更風險。此策略應具備廣泛的潛在風險輸入功能，以及用於風險分析、規劃、緩解和追蹤的敏捷機制。下圖提供範例。

風險緩解策略和計劃的目標是確保無縫程序，以及時管理狀態、問題和呈報並解決衝突。

變更 OCA 專案的風險評估和目標變更解決方案。

變更風險評估會引導變更活動和詳細的變更計畫，以協助確保將變更解決方案鎖定在需要它們的位置，以及它們將帶來最大影響的位置。針對性變更解決方案可讓 OCA 在正確的時間以正確的方式影響正確的對象。

為 OCA 開發 RACI

最後，定義客戶和 關鍵組織變革加速功能的特定責任和責任 AWS。以下是負責、負責、諮詢、告知 (RACI) 矩陣的範例。

OCA 專案的 RACI 矩陣範例。

常見問答集

問：誰應該參與計劃控管？

答：執行發起人、專案或計畫領導者、變革領導者、內部服務供應商 （例如，通訊、訓練/學習和人力資源，如果他們在支援變革計畫中扮演了角色）。

問：此活動的輸入是什麼？

A.專案章程、商業案例、指導委員會的意見、雲端領導團隊和任何雲端評估結果 （例如，遷移準備度或雲端成熟度評估）。

問：此活動的輸出為何？

A.狀態報告範本、報告程序、專案團隊組織圖表、決策矩陣和 RACI。

問：何時應執行活動？

答：OCA 控管結構必須在計畫開始時建立，並保留到專案完成為止。當團隊擴展或簽訂合約時，新角色應由計劃領導層定義和核准。發生團隊變更時，應更新組織圖表，且這些變更應跨計畫進行通訊。

其他步驟

  1. 檢閱雲端控管結構和程序，例如 Cloud Center of Excellence (CCoE)、計畫管理辦公室或轉型管理辦公室。

  2. 判斷 OCA 與雲端控管結構和程序的整合。

  3. 開發風險管理的 OCA 策略、程序和工具。

  4. 整合 OCA 風險管理程序與計劃層級的風險管理程序。

  5. 開發狀態報告程序。

  6. 開發標準化 OCA 狀態範本以供報告之用。