Obecně lze účastníky, kteří se na projektu implementace podílí, rozdělit do tří nebo čtyř skupin:

• management zákazníka,
• uživatelé,
• dodavatel,
• případně IT oddělení zákazníka.

V případech, kdy není projekt příliš velký, bývá poslední jmenovaná skupina vypuštěna. Roli projektového týmu na straně zákazníka pak přebírá management (pokud to tak nebylo od začátku).
Cíle výše uvedených skupin jsou všeobecně známé. Na straně managementu jde o snahu minimalizace nákladů, zvýšení spolehlivosti a přesnosti dodávek. U dodavatele o úspěšnou implementaci s pozitivní referencí. Uživatelé systému si přejí od nového systému zjednodušení a ulehčení práce. Pokud jde o IT oddělení zákazníka, tak tam může být cílem inovace nedostačujícího současného WMS systému, nebo vůbec prvotní zavedení takového systému, případně standardizace a „vyčištění“ procesů.
K rozdílnému chápání a následným neshodám, ať už v menší či větší míře, bude po implementaci docházet vždy. Snahou všech zúčastněných skupin samozřejmě musí být, aby tyto neshody byly minimalizovány a nezpůsobovaly problémy při následné post-implementační fázi. V průběhu následujícího textu se budu snažit několik takových neshod, ke kterým může dojít, popsat.

Důvody neshod

Rozdílné chápání systému

Management v novém WMS systému vidí nástroj pro dosažení svých cílů, tedy naprosto legitimní cíl, vzhledem k tomu, že management má roli tzv. decision makera. V některých případech, ale kombinace dílčích cílů může způsobovat, že jejich realizace, ať už vzhledem k novému systému, nebo vzhledem k pracovnímu procesu uživatelů, nemusí být možná. V závislosti na komplexnosti problematiky jako další faktor vstupuje nemožnost úplné znalosti dodávaného řešení.
Naopak dodavatel musí být svou znalostí systému schopen aplikovat funkčnosti a specifika řešení na požadované cíle managementu a v případech, kdy nějakých cílů nebude možné dosáhnout (z jakýchkoliv důvodů), navrhnout jiné řešení, které bude vyhovovat. Výhodou je, pokud na straně dodavatele není jen IT specialista, ale i člověk, který zná problémy z oboru. Nejlépe pak, pokud přímo IT specialista dříve v oboru pracoval. Dostatečnou analýzou, která bohužel mnohdy na úkor nízké ceny projektu bývá snižována, je dobré na tyto problematické body narazit již před samotnou implementací. Při analýze je nutné, aby dodavatel trval na popsání skutečného průběhu provozu, neboť kvůli poskytnutí neúplných nebo chybných informací nemůže dodavatel nastavit systém správně. Zbytečně potom dochází k časovým průtahům a nedorozuměním. Hned na začátku musí zákazník jasně říct, které procesy chce zlepšit, a které zachovat.
Uživatelé jsou pak tou skupinou, která je před konečné rozhodnutí postavena, bez větší možnosti toto rozhodnutí nějak ovlivnit. V mnoha případech je pak nový systém chápán jako zlo, které musí uživatelé přetrpět a učit se něco nového, co jim na začátku implementace práci spíše přidává nebo ji zpomaluje, protože systém ještě dostatečně dobře neznají. Navíc si někdy mohou svou neznalostí systému práci zkomplikovat.

Rozdílné cíle

Jak již bylo výše uvedeno, rozdílné cíle jsou samozřejmě důvodem, který tyto neshody způsobuje. Z pohledu managementu může být dosažení určitého cíle kritické. Někdy je ale dosažení tohoto cíle v rozporu s cílem jiné skupiny. Například pokud jsou uživatelé pro splnění cíle vedení nucení provádět nějakou z jejich pohledu práci navíc, je to v rozporu s tím, že pro ně šlo o zjednodušení práce. Protože se ale jejich práce stává složitější, může například docházet k větší chybovosti, což narušuje jiný původní cíl managementu.
Na výše uvedeném zjednodušeném příkladu mezi managementem a uživateli by potom dodavatel měl být tím, kdo navrhne v rámci řešení určitý kompromis či různé varianty, kde vybraná varianta oba cíle splní, nebo alespoň částečně splní.

Rozdílné pohledy na řešení neshod

Systémem navrhované vychystávání a zaskladnění

