Projets

Fleury Michon arbitre entre progiciel, verticalisation et spécifique pour son nouveau système d'information

Fleury Michon arbitre entre progiciel, verticalisation et spécifique pour son nouveau système d'information

Le charcutier familial Fleury Michon est en train de refondre son système d'information. Il a choisi de s'appuyer sur un PGI mais en se gardant de la souplesse sans remettre en cause la fiabilité.

PublicitéLa société Fleury-Michon, créée en 1904, reste un groupe familial centré sur la France. Sa DSI de 40 collaborateurs est centralisée sur son siège en Vendée, même si quelques informaticiens orientés métiers sont parfois détachés sur les sites industriels. Son système d'information a connu plusieurs époques et l'adaptation aux besoins actuels passe par l'installation d'un PGI qui, à terme, sera utilisé par un millier de collaborateurs. Ce PGI doit cependant être adapté aux besoins spécifiques de l'entreprise ainsi que de son secteur d'activité. Cela passe par un arbitrage constant entre le progiciel de base, sa verticalisation et quelques spécifiques.

Comme sa DSI, le système d'information de Fleury-Michon est globalement centralisé, à quelques exceptions près. Aujourd'hui, les postes de travail sont tous des clients légers Citrix qui peuvent, en cas de panne, être remplacés par l'équipe de maintenance industrielle sans intervention de la DSI ou d'un prestataire informatique externe. Cette équipe assure, pour les besoins métiers des usines, un service 7 jour sur 7 et 24 heures sur 24. Les serveurs, au siège, sont tantôt des IBM tantôt des Dell avec une virtualisation VMware systématique.

Trois époques de centralisation

L'informatique de Fleury Michon a toujours été centralisée. Avant l'an 2000, elle était basée sur des développements spécifiques sur AS/400. Puis elle a évolué vers une logique « Best of breed ». Ce sont ainsi pas moins de 30 progiciels différents qui ont été installés, la DSI ayant développé la totalité des interfaçages entre eux. L'intégration a donc été compliquée. Les transferts d'information passent par des batches. Chaque métier ne disposait donc pas à un moment donné des mêmes informations que les autres métiers, les écarts pouvant atteindre jusqu'à près de 24 heures. De plus, les référentiels de données étaient différents, entrainant des écarts pouvant également être difficiles à réconcilier. Au dessus de la trentaine de logiciels métiers, certains utilisateurs bénéficient d'un décisionnel BO qui permet de récupérer et de consolider des informations transverses.

« Avec le temps, la fréquence des incidents a beaucoup baissé en lien avec la stabilisation du système d'information, mais chaque panne devenait à l'inverse de plus en plus complexe et longue à réparer » se souvient Stéphane Lopez (en photo), DSI de Fleury Michon. Deux soucis ont été détectés par la direction de l'entreprise : la maintenance, donc, mais aussi l'agilité.

En 2009, la question d'opter pour un PGI du marché s'est donc posée. Outre l'agilité, il fallait que le nouvel outil potentiel assure la même fiabilité que l'ancien ainsi que le temps réel transverse aux différents métiers de l'entreprise. De plus, Fleury Michon voulait être certain d'opter pour une architecture qui serait solide et capable de durer 10 à 15 ans. Du côté de la production, la demande est expressément celle de la stabilité tandis que les utilisateurs administratifs exigent, eux, de l'agilité.

PublicitéUn PGI adapté...



Un PGI adapté

Une fois le choix de base d'un PGI accepté, encore fallait-il choisir le progiciel à déployer. Cela est passé par des phases de maquettage pour convaincre les utilisateurs. Stéphane Lopez indique : « nous avons regardé plusieurs produits. Sage X3 n'était pas assez riche sans beaucoup de développements spécifiques. A l'inverse SAP nous a semblé trop complexe, même dans sa déclinaison pré-paramétrée All-In-One. Microsoft AX nous a semblé bien et nous avons été convaincu par ADAX [Advanced Distribution for Microsoft AX], une verticalisation éditée par le Français TVH Consulting, installée sur une base SQL Server. »

Pour l'instant, le décisionnel BO a été conservé. Ses utilisateurs ne voient donc pas la différence. Mais l'implémentation du PGI, avec son référentiel unique par nature, a entraîné la redéfinition d'un vocabulaire commun à tous les métiers.

