Go/no-go-beslutet: hur du förbereder det och vem som beslutar

Vad go/no-go avgör

Ett go/no-go är ögonblicket då verksamheten säger: den här versionen av CRM:et får gå i produktion, det här datumet. Eller säger: inte än. Det är ingen formalitet i slutet av testet. Det är skälet till att testet gjordes.

Ett bra go/no-go har tre delar:

• Fakta. Vad som testades, vad som gick igenom, vad som fortfarande är öppet. Hämtat från testresultaten, inte ur minnet.
• En bedömning. Processägarna säger om de kan göra sitt arbete med den här versionen, och på vilka villkor.
• Ett beslut. Styrgruppen väger fakta och bedömningar mot go-live-datumet, och beslutar.

De flesta go/no-go-möten som går snett saknar den första delen. Folk diskuterar hur allvarligt ett ärende är, eller om en process alls testades, eftersom ingen har siffrorna. Resten av den här guiden handlar om att se till att fakta finns på plats innan mötet börjar.

Slutkriterier: kom överens om dem före första testdagen

Slutkriterierna säger när testet är tillräckligt bra för att gå live. Kom överens om dem med styrgruppen före första testdagen. I slutet är känslorna starka och datumen nära. Då är fel tillfälle att bestämma vad som räknas.

Kriterier som fungerar för de flesta CRM-go-lives:

• Inget Critical-ärende är öppet.
• Alla Must-testfall har gått igenom.
• Varje öppet High-ärende har en tillfällig lösning eller ett datum för rättningen som verksamheten accepterar.
• Varje testfall som ingår har ett resultat.
• Ägaren till varje process har godkänt.

Kom överens om vad orden betyder

Kriterier fungerar bara när alla använder samma skala. Skriv ner vad varje allvarlighetsgrad betyder, och dela det med både testare och styrgruppen:

Gör likadant för prioritet. Ett testfall märkt Must täcker det som måste fungera från dag ett, till exempel att skapa en offert eller dirigera ett ärende. Om ett Must-testfall misslyckas är go-live i fara. Se Skriva testfall som verksamhetstestare förstår för hur du sätter prioriteter.

Skriv ner vad som inte testas

Varje UAT lämnar något utanför: ett land som går live senare, en rapport som inte är klar, en integration som bara testades i systemtestet. Skriv ner det före testet. Då kan ingen på go/no-go-mötet säga att de trodde att det var täckt.

Vem som beslutar

Två grupper av människor deltar, med olika roller.

Processägarna godkänner

För varje process eller grupp i testet godkänner en person från verksamheten: försäljningschefen för lead to cash, chefen för kundservice för ärendehantering, ekonomiansvarig för fakturering. De vet vad deras team behöver, och de får leva med resultatet. Deras godkännande säger: mina medarbetare kan göra sitt arbete med den här versionen.

Utse dem i början av projektet, inte den sista veckan. En processägare som ser testet för första gången på go/no-go-mötet kommer antingen att skriva under utan att läsa, eller be om en vecka till.

Styrgruppen beslutar

Styrgruppen fattar beslutet för hela go-live. Den består oftast av sponsorn från verksamheten, projektledaren, en ansvarig från IT och, med en implementeringspartner, någon från partnern. Den väger in saker som en enskild processägare inte kan se: ett avtal med det gamla CRM:et som löper ut, en utbildningsplan, en migreringshelg, andra projekt på samma datum.

Testledaren förbereder, men beslutar inte

Testledaren tar fram fakta och ett råd. Testledaren godkänner inte för verksamhetens räkning och fattar inte beslutet. Att hålla isär rollerna är det som gör att beslutet står sig när något går fel efter go-live.

Rapporten: vad den ska innehålla

Go/no-go-rapporten är för personer som inte var med i testet. Håll den kort: en sida, med detaljerna bakom för den som vill ha dem.

• Ett råd. Go, go med villkor eller no-go, med skälen på en eller två rader.
• Omfattning. Vilka processer och user stories som ingick i testet, och vad som inte testades.
• Vad som testades. Miljön, releasen och builden. Ett resultat hör till en version av systemet.
• Siffrorna. Testfall som gick igenom, misslyckades, blockerades och inte slutfördes.
• Per grupp eller process. Samma siffror, med godkännandet från varje grupp.
• Per prioritet. Hur många Must-, Should- och Could-testfall som gick igenom, och vilka Must-testfall som inte har gjort det.
• Ärenden efter allvarlighetsgrad. Hur många som är öppna, klara för omtest och stängda, med de öppna Critical- och High-ärendena namngivna.
• Godkännandena. Vem som skrev under, när, med vilket beslut och vilka villkor.
• Kända risker. De tillfälliga lösningar som verksamheten använder de första veckorna, och vem som stöttar dem.

Skicka rapporten en dag före mötet. Den som läser den hemma ställer bättre frågor.

I UAT StudioGo/no-go report på dashboarden innehåller indikationen (GO, GO with conditions eller NO-GO, med skälen), siffrorna, framstegen per dag, resultaten per grupp, per epic och per prioritet, ärendena efter allvarlighetsgrad, de öppna Critical- och High-ärendena namngivna, och varje godkännande i rundan. Indikationen följer fasta regler och är ett råd: styrgruppen beslutar. Dela den som PDF eller ladda ner den som bilder till styrgruppens presentation.

Vad du gör med öppna ärenden

Det finns alltid öppna ärenden i slutet av en UAT. Frågan är inte om det finns några, utan om vart och ett har ett beslut. Gå igenom dem före mötet, med verksamheten och utvecklingsteamet, som i den dagliga triagen.

Omklassificera med försiktighet

De sista dagarna finns det en press att flytta ett Critical-ärende till High. Ibland är det rätt: en tillfällig lösning dyker upp, eller processen visar sig vara ovanlig. Gör det öppet, i triagen, med processägaren, och skriv ner varför. Gör det aldrig i tysthet för att få siffrorna att se bättre ut. Det är så en go-live misslyckas den första veckan.

Önskemål är inte fel

Testare hittar saker som de skulle vilja ha annorlunda. Om systemet fungerar som det är utformat är det en ändringsbegäran: den hamnar i backloggen, inte i den här releasen, och den räknas inte mot go-live.

I UAT StudioTriagen ger varje ärende en allvarlighetsgrad, en prioritet, en ansvarig och ett beslut: Fix, Reject eller Change request. Med modulen AI test design skriver Summarize with AI på fliken Issues en kort översikt över de öppna ärendena för go/no-go-mötet: grupperade efter tema, med det som blockerar go-live. Utan modulen ger Summarize with your own AI en prompt att klistra in i ditt företags AI.

Ett villkorat go

Många CRM-go-lives får ett go med villkor. Systemet är tillräckligt bra, förutsatt att något görs före eller direkt efter go-live. Det är ett rimligt beslut, så länge villkoren är verkliga.

Ett bra villkor är:

• Konkret. Rabattgodkännandet för order över 50 000 är rättat och omtestat, inte godkännandena fungerar.
• Har en ägare. En person är ansvarig för det, med namn.
• Har ett datum. Före go-live, eller ett datum under de första veckorna efter.
• Kontrolleras. Någon bekräftar att det är gjort, och styrgruppen får veta det.

Håll koll på antalet villkor. Två eller tre är normalt. Femton betyder att testet inte är klart. Ett villkorat go är inget sätt att undvika ett no-go.

Go-live i delar

Ibland är en process inte klar men resten är det. Då kan du gå live utan den processen, eller med ett land eller team senare. Besluta det uttryckligen, skriv ner det nya datumet för den del som väntar, och planera en egen UAT-runda och ett eget godkännande för den.

Godkännande per grupp

Be om ett godkännande per process eller grupp, inte en underskrift för allt. En försäljningschef kan inte bedöma ärendehantering, och ska inte behöva göra det. Varje ägare väljer ett av tre svar:

• Accepted: mina medarbetare kan göra sitt arbete med den här versionen.
• Accepted with conditions: förutsatt att villkoren uppfylls. Skriv ner vart och ett, med vem som gör det och när.
• Rejected: inte tillräckligt bra för att gå live. Fråga vad som skulle ändra svaret.

Samla in godkännandena före mötet, så att styrgruppen beslutar utifrån hela bilden. Ett godkännande hör till en version: när en ny build eller en ny testrunda följer, godkänner man igen.

I UAT StudioKortet Sign-off på dashboarden har en rad för hela projektet och en för varje grupp, med Accepted, Accepted with conditions eller Rejected. Datum, tid och antalet öppna Critical-ärenden registreras. Som standard kan ingen godkänna medan ett Critical-ärende är öppet; med No sign-off while Must test cases have not passed markerat väntar godkännandet också tills alla Must-testfall har gått igenom. Att avvisa går alltid. Ett godkännande hör till den aktuella rundan.

Så leder du go/no-go-mötet

Planera mötet när du planerar testdagarna, med datumet i styrgruppens kalender. Avsätt en timme. En typisk ordning:

1. Testledaren visar rapporten: omfattning, siffror, öppna ärenden, godkännanden. Tio minuter, med siffrorna på skärmen.
2. Varje processägare säger med en eller två meningar varför de godkände som de gjorde, och vilka villkor de har.
3. Frågor om de öppna Critical- och High-ärendena: finns det en rättning, en tillfällig lösning, ett datum?
4. Frågor utanför testet: utbildning, datamigrering, support de första veckorna, planen för att rulla tillbaka.
5. Beslutet: go, go med villkor eller no-go. Läs upp det högt, med villkor, ägare och datum.

Om beslutet är no-go, avsluta med en plan: vad som måste ändras, en ny testrunda och ett datum för nästa go/no-go. Ett no-go med en plan är ett normalt projektbeslut. Ett no-go utan plan känns som ett misslyckande.

Beslutsloggen

Skriv ner beslutet samma dag. Månader senare, efter en incident eller vid en revision, kommer någon att fråga vem som beslutade att gå live med det där öppna ärendet. Svaret ska gå att hitta på en minut.

En beslutslogg innehåller, för varje go/no-go:

• Datumet, och vilka som var med på mötet.
• Beslutet: go, go med villkor eller no-go.
• Varje villkor, med ägare, datum och, senare, när det blev klart.
• De öppna ärenden som verksamheten accepterade, med skälet.
• Rapporten som beslutet grundades på, så som den såg ut i det ögonblicket.

Spara den med projektdokumenten, och följ upp villkoren de första veckorna efter go-live, tills vart och ett är klart.

I UAT StudioSave snapshot på go/no-go-rapporten sparar rapporten så som den var när beslutet fattades; den ändras inte längre, och Show öppnar den igen senare. Varje godkännande finns kvar i historiken, även de som ersattes eller drogs tillbaka. För en revisor laddar administratörer ner Evidence pack: rapporten, testfallen, resultaten och ärendena, historiken för varje ärende, varje godkännande och granskningsloggen, med en kontrollsumma för varje fil.

Gratis att använda

Slutkriterierna, godkännandet och rapporten finns också i UAT-checklistan för en CRM-go-live, som en gratis Excel-fil. För hela testet, se guiderna för en Salesforce UAT och en Dynamics 365 UAT.