Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Anvendes ved ændringer, der har betydning for eksterne.

Interne links (indhold i links ikke relevant for eksterne)

DS-38 - Getting issue details... STATUS

OBS DETTE SKAL TILPASSES MED DE KORREKTE NUMRE NÅR EPICS OPRETTES I JIRA

Indholdsfortegnelse

Afgrænsning af epic

Oversigt over berørte webservices 

Automatisk oversigt

Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.

Beskrivelse af epic

Baggrund

Automatch i Jobnet Classic er blevet vendt med forretningen på flere møder.

Formålet har været at vurdere, om det eksisterende regelsæt for automatch kunne forenkles eller endda optimeres.

Afsæt har været følgende powerpoint:

Det har blandt andet været vurderet om regel 2, dvs. "fritekstsøgning mod Ankiro på selve stillingsbetegnelsen for borgers tilvalgte EscoStar koder", skulle fjernes som led i en forenkling. Denne søgning aktiverer semantisk søgning og kan resultere i et bredere resultat, hvilket var hensigten da den blev introduceret. På den anden side er det bredere resultat blevet udfordret: Giver det rent faktisk værdi for borger? Er det denne regel, der giver anledning til, at nogle borgere føler sig matchet forkert? Eller er den oplevelse hos disse borgere resultatet af angivelse af snævre "Jeg søger job som"-angivelser, der helt naturligt giver færre match og derfor hurtigere resulterer i et match på hotjob eller hotjoblignende stillingsbetegnelser? I sidste ende er det formentlig individuelt da det afhænger af antallet af stillingstyper, som borger søger. Men bliver en højtuddannet, der søger en snæver specialstilling med få opslag matchet på jobopslag, der ikke kræver særlige forudsætninger, vil det givet blive opfattet som et dårligt match.

Det er også blevet vurderet, om man skulle udvide matchet, så der som det første blev matchet på stillingsopslag opslået på aliasser, i det det nu er muligt for arbejdsgiver at opslå en stilling under et alias. Og fordi borger reelt kan have valgt EscoStar koden via et alias, fx at "Kok" er valgt indirekte, ved klik på "kok (fiskekok)". Dette vil dog kræve, at JSJS får lagret aliasset også og ikke bare selve EscoStar koden, som aliasset hører under. Et tiltage der blev for dyrt i situationen, men noget der klart kan anbefales for et bedre match på sigt, da borgere, som har valgt kKok" via "Kok (fiskekok)", som ikke nødvendigvis matches på stillinger opslået på aliasset, kan tænkes at opleve et dårligt match.

Andre muligheder var tillige i spil, fx. at matche på borgers angivne ansættelsesbetingelser. Hvorfor returnere fuldtidsjob til en der søger på deltid osv? Men det vil kræve, at alle ansættelsesbetingelser var at finde i Ankiro, som søges i mod, på automatch profilerne. 

De helt oplagte, men langt dyrere tiltag som AI mach blev bevidst ikke vendt, da det med sikkerhed var udenfor muligt scope.

I sidste ende har forretningen valgt at fortsætte med de eksisterende regler for automatch, dog tilpasset således, at borger matches på opslag inden for en radius af 50 km fra medsendt geokoordinat i det moderniserede Jobnet, hvor afstanden i Classic er 70 km. 

Regler

Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.

Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer

Ingen. 

Acc.kr.1005.18.47.1 - Implementer Jobnet Classics automatch, så matchet sker i Find Job på det moderniserede Jobnet

Hvem automatches?

For at blive kunne blive automatchet, skal borger leve op til følgende kriterier:

• Borger skal være indlogget på Jobnet.
• Have angivet "Jeg søger job som".
• Være bosiddende i Danmark og have et geokoordinat tilknyttet, udfra hvilket der kan automatches. Dvs. en kendt bopæl. Alternativt et centrum for postnummer, hvis adresse er hemmelig. 

To forskellige matchprofiler med forskellige regler

Der opretholdes to forskellige automatchprofiler. En for borgere, der lever op til ovennævnte kriterier og er fleksjobbere (Dvs. fleksjobvisiterede ledige eller fleksjob ansatte). Samt en profil for borgere der lever op til kriterier og ikke er fleksjobbere. 

