# OPS02-BP04 Definizione di meccanismi per gestire responsabilità e titolarità
OPS02-BP04 Definizione di meccanismi per gestire responsabilità e titolarità

 Comprendi le responsabilità del tuo ruolo e il modo in cui contribuisci ai risultati aziendali in quanto questa conoscenza fornisce indicazioni sulle priorità delle tue attività e sul perché il tuo ruolo è importante. I membri del team possono quindi riconoscere le esigenze e rispondere in modo appropriato. Quando i membri del team comprendono il proprio ruolo, possono stabilire la titolarità, identificare le opportunità di miglioramento e capire come influenzare o apportare le modifiche appropriate. 

 Occasionalmente, una responsabilità potrebbe non avere un titolare definito. In queste situazioni, progetta un meccanismo per risolvere la lacuna. Crea un percorso di escalation ben definito a qualcuno con l'autorità di assegnare la responsabilità o il piano per risolvere il problema. 

 **Risultato desiderato:** responsabilità definite in modo chiaro per i team all'interno dell'organizzazione, che comprendono il modo in cui sono correlate alle risorse, alle azioni da eseguire, ai processi e alle procedure. Queste responsabilità sono in linea con le responsabilità e gli obiettivi del team, nonché con le responsabilità degli altri team. Documenti i percorsi di escalation in modo coerente e individuabile e inserisci queste decisioni in artefatti di documentazione, come matrici di responsabilità, definizioni di team o pagine wiki. 

 **Anti-pattern comuni:** 
+  Le responsabilità del team sono ambigue o mal definite. 
+  Il team non allinea i ruoli alle responsabilità. 
+  Il team non allinea scopi e obiettivi alle responsabilità, rendendo difficile misurare il successo delle attività. 
+  Le responsabilità dei membri del team non sono in linea con il team e l'organizzazione in generale. 
+  Il team non mantiene aggiornate le responsabilità rendendole incoerenti con le attività svolte dal team. 
+  I percorsi di escalation per determinare le responsabilità non sono definiti o non sono chiari. 
+  I percorsi di escalation non hanno un unico responsabile del thread per garantire una risposta tempestiva. 
+  Ruoli, responsabilità e percorsi di escalation non sono individuabili e quindi non sono immediatamente disponibili quando richiesto, ad esempio in risposta a un incidente. 

 **Vantaggi dell'adozione di questa best practice:** 
+  Una volta compreso chi ha la responsabilità o la titolarità, puoi contattare il team o il membro del team appropriato per effettuare una richiesta o trasferire un'attività. 
+  Per ridurre il rischio di inattività e di esigenze non soddisfatte, identifichi una persona che ha l'autorità di assegnare responsabilità o titolarità. 
+  Quando si definisce chiaramente l'ambito di una responsabilità, i membri del team acquisiscono autonomia e titolarità. 
+  Le tue responsabilità forniscono indicazioni sulle decisioni che prendi, sulle azioni che intraprendi e sulle tue attività di distribuzione ai titolari appropriati. 
+  Ti sarà facile identificare le responsabilità abbandonate perché hai una chiara comprensione di ciò che non rientra nelle responsabilità del tuo team e quindi potrai effettuare l'escalation per chiedere chiarimenti. 
+  I team evitano confusione e tensione e possono gestire in modo più adeguato i carichi di lavoro e le risorse. 

 **Livello di rischio associato se questa best practice non fosse adottata:** elevato 

## Guida all’implementazione
Guida all'implementazione

 Identifica i ruoli e le responsabilità dei membri del team e verifica che comprendano le aspettative del proprio ruolo. Rendi queste informazioni individuabili in modo che i membri della tua organizzazione possano identificare il team o la persona da contattare per esigenze specifiche. Man mano che le organizzazioni capitalizzano le opportunità di migrare e modernizzare su AWS, i ruoli e le responsabilità potrebbero cambiare. Rendi i team e i membri consapevoli delle loro responsabilità e offri la formazione appropriata per svolgere le attività durante questo cambiamento. 

 Determina il ruolo o il team che deve ricevere le escalation per identificare responsabilità e titolarità. Questo team può interagire con varie parti interessate per prendere le decisioni. Tuttavia, è proprietario della gestione del processo decisionale. 

 Fornisci ai membri della tua organizzazione meccanismi accessibili per scoprire e identificare titolarità e responsabilità. Questi meccanismi insegnano loro a chi rivolgersi per esigenze specifiche. 

 **Esempio del cliente** 

 AnyCompany Retail ha recentemente completato una migrazione dei carichi di lavoro da un ambiente on-premises alla zona di destinazione in AWS con un approccio lift and shift. Ha eseguito una revisione delle operazioni per esaminare come vengono svolte le attività operative comuni e ha verificato che la matrice di responsabilità esistente rifletta le operazioni nel nuovo ambiente. Quando ha eseguito la migrazione dall'ambiente on-premises ad AWS, ha ridotto le responsabilità dei team dell'infrastruttura relative all'hardware e all'infrastruttura fisica. Questo passaggio ha anche rivelato nuove opportunità per evolvere il modello operativo dei carichi di lavoro. 

 Oltre ad aver identificato, risolto e documentato la maggior parte delle responsabilità, ha anche definito i percorsi di escalation per eventuali responsabilità mancanti o che potrebbero cambiare con l'evolversi delle procedure operative. Per la ricerca di nuove opportunità per standardizzare e migliorare l'efficienza dei carichi di lavoro, fornisci l'accesso a strumenti operativi come AWS Systems Manager e strumenti di sicurezza come AWS Security Hub CSPM e Amazon GuardDuty. AnyCompany Retail combina una revisione delle responsabilità e della strategia sulla base dei miglioramenti che intende eseguire per primi. Man mano che l'azienda adotta nuovi modi di lavorare e modelli tecnologici, aggiorna la propria matrice di responsabilità di conseguenza. 

