facebook LinkedIN LinkedIN - follow
Exkluzivní partner sekce
Tematické sekce
 
Branžové sekce
Přehledy
 
Tematické seriály
 

GDPR

General Data Protection Regulation zásadně mění zpracování osobních údajů a zavádí nové povinnosti...

články >>

 

Jak uřídit IT projekt a nezbláznit se

Užitečné tipy a nástroje pro řešení problémů řízení inovací a vývoje produktů...

články >>

 

Industry 4.0

Průmysl 4.0

Jaký vliv bude mít čtvrtá průmyslová revoluce na výrobu a výrobní firmy?

články >>

 

Komplexní svět eIDAS

O nařízení eIDAS již bylo mnoho řečeno i napsáno. A proto jediné, o čem...

články >>

 

Trendy v CRM

Systémy pro řízení vztahů se zákazníky (CRM) prochází v posledních letech výraznou změnou. Zatímco dříve...

články >>

 

Příručka úspěšného IT manažera

Dnes je řada IT manažerů opomíjena. Úspěšní bývají brouci Pytlíci a Ferdové...

články >>

 
Partneři webu
K2 atmitec
IT SYSTEMS 11/2020 , ERP systémy

Dvě cesty ke customizaci ERP systému

Petr Klapka


VisionTéměř tři desítky let se věnuji implementaci informačních systémů do středně velkých společností. Během té doby se mnohé změnilo, ale hlavní cíl je stále stejný: dosažení co největší míry automatizace. Zatímco dříve byly překážkou v jeho dosažení nedostatečné technologie, dnes to může paradoxně být příliš velká paleta možností, které moderní systémy nabízejí.


Nelehké začátky

V devadesátých letech neexistoval internet a výkon tehdejších serverů byl zlomkem výkonu dnešních mobilních telefonů. V té době se běžně v podnicích zaváděl tzv. „účetní systém“. Případně se k němu přidaly sklady, mzdy či nějaké jednoduché kalkulace pro výrobu. Žádné analýzy dat se nedělaly, vše se tisklo ve formě kilometrových sestav a veškerá data musela být hlavně na papíře. Systém byl určen jen několika vyvoleným uživatelům ve firmě. Cíl firem však byl stejný jako to, co je motivuje i dnes: automatizovat zdlouhavou a rutinní práci. O tomto jsou implementace informačních systémů dodnes, jen přibylo násobně víc možností a oblastí, kde a jak to lze udělat.

Nová doba, velká očekávání

Paradoxní je, že ačkoliv prakticky každá firma s nasazením nového systému očekává větší rozsah využití a vyšší míru automatizace svých činností, tak zároveň nepředpokládá, že by implementace měla být náročnější než u toho předchozího. Současně automaticky očekává, že všechny ty vychytávky, které si v předchozím systému nechali vyrobit na míru, bude nový systém již obsahovat. Zákazník má právo očekávat cokoliv a je pochopitelné, že mezi očekáváním a realitou budou značné rozdíly. Důležité je, že zkušený manažer, který již nějakou implementací prošel, si tyto rozpory uvědomuje a své požadavky v tomto ohledu koriguje.

Tak či tak bych řekl, že v dnešní době došlo k jednomu celkem významnému posunu. Středně velké firmy nejsou ochotny se v rámci implementace příliš zabývat všemi detaily. Hlavně to musí být rychle a bezbolestně. Tomu se dá docela dobře rozumět. Na to, aby firma mohla udělat na začátku detailní analýzu a pak se věnovat jeden rok implementaci, prostě není ani čas, ani lidé. Obzvláště s lidmi je potíž, protože na něco takového potřebujete opravdu špičkového pracovníka, který se nejen orientuje v informačních technologiích, ale rovněž zná dokonale vaši firmu z pohledu firemních procesů. A především to umí skloubit dohromady vyváženým, nebo chcete-li, efektivním způsobem. Takových lidí moc není.

Spojení dvou světů

Jak tedy tyto požadavky vyřešit? Než dojdu k jednomu z možných řešení, naznačím, jak probíhá klasická implementace jakékoliv části systému, nebo dokonce celého systému.

