Nasazení ERP a WMS: co se rozbije na straně plánování

Systém postavený na křivém procesu ho nenapraví, jen ho zalije do betonu

Nákup nového WMS nebo ERP proces neopraví. Pouze ukotví stávající stav – včetně front, provizorních řešení a schvalovacích koleček, jejichž smysl už nikdo nedokáže vysvětlit.

Jan Buba, Senior Consultant & Interim Stream Lead ve společnosti Logio, popsal výsledek v článku pro IT Systems letos v létě: „procesy jsou rychlejší a dražší, ale stejně neefektivní jako dřív, jen hůř opravitelné“. Jeho závěr z let záchranných projektů staví na správném pořadí kroků, ne na technologiích: „Teprve když narovnáme procesy a informační toky, má smysl bavit se o technologiích.“

Toto pořadí tvoří hlavní myšlenku celého textu. Vše popsané níže ukazuje, co „nejprve narovnat“ znamená v praxi pro firmu, která už podepsala smlouvu s dodavatelem a má v ní pevný termín.

Pokud se teprve rozhodujete, jaký systém pořídit, nejdříve si ujasněte, zda vás neomezují už stávající systémy. To představuje samostatný krok: posouzení stávajících informačních systémů ještě před jejich výměnou.

Co musí platit, než stanovíte datum go‑livu

Než začne datum cokoliv znamenat, musí platit tři věci: proces na papíře odpovídá reálnému provozu ve skladu, kmenová data za tímto procesem jsou čitelná a každé pole má svého konkrétního vlastníka.

První podmínka bývá nejméně nápadná. Každá firma má proces popsaný ve směrnicích a úplně jiný proces, který běžně funguje ve skladu – a oba se potkávají spíše výjimečně. Buba nazývá řešení datovým realismem: procesy zanechávají v používaných systémech digitální stopy, ze kterých lze poskládat věrný obraz reality. Tento obraz management často překvapí. Odhalí úzká hrdla tam, kde všichni věřili plynulému chodu, a schvalovací kolečka, která přežila tři reorganizace a po cestě ztratila svůj původní smysl.

Udělejte to ještě před zmrazením specifikace, ne až po něm. Specifikace napsaná podle papírového procesu vytvoří systém, který automatizuje fikci. Rozdíl se projeví hned v prvním týdnu ostrého provozu, kdy už na změnu architektury nezbývá čas. Stejná logika platí i pro vaše požadavky na dodavatele: specifikace systému a připravenost dodavatelů je přesně tím místem, kde papírový proces ustupuje realitě.

Kmenová data: práce, do které se nikomu nechce

Rozměry, hmotnosti, časy zpracování a reálné dodací lhůty dodavatelů rozhodují o tom, zda nový systém začne hned od prvního dne objednávat smysluplně. Zároveň představují část projektu, do které se nikdo dobrovolně nehlásí.

Řetězec selhání bývá krátký a drahý. Jedna paleta má v kmenovém záznamu špatnou výšku. Systém pro ni objedná nevhodné auto. Kamion dorazí, paleta se do něj nevejde, zablokuje rampu, řidič čeká a smluvní pokuta jde za vámi. Nic z toho přitom není chyba softwaru.

S automatizací se zásadně mění chybovost, kterou dokážete vstřebat. Dokud objednávky zadával člověk, většinu vlastních přehmatů podchytil ještě předtím, než způsobily škodu. Pokud nad nekvalitní data postavíte automatizovaný engine, chyby se skokově rozmnoží v objemu, který už nikdo nestíhá kontrolovat. Buba to říká jasně: „Algoritmus krmený nepořádkem vrátí zase nepořádek, jen rychleji a ve větším.“

Vyčištění dat znamená projít jeden po druhém všechny záznamy, na kterých procesy stojí: materiály, dodavatele, zákazníky, ceníky. Někde to obnáší fyzické přeměření stovek palet, jinde sjednocení jednotek, mazání duplicit nebo obvolávání dodavatelů s dotazem na reálné dodací lhůty. Žádná AI ani dodavatel systému to za vás neudělá.

