Best practice per la fase di pianificazione

Durante la fase di pianificazione di un'implementazione SAP greenfield, il progetto incontra in genere diverse sfide e opportunità. Questa sezione illustra cinque insegnamenti chiave basati su implementazioni SAP on AWS greenfield a cui è stato coinvolto il AWS team dei Servizi professionali. Puoi implementare alcuni di questi consigli anche prima dell'inizio del progetto o prima che il team di consulenza venga coinvolto. Fornire bozze di documenti come la matrice dei ruoli e delle responsabilità o l'elenco dei contatti del team aiuta ad accelerare il processo di avvio.

Creazione di una matrice RACI

La creazione di una matrice di assegnazione delle responsabilità per il team dell'infrastruttura è fondamentale per qualsiasi progetto di implementazione. Questa matrice assume la forma di un grafico RACI (Responsible, Accountable, Consulted, Informed). Il RACI viene utilizzato per chiarire ruoli, incarichi e attività in una struttura di team complessa. Dovrebbe essere sviluppato in collaborazione con il team AWS SAP Cloud, il team SAP Basis, l'integratore di sistemi SAP (SI) e il cliente. Questo può essere guidato da uno qualsiasi di questi gruppi o da un project manager. La creazione del RACI senza il contributo di queste parti interessate crea incongruenze, lacune e talvolta persino conflitti. È importante considerare tutte le fasi del progetto. Avere il RACI in anticipo rafforza la partnership tra tutte le parti coinvolte e crea chiarezza. Idealmente, il RACI dovrebbe essere completato prima dell'inizio del progetto.

Ecco un estratto da una matrice RACI di esempio per un progetto di implementazione SAP di nuova generazione.

Scarica la matrice RACI completa

Esamina il SoW

Comprendi tutti gli elementi della dichiarazione di lavoro (SoW) per i servizi di AWS consulenza e consulta congiuntamente la SoW con le principali parti interessate in modo che i risultati finali siano chiaramente compresi da tutti. Se il team dell'infrastruttura intende fare più di quanto definito dal SoW, assicuratevi di documentarlo nel registro dei rischi, delle ipotesi, delle azioni, dei problemi, delle dipendenze e delle decisioni (RAAIDD). In un progetto di implementazione SAP all'avanguardia, rimanere agili e agili è della massima importanza, quindi deviare dal SoW è uno scenario comune. Tuttavia, le aspettative possono diventare offuscate se il partner di AWS implementazione inizia a fornire risultati superiori a quanto documentato. In caso di modifiche, è necessario tenere un elenco aggiornato del nuovo ambito di lavoro e dei compromessi che potrebbero essere necessari. Per un approccio progettuale a cascata, è necessario definire e implementare un processo di gestione delle modifiche all'ambito. Per un progetto agile, un processo di prioritizzazione dei backlog è più appropriato per gestire l'ambito.

Considerazioni:

• Man mano il progetto avanza, assicurati di definire il nuovo ambito ed eventuali nuovi risultati finali. Questo ti aiuterà a gestire le aspettative e a chiedere assistenza per stabilire le priorità del tuo backlog.

• Identifica e assegna priorità alle modifiche e alle attività relative alla documentazione oltre al backlog di consegna esistente, in modo che la documentazione possa essere prodotta per tutta la durata del progetto anziché essere ritardata fino alla fine.

• Eseguite regolarmente una panoramica dettagliata del programma SoW durante tutto il progetto per rimanere allineati sui risultati e sulle priorità.

• Per quanto riguarda l'interruzione della produzione, assicuratevi che un SoW con accesso in sola lettura sia approvato con almeno 12 mesi di anticipo per aiutarvi con il supporto di Hypercare.

Creazione di un organigramma e di un elenco di contatti del team

Crea un organigramma di alto livello che descriva i team e la struttura di leadership. Approfondisci sviluppando un elenco di contatti tra i team che includa il nome, il titolo e il ruolo di tutti i membri del team dell'infrastruttura e i punti di contatto chiave per varie funzioni, come sicurezza, operazioni di rete e firewall, Microsoft Active Directory, operazioni cloud interne e operazioni sui server. Tutti devono sapere chi è coinvolto e quale ruolo svolgono nel progetto. Quando il team non dispone di queste informazioni si verificano inevitabilmente ritardi e problemi di comunicazione. È importante anche comprendere i titoli delle parti interessate. Ad esempio, non è il caso di invitare le parti interessate di livello direttivo alle sessioni di progettazione o agli stand-up giornalieri, a meno che non contribuiscano in modo determinante alle discussioni. Conoscere titoli e ruoli consente di invitare le persone giuste alle riunioni pertinenti. La possibilità di visualizzare i team in un organigramma aiuta a capire come sono strutturati i team e come collaborano al progetto.

Il diagramma seguente fornisce un esempio di un tipico organigramma SAP sull'infrastruttura. AWS

Stabilisci un modello di coinvolgimento con il tuo team cloud interno

