1 Ústí nad Labem

2 Budování informačních systémů pro komunitní plánování Zpracoval: MUDr.Miroslav Seiner Obsahová část materiálu vznikla za finanční podpory projektu „Komunitní plánování jako nástroj pro posilování sociální soudržnosti a podporu sociálního začleňování a předcházení sociálnímu vyloučení znevýhodněných osob na trhu práce“ podpořeného v rámci iniciativy Equal Evropské unie. Materiál je využíván pro diseminaci projektu. Další informace naleznete na níže uvedených webových stránkách. Ústí nad Labem

3 Úvod

4 Čím se budeme zabývat ?  Jste aktivními účastníky komunitního plánování  V rámci přípravy komunitního plánování můžete dojít k závěru, že potřebujete k této činnosti  Využít větší soubor informací z jednoho či více informačních zdrojů  a/nebo vytvořit či převzít určitý informační systém, který vám tyto informace zajistí  Tato přednáška vás má seznámit s tím, jak k takovému úkolu přistoupit – metodicky správně

5 Osnova přednášky  Úvod  Definice záměru  Zadání  Cíle metriky a kritéria  Funkční a obecný popis záměru  Řízení rizik projektu  Analýza  Organizační zajištění a řízení projektu  Závěr

6 Co je to informační systém ?  Ucelená struktura technologických, programových a organizačních komponent, určená ke zpracování informací.  Informační systém není jen program,  ale také technologie, které ho zajistí – počítače, komunikace  a postupy, které je třeba provádět

7 Funkce informačního systému  IS pracuje s informacemi, ale co zajišťuje:  Vkládání, získání, pořizování informací  Ukládání informací  Přenos informací  Vyhledávání informací  Zpracování informací

8 Základní pojmový čtyřlístek  Informační proces  Informační systém  Informační projekt  Informační potřeba

9 Vztah mezi základními pojmy Informační procesy Informační projekt Informační systém Vede k realizaci Zajišťuje Informační potřeba naplňuje

10 Příklad  Krajský úřad zahájil projekt vytvoření a zavedení regionálního informačního systému sociálních služeb, který má zajistit proces zpracování informací o nabídce těchto služeb v kraji a jejich zprostředkování zájemcům.

11 Jaké role může v informačním projektu člověk mít...  Subjekty informací  Instituce  Osoby  Aktivní aktéři  Uživatelé  Příjemci informací  Jiné informační systémy  Zadavatelé  Investor  Iniciátor  Tvůrci zadání  Konzultanti Často jsme ve více než jedné roli...  Realizátoři  Analytici  Programátoři  Technologové  Provozovatelé

12 Úkol č.1: definice osobní role  Popište svoje očekávané role při eventuální realizaci jakéhokoliv informačního projektu v rámci komunitního plánování  Definujte přitom tu roli, která je nejtypičtější pro vás

13 Cíl metodiky  Je určena pro pracovníky, kteří se ocitnou v roli zadavatele informačního projektu  Cíle:  Seznámit s odpovědností a úkoly zadavatele při tvorbě informačního systému  Seznámit s některými důležitými technikami  Seznámit se standardní metodikou vedení informačního projektu  Připravit na diskusi o některých specifických problémech budování IS v komunitním plánování

14 Základní teze metodiky  Tvorba (zavedení) informačního systému vyžaduje aktivní účast zadavatele – tedy zástupce budoucích příjemců informací a uživatelů  Zadavatel musí rozumět určitým principům tvorby informačních systémů, aby byl tvůrcům (analytikům, programátorům) rovnocenným partnerem

15 Standardní průběh informačního projektu  Přípravná fáze  Definice záměru  Tvorba zadání  Studie proveditelnosti  Volba řešení a dodavatelů  Realizace  Analýza  Vlastní vývoj a implementace  Akceptace  Provoz Podtržené kroky – budeme probírat velmi podrobně vzhledem k jejich náročnosti pro zadavatele

16 Role zadavatele ve fázích informačního projektu FázeRole zadavatelů PřípravaFormulace záměru Tvorba zadání Volba řešení - dodavatele RealizaceKonzultační činnost Akceptace ProvozKontrola Formulace

17 Krok A Definice záměru

