Bjørn Ness: “Aagedal-utvalgets rapport del 2: Problemstillingene”

Aagedal-utvalgets rapport del 2: Problemstillingene
Date: Tue, 24 Mar 2009 01:19:33 +0100
From: Bjørn Ness 

To: Tove Kristin Karlsen <t.k.karlsen@admin.uio.no>, 
    Benedicte Rustad <benedicte.rustad@jus.uio.no>,
    Ellen Millar <e.o.millar@admin.uio.no>, 
    Ellen Johanne Caesar <e.j.caesar@admin.uio.no>,
    Arne Laukholm <arne.laukholm@admin.uio.no>, 
    Lars Oftedal <lars.oftedal@usit.uio.no>


----------------------------------------------------------------------------
DE VIKTIGSTE PROBLEMSTILLINGENE,
- Hva er de sentrale og viktigste elementene å ta tak i av forslagene i
  Aagedal-utvalgets rapport?
----------------------------------------------------------------------------

Det er ingen tvil om at det underliggende premiss i Aagedal-utvalgets
rapport har full tilslutning, - IS-systemer (administrative systemer) er
ikke og skal ikke være en konkurransearena mellom UH-institusjonene. Både på
dette og på IT-området i bredere mening er det fellestjenester og
fellesløsninger som skal være fokus.

Aagedal-utvalgets skisserer en del tiltak med sikte på å få bedre grep om
organisering, styring og forvaltning av denne virksomheten. Den medisinen de
foreskriver inneholder noen åpenbart riktige elementer og på mange områder
diskutable og kontroversielle tiltak. Jeg har forsøk å sortere noe av dette
i ti problemstillinger:

 [1] Hva er nedslagsfeltet, hva er problemområdet?
 [2] Hvem er interessentene og hvilke aksjer har de i løsningene?
 [3] Hva er gevinstene og hvordan sikre best mulig gevinstrealisering?
 [4] Hva er en hensiktsmessig kategorisering av systemene?
 [5] Hvordan struktureres roller, ansvar og oppgaver best?
 [6] Hva betyr IT-strategi og IT-arkitektur for offentlig sektor?
 [7] Hvem kan eie en IT-strategi og en IT-arkitektur for UH-sektoren?
 [8] Hva med institusjonenes beslutningsmyndighet?
 [9] Hva er KDs rolle? Andre aktørers rolle?
 [10] Hva er egentlig samarbeidsflatene, hva skal det samarbeides om
      og hvordan?

Her er det spørsmål [10] som er det altoverskyggende viktige, de ni andre er
egentlig ikke mer enn kommentarer til selve rapporten. Det tiende spørsmålet
er det som bør være vårt svar på utfordringene vi står overfor.


[1] Hva er nedslagsfeltet, hva er problemområdet?
-------------------------------------------------
Aagedal-utvalget omhandler IS (informasjonssystemer, administrativ
databehandling). IS er en grunnleggende del av IT-virksomheten ved
institusjonene og i sektoren, både på egne premisser og gjennom sine bidrag
til realiseringen av primærvirksomheten (forskning, utdanning, formidling).

Utvalgets rapport drøfter ikke dette forholdet mellom IS og IT og bruker
disse begrepene om hverandre. Denne sammenblandingen er en vesentlig kilde
til forvirring og uklarhet omkring flere av premissene og tiltakene i rapporten.

Det er ikke noen triviell oppgave å gi en skarpt formulert definisjon av IS
og IT og en ditto formulert plassering av de to i forhold til hverandre.
Tror ikke desto mindre at det er viktig å presisere at:

 [a] IS er en del av et større hele, IT-virksomheten ved institusjonene
     og i UH-sektoren
 [b] Ved siden av IS består IT-virksomheten av en rekke fellestjenester
     som alle bruker og en rekke tjenester og løsninger som inngår i de
     ulike delene av primærvirksomheten, - forskning, utdanning og
     formidling
 [c] IS er spesiell i den forstand at den leverer data og funksjonalitet
     til andre deler av IT-virksomheten og ved at den leverer data som
     danner grunnlag for styring, rapportering og finansiering av
     virksomheten
 [d] IS er stor og legger beslag på betydelige ressurser (400 mkr for
     sektoren som helhet anslår utvalget) og bedre kvalitet og høyere grad
     av ressursutnyttelse på dette omrpdet kan frigjøre ressurser for
     primærvirksomheten

