Kritická místa a předpoklady úspěchu ERP projektu.

V současné době už asi nikdo nemůže zpochybňovat názor, že implementace ERP systému je velmi složitý a náročný projekt. Obvykle je tato složitost a sofistikovanost vnímána v souvislosti s technicko-odbornou stránkou projektu – hardware, software, modelovací nástroje, implementační metodiky atd. Na ERP projekt je ale možné pohlížet i prizmatem interakce a komunikace mezi jeho jednotlivými účastníky. Právě tato oblast může být zdrojem kritických momentů projektu a rovněž zde můžeme hledat základní předpoklady konečného úspěchu.

Pokud standardní ERP projekt zobecníme, zjistíme, že se na něm téměř vždy podílí klíčovým způsobem čtyři účastnické skupiny:

  • management zákazníka (subjektu, ve kterém projekt ERP probíhá),
  • IT specialisté zákazníka,
  • uživatelé ERP systému,
  • dodavatel ERP systému.

Mezi těmito čtyřmi skupinami vznikají vzájemné vazby a vztahy, které pak mají zásadní vliv na celý projekt. V následujícím textu naznačím možné neuralgické body mezi uvedenými skupinami i způsoby, jak tyto problémy řešit, či ještě lépe, jak jim předcházet.

Management versus IT specialisté

Možná rizika

Vztah managementu a IT specialistů patří mezi klíčové. Důležitým faktorem je, kdo přebírá roli hlavního iniciátora celého projektu. Je to management, který rozhodl na základě vlastních, obvykle ne-IT záměrů, nebo je to interní IT oddělení, jehož důvodem bývá obvykle technologická inovace ERP systému? Rozhodujícím činitelem je samozřejmě vždy management, který toto strategické rozhodnutí schválí a vyčlení na něj prostředky, nicméně role hybatele celého projektu je zásadní. V tomto okamžiku se mohou objevit dlouhodobě skrývané rozpory mezi oběma skupinami, které při dosavadním rutinním provozu zůstávají ukryté pod povrchem. IT specialisté často považují manažery za nekompetentní ignoranty se zásadní neznalostí IT problematiky, z čehož pak pramení jejich chybná rozhodnutí. Manažeři jsou zase často rozčarováni z nekomunikativních, technických potížistů, kteří často eskalují na první pohled zbytečné a samoúčelné problémy. IT oddělení je pak bráno jako nutné zlo, které je nutné přetrpět, protože bez IT to prostě nejde. Pokud před zahájením ERP projektu vládnou mezi managementem a interním IT oddělením výše popsané vztahy, je celý projekt ve vážném ohrožení. Celá situace pak může vyústit i řadou více či méně vynucených odchodů z řad IT specialistů.

Řešení

Obě skupiny by měly přistoupit na vzájemné uznání svých rolí a založit komunikaci na oboustranném respektu a důvěře. IT specialisté musí připustit, že manažeři jsou ti, kteří mají zodpovědnost a dělají rozhodnutí (jsou „decision makers“), a tudíž musí mít často na zřeteli i jiné než IT priority, což nutně vede ke kompromisním řešením. Manažeři by zase měli vzít v úvahu, že IT specialisté jsou experty ve svém oboru (z tohoto důvodu je manažeři zaměstnávají) a že některé z jejich připomínek mohou být skutečně věcné.

Management versus uživatelé ERP systému

Možná rizika

Na začátku projektu obvykle management i klíčoví uživatelé chápou, že ERP projekt přinese více práce pro všechny zúčastněné. Klíčoví uživatelé jsou ti, kteří vznášejí požadavky na funkcionalitu ERP systému, testují ho, konzultují problémy a implementují ho do firmy. To vše vyžaduje spoustu času, který dříve věnovali vlastním odborným činnostem. Nezřídka jsou v těchto činnostech nenahraditelní (jsou přece klíčoví). Pokud dochází k situacím, kdy je nutné volit mezi vlastní prací a prací na ERP projektu, je to obvykle management, který rozhoduje o prioritách. Pokud dostane vždy přednost operativa, je to pro ERP projekt špatná zpráva, protože je tím de facto degradován na cosi druhořadého, co musí počkat.

Řešení

Jsou jistě situace, kdy se klíčoví uživatelé (obchodní zástupce, hlavní účetní, vedoucí výrobního provozu, konstrukční specialista) musí věnovat své vlastní práci. Nemělo by to však být pravidlem a vymezení této hranice je základním úkolem managementu. Právě zde je možné zřetelně deklarovat podporu projektu. Některé povinnosti klíčových uživatelů je jistě možné vhodně delegovat a možná, že vedlejším efektem ERP projektu bude zjištění, že vedle klíčového pracovníka existují další „téměř klíčoví“.

11-loffelman-02

Management versus dodavatel

Možná rizika

