Migrer de SAP WM vers EWM

WM classique organise le stock autour de types de stockage et d'emplacements de stockage dans une structure relativement plate, avec des types de mouvement qui pilotent les besoins de transfert. EWM remplace cela par une structure d'entrepôt construite sur des types de stockage, sections, zones d'activité et emplacements, mais le changement le plus significatif est procédural : EWM introduit les ordres de transport entrepôt et les ordres entrepôt comme unités d'exécution atomiques, sous les documents de niveau processus que vous connaissez déjà.

Le modèle de transaction RF évolue en conséquence. Les transactions RF de WM se mappent assez directement sur les mouvements de stock ; le cadre RF d'EWM est construit autour d'une couche de présentation paramétrable au-dessus du même moteur d'ordres entrepôt utilisé pour l'exécution pilotée par vagues et gérée par ressources. Séquences d'écran, codes fonction radiofréquence et gestion des exceptions doivent tous être repensés plutôt que recopiés tels quels.

La structure d'entrepôt elle-même devient plus expressive. Les hiérarchies imbriquées d'emplacements de stockage, le tri des emplacements pour l'optimisation des chemins de prélèvement et le stockage géré par unité de manutention sont natifs dans EWM, là où WM ne faisait qu'approcher ces besoins par des contournements. Ce gain d'expressivité est le principal bénéfice fonctionnel — et la principale raison pour laquelle une conversion technique pure sous-estime ce que la migration devrait viser.

EWM embarqué s'exécute dans le même système S/4HANA que le reste de la pile logistique et finance, ce qui simplifie la synchronisation des données de base et supprime une frontière système. Ce modèle convient aux organisations disposant d'une instance ERP unique par landscape d'entrepôt et de volumes transactionnels modérés.

EWM décentralisé s'exécute comme un système séparé, généralement pour isoler la charge d'exécution entrepôt à haute fréquence du système ERP, pour supporter un landscape en étoile avec plusieurs back-ends ERP alimentant un seul système d'entrepôt, ou pour permettre des cycles de release indépendants pour la couche entrepôt. Il introduit une communication asynchrone (qRFC/IDocs en file d'attente ou équivalent) entre l'ERP et EWM, qui devient une surface d'intégration à concevoir, surveiller et tester à part entière.

La décision est rarement purement technique. La stratégie de landscape, le nombre de systèmes existants, l'investissement d'automatisation prévu et l'appétence de l'organisation à exploiter un système d'entrepôt distinct entrent tous en jeu. Se tromper sur ce choix est coûteux à corriger une fois que les flottes RF, les interfaces d'automatisation et les procédures opérationnelles sont construites autour.

Une approche réaliste démarre par une évaluation de l'existant : quels types de stockage et types de mouvement sont réellement utilisés, quelles transactions RF et rapports spécifiques existent, quelles interfaces touchent le processus entrepôt, et où le paramétrage WM a été étiré pour couvrir des lacunes de fonctionnalité standard.

La phase de conception cible mappe les processus existants sur le modèle de processus d'EWM plutôt que de répliquer les structures WM emplacement par emplacement. C'est là que les stratégies de rangement et de prélèvement, les modèles de vagues et la gestion des ressources se conçoivent en fonction du layout et du profil de volume réels de l'entrepôt, et non de ce que WM supportait par hasard.

La construction et les tests doivent être pilotés par scénarios : les flux d'exception (prélèvements partiels, unités de manutention endommagées, stock bloqué, livraisons annulées) méritent autant de couverture de test que le chemin nominal, car c'est de là que proviennent la plupart des incidents de mise en production. La planification du cutover doit tenir compte des comptages de stock physique, de la disponibilité des terminaux RF et d'une fenêtre de gel réaliste pour l'exploitation de l'entrepôt.

Le code spécifique est le facteur de coût le plus sous-estimé. Les enrichissements WM construits via des user-exits et des BAdI se mappent rarement directement sur les points d'extension d'EWM, et une véritable analyse d'écart — pas une conversion mécanique du code — est nécessaire pour décider ce qu'il faut reconstruire, ce qu'il faut abandonner, et ce que le standard EWM couvre désormais nativement.

Les interfaces sont la deuxième source récurrente de retard. Chaque interface entrante et sortante qui touchait l'entrepôt WM — des systèmes transporteurs aux équipements d'automatisation en passant par les extractions de reporting — doit être repointée, et dans les landscapes décentralisés, certaines doivent être repensées autour de modèles de communication asynchrones.

La disponibilité des terminaux RF et du réseau est fréquemment traitée comme un sujet IT secondaire plutôt que comme une dépendance de cutover. Si les terminaux, les mises en page d'écran ou la couverture sans fil ne sont pas validés face aux nouvelles transactions RF avant la mise en production, c'est le terrain qui absorbe le risque dès le premier jour.