Dernière modification le 20 mars 2024 à 17:35.
Temps estimé pour la lecture de cet article : 7 min
Ah, la documentation! S’il y a un sujet de prédilection dans toutes les entreprises avec lesquelles j’ai collaboré en TI, c’est bien la documentation des systèmes. Certaines étaient un modèle de documentation pertinente, d’autres n’avaient aucune documentation alors que d’autres documentaient à outrance, au point d’en perdre tout bénéfice.
Mais qu’en est-il concrètement ? Quelle leçons faut-il en tirer ? Doit-on documenter uniquement la finalité (le système conçu) ou on doit-on également documenter le processus (les décisions prises en cours de projet) ? Quelles documentations apportent réellement des bénéfices à l’entreprise lors d’une implantation ERP et méritent l’investissement ?
Dans ce billet, je vous présenterai les documentations les plus bénéfiques, en fonction du contexte d’implantation.
L’implantation ERP : avant tout un processus de standardisation
D’abord, il faut se rappeler que l’implantation d’un ERP est avant tout un processus de standardisation. On implante une solution commerciale appropriée à nos activités, en configurant l’ERP pour qu’il supporte adéquatement nos processus d’affaires.
On désire avant tout doter l’entreprise d’un système ERP qui va être là pour le long terme, mais c’est un véritable défi.
En consultant la configuration du système, tout analyste arrivera à comprendre le comportement de l’ERP et pourra supporter adéquatement la solution.
Il est cependant largement reconnu que deux documentations finales apportent énormément de valeur pour les opérations d’affaires, de même que pour la conduite des projets et du support TI : les BPM et les BPP.
Le BPM: une documentation des processus d’affaires
On appelle BPM ou Business Process Model la représentation graphique d’un processus d’affaires donné. Par exemple, on pourrait définir un BPM pour chacun des processus suivants:
- La prise de commande de produits en inventaire pour un manufacturier d’armoires de cuisine.
- La prise de commande de produits sur mesure pour un manufacturier de comptoirs de cuisine.
- Le processus de réapprovisionnement des fournitures quand elles baissent sous un niveau d’inventaire donné.
Le BPM représente graphiquement les éléments suivants:
- Les intervenants (par exemple, l’agent du service à la clientèle, le client, l’analyste en planification de production, etc.).
- Les activités suivies (la prise de commande, la vérification du niveau d’inventaire, etc.).
- Les documents produits et échangés, qu’ils soient sur un support électronique ou papier (une commande, une facture, etc.).
- Les relations entre ces différents éléments.
C’est une bonne pratique de produire cette documentation durant les projets et d’utiliser le tout comme matériel de formation, de même que matériel de référence suite à la mise en production. Évidemment, il faudra mettre en place un processus rigoureux pour mettre à jour cette documentation par la suite.
Les BPP: la documentation détaillée des procédures
Les BPP (ou Business Process Procedure) documentent les activités à un niveau plus détaillé. Souvent, c’est un document texte qui décrit le step by step de chaque activité. Ce pourrait être par exemple un document qui précise les différentes étapes à suivre pour entrer une commande de produits en inventaire pour un client.
Le BPP est une documentation qui accompagne normalement le BPM. Plus détaillé, il s’adresse principalement aux gens qui sont impliqués dans les opérations. Mais c’est est un formidable document de référence pour les analystes TI.
Et la documentation des décisions prises durant le projet ?
Certaines entreprises vont jusqu’à documenter certaines grandes décisions prises durant les phases de blueprint mais également lors de la construction (réalisation). Habituellement, ce sont les architectes de solution et les analystes principaux qui vont identifier les décisions majeures à documenter.
Cette documentation n’est pas fréquente mais elle a l’avantage d’offrir une mémoire permanente sur les décisions prises. Ainsi, des analystes ou architectes de solution pourront répondre aux questions du type « Pourquoi ça a été fait comme ça? » des années après la mise en production de l’ERP.
La documentation de l’architecture des systèmes: Requise ?
Il peut être avantageux de documenter l’architecture des systèmes (les liens entre l’ERP et les systèmes périphériques ou même externes à l’entreprise), spécialement dans les cas où les connections sont nombreuses et de multiples technologies sont utilisées pour échanger l’information.
Il n’est pas nécessaire selon moi de documenter en détail chacun des liens, mais l’essentiel est de comprendre comment l’information circule entre les systèmes et quels canaux sont empruntés pour ce faire.
La documentation dans des contextes d’ERP fortement personnalisés
Là où le bât blesse c’est dans les contexte d’ERP fortement personnalisés. La personnalisation consiste à modifier/adapter le comportement de l’ERP en programmant des bouts de code via le langage souvent propriétaire de l’ERP.
Sans embarquer dans le débat de ce qui amène les organisations à personnaliser un ERP (c’est amplement discuté dans un autre billet concernant les implantations vanilles), on comprend deux choses:
- Tout développeur arrivera à comprendre assez facilement ce qu’un bout de code accomplit comme fonction.
- Ce qui est moins évident à comprendre c’est d’identifier les impacts de cette personnalisation sur les autres fonctions du système, donc ailleurs.
Bien que les environnements de développement permettent aisément d’identifier où est utilisé un objet donné (par exemple, une table X dans la base de données), c’est la chaîne de comportement qu’il est difficile de comprendre.
Je vous avoue aisément que je n’ai pas vu cette documentation très souvent. Cependant, il m’apparaît fortement valable de documenter les personnalisations comme suit:
- Décrire la nature de la personnalisation, l’objectif qu’elle atteint.
- Justifications de la personnalisation.
- Analyse d’impact: La modification effectuée a un impact dans quelles autres fonctions de l’ERP ? A-t-on eu à réaliser une personnalisation ailleurs ?
La documentation : une activité difficile à justifier sur le plan financier
La réalité est que sur le plan financier, la documentation est difficile à justifier auprès des lignes d’affaires. En effet, on doit quantifier les bénéfices. Elles accepteront plus facilement de payer pour les BPM/BPP car cette documentation leur est utile. Mais quant aux autres documentations, il faudra utiliser d’autres arguments que les bénéfices à long terme pour les convaincre!
Mon opinion est que c’est à la direction des TI (CIO ou Directeur TI) de mettre ses culottes et de définir ses propres standards pour la conduite de ses projets et des activités de support.
Conclusion
On débat de la documentation des systèmes depuis la naissance des T.I. dans les entreprises. Je vous l’avoue tout de suite : on le fera encore longtemps. Entre l’absence de documentation et la documentation excessive, il y a un juste milieu qui est approprié pour le département des TI, mais également pour les lignes d’affaires.
Je crois personnellement à la valeur de la documentation pour que l’entreprise ait une connaissance qui soit persistante. Je ne crois pas aux connaissances dans la tête de certaines personnes-clés, ce qui met inévitablement toute entreprise à risque.
Vous préparez un projet ERP et aimeriez en savoir plus ? Téléchargez notre eBook « Comment réussir votre projet ERP 🎯 ». Il vous sera d’une aide importante pour assurer la réussite de votre projet.
Lectures additionnelles
Si vous avez envie d’en lire plus au sujet de la documentation dans le contexte d’une implantation ERP, consultez les sites suivants:
- 4 pieces of essential ERP documentation you should understand, sur ERP Focus.
- ERP Documentation – Why it’s so important, par Clients First Business Solutions.
- 9 Ways Procedures and Documentation Improve ERP System Use, sur Multi Channel Merchant.
- ERP Documentation and Training, sur IT Toolbox.
