Et internt verktøy for beslutningsoptimering

Alle bildene er tegnet på nytt, med oppdiktede navn og tall, på grunn av taushetsplikt.

Equinor bygde et internt verktøy som skulle hjelpe team gjennom store beslutninger der mye er usikkert. Produkteieren og fagekspertene hadde en forskerprototype, og utviklerne hadde startet fra grunnen av på selve verktøyet. Jeg ble hentet inn i tre uker, for å designe det som ennå ikke fantes og gjøre det de hadde bygget lett å bruke. Jeg solgte inn to måneder til, for å definere hvordan verktøyet skulle fungere.

Før jeg tegnet noe, ville jeg vite hvorfor verktøyet skulle finnes.

Ingen hadde skrevet ned hva verdien i det var, og fagstoffet bak prosessen så ut til å variere mellom kildene. Uten det svaret hadde jeg lite å prioritere etter. Så jeg kartla beslutningsprosessen, steg for steg, og holdt den opp mot forskerprototypen og det utviklerne hadde bygget. Oppdraget gjorde jeg ved siden av: begynte på design av ny funksjonalitet, og ryddet i det som alt var laget.

Jeg ville bruke kartet til å holde team og produkteier oppdatert, vise fram funnene, og til å selge inn mer arbeid.

Fagekspertene svarte ulikt på de samme stegene

Kartet la fasene øverst og stegene under, med rollen som eier hvert steg. Det utviklerne alt hadde bygget, la jeg ved stegene det hørte til, slik at vi fikk oversikt over hva som manglet.

Starten av prosessen hadde mange sider for det som egentlig bare er oppsett av et prosjekt. Jeg slo dem sammen. Lenger ute manglet det steg, og evalueringen av en ferdig kjørt beslutningsprosess fantes ingen steder, verken i prototypen eller i presentasjonene.

Strukturen fra kartet gikk også inn i verktøyet. Jeg la inn en sidemeny med fasene og stegene, slik de selv tenkte prosessen. Den viste hvor i prosessen man var, og lot dem lettere jobbe iterativt fram og tilbake.

Fagekspertene brukte mye tid på å evaluere og analysere tidligere beslutningsprosesser. Kunne verktøyet gjøre noen av analysene selv, ville fasilitatoren og beslutningstakeren fått mer å gå på, for eksempel om en prosess burde kjøres igjen. Hvilke analyser vi sikter mot, avgjør hvilke data som må fanges opp i de første stegene, så valget måtte tas tidlig. Likevel anbefalte jeg å ikke begynne der, å bygge den analytiske delen før verktøyet er bevist suksessfull i en ekte prosess, ville blitt for komplisert.

Kartet brukte jeg også til å stille spørsmål, de samme fire til hvert steg: hva er hensikten, hva skal brukeren gjøre, hva må de vite først, og hvordan vet de at de skal videre til neste steg. Jeg ville fylle hullene i det de alt visste før jeg lette etter noe nytt. Da jeg gikk gjennom prosessen slik med fagekspertene, kom uenigheten fram. På noen steg ble svarene stående uklare, på andre svarte de ulikt. Det var de samme menneskene som eide produktet, kunne faget og selv satt i møtene verktøyet skulle støtte.

Noe av den løste vi i gjennomgangene av kartet og i workshops senere. Den største, om hvordan sannsynlighet skulle fylles inn og regnes ut, tok en todagers workshop. Resten sto igjen da jeg gikk.

Produkteieren så kartet mens det ble til

Kartet viste jeg først til teamet og de to fagekspertene som trådte inn for produkteieren, mens han selv ikke var der de første ukene. Vi brukte det mest som kontekst for hull og endringer i funksjonene vi bygde. Jeg sørget for at produkteieren fikk se kartet og funnene, og høre tankene mine, i god tid før oppdraget opprinnelig skulle slutte.

På forrige prosjekt handlet jeg før produkteieren hadde fått nok kontekst til å ta stilling. Denne gangen ville jeg være ekstra tydelig.

Jeg tror dette var grunnen til at jeg fikk fortsette, og til at oppdraget mitt endret seg fra tre uker med skjermer til å definere verktøyets del i prosessen.

