|
Úloha
: Zpracování úvodní studie - TASW
|
|
|
|
|
Kód úlohy
Standardní kód úlohy v MBI.
:
|
Autor návrhu úlohy
Jméno a příjmení autora úlohy
:
|
Datum poslední úpravy
Datum poslední úpravy úlohy ve tvaru rrrr.mm.dd.
:
|
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ů.
:
|
|
|
Charakteristiky úlohy
 1. Účel úlohy „Zpracování úvodní studie – TASW“
- Účelem úlohy Úvodní studie je:
- posoudit
realizovatelnost požadavků na projekt
,
-
formulovat celkovou koncepci
a přístup k řešení aplikace (např. ERP, CRM apod.),
- definovat
zadání výstupního produktu
a způsob využití typového ASW,
- navrhnout
alternativní řešení
a vybrat z nich nejvhodnější,
- zpracovat
kontrakt na řešení projektu
,
- sestavit
časový harmonogram
realizace,
- stanovit
metriky
hodnocení projektu,
- Úvodní studie bývá často řešena jako
samostatný projekt
, kdy teprve na základě jeho výsledku je rozhodnuto o projektu realizačním,
- Účelem úlohy je definovat základní,
obecný postup řešení
s tím, že zvláštnosti principů a postupů vzhledem k charakteru aplikací jsou řešeny ve speciálních úlohách MBI,
- Další paragrafy obsahují komplexně
různé aspekty a pohledy
na řešení globální analýzy a návrhu – TASW a je na uživateli, aby vybral ty, které jsou v dané situaci relevantní.
 2. Scénáře, analytické otázky a problémy
- Ve vztahu k řešení jednotlivých oblastí podnikového řízení je dobré vycházet z analytických otázek definovaných ve specifických scénářích pro tyto oblasti řízení podniku: „Scénáře k řízení podniku a byznys analytice“ (SGQ100),
- Úloha má rovněž řešit problémy a otázky definované ve scénáři „Je třeba zajistit systematický průběh řízení a implementace IT projektu“ (S407
).
 3. Vstupy úlohy:
-
Informační strategie
(D001A
),
-
Smlouva na úvodní studii
(D420A
), včetně zadání projektu Úvodní studie,
-
Organizační
a řídící
dokumenty
podniku (DQ002A
),
- Stávající
projektová dokumentace
IT podniku,
-
Podniková architektura
(D051A
) a navazující
Architektura IT služeb
(D052A
),
-
Architektury
stávající podnikové informatiky – a s tím související Aplikační architektura (D053A
), Datová architektura (D055A
), Technologická architektura (D054A
),
-
Nabídka
na dodávku IT služeb a produktů (D132A
),
-
Plán projektů
(D123A
) a
Projektový záměr
(D124A
),
- Dokument
specifikace projektu
(D402A
),
-
Katalog požadavků
na IT (D042A
),
-
Katalog IT služeb
(D111A
),
-
Procesní dokumentace
podniku (DQ003A
),
-
Katalog datových zdrojů
(D211A
),
-
Specifikace technologických standardů
(D232A
).
4. Výstupy úlohy:
-
Úvodní studie
projektu, včetně hrubého popisu nutných změn byznys procesů vyvolaných zvoleným TASW, seznamu projektových rizik a kontraktu na dodávku TASW a jeho implementaci – obvykle v příloze (D421A
),
-
Katalog požadavků
na IT, aktualizovaný (D042A
),
-
Katalog IT služeb
, aktualizovaný o nově plánované služby v rámci projektu (D111A
),
-
Plán
projektu
(D401A
), včetně harmonogramu řešení,
-
Rozpočet
projektu
(D411A
),
- Strategie datové migrace (D427A
).
 6. Klíčové faktory ovlivňující kvalitu řešení
- Faktor velikosti podniku (F000),
- Faktor příslušnosti podniku k odvětví ekonomiky (F006
),
- Stav legislativy (F034),
- Podniková kultura (F050
),
- Podniková organizace (F051
),
- Struktura uživatelů IS, informatiků a úroveň jejich znalostí (F080
),
- Cloud computing (F100
),
- SaaS – Software as a Service (F106
),
- Úroveň a formy sourcingu (F120
),
- Podniková architektura (F150
),
- Aplikační architektura (F152
),
- Technologická architektura (F153
),
- Datová architektura (F154
),
- ERP (F300
).
 8. Podstatné charakteristiky Zpracování Úvodní studie - TASW
- Jednotlivé charakteristiky jsou detailně uvedeny v přiloženém PDF dokumentu.
 9. Role v úloze:
