Práticas recomendadas para a fase de planejamento

Durante a fase de planejamento de uma implementação greenfield do SAP, o projeto normalmente encontra vários desafios e oportunidades. Esta seção discute cinco principais aprendizados baseados no SAP em implementações AWS inovadoras nas quais a equipe de Serviços AWS Profissionais esteve envolvida. É possível implementar algumas dessas recomendações antes mesmo do início do projeto ou do envolvimento da equipe de consultoria. Fornecer rascunhos de documentos, como a matriz de perfis e responsabilidades ou a lista de contatos da equipe, ajuda a acelerar o processo de ramp-up.

Criar uma matriz RACI

Criar uma matriz de atribuição de responsabilidades para a equipe de infraestrutura é fundamental para qualquer projeto de implementação. Essa matriz assume a forma de um gráfico abrangente responsável, accountable, consultado e informado (RACI). A RACI é usada para esclarecer perfis, atribuições e tarefas em uma estrutura de equipe complexa. Ele deve ser desenvolvido em parceria com a equipe do AWS SAP Cloud, a equipe do SAP Basis, o integrador de sistemas SAP (SI) e o cliente. Essa tarefa pode ser conduzida por qualquer um desses grupos ou por um gerente de projeto. Construir a RACI sem a contribuição dessas partes interessadas cria inconsistências, lacunas e, às vezes, até conflitos. É importante considerar todas as fases do projeto. Ter a RACI antecipadamente fortalece a parceria entre todas as partes interessadas e cria clareza. Idealmente, a RACI deve ser concluído antes do início do projeto.

Aqui está um trecho de um exemplo de matriz RACI para um projeto de implementação greenfield de SAP.

Fazer download da matriz RACI completa

Analise o SoW

Entenda todos os elementos da declaração de trabalho (SoW) para serviços de AWS consultoria e consultoria e analise a SoW em conjunto com as principais partes interessadas para que os resultados sejam claramente compreendidos por todos. Se a equipe de infraestrutura pretende fazer mais do que o definido pela SoW, certifique-se de documentar isso no registro de riscos, suposições, ações, problemas, dependências e decisões (RAAIDD). Em um projeto de implementação de SAP inovador, permanecer ágil e ágil é de extrema importância, portanto, desviar-se da SoW é um cenário comum. No entanto, as expectativas podem ficar obscurecidas se o parceiro de AWS implementação começar a entregar além do que está documentado. Em caso de alterações, é necessário manter uma lista contínua do novo escopo de trabalho e das compensações que talvez precisem ser feitas. Para uma abordagem de projeto em cascata, um processo de gerenciamento de mudanças de escopo deve ser definido e implementado. Para um projeto ágil, um processo de priorização da lista de pendências é mais apropriado para gerenciar o escopo.

Considerações:

• À medida que você avança no projeto, certifique-se de capturar o novo escopo e definir quaisquer novos resultados. Isso ajudará você a gerenciar as expectativas e buscar ajuda para priorizar sua lista de pendências.

• Identifique e priorize as alterações na documentação e tarefas junto com as pendências de entrega existentes para que a documentação possa ser produzida no decorrer do projeto, em vez de ser adiada até o final.

• Conduza um passo a passo regular do SoW durante todo o projeto para se manter alinhado com os resultados e as prioridades.

• Para a transição da produção, certifique-se de ter uma SoW com acesso somente leitura aprovada com pelo menos 12 meses de antecedência para ajudar com o suporte de hipercuidados.

Criar um organograma da equipe e uma lista de contatos

Crie um organograma de alto nível que descreva as equipes e a estrutura de liderança. Aprofunde-se desenvolvendo uma lista de contatos entre equipes que inclua o nome, o título e a função de todos na equipe de infraestrutura e os principais pontos de contato para várias funções, como segurança, operações de rede e firewall, Microsoft Active Directory, operações internas na nuvem e operações de servidor. Todos devem saber quem está envolvido e qual o papel cada um desempenha no projeto. Atrasos e falhas de comunicação ocorrem inevitavelmente quando a equipe não tem essas informações. Compreender os títulos das partes interessadas também é importante. Por exemplo, você não gostaria de convidar partes interessadas em nível de diretor para sessões de design de trabalho ou reuniões stand-up diárias, a menos que elas sejam contribuidoras importantes para as discussões. Conhecer títulos e funções permite que você convide as pessoas certas para as reuniões relevantes. Ser capaz de visualizar as equipes em um organograma ajuda a entender como as equipes estão estruturadas e trabalham juntas no projeto.

O diagrama a seguir fornece um exemplo de um organograma típico de SAP em AWS infraestrutura.

Estabeleça um modelo de engajamento com sua equipe interna de nuvem