De ba om ett verktøy. I møtet satt det tre roller.

I oktober intervjuet jeg folk fra alle tre rollene: fasilitatoren som driver prosessen, det tverrfaglige teamet som kan sette sannsynligheter ved usikkerhetene og beslutningstakeren som har ansvar for avgjørelsen. Svarene ble til personas og funn jeg la fram for teamet.

Klarhet betyr ulike ting for de tre rollene. Verdien ligger i at alle følger den samme kjeden av resonnement, hver fra sitt ståsted.

Produkteieren og fagekspertene hadde ønsket seg «helst at brukere skal kunne bruke verktøyet og skjønne det uten fasilitering». Intervjuene sa noe annet. Teamene ville ikke at verktøyet skulle fasilitere eller bestemme for dem. De ville ha en struktur som holdt dem samkjørte. Skal en bruker komme gjennom uten en ekspert til stede, må verktøyet bære noe av veiledningen eksperten ellers gir i rommet, og det lå ikke innenfor rekkevidde på tiden vi hadde. Vi la den forventningen og det målet bort, og landet på at verktøyet skal gjøre ansvaret lettere å utføre, ikke overta det. Jeg ville bygge det brukerne ventet på, ikke det vi hadde sett for oss.

Hvor kompleks modellen skulle få lov til å bli

I november gikk arbeidet over på det vanskeligste i MVP-en: sannsynlighet og verdi. En sannsynlighetstabell er betinget av nodene over, så antall rader og kolonner vokser med hver forelder og hvert utfall noden har. Plutselig sitter en bruker med hundrevis av tall som skal fylles inn. En enklere modell er raskere å fylle ut og gir færre feil, men informasjon kan falle ut av regnestykket.

Ingen av oss kunne ta den avveiingen alene. Produkteieren og fagekspertene svarte for om forenklingen fortsatt stemte mot beslutningsoptimeringsprosessen, jeg for om det var til å bruke.

Jeg testet utfyllingen med en fagekspert. Han hoverte over feltene og sa «prøver å finne ut hva ting er». Etter det første tallet han fylte inn, ble summen rød, før han kunne ha vært ferdig.

En drøy uke senere satte vi strukturen for sannsynlighetene på en todagers workshop. Nodens egne tilstander er alltid kolonnene. Nodene tidligere i diagrammet bygger radene som et tre, og beslutninger står alltid først, for å følge tankegangen til brukeren. Summen for hver rad står ved siden av. Vi bestemte også at verktøyet ikke skulle styre hvor komplisert modellen fikk bli. Fagekspertene så fort når en tabell var for stor. Det skulle være en felles beslutning i prosessen. Verktøyet skulle ikke stå inn for fasilitatoren.

Det jeg la igjen, og det jeg ikke fikk gjennom

Mesteparten av det som ble bygget, ble laget mens jeg var der. I desember overleverte jeg resten, med en egen gjennomgang med produkteieren av hva jeg ville prioritert videre. Ingen designer overtok, så jeg dokumenterte arbeidet i Figma og FigJam for den som måtte komme etter.

Verktøyet ble aldri skikkelig tatt i bruk mens jeg var der. De som testet, var produkteieren og fagekspertene, som selv var fasilitatorer. Beslutningstakerne og de tverrfaglige teamene fikk jeg aldri testet skikkelig med. Jeg sluttet i konsulentbyrået samtidig, og vet ikke hva som har skjedd med verktøyet etter 2025.

Én ting ville jeg gjort likt. Jeg bestemte meg fort for å dele de tre ukene i to: først research, innramming og små forbedringer, så design av det nye. Research og design gikk hele tiden om hverandre, men fristene, både dem jeg fikk og dem jeg satte selv, ga meg tydeligere mål og prioriteringer. Jeg ble ikke stående i én problemstilling for lenge.

To ting ville jeg gjort annerledes. Jeg ventet på de ulike rollene i prosessen og testet derfor sjeldnere enn jeg burde. Kolleger i byrået eller utviklerne kunne svart på spørsmål om forståelse, raskere.

Det andre er uenigheten mellom fagekspertene. Når de selv er brukerne og er uenige med hverandre, hvordan får jeg fram en avklaring raskere uten å tråkke noen på tærne?