Comment personnaliser un ERP pour l’améliorer sans tout casser

Comment adapter un ERP à ses besoins sans faire de « spécifiques » ?

La première réponse à ce paradoxe est qu’il faut d’abord penser à adapter ses processus aux bonnes pratiques qu’embarque l’ERP.

La seconde est que les éditeurs offrent, de plus en plus, une grande flexibilité de paramétrages. Idéalement, cette flexibilité « intégrée » permet d’adapter suffisamment l’ERP pour éviter d’avoir recours à une vraie personnalisation avec des développements.

Cette personnalisation « intégrée » peut être très simple, comme déplacer des éléments d’une UI (menus, icônes, etc.) ou aussi poussée que des changements dans les calculs, les formats de base de données et le contenu.

En règle générale, ces modifications sont stockées dans une table de contrôle – qui n’est pas modifiée ou remplacée lorsque le logiciel est mis à jour (update) par l’éditeur. Ce qui signifie aussi que les modifications survivront à une mise à niveau (upgrade) et qu’elles n’ont pas besoin d’être refaites, retestées ou revalidées. L’entreprise n’est pas bloquée sur une version obsolète de l’ERP comme avec les « spécifiques ».

Voici un aperçu des types de modifications « natives » qu’il est possible de faire avec les principaux ERP. Mais n’oubliez pas que chaque éditeur a ses propres outils et ses propres approches, et que votre package peut inclure certaines de ces capacités (et pas toutes), ou d’autres non listées ici.

Personnalisation de l’interface utilisateur

La plupart des ERP permettent de modifier l’interface utilisateur en déplaçant des éléments, en changeant les libellés, en ajoutant ou en supprimant des modules ou des champs, etc.

Souvent, ces changements peuvent être effectués et enregistrés pour un utilisateur, pour un groupe d’utilisateurs – comme une division ou un service – ou pour tous les utilisateurs.

La possibilité de changer les libellés peut être rendue dynamique en fonction des langues : par exemple, les interfaces de l’utilisateur X d’une division à Madrid seront en espagnol, ceux de ses confrères à Paris ou à Genève seront en français.

De même, vous pouvez rendre des zones de données de certains écrans visibles uniquement à certains rôles (le CA global d’une région ne sera accessible qu’aux responsables de la région et à ses supérieurs).

Ce type de changement peut améliorer la sécurité en affinant les accès de chaque utilisateur. La suppression d’un élément d’UI (un champ) pour un utilisateur donné supprime en fait son accès à cette information, même si l’utilisateur pourrait avoir accès aux données par d’autres méthodes (via une requête SQL directement sur la base, par exemple).

Modification des fonctionnalités

La plupart des ERP permettent d’adapter leurs fonctions sans modifier le code. Via les paramétrages poussés, l’utilisateur peut activer ou désactiver telle ou telle fonctionnalité, modifier la façon dont les calculs sont effectués ou dont les données sont affichées. Il peut aussi définir la structure organisationnelle et les relations, parmi bien d’autres choses.

Cela dit, c’est à la fois une bonne et une mauvaise nouvelle. Côté positif, affiner les fonctionnalités répond au plus près aux besoins de l’organisation. Côté négatif, ce paramétrage poussé est une difficulté supplémentaire dans la phase d’installation et dans la mise en œuvre du système. C’est une loi immuable. Plus un outil est flexible et personnalisable, plus sa mise en œuvre s’avère compliquée.

Afin de surmonter une partie de cette complexité, les meilleurs ERP adaptent à l’avance leurs solutions à certaines industries – comme l’industrie manufacturière, pharmaceutique ou hôtelière pour en citer des très différentes. Ces packages préconfigurés sont passés dans le langage courant sous le terme de « verticaux ». On parle même aujourd’hui de « micro-verticaux ».

Bien que ces offres sur mesure éliminent une grande partie du besoin de personnalisation, la plupart des entreprises effectuent tout de même des ajustements supplémentaires.

Certains éditeurs ont également développé des logiciels pour aider à adapter l’ERP. Ces outils de configuration permettent généralement de mapper les processus métier, puis d’utiliser ces mappages pour automatiser les options de personnalisation afin que l’ERP fonctionne comme souhaité.

Modifications (encadrées) des bases de données

L’un des principaux problèmes que pose la modification des ERP est la modification de la base de données. Il faut généralement ajouter des champs et des tables pour prendre en charge des fonctions supplémentaires non incluses dans le progiciel.

Les champs ajoutés doivent être liés aux données existantes pour assurer la cohérence, l’exhaustivité et la validité. Or ils peuvent ne pas être entièrement coordonnés, sauvegardés et restaurés avec les données ERP.

Le « bricolage » de la base de données d’un système personnalisé est une tâche délicate et risquée, et les changements de versions de la base sous-jacente à l’ERP peuvent être particulièrement dangereux pour ces modifications.

Pour cette raison, de nombreux éditeurs d’ERP ont inclus une possibilité – existante, mais volontairement limitée – de modifier les champs et les formats existants et d’ajouter de nouvelles données aux tableaux, aux écrans et aux rapports.

Les éditeurs proposent divers outils pour le faire et, par conséquent, ces capacités varient grandement d’un fournisseur à l’autre.

Intégration, connecteurs et API

Bien qu’il ne s’agisse pas techniquement de personnalisation, sachez que de nombreux ERP sont conçus avec des possibilités d’intégrations – « portes » vers l’extérieur – qui permettent de communiquer avec des programmes externes de manière moins invasive.

Supposons que vous ayez une façon particulière de calculer l’autorisation de crédit et que votre système de saisie des commandes ne puisse pas être adapté pour faire le calcul comme vous le souhaitez. Grâce à une intégration, le programme de commande peut se connecter à votre programme de calcul. Ce programme tiers transmettra les données requises et recevra les données résultantes.

Une telle d’intégration est, de fait, une modification du programme, mais elle est plus facile à contrôler et à maintenir, car elle n’affecte que très peu le code interne.

Pour réaliser ces connexions entre des applications et un ERP, il existe plusieurs possibilités techniques : des connecteurs fournis par l’éditeur, des APIs ou un iPaaS.

Et si aucune de ces options n’est possible, il reste des formes d’automatisation comme la RPA.

Développements encadrés : PaaS et No-code/Low-code

Les éditeurs ne ferment pas pour autant la porte aux spécifiques. Mais ces spécifiques sont en train de changer pour se rapprocher d’extensions (add-ons et plug-ins).

Ils sont de plus en plus réalisables dans un contexte bien encadré, avec des outils comme des plateformes no-code/low-code complétées par des scripts, qui ne cassent pas la rétrocompatibilité du code de l’ERP.

Pour les ERP cloud (en mode SaaS), la logique est la même avec les développements sur le PaaS de l’éditeur.

« Avec la personnalisation “à l’ancienne”, vous modifiez le code source de l’ERP. Les développements futurs de l’éditeur dans l’ERP ne pouvaient plus parler à ce que vous aviez créé », expliquait au MagIT le président d’un grand éditeur d’ERP et de SIRH. « La différence aujourd’hui, c’est que même si [les éditeurs] ouvrent leurs plateformes pour que vous puissiez personnaliser votre environnement – avec des outils orientés objet ou du low-code – tout ce que nous sortirons demain fonctionnera toujours avec tout ce que vous avez fait hier ».

Conclusions

Toutes ces options – expliquées de manière rapide et superficielle – traduisent la volonté des éditeurs d’ERP de prendre en compte la nécessité de personnaliser leurs packages.

Elles montrent également qu’ils ont compris que leur intérêt était d’aider les clients à le faire, via des options natives de plus en plus nombreuses, et mieux encadrées.

Le but est que ces changements soient apportés de la manière la moins destructive possible pour l’ERP, et la plus durable pour les entreprises.

Article initialement publié en octobre 2018, mis à jour en juin 2022.