Většina projektů však selhává v tom, co následuje potom. Kmenová data nejsou jednorázový projekt, ale trvalý režim. Každé pole vyžaduje svého vlastníka a jasné pravidlo, kdo a kdy ho aktualizuje. Bez toho se firma, která data před go‑live uklidí, dostane do dvou let do původního stavu – a druhý úklid ji stojí stejně jako ten první.

Přesnost skladové evidence je podmínka, ne příjemný bonus

Pokud se vaše evidence rozchází se skutečným stavem v regálech dnes, migrace tento rozdíl nevyřeší. Pouze přenese nesrovnalosti do nového prostředí, kde se stopují mnohem hůře. Už totiž nezjistíte, zda odchylka pochází ze starého systému, ze samotné migrace, nebo z prvních týdnů ostrého provozu.

Chápejte přesnost dat jako podmínku pro stanovení termínu, ne jako dílčí úkol v průběhu projektu. To vyžaduje kompletní inventuru dostatečně blízko cutoveru, aby čísla stále odpovídala realitě, zdokumentované rozhodnutí o způsobu zaúčtování rozdílů zjištěných v prvních týdnech a dohodu o tom, kdo má v novém systému právo opravovat stav zásob. Firmy, které poslední bod opomenou, končí s tím, že několik lidí potichu upravuje stejné zásoby opačným směrem.

Trvejte ještě na jednom detailu v časové posloupnosti: inventuru proveďte před zmrazením provozu, ne během něj. Inventura spuštěná ve zmrazeném okně vytěžuje stejné lidi, kteří mají v té době ručně zadávat objednávky, takže nakonec obě práce dopadnou špatně.

Zmrazené okno: kdo objednává během přepínání systému

Zmrazené okno představuje období, kdy starý systém už nerozhoduje a nový ještě ne. Během této doby však někdo objednávat musí – a to je rozhodnutí pro plánování, nikoli pro IT.

Než termín potvrdíte, zodpovězte čtyři otázky. Jak dlouhé bude toto okno reálně – se započtením dnů se sníženou průchodností po přepnutí, ne pouze technického výpadku. Kdo bude objednávky zadávat ručně a s jakými pravomocemi. Jak daleko dopředu sahá horizont předzásobení u položek s dlouhou dodací lhůtou. A kdo rozhoduje o výjimkách, pokud dodavatel zavolá s problémem, se kterým záložní (fallback) procedura nepočítala.

Dvě kategorie vyžadují zvláštní péči. Položky s dlouhou dodací lhůtou musíte předzásobit s dostatečnou rezervou nad rámec zmrazeného okna, protože výpadek v objednávce u nich v daném čtvrtletí už nedoženete. Promo akce naplánované do tohoto období raději posuňte, pokud to kalendář dovoluje. Promo akce představuje přesně tu situaci, kde má ruční objednávání nejmenší prostor pro chyby a nejvyšší cenu za selhání.

Proč se přesnost prognózy ihned po go‑live zhorší

Přesnost plánování po přepnutí klesá. Jde o očekávaný jev, nikoli o závadu. Pokud na to týmy neupozorníte předem, reagují zpravidla tím nejhorším možným způsobem.

Příčina bývá prostá. V momentě přepnutí se přeruší historie prodejů. Změní se struktura dat, někdy způsobem, který vypadá kosmeticky, ale není: jiná detailnost prodejních záznamů, změněná definice skladového místa, kódování položek a lokací, které stará a nová data nepropojí dokonale. Nástroj na prognózu, který tenhle šev v datech čte, vykazuje po jistou dobu horší výsledky – a čím automatizovanější doplňování zásob máte, tím více je to vidět.

Reakce, která situaci ještě zhorší, je přenastavování parametrů během prvních týdnů. Plánovači vidí špatné návrhy, upravují pojistné zásoby a service level, aby výkyvy vykompenzovali. Než se data usadí, systém si nese nános ručních úprav, které už nikdo nedokáže rozplést. Udržujte paralelní historii dostupnou, řekněte plánovačům předem, jak dlouho bude toto období trvat, a nesahejte na parametry, dokud se datový šev neuzavře.

