Spuštění ERP systému, doporučení pro vedoucího ERP projektu

V loňském roce jsme ve dvou předchozích dílech vydaných v říjnovém a prosincovém vydání časopisu IT Systems popsali jednu reálnou implementaci ERP systému od samotného prvopočátku, tedy od úvodního záměru a následné přípravy implementace komplexního ERP systému ve středně velké firmě se strojírenskou zakázkovou výrobou. Nyní, ve třetím pokračováním této minisérie se dostáváme k vlastnímu spuštění ERP systému a následnému uvedení do rutinního provozu.

Termín a způsob spuštění

Spuštění nového informačního systému bylo naplánováno na začátek roku 2016, respektive na pondělí 4. 1. 2016. Start na začátku kalendářního roku má řadu výhod i některé nevýhody. Pozitivem je ucelený průběh kompletního kalendářního roku v jednom informačním systému, což je výhodné zejména z účetního hlediska. Nevýhodou Nového roku je předem dlouhodobě známé datum spuštění, kdy projekt může být pod termínovým tlakem spuštěn jako ne zcela připravený. Dochází i k opačným situacím, kdy je celý projekt z důvodu nepřipravenosti posunut, což pak ale vyvolává dojem, že nasazení je problematické od samého počátku. Naopak spuštění v průběhu roku může být vnímáno jako více plynulé a pocitově méně stresující než Nový rok, kdy je navíc většina pracovníků zaměstnána událostmi souvisejícími s vánočními svátky a silvestrovskými oslavami.

V námi popisovaném projektu se navíc velmi osvědčila dlouhodobá „psychologická" příprava a postupné seznamování všech uživatelů s celým procesem implementace – o projektu se s uživateli začalo intenzivně hovořit zhruba 6 měsíců před vlastním spuštěním, takže byl dostatek času, aby se na danou situaci mohli připravit. Otevřeně a realisticky se probírala možná rizika a problémy, které může změna informačního systému přinést. Ve chvíli, kdy skutečné těžkosti nastaly, nebyly až takovým překvapením, protože se o této situaci dlouho dopředu vědělo.

Ukázalo se jako velmi prozíravé, že velká pozornost byla věnována úvodním fázím celého výrobního procesu, v našem případě technické přípravě výroby, nákupu a sledování výroby. Tyto činnosti byly v předimplementační fázi velmi pečlivě analyzovány a většina zákaznických úprav byla zaměřena zejména do těchto oblastí. Období mezi vánočními a novoročními svátky, kdy ve firmě probíhala výrobní odstávka, bylo využito pro intenzivní testování a vytváření prvních výrobních zakázek a nákupních objednávek. Tento přístup vedl paradoxně k určitým následným problémům, protože start systému byl „de facto" bezproblémový, úvodní procesy začaly fungovat velmi dobře a vedení projektu za dodavatele i zákazníka poněkud polevilo v ostražitosti. Zhruba po třech týdnech provozu došlo k prvním závažnějším problémům, kdy zakázky a objednávky „protekly" až do fáze zaúčtování, kde začaly kolabovat kvůli neúplnému nebo chybnému nastavení vnitřních účtovacích pravidel (nastavení parametrů zákazníků a dodavatelů, účtovací skupiny, vazby na účetní osnovu, nastavení DPH apod.), které nebyly v případě předchozího samostatného výrobního a účetního systému potřeba. Zde se naplno projevila nutnost úplné a jednotné parametrizace celé firmy v komplexním ERP systému. Dodavatel shodou okolností pod dojmem „relativně klidného" startu projektu alokoval část konzultantských a programátorských kapacit na jiné projekty. Všechny tyto příčiny vedly k určitému zpoždění v průchodu některých zakázek systémem. I přes tyto těžkosti nebyly ohroženy žádné dodací termíny, cenová politika ani kvalita produkce vzhledem k zákazníkům, což bylo primární a nepřekročitelnou podmínkou celého projektu. Podnik navíc na základě zkušeností z předešlých let počítal s tím, že objem lednových a únorových objednávek zákazníků je podle dlouhodobých statistik nižší než v dalších obdobích roku, což bylo rovněž důležitým kritériem pro spuštění nového informačního systému od začátku roku.

Podnik nakonec odstoupil od klasického způsobu hromadného školení uživatelů dodavatelem informačního systému a uživatelé byli průběžně školeni členy projektového týmu zákazníka. Školitel se tak mohl zaměřit na konkrétní činnosti a potřeby školeného a nezatěžovat ho pro něj nepotřebnými informacemi, čemuž se při skupinovém školení dá jen těžko vyhnout.

Jak už bylo uvedeno v předchozím článku, původní informační systém bude ještě zhruba rok využíván pro nahlížení a kontrolu. Zde se velmi osvědčilo jednoduché technické zlepšení, kdy každý klíčový uživatel dostal ke své pracovní stanici dva monitory, přičemž má na jednom spuštěný nový informační systém a na druhém původní (pouze ve čtecím režimu), takže může snadno vizuálně porovnávat například založení výrobní zakázky v novém systému s podobnou zakázkou v systému starém.

Doporučení pro vedoucího projektu

1. Delegujte

