Zdravá skepse

Zdravá skepse vizi nezabije, ale pomůže ji naplnit. V oblasti ERP projektů je často na straně investorů rozšířena představa, že stačí vybrat ten správný systém a úspěch je zaručen. U ERP systémů nemluvíme o „krabicovém“ řešení typu plug-and-play, přesto je v uživatelích toto vnímání zakořeněné. Pokud investor předem počítá s opozicí vůči novému ERP systému uvnitř své společnosti, ušetří si nepříjemné překvapení. Změna vždy naráží na odpor, ať už ze strany konkrétních lidí nebo zaběhlých pořádků. Relevantní otázky investora jsou:

Kolik času mých lidí investuji do projektu?

Konkrétní uživatelé buď nepočítají s nutností aktivně se účastnit implementace, nebo jim to jejich pracovní vytížení neumožňuje. Personální zajištění implementace hraje pravděpodobně největší roli na úspěchu či neúspěchu projektu. Dodavatelé ERP systémů mají pochopitelně své specialisty, ale na straně investorů velmi často dochází k podcenění role vlastních lidí. Implementace je spolupráce dvou stran. Pro investora to za prvé znamená vytvořit uživatelům prostor pro aktivní účast na implementaci. Na druhé straně také důsledné vyžadování této účasti od svých pracovníků.

Jsem připraven prosadit změnu navyklých postupů?

Pokud by otázka zněla: Jsem ochoten změnit navyklé postupy?, odpověď by jistě byla kladná. Nicméně v praxi potom nastává situace, kdy se uživatelé pod provozním tlakem uchylují (vracejí) k zaběhlým postupům, obcházejí principy nového informačního systému a odpovědným pracovníkům chybí vůle tyto odchylky minimalizovat a trvat na nově dohodnutých postupech. Výjimky neubývají, ale množí se a výsledkem je nepřehledný systém s nekonzistentními datovými výstupy. Velmi dobrou investicí je zabývat se již v průběhu předimplementační analýzy vytvořením sady klíčových kontrolních či omezujících mechanismů, které pomohou udržet uživatele v mantinelech.

Udržení dynamiky projektu

Čím déle projekt trvá, tím se zvyšuje pravděpodobnost jeho zpomalení nebo zastavení, tedy ztráta dynamiky. Dynamika projektu je klíčová pro to, aby projekt žil v povědomí uživatelů – tím se také projevuje. Všichni víme, že k rozpohybování stojícího tělesa je třeba daleko většího úsilí než k udržování v pohybu. S projektem je to stejné. V předchozím odstavci jsme zmínili nutnost aktivně zapojit klíčové uživatele do implementace – to vyžaduje motivování, přesvědčování, školení, plánování atd. Restart projektu by znamenal to celé opakovat znovu. Jak se vyhnout ztrátě dynamiky:

• zajistit motivaci garanta projektu za stranu investora a klíčových uživatelů k dosažení stanovených cílů projektu v konkrétních termínech,
• zkrátit dobu mezi školeními a praktickým používáním získaných dovedností,
• pravidelně s uživateli vyhodnocovat etapy implementace,
• co nejdříve začít čerpat a prezentovat data z nového systému.

Plán B

Co když se to nepovede spustit v termínu? Tato a jí podobné otázky někdy manažery dráždí a jsou považovány za poraženectví nebo alibismus. Zbytečně. Mít plán B je nutnost a investor by ho měl vyžadovat i od dodavatele svého ERP systému. Možná rizika se vždy dají minimalizovat zvýšenou pozorností na etapu testovacího provozu, nicméně nikdy je úplně neodstraníme. Neúspěšné spuštění projektu bez připravené záložní varianty přináší škody, a to nejen finanční. V podstatě dochází k zastavení projektu, uživatelé jsou frustrováni a ztrácí důvěru v nový systém. Je důležité si uvědomit, že toto hrozí i v případě, kdy se jedná o skutečně kvalitní ERP systém.

Zajištění následné podpory

