Grupper og informasjonsflyt i Feide

dataflyt-tmbMed jevne mellomrom får vi i Feide spørsmål om hvorfor Feide-tjenester ikke kan få utlevert informasjon om elever og læreres ’et_eller_annet’ idet personen logger inn. Eller i en del tilfeller i forkant av at brukeren logger inn. I det siste har dette ’et_eller_annet’ gjerne vært gruppeinformasjon, typisk elever og læreres basisgrupper/klasser og undervisningsgrupper/faggrupper.

Det virker som mange ikke har oversikt over hvordan person- og gruppeinformasjon flyter lokalt hos skoleeierne og i Feide-systemet. Og ikke minst hvilken informasjon som er tilgjengelig hvor.

I dette innlegget prøver jeg å forklare litt hvordan flyten av person- og gruppeinformasjon foregår hos en typisk skoleeier, hvilken informasjon som er tilgjengelig hvor, hvorfor Feide ennå ikke kan løse alle gruppebehov og hvordan dette kan løses fremover.

Innhold

Informasjonskilder og -typer
Informasjonsflyt lokalt hos skoleeieren
Informasjonsflyt gjennom Feide
Informasjonsflyt for tjenester som trenger mer informasjon
Gruppeinformasjon i Feide
Tilhørighet til skoleeier og skoler
Trinn og andre Grep-koder
Basisgrupper og undervisningsgrupper
Fremtidig alternativ 0: Vi fortsetter som nå uten endringer i Feide
Fremtidig alternativ 1: Flere grupper sendes gjennom Feide
Fremtidig alternativ 2: Grupper hentes på siden av Feide
Veien videre

 

 

Informasjonskilder og -typer

All informasjon som flyter hos en skoleeier, og gjennom Feide, kommer fra en eller flere informasjonskilder hos hver enkelt skoleeier. Finnes ikke informasjonen i et av disse kildesystemene vil vi ikke kunne benytte den automatisk i andre systemer, naturlig nok.

Ofte er det tre kildesystemer som brukes til elektronisk identitetsforvaltning i grunnopplæringa:

  • Skoleeiers personalsystem (HR)
  • Skoleeiers skoleadministrative system (SAS)
  • Skoleeiers identitetsforvaltningssystem (IdM)

Dette er som regel de tre store, men i tillegg til disse kan noen informasjonselementer komme fra fagsystemer som telefonsentralen, fysisk adgangskontrollsystem og lignende.

Kvaliteten på informasjonen om elever og lærere avhenger av de ansatte hos skoleeieren som arbeider med disse kildesystemene. De må holdes oppdaterte og korrekte. Dette gjelder for eksempel å flytte elever opp et trinn når nytt skoleår begynner, flytte elever til ny skole om de bytter underveis, oppdatere hvilke fag eleven tar og så videre. Disse endringene må ikke bare gjøres ved starten av året eller før vitnemålsutskrift, men kontinuerlig gjennom hele året. Alle tjenestene eleven benytter i hverdagen er avhengig av oppdatert og korrekt informasjon.

Dårlig kvalitet i kildene fører til dårlig kvalitet i hele informasjonskjeden. Helt fra kilden, gjennom de lokale systemene, til Feide og til Feide-tjenestene. Den eneste som kan rette på feil eller mangelfull informasjon om elever og lærere er skoleeieren selv.

Informasjonen som kommer fra disse kildesystemene kan vi grovt dele inn i forskjellige typer:

  • Grunnleggende personinformasjon som navn, fødselsnummer, telefon, e-post og lignende
  • Brukerinformasjon som brukernavn, autentiseringsdata og forskjellige identifikatorer
  • Administrative grupper som skoler, avdelinger, seksjoner og informasjon om disse som organisasjonsnummer, sentralbordnummer, e-post og lignende
  • Pedagogiske grupperinger som basisgrupper, undervisningsgrupper, trinn og lignende