Tento vztah je na první pohled typickým vztahem mezi zákazníkem a dodavatelem. Jeho riziko je v tom, že zástupci dodavatele velmi zřetelně vnímají, že management je ten, který o celém ERP projektu (a tedy i o průběžné a závěrečné fakturaci) rozhoduje. V logické snaze „nepřijít o kšeft“ mohou managementu dávat i ne zcela reálné sliby ohledně funkcionality, termínů a ceny. Stejně tak mohou, byť nepřímo, poukázat na možnou nekompetentnost interního IT oddělení. Pokud management této manipulaci podlehne a začne dodavateli dávat zřetelnou přednost před vlastními IT specialisty, zhorší samozřejmě svůj vztah k nim, a navíc vyvolá i averzi mezi dodavatelem a vlastním IT oddělením. Zažil jsem situaci, kdy manažer ve snaze o co nejlepší řešení „přetáhl“ krátce po začátku ERP projektu konzultanta dodavatele a jmenoval ho vedoucím projektu. Součástí dohody byl mnohem vyšší plat, než měli interní IT specialisté a řada dalších výhod. Projekt samozřejmě po krátkém čase skončil totálním fiaskem pro všechny zúčastněné strany.

Řešení

Management by měl v těchto situacích v zásadě vždy podporovat svoje zaměstnance. Pokud má výhrady či pochybnosti, je možné řešit je mezi čtyřma očima a neudělovat svým lidem lekce před dodavatelem. Zástupce dodavatele by měl mít na paměti, že ve finále bude muset projekt absolvovat spolu s pracovníky interního IT oddělení, a nikoliv s generálními či odbornými řediteli. Obcházení svých přirozených partnerů, či dokonce zpochybňování jejich schopností se mu ve výsledku vždy vymstí.

IT specialisté versus uživatelé

Možná rizika

Tento vztah je klíčový pro správné fungování celého ERP systému. Nový produkt přináší pochopitelně řadu změn, s nimi spojená uživatelská školení a tím i více práce a zatížení pro koncové uživatele. IT specialisté by proto měli „překousnout“ trochu toho stěžování a už téměř kultovní větu že „starý systém fungoval mnohem lépe“. Na druhou stranu musí koncoví uživatelé pochopit, že IT specialisté jim nekomplikují život schválně a svévolně, že nová věc v začátcích vždy vyžaduje zvýšené úsilí a že tenhle příšerný nový systém se po čase pravděpodobně stane „tím starým systémem, který fungoval o mnoho lépe“.

Řešení

Velkou výhodou je, pokud IT specialisté dobře znají problematiku koncových uživatelů, protože pak je jejich podpora při implementaci nové funkcionality skutečně účinná. Pokud má koncový uživatel pocit, že IT expert je jen teoretik, který nemá ani ponětí o tom, jak věci reálně fungují, je spolupráce těžká. Mám osobní zkušenost se situací, kdy jsem několik let vyvíjel a programoval řešení pro plánování výroby. Některé uživatelské připomínky jsem nebral vážně a odbýval je jako nepodstatné. Když jsem se pak shodou okolností stal vedoucím plánovacího oddělení a začal svůj program používat k práci, rychle mi došlo, jak významně některé na první pohled nedůležité požadavky usnadňují rutinní činnosti s tímto programem. Dnes opět pracuji na straně IT, ale když se přijdu domluvit do plánování výroby, berou mě jako odborného partnera, a nikoliv jako „v praxi nepoužitelného IT všeználka“.

IT specialisté versus dodavatel

Možná rizika

Klíčový význam tohoto vztahu byl naznačen již v předešlých odstavcích. Na interních IT specialistech a zástupcích dodavatele leží největší část zodpovědnosti i práce z celého ERP projektu. Bude-li mezi nimi panovat nevůle a řevnivost, na výsledku projektu se to vždy projeví. Doporučuji těm prvním neposuzovat konzultanty dodavatele apriori jako okvádrované frajírky z Prahy a těm druhým nepřistupovat k internímu IT oddělení jako k druhořadým informatikům, kteří nevědí nic o světě velkých projektů.

Řešení

Z výše popsaných důvodů by vzájemné vztahy mezi těmito dvěma skupinami měly být maximálně vyvážené a profesionální. Obě strany jsou partnery. Není nutné chodit každý den po práci společně na pivo, ale respekt a korektní jednání jsou nezbytná. Osobně jsem řídil řadu projektů, které byly v drtivé většině úspěšné. S většinou zástupců dodavatelů se znám dlouhá léta a strávil jsem s těmito lidmi řadu pracovních dní, s některými i nocí. Přesto si se všemi stále vykám.

Uživatelé versus dodavatel

Zde platí obdobná pravidla jako mezi IT specialisty a uživateli. Někdy k jejich přímému kontaktu ani nedojde, a to v případě, že veškeré konzultace a školení převezme interní IT oddělení. Pokud se tyto dvě skupiny přece jen setkají, měl by si dobrý konzultant dodavatele najít čas i na to, aby si trpělivě vyslechl připomínky koncových uživatelů. Připouštím, že je to někdy únavné, ale vyplatí se to. Je-li to navíc skutečně dobrý konzultant, může často pomoci vyřešit vyslechnutý problém znalostí řešení z jiného prostředí či projektu.

Závěr

Všechny skupiny participující na ERP projektu usilují o stejný výsledek – manažeři o návratnou investici a kvalitní nástroj na podporu rozhodování, dodavatel o splněné zadání a úspěšnou referenci, IT specialisté o zdárné završení dlouhodobého úsilí a uživatelé o kvalitní informační systém na podporu svých činností. Tento společný cíl by měli mít na paměti i při všech úskalích, které je v průběhu projektu potkají.

Jiří Löffelmann