Les données de test dans les projets ERP

Ou : comment fournir des données pertinentes pour les tests pendant la préparation d’une migration de données.

Introduction

Très souvent, dans les projets multi-fonctionnels — comme une implémentation ERP — les différentes équipes évaluent leur solution indépendamment les unes des autres jusqu’aux phases tardives de test. Et fréquemment, le projet de migration de données fonctionne de la même manière : identification et validation des transformations de données menées en parallèle du reste du projet.

Le risque qui apparaît est que la nouvelle solution et les nouveaux processus soient testés avec des données « positives » — des données censées produire un résultat attendu — et non avec des données « négatives », qui ne sont pas censées produire un résultat négatif mais en provoquent un. Avec les solutions ERP intégrées d’aujourd’hui, différentes valeurs saisies dans un domaine fonctionnel peuvent en impacter un autre négativement, pour des raisons imprévues.

Pour réduire ce risque, et aussi pour accélérer la conception de la transformation des données, il est utile de travailler avec des données réelles et de les échantillonner intelligemment. Les données réelles sont extraites des bases opérationnelles, transformées pour le nouveau modèle de données si nécessaire, et injectées dans l’environnement de test. Examinons ce processus plus en détail.

Échantillonner des données réelles

Il y a 2 prérequis.

1. Vous devez bien sûr savoir quelles données, ou quel type de données, sont nécessaires. Faut-il des produits et des clients pour tester une solution de gestion des commandes ? Des nomenclatures ? Des matières premières, des documents techniques, des prévisions de demande, des historiques ?
2. Vous devez obtenir l’accord de toutes les parties prenantes. Une fois le périmètre compris, on peut commencer à choisir des morceaux de données — mais il est essentiel d’expliquer le processus d’échantillonnage et d’obtenir un alignement à ce sujet. Chaque groupe aura des exigences différentes, du très général au très détaillé, et demandera des données pour couvrir toutes ses exigences. D’expérience, moins les exigences sont détaillées, plus la quantité de données demandée est importante. J’appelle cela le syndrome du « au cas où (j’en aurais besoin de plus) ».

L’absence d’alignement est une voie royale vers les dérives de périmètre et les change requests.

Pour faire un bon échantillon, il faut aussi garder à l’esprit qu’il s’agit d’un exercice dynamique. La plupart des tests peuvent démarrer avec un échantillon basique. Mais il devra évoluer en étendue et en volume — on peut le faire grandir de quelques enregistrements à plusieurs centaines de milliers.

Construire un échantillon basique

Dans la plupart des cas, ce sont les gens du métier qui savent le mieux. Quel que soit le projet, ils connaissent les principaux cas d’usage et les données qu’ils utilisent pour les exécuter. Par exemple en industrie manufacturière : vos gens du métier savent quels sont les différents produits, ce qui les différencie, comment ils sont fabriqués ou vendus. Cela vous permet de proposer un échantillon basé sur les types ou catégories, les méthodes de production, les sites, les canaux commerciaux, les moyens de transport, les méthodes comptables, les méthodes d’entreposage, etc. En gestion d’actifs, cela pourrait être les classes d’actifs, leurs règles d’amortissement, les différentes natures de charges qu’elles génèrent.

Un échantillon basique de ce type suffira généralement pour les premières phases de test, où le besoin porte plus sur la variété des données que sur le volume. Mais à mesure que les tests progressent, il faut plus de données — pour répéter les scénarios de test avec un nombre croissant de petites variantes, et pour alimenter la formation. Pour l’instant, nous avons un échantillon basique et, en raison de sa petite taille, on peut le manipuler à la main — modifier les enregistrements un à un si besoin — et le transformer comme attendu pour la solution cible. Attention toutefois à ne pas piocher les données à la main : vous voulez définir un ensemble de règles pour sélectionner un échantillon, pas choisir des enregistrements directement dans une liste ou une base.

Pourquoi préparer l’échantillon initial avec les gens du métier ? Parce qu’en essayant de transformer les données, on confronte — tôt — la qualité des données et les règles de transformation à des données auxquelles les gens du métier peuvent se rattacher. Nous ne travaillons pas avec des données artificielles, fabriquées à partir d’hypothèses, mais avec des informations réelles, opérationnelles, actuelles. Cela aide à créer l’engagement, en travaillant avec leurs données et pas avec des données. Cela aide aussi à passer à l’action avant la fin complète du blueprinting. Toutes les équipes ne terminent pas leur blueprint au même moment, et cela ne veut pas dire qu’on doive rester inactif en attendant que tout le monde rattrape. Elles voudront commencer à tester, ne serait-ce que pour valider certaines hypothèses. Avec cette approche, nous avons les éléments de données clés et les cas métier couverts — nous pouvons nous lancer dans l’action sans rien perdre pour la migration principale.