De forskjellige kildesystemene er alle autorative for deler av denne informasjonen, men ingen av dem for alt:

  • Personalsystemet (HR) står gjerne for informasjon om personinformasjon om lærere og andre ansatte, og administrative grupperinger
  • Det skoleadministrative systemet (SAS) har personinformasjon om elever og lærere, og de pedagogiske grupperingene
  • Identitetsforvaltningssystemet (IdM) genererer brukerinformasjonen

I mange tilfeller er det overlapp mellom informasjonen i kildesystemene, spesielt for lærere, og da må skoleeier velge hvor de henter informasjonen fra.

Til toppen av siden

 

Informasjonsflyt lokalt hos skoleeieren

For at tjenester skal kunne nyttiggjøre seg den samlede informasjonsmengden over må person- og gruppeinformasjonen samles ett sted lokalt hos skoleeieren, i alle fall logisk, slik at den kan brukes som et helhetlig sett av informasjon om skolens elever og lærere.

Den vanligste måten å gjøre dette på er å hente informasjonen fra kildesystemene og samle den til et konsistent informasjonssett i IdM-systemet. Dette kan gjøres fortløpende gjennom hele døgnet idet endringer skjer eller samle opp endringer og overføre dem av og til. Mange skoleeiere i grunnopplæringa henter oppdatert informasjon fra kildesystemene en til to ganger i døgnet.

 

dataflyt-figur1

Figur 1: Informasjon om personer og grupper hentes fra SASet og HR-systemet og samles i IdM-systemet. IdM-systemet legger til brukerinformasjon.

 

Med et komplett informasjonssett i IdM-systemet kan forskjellige pedagogiske og administrative tjenester hente ut den informasjonen de trenger om elever, lærere og grupper. Dette gjøres også gjerne en til to ganger i døgnet hos skoleeierne, men varierer mye.

Forskjellige tjenester har forskjellige informasjonsbehov så IdM-systemet gjør et utvalg idet informasjonen sendes til tjenestene. En del tjenester skal bare ha informasjon om lærere, noen tjenester skal ha elever, lærere og noen utvalgte pedagogiske grupperinger, andre tjenester igjen trenger så å si all informasjon som finnes.

dataflyt-figur2

Figur 2: Tjenester mottar forskjellige utvalg av informasjonen i IdM-systemet. De færreste får alt.

De fleste tjenestene IdM-systemet sender informasjon til er interne tjenester hos skoleeieren, men skoleeiere sender også informasjon til eksterne tjenester. Den mest vanlige eksterne tjenesten i grunnopplæringa i dag er en eller annen læringsplattform

dataflyt-figur3
Figur 3: Informasjon sendes også til eksterne tjenester utenfor skoleeierens organisasjonsgrenser

En typisk ”feil” vi ofte støter på er tjenester som får informasjonen direkte fra et av kildesystemene. Ofte får de da ikke all den informasjonen de har behov for. Det mest vanlige er at tjenesten ender opp med å mangle elever og læreres brukerinformasjon som brukernavn, Feide-navn og andre identifikatorer.

Dette er spesielt problematisk når elever og lærere så logger seg på tjenesten gjennom Feide. Tjenesten får problemer med å koble personen som kommer inn gjennom Feide med informasjonen tjenesten har fått fra kildesystemet. Noen tjenester benytter da fødselsnummer for å koble informasjonen sammen. Dette er problematisk både på grunn av bruken av fødselsnummer generelt, men også fordi en god del personer i grunnopplæringa ikke har fødselsnummer eller d-nummer. Feide kan også benytte DUF-nummer om dette er registrert, men denne identifiaktortypen er ofte ukjent for tjenestene.

dataflyt-figur4
Figur 4: Hentes informasjonen direkte fra kildesystemene kan tjenestene ende opp med mindre informasjon enn de trenger, spesielt brukerinformasjon

Så fremt det er mulig bør tjenester som henter informasjon om personer og grupper fra skoleeier hente denne fra IdM-systemet og ikke direkte fra HR-systemet eller SASet.

