facebook LinkedIN LinkedIN - follow
IT SYSTEMS 5/2016 , ERP systémy

Implementace ERP systému a řízení souvisejících změn



UnicornZměna je život. Toto konstatování nemusí nutně znamenat, že to, co se nemění, je mrtvé. Zcela bez pochyb je možné najít věci nebo postupy, které se nemění a stále jsou dobré – například níže popsaný postup implementace ERP, který není jediný možný, ale je ověřený a funkční. Zároveň se asi shodneme, že ne každá změna znamená něco lepšího, pozitivního. V následujících odstavcích vás provedu svým pohledem na změnu v kontextu ERP systémů a jejich implementace.


Existence ERP systémů je z mého pohledu důsledek přirozené evoluce a přechodu od tužky a papíru k PC a informačnímu systému. Tato změna vedla mnohdy k vyšší efektivitě ve výrobě, zvýšení množství prodaných výrobků či případně k dalším optimalizacím nebo k otevření nových možností v oblasti řízení podniku jako celku. Dnes, stejně jako kdysi naši předchůdci v dobách průmyslové revoluce, stojíme před milníkem, který se pomalu, ale jistě, dostává do popředí a kterým je Průmysl 4.0. Internet věcí hýbe nejen médii, nýbrž je i často probíraným tématem z pohledu IT profesionálů a výrobních či obchodních podniků. Ať už je tedy potřeba změny vnitřní (ze strany podniku), nebo vnější (ze strany trhu), je nutné vyhodnotit, jak na ni budeme reagovat.

Implementace ERP

Pokud podnik vyhodnotí, že potřebuje na změnu zareagovat, znamená to, že bude provádět úpravu či rozšíření svého stávajícího ERP systému, nebo může dojít k závěru, že je stávající ERP systém nedostačující a rozhodne se pro jeho náhradu novější verzí nebo jiným informačním systémem. Z pohledu implementace ERP systému nastává omezená řada situací:

  • podnik nemá informační systém ERP a rozhodne se pro jeho zavedení,
  • podnik má informační systém ERP a rozhodne se pro přechod na novou verzi,
  • podnik má informační systém ERP a rozhodne se přejít na jiný.
Unicorn schema

Pokud se na výše zmíněné situace podíváme čistě metodicky, jedná se o situace totožné. Podnik „něco“ má a „k něčemu“ se chce dostat. Proběhne tedy změna, resp. sled změn, které nastávají typicky v ICT infrastruktuře a architektuře, procesech v podniku nebo v organizační struktuře. V každém případě je nutné naplánovat a provést sérii kroků takovým způsobem, který zajistí korektní odřízení všech změn nutných pro přechod do cílového stavu:

  • Diagnóza současného stavu přichází na řadu jako první krok. Metodiky tuto fázi mohou nazývat různě, ale její obsah se nemění. Nejprve je nutné zhodnotit stávající stav podniku, zrevidovat popis procesů (případně vytvořit popis procesů), definovat požadavky na cílový stav a sestavit plán a rozpočet projektu. Ano, projektu. Pokud máme změnu řídit, je potřeba k této aktivitě přistoupit jako k projektu.
     
  • Analýza požadavků je logickým pokračováním předchozí fáze. Dochází ke „střetu“ stávajícího stavu a budoucího stavu z pohledu podniku, z pohledu organizační struktury se potkají odběratel (byznys) a dodavatel (IT) nad detailní specifikací požadavků. Cílem je, aby si všichni rozuměli v očekávání budoucího stavu, začali mluvit stejným jazykem a chápali stejně význam požadavků. V tomto kroku je opět vhodné zrevidovat a zpřesnit rozpočet, časový harmonogram, a tím lépe řídit probíhající změnu a očekávání všech zúčastněných.
     
  • Návrh řešení přímo navazuje na krok analýzy požadavků, dokonce jsou tyto dva kroky mnohdy spojeny do jednoho, a to s cílem ušetřit čas. Je však potřebné si uvědomit, že spojením nemizí ani jeden z nich. V tomto kroku již detailně známe požadavky, máme je popsané a je možné si domyslet, jak budou v cílovém stavu řešeny. Nová verze, nový systém, je to jedno. V různých ohledech se bude chovat trochu či více jinak, a je tedy nutné navrhnout, jak budou požadavky v novém systému obslouženy, vymyslet a popsat, jak budou technicky řešeny funkčnosti systému. Dále je nutné vymyslet, jaká data budeme migrovat, jak budeme tato data migrovat, jak budeme nový systém zavádět, jakým způsobem bude ověřena jeho provozuschopnost. A opět je dobrým zvykem zrevidovat rozpočet a plán, eliminujeme tím některá rizika.
     
  • Pokud jsme vše vymysleli, a víme tedy, co a jak budeme vyrábět, zahájíme „výrobní fázi“ – Vývoj a testování. Nepředpokládám, že se dnes najde někdo, kdo by vyvíjel ERP řešení „na zelené louce“. Fáze vývoj a testování si klade za cíl dodat do implementovaného řešení funkčnosti a úpravy, které nejdou jednoduše a standardní cestou v systému nastavit, tedy specifické požadavky podniku, bez kterých nelze provozovat byznys. Ze zkušenosti doporučuji věnovat více času volbě vhodného řešení než následně vyvíjet velké množství programových úprav do řešení ne zcela vhodného. Zhoršuje to udržitelnost systému a komplikuje budoucí rozvoj. Když se programuje, je potřeba testovat. Dodavatel i zákazník musí věnovat čas ověření programovaných funkčností. A asi byste to nečekali, ale opět doporučuji zrevidovat rozpočet a plán.
     
  • Nasazení je krok, ve kterém máme vyvinuté změny, přistoupíme k nastavení dodávaného systému, vyzkoušíme zmigrovat data dle plánu vytvořeného v návrhu řešení, zrevidujeme způsob nasazení. Klíčový je tento krok z pohledu uživatelů systému, protože je začneme školit, detailně seznamovat s plány, novým systémem a intenzivně je začneme připravovat na změnu. Není to tak, že bychom do té doby s uživateli nekomunikovali, ale v této fázi přijde jejich čas.