Zde narážíme na naše dlouhodobé poznání: lepší predikce poptávky vaše výpadky zásob nevyřeší, exekuce ano. Cutover je totiž exekuční problém převlečený za problém s prognózou.

Dva kvalitní systémy, které o sobě nevědí

Spolehlivý WMS a spolehlivý TMS bez vzájemného propojení nepřinášejí dvojnásobnou hodnotu. Znamenají dvojnásobnou investici s pouze zlomkovou návratností – a mezeru mezi nimi zaplňují lidé ručním přepisováním dat.

Bubův příklad z dopravy ukazuje rozsah problému v plné nahotě. Před integrací dispečer přepisoval údaje o zásilce z vlastního systému do portálu každého dopravce. Každý portál přitom vyžadoval jiná pole a jinou logiku. Co nešlo naklikat, to se řešilo po telefonu a e‑mailu: poptávání kapacit, čekání na odpovědi, urgence a následné přepisování potvrzených cen zpět. Jediný překlep znamenal špatně objednanou nakládku a další kolo oprav. Běžný požadavek tak zabral i tři čtvrtě hodiny, z nichž většinu tvořilo čisté přepisování dat mezi okny.

Jakmile se dopravci napojili přes API, dispečer dělá dál stejnou práci: pořádá tendr, vybírá dopravce, vyjednává podmínky. Přepisování ale zmizelo. Poptávka odchází z jednoho rozhraní, nabídky cen se scházejí vedle sebe a stav zásilky se mezi systémy předává automaticky. Desítky minut na jeden požadavek se smrskly na jednotky a stejný tým dnes zvládne násobně více práce bez nutnosti přibírat další lidi.

Klíčovou otázkou při go‑live zůstává, které z těchto předávání dat plánujete nechat v ručním režimu – a zda někdo spočítal, kolik vás toto rozhodnutí denně stojí. Integrace, které ve druhém měsíci vyškrtnete z rozsahu projektu, se často vrací jako trvalá mzdová položka v rozpočtu. Správné nastavení rozsahu pokrývá podpora integrace a spuštění produktu.

„Shadow Excel“: jak go‑live v tichosti selže o šest týdnů později

Nebezpečné selhání nepřichází v den přepnutí. Projeví se až v šestém týdnu, kdy výkazy přestanou odpovídat jakékoliv realitě.

Probíhá to takhle. Dispečer, který svou práci dělal roky po svém a dobře, si slova „nový systém“ v duchu přeloží jako „chtějí mě nahradit“. Navenek kliká, kam mu přikáží. V šuplíku ale dál vede svou starou tabulku, protože jí jako jediné věří. Oficiální systém pak pracuje s neúplnými daty, zatímco skutečná pravda žije v soukromém souboru – a celá investice umírá bez toho, aby někdo nahlásil incident.

Bubův pohled na tuto věc stojí za zapamatování: „Odpor ke změně přitom není zlá vůle, je to normální lidská reakce – a dá se s ní pracovat.“ V praxi fungují tři věci. Zapojte lidi z provozu do návrhu řešení místo toho, abyste jim předložili hotovou věc – kdo si sám spolurozhodl o podobě obrazovky, ten si ji před kolegy obhájí. Nechte běžet stínový provoz (starý a nový systém vedle sebe) dostatečně dlouho, aby si uživatelé ověřili, že se na nový systém mohou spolehnout. A zajistěte, aby každý dispečer slyšel a věřil, že jeho práce nemizí, ale mění se: od přepisování čísel mezi okny k řízení výjimek.

Čtvrtý rozměr je rozpočtový. Change management patří do rozpočtu a harmonogramu od prvního dne, ne jako měkký doplněk, který se škrtne při překročení nákladů na hardware. Pokud vám tato položka v plánu chybí, nemáte plán pro go‑live, ale plán pro instalaci. Implementace a řízení změn představuje část, která bývá nejčastěji podfinancovaná a nejčastěji rozhoduje o celkovém výsledku.

S tím souvisí i jedno pravidlo návrhu: „Systém, do kterého nikdo nevidí, si důvěru v provozu nezíská.“ Pokud uživatel nezjistí, proč systém navrhl daný krok, zůstane u své tabulky – a bude mít pravdu.

