Diagnostic : le vrai problème n'était pas l'outil

Diagnostic : le vrai problème n'était pas l'outil

Comment un diagnostic a révélé qu'un ERP existant ne correspondait pas au métier du client, plutôt qu'un simple problème de bugs.

Secteur : privé - Service : Pilotage SI à temps partagé

Le client pensait avoir un problème d'ERP. Le diagnostic a montré qu'il avait aussi un problème de processus.

Le contexte

Le client disposait déjà d'un ERP et travaillait avec un prestataire éditeur chargé des évolutions. Les demandes tardaient à aboutir et des bugs récurrents compliquaient l'utilisation quotidienne de l'outil.

Le réflexe aurait pu être de multiplier les demandes de correction auprès de l'éditeur, ou de commencer immédiatement à chercher un nouvel ERP.

Il fallait d'abord comprendre ce qui posait réellement problème.

L'intervention

J'interviens auprès de ce client à la demande, en fonction des difficultés rencontrées.

Je ne développe pas pour lui et je n'ai pas vocation à remplacer son prestataire. Mon rôle est de faire le lien entre ses équipes métier, ses prestataires et les décisions que l'entreprise doit prendre.

Dans ce cas, cela a commencé par une question simple : est-ce réellement l'outil qui ne fonctionne pas, ou est-ce que l'entreprise n'a jamais formalisé la manière dont elle voulait l'utiliser ?

Aller au-delà des bugs

En analysant les difficultés rencontrées, un problème plus structurel est apparu.

Les processus de commande fournisseur, gestion des stocks, vente et comptabilisation n'avaient jamais été formalisés en interne. Chaque personne avait donc sa propre manière d'utiliser l'ERP.

Dans ces conditions, il était difficile de déterminer si une difficulté venait d'un défaut du logiciel, d'une mauvaise utilisation, ou simplement de l'absence d'un processus partagé.

Avant de changer d'outil, il fallait donc comprendre comment l'entreprise devait réellement fonctionner.

Formaliser avant de choisir

J'ai accompagné le client dans l'étude et la formalisation de ses processus, indépendamment du choix d'un éditeur.

L'objectif était de partir du fonctionnement réel de l'entreprise plutôt que d'un catalogue de fonctionnalités :

  • comment les commandes fournisseurs sont-elles traitées ?
  • comment les stocks sont-ils gérés ?
  • comment une vente est-elle enregistrée ?
  • comment les informations sont-elles transmises à la comptabilité ?
  • quelles étapes doivent être automatisées, et lesquelles doivent rester sous contrôle humain ?

Cette clarification permet ensuite de comparer les solutions sur la base des besoins réels de l'entreprise, plutôt que de choisir celle qui présente la liste de fonctionnalités la plus séduisante.

Étudier les solutions du marché

Une fois les besoins mieux définis, j'accompagne également le client dans l'étude des solutions et les échanges avec les prestataires.

Le travail consiste notamment à :

  • confronter les fonctionnalités annoncées aux besoins réels ;
  • identifier les écarts entre le fonctionnement attendu et celui proposé ;
  • questionner les choix et les réponses des prestataires ;
  • évaluer les propositions au-delà du simple discours commercial ;
  • aider le client à valider ou écarter une solution.

L'objectif n'est pas de choisir l'outil « techniquement le meilleur », mais celui qui correspond réellement au fonctionnement de l'entreprise.

Ne pas choisir un outil pour aujourd'hui uniquement

La réflexion intègre également les évolutions auxquelles l'entreprise va devoir faire face.

La facturation électronique, notamment, fait partie des sujets pris en compte dans l'étude du futur système.

Le choix d'un nouvel outil ne doit pas simplement résoudre les problèmes actuels pour recréer les mêmes difficultés dans quelques années.

Les aspects techniques

Cette mission n'est volontairement pas une mission de développement.

Mon rôle technique intervient plutôt dans l'évaluation des solutions et des propositions des prestataires : comprendre leurs réponses, identifier les contraintes ou incohérences éventuelles et permettre au client de prendre une décision éclairée.

La technique sert ici à challenger la solution, pas à décider à la place du métier.

Le résultat

Le client dispose désormais d'une meilleure compréhension de ses processus, de ses besoins et des limites de la solution actuelle.

Il est aujourd'hui en phase d'étude pour un nouvel outil, avec une vision plus claire de ce qu'il doit réellement couvrir et des enjeux à anticiper, notamment réglementaires.

Le changement d'outil n'est donc plus une réaction aux bugs de l'ERP actuel : il devient une décision fondée sur le fonctionnement réel de l'entreprise.

Ce que ce projet illustre

Lorsqu'un outil métier ne donne pas satisfaction, changer de logiciel peut sembler être la solution la plus évidente.

Mais si les processus ne sont pas définis, on risque simplement de reproduire les mêmes problèmes avec un nouvel outil.

C'est précisément là que mon rôle prend son sens : comprendre le fonctionnement réel de l'entreprise, formaliser ce qui doit l'être, puis permettre au client de challenger les solutions et les prestataires sur des bases concrètes.

Questions fréquentes

Le problème venait-il vraiment de l'outil ?

Pas uniquement. L'absence de processus formalisés contribuait également aux difficultés.

Pourquoi ne pas simplement demander à l'éditeur de corriger les bugs ?

Parce que corriger les symptômes ne résout pas nécessairement les problèmes structurels.

Est-ce que vous développez la nouvelle solution ?

Pas dans le cadre de cette mission. Mon rôle est ici d'accompagner le client dans la clarification de ses besoins, l'étude des solutions et les échanges avec les prestataires.

Pourquoi faire intervenir quelqu'un d'extérieur ?

Parce qu'il est difficile de challenger objectivement un prestataire lorsqu'il est lui-même la principale source d'information sur le fonctionnement de l'outil et sur les solutions possibles.

Vous avez un prestataire, mais vous n'êtes pas certain que le projet avance dans la bonne direction ?

Discutons de votre situation →
Cette réalisation correspond à un accompagnement SI à la demande. Le niveau d'intervention est adapté aux décisions et difficultés rencontrées par l'entreprise, sans remplacer les équipes ou prestataires déjà en place.