Modele referencyjne i standardy otwarte w ochronie zdrowia a czynniki sukcesu projektów informacyjnych Kazimierz Frączkowski Biuro Zarządzania Projektami PIOZ, CSIOZ, Warszawa k.fraczkowski@csioz.gov.pl Instytut Informatyki, PWr, Wrocław kazimierz.fraczkowski@pwr.wroc.pl Konferencja naukowa „Interoperacyjność i Efektywność Projektów e-Zdrowie” 20-21.12.2010 Warszawa

Plan prezentacji Podstawowe pojęcia i definicje? Stan świadomości, wiedzy oraz za i przeciw Modele referencyjne Standardy otwarte Stan badań współczynnika sukcesu i porażki projektów IT Badania własne dotyczące stanu wiedzy i poglądów jakie czynniki decydują o skuteczności projektów informatycznych w polskim środowisku IT, Wnioski. 02

Model referencyjny Model Referencyjny Współpracy Systemów Otwartych (ang. Reference Model Of Open Systems Interconnection) został opracowany w celu skoordynowania procesów tworzenia, rozwijania, adoptowania istniejących standardów komunikacji (wymiany informacji) między systemami otwartymi. Interconnection oznacza, nie tylko wymianę informacji między systemami otwartymi, ale również współpracę systemów otwartych w celu wykonania określonego, rozproszonego zadania.

Standard otwarty System jest otwarty, jeśli potrafi skomunikować się z innym systemem i spełnia standardy modelu referencyjnego, tzn. został zbudowany według standardów modelu referencyjnego. Współpraca Systemów Otwartych, (ang. Open Systems Interconnection) określa standardy wymiany informacji między systemami, które są na siebie ‘otwarte’ dzięki zastosowaniu jednakowych standardówKomunikacji (Model Referencyjny dla OSI ISO/IEC 7498)

Warunki jakie musi spełniać standard otwarty* przyjęty i zarządzany przez niedochodową organizację, a jego rozwój odbywa się w drodze otwartego procesu podejmowania decyzji (konsensusu, większości głosów, itp.), w którym mogą uczestniczyć wszyscy zainteresowani, opublikowany, a jego specyfikacja jest dostępna dla wszystkich zainteresowanych bezpłatnie lub po kosztach sporządzenia kopii oraz możliwa dla wszystkich do kopiowania, dystrybuowania i używania również bezpłatnie lub po kosztach operacyjnych, wszelkie związane z nim prawa autorskie, patenty i inna własność przemysłowa są nieodwołalnie udostępnione bez opłat, nie ma żadnych ograniczeń w jego wykorzystaniu. *Definicja opublikowana w 2004 roku przez Komisję Europejską.

Organizacje standaryzujące ISO CEN ANSI CEN/ TC251 ISO/ TC215 ISO – International Standard Organization CEN – (fr. Comité Européen de Normalisation) Europejski Komitet Normalizacji TC 215 – Technical Committee – amerykański komitet techniczny ISO ds. medycznych HISB – Health Information Standards Board ASTM – American Society for Testing and Materials - najstarsza organizacja standaryzująca, Podkomitet E31 zajmujący się healthcare (od 1970) DICOM – Digital Imaging and Communications In Medicine NCPDP – National Council for Prescription Drug Programs (1978) (ASC) X12 – Accredited Standards Committee X12 HISB ASTM DICOM NCPDP (ASC) X12 HL7

Jedyny powszechnie akceptowane i stosowany ? Gwint Edisona E27

ISO TC 215 - zakres Na każdym etapie komunikacji: 7. warstwa Aplikacji wykonywane są specyficzne zadania (funkcje, usługi), wykorzystywane są specyficzne aplikacje i urządzenia, wykorzystywane są specyficzne protokoły komunikacyjne. Warstwy Modelu Referencyjnego 7. warstwa Aplikacji 6. warstwa Prezentacji 5. warstwa Sesji 4. warstwa Transportowa 3. warstwa Sieci 2. warstwa Łącza Danych 1. warstwa Fizyczna. Poziom 7 – aplikacja – dotyczy: definicji danych, które mają być wymieniane, harmonogramu wymiany, komunikacji określonych błędów. Poziom 7 wspiera takie funkcje jak: sprawdzenie zabezpieczenia (security check) identyfikacji stron (participant identyfication), sprawdzenie dostępności (availability checks). mechanizmów negocjacji podczas wymiany danych oraz najważniejsze – struktury wymienianych danych. Np. nie zajmują się w tym komitecie standardami fizycznego przenoszenia pakietów informacji, sposobami nawiązywania komunikacji itp.

