Formålet med systemforvaltningsaftalen er at etablere et fælles grundlag for at sikre stabil drift, kontinuerlige opgraderinger og support, fastholde sammenhæng i arkitektur på alle niveauer samt imødekomme og koordinere nye funktionskrav og løbende tilretninger af funktionaliteten.

Ved således at samle aftalerne omkring forvaltningen af SYSTEM, sikres forventningsafstemning mellem parterne i forhold til roller, ansvar, processer, økonomi og serviceniveau.

Aftalen er et dynamisk dokument, der tilpasses i takt med ændringer i installationen eller i forbindelse med ændrede samarbejdsvilkår i øvrigt.

FORLED vedligeholder aftalen og er ansvarlig for at ændringer til aftalegrundlaget bliver opdateret.

SYSEJ skal godkende enhver version af aftalen inden den publiceres. Godkendelse kan foregå på mail eller ved underskrift på forsiden af det fysiske dokument.

SYSEJ er ansvarlig for at gøre aftalen tilgængelig i YYY.

SYSKOR er ansvarlig for at gøre aftalen tilgængelig for IT.

1.2Definitioner og referencer

Begreb	Beskrivelse
AD	Active Directory Microsoft produkt der bliver brugt til at opbevare informationer om netværket og ressourcer henover et domæne¹
AU	Aarhus Universitet
Frozen Zones	Frozen Zone er perioder hvor der ikke udføres planlagt systemvedligeholdelse, men alene akut fejlretning såfremt der skulle blive behov for dette.
RFC	Request For Change Formular eller skærmbillede som benyttes til at registrere detaljer om en anmodning om ændringer²
SLA	Service Level Agreement Skriftlig aftale mellem en serviceudbyder og kunden, der dokumenterer aftalte service niveauer for en service³
Informationssikkerhedshåndbogen	Informationssikkerhedshåndbogen for Aarhus Universitet udstikker spillereglerne for informationssikkerheden ⁴ Findes på AUs hjemmeside for informationssikkerhed: ▇▇▇▇://▇▇▇.▇▇.▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇/
Secure Aware	Til at understøtte arbejdet med risikovurderinger, benyttes programmet Secureaware. ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇▇▇.▇▇.▇▇

1.3Beskrivelse af system

TEKST OG TEGNING

1.3.1Integrationer

TEKST OG TEGNING

1.3.2Øvrige miljøer

TEKST OG TEGNING

1.4Organisering

Forvaltning

Beskriv den overordnede organisering af forvaltningsorganisationen. De enkelte kasser ”foldes ud” i de aftaleafsnit de indgår i.

Sæt eventuelt navne på de personer, der er i de enkelte kasser, så det bliver tydeligt hvilke nøglepersoner, der har flere roller.

Udvikling

Support

Drift

Applikation

Konfiguration

Koderettelser

Teknik

Platform

1.5Roller i systemforvaltningssamarbejdet

Detaljeret ansvars og opgavebeskrivelse lægges i bilag. Benyt standard rollebeskrivelserne som udgangspunkt for den systemspecifikke aftale om roller, ansvar og opgaver. Opsummer i skemaet herunder, så det er afspejlet hvilke roller der findes og hvem, der varetager dem.

Navn på person:	Primær rolle:	Varetager også rollen som:
	Systemejer (SYSEJ)	Procesejer Applikationsejer Datasamlingsejer Integrationsejer
	Forvaltningsleder (FORLED)	Product Owner Superbruger
	Systemkoordinator (SYSKOR)
	Systemansvarlig (SYSAN)	Applikationsansvarlig Datasamlingsansvarlig Integrationsansvarlig Driftsansvarlig
	Løsningsarkitekt (LØSAR)	Udviklingsansvarlig Scrum master Udvikler
	Leverandør (LLL)

Læg eventuelt også et systemspecifikt HUKI-skema ind som bilag.

1.6Økonomi

Budgettet ligger som udgangspunkt hos SYSEJ. Beskriv hvis det der er specielle aftaler, eksempelvis omkring licensafregning eller dele af systemet.

1.7Sikkerhed

