V předcházejícím dílu našeho miniseriálu jsme si v obecných rysech představili jeden reálný projekt nasazení ERP systému, na kterém si ukazujeme postup a také úskalí implementace komplexního ERP systému jako náhrady jednoúčelového informačního systému a dalších jednoúčelových aplikací. Projekt se nyní dostal do situace, kdy je vybrán konkrétní produkt, je schválen projekt implementace a ustaven projektový tým. Jsou také stanoveny klíčové termíny a podepsány smlouvy. Co bude dál?

Vlastní realizace projektu byla rozdělena do následujících fází:

• Analýza a návrh řešení - v této fázi se zkoumají všechny firemní procesy jako takové a zároveň se zkoumá i jejich průběh v současných informačních systémech. Na základě této analýzy je navržen způsob průběhu procesu v novém informačním systému. Zároveň může dojít k situaci, kdy začnou být novým informačním systémem podporovány i procesy, které dosavadní informační systémy nepokrývaly, protože je to nutné pro běh komplexního ERP systému. Konzultanti dodavatele a znalci procesů zákazníka spolu strávili řadu dní a vypili spoustu kávy, než vznikl výstupní dokument návrhu řešení, který přesně popisuje způsob, jakým budou firemní procesy v novém informačním systému obslouženy a zpracovány.
• Vývoj a testování - v průběhu této fáze realizuje dodavatel zákaznické úpravy a vytváří tak jedinečnou zákaznickou verzi ERP systému. Zákaznické úpravy se postupně distribuují zákazníkovi, který provádí testování a svoje poznatky přenáší zpět na dodavatele.
• Nasazení - vývoj a testování zákaznických úprav jsou dokončeny, systém se finálně parametrizuje a obvykle je prováděn úplný test funkcionality (simulace průběhu všech procesů v ERP systému).
• Dohledový provoz - po ostrém spuštění nového informačního systému poskytuje dodavatel po určitou dobu nepřetržitou podporu zákazníkovi, to znamená, že konzultanti dodavatele jsou k dispozici (e-mail, telefon), nebo jsou osobně přítomni přímo u zákazníka a pomáhají řešit problémy vzniklé při startu systému.

V průběhu výše uvedených fází je vhodné zaměřit se, kromě jiného, zejména na následující aspekty.

Komplexnost nového systému

Jedním ze základních předpokladů úspěšného nasazení nového ERP systému je nutnost překonat bariéry vybudované několika lokálními systémy. Správci i konzumenti těchto systémů byli zvyklí, že si svoje lokální aplikace řídí, nastavují a naplňují daty sami a nikdo další jim do toho nezasahuje. Komplexní systém pracuje napříč celou firmou a uživatelé jednoho modulu často využívají číselníky a nastavení z jiných modulů, takže musí důvěřovat cizímu nastavení. Například číselník dodavatelů vzniká v nákupu kvůli vytváření nákupních objednávek, ale zároveň podle něj bude účtárna fakturovat. Tento přístup vyžaduje nové myšlení (trochu zprofanovaný pojem pro nás starší) a zároveň mnohem větší pečlivost a zodpovědnost vůči ostatním uživatelům ERP systému, protože informace podstatné pro nákup nemusí být až tak důležité pro účtárnu a naopak. Firma musí začít fungovat mnohem víc jako celek a odstranit způsob práce nazývaný „over the wall".

Zákaznické úpravy aneb kam až zajít