Til toppen av siden

 

Informasjonsflyt gjennom Feide

For å gjøre det lettere å ta i bruk eksterne tjenester ble Feides innloggingstjeneste opprettet for over ti år siden. Det var mange flere grunner til opprettelsen, men jeg går ikke nærmere inn på det her.

Med Feide-innlogging vil eksterne tjenester enkelt kunne autentisere brukere i grunnopplæringa og få et sett med informasjon om elever, lærere og deres brukeridentifikatorer. I nyeste versjon av informasjonssettet i Feide, det såkalte Feide-skjemaet, er også noen få pedagogiske grupperinger tatt med.

Forenklet består informasjonsflyten gjennom Feide av fire deler:

  • Skoleeiers IdM-system legger informasjonen definert i Feide-skjemaet for grunnopplæringen i en LDAP-katalog Feides innloggingstjeneste kan kommunisere med.
  • Når en elev eller lærer logger inn på en Feide-tilpasset tjeneste henter innloggingstjenesten denne personens informasjon fra Feide-katalogen hos personens skoleeier.
  • Innloggingstjenesten sjekker hvilken informasjon tjenesten har avtale om å få utlevert og fjerner resten.
  • Innloggingstjenesten sender den avtalte informasjonen over til tjenesten sammen med en ferdig autentisert elev eller lærer.

dataflyt-figur5
Figur 5: Skoleeier legger informasjon i sin Feide-katalog som innloggingstjenesten kan formidle videre til tjenestene

Feide kan bare videresende den informasjonen skoleeieren har lagt inn i sin egen Feide-katalog. Feide har heller ikke mulighet til å endre denne informasjonen på noe som helst vis. I enkelte tilfeller utleder vi informasjon basert på det vi får fra skoleeier, som for eksempel fødselsår, men vi endrer ikke på av det vi får oversendt.

Dette innebærer at om en person mangler informasjon, informasjonen er feil eller han har glemt passordet sitt kan ikke Feide gjøre noe med dette. Skoleeier må gjøre endringene i sine kildesystemer. Den nye informasjonen vil så flyte til Feide-katalogen som Feides innloggingstjeneste igjen leser informasjonen fra.

Innloggingstjenesten henter også bare ut informasjon om en person i det øyeblikket denne personen logger inn. I praksis kan vi si at det er personen selv som henter sin informasjon fra skoleeier og leverer denne videre til tjenesten når han logger inn. Innloggingstjenesten har ikke mulighet til å hente ut informasjon om flere personer samtidig eller hente informasjon på andre tidspunkter enn akkurat idet personen logger inn.

På lengre sikt vil vi kanskje se på noe av dette. For eksempel kan det være nyttig å ha mulighet til å sjekke om en person fremdeles eksisterer hos skoleeieren. Om han har sluttet kan tjenestene få beskjed om dette og de kan rydde vekk personer som ikke er tilknyttet skoleeierne lenger.

Men inntil videre er dette begrensningene som er lagt på hva innloggingstjenesten får til å gjøre. Mye av det er av personvern- og sikkerhetshensyn slik at innloggingstjenesten ikke blir et punkt der man kan hente ut veldig mye informasjon om utdanningssektorens over 1 million personer.

Til toppen av siden

 

Informasjonsflyt for tjenester som trenger mer informasjon

For tjenester som trenger mer informasjon enn det som ligger i Feide-skjemaet må de i dag hente informasjonen direkte fra hver enkelt skoleeier. Det samme gjelder for tjenester som trenger informasjon om elever, lærere og deres grupper før personene logger inn første gang.

dataflyt-figur6
Figur 6: Tjenester som trenger informasjon som ikke er tilgjengelig i Feide må hente denne direkte fra hver enkelt skoleeier

Dette er mer krevende enn informasjonshenting gjennom Feide da tjenesten må få informasjon fra alle sine kunders IdM-systemer. For mange tjenester blir det snakk om å hente informasjon fra ti- og hundretalls skoleeiere.

dataflyt-figur7
Figur 7: En tjeneste som trenger mer informasjon må hente den fra hver enkelt skoleeier. For mange tjenester blir dette gjerne ti- til hundretalls skoleeiere de må hente informasjon fra

Det enkleste for tjenesteleverandøren, og skoleeierne, er om tjenesten kan holde seg til informasjonen den får gjennom Feide, men i de tilfeller der dette ikke er tilstrekkelig vil vi anbefale at informasjonen overføres på et av to formater:

  • PIFU-IMS – IMS Enterprise tilpasset norsk utdanning
  • ABC Enterprise – Norsk format som er implementert mange steder, men som ikke vedlikeholdes lenger og bør erstattes av PIFU-IMS

Ta kontakt med IKT-senterets standardiseringsprosjekt om du har spørsmål rundt disse formatene.

Til toppen av siden

 

Gruppeinformasjon i Feide

Informasjonen tilgjengelig gjennom Feide kan sies å være personsentrert. Eleven eller læreren logger inn og henter ut informasjon om seg selv. Dette gjør at informasjonen som blir sendt over til tjenester har personen som grunnelement. Elevens navn, elevens identifikatorer, elevens tilhørighet til en skoleeier, elevens tilhørighet til skoler og så videre.

Dette i motsetning til å se det fra en skoleeiers synsvinkel med et sett av skoler som har en mengde elever og lærere som medlemmer, basisgrupper som inneholder et utvalg av elever og så videre.

Gruppeinformasjon i Feide vil derfor være på formen ’denne eleven tilhører gruppe x, y og z’ ofte uten mye informasjon om selve gruppen.

Til toppen av siden

Tilhørighet til skoleeier og skoler

Frem til og med versjon 1.4.1 av Feide-skjemaet inneholdt Feide i grunnopplæringa bare to grupperinger, begge administrative:

  • Skoleeieren personen tilhører, typisk en kommune, fylkeskommune eller privat skoleeier. En person tilhører én skoleeier.
  • Skoler personen tilhører. En person kan tilhøre ingen, en eller flere skoler samtidig.

Det at en person tilhører én skoleeier er en sannhet med modifikasjoner. I og med at Feide har distribuert informasjonen ut til alle skoleeierne vil en person som har tilknytning til flere skoleeiere ha en Feide-bruker hos hver av skoleeierne. For eksempel vil en person som er student på videreutdanninga på NTNU og lærer i Trondheim kommune ha en Feide-bruker i NTNUs Feide-katalog og en annen i Trondheim kommunes Feide-katalog. Så personen er tilknyttet to skoleeiere, men hver av hans to Feide-brukere er bare tilknyttet én skoleeier hver.

Ikke alle personer i Feide tilhører en skole. Disse vil typisk arbeide med utdanning sentralt i kommunen, gjerne i utdanningsavdelingen eller IT-avdelingen.

Til toppen av siden

Trinn og andre Grep-koder

I arbeidet med oppdatering av Feide-skjemaet til versjon 1.5, som er gjeldende versjon, spurte vi tjenester hvilke grupper de ønsket seg gjennom Feide. Stort sett ønsket de seg informasjonen som lå i det den gang relativt nye Grep-kodeverket fra Utdanningsdirektoratet.

De pedagogiske grupperingene som ble tatt inn i versjon 1.5 av Feide-skjemaet ble derfor:

  • Grep-kodene for trinn for grunnskolen og videregående opplæring.
  • Grep-kodene for utdanningsprogram i videregående opplæring
  • Grep-kodene for programområde i videregående opplæring
  • Grep-kodene for fag i grunnskolen og videregående opplæring

Trinn er obligatorisk for elever i både grunnskolen og videregående. Utdanningsprogram og programområde er obligatorisk for elever i videregående. Fag er valgfritt for elever på begge nivåene.

