

# OPS 2  如何建構組織以支援業務成果？
<a name="w2aac19b5b5b7"></a>

 您的團隊必須了解其在達成業務成果中所扮演的角色。團隊需要了解自己在促成其他團隊成功的過程中所扮演的角色、其他團隊在促進其成功的過程中所扮演的角色，以及擁有共同目標。了解責任、擁有權、決策方式，以及誰有權制定決策，將有助於找到工作重點，並充分發揮團隊的優勢。 

**Topics**
+ [OPS02-BP01 已為資源識別擁有者](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 已為流程和程序識別擁有者](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 已為營運活動識別負責其效能的擁有者](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 團隊成員知道他們負責的項目](ops_ops_model_know_my_job.md)
+ [OPS02-BP05 存在機制用來識別責任和擁有權](ops_ops_model_find_owner.md)
+ [OPS02-BP06 存在用於請求新增、變更和例外狀況的機制](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 團隊之間的責任為預先定義或經過協商](ops_ops_model_def_neg_team_agreements.md)

# OPS02-BP01 已為資源識別擁有者
<a name="ops_ops_model_def_resource_owners"></a>

 了解誰擁有各個應用程式、工作負載、平台和基礎設施元件、該元件提供什麼商業價值，以及該擁有權為何存在。透過了解這些個別元件的商業價值，以及其如何支援業務成果，可得知對元件套用的流程和程序。 

 **建立此最佳實務的優勢：** 透過了解擁有權，可識別誰可以核准改進項目和/或實作這些改進項目。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  已為資源識別擁有者：定義擁有權對環境中的資源使用案例的意義。指定並記錄資源的擁有者，至少包括名稱、聯絡資訊、組織和團隊。借助使用中繼資料 (例如標籤或資源群組) 的資源來儲存資源擁有權資訊。使用 AWS Organizations 建構帳戶並實作政策，以確保擷取擁有權和聯絡資訊。 
  +  定義擁有權形式及其指派方式：擁有權在您具有不同使用案例的組織中可能有多個定義。您可能希望將工作負載擁有者定義為承擔工作負載營運風險和責任的個人，以及最終有權對工作負載做出決策的個人。在將擁有權累計到父組織時，您可能希望根據財務或管理責任來定義擁有權。開發人員可能是其開發環境的擁有者，並負責其操作造成的事件。他們的產品主管可能自行負擔與開發環境營運相關的財務成本。 
  +  定義擁有組織、帳戶、資源集合或個別元件的人員：在可適當存取的位置中定義和記錄擁有權，該位置已經過組織，可支援探索。更新變更的定義和擁有權詳細資訊。 
  +  擷取資源中繼資料中的擁有權：使用標籤或資源群組等中繼資料擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建構帳戶並確保擷取擁有權和聯絡資訊。 

# OPS02-BP02 已為流程和程序識別擁有者
<a name="ops_ops_model_def_proc_owners"></a>

 了解誰具有個別流程和程序的擁有權、為何使用特定流程和程序，以及為何該擁有權存在。了解使用特定流程和程序的原因，能夠幫助發現改進機會。 

 **建立此最佳實務的優勢：** 透過了解擁有權，可識別誰可以核准改進項目和/或實作這些改進項目。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  已為流程和程序識別負責其定義的擁有者：擷取環境中使用的流程和程序，以及負責其定義的個人或團隊。 
  +  識別流程和程序：識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。 
  +  定義擁有流程或程序定義的人員：唯一識別負責活動規格的個人或團隊。他們負責確保具備適當技能的團隊成員能夠成功執行該活動，且該團隊成員具備正確許可、存取權和工具。如果執行該活動時發生問題，執行該活動的團隊成員需負責提供改善活動所需的詳細回饋。 
  +  擷取活動成品中繼資料中的擁有權：在 AWS Systems Manager 等服務中，透過文件和做為函數的 AWS Lambda 自動化的程序，支援以標籤形式擷取中繼資料資訊。使用標籤或資源群組擷取資源擁有權，並指定擁有權和聯絡資訊。使用 AWS Organizations 建立標記政策，並確保擷取擁有權和聯絡資訊。 

