Agilité et ERP : retour de terrain

La Transformation des entreprises n’est pas une aventure facile. Chez aqoba, on le sait, lorsque les clients nous contactent c’est pour les aider à installer de vrais changements impactants, souvent pour venir appuyer ou relancer des transformations qui n’ont pas abouties ou qui au contraire sont en marche mais n’ont pas réussies à embarquer tous les composants du système.

Souvent quelques bastions résistent ou sont les dernières équipes embarquées alors que leur rôle est prépondérant dans la vie du delivery ou de la stratégie d’une entreprise : les équipes infrastructures et les équipes transverses, notamment celles en charge d’ERP.

Un ERP késako? : Vous en avez deja certainement entendu parlé des solutions packagées de SAP, Oracle, Sage ou encore Microsoft Dynamics?

Ces entreprises commercialisent leur ERP (Enterprise Resource Planning), un progiciel intégré qui permet de piloter l’ensemble des fonctions clés d’une entreprise ( tels que la finance, les ressources humaines, les, les ventes, le marketing ou encore la relation client) au sein d’un système centralisé. Il connecte les différents services et fluidifie la circulation de l’information en interne. Ces services sont parfois externalisés, confiés à des intégrateurs ou des plateformes en TMA. Mais pour s’assurer que l’outil sert bien l’entreprise, certaines DSI font le choix de gérer en interne les choix fonctionnels et techniques et de constituer des équipes dédiées.

L’utilisation de Scrum dans ces contextes d’équipes en charge d’application ERP soulève des défis uniques, liés notamment à l’inflexibilité des outils, la complexité fonctionnelle dès lors qu’on s’écarte du standard, la dépendance à des roadmaps éditeurs ou encore la transversalité des équipes.

Et comme aqoba est souvent appelée là où ça gratte encore un peu dans le système, mes 3 dernières missions se sont déroulées auprès d’équipes en charge de ces progiciels intégrés, notamment SAP,Microsoft Dynamics Finance encore Salesforce pour la partie CRM.

Cet article a pour objectif de vous présenter mon regard et mon retour d’expérience sur comment l’agilité peut répondre aux enjeux spécifiques dans ces équipes et plus largement son impact à l'échelle des DSI.

Mais d’ailleurs pourquoi vouloir “agiliser” les équipes ERP ?

Dans un contexte où les DSI sont de plus en plus sollicitées pour livrer rapidement des solutions alignées avec les besoins métiers, l’agilité apparaît comme un levier stratégique, y compris pour les équipes en charge des ERP. L’objectif n’est pas simplement de gagner en vitesse, mais surtout de renforcer la collaboration avec les parties prenantes, de mieux prioriser les demandes et d’accroître la visibilité sur les travaux en cours, ce qui est souvent largement optimisable dans ces équipes.

Traditionnellement, les projets ERP sont lourds, longs, très techniques et pilotés en mode « commande-livraison » : les métiers expriment un besoin → l’équipe ERP l’exécute. Cela entraîne :

• des délais longs,
• des priorités mal gérées,
• peu de visibilité pour les métiers,
• beaucoup de développements spécifiques coûteux et difficiles à maintenir

L’adoption de Scrum dans ces environnements complexes permet donc de sortir d’un fonctionnement en silo ou en mode client/fournisseur, pour évoluer vers une logique de co-construction et de responsabilité partagée.

Ce changement de prisme est essentiel : il ne s’agit plus de répondre mécaniquement aux demandes métiers, mais de mobiliser l’expertise des équipes ERP pour tirer le meilleur parti des standards produits, plutôt que de céder systématiquement à la tentation du développement spécifique.

Ce dernier qui répond à court terme aux besoins métiers mais compromet souvent la maintenabilité à long terme , entraîne fréquemment des surcoûts, et ne garantit pas toujours la pérennité des solutions.

Dans cette dynamique, les équipes, même très techniques et spécialisées, deviennent des actrices à part entière de la transformation digitale.

Enfin, ne pas embarquer les équipes transverses dans des DSI en mutation agile, complique grandement les exercices de planifications, d'anticipation et de transparence dans des contextes dits à l’échelle.

Maintenant qu’on comprend l’importance d’embarquer ces équipes, quelles sont les contraintes auxquelles on risque de faire face?

Ces outils, souvent imposés par le marché, viennent avec leur lot de contraintes : cycles de release fixes et dépendance à l’éditeur (limitant la capacité à livrer en continu) architecture rigide ou encore personnalisation restreinte.

Les équipes doivent souvent composer avec des demandes métiers en flux continu, des charges de maintenance et de support chronophages, parfois en tension avec les engagements et le travail en sprint . Elle vivent aussi avec de fortes dépendances, liées à l’intégration avec d’autres modules et applicatifs, ainsi qu’aux silos historiques de type d’applicatifs.

