Odhalení pravdy o výběru ERP řešení: Úspěch implementace na tom až tak nestojí.
08.02.2021Za posledních 12 let jsem prošel mnoha implementacemi ERP řešení a viděl jak úspěšné transformace, tak totální katastrofy.
Mnoho uvedených katastrof spojuje několik společných faktorů. Jedním z nich je výrazné komplikování a prodlužování výběru vhodného řešení.
Nemálo zúčastněných resp. „stakeholderů“ často proces výběru ERP řešení přeceňuje, na úkor chybějících jasných transformačních cílů a směřování. Nezřídka interní příprava požadavků, tanečky kolem různých řešení, dema, posuzování, kalkulace, vyjednávání či tendrování trvá 6 měsíců až rok, někdy i více. Navíc s mizernou dynamikou, absencí plně dedikovaného týmu a často s nejasnou vizí.
Přílišná pozornost na výběr ERP jde často na úkor chybějícího promyšleného TO BE datového modelu a procesního fungování a cílových změn oproti současnému AS IS stavu. Dále i nedostatečné interní analýzy a plánování zajištění kapacit nebo odsouhlasení cílové podnikové aplikační architektury.
Jak k výběru ERP tedy přistoupit?
Fáze výběru ERP se mnohdy až moc přeceňuje. A přitom to vše nemusí být tak komplikované.
Komplexnější mezinárodní společnosti obvykle příliš nehledají řešení nad rámec SAP S/4HANA, Microsoft Dynamics 365, Oracle Cloud nebo, pokud jde o sofistikované výrobní firmy, třeba i řešení od Infor, např. ERP LN. Seznam se dále zužuje na základě odvětví, dostupnosti implementačních partnerů a referencí ohledně podpory či veřejně dostupný znalostních fór. Nad rámec toho většinou nemá velkou hodnotu zkoumat více. A mnohdy na to interně ani není apetit.
Malé a střední společnosti mají v zásadě větší flexibilitu ve výběru menších ERP řešení, kterých je na trhu značné množství. Tyto firmy také často nejsou zatížené složitou fragmentovanou infrastrukturou různých firemních aplikací. Smysl má pak vybírat především z řešení, která co nejlépe vyhovují danému odvětví, či konkrétním firemním potřebám.
Odlišnost pak představují společnosti, které historicky vyrostly s vlastním organicky interně vyvíjeným podnikovým řešením, které od zajištění provozu core byznysu postupně přerostlo na vysoce komplexní aplikační systém, který v určitý moment začne dosahovat astronomických nákladů na provoz a svých limitů z hlediska udržitelnosti. Firmy pak stojí před rozhodnutím, co z hlediska funkčnosti je pro byznys kritické a musí v této aplikaci zůstat, a naopak co lze „migrovat“ do standardního ERP řešení a vytvořit tak novou modernější, levnější a udržitelnou provázanou architekturu.
Ať spadáte do jakékoli kategorie, samotný výběr ERP řešení by se neměl komplikovat a zbytečně protahovat.
Mým cílem zde je vám dát praktické vodítko, jak být na výběr ERP a vyjednávání s dodavatelem kvalitně připraven, a tím tak dosáhnout snížení časové i finanční zátěže. Pojďme si jej tedy shrnout.
1. Cílová podniková aplikační infrastruktura musí být naprosto jasná a v souladu s byznys vizí
Najděte společné slovo s IT jako klíčovým partnerem a formulujte cílovou páteřní firemní TO BE aplikační architekturu. Ta nezachází do technikálií, ale podává jasný a vizuální pohled na to, co za funkční oblasti bude právě nové ERP řešit a kde jsou očekávané návaznosti na jiné aplikace, a tedy potenciální komplikace nebo přinejmenším body pro pečlivější posouzení a rozplánování.
Kromě toho byste měli určit, které procesy by měly být standardizovány na základě funkčnosti ERP, a naopak které jsou konkurenčními odlišnostmi, které budou vyžadovat „customizace“ anebo budou spravovány např. mimo ERP.
Tato cílová architektura by měla být klíčovými lidmi z firmy (pozor: ne konzultanty) i sponzorem projektu schválena a pochopena. Bez ní jakýkoli detailnější pokus o výběr konkrétního ERP je ruskou roletou, jak pro vás interně, tak pro potenciálního dodavatele ERP.
2. Data model, primární či sekundární okruh, jedno vs. multi-měnová funkcionalita, globální vs. lokalizovaný design.
Investujte čas před samotným posouzením konkrétních ERP řešení do definování konkrétnější podoby budoucího TO BE data modelu, tedy multidimenzionální struktury finančních a provozních metadat. Ta formalizuje budoucí procesní a transakční strukturu v ERP do kombinací účtů a kritických byznys elementů a atributů, resp. dimenzí, jako typ entit, profit center či cost center, business partnerů, projektů, nákupních komodit, kategorizace produktů a služeb atd.
Současně učiňte včas kvalifikované rozhodnutí o tom, zda dáte přednost „globálnímu“ jednotnému designu ERP vč. modulu financí nebo na to půjdete s důrazem na lokalizace a primární uspokojení lokálních statutárních potřeb.
To indikuje základní očekávání od ERP, jak bude s byznys procesy pracováno a jaké jsou základní potřeby a očekávání pro řízení procesů, management reporting či správu a administraci řešení.
Absence vize v těchto oblastech obvykle způsobuje výraznější znevážení validity jinak precizně posuzovaných procesních a funkčních požadavků při výběru ERP.
3. Požadavky na posouzení vhodnosti ERP formulujte přístupem Top-Down ve formě klíčových „Use Cases“.
Nezkušení konzultanti nebo interní uživatelé jsou proslulí generováním vyšších stovek požadavků, na kterých vlastně nezáleží nebo nemají výraznou přidanou hodnotu. Většinu těchto dílčích požadavků řeší téměř každé ERP na trhu, a navíc je nelze smysluplně považovat za výrazný hodnotící prvek pro posouzení daného ERP. Většina zúčastněných, jak těch interních, tak i na straně dodavatele, je pak totálně paralyzována detaily, které nejde uchopit do ucelenějších byznys zadání, tedy „Use Case“.
„Use Case“ představuje konkrétní byznysové očekávané využití systému konkrétním uživatelem s jasně pojmenovaným důvodem, co touto aktivitou uživatel dosáhne. Ty představují kvalitní hodnotící prvek v rámci posuzování ERP vhodnosti.
Doporučuji limitovat na cca 100 až 150 klíčových zadání, zaměřených z větší části na váš „core byznys“, a zajištění, aby navzájem nebyly konfliktní a poskytovaly jasnou vizi a konkrétní využití.
4. Zaměřte se na výrazné zlepšení řízení firemních procesů a přidanou hodnotu.
Místo sepisování současných praktik a dílčích požadavků“, typicky mající tendenci spíše replikovat stávající stav v novém ERP, se zaměřte na největší mezery a příležitosti, jak inovovat svoje interní procesy a kde jsou současné limitace ovlivňující zákazníka, provozní a finanční nákladovost, neefektivitu apod. Chce to hodně vizionářství, nadhled a zkušeností, možná i odvahy, ale jsou to právě budoucí provozní a obchodní procesy, které byste měli posuzovat z pohledu vhodnosti ERP, nikoli současný stav.
Tento budoucí stav vám nejen pomůže určit, který z vašich kandidátů na ERP řešení je nejvhodnější, ale také vám pomůže identifikovat vylepšení, která můžete začít implementovat hned – ještě předtím, než si vůbec nový systém ERP vyberete.
To velice často vyžaduje vhled externích expertů, kritických pro odfiltrování nedůležitých požadavků, a především pro definování TO BE stavu, nezatíženého přílišným detailem, tradiční interní slepotou a mnoha dalšími motivacemi zevnitř.
Buďte připraveni změnit způsob, jakým dnes děláte věci, a zkuste se přizpůsobit řešením procesů, které nabízí vybrané ERP. Především v oblastech, které nejsou vašim „core byznysem“.
5. Raději investujete více času a peněz do úspěšné implementace.
Každá společnost má omezený čas, peníze i další zdroje. Každá koruna a hodina vynaložená na vyhodnocování a výběr ERP jsou peníze a čas, které lze vynaložit na úspěšnou implementaci. Rád říkám, raději bych měl nedokonalý výběr ERP se skvělou implementací než skvělý výběr řešení s mizernou implementací.
Možná k překvapení někoho dodám, že alfa a omega toho, zda celkový projekt dopadne dobře, leží hlavně na důkladném a dobře promyšleném způsobu, jak daný ERP nástroj fakticky reálně využijete. Dále na sladění TO BE potřeb klíčových hráčů, vizionářství a síle vesměs malého množství skutečných interních projektových tahounů a jejich vztahu se sponzorem, a především pečlivě promyšlené a postavené procesní a funkční TO BE architektuře.
Vybere-li 10 větších výrobních firem stejného odvětví stejné ERP řešení, např. Dynamics 365, vždy bude 10 nezřídka i velice odlišných výsledků.
6. ERP není IT projekt. Použité technologie ale pečlivě posuďte.
Posouzení ERP technologické platformy, použitých technologií, škálovatelnost, implementační modely nebo důkladné pochopení produktové roadmapy výrobce ERP a očekávaného budoucího životního cyklu a podpory daného konkrétního řešení, to vše by mělo být zahrnuto do procesu výběru ERP jako kritická součást.
Přestože ERP implementace není primárně IT projektem, IT oddělení je naprosto kritickým partnerem pro výběr a samotnou realizaci.
7. Celkové náklady na správu řešení pro preferovaný implementační model.
Ano, je třeba to celé dobře spočítat. Skutečné náklady (TCO) se skládají z licenčních poplatků, které závisí na počtu uživatelů a někdy i vyjednaných slevách, vybraných modulech, hostování nebo hardwaru, implementačních nákladech, údržbě, školení či modelové podpoře ERP ze strany dodavatele (SLA).
TCO lze smysluplně posuzovat jen ve vazbě na zvolený implementační model, tedy např. externí cloud, vlastní cloud, on-premise apod. Nad rámec toho, je nutné pracovat i se zohledněním ne vždy snadno identifikovatelných nákladů, nebo naopak úspor oproti AS IS stavu. Je rozumné určit hrubý odhad návratnosti investic před podepsáním jakéhokoli druhu smlouvy.
Nenatahujte výběr ERP. Vrhněte se do implementace s dynamikou, nikoli s vyhořením.
Co dodat závěrem? Lidská energie, nadšení a dynamika kroků v rámci těchto projektů je strašně ošidná věc. Je extrémně důležité tuto trakci v rámci „core“ týmu vč. vazby na lidi dodavatele mít a udržovat ji. Je strašně těžké tuto dynamiku obnovovat, pokud dojde k jejímu výraznému narušení.
Proces výběru ERP, který trvá příliš dlouho a jehož dílčí kroky se některými zbytečně komplikují či naopak prokrastinují, vytváří mezi členy projektového týmu, sponzorem a vedoucími pracovníky skepticismus, nejistotu, rozbroje a syndrom vyhoření. Jako sponzor nedopusťte, aby váš klíčový tým vyčerpal svoji energii už na fázi výběru softwaru. A vrhal se pak do samotné implementace již vyhořen a bez patřičné dynamiky.
Jsem někdy ohromen tím, kolik projektů ztratí na síle, než vůbec samotná implementace začne.
Martin Prášek David Štěpán
martin@simplebeez.com david@simplebeez.com
mob. 602 166 975 mob. 602 496 585