Felles studieadministrativt tjenestesenter (FSAT) Vedlegg til FSAT Rapport fra organisasjonsprosjektet

Transkript

1 Felles studieadministrativt tjenestesenter (FSAT) Vedlegg til FSAT Rapport fra organisasjonsprosjektet

2 Felles studieadministrativt tjenestesenter (FSAT) Ny organisering av FSAT analyse og vurdering av alternative modeller Notat fra prosjektgruppa for organisasjonsprosjektet. 27. november

3 Innhold 1 INNLEDNING 3 2 BAKGRUNN OG MÅL FOR ARBEID MED ORGANISASJONSSTRUKTUR BAKGRUNN FOR ARBEIDET MÅLBILDE FOR FSAT FORVENTNINGER TIL EN NY MODELL 4 3 DAGENS ORGANISERING TIDLIGERE ORGANISERING AV SUN TIDLIGERE ORGANISERING AV FS-SEKRETARIATET TIDLIGERE ORGANISERING AV SO 8 4 VURDERING AV FREMTIDIGE ORGANISASJONSMODELLER FOR FSAT MODELL 1 - ORGANISERING ETTER KJERNEOPPGAVENE FORVALTNING OG UTVIKLING Beskrivelse og vurdering av modell MODELL 2 - ORGANISERING ETTER KJERNEOPPGAVENE UTVIKLING, FORVALTNING OG SAKSBEHANDLING Beskrivelse og vurdering av modell MODELL 3 ORGANISERING ETTER SYSTEMER Beskrivelse og vurdering av modell 3: 17 2

4 1 Innledning I dette notatet synliggjør vi alternative måter å organisere FSAT på. Notatet bygger på prosjektgruppas arbeid i uke samt på relevante innspill fra fellessamlingen på Leangkollen oktober. Notatet er i første omgang ment som et diskusjonsgrunnlag til seminaret med alle ansatte 4. desember og skal deretter bearbeides. Notatet gir en begrunnelse for hvorfor arbeidet med organisasjonsstruktur er satt i gang, tydeliggjør noen viktige kriterier for en ny organisasjonsstruktur, og presenterer deretter noen alternative modeller for organisering av FSAT. 2 Bakgrunn og mål for arbeid med organisasjonsstruktur 2.1 Bakgrunn for arbeidet Samarbeidstiltaket FS (SFS), Samordna opptak (SO) og USITs seksjon for utvikling av nasjonale informasjonssystemer (SUN) ble samorganisert 1. juli 2014 som et tiltak under Kunnskapsdepartementet. KD har oppnevnt et styre og fastsatt vedtekter for den nye organisasjonen. Universitetet i Oslo vil være vertsinstitusjon, og skal levere administrative tjenester til den nye organisasjonen som har fått navnet Felles studieadministrativt tjenestesenter (FSAT). De ansatte er formelt tilsatt ved Universitetet i Oslo, men med tjenestested i FSAT. Styret har initiert et organisasjonsprosjekt der målet er å etablere den nye organisasjonen slik at man oppnår best mulig effekt av sammenslåingen. Prosjektet skal anbefale forslag til organisering av FSAT i form av et nytt organisasjonskart med en tydelig funksjonsinndeling og lederstruktur, med klare roller og ansvarsforhold. Forslaget til organisering av FSAT skal i etterkant av et endelig vedtak benyttes som et grunnlag for å utarbeide konkrete funksjons- og bemanningsplaner for den nye organisasjonen. 2.2 Målbilde for FSAT Et målbilde kan forstås som beskrivelsen av en ønsket fremtid for FSAT når det gjelder forhold som struktur, kultur, arbeidsmåter, roller, ledelse og styring mm. Målbilde for FSAT er fremkommet gjennom en bred prosess der alle ansatte har vært involvert før styret har vedtatt et endelig målbilde. Målbilde for FSAT er kategorisert i seks dimensjoner som dekker ulike aspekter ved den nye organisasjonen. I det etterfølgende presenterer vi sentrale målformuleringer for hver av dimensjonene i målbilde: Tjenestesenterets rolle FSAT skal forvalte, utvikle, vedlikeholde og drifte studieadministrative systemer og tjenester til beste for sine brukere. Sammenslåingen skal bidra til at FSAT fremstår som en tydelig aktør med et bredt samarbeid og stor gjennomslagskraft i samspill med sektoren. Våre leveranser FSAT skal levere raske leveranser med høy kvalitet til sine brukere. Sammenslåingen skal medføre en enda mer brukertilpasset leveranse som ser hele prosessen i sammenheng "fra vugge til grav«og med mulighet til synergi og bedre tjenester. 3

5 Samspillet med brukerne FSAT skal være en løsningsorientert samarbeidspartner som evner å fange opp og ivareta brukernes behov og ønsker. FSAT skal utfordre egne og brukernes etablerte rutiner når det er hensiktsmessig. FSAT skal opptre forutsigbart, skape realistiske forventninger og begrunne sine prioriteringer. FSAT skal fremstå med nærhet og tilgjengelighet til brukere og samarbeidspartnere. Det indre liv FSAT skal ha et arbeidsmiljø som fremmer trivsel og arbeidsglede, samtidig som det er en kultur for resultatoppnåelse. FSAT sine ansatte får utvidet oversikt over sitt ansvarsområde og tilgrensende felt. Ansatte får flere anledninger for kompetanseutvikling, da miljøet besitter mer variert og samtidig mer fullstendig kompetanse. Arbeidsmiljøet skal preges av frihet og fleksibilitet med mulighet for faglig utvikling. Effektiv drift av organisasjonen FSAT skal opptre med drifts- og kostnadseffektivitet gjennom hele organisasjonen. Vi skal legge vekt på å unngå dobbeltarbeid og gjenbruke løsninger der dette er mulig også utenfor egen organisasjon. Innovasjon og nyskapning FSAT skal ha god kapasitet (struktur og kultur) for innovasjon og nyskapning, og samtidig trekke veksler på innovasjonskraften hos brukere og samarbeidspartnere. FSAT skal være i front nasjonalt og internasjonalt med tanke på å utvikle og forvalte digitale arbeidsprosesser på det studieadministrative området. For å realisere dette målbilde må FSAT som organisasjon fungere best mulig. Dette krever at det settes fokus på ulike tiltak hvor arbeid med ny organisasjonsstruktur kun er et av virkemidlene. Utvikling av god ledelse, gode møteplasser, gode rutiner, gode prosesser, god samhandling, god rolleforståelse og god organisasjonskultur er vel så viktige faktorer. Når en ny organisasjonsstruktur er på plass, må slike forhold derfor sikres tilstrekkelig fokus. 2.3 Forventninger til en ny modell FSAT har gjennom en bred prosess definert et sett av kriterier eller krav til den nye organisasjonsstrukturen som skal etableres for FSAT. Kriteriene baserer seg på de innspill som ble gitt av de ansatte i FSAT under fellessamlingen på Leangkollen 16. og 17. oktober, og er revidert etter møter i prosjektgruppa og styringsgruppa. Kriteriene har utgjort et bakteppe for prosjektgruppas arbeid med å skissere opp alternative organisasjonsmodeller og vil senere anvendes i en analyseprosess, der kriteriene vil bli lagt til grunn for vurdering av hvilken modell som er mest hensiktsmessig ift FSAT sine behov. Kriteriene anses alle som viktige og vi har derfor valgt ikke å gi prioritet til noen av dem. I vurdering av fremtidige modeller anbefales det at alle de seks kjennetegnene vektes like sterkt. Prosjektgruppen understreker til slutt at den strukturen man vedtar som et resultat av denne prosessen ikke kan være hugget i stein for evigheten. Nye strategier, ny teknologi, nye 4

6 fremtidige oppgaver og nye brukere vil kunne medføre behov for større eller mindre justeringer av strukturen i årene som kommer. Tydelig rolle- og ansvarsfordeling: Både innad i avdelingen og ut mot brukerne må roller og ansvar være tydelig definert og forstått. Strukturen skal bidra til å tydeliggjøre rollefordelingen i organisasjonen og må vise hvem som har beslutningsmyndighet på hvilke områder og nivåer. Strukturen skal tilstrebe å angi entydige myndighetsforhold, og sikre at faglig ledelse og personalledelse er synkronisert. Ledelseskraft: FSAT skal organiseres med tanke på å sikre ledelseskraft i hele organisasjonen. Strukturen må underbygge strategisk styring og tilrettelegge for god prioritering og samordning på alle ledernivåer. Organisasjonsstrukturen må bygge opp under målet om at vi skal bli EN organisasjon: Sammenslåingen må innebære en reel fusjon der man oppnår reelle gevinster som følge av at det indre liv fungerer på en god måte under felles ledelse. Vi skal ha en struktur som tilrettelegger for økt samordning, felles prioritering og samarbeid mellom de gamle enhetene slik at FSAT ivaretar helhetlig tenkning og handling i sine interne prosesser. Vi skal fremstå som EN enhet overfor brukerne våre: FSAT må organiseres slik at man fremstår som helhetlige og koordinerte overfor brukerne, og skal sikre en best mulig samhandling med sektoren. Videre er det behov for en kommuniserbar og forståelig struktur som er lett å forholde seg til for de som er utenfor. Sikre god kommunikasjon og samhandling på tvers: Organiseringen av FSAT kan ikke være for rigid, og må legge til rette for at intern informasjon, kommunikasjon, kompetansedeling og arbeid på tvers av grunnstrukturen kan fungere hensiktsmessig fra dag en. Robusthet og effektivitet i oppgaveløsning: For å styrke dette skal vi tilstrebe å samordne oppgaver og funksjoner som hører naturlig sammen. Organiseringen må bidra til å skape en struktur som i minst mulig grad skaper fragmentert oppgaveløsning, dobbeltarbeid og gråsoneproblematikk. Organiseringen skal dessuten bidra til å samle og utvikle kompetanse for å redusere sårbarhet og øke kvalitet i tjenestene. Underbygge innovasjon og nyskapning: FSAT skal ha en struktur som bidrar til innovasjon og nyskapning for sektoren. Dels kan dette ha konsekvenser for hvilke funksjoner som tydeliggjøres i organisasjonskartet og dels kan det bety noe for hvordan man grupperer funksjoner og oppgaver innenfor de ulike boksene i kartet. Et «passe stort» kontrollspenn: Organiseringen må sikre en god balanse mellom høyde og bredde i strukturen. Den må både sikre at den enkelte leder har et kontrollspenn som er realistisk ift til den ledelsen som forventes, og at antall ledernivåer er hensiktsmessig. 5

7 3 Dagens organisering Felles studieadministrativt tjenestesenter (FSAT) er et forvaltningsorgan under Kunnskapsdepartementet. Styret for senteret har det overordnede ansvaret for den faglige virksomheten og for de administrative oppgaver som er lagt til senteret. FSAT skal forvalte, utvikle, vedlikeholde og drifte studieadministrative systemer og tjenester til norske universiteter og høgskoler (brukerne). Systemene og tjenestene skal bidra til mest mulig effektiv og korrekt studieadministrasjon. FSAT er oppstått som en sammenslåing av Seksjon for utvikling av nasjonale informasjonssystemer (SUN) som tidligere var en del av Universitetets senter for informasjonsteknologi (USIT), Samarbeidstiltaket Felles Studentsystem (FS) og Samordna opptak (SO). Vi vil i det etterfølgende gi en kort presentasjon av hvordan de tre enhetene som i dag utgjør FSAT tidligere var organisert. Organisasjonskartene er hentet fra/utledet av de respektive organisasjonenes nettsider. 3.1 Tidligere organisering av SUN SUN utvikler store administrative informasjonssystemer for forsknings- og utdanningssektoren i Norge. Fokus har primært vært på områder der ferdigsystemer ikke er tilgjengelige i markedet. Utvikling betyr at man lager nye systemer, verktøy eller tjenester. Dette til forskjell fra der man behandler data eller benytter allerede eksisterende verktøy og tjenester for å utføre sine oppgaver. SUN har tidligere vært organisert i 5 grupper. 3 av gruppene representerer utviklergrupper som dels har vært organisert etter kompetanse og dels etter system. SUN har bestått 51,2 årsverk. Figur 1: Organisasjonskart SUN 6

8 3.2 Tidligere organisering av FS-sekretariatet FS (Felles studentsystem) er et studieadministrativt system utviklet for universiteter, vitenskapelige høgskoler, og statlige høgskoler. Systemet er også tilgjengelig for private høgskoler. Det er i dag 51 institusjoner som bruker FS. Systemet var heleid av brukerinstitusjonene og forvaltet av Samarbeidstiltaket FS med Årsmøte som øverste beslutningsorgan. FS-sekretariatet inngikk i Samarbeidstiltaket FS: Figur 2: Organisasjonskart FSS Da FS-sekretariatet består av 4 årsverk har det ikke vært behov for å fokusere på den indre organiseringen. Figuren nedenfor representerer derfor snarere en oversikt over FS sine roller snarere enn organisatorisk inndeling. Figur 3: Organisasjonskart FS-sekretariatet 7

9 3.3 Tidligere organisering av SO Samordna opptak (SO) ble opprettet i 1994 av Utdannings- og forskningsdepartementet (nå Kunnskapsdepartementet) som et service- og koordineringsorgan for opptak til grunnutdanninger ved universiteter og høgskoler. I dag koordinerer Samordna opptak opptaket til 43 universiteter og høgskoler. SO har vært organisert med stab og to fagavdelinger. SO har hatt i overkant av 30 årsverk på permanent basis. Figur 4: Organisasjonskart Samordna opptak 4 Vurdering av fremtidige organisasjonsmodeller for FSAT I det etterfølgende presenterer prosjektgruppen tre hovedmodeller til en fremtidig organisering av FSAT. For alle tre modellene vil det i prinsipp være tenkelig at plassering av funksjoner/oppgaver og ressurser beveger seg på to måter: Vertikalt i organisasjonen, dvs. fra avdelinger/seksjoner til stab og omvendt Horisontalt i organisasjonen, dvs. mellom seksjonene/avdelingene Dette innebærer at det for alle hovedmodellene vil være mulig å skissere ett eller flere alternativer der noen oppgaver/funksjoner er flyttet på, men hvor modellen som sådan er lik. De to første modellene baserer seg på en organisering etter kjerneoppgaver/hovedprosesser, mens modell tre baserer seg på en mer systemsentrisk organisering. Etter en foreløpig vurdering av hovedstruktur for organiseringen anbefaler prosjektgruppen modell 2 nedenfor. 4.1 Modell 1 - Organisering etter kjerneoppgavene forvaltning og utvikling Et alternativ vil være å organisere FSAT etter de to kjerneoppgavene som skal ivaretas; utvikling og forvaltning. Under samlingen på Leangkollen var det flere som pekte på, og ga støtte til en slik tenkning. Modellen er vist i figur 4 nedenfor. 8

10 4.1.1 Beskrivelse og vurdering av modell 1 Grunnideen er å organisere FSAT i to avdelinger; Forvaltning og utvikling, som igjen er inndelt i to eller flere seksjoner/grupper. Figur 5: Modell 1 Organisering etter kjerneoppgavene utvikling og forvaltning FSAT sin ledergruppe vil ifølge denne modellen i utgangspunktet bestå av direktør, stabsleder og to avdelingsledere. Modellen vil ha tre formelle ledernivåer; Direktør, avdeling og seksjon eller gruppe. Beslutningsmyndighet knyttet til ressursfordeling fordeles på avdelingsleder, Gruppeleder og teamleder avhengig av hva slags ressursfordeling det er snakk om. Funksjonene som i dag ligger i SO-SI er i denne modellen fordelt på Sekretariatet, Støtte, Datavarehus og Stab (Lokal IT, info) Det dedikeres fagansvarlig på viktige områder som f.eks. sikkerhet, brukertesting, registerforvaltning mm. Om organisering av utviklergruppene Prosjektgruppa legger til grunn at utviklerne i utstrakt grad kommer til å jobbe teamorientert og teamstyrt. Det vil si at team fortsatt vil kunne settes opp på tvers av gruppene ved behov, uansett organisering av disse. Det er helt nødvendig at gruppene opptrer fleksibelt slik at det er mulig å styrke et gitt team ved behov, samt å sørge for at systemkunnskapen spres på flere grupper/utviklere for å redusere sårbarhet. Dette betyr selvsagt ikke tvangsflytting av alle utviklere rundt på alle team. Kontinuitet i teamene er viktig, men man må ha mulighetene åpne for at noen utviklere kan flytte på seg i perioder. 9

11 Vi ser for oss minst fire måter å organisere utviklergruppene på disse alternativene vil kunne være aktuelle for både modell 1 og 2. Etter en foreløpig vurdering anbefaler prosjektgruppen alternativ 3 nedenfor som inndelingsprinsipp for organisering av utviklergruppene. Alternativ 1 Dagens organisering videreføres Utviklergruppene kan tenkes organisert som i dag, altså i en webgruppe, en integrasjonsgruppe og i en gruppe for opptakssystemer. Dette er en kjent inndeling, og man trenger ikke tegne opp nye kart eller bygge nye «team». Dagens grupper er dels inndelt etter fagområde/kompetanse (Web, Int.) og dels etter system (OPSYS). Gruppenes medlemmer synes i praksis å ha en relativt sterk identitet til system. Gruppene vil i størrelse bli akseptabelt store, som i dag. I utgangspunktet gir denne inndelingen et klart ansvarsområde, men i praksis ser man at folk jobber på tvers og rollefordelingen og ansvar er derfor ikke særlig tydelig. For gruppelederne blir det også litt usikkert hvor mye beslutningsmyndighet de har over ressursfordeling, i og med at gruppen i seg selv ikke har noen klare oppgaver. Med ansvar for ulike fagområder så vil dette alternativet kunne bygge opp under en struktur med helhetlig tenking innenfor hvert fagområde og på den måten sikre standardisering. Praksis har imidlertid vist noe annet, men det kan komme av uklare mandater for hver gruppe og ikke selve organiseringen. Inndelingen vil i utgangspunktet legge til rette for god kommunikasjon og samhandling på tvers, da de ulike gruppene kan ha ansvar for å dele kompetanse med de andre gruppene. I tillegg tvinger strukturen frem en utstrakt grad av teamarbeid, noe som er fordelaktig. Det antas også at denne organiseringen gjør det relativt enkelt å ta inn nye oppgaver. Ulempene synes å være at web- og integrasjonsgruppene ikke har spesifikke oppgaver relatert til sitt område og at ansatte til en viss grad synes litt tilfeldig plassert i gruppene (folk i Web jobber med integrasjon, og motsatt). Når vi i tillegg vet at alle utviklergruppene jobber med web og integrasjon virker dagens gruppenavn litt kunstig. I tillegg synes personalledelse og faglig ledelse ikke å være godt nok synkronisert, og gruppeledere sliter med å ha oversikt over alle i sin gruppe da det jobbes mye på tvers/utenfor gruppene. Det kan være utfordrende for gruppeleder å ha oversikt over de som er i deres gruppe. Dette kan gjøre kommunikasjonen i linjen noe utfordrende. Dette skyldes noen ganger at gruppeleder har delegert for mye av ansvaret og ikke selv deltar. Og noen ganger er dette en virkning av at personer i en gruppe jobber «på tvers». Egentlig tilhører de en annen gruppe men for å sørge for balanse i personalansvar er dette et utslag. Alternativ 2 Tilfeldig inndeling I dette alternativet tenkes det en organisering av utviklerne basert på en tilfeldig inndeling i like store grupper. Formålet med organiseringen er todelt: for det første er dette en måte å sikre personalledelse for den enkelte medarbeider og for det andre legger dette alternativet til rette for at man kan bruke ressursene i utviklingsavdelingen på tvers da den enkelte utvikler ikke er låst mot et fagområde/system. Ingen vil under denne inndelingen føle at man har havnet i feil gruppe (eller riktig for den saks skyld), eller at de har fått en merkelapp de ikke kjenner seg igjen i. Det vil være enkelt organisatorisk å spre medarbeidere, og man trenger ikke detaljerte beskrivelser for hver utvikler. Organiseringen vil kunne signalisere at hele utviklergruppa fremstår som en enhet, bare med en personalmessig oppdeling. Denne inndelingen gjør det også svært tydelig at det jobbes i team på tvers. 10

12 Ulempene synes først og fremst å være at dette alternativet innebærer en enda større utydelighet mht. lederansvar, enn alternativ 1. For gruppelederne blir det usikkert hvor mye beslutningsmyndighet de har over ressursfordeling, i og med at gruppene i seg selv ikke har noen klare oppgaver. I dette alternativet må egentlig det faglige formelle ansvaret i linja ligge hos avdelingsleder. Dette kan føre til at avdelingsledernivået blir sittende med et betydelig fagog koordineringsansvar som gjør operativ ledelse vanskelig. Samsvaret mellom personalledelse og faglig ledelse er i liten grad til stede og det kan oppstå store utfordringer knyttet til ressursfordeling så vel som oppfølging. Det kan også bli utfordrende å utvikle en god gruppetilhørighet og gruppelederne vil ha problemer med å kunne støtte alle i sin gruppe da de sannsynligvis ikke vil jobbe med de samme tingene. Alternativ 3 Organisering etter system I dette alternativet ser vi for oss en tydeligere organisering av utviklerne etter system. Her kan man f.eks. se for seg en FS-gruppe, en SO-gruppe, en Cristin gruppe og en DVB-gruppe. Det vil imidlertid også være mulig å tenke seg at gruppene gis mer generiske navn som f.eks. gruppe for studieadministrative systemer, gruppe for opptakssystemer, gruppe for forskningsdokumentasjon, og alternativt gruppe for salg av tjenester. Modellen kan gi en større tydelighet ift roller og ansvar både på gruppe- og avdelingsnivå og det vil være enklere for gruppeledere å utøve ressursstyring så vel som faglig og personlig oppfølging. Ansvarsfordelingen fremstår i denne modellen som tydelig, med hvilken gruppe som har det helhetlige ansvaret for hvert system. Gruppelederen har også en klarere og mer definert rolle og myndighetsforholdet kommer tydeligere frem. Trolig vil det også kunne bli enklere for gruppen som helhet å "samkjøre" og dra i samme retning med felles løsninger. Ulemper er at det kan utvikles tettere skott mellom gruppene, at gruppeidentiteten kan bli for sterk på bekostning av avdeling/organisasjonsidentitet, og at organisasjonen samlet sett vil få utfordringer med koordinering og samhandling på tvers. Innenfor systemene så vil denne modellen helt klart gi en bedre samkjøring, men på tvers av systemene så kan det kan også tenkes at oppgaveløsningen blir fragmentert, medføre dobbeltarbeid og gråsoneproblematikk mellom systemer/grupper. Her vil det derfor hvile et større ansvar på gruppelederne samt avdelingsleder for å samkjøre. Opprettelse av tverrgående grupper/møtearenaer kan kompensere for dette, slik at kompetansedeling, samordning og helhet blir ivaretatt. Med tanke på innovasjon og nyskapning vil dette alternativet kunne gjøre det vanskeligere å starte på prosjekter som ikke passer inn i et av de eksisterende systemene. Slik sett må organiseringen vurderes dersom nye oppgaver skulle tilkomme i fremtiden. For å møte disse utfordringene kan man som vist i figur 6 nedenfor tenke seg at vi organiserer gruppene rundt systemene (altså FS, SO og Cristin), men uten å gi de merkelappene som "låser" folk i en gruppe. Samtidig kan vi sørge for å skape fleksibilitet ved at teamene bevisst settes sammen for å myke opp systemfokuset i gruppene. Man tar her hensyn til at det er en viss kontinuitet i teamene, samtidig som at man har fleksibiliteten til å spre kunnskapen, og på den måten redusere sårbarheten, samt kraftsamle rundt prioriterte oppgaver. I tillegg er det en mulighet for enkeltpersoner å "hoppe ut" av team for å gjøre linjeoppgaver i kortere eller lengre tidsperioder. 11

13 Figur 6: Visualisering av alternativ 3 Alternativ 4 Organisering etter kompetanse I dette alternativet tenkes en organisering i flere mindre grupper basert på kompetanse. Dette alternativet vil kunne ha mye felles med alternativ 1, men med en mer differensiert organisering med fler og mindre grupper. Eksempelvis kan man tenke seg flere grupper som "database", "sikkerhet og testing", "design", "interaksjon", "integrasjon" osv. Alternativet kan teoretisk gi klarere ansvarsområder på fag og gruppene kan få spesifikke oppgaver og myndighet knyttet til fagområdene. En kan tenke seg at dette vil kunne bidra til en struktur for helhetlig tenking innenfor hvert fagområde og på den måten sikre standardisering. Gruppene vil heller ikke fokusere på system. Ulempene ved denne løsningen kan være knyttet til hvordan inndelingen i kompetanse i praksis skal gjøres. Kompetanse er veldig vanskelig å dele inn etter fordi mange jobber på tvers. Gjør man det for generisk, som i dag, mister det litt mening og gruppene blir store. Gjør man det for spesifikt, vil vi få mange som ikke passer inn i kun en kategori. Alternativet kan kanskje fort gi noen navnekrangler om hvor man legger skillelinjene på kompetanse. Ser man bort i fra at man organiserer i team, vil ikke denne strukturen i seg selv sikre samordning av oppgaver som hører naturlig sammen, da vår utvikling er veldig «systemsentrisk». Om stabens rolle og funksjoner Prosjektgruppen mener at de stabs- og støttetjenester som i dag ivaretas av SO- stab og FSsekretariat for henholdsvis gamle FS og SO, bør samles i en felles stabsenhet i den nye organisasjonen. Hovedargumentet for dette syn baserer seg på en forståelse av at det er viktig med nærhet og lett tilgang til administrative støttetjenester. Prosjektgruppen mener videre at alle stabs- og støttefunksjoner bør tillegges en samlet stab direkte underlagt direktør og at stabsfunksjoner ikke bør spres på avdelinger eller seksjoner. Det synes å være bred enighet i prosjektgruppa om at følgende funksjoner bør legges til/ivaretas av sentral stab i FSAT: Felles HR-funksjon (sykemeldinger, permisjoner, ansettelser, bilag (reiseregninger), rådgivning lønn/personal, brukerstøtte lokalt adm.sys). Vi har ressurser i dagens org. 12

14 Økonomi (budsjettarbeid, regnskapsføring, rapportering, årsoppgjør, bestillerfunksjon Innkjøp) Lokal IT (brukerstøtte på PC/maskinpark, kopimaskiner, AV-utstyr mm.) Arkivfunksjon (Rådgivning og støtte knyttet til EPHORTE, fysisk arkiv). Arrangementsstøtte til konferanser m.m. Informasjon og kommunikasjon Utrednings- og ledelsestøtte (koordinering av høringer, styreforberedelser, mm.) Sentralbordfunksjon knyttet til fellesnummer for den nye organisasjonen Juridisk bistand inkl. sekretariat for felles klagenemnd (studentsaker) Hva dette krever av stabens dimensjonering og av revisjon av eksisterende avtaler med UiO, må sees nærmere på. På spørsmål om all avtaleforvaltning bør samles i stab mener prosjektgruppen at dette ikke vil være riktig. Juridisk støtte til forvaltning av avtaler bør ligge i stab, men ansvaret for avtalen og forvaltningen av denne må ligge hos den avdelingsleder som faktisk eier avtalen. I tillegg ser prosjektgruppen for seg at man etablerer to sentrale roller i FSAT som skal ivareta systemansvar og tjenesteansvar for hele organisasjonen. I modell 1 og 2 anbefales det at disse rollene bør fylles av eller sortere direkte under avdelingslederne i henholdsvis utviklingsavdelingen og (system)forvaltningsavdelingen og ikke i en sentral stab. I modell 3 derimot vil det være naturlig at disse rollene ligger direkte under FSAT sin direktør. Rollene er forsøkt beskrevet nærmere i det etterfølgende. Overordnet utviklingsansvarlig må blant annet: Ansvar på et overordnet nivå Ansvar for koordinering av utvikling pr. system Hvert system skal ha en utviklingsleder Sørge for at systemer utvikles i tråd med pålagte og avtalte arkitekturprinsipper Delta i arkitekturarbeid for alle systemer Sørge for at FSAT benytter avtalt systemutviklingsmetodikk Vurdering av utviklingsverktøy etter felles prinsipper, evt. vurdere unntak fra prinsippene Teknologivalg Sørge for at FSAT utvikler systemer som kan integreres mot andre systemer på en felles måte, som er i tråd med nasjonale retningslinjer. Systemansvarlig må blant annet: Koordinere forslag til og pålegg om endringer og forbedringer Ta ansvar for å spille inn forslag til prioriteringer til styret (koordinert på FSAT-nivå) Ta ansvar for detaljering av vedtatte prioriteringer (på systemnivå) Ta ansvar for å ivareta produkteierrollen 13

15 Plassering av brukerstøtte/produkteierskap Dagens gruppe for FS-støtte har oppgaver både knyttet til forvaltning og utvikling. Deres oppgaver er brukerstøtte og kurs overfor FS-brukere ved institusjonene, koordinere og lede ekspertgrupper, lede utviklingsprosjekter, legge til rette for utviklerne både i forhold til nyutvikling og til feilretting og vedlikehold av eksisterende systemer. Gruppen har frem til nå ligget i SUN og altså vært en del utviklingen. Det har fungert svært godt. Mot dette kan det anføres at dersom brukerstøtte (og dermed systemspesifisering og produkteierrollen) havner i utviklingsavdelingen kan det føre til en sammenblanding av roller ved at bestiller og leverandør er den samme.. Tilsvarende for opptak er det en uheldig å splitte «opptaksproduksjonen» og produkteierskap for SO. SO er i mange tilfeller eneste bruker av SOsystemene, og det er en stor fordel at det er brukerne som spesifiserer endringsbehov. Brukerstøtte/rollen som produkteier kan både legges til utviklingsavdelingen og til forvaltningsavdelingen, for å få frem begge alternativer har vi i modell 1 lagt det til utviklingsavdelingen og i modell 2 til systemforvaltningsavdelingen. Et tredje alternativ kan være å dele brukerstøtte i to, slik at kurs og brukerstøtte ligger i utviklingsavdelingen, mens systemspesifiseringen ligger i forvaltningsavdelingen. Kontakt mot drift Flere har pekt på at det er et behov for å tydeliggjøre en rolle i vår organisasjon som har med kontakten mot drift å gjøre. Denne funksjonen/oppgaven bør også plasseres et sted i de ulike modellene. Det formelle ansvaret må ligge i systemforvaltning men mye av den operative kontakten må utviklingsavdelingen ta seg av. Forvaltningen vil ha følgende roller mot drift: det daglige ansvaret for avtalen(e) med driftsorganisasjonen(e) kontakt mot driftsorganisasjonen ved brudd i driften eller utilstrekkelig kapasitet kontaktpunkt for driftsorganisasjonen ved melding om nedetid leverandør av nye applikasjoner/nye versjoner for driftssetting Under selve utviklingsarbeidet og i leveringsfasen, og i særlig grad når det gjelder nye systemer eller ny teknologi, vil det være utviklerne som best har direkte kontakt med drift for å sikre at valgt system og teknologi kan testes og driftes når systemet er ferdig utviklet og å være med å løse problemer som eventuelt oppstår i oppstartfasen. Dersom continious delivery etableres for et system vil det være veldig liten kontakt mellom systemforvaltning og drift for det som gjelder utvikling. Da er det ikke lenger drift som lanserer men systemforvaltningen selv, ved at de gis funksjonalitet i systemene som kan lansere en ny versjon og eventuell rulle tilbake. Til å begynne med så bør det enkelte system ha en egen person som jobber tett mot drift. Dette er kun basert på en praktisk tilnærming og ved at man trolig trenger å høste erfaring med dette. Oppsummert er det i hovedsak to typer kontakt mot drift som er ønskelig: a. På den ene siden kontakt som gjelder systemer som er i drift og avtalefestede rutiner og forpliktelser knyttet til disse. b. På den annen side kontakt i utviklingsfasen for å sikre at utviklet system/teknologi kan driftes når det blir levert. Ideelt sett bør oppgavene under a) ligge til forvaltningssiden og til hvert enkelt system, mens b) bør ligge til utviklingssiden, helst med ett felles kontaktpunkt mot drift for alle systemer. 14

16 4.2 Modell 2 - Organisering etter kjerneoppgavene utvikling, forvaltning og saksbehandling Modell 2 skiller seg fra modell 1 ved at man vurderer saksbehandling som en egen hovedoppgave som skilles ut organisatorisk på nivå 1. I tillegg er det enkelte funksjoner i modell 2 som er overført fra avdeling for utvikling til avdeling for systemforvaltning. Modellen er synliggjort i figur 5 nedenfor Beskrivelse og vurdering av modell 2 Grunnideen er å organisere FSAT i tre avdelinger; Forvaltning, utvikling og kompetansevurdering som igjen er inndelt i to eller flere seksjoner/grupper. Figur 5 Modell 2 Organisering etter kjerneoppgavene utvikling, systemforvaltning og saksbehandling Beskrivelse og vurdering av modell 2: Ledergruppen vil bestå av direktør, leder stabsenhet, og avdelingsledere for utvikling, systemforvaltning og kompetansevurdering (5) Modellen har 3 formelle ledernivåer; direktør, avdeling og grupper 15

