Sur mon mandat, j’ai croisé un ERP pour la première fois. Pas pour le programmer — je suis ben loin de ça — mais parce que l’application que je touche doit aller lire des données dedans. Pis disons que la rencontre m’a laissé songeur.

Un ERP, vu de loin, ça impressionne. C’est un gros moteur qui fait rouler les commandes, l’inventaire, la facturation, le tout dans une seule bête. Mais vu d’un peu plus proche, je commence à voir où ça coince.

Solide sur les rails, raide dans les virages

Ce qui m’a frappé, c’est la rigidité. Le processus standard est fort: une commande suit son chemin, statut par statut, sans accroc. Mais dès qu’une situation sort du cadre prévu, là ça devient compliqué. Le monde sur le plancher invente des contournements, pis ces contournements-là finissent par vivre à côté du système.

flowchart LR
    A[Commande créée] --> B[Confirmée]
    B --> C[Préparée]
    C --> D[Expédiée]
    D --> E[Facturée]
    B -.cas spécial.-> X[Contournement<br/>hors système]
    X -.-> D

Les belles flèches pleines, c’est le chemin officiel. La flèche pointillée, c’est la vraie vie. Pis c’est là, dans les pointillés, que se cache la complexité que personne montre dans la démo de vente.

Le reporting, l’autre surprise

Deuxième constat: sortir un rapport simple est rarement simple. Les données sont là, structurées au boutte, mais aller les chercher comme je veux demande de comprendre un modèle de tables énorme. C’est exactement pour ça que mon application doit exister: faire un pont entre l’ERP pis ce que le monde a vraiment besoin de voir.

Ce que j’en retire pour l’instant

Je suis pas un gars d’ERP, pis je le serai peut-être jamais. Mais cette première rencontre m’apprend quelque chose d’important sur les gros systèmes: leur force, c’est la discipline du processus; leur faiblesse, c’est tout ce qui sort du processus. Comme jeune dev, je trouve ça fascinant de voir où la réalité terrain pousse pis tire sur la machine. Ça m’en dit plus long sur une entreprise que n’importe quel organigramme.