本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 規劃階段的最佳實務
在綠地 SAP 實作的規劃階段，專案通常會遇到各種挑戰和機會。本節討論以 SAP 為基礎的五個關鍵學習，了解 AWS 專業服務團隊已參與的 AWS 綠地實作。甚至可以在專案開始或諮詢團隊參與之前實作其中一些建議。提供文件草稿，例如角色和職責矩陣或團隊聯絡人清單，有助於加速提升程序。
## 建置 RACI 矩陣
為基礎設施團隊建置責任指派矩陣對於任何實作專案來說都很重要。該矩陣採用綜合負責者、當責者、事先諮詢者和事後告知者 (RACI) 圖表的形式。RACI 用於闡明複雜團隊結構中的角色、工作分派和任務。它應該與 AWS SAP Cloud 團隊、SAP Basis 團隊、SAP 系統整合商 (SI) 和客戶合作開發。這可以由這些群組中的任何一個或由專案經理驅動。在沒有這些利益相關者參與的情況下建置 RACI 會產生矛盾和分歧，有時甚至是衝突。考慮專案的所有階段至關重要。提前設立 RACI 可加強所有參與方之間的合作夥伴關係，並提高透明度。理想情況下，RACI 應在專案啟動前完成。
以下是綠地 SAP 實作專案的範例 RACI 矩陣摘錄。
[ 下載完整的 RACI 矩陣](samples/sap-greenfield-implementation-raci.zip)
## 檢閱 SoW
了解 AWS 諮詢和顧問服務的工作陳述式 (SoW) 的所有元素，並與主要利益相關者共同檢閱 SoW，以便所有人清楚地了解交付項目。如果基礎設施團隊打算執行超過 SoW 定義的作業，請務必在風險、假設、動作、問題、相依性和決策 (RAAIDD) 日誌中記錄。在綠地 SAP 實作專案中，保持靈活和敏捷至關重要，因此偏離 SoW 是常見的案例。不過，如果 AWS 實作合作夥伴開始交付超出記錄的內容，預期可能會變得模糊。發生變更時，應保留新工作範圍以及可能必須進行權衡的執行清單。對於瀑布式專案方法，必須定義和實作範圍變更管理程序。對於敏捷專案，積壓工作優先級排序程序更適合管理範圍。
考量：
+ 隨著專案的進展，請務必擷取新範圍並定義任何新的可交付成果。這將協助您管理期望，並在確定積壓工作的優先級時尋求協助。
+ 識別文件變更和任務以及現有的交付積壓，並確定其優先順序，以便可在專案的整個生命週期內生成文件，而不是延遲到結束。
+ 在整個專案中定期進行 SoW 演練，以與交付項目和優先順序保持一致。
+ 對於生產切換，請務必至少提前 12 個月核准具有唯讀存取權的 SoW，以協助 Hypercare 支援。
## 建立團隊組織結構圖和聯絡人清單
構建可描繪團隊和領導結構的高層級組織結構圖。開發跨團隊聯絡人清單進行更深入的了解，它包括基礎設施團隊中每個人的姓名、職稱和角色，以及各種功能的關鍵聯絡點，例如安全性、網路和防火牆操作、Microsoft Active Directory、內部雲端操作和伺服器操作。每個人都應該知道專案的參與者是誰以及他們扮演的角色。當團隊沒有掌握此資訊時，不可避免地會發生延遲和溝通不當。了解利益相關者的頭銜也很重要。例如，您不希望邀請董事級別的利益相關者參加設計會議或每日站立會議，除非他們是討論的主要貢獻者。了解頭銜和角色可讓您邀請合適的人員參加相關會議。能夠在組織結構圖中可視化團隊可以協助您了解團隊的結構以及在專案中的合作方式。
下圖提供 AWS 基礎設施組織圖表上典型 SAP 的範例。
## 與內部雲端團隊一起建立參與模型
如果您的 IT 組織有內部 AWS 雲端團隊，您應該與該團隊建立互動模式，並釐清他們將執行的工作，與 AWS 實作合作夥伴 （例如 AWS ，專業服務或 AWS 合作夥伴） 的任務相比。需要考慮的一個關鍵責任是在建置和移交環境之後的支援情況。例如，如果只有兩位 SAP 雲端架構師正在為數十個 AWS SAP 應用程式建置多景觀和多環境基礎設施，則他們沒有頻寬來支援同時完成建置*和*建置新環境的環境。一種選擇是請求內部雲端團隊接管已完成環境的支援。這使內部團隊有機會學習並獲得環境的所有權。當專案有所進展並確定新的工作範圍時，他們最終將負責維護和擴展這些環境。
內部雲端基礎設施和雲端 DevOps 團隊也應該同意要使用的自動化軟體類型，例如，是否使用 AWS CloudFormation 或 Terraform 做為基礎設施做為程式碼 (IaC) 工具。同樣地，他們可能會決定將 AWS Systems Manager 或 Ansible 用於組態任務，例如引導磁碟區和可能的 SAP 安裝。這些決定應記錄在案。此外，如果需要第三方監控和可觀測性儀表板，但這不是 SoW 中的可交付項目，請考慮在此期間使用 Amazon CloudWatch 和 Amazon Simple Notification Service (Amazon SNS) 放置監控和記錄掛鉤。內部雲端團隊可以在以後使用第三方監控解決方案進行整合。
參與模型或支援協議也應該是 RACI 矩陣的一部分，並在 SoW 中表達。使用 AWS 服務可以實現顯著程度的自動化。SoW 和 RACI 矩陣應識別在綠地 SAP 實作專案中需要達成的項目，以及可委派給營運團隊的項目。
當您建立參與模型時，請判斷瀑布式、敏捷式或混合式方法是否會是向前邁進的關鍵方法。 AWS 與瀑布式方法相比，專業服務觀察到任務完成增加 300%，並在實作敏捷式或混合式方法的參與中縮短 94% 的規劃時間。在規劃階段，您也應該在客戶的協助下，選取溝通計畫和工具方法。下表顯示通訊計劃範例。
最後，請務必識別將及早支援專案的客戶和 SAP Basis 團隊。在您實作和遷移新解決方案時對其進行訓練，是儘早開始知識轉移工作階段的關鍵。
## 記錄雲端建置和部署程序
如果您的 IT 組織擁有內部雲端團隊，該團隊應該使用程序流程圖來記錄雲端建置和部署程序，並與整個團隊共用這些圖表。您希望主要利益相關者能夠輕鬆發現程序中的任何瓶頸或低效，並了解現有內部程序在造成低效或延遲方面所起的作用。在下列範例中，您可以看到 Active Directory 加入和網域名稱系統 (DNS) 更新程序如何花費最長的時間才能完成。這種視覺效果可能會激勵團隊進行協作，並想辦法減少該程序步驟中涉及的時間。
考量：
+ 分別記錄服務台程序和工作流程，與基礎設施團隊共用此資訊，並確保每個人都可以存取服務台工具，以免依賴某個人。通常情況下，執行 Active Directory 加入、DNS 更新、開放防火牆和請求加密金鑰時，可能會有一個複雜且耗時的票證程序。記錄這些程序並在專案規劃階段考慮每個團隊的服務水準協議 (SLA) 至關重要。它還有助於解釋需要特別注意才能消除的延遲或瓶頸的原因。
+ 為 Active Directory 和防火牆或聯網任務指派具名聯絡點。這些專用資源應該是專案的一部分。如果必須依賴服務票證，則無法控制服務 SLA。
## 專案藍圖和里程碑追蹤器
下列圖表提供 AWS 綠地專案上多年 SAP 的範例藍圖。
下表顯示相同專案的 AWS Professional Services 參與時間表範例。
下圖顯示此專案的上線里程碑追蹤器。
