U472A : ECM: Analýza a návrh aplikace

Kód úlohy:

U472A

Autor návrhu úlohy:

Malý, J. (KIT, VŠE)

Datum poslední úpravy:

2014-12-03

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

0.7

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