Pourquoi le retail automatise et industrialise son IT plus fortement que les autres secteurs ?

A l’origine, les métiers du Retail sont informatisés principalement avec des environnements mainframes IBM. La force de ces environnements a été leur évolutivité, leur puissance et la centralisation qui a permis une expansion rapide sur tous les continents. Le retail a su au fil du temps s’adapter rapidement, démultiplier ses offres et gérer une logistique de plus en plus complexe. Il a dû s’automatiser très tôt avec des ordonnanceurs et outils de supervision dès les années 70/80 pour faire face aux volumes de transactions et la complexité engendrée.

A l’approche des années 2 000, leur IT a fortement évolué avec les projets « an 2000 » : l’adoption de l’Euro et les premiers site web pour la vente en ligne. Cela s’est traduit par l’arrivée massive des environnements ouverts, l’adoption des ERP et le début de la gestion de la donnée à grande échelle. Le degré d’automatisation n’a pas accompagné ces changements car les solutions d’automatisation mainframes en place étaient non transposables, la complexité accrue et par manque de temps avec la priorité donnée aux projets. D’autres types d’ordonnanceurs décentralisés ont été ajoutés aux existants sur la partie Open qui s’adaptaient très bien pour les serveurs magasins, par exemple, avec l’adoption des architectures distribuées. A l’inverse, l’automatisation en silos a diminué l’efficacité opérationnelle, conduit vers une maintenabilité difficile et augmenté la charge pour les exploitants de manière significative avec des coûts qui ont explosés.

Plus récemment, avec l’avènement du e-commerce et le commerce multicanal, d’autres enjeux et de nouveaux challenges sont apparus au sein des architectures et systèmes IT. La disponibilité des applications, l’accès aux données et les projets de transformation digitale incluant le BIG DATA ont créés des contraintes encore plus fortes pour les DSI. Pour résumer les changements, ils ont mis la pression sur les équipes applicatives avec des livraisons de plus en plus en continu (CI/CD), sur les équipes systèmes pour la mise en place des infrastructures Hybrides intégrant du Cloud et l’adoption des containeurs et pour finir sur les fonctions de la production qui doivent s’adapter en tendant vers le zéro arrêt.

Pour faire face à ces changements sur des délais aussi courts, une des réponses, est l’automatisation qui doit s’imbriquer avec les nouvelles organisations DevOps indispensables pour tenir les délais et les coûts. On voit apparaitre des plateformes d’automatisation qui permettent d’intégrer l’ensemble des fonctions indispensables (API, Cloud, Containers, Orchestration, CI/CD, …)

« Ce qui a changé : Avant on avait un peu temps pour régler les problèmes et les impacts restaient contenus au sein de l’IT. Actuellement, tout incident a quasiment un impact direct sur nos métiers ou directement sur notre business. »

Qu’est ce qui change la donne ?

Cette nouvelle ère voit émerger les nouvelles organisations du SI sur trois piliers majeurs : l’adoption du Cloud, l’intégration des plateformes applicatives et la gestion de la donnée centralisée. Pour garder la cohérence entre les systèmes en place et l’adoption de ces nouvelles technologies, l’automatisation est la pierre angulaire pour que cela reste exploitable au quotidien et avec la maitrise des équipes en place.

Quand on évoque l’Automatisation IT, il existe plusieurs types de process dont voici les principaux : les process de déploiement applicatifs, les process de gestion de la donnée et les process d’infrastructures. A la vitesse actuelle des changements et des évolutions nécessaires, si l’un d’eux est défaillant, c’est l’ensemble du SI qui est impacté et les métiers quasiment immédiatement touchés.

Dans une approche pas si lointaine, on adoptait une démarche de gestion en parallèle de l’ancien monde et du nouveau monde. Ce n’est plus possible de nos jours, l’imbrication est bien trop importante et tous les métiers sont informatisés créant une interdépendance quasi permanente.

Les process arrière sont de plus en plus complexes et nombreux. Tous dysfonctionnement crée rapidement des effets de bords jusqu’à la panne en cascade.

L’autre aspect d’une automatisation partielle, en silos ou obsolète joue sur la capacité d’adaptation et la vitesse d’exécution dans un SI. Si l’une des automatisations est en retard ou obsolète, Ia moins performante dictera la vitesse du changement aux deux autres.

Exemples : pour intégrer le cloud, les ordonnanceurs classiques sont un frein direct pour continuer à automatiser les tâches sur le cloud en synchronisation avec les serveurs existants. La plupart du temps, ils n’exposent pas d’API, ne sont pas sécurisés sur les flux, ne gèrent pas les jetons de connexion, ne disposent pas d’une interface Web sécurisée ou ne gèrent pas les tâches dans les containers.

Un des points majeurs à considérer, c’est d’intégrer la production et la sécurité dès le départ des nouveaux projets. Cela parait tellement naturel, mais pas encore systématiquement réalisé. Les conséquences sont des démarrages chaotiques jusqu’à l’échec et remise en cause d’un projet. Les pertes sont vites identifiées et difficilement réversibles. Les équipes se démotivent et deviennent résistantes aux changements. C’est perdant-perdant à tous les niveaux.

« Avec la mise en place du Drive, du E-commerce multicanal et de la personnalisation grandissante nécessaire pour rester compétitifs, le SI doit être très agile et architecturé pour changer rapidement. Dans les années 80, on créait un SI pour qu’il soit principalement stable, c’est une approche radicalement différente. »

Dans quel ordre doit-on procéder ?

La modernisation d’un IT, qui embarque digitalisation, cloudification, analyse de la donnée orientée business, etc. est un projet complexe et qui s’appuie sur un schéma directeur agile. Une des questions importantes à se poser est dans quel ordre j’organise mon projet ?

• Les projets menés en parallèle, c’est possible mais c’est plus bien plus coûteux et risqué. C’est souvent une solution proposée par les SSII car lucratives et invasives qui verrouillent le client. Ce n’est pas un gage absolu de rapidité, surtout en cas de difficultés techniques, souvent sous estimées. Causes : départ en retraite, obsolescence importante, SI en silos, etc.
• Les projets menés en séquentiel et en mode agile, diminue le risque et les coûts de manière sensible, mais se fait sur des délais à moyen ou long terme. Cela permet d’aller vite, d’identifier les risques au plus tôt et de répercuter les changements nécessaires sur le projet suivant dès le départ. Les ressources mobilisées seront bien moindres et le projet peut être mené avec une task force.

Au regard de mes 30 ans d’expériences, il apparaît clairement que la modernisation du socle technique en préalable est une garantie de succès bien plus importante.

Pourquoi ? Il paraît évident de ne pas installer une nouvelle application sur une infrastructure et une gestion de process ancienne ou obsolète.

Plus subtilement et souvent mal estimé, les technologies actuelles redessinent l’ensemble d’une architecture à l’heure du cloud. On se retrouve vite bloqué pour des problèmes d’API, de sécurité, liés au type d’accès, etc. La liste est longue.

Selon une étude du Gartner, 90% des projets de modernisation vers le digital échouent à cause de process techniques et fonctionnels mal maîtrisés.

Exemple : Une société dans le domaine du loisir qui a basculé son business à + de 50% dans le numérique l’a clairement démontrée : rien qu’en modernisant son automatisation et en l’étendant significativement, elle a fini son projet de refonte applicative 6 mois avant la date planifiée. La société de services et ses experts ont eux-mêmes été surpris.

A l’inverse, un projet bien avancé sur la modernisation du core demande des démarrages de projets d’automatisation en urgence pour ne pas faire déraper les délais et les coûts, voire tout simplement pour lever des impasses techniques bloquantes.

J’ai encore en mémoire des projets de refonte applicative basée sur des nouvelles architectures (en réalité, c’était seulement un changement de système) qui a coûté des sommes astronomiques sans résultats probants, encore impactant sur les coûts et la compétitivité actuels de l’enseigne.

Lors de la pandémie, une grande partie du retail français a démontré sa capacité de résilience face au changement imposé par le développement du e-commerce. Le luxe par exemple a démontré sa capacité à se déployer rapidement au niveau mondial et à basculer dans le e-commerce avec des niveaux de profits records. Ce n’est pas un hasard, leur SI s’est modernisé sur les trois piliers avec une approche pragmatique et agile. Leur organisation IT était déjà bâtie avec des process DevOps et un taux d'automatisation important jusqu'au niveau des opérations qui ont du travailler à distance ont été des contributeurs majeurs de ce succès.

Nous commençons à voir les premiers audits complets des socles techniques et fonctionnels menés en mode projet en amont des projets de modernisation vers le cloud. C’est une approche essentielle pour actualiser son SI, réussir son projet et l’aligner sur les besoins métiers pour rester compétitif.

Un autre constat que je partage, c’est l’architecture choisie. Il n’y a rien qui ressemble le plus à un SI qu’un autre SI. Les applications sont souvent identiques (Cegid retail, SAP retail,...), les bases de données sont bâties sur les même modèles et les middleware utilisés sont très semblables. Ce qui fait créera la valeur face à la concurrence, c’est la façon dont on conçoit, organise, automatise et industrialise les process qui feront la différence entre deux enseignes.

Pour mémo, voici quelques best practices pour les équipes :

• Un process non fiabilisable est un process devenu un programme : c’est une boite noire à supprimer.
• Un process non automatisable doit être réécrit : l’excellence opérationnelle n’est pas négociable !
• Un process trop complexe doit être repensé. Il est non maintenable et peu agile vis à vis du business.
• Un process contenant une tâche n’est pas un process : c’est de l’automatisation en Silo à proscrire.