Se sua organização de TI tiver uma equipe interna de AWS nuvem, você deve estabelecer um modelo de engajamento com essa equipe e esclarecer o trabalho que ela realizará, em comparação com o que o parceiro de AWS implementação (por exemplo, Serviços AWS Profissionais ou AWS Parceiro) tem a tarefa de fazer. Uma responsabilidade fundamental a ser considerada é o suporte dos ambientes depois que eles são construídos e entregues. Por exemplo, se houver apenas dois arquitetos do AWS SAP Cloud que estão construindo uma infraestrutura de vários cenários e vários ambientes para uma dúzia de aplicativos SAP, eles não terão a largura de banda para suportar o ambiente que concluem e criam novos ambientes ao mesmo tempo. Uma opção é pedir à equipe interna de nuvem que assuma o suporte dos ambientes concluídos. Isso proporciona à equipe interna a oportunidade de aprender e assumir a responsabilidade pelos ambientes. Seus integrantes acabarão se tornando responsáveis por manter e expandir esses ambientes quando o projeto progredir e um novo escopo de trabalho for identificado.

A infraestrutura de nuvem interna e DevOps as equipes de nuvem também devem concordar com o tipo de software de automação a ser usado, por exemplo, se deve ser usado AWS CloudFormation ou o Terraform como uma ferramenta de infraestrutura como código (IaC). Da mesma forma, eles podem decidir usar o AWS Systems Manager Ansible para tarefas de configuração, como volumes de inicialização e possivelmente instalações do SAP. Essas decisões devem ser documentadas. Além disso, se houver a necessidade de um painel de monitoramento e observabilidade terceirizado, mas isso não era um produto final na SoW, considere colocar ganchos de monitoramento e registro usando o Amazon e o Amazon Simple Notification Service ( CloudWatch Amazon SNS) nesse ínterim. A equipe interna de nuvem poderá implementar a integração com uma solução de monitoramento terceirizada posteriormente.

O modelo de engajamento ou contrato de suporte também deve fazer parte da matriz RACI e ser articulado na SoW. Há um nível significativo de automação que pode ser alcançado com o uso de AWS serviços. A matriz SoW e RACI deve identificar o que precisa ser alcançado como parte do projeto inovador de implementação do SAP e o que pode ser delegado à equipe de operações.

Ao estabelecer um modelo de engajamento, determine se uma abordagem em cascata, ágil ou mista será o principal método para avançar. AWS Os Serviços Profissionais observaram um aumento de 300% na conclusão de tarefas e 94% de redução no tempo de planejamento em projetos que implementaram uma abordagem ágil ou mista em comparação com uma abordagem em cascata. Na fase de planejamento, você também deve selecionar um plano de comunicação e uma abordagem de ferramentas com a ajuda do cliente. A tabela a seguir mostra um exemplo de plano de comunicação.

Por fim, certifique-se de identificar o cliente e a equipe do SAP Basis que apoiará o projeto desde o início. Treiná-los à medida que você implementa e migra novas soluções é fundamental para iniciar as sessões de transferência de conhecimento mais cedo.

Documentar o processo de criação e implantação na nuvem

Se sua organização de TI tiver uma equipe interna de nuvem, essa equipe deverá documentar o processo de criação e implantação na nuvem usando diagramas de fluxo de processo e compartilhar esses diagramas com toda a equipe. Você quer que suas principais partes interessadas detectem facilmente quaisquer gargalos ou ineficiências no processo e entendam o papel que seus processos internos existentes desempenham na criação de ineficiências ou atrasos. No exemplo a seguir, é possível ver como os processos de ingresso no Active Directory e atualização do Sistema de Nomes de Domínio (DNS) demoram mais para serem concluídos. Ter essa visão pode motivar as equipes a colaborar e descobrir como reduzir o tempo envolvido nessa etapa do processo.

Considerações:

• Documente o processo e o fluxo de trabalho do suporte técnico separadamente, compartilhe essas informações com a equipe de infraestrutura e certifique-se de que todos tenham acesso às ferramentas de suporte técnico para que não dependam de uma pessoa. Muitas vezes, pode haver um processo de tíquete complicado e demorado para a realização de ingressos no Active Directory, atualizações de DNS, abertura de firewalls e solicitação de chaves de criptografia. É fundamental documentar esses processos e considerar o Acordo de Serviço (SLA) de cada equipe na fase de planejamento do projeto. Isso também ajuda a explicar os motivos de um atraso ou gargalo que requer atenção especial para ser removido.

• Atribua um ponto de contato nomeado para tarefas de Active Directory, firewall ou rede. Esses recursos dedicados devem fazer parte do seu projeto. Se você precisa depender de tíquetes de serviço, não há como controlar o SLA de serviço.

Roteiros de projetos e rastreador de marcos

Os gráficos a seguir fornecem um exemplo de roteiro para um projeto SAP on AWS greenfield de vários anos.

O gráfico a seguir mostra exemplos de cronogramas de engajamento com os Serviços AWS Profissionais para o mesmo projeto.

O gráfico a seguir mostra um rastreador de marcos de entrada em operação para este projeto.