Pourquoi analyser le processus opérationnel sur votre ERP?

Pourquoi j’ai analysé Pointforce (et pourquoi ce n’était pas “juste un SOP de plus”)

Mais une accumulation de petits irritants.
Des contournements.
Des “on fait ça comme ça ici”.
Des exceptions devenues la norme.

C’est exactement à ce moment-là que j’ai décidé de faire une analyse structurée du fonctionnement réel du logiciel et de son utilisation terrain.

Non, ce n'était pas mon rôle. Non, je n'était pas embauché pour ça. Non, on ne me l'a pas demandé. Je l'ai fais, parce que j'en ai vu la nécessité et que je trouvais que le processus en place ajoutait une lourdeur opérationnelle à toutes les équipes. 

C'est là, que j'ai développé le goût d'apprendre, d'analyser et de faire comprendre. 

Pourquoi j’ai fait cette analyse

Je n’ai pas analysé Pointforce par perfectionnisme.
Ni pour “standardiser pour standardiser”.

Je l’ai fait parce que je constatais trois choses très claires :

1. Le logiciel était sous-utilisé
2. Certaines fonctions étaient mal comprises ou mal alignées avec la réalité
3. Les utilisateurs développaient des habitudes pour compenser le système plutôt que de s’appuyer sur lui. 

Autrement dit, le problème n’était pas l’outil, ni l’humain.

C’était le décalage entre l’outil, les processus et les besoins réels.

L’erreur classique que je voulais éviter

Le réflexe habituel dans ce genre de situation, c’est :

- ajouter une procédure
- rappeler aux gens de “bien utiliser le système”
- former encore… sans corriger le fond

Je savais que ça ne fonctionnerait pas.

Parce que quand un logiciel est contourné, ce n’est presque jamais par mauvaise volonté.

C’est parce qu’il ne soutient pas efficacement le travail réel.

Mon approche d'analyse

Avant d’écrire la moindre ligne de SOP, j’ai commencé par observer.

J’ai analysé :

- comment les gens utilisaient réellement Pointforce
- à quelles étapes ils perdaient du temps
- où les erreurs se produisaient
- quels champs étaient ignorés ou remplis “pour passer à autre chose”
- quelles étapes existaient en théorie… mais pas en pratique
- et... quelles étapes existaient en pratique... mais pas en théorie! (ce qu'on appel communément.. le contournement de procédure, ou pour les plus rigides, de l'insubordination.)

Ensuite seulement, j’ai documenté.

Pas le logiciel tel que vendu.
Pas le processus idéal.

👉 Le processus tel qu’il devait être compris par de vrais gens, pour être réellement applicable par de vrais gens. 

Ceux qui n'ont pas de BAC+8 avec une maîtrise en génie informatique. Les gens comme toi et moi.

Pourquoi un SOP, mais pas n’importe lequel

Le SOP que j’ai produit n’avait pas pour objectif de :

❌ contrôler
❌rigidifier
❌surveiller

Son objectif était de :

✔️ clarifier
✔️ sécuriser
✔️ réduire l’ambiguïté
✔️ diminuer la charge mentale des utilisateurs

Chaque étape documentée répondait à une question simple :

Est-ce que ça aide réellement la personne à faire sa job plus facilement et plus proprement?
Si la réponse était non, l’étape devait être revue.

Ce que ça a concrètement apporté

L’impact n’a pas été spectaculaire du jour au lendemain.
Mais il a été profond et durable.

Voici ce qui a changé :

- Moins d’erreurs liées à l’interprétation du système
- Moins de dépendance à “la personne qui sait”
- Une meilleure cohérence dans l’entrée des données
- Une réduction des contournements
- Un gain de confiance envers l’outil

Pointforce est passé d’un logiciel “obligatoire” procédurale...à un outil soutenant et compris.

Ce que cette analyse m’a confirmé

Cette expérience a confirmé quelque chose que je vois encore aujourd’hui, dans presque toutes les organisations :

- Un logiciel n’échoue pas parce qu’il est mauvais.
- Il échoue parce qu’on ne prend pas le temps de comprendre comment il est vécu sur le terrain.

Et tant qu’on n’analyse pas cet écart-là, on traite les symptômes.

Jamais la cause.

Pourquoi cette démarche est encore pertinente aujourd’hui

Que ce soit Pointforce, un ERP, un CRM ou tout autre outil :

- la logique reste la même
- les erreurs se répètent
- les contournements réapparaissent

Ce n’est pas un problème de technologie.
C’est un problème de lecture du système.

Et c’est exactement là que l’analyse fonctionnelle prend tout son sens.

En résumé

- J’ai analysé Pointforce pour comprendre, pas pour juger
- J’ai créé un SOP pour soutenir, pas pour contraindre
- L’impact a été opérationnel, humain et durable
- Cette démarche m’a permis de passer de l’exécution à l’optimisation

Et surtout, elle a renforcé une conviction profonde :

On ne peut pas améliorer ce qu’on ne comprend pas vraiment, surtout quand on ne sait pas, qu'on ne ne comprend pas.