Regulerer rammerne for datalevering til Arbejdsgivernes Uddannelsesbidrag
Instruks om datasamarbejde med Arbejdsgivernes Uddannelsesbidrag
Regulerer rammerne for datalevering til Arbejdsgivernes Uddannelsesbidrag
mellem
Erhvervsskolerne
og
Arbejdsgivernes Uddannelsesbidrag
Arbejdsmarkedets Tillægspension Kongens Vænge 8
0000 Xxxxxxxx
CVR: 43 40 58 10
Instruks 2018.09.01 Gældende fra september 2018
Indhold
2. Instruksens indhold og omfang 2
3. Parternes driftsansvar og sikring af serviceniveau 3
3.1 Erhvervsskolens ansvar og forpligtelser 3
3.2 AUB's ansvar og forpligtelser 3
3.3 Fejl og nedbrud på dataudvekslingen 3
4. Serviceniveau og servicemål 4
4.1 Orienteringsansvar i tilfælde af kritisk fejl 4
4.2 Reaktionstid og kommunikationstid 4
7.1 Bilag 1: AUB’s kontaktoplysninger 9
7.2 Bilag 2: Erhvervsskolens kontaktoplysninger 9
Version | Dato | Ansvarlig | Beskrivelse af ændring |
1.0 | 09-06-2017 | BBN | Dokument oprettet |
1.1 | 28-06-2018 | MVS | Ændringer angående bilag, det daglige samarbejde og driftsstatus |
1.2 | 04-09-2018 | MVS | Diverse præciseringer |
I forbindelse med Arbejdsgivernes Uddannelsesbidrags (herefter AUB) administration af bl.a. refusions- og tilskudsordninger, der skal medvirke til at skaffe det fornødne antal lærepladser for uddannelsessøgende, modtager AUB oplysninger om skoleophold samt kost- og logiophold fra erhvervsskolerne via en eller flere systemleverandører.
Skolerne er forpligtet til at indberette til AUB, jf. ’Bekendtgørelse om udbetaling af lønrefusion m.v. fra Arbejdsgivernes Uddannelsesbidrag § 9’, ’Bekendtgørelse om udbetaling af refusion for arbejdsgiveres udgifter ved elevers ophold på kostafdelinger fra Arbejdsgivernes Uddannelsesbidrag § 7’ og ’Bekendtgørelse om udbetaling af tilskud til befordringsudgifter fra Arbejdsgivernes Uddannelsesbidrag § 8’.
For erhvervsskoler, der sender oplysninger om skoleophold samt kost- og logiophold til AUB via et andet studieadministrativt system end Styrelsen for It og Lærings EASY-A, regulerer denne instruks Erhvervsskolens og AUB’s (herefter Parterne) samarbejde og deres respektive rettigheder og forpligtelser i forbindelse med AUB's modtagelse og anvendelse af data gennem grænsefladen, således som den til enhver tid er beskrevet på AUB’s hjemmeside (xxx.xxxx.xx/xxx-xxxxxxxxxxx), samt de bestemmelser, der fremgår af ”Bekendtgørelse om krav til studieadministrative it-systemer for almene voksenuddannelser, erhvervsuddannelser, gymnasiale uddannelser m.fl.” (herefter Systemrevisionsbekendtgørelsen).
Herudover reguleres dataudvekslingen af den persondataretlige regulering, der i medfør af forvaltningslovens
§ 31 forpligter offentlige myndigheder til at bistå hinanden uden beregning. Pligten til at videregive data er derudover særreguleret i AUB-loven. Det fremgår af AUB-lovens § 26, at offentlige myndigheder, skoler m.fl. skal give AUB oplysninger, der har betydning for, at AUB kan træffe afgørelse om udbetaling af ydelser. Videre fremgår det af § 28, at der kan straffes med bøde, hvis en part ikke indgiver oplysninger, eller indgiver urigtige eller vildledende oplysninger til AUB.
Instruksen beskriver, hvordan driftsansvaret er placeret (afsnit 3), hvilket serviceniveau, som skal leveres (afsnit 4), processer for fejlhåndtering og ændringsønsker (afsnit 5) samt processen for opdatering af denne instruks (afsnit 6).
Bilag 1 indeholder AUB’s kontaktoplysninger. Bilag 2 indeholder Erhvervsskolens og Systemleverandørens kontaktoplysninger. Bilag 2 skal udfyldes af Erhvervsskolen og fremsendes til AUB.
2.1 Definitioner
SA systemet: Erhvervsskolens studieadministrative system til håndtering af oplysninger om skoleophold samt kost- og logiophold.
Systemleverandør: Erhvervsskolens leverandør af SA systemet.
Grænseflader: De webservices, som AUB stiller til rådighed til levering af data via SA systemet. De omfatter de to services ’Indberetning af oplysninger om skoleophold’ og ’Indberetning af oplysninger om kost- og logiophold’.
PARTERNES DRIFTSANSVAR OG SIKRING AF SERVICENIVEAU
3.1 Erhvervsskolens ansvar og forpligtelser
Erhvervsskolen er ansvarlig for, at SA-systemet leverer de relevante data til AUB samt at gældende krav og lovgivning overholdes, jf. Systemrevisionsbekendtgørelsen og grænsefladebeskrivelsen på xxx.xxxx.xx/xxx- leverandoer.
Erhvervsskolen er ligeledes ansvarlig for etablering, drift, vedligeholdelse og videreudvikling af SA-systemet samt tilslutningen til AUB’s webservice i samarbejde med sin Systemleverandør.
Erhvervsskolen forpligter sig til på AUB’s anmodning at medvirke til test i fornødent omfang.
Erhvervsskolen forpligter sig til, evt. via sin Systemleverandør, at underrette AUB ved nedbrud, tekniske problemer og ændringer af SA-systemet, som påvirker AUB’s modtagelse af data via grænsefladen. Kontaktpersoner og information om åbningstider er beskrevet i bilag 1.
I tilfælde af manglende overholdelse af servicemål, eller hvor der er risiko for, at servicemål ikke bliver overholdt, skal Erhvervsskolen håndtere og om nødvendigt eskalere sagen.
Såfremt AUB ønsker at drøfte forhold omkring driften af dataleverancen, kan AUB kontakte Erhvervsskolen. Strukturen for denne type henvendelser og evt. videre eskalation er beskrevet i bilag 1 og 2.
3.2 AUB's ansvar og forpligtelser
AUB er ansvarlig for at sikre, at grænsefladen er konfigureret og eventuelt tilrettet i nødvendigt omfang, så den understøtter gældende lovgivning.
AUB er ansvarlig for at kravstille de grænseflader og det format, data skal modtages i. I forbindelse med ændringer (f.eks. lovændringer) er det ligeledes AUB, der skal specificere datakravene.
Det er AUB’s ansvar at teste, at indkomne data anvendes korrekt i AUB ordningen.
3.3 Fejl og nedbrud på dataudvekslingen
Erhvervsskolen sikrer, at deres Systemleverandør har en supportfunktion vedrørende SA systemet, som kan supportere og understøtte driften i AUB i relation til SA-systemet.
AUB’s kontaktperson har i forbindelse med driftsproblemer og fejlmeldinger mulighed for direkte af rette henvendelse til Erhvervsskolen eller dennes Systemleverandør, jf. bilag 2.
4.1 Orienteringsansvar i tilfælde af kritisk fejl
AUB forpligter sig til snarest muligt at underrette og løbende holde Erhvervsskolen eller dennes Systemleverandør opdateret i tilfælde af en kritisk fejl (prioritet 1) hos ATP, som påvirker én eller flere af de aftalte grænseflader.
Erhvervsskolen forpligter sig til, evt. via sin Systemleverandør, snarest muligt at underrette og løbende holde AUB opdateret i tilfælde af en kritisk fejl (prioritet 1) på dataleverancens services, som påvirker én eller flere af de aftalte grænseflader, jf. Systemrevisionsbekendtgørelsen.
4.2 Reaktionstid og kommunikationstid
Driften, vedligeholdelsen, den tekniske support af SA systemet samt SA systemets integration til grænsefladen varetages af Erhvervsskolen eller dennes Systemleverandør.
Følgende servicemål skal overholdes:
Aftalt driftstid: Alle dage 24-7 ekskl. servicevinduer Aftalt oppetid i driftstiden: 98,5 %
Aftalte reaktions-og kommunikationstider:
Fejlkategori* | Reaktionstid | Kommunikationstid |
1 | 15 min. til påbegyndt | 15 min og herefter hver time |
2 | 1 time | 1 time og herefter efter aftale |
3 | 4 timer | Efter aftale |
4 | 16 timer | Efter aftale |
* Fejlkategori: Se afsnit 5.2.4 for definitioner.
Reaktionstid forstås som det tidsrum, der forløber fra, at en af Parterne konstaterer et incident eller burde have konstateret et incident frem til det tidspunkt, hvor fejlhåndtering og -løsning påbegyndes. For incidents med prioritet 1, jf. punkt 5.2.4, er tidsrummet døgnet rundt alle dage (via mail, hvis uden for Parternes aftalte telefontid), for andre incidents er tidsrummet åbningstiden for Parternes respektive telefontid, jf. bilag 1 og 2.
Kommunikationstid forstås som det tidsrum, der forløber fra, at en af Parterne konstaterer et incident eller burde have konstateret et incident frem til det tidspunkt, hvor der skal gives første tilbagemelding og efterfølgende tilbagemeldinger om sagens status til modparten. For incidents med prioritet 1 er tidsrummet døgnet rundt alle dage (via mail, hvis uden for Parternes aftalte telefontid), for andre incidents er tidsrummet åbningstiden for Parternes respektive telefontid, jf. bilag 1 og 2.
I det følgende beskrives de processer, der anvendes i det daglige samarbejde vedrørende fejl og ændringsønsker.
5.1 Det daglige samarbejde
Det daglige samarbejde varetages gennem Parternes aftalte kontaktpunkter. Henvendelse til AUB sker gennem AUB’s Kundeservice, jf. kontaktoplysninger i bilag 1. Henvendelser til Erhvervsskolen eller dennes Systemleverandør sker gennem de aftalte kontaktpunkter, jf. bilag 2. Parterne er ansvarlige for at vedligeholde kontaktoplysningerne og holde hinanden informeret om ændringer.
Parterne skal løbende og fyldestgørende informere hinanden om ethvert forhold, som skønnes at have betydning for gennemførelsen af et tilfredsstillende samarbejde.
Parterne kontakter endvidere løbende hinanden ved behov for allokering af ressourcer til løsning af Incidents og Problems samt udveksling af information om ændringer:
• Incident Management - håndtering af incidents (IT-fejl).
• Problem Management - løsning af problemer som reaktion på en eller flere incidents.
• Change Management - udveksling af information om planlagte servicevinduer og ændringer.
5.2 Incident Management
Incident dækker over en begivenhed, der resulterer i eller kan resultere i afbrydelsen af en service eller en reduktion af servicekvalitet.
Når dataleverancen er utilgængelig eller behæftet med alvorlige fejl set i forhold til AUB’s anvendelse, meddeles dette straks AUB via de kontaktpunkter, xxx xx xxxxxxxxx x xxxxx 0.
Fejlretning håndteres af Erhvervsskolen eller dennes Systemleverandør, som om nødvendigt igangsætter en procedure for hasteændringer/emergencies.
Forhold, som medfører, at dataleverancen blokerer systemet, at data ikke kan leveres, eller at data er fejlbehæftet i større omfang, tildeles 1. prioritet af Erhvervsskolens eller dennes Systemleverandør og betragtes (sammen med nedbrud af hele grænsefladen) som kritiske fejl i Parternes driftssamarbejde.
5.2.1 Fejlhåndtering mellem parterne
XXX’x aftalte kontaktpersoner har i forbindelse med driftsproblemer og fejlmeldinger mulighed for direkte at rette henvendelse til Erhvervsskolen eller dennes Systemleverandør xxx xx x xxxxx 0 beskrevne kontaktpunkter.
Erhvervsskolens eller dennes Systemleverandør skal tilsvarende rette henvendelse til AUB i forbindelse med driftsproblemer og fejlmeldinger.
Henvendelser skal som minimum indeholde nedenstående data.
Alle henvendelser registreres med følgende data:
• BrugerID (navn, afdeling, lokalitet, telefonnummer)
• Sagstype (incident, ændringsønske)
• ATP område el. system (f.eks. webservice til AUB)
• Beskrivelse (forretningskonsekvens)
• Prioritet
Alle henvendelser tidsstemples med følgende:
• Sag åbnet (dato og tid)
• Sag løst (dato og tid)
• Sag lukket (dato og tid)
Alle henvendelser har en historik log, som beskriver al aktivitet i forhold til, hvem og hvornår sagen har været læst/opdateret.
5.2.2 Fejlmeldinger fra ATP Servicedesk til Erhvervsskolen
Aktuel driftsstatus, herunder prioritet 1 fejl hos ATP, fremgår af AUB’s gruppe på Xxxxxxxxxxx.xx (indenfor normal arbejdstid). Se prioritetsmatrix, afsnit 5.2.4 for nærmere beskrivelse af prioritet 1.
5.2.3 Fejlmeldinger fra Erhvervsskolens eller dennes Systemleverandør til AUB
Fejlmelding fra Erhvervsskolen vil blive håndteret af Erhvervsskolen eller dennes Systemleverandør ved, at der sendes en mail til AUB, der efterfølgende opretter en sag til ATPs interne IT-afdeling. I tilfælde af kritisk fejl (prioritet 1) vil Erhvervsskolen eller dennes Systemleverandør samtidig kontakte AUB telefonisk. Hvis kritiske fejl opstår uden for Parternes aftalte telefontid, skal henvendelsen ske via mail. AUB vil, via ATP Servicedesk, udpege en koordinator (Situation Manager) til at styre fejlhåndtering og kommunikation. Erhvervsskolen eller dennes Systemleverandør udpeger tilsvarende en kontaktperson, som skal håndtere den løbende koordinering.
5.2.4 Prioritering af Incidents
Kategoriseringen af et Incident afhænger særligt af Impact og Urgency.
5.2.5 Prioritetsmatrix ved Incidents
Prioritet | Definition | Eksempler |
1 Kritisk (major incident) | Ved kritiske Incidents forstås Incidents, der uanset årsag hindrer anvendelse af hele eller væsentlige dele af SA systemet eller grænsefladen. ATP opfatter kategori 1 som major Incident, og en særlig funktion i ATP aktiveres til at håndtere major Incidents, i daglig tale kaldet ”Situation Management”. | • Fejl med stor forretningskritisk konsekvens (f.eks. forsinkelse i udbetaling til virksomheder eller kritisk fejl i batchafvikling). • Nedbrud på netværksforbindelser / system hos leverandør, ATP eller tredjepart, som varer længere end 24 timer. • Fejl, som skaber risiko for forsinkede udbetalinger til et betydeligt antal virksomheder. • Fejl, som skaber risiko for negativ offentlige mediers interesse af ATP |
2 Alvorlig | Ved alvorlige Incidents forstås Incidents, som er til stor gene for mange medarbejdere og/eller for mange virksomheder, som er afhængige af, at data fra SA systemet leveres via grænsefladen. Alvorlige Incidents er Incidents, der uanset årsag hindrer anvendelse af dele af SA systemet eller grænsefladen | • Udbetalingsfejl / forsinkelse som berører mange virksomheder. • Kritisk fejl i batchafvikling • Nedbrud på netværksforbindelser / system hos leverandør, ATP eller tredjepart, mindre end 24 timer. |
3 Normal | En Incident, som er til gene for medarbejdere / kunderådgivere eller virksomheder, men som evt. kan omgås via workaround, indtil fejlen er rettet, og / eller som ikke i væsentlig grad forsinker arbejdets udførelse. | • En eller meget få virksomheder er berørt af den pågældende fejl uden større forretningsmæssig / økonomisk konsekvens. • Fejl, som kun påvirker intern sagsbehandling for en eller få medarbejdere/kunderådgivere. |
4 Minor | En Incident, som har minimal betydning, men som skal løses. Fejlens løsningstid aftales ml. ATP og Erhvervsskolen eller dennes Systemleverandør. | • Fejl som ikke direkte påvirker sagsbehandling eller forretningsfunktionalitet for medarbejdere / kunderådgivere / virksomheder. |
(Ovenstående er ATP’s generelle kategoriseringer på tværs af forskellige forretningsområder og eksemplerne er vejledende)
5.3 Problem Management
Problem Management skal medvirke til at minimere og forebygge de driftsmæssige konsekvenser af Incidents. Erhvervsskolen og dennes Systemleverandør skal afsætte ressourcer til at sikre løsning af problemer som reaktion på en eller flere Incidents.
Formålet med Problem Management processen er at minimere generne for Kunderne ved proaktivt at identificere og analysere årsagen til fejl og ved at håndtere problemer og kendte fejl, indtil disse lukkes.
For Problems, som påvirker dataudveskling med AUB, er der følgende opgaver:
• Et Incident genererer et Problem, når én eller flere af følgende betingelser er opfyldt:
o Ved et Major Incident, hvor der er foretaget work around.
o Root cause til et Incident ikke er fundet.
o Der er genereret mange identiske Incidents.
Erhvervsskolens eller dennes Systemleverandør skal udarbejde en Root Cause analyse for Problem Management-sager, der vedrører AUB’s anvendelse af data modtaget gennem grænsefladen, såfremt sagens karakter berettiger det.
Root Cause analyse skal være tilsendt ATP Servicedesk senest ti (10) Arbejdsdage efter, Problem Management-sag er oprettet eller efter aftale, dog senest inden tyve (20) Arbejdsdage.
5.4 Change Management
Planlagte systemopdateringer eller ændringer i SA systemet, som vurderes at kunne have betydning for AUB, meddeles til AUB (jf. bilag 1) i så god tid som muligt og minimum 60 dage inden implementeringen.
Ændringer i krav stillet af AUB til Systemleverandøren vil ligeledes skulle varsles i så god tid som muligt og minimum 60 dage inden, implementeringen skal være gennemført.
Erhvervsskolen må ikke gennemføre changes, der påvirker AUB’s anvendelse af data modtaget gennem grænsefladen, uden en forudgående dialog med AUB.
Alle ændringer, der påvirker AUB’s anvendelse af data modtaget gennem grænsefladen, som gennemføres af Erhvervsskolens Systemleverandør, er omfattet af Change Management.
5.4.1 Krav til Change (RFC) information
Varsling af changes fremsendes til AUB, med et minimum sæt af informationer, som fx servicevinduets udstrækning, urgency, impact, risiko, brugerpåvirkning mv.
5.4.2 Fryseperioder (Frozen Zone)
ATP har to fryseperioder årligt (også omtalt som Frozen Zone). I fryseperioder kan der under normale omstændigheder ikke gennemføres changes på ATP’s produktionsmiljøer. De aftalte fryseperioder er:
Fryseperiode | Periode |
Xxxxxxxxxxx | Xxxxxx søndag i juni til og med første fredag i xxxxxx |
Xxxxxxxxx | Efter 3. weekend i december til og med 2. weekend i januar |
Undtagelser:
Alle changes, der ønskes behandlet i en fryseperiode, vil blive behandlet som:
1. Changes med prioritet 1 eller 2, der haster (emergency). Der skal ligge et kritisk Incident til grund for changen (et Incident med prioritet 1 eller 2).
2. Forhåndsgodkendte changes (standard changes).
AUB kan efter behov tage instruksen op til revision med henblik på at forbedre instruksen til Parternes tilfredshed. Den til enhver tid gældende version af instruksen findes på xxx.xxxx.xx/xxx-xxxxxxxxxxxxxxxxx
7.1 Bilag 1: AUB’s kontaktoplysninger
Bilag 1 indeholder AUB’s kontaktoplysninger. Bilaget er fremsendt til Erhvervsskolens E-boks.
7.2 Bilag 2: Erhvervsskolens kontaktoplysninger
Bilag 2 udfyldes af erhvervsskolen, og indeholder Erhvervsskolens og Systemleverandørens kontaktoplysninger. Bilaget er fremsendt til Erhvervsskolens E-boks.