Běžně by měla začít implementace efektivně rozsáhlou analýzou. Efektivně znamená, že podrobnost analýzy by neměla zacházet do nepodstatných detailů, jejichž vyřešení či nevyřešení by mělo zanedbatelný dopad na výsledek. Nastává tady spojení dvou světů – „zákazník“ a „dodavatel“. V této fázi jde především o to, aby dodavatel co nejlépe pochopil, co po něm zákazník chce a zákazník to měl opravdu promyšlené. Dodavatel by už v této fázi měl být schopen některé požadavky korigovat, tak aby jejich výčet nezabředl mimo efektivní rozsah, nebo opačně, aby požadavek nebyl příliš obecný. Nutno říci, že je to z větší části odpovědnost zákazníka. Prostě je nutno stanovit cíle implementace a podrobnější požadavky ke splnění těchto cílů.

Druhá část analýzy je návrh řešení. Bude jej tvořit dodavatel a bude na základě požadavků navrhovat cílová řešení. Nebudu se pouštět do metod analýzy, kterých je též několik, ale podstatné je, aby dodavatel nakonec dokázal zákazníkovi prezentovat návrh řešení a zákazník byl schopen potvrdit, že opravdu pokrývá jeho požadavky. Potom teprve je možné naplánovat postup implementace formou projektu a projekt zahájit.

Myslím, že nejčastější chybou v těchto fázích je nedostatek vzájemného porozumění mezi dodavatelem a odběratelem. Rád používám příměry a zde se hodí příměr se stavbou rodinného domu. Hodně lidí si to umí představit, protože něčím takovým již prošli. Každý také ví, jaký je rozdíl mezí tím, jestli se dům staví podle obrázku z katalogu, nebo podle projektové dokumentace. Je nasnadě, co se začne dít ve chvíli, kdy jsou hotové omítky a majitel si vzpomene, že ještě potřebuje další čtyři zásuvky v kuchyni. Také si každý umí představit, že zadání „koupelna s jedním umyvadlem a sprchovým koutem“ může v hlavě stavitele vypadat úplně jinak než v představách zadavatele.

Z toho, co jsem napsal, je zřejmé, že jen samotná analýza – byť by měla jít jen do určité míry detailu – bude nesmírně zdlouhavá a komplikovaná, obzvláště pokud budete chtít projít poctivě celou firmu. Určitě bude generovat řadu „brainstormingů“, na kterých si i sám zákazník teprve začne ujasňovat, co vlastně potřebuje. Je zde velké riziko, že tato snaha povede ke ztrátě elánu a „rozpliznutí“ celé dobré myšlenky do nekonečného příběhu. Nabízí se otázka, jak už v začátku předejít rizikům, která z toho všeho plynou. Pokud analýzu neuděláte detailně, budete čelit několika rizikům. Největší z nich je to, že realizace projektu přinese nesmírné množství změn a velmi se protáhne. Na druhé straně, pokud budete chtít udělat analýzu skutečně poctivě, musíte na to mít zdroje, a to nejen finanční, ale i lidské. Takže jak z toho ven?

Změna strategie

Nabízí se jedno řešení, které jde trochu proti výše popsaným postupům. Vraťme se opět k příkladu se stavbou domu. Představte si, že byste měli možnost se nastěhovat na zkoušku do běžného domu, který má kuchyň, obývák, dětské pokojíčky, ložnici, koupelnu a garáž. Velikost je „tak akorát“. Se stavitelem se jen dohodnete, jestli má být v základu jeden nebo dva dětské pokoje, zda tam bude garáž pro jedno nebo dvě auta a jestli má obývák mít 20 či 40 metrů. Jinými slovy vůbec neřešíte, které spotřebiče budou v kuchyni, jaká značka, jestli je elektroinstalace inteligentní, zda je dům podsklepený a jakou barvu budou mít kachličky. Zato se do takového domu můžete nastěhovat už za dva měsíce. Stavitel vás nechá v domě bydlet a na vás bude, abyste si začali „osahávat“ jednotlivé pokoje. Začnete třeba kuchyní. Vaše manželka dostane za úkol si v následujících třech měsících zapisovat, co jí nevyhovuje, které přístroje chce doplnit, jak by měla být kuchyň ideálně veliká a jaký by měla mít design. Pak to předložíte staviteli a domluvíte se na ceně a termínu dodání. Stavitel vám v dohodnuté době dodá zcela novou kuchyň bez nutnosti rozkopat dům, bez příkoří bydlet na staveništi a plateb za bourací práce. Prostě vám ji vymění kus za kus. Pokud tu budou nějaká omezení, tak jen malá, která neomezí podstatně chod domácnosti.