Se la tua organizzazione IT ha un team AWS cloud interno, dovresti stabilire un modello di coinvolgimento con quel team e chiarire il lavoro che svolgerà, rispetto a quello che è incaricato di fare il partner di AWS implementazione (ad esempio, AWS Professional Services o AWS Partner). Una responsabilità fondamentale da considerare è il supporto degli ambienti dopo la loro compilazione e consegna. Ad esempio, se ci sono solo due architetti AWS SAP Cloud che stanno costruendo un'infrastruttura multi-paesaggio e multiambiente per una dozzina di applicazioni SAP, non disporranno della larghezza di banda necessaria per supportare l'ambiente che completano, costruendo e costruendo nuovi ambienti contemporaneamente. Un'opzione è chiedere al team cloud interno di occuparsi del supporto degli ambienti completati. In questo modo il team interno ha l'opportunità di imparare e di assumere la titolarità degli ambienti. Alla fine diventeranno responsabili della manutenzione e dell'espansione di questi ambienti, quando il progetto proseguirà e verrà identificato un nuovo ambito di lavoro.

L'infrastruttura cloud interna e i DevOps team cloud dovrebbero anche concordare il tipo di software di automazione da utilizzare, ad esempio se utilizzare AWS CloudFormation Terraform come strumento Infrastructure as Code (IaC). Allo stesso modo, potrebbero decidere di utilizzare AWS Systems Manager Ansible per attività di configurazione come l'avvio di volumi e possibilmente le installazioni SAP. Queste decisioni devono essere documentate. Inoltre, se è richiesta una dashboard di monitoraggio e osservabilità di terze parti, ma questa non era disponibile nel SoW, prendi in considerazione la possibilità di inserire ganci di monitoraggio e registrazione utilizzando Amazon e Amazon Simple Notification Service ( CloudWatch Amazon SNS) nel frattempo. Il team cloud interno può implementare l'integrazione con una soluzione di monitoraggio di terze parti in un secondo momento.

Il modello di coinvolgimento o l'accordo di supporto dovrebbero inoltre far parte della matrice RACI e articolato nel SoW. Esiste un livello significativo di automazione che può essere raggiunto utilizzando i servizi. AWS La matrice SoW e RACI dovrebbe identificare ciò che deve essere raggiunto nell'ambito del progetto di implementazione SAP Greenfield e ciò che può essere delegato al team operativo.

Quando stabilisci un modello di coinvolgimento, stabilisci se un approccio a cascata, agile o misto sarà il metodo chiave per andare avanti. AWS Professional Services ha registrato un aumento del 300% nel completamento delle attività e una riduzione del 94% dei tempi di pianificazione negli incarichi che hanno implementato un approccio agile o misto rispetto a un approccio a cascata. Nella fase di pianificazione, è inoltre necessario selezionare un piano di comunicazione e un approccio basato sugli strumenti con l'aiuto del cliente. La tabella seguente mostra un esempio di piano di comunicazione.

Infine, assicurati di identificare tempestivamente il cliente e il team SAP Basis che supporterà il progetto. Formarli durante l'implementazione e la migrazione di nuove soluzioni è fondamentale per avviare tempestivamente le sessioni di trasferimento delle conoscenze.

Documentazione del processo di creazione e implementazione del cloud

Se la tua organizzazione IT dispone di un team cloud interno, tale team deve documentare il processo di creazione e implementazione del cloud utilizzando diagrammi di flusso del processo e condividerli con l'intero team. Immagina di desiderare che le principali parti interessate rilevino facilmente eventuali strozzature o inefficienze nel processo e comprendano il ruolo che i processi interni esistenti svolgono nel creare inefficienze o ritardi. Nell'esempio seguente, puoi vedere in che modo il completamento dei processi di aggiunta e aggiornamento del sistema dei nomi di dominio (DNS) di Active Directory richiede più tempo. La visualizzazione di questa immagine potrebbe motivare i team a collaborare e a capire come ridurre il tempo impiegato in quella fase del processo.

Considerazioni:

• Documenta separatamente il processo e il flusso di lavoro dell'help desk, condividi queste informazioni con il team dell'infrastruttura e assicurati che tutti abbiano accesso agli strumenti dell'help desk in modo da non dover fare affidamento su una sola persona. Spesso, può verificarsi una procedura di ticket complicata e dispendiosa in termini di tempo per eseguire join ad Active Directory, aggiornamenti del DNS, aprire i firewall e richiedere chiavi di crittografia. È fondamentale documentare questi processi e prendere in considerazione l'accordo sul livello di servizio (SLA) di ogni team nella fase di pianificazione del progetto. Inoltre aiuta a spiegare i motivi di un ritardo o di un ostacolo la cui rimozione richiede particolare attenzione.

• Assegna un punto di contatto denominato per Active Directory e le attività di firewall o di rete. Queste risorse dedicate dovrebbero far parte del tuo progetto. Se devi fare affidamento sui ticket di assistenza, non puoi controllare lo SLA del servizio.

Tabelle di marcia del progetto e tracker delle tappe fondamentali

I grafici seguenti forniscono un esempio di tabella di marcia per un progetto pluriennale SAP on greenfield. AWS

Il grafico seguente mostra alcuni esempi di tempistiche di coinvolgimento con AWS Professional Services per lo stesso progetto.

La tabella seguente mostra un tracker dei traguardi raggiunti con il lancio di questo progetto.