Ať už je kterákoli firma v situaci, kdy si pořizuje nový informační systém, a ať už je jejím dodavatelem kterákoli softwarová společnost, jedno platí vždy: Úspěch implementace ERP závisí na tom, jak dobře je projekt připraven. K tomu je nezbytná výborná znalost potenciálního zákazníka a umění vyhodnotit jeho potřeby. Antonín Šejvl, dipl. tech.; Business AnAlytik systémů helios; Asseco solutions, A. s.
JešTě než doJde k zakoupení systému, měl by si zákazník umět odpovědět na tři základní otázky: Co od informačního systému očekává? Kolik chce investovat? V jakém časovém horizontu očekává spuštění? Teprve pak je možné zahájit přípravu projektu. Na druhé straně dodavatel by měl dokázat zákazníka k odpovědi na tyto klíčové otázky navést a zároveň pomoci identifikovat dle svých zkušeností důležité milníky projektu. Z toho tedy vyplývá, že již obchodní fáze a první kontakt se zákazníkem je důležitým startovním bodem úspěšné implementace. Zákazník by měl najít v dodavateli spíše partnera a poradce než „prodavače“. Dodavatel by měl umět vysvětlit, v čem vidí možné přínosy, úspory, ale i případná rizika projektu. Definice projektu, detailní analýza Jsme tedy v úvodní fázi projektu, kdy známe základní potřebu zákazníka a máme stanoveny finální cíle. Z těchto vstupních údajů je možné vytvořit tzv. „definici projektu“. Tento dokument mimo jiné popisuje role jednotlivých účastníků projektu a jejich odpovědnosti na straně dodavatele i na straně zákazníka, obsahuje definici řešení, etapy projektu s termíny plnění a důležitými milníky, požadavky na součinnost zákazníka nebo třetích stran a rizika projektu. V návaznosti na definici projektu je vytvořena detailní analýza. Ta už řeší konkrétní procesy a popisuje oblasti, které bude ERP řešit. Analýzu je možné vytvořit „modulově“, tedy popsat v ní funkci jednotlivých modulů, jako jsou Účetnictví, Sklady, Výroba a všechny ostatní, které zde budou implementovány. Anebo ji lze uchopit „procesně“, což znamená, že v ní budou detailně popsány všechny procesy, které bude systém u zákazníka řešit. Například od přijetí objednávky přes nákup materiálu, realizaci zakázky až po fakturaci. Mezi jednotlivými analýzami mohou být rozdíly také v jejich složitosti, což závisí na realitě a potřebách zákazníka. Jednou z klíčových součástí dokumentu analýzy jsou i definice akceptačních kritérií. Stejně jako každá smlouva je tvořena odběratelem a dodavatelem, tak i definice projektu a analýza musejí být vytvořeny společně. Každý zákazník je svým způsobem unikátní, takže i zkušený dodavatel potřebuje partnery v klíčových uživatelích zákazníka, kteří mu přiblíží současnou, ale i plánovanou podobu jednotlivých částí firmy. Centrála versus pobočka Často se stává, že vedení firmy, která si systém pořizuje, má konkrétní představu, jak mu ERP pomůže, co mu vyřeší, ale zdaleka ne všichni jeho zaměstnanci se s jeho myšlenkou ztotožňují. A to včetně těch, u nichž je třeba, aby se podíleli na implementaci. Proto je nutno, aby dodavatel znal nejen představy a přání vedení společnosti, ale aby pracoval i s jednotlivými klíčovými uživateli. Úkolem je, aby nakonec byli všichni klíčoví uživatelé ztotožněni s cílem implementace. Příkladem může být situace u zákazníka, kde se nasazovala ekonomika a sledování a vyhodnocování směn zaměstnanců. Tato firma se skládala z centrály a téměř stejně velké pobočky. V průběhu tvorby analýzy se ukázalo, že klíčoví uživatelé z každé z částí firmy mají na informační systém diametrálně odlišné požadavky. Po delších jednáních se podařilo mezi oběma subjekty docílit shody, ale celá implementace se tím podstatně zdržela. Peníze versus očekávání Dalším příkladem je společnost, kde se od začátku definice projektu ukazovalo, že klíčoví uživatelé mají úplně jinou představu o úloze ERP než vedení společnosti. Zjednodušeně se dá říci, že vedení zakoupilo „cosi“, do čeho nechtělo investovat mnoho peněz, a tak funkčnost nebyla v takovém rozsahu, jaký uživatelé očekávali. Ti naproti tomu předpokládali, že jim ERP vyřeší ve firmě naprosto vše. Nakonec bylo nutné navýšit investici a vyměnit některé klíčové uživatele, aby bylo možné zajistit spuštění systému v potřebném rozsahu. Zde je důležitá role dodavatele jako odborníka na danou problematiku, který by měl umět zákazníka nasměrovat a pomoci mu zvážit přínosy a rizika ještě před samotnou investicí. Znovu a lépe Po odsouhlasení analýzy nastává fáze konfigurace a implementace systému. Pokud dodavatel od začátku správně pracuje se zákazníkem a jeho klíčovými uživateli a zákazník má ujasněnou představu o svém záměru, implementace by měla probíhat podle stanoveného harmonogramu. Tím bychom měli dosáhnout včasného a úspěšného dokončení projektu. Nicméně realita bývá odlišná. Důsledkem podcenění analýzy je vznik dodatečných požadavků ze strany zákazníka, u nichž je obtížné definovat, zda jsou v rámci, nebo nad rámec projektu. Výsledkem jsou nepříjemná a časově náročná jednání, která mohou projekt prodlužovat a zároveň prodražit. Příklad: Evidujeme kartu majetku, na níž jsou zákonné hodnoty, které je nutné kontrolovat a zapisovat. Karta může obsahovat i evidenční a inventární údaje či další nepovinné atributy. Pokud potřebné údaje nejsou v analýze definovány, dochází k rozdílnému vyložení popsaného procesu a to někdy vede až k více nákladům na projekt. Jak známe z praxe, stejnou situaci může ale také zavinit více údajů na kartě, než chce zákazník využívat. V těchto situacích je jediným možným řešením vrátit se o krok či více kroků zpět a danou část analýzy spolu se zákazníkem upravit. Dvě zásady Uvedl jsem pouze pár často se opakujících situa cí, kterým je lépe předcházet. K tomu by měly napomoci dva zásadní body: Zkušený dodavatel ERP by měl umět maximálně eliminovat nejasnosti již v části definice projektu a analýzy. A zároveň by měl být pro zákazníka respektovaným rádcem. Zákazník by měl znát svůj cíl a s tímto cílem by měly být ztotožněny i všechny klíčové osoby. Jestliže si tedy obě strany ujasní očekávání a potřeby, jestliže všichni vědí, jak je naplnit, a jestliže toto vše je do potřebné hloubky zachyceno na stránkách dokumentace, máme správně nakročeno k úspěšné implementaci projektu.