Jak tento příměr souvisí s implementací podnikového informačního systému? Jedná se o tu variantu implementace, při které se na začátku udělá jen minimální (srovnávací) analýza. Systém se nasadí v základní verzi v rozsahu, který pokryje procesy společnosti v dostatečné míře. Teprve po určité době užívání se sesbírají požadavky klíčových uživatelů na úpravy systému, které se následně (za provozu) uskuteční. Firma tedy na počátku nemá systém „na míru“. Dostane ale velmi rychle do ruky nástroj, který může efektivně používat, a o to lépe později definovat požadavky na jeho rozvoj.

Možná namítnete, že vás tak dodavatel dostane do pastičky, ze které se nedá vyklouznout, a vy nebudete vědět, kolik vás všechny úpravy budou nakonec stát. To je do jisté míry pravda. Podobně to ale platí i v prvním případě, protože informační systém je živý organismus a stále se musí rozvíjet. Myslet si, že se jednou nastaví a pak už nebude potřeba na nic sahat, je omyl. Pokud se po implementaci rezignuje na další rozvoj ERP systému, tak zatímco firma roste a mění své procesy, systém postupně přestane vyhovovat. Konec implementace tedy neznamená stop dalším investicím do systému.

V případě dodatečné customizace je riziko této pasti paradoxně výrazně menší. Zpět k našemu příměru: Hned od začátku bydlíte, a tudíž užíváte dům. Už to samo o osobě je velkou úsporou. Ano, některý váš pozdější požadavek na změnu dispozice se může ukázat jako neřešitelný, nebo příliš drahý. Jenže to by platilo i v případě podrobného projektování, protože pokud by se udělalo skutečně poctivě, tak tento požadavek stejně zazní a nákladům na něj se nevyhnete. Co je ale nesporná výhoda, je možnost o každém požadavku přemýšlet na základě vlastní zkušenosti. Vrátím se k tomu příkladu s kuchyní. Představme si fiktivní příběh – buď necháte ženu vymyslet si kuchyň tzv. „na papíře“, nebo jí necháte pár týdnů v nějaké kuchyni pracovat a pak ji necháte kuchyň vymyslet. V druhém případě bude nová kuchyň daleko promyšlenější a možná i za méně peněz.

Rizika změny strategie

U klasického postupu s podrobnou analýzou a delší dobou implementace jsme zmínili několik rizik. Také v případě rychlého předání „hotového domu“ bychom měli vzít v úvahu rizika. Mezi ně patří především:

Riziko neschopnosti dodavatele řešit následný rozvoj. Tomuto riziku lze celkem efektivně čelit. I když klient nebude dělat detailní analýzu, rozhodně má jakousi představu, kterou by měl konzultovat s dodavatelem. Dodavatel by měl být schopen rámcově odpovědět, zdali může v budoucnosti takový požadavek vyřešit, za jak dlouho a zdali se bude pohybovat například v řádu desítek tisíc, či spíše ve stovkách tisíc korun.

Riziko vlastního vyčerpání elánu po rozběhnutí základní funkcionality. Myslím, že toto riziko je větší v případě detailní analýzy a standardní implementace. Při ní trvá implementace mnohem déle a spíše hrozí, že uživatelé dlouho neuvidí hmatatelný výsledek, byť se na přípravě intenzivně pracuje.

Riziko „paralyzace vlastní firmy“. Řekl bych, že toto je nejzásadnější riziko a mělo by být podrobováno rozboru a opatřením po celou dobu. Dá se obecně říci, že každá firma má ve svých procesech určitá klíčová místa, bez kterých by nefungovala. Tyto oblasti je potřeba primárně ošetřit a zaměřit se na ně. Dobré je, že tato místa bývají známá a dobře zmapovaná.

Riziko nazývané „údolí smrti“. Toto riziko souvisí s tím, že uživatel má v pilotním provozu pocit, že „nový IS pomáhá méně než předchozí systém“. Toto riziko se dá docela dobře ošetřit právě tím, že uživateli dobře vysvětlíme strategii a přizveme jej k přípravě následných řešení. Slovy výše použitého příkladu: „Ta kuchyň, ve které teď musíš vařit, neslouží pouze k tomu, abys navařil pro celou rodinu, ale také k tomu, aby sis na vlastní kůži osahal základní možnosti a vymyslel, jak by kuchyň v novém domě měla ve výsledku vypadat …“

