logo ICT UNIE o.s.

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:

Investor:

Národní standardizační jednotka:

Projektový manažer (supervizor zadavatele):

Věcný gestor agendy:

Zadavatel (sponzor):

2.1.B. Role na straně dodavatelské

Architekt:

Architektonicko-projektantská kancelář:

Dodavatel:

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

Projektant:

Projektový dohled:

Projektový manažer (supervizor):

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

2.2 Dokumentace

Architektonická studie:

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

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

Implementační dokumentace:

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

Projektová dokumentace:

Smlouva o podpoře:

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

Zadávací dokumentace:

3 JAK IT PROJEKT PROBÍHÁ

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

ICT projekt:

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):

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:

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:

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.

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

  1. globální analýza (architekt)
  2. detailní analýza (projektant)
  3. design (implementátor IS)
  4. prototyp - technologický, funkční, procesní, designový (implementátor IS)
  5. vývoj (implementátor IS)
  6. testování - funkční (implementátor IS, zadavatel), integrační, výkonnostní, bezpečnostní (implementátor IS)
  7. pilotní provoz (implementátor IS, zadavatel)
  8. implementace (implementátor IS - překrývá se časově s některými předchozími etapami)
  9. předání do provozu (implementátor IS)
  10. 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ě
  11. 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)
  12. 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)
  13. 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:

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:

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:

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:

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ů:

Článek ICT UNIE o.s. ze dne 25. července 2012 - středa

Další články od ICT UNIE o.s.

Snahy o regulaci internetu rozdělují světové mocnosti

Regulace internetu na programu konference WCIT-12

Elektronická fakturace bez elektronických značek přináší možná rizika

VERA je novým členem ICT Unie

Znalecký ústav APOGEO Esteem je novým členem ICT Unie

ICT Unie a ČNFeH kritizují podobu zadání tendru na elektronizaci zdravotnictví v ČR

Diplomová práce roku 2012: soutěž zná své vítěze

Superurednik.cz: kampaň ICT Unie chce zvrátit negativní trendy ve využívání ICT v Česku

Provoz systému základních registrů veřejné správy není dosud smluvně zajištěn

Diplomová práce roku 2012: v soutěži se utká o vítězství téměř sto studentů

10 důvodů pro vypnutí ICT v ČR

Nepovedené ICT projekty ve veřejné správě

Stavíme informační systém

ARTIN a INVEA-TECH se staly členy ICT Unie

Seznam.cz členem do ICT Unie

Diplomová práce roku 2012: soutěž na podporu spolupráce mezi vysokoškolským prostředím a komerční sférou

CompuGroup Medical členem ICT Unie

CoolPeople a DAIN: noví členové ICT Unie

eHealth se v Česku prosazuje

CoolPeople a DAIN: noví členové ICT Unie

Elektronická fakturace v EU: ICT Unie se zapojuje do činnosti Evropského fóra pro e-fakturaci

Sdílené ICT služby přinesou vyšší efektivitu i úspory ve veřejné správě

NPR ČR 2012: Národní program reforem opomíjí důležitost oblastí ICT

Vítězné projekty soutěže IT Projekt roku 2011

ICT Unie vyzývá vládu k odborné diskusi o dohodě ACTA

HP je novým členem ICT Unie

SAP je novým členem ICT Unie

ICT Unie a Úřad průmyslového vlastnictví uzavřely memorandum o spolupráci