### Passaggi dell'implementazione
Passaggi dell'implementazione

1.  Inizia con la documentazione esistente. Alcuni documenti di origine tipici possono essere: 

   1.  Matrici di responsabilità o responsabili, affidabili, consultabili e informate (RACI). 

   1.  Definizioni dei team o pagine wiki. 

   1.  Definizioni e offerte di servizi. 

   1.  Ruolo o descrizione delle mansioni lavorative. 

1.  Esamina la documentazione e organizza discussioni sulle responsabilità documentate: 

   1.  Collaborando con i team identifica i disallineamenti tra le responsabilità documentate e quelle normalmente assunte dai team. 

   1.  Esamina i potenziali servizi offerti dai clienti interni per identificare le lacune nelle aspettative tra i team. 

1.  Analizza e risolvi le discrepanze. 

1.  Identifica le opportunità di miglioramento. 

   1.  Identifica le richieste più frequenti e con uso intensivo di risorse, che in genere sono ottime candidate al miglioramento. 

   1.  Esamina le best practice, comprendi i modelli, segui le linee guida prescrittive per semplificare e standardizzare i miglioramenti. 

   1.  Registra le opportunità di miglioramento e monitorale fino al completamento. 

1.  Se nessuno nel team è responsabile della gestione e del monitoraggio dell'assegnazione delle responsabilità, identifica qualcuno che assuma tale responsabilità. 

1.  Definisci un processo per consentire ai team di richiedere chiarimenti sulla responsabilità. 

   1.  Esamina il processo e verifica che sia chiaro e semplice da usare. 

   1.  Assicurati che qualcuno sia proprietario e segua le escalation fino al completamento. 

   1.  Stabilisci le metriche operative per misurare l'efficacia. 

   1.  Crea un meccanismo di feedback per verificare che i team possano evidenziare le opportunità di miglioramento. 

   1.  Implementa un meccanismo di revisione periodica. 

1.  Rendi i documenti disponibili in una posizione individuabile e accessibile. 

   1.  I wiki o il portale di documentazione sono le posizioni normalmente scelte. 

 **Livello di impegno per il piano di implementazione:** medio 

## Risorse
Risorse

 **Best practice correlate:** 
+  [OPS01-BP06 Valutazione dei compromessi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html) 
+  [OPS03-BP02 Potere di intervento dei membri del team quando i risultati sono a rischio](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html) 
+  [OPS03-BP03 Incoraggiamento all'escalation](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html) 
+  [OPS03-BP07 Fornitura di risorse appropriate ai team](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html) 
+  [OPS09-BP01 Misura gli obiettivi operativi e i KPI con le metriche](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html) 
+  [OPS09-BP03 Revisione delle metriche operative e assegnazione delle priorità per favorire il miglioramento](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html) 
+  [OPS11-BP01 Definizione di un processo per il miglioramento continuo](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html) 

 **Documenti correlati:** 
+  [Whitepaper AWS - Introduzione a DevOps in AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html) 
+  [Whitepaper AWS - Cloud AWS Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html) 
+  [Eccellenza operativa del Framework AWS Well-Architected: topologie del modello operativo a livello di carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html) 
+  [AWS Prescriptive Guidance - Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html) 
+  [AWS Prescriptive Guidance - Create a RACI or RASCI matrix for a cloud operating model](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html) 
+  [Blog sulle operazioni e le migrazioni Cloud AWS - Delivering Business Value with Cloud Platform Teams](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/) 
+  [Blog sulle operazioni e le migrazioni Cloud AWS - Why a Cloud Operating Model?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/) 
+  [Blog AWS DevOps - How organizations are modernizing for cloud operations](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/) 

 **Video correlati:** 
+  [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag) 
+  [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)