18 Proces definice záměru Jak je stav ? (východiska) Co chceme ? (popis – definice) Proč to chceme ? (cíle – přínosy) Potřeba postupného zpřesňování zadání Je jedno v které části kruhu začneme Kruh zpřesnění projdeme totiž několikrát Kde byste chtěli začít ?

19 Jak stručně definovat záměr  Měly by stačit tři věty:  Co máme = kde jsme ? Vnitřní východiska – současný stav řešení Vnější východiska: Dostupná řešení, legislativa, trendy ap.  Co chceme = kam se chceme dostat ? Co má informační systém „dělat“  Proč to chceme = co nám to má přinést? Jaký je cíl takového řešení ?

20 Příklad definice informačního záměru  Potřebuji v informačním systému evidovat výdaje své domácnosti, protože  Chci rodině dokázat, že správně hospodařím  Pořád mi vyčítají, že moc utrácím a já opravdu neumím vysvětlit, proč pořád nemáme peníze, protože nesleduji výdaje, proto

21 Úkol č.2: Popište stručně váš informační záměr  Vyberte raději jen dílčí část záměru, aby byl popis pro vás i okolí srozumitelný  Snažte se popsat záměr ve třech větách:  Co chci, aby systém řešil  Proč potřebuji, aby to bylo řešeno, co mi to přinese  Jaký stav je dnes  Při definici záměru si vytvořte skupiny, které budou dále řešit svůj záměr společně

22 Zadání informačního systému

23 Standardní průběh informačního projektu  Přípravná fáze  Definice záměru  Tvorba zadání  Studie proveditelnosti  Volba řešení a dodavatelů  Realizace  Analýza  Vlastní vývoj a implementace  Akceptace  Provoz Podtržené kroky – budeme probírat velmi podrobně vzhledem k jejich náročnosti pro zadavatele

24 Zadání informačního projektu  Klíčový dokument, kterým zadavatel popisuje svůj záměr a který je „materializací“ jeho podílu na projektu  Za zadání nese odpovědnost zadavatel (investor) – dodavatel může mít jen oponentní a metodickou roli  Zadání má svůj životní cyklus a prolíná se celým projektem  Zadání má určitou standardní strukturu, která se opakuje ve všech projektech

25 Životní cyklus zadání  Zadání informačního systému se vyvíjí:  Předběžný záměr  Zadání pro studii proveditelnosti  Zadání pro výběr řešení a partnera  Zadání realizace – jako součást smlouvy  Zadání jako součást plánu  Akceptace výsledku proti zadání

26 Standardní obsah zadání IS  Souhrn záměru  Východiska – popis stavu (vnější, vnitřní)  Kontext řešení  Cíle záměru  Metriky a kritéria naplnění cílů  Obecné (non-funkční) požadavky  Funkční požadavky  Rizika Označenými body se budeme zabývat důkladně

27 Popis stavu - východiska  Vnitřní (typické body)  Popis struktury, kde bude systém zaváděn  Dosavadní řešení problému  Odhad očekávaných změn  Personální zajištění  Vnější (typické body)  Legislativa a vnitřní předpisy  Stav řešení v analogických projektech

28 Kontext systému  Historický  Jaké systémy mají být nahrazeny  Jaké procesy musí být změněny  Jaká data mají být převedena !!!  Lokální  S jakými systémy bude komunikováno  Negativní věcné  Co do systému nepatří

29 Krok B Cíle, metriky, kritéria

30 Zásady stanovení cílů realizace IS  Jde o zásadní bod definice záměru  Obtížná definice „správných cílů“  Cílem je jen to, co může být kontrolováno (a změřeno)  Cíle  Klíčové - maximálně 3  Ostatní - nezměňovat s požadavky  Zamítnuté - užitečné si poznamenat, co nechceme

31 Kritéria a metriky naplnění  Metrika je způsob, jakým dosažení cíle měříme - metoda  Kritérium je hodnota metriky, kterou chceme dosáhnout  Kritérium naplnění cíle  Jeden cíl může mít více kritérií, ale musí mít alespoň jedno  U vedlejších cílů není třeba vždy exaktně měřit, ale je to vhodné  Poznámky  Nezapomínat i na možnost subjektivního hodnocení naplnění - dotazníky, ankety apod.

