Stavíme informační systém

Cílem dokumentu, který vznikl ve spolupráci ICT Unie a Rady vlády pro konkurenceschopnost a informační společnost (RVKIS), je vytvořit podklad pro usnadnění dosažení souladu v chápání rozsahu a komplexnosti ICT zakázky mezi zadavatelem a dodavatelem.

1. ÚVOD

Dokument "Stavíme informační systém" má ambici sjednotit klíčové pojmy tak, aby vznikl slovník pojmů, díky kterému by zadavatelé a dodavatelé mohli mluvit stejnou řečí. Pro uvědomění si kontextu byla jako vhodná paralela pro připodobnění, díky hmatatelnosti a široké znalosti pojmosloví ve společnosti, vybrána oblast stavebních projektů a zakázek.

Na příkladu stavebního projektu chceme názorně popsat ideální postupy při defi nici zadání, ověření realizovatelnosti, návrhu řešení, zadání poptávky, nákupu, realizaci a vlastním provozu (užívání) informačního systému, či případné likvidaci původního řešení, a to včetně jednotlivých kompetencí nutných pro hladký průběh naznačených aktivit a naznačení vhodného obsahu výstupů jednotlivých fází.

Základním vymezením tohoto dokumentu je předpoklad, že řešení jako takové se týká povinné agendy veřejné správy (agendy definované příslušnou legislativou) a vhodným řešením je informační systém. Cílem dokumentu tedy není doporučovat vhodné postupy pro nákup ICT komodit nebo standardizovaných řešení, ale pro unikátní řešení určená zpravidla pro podporu výkonu konkrétní agendy nebo oblasti činností zadavatele.

Jedná se tedy o doporučení směřující k nastavení rolí, odpovědností, dokumentace a procesů při zajištění řešení na úrovni ICT služeb podporujících služby veřejné správy.

Níže uvedené "best practice" je třeba vždy používat s přihlédnutím zejména k fi nančnímu rozsahu Vámi realizovaného projektu a adekvátně rozhodnout o rozsahu aplikace definovaných principů včetně využití jednotlivých rolí.

2. SLOVNÍK

Výkladový slovník pojmosloví je rozdělen do dvou částí - role a dokumenty. Výklad je zpracován v takovém rozsahu, aby názorně objasnil pojem, aniž by zachytil veškeré možné alternativy, naopak extrahuje koncentrovanou obvyklost.

2.1.A. Role na straně zadavatelské

Hlavní architekt eGovernmentu:

osoba odpovědná za efektivní tvorbu, rozvoj a dozor nad implementací strategií v oblasti eGovernmentu
garantuje konzistenci připravovaných projektů s celkovou koncepcí eGovernmentu v ČR
koordinuje architektury kmenových projektů

Investor:

osoba nebo subjekt zajišťující investici do odsouhlaseného řešení
nejčastěji je investor zároveň zadavatelem

Národní standardizační jednotka:

odpovídá za dodržování vydaných architektonických, technologických a bezpečnostních standardů
vydává stanovisko k naplňování Národního architektonického plánu

Projektový manažer (supervizor zadavatele):

má odpovědnost za průběh realizace dodávky odsouhlaseného řešení
řídí projekt napříč liniovou strukturou organizace
jsou mu dány kompetence a pravomoci
je partnerem pro jednání s dodavateli

Věcný gestor agendy:

spolupracuje na tvorbě architektonického záměru (globální architektury)
poskytuje informace o předpokládaném průběhu výkonu agendy
osoba nebo subjekt pověřený výkonem dané agendy
definuje (funkční) požadavky na výsledné řešení

Zadavatel (sponzor):

osoba nebo subjekt zodpovědný za výběr dodavatelů a průběh dodávky odsouhlaseného řešení
nejčastěji zahrnuje i investora a věcné gestory agendy

2.1.B. Role na straně dodavatelské

Architekt:

pomáhá věcnému gestorovi se zhmotněním představy projektu a vytváří architektonický záměr (globální architekturu)
v průběhu výběru architekta předkládá zadavateli architektonickou studii
v rámci realizace projektu zajišťuje architektonický dozor
dává projektu rámec, umí projekt usadit do souvztažností
spolupracuje s hlavním architektem eGovernmentu

