Rekapitulace zkušeností z reálného ERP projektu

Od října loňského roku do května letošního roku jste se mohli na stránkách IT Systems (čísla 10/2008, 12/2008, 3/2009, 5/2009) a současně na webovém portálu www.ERPforum.cz setkat se čtyřmi pokračováními seriálu Krok za krokem projektem ERP, které popisovaly vývoj reálné implementace podnikového informačního systému ve výrobním podniku. Jednotlivé články s malým odstupem komentovaly aktuální situaci a při psaní prvního příspěvku tedy nebylo vůbec jasné, jak celá implementace nakonec dopadne. V tomto samostatném článku bych se rád vrátil k rekapitulaci celého projektu a k některým obecným závěrům.

Podnik

Hned v úvodu připouštím, že začínat text odkazem na finanční a hospodářskou krizi je poměrně velké klišé, nicméně okolní ekonomická realita měla samozřejmě vliv na celý projekt. Pozorní čtenáři si možná pamatují, že původně měl projekt proběhnout až v roce 2009, přičemž ostrý start nového systému byl naplánován na 1. ledna 2010. Nakonec došlo vlivem celé řady okolností k posunu směrem dopředu s plánovaným ostrým startem 1. dubna 2009. Při zhodnocení celé akce jsme došli k závěru, že při původních termínech bychom projekt vůbec nezačali, nebo ho přerušili v jeho úvodních fázích. V průběhu prvních dvou měsíců roku 2009 byl přehodnocen celkový business plán naší společnosti, a to včetně snížení nebo zrušení rozpočtů na celou řadu projektů, a kdyby byla reimplementace teprve v úvodních fázích, zcela jistě by byla mezi těmi, které zahraniční vlastník doporučil k zastavení. Díky posunu byl projekt na začátku roku 2009 již v závěrečné fázi, a proto mohl být dokončen. I dodavatel řešení potvrdil, že řada slibně rozpracovaných pre-sales akcí z té doby byla zastavena v podstatě ze dne na den. U jedné ze smluv se dokonce od managementu zákazníka dozvěděli, že kdyby byl podpis smlouvy naplánován o týden později, už by k němu nedošlo. IT projekty jsou tak jednou z oblastí, kde se výrazně projevily škrty v podnikových rozpočtech, přičemž firemní lídři uvažují asi následovně: pokud systém není v úplně havarijním stavu a alespoň trochu funguje, může implementace nebo reimplementace ještě počkat. Dodavatelé samozřejmě tvrdí, že nový systém může pomoci optimalizovat řadu procesů a tím přinést úspory i v této složité situaci, ale realitou je, že počet IT projektů se v podnikové oblasti snížil. Důkazem je i statistický pokles průměrného výdělku pracovníků v IT z poslední doby, a to po velmi dlouhém období nepřetržitého růstu.

Management podniku

Co se týká přístupu vrcholového managementu k celému projektu reimplementace, dal by se podle mých dosavadních zkušeností označit za standardní. Generální ředitel a další vrcholoví manažeři projekt vnímali, nicméně nechávali ho zcela v kompetenci sponzora projektu a vedoucího projektu. Základním předpokladem stále zůstávalo, že reimplementace nesmí jakýmkoliv způsobem ohrozit chod společnosti. Projekt byl velmi dobře komunikován sponzorem projektu (který byl jako finanční ředitel rovněž vrcholovým manažerem) a měl možnost jednat přímo s generálním ředitelem, což bylo v řadě případů velmi důležité. Rovněž bylo bez problému akceptováno poměrně zásadní omezení, jako byl pětidenní výpadek provozu informačního systému při převodu dat a finálním přechodu na reimplementovaný systém. Mojí osobní satisfakcí bylo neformální ocenění od obchodního ředitele společnosti, který v našem rozhovoru mezi čtyřma očima vyzdvihl fakt, že společnost přešla na nový systém, aniž by uživatelé zaznamenali jakékoliv závažné problémy.

Projektový manažer a konzultanti dodavatele

Jak již vyplynulo z prvního odstavce, počet velkých IT projektů se momentálně snižuje, takže zákazníci, kteří takový projekt přinášejí, získávají logicky maximální podporu dodavatele. V současné době většina řešení ve stejné cenové hladině naplňuje obdobným způsobem požadovanou funkcionalitu, zásadní přechody na řešení od jiných dodavatelů jsou stále méně časté a existuje oboustranný zájem na dlouhodobé spolupráci. Tento stav přináší podle mého názoru i méně vyhrocené vztahy zákazník versus dodavatel. Řídil jsem za posledních patnáct let celou řadu projektů a tento považuji za nejméně konfliktní. K tomuto faktu beze sporu přispěli i projektoví manažeři na obou dvou stranách. V každém okamžiku převládala snaha domluvit se a nalézt společné řešení, jednání byla otevřená a korektní za všech okolností. Několik drobných nedorozumění se podařilo zažehnat již v zárodku díky vzájemnému respektu, ale současně bezproblémové komunikaci obou projektových manažerů, kteří se svou věkovou kategorií (nad 45) a svými zkušenostmi řadí již mezi „veterány“. Jsem přesvědčen, že pro řízení takového projektu musí mít jeho manažer přece jenom už něco „odžito“, a to jak odborně, tak i osobně. Rozvaha, nadhled, již mnohokrát prodělané a překonané krizové situace, smysl pro humor i vyrovnaný mimoprofesní život jsou pro řízení projektů ty nejcennější devizy.

