Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Faktor : Customizace aplikačních produktů
Customizace aplikačních produktů
Kód faktoru

Standardní kód faktoru v MBI.

:
F132
Autor

Jméno a příjmení autora

:
Půta, T. (Artex Informační systémy)
Podstatné charakteristik faktoru

Obsahové vymezení faktoru

1. Obsahové vymezení customizace aplikačních produktů
  • Dílčími úpravami na míru (customizace) se rozumí takové úpravy, které standardní funkcionalita aplikačního systému neposkytuje.
  • Customizace je proces, během něhož dochází ke změněně nebo vytvoření zdrojového kódu uvnitř podnikového systému . Vyžaduje tedy znalost programovacího jazyka, ale i daného informačního systému.
  • Customizace se uplatňuje v případě, že podniku nevyhovuje nebo nedostačuje základní verze systému od dodavatele. Pomocí změn v programu tak lze reflektovat unikátní procesy organizace.
  • Customizace můžeme rozdělit podle několika hledisek .
1.1. Členění customizace - podle doby, kdy je customizace prováděna:
  • Iplementační:
    • Úprava funkcionality, která je pro podnik často natolik zásadní, že je nutné ji zvážit již v případě vypracovávání úvodní studie implementace aplikačního systému.
    • Často se jedná například o úpravy v rámci skladového hospodářství případně o změny u objednávkových a fakturačních procesů.
    • Tyto úpravy je nutné zahrnout do celkové kalkulace nákladů na projekt, jakož i do časového harmonogramu implementace.
    • Nevýhodou tohoto typu customizace je to, že úprava funkcionality často probíhá před migrováním reálných dat. Dodavatel úpravy tak musí pracovat s pouze uměle vytvořenými daty.
  • Post-implementační:
    • Jakýkoliv druh customizace, který je prováděn až po dokončení implementace aplikačního systému.
    • Většinou se jedná o takové druhy úprav, které nejsou pro podnik klíčové , případné požadavek na jejich vznik vyvstal v důsledku změny procesů vně podniku.
    • Na rozdíl od implementační customizace je tento typ prováděn na „reálných“ datech (byť ve vývojové či testovací databázi).
1.2. Členění customizace podle podoby vyvolání požadavku na customizaci
  • Legislativní : požadavky, které jsou vyvolány změnou v zákoně (nejčastěji v oblasti účetnictví):
    • Podnik musí takovéto požadavky respektovat, jinak se vystavuje rizikům postihu zodpovědnými orgány.
    • Pokud podnik používá systém s lokální podporou, často bývají tyto změny poskytovány zdarma v rámci údržby, a to formou kumulativních updatů .
    • Problém může nastat, pokud podnik nepoužívá systém s lokální podporou, přestal platit údržbu, případně používá starou verzi systému. V takových případech je nutné nechat si požadovanou změnu vyvinout na míru.
  • Klíčové:
    • Takové druhy úprav, které jsou pro podnik velmi významné, neboť mohou poskytovat kompetitivní výhodu, zefektivnění procesů nebo jsou na něm závislé další procesy. Pokud se podnik nechce o tyto výhody připravit, musí dané změny zapracovat.
  • “Nice-to-have“ :
    • Úpravy, které sice mohou přinést určité výhody (například zjednodušení práce pro konkrétní uživatele), avšak náklady (časové či finanční) na jeho vývoj by převážely výnosy.
    • Dalším příkladem mohou být úpravy, které sice nebudou mít vyšší náklady než přínosy, avšak nejsou pro podnik v danou dobu prioritou .
    • Problémem bývá to, že uživatelé často přeceňují potřebu dané úpravu a snaží se prezentovat potřebu dané úpravy jako klíčovou. Proto by měla být před zahájením práce na úpravě provedena úvodní studie, kde by měla být potřeba dané úpravy vyhodnocena.
1.3. Členění customizace – Gartner

