Un catalyseur de changement

Le même sondage a toutefois révélé que "74% des membres de la DSAG et 13% des membres de l'ASUG pensent que l'introduction aura un impact sur les processus commerciaux". Il s'agit donc vraisemblablement d'une transformation qui va bien au-delà des simples questions techniques et qui se poursuivra longtemps après la mise en service.

C'est l'une des raisons pour lesquelles de nombreuses entreprises profitent de leur migration S/4 pour remettre en question les approches bien établies de la gestion des systèmes SAP et se demandent à cette occasion à quoi pourrait ressembler une approche optimale (ou optimale pour l'entreprise concernée), compte tenu des évolutions technologiques, de la fragmentation des chaînes d'outils et des exigences croissantes des clients. 

Dans cette série, j'examine trois changements forcés ou rendus possibles par la migration vers S/4, même si, d'un point de vue technique, ils ne sont pas une condition obligatoire de réussite.

Les équipes SAP utilisent de plus en plus des concepts modernes de développement de logiciels. Les avantages de CI/CD et DevOps sont largement reconnus. Dans ce contexte, une nouvelle enquête de Google a révélé que les meilleurs du secteur sont capables de déployer un nouveau code à un rythme impressionnant de 6570 fois plus rapide que les pires. Il ne fait aucun doute que des avantages similaires peuvent être obtenus par les équipes SAP.

Un projet de transformation S/4 est la justification idéale pour explorer de nouvelles méthodes de travail, non seulement pour accélérer le projet, mais aussi pour assurer une plus grande agilité et productivité une fois que le système est opérationnel. Les entreprises prévoyantes peuvent même décider d'introduire DevOps dans leur projet S/4 avant qu'il ne commence, afin que la nouvelle méthode de travail soit déjà ancrée et puisse créer de la valeur lorsque le passage à S/4 aura lieu.

L'automatisation est essentielle à la réussite de DevOps, que ce soit dans le cadre d'une transformation S/4 ou non. Dans les deux cas, vous avez besoin d'une automatisation adaptée à l'architecture technique de SAP. Un logiciel de ce type - comme -ActiveControl de Basis Technologies - doit également offrir la flexibilité, l'agilité et la gestion allégée qui permettent de réagir rapidement à l'évolution des processus DevOps.

Peut-être plus important encore, une automatisation SAP DevOps doit relier les chaînes d'outils existantes afin de protéger davantage le processus de changement contre les gaspillages et les risques au fur et à mesure que les systèmes S/4 sont construits et optimisés. Il peut s'agir de choses aussi simples que la mise à jour automatique des exigences gérées dans Jira ou ServiceNow au lieu de leur ressaisie manuelle, ou d'opérations complexes comme l'intégration de SAP dans un pipeline de livraison orchestré et comprenant plusieurs applications via des produits comme Jenkins ou GitLab.

L'analyse de la chaîne de valeur est un sujet d'actualité dans le monde DevOps. Il s'agit du processus de définition de chaque étape faisant partie des flux de changements et d'informations nécessaires à l'ensemble du parcours d'un produit logiciel, de la conception à la livraison. Elle devrait donc constituer un apport important lors de la conception de votre pipeline de livraison de logiciels. L'automatisation DevOps ne facilite pas nécessairement la définition des flux de valeur, mais elle joue certainement un rôle central dans leur gestion - par l'intégration de la chaîne d'outils, l'orchestration de la livraison des logiciels, la surveillance des indicateurs clés de performance et plus encore.

Malgré les avantages potentiels de DevOps pour SAP, certaines entreprises y voient un état à atteindre une fois que le défi de la migration S/4 et toute sa complexité ont été maîtrisés. Pour elles, le développement agile est au contraire une première étape plus facile à réaliser. Dans le prochain numéro, j'examinerai comment le développement agile peut aider les équipes SAP.