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á).

Úloha : ERP: Analýza a návrh
ERP: Analýza a návrh
Kód úlohy

Standardní kód úlohy v MBI.

:
U422A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Šmahel, M. (KIT, VŠE), Zelenka, P.
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.5
Charakteristiky úlohy

Charakteristiky úlohy

1. “ERP: Analýza a návrh“ – cíl, účel

Cílem úlohy je definovat funkcionalitu aplikace a nároky na customizaci, resp. dovývoje podle potřeb zákazníka.

2. Obsah úlohy

Úloha bezprostředně navazuje na úlohu U421A (Úvodní studie) a je obvykle rozdělena na dvě části – globální analýza a návrh (GAN) a detailní analýza a návrh (DAN). Fáze GAN se zabývá návrhem celkové koncepce nasazované typové aplikace a jejím rozdělením na jednotlivé přírůstky (iterace). Ve Fázi DAN jsou pro každý definovaný přírůstek navrhnuty potřebné úpravy a změny parametrů dle požadavků zákazníka.

Obsahem fáze GAN je zpřesnění a rozpracování požadavků na typové ERP řešení, u kterého probíhá parametrizace, customizace a případně dovyvinutí chybějících funkcí. Je třeba počítat s tím, že si TASW řešení vynutí změny v podnikových procesech, aby se z aplikace vytěžil maximální potenciál. Pro specifikaci požadovaných funkcí a identifikaci funkcí chybějících se většinou použijí procesní modely a diagramy případů užití (use case diagram). Ty se porovnávají s dokumentací aplikace nebo přímo při používání referenčních instalací systému. U všech požadovaných funkcí je třeba rozhodnout, jak budou realizovány v rámci TASW řešení:

  1. Aplikace daný proces pokrývá od začátku – proces je natolik standardizovaný, že ho typová aplikace podporuje beze změn nebo s malými úpravami.
  2. Podnikový proces je třeba změnit – proces v podniku se liší od procesu podporovaného aplikací a je nutné ho změnit, aby se docílilo shody.
  3. Parametrizace a customizace –je možné docílit požadované funkcionality nastavením parametrů aplikace.
  4. Požadovaná funkcionalita musí být dovyvinuta – pokud podnik vyžaduje speciální funkce, které nejsou součástí základního typového řešení (a není možné jich docílit předchozími kroky).

Dále je třeba zjistit, zdali typová aplikace obsahuje všechny důležité entity, atributy a jejich vztahy. Vytvoříme tedy požadovaný konceptuální datový model a porovnáme ho s datovým modelem TASW řešení. Případné konflikty musíme řešit s dodavatelem – může se jednat pouze o jiná pojmenování stejných entit, ale také mohou chybět klíčové atributy a entity, které je třeba doimplementovat.

Je třeba provést detailní popis ostatních požadavků na aplikaci – bezpečnostní (přístup k datům, šifrování), kvalitativní (dostupnost aplikace, doba odezvy), legislativní (účetní standardy, platné zákony) technologické (změny v hardwarové infrastruktuře), aplikační (změny základního a aplikačního softwaru, integrace na ostatní podnikové a externí aplikace), organizační (změny v organizační struktuře podniku vynucené aplikací) a další relevantní požadavky.

Stejně jako v případě individuální aplikace musíme zavedení celého řešení rozdělit na jednotlivé přírůstky (iterace) a určit pořadí jejich implementace a rozhraní pro integraci s ostatními podnikovými a externími (zákazníci, dodavatelé, veřejná správa) aplikacemi. Je vhodné zvolit funkční jádro typové aplikace – nejmenší možnou část, která může samostatně fungovat. Je nutné vytvořit detailní plán migrace na novou aplikaci. Typové aplikace většinou vyžadují specifické vývojové a provozní prostředí (např. konkrétní databázový systém), a proto zde není mnoho prostoru pro „manévrování“. V neposlední řadě je nutné provést detailní návrh programových standardů a vzorů pro ty části TASW, které bude třeba dovyvinout.

Globální analýza a návrh končí ve chvíli, kdy jsou jasně specifikovány požadavky na zaváděnou typovou aplikaci – existuje návrh požadovaných funkcí včetně způsobu jejich realizace (parametrizace, customizace, vývoj nových komponent) a jsou definovány nefunkční vlastnosti řešení (bezpečnost, kvalita). Systém je rozdělen na přírůstky a existuje plán, podle kterého budou zaváděny. Také jsou detailně zdokumentovány změny v podniku vyvolané TASW aplikací.