32 Standardní obsah zadání IS  Souhrn záměru  Východiska – popis stavu (vnější, vnitřní)  Kontext řešení  Cíle záměru  Metriky a kritéria naplnění cílů  Obecné (non-funkční) požadavky  Funkční požadavky  Rizika Označenými body se budeme zabývat důkladně

33 Úkol: Navrhnout cíle budoucího systému  Společně ve skupinách navrhnout klíčové cíle systému  Nadefinovat metriky, kterými budeme cíle měřit  Nadefinovat kritéria, která pro jednotlivé metriky stanovíte

34 Krok C Funkční popis záměru v zadání IS

35 Technika detailního funkčního popisu záměru  Popis případů užití  Jiná synonyma: Use-case Uživatelské scénáře Aktivity  Popisují konkrétní dílčí aktivity konkrétních aktérů  Uživatelské scénáře vždy „znají své role“  Nesnažíme se v této fázi o „návrh řešení“ pouze sbíráme funkční požadavky

36 Technika Uživatelské scénáře  Je třeba přitom definovat aktéry a jejich role  Popis obsahuje konkrétní aktivity činnosti uživatelů a rolí s budoucím systémem (i mimo něj)  Pozor: jeden aktér má i více rolí Eviduje příchody a odchody vrátný Získává statistiku využití pracovní doby ředitel Zobrazuje Individuální výkaz pracovníka pracovník Příklad: Systém evidence pracovní doby

37 Úkol: Popište ve skupině záměr IS pomocí uživatelských scénářů  Nebudeme již definovat dílčí, individuální záměry, ale jeden společný systém  Vytvářejte seznam rolí – aktérů v zamýšleném systému  Vytvářejte seznam scénářů  Doplňte seznam obecných požadavků

38 Krok D Stanovit obecné požadavky

39 Obecné požadavky  Kapacitní a výkonnostní  Pro kolik uživatelů, kolik stanic, kolik dat  S jakou odezvou, s jakými časy zpracování  Cenové, nákladové – za kolik ?  Termínové – do kdy ?  Technologické  Technická omezení  Dostupnost systému Určuje spolehlivost pro uživatele

40 Úkol: Doplnit zadání projektu  Ve společném záměru musíme dodefinovat společně:  Důležité informace o výchozím stavu  Obecné požadavky  Kontext  Poznámka: Definice rizik v další kapitole

41 Krok E Řízení rizik informačního projektu

42 S jakými riziky musíme počítat ?  Typy rizik  Rizika na straně zadavatele Nedostatek zdrojů, neujasněnost záměru, nepřijetí záměru uživateli, nepřijetí veřejností  Rizika na straně dodavatele Nedostatek zdrojů, nekvalita realizace  Rizika komunikační Neporozumění komunikace zadavatel - dodavatel  Rizika bezpečnostní Riziko ztráty či zničení dat Riziko zneužití dat  Rizika specifická

43 Zásady řízení rizik  Každé riziko je evidováno, jakmile je zjištěno  U každého rizika stanovujeme míru odpovědnosti  (Vysoká, Střední, Nízká)  U každého rizika stanovujeme možnou eliminaci a její potenciální úspěšnost  (Vysoká, Střední, Nízká)  Využití metody „zbytkového rizika“  Rozdíl mezi mírou rizika a účinností eliminace

44 Úkol: Definovat rizika projektu  Detekujte rizika dosud navrženého záměru a stanovte:  Míru rizika (třístupňově)  Kdy se riziko projeví (fáze)  Možnou eliminaci  Účinnost eliminace (třístupňově)

45 Krok F Analýza a návrh systému

46 Standardní průběh informačního projektu  Přípravná fáze  Definice záměru  Tvorba zadání  Studie proveditelnosti  Volba řešení a dodavatelů  Realizace  Analýza a návrh  Vlastní vývoj a implementace  Akceptace  Provoz Podtržené kroky – budeme probírat velmi podrobně vzhledem k jejich náročnosti pro zadavatele

47 Analýza a návrh  Fáze, kterou provádí dodavatel (řešitel)  Následuje po zadání, obsahuje minimálně:  Procesní popis  Analýzu dat  Funkční analýzu  Návrh uživatelského rozhraní  Technologickou architekturu  Postup implementace  Analýzu bezpečnosti

