Systemforvaltningsaftale for SYSTEM
Systemforvaltningsaftale for SYSTEM
Indgået mellem parterne:
Organisatoriske enheder: Den enhed, der ejer systemet, Dekanater, IT, andre
Roller: Systemejer, Aftalepart hos IT, andre
Version 0.x
Dato 26-02-2015
Dokumenthistorik:
Version |
Dato |
Ændret af |
Ændring (hvad er ændret) |
Godkendt af |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Indholdsfortegnelse
1.1 Formålet med systemforvaltningsaftalen 4
1.2 Definitioner og referencer 4
1.5 Roller i systemforvaltningssamarbejdet 5
1.7.1 Risikoanalyse fra Secureaware 6
2.1.1 Adgange for AU brugere 8
2.1.2 Adgange for leverandører 8
2.2.1 Opgraderinger af driftsplatformen 9
2.2.3 Ad Hoc Servicevinduer: 9
2.2.8 Offline tilgængelighed 11
2.5 Oprydning og arkivering 11
3.1 Organisering og ansvarsbeskrivelse 12
3.3 Kritiske successfaktorer for supportprocesserne 12
3.4 Aftaler om tilgængelighed af support 12
3.4.2 Udvidet drift og supportberedskab 12
3.6.1 Oplæring af nye brugere 13
3.6.2 Efteruddannelse af eksisterende brugere 13
4 Funktionel vedligehold og videreudvikling 14
4.1 Organisering og beslutningskompetence 14
4.2 Kontinuerlige forbedringer 14
4.3.2 Prioritering af ændringer 14
4.3.3 Frekevens af opdateringer 14
4.4.1 Rapporteringer/lister 15
5.3 Planlægning af systemanvendelse 16
7 Bilag – Samlet overblik over aftalte SLA 17
1Aftalerammer
1.1Formålet med systemforvaltningsaftalen
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
|
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
|
SLA |
Service Level Agreement
|
Informationssikkerhedshåndbogen |
Informationssikkerhedshåndbogen for Aarhus Universitet udstikker spillereglerne for informationssikkerheden 4 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
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) |
|
|
|
|
|
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