Architektonicko-projektantská kancelář:

zpravidla se jedná o jeden subjekt nebo sdružení subjektů (konsorcium, sdružení dodavatelů na základě subdodavatelského vztahu) poskytující obě kompetence (role Architekt i Projektant)
dodává role Architekt a Projektant

Dodavatel:

nejčastěji zahrnuje architektonicko-projektantskou kancelář (ve vybraných případech může být architekt a projektant dodáván různými subjekty), projektový dohled (pokud jej zadavatel nerealizuje vlastními silami), implementátor informačního systému a provozovatel řešení (ve vybraných případech může být implementátor informačního systému a provozovatel řešení dodáván různými subjekty)
externí osoba nebo subjekt zajišťující dodávky pro dosažení odsouhlaseného řešení

Implementátor informačního systému:

dodává technologie jako součást realizace informačního systému nebo připravuje technickou specifi kaci infrastruktury (zejména závazné parametry, které musí infrastruktura a její případný dodavatel splnit) a technologie integruje do informačního systému
realizuje zakázku podle projektové dokumentace (prováděcí projekt, technická specifi kace řešení)
implementuje řešení do procesů zadavatele

Projektant:

vytvoří takové podklady, podle kterých lze projekt realizovat, případně zadat k realizaci, a to v souladu s architektonickým záměrem
nese plnou odpovědnost za soulad svých výstupů s architektonickým záměrem
přebírá na sebe odpovědnost a rizika za správnost a realizovatelnost zadání
definuje parametry, které musí být splněny

Projektový dohled:

je vybaven odpovídajícími pravomocemi (ve vybraných případech je oprávněn i pozastavit realizaci dodávky)
přebírá na sebe odpovědnost za správnost realizace v souladu se zadáním (resp. nabídkou)
spolupracuje s projektovým manažerem (supervizorem) zadavatele
vede dokumentaci o průběhu projektu ("stavební deník")
kontroluje veškeré předem stanovené dílčí výstupy
řídí na straně zadavatele změnová řízení
kontroluje shodu se zadáním a nabídkou
má odpovídající know-how a zkušenosti

Projektový manažer (supervizor):

spolupracuje s projektovým manažerem (supervizorem) zadavatele
má zodpovědnost za průběh realizace projektu
řídí projekt napříč liniovou strukturou instituce
jsou mu dány kompetence a pravomoci
je partnerem pro jednání s dodavateli

Provozovatel řešení (Facility manažer v ICT prostředí):

je konzultován v případě implementace jiného systému majícího dopad na jím provozované řešení nebo na infrastrukturu, v níž je jeho řešení provozováno
zajišťuje správu a údržbu realizovaného řešení v dané infrastruktuře (opravy chyb)
řídí aktualizaci řešení (nové verze)

2.2 Dokumentace

Architektonická studie:

návrh hlavních funkcí systému, věcného řešení potřeb a souvislostí, které nemají být opomenuty, resp. klíčové know-how (princip, klíč řešení)
architektonická studie je později rozpracována do podoby architektonického záměru
návrh architektury řešení předkládaný zadavateli během výběru architekta

Architektonický záměr (globální architektura):

studie proveditelnosti - cost-benefit analýza (CBA)
architektura řešení (globální, konceptuální)

Dokumentace o průběhu projektu ("Stavební deník"):

řízená dokumentace definovaná metodikou řízení projektu
zahrnuje i dokumentaci ke změnovým řízením

Implementační dokumentace:

uživatelská, školicí a programátorská dokumentace (v souladu se zákonem č. 365/2000 Sb.)
provozní dokumentace
zdrojové kódy

Podklady (dokumentace) ke „kolaudaci“ a převzetí díla:

dokumentace předávaná zadavateli nebo investorovi v okamžiku "kolaudace" a převzetí díla všemi zúčastněnými dodavateli (případně dalšími subjekty)

Projektová dokumentace:

