De nombreuses organisations ont aujourd'hui du mal à intégrer et à orchestrer des outils dans leurs environnements non-SAP et SAP. Cette déconnexion peut entraîner des inefficacités, une augmentation des charges de travail manuelles et un risque accru d'erreurs lors de la gestion des modifications SAP.
La gestion agile des changements SAP repose sur une intégration transparente et un flux de travail unifié automatisé pour réussir. Dans ce blog, nous mettons en lumière le chemin emprunté par l'un de nos clients, une compagnie d'assurance allemande, pour atteindre ses objectifs Agile/DevOps pour SAP et son excellence opérationnelle.
Un contexte pour un changement SAP agile !
Cette entreprise d'assurance, filiale d'une plus grande entreprise, exploitait son informatique de manière agile, en utilisant des outils tels que Jenkins, Jira, Tricentis Tosca et ServiceNow. Même si ces outils étaient bien intégrés dans leurs environnements non-SAP, les modifications SAP étaient gérées manuellement et étaient très fragmentées.
L'entreprise gérait les exigences et les incidents dans JIRA et ServiceNow. Cependant, il n'y avait pas d'échange automatique d'informations entre ces outils et SAP. En conséquence, les développeurs ont travaillé dur pour documenter manuellement leurs transports SAP en copiant et en collant des données, etc. Malgré tous les efforts, seulement 80 % environ ont été correctement effectués.
Ce manque d'intégration et d'automatisation a conduit à divers problèmes :
- Audits coûteux en raison de rapports incomplets et inexacts
- Tâches fastidieuses et chronophages pour les développeurs et testeurs de systèmes, qui devaient consacrer beaucoup de temps aux processus manuels. Le travail quotidien impliquait de nombreuses tâches fastidieuses et ennuyeuses pour les personnes chargées du développement et des tests du système, car elles devaient consacrer beaucoup de temps à satisfaire le processus.
- Retards dans la réalisation des objectifs Agile/DevOps pour SAP, car les étapes manuelles ralentissaient la mise en œuvre des modifications.
- Impact sur la qualité
Il était logique pour eux de rechercher une solution capable de combler l'écart : un outil qui appliquerait leurs processus même sur leurs paysages SAP et automatiserait leurs processus.s le processus de changement autant que possible. Ils souhaitaient également utiliser TOSCA de manière automatisée sur SAP pour clôturer la DevSecOps Chain.
Sprint 1 – Implémentation du Rev-Trac
Leur parcours vers DevSecOps a commencé en 2019 avec une mise en œuvre autonome de Rev-Trac Platine.
Rev-Trac a été mis en service moins de trois mois après la signature des contrats. La mise en œuvre comprenait une formation des administrateurs, la configuration du flux de travail et une formation de mise en service des utilisateurs finaux.
Ce premier sprint a assuré la cohérence des processus et amélioré la conformité, car Rev-Trac garantit qu'un ticket est attribué à un transport et applique ce processus. Certaines tâches manuelles étaient néanmoins nécessaires, par exemple l'attribution des demandes de modification ServiceNow au ticket Rev-Trac et vice versa.
Sprint 2 – Intégration de ServiceNow
ServiceNow gère les incidents comme une source de changements. Avant la mise en ligne, le processus nécessite une demande de modification ServiceNow pour obtenir les approbations du CAB.
L'intégration de ServiceNow avec Rev-Trac à l'aide des API REST offre des avantages significatifs :
- Automatisez davantage le processus en générant des tickets Rev-Trac à partir de ServiceNow
- Renforcez la conformité : la modification de SAP n'est possible qu'avec un ticket ServiceNow attribué
La configuration a pris environ deux jours après quelques obstacles organisationnels pour établir les connexions réseau.
Les résultats de ce Sprint ont apporté un grand soulagement au management et aux développeurs. Leur processus nécessite de remplir de nombreux champs dans ServiceNow, ce qui se fait désormais automatiquement, de manière cohérente et conforme.
Sprint 3 – Intégration Jira
Pourtant, ServiceNow ne traitait que les incidents, laissant un vide. De nouvelles exigences sont planifiées dans Jira et toujours gérées manuellement. L’intégration de Jira à Rev-Trac Sprint 3 était donc la prochaine étape logique.
Pour combler cette lacune, dans les problèmes Jira, ils ont défini où se connecter à Rev-Trac. Pour cette intégration, ils ont choisi des sous-tâches. Le résultat a été une intégration bidirectionnelle, mettant à jour Jira et Rev-Trac au bon moment du processus.
Le processus commence par la création d'un ticket Rev-Trac dès qu'une sous-tâche de type « Rev-Trac » a été créée dans Jira. Le ticket Rev-Trac contient des références (avec des liens) vers la sous-tâche Jira et son parent (généralement la User-Story) et la sous-tâche Jira obtient un lien vers le ticket Rev-Trac et toutes les mises à jour de statut.
Dernière étape vers SAP DevSecOps
Sprint 4 – Intégration Tricentis Tosca
Avec Tosca en place, il logique s'intégrer dansà le chaîne d'outils unifiée qui comprend Rev-Trac, Jira et ServiceNow.
Techniquement, Rev-Trac peut appeler Tosca pour exécuter des scripts de test automatisés. Tosca rend le result, et le Rev-Trac déroulement du flux de travail en fonction du résultat.
Au moment de la rédaction de cet article, Sprint 4 est encore en phase de planification.
Contact un de nos experts en gestion du changement pour plus d’informations sur Rev-Trac PlatineL'intégration bidirectionnelle de avec les outils ITSM et ALM populaires.
