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 "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ů.