Transition des processus de l'ERP au MDM

La gestion des données de base statiques ou des données de référence relatives à des objets importants pour l'entreprise, tels que les clients, les fournisseurs, les matériaux, les collaborateurs et les finances, fait partie des tâches essentielles de la gestion d'entreprise actuelle. L'exemple du client SAP KTM en Autriche montre comment une gestion efficace des données de base des articles améliore la qualité des données et la gouvernance des données.

KTM est un constructeur haut de gamme de motos hautes performances destinées à une utilisation tout-terrain et routière. L'entreprise développe et produit des motos sous les marques KTM, Husqvarna et Gasgas, dont plus de 280 000 véhicules ont été vendus dans le monde en 2019, ainsi que la super voiture de sport X-Bow. Avec un chiffre d'affaires de 1,5 milliard d'euros, KTM est devenu le plus grand constructeur européen de motos et le groupe emploie environ 4000 personnes dans le monde.

En 2016, KTM a introduit l'ERP de SAP. À cette occasion, une partie des données de base article existantes - vieilles de plus de 20 ans - ont été migrées, mais d'autres ont également été créées. Au début, la qualité était "assez décevante", comme le constate Patrick Berger, Head of Master Data Governance chez KTM. Le statut des articles et des matières qui devaient être utilisés dans la production était souvent incorrect. Certains champs étaient gérés - ou pas. De plus, les désignations des articles n'étaient pas traduites ou n'étaient pas dans la bonne langue. Au total, ces problèmes de qualité des données se répercutaient également sur les processus de production et de vente.

Comme une gestion décentralisée des données de base était souhaitée, il fallait une solution qui permette des flux de travail et une meilleure vérification des données saisies. Pour ce faire, une initiative sur les données de base a été lancée en 2017. Les processus ont été analysés en collaboration avec les services spécialisés : Qui entretient quelles données et pourquoi ? À quel moment ? Quelles sont les possibilités d'organiser proprement le flux de travail ?

Beaucoup de cuisiniers gâchent la bouillie

L'un des problèmes était le grand nombre de personnes qui pouvaient - du moins en théorie - gérer les données (sur les articles). Ce nombre devait être nettement réduit au minimum nécessaire. En outre, il fallait définir quel domaine était responsable de quelles étapes de la maintenance des données de base. Outre la réduction du nombre d'utilisateurs et des autorisations, ainsi que la gestion répartie des données de base article par les départements concernés, la gestion des données de masse était l'un des thèmes centraux - lendemain de l'introduction de SAP et de la migration qui y était liée.

"Nous sommes toujours tombés sur de très nombreux articles qui nécessitaient un processus dans SAP qui n'existait pas auparavant", explique Berger.

Un autre exemple serait les modes d'emploi pour les modèles de la nouvelle année. Pour cela, il faudrait créer quelques centaines, voire quelques milliers d'articles qui sont en principe tous identiques ou qui ne se distinguent que par des détails.

KTM souhaitait proposer une gestion Excel permettant aux collaborateurs de l'entrepôt de matériel de mettre à disposition toutes les informations via Excel. Après le téléchargement, un contrôle de qualité devait être effectué, tout comme si les données étaient gérées manuellement. De plus, des modèles devaient garantir qu'il n'y ait pas de nouvelle "prolifération" lors de la création des données de base du matériel.

Qui, quoi, quand et comment ?

Un point important était de déplacer la souveraineté des données vers le logiciel MDM, c'est-à-dire de bloquer les transactions dans SAP pour la création et la modification des fiches articles pour tous les utilisateurs "normaux". L'accent a été mis sur les modèles pour la création de matériel. Avant même l'introduction du nouveau logiciel, KTM avait déjà défini des modèles pour les articles créés dans SAP avec un certain numéro ; de plus, avec des données rudimentaires qui devaient être reprises, si possible, exactement de la même manière dans un nouvel article.

Une installation de matériel entièrement libre n'était pas prévue. Pour un nouveau matériau, il fallait utiliser le modèle existant d'un matériau déjà existant. Le matériau modèle a également été défini dans le nouveau logiciel. L'utilisateur reçoit des valeurs prédéfinies pour le matériau et n'a plus qu'à procéder à des adaptations à certains endroits.