plán kvality (akceptační kritéria jednotlivých komponent řešení)
prováděcí projekt (detailní analýza, detailní architektura)
technický projekt (technická specifikace řešení)
pravidla řízení změn projektu

Smlouva o podpoře:

vymezuje rámec běžného (rutinního) provozu
SLA (Service Level Agreement)

Věcné zadání (důvodová zpráva pro investora):

přehledový dokument shrnující popis agendy a potřebnost a přínosy zajištění této agendy informačním systémem

Zadávací dokumentace:

její součástí by měla být projektová dokumentace (prováděcí a technický projekt)
dokumentace sloužící zadavateli k výběru budoucího dodavatele

3 JAK IT PROJEKT PROBÍHÁ

eGovernment je definován Národním architektonickým plánem:

v plánu jsou zahrnuta stávající technologická i aplikační řešení včetně průřezově poskytovaných
plán zahrnuje "území" definovaná zákonným zmocněním (agendou)
jde o plánovité vymezení projektů eGovernmentu
existuje "úřad hlavního architekta eGovernmentu"

ICT projekt:

architekt zpracuje architekturu řešení (studii, resp. záměr); navrhne elektronizaci procesů vykonávání agendy, technologický rámec, bezpečnostní rámec apod.
projektant díla zpracuje projektovou dokumentaci; spočítá požadavky na zátěž řešení, definuje akceptační kritéria apod.)
implementátor vytvoří a dodá IS

Dozor projektu, akceptace, provoz ICT řešení a vyřazení řešení z provozu a archivace dat.

3.1 "Chci postavit dům"

"Musím zajistit výkon agendy definované příslušnou legislativou a chci pro to postavit informační systém."

Veškeré úsilí a činnosti se odehrávají ve věcné rovině. Budoucí zadavatel cítí potřebu (nebo je povinován legislativním požadavkem na zabezpečení konkrétní agendy) najít vhodné řešení budoucího stavu. Cílem této fáze je získat představu o potřebnosti / nutnosti, rozsahu, náročnosti, výsledcích a přínosech uvažovaného řešení.

Potřebné kroky a výstupy

Konkrétní specifikace potřeby / požadavku na zabezpečení konkrétní agendy, určení (věcného) gestora agendy a rozhodnutí o vhodné variantě, schválení věcného záměru příslušnou úrovní investora.

Sepsání věcného zadání (důvodová zpráva pro investora):

detailní potřeby zadavatele - co má informační systém řešit a v rámci jaké agendy / legislativy
jaký bude přínos informačního systému / jaká hrozí rizika v případě nerealizace
kdo bude informační systém a jeho výstupy užívat (cílové skupiny řešení)
představa o finančním rozsahu
základní porovnání variant

3.2 "Dá se to postavit tak, jak si představuji?"

Veškeré úsilí a činnosti shromažďují podklady pro rozhodnutí - "Je to možné, nebo to není možné?"

Potřebné kroky a výstupy:

ve variantách zjistit proveditelnost a porovnat fi nanční náklady na realizaci a provoz informačního systému oproti přínosům řešení, projekt ověřit finančně
vybrat architekta, resp. architektonicko-projektantskou kancelář5 a architektem nechat zpracovat architektonický záměr / globální návrh
ověřit parametry navrhovaného řešení - zda jsou v souladu s aktuálním stavem politiky a strategie eGovernmentu
architektonický záměr komunikovat a nechat schválit hlavním architektem eGovernmentu
porovnat nabídnuté architektonické studie (pozor na ochranu autorských práv)
vytvořit Studii proveditelnosti jako sumarizaci výše uvedeného
oslovit architekty, vyjasnit zadání

3.3 "Dokumentace ke stavbě a stavební dozor"

Dříve, než je spuštěna realizace, je nutné mít všechno připraveno - jedině tak je umožněna kontrola termínů, kvality a nákladů. Investice do přípravy se násobně vrátí při realizaci. Důkladným zpracováním projektové dokumentace je přenesena odpovědnost z investora na architekta, resp. projektanta.

Existují-li dvě samostatné role - architekt a projektant - je první kontrola provedena zpracováním projektové dokumentace projektantem nad architektonickým návrhem architekta. Realizaci projektu dle výstupů architekta i projektanta pak kontroluje projektový dohled.

Potřebné kroky a výstupy

Zpracovat jednotlivé typy dokumentací pro následnou realizaci projektu:

nechat projektanta rozpracovat architektonický záměr do podoby projektové dokumentace, tedy do podoby prováděcího projektu (detailní analýza, detailní architektura) a technické specifi kace řešení v souladu s Národní standardizační jednotkou
zajistit si služby projektového dohledu (pokud není pro projekt přínosné, aby tuto roli plnila architektonicko-projektantská kancelář)
rozhodnout o ukončení provozu původního řešení, popřípadě naplánování souběžného provozu (pokud je to nezbytné)
pokud je potřeba, připravit zadávací dokumentaci (spolupracující role - zadavatel, architekt, projektant, právník apod.)
zajistit služby projektanta (pokud nejsou využívány služby architektonicko-projektantské kanceláře)
zajistit schválení projektové dokumentace Národní standardizační jednotkou
zajistit služby implementátora informačního systému

3.4 "Vlastní stavba"

Realizace informačního systému není úkolem pouze implementátora informačního systému - úspěch závisí na kvalitě součinnosti všech stran: zadavatele, implementátora informačního systému, architekta, projektanta a projektového dohledu.

Projekt musí být řízen dle standardních projektových metodik (Prince2, PMBOK apod.) upravených pro potřeby konkrétního projektu.

protipólem implementátora informačního systému je projektový manažer (supervizor) zadavatele nebo projektový dohled, který může plnit roli projektového manažera zadavatele
za řízení projektu je primárně odpovědný implementátor informačního systému, včetně správy kompletního harmonogramu (úkoly všech zúčastněných stran)
v průběhu realizace projektu vzniká dokumentace o průběhu projektu (řízená dokumentace definovaná použitou metodikou řízení projektu)

Projekt by měl být rozdělen minimálně na následující etapy:

globální analýza (architekt)
detailní analýza (projektant)
design (implementátor IS)
prototyp - technologický, funkční, procesní, designový (implementátor IS)
vývoj (implementátor IS)
testování - funkční (implementátor IS, zadavatel), integrační, výkonnostní, bezpečnostní (implementátor IS)
pilotní provoz (implementátor IS, zadavatel)
implementace (implementátor IS - překrývá se časově s některými předchozími etapami)
předání do provozu (implementátor IS)
každá etapa musí mít předem definován plán kvality včetně akceptačních kritérií navazujících na KPI6 definovaná v Zadávací dokumentaci, resp. Smlouvě
zadavatel by měl být zapojen do průběžného plnění všech etap tak, aby sdílel maximální množství znalostí o výstupech - odborné kapacity pro konzultaci obsahu řešené agendy, případně i vlastní analytické nebo programátorské kapacity (vlastní nebo externí kapacity)
chybovost při testování (funkčním a integračním) před přechodem do provozu by měla být hodnocena na základě předem daných parametrů - při překročení dohodnutého procenta chyb by implementátor IS měl poskytnout např. slevu dle výše překročení; do počtu chyb se započítávají i chyby zjištěné ihned po startu ostrého provozu (např. první měsíc provozu)
je možné využít zádržné jako nástroj ukončení realizace dodávky informačního systému

3.4.1 Implementace

Implementací rozumíme zavedení informačního systému do procesů zákazníka.

Součástí implementace je:

příprava a ověření funkčnosti infrastruktury (hardware včetně zálohování, software, komunikační linky apod.)
školení uživatelů (školitelů), administrátorů a helpdesku, včetně závěrečných testů
instalace a konfigurace systému včetně zavedení uživatelů a přístupových práv
předání odpovídající dokumentace
migrace dat

3.4.2 Náběh provozní fáze

Bezproblémový rozjezd provozu informačního systému je velmi důležitý pro jeho vnímání jak uživateli, tak odpovědnými zástupci investora.

Klíčové v prvních týdnech provozu je:

interní marketing - výsledné řešení (informační systém) je potřeba "prodat" dovnitř organizace, tzn. interní komunikací zdůraznit význam tohoto řešení pro organizaci i pro jeho jednotlivé uživatele
PR výsledného řešení - připravit témata, která se budou komunikovat vně organizace a zvolit vhodné komunikační nástroje (tisková prohlášení, články v odborném tisku a internetových portálech, vystoupení na konferencích atd.)
častější vyhodnocování stavu provozu s cílem minimalizace rizik při náběhu provozu
kontinuální a zvýšená podpora uživatelů v užívání informačního systému

3.4.3 "Kolaudace"

Podmínka nutná k užívání díla. Jedná se o protokolární-písemný akt stvrzující všemi (zadavatel, investor, architekt, projektant, projektový dohled, implementátor informačního systému) stranami, že dílo je předáváno v určeném rozsahu, funkcionalitě a definovaných parametrech (chybovost funkčních a integračních testů nepřesahující stanovené limity, výkon - odezva, neexistují závažné odchylky od architektonického záměru a projektové dokumentace atp.).

Podklady (dokumentace) ke "kolaudaci" a převzetí díla:

pro informační systémy veřejné správy také povinná dokumentace podle zákona č. 365/2000 Sb. (provozní dokumentace - bezpečnostní politika, bezpečnostní směrnice bezpečnostního správce, systémová dokumentace - příručka správce, příručka administrátora, uživatelská příručka)
dokumentace o průběhu projektu (zápisy z řídících výborů, zápisy z jednání projektových týmů, protokoly a dokumentace ze změnových a akceptačních řízení apod.)
protokol o testování (všechny testy proběhly dle předem stanoveného zadání, neexistují závažné chyby bránící přechodu do ostrého provozu)
aktualizovaná dokumentace díla (u aplikačního vývoje aktuální zdrojové kódy a dokumentace aplikace)
uživatelská, školicí a programátorská dokumentace, včetně zdrojových kódů
projektová dokumentace (prováděcí a technický projekt)
věcné zadání (důvodová zpráva pro investora)
provozní dokumentace ("návod k používání")
pravidla poimplementační podpory - servisu
architektonický záměr

3.5 "Užívání domu a jeho správa"

Rámec běžného (rutinního) provozu je zpravidla vymezen smlouvou o podpoře nebo SLA, kde jsou popsány parametry podpory (čas podpory, reakční doba podle závažnosti nahlášené chyby, příp. doba odstranění chyby atd.). Tyto parametry jsou pravidelně vyhodnocovány a jejich neplnění může být sankcionováno. Smlouva o podpoře může obsahovat i další rozvoj informačního systému, a to zejména dle požadavků příslušné legislativy.

Pokud je to pro výsledné řešení nebo investora (zadavatele) přínosné, je možné zajistit si služby provozovatele řešení (Facility manažera) i od jiného subjektu nežli implementátora informačního systému.

Pravidelné činnosti:

řízené nasazování dalších verzí informačního systému (změny, opravy chyb), striktní zavedení konfiguračního managementu verzí informačního systému obsahujících opravy a/nebo změny, včetně jejich dvoustupňového testování (implementátor informačního systému, zadavatel) a rozdílového školení uživatelů a administrátorů
provoz helpdesku a vyhodnocování tohoto provozu (počty chyb nebo změn a vyhodnocování jejich zpracování)
získávání zpětné vazby od uživatelů např. prostřednictvím dotazníků (měření spokojenosti uživatelů)
monitoring provozu (výkonnost, poruchovost, bezpečnost) a jeho optimalizace
průběžná aktualizace dokumentace s každou úpravou, resp. verzí systému
PR výsledného řešení - např. komunikace přínosu informačního systému
dodatečná a doplňková školení uživatelů a administrátorů
sběr požadavků na rozvoj a rozhodnutí o jejich realizaci
pravidelné vyhodnocování plnění SLA

3.6 "Co se starým domem?"

Řešení, které je novým projektem nahrazováno, je třeba systémově "zakonzervovat".

Jde o realizaci těchto procesů: