Utfordring, tiltak og status:

Transkript

1 Utfordring, tiltak og status: Organisasjon, bemanning og kompetanse Komplisert og tidkrevende for systemeierskap å få et helhetlig bilde av både utfordringer og ansvarsområde, spesielt i forhold til NISSY. 1 Avdekke både utfordringer og ansvarsområde, spesielt i forhold til NISSY. Overføring av nøkkelkompetanse om systemene NISSY og PRO. Udokumenterte prosesser knyttet til systemeierskap NISSY. 2 Sikre kompetanseoverføring og løpende vurdere nødvendige justeringer for å sikre overføringen av nøkkelkompetanse fra nåværende systemeier til løsningsarkitekt og systemeier i Pasientreiser ANS. 3 Beskrive hvordan en kan måle effekten av de enkelte prosesser knyttet til ivaretakelsen av systemeierskapet for NISSY. Tjenesteleveranse Begrenset forankring og enighet om definisjoner av nivå på tjenestene som RHF får fra programvare- og drifts- leverandør. 4 Avklare forventet SLA- nivå fra brukere i NISSY og vurdere det mot det som er avtalefestet. 5 Avklare forventet SLA- nivå fra brukere i PRO og vurdere det mot det som er avtalefestet. 6 Etablere et klart definert ansvarskart basert på det som ligger til grunn i dagens avtaler i forhold til NISSY. Dette gjøres i fellesskap med leverandører og skal tydelig vise hvilke aktører som er ansvarlig for de ulike delene av tjenestene som den enkelte sluttbruker skal ha tilgang til. 7 Etablere ett klart definert ansvarskart basert på det som ligger til grunn i dagens avtaler i forhold til PRO. Dette gjøres i fellesskap med leverandører og skal tydelig vise hvilke aktører som er ansvarlig for de ulike delene av tjenestene som den enkelte sluttbruker skal ha tilgang til. 8 NHN etablerer samhandlingsprosesser med programvareleverandørene og definerer tydelig når en skal behøve å involvere Pasientreiser ANS og hvilke oppgaver som kan gå uten involvering. Side 1 av 5

2 9 Om det avdekkes at forventningene er høyere enn det som dagens avtaler ivaretar må det vurderes om det er mulig å nå det som forventes og hvilken kostnad det vil ha. Presentere kostnad og effekt til styret for et vedtak om hvilket nivå en skal legge seg på. 10 Synkronisere leverandørens tolkning av avtalen med kundens tolkning og definere de vanligste tjenestene kort og konsist, gjerne i form av et bilag til gjeldende avtale. Pasientreiser ANS har ikke noe avtaleforhold med EPJ-leverandører og systemleverandører til taxinæringen. 11 Vurdere om nåværende måling/rapportering til Pasientreiser ANS fra NHN og programvareleverandører er tilfredsstillende. 12 EPJ-leverandører - Definere sammen med jurist hvordan staten som gir primærleger godkjennelse for å drive egen praksis også kan definere et sett med regler for krav til pasienttransport som må følges. 13 Lokal infrastruktur på det enkelte pasientreisekontor - etablere en prosess som sikrer at Pasientreiser ANS har en samhandling med de enkelte HF som har avtaleforhold for lokal infrastruktur. 14 Sonic og Helsenettet - Sikre at vi kan levere de tjenester som vi er satt til å levere. 15 Systemleverandører til taxinæringen - etablere et sett formuleringer som er juridisk gjennomarbeidet og som kan legges inn i avtaler som inngås med taxisentraler og andre transportører (tekniske leverandører til taxinæringen - taxisentraler - HF - ANS ). Svakheter i hvordan informasjon og avgjørelser knyttet til IKT til nå har vært kommunisert mellom Pasientreiser ANS og det enkelte HF. 16 Etablere en felles forståelse av hvilken informasjon og hvilke avgjørelser som skal håndteres på hvilken måte. 17 Etablere en kommunikasjonsplan. 18 Etablere et optimalt sett med samhandlingsfora og tilhørende mandater. Også fora / grupper / involvering rundt eksisterende samhandlingsfora som funksjonelle arbeidsgrupper og SEF. Utilfredstilte behov over flere år i forhold til styringsinformasjon fra NISSY, spesielt produksjonsinformasjon. 19 Avdekke hva som mangler av rapporter i forhold til det sett med rapporter som finnes og bestille de manglende rapportene. 20 Etablere en prosess som involverer utvalgte ressurser fra nivåer relevant for de enkelte rapportbehov som sikrer at en kan få beskrevet, bestilt, testet og levert de rapporter som er ønskelig. Side 2 av 5

3 21 Utrede en dynamisk rapportløsning hvor vurdering og anbefaling fremmes for representanter for brukermiljøet og eventuell kostnad fremmes i styret til Pasientreiser ANS. Leverandøroppfølging Manglende tjenesteavtaler mellom drift / programvareleverandører og RHF / Pasientreiser ANS. 22 Avdekke både utfordringer og ansvarsområde, spesielt i forhold til NISSY. 23 Basert på dagens avtale: Etablere definert SLA i forhold til oppetid fordelt på sentral infrastruktur (HW, switcher), Sonic, helsenettet og lokal infrastruktur ute hos bruker. 24 Etablere SLA på tjenester som det mangler SLA på utover oppetid (responstider på feil, support eller andre tjenester som er definert i dagens avtaler). 25 Identifisere gap og tiltak for å tette eventuelle gap med kost/nytte vurdering. Harmonisere avtaler med tanke på SLA- nivå, dekningsperiode, kategorisering, måling/overvåking og rapportering. Ny funksjonalitet fra programvareleverandør inneholder feil og testrapporter er mangelfulle. Ny funksjonalitet som leveres fra programvareleverandør er tidvis noe annet enn det som er bestilt. 26 Avklare ønsket grad av involvering i programvareleverandørs smidige utviklingsprosess for personell hos Pasientreiser ANS. 27 Etablere dokumentasjon knyttet til test som viser hva som er testet og hvordan. Det skal foreligge en testplan, dokumentasjon av testprosedyrer og en oppsummering av testfasen i en testrapport. 28 Etablere en forståelse fra eiere og brukere til sammenhengen mellom antall releaser og oppetid. 29 Fjerne de feil i programvaren som er mulig å avdekke i dagens konfigurering av TREF før programvaren flyttes fra TREF til QA og fjerne de feil i programvaren som er mulig å avdekke i dagens konfigurering av QA før programvaren flyttes fra QA til produksjon. Side 3 av 5

4 30 Forbedre dagens endringsprosess fra det identifiseres et behov for endring av programvaren til endringen er satt i drift og ikke forårsaker feil. Etablere tilstrekkelige avsjekkpunkter både i forkant av bestilling og underveis i utviklingen etter bestilling som muliggjør korrigering underveis i utviklingen om det avdekkes at noe utvikles i en annen retning enn det som funksjonell arbeidsgruppe har definert. Bedre kvalitetssikring av funksjonalitet. Vurdere "modell" for bestilling og utvikling av ny funksjonalitet. 31 Hva er det som er mulig / ikke mulig å avdekke i miljøene som finnes i dag i forhold til det som er mulig med nye tiltak. Avklare hva som er mulig å utvide / endre i TREF og QA for å avdekke feil tidligere i testmiljøene enn i dag (kost / nytte vurdering). 32 Vurdere QA miljø ift PROD. QA skal være så likt PROD som mulig. Avklare hva som er mulig å utvide / endre i TREF og QA for å avdekke feil tidligere i testmiljøene enn i dag (kost / nytte vurdering). Stadige feil i infrastruktur hos driftsleverandør fører til nedetid og ustabilitet. 33 Bruke Sonic optimalt (kjøre WS trafikk utenom Sonic) Unngå avhengighet av Sonic på synkron WS trafikk. Sonic er ikke spesielt egnet for synkron webservertrafikk. 34 Fjerne unødvendige feilhendelser. 35 Om en har tilstrekkelig bemanning for å få gjort unna saker innen rimelig tid, må en se på hvordan arbeidet er organisert. Være mer tydelig på ansvarlig, frister etc. og frister som ikke overholdes må få konsekvenser. Kontinuerlig vurdering av egen kapasitet, kompetanse og organisering - Mulighet for å fordele belastning. - Sterkere koordinering/prioritering av oppgaver og ressursbruk. 36 Overvåking: Vurdere eksisterende verktøy for overvåking. Evaluere Actional for overvåking. Tilgang til produksjon/overvåking hos Norsk Helsenett. Side 4 av 5

5 37 Øke grad av proaktivitet (fjerne kilder til feil, unngå at feil oppstår) - Bruke helsesjekker fra programvareleverandører som underlag til mulige justeringer og forbedringer. - Kontinuerlig utskifte/oppgradering av hardware/os. - Re-factoring. Identifisere deler som bør endres ift arkitektur/implementasjon. Tilfeller der programvareleverandør og driftsleverandør er uenige om hva som er årsak til feil og hvem som er ansvarlig for å fjerne feil permanent. 38 Etablere eskaleringsmulighet i de tilfeller det er nødvendig. Rutine for eskalering av tiltak som ikke iverksettes eller der Acando/NHN Ikke er enige om årsak/tiltak mangler. Pasientreiser ANS må komme i god posisjon til å utøve sin rolle som kontraktspart med alle leverandørene. 39 Utføre feilreduserende tiltak og sikre at det fokuseres på å finne kilden til feil (rotårsak til feil). Prosess for proaktivitet og kontinuerlig forbedring av systemet. NHN og Acando avtaler fortløpende tiltak for forbedring. Oppfølging av iverksatte og ikke iverksatte tiltak kan forbedres. Trege og uferdige leveranser samt feil og uorden i fakturaer fra Sykehuspartner. 40 Sykehuspartner etablerer prosesser som sikrer at Pasientreiser ANS får løpende tilbakemeldinger på fremdrift og problemer knyttet til alle bestilte leveranser fra Sykehuspartner. 41 Sykehuspartner etablerer prosesser som sikrer at Pasientreiser ANS kun får fakturaer i forhold til det som er definert i gjeldende avtaler og/eller fakturaer knyttet til nye bestillinger som er gjort og hvor detaljer rundt bestillingen er godkjent av Pasientreiser ANS. 42 Sykehuspartner etablerer prosesser som sikrer svar på våre henvendelser. Side 5 av 5