Přechod do provozu a stabilizace je nezbytnou a často podceňovanou součástí každé implementace ERP systému (a nejen ERP). I kdyby se sešli top experti na všech zúčastněných stranách, není možné eliminovat všechna rizika a zajistit, že nenastanou chyby, problémy či drobné potíže. Je nutné si uvědomit, že řídíme změnu a přecházíme s podnikem do nového nepoznaného stavu.

Řízení změn

Velkou i malou změnu je potřeba korigovat. Malé změny stačí komunikovat na poradě, velké změny, jako je například implementace ERP systému, je nutné řídit. Nenabídnu vám kompletní výčet nástrojů a mechanismů, pouze ty důležité.

Plán je základ

Naplánovat reakci na změnu a kroky vedoucí k úspěšnému provedení změny je nutné. A plánovat je z mého pohledu potřeba především:

  • úkoly, které vyplývají pro podnik ze změny,
  • komunikaci o změně, komunikaci o dopadech změny a reakci na změnu,
  • řízení rizik, abychom byli připraveni, že můžeme riziko objevit.

Proces řízení změn

Obecně platí, že změnu je nutné identifikovat, vyhodnotit dopady, naplánovat reakci, provést reakci a vyhodnotit výsledek. Je to proces obecný, ale naprosto platný. Řízení tohoto procesu musí být transparentní pro všechny zainteresované strany tak, aby byl předem definovaný a pochopený, aby byl do maximální možné míry jednoduchý.

Zainteresovaný management a interní marketing

Management podniku plně zainteresovaný do průběhu implementace a interní marketing prováděných změn jsou dvě další doporučení. Lídři v podniku, kteří dobře komunikují o změně, o jejích dopadech, o budoucnosti, to je osvědčený nástroj, který pomáhá úspěšně řídit reakci na změnu. A v neposlední řadě přiznání si, že změna není sprosté slovo, že může být pozitivní, že je potřeba ji řídit. To je podle mne nutné.

Unicorn schema


Když to nejde podle plánu

Přesto, že je to v zásadě jasné a popsané, objeví se situace, kdy vše neběží zcela podle plánu. Jsme jenom lidé, zavádíme změnu v podniku nebo na ni reagujeme, a jeho chod se nezastaví, prostě pořád pokračuje v každodenním byznysu. V praxi, když se implementují ERP systémy, nastávají často následující problémy:

  • „Udělejte to stejně, jako to máme teď.“ – v podstatě situace, kdy byznys změnu odmítá, ale zároveň nechce popsat nebo definovat, jaký proces aktuálně provozuje. Univerzální řešení neexistuje, vyplácí se zlepšit komunikaci, posílit tým takovým způsobem, aby byl schopen správně definovat požadavky na budoucí stav. Nově zaváděný systém může některé procesy podporovat jinak a lépe.
  • „Proč bychom to testovali, vždyť vy jste přece odborníci.“ – stává se, že se byznys snaží zbavit odpovědnosti za společnou práci na navrženém a implementovaném řešení. V této situaci je potřeba se zastavit, zapojit management, vysvětlit si účel jednotlivých kroků. Jistě, že ERP systém dodávají odborníci, ale největším odborníkem na procesy podniku jsou právě zástupci byznys oddělení. Proto musí být zapojeni a pracovat společně s odborníky na ERP.
  • „Vy nám ty data nevyčistíte?“ – je situace, kdy se byznys diví, že dodavatel nechce čistit data podniku. A dodavatel toto dělat nemůže, protože to nejsou jeho data a nezná jejich specifika, která byznys sbíral někdy i dlouhá léta. Byznys data čistí, dodavatel je migruje, byznys si ověří správnost migrace. To je správný scénář.
  • „Změna? No to tu vůbec neříkejte.“ – změna je přirozená, změny se dějí a je potřeba to byznysu pořád opakovat. Nastavit si proces řízení změn, odsouhlasit, komunikovat a dodržovat ho.
Zbyněk Šlosar Zbyněk Šlosar
Autor článku je ředitelem produkční divize společnosti Unicorn odpovědný mimo jiné za realizaci projektů implementace systémů ERP, CRM, e-commerce, SharePoint apod. Má také zkušenosti v oblastech Business architektury a funkční analýzy. Školí projektové řízení, vystupuje na konferencích a působí v Komoře projektových manažerů.
Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.