Fra prompt til forløp

Det viktigste kort

Moden for et forløp er en prompt som har fungert likt tre ganger, hvis inndata lar seg navngi, og hvis feil ville vært synlige.
Fire byggeklosser hører med: utløser, inndata, instruks, utdatamål – pluss en avbruddsbetingelse.
Et menneske blir stående på nøyaktig to steder: ved vurderingen og ved alt med virkning utad.
Den vanligste feilen er forløpet uten nødbrems og uten logg – da merker ingen at noe tipper.

I chatvinduet er hver feil uten følger: man leser svaret og forkaster det. Et forløp går uten tilskuere – og nettopp det utgjør forskjellen mellom de to formene.

Når en prompt er moden for et forløp

Tre betingelser, alle samtidig:

Den har fungert likt tre ganger. Ikke likt nok – likt. Den som automatiserer en prompt som måtte etterjusteres hver gang, automatiserer bort etterjusteringen, ikke arbeidet.
Inndataene lar seg navngi. Hva går nøyaktig inn, og hvor kommer det fra? Hvis svaret lyder «det kommer an på», lar forløpet seg ennå ikke beskrive.
En feil ville vært synlig. Hvis et feil resultat ser ut som et riktig og ingen ser etter, mangler kontrollen – ikke automatiseringen.

Merk «Jeg gjør det ofte» er ingen modenhetsbetingelse. Hyppighet sier ingenting om ensartethet. Oppgaver man gjør ofte og hver gang på ny måte, er de dårligste kandidatene overhodet – og blir oftest foreslått.

De fire byggeklossene

1. Utløser

Hva starter forløpet? Et tidspunkt («hver mandag kl. 8»), en hendelse («ny henvendelse i skjemaet») eller en handling («fil lagt i mappen»).

Vanlig feil: En utløser som fyrer for ofte. Hver endring i et datasett er som regel for mye; én gang daglig holder.

2. Inndata

Hvilke data strømmer inn, fra hvilken kilde, i hvilket omfang? Her hører en mengdebegrensning med – ellers går det en gang inn en liste med 5000 oppføringer.

Vanlig feil: Ingen øvre grense. Det merkes ikke under testingen og straks i drift.

3. Instruks

Prompten, nå fast innkoblet: utgangspunkt, nummererte oppgaver, regler, utdataform. Med plassholdere for inndataene.

Vanlig feil: Ingen oppdiktingsforbud. I chatvinduet merkes et oppdiktet tall, i forløpet ikke.

4. Utdatamål

Hvor går resultatet? Et utkast, et notat, en fil, en melding til en person. Helst dit noen uansett ser på det.

Vanlig feil: Rett ut. Utsending, publisering eller endring av datasett uten mellomledd.

Et forløp i detalj

Som eksempel den ukentlige analysen av innkomne henvendelser – et forløp som gir mening i nesten enhver bedrift.

Byggekloss	Fastsettelse
Utløser	Mandag kl. 7
Inndata	Henvendelser de siste 7 dagene, høyst 100, felter: dato, kilde, ærend, status
Instruks	Gruppere etter ærend, navngi de tre vanligste, avvik sammenlignet med forrige uke, ikke finn på noe tall
Utdatamål	E-post til ledelsen, høyst 200 ord
Avbruddsbetingelse	Færre enn 3 henvendelser: ingen utsending
Logg	Tidspunkt, antall inndata, suksess eller feil

Visste du at …?

Avbruddsbetingelsen er byggeklossen som oftest mangler – og den som forhindrer mest irritasjon. Uten den går forløpet også når ingenting foreligger, og produserer en rapport om ingenting.

Skaden er ikke den ene meningsløse rapporten. Den er at en ukentlig rapport som ofte ikke inneholder noe, etter to måneder ikke lenger blir lest – heller ikke når den én gang inneholder noe viktig. Et forløp som bare melder når det er noe å melde, forblir nyttig i årevis.

Der mennesket blir stående

To steder, og de er ikke forhandlingsbare:

Ved vurderingen. Om en kontakt er alvorlig interessert, om en tekst treffer riktig tonefall, om et avvik er et problem eller en tilfeldighet – slike dommer hviler på sammenhenger som ikke står i dataene.

Ved alt med virkning utad. Utsending, publisering, sletting, betaling. Ikke fordi en modell ikke ville vært i stand til det, men fordi en feil der ikke lenger lar seg hente tilbake.

Fra praksis

Et mønster som gjentar seg: Forløpet går bra i tre måneder, så endres en småting i datakilden – et felt heter noe annet, en visning ble bygd om. Forløpet går videre og produserer resultater som er feil, men ser riktige ut.

