U471A : ECM: Zpracování úvodní studie

Kód úlohy:

U471A

Autor návrhu úlohy:

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

Datum poslední úpravy:

2014-12-02

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

0.7

Charakteristiky úlohy

1. “ECM: Zpracování úvodní studie“ – cíl, účel

Cílem úlohy je formulovat celkovou koncepci řešení aplikace ECM , definovat základní, obecný postup její implementace s tím, že zvláštnosti principů a postupů vzhledem k charakteru jednotlivých modulů ECM jsou řešeny v rámci vazeb na tyto komponenty.

2. Obsah úlohy

Vstupní analýza, tj. kontrola shody připravovaného projektu s Informační strategií podniku, s Projektovým záměrem a analýza aktuálních uživatelských požadavků,
Zahájení kooperace s vybraným dodavatelem , pokud je projekt řešen dodavatelským způsobem, * /Zpracování Úvodní studie projektu a v rámci ní především :
- konkretizace přínosů projektu, kontrola přínosů nové aplikace vzhledem k podnikovým potřebám,
- definování typů uživatelů aplikace a jim poskytovaných služeb,
- vymezení rozsahu a okolí projektu (čím se projekt zabývá a čím se nezabývá, jaké jsou požadované vazby na ostatní aplikace),
- zhodnocení variantních koncepcí řešení projektu (např. využití vlastních kapacit outsourcing, cloud computing apod.),
- definování zdrojů použitých pro řešení, budoucí provoz a údržbu (HW, SW, data, lidé – externí x interní),
- definování metrik na měření postupu a naplňování cílů projektu a požadovaných efektů realizované aplikace,
- návrh rozpočtu projektu,
- návrh harmonogramu projektu.

3. Vstupy úlohy:

Projektový záměr (D124A ),
Smlouva na úvodní studii (D420A ),
Plán projektů (D123A ),
Aplikační architektura (D053A ),
Datová architektura (D055A ),
Technologická architektura (D054A ),
Katalog požadavků na IT (D042A ),
Katalog IT služeb (D111A ),
Dokument specifikace projektu (D402A ),
Informační strategie (D001A ),
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:

Úvodní studie projektu (D421A ),
Katalog požadavků na IT, aktualizovaný (D042A ).

5. Podmínky úspěšnosti úlohy

V rámci této úlohy je pro úspěšné zahájení a další řešení projektu třeba:
- zajistit přístup k podnikovým dokumentům a specialistům a vytvořit jim i potřebný časový prostor a motivaci na řešení projektu,
- získat dostatečné finanční, lidské, technologické zdroje,
- vytvořit realistický harmonogram a rozpočet projektu,
- vyhodnotit situaci, kdy je lepší projekt aplikace zastavit z nejrůznějších důvodů (očekávaný nedostatek zdrojů, očekávané organizační změny, pravděpodobné využití nových technologií apod.),
Osoba manažera projektu je klíčová, je účelné vytvořit potřebné předpoklady, aby se projektový manažer v průběhu projektu pokud možno neměnil.
Je účelné již v průběhu řešení Úvodní studie nastavit jasná a efektivní pravidla kooperace mezi dodavatelem a zákazníkem.
Rodina ECM produktů zpravidla není v obecném povědomí managementu jako je tomu v případě ERP nebo CRM, proto je vhodné možnosti těchto produktů představit již v rané fázi projektu . Celkově řízení očekávání hlavně na straně byznysu vede k hladšímu průběhu projektu.

6. Doporučené praktiky

