En pilot som tål fel och rättelser

Börja med godkänt testmaterial från en fastighet och en vald period, eller med påhittade dokument som motsvarar det. Agenten ska registrera underlag, föreslå värden och lämna frågor till en granskare. Den första piloten ska inte publicera rapportuppgifter eller välja beräkningsmetod. Skriv ned gränsen innan ni kopplar in dokumenten, så att alla vet vad försöket får göra och vad som ligger utanför.

Nexus beskriver godkännande av dataflöde, åtkomst och granskningsloggar som ett villkor före start. Microsoft dokumenterar krav på godkännande mellan utveckling, test och produktion.^1,2

Bestäm vad ni vill se för att godkänna insamlingen. En godkänd faktura ska ge ett förslag som går att granska. Ett saknat dokument ska lämna ett öppet ärende, och ett avvisat värde ska stanna utanför det som lämnas vidare. Namnge personen som får godkänna nästa steg och felen som stoppar försöket. Spara hur mottagarens register såg ut från början, så att en gammal uppgift inte tas för ett nytt resultat.^1,2

Förbered ett fall där dokumentet saknas, en dubbel faktura, en rättelse och en faktura med oklar enhet. Skriv facit innan leverantören kör dem. Dubbletten ska inte ge ännu ett godkänt värde. Rättelsen ska bli den gällande versionen medan historiken finns kvar. Den oklara enheten ska lämnas som en fråga till granskaren. Detta är krav att pröva i ert försök, inte löften om hur produkterna fungerar från början.

Dust beskriver att uppgifter kan hämtas enligt ett schema som kunden bestämmer. Glean anger att källsystemets behörigheter gäller när agenten läser och skriver.^3,4

Kontrollera först att värdena stämmer med facit. Prova sedan samma begäran med ett konto som inte får läsa dokumentet. På så sätt prövar ni innehållet och åtkomsten var för sig. Titta både på agentens svar och i mottagarregistret: vilken uppgift kom fram, eller varför kom ingenting? Ett allmänt felmeddelande räcker inte för kollegan som ska förstå och ta hand om ärendet efteråt.^3,4

Nexus beskriver att osäkra fall lämnas vidare till en person. Glean beskriver mänskligt godkännande innan agenten utför en åtgärd.^5,6

Välj ett fall där agentens svar verkar säkert men där er regel ändå kräver granskning. Låt granskaren säga nej. Lämna ett annat förslag obesvarat och godkänn sedan ett rättat underlag. Kontrollera att de tidigare förslagen inte har smugit sig in i rapportpaketet. När agenten ber om hjälp ska granskaren få källan, det som är fel eller oklart, fältet det gäller och frågan som behöver ett beslut.^5,6

Byt också dokumentversion medan granskaren ännu inte har svarat. Bestäm om ärendet ska tas tillbaka och granskas på nytt. Systemet behöver visa vilken version ett beslut gäller. Är kopplingen oklar ska den ansvariga personen kunna stoppa överlämningen. Behåll det avvisade förslaget i historiken, så att det går att förklara både varför det inte användes och varför den nya versionen godkändes.

Dust beskriver granskningsloggar som skiljer människors åtgärder från agenters och som kan skickas löpande till ett mottagande loggsystem. Funktionen kräver Enterprise enligt dokumentationen.^7,8,9

Avsluta med att jämföra listorna: vad ni väntade på, vilka dokument som kom, vilka frågor som är öppna och vilka värden som godkänts. Låt en kollega som inte var med och byggde återskapa ett godkänt värde och en rättelse från exporten. Saknas ett beslut eller fungerar inte en källhänvisning ska det bli en uppgift för en namngiven person. Det får inte råka räknas som ett accepterat undantag.

Lämna över uppdragets gränser, fältdefinitionerna, testfallen och resultaten, exportvägen, instruktionen för att stoppa arbetet och vem som ger support. Låt den framtida förvaltaren själv följa upp ett saknat underlag. Utöka först när rapportansvarig har accepterat resultatet och IT har godkänt driften. Nya dokumentformat och ändrade beräkningar behöver nya beslut. En lyckad första pilot ger inte i sig agenten rätt att göra mer.