Implementace ERP ve výrobní firmě

Výchozí situace

Firma řídila zakázkovou výrobu napříč sedmi technologiemi v legacy systému postaveném na MS Access. Vedoucí výroby každé ráno obcházel pracoviště a rozděloval papírové průvodky. Kalkulace vznikaly kopírováním textových polí ze starších zakázek a tisková data se předávala e-mailem nebo v papírových složkách.

Zakázka běžně procházela třemi až pěti technologickými uzly v pořadí, které se kus od kusu měnilo. S rostoucím objemem už původní systém nedával firmě spolehlivou historii položek, jednotné názvosloví ani jistotu, že výroba pracuje s poslední schválenou verzí dat.

Cílem nebylo nasadit ERP. Bylo potřeba připravit firmu, data a procesy tak, aby nový systém vůbec mohl fungovat v reálném provozu.

Co měl projekt změnit

• zkrátit průběžnou dobu zakázky z dvou až tří týdnů na jeden až dva
• snížit rozpracovanost pod 200 otevřených zakázek řízením průtoku
• zajistit škálovatelnost až na 1 000 otevřených zakázek bez degradace výkonu
• přenést výrobní informace digitálně na zařízení u pracoviště místo papírových průvodek

Zadání jako nástroj řízení projektu

Zadávací dokumentace nepopisovala jen seznam požadovaných funkcí. Definovala cílové ukazatele, principy výběru řešení a kompletní cestu zakázky ve 25 krocích, od přijetí poptávky po post-costing, vždy s vlastníkem a požadovaným chováním systému.

Principy výběru byly pevné: hledal se hotový systém přizpůsobitelný konfigurací, ne vývoj na zelené louce. Specifika firmy měla jít vyřešit standardním nastavením místo zásahů do jádra. Pokud se interní proces lišil od standardu ERP, nejdřív se zvažovala změna vlastního postupu. Žádná úprava nesměla blokovat budoucí aktualizace a napojení mělo běžet přes standardní konektory nebo otevřené API.

Dobré zadání není nákupní formulář. Je to dokument, o který se dá opřít ve chvíli, kdy se implementace začne rozcházet s dohodou.

Datová příprava proběhla mimo ERP

Největší kus práce se odehrál dřív, než se systém vůbec zapnul. Standardizace dat, názvosloví a výrobní logiky vychází z byznys logiky firmy, takže ji dodavatel systému za zadavatele udělat nemůže.

• pětisložková logika názvu položek, která odstranila duplicity a zpřehlednila číselník
• katalog 75 normalizovaných operací se sjednoceným kódováním
• 32 vzorů produkce, každý v průměru s 12 operacemi, jako základ šablon výrobních postupů
• datový model, jehož hierarchii jsme během přípravy upravili podle toho, jak firma skutečně pracuje
• jednotný formát dokladů a samostatné číselné řady pro klíčové typy
• šest standardních fakturačních artiklů dopravy postavených na Incoterms místo volných textů

Procesní mapování přímo s lidmi z provozu

Mapování probíhalo po jednotlivých uzlech: jedno pracoviště, jedno sezení, jedna otázka v jednu chvíli. Ne dotazníky, ale rozhovory s lidmi, kteří danou práci reálně dělají. Zápis se hned převáděl do diagramu a nechával odsouhlasit. Rozsah zahrnoval devět výrobních uzlů, tři materiálové větve, dokončovnu, naskladnění hotových výrobků i administrativní část cesty zakázky.

Procesní mapa popisuje, co výroba potřebuje. Ne jak má vypadat obrazovka ERP. Technické řešení je odpovědnost dodavatele, byznys logika odpovědnost zadavatele.

Z mapování vzešla samoobslužná fronta práce na pracovištích místo ranního rozdávání papíru, automatická priorita podle termínu zákazníka a počtu zbývajících operací, evidence neshod s eskalací až při ohrožení dodávaného množství a sdružování výrobních příkazů se stejnou operací a materiálem do jednoho běhu.

Change management: systém se nemění jen technicky

Ve firmě pracovalo přibližně 50 lidí, velká část přímo u strojů a bez každodenní práce s počítačem. Přechod proto nešlo postavit na jednorázovém školení těsně před spuštěním.

• komunikovaly se konkrétní termíny, ne neurčité „na podzim"
• školení jako rutina: hodina denně, stejný čas a místnost po celý měsíc před náběhem
• personální a mzdové závazky komunikoval CEO, ne projektový tým
• výroba dostala zařízení s předinstalovanou aplikací přímo na pracoviště
• podněty šly jedním kanálem přes vedoucí do dohledatelného seznamu
• denní rytmus náběhu: ranní huddle, polední stavová tabule, odpolední kontrola s dodavatelem

Pilot a odchylka

Pilot byl ostrý a proběhl napříč všemi odděleními současně, protože dílčí pilot po jednom oddělení netestuje realitu zakázky, která firmou prochází napříč. Měl jeden cíl týdne, měřitelné kritérium úspěchu a předem definovaný rollback trigger s konkrétním dnem, hodinou a prahem migrované rozpracovanosti. Starý systém běžel několik týdnů jako pojistka.

Ostrý náběh proběhl podle plánu a firma se ke starému systému nevrátila. Pilot ale odhalil vady, které se v testovacím prostředí neprojevily. Nejvíc zasáhly skladovou agendu, jejíž ostrý náběh se posunul o dva týdny.

Odchylka byla vidět druhý den, ne na konci měsíce. Právě proto měl projekt od začátku denní rytmus, jeden kanál pro chyby a předem stanovený rollback trigger.

Co firmě po projektu zůstalo

Každá fáze končila výstupem, se kterým firma pracuje dál bez přítomnosti člověka, který implementaci vedl: zadávací dokumentace s cestou zakázky ve 25 krocích, názvoslovná logika a číselníky, procesní mapa devíti uzlů, podkladové karty pro implementační tým, změnová tabulka vad a požadavků se stavem a vlastníkem, komunikační materiály a plán pilotního týdne, uživatelská příručka obchodního oddělení a postupy expedice a fakturace.

Hotový projekt není systém, který je nasazený. Hotový je ve chvíli, kdy firma ví, jak v něm pracovat, má popsané procesy, vlastní data a umí pokračovat bez člověka, který implementaci vedl.

Časté otázky