V předcházejícím článku jsme se zabývali první fází implementace ERP systému. V případě jejího úspěšného absolvování jsme se dostali do okamžiku, kdy máme v ruce zákazníkem protokolárně akceptovanou detailní analýzu. Tím nastává období vlastní implementace – pro zákazníka o něco klidnější, zatímco pro dodavatele období plného nasazení s cílem stihnout stanovený termín.

V tomto období dodavatel nejdříve systém nastavuje a přizpůsobuje podle odsouhlasené detailní analýzy požadavkům zákazníka. Sem patří namátkou: nastavení parametrů a konfigurací jednotlivých dokladů, úprava tiskových šablon a nabídek funkcí, vytvoření integritních omezení pro jednotlivé atributy (povinné atributy, přednastavené hodnoty) nebo stanovení následných kroků, které se mají vykonat automaticky na základě splnění nějaké vstupní podmínky. V neposlední řadě se v této fázi implementace systému nastavují kategorie práv a přístupů pro jednotlivé uživatele.

Do tohoto období spadá též tvorba dovývojů, tedy úprav, které nelze udělat prostou konfigurací stávajících parametrů systému, ale je třeba provést programové úpravy přímo v kódu systému. V praxi tyto dovývoje bývají často zdrojem sporů mezi dodavatelem a zákazníkem. Dle zákazníka jsou jeho požadavky oprávněné, zatímco dodavatel je považuje za požadavky nad rámec dodávky. V tomto případě nezbývá než takový požadavek konfrontovat s detailní analýzou. To je další důvod, proč detailní analýze věnovat patřičnou pozornost. Pokud dodatečný požadavek zákazníka je skutečně nad rámec projektu, pak je potřeba vyvolat takzvané změnové řízení, ve kterém je požadavek přesně popsán. Dodavatel navrhne způsob a podmínky řešení a takto připravený dokument je předložen ke schválení na jednání vedení projektu za obě strany.

Když nastane problém…

Nejen v tomto období, ale v průběhu celé implementace je důležité pravidelně svolávat takzvané kontrolní dny, na kterých se rekapituluje práce odvedená za uplynulé období, připravují se podklady pro vedení projektu a plánují se konkrétní kroky a úkoly na další období. V případě nutnosti řešení některých sporných bodů se svolává jednání vedení projektu, takzvaný řídící výbor, kde jsou přítomni i manažeři s vyššími rozhodovacími pravomocemi. Zpravidla to bývá sponzor projektu na straně odběratele a přímý nadřízený vedoucího projektu či ředitel příslušné divize na straně dodavatele.

Jak už bylo řečeno, v tomto období se těžiště práce přesunuje na dodavatele. To však neznamená, že zákazník není do procesu implementace vůbec zapojen. Naopak, velmi doporučujeme, aby jednotlivé dílčí realizační kroky dodavatel se zákazníkem průběžně konzultoval. Jakmile je nakonfigurována nějaká oblast systému, je dobré toto nastavení se zákazníkem projít a odsouhlasit si je. Vyhneme se tímto nepříjemným překvapením a diskusím při školení či testování systému.

Součástí této projektové fáze je i zahájení prací na migraci dat ze stávajícího systému do nového. Dodavatel by měl v dostatečném předstihu zákazníka seznámit s rozsahem a strukturou požadovaných importních dat. Tato část implementace by se neměla podcenit, protože zákazník má často problémy s přípravou těchto požadovaných dat a jejich konverzí do správné struktury. Je to dáno zejména tím, že se již nemůže plně opřít o podporu dodavatele stávajícího systému a jednak sám zpravidla nedisponuje potřebnými znalostmi ohledně datové struktury původní databáze.

Co se ve fázi implementace naučíš...

Období nastavování systému obvykle končí fází školení uživatelů. Pochopitelně by se mělo školit na již nastaveném a připraveném systému. Školit uživatele dříve by nemělo smysl, protože jednak by se učili pracovat se systémem, který se bude v konečném důsledku lišit od jejich produkčního nastavení, jednak by mohli uživatelé bez potřebného tréninku řadu věcí zapomenout.

Při organizaci školení uživatelů, se musíme držet několika důležitých zásad. Nejdříve musíme zákazníka seznámit s programem plánovaného školení. Nejen proto, aby školení mělo konkrétní osnovu a náplň, ale i proto, aby zákazník mohl na jednotlivá školení cíleně poslat ty uživatele, jejichž pracovní náplně se školení bude týkat. Například stanovíme, že budeme školit ekonomické moduly. Ovšem to je příliš široké téma, proto je důležité upřesnit, co konkrétně bude náplní, například práce s bankovními výpisy, importy a exporty plateb, úhrady apod.

