Bilan : une intégration plus complète du dialogue «commercial-production» et une réduction des délais de livraison pour les clients de Transrail B&V.
La solution intégrée en logiciel libre OFBiz Neogia est destinée aux PME/PMI de 20 à 500 personnes et aux filiales de grands groupes. La couverture fonctionnelle de la solution gère l'ensemble des besoins des PME, de la gestion de production jusqu'à la finance en passant par la collaboration logistique, la gestion commerciale, le CRM et le e-commerce.
La modularité de la solution permet des mises en ½uvre partielles et progressives afin de pouvoir répondre au plus près aux besoins présents et futurs de l'entreprise. La solution OFBiz Neogia fournit également des outils de reporting et de pilotage puissant au travers d'une interface 100% Web.
OFBiz Neogia est un logiciel libre publié sous la licence GPL permettant d'initier des collaborations fortes entre les utilisateurs et les intégrateurs de la solution tout en réduisant très fortement les coûts de maintenance pour le client. Transrail B&V est une PME industrielle spécialisée dans la fabrication de transformateurs pour le domaine ferroviaire, présente en France et en Chine. Son portefeuille client est composé pour l'essentiel de clients internationaux.
Courant 2005, la société Transrail B&V est détachée du groupe Schneider pour intégrer le groupe SDCEM. Le système d'information de la société est géré à partir de l'ERP Baan IV qui a été déployé au sein des filiales du groupe Schneider. Cette solution de gestion, ainsi que la gestion du réseau, sont externalisées auprès de Cap Gemini, dans le cadre d'un accord groupe.
Les termes de l'accord d'outsourcing de Schneider permettent à Transrail B&V de continuer à en bénéficier 18 mois après la scission. Au-delà de ces 18 mois, Transrail B&V doit faire le choix de :
- soit internaliser l'ERP Baan IV,
- soit signer un nouvel accord d'outsourcing avec Cap Gemini,
- soit migrer son ERP vers une autre solution de gestion.
Le logiciel Baan IV, dont le paramétrage ne prenait pas entièrement en compte les besoins spécifiques de Transrail B&V de la fabrication à la commande, était utilisé de manière inadéquate par les utilisateurs. De plus, le contrat de maintenance proposé par l'éditeur en vue de remplacer le contrat global du groupe Schneider, s'avérait trop onéreux pour Transrail B&V. Cette situation a encouragé la société à étudier le marché.
Sur les conseils d'une SSII intervenant déjà sur le développement d'une application spécifique de dimensionnement des produits de Transrail B&V, et après une proposition conjointe de cette SSII et d'une SSLL spécialisée dans l'intégration de solution de gestion en logiciel libre, Transrail B&V choisit de migrer son ERP de Baan IV vers la solution en logiciel libre OFBiz Neogia. Outre un budget de mise en ½uvre de l'ordre de - 30% par rapport aux autres offres, le choix de l'offre présentée a été également motivé par des coûts d'exploitation divisés par 3 et l'approche service permettant de bien intégrer les besoins de l'entreprise.
Le projet a été mené sur une période de 8 mois. Il a porté sur la mise en ½uvre des modules fonctionnels gestion commerciale, achats, stocks, GPAO et comptabilité. Compte tenu de l'expertise Baan de certains des collaborateurs de la SSLL, Transrail B&V a pu réaliser une reprise complète de ses données Baan vers l'ERP OFBiz Neogia.
Le projet a mobilisé une équipe de 3 consultants à temps partiel durant toute la durée du projet tant sur les parties fonctionnelles que techniques (administration et développements de fonctionnalités complémentaires).
La direction de Transrail B&V a été impliquée très tôt dans le projet. Cette implication s'est traduite par un suivi important de la part de la direction, ainsi qu'une implication forte dans les choix de mise en ½uvre qui ont été faits au cours du projet.
Afin de pallier au manque de compréhension de certains processus, tel que le MRP, les consultants ont réalisé des fiches pour chaque type de poste. Ces fiches de postes ont permis de réduire l'appréhension des utilisateurs quant au changement d'outil de gestion ainsi que d'améliorer leur vision des processus de l'entreprise.
Au final, malgré une appréhension première de la part de Transrail B&V vis-à-vis d'un produit jeune, la solution OFBiz Neogia apporte toute satisfaction comme élément central du système d'information de Transrail B&V. Les délais de livraison client sont en constante baisse depuis le démarrage en production de la solution grâce à l'amélioration de la productivité dans le déroulement des processus et de la communication entre l'administration des ventes et la production apportés par la solution mise en ½uvre. Des extensions sont prévues en 2007 dans les domaines du CRM et de la configuration produit. Ces extensions permettront d'augmenter encore la satisfaction des clients de Transrail B&V.
La solution ERP/CRM OFBiz Neogia sera présente lors du salon Solutions Linux sur le stand du réseau Libre-Entreprise, 1er réseau d'experts en logiciel libre.
Aller plus loin
- Neogia (104 clics)
- Définition d'un ERP sur wikipedia (30 clics)
- Réseau Libre-Entreprise (29 clics)
- Projet Neogia sur sourceforge (19 clics)
# Des détails sur la migration?
Posté par achil . Évalué à 10.
Juste par simple curiosité, je présume que durant toute la durée de ce projet de migration, vous avez été confronté à des problèmes que vous n'aviez pas prévu ou que l'on pourrait classer comme n'étant pas évidents.
Afin d'éviter que cela arrive à d'autres sociétés qui seraient intéressé à vous immiter, pourriez vous nous faire part de ces dit problèmes (peut être que tout c'est passé sans embuche, mais j'en doute un peu). Avez vous par exemple eu des problèmes de compatibilité durant la migration? Les données ont été portée sans problème? A combien estimmez vous le coût de cette migration?
[^] # Re: Des détails sur la migration?
Posté par malin nicolas . Évalué à 5.
Nous n'avons pas a proprement parlé eu de soucis sur l'import de donnée. Je dis a proprement parlé car la reprise de donnée, que nous soyons avec un logiciel libre ou un logiciel propriétaire, la problématique reste la même.
La plus grande difficulté due au basculement est la mise en production de fonctionnalités jeunes qui par manque de temps n'avaient pu être valider sur tous les possibilités auquel elles étaient soumises. Heureusement le fait de s'appuyer sur un produit libre nous à permis d'effectuer les modifications très rapidement sans bloquer la production.
Il est à noter que la majorité (pour ne pas dire la globalité) des améliorations qui ont été effectuées sur cette ERP lors de la mise en place au sein de l'entreprise ont été reversées au projet. Pour cela, les intégrateurs ont travaillé de consort avec les mainteneurs de la solution afin que les corrections apportés soit assez générique pour être incorporées dans le projet global et ne pas faire du specifique.
Nicolas
[^] # Re: Des détails sur la migration?
Posté par Jean-Pierre Heraton . Évalué à 2.
- réaliser le mapping correct entre les données sources et les données cibles. Cette étape fut source de travail car , malgré la très bonne connaissance du modèle de données Baan par les intégrateurs, certaines données étaient soient inexistantes dans la sources et devaient être crées, soit pas utilisables directement et devait faire l'objet d'une transformation ou d'une transcodification.
- l'utilisation inadéquate de Baan a engendré des erreurs et des incohérences dans les données sources. Si dans Baan, cela ne posait pas de soucis, dans Neogia ces incohérences ont dûes être corrigées.
Le coût de la migration fut d'environ 15 jours/homme.
Yannick
[^] # Re: Des détails sur la migration?
Posté par Sylvain Sauvage . Évalué à 2.
Tu veux sûrement dire 15 jours-hommes¹.
Ça n'est déjà pas parlant pour tout le monde, alors si on induit en erreur…
¹ : = 15 jours théoriques de travail pour un homme théorique ; c'est théorique dans le sens où ça ne donne pas le temps passé ni le nombre de personnes (ce qui prend 15 jours s'il n'y a qu'une personne ne prend pas un seul jour s'il y en a quinze), c'est un coût (et encore, il faudrait préciser la « nature » de l'homme (un technicien, un ingénieur, un consultant…)).
[^] # Re: Des détails sur la migration?
Posté par Jean-Pierre Heraton . Évalué à 2.
Les profils des professionels furent :
- consultant pour la réalisation du mapping
- ingénieur d'étude pour la réalisation des interfaces
[^] # Re: Des détails sur la migration?
Posté par pasBill pasGates . Évalué à -1.
Ok, je -->[]
[^] # Re: Des détails sur la migration?
Posté par Jean-Pierre Heraton . Évalué à 1.
:-D
# Doc
Posté par karteum59 . Évalué à 4.
-> http://cps.erp5.org/sections/erp/mourlon-neyer.pdf/downloadF(...)
[^] # Re: Doc
Posté par Pierre Jarillon (site web personnel) . Évalué à 7.
Personnellement, je suis très réservé quant aux ERP tels qu'ils existent aujourd'hui. Le fait de croire que mettre toute la vie d'une entreprise dans une seule base de données résoudra les problèmes est une parfaite utopie. C'est un dogme et toute l'énergie déployée sert à démonter que le dogme est juste.
Le mythe a débuté vers 1980 avec le CIM d'IBM : Il suffisait selon eux de mettre toutes les données de l'entreprise dans une base de données DB2 pour résoudre tous les problèmes. Cela a coûté très cher à beaucoup d'entreprises.
Ce que je préconise, c'est de définir les interfaces¹ entre les métiers. Cela permet de faire ensuite des systèmes interopérables et donne une autonomie à chacun d'eux tant qu'il respecte ses interfaces. Ainsi on obtient une grande souplesse d'évolution et d'adaptation. Le DSI (Directeur du Système d'Information) est alors le responsable de ces interfaces. Sa tâche est beaucoup plus simple. Chaque système est d'une dimension plus petite, plus facile à gérer et surtout, compréhensible par une personne qui connaît le métier où il s'applique. À l'ntérieur de chaque système, il est possible de reproduire le même raisonnement. C'est ainsi que j'avais défini une interface entre le système de gestion du contrôle qualité et les appareils de test ou les exportations vers des clients internes ou externes à l'entreprise. L'expérience m'a permis de vérifier la justesse de cette approche qui peut être conduite avec peu de personnes et permet de délèguer les responsabilités.
¹ Pour définir les interfaces, on peut s'aider de http://pjarillon.free.fr/redac/interface.html
[^] # Re: Doc
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Définition : http://en.wikipedia.org/wiki/Computer_Integrated_Manufacturi(...)
Un bref historique : http://www-users.cs.york.ac.uk/~kimble/research/cim.html
Le CIM 'est une vision très hiérarchisée et centralisée de l'entreprise. Je crois que notre époque s'oriente vers moins de jacobinisme. C'est peut être parce que je suis girondin ;-)
[^] # Re: Doc
Posté par Jean-Pierre Heraton . Évalué à 3.
Par contre, je pense que consolider dans un référentiel unique les données commerciales, de GPAO et comptable me semblent interressantes.
La principale problématique apporter par l'utilisation d'applications diverses est la nécessité d'avoir un référentiel commun à toutes ces applications afin que les interfaces puissent réaliser les transcodifications nécessaires.
De la bonne gestion de ce référentiel dépend la stabilité du système d'information.
Et au final un ERP c'est quoi ? un référentiel avec des transactions pour le gérer.
Yannick
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.