Liste de contrôle pour choisir un ERP

Un ERP est un modèle du fonctionnement de l'entreprise : comment une commande devient du chiffre d'affaires, comment un achat devient une dette fournisseur, comment le stock circule entre un entrepôt et une ligne de production. Avant d'inviter le moindre éditeur, formalisez ce modèle. Décrivez avec vos propres mots dix à quinze scénarios de bout en bout (du devis à l'encaissement, de l'achat au paiement, de la planification à la production, du recrutement au départ), y compris les exceptions propres à votre activité. Un distributeur avec du stock en consignation, un industriel avec des sous-produits ou une société de services facturant par jalons sont des cas typiques où un système générique échoue sans prévenir.

Conduisez les démonstrations à partir de ces scénarios plutôt que du script de l'éditeur. Demandez à chaque équipe de montrer le flux complet, y compris les points délicats : un avoir sur une facture partiellement réglée, un inventaire qui ne concorde pas avec le système, une clôture mensuelle avec une facture fournisseur tardive. La qualité des réponses en dit plus que la longueur de la liste de fonctionnalités.

L'adéquation concerne aussi le périmètre de la plateforme. Une plateforme qui couvre finance, ventes, stocks, production, RH et achats dans un seul modèle de données évite du travail d'intégration par la suite ; un ensemble d'outils spécialisés « best of breed » offre à chaque service ses écrans préférés. Aucune des deux approches n'est mauvaise, mais le choix doit être délibéré, car il détermine la part d'intégration que l'organisation devra prendre en charge.

Aucun ERP ne fonctionne seul. Il échange des données avec les banques, les boutiques en ligne, les systèmes de point de vente, un système d'entrepôt ou de production, un CRM, les services de l'administration fiscale et souvent l'outil de consolidation d'une maison mère. Établissez la cartographie des intégrations avant de faire votre choix. Pour chaque connexion, déterminez si elle fonctionne par lots ou en temps réel, quel système est maître des données, et ce qui se passe lorsque l'autre côté est indisponible.

Examinez ensuite comment chaque candidat expose ses données. Une API REST documentée avec une authentification que l'organisation peut maîtriser, des webhooks pour les événements, et des imports et exports en masse automatisables constituent le minimum. Si le seul accès aux données passe par un consultant de l'éditeur qui écrit une procédure stockée, chaque évolution future deviendra un bon de commande. Demandez à voir la documentation de l'API et quels autres clients s'y sont intégrés.

Enfin, décidez où résidera la logique d'intégration. Les connecteurs point à point sont rapides à construire et lents à maintenir ; une petite couche d'intégration détenue par l'organisation demande plus de travail au départ et coûte nettement moins cher dès la troisième année.

Traitez la migration comme un chantier distinct, avec son propre responsable. Commencez par un inventaire des données : quelles données de référence (clients, fournisseurs, articles, plan comptable, employés) et quelles opérations en cours (factures ouvertes, commandes d'achat en cours, soldes de stock, registres d'immobilisations) doivent être reprises, et jusqu'à quelle date l'historique doit être consultable dans le nouveau système plutôt que conservé en archive.

Nettoyez les données avant de les charger. Clients en double, articles avec trois unités de mesure sans facteur de conversion, fournisseurs dont l'identifiant fiscal a expiré : chacun devient un problème de rapprochement le week-end de la mise en production. Développez tôt les scripts de chargement et exécutez-les à plusieurs reprises sur une copie de la production, en rapprochant à chaque fois les totaux de contrôle (balance générale, balances âgées clients et fournisseurs, valorisation des stocks). Le chargement final doit se dérouler sans surprise, puisqu'il a déjà été réalisé plusieurs fois.

Convenez de la stratégie de bascule avec la finance. Un démarrage à blanc en début de période, avec des soldes d'ouverture, est plus simple que la migration de l'historique des opérations ; si l'historique est nécessaire, définissez précisément les rapports qui devront être reproduits avant la validation.

Les systèmes qui échouent la première année sont rarement ceux dont les fonctionnalités ne convenaient pas. Ce sont ceux dont les utilisateurs quotidiens ont été informés du changement au lieu d'y être associés. Intégrez à l'équipe de sélection des responsables de processus de la finance, des ventes et de l'exploitation, avec un réel pouvoir de décision. Confiez-leur la conduite des démonstrations par scénario et faites-leur valider les processus cibles aux côtés du DSI.

Planifiez la formation par rôle et par scénario, à l'approche de la mise en production, avec les données que les utilisateurs verront en production. Identifiez des utilisateurs référents dans chaque service avant le début de la formation et donnez-leur du temps dans l'environnement de test. Conservez l'ancien système en lecture seule pendant un certain temps après la bascule pour permettre la vérification des chiffres, puis arrêtez-le à une date annoncée à l'avance.

Enfin, évitez de reconstruire chaque rapport et chaque écran existant dans le nouveau système. Certains n'existaient que parce que l'ancien système ne savait pas faire ce que le nouveau fait nativement. Laissez un trimestre aux nouveaux processus avant de décider de ce qui manque réellement.