Výhody

Nezabývali bychom se zde možným „alternativním postupem“ implementace, pokud by oproti tomu klasickému neskýtal možné výhody. Řada z nich už zde byla naznačena.

Výhoda přímé cesty. Určitě není možné podnikový informační systém implementovat zcela bez rozmyslu a bez určité formy prvotní, byť zjednodušené, analýzy. Lze se ale zaměřit pouze na kritické požadavky a přijmout ostatní funkcionalitu ve standardním provedení i za cenu mírného nepohodlí, či neefektivit. Využití této strategie vede k rychlému spuštění nového ERP systému.

Výhoda rozlišení užitečnosti jednotlivých požadavků. Tato výhoda je velmi významná. Ovlivňuje nejen dobu trvání implementace, ale i jeho celkovou cenu, a to dost podstatně. Potíž se softwarem je v tom, že je velmi „nehmatatelný“, těžko představitelný, těžko popsatelný. Pokud uživatel nemá o zamýšlené funkcionalitě dostatečnou představu, může se snadno stát, že nedokáže správně pochopit, co vlastně bude software umožňovat a jak se bude chovat. Své požadavky proto neumí dobře formulovat. Pokud ale uživatele necháte si software tzv. „osahat“, nebo jej dokonce přimějete, aby jej začal používat, začnou se jeho požadavky velmi rychle konkretizovat. Uživatel s dodavatelem díky tomu najdou společný slovník. Ve výsledku se realizují jen ty změny, které skutečně vedou k naplnění potřeb uživatele.

Výhoda rychlé implementace. Vlastně celá tato strategie směřuje k rychlému nasazení systému. Výhoda tedy spočívá v tom, že nový systém startuje relativně rychle, začíná sloužit a uživatelé své požadavky řeší postupně – nejsou vystaveni stresu z řešení velkého množství nových postupů najednou.

Výhoda rozložení nákladů v čase. Vyjděme z předpokladu, že vyrobení určité funkcionality bude stát stejné peníze, ať ji máte promyšlenou hned na začátku, nebo k ní dojdete postupně. Postupné doplňování funkcí má však tu výhodu, že si sami volíte, v jakém pořadí a čase se budou změny realizovat. Stejně tak máte pod kontrolou i platby za nové funkce.

Výhoda aktuálnosti požadavků. Pokud řešíte požadavky postupně, tak sice nemáte hotové vše „na klíč“, ale máte obrovskou výhodu v tom, že každý požadavek můžete posuzovat z pohledu okamžité situace. V průběhu implementace se může řada věcí změnit. Pracovat na funkcionalitách s velkým předstihem s sebou nese určité riziko neaktuálnosti ve chvíli, kdy se konečně dostane k nasazení dané funkce v praxi, případně jejich nepotřebnosti.

Kterou strategii zvolit?

Středně velké společnosti obvykle nemají interního člověka, který je schopen velkou implementaci dobře zastřešit. Přitom ve své dynamičnosti potřebují problémy řešit rychle a efektivně. Zejména v těchto případech by mohla být tato strategie vhodnou cestou, jak také ukazují naše zkušenosti z praxe. I v tomto případě bude nutné udělat úvodní analýzu, byť v efektivně zjednodušeném rozsahu. Stejně tak je potřeba pečlivě projektově řídit celou implementaci, nezanedbat intenzivní komunikaci s uživateli, a především se následně věnovat celkové customizaci tak, aby byl nový systém skutečným přínosem pro fungování celé firmy.

Petr Klapka Petr Klapka
Autor článku je ředitelem společnosti Vision Praha s.r.o.
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.

Inzerce

Covid jako katalyzátor digitalizace a fenomén homeworkingu

IT Systems 1-2/2021V aktuálním vydání IT Systems jsme se zaměřili na odvětví, která v současné době prochází velmi turbulentním vývojem. Vím, že se to dnes dá říct prakticky o všech oblastech našeho života, ovšem retail, logistika a potravinářský průmysl jsou navíc názorným příkladem, proč je pandemie onemocnění covid označována za katalyzátor digitalizace desetiletí. Pokud totiž ještě někdo pochyboval o významu digitalizace, musel v loňském roce prozřít.