Que votre société soit une start-up récente, ou bien une entreprise classique installée depuis des années, fonctionnant avec un cabinet d’expertise comptable en charge d’établir les comptes pour le greffe et le fisc, pourquoi mettre en oeuvre un ERP dans une PME ? Pourquoi les tableurs bureautiques ne font-ils plus le job ?

Pourquoi un ERP dans une PME ?

Au début était le papier, puis les tableurs

Tout va bien, vous arrivez à générer du chiffre d’affaires, vous recrutez du monde, vous commencez à structurer la société de sorte à spécialiser les personnes par fonctions : marketing, ventes, production, logistique, administration, finance, GRH… Vous avez un suivi de chaque fonction avec des outils maison construit par la bonne volonté d’autodidactes, stagiaires ou responsables administratifs geeks.

Votre expert comptable reçoit des boites à chaussures remplies de pièces papier, ou pour les plus évolués, échangent avec vous des pièces nativement numériques ou numérisées, via des partages de répertoires dans le Cloud, Dropbox, Google Drive, Microsoft OneDrive ou autre.

Mais petit à petit, les limites de l’exercice se font sentir.

Comment assurer un flux de données d’un bout à l’autre de l’entreprise ?

Vous vendez une affaire. Un chiffre d’affaires prévisionnel atterrit dans un tableur. Assez vite, vous avez besoin d’ajouter des informations : quel client, quel produit ou service, quel échéancier de facturation, quelle(s) TVA(s), quel exercice fiscal, quel statut ?

Si vous voulez connaitre la marge de l’affaire, qu’elle concerne des produits ou des services ou les deux, il faut affecter des coûts associés, directs et indirects : matières premières ou sous-ensembles semi finis, heures ou jours x homme à un coût réel ou standard…

Si vous voulez connaître la performance de vos produits, équipes de vente, ou de production, il vous faut tracer des références de produits, d’équipes, d’entités de production, au travers de plusieurs étapes de la chaine de valeur.

Les tableurs rendent vite les armes à ce jeu là : ils sont très mal armés pour véhiculer l’information d’un bout à l’autre de l’entreprise, pour une simple raison : ils ont été conçus à une époque où l’ordinateur était PERSONNEL, l’internet n’existait pas, donc la transmission de données entre tableurs non pensée puis laborieusement ajoutée avec tous les problèmes posés : si le chemin de répertoire change, on perd le lien. Quand le pack office change, certaines fonctions ne marchent plus. La mise à jour des données externe est délicate, génère des plantages…

La promesse des ERP tient dans leur aspect intégré, mieux véhiculé par la traduction française de PGI : Progiciel de Gestion Intégré(e), le débat pour savoir si c’est le progiciel ou la gestion qui est intégré(e) n’est pas tranché. Cela signifie que le système a été pensé autour de données de référence, relativement stables et durables : produits, activités, clients, fournisseurs, employés, code comptables et analytiques, entités diverses. Et aussi de données transactionnelles, à durée de vie bien plus courte : factures, ventes, saisies de temps, devis, tickets de caisse, bons de livraison…

Comme le progiciel est intégré, on est assuré d’avoir la donnée à jour et la même pour tous les métiers qui y accèdent dans l’ERP : l’ADV a le client saisi par le commerce, la production aussi, la facturation, le contrôle de gestion, le comptable également. Moins de risques de doublons, des reportings plus fiables, des saisies multiples évitées.

D’autres besoins justifient aussi des ERP.

Générer des données fiables

Un tableur, c’est souple. Le DSI d’un grand constructeur automobile me disait qu’Excel était le premier SI de sa société. Certains ingénieurs faisaient même du calcul intégral avec.

Comme c’est souple, dans une colonne où on attend des euros, quelqu’un pourra saisir des roupies indiennes. Ou bien un commentaire littéraire. Ou bien encore écraser une formule avec une saisie en dur. À un moment vous détectez des incohérences, et mettez un temps forcément trop long à en trouver la cause et les corriger. Jusqu’à ce que d’autres refassent de mauvaises saisies. Et peut-être que vous ne verrez jamais rien, parce que des dollars et des euros, ce sont les mêmes ordres de grandeur.

Un ERP fait une promesse face à ce problème : les données sont soit générées automatiquement, soit dans des masques de saisie contrôlés, contraignant autant que faire se peut l’utilisateur moyen à saisir les « bonnes » données.

Ce n’est pas une panacée, car les ERP deviennent vite complexes. Un collègue, qui a passé 40 ans dans une ESN leader, me disait qu’il n’avait jamais trouvé plus de 50% de données fiables dans les ERP.

Les ERP ont encore d’autres apports.

Fournir des processus standards