À cela s’ajoutent les relations parfois rigides avec les intégrateurs, des coûts élevés des experts ERP dans des contextes budgétaires parfois serrés ( et pourtant pas question de se tromper sur le casting vu l’expertise appartient à une niche) et des organisations “projet” pas toujours pensées pour l’itératif : les outils sont souvent utilisés dans des cadres métiers très réglementés, avec des processus longs et complexes et des spécificités fonctionnelles fortes.

Faire cohabiter une méthode itérative et axée sur la valeur avec des besoins plutôt structurés autour de cycles en V, représente un véritable défi qui exige de concilier flexibilité et conformité sans compromettre ni l’un ni l’autre.

Sans oublier la dette technique parfois bien installée sur les systèmes anciens, ou au contraire des chantiers encore balbutiants sur des solutions fraîchement intégrées.

Bref, avant de pouvoir parler de Scrum, il faut déjà adapter le terrain de jeu. Mais c’est faisable, à condition d’y aller avec pragmatisme, souplesse et un vrai travail d’alignement collectif ( sans toutefois renier les fondamentaux!)

Quelles sont les vertus de Scrum que je peux viser et quels ajustement sont nécessaires pour y parvenir?

Une cible agile, Scrum notamment dans le cadre de mes missions, on le sait, va apporter de nombreux bénéfices : un cadre transparent qui facilite la priorisation et la visibilité sur les travaux en cours, va renforcer l’autonomie de l’équipe et créer une collaboration plus fluide avec les métiers ou les équipes produits.

Pour que Scrum soit efficace plusieurs adaptations sont nécessaires, dont voici quelques-unes mises en place dans mes équipes suite à l’observation de ces écosystèmes.

Premier constat, les équipes ERP sont souvent peu habituées aux méthodes agiles et nécessitent un temps d’appropriation plus long des outils et artefacts Scrum. Cela m’a conduit parfois à accepter une phase où je “ fais un peu “ Scrum, je mets à jour “à la place de” là où je devrais “faire avec” le temps que chacun trouve progressivement sa place et comprenne pleinement sa contribution.

La contribution, parlons-en.

Le Product Owner par exemple, a un rôle particulièrement exigeant : son rôle initial est développer la vision et la vie de son produit

notamment par la gestion de son le backlog , la priorisation des demandes et la récolte du feedback utilisateur.

Mais dans les faits, il a également un rôle dans la dev team, puisqu’en tant qu’expert fonctionnel il prend aussi en charge une part de la construction par la configuration et le paramétrage de l’ERP.

Il devra également maîtriser et être en veille permanente des standards proposés par l’outil.

En effet, coder du sur-mesure entraîne de nombreux risques : en plus d’un coût élevé, cela complique la maintenance et va souvent à l’encontre de l’idée d’exploiter au mieux les capacités natives de l’outil.

Cette recherche nécessaire du standard casse un paradigme de l’agilité, dans lequel l’équipe cherche à répondre au plus près des besoins exprimés par l’utilisateur, alors que dans dans le cadre d’un ERP ont est souvent amené à demander à l’utilisateur de changer sa manière de faire pour correspondre aux standards préconisés.

Les réalisateurs de la dev Team ont souvent un profil très technique, parfois spécialisé sur un seul module ou une seule technologie, et peuvent manquer de recul fonctionnel.

Cela entraîne une dérive sur la rédaction des user stories qui sera souvent plus détaillée et précise que dans un contexte logiciel classique, avec des critères d’acceptation bien clairs et souvent techniques, pour s’assurer que les adaptations restent conformes aux standards du produit et aux contraintes métiers.

Toute la difficulté sera donc de constituer des équipes suffisamment acculturées à leur Produit et à son domaine de façon à faciliter la communication et la compréhension entre le PO et son équipe,qui sera en capacité de l’aiguiller et de le challenger sur ses propositions.

L’équipe de développement nécessite aussi souvent l’identification d’un Tech Lead, rôle pourtant non défini dans Scrum, qui sera le garant de l’architecture et des bonnes pratiques préconisées par l’éditeur et aura un rôle phare de veille des évolutions fonctionnelles et techniques de l’outil, afin de s’assurer de sa compatibilité avec l’architecture de l’entreprise.

Autre point de vigilance : ** les différents acteurs ont souvent des compétences et des expertises précises**, sur certains modules, certaines technologies ( par exemple un dev ABAP pour SAP pourra avoir une expertise sur le module FiCo mais pas du tout sur RH, etc.., pour Salesforce on nécessitera souvent d’un expert de la gestion des Flux type Mulesoft, et de développeurs Apex pour le code principal..).

