|
|
2 Travaux réalisés Dans le cadre de ce stage, je me suis vu confier un projet d’étude portant sur un progiciel intégré paramétrable (ERP) : Baan IV. Le sujet de mon stage était l’étude de la fonctionnalité du logiciel Baan au niveau de la planification des besoins, du suivi des approvisionnements et des services associés. Mon rôle était d’étudier ce logiciel au travers de ces différents services et d’analyser l’ensemble des procédures d’utilisation. Ce travail devant me permettre de discerner les faiblesses du logiciel et les utilisations inadaptées des différents utilisateurs, je devais être en mesure de proposer des solutions correctives mais aussi préventives afin d’optimiser l’efficacité et l’interactivité utilisateur-logiciel.
2.1 Présentation générale des ERP : L'ERP ? C'est le système majeur d'intégration informatique de l'entreprise. Autant dire son centre structurel. C’est un progiciel de gestion intégré, permettant d'automatiser les processus clés de l'entreprise, d'améliorer l'efficacité organisationnelle ainsi que d'éliminer les coûts et la complexité au paramétrage des applications.
2.1.1 Qu'est-ce qu'un ERP ?
L'ERP désigne le système de gestion intégrée de l'entreprise, reposant sur un "progiciel intégré" paramétrable. Le terme ERP (Enterprise Resources Planning) dérive de la méthode MRP (Manufacturing Resources Planning), célèbre méthode utilisée depuis longtemps en gestion industrielle, pour des domaines comme la gestion de production. L'éditeur allemand SAP est le leader incontesté du marché des outils ERP, avec son produit SAP R3, mais subit une concurrence importante de la part d'Oracle, de JD Edwards mais aussi de Baan. Certains éditeurs s'adressent davantage à des segments, comme MFG-Pro, Qad ou Marcam dans les entreprises moyennes du secteur industriel. Les outils ERP proposent un grand nombre de fonctions comme la comptabilité, la gestion financière, la gestion commerciale, les ressources humaines, la GPAO (gestion de production assistée par ordinateur), la gestion de magasin, les stocks, etc. Cette intégration signifie notamment que les données utiles sont stockées en un seul endroit : il existe par exemple une seule base client pour les fonctions commerciales et de facturation, garantissant l'absence d'incohérences et supprimant les saisies redondantes.
2.1.2 Pourquoi met-on en place aujourd'hui un ERP ?
On ne met plus en place des ERP par simple nécessité d'améliorer la performance informatique et de changer le système d'informations, ou même par simple effet de mode, comme cela a pu être le cas dans le début des années 90. L'installation répond désormais à des objectifs de valeur ajoutée. L'objectif peut être économique : chercher à réduire des coûts de maintenance ou à améliorer un processus. Il est souvent humain et touche alors des aspects variés, comme l'activité et la performance individuelle des personnels concernés. Enfin, les objectifs organisationnels concernent par exemple la réduction des délais de traitement ou d'acheminement des flux d'information dans l'entreprise. L'ERP représente un défi organisationnel qui doit être soigneusement préparé. Il faut définir au préalable le "Business Case" et l'impact du projet sur ces trois plans, humain, économique et organisationnel.. "L'ERP est avant tout à considérer dans sa dimension de levier, contribuant à certaines améliorations dans l'entreprise. La définition des objectifs est un moment important, où il s'agit d'allumer le phare qui pendant toute la durée du projet va servir de guide à tous les acteurs concernés "
2.1.3 Les ERP intègrent-ils toutes les fonctions de gestion de l'entreprise ?
Les outils ERP représentent un grand progrès, car ils unifient les bases de données de l'entreprise en un référentiel unique. Ils présentent souvent une pléthore de fonctions (d'où la lourdeur fréquente des opérations de paramétrage), mais les entreprises n'en utilisent en général qu'une partie. De plus, pour des raisons historiques ou d'expérience sur certains segments, tels ou tels modules d'un ERP peuvent être meilleurs que d'autres sur des fonctions spécifiques. Aujourd'hui, les outils ERP commencent à répondre aux besoins des secteurs verticaux ou à des fonctions particulières, qui jusqu'à présent relevaient d'éditeurs.
2.2 Présentation de BaaN IV : Pour garder un avantage concurrentiel dans le contexte actuel, il est nécessaire pour une entreprise de gérer toute la chaîne d'approvisionnement, des fournisseurs aux clients en passant par les traitements clés. Consciente de cet impératif, la société AFR a choisi d’investir un budget de 7 millions de Francs (1.07 million d’euros) pour l’acquisition du progiciel Baan IV.
2.2.1 BAAN IV : Solutions d'entreprise BAAN IV Enterprise Resource Planning (ERP) est une suite intégrée d'applications professionnelles proposée par Baan Company NV pour aider les entreprises à conserver leur avantage concurrentiel dans la gestion des traitements stratégiques à tous les niveaux de leur organisation. Baan Company a été fondée en 1978 aux Pays-Bas. Les solutions Baan sont utilisées par 15 000 entreprises à travers le monde. Baan emploie plus de 3000 employés. Le siège social se trouve à Barneveld aux Pays-Bas, elle est entièrement possédée par Invensys plc et représente 2,5 milliard de francs de chiffre d’affaire (381 millions d’euros). 2.2.2 Baan, leader en solutions ERP
Baan Company NV est un leader reconnu en matière de fourniture d'applications pour l'entreprise et inter-entreprises spécifiquement conçues pour satisfaire les besoins de clients opérant sur une large gamme d'activités industrielles, y compris des secteurs tels que la fabrication hybride, l'automobile, l'électronique, et la gestion de projets et de process. La
famille de produits BAAN IV répond aux besoins des petites, moyennes et
grandes entreprises. Elle est basée sur une architecture client/serveur
de type systèmes ouverts et peut évoluer sur de nombreuses
plates-formes de types ordinateurs de bureau et serveurs. Le puissant
concept Dynamic Enterprise Modeling (DEM) permet aux entreprises de lier
leurs process et leur structure organisationnelle aux nombreuses
fonctionnalités BAAN IV. Les solutions BAAN apportent une réponse complète aux préoccupations principales des utilisateurs aujourd'hui, tels le passage de l'an 2000 et l'application de la monnaie unique Européenne. 2.2.3 Un large éventail d'applications La famille de produits BAAN IV prend en charge tous les traitements de l'entreprise, et notamment : Fabrication: Finances: Projets: Distribution/transport: Entretien: 2.3 Présentation du logiciel et de sa situation au sein d’Arbel C’est donc en prenant en compte tous les avantages de Baan précédemment cités, que la société Arbel Fauvet Rail a opté pour cet ERP. Il s’agit d’un projet qui a été forcé par le passage en l’an 2000. En effet, la société possédait déjà un ERP : SAP, mais ce dernier ne passait pas la date fatidique du 30 novembre 1999. C’est donc dans un double but de modernisation et de passage, sans encombre, à l’an 2000 que la société a lancé le projet AFR2000 qui a débuté en mi-février 1999 pour s’achever 8 mois plus tard. Lorsque j’ai débuté ce stage, les utilisateurs étaient donc passés sur ce système depuis un an et demi. Ils avaient donc eu certes le temps de bien s’habituer au produit mais aussi de tomber dans des routines qui généraient souvent de nombreuses erreurs. Il fallait donc, pour finaliser ce projet, développer 3 axes de travail principaux : - Etudier le progiciel et inventorier les connaissances de chaque personne - Finaliser et remettre à jour la base de données Baan au niveau article, nomenclature et projet - Développer des outils ou des procédures évitant la réapparition de nouvelles erreurs. L’objectif final étant de repartir d’une base épurée et nettoyée pour faciliter, entre autres, le passage à l’Euro et de ne plus générer d’erreurs lors des différents stades d’utilisation. 2.4 Audits et créations de procédures N’ayant aucune connaissance de Baan, mon premier travail a été de découvrir ce logiciel afin de pouvoir dresser : - Des procédures d’utilisation qui permettront de formaliser le travail sous Baan mais aussi de déceler les différentes erreurs d’utilisation et de rédiger des documents Qualité - Des rapports d’audit dont le but sera de réaliser un cahier des charges de développement à partir des améliorations requises. Pour cela, j’ai passé près de 4 semaines aux cotés des utilisateurs du « monde » Bureau d’Etudes (BE) et de la Planification. J’ai pu ainsi réaliser des procédures récapitulant les écrans de saisies de Baan et surtout déceler les erreurs de manipulations et soulever les différents problèmes ou « gardes-fous » qu’ils seraient nécessaires de traiter. Il m’a ensuite était demandé de créer une présentation reprenant l’intégralité de la procédure de création et de gestion des nomenclatures du bureau d’études. Cette dernière devait me permettre d’animer un réunion afin d’égaliser les connaissances d’utilisation Baan du service BE. Cette réunion s’est déroulée sur un temps d’une heure avec la présence de l’intégralité du service bureau d’études, soit 12 personnes. Elle a formalisé les procédures d’utilisations et a permis de répondre aux nombreuses questions d’utilisateurs auxquels il n’avait pas été expliqué les conséquences et les résultats de leurs manipulations. Le cahier des charges est en fait le reflet des corrections à apporter suite à l’audit effectué sur le BE. Ce dernier a permis de mettre en avant différents types d’erreurs dues le plus souvent à la lourdeur du suivi de chaque article. Il était donc nécessaire d’apporter des mesures correctives de manière à ne plus avoir besoin de corriger la base de données. Pour cela deux solutions nous étaient offertes : - Création d’un spécifique, qui est un développement informatique au cœur du logiciel et réalisé par la société de services qui a implanté Baan (coût 2000-5000 F [305-762€]) - Création d’un état de contrôle, qui est un développement informatique réalisé en interne et qui se contente de prélever et/ou de lister des données pour contrôler leur exactitude et concordance. Pour des raisons de coût, c’est la deuxième solution qui a été choisie. J’ai donc mis en place un cahier des charges détaillant pour le développeur la structure souhaitée de l’état de contrôle BE avant génération des nomenclatures. Le but du document qualité était de retracer le processus de gestion des articles achetés ou sous-traités. De tels documents seront réalisés dans le futur pour chaque action sous Baan de manière à rendre plus polyvalents les utilisateurs et à éviter d’être bloqué par l’absence d’une personne qui détiendrait l’intégralité des connaissances sur une action. La rédaction du document qualité fut pour moi une occasion de découvrir les contraintes, les normes qui régissent de tels documents mais aussi l’utilité qui va en découler. La principale difficulté rencontrée dans cette phase fut l’imprégnation
et la compréhension d’un progiciel de l’envergure de Baan et ce
sans manuel d’utilisation ni support technique. Les seuls recours, mis
à ma disposition, étaient la base de tests et l’expérience
d’utilisateurs plus ou moins formés. Ces seuls moyens devaient me
permettre d’assimiler son fonctionnement. Il a donc fallu de la persévérance
et de nombreux essais avant d’arriver à un résultat concluant. La partie inventaire des connaissances m’a aussi permis de me mettre
en relation avec une grande partie du personnel et de me faire connaître. La partie rédaction de procédures ou de documents et la présentation orale m’a permis de synthétiser les connaissances acquises, de dégager les problèmes ou dysfonctionnements et de mettre en œuvre une pédagogie pour retransmettre de manière assimilable ce savoir. 2.5 Remise à jour de Baan Apparu en novembre 1999, les responsables ont paramétré au mieux Baan de manière à ce qu’il soit utilisable immédiatement. Mais au cours des mois, les stratégies d’utilisation et de gestion ont changé, en particulier la gestion en stock des articles. Lorsqu’un article spécifique à un projet se retrouvait de manière périodique dans d’autres projets, il fut décidé de les gérer en tant que standard sans aucun rattachement à un projet mais géré par un stock de sécurité. Or la formation du personnel ne s’est pas forcément adaptée à ces dernières mesures, ce qui a engendré de nombreuses erreurs de manipulation ou de non actualisation de nomenclatures passées. De plus, comme cela arrive souvent, le suivi des projets n’est pas mené jusqu’au bout informatiquement et on se limite à l’aspect commercial, ceci engendre des projets qui ne sont jamais clôturés par leurs responsables. Afin d’optimiser l’utilisation de Baan, il était donc nécessaire de commencer à contrer ces problèmes en remettant à jour la base de données. 2.5.1 Nettoyage des articles et nomenclatures tombés en standard Suite aux erreurs de manipulations et au manque de formation, l’affectation des références d’études en standards ou spécifiques se déroulaient sans maîtrise ni procédures clairement définies. Pendant 2 semaines, après avoir rédigé la procédure de suppression des standards incorrects, j’ai suivi l’intégralité des sous-ensembles basculés en standard de manière à corriger la base de données et avoir une répartition correcte entre articles standards et spécifiques. Cette correction permettant d’avoir une évaluation du coût des stocks fiable. 2.5.2 Analyse des nomenclatures eurotunnel Le projet de rames eurotunnel a débuté en 1999 avant l’apparition de Baan. Les nomenclatures des trois produits principaux que sont la bogie 9ème navette, le wagon porte-camion chargeur et porteur ont donc été enregistrées avec la stratégie d’utilisation de l’ERP de l’époque. La différence entre article standard et article spécifique n’apparaissait alors pas encore. Dans le but d’une optimisation du coût des stocks et des achats spécifiques, il était donc nécessaire de suivre la totalité des nomenclatures qui représentait plus de 10 000 articles. Ce travail consistait à analyser l’intégralité des nomenclatures afin d’isoler les articles standards existant sous Baan. Il fallait par la suite comparer ces résultats avec la base de données standards existantes. Une fois les articles à standardiser repérés, il faut reconstruire un à un les liens directs avec le stock banalisé. 2.5.3 Clôture des projets 1999/2000 Chez AFR, chaque commande de wagon est rentrée sous Baan sous la forme d’un projet. Les nomenclatures liées au produit commandé, les achats, les ordres de fabrication, les heures travaillées qui en découlent etc… seront tous liés à ce projet pour montrer leur appartenance à ce dernier. C’est donc le projet et son numéro qui seront la trame d’un bout à l’autre de la réalisation de la commande. Ces projets sont ouverts en début de commande, une fois cette dernière réalisée et livrée, le projet reste ouvert pendant encore une année pour pouvoir rentrer les possibles interventions en service après vente. Une fois ce délai passé, les projets doivent être clôturés pour pouvoir être archivés. Cette dernière opération n’est jamais réalisée par les chargés de projets car ils s’occupent d’autres projets en cours et ne prennent pas le temps de changer les statuts. Afin de pouvoir réaliser ces opérations de clôtures de projet, j’ai dans un premier temps rédiger une procédure. Cette dernière permet d’analyser tous les cas de clôtures rencontrés puis j’ai fermé un à un les projets datant de plus d’un an en parallèle avec la logistique et les chargés de projet de manière à couper les différents liens encore actifs qui auraient pu encore exister vis à vis du projet.
|