SYSEJ, SYSANS og UDVANS er forpligtede til at overholde informationssikkerhedshåndbogen og implementere de dele af håndbogen som påhviler dem hver især.

Beskriv her, hvis der gælder særlige forhold som afviger fra informationssikkerhedshåndbogens formuleringer.

Jf. Aarhus Universitets årshjul for informationssikkerhed, er det Systemejerens ansvar, at der minimum én gang om året foretages en system- og dataklassifikation, og såfremt denne resulterer i en klassifikation som enten et Type A eller B system, at der efterfølgende udarbejdes en risikovurdering (Type A og B) og at der udarbejdes/vedligeholdes en beredskabsplan (Type A).

Ud over den faste årlige klassifikation og vurdering, skal der for Type A og B systemer foretages en ny risikovurdering ved større ændringer i systemet.

1.7.1Risikoanalyse fra Secureaware

Til at understøtte arbejdet med risikovurderinger, har Aarhus Universitet indkøbt programmet Secureaware, som skal benyttes til at foretage vurderingerne.

Secureaware indeholder alle identificerede risici for systemet, men kun de væsentligste medtages i systemforvaltningsaftalen. Det er Systemejers ansvar at vurdere hvornår en risiko skal indarbejdes i aftalen.

For at imødegå de identificerede risici, er følgende forebyggende tiltag implementeret:

Risiko	Imødegåelse	Behandlet i afsnit	Ansvarlig
Produktionsmiljøet overskrives helt eller delvist af testdata	Separate logins for udvikling, test og produktion. Tydeliggørelse af testmiljø med farver, overskrifter eller andet.		Systemansvarlig
3.part med legal adgang til systemerne videregiver fortrolig information der fører til sagsanlæg	Kontraktlig ansvarspådragelse hos 3.part i forhold til deres medarbejderes tavshedspligt.		Systemejer
Data tab som følge af korrupt database/diskfejl

1.8Aftalt dokumentation

Hvilken dokumentation er det aftalt, der skal udarbejdes for systemet? Hvis det ikke allerede findes, beskrives hvilke aftaler, der er for færdiggørelsen. Beskriv også hvor dokumentatione kan findes og hvem, der er ansvarlig for at den opdateres.

Afsnittet skal afspejle ambitionsniveauet for den operationelle dokumentation eksempelvis vejledninger, udviklingsdokumentation, driftsprocedurer m.m.

2Drift

2.1Adgange og rettigheder

Sørg for at processen for tildeling /nedlægning af adgange også beskriver hvordan man gør under ferie og fravær.

Tegn procesdiagram med svømmebaner.

Beskriv hvis der er særlige vilkår for eksterne brugere eller andre specifikke brugergrupper. Hvem kan godkende?

2.1.1Adgange for AU brugere

Beskriv hvorledes adgange tildeles og fjernes for brugere på AU. Medtag også adgange, der tildeles direkte til databaseservere.

2.1.2Adgange for leverandører

Beskriv hvilke adgange der er givet til leverandøren og hvordan de tildeles og fjernes igen.

2.1.2.1Navngivne adgange

2.1.2.2Ikke navngivne adgange

2.1.2.3Fællesadgange for leverandørens servicedesk

Leverandørens servicedesk har en fælles permanent adgang til XXX.

Det er SYSANs ansvar at LLLs medarbejdere ikke kan få adgang til andre dele af AUs netværk og systemer.

Det er SYSEJ ansvar at aftalerne med LLL beskriver LLLs ansvar i forhold til forvaltning af brugernavn og password så de overholder AU ITs informationssikkerhedshåndbog. Særligt bemærkes passwordskift i forbindelse med medarbejderfratrædelse hos LLL.

Det er også SYSEJ ansvar at det i aftalen er beskrevet hvorledes LLL må omgås data i databasen og LLLs erstatningsansvar i tilfælde af misbrug fra deres medarbejdere.

SYSEJ har ansvaret for at ansøge om og sikre dispensation hos CISU til denne fælles permanente adgang hos LLLs servicedesk.

2.1.3Sporbarhed

I XXX skal det logges og overvåges, at der ikke foregår uautoriseret brug.

SYSAN skal sikre denne logning, og fremstille rapporter til FORLED på opfordring, samt inden hvert statusmøde.