Pokud tomu nebrání předpisy nebo jiná omezení, je účelné, aby úvodní studii zpracovávali nejlepší 2 dodavatelé z výběrového řízení, a teprve na základě výsledné úvodní studie se určí finální dodavatel.
Pro zpracování úvodní studie je dobré vyčlenit dostatečný časový prostor , protože její kvalita často ovlivňuje výslednou kvalitu celého projektu.
Úvodní studie se často stává podkladem pro přípravu kontraktu na celý projekt a pak je třeba zajistit provázanost Úvodní studie a kontraktu.
Pokud již podobné řešení v podniku existuje, je třeba s ním při vypracování Úvodní studie počítat. I v případě, že nové řešení zcela nahradí stávající, vzniklá dokumentace může posloužit jako vstup v rámci dalšího řešení projektu.
Pro jednotlivé varianty řešení se doporučuje vypracovat :
- Strukturní model – popisuje komponentovou strukturu ECM řešení (které komponenty je vhodné implementovat, nejlépe přímo s vazbami na konkrétní uživatelské požadavky) včetně integrace s ostatními systémy uvnitř i vně podniku,
- Procesní model – obsahuje model životního cyklu podnikového obsahu, způsob realizace (komponenty), základní bezpečnostní principy a pravidla přístupu (např. jakým způsobem řešit autorizaci a autentizaci, ale i rozhraní, přes které budou moci uživatelé k obsahu přistupovat),
Práce s uživatelskými požadavky by v této fázi měla probíhat v agregované podobě s malou mírou detailu. Důvodem je vyšší flexibilita ve fázi analýzy a návrhu, kde je dostatečný prostor pro specifikaci detailů. Změna již odsouhlaseného dokumentu totiž často podléhá složitému změnovému řízení.
Při řešení Úvodní studie je efektivní vycházet z již zpracovaných a odsouhlasených dokumentů , tj. informační strategie a projektového záměru. Jednak není efektivní začínat vždy „od nuly“, jak se často děje, a navíc je nezbytné zachovat konsistenci mezi jednotlivými dokumenty.
Úvodní studie musí rovněž korespondovat s připravenou Specifikací zadání projektu, resp. Plánem projektu v rámci skupiny úloh řízení projektu.
Jednotlivé projektové metodiky se liší v náplni této fáze, nebo úlohy a je tedy výše navržený obsah vždy konkretizovat podle dané metodiky .

7. Zpracování úvodní studie“ - klíčové aktivity

7.1. Vstupní analýza pro řešení projektu

Smyslem vstupní analýzy je posoudit zamýšlený projekt aplikace z pohledu celkové koncepce IT , resp. informační strategie podniku a z pohledu aktuálních uživatelských požadavků na aplikaci.
Z informační strategie by mělo vyplynout zhodnocení, do jaké míry navrhovaná aplikace pokrývá cíle společnosti a její informatiky, jaká je její pozice v aplikační architektuře, jak se váže na ostatní aplikace, případně pokud některé nahrazuje, jak zapadá do celkového harmonogramu rozvoje celého informačního systému.
Smyslem analýzy uživatelských požadavků na aplikaci je požadavky zjistit, dokumentovat (pokud již dříve dokumentovány nejsou) a posoudit jejich oprávněnost vzhledem k cílům a možnostem podniku. Posouzení požadavků tak sleduje nejen jejich smysluplnost vzhledem k cílům podniku , ale snaží se i odhalit jejich duplicity . Mezi základní techniky pro zjišťování uživatelských požadavků patří interview .
Doporučovaným postupem analýzy uživatelských požadavků je uskutečnit nejprve počáteční – seznamovací workshop, následně jednotlivá interview, která jsou vedena s jednotlivci nebo v malých skupinkách uživatelů a potom jejich výsledky ověřovat při větších setkáních, resp. oponenturách. Tento postup má své logické opodstatnění v tom, že například při jednotlivých interview lze zaznamenávat dílčí názory jejich účastníků i různé nekonzistence v chápání podnikové reality. Typickým příkladem jsou nekonzistence v terminologii.
Závěr interview by měl směřovat k formulaci priorit pro řešení projektu, tedy co je pro zúčastněné v řešení nejpodstatnější, resp. kde očekávají pro ně nejvýraznější efekty. Tyto efekty mají mít, pokud je to racionální, kvantifikovatelnou podobu.
Jádrem těchto měřitelných efektů jsou ekonomické a zákaznické efekty . Je třeba určit, kdo bude zodpovědný za dosažení jednotlivých efektů a nadefinovat k nim metriky a k nim všechny potřebné údaje jako jsou název, ukazatel, současný stav, očekávaný stav v budoucnu, způsob měření a odpovědnou osobu za toto měření.

7.2. Zahájení zpracování úvodní studie a základní vymezení obsahu a rozsahu projektu

Vymezení obsahu aplikačního projektu, určení spolupracujících a ovlivněných subjektů, určení toho, čím se projekt zabývá a čím se na druhé straně nezabývá. Zmapování okolí projektu , a to na úrovni softwarové, technologické, legislativní, organizační, procesní a projektové.
Definují se podmínky řešení aplikace
- identifikace zákonů, norem a podnikových předpisů vztahujících se k řešené problematice,
- dopad aplikace do organizační struktury a podnikových předpisů,
- nastavení organizace řešení projektu,
- odhad potencionálních konfliktních zájmů,
- podnikové procesy, které budou aplikací ovlivněny, a které je třeba řešit,
- rámcová specifikace typového ASW pro implementaci aplikace,
- dopad systému na počet a kvalifikační strukturu pracovníků.