ERP projekt je živá záležitost, která nekončí ukončením implementace. Požadavky a potřeby uživatelů se pochopitelně mění v závislosti na prostředí, ve kterém investor podniká. Často se také v průběhu implementace řeší pouze stěžejní „must be“ záležitosti, a „nice to have“ (rádi bychom) body zůstávají do další fáze. Z těchto důvodů je nutné, aby měli uživatelé zajištěnou následnou odbornou podporu. Většina dodavatelů ERP systémů provádí na závěr fáze implementace tzv. dohled nad rutinním provozem, kdy uživatelé již v novém systému pracují a dostávají odezvu na své provozní dotazy a požadavky – obvykle se jedná o jeden až dva měsíce od zahájení provozu. Po ukončení dohledu může nastat „zakonzervování“ ERP systému, čímž však bude systém postupně ztrácet schopnost reagovat na měnící se požadavky. Aby se tomu investor vyhnul, je třeba zajistit, buď z vlastních zdrojů, nebo outsourcingem specialistu, který uživatelům podporu poskytne. Dodavatelé ERP systémů dnes nabízejí poměrně širokou řadu služeb na pokrytí těchto provozních zákaznických požadavků. Typickým příkladem je reporting, ať už se jedná o výměnu dokladů nebo nejrůznější statistiky. Samozřejmostí většiny ERP systémů je dnes prezentace dat formou BI statistik, nebo alespoň prostředky MS Excel atd. To výrazně rozšiřuje možnosti využití systému, ale málokterý investor má dostatečně pokročilé uživatele schopné si tyto statistiky definovat podle aktuálních požadavků. Pokud si investor nezajistí následnou podporu, pravděpodobně začne po určité době od svých pracovníků slýchat: to náš systém neumí, to v našem systému nejde. Může tím dojít i k určitému znehodnocení původní investice do nového systému. ERP systém je užitečný nástroj, je však pouze na uživateli, jak vytěží jeho potenciál.

Časté chyby při nasazování ERP

Nejčastější chybou na straně zákazníka a zároveň největším problémem při nasazení ERP systému je nedostatečná zainteresovanost zaměstnanců zákazníka. V takovém případě je pak velkým přínosem zkušený garant uživatele, který by měl zabezpečit vtáhnutí zaměstnanců do procesu a správně interpretovat jejich požadavky a následně řešení. Toho však nelze dosáhnout bez podpory vedení společnosti, které musí být přesvědčeno o správnosti nasazení ERP systému ve své firmě. V případě, že nebude podpora pro projekt ze strany vedení, těžko ji lze očekávat ze strany zaměstnanců, pro které je to velká zátěž nad rámec běžných pracovních činností.
Z toho pak i nepřímo vyplývá další častá chyba na straně zákazníka, a to nabytí mylného dojmu, že vlastně za nic nezodpovídá a všechny starosti leží na bedrech konzultanta. Dochází pak k nepříjemným situacím, kdy si uživatel objedná uživatelské řešení, podepíše a odsouhlasí analýzu, a teprve při nasazení zjišťuje, co vlastně odsouhlasil. Dodatečně požaduje funkčnosti nad rámec analýzy s tím, že to tak myslel a určitě to říkal, jen se moc nevěnoval přečtení a oponentuře analýzy. Výsledkem je naprogramované uživatelské řešení, které dodavatel chce zaplatit, neboť odpovídá odsouhlasené analýze, ale zákazník ji zaplatit nechce, protože neodpovídá jeho představě.
Jelikož je konzultant ve většině případů daleko zkušenější než zákazník, neměl by tuto situaci dopustit. Měl by se důsledně věnovat požadavkům zákazníka a vždy provádět jejich podrobnou analýzu a ujistit se, že opravdu obě strany mluví o tomtéž. Veškerá připravovaná řešení detailně představit uživateli a opět se ujistit, že návrh řešení odpovídá zákazníkovu požadavku. Řešení by mělo být vždy co nejjednodušší a nikdy polovičaté. Jedno špatné řešení může totiž zbortit práci všech zainteresovaných osob v celém projektu. Z toho plyne, že největší chybou ze strany dodavatele je podcenění situace.

Pavel Pech
Autor je mobilním konzultantem ve společnosti J.K.R., která dodává podnikové informační systémy Byznys ERP.