2.1.4Rettigheder

Beskriv hvorledes rettigheder tildeles og hvem, der har ansvaret. Vil typisk være en del af applikationsdriften.

Tegn procesdiagram med svømmebaner.

2.2Driftsforstyrelser

2.2.1Opgraderinger af driftsplatformen

Opgraderinger gennemføres som udgangspunkt i faste servicevinduer, alternativt på aftalte tidspunkter i forhold til systemets årshjul.

Beskriv hvad der er aftalt for systemet og tegn eventuelt et procesdiagram til at visualisere godkendelsesflowet og koordineringen.

Det er SYSAN´s ansvar at planlægge og koordinere opgraderinger af platformen og det er FORLEDs ansvar at koordinere indholdet i disse 4 servicevinduer med leverandøren, brugerne og SYSEJ.

Det er SYSEJs ansvar at aftalen med LLL giver mulighed for at applikationsopdateringer på systemet kan foregå udenfor almindelig arbejdstid.

2.2.2Frozen zones

Frozen Zone er perioder hvor der ikke udføres planlagt systemvedligeholdelse, men alene akut fejlretning såfremt der skulle blive behov for dette.

Det er aftalt at der IKKE må planlægges servicevinduer, foretages systemvedligehold, opdateres i konfigurationer eller kode:

1) Indtil 14 dage før og efter …...

2) Indtil 14 dage før og efter udsendelse af …..

3) I månederne … grundet….

4) …

Det er SYSEJs ansvar at identificere behovet for frozen zones.

2.2.3Ad Hoc Servicevinduer:

Kan rekvireres af både FORLED og SYSAN. – Beskriv proces inkl. Kommunikation

Som udgangspunkt lægges servicevinduet inden for normal arbejdstid. Det aftales særskilt om der er behov for at afvige fra dette.

2.2.4Change Management

Beskriv hvorledes kontakten til change management er fordelt på FORLED, SYSAN og SYSKOR.

Som udgangspunkt har SYSAN ansvaret for og kontakten til CM i forhold til platformsændringer på systemet.

FORLED skal sikre at CM kender systemsammenhængene, og FORLED skal udpege de systemer som FORLED skal godkende eller informeres om inden nedlukning, idet de har stor påvirkning på brugen af XXX.

SYSAN skal definere og vedligeholde listen over prægodkendte platformsændringer, der ikke behøver at følge CM-processen.

2.2.5Overvågning

Hvilke dele af systemet skal overvåges og hvad er processen for fejlmeldinger gennem overvågningen? Sendes en mail, registreres en sag i NILEX? Hvem holder øje, og hvordan reageres der på de forskellige typer af fejl?

Er der aftalt reaktionstider eller andre SLA for overvågningen?

2.2.6Problemhåndtering

Beskriv processen fra en sag identificeres, til det er blevet et defineret problem. Hvilke typer af udfordringer skal håndteres som problemer, og hvordan organiseres arbejdet med problemer?

Hvem kommunikerer hvor om problemet?

Skal der opdateres i en ”Kendte fejl” database når årsagen til problemet er fundet? Hvem gør det?

Hvornår nedsættes en ”task-force” og hvem skal udpege/godkende deltagerne?

2.2.7Beredskabsplaner

Hvilke fejlsituationer kan lægge systemet ned og hvor lang tid vil det tage at komme tilbage til normal produktion igen, hvis det sker? Se ”Input til beredskabplan” på projektmodellens hjemmeside.

Hvilke typer af problemer, skal der defineres en beredskabsplan for og hvordan ser den så ud? Hvad er kommunikationsvejene, eskalationsvejene og rapporteringskravene?

Er deltagerne prægodkendt til at dedikere sig 100% til løsning af problemet og er leverandøren klar til at gå ind i arbejdet med kort varsel?

Beskriv både it-beredskabsplanen og forretnings-beredskabsplanen. Læg dem eventuelt i bilag. Se ”Tjekliste til beskrivelse af forretningsberedskab” på projektmodellens hjemmeside.

2.2.8Offline tilgængelighed

Hvad er kravene til at kunne tilgå systemet eller dele af systemet, hvis der ikke er forbindelse? Skal der eksistere en særkilt kopi og hvor opdateret skal den være? Hvordan tilgåes den?

2.3Redundans

Hvad er aftalt omkring redundans og failover på systemet? Er der manuel failover? Automatisk? Er der dele af systemet, som ikke er redundant og hvad betyder det i tilfælde af driftsproblemer?

2.4Backup og restore

Hvilke krav er der til backup-periode og restore muligheder?

Beskriv SLA på restoretider.

Skal restore testes ved alle opgraderinger?

2.5Oprydning og arkivering

Hvor længe skal data være tilgængelige for brugerne?

Læringsrum
Kurser
Mails/beskeder
Dokumenter

Hvordan arkiveres og hvor længe? Er der juridiske forpligtelser 10 år tilbage? Skal data kunne tilgås på et bestemt medie?

Hvordan og hvornår foretages oprydning i systemet? Hvem har ansvaret og hvem skal godkende sletninger?

Skal genindlæsning af arkiverede data testes ved opgraderinger?

3Support

3.1Organisering og ansvarsbeskrivelse

Tegn og beskriv hvorledes supportorganiseringen er tænkt.

3.2Supportprocesser

Lav procesdiagram og eventuelt korte beskrivelser for de vigtigste hændelser. Eksempler kunne være:

Fejl opdaget af bruger eller overvågning
Spørgsmål til funktionalitet eller forretningsprocesser
Login problemer, Printproblemer eller andre specifikke sager.

Er processerne afspejlet NILEX-workflow?

3.3Kritiske successfaktorer for supportprocesserne

Hvornår fungerer supportprocesserne godt? Kan det måles?

3.4Aftaler om tilgængelighed af support

Er der aftalt servicemål for tilgængelig hed af support?

Telefon
Mail
Vejledninger
FAQ

Beskriv aftaler om tilgængelighed af både 1´st level, 2´nd level og 3´rd level i både IT, forretning og hos leverandøren.

3.4.1Leverandørkontakt

Hvem må kontakte leverandøren og hvordan?

Som udgangspunkt bør Systemansvarlig og Udviklingsansvarlig kunne kontakte leverandøren direkte uden forudgående godkendelse i tilfælde af kritiske driftsproblemer.

Er der specielle aftaler omkring afregning i foruddefinerede tidsrum? Hvem kan godkende?

3.4.2Udvidet drift og supportberedskab

Ved udvidet beredskab skal både driftsplatform, relevant it-infrastruktur, it-support såvel som applikationsdrift, applikationssupport og leverandøren formentlig være repræsenteret. Beskriv rammerne og deltagelse helt ned på rolle/personniveau.

3.5Information

Driftsstatus
WIKI
Kendte fejl
Knowledgebase

Hvad findes hvor, og hvem opdaterer og vedligeholder?

3.6Uddannelse

3.6.1Oplæring af nye brugere

Hvem

Hvad

Hvem gør det

Nye brugere

(Undervisere, administrative medarbejdere, studerende, eksterne, andre)

Nye superbrugere
Nye IT-supportere
Nye applikationssupportere
Nye IT-medarbejdere

Teknisk platformsforståelse
Processer
Roller/rettigheder/adgange
NILEX
Konfiguration
Hjælpeværktøjer
Vejledninger, WIKI

3.6.2Efteruddannelse af eksisterende brugere

Skal der iværksættes særlige tiltag til videreuddannelse/efteruddannelse af ekisterende brugere? Hvem har i givet fald ansvaret for at gennemføre det?

Skal der arrangeres et tilbagevendende webinar 1 gang årligt?

Skal der gøres noget for nogle brugergrupper, men ikke for alle?

4Funktionel vedligehold og videreudvikling

FORLED er Product Owner og ejer backloggen og ændringsprocesserne.

4.1Organisering og beslutningskompetence

Tag stilling til hvorledes ændringer skal styres i forhold til

Fælles
Tværgående
Lokal

Visualiser organisering og beslutningskompetence.

4.2Kontinuerlige forbedringer

Holde øje med supportsager og opdukkende problemer for at se mønstre og forbedre løsningen.

4.3Ændringsprocesser

