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

Standardní kód úlohy v MBI.

:
U411A
Autor návrhu úlohy

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

:
MBI tým
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. Úč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.
2. 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 ).
3. 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 ).
4. Podstatné charakteristiky Zpracování Úvodní studie - TASW
  • Funkce / procesy:
    • vymezení byznys procesů, kterých se projekt týká (seznam),
    • zpřesnění procesního modelu (informační výstupy a datové vstupy),
    • rozdílová analýza - specifikace hlavních funkčních požadavků, vyplývajících z procesů tak, aby bylo možné zjistit procesy, činnosti a funkce, které vybraným TASW řešením jsou a které nejsou realizovány,
    • mapování byznys procesů a jejich činností na funkce vybraného TASW,
  • Data:
    • hrubý konceptuální model tříd / entit a jeho porovnání s dokumentací TASW (modelem tříd nebo datovým modelem),
    • návrh způsobu mapování stávajících datových struktur do datových struktur TASW,
    • vymezení chybějících datových struktur a návrh způsobu jejich doplnění,
    • popis externích datových vstupů a výstupů a požadavků na jejich formu,
  • Aplikační SW:
    • porovnání dostupných TASW pro řešenou předmětnou oblast,
    • výběr nejvhodnějšího TASW,
    • realizace „proof of concept“ (demo aplikace na vzorku dat podniku) k ověření realizovatelnosti vybraného TASW pro podmínky podniku,
    • identifikace funkcionalit, které v TASW chybějí,
    • identifikace stávajících aplikací, které bude nutné s TASW integrovat,
  • Technologická infrastruktura:
    • specifikace technologických požadavků a posouzení jejich splnění vybraným TASW,
    • hrubý návrh technologické architektury, kontrola a upřesnění technologické architektury z informační strategie,
    • návrh parametrů nově nakupovaných HW komponent a infrastrukturního SW (operačních systémů, databázových systémů, aplikačních serverů, integračních platforem a middleware obecně, včetně způsobů licencování a potřebných počtů licencí),
  • Uživatelské rozhraní:
    • principy a specifika uživatelského rozhraní TASW a posouzení možností přizpůsobení podnikovým standardům UI,
  • Personální, sociální, etická stránka projektu:
    • definování kategorií uživatelů,
    • popis specifik skupin uživatelů (interní/externí) a jejich standardního chování a způsobu využívání IS,
    • počet uživatelů, minimální a maximální počet paralelně pracujících uživatelů,
    • vymezení hlavních aplikačních rolí,
    • výběr pracovníků, kteří se budou účastnit realizačního projektu a definice jejich odpovědností (vlastníci procesů resp. manažeři oddělení, garanti věcných oblastí, klíčoví uživatelé, akceptační tým),
  • Organizace a legislativa:
    • identifikace zákonů a norem vztahujících se k řešené problematice,
    • identifikace podnikových předpisů vztahujících se k řešené problematice,
    • dopad zavedení systému do organizační struktury a podnikových předpisů (nové organizační schéma, nové role, náplně práce atd.),
  • Bezpečnost a kvalita:
    • požadavky na informační bezpečnost,
    • seznam norem a zákonů, které musí v oblasti bezpečnosti zákazník respektovat,
    • základní parametry SLA (doba provozu, dostupnost, vymezení kritické funkcionality a parametry reakce na incidenty),
  • Ekonomika:
    • definování předpokládaných ekonomických i mimoekonomických efektů řešení,
    • stanovení celkového rozpočtu projektu a cenové struktury (licencí, cena za vývoj, cena technologií, cenové podmínky podpory provozu vzhledem k SLA),
    • stanovení platebních podmínek a možností financování projektu.
5. 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.
6. Řešení úlohy v kontextu řízení podniku:
  • Obsah řízení podniku je klíčovým podkladem pro kvalitní řešení Úvodní studie. V MBI je vymezen ve skupinách úloh odpovídajících jednotlivým oblastem řízení, a to v doménách Řízení podniku (DO00 ), Odvětvové řešení: maloobchod, retail (DO005 ), Odvětvové řešení: Výroba (DO006 ).,
  • Každá skupina úloh je rozdělena do úloh dle jejich typů (viz základní informace k doménám), v nichž Úvodní studie pokrývá specifické otázky – viz další přehled,
  • Evidenční úlohy:
    • rámcový přehled potřebných datových bází a vyhodnocení disponibilních datových zdrojů,
    • vyhodnocení chybějících datových zdrojů,
  • Transakční úlohy:
    • základní specifikace funkcionality úloh a hlavních procesů, na nichž jsou založeny,
  • Úlohy reportingu:
    • přehled klíčových požadovaných reportů dle oblastí řízení (skupin úloh),
  • Analytické úlohy :
    • základní vymezení požadované funkcionality, tedy analytických funkcí a odpovídajících klíčových ukazatelů,
  • Plánovací úlohy:
    • základní vymezení požadované funkcionality, tedy plánovacích funkcí a odpovídajících klíčových plánovacích ukazatelů,
  • Specifické úlohy:
    • rámcové vymezení specifické funkcionality odpovídající jednotlivým úlohám,
  • U všech typů úloh je určeno jejich pokrytí, či nepokrytí vybraným typovým aplikačním software.
7. Řešení úlohy v kontextu domén řízení IT:
  • Strategické řízení IT (DO000 ):
    • 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 ).
8. 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.
9. 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 .
10. Klíčové aktivity úlohy „Zpracování úvodní studie – TASW“

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