Noark-5 KDRS 14.6.2012 Petter Pedryc petter.pedryc@ika-trondelag.no
Utgangspunkt Fokus for dagen: Noark-5. Jeg skal her forsøke å si noe om hva det var tenkt å være, hva det er i dag, og hvordan man bør forholde seg til standarden. Fokuset her vil ligge på kjernen, da denne er basisen for resten av systemet. Oppgradering av fagsystemer til Noark-5 versjon. Hvor mange her jobber med arkivdanning? Hvor mange her har deltatt i arbeid knyttet til Noark-5?
Bakgrunn Noark-5 blir kun utgitt som en standard En standard sier kun noe om hvilke krav et system skal innfri, men ingenting om hvordan systemet som skal innfri kravene skal se ut. Noark-4 ble utgitt både som en standard så vel som en fullstendig kravspesifikasjon. En kravspesifikasjon kan legge svært konkrete føringer i forhold til hvordan systemet skal bygges opp, og hvordan kravene i standarden gjennom systemet skal ivaretas.
Kravspesifikasjon Hva er en kravspesifikasjon En kravspesifikasjon er en bestilling på et produkt, og skal fungere som grunnlag for enighet mellom bestiller og utvikler. Hvilke krav som stilles avhenger av produktet. Kostnad, tid, funksjonalitet og valideringsmål, nasjonale og internasjonale standarder m.m. Ikke gitt at det er kunde som skriver kravspesifikasjon.
Hvorfor ny Noark standard? Noark-4 standarden hadde av flere grunnet behov for å bli mer åpen: Noark-4 primært utviklet for saksbehandling i statlige direktorat kommuner på sin side har behov for andre arbeidsformer, en annen organisasjonsstruktur, samt andre behov eksempelvis byggsak m.m. Arkivstrukturen i Noark-4 hadde med andre ord behov for kraftig revidering, da denne legger føringer på disse elementene. Noark-4 skalerer svært dårlig. Små, mellomstore og store offentlige forvaltningsorgan benytter stort sett samme system ikke samtlige er et sentralisert postmottak. Systemet måtte med andre ord moduleres bedre, og integrasjonsløsningen mellom modulene måtte standardiseres. Noark-4 har hatt utfordringer knyttet til integrasjonsløsninger. Noark-4 har hatt store utfordringer i forhold til bevaring. Skyldes delvis vanskelig uttrekksformat.
Et modulbasert Noark system? Service Oriented Architecture En overgang fra store altomfattende systemer til systemer skreddersydd spesifikt for enkeltkunder. (N4) Man definerer som regel en basispakke som ligger i bunn, og lar deretter kunden selv fylle ut resten vha. egen kravspesifikasjon. (N5) Det er denne modulbaserte tankegangen som ligger bak kravet om kravspesifikasjon. Hva er basispakken i Noark?
Ulike løsninger innenfor Noark-5 Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Noark-5 indre kjerne Hvordan avgjøre hvilke elementer som må ligge i bunn? Hensikten med et Noark-5 system er å tillate fullelektronisk danning så vel som bevaring. I kjernen stilles det basiskrav til systemet i forhold til innholds- og metadata som er bevaringsverdig. Altså krav til minimum bevaringsverdig informasjon inn, hvordan den skal administreres, og hvordan den skal bevares. Det er dog viktig å merke seg at dette er en såkalt logisk modell. Dette betyr at man ikke må ha en fysisk Noark-5 kjerne liggende i bunn men at kravene som stilles til Noark-5 indre kjerne blir ivaretatt av systemet på en eller annen måte. Klikk for å redigere tekststiler i m Andre nivå Tredje nivå Fjerde nivå Femte nivå
Fullelektronisk arkiv Systemer Organisasjonen Fullelektronisk originaldokument Sikkerhet Dokumentasjon
Arkivstruktur
Kjerne ~ metadata Metadata for nivå arkiv se side 42/43 Metadata for nivå arkivdel se side 46 Kjernen er egentlig ingenting annet enn en systematisering av metadata, altså informasjonen som skal bevares. Kjernen er egentlig kun to ting: 1. Krav til logisk struktur hva informasjon angår. Skal åpne muligheten for en fornuftig arkivdanning. 2. Hvilke opplysninger altså metadata hvert nivået skal inneholde. Skal sørge for «korrekt» bevaring.
Kommentar arkivstruktur Arkivdel Samme funksjon som i Noark-4. Hvorvidt løsningen bør ha flere arkivdeler er opp til behovet. I forhold til vår kravspesifikasjon for sosialsystem legger vi opp til flere arkivdeler blant annet grunnet bortsetting. Underarkiv Brukes primært kun dersom man fremdeles benytter papirarkiv, og dette ligger fordelt på flere lokasjoner. For fullelektroniske systemer vil behovet mest sannsynlig ikke være til stede. Klassifikasjonssystem Samme som i Noark-4. Her defineres om arkivdelen er objekt- eller emnebasert. Klasse Klassifikasjonssystemet er bygd opp av klasser også i Noark-5, tilsvarende ordningsverdi eller arkivkode i Noark-4. For de fleste objektbaserte arkivdeler vil en klasse være nok, for saksmapper skal sekundærkode være mulig. Viktig å huske på at dersom systemet skal inneholde både objekt og emne må løsningen åpne for flere nivå klasser. Registrering Tilsvarer journalpost i Noark-4, altså transaksjoner i eksempelvis en sak. Dokumentbeskrivelse Refererer til et eller flere dokumenter under en enkel registrering. Utkast, eller hoved- og vedleggsdokumenter Dokumentobjekt Peker til selve dokumentet. Et dokumentobjekt pr. elektroniske dokument.
Utfordring objektserier Objektserier har i en Noark-4 struktur vært vanskelige å sette bort. Fagsystemer benytter jevnt over en meget lik mappestruktur på den enkelte klient? Sak Journalpost-1 Sak [Klient] Journalpost-1 Journalpost-2 Journalpost-3 [Hendelse-1] [Hendelse-2] [Hendelse-3]
Objektserier i Noark-5? Mappe Undermappe Mappe [Klient] Undermappe [Hendelse-1] Undermappe [Hendelse-2] Undermappe [Hendelse-3] Registrering [Dokument-1] Registrering [Dokument-1]
Arkivstruktur 0..1 betyr at en arkivdel kan ha 0 eller 1 klassifikasjonssystem 0..* betyr at en et arkiv kan ha 0, 1 eller mange arkivdeler, motsatt kan en arkivdel bare tilhøre et arkiv. En arkivdel kan ha 0 eller 1 klassifikasjonssystem, motsatt kan et klassifikasjonssystem inngå i 0, 1 eller mange arkivdeler. Klikk for å redigere tekststiler i m Andre nivå Tredje nivå Fjerde nivå Femte nivå
Kravspesifisering av arkivstruktur Når skissert arkivstruktur er klar går man inn på hvert enkelt nivå i Noark-5 standarden og tar stilling til følgende tre elementer hvert nivå består av: Strukturelle krav Sier noe om hvordan aktuelt nivå skal forholde seg til den øvrige arkivstrukturen. Det skal være mulig å utvide mappe til undernivået mappe-imappe Funksjonelle krav Sier noe om hvordan nivået skal fungere, altså hvilken funksjonalitet skal ligge i aktuelt nivå. «Det skal ikke være mulig å slette et arkivert dokument, kun eldre dokumentversjoner» Metadata Redegjørelse for hvilken type metadata som skal registreres på aktuelt nivå, altså hvilken informasjon skal nivået inneholde. Klikk for å redigere tekststiler i m Andre nivå Tredje nivå Fjerde nivå Femte nivå
Noark-5 og mappe-i-mappe Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Noark-5 og egendefinerte mapper Noark-5 standarden foreslår og spesifiserer to mappetyper, basismappe og saksmappe. Utover dette defineres mappetyper som ønsket.
Mappe Av samtlige nivå i arkivstrukturen er det særlig nivå mappe som krever mye arbeid. Grunnen til dette ligger i at Noark-5 åpner for fullelektroniske fagsystem. I standarden gjøres det rede for «basismappe» samt en «saksmappe». Samtlige egendefinerte mappe typer skal dog basere seg på kravene i basismappen. Spesialisert Basismappe??Spesialisert? Man står fritt til å definere sine egne krav utover det som defineres Spesialisert [Saksmappe] Metadata for saksmappe se side 60 Basismappe [minimum metadata og funksjonalitet] Metadata for basismappe se side 59
Funksjonalitet i indre kjerne Etter kravspesifisering av fullstendig arkivstruktur må også funksjonalitet i forhold til indre kjerne spesifiseres. Hvordan skal data inn i kjernen og ut igjen, hvordan skal kjernen administreres, hvordan skal kjernen utføre bevaring eller kassasjon og hvordan skal kjernen avlevere informasjon til depot. Klikk for å redigere tekststiler i m Andre nivå Tredje nivå Fjerde nivå Femte nivå
Noark-5 ytre kjerne Den indre kjerne inneholder ingen funksjonalitet mot brukeren. Indre kjernen fungerer kun som arkivet, altså lageret av bevaringsverdig informasjon. Den ytre kjernen er et sett med krav til funksjonalitet som forsystemene må inneholde. Her er mye hentet direkte fra Noark-4. Klikk for å redigere tekststiler i m Andre nivå Tredje nivå Fjerde nivå Femte nivå
Noark-5 ytre kjerne Det er forsystemene som skal tilby brukere funksjonalitet ikke den indre kjernen. Det ytre laget er med andre ord et sett med krav til funksjonalitet som forsystemene må ha i seg.
Noark-5 komplett system Med Noark-5 komplett system menes egentlig system som består av følgende to komponenter: Et system som tilfredsstiller samtlige krav til indre kjerne Forsystem som tilfredsstiller samtlige krav presentert i den ytre kjerne. Med samtlige krav menes her samtlige O og aktuelle B krav, samt samtlige ytterligere krav presentert i kravspesifikasjonen.
Løsrevet kjerne? Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Noark-5 komplett for IKA- Trøndelag Forsystem WebSkjema Forsystem Utvalgsbehandling? Forsystem Saksbehandling m/epost stort system Samtlige moduler leveres i dag som et Forsystem Administrator Noark-5 kjerne
Hva er Noark-5 egentlig? For meg handler Noark-5 om å gi OF mulighet til å krav spesifisere egne løsninger på egne behov.
Noark-5 implementering og kravspesifikasjon Noark-5 implementeringen i markedet har nok ikke vært slik mange tenkte seg.
Noark-5 implementering i markedet Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Public 360 godkjent som komplett Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Ephorte egenerklæring - komplett Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Acos egenerklæring komplett Klikk for å redigere tekststiler i malen Andre nivå Tredje nivå Fjerde nivå Femte nivå
Kravspesifikasjon Hvordan utformes en kravspesifikasjon Systemutvikler lager kravspesifikasjon. Systembestiller lager kravspesifikasjon. Systembestiller og systemutvikler lager kravspesifikasjon gjennom dialog. Mange i både stat- og det kommunale miljøet har overvurdert kommunens ressurser.
Hvorfor er kravspesifikasjon av kjerne sentralt? En klart definert kjerne er i praksis en bevaringsog kassasjonsvurdering på mikro nivå. Stadfester hva i systemet som er bevaringsverdig. I en kravspesifikasjon bør kommunen minimum klare å definere opp metadataelementer i kjernen. Stadfester også i stor grad krav til funksjonalitet i forsystemet. Forsystemet må inneholde funksjonalitet som understøtter generering av arkivstruktur og metadataelementer i kjernen.
Noark-5 hva er godt nok? Hva forventer en kunde å få levert når man oppgraderer til Noark-5?
Datakvalitet Hva ligger i begrepet datakvalitet, og hvorfor er det aktuelt i denne sammenheng? Datakvalitet kan sies å være et mål på i hvilken grad data man sitter igjen med faktisk representerer virkeligheten slik den faktisk fant sted. Oversatt til arkiv, i hvilken grad det som ligger igjen i Noark-5 kjernen faktisk dokumenterer saksgangen slik den faktisk fant sted.
Fullelektronisk sakarkiv Systemer Organisasjonen Fullelektronisk originaldokument Sikkerhet Dokumentasjon
Fullelektronisk dokument Hva ligger i begrepet fullelektronisk dokument? Begrepet fullelektronisk dokument må ses i sammenheng med det britiske records begrepet altså en dokumentasjon på at transaksjon har funnet sted. Oversatt til norsk arkivlov hvem har gjort hva, når, og hvorfor. Et fullelektronisk dokument er altså en fullstendig dokumentasjon på at FV har ført saksbehandling i tråd med lovverk.
Noark-5 godkjenning Hva ligger bak Noark-5 godkjenningen? Fagsystemer som tilfredsstiller Noark 5 har per definisjon mekanismer for å produsere uttrekk av bevaringsverdige dokumenter og metadata på en standardisert måte for deponering eller avlevering til Arkivverket. Disse mekanismene er en forutsetning for å få godkjent et fagsystem som et Noark 5-system. Hva betyr dette?
Noark-5 «God nok» datakvalitet krever at kunden er bevist hva man får levert Den første forutsetningen er at forsystemet evner å produsere fullelektroniske dokumenter Den andre forutsetningen er at disse blir lagret riktig i kjernen Dette er dessverre ikke garantert av en Noark-5 godkjenning
Noark-5 kravspekk Min anbefaling i forhold til både oppgradering og innkjøp Dersom Noark-5 kompetanse er tilgjengelig, skriv gjerne en kravspesifikasjon med utgangspunkt i Noark-5 standarden. Særlig fokus på kjernen, da denne vil legge premiss for både hva som skal bevares samt hva forsystemet må evne å produsere av Dersom Noark-5 kompetanse ikke er tilgjengelig, skriv en kravspesifikasjon basert på funksjonalitet eller produksjonsløyper del disse opp eksempelvis i henhold til N-4 prosess styring og definer opp hvilke elementer som er bevaringsverdige i hver etappe. Be leverandøren om kopi av prøveuttrekket man har benyttet for å få midlertidig godkjenning av systemet.
Noark-5 kravspekk Min anbefaling i forhold til både oppgradering og innkjøp Det at en og en kommune skriver sin egen kravspesifikasjon vil rett og slett ikke skje, dette pga ressurser og kompetanse. Jeg ser heller ikke for meg at KAI institusjonene skal skrive sine egne kravspesifikasjoner for eiere av samme årsak. En mulig løsning er at det nedsettes en gruppe bestående av kompetanse innen KAI institusjoner for å skrive forslag til sak- og arkivsystem og klientsystem. En annen mulig løsning med langt større tyngde hadde vært om dette ble gjort gjennom KS.
Arkivstruktur
Noark-5 Arkiv Arkivdel Klassifikasjonssystem Klasse 1 Saksmappe 1 Registrering 1 Dokumentbeskrivelse -> papir dokument Dokumentobjekt -> elektronisk dokument Registrering 2 Saksmappe 2 Saksmappe 3 osv.
IKA sitt ansvar? I hvilken grad er IKA ansvarlig for datakvaliteten hos sine kommuner? I hvilken grad har digitalt depot mulighet til å måle datakvalitet når det ikke foreligger en klart definert bevaringsvurdering på mikronivå pr. funksjon? Nye bevarings- og kassasjonsreglene er funksjonsbasert, men i hvilken grad er de detaljerte nok til at det er mulig å benytte disse når indre kjerne spesifiseres? I hvilken grad er det mulig å måle datakvalitet i etterkant, altså ved deponering?
Takk for meg KDRS 14.6.2012 Petter Pedryc petter.pedryc@ika-trondelag.no