V případě implementace nového WMS zákazník očekává, že systém bude automaticky navrhovat úlohy zaskladnění a vyskladnění. Příkladem jednoho cíle managementu může být maximalizace volných skladových lokací. V praxi pro nastavení procesu vychystávání mohou vstupovat tato kritéria: celopalety ze skladových lokací s nejbližším datem expirace, dále celopaleta s nejnižším množstvím definované měrné jednotky (např. boxy), boxy z vychystávací lokace a například v poslední řadě menší měrná jednotka než boxy (kusy). Berme, že takto nadefinovaná kritéria vychystávacího algoritmu splňují definovaný cíl.
Z pohledu uživatelů ale v praxi mohou takto nadefinovaná pravidla způsobit problém. Místo toho, aby si uživatel vzal z jedné lokace celý box na vykrytí objednávky, tak mu z důvodu maximalizace volných skladových míst systém navrhne jednu úlohu pro odebrání posledního kusu a druhou úlohu pro „rozbití“ boxu pro vychystání zbývajícího množství kusů.
U skladu s rychloobrátkovým zbožím, kde je vysoký počet skladových transakcí (úlohy skladníků), může takto nastavené pravidlo způsobit operativní problémy a je nutné zvážit, jestli dosažení cíle maximalizace volných skladových míst není s ohledem na navýšení skladových transakcí příliš nákladné.
Další důsledek by toto nastavení mohlo mít na fakturaci. Místo toho, aby zákazníkovi bylo fakturováno za jeden box, by systém nyní navrhl k fakturaci jeden plus devět kusů (jeden box obsahuje deset kusů). Zákazník si ale objednal jeden box a takto by mu bylo fakturováno deset kusů, čímž by mohl přijít o některé výhody plynoucí z objednání vyšší měrné jednotky. Samozřejmě ale musíme předpokládat, že je fakturace tímto způsobem – tedy na úlohy výdeje – nastavená, protože chce například management zákazníkovi fakturovat manipulaci zboží pro vykrytí objednaného. Podobných příkladů u návrhu vychystávání a zaskladnění si lze představit nespočet.

Traceability

Často skloňovaným pojmem je i traceability – někdy překládaný jako dohledatelnost. Jde o požadavek na přesné dohledání historie vybrané položky, tedy její skladové pohyby. Pro management znamená traceability hodně. U 3PL a 4PL společností to navíc může být umocněno požadavkem od zákazníka. Se stoprocentní dohledatelností jsou ale mnohdy spojeny vícenáklady v podobě komplikovanějších, nebo spíše striktnějších skladových procesů pro uživatele ve skladu, a tedy přesnějšího dodržováním skladových operací.
Na druhou stranu pro řadové uživatele znamená traceability často jen práci navíc, a pokud nejsou uživatelům dostatečně striktně nastaveny procesní mantinely či pravidla práce nadřízeným, tak mají tendenci si práci zjednodušovat a porušovat pravidla nutná pro stoprocentní dohledatelnost. Někdy to může dojít tak daleko, že si uživatelé na dvou skoro prázdných lokacích stejného zboží dají do jednoho boxu zboží s různými šaržemi. Sice tím uvolní místo na přípravně, což jim následně umožní snáze vykrýt následující objednávky, ale společnost tak naprosto ztratí možnost dohledat historii k tomuto zboží.
I v tomto případě je třeba zvážit, o jak potřebný cíl se jedná a jestli náročnost jeho plnění nepřevyšuje přínosy.

Závěrem

Pro úspěšné dosažení všech nadefinovaných cílů jednotlivými skupinami, které se procesu implementace WMS a jeho následného užívání účastní, je nutné, aby strany jasně definovaly všechny stávající a požadované procesy, které má systém splňovat. Zde hraje velkou roli dodavatel nového řešení, který musí, s ohledem na znalost systému, od zákazníka zjistit a získat všechny potřebné informace pro správné nastavení systému. Management musí být schopen uživatele dostatečně jasně, někdy i přes jeho počáteční nevůli, donutit postupovat dle nadefinovaných procesů. No a pak už je jen na uživatelích, jak rychle se s novým systémem sžijí a kolik budou mít trpělivosti, než si nový systém přes počáteční rozdílnost osvojí.

Jan Kolář
Autor působí jako senior SCM konzultant společnosti Navisys.