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 : ECM: Analýza a návrh aplikace
ECM: Analýza a návrh aplikace
Kód úlohy

Standardní kód úlohy v MBI.

:
U472A
Autor návrhu úlohy

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

:
Malý, J. (KIT, VŠE)
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.7
Charakteristiky úlohy

Charakteristiky úlohy

1. “ECM: Analýza a návrh aplikace“ – cíl, účel
  • Cílem úlohy je analyzovat, jaké procesy bude implementované ECM řešení podporovat, jakou funkcionalitu je nezbytné pro dané procesy zajistit, kde je potřeba řešit customizaci, v jakém rozsahu, u jakých funkcí, jaké je případně třeba realizovat dovývoje, jak řešit nasazení aplikace v podniku.
2. Obsah úlohy
  • Analýza definovaných požadavků na aplikaci,
  • Návrh řešení aplikace především z obsahového pohledu, tj. na podstatně větší úrovni detailu musí specifikovat:
    • jaké funkce má poskytovat,
    • s jakými daty pracovat,
    • jaké podnikové procesy podporovat.
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
  • Účast pracovníků uživatelské sféry podniku na řešení úlohy (alespoň konzultační formou), jejich pochopení a respektování nových možností aplikace oproti zavedeným zvyklostem, nepožadovat realizaci zbytečných změn v TASW.
  • Dobrá organizace a úroveň školení uživatelů kooperujících na projektu, aktivní účast uživatelů na školení a ochota studovat principy a funkcionalitu implementované aplikace.
  • Otevřenost vedení podniku a uživatelské sféry změnám , která aplikace přináší, včetně podnikové organizace a podnikových procesů.
  • Zkušenosti implementačního týmu (zejména externího dodavatele) s konkrétním obsahem aktivit podniku, jeho podnikání (podle daného odvětví).
  • Respektování časové náročnosti realizace analýzy a návrhu vzhledem k rozsahu a komplexnosti implementovaného ECM řešení.
  • Zajištění průběžné komunikace implementačních týmů s uživatelskou sférou.
6. Doporučené praktiky
  • Pro efektivní kooperaci implementačních týmů s klíčovými uživateli je nezbytné těmto uživatelům vytvořit, pokud je to možné, dostatečný časový prostor a odpovídající motivaci na řešení projektu.
  • Při zpracování analýzy stávajících podnikových procesů a návrhu nových je důležitým faktorem volba notace . Zde je nutné si uvědomit, že procesní diagramy jsou především nástrojem komunikace. Proto je vhodné vybrat notaci dle audience, která dokumenty bude revidovat a případně i schvalovat . Ve většině případů se jedná o zástupce businessu, takže vhodnou volbou jsou základní flow diagramy u jednoduchých procesů a standardizované business notace (např. BPMN) u těch komplexnějších. V rámci projektu je dobré stanovit jednotnou notaci.
7. “ECM: Analýza a návrh aplikace“ - klíčové aktivity

7.1. Sběr uživatelských požadavků
  • Sběr uživatelských požadavků by měl probíhat systematicky se zaměřením zejména na organizační složky, které nová funkcionalita významně postihuje . Sada analytických otázek by měla být předem připravena. Míra detailu se odvozuje od složitosti daného řešení.
  • Sběr požadavků a jejich specifikace zpravidla probíhá ve více kolech, aby se předešlo případným nedorozuměním v souvislosti s rozdílným očekáváním a zároveň byly zodpovězeny otázky, které vznikly v průběhu přípravy návrhu.
  • Příklady analytických otázek z oblastí řízení podnikového obsahu , které se v této fázi projektu běžně objevují, mohou být:
    • S jakým typem obsahu uživatelé v dané organizační jednotce běžně pracují?
    • Jaký je účel tohoto obsahu?
    • Vzniká daný obsah přímo v této organizační jednotce?
    • Má tento obsah jednotnou formu, případně přímo šablonu?
    • Je daný obsah schvalován? Pokud ano – kým je schvalován a z jakého důvodu?
    • Kdo, resp. jaké role, má k danému obsahu přístup? Kdo k němu má mít přístup a kdo k němu naopak přístup mít nesmí?
    • Je třeba k danému typu obsahu evidovat další informace v podobě metadat?
