Ce qui devrait vivre dans votre ERP, ce qui gagne à vivre à côté, et une grille pour le décider fonction par fonction.
Votre ERP enregistre les commandes, suit l'inventaire, centralise les coûts et alimente la facturation. Puis, avec les années, on lui a demandé plus. Une boutique en ligne. Un portail client. Un outil de suivi pour les équipes sur le plancher. Un processus qualité propre à votre façon de travailler. Chaque ajout répondait à un vrai besoin. Pris un à un, chacun était logique.
Les symptômes arrivent plus tard, et ils sont faciles à ignorer. Des données sont exportées dans Excel pour être retravaillées. La même information est saisie à deux endroits. Des employés tiennent leurs propres fichiers pour suivre une étape que le système gère mal. Certains rapports sont encore reconstruits à la main.
Le symptôme qui mérite le plus votre attention est celui-ci : vous repoussez les mises à jour de votre ERP parce qu'il y a trop de personnalisations à reprendre et à tester. Une mise à jour qui devrait vous apporter des fonctionnalités et des correctifs devient un projet en soi, puis une source d'inquiétude. Est-ce que nos développements vont encore fonctionner? Qu'est-ce qu'il faudra adapter? Quel processus risque d'être touché?
À ce stade, le problème n'est pas votre ERP. Il fait très bien ce pour quoi il a été conçu. Le problème, c'est qu'on lui a confié des responsabilités qui dépassent son rôle. Un fournisseur d'ERP dira volontiers que, puisque l'ERP est le système central, tout devrait y être développé. C'est confondre deux choses : l'importance d'un processus pour l'entreprise, et l'endroit où ce processus devrait vivre. La production peut être le cœur d'une entreprise sans devoir être développée dans son ERP.
Ce guide propose une façon de trancher qui ne dépend pas de qui vous la présente : un principe, une porte d'entrée, six critères, une règle, puis une deuxième décision pour ce qui sort de l'ERP. Appliquez-la fonction par fonction. Une même entreprise aura des fonctions des deux côtés, et c'est normal.
L'ERP est votre système de référence. Il modélise des clients, des articles, des commandes, des factures, des mouvements de stock et des écritures comptables, et il fait ça mieux que n'importe quoi d'autre : cohérence des données, audit, sécurité, rapports financiers, un seul fournisseur. Tout ce qui touche l'argent, l'inventaire ou un document comptable y reste enregistré, et personne de sérieux ne le recode.
Ce qui se construit autour est votre système d'opération : l'outil dans lequel vos gens travaillent toute la journée, avec vos règles, et qui envoie à l'ERP ce qui doit être facturé et comptabilisé. Prenez un retour de marchandise. Le client se connecte à un portail conçu pour lui, retrouve sa commande et fait sa demande dans une interface beaucoup plus simple que celle de l'ERP. Le portail recueille l'information et la transmet au bon système. L'autorisation de retour (la RMA) et la note de crédit, elles, sont créées dans l'ERP. L'ERP reste la source de vérité pour la transaction; le portail gère l'expérience et le flux qui y mènent. Et si votre ERP offre déjà un portail client qui fait exactement ça, prenez-le : la grille plus bas vous le dira.
Il faut aussi être précis sur ce que « dans l'ERP » veut dire, parce que votre intégrateur le sera. Il y a trois niveaux. La configuration : champs, flux d'approbation, rapports, règles de validation, écrans adaptés; c'est prévu, c'est inclus dans la licence, ça survit aux mises à jour. L'extension prévue par l'éditeur : du code, mais isolé du cœur par les mécanismes officiels, et qui survit lui aussi aux mises à jour. Et la modification du cœur, ou son contournement : on écrit dans le produit, on détourne ses objets, on y bâtit une logique qu'il n'était pas fait pour porter. C'est ce troisième niveau que les éditeurs eux-mêmes combattent désormais. SAP en a fait une doctrine, le « clean core » : « Prioritize extensions only for business-differentiating processes », avec des extensions « decoupled from the core by leveraging released APIs ». Et SAP décrit ainsi ses extensions « side-by-side », celles qui vivent sur une plateforme séparée : « Side-by-side extensibility ensures lifecycle stability of the extensions through future release upgrades because any customization you develop fundamentally lives in a different platform and simply communicates with the target application through integration(s) ». Microsoft a remplacé la modification du code de base de Business Central par des extensions isolées.
Autrement dit, la question n'est pas « ERP ou pas ERP ». C'est : par configuration, par extension prévue, ou à côté. Et à côté, il y a deux options, le logiciel spécialisé et le sur-mesure, qu'on départage à la deuxième décision.
Avant les critères, une question qui tranche à elle seule. Si la fonction crée ou modifie une transaction, c'est-à-dire de l'argent, de l'inventaire, un document comptable ou légal (facture, bon de commande, note de crédit, mouvement de stock, paie), elle vit dans l'ERP. Une application à côté peut la déclencher par API, comme le portail de retours fait créer la RMA; elle ne la remplace jamais et elle n'en tient jamais une copie qui ferait foi. Si vous répondez oui ici, le reste de la grille ne s'applique pas.
Pour tout le reste, six critères. Chacun vient avec la raison d'architecture qui le justifie, parce qu'un critère sans raison est une opinion.
Plutôt dans l'ERP. Le besoin se décrit avec ce que l'ERP a déjà (clients, articles, commandes, factures, mouvements de stock, ordres de fabrication), et au plus quelques champs ou une table de plus.
Plutôt à côté. Les objets du métier n'existent pas dans l'ERP, et il en faudrait beaucoup : un train, un wagon, une lettre de transport, un lot de cuisson, un chantier, une règle de tarification par corridor, un dossier d'inspection propre à une certification.
Pourquoi ça compte. Forcer un train ou un lot dans un ERP qui ne connaît que des articles, c'est détourner des entités génériques, perdre l'intégrité des données et les rapports, et perdre du même coup l'avantage de l'ERP qu'on voulait garder. Un champ ou une table de plus, c'est une extension. Trente objets et leurs écrans, c'est une application; la bâtir dans le cadre d'extension de l'ERP, c'est bâtir une application entière au rythme des versions de l'ERP, avec ses licences et son interface, et la migrer à chaque version majeure.