De fleste elever vil bare ha ett trinn, utdanningsprogram og programområde. Det er likevel en liten mulighet for at en elev kan være registrert på flere av disse samtidig. Tjenester bør derfor ta høyde for dette. Om fag er registrert vil en elev naturlig nok ha mange fagtilknytninger samtidig.

For rollen lærer er Grep-kodene valgfritt å fylle ut og de fleste har det ikke. Noen kan ha det fylt ut og sannsynligheten for at en lærer har flere tilknytninger til forskjellige trinn, utdanningsprogram og programområder samtidig er naturlig nok mye høyere enn for en elev.

For mer informasjon om Grep-kodene og deres verdier se:

Ikke alle har oppdatert til nyeste versjon

Versjon 1.5 av Feide-skjemaet ble satt i 2010, men fremdeles er det en del skoleeiere som ikke har fått inn de nye informasjonselementene i sine lokale Feide-kataloger. Mange kommuner har fått inn trinn på sine elever, men noen mangler dette fremdeles.

For videregående opplæring er det foreløpig bare en privatskole som har fått på plass trinn, utdanningsprogram og programområde for sine elever. Jeg har et håp om at fylkeskommunene skal begynne å komme etter til skolestart 2013/2014.

I dag viser rapportene våre at 80% av skoleeierne i grunnopplæringa sier de er på versjon 1.5. I prinsippet skal de da ha Grep-kodene inne.

Årsakene til at det tar såpass lang tid er mange, men for Grep-kodene har vi en situasjon der informasjonen ikke har vært lett tilgjengelig. Kodene ligger ofte SASet, men har ikke blitt overført til IdM-systemet. Og da har det heller ikke vært mulig for IdM-systemet å legge denne informasjonen ut i Feide-katalogen. Se figur 1 og figur 2.

For trinn, som er rimelig statisk og et veldig lite sett med mulige verdier, har noen utledet informasjonen fra annen informasjon i IdM-systemet. For utdanningsprogram, programområder og fag er mengden verdier mye større. En del av den endrer seg over tid. Å utlede korrekt informasjon for store mengder elever blir da mer utfordrende.

SASene og IdM-systemet som de fleste fylkeskommunene og mange kommuner bruker driver nå og implementerer PIFU-IMS, som har støtte for Grep-koder og andre typer grupper. Forhåpentligvis blir implementasjonen ferdig i løpet av våren og Grep-kodene kan flyte fra SASet, gjennom IdM-systemet og til Feide-katalogen.

Men det vil fremdeles ta tid fra implementeringen er ferdig til de forskjellige skoleeierne har oppdatert sine systemer lokalt.

Til toppen av siden

Basisgrupper og undervisningsgrupper

I det siste året eller to har vi begynt å få spørsmål om Feide ikke også kan overføre informasjon om basisgrupper/klasser og undervisningsgrupper/faggrupper. Typisk at en elev eller lærer tilhører klasse 10A og undervisningsgruppe 2AIS – Valgfag Elevavis.

Dette er ikke informasjon Feide har mulighet til å overføre til tjenester i dag. Disse gruppene ikke er med i Feide-skjemaet og informasjonen er heller ikke er tilgjengelig i Feide-katalogen ute hos skoleeierne. Dessverre er det derfor ingen magisk bryter vi bare kan skru på.

Spørsmål om disse gruppene ser ut til å komme oftere og oftere fra tjenesteleverandører så det virker som om det er et behov for denne informasjonen og et ønske om at de skal bli tilgjengelige gjennom Feide.

Det vi i Feide har gjort for å imøtekomme dette er i første omgang å åpne for at sektoren kan prøve ut forskjellige måter å utveksle disse gruppene, og eventuelt andre gruppetyper, i tilknytning til Feides innloggingsløsning. Når vi har fått litt erfaringer kan Feide få dette inn i en ny versjon av Feide-skjemaet eller anbefale en annen måte å gjøre dette på.

