HackMD6 Aplikované informační systémy
PV028
tags: řvss, informační-systémy, pv028
Aplikované informační systémy. Informační systémy a jejich role v řízení, jejich cíle, problémy analýzy a návrhu. Problematika IS v oblastech výroby, státní správy, zdravotnictví. Geografické IS. (PV028)
Okrem úvodu sú všetky informácie a vytiahnuté získané iba z Ráčkových videí.
Treba to brať s rezervou.
Informační systémy a jejich role v řízení, jejich cíle, problémy analýzy a návrhu.
Informační systém je soubor lidí, technických prostředků a metod (programů), zabezpečujících sběr, přenos, zpracování, uchování dat, za účelem prezentace informací
pro potřeby uživatelů činných v systémech řízení.
Aplikační software je programové vybavení počítače, které umožňuje provádět nějakou
užitečnou činnost. Aplikace využívají pro interakci s uživatelem grafické nebo textové
rozhraní, případně příkazový řádek. Aplikace se může skládat z několika počítačových
programů. Mezi aplikace neřadíme systémový software (firmware, OS).
Aplikačný informačný systém (?) - rozsiahle systémy pracujúce nad spoločnými datami, “aplikace tak rozsáhla, že jí nazveme informačním systémem”
Podnikový informační systém vytvářejí lidé, kteří prostřednictvím dostupných technologických prostředků a stanovené metodologie zpracovávají podniková data a vytvářejí z nich informační a znalostní bázi organizace, sloužící k řízení podnikových procesů, manažerského rozhodování a správě podnikové agendy.
Vlastnosti IS
- sada programů integrovaná do jednoho celku, který má plnit určité úlohy nikoli pro jednoho uživatele, nýbrž pro celou organizaci.
- Všichni uživatelé pracují s týmiž daty, uloženými ve společné databázi (najčastejšie relačné, môže to byť aj ale napr. document management system , NoSQL, xml súbory atď.), a za výsledek proto zodpovídají společně. Nestačí, aby správně, přesně a včas svou práci udělal uživatel sám, stejně musí jednat i jeho kolegové. Když někdo udělá chybu, následek se může projevit v jiném útvaru resp. až po čase.
- Programy, které jsou součástí IS, (obvykle) neběží na počítačích jednotlivých uživatelů, ale na nějakém výkonném serveru (serverech) a uživatelé s nimi komunikují prostřednictvím své klientské stanice, v tzv. režimu klient-server. Komunikace se serverem probíhá na dálku. Klientem může být desktop, notebook, tablet, mobil atď.
- primárne vyvíjané pre desktopy,laptopy
- mobilné rozhrania sú často súčasťou IS, ale sú koncipované pre konkrétne situácie, nemajú plný rozsah funkcionality celého IS
Problematika IS v oblastech výroby, státní správy, zdravotnictví.
Oblasť výroby
IS pre podnik špecializujúci sa na predaj batérií
- pôvodne malá firma, ktorá začala expandovať (viaceré sklady, expanzia do zahraničia, noví zákazníci - hypermarkety)
- majiteľ doposiaľ sám pokrýval množstvo funkcií (dáta v exceloch, notesoch), teraz to už nestíhal
Analýza
- procesná analýza by tu bola problematická
- množstvo dátových tokov a dátových úložíšť, ktoré by bolo treba modelovať
- zvolili teda prístup modelovania cez data-flow diagram
- terminátory (aktéri)
- obchodník, hypermarket, zákazník, vedúci veľkoobchodu…
- viaceré z nich vykonával ten istý človek (majiteľ firmy, Ernest)
- procesy
- výdaj zo skladu, doplňovanie skladu, plánovanie sortimentu, predaj zákazníkom, sledovanie stavu
- dátové zdroje
- informácie od zákazníkov (kto koľko čoho objednal)
- plán predaja (komu koľko čoho predáme)
- sklad zboží (aktuálny stav)
- problém: 3 rôzne databáze s prekrývajúcimi sa dátami
- synchronizácia medzi nimi prebiehala procesom "sledovanie stavu", ktorý vykonával sám majiteľ
- synchronizácia bola problematická: stávalo sa že sa doobjednal tovar, pretože na sklade chýbal, avšak bol v dodávke -> keď sa dodávka vrátila na sklad, zistilo sa že daného tovaru je priveľa
- terminátory (aktéri)
Návrh
Navrhnutý data flow diagram
- procesy
- Ekonomika
- Prodej
- Logistika
- Monitoring
- firmu zaujímalo hlavne koľko je toho skladom, a koľko je objednané zákazníkmi
- riešené cez horné a dolné dorazy
- vymedzujú rozsah, koľko zboží chceme mať na sklade
- ak je ho menej ako dolný doraz, musíme doobjednať
- ak je ho viac ako horný doraz, je ho prebytok
- riešené cez horné a dolné dorazy
Dátový model
- katalóg zboží (typy zboží)
- substitút zboží (nahraditeľné typy zboží, ak je daný nedostupný, ponúkame podobný)
- dorazy (vysvetlené vyššie)
- zboží (konkrétne zboží, s dátumom nákupu/objednania/predaja/rezervácie)
- sklady (v ktorých je zboží uložené)
- šoféri v dodávkach majú tablety, ktorými real-time updatujú stav pri nakladaní/vykladaní
- obchodníci (kto má dané zboží rezervované)
Štátna správa
IS pre Ministerstvo životného prostredia
- konkrétne pre organizáciu CENIA (Česká informační agentura životního prostředí)
- projekt: Analýza a návrh enviromentálnych dátových modelov a vonkajších rozhraní JISŽP kompatibilných s EÚ
- JISŽP - Jednotný informačný systém životného prostredia (ŽP)
- EÚ má definované požiadavky na dáta, ktoré musia štáty vykazovať
- v ČR bolo množstvo rôznych dátových zdrojov ohľadom životného prostredia (dáta z ČHMU, znečistenie ovzdušia, odpad…)
- niektoré dáta, ktoré EÚ vyžaduje nemá ČR dostupné
- naopak niektoré dáta, ktoré ČR zbiera, EÚ nevyžaduje (sú zbierané zbytočné)
- cieľ: urobiť v tom poriadok
- EÚ legislatíva reportov: pyramída MDIAR
- tento systém mal pokrývať spodné 3 vrstvy
- tento systém mal pokrývať spodné 3 vrstvy
- časti projektu:
- kompletná analýza požiadaviek
- analýza signifikantných dátovych zdrojov (aktuálne dátove zdroje ohľadom ŽP dostupné v ČR)
- návrh centrálneho dátového modelu
- prístup
- dátová analýza
- analýza signifikantných dátových zdrojov
- enviromentálne a zdravotnícke IS mávajú najväčšie dátové modely
- procesná analýza
- na základe legislatívy EÚ
- snaha napasovať procesy na signifikantné dátove zdroje
- dátová analýza
Schéma analýzy
Logický dátový model
Výsledok
- aplikácia v PHP
- zlúčenie 410 dátových zdrojov (je ich veľa, kôli rôznym regionálnym zdrojom)
Zmluvy na IS
- projekt: Vládny legislatívny helpdesk
- poradňa pre otázky ohľadom legislatívnych postupov
- napr. ak zákon pripomienkuje združenie záhradkárov, v legislatíve sa pravdepodobne nevyznajú, tak potrebuju poradiť
Zmluva
Štruktúra zmluvy:
- úvodné ustanovenie
- vysvetlenie kontextu
- že helpdesk bude súčasťou väčšieho ISu
- predmet zmluvy
- dodanie IS Helpdesk
- popis dodávaného systému
- požiadavky na vývojový tím
- kvalifikácia (požadované životopisy + čestné prehlásenie)
- napr. certifikát PRINCE2, IPMA, alebo diplom zo školy daného zamerania
- miesto a doba plnenia
- miesto je sídlo poskytovateľa
- detailné vymedzenie termínov jednotlivých fáz vývoja
- cena diela a podmienky
- priebežné splácanie celkovej ceny, podľa termínov fáz definovaných v predošlej sekcii
- licenčné ujednanie
- 2 typy:
- výhradné: po predaní je výhradným vlastníkom systému zákazník, poskytovateľ ho nemôže ďalej používať
- nevýhradné: poskytovateľ môže daný systém ďalej používať, napríklad ako základ systému pre iného zákazníka (výhodnejšia varianta)
- 2 typy:
- ochrana dôverných informácií
- napr. podľa ISO 27000 (ISMS)
- ochrana osobných údajov
- záruka na dielo
- na koľko mesiacov je definovaná (v tomto prípade bolo na 36)
- pri chybe je povinnosť opravy do určitého času (v tomto prípade bolo 5 dní)
- sankcie
- uhradiť 0,5% z ceny systému za každý deň nedodržania termínu
- 100k CZK za porušenie podmienok zmluvy (napr. porušenie definovanej ochrany informácií)
- poistenie
- v tejto zmluve zákazník vyžadoval od poskytovateľa pojistenie zodpovednosti
- poistenie ak napríklad pracovník vymaže zákaznícku databázu
- vysoké poistné plnenie (12M CZK)
- v tejto zmluve zákazník vyžadoval od poskytovateľa pojistenie zodpovednosti
Prílohy
- definícia požiadavkov (súčasný stav, problémy súčasného stavu, žiadúci budúci stav, ciele nového systému, procesná schéma, štuktúra)
- dokument s textom a jednoduchými diagramami
- technické řešení provádění díla
- harmonogram prác (rovnaké fázy vývoja ako v sekcii o dobe plnenia)
Servisné zmluvy
- projekt: Vládny legislatívny helpdesk (rovnaký ako predošlý)
- zmluva na podporu/údržbu systému po jeho nasadení zákazníkovi
- podporu môže poskytovať poskytovateľ, ktorý vytvoril systém (výhodnejšie), alebo iný poskytovateľ
Štruktúra zmluvy
- úvodné ustanovenia (podobne ako v predošlej zmluve)
- predmet zmluvy
- úvadza povinnosti, ktoré je poskytovateľ povinný za mesačnú platbu vykonávať
- Incident management
- reakcia na chyby hlásené zákazníkom
- povinnosť v danom čase chybu opraviť
- Change management
- nové zákaznícke požiadavky
- Konzultace
- treba si dávať pozor, aby boli nejako obmedzené, inak nás nimi môže zákazník zahĺtiť
- Profylaxe
- pravidelné prehliadky systému (výhodné pre poskytovateľa)
- znižujú počet incidentov, na ktoré bude treba reagovať
- Školenie používateľov (napr. e-learning)
- miesto plnenia
- sídlo objednávateľa (zákazníka)
- doba platnosti
- zväčša na dobu neurčitú
- stanovenie ceny, fakturácia
- paušálna cena (mesačná platba), nesúvisí s počtom incidentov
- za pár rokov provozu systému zvyčajne cena za servis prekročí cenu za systém samotný
- práva a povinnosti
- ochrana dôverných informácií
- povinná poistka
Prílohy
- Service Level Agreement (SLA)
- obsahuje číselné hodnoty hovoriace o časoch a kvalite hlavne incident managementu
- servisné hodiny (5 x 10h alebo 7 x 24h)
- Incident Management
- odozva (response time, čas na reakciu na zákaznícky ticket)
- riešenie problému
- odstránenie problému (fix time)
- incidenty delené na priority
- high
- medium
- low
- pre každú prioritu definuje iný reponse time a fix time
- výhoda: ak je fix time 10h, a servisné hodiny 5x10h, znamená to, že každý požiadavok stačí vyriešiť na druhý deň
- ak nie sme schopní vyriešiť ticket do stanoveného fix time, môžeme ticket otočiť na zákazníka, s nejakou žiadosťou o dáta, o ktorej vieme, že mu zaberie dlhý čas -> tým získame viac času, počas ktorého môžeme ticket riešiť
- definuje penále za nedodržanie dohodnutých časov
- odrátáva sa z ceny, ktorú zákazník platí
- v najhoršom prípade môže byť nulová, nemôže sa stať, že budeme my platiť zákazníkovi
- Change management
- zákazník môže zadať požiadavku o zmenu
- máme nejaký čas na analýzu a nacenenie
- malé zmeny, do 15 človekohodín sú predplatené
- dajú sa preniesť do ďalšieho mesiace
- prenášať sa môžu max. 3 mesiace
- veľké zmeny majú definovanú cenu za človekohodinu
- pri naceňovaní teda stačí odhadnúť pracnosť v človekohodinách
- Profylaxe
- periodická prehliadka
- zákazníka niečo stojí, no znižuje množstvo incidentov
- robí sa napr. každých 6-12 mesiacov
- trvá cca 1 pracovný týždeň
- výsledkom je profylaktická správa
- upozorňuje zákazníka na možné budúce problémy
Verejné zakázky - Zadávací dokumentace
Projekt: SW analýza v prostředí Ministerstva školství, mládeže a tělovýchovy
- analýza SW a procesná analýza nového intranetu ministerstva školstva
- zákazky sú zadané zväčša súborovou štruktúrou s hlavným podpísaným PDF (Zadávacia dokumentácia) a viacerými prílohami
- prílohy: návrh smlouvy, cenová tabuľka, vzory čestných prehlásení…
Zadávacia dokumentácia
Štruktúra
- názov
- portál pre komunikáciu so zadávateľom, prihlasovanie sa na zakázku (URL)
- predmet zakázky
- účel
- obecný popis
- klasifikácia (kódy podľa číselníka)
- predpokladaná hodnota
- suma, ktorú ponuka nemôže prekročiť
- kvalifikácia (podmienky na poskytovateľa)
- základná spôsobilosť (nemať nedoplatky, nebyť trestaný…)
- profesná spôsobilosť (výpisy z obchodného registra, o vykonávaní podobných zákaziek v minulosti…)
- technická spôsobilosť
- referencie
- certifikáty
- zoznam významných vykonaných služieb (či sme za posledné 3 roky robili podobný projekt za definovanú cenu)
- osoby a ich kvalifikácie (diplomy, životopisy + čestné prehlásenia)
- hodnotiace kritériá
- sú hlavne o cene, ohodnotienie uchádzačov 100 bodmi
- 70 bodov je za najnižšiu cenu
- ďalšie body je možné získať za ponúkanú kvalitu
- definuje aké výpisy musíme dodať
- certifikáty
- cenová ponuka
- prehlásenie o poddodávateľoch
- návrh zmluvy (vopred podpísaný, tým pádom ak uspejeme, rovno s nami podpíšu zmluvu -> po zadaní ponuky ju teda nemôžme zrušiť, návrh zmluvy je už podaný)
- …
Projekt: STaR - Statistika a reporting
- pre Ministerstvo pro místní rozvoj ČR
Tu iba porovnával zadávaciu dokumentáciu s tou prvou, a poukazoval na rozdiely, a na to, že táto je zbytočne zložitá, napr. zbytočné komplexný rozpad ceny na malé časti, keď na konci aj tak vyberali poskytovateľa podľa celkovej ceny
Odhadovanie ceny (ponuky)
- na základe požiadaviek definovaných v zadávacej dokumentácii
- použili metódu PERT (viz. téma Projektové řízení) pre ohodnotenie každej požiadavky
Zdravotníctvo
Prednáška popisuje Use Case pre IS vo fakultnej nemocnici u sv. Anny. Prof. Ráček následne hovorí o tom, ako robili analýzu pre tvorbu IS vo FN v Bohunicích podľa use casov a softwaru u sv. Anny.
- Aj v zdanlivo rovnakých a prepojených inštitútoch (FN Bohunice a FN sv. Anny) môže byť mnoho veci riešených úplne inak
- IS nemocnic (NIS) generujú neuveriteľné množstvo najrôznejších štatistík a prehľadov
- rôzne štatistiky pre management, štatistiky o liečivách, vydaných receptoch, a mnoho ďalších.
- nemocnica sa o tieto štatistiky musí starať, posielať ich ďalej na rôzne úrady
- Nemocnice vykonajú úkony, tieto úkony preposielajú poisťovnam. Tie za prevedené úkony nemocniciach platia.
- Typy importu dát podľa potreby:
- spúšťa časovač, pretože sa to deje periodicky v definovanom časovom intervale
- spúšťa externý systém, keď sú dáta pripravené k importu
- spúšťa lekár, keď potrebuje dáta odniekiaľ získať
- Dôležité rozhrania, ktorými NIS disponuje sú rozhrania na systémy, ktoré robia vyšetrenia alebo pořizují zdravotnická data
- obrazové data - data z RTG, Ultrazvuky a pod.
- laboratórne vyšetrenia - 2 typy, pre oba typy obvykle 2 samostatné rozhrania
- chemická analýza - stopy chem. látok či prvkov v krvi
- biologická analýza - stopy organizmov (vírusy, baktérie)
- V FN Bohunice funguje (alebo fungovala?) potrubní pošta
- odobraté vzorky krvi sa pošlú potrubnou poštou do laboratórií a cez IS sa naspäť už pošlú data
- so vzorkami zároveň putovala informácia o tom, koho je to krv (prúvodka?) do lab. v papierovej podobe
- potrubná pošta bola zároveň dátovým nosičom IS
- Odhadnutie práce pri tvorbe IS napr. pomocou metodiky COCOMO a metódy funkčných bodov
Základné členenie všetkých nemocničných IS v ČR:
- péče o pacienty, hospitalizace, ambulance, sú tam štatistiky, je tam nejaký modul pre poisťovne, importy a exporty dát, viď use case diagram pri FN sv. Anny
UC diagram NIS u sv. Anny
Use Case v Bohunicích vytvorený na základe use casu NIS u sv. Anny
žltá - potrebná modifikácia, pretože štýl prace v Bohunícich oproti sv. Anne je iný
červená - úplne nový use case, potrebné vytvoriť (napr. u sv. Anny nie je/v čase tvorby prezentovaného dokumentu nebola pôrodnica)
zelená - minimálne úpravy, možná prenositeľnosť medzi NIS
biela - use case bude priblížený detailnejšie, kde už budú zvyšné farby (Ž,Č,Z) viditeľné
Péče o pacienty
- všetky informácie pri všetkých úkonoch musia byť zaznamenané v nejakej “datovej vete” - napr. pri péči o pacientoch je “táto” veta preposlaná poistovni a na základe nej poisťovňa úkon preplatí
- Hospodářka sa stará o finančný chod danej kliniky, pořizuje dáta pre poisťovne
Regulačné poplatky
- jeden z príkladov, ako sa improvizovalo, keď sa zmenila legislatíva a nebolo ľahké to zakomponovať do IS, ktorý nikdy predtým poplatky nevyberal.
- v prípade nezaplatenia poplatku mal “blokovať” ďalšiu zdravotnú péči
- vznikli, aby pacienti nezneužívali zdravotnú péči zadarmo
- regulačné poplatky vznikli, keď IS už existovali
- nemocnice dosť improvizovali
- niektoré sa to snažili vložiť do ekonomických modulov, mali pokladňu a vyberali poplatky pri príjme pacienta
- niektoré pri parkovaní v automate vyberali zároveň poplatok
Ambulantní péče (FN sv. Anna)
Procesní analýza poskytovaní ambulantní péče (FN Bohunice)
Hospitalizace
Poisťovne
Zaujímavý prípad diametrálnych rozdielov v ekonomických oddeleniach dvoch príbuzných nemocníc
Bohunice
Bola zriadená rola “datozberačky”. Tá zbierala data, čo za úkony sa urobili, dávala ich do tabuliek. V Bohuniciach je mnoho klinik, každá mala svoju rolu datozberačky. Z kliník datozberačky zaniesli data do centra, kde boli datozberačky iných kategórií, ktorí data z kliník dávali dokopy za celú nemocnicu, radili úkony do správneho poradia, aby to poisťovňa zaplatila. Poisťovňa platí iba úkony prevedené hospodárne, teda najprv chcete previesť lacné vyšetrenia, aby vylúčila potrebu provedení drahého vyšetrenia - tento reťazec vyšetrení musí byť nejako poskladaný.
Radenie IS v Bohuniciach vôbec neriešil.
Pri zlom zoradení to poisťovňa vrátila na prepracovanie.
sv. Anna
sv. Anna si kúpila rovnaký software ako poisťovne, ktorý vedel úkony zoradiť pred zaslaním do poisťovne, nič sa prepracovanie sa nevracalo, žiadni datozberači neboli potrební.
Vyššie náklady na vstupe, no v konečnom dôsledku oveľa efektívnejšie.
