Hva er NADA?

Der NAIS-plattformen gjør det enkelt for team å bygge og forvalte applikasjoner, gjør NADA-plattformen det enkelt å bruke analytiske data for å forbedre produkter og tjenester.

Det skal være lett å finne og få tilgang til andre teams data og innsikt på markedsplassen. Målet for plattformen er å legge til rette for bedre beslutningsgrunnlag og dele læring som gjør at vi leverer bedre produkter og tjenester til brukerne våre.

Selv om ambisjonen med NADA-plattformen er å gjøre det enkelt å bruke analytiske data på tvers av team og produktområder, brukes plattformen også av team til å analysere egne data. Data som registreres på markedsplassen er i utgangspunktet kun tilgjengelig for teamet selv, og kan merkes om det primært er tiltenkt brukt innad i teamet.

Plattformen består i dag av verktøy for å:

• Lese og behandle data fra kilder både i sky og on-prem gjennom KNADA. Det finnes verktøy i Google Cloud Platform som kan brukes til å flytte data. Federated Query er det mest brukte, men det finnes også andre aktuelle verktøy som Datastream.
• Dele metadata på markedsplassen som sammen med BigQuery-tabellen utgjør dataproduktet.
• Tilgangsstyre dataprodukter på markedsplassen.
• Finne og forstå dataprodukter på markedsplassen før analyse.
• Analysere data i Jupyter Notebooks og Metabase (dashboard).
• Deling av innsikt som rapporter i form av datafortellinger.

Snarveier for NAV-ansatte som bare vil komme i gang

• Markedsplassen
• Kontakt oss via nada på Slack
• Dokumentasjon

Datadrevet: Hvorfor og hvordan?

NAVs ambisjon er at data skal ligge til grunn for vår utvikling, slik at vi kan tilby brukerne gode produkter og tjenester. Det betyr at vi måler hvordan folk bruker våre produkter og baserer beslutninger så langt det lar seg gjøre på data. Hvordan kan vi best hjelpe mennesker inn i et arbeidsliv i omstilling? Hvordan kan vi hjelpe permitterte å få de rettighetene de har krav på? Hvilke paragrafer brukes “aldri” og bør fjernes? Hvordan kan vi sikre at team i NAV ser sine bidrag i en større retning og prioriterer deretter?

For å forstå problemstillingene over, tror vi at vi må tenke annerledes rundt ansvaret for analytiske data. Den nye dataretningen skiller seg fra den tradisjonelle måten å behandle data på ved at produktteamene selv skal få verdi av analytiske data. Data skal ikke lenger bare leveres videre. For å få til det, må analyse være noe hele teamet er med på. Verktøyene må derfor være så "utvikler-nære" som mulig. Vi ønsker å komme dit at alle i teamet er med på å diskutere og ta beslutninger basert på data.

Visjonen er at datadeling direkte fra produktteam er normalen og at relevante data er tilgjengelig for beslutninger og til bruk direkte inn i produktutviklingen. Dette er en stor endring. For å komme dit tror vi at må gjøre stegvise endringer i organisasjonen.

Første steg tror vi er at team bruker egne data til analyse. Det gjør at team ser verdien i å bruke analytiske data jevnlig. Når disse dataene er synlige og tilgjengelige på markedsplassen, kan andre bruke de samme dataene inn i sine analyser. På den måten blir deling av data ikke noe som gjøres "på siden" av hva teamet driver med.

På alle nivåer kan vi besvare spørsmål ved bruk av data. Vi kan måle samfunnseffekten av det vi gjør heller enn å følge metrikker fordi de er enkle å måle. Folk i team vet hva de bidrar til i et større bilde. Team kan svare ut hypoteser med bruk av egne og andres data. Det er en stor endring. Men det er også en endring vi må gjennom om vi skal nå målene våre og fortsette å levere velferdstjenester i et samfunn i endring.

Vil du utforske temaet mer?

• OKR i form av radical focus
• Fallgruver ved bruk av metrikker
• AARRR-rammeverket for klassifisering av metrikker
• Om data mesh-paradigmet

...og komme i gang selv?

• Dokumentasjon
• Kontakt oss via nada på Slack