Foreløpig er det foreslått tre alternativer.

Til toppen av siden

 

Fremtidig alternativ 0: Vi fortsetter som nå uten endringer i Feide

Feide styres i stor grad av de samlede behovene hos skoleeierne. Det er skoleeierne som sitter på informasjonen som brukes i Feide og det er de som må endre sine systemer for å gjøre ny informasjon tilgjengelig for Feide og tjenester.

Det er de ca. 500 skoleeierne som må bruke en god del ressurser for å få ny informasjon til å flyte i sine interne systemene og det er erfaringsmessig også der den største tregheten ligger. Noen skoleeiere er veldig raske, mens hos andre havner denne typen endringer lenger ned på prioriteringslista i konkurranse med andre oppgaver.

Feide sentralt, og ikke minst tjenesteleverandørene, bruker også mye ressurser her, men stort sett kan vi si at den største utfordringen er å få med alle skoleeierne.

Så nullalternativet er å ikke innføre noe nytt for å få overført andre typer gruppeinformasjon enn dagens skoleeier, skoler og Grep-koder.

Tjenester som trenger mer informasjon må få denne utlevert fra hver enkelt skoleeier som i dag. Læringsplattformene er et eksempel på tjenester som gjør dette. Dette kan gjøres på forskjellige formater, men som beskrevet over anbefaler vi PIFU-IMS eller ABC Enterprise. Se figur 6.

Fordelen er at disse uttrekkene er tilgjengelige fra de fleste skoleeierne i dag slik at de ikke trenger å gjøre noen større endringer.

Ulempen er selvsagt at tjenestene må hente denne informasjonen fra hver enkelt av de opp til 500 skoleeierne de har som kunder i grunnopplæringa. Og skoleeiere må sende informasjon til alle tjenestene som har behov for denne informasjonen hver for seg. Se figur 7.

Til toppen av siden

 

Fremtidig alternativ 1: Flere grupper sendes gjennom Feide

Det første alternativet vi i Feide har åpnet for utprøving er å sende informasjonen om basisgrupper og undervisningsgrupper gjennom Feide på samme måte som Grep-kodene sendes i dag.

dataflyt-figur8
Figur 8: Mer gruppeinformasjon sendes gjennom Feide

Tjenestene vil da kunne bruke disse gruppene på samme måte som de i dag kan bruke Grep-kodene som sendes over. I og med at det ikke er noen nasjonal samordning på navngivningen av basisgrupper og undervisningsgrupper vil det være variasjoner i hva disse gruppene kalles fra skoleeier til skoleeier.

Så vidt vi har oppfattet er dette som regel ikke noe problem for tjenestene. Navnene gir mening for elevene og lærerne som bruker tjenestene og det er sine egne grupper de ser.

For å få prøvd ut dette alternativet er vi avhengige av at noen skoleeiere og tjenester tilpasser sine løsninger. Skoleeierne må legge informasjonen ut i Feide-katalogen og tjenestene må kunne motta den.

Innloggingstjenesten i Feide trenger ikke å gjøre noen store endringer med dette alternativet, men vi må forsikre oss om at den økte informasjonsmengden flyter godt gjennom innloggingssystemet. For en typisk elev kan det se ut som om informasjonsmengden omtrent dobles i størrelse. Sannsynligvis må vi dimensjonere opp maskinparken om dette blir en løsning som skal tas i bruk for hele sektoren.

Fordelen med dette alternativet er at tjenestene kan hente gruppeinformasjonen gjennom Feide i stedet for å måtte hente den fra hver enkelt skoleeier. På samme måte legger skoleeiere informasjonen bare i sin egen Feide-katalog i stedet for å sende den direkte til alle tjenestene.

Ulempen ligger i at alle skoleeiere og tjenester må gjøre endringer i sine lokale systemer for å tilby og bruke seg denne informasjonen. Som vi har sett med innføring av Grep-kodene tar dette lang tid så fremt vi ikke får satt det høyt nok på prioriteringslisten til alle parter.

