Regulerer rammerne for datalevering til Arbejdsgivernes Uddannelsesbidrag

Arbejdsgivernes Uddannelsesbidrag (herefter AUB) administrerer forskellige refusions- og tilskudsordninger, der skal medvirke til at skaffe det fornødne antal praktikpladser i virksomhederne, så flere unge og voksne får mulighed for at gennemføre en erhvervsuddannelse eller en erhvervsgrunduddannelse.

Efter lov om Arbejdsgivernes Uddannelsesbidrag § 14, stk. 2, udbetaler staten en bonus på samlet op til

40.000 kr. til private arbejdsgivere, der ansætter elever i uddannelsessporet erhvervsgrunduddannelse (EGU), jf. § 18, stk. 1, i lov om forberedende grunduddannelse, i perioden fra den 1. august 2019 til den 30. juni 2022.

Til brug for administrationen af ovennævnte EGU-bonusordning er det nødvendigt for AUB at modtage oplysninger om elevers EGU planer og virksomhedspraktik hos private og offentlige arbejdsgivere under erhvervsgrunduddannelse fra FGU-institutionerne via en eller flere systemleverandører.

Denne instruks regulerer FGU-institutionen 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, forberedende grunduddannelse 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 lov om Arbejdsgivernes Uddannelsesbidrag. Det fremgår af lov om Arbejdsgivernes Uddannelsesbidrag § 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 FGU-institutionen og Systemleverandørens kontaktoplysninger. Bilag 2 skal udfyldes af FGU-institutionen og fremsendes til AUB.

2.1 Definitioner

SA-systemet: FGU-institutionens studieadministrative system til håndtering af oplysninger om EGU planer og virksomhedspraktik under elevers erhvervsgrunduddannelse - EGU.

Systemleverandør: FGU-institutionens leverandør af SA-systemet.

Grænseflade: Den webservice, som AUB stiller til rådighed til levering af data via SA-systemet, er navngivet ’EGUPlaner’.

3. PARTERNES DRIFTSANSVAR OG SIKRING AF SERVICENIVEAU

3.1 FGU-institutionens ansvar og forpligtelser

FGU-institutionen 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 .

FGU-institutionen er ligeledes ansvarlig for etablering, drift, vedligeholdelse og videreudvikling af SA-systemet samt tilslutningen til AUB’s webservice i samarbejde med sin systemleverandør.

FGU-institutionen forpligter sig til på AUB’s anmodning at medvirke til test i fornødent omfang.

FGU-institutionen 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 FGU-institutionen håndtere og om nødvendigt eskalere sagen.

Såfremt AUB ønsker at drøfte forhold omkring driften af dataleverancen, kan AUB kontakte FGU-institutionen. 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.

3.3 Fejl og nedbrud på dataudvekslingen

FGU-institutionen 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 FGU-institutionen eller dennes systemleverandør, jf. bilag 2.

4. SERVICENIVEAU OG SERVICEMÅL

4.1 Orienteringsansvar i tilfælde af kritisk fejl

AUB forpligter sig til snarest muligt at underrette og løbende holde FGU-institutionen 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.

FGU-institutionen 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 FGU-institutionen 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.

5. PROCESSER

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 FGU-institutionen 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 FGU-institutionen 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 FGU-institutionen 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 FGU-institutionen eller dennes systemleverandør xxx xx x xxxxx 0 beskrevne kontaktpunkter.

FGU-institutionen 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 FGU-institutionen

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 Xxxxxxxxxxxxx fra FGU-institutionen eller dennes Systemleverandør til AUB

Fejlmelding fra FGU-institutionen vil blive håndteret af FGU-institutionen 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 FGU-institutionen 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. FGU- institutionen 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 FGU-institutionen 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. FGU-institutionen 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.

FGU-institutionen 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.

FGU-institutionen 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 FGU-institutionens 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).

6. OPDATERING AF INSTRUKSEN

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. BILAG

7.1 Bilag 1: AUB’s kontaktoplysninger

Bilag 1 indeholder AUB’s kontaktoplysninger. Bilaget er fremsendt til FGU-institutionens E-boks.

7.2 Bilag 2: FGU-institutionen kontaktoplysninger

Bilag 2 udfyldes af FGU-institutionen, og indeholder FGU-institutionen og Systemleverandørens kontaktoplysninger. Bilaget er fremsendt til FGU-institutionens E-boks.

Document Metadata

Regulerer rammerne for datalevering til Arbejdsgivernes Uddannelsesbidrag

Document Metadata