Hendelsesrapportering F/NLF Nytt hendelsesrapporteringssystem Beskrivelse av prosjekt for nytt hendelsesrapporteringssystem Frode Finnes Larsen F/NLF Fagseminar Mars 2009

Innhold Bakgrunn Prosjektplan Veien videre Diskusjon Problembeskrivelse Kartlegging og analyse av nå-situasjon Anbefaling fra C-kursoppgave 2008 Prosjektplan Veien videre Diskusjon Hendelsesrapporteringsprosessen og input fra lokale prosesseiere

Bakgrunn

Prosjektbakgrunn C-kursoppgave 2008 Målet med studien er å komme frem til en anbefaling som vil øke informasjonskvaliteten og redusere administrativt arbeid ifm hendelsesrapportering i både lokale og sentrale ledd. Det anbefalte forlaget skal være gjennomførbart innenfor rammene til FNLF.

Hendelsesrapportering FNLF er pålagt å ha rapporteringssystem Beskrevet i HB pkt. 505.5 Essensielt i sikkerhetsarbeidet Sikrer kontinuerlig forbedring

Problemer Dårlig informasjonskvalitet Hendelser kommer inn for sent eller aldri Flere manuelle ledd – kilder til feil Utdatert hendelsesrapporteringsskjema Vanskelig å bestemme årsaksforhold Dårlig struktur i database Krevende å lage gode rapporter og statistikk På grunn av dårlig informasjonskvalitet (grunnlagsdata ) Unødig administrasjon Tar tid å rapportere (lokale ledd) Tar tid å følge opp (lokale og sentrale ledd) Tar tid å rapportere og analysere (sentrale ledd)

Eksisterende prosess

Hendelsrapporten Faste punkter Utfylling ved feilfunksjon Fritekst Ingen datovalidering (el.) Utfylling ved feilfunksjon Tung og ulogisk struktur Udaterte valg Utfylling ved personskade Mangler flere årsaker

Hendelsrapporten HL/HI sine kommentarer Mangler støtte for bilder Vanskelig å bli kvitt fritekst Bør strukturere/veilede mer Mangler støtte for bilder Kan erstatte mange ord Design filosofi Denne siden bør oppleves som unødvendig for HL

System og infrastruktur

Forbedringer Todelt tilnærming Prosessforbedringer Arbeidsflyt Forbedring av rapport Systemforbedringer Forbedret arkitektur Teknologivalg

Forbedringer Systemalternativer 1. Ingen systemendring 2. Forbedring av dagens HTML skjema 3. Ny webapplikasjon

Anbefaling Fra C-oppgave 2008 Etablere et prosjekt for hendelsesrapportering Forbedre hendelsesrapporteringsprosessen Utvikle ny webapplikasjon Etablere en faggruppe for IT Jobbe langsiktig med forbedringer av prosesser Utvikle og implementere IT strategi for F/NLF

Faktorer Som påvirker ny løsning Lover og regler Økonomi Informasjonskvalitet Brukervennlighet Enkel forvaltning Rolle- og ansvarsfordeling Eksisterende system og infrastruktur

Prosessforbedring Forslag til ny prosess

Forbedringer av skjema Faste punkter Fritekst felt Personopplysninger, papirer, klubbinfo hentes fra Melwin med et web service kall. Utstyr kan gå mot en materiell database og tilgjengeliggjøres i grensesnittet. Det kan også legges direkte i grensesnitte om man ikke ønsker en database. Med mer moderne grensesnitt som Ajax, kan man få opp alternativer mens man skriver inn tekst. Datofelt Dette kan enkelt løses uavhengig av hvilken webteknologi man benytter. Selv for dagens HTML løsing kan man legge inn validering eller kaldender/datovelger basert på JavaScripts. Utfylling ved feilfunksjon Tung og ulogisk struktur Primært designspørsmål – tas etter besluttet løsing Grensesnittet bør lages med betingede menyvalg. Da vil skjermbildet endre seg underveis med utfyllingen. Slik at man kun har relevante valg. Det må også gjøres en jobb på databasesiden med å strukturere og kategorisere informasjonen. Men strukturen i databasen bør ikke være tett knyttet mot grensesnittet. Da mister man fleksibiliteten til å utforme effektive grensesnitt. Fritekstfeltet er mye brukt Dette løses med å ha gode alternativer blant de faste valgene. Da blir det enklere for HL å krysse av enn å skrive. Mange valg krever gode kategorier. Det henger på forrige punkt. Endringer mulige avkryss Her er det bare å endre alternative feilfunksjoner etter en hensiktsmessig kategorisering. Bilder Lage en valg i grensesnittet (hendelsesrapporten) der man kan laste opp noen bilder som er relevante for hendelsen. Det kan være materielle ting eller noe som viser landingsområde, demofelt, med mer. Når man senere henter opp saken i en nettleser, så har man også mulighet til å kikke på bildene.

Forbedringer av skjema Utfylles ved personskade Fritekst felt Samme virkemidler som nevnt tidligere. Nye felt Legges inn i skjema. HL og HI sine kommentarer Fritekstfelt Den beste måten å redusere bruken av disse på, er at brukeren/HL finner det mer hensiktsmessig og effektivt å fortelle den samme historien med noen museklikk. Så dette vil være en utfordring til utviklerne av grensesnittet. Her er det da viktig å benytte en web teknologi som gir stor fleksibilitet og mange muligheter. Men det vil være tilfeller der man må benytte fritekstfeltet, og da vil det hjelpe med en god beskrivelse/evt mal som styrer HL til å skrive relevant, kort og konsist.

Ny webapplikasjon Lage ny web-applikasjon Funksjonsrik teknologi (Ajax, mm.) Masse fleksibilitet og interaksjon (brukervennlighet) Tilgjengelig ”overalt” Melwin benyttes til autentisering og autorisering Melwin benyttes som database (?)

Ny webapplikasjon Merk: Kun illustrasjon Rollestyrt grensesnitt HL HI FNLF Statistikkansvarlig Fleksibelt og raskt Kan hente info fra ulike kilder

Hendelsesrapporteringsprosjektet

Prosjektmål Målet med prosjektet er forbedre informasjonskvaliteten og redusere administrativt arbeid ifm hendelsesrapportering i både lokale og sentrale ledd. Prosjektet skal videre legge til rette for videre automatisering og forbedring av F/NLF sine prosesser (fornyelse/utstedelse, hoppstatistikk, materielltjeneste, med mer.)

Prosjektleveranser Forbedret hendelsesrapporteringsprosess Nytt hendelsesrapporteringssystem Hendelsesrapportering Materiellrapport Opplæring av sentrale og lokale instanser Sentral støtte første 6 mnd.

Milepæler (tentativ) 31.04.2009 - Prosjektplan godkjent 15.08.2009 - Spesifikasjon og overordnet design godkjent 30.08.2009 - Ny hendelsesrapporteringsprosess godkjent 30.09.2009 - Systemdesign godkjent 30.11.2009 - Utvikling ferdigstilt 18.12.2009 - Akseptansetest 30.12.2009 - Produksjonssetting 01.01.2010 - ”Go live” (start handholding periode) 1Q 2010 - Presentasjon på fagseminar 2010 1H 2010 - Utrulling lokalt i klubbene 01.08.2010 - Lukking av prosjekt (slutt handholding periode)

Prosjektorganisering Styringsgruppe SU v/Morten Kristoffersen FNLF v/Jan Wang Prosjektgruppe Ressursgruppe Prosjektleder/arkitekt: Frode Finnes Larsen Teknisk ekspert 1: Einar Huseby Teknisk ekspert 2: Åpen Utviklere: Åpen Supportgruppe: Åpen Øystein T. Engelsen, statistikkansvarlig Jostein Tangen, MelWin Rolf, MSJ HI 1: Åpen HI 2: Åpen HI 3: Åpen

Prosjektkostnader Estimater ferdigstilles i prosjektplan Ramme: SU sitt budsjett til implementering Noe rom hos Jan Prinsipper Marginal økning i driftskostnader Tilstrebe lav implementeringskost Bruke studentgruppe, dugnadsånd

Veien videre…

Fremtidige utvidelser Materielldatabase Forbedring av utstedelse/fornying ”JumpRun” (ol.) integrasjon Service til klubbene Informasjon på lokale nettsider Medlemsregister (MelWin lokalt) IT strategi for FNLF (evt. NLF)

Diskusjon…

Diskusjon Lokale løsninger i dag? Lokale erfaringer? Lokal infrastruktur? Lokale behov? Egen statistikk, trender andre klubber, varsling, …

Støtteslides

Applikasjonsarkitektur Tradisjonelle applikasjoner Ingen separasjon data og presentasjon Ingen deling av data Lokale installasjoner Rik på funksjonalitet Flerlagsapplikasjoner Separasjon av presentasjons- og datalag Deling av data Web-sider Kun webbrowser (Internet Explorer) Primært presentasjon av informasjon Lite interaksjon og funksjonalitet Web-applikasjoner Det beste fra to verdener… Kun webbrowser (nyere Internet Explorer) Meget god interaksjon + laster data i bakgrunn

Web Services Teknikk for at et system skal dele/tilby funksjonalitet/data til et annet Gjøres over standard grensesnitt som er teknologi nøytralt HTTP HTTP HTTP Web Services Web Service eksempler finnMedlem(nakNr|navn) hentMedlemsinfo(nakNr) hentRapportListe(status, klubb) hentRapport(id) oppdaterRapport(id) hentTypegodkjenteSkjermer() f(x) MeLWin