En bref : Savoir si un ERP fonctionne efficacement ne se juge pas en regardant le système lui-même, mais en vérifiant si le travail se fait dans le système ou à côté. Six signaux d’alerte sont typiques : la fuite vers les tableurs, la double saisie, la méfiance envers les rapports, des adaptations qui bloquent les mises à niveau, des modules inutilisés et des intégrations corrigées à la main. Un bilan de santé de l’ERP examine cinq domaines : l’adéquation aux processus, la qualité des données, les adaptations et la version, les intégrations, l’utilisation et les droits. La décision doit reposer sur des preuves tirées des journaux du système et des données de processus, non sur des opinions.
Ce qu’est un audit ERP, et ce qu’il n’est pas
Un audit ERP évalue dans quelle mesure un système installé porte aujourd’hui les processus réels de l’entreprise. Ce n’est pas l’audit légal des comptes, ni un simple contrôle de sécurité de l’information. Il cherche à répondre à trois questions : les processus se déroulent-ils dans le système, les données du système sont-elles assez fiables pour décider, et le système est-il viable dans son état actuel ?
Les référentiels de gouvernance informatique les plus utilisés recommandent d’évaluer régulièrement si les systèmes d’information servent les objectifs de l’entreprise. L’audit ERP applique ce principe général au système de gestion le plus critique de l’entreprise.
6 signaux d’alerte d’un ERP qui ne fonctionne pas efficacement
- La fuite vers les tableurs : la planification, le calcul des coûts ou le suivi des expéditions se font dans des tableurs tenus à côté du système ; celui-ci ne sert plus qu’à enregistrer.
- La double saisie : les mêmes données de commande, de client ou d’article sont saisies à la main à plusieurs endroits ; le transfert entre systèmes est devenu le travail de quelqu’un.
- La méfiance envers les rapports : les rapports de direction sont corrigés à la main chaque mois, la clôture mensuelle et les rapprochements prennent du temps, et différents services répondent à la même question avec des chiffres différents.
- Des mises à niveau évitées : les adaptations accumulées repoussent sans cesse le passage à une nouvelle version ; chaque mise à niveau ressemble à un nouveau projet.
- Des modules et licences inutilisés : une partie des modules achetés n’a jamais été déployée ou a été abandonnée ; une grande partie des utilisateurs n’ouvre le système que pour consulter.
- Des intégrations corrigées à la main : les flux de documents électroniques, les mouvements bancaires ou les liens avec d’autres systèmes demandent régulièrement des interventions manuelles.
Notre évaluation : ces signaux viennent le plus souvent non d’une faiblesse du logiciel, mais de processus qui ont changé depuis la mise en production sans jamais être reportés dans le système. La première question ne devrait donc pas être « faut-il changer de système ? », mais « à quel point le système actuel s’est-il éloigné de notre façon de travailler ? ».
Un bilan de santé de l’ERP : cinq domaines
Le tableau ci-dessous résume quel domaine un bilan de santé examine, et avec quelle preuve :
| Domaine | Preuve à examiner | Question à poser |
|---|---|---|
| Adéquation aux processus | Journaux de transactions du système, tableurs tenus à côté | Quelles étapes de processus se déroulent hors du système ? |
| Qualité des données | Échantillon de données de base, enregistrements en double ou incomplets | Les données articles, clients et nomenclatures sont-elles assez fiables pour décider ? |
| Adaptations et version | Liste des adaptations, historique des versions | Quelles adaptations restent nécessaires, et lesquelles bloquent une mise à niveau ? |
| Intégrations | Liste des interfaces, erreurs et corrections manuelles | Quels liens sont régulièrement corrigés à la main, et qui en est responsable ? |
| Utilisation et droits | Données d’utilisation par utilisateur et par module, définitions des rôles | Qui utilise quoi, et les droits correspondent-ils aux fonctions ? |
D’où viennent les preuves ?
Un audit vaut parce qu’il repose sur des preuves plutôt que sur des opinions. Quatre sources sont utilisées ensemble :
- Les journaux du système : les enregistrements de transactions de l’ERP montrent comment un processus se déroule réellement. Le process mining reconstitue à partir de ces journaux d’événements le flux réel du processus ; la norme XES de l’IEEE est le format commun des données d’événements.
- Les données d’utilisation : quels modules sont utilisés, par quels utilisateurs et à quelle fréquence.
- Un échantillon de données : la cohérence et les lacunes des données de base sont examinées sur un échantillon réduit mais représentatif.
- Des entretiens avec les responsables de processus : les exceptions et le travail hors du système que les journaux ne montrent pas. Les processus actuels sont décrits dans une notation commune comme BPMN 2.0.
Lorsque les enregistrements contiennent des données personnelles, l’examen respecte la loi applicable en matière de protection des données (en Turquie, la loi n° 6698) et n’utilise que les données nécessaires à sa finalité.
Après l’audit : trois décisions possibles
- Améliorer : le système est le bon, le paramétrage a vieilli. Les processus sont mis à jour, les adaptations inutiles supprimées, les utilisateurs formés à nouveau.
- Mettre à niveau et simplifier : une partie des adaptations peut être remplacée par des fonctions standard ; la mise à niveau est planifiée avec la simplification.
- Remplacer : le système ne convient plus à la taille ou aux processus de l’entreprise. Le choix d’un nouveau système part alors du périmètre que l’audit a rendu visible.
On ne peut pas savoir avant l’audit quelle décision est la bonne. Une erreur fréquente consiste à chercher un nouveau système dès qu’un problème se fait sentir, sans jamais mesurer pourquoi l’actuel ne suffit pas ; les mêmes problèmes passent alors dans le nouveau système.
Les erreurs à éviter
- Confier l’audit à la seule équipe informatique : la plupart des problèmes apparaissent dans le travail quotidien des responsables de processus.
- S’appuyer sur l’avis d’une seule personne ou d’un seul service : les signaux varient d’un service à l’autre.
- Ne pas traduire les constats en périmètre : une liste de constats non hiérarchisés ne se transforme pas en action.
Pour les critères à examiner lors du choix d’un ERP, voir notre article sur cinq fonctionnalités critiques pour choisir un ERP.
L’approche MindDX
MindDX résume cet ordre ainsi : « D’abord la radiographie, ensuite le diagnostic ». Pour un système Odoo, Zoho ou abas ERP installé, la voie d’Assess pour les systèmes en production est Audit : il évalue l’installation existante sans la modifier et produit le Périmètre d’amélioration validé, qui montre ce qu’il faut améliorer. Découvrez la MindDX Platform.
Sources
- ISACA — COBIT (référentiel de gouvernance de l’information et des technologies)
- IEEE Task Force on Process Mining — Process Mining Manifesto
- IEEE 1849 XES — eXtensible Event Stream
- Object Management Group — Business Process Model and Notation (BPMN) 2.0
- Administration fiscale turque (GIB) — portail des documents électroniques (en turc)
- Loi n° 6698 sur la protection des données personnelles — texte officiel (en turc)