På denne bakgrunn er det ikke riktig å tillegge en organisering på
IS-siden ansvar og oppgaver knyttet til:

 * IT-strategi
 * IT-arkitektur

Dette er oppgaver som må løses av andre organer og som må involvere
andre deler av virksomheten for å ivareta primærvirksomhetens behov. De
sentrale spørsmålene er egentlig:

 * Hva er IS sin plass i en IT-strategi og IT-arkitektur?
 * Hva er spesifikke IS-momenter i en IT-strategi og IT-arkitektur?


[2] Hvem er interessentene og hvilke aksjer har de i løsningene?
----------------------------------------------------------------
Rapporten er i liten grad eksplisitt i vurderingen av hvilke
interessenter (eller problemeiere) som har hvilke aksjer i løsningene.
Det går an å lese noe av dette ut fra innstillingen, men bildet er ikke
så klart og tydelig som en systematisk interessentanalyse ville gitt.
Noen aktuelle interessenter å analysere og kartlegge aksjene til, ville
vært:

 * Departementet
 * Sektorinterne organer, organisasjoner og institusjoner
 * Institusjonene
   - Store institusjoner
   - Små institusjoner
   - Institusjonenes ledelse
   - Prosesseiere (systemeiere)
   - Virksomhetsområdene
     . Forskning
     . Utdanning
     . Formidling
 * Brukerne
   - Allmennheten
   - Offentlig forvaltning
   - Organisasjonen og institusjoner i sektoren
   - Institusjonens egne
     . Forskerne
     . Underviserne
     . Studentene
     . Administratorene


[3] Hva er gevinstene og hvordan sikre best mulig gevinstrealisering?
---------------------------------------------------------------------
Det logiske neste skrittet ville vært å systematisere gevinstene som
ønskes realisert med utgangspunkt i en slik interessentanalyse og samlet
dette i en plan for gevinstrealisering.

Arbeidet med fellestjenester og fellesløsninger på UH-sektoren er drevet
av en klar oppfatning av at dette gir noen gevinster som er større en
alternativet (der institusjonene selv sørger for tjenestene og
løsningene på egenhånd):

 * Mer effektiv bruk av ressursene, mer for pengene, kosteffektive
   løsninger
 * Bedre kvalitet på tjenestene og løsningene
 * Høyere tjenestenivå
 * Riktigere fokus på hva det skal samarbeides og konkurreres om

Disse gevinstene må operasjonaliseres i gevinster som i langt større
grad er mål- og evaluerbare. I beste fall er det kun implisitt at det er
mulig å lese slike (et stykke på vei) operasjonaliserte gevinster.

Tror det er nødvendig å gå tydeligere inn i forhold til interessentene,
aksjene de har i løsningene og gevinstene de kan hente ut for å skape
forståelse for oppslutning om og lojalitet til tiltakene og grepene som
foreslås. Ikke minst er dette nødvendig for å identifisere de instansene som
har mest å vinne og som derfor må tyngst inn i arbeidet.

Dette ville kanskje også gjort det tydeligere hva som er hensiktsmessige
tiltak og grep og hvor ansvaret for å håndtere dem ligger.


[4] Hva er en hensiktsmessig kategorisering av systemene?
---------------------------------------------------------
Utvalget kategoriserer systemene etter om de er virksomhetskritisk eller
ikke og om de er egenutviklet eller ikke.

Det er flere problemer med denne kategoriseringen:

 * Hva gjør et system virksomhetskritisk? Hva er virksomhetskritisk? Når
   blir et system virksomhetskritisk?
 * Hvor hensiktsmessig er det å skille ut for- og ettersystemer til et
   virksomhetskritisk system som ikke-virksomhetskritisk?
 * Ville det vært mer hensiktsmessig å se på oppgaver og prosesser, ikke
   systemer som virksomhetskritisk?
 * Når er et system virksomhetskritisk, - hele året eller på bestemte
   tidspunkter?

Et annet aspekt er avgrensingen av informasjonssystemer/administrative
systemer. Hvorfor er plagiatkontroll en del av dette, mens LMS ikke er
det? Er biblioteksystemer å regne som informasjonssystem i denne konteksten?
På minst ett punkt nevner rapporten også web-tjenester, er dette også en del
av IS?

Ville en mer hensiktsmessig tilnærming vært en beskrivelse av
systemlandskapet på IS-området? Dette ville være en beskrivelse som tok
dataflyt som utgangspunkt. I dette ville noen systemer være noder dels i
egenskap av at de leverer data til andre systemer, dels ved at det rundt
nodesystemene er et antall støttesystemer for registrering, rapportering og
andre oppgaver i forhold til nodesystemet.


[5] Hvordan struktureres roller, ansvar og oppgaver best?
---------------------------------------------------------
Et viktig spørsmål å diskutere i det videre arbeidet er den tydelighet
utvalget mener å oppnå ved å rendyrke rollene som kunde og leverandør.

En viktig suksessfaktor for egenutviklete systemer er den tette
koplingen mellom utvikler (leverandør) og kunde (bruker). Dette sikrer
en felles forståelse av både kundens (brukerens) behov og av hva
leveransen skal løse.

Dette er også et viktig forhold når det gjelder anskaffelse av systemer.
Spørreundersøkelsen gir en unison oppslutning om utsagnet
"Fellesløsninger bør være basert på kommersielle standardsystemer med
eventuelt noen tilpasninger" og utvalget tolker dette som et "sterkt
signal". Spørsmålet er om det er noe realisme i dette utsagnet, - lar
våre fellesløsninger seg realisere med noen få tilpasninger av
kommersielle standardsystemer?

Erfaringene er vel heller det motsatte og det har med karakteren av en
del systemer å gjøre. Kommersielle standardsystemer på det nivå det her
er snakk om kommer ikke ferdigpakket i forhold til kundens behov, de må
tilrettelegges og tilpasses organisasjonens behov, samtidig som
organisasjonen må endre sine rutiner og sin arbeidsorganisering. Spørsmålet
er om endringene på begge disse områdene lar seg gjennomføre innenfor en
strengt definert kunde/leverandør-dikotomi.

Faren er tilstede for at en slik dikotomi gjør at kunden sitter på sin
tue og definerer sine krav og behov utfra eksisterende organisasjon,
ikke utfra potensialet som endringer gjennom innføring av nytt system
kan realisere, noe som gir som resultat:

  NT + GO = DGO
  (Ny Teknologi + Gammel Organisasjon = Dyr Gammel Organisasjon)

Det er heller ikke noe automatikk i at en slik todeling sikrer at
helheten blir bedre ivaretatt.


[6] Hva betyr IT-strategi og IT-arkitektur for offentlig sektor?
----------------------------------------------------------------
Aagedal-utvalget er tydelig på at det hverken er ønskelig eller
hensiktsmessig med en IT-strategi og IT-arkitektur som omfatter mer enn
UH-sektoren.

Samtidig er det betydelig aktivitet fra offentlige myndigheters side i
retning av samordning på strategiske områder og utvikling av en
overordnet IKT-arkitektur for offentlig sektor. Dette framtrer som et
slags ris bak speilet i rapporten, - dersom sektoren nå ikke klarer å
ordne dette på en tilfredsstillende måte, så vil andre komme inn med
sterkere sentralisering og sentral styring som resultat.

Hvor reelt dette er, er det vanskelig å lese ut av rapporten, men det er
absolutt et moment å vurdere siden helt klart finnes organer og aktører
som har klare ambisjoner når det gjelder eierskap og styring av
IT-strategi og IT-arkitektur i offentlig sektor.

Nå er det relativt løse føringer som legges på IT-strategi og
IT-arkitektur for offentlig sektor i St.m. 17 med mer:

 * Universell utforming
 * Døgnåpen digital forvaltning
 * Desentralisert beslutningsmyndighet
 * Programvarepolitikk basert på åpne standarder og åpen kildekode
 * Tverrsektorielle fellesløsninger
 * Felles arkitekturprinsipp for offentlig sektor (hentet fra
   utredningen "Felles IKT-arkitektur for offentlig sektor"):

   - Tjenesteorientering
   - Interoperabilitet
   - Tilgjengelighet
   - Sikkerhet
   - Åpenhet
   - Fleksibilitet
   - Skalerbarhet
   - Felles brukerfront

 * Overordnet sikkerhetsansvar plassert i fagdepartementene

For sektoren vil det være viktig å sikre at arkitekturen etterlever slike
overordnete føringer og prinsipper, men enda viktigere er det å definere og
beskrive konkrete arkitekturkomponenter, - eksempelvis i forhold til roller,
steder, dataelementer, autentisering, autorisering med mer.


[7] Hvem kan eie en IT-strategi og en IT-arkitektur for UH-sektoren?
--------------------------------------------------------------------
Aagedal-utvalget mener at (deler av, uklart hvor mye) en IT-strategi og
en IT-arkitektur for sektoren kan eies av et eget organ og forvaltes
utenfor institusjonene.

Er dette overhodet mulig? Hvem kan "eie" og "eksekvere" en felles
IT-strategi og en felles IT-arkitektur?


[8] Hva med institusjonenes beslutningsmyndighet?
-------------------------------------------------
I KDs strategiske føringer for sektoren, trykt som vedlegg til rapporten
omhandler det første punktet forholdet mellom samarbeid og institusjonenes
beslutningsmyndighet:

 "Utviklingen av fellesadministrative systemer skal skje gjennom
  samarbeid der den enkelte institusjon ivaretar sin
  beslutningsmyndighet"

Det er vanskelig å se at dette er kompatibelt med den rollen og det
ansvar utvalget tillegger UHIS både når det gjelder strategi, arkitektur
og ha ansvar for kundesiden i forhold til de virksomhetskritiske systemene.

Vil institusjonene være villig til å avgi myndighet til et slikt organ?


[9] Hva er KDs rolle? Andre aktørers rolle?
-------------------------------------------
Forøvrig kan det være på sin plass å se nærmere på både KDs strategiske
føringer og KDs rolle. Utover ovennevnte lister KD opp følgende
strategiske føringer for arbeidet med administrative fellessystemer:

 * Utvikle standardisering og interoperabilitet på tvers av systemer og
   institusjoner for å tilrettelegge for god informasjonsutveksling

 * Etablere felles arkitekturprinsipp for sektoren for å bedre samspill
   mellom systemene (teknologisk og organisatorisk). Dette må utdypes
   siden arkitekturbegrepet først må utdypes, og det må vurderes på
   hvilket nivå dette skal defineres

 * Anskaffelse og utvikling av ny programvare skal i størst mulig grad
   bygge på åpne standarder og åpen kildekode

 * Etablering av fellesløsninger må balanseres mot behovet for å ivareta
   konkurransen i leverandørmarkedet slik at samarbeidet kan brukes til
   å utvikle gode og serviceinnstilte leverandører

 * Utvikle samarbeidet om IKT-sikkerhet i sektoren med KD som
   koordinator

Med dette og også av andre grunner er det betimelig å stille spørsmål om
hva slags rolle KD skal spille, hva skal KD eie av problemer og løsninger?

Tilsvarende spørsmål bør det stilles ved andre aktører. Å svare på dette
hadde vært mye enklere dersom det var gjort en interessentanalyse og
utarbeidet en plan for gevinstrealisering nevnt ovenfor.


[10] Hva skal det samarbeides om og hvordan?
--------------------------------------------
Det er bred enighet om premisset, - vi tror på samarbeid og
fellesløsninger, vi tror at det gir bedre løsninger for sektoren som
helhet og for den enkelte institusjon. Spørsmålene er da:

 * Hva må samarbeidet og fellesløsningene tuftes på? Felles forståelse?
   Avtaler? Spesielle organisatoriske grep?

 * Hvem er eier av samarbeidet og fellesløsningene? Hvem skal ta
   beslutningene på vegne av fellesskapet? Hvem veier fellesskapets
   interesser mot de spesifikke interessene til fagområdene? Hvor
   plasseres samarbeidskonstellasjonen organisatorisk?

 * Er felles IT-strategi og felles IT-arkitektur en del av grunnlaget
   som samarbeidet må tuftes på? I tilfelle svaret er ja:

   - Hvor langt går dette? Kun prinsipper eller fullt utviklet strategi
     og arkitektur? Hva vil det i så fall inneholde?
   - Hvor plasseres i så fall dette i forhold til institusjonenes
     strategi og arkitektur? I forhold til departementets? Offentlig
     sektors?
   - Hvilke plass har IS-strategi og IS-arkitektur i dette bildet?

 * Hva er de viktigste samarbeidsflatene for fellesløsningene?

   - Anskaffelse og innføring?
   - Systemutvikling?
   - Implementering?
   - Arkitektur og arkitekturprinsipper?
   - Integrasjon?
   - Sikkerhet?
   - Felles datadefinisjoner? Eierskap til dataelementer?
   - Driftsløsninger?
   - Brukergrensesnitt og brukerinteraksjon?
   - Felles forvaltning og endringshåndtering?
   - Retningslinjer og reglement?