U422A : ERP: Analýza a návrh

Kód úlohy:

U422A

Autor návrhu úlohy:

Šmahel, M. (KIT, VŠE), Zelenka, P.

Datum poslední úpravy:

2013-12-17

Předpokládaná pravděpodobnost užití v praxi:

0.5

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 "ERP: Zpracování úvodní studie" (U421A ) a je obvykle rozdělena na dvě části:
- Globální analýza a návrh (GAN),
- Detailní analýza a návrh (DAN).

2.1. Fáze Globální analýza a návrh, GAN

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). Obsahem je:
- Z př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í:
- 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.
- 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.
- Parametrizace a customizace –je možné docílit požadované funkcionality nastavením parametrů aplikace.
- 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).
Je třeba zjistit, zdali typová aplikace obsahuje všechny důležité entity, atributy a jejich vztahy. Vytvoří se tedy požadovaný konceptuální datový model a porovnává se s datovým modelem TASW řešení. Případné konflikty se řeší 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ší.
Stejně jako v případě individuální aplikace se zavedení celého řešení rozdělí na jednotlivé přírůstky (iterace) a určí 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.
Vytváří se 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). 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í.

2.2. Fáze Detailní analýza a návrh, DAN

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 j sou 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é bylo definováno 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.
P ro 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 se mapují na funkce TASW aplikace a zjišťuje se 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.
Ověřuje se, zdali m odul 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.
Navrhují se ú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 se ověřuje kvalita 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

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ů.
Š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.
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.
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í.
Vytvoření harmonogramu - pro implementaci jednotlivých částí (přírůstků) aplikace.
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ů.
Návrh datových rozhraní - mezi moduly vyvíjeného TASW řešení i k ostatním aplikacím.
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ů.
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ů.
Návrh kmenových databází - jejich struktura, úpravy základních dat.
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ů.