ERP et agilité

Aujourd’hui les grands groupes industriels font face à une multiplication des solutions de gestion dans leurs filiales avec un constat, plus on s’éloigne du centre et plus les solutions se font hétérogènes et exotiques. Ces différentes solutions vont de SAP, leader du marché pour lequel les processus sont presque gravés dans le code jusqu'à un simple ensemble d’outils de bureautique : un tableur pour suivre les commandes et un éditeur de texte pour émettre des factures. Entre ces deux extrêmes il existe quelques acteurs majeurs : Oracle EBS, SAGE, NAVISION... et de nombreux éditeurs locaux.

Comment rationaliser un écosystème aussi diversifié ?

Au niveau du groupe les gains d’une solution uniforme sur l’ensemble des entités sont évidents :

• reporting simplifié
• économies réalisée sur la formation aux outils
• capitalisation des équipes IT
• rationalisation du SI

D’un autre coté, les filiales en devenir veulent être capables d’évoluer rapidement sans être contraintes par un outil mais en ayant la possibilité d’informatiser un processus qui émerge de leur organisation. Et cela passe donc par des choix différents de ce qui est proposé par la maison mère. Il sera souvent préféré une solution ERP intermédiaire au core model pour de nombreuses raisons dont :

• des coûts moindres
• une maîtrise du périmètre des processus implémentés
• la rapidité de mise en œuvre

Ces points se résument à un choix entre simplicité et complexité qui est proposé par le centre. Or le coeur est complexe parce qu’il est riche et cette richesse est intrinsèquement lourde, ce qui est un atout au centre mais deviendra un frein dans les jeunes filiales.

Certains éditeurs essaient de pallier à cette problématique en proposant des solutions distinctes pour des BU de tailles différentes, c'est le cas par exemple avec SAP Business One, mais ce modèle ne fonctionne pas. Les synergies entre les solutions sont détruites au fur et à mesure que l’on essaie d’adresser les besoins de l’une ou l’autre des cibles.

Alors comment faire ? Et surtout, comment bien faire ?

A l’approche top-down qui définit une cible au centre, nous allons préférer l’approche bottom-up. Construire une application qui réponde aux besoins des petites entités, puis augmenter le périmètre avec des entités plus importantes jusqu’à rejoindre le core model… peut-être. Nous allons donc nous inspirer de la méthodologie agile, itérative, pour construire le coeur de cet ERP de façon incrémentale.

La base doit être acceptable par de toutes petites structures et solide afin de pouvoir grandir. Pour cela les critères de choix vont être les suivants :

• des coûts réduits
• une technologie éprouvée
• un périmètre fonctionnel qui couvre 80% des besoins

C’est donc naturellement que nous allons chercher des candidats du coté des projets open source matures : OpenERP, Compiere, Neogia, ERP5.... Souples et robustes, ils sont modulaires ce qui est l'empreinte d’un développement communautaire au niveau de l’architecture logicielle. Cette modularité est la garantie d’une évolutivité future. De plus, les projets open source nous apportent des technologies ouvertes et standardisées facilitant l’intégration avec d’autres systèmes.

Et c’est un point important, l’approche d’OCTO n’est pas de créer un second core model décorélé du centre, en concurrence avec le centre. Il s’agit de réaliser un système qui soit potentiellement une marche vers le système central, une marche qui rapproche du centre. Ainsi cette solution apporte de la valeur à la filiale ET au centre.

Le choix d’une approche incrémentale pour la rationalisation du SI est différenciante dans le sens où il s’agit d’accompagner la création de valeur depuis le début d’une activité. Le système qui va être implémenté doit aider l’organisation cible sur un cycle court en terme de réalisation de « business » et sur un cycle long en l’aidant à s’intégrer dans le core model du centre. Et ceci de façon progressive. La méthode agile va nous permettre de faire évoluer en douceur l'ERP retenu vers les limites fixées : couvrir X% des processus, supporter une charge maximum de X utilisateurs...

Bien que les notions d'ERP et d'agilité puissent paraître antinomiques, il s'avère possible de profiter du meilleur des deux mondes dans ces projets souvent réputés pour être très lourds à cadrer, à réaliser et à mettre en oeuvre.

Dans un prochain article, nous verrons comment aborder ce type de projet d’un point de vue organisationnel et fonctionnel. Les projets ERP forment intrinsèquement un ensemble de fonctionnalités fortement imbriquées et nous verrons comment, avec une approche agile / incrémentale, nous allons pouvoir segmenter ces projets dans des livraisons fréquentes et fonctionnelles apportant de la valeur aux métiers régulièrement.