Gartner na uvádí typ customizace rozlišuje:

  • Změny v uživatelském rozhraní : zahrnuje úpravy designu a přehledu systému a dialogových oken. Cílem těchto úprav bývá snaha poskytnout personifikovanější prostředí jednotlivcům nebo skupinám uživatelů systému.
  • Sestavy (reporty), dokumenty a formuláře :
    • Jedná se o nejčastěji customizované prvky systému.
    • Reporty v základních verzích systému bývají mnohdy velmi generické a zaměnitelné, takže dostatečně nereflektují informační potřeby podniku.
    • Mnohdy se rovněž jedná o pouhé změny ve vzhledu s cílem sladit sestavy (faktury, objednávky …) do podoby firemních dokladů.
    • Změny ve formulářích mívají mnohdy dva důvody. Buď se opět jedná o snahu poskytnout uživatelům personifikovanější prostředí, kdy dochází k vytvoření nových, mnohdy zjednodušenějších formulářů. Druhým důvodem pak bývají změny v již existujících formulářích, kdy dochází k napojení nové funkcionality, případně úpravě stávající.
  • Pracovní postupy (workflow) : Umožňuje uživatelům výběr kroků v pracovních postupech a definování jejich správného sledu. Správa pracovních postupů může být buď interní přímo v aplikaci, nebo se může jednat o externí nástroj, který používá programátorské rozhraní pro přístup do již existující aplikační funkcionality.
  • Integrace ostatních aplikací :
    • Zahrnuje poměrně širokou škálu možností .
    • V nejjednodušších případech se jedná o integraci ERP a ostatních informačních systémů (CRM, BI, SCM, …) od stejného dodavatele . V takovýchto případech dochází pouze k omezené customizaci, která se spíše snaží integrovat ostatní již customizované části.
    • Dále lze integrovat ERP s ostatními IS od jiných dodavatelů a to buď v rámci podniku, nebo v případě napojení na systémy partnerů (dodavatelů či odběratelů).
    • Posledním případem bývá napojení ERP na jiné aplikace než informační systémy . Nejčastěji se může jednat o e-shopy, webové služby ale i o napojení na hardwarové zařízení jako jsou platební terminály.
  • Rozšíření funkcionality : Ačkoliv ERP systémy obsahují celou řadu best practies a dodatečných funkcionalit, v některých případech může podniku scházet určitá funkcionalita. V takových případech je nutné tuto funkcionalitu dovyvinout.
  • Úprava existující funkcionality :
    • Je částečně podobná úpravě reportů a formulářů, neboť i v této kategorii dochází k předělání již existujícího kódu. Hlavní rozdíl v obou kategoriích je ten, že při úpravě existující funkcionality se má na mysli spíše kód, který běží tzv. „na pozadí“ (např. úpravy v procesu účtování, skladových transakcích …).
    • Tato kategorie je pro řadu dodavatelů systému nejkontroverznější, neboť může významným způsobem znesnadňovat nasazování hotfixů (jedno druhový nebo kumulativní balík změn, který obsahuje programový kód, který má za cíl odstranit chybu v programu), přechod na nové verze a v případě špatně provedené modifikace kódu může dojít i k zanášení chyb do dat.
1.4. Členění customizace – Davis
  • Davis na rozděluje customizaci z pohledu významnosti na :
    • Strategickou: takový druh úprav, jehož výsledkem je dosažení strategických cílů podniku nebo podpora strategického plánování. Z definice vyplývá, že se jedná o velmi důležité změny v systému, které by měly být v souladu s celkovou strategií podniku. Tím, že budou změny podporovat strategii, bude rovněž dosaženo souladu strategie informačního plánu a business strategie (tzn., že u těchto úprav nedochází k neúčelnému plýtvání prostředků na zbytečné změny).
    • Konzistentní: představuje změny, které se snaží zachovat „status quo“ u business procesů, případné jsou důsledkem špatně nastavených procesů. Nejsou tedy strategického charakteru, nýbrž snahou zachovat konzistentnost prvků napříč podnikem. Příkladem může být úprava sestavy faktury, kdy podnik klade důraz na jednotný vzhled všech dokladů, které z podniku odcházejí (stejná hlavička, patička, logo…). Pokud nebude vyhovovat standardní sestava, kterou ERP poskytuje v základu, je nutné takovouto sestavu dovyvinout – takovýto druh úpravy není strategický ale konzistentní.
2. Způsob poskytování customizace