En annen ulempe er at dette ikke er en løsning for tjenester som trenger informasjon før eleven eller læreren kommer til tjenesten. Som annen informasjonen i Feide vil denne gruppeinformasjonen bare være tilgjengelig idet elever og lærere logger inn.

Til toppen av siden

 

Fremtidig alternativ 2: Grupper hentes på siden av Feide

Det andre alternativet vi har åpnet for er å sette opp et lager for gruppeinformasjon på siden av selve innloggingstjenesten.

Dette attributtlageret kan være felles for hele sektoren, bare for grunnopplæringen eller for mindre grupperinger helt ned til hver enkelt skoleeier. I utgangspunktet virker det mest hensiktsmessig å ha færrest mulig attributtlager for samme type informasjon, helst for ett for hele sektoren eller ett for grunnopplæringa.

Med et attributtlager for grupper kan tjenester slå opp informasjon om basisgrupper og undervisningsgrupper der. Avhengig av modell som velges kan vi begrense det til

  • oppslag idet en person logger inn på samme måte som alternativ 1
  • oppslag uavhengig av om personen er innlogget eller ikke, men etter at personen har gitt samtykke til utvekslingen en gang
  • oppslag uavhengig av personen har logget inn, men basert på en avtale mellom skoleeieren og tjenesten
  • en kombinasjon av disse

dataflyt-figur9
Figur 9: Attributtlager for grupper på siden av innloggingstjenesten

Fordelen med et attributtlager på siden av Feide, men som fungerer i samspill med innloggingstjenesten, er at vi kan være mer fleksibel med hvordan informasjonen utveksles. Vi kan også enklere utvide attributtlageret med annen type informasjon etterhvert som behovene endrer seg i sektoren.

Både skoleeiere og tjenester får én løsning å forholde seg til for utvidet informasjon. Feides innloggingstjeneste blir i stor grad uforandret og blir ikke tynget ned med ny informasjon etterhvert som nye behov dukker opp.

dataflyt-figur10
Figur 10: Både skoleeiere og tjenester forholder seg bare til innloggingstjenesten og ett attributtlager

Ulempen er at dette er det mest uklare av alternativene og som trenger mest arbeid for å få på plass i første runde. Det er uklart hvordan en slik løsning kan realiseres og hvem skal ha ansvaret for den. Og ikke minst er det usikkert om aktørene i sektoren er villige til å ta utviklings- og driftskostnaden både lokalt og for det sentrale attributtlageret.

Personlig tror jeg dette alternativet er det beste på lang sikt og kan gi oss en større fleksibilitet og mindre ressursbruk i fremtiden.

Til toppen av siden

 

Veien videre

Foreløpig er veien videre uavklart. Som sagt har vi i Feide åpnet for utprøving av disse alternativene for å finne en god måte å utveksle mer informasjon mellom skoleeiere og tjenester. Vi er avhengige av at skoleeiere og tjenesteleverandører er villige til å bli med på utprøving. Etter en pilotperiode ganske sikkert den løsningen justeres, kanskje endres radikalt. I verste fall kan resultatet av utprøvingen bli at den ikke videreføres i det hele tatt.

IKT-senteret ønsker ganske sikkert å bidra aktivt i forskjellige piloter, men da må vi også få/sette av større ressurser til dette arbeidet fremover enn det vi har hatt mulighet til og prioritert hittil. Vi tar gjerne imot kontakt fra skoleeiere og tjenester som ønsker å være med på dette arbeidet.

Etter utprøving, og etter en beslutningsprosess som vil involvere mange parter i sektoren, vil Feide kunne komme med en endring eller en anbefaling som så kan innføres i hele grunnopplæringa. Tiden det vil ta avhenger veldig av hvor store endringene blir og ikke minst hvor høyt skoleeierne prioriterer disse endringene.