Ces spécificités amènent à ne plus avoir des réalisations guidées par la valeur mais plutôt par la compétence de l’équipe.

Ce qui est contraire aux pratiques de Scrum.

Pour gérer cela on aura tendance à vouloir affecter les stories pour optimiser l’occupation des développeurs. Ce n’est clairement pas idéal, mais selon la maturité de l’équipe on peut accepter quelques temps ces accrocs et affecter les tickets en sprint planning.

J’ai la croyance que l’affectation limite l’autonomie de l’équipe et son auto-organisation.

Et pourtant dans ce contexte, et en début de mission, elle s’est montrée libératrice pour les devs et a facilité l’engagement de chacun sur la capacité à faire et sur les objectifs de sprint à chaque nouvelle itération.

Et tout en pratiquant cette affectation des items, rien n’empêche d’organiser des sessions de partage de connaissances techniques sur les bonnes pratiques ou les modules communs, de présenter le travail de chacun, d’encourager le peer programming et le peer review, d’aller cherche le fameux “T-shaped” des compétences., pour adresser la pluridisciplinarité au bon moment, et à terme ne plus affecter.

OK mais j’adapte comment mes artefacts?

La Definition of Done doit intégrer des validations spécifiques, telles que les tests sur multiples environnement, la conformité aux exigences éditeurs, ou encore la recherche systématique de la solution standard avant de démarrer tout développement sur mesure.

La gestion documentaire : oui le manifeste Agile nous parle d’un logiciel fonctionnel avant une documentation exhaustive. Mais dans le cas où le premier principe est deja un peu émoussé, l’outil étant au centre des choix, il est important de s’assurer que la connaissance du standard et des fonctionnalités de l’outil est documentée en interne( et pas seulement sur la doc de référence de l’éditeur), pour identifier rapidement les besoin ou là il y a deja eu des adaptation customs, et l’impact que ces modifications peut avoir.

La structuration de cette documention et quelques préconisations pourront être présentées dans un futur article, tant celle ci est importante.

Le backlog, lui, se distingue souvent par une prédominance des tâches techniques et des spikes par rapport aux user stories classiques orientées métier. Cette particularité s’explique par la complexité technique des environnements ERP, où les équipes doivent régulièrement investiguer, expérimenter ou préparer des solutions avant de pouvoir définir précisément des fonctionnalités métier.

Les spikes ou POC (activités exploratoires destinées à réduire l’incertitude technique ou fonctionnelle ) occupent donc une place importante, permettant de valider des choix d’architecture, d’intégration ou de paramétrage.

Par conséquent, le backlog est fréquemment un mélange hybride où la valeur métier cohabite avec des travaux techniques indispensables, ce qui demande au Product Owner et à l’équipe de trouver un équilibre pour maintenir un focus sur la valeur tout en gérant la complexité sous-jacente.

Pour gérer efficacement un backlog ERP, plusieurs bonnes pratiques peuvent être mises en œuvre.

Le Product Owner travaille en étroite collaboration avec les équipes techniques pour bien comprendre la nature et l’enjeu de ces travaux exploratoires, afin de les prioriser judicieusement en regard de la valeur métier attendue.

Pour éviter que le backlog ne devienne trop technique et perde de vue les besoins métiers, il est conseillé de distinguer clairement les types de travaux (user stories, tâches techniques, spikes) et d’utiliser des catégories ou des tags dans l’outil de gestion.

Cette visibilité aide à équilibrer la planification et à communiquer plus clairement avec les parties prenantes.

Les spikes doivent être limités dans le temps avec des objectifs précis, permettant de valider rapidement des hypothèses sans s’éterniser sur l’exploration.

Il est donc bénéfique d’intégrer régulièrement des sessions de refinement pour adapter les tâches techniques selon les retours métiers et ajuster les priorités, garantissant ainsi un backlog vivant et aligné avec la création de valeur.

Petite note : afin de toujours mieux adapter mon approche aux besoins de mes équipes j’ai fait quelques petites recherches. J’ai trouvé l’existence de “méthode agiles” spécifiquement conçues pour des équipes ERP type SAP Activate qui se positionne comme un** **cadre hybride, combinant approche agile, conduite du changement, et recommandations SAP sur le paramétrage et l’adoption des fonctionnalités standards. .

Mais j’ai fait le choix de ne pas m’y aventurer pour plusieurs raisons. J’y ai vu une agilité de façade qui conserve surtout une logique de phase séquentielle héritée du cycle en V. Le backlog issu des best practices reste orienté solution, et non pas valeur métier. Les équipes y dépendent des consultants/intégrateurs : l’esprit agile de responsabilisation collective est donc parfois plus difficile à faire émerger, et ces profils d’experts externes sont habitués à des schémas contractuels et décisionnels traditionnels, ce qui freine l’adoption d’une vraie culture agile.