Vývoj a nasazování úpravy může poskytovat těmito cestami:

  • Interně :
    • Bývá častější u velkých podniků , které mají vlastní IT oddělení, případné u firem, které se zabývají poskytováním implementace a customizace ERP.
    • I nterní tým vývojářů má výhody v lepším vhledu do problematiky daného podniku (avšak při správně provedené analýze by problematika měla být přehledná i pro externí tým) a teoreticky zde hrozí menší riziko úniku dat (u externího poskytovatele lze ošetřit smlouvou).
    • Na druhou stranu jsou tyto týmy limitovány znalostí best practies v oblasti poskytování customizací, neboť byť je každá úprava do určité míry specifická, lze u nich vysledovat určité podobnosti napříč podniky (především pak v oblasti reportingu).
    • Další potenciální nevýhodou tohoto způsobu je nutnost vlastnit vývojářskou licenci – to je u řady aplikací nemožné nebo velmi nákladné.
  • Externě:
    • Nejčastějším případem bývá přímo dodavatel, který implementovalaplikaci , avšak může se jednat i o naprosto odlišnou firmu, než která systém nasazovala.
    • Externí poskytovatel může poskytnout cenné rady již při vypracovávání úvodní studie, neboť se zpravidla setkává s podobnými požadavky na customizaci.
    • Další výhodou je to, že odpadá nutnost vlastnit vývojářskou licenci – tato povinnost přechází na dodavatele, který pro zásah do kódu musí použít vlastní licenci.
  • Kombinovaně:
    • Některé podniky volí kombinaci externího a interního poskytování. Pro některé snazší úpravy (jako je například úprava reportů) není u některých systémů (např. Microsoft Dynamics Nav, Microsoft dynamics AX …) vyžadována vývojářská licence.
    • Podnik pak zřizuje menší interní týmy, které se zabývají těmito drobnějšími customizacemi, zatímco na složitější úpravy využívá služeb externího dodavatele.
    • Další využití kombinované formy bývá u podniků, jejichž mateřská firma sídlí v zahraničí a na úpravy centralizovaného ERP systému využívá zahraničního interního týmu.
    • Pokud ale v České republice vznikne legislativní požadavek (nejčastěji v oblasti účetnictví) na určitou úpravu, nejsou tato interní oddělení schopna podchytit a zapracovat dané změny. V takových případech pak dceřiný podnik volí po dohodě s mateřskou firmou cestu externího dodavatele pro danou úpravu.
3. Efekty a přínosy faktoru pro kvalitu řízení podniku a IT
  1. Přizpůsobení se business procesům : je největší potenciální přínos customizace. Ačkoliv se výrobci snaží zapracovat do svých produktů best practies a vydávat nové verze, reflektující změny v procesech co nejčastěji, někdy ani tato reakční doba nestačí. Proto podnik může reagovat customizacemi a reagovat na nejrůznější podněty. Dalším pozitivním přínosem je přizpůsobení funkcionality přímo pro konkrétní segment podniku. Výrobci ERP vytváří systém masově. Rozdíly jsou ale mezi společností prodávající chemické soupravy a společností, která vyrábí a prodává stavební materiál. Navzdory tomu, že se výrobce často snaží poskytnout alespoň nějaké dodatečné balíky pro daný segment, může až customizace finálně postihnout všechna specifika daného segmentu.
  2. Sjednocení vzhledu: týká se především vzhledu reportů odcházejících z podniku. Díky customizaci může podnik zachovat stejnou (nebo velmi podobnou) formu dokladů, jakou používal před implementací systému. Navíc si řada podniků platí grafické designery, které jim vytváří vzhled a formu dokladů. I to lze do určité míry pomocí customizace reflektovat.
  3. Zachování kompetitivní výhody: některé úpravy mohou pomoci optimalizovat daný proces, což může podniku přinést kompetitivní výhodu či dosáhnout větší efektivity práce.