Cílem fáze DAN je návrh realizace vybrané části (přírůstku, iterace) typové aplikace. Probíhá postupně pro všechny přírůstky specifikované v globální analýze a návrhu. Pro každý přírůstek jsou provedeny detailní analýza a návrh, které jsou následovány implementací a zavedením vytvořené části aplikace. Poté se celý cyklus opakuje s dalším přírůstkem. Je tedy vhodné začít funkčním jádrem aplikace, které jsme definovali v předchozí fázi a postupně ho integrovat s dalšími částmi systému. Dodavatel a zákazník musí neustále vést dialog, aby návrh co nejvíce odpovídal požadavkům podniku. Návrhy všech klíčových aspektů řešení jsou ověřovány uživateli, kteří budou aplikaci používat v praxi.

Pro specifikaci požadavků na funkcionalitu přírůstku jsou opět využívány procesní modely a diagramy případů užití z modelovacího jazyka UML. Činnosti v procesních modelech mapujeme na funkce TASW aplikace a zjišťujeme tak, do jaké míry modul podporuje požadovanou funkcionalitu. Pro případné neshody je třeba navrhnout řešení – změny v podnikových procesech, provedení parametrizace a customizace nebo vývoj části aplikace na míru. Dále lze použít diagramy případů užití – popisují chování aplikace z hlediska uživatele a využívají aktéry a činnosti, které aktéři mohou provádět v dané části systému.

Také je nutné ověřit, zdali modul obsahuje všechny požadované entity, atributy a vztahy. Je třeba zajistit, aby do navržené databáze bylo možné uložit všechna důležitá podniková data. Dále je třeba navrhnout úpravy uživatelského rozhraní (kritické pro použitelnost aplikace) na základě požadavků klíčových uživatelů aplikace. Před zaváděním přírůstku musí existovat plán migrace dat, aby byla zachována kontinuita kritických podnikových dat a zamezilo se případným ztrátám. Je nutné definovat rozhraní přírůstku na ostatní podnikové aplikace, ale také na plánované přírůstky vyvíjeného řešení, aby bylo možné jednotlivé části aplikace snadno propojit. Před fází implementace je nutné naplánovat testy (funkční, integrační, uživatelské a další), kterými ověříme kvalitu vytvořeného přírůstku. Při detailní analýze a návrhu jsou také vytvořeny a verifikovány první prototypy (části kódu) přírůstku aplikace. Detailní analýza a návrh končí ve chvíli, kdy byl jasně specifikován nový přírůstek typové aplikace a jeho potřebné úpravy. Uživatelské rozhraní aplikace je odsouhlaseno uživateli a existuje plán testů, které prověří kvalitu zavedeného přírůstku. Dále jsou jasně zdokumentovány a komunikovány změny v procesech a organizační struktuře podniku způsobené zaváděným TASW řešením.

3. Vstupy úlohy:
  • Úvodní studie projektu (D421A ),
  • Katalog požadavků na IT (D042A ),
  • Katalog IT služeb (D111A ),
  • Dokument specifikace projektu (D402A ),
  • Plán projektů (D123A ),
  • Plán projektu (D401A ),
  • Rozpočet projektu (D411A ),
  • Organizační a řídící dokumenty podniku (DQ002A ),
  • Procesní dokumentace podniku (DQ003A ),
  • Katalog datových zdrojů (D211A ),
  • Specifikace technologických standardů (D232A ).
4. Výstupy úlohy:
  • Dokumentace řešení projektu: analýza a návrh aplikace (D422A ),
  • Katalog požadavků na IT, aktualizovaný (D042A ).