Souvent construits autour de la comptabilité fiscale, puis légale, puis analytique, univers très normés, les ERP se sont déployés partout et ont naturellement débordé du monde du chiffre pour servir toutes les autres fonctions de l’entreprise beaucoup moins normées, voire très spécifiques.

Les plus grands des ERP ont donc verticalisé leurs solutions pour intégrer des métiers particulier : banque, assurance, manufacturing, automobile, pétrole, logistique, transport, service…

Dès lors se pose l’éternelle question : dois-je aligner mon fonctionnement sur les processus standards codés dans l’ERP, processus sélectionnés avec une rigueur toute darwinienne par des dizaines de clients passés (ou stalinienne par un architecte produit psycho-rigide), ou bien dois-je garder mes process à moi, parce qu’ils me donnent un avantage compétitif, ou parce que je ne veux pas me mettre à dos Madame Michu en lui demandant de changer ses habitudes.

Dans le premier cas, si la sélection a été réellement darwinienne et que les processus codés dans l’ERP sont normés par la loi ou non différentiants, vous avez intérêt à vous aligner sur l’ERP.

Dans le deuxième cas, si vos processus constituent ce qui vous fait sur performer par rapport à vos compétiteurs, ou si vous estimez impensable de demander à Madame Michu quelque effort que ce soit, il faut se poser la question de réaliser des développements spécifiques ou de l’assemblage de briques logicielles, et renoncer à l’ERP et sa rigide directivité.

Assurer une connectivité avec vos partenaires stratégiques

Il existe de nombreux exemples où clients et fournisseurs sont étroitement liés : constructeur automobile et équipementier. Grande distribution et fabricant ou négociant. Constructeur aéronautique et fournisseurs de pièces sensibles.

Des acteurs très interdépendants

Dans ces cas-là, c’est le niveau de stock en bord de chaine du Client qui déclenche l’expédition ou la fabrication chez le Fournisseur, qui se retrouve en asservissement complet. Le Client peut exiger que son fournisseur ait le même ERP pour simplifier la mise en place de cet asservissement, en assurant l’interopérabilité technologique et sémantique.

Asseoir la crédibilité de l’entreprise

Autre raison : si vous levez des fonds, vos financeurs vont vous demander des comptes. Trimestriels, voire mensuels, en trésorerie, en résultat, en bilan.

L’exigence monte d’un ordre de grandeur si vous entrez en bourse. Vous devez de nombreux reporting aux analystes, aux actionnaires. Vous devez inspirer confiance, et un ERP, même plein de données douteuses, sera toujours plus crédibilisant qu’un empilement instable de tableurs aussi fiables soient-ils. Car les ERP donnent l’apparence d’infalsifiabilité des chiffres, que ne donnent pas des tableurs.

Lors d’une grosse levée de fonds, ou en franchissant un seul de taille, 50, 250, 1000 personnes, il devient impensable de gérer une société comme dans les années 1970’s ou 1990’s, avec du papier, du fax, du téléphone et quelques tableurs.

Vous appuyer sur un partenaire industriel durable

Il existe une raison plus globale : une entreprise, même de technologie numérique, fera moins bien pour elle-même ce que des acteurs focalisés, qui font le travail pour des milliers de clients.

Si c’est évident pour des systèmes de paie, dont plus personne ne peut gérer la complexité avec un tableur personnel, ça l’est peut-être moins pour des systèmes métiers moins normés. Mais il faut éviter de croire que nous sommes seuls à avoir raison : il est rare qu’un besoin n’ait pas déjà été rencontré par un autre acteur, et qu’un éditeur ne l’ait pris en charge pour proposer une solution.

Il est donc aujourd’hui très rare qu’il faille faire des développements ad hoc, en se dotant d’architectes, de développeurs, de chefs de projet, d’exploitants… Le marché a muri, pléthore de solutions sont disponibles, notamment en SaaS via internet : Odoo, Freshbooks, purs players SaaS, de même que les historiques qui passent de leur solution on premise à du SaaS comme Sage, CEGID, Microsoft Navision, même si parfois il faut garder un client lourd en remote desktop pour certaines fonctions ou pour la performance.

Il peut être envisageable d’assembler des produits « best of breed » grâce aux API et à l’internet. Cela nécessite tout de même une maitrise technique minimale là où les solutions du marché ne sont pas encore au niveau de M. et Mme Michu.

Monsieur Michu

Il est infiniment plus sûr de se reposer sur un industriel centré sur les besoins d’un secteur ou d’une fonction, professionnel de la gestion d’un produit, rompu au management d’ingénieurs informaticiens, qui fait ça pour des centaines voire des milliers de clients depuis des dizaines d’années, que de penser le faire soi-même avec autant d’efficacité et d’efficience.

Votre éditeur devient donc votre partenaire stratégique qui gère l’informatique pour vous, et vous permet de concentrer vos efforts sur votre métier à vous.