-
Informační manažer
(CIO) (R101
):
- Konzultuje řešení úlohy a přípravu projektu z hlediska celkové koncepce podnikové informatiky a z hlediska vazeb na ostatní projekty a aplikace. Podílí se na schvalování Úvodní studie na úrovni vedení podniku, případně na schvalování jejích dílčích částí,
-
Manažer IT služeb
(R102
):
- Definuje celé spektrum služeb ve vazbě na aplikaci a podle toho se postupně upravuje i katalog IT služeb,
-
Manažer projektu
(R103
):
- Je zodpovědný za celé řešení úlohy a za výstupní Úvodní studii, řídí řešení úlohy a kooperaci s externím dodavatelem,
-
Manažer rozvoje IT
(R104
):
- Konzultuje koncepci nasazení aplikace z pohledu celkového rozvoje podnikové informatiky, vazby na ostatní aplikace, překrývání jejich funkcionality apod.,
-
Byznys analytik
(R302
):
- Řeší v kooperaci s externím dodavatelem všechny jednotlivé části Úvodní studie, zajišťuje i vazby a konzultace s interními manažery, metodiky, klíčovými uživateli,
-
IT architekt
(R401
):
- Je zodpovědný za promítnutí plánované aplikace do IT architektury, konkretizuje nebo schvaluje nároky na úpravy IT architektury, pořizování nových technologií a nároky na upgrade,
-
Generální manažer
(CEO, Chief Executive Officer) (RQ001
):
- Je informován o výsledné Úvodní studii a schvaluje ji zejména z hlediska navrženého harmonogramu a rozpočtu,
-
Byznys manažer
(RQ009
):
- Byznys manažeři se účastní interview v rámci vstupních analýz. Dostávají k dispozici Úvodní studii a obvykle se na úrovni vedení podniku podílejí na jejím schvalování,
-
Metodik, klíčový uživatel
(RQ032
):
- Konzultuje požadavky na aplikaci v rámci interview vstupních analýz a následně se konkretizují i požadavky na customizaci a dovývoje TASW,
-
Vlastník byznys procesu
(RQ033
):
- Konzultuje požadavky na aplikaci v rámci interview vstupních analýz a následně se konkretizují i požadavky na customizaci a dovývoje TASW.
 10. Řešení úlohy v kontextu domén řízení IT:
-
Strategické řízení IT
(DO090
):
- Vstupy ze skupin úloh strategického řízení, zejména kompletní informační strategie, včetně jednotlivých typů architektur z úloh Návrh architektury IT služeb (U033A
) a Promítnutí architektury IT služeb do dílčích IT architektur (U034A
),
- Podklady pro rozhodnutí a řízení využití cloud computingu – ve skupině úloh Cloud Governance a Cloud Management (TG007
),
-
Řízení IT služeb
(DO100
):
- Vstupy z úlohy Plánování a zařazování projektů pro realizaci (U122A
), zejména Projektový záměr,
- Vstupy z úlohy Výběrové řízení na dodavatele IT produktů a služeb (U134A
), pokud se předpokládá řešení externím dodavatelem, resp. v kooperaci s ním,
-
Řízení IT zdrojů
(DO200
):
- Vstupy k vyhodnocení a posouzení disponibilních zdrojů pro řešení projektu, tj. z úloh Analýza datových zdrojů (U201A
), Personální analýzy v IT (U221A
), Analýzy ASW zdrojů (U241A
), Analýzy IT infrastruktury (U242A
),
-
Řízení IT ekonomiky
(DO300
):
- Vytvoření podkladů pro přípravu rozpočtu projektu s respektováním hodnot a pravidel pro celou podnikovou informatiku v úloze Tvorba rozpočtu na IT (U304A
),
-
Řízení rozvoje IT služeb
(DO400
):
- Vstupy a pravidla pro řízení projektu ve skupině úloh Řízení projektu (TG401
), zejména v úlohách Řešení projektu (U404A
) a Analýzy průběhu a výsledků projektu (U405A
),
- Úloha Zpracování úvodní studie – TASW je rámcovým podkladem pro řešení obdobných úloh pro jednotlivé typy projektů, jak ukazuje následující přehled,
- ERP: Zpracování úvodní studie (U421A
),
- WMS - ERP: Úvodní studie (U426A
),
- Zpracování BI Úvodní studie (U431A
),
- Zpracování Úvodní studie pro SSBI (U451A
),
- Zpracování Úvodní studie pro mobilní aplikace (U461A
),
- ECM: Zpracování úvodní studie (U471A
),
- CRM: Zpracování úvodní studie (U481A
),
-
Řízení provozu IT
(DO700
):
- Podklady pro konkretizaci uživatelských požadavků z výstupů úloh Řízení uživatelských požadavků (U733A
), Řízení externího service-desku (U734A
), Řízení interního service-desku (U734B
).
 11. Podmínky úspěšnosti úlohy
- V rámci ú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 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.
 12. 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
.
13. Klíčové aktivity úlohy „Zpracování úvodní studie – TASW“ 13.1. Vstupní analýza pro řešení projektu
-
Smyslem
vstupní analýzy
je
posoudit projekt aplikace z pohledu celkové koncepce
podnikové informatiky, 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. V návaznosti na vyhodnocení aplikace v rámci informační strategie se v dalším kroku provádí analýza konkrétních uživatelských požadavků na aplikaci.
-
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í.
13.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ů.
13.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í 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.
13.4. Zasazení řešené aplikace 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í
lze 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.
13.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ů.
13.6. Definování zdrojů použitých pro řešení, budoucího provozu, údržby 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.
13.7. Zpracování rozpočtu projektu
- Určují se
náklady na tvorbu, nákup, provoz a údržbu
(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.
13.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,
- 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 potřeby zdrojů
a to jak finančních, tak personálních, datových a technologický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.
13.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í.
13.10. Kompletace úvodní studie projektu
- Úvodní studie 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.
 14. Poznámky, reference:
|
|
|
|
7. Hlavní metriky uplatňované v řešení úlohy