Le projet coûtera en tout un peu plus d'un million d'euros pour, à terme, un millier d'utilisateurs. « Il n'y avait pas d'écart significatif entre les différents produits regardés, du moins au niveau de l'investissement initial mais il y en avait sur le fonctionnement et la suite des opérations » observe Stéphane Lopez. Le choix d'ADAX a permis un bon transfert de compétences au sein de la DSI. Stéphane Lopez souligne ainsi : « avec ADAX, nous avons été autonomes pour démarrer l'implémentation sur notre unité au Canada mais cela n'aurait pas été le cas avec SAP. »

Pas de big bang

Tout ce qui existait fonctionnait en répondant globalement aux besoins métier. L'entreprise a donc décidé de limiter les risques et les investissements en étalant dans le temps le déploiement qui va se poursuivre jusqu'en 2015. Les modules financiers et administratifs ont été les premiers à être déployés. Les modules de logistique et de vente sont actuellement en cours de déploiement. En 2015, la gestion de la production fermera la marche.

Le MES (Manufacturing execution systems) restera cependant indépendant du PGI, de même que certains outils très pointus (en gestion de trésorerie notamment). « L'inconvénient du déploiement progressif est, bien sûr, qu'il nous faut développer des interfaces temporaires » admet Stéphane Lopez.

Ce déploiement progressif permet malgré tout de tenir compte des évolutions régulières exigées par les métiers. Si un comité de pilotage unique a permis d'assurer la cohérence du projet, chaque déploiement de module a été réalisé en s'appuyant sur un groupe projet associant des utilisateurs-clés variables selon le module concerné. L'une des difficultés a donc été de prévoir très en amont la disponibilité de ces utilisateurs-clés, avec recrutement ponctuel d'équipes de renfort pour que le travail se poursuive normalement.

Arbitrer entre progiciel / verticalisation / spécifique ...



Arbitrer entre progiciel / verticalisation / spécifique

Mais Microsoft AX est un progiciel américain. La distribution en France implique des complexités bien plus importantes qu'aux Etats-Unis ou au Canada. « Par exemple, en Amérique, il n'y a qu'un seul type de remises » note Stéphane Lopez. Cette simplicité a été bien appréciée lorsque le PGI a été déployé sur l'entité canadienne du groupe.

Les spécificités liées au marché sont couvertes par la verticalisation ADAX. Stéphane Lopez explique : « nous avons un partenariat étroit avec TVH consulting qui amène cet éditeur à faire évoluer son produit selon nos besoins. » Lorsqu'une évolution est intégrée à ADAX, l'investissement est évidemment pris en charge par l'éditeur. Mais, à l'inverse, lorsqu'un spécifique propre à des pratiques différenciantes de Fleury Michon est nécessaire, c'est évidemment l'entreprise qui en finance le développement et qui en conserve l'exclusivité.

L'évolution de Microsoft AX, comme le passage d'AX 2009 à AX 2012, a des impacts importants. Le choix d'une verticalisation inscrite au catalogue de Microsoft a été une nécessité pour Fleury Michon : l'éditeur de la verticalisation peut ainsi être informé au fur et à mesure des évolutions de sa plate-forme et adapter son propre produit très en amont.

Fleury Michon a toujours tenté de limiter le nombre de développements spécifiques afin d'éviter les problèmes d'évolution du produit. Et chaque spécifique est développé par TVH en respectant un guide de bonnes pratiques émis par Microsoft, ce qui facilite les évolutions de versions. Mais, par contre, les évolutions fonctionnelles des versions permettent aussi de supprimer des spécifiques. « Nous sommes passés d'environ 30 spécifiques avec AX 2009 à une quinzaine avec la version 2012 » indique Stéphane Lopez.

Cette stragéie permet de garantir la fiabilité du système tout en conservant la souplesse.

Oui au bon gris mais pas au mauvais gris

Le choix de Microsoft AX facilite également le transfert de données vers le tableur Microsoft Excel. A l'époque des trente progiciels best of breed, l'export Excel était souvent le seul moyen de réconcilier des données. De plus, des micro-applications développées à droite ou à gauche complétait l'informatique officielle. Cette informatique grise est honnie par les DSI.

Pourquoi, dès lors, faciliter un export vers Microsoft Excel ? Stéphane Lopez s'explique : « il existe un bon gris, notamment pour le décisionnel, mais le mauvais gris est en train de disparaître. »

Partager cet article

Commentaire

Avatar
Envoyer
Ecrire un commentaire...

INFORMATION

Vous devez être connecté à votre compte CIO pour poster un commentaire.

Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire

    Publicité

    Abonnez-vous à la newsletter CIO

    Recevez notre newsletter tous les lundis et jeudis

    La question du moment
    Avez-vous mis en place une charte ou une politique encadrant les usages de l’IA générative au sein de l’organisation ?