Konzultanti dodavatele rovněž potvrdili svoje vysoké kvality. V této oblasti se nicméně projevila jedna slabina, a sice pokrytí jednotlivých oblastí pouze jedním skutečně kvalitním (senior) konzultantem. Při jeho krátkodobém výpadku (nemoc, dovolená, vyšší priorita jiného projektu) docházelo k občasným přerušením jinak příkladné spolupráce. Tento nedostatek je ale podle mého názoru typický i pro další dodavatele a je způsoben menším českým trhem.

Projekt

Co se týká vlastního průběhu a řízení celého projektu, vyplynulo po jeho skončení několik následujících zobecnění a doporučení.

Předimplementační příprava je zcela nezbytnou součástí projektu implementace informačního systému a má zásadní dopad na jeho úspěšnost. Nezávislost procesního modeláře na vlastním řešení nepřinesla žádné problémy.

Rozdělení celého projektu na jednotlivé etapy se ukázalo jako velmi výhodné, a to zejména z následujících důvodů:

• mnohem přesnější, detailněji formulovaná, a tedy i lépe kontrolovatelná zadání jednotlivých etap (segmentace projektu),
• samostatná smlouva pro každou etapu (přirozené rozložení plateb v čase),
• každá následná etapa mohla být zahájena až po úplném dokončení předchozí etapy (přirozený tlak na dodavatele ve smyslu dodržování dílčích termínů v průběhu projektu),
• možnost projekt případně přerušit a zakonzervovat v jasně definovaném a zdokumentovaném stavu (již dokončené a zdokumentované etapy by bylo možné jednoduše použít při obnovení projektu).

Každý IT projekt obecně sleduje tři plánované parametry: čas, funkčnost a náklady. Parametr času byl v našem případě splněn – reimplementovaný systém byl spuštěn přesně podle plánu 1. dubna 2009.

Konečná funkcionalita řešení byla předmětem poměrně náročného vyjednávání. Všechny uživatelské požadavky (odchylky od standardního řešení), které projektový tým shromáždil, by při realizaci vysoce překročily plánované náklady. Z tohoto důvodu došlo k částečné redukci těchto požadavků. Zásadním rozhodnutím bylo nenutit dodavatele do všech změn při zachování původní ceny, protože by zcela jistě utrpěla kvalita požadovaných úprav. Nakonec ustoupily obě strany – zákazník redukoval svoje požadavky a dodavatel zproduktivnil svoji činnost (částečné zvýšení počtu konzultantských a programátorských hodin bez současného zvýšení ceny).

Původně plánované náklady na projekt byly nakonec překročeny o šestnáct procent. Důvodem bylo odůvodněné rozšíření původně plánovaných uživatelských požadavků na odchylky od standardního řešení.

Projekt byl tedy splněn ve dvou ze tří původně plánovaných parametrů, přičemž nesplnění nákladů bylo odůvodněno větším uživatelským komfortem. Takto vyhodnocený projekt je podle mého názoru možné hodnotit jako úspěšný.

Mezi další zobecněná doporučení je možné zařadit striktní vedení projektové dokumentace (rutinní záležitost, která se ale následně vyplatí). Porady vedení projektu za účasti obou stran se osvědčily v intervalu jedenkrát za měsíc.

Jako zásadní se ukázalo detailní vypracování a mnohonásobné prověření závěrečného harmonogramu přechodu na reimplementovaný systém (poslední týden byl rozepsán v podstatě na jednotlivé hodiny).

Projektový tým

Mojí osobní ambicí bylo pokusit se změnit charakter členů projektového týmu, kteří se rekrutovali převážně z řad interních programátorů (specialistů, kteří vytváří zdrojový kód) na konzultanty (experty, kteří znají podnikové procesy a mají schopnost aktivně řídit a zlepšovat prostředí informačního systému pro jednotlivé podnikové oblasti). Tato snaha se nesetkala s očekávaným výsledkem. Pouze u jednoho kolegy z pěti je v současné době předpoklad, že by tento kvalitativní posun zvládl. Ostatní se stále profilují spíše jako „opraváři kódu“ než jako „opraváři procesů a metodických postupů“. Důvodem je zřejmě vyšší věkový průměr a vnitřní neochota k takové změně.

Dalším faktorem, který se poměrně jasně projevil, byla nepříliš vysoká odolnost proti stresu. Za devět měsíců se samozřejmě vyskytla celá řada problémů, ale rámcově projekt probíhal téměř přesně podle plánu. Přesto se stres podepsal na všech členech projektového týmu ve formě některých neadekvátních reakcí, zvýšeného počtu vzájemných konfliktů, pesimismu vzhledem k výsledku celého projektu apod. V jednom případě měla situace těsně před koncem projektu souvislost i s drobnými zdravotními komplikacemi člena projektového týmu.

Jedním z problémových momentů, za který se cítím plně zodpovědný, byla nevyjasněná situace s celkovou odměnou. Na začátku projektu byla sice zcela přesně definována částka, kterou projektový tým získá v případě úspěšně zrealizovaného projektu, ale předem nebylo stanoveno, kolik dostanou konkrétní členové týmu, ani v jakém časovém horizontu budou jednotlivé části odměny vypláceny. Tato nejednoznačnost vyvolala po skončení projektu mnoho „zlé krve“ a osobně jí beru jako velké poučení pro případné příští projekty. Kromě této zásadní chyby považuji naopak za svůj úspěch zejména dobře zvládnutou komunikaci vzhledem k dodavateli, ale i vzhledem k managementu, uživatelům a až na již zmíněnou chybu i vzhledem k projektovému týmu. Projekt mně osobně přinesl celou řadu nových poznatků a zkušeností. V současné době mi bylo ve společnosti svěřeno řízení dvou poměrně velkých projektů, přičemž jeden je mimo oblast IT.