Další důležitou zásadou je nepřipustit, aby zákazník školení pojal jako další konzultaci či analýzu. Řadoví uživatelé při prvním podrobnějším seznámení se systémem mají tendenci diskutovat o nastaveném řešení a vznášet další požadavky. Školení se pak může snadno změnit v diskusi na téma, že dosud se to a to dělalo jinak a proč se to nyní má dělat takto… Je tedy na školiteli, aby se k podobné diskusi nedal strhnout a držel se programu školení. Na straně klíčového uživatele zákazníka je pak usměrňovat dotazy uživatelů a držet se programu školení v rámci dané osnovy. Právě klíčový uživatel musí být schopen vysvětlit ostatním uživatelům, proč je nutná ta či ona změna v jejich práci a pracovních postupech. Na druhé straně je třeba k podnětům uživatelů v rámci školení přistupovat s otevřeností, protože právě nyní mohou přijít dobré a věcné připomínky k rutinnímu užívání nového systému. Školitel si v takovém případě má udělat poznámky a věc dořešit mimo vlastní školení.

...v ostrém provozu jako když najdeš

Přenesme se už do doby, kdy je systém u zákazníka, je plně nastavený a uživatelé jsou proškolení. Nyní nastává další velmi důležitá fáze – import dat. V této fázi projektu se importují ty číselníky, které by měly být v novém systému ještě před zahájením ostrého provozu, tedy například: organizace (odběratelé, dodavatelé, …), kmenové karty materiálu a zboží ve skladu, organizační struktura, zakázky či smlouvy. Další import dat nastává neprodleně po startu systému do ostrého provozu. V tuto chvíli se importují počáteční stavy účtů a další otevřené položky, například zálohové faktury, platební kalendáře, které byly vygenerovány ještě ve starém systému, ale jsou splatné až v budoucím období. Jak jsme již doporučovali, s přípravou importů je dobré začít co nejdříve.

Nepodcenit testování

Posledním krokem před spuštěním systému do ostrého provozu je jeho testování. Testování probíhá ve dvou úrovních. Nejprve je realizován takzvaný „pilotní test“. Jeho cílem je ověření nového informačního systému, a to jak z hlediska komplexnosti, tak správnosti nastavení podle schválené úvodní analýzy. Test provádí konzultant za danou oblast společně s klíčovým uživatelem. U testování, podobně jako v případě školení, doporučujeme předem seznámit zákazníka s „testovacím plánem“. Ten by měl obsahovat přesný harmonogram testu, soupis jednotlivých testovacích případů, místo a způsob testování včetně definice testovacích dat a prostředí.

Druhou úrovní je „komplexní test“, tedy závěrečný test před spuštěním systému do ostrého provozu. Jeho úspěšné provedení je podmínkou pro ostrý start. Podobně jako u pilotního testu i zde vzniká testovací plán, s tím rozdílem, že samotný test vykonávají jednotliví uživatelé a pracuje se s již importovanými daty. Kontrolují se jednotlivé funkcionality a nastavení, tiskové výstupy, přístupová práva uživatelů, stabilita systému, ale i uživatelské znalosti a připravenost prostředí. Zejména připravenost uživatelů na přechod na nový informační systém by se neměla podceňovat.

Jak pilotní, tak i komplexní test jsou po dokončení protokolárně vyhodnoceny. Přílohou protokolu je již zmíněný testovací plán a samozřejmě též výsledek testu včetně termínů a způsob odstranění případných nedostatků a chyb. Akceptační protokol komplexního testu se stává výchozím dokumentem pro rozhodnutí o spuštění systému do ostrého provozu ke konkrétnímu datu.

Konec tréninku – je čas skočit do vody a plavat

Nyní následuje poslední fáze – zpravidla jeden měsíc – kdy je systém provozován v takzvaném pilotním provozu. Toto období je zpravidla ukončeno úspěšným provedením některých klíčových operací, například zpracováním mezd, měsíční účetní závěrky apod. Probíhají poslední aktivity implementačního týmu. Dodavatel zajišťuje zvýšenou podporu uživatelů. To znamená, že jednotliví konzultanti přímo v sídle zákazníka (nebo vzdáleným připojením) pomáhají uživatelům s orientací v systému, kontrolují data, monitorují jednotlivé procesy apod. Po úspěšném ukončení pilotního provozu je zákazník převeden do režimu běžné servisní podpory. Ta zpravidla obsahuje služby typu hotline, pravidelné aktualizace systému na nové verze, přístup na zákaznický portál atd. Ale to už je jiný příběh….

Luboš Krubner