Bonnes pratiques pour la phase de planification

Au cours de la phase de planification d'une implémentation inédite de SAP, le projet est généralement confronté à divers défis et opportunités. Cette section décrit cinq enseignements clés basés sur SAP sur des mises AWS en œuvre nouvelles auxquelles l'équipe des services AWS professionnels a participé. Vous pouvez implémenter certaines de ces recommandations avant même le lancement de votre projet ou avant que l'équipe de consultants ne soit impliquée. La fourniture de brouillons de documents tels que la matrice de rôles et de responsabilités ou la liste des contacts de l'équipe permet d'accélérer le processus de démarrage.

Générer une matrice RACI

L'élaboration d'une matrice d'attribution des responsabilités pour l'équipe d'infrastructure est essentielle à tout projet d'implémentation. Cette matrice prend la forme d'un tableau complet responsable, redevable, consulté et informé (RACI). La matrice RACI est utilisée pour clarifier les rôles, les missions et les tâches dans une structure d'équipe complexe. Il doit être développé en partenariat avec l'équipe AWS SAP Cloud, l'équipe SAP Basis, l'intégrateur de systèmes SAP (SI) et le client. Cette opération peut être dirigée par l'un de ces groupes ou par un chef de projet. La génération de la matrice RACI sans l'apport de ces parties prenantes crée des incohérences, des lacunes, voire même des conflits. Il est important de prendre en compte toutes les phases du projet. Le fait de disposer initialement de la matrice RACI renforce le partenariat entre toutes les parties impliquées et apporte de la clarté. Idéalement, la matrice RACI devrait être finalisée avant le lancement du projet.

Voici un extrait d'un exemple de matrice RACI pour un nouveau projet d'implémentation inédite de SAP.

Télécharger la matrice RACI complète

Passez en revue le SoW

Comprenez tous les éléments du cahier des charges (SoW) pour les services de AWS conseil et examinez conjointement le Cahier des charges avec les principales parties prenantes afin que les résultats attendus soient clairement compris par tous. Si l'équipe d'infrastructure a l'intention de faire plus que ce que le SoW définit, assurez-vous de le documenter dans le journal des risques, des hypothèses, des actions, des problèmes, des dépendances et des décisions (RAAIDD). Dans le cadre d'un nouveau projet de mise en œuvre de SAP, il est de la plus haute importance de rester agile. Il est donc courant de s'écarter du SoW. Cependant, les attentes peuvent être obscurcies si le partenaire de AWS mise en œuvre commence à fournir des résultats au-delà de ce qui est documenté. Lorsque des changements interviennent, vous devez tenir une liste récapitulative de la nouvelle portée des travaux et des compromis qui pourraient s'avérer nécessaires. Pour une approche de projet en cascade, un processus de gestion des modifications de la portée doit être défini et implémenté. Pour un projet agile, un processus de priorisation des backlogs est plus approprié pour gérer la portée.

Considérations :

• Au fur et à mesure que vous progressez dans le projet, assurez-vous de saisir la nouvelle portée et de définir les nouveaux livrables. Cela vous aidera à gérer les attentes et à demander de l'aide pour prioriser votre backlog.

• Identifiez et hiérarchisez les modifications et les tâches liées à la documentation ainsi que le backlog de livraison existant, afin que la documentation puisse être produite tout au long du cycle de vie du projet au lieu d'être retardée jusqu'à la fin.

• Procédez à un examen régulier du SoW tout au long du projet afin de rester en phase avec les livrables et les priorités.

• Pour le transfert de production, assurez-vous d'avoir un SoW avec accès en lecture seule approuvé au moins 12 mois à l'avance afin de faciliter l'assistance hypercare.

Créer un organigramme d'équipe et une liste de contacts

Créez un organigramme de haut niveau qui décrit les équipes et la structure de la direction. Allez plus loin en développant une liste de contacts entre équipes qui inclut le nom, le titre et le rôle de tous les membres de l'équipe d'infrastructure, ainsi que les principaux points de contact pour diverses fonctions, telles que la sécurité, les opérations réseau et de pare-feu, Microsoft Active Directory, les opérations cloud internes et les opérations de serveur. Chacun doit savoir qui est concerné et quel est son rôle dans le projet. Des retards et des problèmes de communication se produisent inévitablement lorsque l'équipe ne dispose pas de ces informations. Il est également important de comprendre les titres des parties prenantes. Par exemple, vous ne voudriez pas inviter les parties prenantes de niveau directeur à des sessions de conception de travail ou à des rencontres quotidiennes, à moins qu'elles ne soient des contributeurs clés aux discussions. Connaître les titres et les rôles vous permet d'inviter les bonnes personnes aux réunions appropriées. La possibilité de visualiser les équipes dans un organigramme vous aide à comprendre comment les équipes sont structurées et travaillent ensemble sur le projet.

Le schéma suivant fournit un exemple d'organigramme typique de SAP sur l' AWS infrastructure.

Établir un modèle d'engagement avec votre équipe cloud interne