48 Komponenty analýzy které posuzuje zadavatel  Analýza a popis procesů  Definice uživatelských scénářů  Logický datový model  Návrh struktury programu  Uživatelské rozhraní Podtržené části – budeme probírat podrobně vzhledem k jejich náročnosti pro zadavatele

49 Procesní model  Popisují se všechny dotčené procesy  Dvoudimenzionální popis  Časová osa  Osa rolí (plavecké dráhy)  Procesní popis může zachytit i variantní průběhy procesů

50 Příklad procesního popisu KlientPoskytovatelSprávce Zadá nabídku do systému Aktivuje nabídku Zadá dotaz na službu Vyšle poptávku po zajištění služby Odpoví na poptávku Obdrží informaci o možnostech poskytovatele Obdrží informaci o míře uspokojení potřeb Samospráva Systém na evidenci poptávek a nabídek služeb

51 Logický model dat  Nepopisuje návrh technického řešení databáze, ale vztahy mezi daty v realitě  Umožňuje řešiteli ověřit si, zda porozuměl problematice  Popis obsahuje:  Popis tzv. tříd  Vztahy mezi třídami  Atributy jednotlivých tříd

52 Příklad logického modelu dat (Analytic Class Model) OrganizaceZařízení 1-N1 Poskytovaná služba má poskytuje 1-N 1 Typ služby 1 N Klient -Příjmení -Jméno -Rodné číslo -Adresa -Pohlaví konzumuje M N Služby pro klienta StátníNestátní

53 Úkol: Ověření srozumitelnosti analytických modelů  Popište formou procesního modelu některý z procesů, řešených v systému  Vytvořte logický model dat pro některou část zamýšleného systému (bez atributů)

54 Krok G Zajištění organizace informačního projektu

55 Proč jsou informační projekty tak rizikové ?  Informatika - relativně mladý obor s neustálenými postupy  Stále malé zapojení zadavatelů do tvorby IS a jejich pasivita  Obtížná průběžná validace výsledku  U projektů v sociálních a zdravotních službách navíc přistupují omezené finanční prostředky

56 Vztah dodavatel - zadavatel Dodavatel  Snaha o maximum zisku  Snaha vnutit určité řešení  Snaha vzbudit širší poptávku  Konkurence jiných zakázek  Problémy dodavatele Zadavatel  Neujasněnost záměru  Subjektivismus rozhodování  Omezenost zdrojů  Neznalost problematiky  Podceňování náročnosti  „Neobchodní“ přístup Potřeba vytvoření stabilního vztahu a úspěchu realizace

57 Řízení informačního projektu  Pro řízení projektu na straně zadavatele je třeba vytvořit řídící a výkonný tým  Řídící tým – Rada projektu Složení Ekonom, zástupce investora Technolog Manažer – koordinátor projektu Klíčoví uživatelé Řídící tým spolu s partnery dodavatele činí zásadní rozhodnutí na projektu  Výkonný tým projektu Konzultanti, uživatelé Informatici zadavatele ap.

58 Zásady pro řízení projektu radou projektu – řídícím týmem  Vazba na smlouvy a vnitřní směrnice  Písemně daná pravidla  Konsensuální rozhodování  Pečlivá dokumentace  Zásady projektového řízení (heterogenní zdroje)  Odpovědnost vrcholnému vedení organizace

59 Standardní průběh informačního projektu  Přípravná fáze  Definice záměru  Tvorba zadání  Studie proveditelnosti  Volba řešení a dodavatelů  Realizace  Analýza  Vlastní vývoj a implementace  Akceptace  Provoz Podtržené kroky – již probrány – zbývají poznámky k ostatním

60 Studie proveditelnosti  Základní otázky:  Je záměr realizovatelný ?  Za jaké náklady (finanční a personální) lze řešení pořídit ?  Jaké budou přínosy – peněžní i nepeněžní ?  Jaké jsou varianty řešení ?  Jak zajistit dlouhodobou udržitelnost  Jaká jsou rizika a jak je eliminovat ?  Základem pro smysluplnost studie je její nezávislost na kterékoliv variantě realizace  Nejen nezávislost finanční a dodavatelská, ale i „prestižní a znalostní“