Kdy spuštění go‑livu odložit

Existují tři situace, kdy je odložení levnější než spuštění.

Nemáte uklizená kmenová data u položek, které tvoří většinu vašeho obratu. Nejde o všechny položky, ale o ty, které se hýbou. Pokud u A položek pořád figurují odhadnuté hmotnosti nebo neověřené dodací lhůty, první týdny automatického objednávání vygenerují více práce, než zabral původní proces.

Zmrazené okno nemá konkrétního vlastníka. Pokud nikdo nedokáže říci, kdo, co a s jakou pravomocí během přepnutí objednává, nemáte plán cutoveru, ale jen stanovený termín.

Termín spadá do vaší sezónní špičky. Ostré spuštění šest týdnů před nejrušnějším obdobím roku znamená, že se náběhová křivka i provozní špička potkají u stejných lidí ve stejný čas.

Odložení není zdarma a protiargumenty mají svou váhu. Dva systémy v paralelním chodu stojí reálné peníze za licence, údržbu i pozornost lidí. Tříměsíční posun často znamená ztrátu lidí z implementačního týmu, kteří váš projekt znají, a smluvní milníky mohou nést sankce. Rozhodnutí je porovnáním dvou typů nákladů, ne otázkou principu. Upřímná diskuse o nich musí proběhnout ještě před vyhlášením termínu celé firmě, ne dva týdny před cutoverem.

Často kladené otázky

Jak dlouho před go‑live by mělo začít čištění kmenových dat?
Dostatečně včas, aby se výsledek dal otestovat na reálném procesu. Pro firmu s desítkami tisíc aktivních položek to znamená spíše měsíce než týdny. Užitečným testem není to, zda je úklid hotový, ale zda funguje pravidlo vlastnictví: pokud nikdo nedokáže jmenovat, kdo a kdy aktualizuje dodací lhůty dodavatelů, data se do go‑livu opět znehodnotí.

Kdo má objednávat během zmrazeného okna?
Lidé, kteří budou proces vlastnit i po spuštění, a to podle písemně dané záložní (fallback) procedury a s jednou pověřenou osobou určující výjimky. Svěřit zmrazené okno tomu, kdo má zrovna čas, vedlo u řady firem k tomu, že ve třetím týdnu zjistily, že nikdo neobjednal položky s dlouhou dodací lhůtou.

Jak dlouho zůstává přesnost prognózy po cutoveru zhoršená?
Dost dlouho na to, abyste s tím počítali v plánu, místo abyste reagovali až na vzniklou situaci. Délka závisí na tom, jak čistě se spárují staré a nové kódy položek a kolik historie prodejů se podaří přenést. Nesahejte na parametry plánování, dokud nemáte po cutoveru dostatek dat, abyste odlišili datový šev od reálné změny poptávky.

Měl by starý systém zůstat dostupný i po go‑live a jak dlouho?
Přístup v režimu pouze pro čtení se vyplatí udržet do první účetní uzávěrky, protože dotazy na odsouhlasení dat přicházejí později, než se čeká. Co by však dostupné zůstat nemělo, je možnost v něm provádět transakce. Dva živé systémy znamenají dvě verze pravdy – tedy problém typu „shadow Excel“, jen s IT rozpočtem v zádech.

Chcete podrobit váš plán go‑livu zátěžovému testu?

Pokud máte ve smlouvě pevné datum a nejste si jistí, zda je na něj připravená strana plánování, jde o otázku, kterou lze posoudit. Zaměřujeme se vždy na totéž: kmenová data u klíčových položek, přesnost skladové evidence, zmrazené okno, integrační místa, která plánujete ponechat v ručním režimu, a vlastnictví změny přímo v provozu.

Působíme jako nezávislý poradce, ne jako dodavatel systému – od výběru až po ostrý provoz, jako v tomto projektu výběru a implementace software. Byli jsme přizváni k projektům jak před go‑live, tak po něm – a ta druhá varianta je pro klienta vždy dražší.

Proberte s námi svou implementaci →