Dette er andre del i en serie på tre kronikker fra Jean-Philippe André Caquet, arkivarkitekt og rådgiver i Trondheim kommune.
I forrige artikkel skrev jeg om manglende datakontroll, i denne skal jeg forsøke å beskrive hvordan man kan begynne å få kontroll. Så la oss hoppe ut i datahavet og forsøke å svømme.
Det finnes mange måter å kategorisere data på, men jeg velger her å fokusere på to typer; Data som blir til som resultat av transaksjoner (transaksjonsdata eller records) og data som ligger til grunn for transaksjoner (for enkelhets skyld kalt registerdata). En del data kan høre hjemme i begge kategorier, for eksempel kan resultat av transaksjoner føre til endringer i registerdata (en delingsforretning kan for eksempel endre data i et eiendomsregister).
Transaksjonsdata skal beskrive noe som faktisk har funnet sted. I utgangspunktet kan vi gå ut fra at absolutt alt vi gjør genererer transaksjonsdata. Det vil si at vi ikke bare er avhengige av dataene for å kunne kalles etterrettelige og for å utføre våre arbeidsoppgaver, men vi er også lovpålagt å ta vare på dem iht Arkivloven og Forvaltningsloven.
Vurder bevaringsbehov
Den eneste måten vi kan slippe å ta vare på data fra absolutt alt vi ‘driver med’er ved å vurdere bevaringsbehov. En god bevaringsvurdering bør både avdekke hvilke transaksjoner i en forretningsprosess som må dokumenteres og hvilke metadata som skal følge dem. Dette er enklest å gjøre når man digitaliserer forretningsprosesser. Det gjør prosesstegningen noe mer komplisert, men resultatet blir at de som bruker prosessene slipper å gjøre stadige manuelle vurderinger. Manuelle vurderinger er tidkrevende, skaper ofte frustrasjon og gjør at digitalisering ofte ikke oppleves særlig tidsbesparende.
For at transaksjonsdata skal være valide, må de ikke være mulige å endre etter at transaksjonen har funnet sted. I tillegg må de inneholde tid- og stedfesting, kontekst og involverte aktører, samt opplysninger om sikkerhet, sensitivitet og tilgangsinformasjon. De må også gjøres gjenfinnbare og gjenkjennbare for overskuelig fremtid, også når den som utførte transaksjonen ikke lenger har ansvaret for den. Å tilføre nok opplysninger til å gjøre data gjenfinnbare kan ofte være en komplisert oppgave, siden en transaksjon som er aktiv ofte har andre kriterier for gjenfinning enn en som er avsluttet.
Alt av opplysninger jeg beskrev i forrige avsnitt er metadata. Gode transaksjonsdata vil kanskje ha flere hundre felter med tilknyttede metadata. Det er disse metadataene som gir oss mulighet til å dele og gjenbruke data på tvers av systemer og fagområder, samt å gi data tilbake til både brukere, forskere og næringsliv. Disse metadataene finnes allerede. De oppstår i løpet av forretningsprosessene, men dersom de ikke blir lagret sammen med transaksjonsdataene vil de forsvinne. Dersom man kan standardisere disse metadataene, vil de lettere kunne gjenkjennes av både folk og systemer, og dersom man i tillegg kan bruke standardiserte strukturer vil man gjenkjenne transaksjonsdata på tvers av systemer og fagområder og kunne gjenbruke dem på en sikker måte.
Å få til dette vil kreve noe omstilling i kommunene, men mest hos systemleverandører som må tvinges til å endre gammel praksis med å binde data og metadata til sine egne løsninger.
Hvor skal metadataene komme fra?
Nå har vi sagt at vi kanskje trenger flere hundre felter med metadata, men hvor skal disse metadataene komme fra? Noen, som f. eks dateringer, vil genereres som en del av prosessene, men mange vil måtte komme fra forskjellige typer registre. I dag finnes en del registre i fagsystemer (de fleste eldre fagsystemer er en salig blanding av registre og transaksjoner), mange opprettes manuelt for å dekke et behov som har oppstått og noen få vil finnes som fellesløsninger. Mange av registrene vil finnes forskjellige steder eller i forskjellige utgaver uten noen form for synkronisering. Ikke uventet vil man, med mindre man har en pinlig nøyaktig og tidkrevende prosess for kvalitetskontroll, få flere forskjellige varianter av metadata som i utgangspunktet skal være identiske. Dette gjør metadataene lite brukbare til deling.
Bruk av masterdata er en mulig løsning på problemet. Masterdata er ett eller flere datasett man har vedtatt skal brukes av alle deler av virksomheten, uavhengig av fagområde. For eksempel kan man operere med felles personalregistre, adresseregistre, eiendomsregistre osv, og alle prosesser må hente nødvendige metadata fra disse. Dette gjør at metadata i transaksjoner vil være identiske uavhengig av hvilken prosess som skapte dem. Dermed vil også deling være mulig.
Det er mange utfordringer med masterdata, blant annet må de vedlikeholdes, kvalitetssikres og oppdateres hyppig, og ta vare på sin egen historikk. Dette medfører også at noen må ha ansvaret for disse oppgavene.
Det finnes allerede en del nasjonale masterdatakilder som i for liten grad utnyttes,som f. eks Folkeregisteret, Matrikkelen og Brønnøysundregistrene. Disse og tilsvarende registre kan brukes i mye større grad enn det gjøres i dag, og her kan nok både kommunene bli flinkere til å bruke dem og staten bli flinkere til å tilgjengeliggjøre og informere om dem. Nasjonale registre kan aldri dekke absolutt alle behov, og kommunene kan aldri helt slutte å ha egne registre, men det bør være et uttalt mål at kommunene skal trenge å opprettholde så få som mulig, siden små kommuner har for begrenset økonomi til å opprettholde gode registre. Kanskje kan det også være en løsning at store kommuner er vertskommuner for mer spesialiserte registre?
For å oppsummere: Transaksjonsdata og registerdata henger nøye sammen. I databasekretser snakker man ofte om ‘shit in, shit out’ og dette gjelder i høyeste grad her. Dårlige registerdata gir dårlige transaksjonsdata og dårlige transaksjonsdata umuliggjør gjenbruk og deling av data. Derfor må vi se sammenhengene og fokusere på begge deler deler samtidig. Først da kan ‘shit in’ bli til ‘good shit in’.
