Page History
...
| Excerpt | ||
|---|---|---|
| ||
Dette dokument beskriver NSP Incident management processen |
SDS Incident Management
...
Processen gælder for incidents der er indmeldt fra de enheder der supporterer brugere af de systemer, som SDS stiller til rådighed for parter i sundhedsvæsenet. Dette gælder således Produktions-, test- og uddannelses-miljøer.
Formålet med processen er at sikre en ensartet, struktureret, effektiv og dokumenteret behandling af incidents vedrørende de relevante løsninger. Processen skal være gennemskuelig for alle involverede parter. Samtidigt skal processen sikre en afstemt og præcis kommunikation til alle relevante interessenter for alle incidents. Dette gælder både udmeldinger på NSPOP og direkte kommunikation med primære interessenter ved P1 og P2 incidents.
Procesdokumentation
Incident Management Proces flow og beskrivelse
Beslutningsregler ved løsning af 24-7 incidentsIncidents
...
Termer og definitioner for 24-7 systemerne
Kategorisering (prioritet) af Incidents
Incident kategoriseres i forhold til impact (indvirkning på forretningen) og urgency (hvor hurtigt servicen skal genetableres). Prioriteringen af incident foretages af Sundhedsdatastyrelsens Nationale Service Desk, SDS eller 3. parts leverandør på baggrund af beskrivelse fra indmelderen.
...
(**) Normal arbejdstid er 8-16 (ma-to) og 8-15.30 fredage
Definition af reaktionstid
Reaktionstiden måles fra starttidspunktet for event (alarm sms eller telefonopkald) til tidspunktet for påbegyndelse af behandlingen af incidentet.
Hvis incidentet er modtaget som udfyldt Webformular, så måles reaktionstiden fra tidspunktet hvor Webformularen er modtaget.
Definition af løsningstid
Løsningsstiden måles fra starttidspunktet for event (alarm sms eller telefonopkald) til tidspunktet hvor incidentet er løst eller afvist.
Tiden hvor leverandøren afventer yderligere information, der er nødvendig for at fortsætte løsningsforløbet, fra indmelder medregnes ikke.
Ændring af incident prioritet
Prioriteten kan ændres hvis incidentet viser sig at være anderledes mht impact og urgency end først antaget. Prioriteten kan også ændres for en lukket incident. Dette skal kun gøres i undtagelsestilfælde, hvor det ikke var muligt at fastsætte prioriteten rigtigt under løsningsforløbet. En ændring af prioriteten for en incidents skal altid opdateres i IBM Clear Quest.
Incidents på Test eller uddannelses miljøer
Incidents på test og uddannelsesmiljøer kan kun være enten P3 eller P4.
Scope for processen
Scopet for Incident Management processen er enhver hændelse, som afbryder, kan afbryde eller kan nedsætte kvaliteten af en service. Dette inkluderer incidents der er indberettet til Sundhedsdatastyrelsens Nationale Service Desk (IBM) samt incidents, der er indmeldt/detekteret af Netic eller Trifork.
...
| Scope inkluderer | Scope inkluderer IKKE |
| Incident indberetning og registrering i PROD, TEST og UDD | Event monitorering |
| Klassifikation og prioritering af incidents | En request for ny service eller ændring af eksisterende Service |
| Visitering af incidents og allokering til 3. parts leverandør | Root cause analysis (Problem Management) |
| Løsning af incidents (kun på overordnet niveau) | Service Requests, dvs simple request fra brugere, der ikke omhandler afbrydelse af service |
| Lukning af incidents og kommunikation til indberetter | Detaljeret flow for løsning af incidents hos 3. parts leverandør |
| Opdatering af database med kendte løsninger | |
| Aktivering af Problem management process for major incidents | |
| Aktivering af Change Management proces hvis en løsning er tilgængelig og skal implementeres | |
| Kommunikation med pressen ved pressehenvendelser vedrørende incidents | |
| Kommunikation med primære interessenter vedrørende P1 og P2 incidents | |
| Udmeldinger på NSPOP | |
| Skrivning og godkendelse af Incident rapporter |
Basale Regler og beslutninger
- Der vil kun være én Incident Management process for alle Systemer og Services under NSP'en
- IBM ClearQuest er master for alle incidents (undtagen rene infrastruktur incidents), dvs at alle væsentlige ændringer på incidentet skal opdateres i IBM ClearQuest
- Alle statusændringer på incidents der er sendt til løsning hos 3. parts leverandør (håndteret i JIRA) skal replikeres til ClearQuest.
- 1st Level support udføres af den lokale service desk
- 2nd level support udføre af Sundhedsdatastyrelsens Nationale service desk
- 3rd level support udføres af 3. parts leverandør (Trifork, Netic, Arosii, Systematic, etc).
Incident Prioritering
- Prioriteten bestemmes af Sundhedsdatastyrelsens Nationale Service Desk ved registering af incidentet
- Prioriteten kan efterfølgende ændres af SDS eller 3. parts leverandør, hvis dette er nødvendigt
- Prioriteten bestemmes ud fra de angivne definitioner og guidelines, se ovenfor.
- Prioriteten kan ændres efter lukning af incidentet. Dette skal ske undtagelservist i tilfælde hvor det ikke var muligt at bestemme den korrekte prioritet af incidentet under løsningsforløbet
Relationer til SOP'er og andre processer
| Proces / SOP Navn | Beskrivelse af relationen |
| Problem Management | Overordnet sker den samlede analyse af incidents som en del af problem management. Hvis Incident Management ikke har en brugbar workaround på det rapporterede incident, et incident fremkommer gentagne gange eller Incidentet er kategoriseret 1 eller 2, skal det overdrages til Problem Management. Problem Management har til opgave at finde en holdbar løsning på problemet. Det primære formål med Problem Management er at forebygge, at problems og deraf følgende incidents opstår, at forhindre gentagne incidents og at minimere konsekvenserne af incidents, som ikke kan forebygges. |
| Service Level Management | Har til formål at afgrænse, dokumentere, aftale, overvåge, måle, rapportere og reviewe service levels for de services, som leveres. Ligeledes skal processen sikre, at alle aftalte service levels leveres for alle it-services, samt af services og deres performance måles på en ensartet måde. Rollen, som SLM er i 24:7-arbejdet defineret som en kundevendt rolle. |
Change Management | Formålet med Change Management er at sikre, at alle ændringer bliver registreret, vurderet, godkendt, prioriteret, planlagt, testet, implementeret, dokumenteret og reviewet i et kontrolleret forløb. |
| Løs Incident | Process til løsning af incident hos 3. parts leverandør. Processen vil blive trigget hvis incidentet ikke kan løses af 2. level (IBM) ud fra godkendt løsning eller workaround hentet i Knowledge Management databasen (SKMS). Processen er intern for 3. parts leverandøren og vil ikke blive beskrevet yderligere i dette dokument. |
| Presse SOP | Ved pressehenvendelser i forbindelse med P1 og P2 incidents skal der kommunikeres med pressen. Dette skal ske i overensstemmelse med Presse SOP'en |
...