# OPS02-BP03 已為營運活動識別負責其效能的擁有者
<a name="ops_ops_model_def_activity_owners"></a>

 了解誰負責在已定義的工作負載上執行特定活動，以及為什麼該責任存在。透過了解誰負責執行活動，可得知誰將會進行活動、驗證結果，以及提供回饋給活動擁有者。 

 **建立此最佳實務的優勢：** 透過了解誰負責執行活動，可得知在需要採取動作時通知誰，以及誰將會執行動作、驗證結果，以及提供回饋給活動擁有者。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  已為營運活動識別負責其效能的擁有者：擷取執行環境中所使用之流程和程序的責任 
  +  識別流程和程序：識別為支援工作負載所執行的營運活動。將這些活動記錄在可探索的位置中。 
  +  定義負責執行每個活動的人員：識別負責活動的團隊。確保他們擁有活動的詳細資訊，以及執行活動所需的技能和正確的許可、存取權和工具。他們必須了解活動執行條件 (例如，事件或排程)。讓此資訊可供探索，如此組織的成員便能夠識別他們針對特定需求需要聯絡的人員 (團隊或個人)。 

# OPS02-BP04 團隊成員知道他們負責的項目
<a name="ops_ops_model_know_my_job"></a>

 透過了解您角色的責任以及您為業務成果做出貢獻的方式，可得知任務的優先順序以及您的角色為何很重要。如此可讓團隊成員辨識需求並適當地回應。 

 **建立此最佳實務的優勢：** 透過了解您的責任，可得知您所做的決定、您採取的動作，以及如何將活動交給其適當的擁有者。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  確保團隊成員了解其角色和責任：識別團隊成員的角色和責任，並確保他們了解其角色的期望。讓此資訊可供探索，如此組織的成員便能夠識別他們針對特定需求需要聯絡的人員 (團隊或個人)。 

# OPS02-BP05 存在機制用來識別責任和擁有權
<a name="ops_ops_model_find_owner"></a>

 如果沒有識別個人或團隊，就會有定義的向某人向上呈報的路徑，該人員有權指派擁有權或為需解決的需求進行規劃。 

 **建立此最佳實務的優勢：** 透過了解有責任或擁有權的人員，讓您可以聯絡適當的團隊或團隊成員，以提出請求或轉換任務。擁有有權指派責任或擁有權或為解決需求進行規劃的已識別人員，可降低無作為和需求得不到解決的風險。 

 **若未建立此最佳實務，暴露的風險等級：** 高 

## 實作指引
<a name="implementation-guidance"></a>
+  存在機制用來識別責任和擁有權：為您的組織成員提供可存取的機制，以探索和識別擁有權和責任。這些機制讓他們可以針對特定需求識別要聯絡的人員 (團隊或個人)。 

# OPS02-BP06 存在用於請求新增、變更和例外狀況的機制
<a name="ops_ops_model_req_add_chg_exception"></a>

 您可以向流程、程序和資源的擁有者提出請求。評估收益和風險後，若可行並經判斷是合適的行為，則應制定明智的決策以核准請求。 

 **建立此最佳實務的優勢：** 機制存在的目的應為請求新增、變更和例外狀況，以支援團隊的活動。如果沒有此選項，目前狀態就會成為創新的限制。 

 **若未建立此最佳實務，暴露的風險等級：** 中 

## 實作指引
<a name="implementation-guidance"></a>
+  存在用於請求新增、變更和例外狀況的機制：當標準很嚴格時，創新會受到限制。為您的組織成員提供機制，讓他們可向流程、程序和資源的擁有者提出請求，以支援其業務需求。 

# OPS02-BP07 團隊之間的責任為預先定義或經過協商
<a name="ops_ops_model_def_neg_team_agreements"></a>

 團隊間已定義或協商說明如何相互配合及支援的協議 (例如，回應時間、服務等級目標或服務等級協議)。透過了解團隊工作對於業務成果和其他團隊及組織成果的影響，可得知其任務的優先順序，並讓他們能做出適當的回應。 

 如果責任和擁有權未定義或未知，則您會面臨風險，不僅無法及時處理必要的活動，在解決這些需求時還會出現冗餘和可能相互衝突的工作。 

 **建立此最佳實務的優勢：** 透過建立團隊、目標和溝通需求之方法之間的責任，可簡化請求的流程，並協助確保提供必要的資訊。此舉可減少團隊之間的轉換任務所造成的延遲，並協助支援達成業務成果。 

 **若未建立此最佳實務，暴露的風險等級：** 低 

## 實作指引
<a name="implementation-guidance"></a>
+  團隊之間的責任為預先定義或經過協商：指定團隊互動的方法以及彼此支援所需的資訊，有助於將請求反覆審查和釐清時產生的延遲降到最低。擁有定義期望的特定協議 (例如，回應時間或履行時間)，讓團隊可以適當地制定有效的計畫和資源。 