Budování informačních systémů pro komunitní plánování

Ústí nad Labem

1

Budování informačních systémů pro komunitní plánování

Ústí nad Labem

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.

2

Úvod

3

Čí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ě

4

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

5

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

6

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í 7

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

Vztah mezi základními pojmy Informační projekt Vede k realizaci

Vede k realizaci

Informační procesy

Informační systém Zajišťuje

naplňuje

Informační potřeba 9

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

Jaké role může v informačním projektu člověk mít...  Zadavatelé

 Investor  Iniciátor  Tvůrci zadání  Konzultanti

 Aktivní aktéři  Uživatelé  Příjemci informací  Jiné informační systémy

 Realizátoři  Analytici  Programátoři  Technologové  Provozovatelé

 Subjekty informací  Instituce  Osoby Často jsme ve více než jedné 11 roli...

Ú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 12

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í

13

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 14

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

15

Role zadavatele ve fázích informačního projektu Fáze Příprava

Realizace Provoz

Role zadavatelů Formulace záměru Tvorba zadání Volba řešení - dodavatele Konzultační činnost Akceptace Kontrola Formulace

16

Krok A Definice záměru 17

Proces definice záměru Co chceme ?

Jak je stav ?

(popis – definice)

(východiska)

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

Proč to chceme ? (cíle – přínosy)

Kde byste chtěli začít ? 18

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í ? 19

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 20

Ú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ě 21

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





 Provoz


23

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 24

Ž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í 25

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ě 26

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 27

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ří 28

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

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 30

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.

31

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ě 32

Ú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

33

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

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 35

Technika Uživatelské scénáře Příklad: Systém evidence pracovní doby

 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í

vrátný

ředitel

Eviduje příchody a odchody Získává statistiku využití pracovní doby Zobrazuje Individuální výkaz pracovníka

pracovník

36

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

37

Krok D Stanovit obecné požadavky 38

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

39

Ú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

40

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

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á

42

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 43

Ú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ě) 44

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




 Realizace  Analýza a návrh  Vlastní vývoj a implementace  Akceptace

 Provoz


46

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 47

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 48

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

Příklad procesního popisu Klient

Poskytovatel

Správce

Samospráva

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

Systém na evidenci poptávek a nabídek služeb

Obdrží informaci o míře uspokojení potřeb 50

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 51

Příklad logického modelu dat (Analytic Class Model) Organizace

1

1-N má

Zařízení

Typ služby

1 Státní

Nestátní

1

poskytuje 1-N

Klient -Příjmení -Jméno -Rodné číslo -Adresa -Pohlaví

konzumuje

N

N Poskytovaná služba

M Služby pro klienta 52

Ú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ů) 53

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

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

55

Vztah dodavatel - zadavatel Zadavatel  Neujasněnost záměru  Subjektivismus rozhodování  Omezenost zdrojů  Neznalost problematiky  Podceňování náročnosti  „Neobchodní“ přístup

Dodavatel  Snaha o maximum zisku  Snaha vnutit určité řešení  Snaha vzbudit širší poptávku  Konkurence jiných zakázek  Problémy dodavatele

Potřeba vytvoření stabilního vztahu a úspěchu realizace

56

Ří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.

57

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 58





 Provoz

Podtržené kroky – již probrány – zbývají poznámky k ostatním 59

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í“

60

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 61

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 62

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í 63

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 64

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 65

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

66

Ú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 67

68

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 ! 69

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

70

Centrum komunitní práce Ústí nad Labem Koněvova 18, 400 01 Ústí nad Labem [email protected]; [email protected] www.ckpul.cz; www.komunitniplanovani.com tel.: +420 475 201 096

Nashledanou V případě zájmu nás kontaktujte 71

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.

72

Budování informačních systémů pro komunitní plánování

Recommend Documents