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: Zpracování úvodní studie
ECM: Zpracování úvodní studie
Kód úlohy

Standardní kód úlohy v MBI.

:
U471A
Autor návrhu úlohy

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

:
Malý, J. (KIT, VŠE)
Datum poslední úpravy

Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.

:
2014-12-02
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: 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.