Ratownictwo medyczne szpitale Kontrola bezpieczeństwa dostępu Mobilny dostęp do EHR Systemy Medyczne szpitale Elektroniczny Rekord Pacjenta (EHR) Architektura zintegrowana Systemy kliniczne administracyjne Teleopieka dostęp do EHR Infrastruktura bazodanowa

Model platformy dla P1

Modele referencyjne procesów biznesowe oraz standardy i podstawą sukcesu e-Zdrowia Wiele grup użytkowników systemów eksploatowanych w szpitalu musi mieć świadomość integracji swoich działań poprzez unifikację i standardy (słownik nazw oddziałów, procedur, OPK, inne) Należy zapewnić mechanizmy bieżącego monitorowania spójności i kompletności wprowadzanych danych w czasie rzeczywistym

Za i przeciw standardom otwartym Fundacja Wolnego i Otwartego Oprogramowania (www.standardy.org.pl) Free Software Foundation Europe (FSFE) BSA European Interoperability Framework – EIF Plan Informatyzacji Państwa – zalecenie stosowania otwartych standardów CEN-GARTNER ? STORM Za Przeciw UE, Organizacje i stowarzyszenia Czołowe firmy na świecie IT, BSA Sposób na likwidacje monopolów firm Możliwość wymuszenia lojalności użytkowników Rządy krajów UE Zagrożenie dla innowacyjności Możliwość kreatywnego uczestnictwa w rozwoju oprogramowania Brak odpowiedzialnego za oprogramowanie

ISBSG- International Software Benchmarking Standards Group

The Standish Group Trends in IT Investments Copyright 2008 18 pages/ea. $2,500.00 Członek 35000,00 $

Badania własne czynników wpływających na sukces lub niepowodzenie projektów IT Zdefiniowanie celu oraz opracowanie planu realizacji projektu Wybór i przygotowanie środowiska do badań Opracowanie atrybutów metryk Post Mortem, oddanie ich pod ocenę uczestników projektów IT oraz PM, http://itresearch.iis.pwr.wroc.pl/ Modernizacja metryk i ich publikacja w celu gromadzenia danych o projektach IT Opracowanie raportów statystycznych dotyczących skuteczności realizowanych w Polsce projektów IT, na podstawie wypełnionych metryk Post Mortem. Możliwość porównania projektu w początkowej fazie do projektów zrealizowanych, w celu wczesnego zidentyfikowania ryzyka. 10

Etapy realizacji badań BAZA WIEDZY Z MODUŁEM RAPORTOWANIA Wnioski MODEL AKTUALIZACJI I ZARZĄDZANIA WIEDZĄ PROJEKTIT METRYKA PROJEKTU IT PROJEKT Jaki jest stan obecnie realizowanych projektów? Jak prowadzić dany projekt IT? Jakie są szanse na powodzenie danego projektu? Jakie są dla niego odnotowane zagrożenia? Doświa dczenie Eksperci dziedzinowi Raporty 09

Lista 10 najważniejszych atrybutów projektów IT lp atrybut projektu IT ocena deweloperów ocena kierowników średnia ocena 1 Rzeczywisty koszt projektu poniesiony przez wykonawcę 6,75 8,54 8,47 2 Rzeczywisty czas trwania projektu 8,25 8,21 8,35 3 Planowany koszt projektu poniesiony przez odbiorcę 6,00 8,29 4 Planowany czas trwania projektu 7,33 9,17 5 Planowany koszt projektu poniesiony przez wykonawcę 7,50 7,59 7,94 6 Rzeczywisty koszt projektu poniesiony przez odbiorcę 4,33 8,42 7 Doświadczenie wykonawcy w zakresie wytwarzania oprogramowania 7,00 7,64 7,88 8 Jaki nakład pracy użytkownika końcowego został włożony w projekt 7,67 7,87 9 Czy oczekiwania odbiorcy projektu zostały w zupełności zaspokojone 8,50 7,82 10 Czy produkt końcowy całkowicie pokrywa wyspecyfikowane wymagania 6,25 9,11 7,79 * W badaniach wzięło łącznie udział 76 osób z tego 45 % kierownicy projektów (stan na 13.04.2008) 13

