- Přehledy IS
- APS (20)
- BPM - procesní řízení (22)
- Cloud computing (IaaS) (10)
- Cloud computing (SaaS) (33)
- CRM (51)
- DMS/ECM - správa dokumentů (20)
- EAM (17)
- Ekonomické systémy (68)
- ERP (79)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (36)
- WMS (29)
- Dodavatelé IT slueb a řeení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (39)
- Dodavatelé CRM (33)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (71)
- Informační bezpečnost (50)
- IT řeení pro logistiku (45)
- IT řeení pro stavebnictví (26)
- Řeení pro veřejný a státní sektor (27)
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údrby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk![]() | |
| Přihlaste se k odběru newsletteru SystemNEWS, který kadý týden přináí výběr článků z oblasti podnikové informatiky | |
![]() | |
Dvě cesty ke customizaci ERP systému
Té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ý: dosaení co největí míry automatizace. Zatímco dříve byly překákou v jeho dosaení nedostatečné technologie, dnes to můe paradoxně být příli velká paleta moností, 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 dnení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, ve se tisklo ve formě kilometrových sestav a vekerá data musela být hlavně na papíře. Systém byl určen jen několika vyvoleným uivatelům ve firmě. Cíl firem vak 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 moností a oblastí, kde a jak to lze udělat.
Nová doba, velká očekávání
Paradoxní je, e ačkoliv prakticky kadá firma s nasazením nového systému očekává větí rozsah vyuití 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 vechny 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ůleité je, e zkuený manaer, který ji nějakou implementací proel, si tyto rozpory uvědomuje a své poadavky v tomto ohledu koriguje.
Tak či tak bych řekl, e v dnení době dolo k jednomu celkem významnému posunu. Středně velké firmy nejsou ochotny se v rámci implementace příli zabývat vemi 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í, protoe 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 vai 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 poadavky vyřeit? Ne dojdu k jednomu z moných řeení, 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řeení či nevyřeení 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 promylené. Dodavatel by u v této fázi měl být schopen některé poadavky korigovat, tak aby jejich výčet nezabředl mimo efektivní rozsah, nebo opačně, aby poadavek 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í poadavky ke splnění těchto cílů.
Druhá část analýzy je návrh řeení. Bude jej tvořit dodavatel a bude na základě poadavků navrhovat cílová řeení. Nebudu se poutě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 řeení a zákazník byl schopen potvrdit, e opravdu pokrývá jeho poadavky. Potom teprve je moné 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, protoe něčím takovým ji proli. Kadý 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 jetě potřebuje dalí čtyři zásuvky v kuchyni. Také si kadý 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é mylenky 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 veho 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é mnoství 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é. Take jak z toho ven?

Změna strategie
Nabízí se jedno řeení, které jde trochu proti výe popsaným postupům. Vrame se opět k příkladu se stavbou domu. Představte si, e byste měli monost se nastěhovat na zkouku do běného domu, který má kuchyň, obývák, dětské pokojíčky, lonici, 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í. Vae manelka 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 staveniti 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í poadavky klíčových uivatelů 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 poadavky na jeho rozvoj.
Moná 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 vechny úpravy budou nakonec stát. To je do jisté míry pravda. Podobně to ale platí i v prvním případě, protoe 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 naemu 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í poadavek na změnu dispozice se můe ukázat jako neřeitelný, nebo příli drahý. Jene to by platilo i v případě podrobného projektování, protoe pokud by se udělalo skutečně poctivě, tak tento poadavek stejně zazní a nákladům na něj se nevyhnete. Co je ale nesporná výhoda, je monost o kadém poadavku přemýlet na základě vlastní zkuenosti. 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 promylenějí a moná 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 řeit 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ý poadavek vyřeit, 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 uivatelé 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 kadá firma má ve svých procesech určitá klíčová místa, bez kterých by nefungovala. Tyto oblasti je potřeba primárně oetř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 uivatel 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 oetřit právě tím, e uivateli dobře vysvětlíme strategii a přizveme jej k přípravě následných řeení. Slovy výe pouité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í monosti a vymyslel, jak by kuchyň v novém domě měla ve výsledku vypadat
Výhody
Nezabývali bychom se zde moným alternativním postupem implementace, pokud by oproti tomu klasickému neskýtal moné výhody. Řada z nich u zde byla naznačena.
Výhoda přímé cesty. Určitě není moné podnikový informační systém implementovat zcela bez rozmyslu a bez určité formy prvotní, by zjednoduené, analýzy. Lze se ale zaměřit pouze na kritické poadavky a přijmout ostatní funkcionalitu ve standardním provedení i za cenu mírného nepohodlí, či neefektivit. Vyuití této strategie vede k rychlému sputění nového ERP systému.
Výhoda rozliení uitečnosti jednotlivých poadavků. 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 uivatel 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é poadavky proto neumí dobře formulovat. Pokud ale uivatele necháte si software tzv. osahat, nebo jej dokonce přimějete, aby jej začal pouívat, začnou se jeho poadavky velmi rychle konkretizovat. Uivatel 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 uivatele.
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á slouit a uivatelé své poadavky řeí postupně nejsou vystaveni stresu z řeení velkého mnoství nových postupů najednou.
Výhoda rozloení nákladů v čase. Vyjděme z předpokladu, e vyrobení určité funkcionality bude stát stejné peníze, a ji máte promylenou hned na začátku, nebo k ní dojdete postupně. Postupné doplňování funkcí má vak 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 poadavků. Pokud řeíte poadavky postupně, tak sice nemáte hotové ve na klíč, ale máte obrovskou výhodu v tom, e kadý poadavek můete posuzovat z pohledu okamité 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řeit. Přitom ve své dynamičnosti potřebují problémy řeit rychle a efektivně. Zejména v těchto případech by mohla být tato strategie vhodnou cestou, jak také ukazují nae zkuenosti z praxe. I v tomto případě bude nutné udělat úvodní analýzu, by v efektivně zjednodueném rozsahu. Stejně tak je potřeba pečlivě projektově řídit celou implementaci, nezanedbat intenzivní komunikaci s uivateli, 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 Autor článku je ředitelem společnosti Vision Praha s.r.o. |




















