Données de base des pièces de rechange avant S/4HANA : laisser, fusionner ou compléter

L’équipe données de base extrait les pièces de rechange d’ECC et trie l’extraction par texte court. Trois lignes décrivent le même codeur rotatif. L’une a été créée dans l’usine dont le convoyeur l’utilise aujourd’hui. Une autre a été créée dans une usine sœur qui en a acheté un de réserve sous son propre numéro. La troisième appartient à une usine fermée depuis des années, dont les fiches sont toujours dans le référentiel. Les trois passent dans S/4HANA, sauf si quelqu’un en décide autrement.

S/4HANA : la première lecture complète des pièces de rechange depuis des années

La décision de passer de SAP ECC à S/4HANA est prise et financée, et le référentiel articles fait partie du périmètre. Les pièces de rechange sont le coin de ce référentiel que personne ne lit de bout en bout au quotidien. La maintenance cherche la pièce dont elle a besoin, les achats commandent ce qu’ils trouvent, et une fiche que personne ne cherche n’est plus jamais vue. La migration change cela. Chaque fiche de l’extraction doit être mappée, chargée et vérifiée : pour une fois, quelqu’un les regarde toutes.

Ce que l’on y trouve est prévisible. Il y a des articles inactifs que personne n’a touchés depuis des années. Il y a la même pièce sous plusieurs numéros, créée dans différentes usines par des personnes qui l’ont chacune bien décrite, avec leurs propres mots. Et il y a des textes courts qui disent « ENCODER » et rien d’autre, que aucun technicien ne trouvera par une recherche. Un cas mesuré va dans le même sens. Un mémoire de master de l’Université de Lund, en 2024, a étudié les pièces de rechange d’un OEM à travers ses données ERP, et ses auteurs ont conclu que le système avait besoin d’un nettoyage.

Migrer ces fiches telles quelles transporte leurs coûts dans le nouveau système : la pièce achetée deux fois parce que la première se trouvait sous un autre numéro, la réparation qui attend une pièce que personne ne trouve, les heures passées à rapprocher des fiches à la main. Ces coûts sont résumés dans notre article sur les données articles de mauvaise qualité. La migration est le moment où le budget permet à une équipe de s’en occuper. Ce n’est pas la dernière fois qu’ils apparaissent, et la dernière partie y revient.

Données de base avant S/4HANA : trois décisions par groupe de fiches

Un outil de migration déplace des fiches. Il ne décide pas quelles fiches doivent exister, et cette décision revient aux personnes qui connaissent les pièces, avant le chargement. Elle est plus facile à prendre par groupe de fiches que ligne par ligne. Triez l’extraction des pièces de rechange en trois groupes :

• Laisser derrière. Les fiches sans mouvement, sans stock et sans équipement installé qui les utilise. Elles ne sont pas chargées, une fois que la maintenance a signé qu’aucune machine n’a encore besoin de la pièce.
• Fusionner. Les fiches qui décrivent la même pièce sous différents numéros. Une fiche est conservée et reprend le stock et les données usine des autres ; les autres sont bloquées, pour que personne ne commande dessus.
• Compléter. Les fiches dont dépendent la prochaine recherche et la prochaine commande, mais auxquelles il manque le fabricant, la référence fabricant ou les attributs qui distinguent une variante d’une autre. Elles migrent une fois ces champs remplis.

Le codeur rotatif montre comment les trois s’appliquent. L’article 300871, dans l’usine fermée, indique « ENCODER », ne porte aucune référence et n’a pas bougé depuis la fermeture de l’usine. Il reste derrière, une fois que la maintenance a confirmé que le codeur n’est installé nulle part ailleurs. L’article 140552, dans l’usine sœur, indique « DREHGEBER 1024 IMP 10MM », porte la référence fabricant écrite avec des tirets et compte deux pièces en stock. C’est le même codeur que la fiche de l’usine des convoyeurs : il est donc fusionné dans cette fiche, et ses deux codeurs deviennent un stock visible par les deux usines. Trouver des paires comme celle-ci est ce qui prend le plus d’heures. L’article 100917, dans l’usine des convoyeurs, est conservé lors de la fusion et migre une fois complété : le fabricant, la référence fabricant sous une seule forme, la résolution, le diamètre de l’arbre et le signal de sortie. Les numéros d’article et les textes sont ceux de l’exemple.

