Pourquoi migrer votre ERP vers le cloud ne règle pas votre problème de processus

Une promesse revient à chaque réunion de migration d'ERP. "Une fois dans le cloud, tout sera plus simple." Non. Le cloud change l'endroit où tourne le logiciel, pas la façon dont votre entreprise travaille.

Si la demande d'achat passe aujourd'hui par trois validations par e-mail, un fichier Excel parallèle et un coup de fil, elle suivra le même chemin après la migration. Sauf qu'elle tournera désormais sur des serveurs à Francfort plutôt que sur une machine à la cave.

Le cloud est un lieu, pas une décision de processus

Migrer vers le cloud règle de vrais problèmes. Vous arrêtez de gérer du matériel. Vous obtenez des sauvegardes gérées, une mise à l'échelle élastique, des mises à jour sans interrompre l'activité. Cela justifie l'investissement. Mais c'est un problème d'infrastructure.

Votre problème, lui, est presque toujours ailleurs. C'est le commercial qui accorde du crédit à l'instinct. C'est le stock qui s'écarte du système parce que personne n'enregistre les retours au bon moment. C'est la clôture mensuelle qui prend deux semaines parce que la moitié des écritures vit dans des fichiers volants.

Rien de tout cela ne s'améliore en changeant de serveur. L'ERP, sur site ou en cloud, est le miroir de vos processus. Si le processus est confus, le miroir renvoie de la confusion avec un meilleur taux de disponibilité.

L'erreur du relevé "as-is" paresseux

La migration typique commence par un relevé des processus actuels. L'objectif affiché : "reproduire ce que nous avons déjà". C'est là que le projet meurt avant même de commencer.

Reproduire ce que vous avez déjà, c'est coder des décennies d'exceptions, de raccourcis et de "on a toujours fait comme ça" dans un système neuf et coûteux. Le résultat est un Frankenstein sur mesure que plus personne ne sait mettre à jour ensuite.

Le cas Lidl est l'exemple public le plus cité. Le distributeur a travaillé des années sur un nouveau système de gestion des stocks basé sur SAP. Le projet a été abandonné en 2018, après des centaines de millions investis. Une des raisons rapportées : Lidl a tenu à adapter le logiciel à son modèle d'inventaire au coût d'acquisition, au lieu d'adapter le processus au standard. Le logiciel a plié jusqu'à casser.

Vingt ans plus tôt, Hershey a pris le chemin inverse et a échoué par précipitation. L'entreprise a mis en production ERP, CRM et gestion de la chaîne logistique en même temps, juste avant Halloween, sans laisser le temps aux processus de se stabiliser. Elle n'a pas pu expédier des commandes qu'elle avait pourtant en entrepôt. La migration était techniquement faite ; l'activité s'est arrêtée quand même.

Ce qu'il faut faire avant de toucher au cloud

Le bon ordre est inconfortable, parce qu'il est plus lent au début. D'abord, vous comprenez les processus. Ensuite, vous décidez lesquels valent la peine, lesquels vous coupez et lesquels vous alignez sur le standard du logiciel. Alors seulement vous migrez.

• Cartographiez les processus réels, pas ceux du manuel. Le processus réel, c'est ce que les gens font à 17h un vendredi, avec un client en colère au téléphone.
• Pour chaque exception sur mesure, demandez pourquoi. La moitié du temps, la réponse est une règle dont plus personne n'a besoin.
• Décidez ce que vous alignez sur le standard. Une personnalisation coûteuse aujourd'hui devient une dette technique qui vous enchaîne à un fournisseur demain.
• Nettoyez les données avant de migrer. Des données sales dans un système neuf restent des données sales, point.
• Désignez un responsable pour chaque processus. Sans responsable, personne ne défend le changement quand l'équipe résiste.

La résistance interne, voilà le vrai projet

La partie technique d'une migration est la plus prévisible. API, intégrations, fenêtres de bascule : tout cela a des manuels. Ce qui n'a pas de manuel, ce sont les personnes qui ont fait l'ancien processus pendant quinze ans et le connaissent mieux que n'importe quel consultant.

Les travaux classiques sur la conduite du changement sont cohérents sur ce point. La plupart des programmes de transformation n'échouent pas à cause de la technologie. Ils échouent sur l'exécution, l'alignement et l'adhésion des gens. La HBR le résume bien dans le travail de Sirkin, Keenan et Jackson sur les facteurs durs du changement.

Voici le scénario typique : le responsable d'entrepôt reçoit un nouveau système qui l'oblige à enregistrer chaque mouvement sur le moment, au lieu de la fin de poste. Pour lui, le nouveau système, c'est plus de travail, pas moins. Si vous ne lui montrez pas le pourquoi et n'ajustez pas le processus à la réalité du terrain, il revient au fichier Excel parallèle. Et votre ERP en cloud devient une archive morte et coûteuse.

Alors, le cloud, ça vaut le coup ?

Oui. Mais pour les bonnes raisons. Migrez vers le cloud pour cesser de gérer l'infrastructure, gagner en élasticité et vous intégrer plus facilement au reste de votre stack numérique. Ne migrez pas en attendant que le changement de serveur réorganise votre activité.

La séquence qui marche est simple à dire et dure à faire. Rangez le processus. Nettoyez les données. Alignez les gens. Branchez ensuite le cloud. Qui inverse cet ordre paie deux fois : une fois pour la migration, une fois pour la défaire.

Un bon logiciel ne répare pas une mauvaise opération. Il la rend juste plus rapide à se casser. La vraie question n'a jamais été "cloud ou sur site". C'était "nos processus méritent-ils d'être automatisés tels quels ?". Dans la plupart des cas, la réponse honnête est non. Et c'est là que le projet commence vraiment.