17 Rendyrker hovedfunksjoner i tre avdelinger; Utvikling, forvaltning og saksbehandling Avdeling for utvikling består av dagens ansatte i gruppe for webapplikasjoner, gruppe for integrasjon, gruppe for opptakssystemer samt de som jobber med database i DVgruppen Avdeling for utvikling har ansvar for datamodellering, utvikling, vedlikehold, systemdokumentasjon, driftsdokumentasjon, ivareta daglig kontakt og kommunikasjon med driftsleverandør samt tjenesteleveranser CRIStin og ITAR Utviklerne kan i prinsipp organiseres på flere måter slik vi har skissert i modell 1, men vi har i figuren valgt å synliggjøre en inndeling etter alternativ 3 Avdeling for systemforvaltning vil bestå av FS-støtte, SO-SI (med unntak av informasjon og lokal-it, som ligger i stab), deler av funksjonene fra dagens FS sekretariatet, og Datavarehus (med unntak av database) Avdeling for systemforvaltning har ansvar for alle oppgaver som har å gjøre med systemspesifisering, brukerstøtte og faktisk behandling av data i systemene. Dette vil omfatte opptaksarbeid, forvaltning av FS, NVB, GAUS og RUST, samt avtaleforvaltning på en rekke områder. I tillegg vil Datavarehus kunne ivaretas i avdelingen. En naturlig organisering av avdelingen vil være å etablere to eller tre grupper/seksjoner på nivå tre i organisasjonen. I figur 5 ovenfor har vi synligjort en tredeling av avdelingen, men man kan også tenke seg en modell der avdelingen inndeles i to grupper: en for opptak/nvb og en for FS, GAUS, RUST og DV. Avdeling for kompetansevurdering består av dagens ansatte i avdeling for kompetansevurdering. Avdeling for kompetansevurdering har ansvar for saksbehandling av spesielle søkergrupper i NOM, vurdering av søknader om generell studiekompetanse fra søkere med utenlandsk utdanning, Informasjon om vurdering av utenlandsk utdanning fra vgs. på nett og i vurderingshåndboka, utarbeide omregningstabeller, svare på henvendelser fra søkere, rådgivere m.fl., bistand til KD i faglige spørsmål, samle rutiner og retningslinjer for saksbehandling av søkere i NOM (boka vår), delta i erfaringsutveksling og samarbeid om vurdering av utenlandsk utdanning i Norge og Norden, ivareta lederog sekretæroppgaver for SOs utvalg, sekretariat for nasjonal klagenemnd Stabsfunksjonen er som i modell 1 Om DV/DB Datavarehus ble etablert i SUAF i Fra 2000 til 2010 hørte datavarehus under gruppen FUS. Dette var en gruppe på ca. 20 personer der 5-6 personer var datavarehustviklere. En erfaring med å høre inn under en dominerende gruppe er at andre systemer får lite fokus. Fra 2008 fungerte i praksis datavarehus som en egen gruppe med seks utviklere. I 2011 fikk DV etablert en ordning der det formelt ble opprettet en utviklingsgruppe for datavarehus. Gruppen har uavhengig av formalia alltid markedsført seg selv som datavarehusgruppen. Idéen har vært å bygge en merkevare som er kjent for sektoren og som vet hva vi kan tilby av verktøy og tjenester. Datavarehus har i dag flere oppdragsgivere, man har oppdrag for økonomidirektørene ved UiB og UiO, CRIStin (forskning) og FS (studie). I modell 2 er Database og DV delt på to avdelinger. Datavarehus er lagt til avdeling for systemforvaltning fordi alle tjenester hvor man faktisk behandler data, enten på egne vegne eller på vegne av andre, er lagt til avd. for systemforvaltning, mens Database er lagt til utviklingsavdelingen som rendyrker systemutvikling (verktøyutvikling). 16

18 En oppsplitting av DV der dagens funksjoner fordeles på ulike organisatoriske enheter oppfattes som uheldig. Også et modellforslag der DV inngår sammen med et dominerende system kan være uheldig. I alle de foreliggende modellene er disse bekymringer hensyntatt. 4.3 Modell 3 Organisering etter systemer Modell 3 legger til grunn en organisering basert på dagens systemer som vi skal forvalte, utvikle, vedlikeholde og drifte. Som vist i figur 6 nedenfor baserer modellen seg på en inndeling etter FS, opptak, nasjonale fellesregistre, samt en avdeling for salg av tjenester Beskrivelse og vurdering av modell 3 Modellen har 3 formelle ledernivåer; direktør (nivå 1), avdeling (nivå 2) og grupper (nivå 3) Ledergruppen vil bestå av direktør, leder stabsenhet, og avdelingsledere for FS, opptak, nasjonale fellesregistre og tjenestesalg (6 stk.). Modellen har en stabsfunksjon med innhold tilsvarende modell 1 og 2 Avdeling for Fellessystem vil ivareta alle oppgaver som har med FS å gjøre, inkl. informasjonsansvar for fellesstudentsystem.no. Avdelingen vil bestå av tre grupper: o o o gruppe for systemforvaltning (dagens sekretariat (bortsett fra avtaleforvaltning som legges til stab) og dagens FS-støtte) gruppe for utvikling (dagens utviklerteam som jobber med FS, med unntak av et årsverk (UiO-finansiert) som disponeres av avdeling for salg av tjenester) gruppe for datavarehus (dagens datavarehusgruppe, minus et årsverk som disponeres av avdeling for salg av tjenester) Avdeling for opptak vil ivareta alle oppgaver knyttet til samordning av Samordning av opptaket til grunnutdanninger. Masteropptaket vil legges til denne avdelingen dersom vi får ansvar for det. Avdelingen vil bestå av tre grupper: o o o Gruppe for systemforvaltning (dagens SO-SI (bortsett fra lokal-it som ligger i stab og NVB som ligger i avdeling for nasjonale fellesregistre). Informasjonsansvar for samordnaopptak.no og tilhørende tjenester) Gruppe for saksbehandling (dagens avdeling for kompetansevurdering) Gruppe for utvikling (dagens gruppe for opptakssystemer) 17

19 Figur 6 Modell 3 Organisering etter systemer Avdeling for nasjonale fellesregistre vil ivareta forvaltning og utvikling av NVB, GAUS og RUST. Vitnemålsbanken legges til avdelingen dersom FSAT får denne Avdeling for salg av tjenester vil ivareta utvikling av CRIStin og ITAR Stab er som i de øvrige modellene, med unntak av at rollene som overordnet utviklingsansvarlig og systemansvarlig her er lagt i sentral stab, ikke i avdelingene. 18