Cela signifie deux choses : le confort et la qualité des données. Les modèles doivent d'une part décharger les utilisateurs d'un maximum de travail et, d'autre part, ne pas autoriser la gestion d'un maximum de champs de données qui peuvent de toute façon être remplis de manière standard, afin d'obtenir des améliorations de la qualité. L'approche par les modèles a permis de reproduire un nombre relativement important de processus. D'autre part, le contrôle est beaucoup plus précis.

Par exemple, il est possible de définir qu'un modèle ne peut être modifié que par l'unité centrale MDM - et pas par n'importe qui. La gestion des champs d'articles à trois chiffres - sur la base des articles de référence - a été simplifiée. Entre autres, la gestion des données provenant des différentes organisations de vente et des différentes divisions (lieux de stockage, types de stockage, numéros de stockage) peut être effectuée de manière plus centralisée.

Pour les règles de validation visant à garantir la qualité des données, il est possible de représenter les dépendances entre les champs obligatoires. Ainsi, pour les articles, on vérifie avant une étape du processus si une fiche infos-achats existe déjà ; l'étape suivante n'est possible que si cette fiche est disponible.

Concept d'autorisation MDM

Avec l'introduction du nouveau logiciel MDM, les autorisations ont été bloquées lorsque cela était nécessaire. Tous les articles sont créés via les processus définis ; tous les services (recherche et développement, planification, achats, finances) gèrent les données dans le nouveau logiciel. Environ 180 000 articles sont gérés dans le système, avec en moyenne dix à quinze enregistrements d'usine par article, 60 usines et 50 organisations de vente, ainsi que 200 classifications avec sept classes d'articles.

70 utilisateurs travaillent quotidiennement dans le système, environ 100 processus et 140 règles de validation sont utilisés. Un processus spécifique a été défini pour chaque modèle, y compris pour chaque région, c'est-à-dire pour l'Amérique, l'Europe, etc. Les utilisateurs choisissent le bon processus et disposent ainsi automatiquement du modèle adéquat. Chaque processus comprend en outre la possibilité de "passer" directement à des données supplémentaires, par exemple pour gérer les prix ou des données de planification spéciales.

Le logiciel permet de contrôler qui peut modifier les modèles (en ajoutant le processus concerné aux autorisations individuelles). Les modifications peuvent ensuite être contrôlées à nouveau dans la gestion des données de base. Il n'existe cependant pas chez KTM d'organe central chargé de valider les données. Certains types de processus (administratifs) permettent plus de liberté, plus de flexibilité dans la gestion des données de base.

Ils passent aussi encore par l'équipe MDM. En revanche, l'équipe MDM n'est pas impliquée dans les processus standard de création et de gestion du matériel. Il y a une validation "préalable", sinon KTM compte sur les utilisateurs pour disposer des informations correctes et les saisir en conséquence. Bien sûr, la nouvelle solution technique contribue aussi à améliorer la qualité des données, mais le simple fait de se pencher sur les processus et le système nous a permis de "trouver beaucoup de cadavres dans le placard", résume Berger.

Parmi les leçons apprises, il y a la compréhension commune des exigences des domaines spécialisés, de l'équipe MDM et du prestataire de services logiciels, ainsi que l'intégration précoce des domaines spécialisés compétents. Selon Berger, il n'est pas facile de trouver les domaines spécialisés qui apparaissent dans les processus pertinents. De plus, il existe régulièrement des "domaines secondaires" auxquels on ne pense pas du tout au premier abord. Cela vaut également pour les processus qui ne sont pas suivis quotidiennement et auxquels participe une personne qui n'est normalement pas impliquée.

La délimitation précoce entre le logiciel MDM et SAP ERP s'est avérée être un sujet important, c'est-à-dire quelles données (prix, etc.) doivent être gérées dans le logiciel de données de base et lesquelles dans SAP ERP. Il est important de garantir la souveraineté des données de la solution MDM. Pour cela, il faut définir au niveau des champs quel est le système principal.

"Enfin, il faut toujours garder à l'esprit les exigences non fonctionnelles, comme l'utilisabilité et la performance. Au début, on a tendance à les négliger", avertit Berger.

Dans le cadre d'une mise à jour du système au printemps 2019, les développements spécifiques aux clients ont été remplacés. En outre, au cours du premier semestre 2020, KTM a étendu l'utilisation de la solution de données de base article désormais établie à un autre domaine : les données de base client.