Migrace z WM na EWM: 6 lekcí, na které vás nikdo nepřipraví
SAP WM → EWM (Embedded) v komplexním výrobním prostředí
Kdy „jednoduchý“ upgrade přestane být jednoduchý
Říká se, že SAP Extended Warehouse Management (EWM) je nástupcem Warehouse Management (WM) a migrace je přirozený krok vpřed. A v zásadě je to pravda – EWM přináší bohatší funkci, lepší monitoring, sofistikovanější řízení skladových procesů a konečně pořádný přehled o tom, co se ve skladu děje, i bez nutnosti obvolávat vedoucí každé směny. Pak ale přijde reality check.
Projekt, o kterém píšu, byl implementace SAP S/4HANA s Embedded EWM pro velkého průmyslového výrobce – Tier 1 dodavatele v automobilovém průmyslu. Šlo o podnik s několika řízenými sklady pokrývajícími příjem, výrobu, expedici a meziskladování, přičemž každý sklad měl desítky až stovky typů skladů. Celkový počet typů skladu přesáhl několik stovek. Na tyto typy byly navázány komplexní strategie uskladnění a vyskladnění, z nichž řada existovala jen v hlavách zkušených uživatelů a v komentářích ABAP kódu, který nikdo za posledních deset let nečetl. Původní WM bylo v průběhu let silně modifikováno – mluvíme o desítkách zákaznických transakcí a řadě Z-tabulek pro konfiguraci procesů. Stručně: nešlo o greenfield. Šlo o brownfield s vrstvami barev, přičemž nikdo přesně nevěděl, co je pod tou třetí vrstvou. A přesto – projekt dopadl úspěšně.
Šest lekcí z migrace
Problém, realita a doporučení z každé z nich
Lekce 1: Organizační struktura – s chutí do toho, ale nepřehánějte
Původní idea: Ukliďme si cestou. Při plánování migrace přišel logický nápad: když už měníme systém, neudělejme jen technický přesun, ale zároveň narovnejme organizační strukturu. Sloučme typy skladů se stejným účelem napříč sklady (proč mít osm variant „regálového skladu“?), sjednoťme konvenci pojmenování, racionalizujme skladové zóny… Na papíře to vypadalo skvěle.
Realita. SAP poskytuje migrační nástroje pro přechod z WM na EWM. Tyto nástroje fungují na principu 1:1 mapování – Storage Type v WM = Storage Type v EWM. Chtít přemapovat organizační strukturu uprostřed migrace je jako chtít přestavět základy domu, zatímco v něm bydlíte a stěhujete nábytek. Ruční nastavení pro několik skladů a stovky typů skladů je časově extrémně náročné. A to ještě nepočítáme, že každá změna mapování se propaguje do migrace zásoby – a zásoby v komplexním výrobním prostředí jsou věc, se kterou se nežertuje.
Doporučení. Převeďte existující organizační strukturu 1:1. Je to bezpečné, předvídatelné a mapovací nástroje s tím umí pracovat. Co je ale naprosto v pořádku – a doporučuji – je přejmenování dle konvencí EWM, pokud zachováte logiku pojmenování z WM. Například Z01 → Z001 je kosmetická změna a zároveň váš systém bude v souladu s EWM konvencemi. Velká reorganizace? Tu nechte na jindy – třeba na druhé kolo, ke kterému rozhodně nedojde, protože na první si budete pamatovat ještě dlouho.
Lekce 2: HU Type – sjednoťte včas, jinak budete litovat
Problém, který vypadá jako detail. V EWM se typ manipulační jednotky (HU Type) odvozuje v mnoha případech přímo z obalového materiálu. Jeden obalový materiál = jeden typ manipulační jednotky. Tohle je standardní logika a na první pohled nic dramatického. Dramatické to začne být, když zjistíte, že stejný fyzický obal (řekněme plastová bedna 600×400) byl v různých řízených skladech evidován pod různými typy skladových jednotek. Proč? Protože každý sklad si v průběhu let dělal po svém, nikdo to centrálně nehlídal a WM to tolerovalo. V WM byl typ skladové jednotky volnějším pojmem – v EWM je to tvrdá podmínka.
V projektu, o kterém píšu, existovalo původně v WM několik stovek typů skladových jednotek. Část z nich byla duplicitní nebo se lišila jen konvencí pojmenování. Na tyto typy byly navázány strategie uskladnění, kapacitní parametry a RF procesy. Sjednocení si vyžádalo analýzu, přemapování a několik iterací testování.
Co z toho plyne. Toto byl jeden z největších „surprise“ úkolů projektu z hlediska zatížení na straně zákazníka. Podceňte ho a budete řešit nekonzistence ještě v hypercare, což je – jak se dozvíte v Lekci 6 – zábava, kterou si nikdo nepřeje.
Co dělat:
Inventarizace obalových materiálů a typů man. jednotek jako první krok analytické fáze, ne jako poslední
Vytvoření kontrolních nástrojů pro ověření konzistence napříč sklady
Jasná governance: kdo schvaluje změny typů manipulačních jednotek?
Jednoduše řečeno: nepodceňujte. Toto je tiché riziko každé WM→EWM migrace ve větším prostředí.
Lekce 3: Integrace do existujících procesů – EWM je jen část příběhu
Co je „mimo scope EWM“ – ale ne mimo scope projektu. EWM řídí sklad. To, co se děje mimo sklad – odvádění z výroby (MFBF backflush), pohyby v IM (Inventory Management) – to je technicky mimo scope EWM. „Mimo scope“ ale neznamená, že zákazník přestane tyto procesy potřebovat v okamžiku Go-Live.
V projektu bylo nutné pokrýt celou řadu procesů, které stávající WM řešení historicky obsluhoval „bokem“ – ať už pomocí user exitů, vlastních report programů nebo neformálních pracovních postupů.
Poučení. Začněte s analýzou těchto „mimo-EWM“ procesů co nejdříve po ukončení blueprintu. Čím déle čekáte, tím větší je riziko, že Go-Live datum dorazí dřív než dokončená implementace. Prakticky: zmapujte všechny stávající WM user exity, custom programy a neformální procesy jako součást analytické fáze. Každý z nich je potenciální funkční gap v EWM.
Lekce 4: EWM je podobné WM – ale není to WM
Největší omyl zkušených uživatelů. Paradoxně, největší riziko pro adopci EWM nepředstavují uživatelé, kteří SAP neznají. Jsou to uživatelé, kteří SAP znají velmi dobře – a mají desetileté zkušenosti s WM. Tito lidé přicházejí s pevně zakořeněnými návyky. Vědí, jak se pohybovat v LT0A, co je Skladový příkaz, jak funguje HUMO. A právě tato znalost se stává brzdou, protože EWM pracuje jinak.
Nejčastěji opakované sdělení na tomto projektu bylo: „ERP HU a EWM HU jsou dvě různé věci.“ Tuto informaci jsme komunikovali od první demo session přes školení až po hypercare support.
Co s tím:
Zdůrazňujte rozdíly od první chvíle – neříkejte „EWM funguje podobně jako WM.“ Říkejte konkrétně: „V EWM máte Skladovou úlohu místo Skladového příkazu. Přehledy typu LT0A nebo LX03 najdete ve Skladovém monitoru /SCWM/MON. HU v EWM jsou jiná entita než HU v HUMO.“
Ukažte benefity ihned – /SCWM/MON není jen náhrada jedné transakce, ale jedno místo, odkud uživatel vidí a řídí celý sklad. Nechte uživatele si ho „osahat“ brzy – nadšení je nejlepší motivátor pro změnu návyků
Komunikujte opakovaně – Jedna školicí session nestačí. Klíčové informace musí zaznít víckrát, v různých kontextech
Připravte cheat-sheety – mapování „WM transakce → EWM transakce“ vytištěné a pověšené vedle každé RF čtečky zachránilo nejednu směnu
Lekce 5: Migrace – těžce na cvičišti, lehce na bojišti (tentokrát to platí doslova)
Destruktivní povaha migrace. Migrace z WM na EWM je destruktivní operace ve specifickém smyslu: jakmile přeúčtujete zásobu přes mezisklad, cesta zpět je velmi komplikovaná. Není to jako Ctrl+Z. Je to spíš jako přesun nábytku z bytu do nového domu – pokud zjistíte, že stolek se nevejde do dveří, řešení existuje, ale bude bolet. Proto platí bez výjimky: každý scénář, který může nastat v produkci, musí být nejprve odtestován. A pak testován znovu. A pak ještě jednou.
Dávkujte migraci. Pokud migrujete tisíce skladových jednotek a manipulačních jednotek najednou, je silně doporučeno rozdělit migraci na menší dávky. Důvod je prostý: pokud import havaruje uprostřed zpracování, rozsah problému je přímo úměrný velikosti dávky.
Toto není teorie. Na projektu nastala situace, kdy sobotní večerní migrace havarovala – a to v důsledku okolnosti, kterou žádný migrační plán nemůže předvídat: účetní oddělení likvidovalo fakturu k nákupní objednávce – v sobotu pozdě večer, na systému, který měl být po dobu migrace uzamčen. Výsledek: blokovaný materiál způsobil selhání importu. Namísto plánovaných 60 minut se tým v 23:00 věnoval odrolování zásoby zpět, identifikaci problémového záznamu, jeho řešení a opakovanému importu. Celé to zabralo několik hodin.
Poučení: migrace je týmová disciplína – zahrnuje nejen IT a konzultanty, ale i finanční oddělení, nákup a logistiku, kteří musí mít jasně definované zákazy aktivity po dobu migračního okna. Tohle musí být formálně schváleno a komunikováno.
Praktická pravidla:
Testovací migrace (minimálně 2–3 cykly) v testovacím systému s produkčními daty
Dávkování – preferujte menší skupiny záznamů s kontrolními body
Rollback plán – musí existovat, musí být otestován a všichni musí vědět, kde je uložen
Freeze na systémy – písemně, s potvrzením od business stran
Lekce 6: Nic vás nepřipraví na Hypercare
Co je Hypercare. Hypercare je období bezprostředně po Go-Live, kdy je konzultantský tým k dispozici pro podporu uživatelů. V projektovém plánu to vypadá jako přiměřená časová rezerva na dořešení drobností. V praxi je to výzva k přežití.
Uživatelé, kteří celé měsíce absolvovali školení a říkali „ano, rozumíme,“ najednou zjišťují, že SAP v produkci je jiný než SAP na školení. Procesy, které v testovacím systému fungovaly bez problémů, se v produkci chovají jinak – protože produkční data jsou jiná, produkční objem je jiný a pracovní stres uživatelů je jiný. Tikety přicházejí ve vlnách. Některé jsou triviální, jiné jsou urgentní a vyžadují okamžitou analýzu. Rozlišit, co je chyba systému a co je chyba uživatele, je samo o sobě umění.
Co to znamená pro vás. Nic, co přečtete v tomto článku, vás na Hypercare plně nepřipraví. Musí se zažít. Co ale pomáhá:
Robustní monitoring – /SCWM/MON, custom alert monitor, qRFC monitoring – vše musí být nastaveno, funkční a monitorované
Jasná eskalační cesta – kdo co řeší, kam se hlásí kritické problémy
Dokumentace pro key usery – interní „quick reference“ karty pro nejčastější scénáře
Trpělivost – ta se nedá nastavit v SPRO
A na závěr, s plnou upřímností: Hypercare je fáze, kde se ukáže, za co projekt opravdu stál. Dobře připravený systém, dobře zaškolení uživatelé a dobře nastavené procesy tuto fázi přežijí. Zbytek… taky přežije, ale s jizvou. Hodně štěstí. Budete ji potřebovat.
Shrnutí: 6 lekcí v kostce
| # | Lekce | Klíčové sdělení |
|---|---|---|
| 1 | Organizační struktura | Migrujte 1:1, přejmenujte dle konvence, velké změny nechte na jindy |
| 2 | Sjednocení HU Types | Inventarizujte obalové materiály jako první, vytvořte kontrolní mechanismy |
| 3 | Integrace procesů | Analyzujte „mimo-EWM“ procesy včas, neodkládejte development |
| 4 | EWM ≠ WM | Zdůrazňujte rozdíly opakovaně, ukazujte benefity EWM od začátku |
| 5 | Migrace | Destruktivní, dávkujte, testujte, zmražte systém – formálně |
| 6 | Hypercare | Nedá se naučit, dá se přežít. Připravte monitoring a nervy |
Časté otázky k migraci z WM na EWM
Je migrace z WM na EWM jen technický upgrade?
Ne. Přestože je EWM nástupcem WM, nejde o prostý upgrade. EWM pracuje jinak (Skladová úloha místo Skladového příkazu, jiná logika HU, tvrdší pravidla pro typy manipulačních jednotek) a v komplexním brownfield prostředí je nutné počítat s analýzou procesů, sjednocením kmenových dat a rozsáhlým testováním.
Má se při migraci z WM na EWM narovnat organizační struktura?
Doporučujeme migrovat organizační strukturu 1:1. SAP migrační nástroje fungují na principu mapování Storage Type WM = Storage Type EWM a velké reorganizace uprostřed migrace jsou riskantní a časově náročné. Přejmenování podle konvencí EWM je v pořádku, pokud zachováte původní logiku pojmenování; velké změny nechte na samostatný projekt.
Proč je sjednocení typů manipulačních jednotek (HU Type) tak důležité?
V EWM se typ manipulační jednotky často odvozuje přímo z obalového materiálu a je to tvrdá podmínka, zatímco WM byl volnější. Pokud byl stejný fyzický obal v různých skladech veden pod různými typy, je nutné je sjednotit ještě před migrací. Inventarizaci obalových materiálů zařaďte jako první krok analýzy, ne jako poslední.
Jak se připravit na fázi hypercare po go-live?
Hypercare se nedá plně nasimulovat, ale pomáhá robustní monitoring (/SCWM/MON, qRFC, custom alerty), jasná eskalační cesta, quick-reference dokumentace pro key usery a cheat-sheety s mapováním WM → EWM transakcí. Klíčové je také migraci dávkovat, mít otestovaný rollback plán a písemně schválený freeze systémů po dobu migračního okna.
