Transformation vers SAP S/4 Hana : l'agilité nécessite l'automatisation

Aucun sujet ne préoccupe actuellement autant les départements SAP que le passage à SAP S/4 Hana : les données, les processus et le Customizing doivent-ils être repris tels quels dans le nouveau monde ?

Ou peut-on oser un nouveau départ en pleine nature avec l'introduction ? Et laquelle des nombreuses nuances entre les deux approches extrêmes brownfield et greenfield convient le mieux à la situation du client ?

Il n'y a pas de réponses simples à ces questions fondamentales. Après tout, les entreprises ont investi beaucoup de temps et d'argent dans le Customizing. De plus, pour des raisons commerciales, elles sont tributaires de fonctionnalités qui ne seront disponibles qu'avec les prochaines versions de S/4.

C'est pourquoi de nombreux clients SAP existants vont sans doute effectuer leur transition vers le nouveau monde par étapes : d'abord consolider leurs différents systèmes SAP ERP/ECC 6.0, puis passer à la base de données Hana et enfin implémenter les premières applications S/4.

En conséquence, ils exploiteront les deux générations de logiciels en parallèle. Dans le cadre de cette "double maintenance", les équipes SAP doivent développer, tester et mettre en œuvre des modifications et des innovations pour les deux mondes, ainsi que déployer des mises à jour dans les deux environnements.

En outre, les modèles pour les systèmes SAP ERP/ECC comme S/4 doivent être protégés et maintenus afin d'éviter les difficultés liées à des modifications différentes d'une même configuration dans les deux mondes.

Pour que cette complexité ne se fasse pas au détriment de l'agilité, les responsables SAP envisagent de plus en plus de convertir leurs processus à DevOps. Les avantages qui en découlent sont trop évidents : pouvoir réagir plus rapidement aux exigences de l'entreprise et mettre à disposition des innovations grâce à l'imbrication étroite du développement et de l'exploitation.

Or, dans le cas de projets de grande envergure comme l'introduction de SAP S/4, rien ne doit aller de travers, les arrêts du système et donc les pertes d'activité doivent être évités à tout prix.

Contrôle ou risque - c'est le choix auquel sont confrontés de nombreux managers SAP qui s'accrochent encore au modèle en cascade éprouvé. Et ce, bien qu'ils ne remettent pas en question le concept DevOps en soi et que SAP contribue largement à convaincre ses clients des avantages du DevOps.

Ainsi, les méthodes agiles sont déjà soutenues depuis 2010 dans SAP SolMan et constituent depuis 2015 le noyau de SAP Activate, la méthodologie de mise en œuvre pour S/4. En particulier, lors de l'implémentation des exigences, SAP Activate prévoit une mise en œuvre selon le modèle de l'approche agile Scrum en cycles courts et itératifs - appelés sprints - par de petites équipes puissantes et interdisciplinaires de développeurs, d'administrateurs et de responsables qualité.

Pour maîtriser le problème de la complexité sur le chemin de S/4 et passer du modèle en cascade à des méthodes plus modernes comme SAP Activate ou carrément à DevOps, la solution pour les équipes SAP réside dans l'automatisation.

Cela profite non seulement aux processus de développement et de livraison, mais aussi aux processus de test. Cela vaut aussi bien pour les tests de nouvelles fonctions dans le cadre de la migration que pour les tests de régression des processus existants dans SAP ECC.

En raison de la taille et de la complexité des environnements SAP, anciens et nouveaux, des procédures de test aussi complètes ne peuvent être mises en œuvre qu'au moyen de l'automatisation. Inversement, si les transports et les modifications sont effectués manuellement et à un rythme soutenu, l'intégration et la mise à disposition continues sont liées à des risques.

En fait, dans les paysages SAP, seule l'automatisation crée la confiance nécessaire pour DevOps. Et plus le degré d'automatisation de la livraison continue, de l'intégration continue et des tests continus est élevé, plus la migration et la transformation vers S/4 sont rapides.

Pour que les responsables SAP n'aient plus à choisir entre contrôle et risque, il faut donc une chaîne d'outils intégrée et hautement automatisée pour toutes les phases de la migration, y compris la double maintenance.