4. Otázky, roblémy a omezení spojené s faktorem
  1. Obtížný přechod na nové verze systému: při customizaci dochází k úpravě zdrojového kódu. Každá takováto úprava může ztížit a prodražit přechod na novější verzi systému. Tyto změny v systému totiž výrobce nepodporuje a tak je jejich přenos do nové verze buď nemožný (např. v případech úprav existující funkcionality, která je v nové verzi významně změněna) nebo velmi obtížný. P odnik pak stojí před rozhodnutím jakou cestou se vydat :
    1. Přechod na novou verzi, bez zapracování změn: tím ale může dojít ke snížení produktivity práce (pokud byly změny významné a uživatelé na ně byli zvyklí). Navíc v případě, že došlo při customizaci k úpravě datové struktury tabulek, bude přechod i tak náročný a vyvolá další dodatečné náklady na migraci dat.
    2. Přechod na novou verzi, se zapracováním změn: opět ovšem může dojít ke zvýšení nákladů na migraci, stejně jako v předchozím případě. Další náklady jsou pak spojené se samotným „přenosem“ úprav, neboť mnohdy nestačí úpravy pouze překopírovat a přenést do nového systému, ale je nutné je znovu přeprogramovat a otestovat.
    3. Nepřecházet na novou verzi: čímž se ale podnik může ochudit o nové funkcionality, které výrobce poskytuje. Navíc, jak již bylo zmíněno výše, v tomto případě řada podniků přestává platit údržbu, neboť se dobrovolně vzdávají nároku na novou verzi systému. V takovém případě pak většinou dochází k většímu propojení s dodavatelem (ať už interním nebo externím) poskytujícím customizaci. Ve snaze neztrácet konkurenční výhodu si pak může podnik nechávat vyvinout funkcionalitu, která je však v nové verzi systému již poskytnuta. To však v konečném důsledku může vyvolávat ještě vyšší náklady než v předchozích případech. Nelze obecně říci, která z cest je nejvhodnější, vždy záleží na množství úprav, rozdílech v obou verzích a současném využívání ERP systémů.Implementace hotfixů: je podobným problémem jako přechod na novou verzi systému, avšak s tím rozdílem, že implementaci hotfixu se většinou podnik nemůže vyhnout, neboť by se tím vystavil rizikům vyplývajícím z charakteru softwarové chyby, které hotfix odstraňuje. Pokud se úprava a daný hotfix překrývají (tj. upravují stejnou část kódu) je nutné nejprve zapracovat hotfix a následně přepracovat úpravu, což může vyvolat další dodatečné náklady.
  2. Špatně provedené úpravy: úprava v programu může poskytovat fatálně chybné údaje. Na druhou stranu ji lze minimalizovat vhodným výběrem dodavatele i korektním dodržováním pravidel metodiky a testováním úpravy.
  3. Růst nákladů: dochází k němu především u společností, kde nejsou jasně vymezeny zodpovědnosti za rozvoj systému a pravomoci k rozhodnutí o zahájení vývoje dané úpravy. V takovém případě pak dochází k situaci, že si jednotlivé útvary podniku (obchodní, finanční …) zvyknou diktovat nové podmínky na systém a začne vznikat velké množství úprav z kategorie „nice-to-have“. To samozřejmě vede k růstu nákladů na vývoj a znesnadňování budoucího přechodu na nové verze.
  4. Problémy v řízení změn: customizace je sice založená na úpravách, které mají podporovat business procesy podniku, avšak mnohdy se může jednat o špatně nastavené procesy. Některá oddělení (nebo jednotliví uživatelé) se však nechtějí přizpůsobit standardní funkcionalitě systému, byť by z procesního hlediska byla vhodnější a raději se snaží podnik dotlačit k úpravě systému. Tím dochází nejen k vyšším nákladům, ale i k zakonzervování neefektivních procesů. Řízení business procesů by tedy v procesu customizace nemělo být opomíjeno a tento negativní jev eliminovat vhodně zpracovanou úvodní studií.
  5. Správa úprav: se týká především velkých podniků, kde vzniká velké množství úprav. Tyto úpravy je nutné dobře dokumentovat. V opačném případě může docházet k tomu, že společnost začne ztrácet přehled o provedených úpravách, což nejenže vede k vyšší složitosti přechodu na nové verze systému a zapracovávání hotfixů, ale i k riziku, že bude podobná úprava vyvíjená znovu. Dalším rizikem je pak stav, kdy uživatelé nebudou vědět, proč se funkcionalita chová daným způsobem, neboť nebudou o provedené úpravě vědět.