• Prioriteten er for ikke fleksjobbere at vise jobopslag efter:

  1. Regel 1: Jobopslag med Matchende Escostarkoder jf. JSJS

  2. Regel 2: “Lignende jobs” gennem søgning mod Ankiro, med de af borger angivne JSJS stillingsbetegnelser, dog angivet som fritekst.

  3. Regel 3: Som sidste prioritet fyldes op job der er markeret som hotjob “lignende” job (dvs. jobopslag, der er eksplicit er hotjobmarkerede eller angivet som HotJobQualified af STAR).
     
     Et hotjob er et internt jobopslag, der eksplicit er markeret som hotjob - dvs. et job der "ikke kræver særlige forudsætninger" at bestride. Det er arbejdsgiver der markerer jobbet som Hotjob.
     Et HotJobQualified job, er et job - internt som eksternt - der er slået op under givne EscoStar koder, som vedligeholdes af STAR. Det er job, eksekempelvis tjener, som i mange situationer kan bestrides uden særlige forudsætninger (fx. tjener på en café) men som kan kræve uddannelser i andre sitautioner (tjener på michelin restaturant). 

  For fleksjobbere skal vises job efter:

  1. Regel 1: Fleksjob med matchende Escostar koder.

  2. Regel 2: "Lignende fleksjobmarkerede job", ved søgning på de stillingsbetegnelser, som borger har angivet under JSJS, hvor søgning dog foretages i fritekst og hvor job tillige er fleksjobmarkerede.

  3. Regel 3: Endelig søges på stillinger med matchende EscoStar koder, hvor det for stillingerne dog gælder, at de skal være deltidsstillinger

  
  Kun job der i ankiro har markeringen ShowInAutomatch = true indgår i automatchet. Dette er STARs måde at sikre, at givne opslag kan pilles fra - eksempelvis michelin stjerne tjener jobbet, som "job der ikke kræver særlige forudsætninger". 
  
  Det gælder i øvrigt, at et jobopslag kun må indgå een gang, uanfægtet det måtte rammes af flere af reglerne.

Ovennævnte matchprofiler er uændrede i forhold til Classic. I selve kaldet af metoderne skelnes dog, da STAR på det moderniserede Jobnet ønsker, at borger kun skal matches på opslag indenfor 50 km af medsendt geokoordinat. 

Interaktionsdesign af match i Find job

I classic var automatch integreret ind i den indloggede forside. Det fremgik af primary action hvor mange opslag der blev fundet og der var links til forklarende sider om automatch, hvor et Danmarks kort visuelt viste, hvordan matchet virkede. I det moderniserede Jobnet er valgt en anden strategi. Indlogget borger kommer ikke til en forside som indlogget, men sendes direkte i Find Job, hvor automatch skal ske som det første. 

Der er derfor behov for, i Find job - for indloggede borgere der lever op til reglerne for automatch - at give dem en mulighed for at komme tilbage til matchet uden at de skal logge på igen. Der laves derfor et særskilt link for disse borgere, som implementeres ind i Jobnet logoet (1) og over Vis flere søgemuligheder (2). Klik på link vil udføre en automatch på ny. Bemærk: Det er et levende system, så der er ingen garanti for, at det er de samme jobopslag der vises, hvis nye er kommet til, der matcher kriterierne. 

Klik på et af de to links vil i øvrigt

• nulstille evt. angivne søgekriterier herunder et angivet søgeord i fritekst
• folde et evt. udvidet søgepanel ind og vises linket "Vis flere søgemuligheder"
• samt skjule labels “antal stillinger”, “Sorter efter” og drop down boks til at ændre sortering

Derefter vises automatchet jf. regel 1-3 jf. ankiroprofilen borger og som gennemgået i afsnit: "Visning af matchet i det moderniserede design".

Bemærk i øvrigt, at knappen "Indlæs flere" alternativt label “Der er ikke flere jobannoncer”, som vises i bunden af en normal søgning, ikke vil fremgå i bunden af et automatch. Automatch viser op til 10 forslag. 

Visning af matchet i det moderniserede design

Et figma designoplæg er udarbejdet for inspiration: (JOBNET_RE_DESIGN_FINAL – Figma).

Reglerne for visning i det moderniserede Jobnet er gennemgået herunder for hver profil. I praksis adskiller de sig dog ikke fra visningen i classic.

Særlige krav til test

* Batchjobs

• bør testes både med delta og fuldt load,
• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
• bør testes i samarbejde med teams som har afhængigheder
• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres:  
• Skal der køres konvertering:  
• Skal der køres databasescripts for opdatering af tabeller i databasen:  

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder:  
• Nye snitflader:  
• Nye komponenter:  
• Nye miljøer:  
• Nye teknologier:  
• Nye aftagertyper:  
• Eller afvigelser fra principperne:  
• Eventuelle behov for reduktion af teknisk gæld skal afdækkes:  

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.

Husk GDPR stillingtagen

Ingen personfølsomme data i epics

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

•  Ja, det er tjekket, at epic ikke indeholder dette.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.  

Korrekte sikkerhedsattributter på services

PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.

Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )

A-kasse filtrering

Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.

En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.

Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.

Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin