Klar i Danmark. Klar i Sverige?

En koncern vil tage sin agent til servicehenvendelser fra Danmark til Sverige. Det er vores tænkte eksempel. Den danske procesbeskrivelse kan genbruges, men det svenske selskab skal have sit eget grundlag for at sige ja. Skriv de lokale datakilder, konti, agentversion, model, tilladte handlinger, godkendere og supportvej ned, før opsætningen kopieres. En anden kilde eller godkender kan ændre resultatet, selv når instruktionerne er identiske. Produktvalg som projekt og lokation skal også stå her; de følger ikke nødvendigvis med det andet lands løsning.

Vælg almindelige sager og undtagelser, og skriv det forventede resultat for hver. Nogle skal agenten afslutte, andre skal den sende videre. Hver prøve har brug for en ansvarlig bedømmer og et sted at gemme resultatet. Brug godkendte testkonti og materiale, der må behandles i miljøet. Før agenten får lov at skrive, skal I aftale, hvordan ændringer fra prøven kan genkendes og føres tilbage. Ellers er det svært at vide, hvad afprøvningen efterlod.

Google beskriver, at licenser er knyttet til et bestemt projekt og en lokation.¹

Begynd med en bruger, der må læse den lokale sag. Gentag med en bruger, der ikke må, og prøv derefter en kilde fra et andet selskab. Se både på svaret og på, hvad der sker i systemet. Det hjælper ikke at skjule et søgeresultat, hvis agenten stadig kan ændre den samme post. Gem forespørgslen, kontoen, beslutningen og resultatet. Den lokale ansvarlige skal kunne forklare, hvor grænsen blev håndhævet.

DRUID beskriver rettigheder for hver agent, arbejdsgang, del af vidensgrundlaget og samtaletråd. Langdock beskriver synkronisering via SCIM, når brugere tilføjes eller fjernes. Relevance AI beskriver godkendelse fra et menneske før handlinger med store konsekvenser.^2,3,4

Brug beskrivelserne til at planlægge konkrete prøver. Fjern en testbrugers adgang, send en sag til den forkerte godkender, og lad være med at svare på en nødvendig godkendelse. Afviser eller afventer systemet som aftalt? Beskriv også, hvad kollegerne gør, når godkenderen er fraværende. Den lokale leder skal kunne tage over eller sende sagen videre uden samtidig at give agenten lov til mere.^2,3,4

Aftal kontrollerede fejl med leverandøren i et godkendt testmiljø. Lad en datakilde være utilgængelig, forsink et svar, eller send den samme sag igen. Teamet skal kunne skelne mellem 'ikke udført', 'udført' og 'vi ved det endnu ikke'. I den sidste situation bør den aftalte procedure undersøge målsystemet, før nogen gentager handlingen. Ellers kan forsøget på at rette fejlen komme til at udføre den samme ændring to gange.

Prøv også at gå tilbage til en tidligere agentversion. Notér, hvilke instruktioner, integrationer og lokale indstillinger der faktisk følger med tilbage. Er datakilden eller en fælles regel ændret, er den gamle agentversion ikke nødvendigvis den løsning, som tidligere virkede. Bed om en beskrevet vej tilbage, en ansvarlig for arbejdet og et tydeligt tegn på, at driften kan genoptages.

Copilot Studio beskriver godkendte releases mellem udvikling, test og produktion. DRUID beskriver rapporter over blandt andet ændringer i opsætning og modeller. Relevance AI beskriver eksport af revisionslog og spor fra kørsler til en destination, kunden ejer.^5,6,7

Bed leverandøren bruge de relevante spor til at forklare en af jeres fejlsager. Teamet skal kunne forbinde sagen med agentens version, beslutningen og det faktiske resultat i systemet. Et logudtræk, som kun demonstratøren kan forklare, giver ikke kollegaen, der overtager driften, et brugbart svar på, hvad der skete.^6,7

Saml resultaterne i et ark med krav, prøvesag, faktisk udfald, bevis, afvigelse, ansvarlig og beslutning. Sæt de kritiske åbne fejl ved siden af beslutningen om start; de må ikke forsvinde i et bilag. Den lokale procesansvarlige godkender arbejdsgangen, og kollegerne med ansvar for platform og sikkerhed godkender deres områder. Accepterer I en begrænsning, så skriv også, hvilken manuel kontrol der gælder imens.

Nexus beskriver forretningsteamet som ansvarligt for driften efter lancering. Relevance AI beskriver oplæring, efter at implementeringsteamet har hjulpet kunden i gang. Dust angiver prioriteret support med en SLA på Enterprise-niveau.^8,9,10

Nexus beskriver også hjælp før overdragelsen: en ingeniør bygger den første procedure sammen med kundens team og viser den i kundens egne værktøjer. På hjemmesiden skriver Nexus, at teamet bliver og forbedrer løsningen sammen med kunden efter den første version.^11,12

Det giver en koncern noget konkret at bede om i overdragelsesplanen. I det svenske eksempel kan I aftale, at Nexus-ingeniøren og den lokale driftskontakt sammen gennemgår en fejlsag i de svenske systemer. Lad driftskontakten finde årsagen, mens ingeniøren hjælper med at rette den del af opsætningen, der svigter. Gem ændringen og gentag sagen, så den lokale ejer kan godkende resultatet. Aftal i tilbuddet, hvem der hjælper med de efterfølgende rettelser. På den måde kan byggehjælpen bruges til at gøre den lokale overtagelse praktisk.^11,12

Lad den lokale driftskontakt følge en sag, finde sporet i loggen, håndtere en afvist handling og sende et problem videre ad den aftalte vej. Det gør overdragelsen konkret. Aftal supportens sprog og tidsrum i kontrakten. Opdatér koncernens oversigt med landets godkendte version, åbne begrænsninger og næste kontrol. Det næste selskab kan bruge samme fremgangsmåde, men skal stadig vise sine egne resultater, før det siger ja.^8,9,10