Si votre service informatique dispose d'une équipe AWS cloud interne, vous devez établir un modèle d'engagement avec cette équipe et clarifier le travail qu'elle effectuera, par rapport à ce que le partenaire de AWS mise en œuvre (par exemple, les services AWS professionnels ou le AWS partenaire) est chargé de faire. L'une des principales responsabilités à prendre en compte est le soutien aux environnements une fois qu'ils ont été générés et transmis. Par exemple, si seuls deux architectes AWS SAP Cloud créent une infrastructure multi-paysages et multi-environnements pour une douzaine d'applications SAP, ils ne disposeront pas de la bande passante nécessaire pour prendre en charge l'environnement qu'ils achèvent de créer et de créer de nouveaux environnements en même temps. L'une des options consiste à demander à l'équipe cloud interne de se charger de la prise en charge des environnements finalisés. Cela donne à l'équipe interne l'occasion d'apprendre et de s'approprier les environnements. Elle finira par devenir responsable de la maintenance et de l'extension de ces environnements, lorsque le projet progressera et qu'une nouvelle portée des travaux aura été définie.

L'infrastructure cloud interne et les DevOps équipes cloud doivent également s'entendre sur le type de logiciel d'automatisation à utiliser, par exemple, s'il faut utiliser AWS CloudFormation ou Terraform en tant qu'outil d'infrastructure en tant que code (IaC). De même, ils peuvent décider d'utiliser AWS Systems Manager Ansible pour des tâches de configuration telles que le démarrage de volumes et éventuellement des installations SAP. Ces décisions doivent être documentées. En outre, si un tableau de bord de surveillance et d'observabilité tiers est requis, mais que cela ne figurait pas dans le SoW, envisagez de placer des crochets de surveillance et de journalisation en utilisant Amazon et CloudWatch Amazon Simple Notification Service (Amazon SNS) dans l'intervalle. L'équipe cloud interne peut implémenter l'intégration ultérieurement avec une solution de surveillance tierce.

Le modèle d'engagement ou l'accord de soutien doit également faire partie de la matrice RACI et être articulé dans le SoW. Il est possible d'atteindre un niveau important d'automatisation en utilisant les AWS services. La matrice SoW et RACI doit identifier ce qui doit être réalisé dans le cadre du nouveau projet de mise en œuvre de SAP et ce qui peut être délégué à l'équipe des opérations.

Lorsque vous établissez un modèle d'engagement, déterminez si une approche en cascade, agile ou mixte sera la méthode clé pour aller de l'avant. AWS Les services professionnels ont observé une augmentation de 300 % du temps d'exécution des tâches et une réduction de 94 % du temps de planification dans le cadre des missions mettant en œuvre une approche agile ou mixte par rapport à une approche en cascade. Au cours de la phase de planification, vous devez également sélectionner un plan de communication et une approche d'outillage avec l'aide du client. Le tableau suivant présente un exemple de plan de communication.

Enfin, assurez-vous d'identifier le client et l'équipe SAP Basis qui soutiendront le projet à un stade précoce. Il est essentiel de les former lors de la mise en œuvre et de la migration de nouvelles solutions pour démarrer rapidement les sessions de transfert de connaissances.

Documenter le processus de génération et de déploiement du cloud

Si votre service informatique dispose d'une équipe cloud interne, cette équipe doit documenter le processus de génération et de déploiement cloud à l'aide de schémas de processus et les partager avec l'ensemble de l'équipe. Vous souhaitez que vos principales parties prenantes détectent facilement les goulots d'étranglement ou les inefficacités du processus, et qu'elles comprennent le rôle que jouent vos processus internes existants dans les inefficacités ou les retards. Dans l'exemple suivant, vous pouvez voir comment les processus de jointure Active Directory et de mise à jour du système de noms de domaine (DNS) sont les plus longs à finaliser. Ce visuel pourrait motiver les équipes à collaborer et à trouver un moyen de réduire le temps nécessaire à cette étape du processus.

Considérations :

• Documentez le processus et le flux de travail du service d'assistance séparément, partagez ces informations avec l'équipe d'infrastructure et assurez-vous que tout le monde a accès aux outils du service d'assistance afin de ne pas dépendre d'une seule personne. Souvent, le processus de création de tickets peut être fastidieux et complexe pour effectuer des jointures à Active Directory, mettre à jour DNS, ouvrir des pare-feux et demander des clés de chiffrement. Il est essentiel de documenter ces processus et de prendre en compte le contrat de niveau de service (SLA) de chaque équipe lors de la phase de planification du projet. Cela permet également d'expliquer les raisons d'un retard ou d'un goulot d'étranglement dont l'élimination nécessite une attention particulière.

• Attribuez un point de contact désigné pour les tâches relatives à Active Directory, au pare-feu ou à la mise en réseau. Ces ressources dédiées devraient faire partie de votre projet. Si vous devez vous fier aux tickets de service, vous ne pouvez pas contrôler le SLA du service.

Feuilles de route du projet et suivi des étapes

Les graphiques suivants fournissent un exemple de feuille de route pour un projet SAP sur de nouvelles installations pluriannuel AWS .

Le graphique suivant montre des exemples de calendrier d'engagement avec les services AWS professionnels pour le même projet.

Le graphique suivant montre le suivi des étapes de mise en service de ce projet.