7.2. Analýza podnikových procesů
  • Rozsah aktivity je dán rozsahem projektu, při čemž platí, že se podrobně analyzují pouze procesní domény, které se projektu přímo týkají . Domény, které se projektu týkají nepřímo, stačí zmínit.
  • V rámci řízení podnikového obsahu do detailu se popisují procesy z oblastí životního cyklu obsahu :
    • Pořízení elektronického obsahu,
    • Uskladnění podnikového obsahu,
    • Dodání podnikového obsahu,
    • Uchování podnikového obsahu.
  • U identifikovaných procesů nás zajímá vlastník procesu, aktéři, iniciační a konečné události, jednotlivé činnosti, vstupy a výstupy a případně metriky pro měření klíčových charakteristik procesu.
  • Procesy je možné popsat textově či graficky pomocí diagramů . V praxi se pro větší srozumitelnost doporučuje kombinovaný přístup.
7.3. Návrh řešení aplikace
  • Vlastní návrh lze rozdělit do tří částí :**Aplikační architektura,
    • Technologická architektura,
    • Informační architektura.
  • Aplikační architektura představuje logický pohled na systém. Obsahuje komponentovou strukturu řešení a množinu rozhraní pro komunikaci s dalšími podnikovými systémy. U komponent i rozhraní je třeba definovat detailní funkční specifikaci vycházející z uživatelských požadavků a určit způsob realizace dané funkcionality – zda je řešena „out-of-box“ přímo TASW či je třeba ji dovyvinout.
  • Technologická architektura se zabývá technickou stránkou řešení. Po hardwarové stránce jde hlavně o IT infrastrukturu (webové, aplikační a databázové servery, síťové prvky,…), která vychází ze systémových požadavků softwaru. Systémové požadavky je nutné patřičně dimenzovat vzhledem k počtu uživatelů a objemu předpokládaného zpracovávaného / uskladněného obsahu, při čemž je třeba myslet i na budoucí potřebu. Z hlediska softwaru se řeší potřebný počet a struktura licencí. Důležitým prvkem technologické architektury je i model nasazení jednotlivých komponent (desktopová aplikace, intranet, extranet nebo online řešení).
  • Informační architektura je nejspecifičtějším prvkem návrhu, kterým se ECM liší od ostatních typů TASW. Zaměřuje se na obsah a strukturu systémem zpracovávaných dat – datovou bázi. V případě ECM se jedná zejména o podnikový obsah, jenž by měl být evidován v katalogu podnikového obsahu, což je analytický dokument popisující jednotlivé typy obsahu v následující (doporučené) struktuře:
    • Typ obsahu,
    • Základní popis – musí obsahovat jednoznačné vymezení typu obsahu,
    • Metadata, která je potřeba u daného typu obsahu v systému evidovat,
    • Seznam procesů, kde se s daným typem obsahu jakkoliv manipuluje, včetně specifikace, o jakou jde operaci,
    • Zdroje obsahu – uvádí se interní i externí,
    • Diagram procesu životního cyklu daného typu obsahu.
7.4. Návrh systému vyhledávání obsahu
  • Dále je třeba definovat systém vyhledávání obsahu. V rámci ECM je možné nastavit centrální vyhledávání , které dokáže při vhodné implementaci integračních rozhraní vyhledávat i v externích systémech.
  • Druhou možností je využívat proprietárních vyhledávacích systému v rámci jednotlivých komponent . Oba přístupy mají svá pozitiva i negativa, která závisí na detailech dané implementace.
  • Nezávisle na typu vyhledávání je v každém případě nutné určit, na jakou část systému se vyhledávání vztahuje. Návrh vyhledávání by měl také stanovit pravidla tvorby definice vyhledávání a případné filtry .
7.5. Řešení bezpečnosti a definice přístupových práv
  • Další velkou oblastí je bezpečnost a definice přístupových práv. Způsob autorizace a autentizace je hlavně technickou otázkou, proto se spíše řeší v rámci návrhu technologické architektury.
  • Běžně se řeší integrací na centrální adresářový server, ve výjimečných případech individuálně přímo v aplikaci .
  • Pro účel definice přístupových práv je dobré uživatele rozdělit do skupin dle rolí (měly by odpovídat rolím v navržených procesech) a organizačních jednotek. Jasně definovaná uživatelská práva by pak měla být mapována na jednotlivé skupiny uživatelů.