Många av oss som jobbar med AI har lätt att falla för hur cool tekniken är och vilka coola grejer man kan göra. Om ni vill se något galet coolt kan ni till exempel titta på detta forskningspapper.

Självklart vet vi alla att vi inte kan hålla på att bygga sådant som är coolt bara för att vi vill om vi inte kan motivera investeringen ekonomiskt. Det betyder inte alltid att vi ska tjäna eller spara pengar med lösningen men investeringen behöver vara värdeskapande på något sätt, till exempel genom att den kan användas för att skydda vår demokrati eller våra medborgare som vi såg i ett tidigare inlägg. Det behöver med andra ord finnas ett tydligt behov hos någon eller några intressenter.

Det tydliga behovet hjälper oss inte bara att motivera varför vi gör något utan ger oss också energi på resan framåt eftersom de som behöver något också kommer att vara engagerade beställare eller kunder. Här snuddar vi vid några principer som man kommit att omfatta inom agil utveckling, till exempel tydlig beställare i form av en produktägare, intensiv kommunikation med kunderna samt frekvent återkoppling baserat på faktisk progress.

Dessutom är det så att med ett tydligt behov får vi också möjlighet att fokusera byggandet eller beställandet av en lösning mot det som är viktigast. Något som lämpar sig extra bra för agil utveckling av AI-lösningar.

Hur realiserar vi maximalt värde?

Vi kan åstadkomma maximalt värde genom några enkla grepp som inte behöver ta särskilt lång tid - i synnerhet i förhållande till hur viktiga de är. Snarare sparar de mängder av tid eftersom de hjälper oss fokusera på det som är riktigt viktigt.

Intressentanalys

Jag fick för många år sedan lära mig hur man gör en vettig intressentanalys av Kurt Bittner som tillsammans med Ian Spence beskrev det hela i sin bok Use Case Modeling [1]. Det finns förmodligen många som beskrivit detta på ett lika bra sätt men Kurt är en av de duktigare jag träffat på i mjukvaruindustrin så när han säger något brukar det vara rätt 😊.

Väldigt förenklat gör man en tabell på det här sättet:

*Tabell 1. En intressentanalys låter oss se vilka som vi behöver involvera och hur för att säkerställa att vi bygger rätt lösning.*

Business case

Utifrån intressentanalysen kan man så formulera ett business case. Jag börjar faktiskt gärna med ett business case innan jag gör intressentanalysen, för att därefter komplettera eller justera business caset. Beroende på hur omfattande initiativ vi pratar om kan man förstås göra olika djuplodade business cases. Senast tog vi fram ett 10-tal lättvikts business case i ett projekt för att värdera olika proof-of-concepts mot varandra. Sådana kan man till exempel utforma i stil med ett Lean Business Case enligt SAFe [2].

Ett business case hjälper oss se vad som är viktigt i leveransen, vad det kan tänkas kosta, samt hur mycket vi tror det är värt. Jag stöter ofta på invändningar som att det inte går att göra business case för ett speciellt initiativ eftersom det [fyll i ett favorit-argument 😊]. Det har hittills aldrig hänt mig att jag inte lyckats formulera ett business case för ett initiativ när jag försökt - och jag har gjort det ganska många gånger. Det är märkligt hur vanligt det är att man kör projekt utan att ha koll på sitt business case. Det har jag också varit med om. Pinsamt kan jag tycka när jag tittar tillbaka.

Emellanåt är det inte alltid lätt att formulera ett business case. Det kan ibland ta ett antal sittningar innan man hittar vägen fram. Enligt min erfarenhet kan det då handla om att man måste hitta kombinationen av idén och intressenterna som låter oss realisera ett värde. Ta gärna hjälp av någon som har lätt att hitta kreativa sätt att se på värdeskapande, det är lätt att sitta fast i gamla tankebanor.

Tillgänglig data

Många AI-lösningar kräver betydande mängder av relevant och korrekt data. Det är något som också behöver beaktas när man formulerar sitt business case, dvs i stort vilka slags mängder av data vi tror oss behöva samt om vi har någon uppfattning om hur enkelt och till vilket pris vi kan få tag på dessa data. Detta uttrycks med fördel som ett separat avsnitt i business caset.

Business Model Canvas

Ett kompletterande angreppsätt är att jobba med ett Business Model Canvas [3] för att pröva olika affärsmodeller för att på så sätt åstadkomma rätt värde. Det passar tycker jag speciellt bra när lösningen åstadkommer nytta i ett sammansatt nätverk av olika intressenter. På så sätt kan du prova olika sätt att skapa värde för olika intressenter. Ofta är situationen enklare än så men ändå sådan att en canvas låter oss prova olika sätt att göra förtjänster baserat på vår idé. Det finns faktiskt en speciell variant av Business Model Canvas för machine learning som man kan använda. Själv tycker jag att den vanliga canvasen fungerar bra.

Risker och prioriterade förmågor

Om man gör sitt business case enligt modellen för Epics i SAFe kan vi där hitta ett antal prioriterade förmågor eller funktioner. Dessutom bör arbetet med ett business case också inrymma en inledande riskanalys. Baserat på riskanalysen och de prioriterade förmågorna kan vi sätta samman en prioriterad produktbacklog med features prioriterade utifrån hur mycket de bidrar till att validera vårt business case – till exempel genom att visa att det är sannolikt att lösningen går att bygga med rimlig kvalitet.

Agil fokusering och validering, baserat på business case

Ovanstående sätt att tänka passar speciellt bra för utveckling av AI-lösningar eftersom vi ofta har betydande osäkerheter i hur bra vi kan bygga lösningarna. Ofta talar man om att man gör experiment när man testar olika funktioner eller attackerar risker med hjälp av AI-lösningar. Gärna använder man här verktyg som passar bra för att göra sådana experiment såsom Jupyter Notebooks [4]. Med hjälp av en serie sådana experiment kan man så successivt validera såväl värdet som genomförbarheten i den leverans man vill åstadkomma. Emellanåt hamnar vi i ett sammanhang där man testar lösningar i en slags lekstuga med otydligt fokus på det värde som ska åstadkommas. Det är inte vad jag menar med experiment. Den typen av experiment jag talar om är kirurgiska experiment för att med ett minimum av insats validera eller falsifiera värdet eller lämpligheten hos en högt prioriterad feature eller del av sådan. Ett exempel på sådant experiment är att testa vilken slags träffsäkerhet en modell kan få med den data vi har tillgänglig.

Med andra ord kör vi projektet eller initiativet som ett agilt projekt där vi kontinuerligt demonstrerar lösningen för våra intressenter och så snart som möjligt levererar något till de verkliga användarna. Men hur man kör ett AI projekt agilt på stereoider med hjälp av något som kallas DevOps/MLOps kommer vi att återkomma till i en senare artikel.

Vad tycker du är svårast i formuleringen av ett business case för en AI-lösning? Välj gärna en av nedanstående så sammanställer vi det i en graf som du sedan får ta del av:

1.     Att förstå intressenterna rätt?
2.     Att identifiera värdet?
3.     Att avgöra om vi kan få tag på rätt data av tillräcklig kvalitet?
4.     Att skapa en lösning som är användarvänlig?
5.     Att hitta en ersättningsmodell, dvs hur vi ska tjäna pengar på den (om det är aktuellt)?
6.     Att bedöma kostnaden?
7.     Annat: skriv gärna vad

Patrik Jonsson, Novatrox

Referenser:

1. Use Case Modeling, Kurt Bittner and Ian Spence
2. Lean Business Case
3. Business Model Canvas
4. Jupyter Notebooks

Business case för AI