7.3. Definování typů uživatelů aplikace a jim poskytovaných služeb

Zmapování všech zainteresovaných jednotlivců, skupin a oddělení, které budou jakkoli ovlivněny aplikací, a jim poskytovaných služeb. Provádí se analýza uživatelů aplikace a jejich rozdělení je do jednotlivých skupin a přiřazují se jim poskytované služby, oprávnění a omezení .
Lze rozlišovat dva druhy uživatelů aplikací a to klasické uživatele, pro které jsou zamýšleny poskytované služby a tou druhou jsou administrátoři/správci , kteří danou aplikaci spravují a udržují v požadovaném funkčním stavu.

7.4. Zasazení ECM aplikací do podnikových architektur, zejména aplikační a technologické

Rozhoduje se , zda se bude zapojení aplikace do již stávající aplikační architektury řešit formou nové komponenty, či možnostmi zapojení aplikace do architektury formou nasazení celého integrovaného programového balíku.
U komponentového řešení můžeme použít aplikace, které nejvíce vyhovují potřebám společnosti, a společnost není závislá na jednom dodavateli SW. Je však zde složitá integrace mezi jednotlivými aplikacemi a problematická funkcionalita a integrita celého informačního systému. Jsou s tím spojeny i vyšší náklady , protože se musí aplikace integrovat s každou již zavedenou aplikací zvlášť.
U řešení formou integrovaného balíku je tomu přesně naopak .
V souvislosti se zasazením aplikace do architektur podniku se řeší tyto dílčí aktivity :
- určení aplikací, s nimiž bude aplikace integrována a kde bude docházet ke sdílení, nebo výměně dat, s přesnějším určením jejich obsahu, periodicity, technologické realizace,
- určení technologii pro aplikaci, na všech úrovních technologických vrstev, možnosti využití již instalovaných a provozovaných technologií,
- určení databázových systémů a databází, využití již existujících databází.
Další rozhodnutí souvisí s tím, zda využít zdroje vlastní či cizí. Kritérii v této oblasti jsou: náklady, bezpečnost dat, spolehlivost a míra závislosti na externích dodavatelích.
U aplikací řešených na bázi typového ASW jde většinou o řešení externí, tedy založené na outsourcingu, resp. v kombinaci s interními kapacitami. Další variantou k posouzení je provoz aplikace je formou SaaS (Software as a Service) v rámci cloud computingu , kdy je celá aplikace provozována externí firmou a společnosti nabízena pouze formou služby.

7.5. Kontrola shody připravovaného projektu s informační strategií podniku a projektovým záměrem

V navrhovaném projektu musí být zohledněny a zkontrolovány všechny souvislosti plánované aplikace s Informační strategií podniku, a to na základě dokumentů Aplikační architektura a Technologická architektura (viz předchozí aktivita).
Obdobně je nutné verifikovat navrhované řešení projektu s Projektovým záměrem , který rovněž z Informační strategie vychází. Pokud nedochází ke shodě, je třeba projekt pozastavit a zajistit konsistenci všech základních dokumentů.

7.6. Definování zdrojů použitých pro řešení, budoucí provoz a údržbu a jejich rozsahu

Definují se všechny zdroje potřebné pro projekt a zdroje, které budou potřebné pro budoucí provoz a údržbu aplikace . Určují se tyto zdroje:
- Typový aplikační software, jeho moduly, architektura. Na základě hrubé analýzy se určuje i rozsah potřebných customizací a případných dovývojů,
- Základní software (databázový systém, OS), rozsah pořízení nových produktů, resp. nezbytných upgrade stávajících,
- Vývojové nástroje a CASE nástroje pro případné dovývoje,
- HW zdroje, rozsah pořízení nových produktů, resp. nezbytných upgrade stávajících,
- Lidské zdroje,
- Ostatní – energie, vozový park, budovy.
Je nutné tyto zdroje alokovat a zajistit pro jednotlivé části projektu , aby nedošlo ke konfliktům využití zdrojů, protože tyto zdroje mohou být požadovány také jinými projekty.

