Det korte svar
En hændelseslog bør vise de væsentlige trin i en sag og forbinde dem med samme reference. Loggen skal hjælpe med at rekonstruere forløbet uden at kopiere unødvendige personlige eller fortrolige oplysninger.
Beskriv de hændelser, der ændrer sagens status
Modtaget, valideret, sendt til godkendelse, udført og fejlet er forskellige hændelser. Et forslag er ikke en udført handling. Aftal hvilke overgange der skal registreres, og hvilket system der kan bekræfte dem.
Brug en fælles sagsreference på tværs af integrationer. Uden den kan hvert system have en fin lokal log, mens teamet stadig ikke kan finde sammenhængen mellem kundemail og ordre.
Eksempel: godkendt, men ikke oprettet
En medarbejder godkender en ordrekladde. Kaldet til ERP fejler, og ordren bliver ikke oprettet. Hvis oversigten kun viser godkendt, kan medarbejderen tro, at arbejdet er færdigt.
Loggen bør vise godkendelsen og det efterfølgende udførelsesresultat særskilt. Ved ukendt resultat skal status afspejle netop det, så en kollega ikke ukritisk prøver oprettelsen igen.
| Oplysning | Formål |
|---|---|
| Sagsreference | Forbinder forløbet på tværs af systemer. |
| Hændelse og tidspunkt | Viser rækkefølge og ventetid. |
| Rolle eller komponent | Viser hvem eller hvad der handlede. |
| Grundlagsversion | Forbinder beslutningen med de brugte data. |
| Resultatreference | Peger på den faktisk oprettede post. |
Gem det nødvendige grundlag med passende adgang
Det kan være tilstrækkeligt at gemme referencer til dokumenter frem for hele dokumentteksten. Afklar, hvilke oplysninger der skal være tilgængelige for drift, og hvem der må åbne dem. Logs bør ikke blive en ubeskyttet kopi af alle forretningsdata.
Aftal også opbevaring og håndtering af rettelser efter virksomhedens relevante krav. Denne guide fastsætter ikke en bestemt opbevaringsperiode. Behovet afhænger af data, formål og den konkrete proces.
Test om en kollega kan forklare en sag
Vælg et normalt forløb, et afvist forslag og en teknisk fejl. Bed en person, som ikke udførte opgaven, forklare hvad der skete, hvilket grundlag der blev brugt, og hvad næste handling er.
Hvis det kræver at spørge udvikleren, mangler loggen sandsynligvis forretningskontekst. Brug testen til at forbedre felter og statusser. Flere tekniske linjer hjælper ikke nødvendigvis; forståelige forbindelser gør.
Brug det i praksis
Jeres næste skridt
- Definér væsentlige statusændringer.
- Brug fælles reference gennem hele forløbet.
- Adskil beslutning og faktisk effekt.
- Begræns indhold og adgang i logs.
- Afprøv rekonstruktion uden den oprindelige medarbejder.
Ofte stillede spørgsmål
Skal alle modelkald gemmes i fuld længde?+
Ikke nødvendigvis. Gem det nødvendige for formålet og afklar adgang og opbevaring.
Hvad er vigtigst ved en fejl?+
At status, sagsreference, kendt resultat og næste handling kan findes.
Er en teknisk log nok?+
Kun hvis den også gør det muligt at forstå forretningsforløbet. Ofte kræves tydelige sags- og resultatreferencer.
Kilder og faglig baggrund
De praktiske eksempler og tjeklister er udarbejdet til denne guide. Følgende kilder uddyber de angivne faglige begreber.
Supplerende teknisk baggrund om sammenhængende AI-forløb og deres afhængigheder.
Begreber i guiden
Fra guiden til jeres arbejdsgang
Se hvilke oplysninger, adgange og kontroller der skal afklares, før jeres systemer forbindes.
Brug skabelonen
Saml jeres egne oplysninger i et arbejdsgrundlag, som kan udfyldes og downloades.
Udgivet af Norstream med AI-assisteret udarbejdelse. Eksempler er illustrative, medmindre andet er angivet. Tilpas metoder og kontroller til jeres systemer og faglige ansvar.
Har du en rettelse eller et spørgsmål?