L’ordre compte. Laisser d’abord les fiches mortes derrière réduit la fusion, car un doublon dans une usine fermée n’est plus à fusionner. Fusionner avant de compléter permet à l’équipe de remplir les champs une seule fois, sur la fiche conservée, au lieu de trois. Chaque groupe demande aussi une signature différente. La maintenance signe ce qui reste derrière, le magasin et les achats signent ce qui est fusionné, et l’équipe données de base est responsable de ce qui est complété.

Le tri doit tenir dans le calendrier de la migration

L’extraction d’une usine peut se trier à la main. Celle d’un groupe, avec des dizaines de milliers de fiches de pièces de rechange réparties entre usines et langues, ne le peut pas, et la migration suit des dates que l’équipe données de base ne fixe pas. Trier par mouvement et par stock trouve l’essentiel du premier groupe en un après-midi. Les deuxième et troisième groupes demandent que quelqu’un lise des textes courts, compare des références écrites de trois façons et décide quels attributs chaque type de pièce requiert. C’est dans cette lecture qu’un tri manuel manque de temps.

Partium Cockpit est l’endroit où l’équipe fait ce travail. La classification range chaque pièce de votre catalogue dans sa classe le jour même où vous le chargez. Chaque fonctionnalité de Cockpit part de cette cartographie. Pour l’extraction, le codeur arrive dans sa classe le jour de son chargement, et la classe indique quels attributs porte une fiche complète. Le dédoublonnage repère la même pièce enregistrée sous différentes références, et empêche une nouvelle fiche d’en ajouter une de plus. Le DREHGEBER de l’usine sœur et le codeur de l’usine des convoyeurs arrivent comme un seul groupe, et la fusion reste la décision de l’équipe. Dans l’Enrichissement ciblé des attributs, le tableau complet des résultats accepte les corrections directement et en masse : l’IA propose, votre équipe corrige. La proposition et la décision restent séparées : chaque champ rempli sur la fiche du codeur est un champ que l’équipe a accepté.

Le référentiel change après la mise en production, les contrôles continuent

Le jour où S/4HANA entre en production, le référentiel des pièces de rechange est aussi propre qu’il le sera jamais. Le lendemain matin, un acheteur d’une usine sœur crée une fiche pour une pièce qu’il n’a pas trouvée, et une nouvelle machine arrive avec sa liste de pièces de rechange. Un nettoyage fait une fois, pour la migration, commence à vieillir la même semaine. Les équipes qui ont déjà nettoyé leur référentiel une fois connaissent le schéma : l’argent est dépensé d’un coup, et la dégradation recommence.

Les contrôles qui ont trié l’extraction sont ceux dont le nouveau référentiel a besoin chaque jour : une classe pour chaque nouvelle pièce, une vérification des doublons avant l’enregistrement d’une nouvelle fiche, et les champs dont dépend une recherche remplis avant que la pièce ne soit commandée. Votre ERP reste le système de référence. Partium Agent y lit les données et y réécrit ce que votre équipe décide. Ainsi, le codeur reste une seule fiche après la mise en production, et la prochaine migration ne part pas de la même extraction.

Commencez cette semaine avec une usine. Extrayez ses pièces de rechange et triez l’extraction en trois groupes : sans mouvement et sans stock, la même référence fabricant sous deux numéros d’article ou plus, et les pièces utilisées auxquelles il manque le fabricant ou la référence. Comptez chaque groupe, et soumettez la première liste à la maintenance pour signature. Ces trois chiffres donnent la taille de la décision que votre migration s’apprête à prendre. Pour faire le même tri sur cette extraction, réservez une démo et voyez-le sur notre catalogue de démonstration, ou sur un échantillon de vos données.