Zákaznické úpravy jsou hamletovskou otázkou každé implementace, přeprogramovat či nepřeprogramovat? Zodpovězení této otázky musí předcházet důkladná analýza procesu (viz předešlý odstavec) a hledání ekvivalentních funkcí v novém systému. Vyplatí se hledat důkladně a právě v tomto okamžiku se projeví kvalita konzultantů dodavatele. Dobrý konzultant často dokáže najít ve standardní funkcionalitě řešení, které nahradí spoustu programování. Cílem by vždy mělo být maximální využití standardu ERP systému a zabudovaných „best practices". Na druhou stranu může dojít k situaci, kdy je přeprogramování nezbytné. Základním vodítkem bývá změna procesu. Pokud by byl vlastní proces standardní funkcí závažně narušen, je vhodné provést zákaznickou úpravu. Z hlediska struktury změn je vhodné vytvářet programové úpravy spíše paralelní a pokud možno nezávislé na standardní funkcí. Je například výhodné vytvořit speciální tabulkovou strukturu i vstupní formulář, ale pak získaná data přenášet do standardních struktur na základě aplikační logiky a tím standard vlastně nenarušit. Tento postup se vyplatí i v případě přechodu na vyšší verze ERP systému.

Reporting

Častými zákaznickými požadavky na úpravy jsou tiskové sestavy, reporty a reporting obecně. Data v informačním systému jsou vlastnictvím zákazníka a ten by měl mít možnost s nimi libovolně nakládat, vytěžovat je a prezentovat. V moderních informačních systémech jsou nástroje pro BI a reporting integrované a je efektivnější, když zákazník drží reporting ve svých rukou, než když musí kvůli každé sestavě kontaktovat dodavatele, kterému je nucen navíc poměrně pracně vysvětlit, jak má report nebo tisková sestava vypadat. Záleží také na velikosti organizace. Někde složité sestavy programuje dodavatel a jednoduché reporty si zákazník vytváří sám, zcela v duchu zásady, že lepší než někomu dát rybu, je lepší naučit ho ryby chytat.

Metodika řízení projektu

Projektoví puristé asi nebudou s následujícím odstavcem souhlasit, ale v praxi se často osvědčuje přístup, že pokud projekt a jeho činnosti běží, je někdy lepší ponechat striktní metodické postupy na vedlejší koleji. Tento postoj je alegorií k doporučení, že pokud se cítíte zdraví, je lepší nechodit raději ani na preventivní prohlídky, protože pocit vlastního zdraví je nejdůležitější. Je nutné aby normálně fungovaly základní projektové nástroje kterými jsou pravidelné porady vedení projektu, zápisy ze schůzek, definice konkrétních úkolů a zodpovědností a zejména včasná identifikace rizik. Fungující komunikace je dalším nezbytným předpokladem.

Řízení projektu

Projektový tým se standardně skládá ze zástupců zákazníka a dodavatele. Jednou z nejdůležitějších věcí je rovnoměrné rozložení sil - vyvážené počty členů, nevytváření převahy ani na jedné straně a neprosazování silových řešení. Obě složky projektového týmu sledují totožný cíl, takže optimální strategií je win-win. Důležitý je rovněž vztah mezi oběma vedoucími projektu zákazníka a dodavatele. Rovněž ten by měl být vyvážený se vzájemným respektem a pochopením protistrany. I nepříjemné věci se dají sdělit bez emocí a ultimat. Určitě se vyplatí zavázat si druhou stranu v duchu ... netlačím na termíny, nebo ... najdu prostor v kapacitách pro případné vícepráce. Je dobré uvědomit si i rozdělení rolí členů projektového týmu dodavatele. Někteří dodavatelé preferují řízení projektu silným vedoucím projektu, který ve své osobě soustřeďuje všechny kompetence, jinde funguje více vertikální členění, kde je nutné jednat s jednotlivými členy v rámci jejich specializací (obchodník, konzultant, vedoucí projektu, techničtí specialisté). V každém případě je vždy základním předpokladem otevřená komunikace mezi všemi zájmovými skupinami projektu (management zákazníka, IT specialisté zákazníka, uživatelé ERP systému, dodavatel ERP systému).

Příště ostrý start a rekapitulace projektu

Ve chvíli vzniku tohoto článku se náš poloanonymní projekt nachází v závěrečné fázi, ostrý start nebyl odložen a je naplánován na 1.1.2016. Jak dopadl? To se dozvíme v dalším pokračování našeho miniseriálu, které jenaplánováno do březnového vydání IT Systems 3/2016.

Jiří Löffelmann