Bak de fleste effektive systemer ligger det et lag av automatisering, og det gjelder også våre interne løsninger i Snøkam. Ett av disse systemene er en løsning for å automatisere innhenting og visualisering av OKR-metrikker.

Men hva er egentlig OKR og hvorfor bruker vi det? OKR (Objectives and Key Results) er et rammeverk for mål- og resultatstyring som hjelper organisasjoner med å sette ambisiøse mål og måle fremdrift gjennom tydelige nøkkelresultater. Metoden skaper fokus, transparens og smidighet, men for å lykkes kreves oppdatert og pålitelig data. Nøkkelordet her er oppdatert da vi raskt så at det tok unødvendig lang tid å oppdatere alle Key Resultene våre manuelt.

For en integrasjonsutvikler kan dette fremstå som en drøm om sømløs datainflytelse, eller et mareritt fylt med fragmenterte API-er, kompleks autentisering og unødvendig webscraping, og ikke minst elendig dokumentasjon. I denne artikkelen ser vi på hvordan automatisering av datainnhenting kan forenkle arbeidet med OKR-er. Men lønner det seg alltid å automatisere slike prosesser?

Resultatet av vår automatisering kan du se her: Snøkam OKR

Hva må til for å automatisere OKRer?

Dette vil såklart variere utrolig mye etter hvilke system selskapet du jobber i bruker, men vi har ihvertfall over tid koblet oss mot et bredt spekter av systemer:

• Sanity (CMS) - grunnpilaren i vår datamodell.
• CVPartner/Flowcase - informasjon om CVene våre
• Jira - Hvor alle oppgaver gjør har er lagret
• Salesforce - Alle leads, kontakter, og kunder
• PowerOffice - Vårt kjære økonomisystem
• Medium - Vår tidligere bloggplatform
• LinkedIn - Friend of many, foe of more
• Google Analytics - Metrikker på våre flater

Valget av integrasjon styres i stor grad av hvilke Key Results vi måler. Når vi kan gjenbruke eksisterende dataflyt utnytter vi det! For eksempel gjennom NuGet-pakker vi allerede har utviklet, som Sanity-pakken vår. Dette gir oss betydelige tidsbesparelser og reduserer samtidig risikoen for teknisk gjeld. Over tid forventer vi også at antall systemer vi henter data fra vil stabilisere seg, med andre ord vil forhåpentligvis mengde jobb med tanke på selve integrasjonen mot nye systemer konvergere mot et stabilt tall.

Gode og onde APIer

En av de viktigste erfaringene våre er hvor varierende API-kvalitet kan være.

• I toppsjiktet: PowerOffice, Salesforce og Jira – veldokumenterte, konsistente, og fleksible API-er som gjør integrasjon og feilhåndtering relativt rett frem.
• I bunnsjiktet: Medium og LinkedIn – komplekse tilgangskontroller, fragmentert dokumentasjon og hyppige endringer.

Det var faktisk API-frustrasjonen med Medium som gjorde at vi valgte å bygge vår egen bloggløsning. Da fikk vi også full kontroll på dataflyt, autentisering og struktur. Når du har utviklere som møter opp på mandag og sier «jeg bygde en bloggløsning i helga», blir det lett å kaste dårlige API-er langt, langt bort.

For enklere behov gikk vi like gjerne for webscraping, en pragmatisk løsning når API-ene bremser mer enn de hjelper.

Oppsett

Fra API-rant til litt mer konkret om OKR oppsettet vårt. Hvilke deler av vårt internsystem innebærer løsningen? I de forrige episodene har vi sett mer på veldig sentrale deler av systemet, mens dette er en mer konkret implementasjon. Under ser du hvilke deler av systemet som blir involvert, pluss det kommer en mer konkret tegning litt senere.

Hva er det vi egentlig lagrer?

• For hver Key Result beregnes status kontinuerlig opp mot mål definert i januar.
• Hver oppdatering lagres som et historisk datapunkt, slik at vi kan visualisere progresjon gjennom året.
• Persistens skjer i Sanity, via en custom NuGet-klient som gjenbrukes på tvers av prosjekter.

Under er databaseskjemaet vårt representert, hvor en kan se Objectiven som har flere Key Results som inneholder flere data points.