7.7. Zpracování rozpočtu projektu

Určují se náklady na tvorbu, a nákup (dále jsou uvedeny hlavní z možných nákladů), tj. určují se náklady na:
- vývojové prostředí,
- strojový čas a spotřební materiál,
- mzdové náklady na čas projektantů, programátorů a uživatelů a další se zaměstnanci spojené náklady,
- školení,
- HW,
- licence SW - ZSW (vč. SŘBD), ASW. Varianty stanovení ceny licence (počet serverů/CPU/koncových stanic, jmenovitý uživatel, paralelní uživatel, dle počtu výskytů klíčového datového objektu, dle počtu transakcí).
Náklady na provoz a údržbu zahrnují:
- odpisy investic,
- provozní materiál,
- poplatky za komunikační cesty,
- provozní personál,
- service-desk,
- drobné úpravy,
- poplatky za roční údržbu HW a SW.

7.8. Vytvoření harmonogramu projektu

Harmonogram projektu je vytvořen pro celé období projektu od počátečních analýz až po zavedení do provozu . Následný provoz a údržba zde již není brán jako součást projektu, ale jsou součástí jednotlivých úloh domény Řízení provozu podnikové informatiky. Hlavními etapami jsou obvykle Analýza a návrh aplikace, Implementace aplikace a Příprava na zavedení do provozu, migrace.
Při vytváření harmonogramu projektu je nezbytné vytvářet jednotlivé etapy s reálnými časovými odhady, ale je nutné počítat s případnými časovými skluzy . Je vhodné použít metody omezení TOC (Theory of Constrains) , při které je identifikován klíčový řetězec, který obsahuje činnosti, bez jejichž dokončení nemohou pokračovat ostatní činnosti a je tedy nutné postupovat po tomto klíčovém řetězci.
Tato problematika je více obsáhnuta v metodách Critical Chain Project Management.
K jednotlivým činnostem je nutné nadefinovat a přiřadit plán spotřeby zdrojů a to jak finančních, tak personálních. Pro grafické znázornění a následnou práci s harmonogramem a zdroji projektu se obvykle využívá některý ze specializovaných SW pro podporu projektového řízení (např. MS Project), včetně využití Ganttova diagramu, kde je názorně vidět návaznost mezi jednotlivými činnostmi a jejich časová posloupnost.

7.9. Nastavení metrik na měření postupu a naplňování cílů projektu

Před zahájením projektu se definuje množina metrik , které budou sloužit pro sledování a měření postupu projektu . Také mají sloužit pro případné upozornění na problémovou situaci a signalizovat stav, kdy je vhodné projekt přerušit.
Každá metrika musí obsahovat informace jako je název, ukazatel, aktuální stav, očekávaný stav dle harmonogramu a plánu spotřeby zdrojů, způsob měření a odpovědnou osobu za toto měření.

7.10. Kompletace úvodní studie projektu

Jediným výstupním dokumentem této úlohy je Úvodní studie , což je dokument, ve kterém jsou shrnuty všechny výsledky této úlohy, a obsahuje celkovou koncepci řešení aplikace. Hlavním cílem Úvodní studie je zjištění, zdali je aplikace proveditelná tak, aby naplnila očekávané přínosy z jejího zavedení a to tak, aby respektovala rozpočtová omezení . Úvodní studie je často podkladem i pro zpracování kontraktu na celý projekt , neboť teprve v jejím rámci jsou upřesněny a konkretizovány všechny nezbytné obchodní parametry projektu.

8. Poznámky, reference

AutoCont: Správa dokumentů v Microsoft Dynamics AX 2012 - Bezpapírová Axapta ,
Feige, T.: Interní sociální síť jako nová forma podnikového intranetu,
Bruckner, T. Voříšek, J., Buchalcevová, A. a kolektiv - Tvorba informačních systémů: Principy, metodiky, architektury - (Grada Publishing 2012) - ISBN9788024779027,
Buchalcevová, A. - Metodiky vývoje a údržby informačních systémů - (Grada Publishing 2004) - ISBN8024710757,
Frappaolo, C. - Building an ECM Strategy – Alternatives and Decision Points - (AIIM - The ECM Association 2008),
Voříšek, J. a kol - Principy a modely řízení podnikové informatiky - (Praha, Oeconomia 2008) - ISBN9788024514406.