Pour résumer, on permet :

• L’engagement des gens du métier
• Des données pour le prototypage et les premiers tests
• Des données cohérentes à l’échelle du périmètre du projet, et pas pour une seule équipe
• Un passage rapide à l’action

Et si on vous challenge, certains demandant beaucoup plus ou des données différentes ? D’expérience, une courte question fait des merveilles : pourquoi ? Pourquoi l’échantillon initial ne leur convient-il pas ? Pourquoi ont-ils besoin de plus, ou d’autre chose ? Très souvent, les données supplémentaires ne seront finalement pas utilisées — c’est juste « au cas où ». Avec cette information en main, vous pouvez factuellement repousser, ou accepter, selon le temps et les ressources.

Profiling et business intelligence

Idéalement, cet exercice doit avoir lieu tôt dans le projet — avant ou pendant la phase de blueprinting. Au minimum, juste après la création d’un échantillon initial.

Grossièrement, le profiling consiste à identifier des motifs dans les données. On l’utilise souvent dans une optique de qualité de données : cela aide à définir des règles de qualité, et on s’arrête facilement là. Mais le profiling peut faire bien plus. On peut utiliser la masse d’informations collectée pour comprendre comment le business est structuré. En examinant les données opérationnelles ou transactionnelles, on récolte :

• Des données maîtres, comme les clients, les matières, les actifs
• Des données transactionnelles, comme les commandes ou les bons de livraison
• Des données de référence, comme les types de commande, les codes site ou les conditions de paiement

Ces données aident à répondre à des questions du type : « quels types de commandes sont passés par quel type de clients, dans quels pays, et livrés depuis quel entrepôt ? »

Nous ne pouvons pas entrer dans plus de détails ici — les cas métier sont nombreux — mais la logique est simple. Avec toutes ces informations, on a une bonne prise sur les données et sur la logique métier qui les relie. On est prêt à discuter des nouveaux échantillons.

Ré-échantillonner

Nous pouvons à présent décliner les données en fonction des scénarios métier à tester. Et nous pouvons encore restreindre avec des filtres complémentaires, par exemple une période de temps — par exemple, sélectionner les données utilisées sur les 6 derniers mois d’opérations. Bien sûr, certains scénarios ne rentreront pas dans cette fenêtre. Mais ils seront facilement repérés en comparant le profiling avec les données sélectionnées, et les données correspondantes pourront être ajoutées à l’échantillon.

Reprenons nos commandes de vente : nous avons peut-être identifié les types de commandes utilisés par les différents clients, les produits qu’ils achètent typiquement, les conditions de livraison convenues. Pour aider à l’échantillonnage, on peut aussi faire des classements et sélectionner, par exemple, les 10 plus gros clients en volume de chiffre d’affaires ou en volume de transactions. On peut aussi identifier les produits qui font 80 % des ventes. En combinant les cas métier identifiés avec ces classements, on peut bâtir une base très solide.

Soutenir le projet plus loin encore

Avec ce nouvel ensemble d’informations, nous pouvons aussi assister le projet général avec une meilleure compréhension de certains scénarios métier. Nous avons un inventaire des transactions et des tendances, de sorte que nous puissions les classer — mais aussi de manière à repérer des exceptions significatives (par exemple, une commande annuelle qui pèse une bonne part du chiffre d’affaires) et des anomalies. Toutes ces données peuvent aider à améliorer le blueprint en y incluant des cas oubliés et en éliminant du bruit.

Conclusion

J’ai montré l’intérêt de construire des échantillons et de faire du profiling à des fins de business intelligence tôt dans le projet. Ce nouvel ensemble d’informations peut soutenir la migration des données et le projet général avec une grande efficacité, de plusieurs manières :

• Impliquer les gens du métier tôt et de manière constructive
• Élever la compréhension du business pour toutes les parties prenantes
• Fournir des données de test pertinentes avec des volumes maîtrisables

Parfois, cette approche est difficile à suivre. Certains clients rejetteront le profiling par peur de ce qu’il pourrait révéler, et certains contesteront les résultats. Il n’y a pas de solution unique. Dans ces cas, j’essaie d’éduquer mes parties prenantes avec quelques exemples, ou de garder les résultats au sein de l’équipe projet seule.