På denne side
En demo læser en eksempelfaktura, henter beløbet og sender et pænt resumé til godkendelse. I den faktiske proces kommer fakturaer gennem tre kanaler, nogle tilhører en anden juridisk enhed, og godkendelsessystemet accepterer kun brugere med en bestemt rolle. Udtrækket virker stadig. Arbejdsgangen gør ikke. Det er et tænkt tilfælde, ikke en kunderapport.
En samtale om at tage AI i brug i ældre forretningssystemer peger på data, eksisterende software og lokale vaner som den genstridige del af arbejdet. Kilden beskriver én virksomheds praksis, ikke en generel succesrate. Den nyttige forskel er mellem at bevise en komponent og at sætte den i arbejde.
Demoen vælger sit eget miljø
En demo kan vælge rene input. Den kan give kontoen adgang på forhånd, springe køen over, nulstille en fejlet kørsel og lade skaberen forklare et tvetydigt output. Det er rimelige valg, når en evne skal vises. De bliver farlige, når teamet ser testen af evnen som bevis for, at den er klar til drift.
I fakturaeksemplet er udtræk kun ét trin. Virksomheden skal fastslå, hvilken indbakke der bestemmer, hvordan dubletter findes, om beløbet må ændres efter indsendelse, hvem der må godkende, og hvor en fejlet indsendelse til godkendelsessystemet havner. Et genereret resumé kan ikke svare på det ved at være mere velskrevet.
Grænsen ses nemmest ved at følge én opgave fra den ankommer, til resultatet er accepteret:
En vist evne bliver først nyttigt arbejde, når lokale data, tilladelser og genopretning forbinder den med medarbejderens faktiske arbejdsgang.
| Trin | Spørgsmål i demoen | Spørgsmål i drift |
|---|---|---|
| Input | Kan modellen læse dette eksempel? | Kan den modtage alle tilladte formater og afvise resten? |
| Kontekst | Kan den finde et beløb? | Kan den matche den rette leverandør, juridiske enhed og version af politikken? |
| Handling | Kan den lave et resumé? | Kan den kun udføre tilladte handlinger og undgå dubletter? |
| Fejl | Kan den, der viser demoen, prøve igen? | Hvem ser en fastlåst opgave, retter den og fortsætter sikkert? |
| Brug | Ser output nyttigt ud? | Bruger og stoler den ansvarlige på det i den virkelige kø? |
Sammenligningen er begrebsmæssig. Den siger intet om en målt fejlrate for AI-projekter.
Følg den lokale tilstand
Dataintegration kaldes ofte den sidste kilometer, som om det var et kabel, der kan tilsluttes efter produktet er færdigt. Den lokale datamodel kan ændre, hvad produktet betyder. Én virksomhed kan kalde fakturaen »modtaget«, når den lander i indbakken. En anden gør det først, når den er matchet med en indkøbsordre. Hvis systemet handler på den forkerte tilstand, kan et teknisk gyldigt API-kald stadig være en fejl i forretningen.
Spørg, hvor hvert faktum kommer fra, og hvem der kan rette det. Spørg så, hvad systemet gør, når fakta er uenige. Hvis en post i kilden ændres, efter at modellen har lavet et udkast til godkendelse, skal udkastet så gøres ugyldigt? Hvis en tilladelse trækkes tilbage, mens en opgave står i kø, kontrollerer den kørende proces så igen før handling? Det er spørgsmål om den færdige løsning, ikke pynt omkring den.
Artiklen om at opdage arbejdsgange begynder tidligere med at se, hvad medarbejderne faktisk gør. Her er spørgsmålet, hvad der skal være sandt, før den viste evne kan overleve mødet med arbejdsgangen.
Byg en prototype af evnen, og test derefter arbejdsgangen
En lille prototype kan være den hurtigste måde at lære, om modellen overhovedet kan den centrale opgave. Den behøver ikke alle driftskontroller første dag. Fejlen er at planlægge resten som en lille afslutning uden at undersøge arbejdet.
En nyttig prototype fortæller, hvad den ikke gør. Den kan sige: »Den læser godkendte eksempelfakturaer, foreslår felter og udfører ingen handling i andre systemer.« Næste test kan bruge virkelige poster med tilladelse, mens indsendelse til godkendelsessystemet stadig er slået fra. Først når match af data, tilladelser og genopretning er forstået, bør den skrive til godkendelsessystemet. Hvert trin besvarer et andet spørgsmål.
Løsningen har også en menneskelig side. Den, der allerede løser tvetydige fakturaer, skal kunne rette forslaget, se hvad der blev ændret og vide, om systemet gentager samme fejl. Hvis den nye arbejdsgang tilføjer mere kontrolarbejde, end den fjerner, viser brugen det. Udled ikke, at folk tager løsningen til sig, af en vellykket demonstration.
En frigivelseskontrol kan formuleres som et spørgsmål om drift: Kan en anden medarbejder med tilladelse afslutte og genoprette én opgave, uden at den, der lavede demoen, er i rummet? Medarbejderen bør kunne finde det oprindelige input, se den foreslåede handling, finde grundlaget for tilladelsen og sende en fejl videre. En øvet tilbagerulning er vigtig, fordi en vellykket første kørsel intet siger om en dublet eller en delvis skrivning. Guiden til at indføre AI i eksisterende arbejdsgange giver en bredere plan for udrulning. Hold denne kontrol snæver, og gentag den med den undtagelse, der mest sandsynligt bryder normalforløbet.
Det, der skal tælles, er ikke et genereret output. Det er en accepteret opgave i den virkelige proces med en kendt vej for undtagelser. Indtil den vej virker, er demoen værdifuldt bevis for én komponent. Den er ikke bevis for, at arbejdet er færdigt.
Ofte Stillede Spørgsmål
Hvorfor kan en vellykket demo fejle i drift?
En demo bruger ofte klargjorte data og én medarbejder. Virkeligt arbejde tilføjer poster, der ændrer sig, adgangsgrænser, forsinkede hændelser, håndtering af undtagelser og folk, som skal kunne stole på resultatet.
Hvad bør en test af en løsning i drift indeholde?
Brug en virkelig arbejdsgang, du har tilladelse til, med normale tilfælde og undtagelser. Kontrollér kildedata, tilladte handlinger, genopretning efter fejl, ansvarlig ejer og om den tilsigtede bruger faktisk anvender resultatet.
Betyder det, at modellen er uvigtig?
Nej. Modellens kvalitet er nødvendig i opgaver, der kræver den. Løsningen afhænger også af, om modellen kan handle sikkert i det omgivende system og arbejdsgangen.