61 Poznámky k procesu výběru řešení  Vybíráme nejen partnery k řešení, ale také způsob řešení, architekturu řešení  Důležitá je volba mezi možnostmi:  nákup systému  pronájem systému  nákup služeb  Většinou není pouze podstatné, kdo je dodavatelem, ale za jakých podmínek je uzavřen kontrakt

62 Akceptace  Klíčový moment realizace  Kvalita akceptace je podmíněna již jejím zakotvením v plánech a ve smlouvách  Kvalitní akceptace vyžaduje nemalé nároky na vnitřní zdroje  Nedostatky při akceptaci může být příčinou devalvace předchozích kroků projektu  POZOR: záruka nenahrazuje kvalitní akceptaci

63 Provozní aspekty NIS  Provozní náklady = 15% a více z pořizovacích nákladů  Provoz je rizikový z hlediska dlouhodobého zajištění potřebných zdrojů, stability produktu i dodavatelů, technologií ap.  Základní otázka:  Co koupit a co si jen pronajmout  Outsourcing proniká nejen do služeb ale i do technologií - není jednoznačná odpověď - vždy záleží na podmínkách smlouvy  Způsoby zajištění podpory uživatelů:  Help-desk, evidence požadavků a kontrola jejich plnění

64 Práce se zdroji na rozvoj  Náklady na informatiku jsou obecně podceňovány:  Neuvažují se následné náklady - platby za podporu, obnova technologií, aplikací  Nepočítají se dobře provozní náklady  Neurčují se dobře přínosy IS  Potřeba průběžného uvolňování nákladů a průběžné obnovy

65 Náklady IS  Náklady na výběr a pořízení  Investiční náklady na aplikace a technologie  Náklady provozní +Náklady na maintenance (údržbu) +Náklady komunikace +Náklady energií +Jiné provozní - tonery, papíry… +Náklady na obměnu +Náklady osobní +Náklady transakční - nepřímé vynucené náklady na provoz =TCO - Total Cost of Ownership

66 Bezpečnostní aspekty provozu  Každý IS je bezpečnostním rizikem  Odpovědnost vždy nese provozovatel (správce v terminologii zákona)  Na bezpečnost je třeba myslet již od tvorby záměru a zajistit ji při vývoji i v provozu  Technické a organizační prostředky zajištění  Tři pilíře bezpečnosti:  Strategie bezpečnosti  Výkon správy bezpečnosti  Kontrola (audit) bezpečnosti

67 Úkol: Zajištění řízení projektu  Definujte jmenovitě tým pro řízení projektu, obsaďte všechny klíčové role  Definujte oblasti, pro které budou jmenování klíčoví uživatelé  Definujte bezpečnostní rizika projektu, pokud jste je dosud nezachytili

68 Závěr

69 Závěr: co by mělo být výsledkem  Vědomí, že bez Vaší aktivní účasti nelze IS budovat  Ztráta ostychu při komunikaci s řešiteli  Znalost základních principů práce při tvorbě IS a povědomí o technikách  Opatrnost a vědomí rizik !

70 Závěr - klíčové faktory úspěchu  Týmový přístup k řešení  Včasné vybudování stabilního řešitelského týmu  Zájem vedení organizace o projekt  Schopnost definovat jasný cíl  Dodržení metodických zásad projektového řízení  Zajištění kontinuity kroků:  záměr- výběr řešení – smlouva - akceptace  Pamatovat stále na zdroje na provoz

71 Centrum komunitní práce Ústí nad Labem Koněvova 18, Ústí nad Labem tel.: Nashledanou V případě zájmu nás kontaktujte

72 Zpracoval: MUDr. Miroslav Seiner Obsahová část materiálu vznikla za finanční podpory projektu „Komunitní plánování jako nástroj pro posilování sociální soudržnosti a podporu sociálního začleňování a předcházení sociálnímu vyloučení znevýhodněných osob na trhu práce“ podpořeného v rámci iniciativy Equal Evropské unie. Materiál je využíván pro diseminaci projektu. Další informace naleznete na níže uvedených webových stránkách.