Mot det hjelper bare én ting: en rimelighetskontroll i selve forløpet. «Hvis færre enn tre felter er fylt ut, bryt av og meld fra.» Fem minutter under byggingen, og forskjellen mellom et forløp som stopper ved et problem, og ett som skriver feilaktige rapporter i månedsvis.

Hva som går galt

Ingen nødbrems. Hvert forløp trenger et sted der det kan stanses øyeblikkelig – kjent før man trenger det.
Ingen logg. Uten opptegnelse lar det seg ikke rekonstruere hva som skjedde når og med hvilke data.
Ingen ansvarlig. Forløp foreldes stille. Uten en kvartalsvis gjennomgang skader et forløp etter ett år mer enn det gagner.
Innsmuglede instrukser. Når forløpet leser tekst fra fremmed kilde – e-poster, skjemaer, dokumenter – kan det stå en oppfordring der som virker som et oppdrag. Virksomt mot det er framfor alt en snever rettighet.

Prompt

Jeg vil overføre en gjentakende prompt til et fast forløp.
Vurder planen og skriv opp forløpet.

Prompten jeg i dag bruker for hånd:
[sett inn prompten]

Utgangspunkt:
- Hvor ofte jeg gjør det: [HYPPIGHET]
- Hvor inndataene kommer fra: [KILDE]
- Hva som skjer med resultatet: [beskrivelse]
- Måtte jeg tilpasse prompten hver gang hittil? [ja / nei]
- Strømmer det inn data fra fremmed kilde (e-poster, skjemaer)?
  [ja / nei]

Oppgaver:
1. Kontroller de tre modenhetsbetingelsene: fungert likt tre ganger,
   inndata lar seg navngi, feil er synlige. Si tydelig fra når en
   av dem ikke er oppfylt – da er forløpet ennå ikke aktuelt.
2. Skriv opp de fire byggeklossene: utløser, inndata (med
   mengdebegrensning), instruks med plassholdere, utdatamål.
3. Formuler en avbruddsbetingelse og en
   rimelighetskontroll som forhindrer at feilaktige
   resultater ser riktige ut.
4. Nevn stedene der et menneske må bestemme.
5. Nevn hva som må logges og hvordan forløpet
   stanses.

Hvis planen ikke er bærekraftig i denne formen, si det
tydelig og nevn den mindre versjonen.

Konklusjon

Skrittet fra prompt til forløp er ingen teknisk terskel, men et spørsmål om beskrivbarhet. Den som kan skrive opp utløser, inndata, instruks og mål, har den vanskelige delen bak seg.

Det som deretter utgjør forskjellen, er de uspektakulære delene: avbruddsbetingelse, rimelighetskontroll, logg, nødbrems. De koster til sammen tjue minutter og avgjør om et forløp fortsatt gagner etter ett år eller stille gjør skade.

Vanlige spørsmål

Hvordan automatiserer man arbeidsforløp med KI?

Ved å overføre en velprøvd prompt til fire byggeklosser: utløser (tidspunkt eller hendelse), inndata (med kilde og mengdebegrensning), instruksen med plassholdere, og et utdatamål – helst der noen uansett ser. Til det hører en avbruddsbetingelse, en rimelighetskontroll og en logg.

Når er en prompt moden for et forløp?

Når tre betingelser er oppfylt samtidig: den har fungert nøyaktig likt minst tre ganger, inndataene lar seg navngi, og et feil resultat ville vært synlig. At man gjør en oppgave ofte, holder ikke – hyppige oppgaver som går ulikt hver gang, er de dårligste kandidatene.

Hva hører nødvendigvis med i hvert forløp?

En avbruddsbetingelse, slik at forløpet ikke går når ingenting foreligger; en rimelighetskontroll som stopper når inndataene ser uventede ut; en logg med tidspunkt, omfang og resultat; og en kjent mulighet til å stanse det øyeblikkelig.

På hvilke steder må et menneske bli stående?

På to: ved vurderinger som hviler på sammenhenger som ikke står i dataene – for eksempel om en kontakt er alvorlig interessert – og ved alt med virkning utad: utsending, publisering, sletting, betaling. Der lar en feil seg ikke hente tilbake.

Hvorfor leverer et forløp feilaktige resultater etter måneder?

Som regel fordi datakilden har endret seg ubemerket – et felt heter noe annet, en visning ble bygd om. Forløpet går videre og produserer resultater som er feil, men ser riktige ut. Mot det hjelper en rimelighetskontroll i selve forløpet og en fast kvartalsvis gjennomgang.