Vedoucí projektu za stranu zákazníka je jedním z klíčových článků celého projektu, nicméně i při středním rozsahu projektu nelze vše postihnout a zvládnout jedinou osobou, byť nemá na starosti nic jiného. Řešení je jednoduché – delegujte, delegujte a znovu delegujte. I v námi popisovaném rozsahu projektu se ukázalo jako mimořádně přínosné rozdělit projekt mezi tři členy projektového týmu zákazníka – první je zodpovědný za technickou přípravu výroby a výrobu (současně je vedoucím celého projektu), druhý zodpovídá za nákup, skladování a kvalitu a třetí za účetnictví a ekonomiku. V prvním měsíci rutinního provozu se rovněž velmi osvědčily pondělní operativní porady, kdy vedoucí projektu stručně popsal, kam se projekt za minulý týden posunul, které problémy jsou v daném okamžiku nejpalčivější a jak se budou řešit – první týden to byl celkový rozběh systému, zakládání položek a výrobních zakázek, druhý týden vytváření nákupních objednávek a příjem materiálu a v následujících týdnech sledování výroby, skladování a vnitropodnikové účtování. V tomto období probíhaly i pravidelné celodenní návštěvy konzultantů dodavatele, při kterých se řešily aktuální problémy, testovaly se zákaznické úpravy a odstraňovaly vzniklé chyby.

2. Ušpiňte si ruce

Vedoucí projektu byl v tomto případě i hlavním komunikačním článkem jak s uživateli, tak s dodavatelem. Neexistuje lepší zkušenost než si vlastníma rukama založit zakázku nebo objednávku kooperace a na vlastní kůži otestovat, jak se celá funkčnost nebo zákaznická úprava chová. Snáze pak pochopíte, že některé uživatelské požadavky jsou opodstatněné.

3. Žumpy nefungují

Nový informační systém je z principu o něco složitější, protože vyžaduje více dat a zejména přesnější data. Řada uživatelů má pak sklon pravidla nastavená novým systémem nějakým způsobem obcházet. Vznikají nápady jako založit fiktivní zakázku, na kterou se odepíše materiál, který se „ztratil", nebo vytvořit „hromadnou položku", na níž by se dalo objednat cokoliv a v jakékoliv ceně. Aktivita uživatelů je v tomto směru žádoucí, ale obecně platí, že tyto „žumpy" nefungují, protože zakázku bude jednou třeba uzavřít a účetně vypořádat a každou položku bude nutné přijmout na sklad ve správném množství a se správnou cenou.

4. Zapište si každý nápad

Pokud projekt běží od úvodních fází už několik měsíců, psychika se jím zabývá podvědomě a myšlenky na nejrůznější nápady, hrozivé souvislosti či fatální opomenutí vás napadají v nejrůznějších denních i nočních hodinách a v nejnevhodnějších situacích. Velmi se osvědčilo mít vždy po ruce (na nočním stolku, v příručním zavazadle atd.) papír a tužku, případně tablet a každý nápad nebo potenciální řešení si okamžitě zapsat. Věřte, že myšlenka vás může opustit stejně lehce, jako vás napadla.

5. Stavy zoufalství a euforie se střídají – počítejte s tím

Momenty, kdy se zdá, že celý projekt se hroutí a je definitivně ztracen, a pocity, že vše šlape, jak má, se střídají se vzácnou pravidelností. Moje osobní zkušenost je, že tyto změny nesouvisí ani tak s reálným stavem projektu, jako s osobním psychickým rozpoložením. Počítejte s tím, že tyto stavy se dostaví a zase odezní. Není to nic výjimečného a postihuje to téměř všechny vedoucí projektu.

6. Stále komunikujte s dodavatelem

Zákazník i dodavatel mají sice stejný cíl, ale liší se ve způsobu, jakým ho dosáhnout. Jedná se o střet různých způsobů řízení, firemní kultury, řešení problémů, způsobu komunikování a dalších oblastí. Jediná cesta, jak tyto odlišnosti úspěšně synchronizovat, je komunikace a permanentní vzájemné vysvětlování se snahou přemýšlet jako druhá strana.

Závěr

Úspěšnost implementace projektu je možné znovu hodnotit z pohledu vlastníka (iniciátora změny) a z pohledu uživatelů (konzumentů změny). Z pohledu vlastníka se projekt jeví jako úspěšný – firma funguje s novým ERP systémem od plánovaného data spuštění, předpokládané finanční náklady byly dodrženy, zákazníci tuto změnu nepocítili v žádném ohledu. Integrované a transparentní účetnictví, které bylo jedním z hlavních důvodů změny, je funkční.

Uživatelé současný stav vnímají poněkud odlišně – stále si zvykají na nový systém i obměněné procesy, u některých se částečně změnila jejich pracovní náplň. Řada stereotypů byla narušena, některé činnosti zabírají více času než dříve. Přínosy, které jsou globální (celopodnikové), už jednotliví uživatelé jako osobní přínos nepociťují.

Jiří Löffelmann

Mohlo by vás zajímat:

Mít, či nemít ERP? Investice do podnikového informačního systému je imperativem současnosti. Skoro se zdá, že firma bez ERP nemůže existovat. Přínosy implementace pro řízení podniku jsou...

< Předchozí		Další >