4.3.1Ændringsønsker

Beskriv processerne frem til ændringen er registreret i backloggen. Hvem kan indmelde ændringsønsker hvorhenne, og hvem godkender/afviser at det skal laves?

Opdel eventuelt i flere processer baseret på hændelser eksempelvis:

▇▇▇▇▇▇▇▇▇, der udspringer af strategiske beslutninger
Supportsag, der ikke kan løses uden ændringer
Opdukkende udviklingsønsker => Lovgivning, Brugerhenvendelser, Supportsager, Kontinuerlige forbedringer
Mindre planlagte udviklingsønsker, Større planlagte udviklingsønsker=> hvornår er det et projekt?
Andre systemers ønsker
Applikationsopgraderinger fra leverandøren
Tabelrettelser/konfiguration

4.3.2Prioritering af ændringer

Beskriv hvorledes ændringsønskerne i backloggen prioriteres. Hvad skal der til for at en ændring haster og hvem skal godkende prioriteringerne?

4.3.3Frekevens af opdateringer

Releases – Eventuelt afspejlet i årshjulet
SCRUM
Information – Hvem informeres hvor? – Hvornår i forhold til ændringernes ikrafttrædelse?

4.3.4Test

Beskriv en samlet proces for test af ændringer.

Hvordan testes de enkelte sprint, releases, applikationsopgraderinger, platformsopgraderinger?

Testen kan eventuelt være afspejlet i årshjulet og indeholde aftaler om bemanding af hensyn til årshjulets øvrige aktiviteter.

4.4Årshjul

Gerne skema eller tegning af de tilbagevendende aktiviteter, eller som minimum 12 måneder fra næste aftaleperiode. Tegn Frozen zones ind.

4.4.1Rapporteringer/lister

Er der faste rapporter/lister, der skal trækkes på bestemte tidspunkter?

Indberetninger til myndigheder
Oversigter over medarbejdere/studerende
Andet

4.5Kommunikation

Beskriv strategien for valg af kommunikationsveje (Twitter, SMS, nyhedsmodul i TYPO3, interne systemopslagstavler, e-mail, driftsinfo….)

Lav en samlet oversigt over kommunikationssamarbejdet. Hvordan er det organiseret og hvilke opgaver ligger hos de enkelte interessenter. Hvordan er processen for at få en information ud til brugerne?

Kommunikationsorganiseringen kan være kompleks med mange aktører. Overvej:

Kommunikationspartnere – Medarbejdere og studerende for hvert hovedområde
Kommunikationspartner for VD-området
Oversættere
Rollerne i forvaltningsorganisationen

5Årlige møder

5.1Statusmøder

Formålet med statusmøderne er, at diskutere hvorledes samarbejdet kan gøres endnu bedre, og sikre at dokumentationen stadig er gyldig og relevant. Der bør afholdes mindst 1 årligt møde med leverandøren, hvor både IT og forretning deltager.

Siden sidst
Vurdering af samarbejdet, herunder leverandørsamarbejdet og udviklingssamarbejdet
Revurdering af systemklassifikation og beredskabsplan
Opdatering af aftalehåndbogen

5.2Koordineringsmøder

Faste årlige møder af hensyn til koordinering op mod ferie eller spidsbelastningsperioder

5.3Planlægning af systemanvendelse

Beskriv møder af hensyn til fastlæggelse af kommende års aftaler om ressourcer og systemforvaltning.

6Bilag

Samlet oversigt over aftalte SLA
Roller, ansvar og opgaver
HUKI skema
Link til informationssikkerhedshåndbogen

7Bilag – Samlet overblik over aftalte SLA

Heri samles SLA fra de forskellige afsnit i systemforvaltningsaftalen. Brug words funktionalitet omkring referencer, således at afsnittet kan opdateres .

1 Fra Wikipedia

2 Tolket fra ITIL

3 Oversat fra ITIL definition

^{4
Hentet fra rektors ord i informationssikkerhedshåndbogen.}

Systemforvaltningsaftale for SYSTEM 0.x 26-02-2015 Side 20 af 20

Systemforvaltningsaftale for SYSTEM

Document Metadata

Document Metadata

Table of Contents