Ce qui m'intéresse dans mon métier d’accompagnement des équipes c’est précisement de travailler sur la culture, la gouvernance, et l’organisation produit. Or ce cadre hybride n’en parle pas du tout.

Et mon rôle d’accompagnement dans tout ça?

Dans ces missions j’ai assez vite compris que mon rôle de Scrum Master allait bien au-delà de l’animation des cérémonies ou de l’explication des rôles.

Au départ, j’ai eu tendance à vouloir poser un cadre Scrum très structuré, assez rapidement, en pensant que cela sécuriserait les équipes et accélérerait leur montée en maturité. J’ai mis en place les rituels, les artefacts, les rôles… mais avec le recul, j’ai compris que j’étais allé trop vite. Le processus paraissait rigide, parfois artificiel, et n’avait pas encore trouvé de résonance dans leur quotidien très contraint, entre run, intégration, configuration et dépendances multiples.

J’ai dû faire un pas de côté, revenir à l’écoute, et adapter le cadre en fonction de leur réalité opérationnelle.

Aujourd’hui, j’aborde ces accompagnements avec plus de patience et de pragmatisme : mon objectif est d’aider les équipes à trouver leur propre rythme, à faire comprendre le sens des pratiques agiles, et à construire des repères durables.

Cela passe aussi par l’animation d’un dialogue constant entre les équipes, les intégrateurs, les métiers, et les fonctions support.

Et surtout, j’ai appris à vraiment défendre mes équipes : à leur donner les moyens de dire non, de poser un cadre clair sur leur capacitaire, et de faire respecter leurs décisions, en particulier lorsqu’elles choisissent de déprioriser une demande métier pour stabiliser un socle technique. Car dans un ERP, livrer une fonctionnalité sans avoir sécurisé l’environnement qui l’héberge revient souvent à construire sur du sable : la valeur apparente masque une dette technique qui fragilise tout le système.

Dans ces environnements ERP complexes, mon rôle consiste surtout à créer les conditions pour que l’agilité prenne racine sans être plaquée, en acceptant que cela prenne du temps, mais aussi que ce temps est nécessaire pour faire émerger une dynamique collective solide et adaptée.

Accepter de ne pas exploiter complètement ses hard skills acquis au fil des accompagnements, au profit de développement de soft skills plus profonds : se focaliser sur l’humain, donner confiance aux équipes dans leurs capacités à s’adapter au changement.

Ces accompagnements, en tous cas pour moi, sont éprouvants et nécessitent des remise en question permanentes, mais sont extrêmement riches en apprentissages sur les comportements, la manière dont sont perçues certaines équipes en entreprise et comment y remédier.

Un petit mot pour conclure?

L’agilité dans les équipes ERP est non seulement possible, mais elle est un véritable levier de performance, à condition d’y apporter les ajustements pragmatiques que le contexte impose. L’objectif n’est pas d’appliquer Scrum “by the book“, mais de s’appuyer sur ses principes pour construire un cadre de travail durable, centré sur la valeur, la collaboration et l’adaptation continue.

Dans ces environnements souvent perçus comme rigides, l’accompagnement par un coach plutôt capé ou qui a déjà rencontré ces typologies joue un rôle clé pour faire émerger une agilité qui a du sens et qui tient dans la durée.

Avec le temps, j’ai assimilé que ce n’est pas la maîtrise théorique du framework qui fait la différence, mais la capacité à lire un contexte, à entendre ce qui se joue réellement dans les équipes, et à ajuster les curseurs avec justesse. J’ai aussi appris, souvent à travers mes propres erreurs, à ne pas plaquer un cadre trop vite, à laisser de la place à l’expérimentation, et à soutenir les équipes dans la durée, même lorsque le terrain semble peu propice.

D’ailleur je repense souvent à cette petite phrase prononcée par la Product Manager et la Tech Lead d’une de mes équipes, qui, il y a deux ans, m’avaient dit : « L’agilité ? Ce n’est clairement pas compatible avec notre ERP. » Et pourtant… En avançant pas à pas, en adaptant les pratiques sans jamais perdre de vue le sens, leur équipe a évolué, grandi, et s’est structurée autour d’un véritable produit Finance. Aujourd’hui, elle constitue l’un des Trains SAFe de la DSI, au cœur des enjeux stratégiques de l’entreprise. Et ça c’est une petite fierté que de savoir que j’y ai contribué 🙂.

Si vous travaillez dans un environnement ERP et que vous vous posez les mêmes questions, ou si vous avez vécu des expériences similaires ,ou complètement différentes, je serais ravi de lire vos retours et d’échanger sur vos pratiques 🙂.