Gi én person ansvar for å følge saken til den er avklart
Avtal en navngitt ansvarlig for hendelsen, med en stedfortreder. Denne personen følger saken fra første varsel til normal drift er bekreftet. Rollen kan ligge hos dere eller hos en leverandør, men må være avtalt og bemannet når dere trenger den.
Den ansvarlige trenger ikke rette feilen selv. Oppgaven er å holde oversikt over konsekvenser, samle riktige personer og sørge for at neste handling har en eier. Hvis flere leverandører er involvert, bør dere vite hvem som koordinerer kontakten mellom dem.
Google beskriver en rollefordeling mellom koordinering, teknisk håndtering og kommunikasjon ved driftsavvik. For en mindre virksomhet kan samme person dekke flere oppgaver, så lenge det er tydelig hvem som gjør hva. Kilde: Google SRE – Incident Response.
Et praktisk utgangspunkt er å avklare fire oppgaver:
| Oppgave | Dette må noen ha ansvar for |
|---|---|
| Følge opp hendelsen | Bekrefte at varselet er sett, vurdere hvem som berøres og holde saken samlet. |
| Rette den tekniske feilen | Undersøke årsaken, utføre avtalte tiltak og dokumentere hva som er endret. |
| Informere brukerne | Fortelle hva som ikke fungerer, hvilken rutine som gjelder og når neste beskjed kommer. |
| Godkjenne normal drift | Kontrollere at data og arbeidsoppgaver stemmer, og avklare eventuelle restanser. |
Fyll inn navn, kontaktpunkt og stedfortreder. «IT følger opp» er først nyttig når det er klart hvem som faktisk mottar saken.
Overvåk om arbeidsoppgaven blir utført
En tjeneste kan svare på en teknisk kontroll samtidig som en ordre fortsatt venter på behandling. Microsoft peker på at en vellykket HTTP-status alene gir begrenset informasjon om hvordan applikasjonen fungerer. Det er derfor nyttig å kontrollere funksjonen som betyr noe for virksomheten. Kilde: Microsoft – Health Endpoint Monitoring.
For en ordreintegrasjon kan dere be leverandøren vurdere varsler basert på:
- hvor lenge den eldste ubehandlede ordren har ventet;
- om køen av ventende saker vokser;
- om overføringer er avvist eller trenger manuell avklaring;
- om forventede opplysninger faktisk finnes i mottakersystemet.
Velg terskler ut fra når forsinkelsen får konsekvenser. En overføring som kjøres hver natt, trenger andre vurderinger enn en arbeidsflyt som skal oppdateres fortløpende. Manglende aktivitet er heller ikke automatisk en feil: Det må forventes saker i perioden før fravær av nye overføringer er et nyttig signal.
Be også om å få vite hva overvåkingen ikke oppdager. Det gjør det lettere å vurdere behovet for en supplerende kontroll.
Avtal hva som skjer når ingen svarer
Et varsel trenger en mottaker som kan handle, og en vei videre dersom mottakeren ikke svarer. Avklar hvilken kanal som brukes, hvordan mottak bekreftes, og når saken skal løftes til neste kontaktpunkt. Dette kalles eskalering.
Få særlig tydelig frem:
- hvilke tider oppfølgingen er bemannet;
- hvem som tar over ved ferie og fravær;
- hvor lenge et varsel kan stå ubekreftet;
- hvem som kontaktes dersom første leverandør ikke kan løse problemet;
- hvem som kan beslutte en midlertidig arbeidsrutine.
Skill mellom tid til noen svarer, tid til feilsøking starter og tid til problemet er løst. En avtalt responstid sier ikke alene når dataflyten er tilbake. Be leverandøren konkretisere hva dere kan forvente, også utenfor arbeidstid.
Samle fakta før flere begynner å rette
Opprett én felles hendelseslogg. Den kan være enkel, men bør vise tidspunkt med tidssone, berørt arbeidsflyt, hvem som følger opp og hvilke tiltak som er utført. Bruk et kontaktpunkt og en logg dere har tilgang til selv om det berørte systemet er utilgjengelig.
Begynn med det dere vet: Når fungerte overføringen sist? Hvilke saker er berørt? Hva får de ansatte ikke gjort? Merk mulige årsaker som hypoteser frem til de er undersøkt.
Teknisk ansvarlig bør koordinere endringer. Hvis én person starter overføringer på nytt mens en annen registrerer de samme sakene manuelt, blir det vanskeligere å vite hva som er behandlet. Avtal derfor hvordan midlertidig arbeid registreres og hvem som holder oversikten.
Bruk saksreferanser i loggen fremfor å kopiere hele kundemeldinger eller tilgangsopplysninger. Ta med det som trengs for å finne og følge opp saken.
Kontroller etterslepet før dere melder at alt fungerer
Når forbindelsen er tilbake, må dere undersøke hva som skjedde med sakene som ventet. Noen kan ha blitt behandlet automatisk, andre manuelt, og noen kan fortsatt være uavklarte.
Stripe dokumenterer for eksempel at automatiske leveringsforsøk kan fortsette etter manuell behandling av hendelser. Dokumentasjonen understreker behovet for å unngå at samme hendelse behandles flere ganger. Andre systemer kan fungere annerledes, så leverandøren må beskrive hvordan akkurat deres løsning håndterer gjenopptakelsen. Kilde: Stripe – Process undelivered webhook events.
Be teknisk ansvarlig og den som kjenner arbeidsprosessen, avklare disse punktene sammen:
- Hvilke saker tilhører den berørte perioden, og hvilke finnes allerede hos mottakeren?
- Hvilke saker er håndtert manuelt, og hvordan hindres dobbel behandling?
- Er rekkefølgen viktig, for eksempel hvis en endring eller kansellering har kommet etter opprettelsen?
- Kan gjenopptakelsen kontrolleres i et avgrenset omfang før resten behandles?
- Hvem godkjenner resultatet, og hvem følger opp saker som fortsatt mangler avklaring?
Avtal på forhånd hva som skal være oppfylt for å avslutte hendelsen. Et forslag er at nye overføringer fungerer, etterslepet er avstemt og berørte brukere har fått beskjed. Hvis enkelte saker gjenstår, skal de være synlige med ansvarlig og frist. Å avstemme betyr her å sammenligne registreringene og forklare forskjellene.
En driftsmal dere kan fylle ut sammen
Bruk ett ark per viktig integrasjon. Tabellen er et redaksjonelt forslag som må tilpasses løsningen og avtalen deres.
| Avklaring | Fyll inn |
|---|---|
| Arbeidsflyt og systemer | Hva overføres, hvorfra og hvorhen? |
| Konsekvens ved stans | Hvilket arbeid stopper, og hvor lenge kan det vente? |
| Varsel og terskel | Hva utløser varselet, og i hvilke tidsrom? |
| Første mottaker | Navn eller bemannet funksjon, kontaktkanal og stedfortreder. |
| Bekreftelse og eskalering | Frist for å bekrefte, neste kontaktpunkt og kanal ved manglende svar. |
| Teknisk ansvar | Hvem undersøker og utfører tiltak? Hvem kontakter øvrige leverandører? |
| Midlertidig arbeidsrutine | Hvem beslutter den, og hvordan registreres manuell behandling? |
| Informasjon underveis | Hvem informerer hvilke brukere, og hvor varsles neste oppdatering? |
| Gjenopptakelse | Hvem avstemmer etterslepet og godkjenner normal drift? |
| Oppfølging etterpå | Hvem eier forbedringstiltakene, og når skal de være fulgt opp? |
Prøv malen med et tenkt driftsavvik. Finn frem kontaktpunktene og gå gjennom beslutningene uten å stoppe en virkelig integrasjon. En slik gjennomgang kan avdekke uklart ansvar; den dokumenterer ikke at den tekniske feilhåndteringen virker.
Eksempel: Ordrene kommer ikke frem til planleggingen
Konstruert eksempel: En bedrift ser at godkjente ordrer fortsatt venter på overføring til planleggingssystemet. Driftsleder bekrefter varselet og samler oppfølgingen. Integrasjonsleverandøren undersøker overføringen, mens en medarbeider i planleggingen kartlegger hvilke oppdrag som berøres.
Driftsleder avklarer at bare hasteordrer skal registreres manuelt etter en avtalt rutine. Disse får en referanse i hendelsesloggen, slik at de kan gjenfinnes når overføringen starter igjen.
En intern statusmelding kan da se slik ut:
Ordreoverføringen til planlegging er forsinket. Driftsleder følger saken, og leverandøren undersøker årsaken. Bruk avtalt rutine for hasteordrer og registrer referansen i hendelsesloggen. Neste status kommer klokken 10.30. Tidspunktet for normal drift er foreløpig ukjent.
Etter feilrettingen sammenligner leverandøren og planleggingsansvarlig de berørte registreringene. Driftsleder melder normal drift først når kontrollen er gjennomført og eventuelle uavklarte saker har en eier. Eksemplet viser en mulig arbeidsdeling, ikke en test eller et resultat fra en kunde.
Start med én integrasjon som er viktig for driften
Velg en arbeidsflyt som får merkbare konsekvenser når den stopper. Fyll ut driftsmalen sammen med systemeier og leverandør. Start med de tomme feltene for mottaker, stedfortreder og godkjenning av normal drift.
Hvis dere fortsatt beskriver selve arbeidsflyten, kan guiden om kartlegging før integrasjon brukes som grunnlag.
Digital Flow arbeider med integrasjoner og automasjon. Beskriv systemene og hvor oppfølgingen er uklar, så kan vi avklare hva dere trenger hjelp til.