{
  "_id": "xxxxxxxxxxxxxxxxxxxxxxx",
  "_type": "okr",
  "description": "Forklaring/dypere beskrivelse av selve Objectiven",
  "keyResults": [
    {
      "_key": "xxxxx11111",
      "_type": "keyResult",
      "description": "Forklaring/dypere beskrivelse av Key Resulten",
      "goal": 3,
      "key": "Navnet på Key Resulten",
      "owner": {
        "_ref": "xxxxx-2222-2222-22222-1111111",
        "_type": "reference"
      },
      "progressHistory": [
        {
          "_key": "xxxxxxxxxx",
          "_type": "historyEntry",
          "date": "2025-05-01T10:58:00.000Z",
          "resultAtDate": 1
        }
      ],
      "public": true,
      "result": 1
    }
  ]
}

Selve arkitekturen består av:

• Azure Functions orkestrert via CRON-triggere.
• Ferdigbygde og custom NuGet-pakker
• HTTP-clients om eksisterende pakker ikke finnes som støtter hva vi gjør
• Datavisualisering på toppen av Sanity, slik at hele organisasjonen får innsikt i sanntid (så ofte vi setter frekvensen på CRON jobben). Dette er også tilgjengelig på vår nettside!

Pros and cons med å automatisere dette

Pros

• Eliminering av manuelt arbeid! Systemet gjør jobben mens vi fokuserer på verdiskaping. Innhenting av data + kalkulering kan ta lengre tid enn en tror.
• Gjenbrukbare integrasjoner via NuGet-pakker (kan brukes andre plasser også)
• Skalerbart: flere datapunkter kan hentes uten ekstra manuelt overhead.
• Som alle andre automatiseringer er det ingenting som er digger enn å slippe å gjøre manuell jobb, men heller bare se automatikken gjøre sin magi

Cons

• Det er dessverre ikke alt som lar seg automatisere, eller som det ikke er verdt det, spesielt når vi ikke helt vet hvordan vi skal løse en KR.
• Høy initial investeringskostnad, spesielt i oppstartsåret.
• Nye OKR-er hvert år innebærer omskriving og tilpasning av integrasjoner.

Hva er det som er mulig å automatisere?

Ikke alt kan eller bør automatiseres. Nøkkelfaktorene er:

• Datatilgang: Har vi pålitelige kilder, eller må vi gjette?
• Frekvens: Måler vi ukentlig, eller kun 2–3 ganger i året?
• Definisjoner: Er metrikken klart definert (f.eks. «inntekter per måned») eller vag?

Der faktorer er uklare, er det bedre å vente. Automatisering gir bare verdi hvis datakvalitet og kontekst er på plass. Konkrete eksempler fra våre egne KR-er er:

• Trivsel skal måles 3 ganger i året og vi skal følge opp (og jobbe for forbedring) 100 % av innspillene/ulempene som kommer inn

Denne kunne i teorien ganske enkelt blitt målt, men når det bare er snakk om 2-5 målinger er det ikke verdt å automatisere. Når det er sagt er nok en slik trivselsundersøkelse noe vi kommer til å fortsette med i årene fremover så det kunne potensielt gått inn som en annen automatikk. But I digress!

• Minst 1000 unike brukere i et nytt Snøkam AI-produkt

Dette er også et eksempel på at vi ikke vet hvor dataen skal komme fra. Hadde vi lansert et spill for eksempel kunne vi hentet dette fra plassen vi lanserte det til, men siden det er litt uvisst, ble denne avventet. Mest sannsynlig kan det hentes fra Google Analytics om vi lanserer det direkte på nettsiden vår, og da er det bra at vi allerede har en kobling mot det API-et slik at vi eventuelt kan få raskt opp dataen om vi skulle ønske det.

Er det verdt det?

Kort svar: Ja, definitivt.

For selskaper kan gevinsten i starten være relativt liten sammenlignet med manuelt arbeid (15-30 minutter i uka). Men om OKR-ene blir mer komplekse, frekvensen trenger å være hyppigere, eller det rett og slett tar for lang tid å hente + kalkulere resultatene. øker gevinsten av automatiseringen utrolig mye.

Automatisering av OKR-er har gitt oss:

• En mye mindre manuell hverdag.
• Et datagrunnlag som enkelt kan eksponeres eksternt og internt.
• Mulighet til å bruke integrasjoner i andre sammenhenger.

Med andre ord:
Har du ikke automatisert OKR-ene dine ennå, er det på tide å sette i gang. Det er både lærerikt og gøy. Du får jobbe med mange forskjellige API-er, du oppdager hvor variert "best practice" faktisk er i integrasjonsverdenen, og du bygger en plattform som skalerer med selskapet.

Automatisering handler ikke bare om å spare tid, men om å bygge en datadrevet kultur der innsikt er tilgjengelig, presis og kontinuerlig oppdatert. Det er det som gjør at små beslutninger kan tas raskt, og store beslutninger kan tas på riktig grunnlag.