Lista 10 najmniej istotnych atrybutów projektów IT lp atrubut projektu IT ocena deweloperów ocena kierowników średnia ocena 1 Wielkość słownika systemowego 4,25 2,40 4,64 2 Wielkość rocznych obrotów kapitałowych wykonawcy projektu 4,75 2,37 4,73 3 Wielkość słownika biznesowego 4,00 2,55 4,79 4 Ilość ekranów 5,00 3,54 4,88 5 Ilość zatrudnianych pracowników przez odbiorcę projektu 3,00 4,92 5,06 6 Liczba linii kodu 7 Łączna liczba wykrytych, w trakcie tworzenia oprogramowania, błędów nieznacznych, nie czyniących oprogramowania niesprawnym w żadnym znaczeniu 5,59 5,12 8 Ilość zatrudnianych pracowników przez wykonawcę projektu 6,50 5,82 5,25 9 Serwer / serwery z jakich będzie korzystać wytwarzana aplikacja 5,79 5,29 10 Rodzaj docelowej platformy sprzętowej 3,50 5,96 5,31 15

Badania współczynnika sukcesu i porażki projektów IT realizowanych na świecie Standish Group Report 2006: „Obecnie jest mniej chaosu w projektach informatycznych” Jim Johnson w najnowszym raporcie The Standish Group przedstawia 3 powody poprawy jakości oprogramowania: *lepsze zarządzanie projektami *podejście iteratywne * Poprawa infrastruktury WEB Źródło: Opracowanie własne na podstawie raportów The Standish Group 07

Czynniki sukcesu projektu* Zaangażowanie klienta 15,5% Wspomaganie kierownictwa 13,9% Jasne określenie wymagań 13,0% Właściwe planowanie 9,6% Realistyczne analizowanie 8,2% Mniejsze odstępy między punktami kontrolnymi 7,7% Kompetencje pracowników 7,2% Odpowiedzialność 5,3% Jasno sprecyzowane cele 2,9% Ciężko pracujący pracownicy 2,4% Inne 13,9% * wg. Badań Standish Group 2005 r

Standardy procesów biznesowych w Szpitalach podstawą integracji systemów informatycznych Wiele grup użytkowników systemów eksploatowanych w szpitalu musi mieć świadomość integracji swoich działań poprzez unifikację i standardy (słownik nazw oddziałów, procedur, OPK, inne) Należy zapewnić mechanizmy bieżącego monitorowania spójności i kompletności wprowadzanych danych w czasie rzeczywistym

Materiał badawczy Badanie prowadzone jest od marca 2010 Informacje nt. projektów gromadzone są poprzez ankietę dostępną na portalu www.pmresearch.pl Zapytania kierowano do osób realizujących projekty w różnych obszarach gospodarki i administracji poprzez akcje mailingową i wywiady bezpośrednie z udziałem: Polskiego Towarzystwa Informatycznego Stowarzyszenia Projekt Management Polska Project Management Instytut Instytut Informatyki Politechniki Wrocławskiej Metoda badania ankieta kierowana do PM oraz osób, które miały wiedzę nt. zrealizowanych projektów Uzyskaliśmy informacje o ponad 150 projektach, do analizy wzięto tylko 80 projekty, o których uzyskaliśmy komplet wymaganych danych zawartych w ankietach.

Rodzaj badanych projektów wg. klasyfikacji

Co decyduje o sukcesie projektów IT ? Wielkość projektu i jego złożoność ? Doświadczenie PM ? Posiadanie certyfikatu przez PM (Prince, PMP, IPMA) ? Odstępy miedzy punktami kontrolnymi ? Użyta metodyka wytwarzania oprogramowania ? Rodzaj projektu ? Nadzór projektu i jego rola w projekcie? Zaangażowanie sponsora/beneficjenta ? Liczba prowadzonych projektów przez organizacje ? Umiejętności i technika zakresie zarządzania ryzykiem? Czy i jakie dokumenty zarządcze mają są najważniejsze ? Inne….

Szersze przedstawienie wyników badań zostanie udostępnione zarejestrowanym użytkownikom portalu www.pmresearch.pl

Zamiast wniosków

Kazimierz Frączkowski Dziękujemy za uwagę Kazimierz Frączkowski 16