Hvordan utvikles en standard i praksis
Standarder blir sjelden gode i første utkast. De utvikles gjennom en strukturert prosess fra problemforståelse til vedlikehold.
En standard oppstår sjelden som et ferdig svar. Den utvikles vanligvis gjennom flere steg der behov må kartlegges, forslag må testes, og dokumentasjonen må bli tydelig nok til at flere kan bruke standarden likt. Det er dette som gjør standardarbeid til en prosess, ikke bare et resultat.
Et vanlig forløp fra problem til standard
Selv om standarder kan utvikles på ulike måter, går mange løp gjennom de samme fasene:
- Et problem blir synlig. Det kan være uklar kontostruktur, svak dokumentasjon, dårlig samspill mellom systemer eller for mye lokal tolkning.
- Behovet beskrives. Fagmiljøer og brukere må kunne forklare hva som ikke fungerer godt nok i dag.
- Et utkast blir laget. Forslaget må konkretisere begreper, struktur og avgrensninger.
- Forslaget blir drøftet. Høringer, arbeidsgrupper og faglige innspill avdekker om løsningen faktisk er brukbar.
- Forslaget testes. Eksempler, datauttrekk og implementasjon viser om standarden holder i praksis.
- Standarden forvaltes videre. Når nye behov dukker opp, må endringer kunne håndteres uten at alt bryter sammen.
Hva som må avklares underveis
| Fase | Typiske spørsmål |
|---|---|
| Kartlegging | Hvilket problem prøver vi å løse, og for hvem? |
| Utkast | Er begreper, felter og regler presise nok? |
| Høring | Hva fungerer dårlig i praksis, og hvorfor? |
| Testing | Kan løsningen brukes i faktiske systemer og dataflyter? |
| Publisering | Er dokumentasjonen sterk nok til at andre kan bruke standarden? |
| Vedlikehold | Hvordan håndteres endringer uten unødvendig brudd? |
En svak standard er ofte et tegn på at ett av disse spørsmålene fikk for lite oppmerksomhet.
Hvorfor høringer og arbeidsgrupper betyr så mye
Det er lett å tenke at standarder først og fremst er tekniske spesifikasjoner. I praksis blir de bedre når flere får mulighet til å kommentere dem tidlig. Høringer og arbeidsgrupper gjør det lettere å:
- oppdage uklarheter før de blir låst
- avdekke behov som ikke var synlige i første utkast
- teste om begrepsbruk fungerer på tvers av fag og system
- gi forbedringsforslag som kan dokumenteres og vurderes åpent
Det er også derfor hvordan påvirke standarder gjennom komitearbeid og høringer er et eget tema på nettstedet.
Dokumentasjon må med fra starten
Mange standarder blir svakere enn de trenger å være fordi dokumentasjon kommer for sent. Hvis eksempler, feilsituasjoner og begrepsforklaringer ikke utvikles sammen med standarden, blir resultatet ofte at brukerne må tolke for mye selv.
God standardutvikling krever derfor at:
- dokumentasjonen skrives parallelt med strukturen
- eksempler brukes for å teste forståelsen
- endringer forklares tydelig når standarden revideres
- ansvar for vedlikehold ikke blir skjøvet til slutt
Dette er samme logikk som ligger bak Dokumentasjon er en del av standarden .
Hva som ofte går galt
Tre problemer går igjen når standarder utvikles for raskt eller for smalt:
- begrepene virker tydelige for dem som skrev dem, men ikke for dem som skal bruke dem
- strukturen ser riktig ut i teorien, men fungerer dårlig i virkelige dataflyter
- vedlikehold og endringer blir undervurdert helt til friksjonen blir synlig
Det er derfor testing og deltakelse er like viktig som selve utkastet.
Dette gjelder også konkrete standarder i økonomi
Prosessen over er relevant enten man arbeider med SAF-T , Peppol og e-faktura eller NS 4102 . Forskjellen ligger ofte i hvilket problem som skal løses, men behovet for god prosess er det samme.
Hvis du vil ha en bredere inngang til feltet, kan du også lese Hva er standardarbeid? , Hva gjør en standardorganisasjon? , Hvordan skrive gode høringsinnspill til en standard , Referanseimplementasjon for standarder , Versjonering av standarder uten unødvendig brudd og Når bør en standard revideres .