5. Podmínky úspěšnosti úlohy
  • Podpora ze strany vedení podniku – vedení podniku musí být přesvědčeno, že zavedení dané aplikace opravdu podpoří definované byznys cíle (Business/IT alignment).
  • Účast klíčových uživatelů – zahrnutí uživatelů budoucí aplikace do vývojového procesu. Klíčoví uživatelé musí být dostatečně odborně zdatní, musí dokonale znát procesy minimálně ve své oblasti a musí mít možnost je redefinovat a přenastavovat. Jejich účast na celém procesu, jejich kvalita a nasazení je jedním z klíčových faktorů rozhodujících o úspěchu implementace na straně zákazníka.
  • Obeznámení uživatelů se změnou – často se vyskytuje odpor ke změnám v organizaci, a tak je nutné včas obeznámit zaměstnance s plánovanými změnami v podnikových procesech a organizační struktuře a vypěstovat tak podnikovou kulturu, ve které se počítá s používáním nové aplikace.
  • Globální návrh aplikace – návrh datové základny, funkcionality, parametrizace a dalších klíčových aspektů aplikace musí splňovat všechny definované požadavky.
  • Udržení rozsahu projektu – musíme se držet stanovených požadavků na typovou aplikaci a neprovádět zbytečné změny mimo rozsah projektu, které navýší cenu i délku trvání projektu.
  • Kvalifikovaný dodavatelský tým – zaměstnanci dodavatele mají zkušenosti s projekty podobného typu a dokážou správně navrhnout nutné úpravy aplikace a prezentovat jejich dopady zákazníkovi.
6. Doporučené praktiky

Na počátku detailní analýzy je proškolení klíčových uživatelů v základech ovládání implementovaného ERP systému, po kterém následuje vlastní etapa. Ta je z hlediska časového vytížení pracovníků dodavatele i klíčových uživatelů velmi náročná a intenzivní. V této fázi implementace může využití CASE nástrojů značně zjednodušit návrh systému. Z existujících modelů lze generovat kód, který lze použít jako základ ve fázi implementace. Součástí této fáze je i počátek obměny hardwarového vybavení. Dnešní ERP jsou náročné systémy, které obvykle vyžadují výraznější investice do serverů a do výměny pracovních stanic. Jako první přichází v této fázi na řadu serverové vybavení, pracovní stanice lze postupně obměňovat po celý průběh implementace až do doby spuštění ostrého provozu.

7. “ERP: Analýza a návrh“ - klíčové aktivity

7.1. Podrobná specifikace organizace projektových činností

Určení řídícího výbor u, personálního obsazení analytických a aplikačních týmů, základních principů plánování a řízení projektu, určení pravidel komunikace pracovních týmů, specifikace dokumentace, určení přístupových práv jednotlivých členů týmů k aplikacím a dokumentaci. V této etapě se tak již zcela konkretizuje organizační struktura projektu, složení řídící komise projektu a jednotlivých specializovaných a analytických týmů.

7.2. Školení pracovních týmů

Školení organizace a řízení projektu, struktury a celkového postupu projektu, účelu jednotlivých fází a činností, analytických metod, školení obsahové, ekonomické a organizační podstaty řešení jednotlivých aplikačních modulů, jejich vlivu na stávající řídící a obchodní procedury, školení architektury aplikačního softwaru.

7.3. Upřesnění a aktualizace uživatelských požadavků

Specifikace požadavků na funkce zajišťované aplikačním softwarem a analýza jejich realizovatelnosti, ekonomické efektivnosti a konsistence.

7.4. Analýza funkčních požadavků uživatelů vzhledem k možnostem aplikačního softwaru

Analýza funkčních požadavků uživatelů vzhledem k možnostem aplikačního softwaru, analýza pokrytí chybějících funkcí, ověření možností využití nebo integrace stávajících aplikací.

7.5. Vytvoření harmonogramu

Vytvoření harmonogramu pro implementaci jednotlivých částí (přírůstků) aplikace.

7.6. Prototypování ASW ERP

Implementace prototypu podle analýzy uživatelských požadavků, návrh datové základny pro prototyp, určení přístupových práv pro testování prototypu, ověřování zkušebních výsledků, ověření celého prototypu a návrh úprav programových modulů.

7.7. Návrh datových rozhraní

Návrh datových rozhraní – mezi moduly vyvíjeného TASW řešení i k ostatním aplikacím.

7.8. Definice technologického řešení

Definice technologického řešení a technických konfigurací – síťová konfigurace a konfigurace jednotlivých technických prostředků.

7.9. Návrh změn v organizační struktuře

Změny náplně organizačních jednotek a jejich uspořádání, přístupových práv (určení skupin a podskupin pracovníků), funkčních náplní pracovníků.

7.10. Návrh kmenových databází

Návrh kmenových databází – jejich struktura, úpravy základních dat.

7.11. Návrh výstupních informací

Návrh tištěných formulářů, jejich grafické formy, standardních textů, tiskových sestav, interních a externích výkazů.