Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

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


STAR Projektleder (PL)Forretningsanalytiker (FA)STAR ReleaseEpic statusEksterne snitflader
Camilla Hagedorn TrolleBjarne Hansen (Edora)2022-30.1N/A


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

Ingen ændringer på eksterne snitflader.

Interne links (indhold i links ikke relevant for eksterne)

key po fa ux sme eksterne snitflader interne snitflader status labels
Refresh

VIR-3905 - Getting issue details... STATUS


Indholdsfortegnelse



Afgrænsning af epic

Afgrænsning

Som en bruger af VITAS

vil jeg gerne have at ordningerne virker på samme måde i det omfang, det er muligt

for at jeg oplever VITAS som en konsistent og brugervenlig løsning

Acceptkriterier

Nr.BeskrivelseRelevant for
971.54.1Hver aktør (borgere, virksomheder, jobcentre, AA) oplever konsistent præsentation af borgerinformation (navn og CPR_nummer) på alle ordninger (FB 165067)VITAS
971.54.2Alle ordninger opfører sig ens, når de oprettes og indsendes af Anden Aktør (FB 178721, FB 164970)VITAS
971.54.3Alle ordninger med "send kladde" understøtter gensend kladde (FB 142979)VITAS
971.54.4Ensartede regler for valg og flytning af sager mellem jobcentreVITAS
971.54.5"Sæt ansvarlig" for jobcenter og Anden Aktør virker ens på alle ordninger (FB 171606)VITAS
971.54.6Indtast og fjern CPR-nummer på ansøgninger og bevillinger fungerer ens på tværs af ordninger (FB 179932, FB 213132, FB 225005)VITAS
971.54.7Frigiv / overtag fungerer ens på tværs af ordninger (FB 180749, FB 212804)VITAS
971.54.8 Beskyttet navn- og adresse håndteres ensartetVITAS
971.54.9Øremærkede ansøgninger fordeles automatisk til Anden Aktør, hvis borger er udlagt til Anden Aktør (FB 121411)VITAS
971.54.10Ensartede forretningsregler for borgerrelationer (FB 240522)VITAS
971.54.11Upload underskrift er generelt alternativ til underskrift med pen eller NemID / MitIDVITAS


Ikke behov for tilsagn.

Oversigt over berørte webservices 

Ingen ændringer i webservices.

Beskrivelse af epic

Baggrund

Denne epic har til formål at give bedre konsistens mellem ordningerne på VITAS. VITAS bærer i såvel kode, funktionalitet og brugergrænseflade præg af, at hver ordning i stort omfang er udviklet uafhængigt af hinanden. Indholdet i hver ordning er præget af analyser og prioriteringer foretaget af PO, forretning, FA mht. ambitionsniveau, budget mv. VITAS fremstår derfor i dag med nogle konsistensproblemer, hvor brugere med rimelighed forventer, at ordningerne opfører sig ens og konsistent, men hvor ordningerne i VITAS har mere eller mindre tilfældige forskelle. 

Indholdet i epic'en tager udgangspunkt i specifikke FB-sager jf. epicens acceptkriterier.

VITAS' ordninger er implementerede på hhv. gammel og ny applikation. Der forventes fortsat visuelle forskelle mellem gammel og ny applikation, mens der forventes større ensartethed mellem ordninger på samme applikation. Den gamle applikation forventes udfaset på et tidspunkt, hvorefter ordninger på den gamle applikation migreres til den nye applikation. Det afhænger af moderniseringsprojektet.

Regler

Jf. nedenstående epic acceptkriterier.

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

Alle brugere af VITAS oplever større ensartethed mellem ordningerne i VITAS. Der vil fortsat være mindre forskelle mellem ordninger på hhv. gammel og ny applikation i VITAS.

971.54.1 Hver aktør (borgere, virksomheder, jobcentre, AA) oplever konsistent præsentation af borgerinformation (navn, adresse og CPR_nummer) på alle ordninger (FB 165067) 

Status: Godkendt af PO. Prioritet: 1

Alle ordninger skal implementere følgende principper:

/wiki/spaces/CITY/pages/3391619122: /wiki/spaces/CITY/pages/3391619122

med følgende modifikationer:

  • Skjulte bogstaver ved passwords mv. vises med "***" (som genkendes ved indtastning af skjulte tegn i passwords).
  • konsistente meddelelser ved manglende adgang til borgerdata:
    • Anden aktør:  “Er ikke udlagt til anden aktør”
    • Jobcenter (ikke egen borger): “Tilhører en anden kommune”

Dokumentation

Dokumentation af forretningsregler for præsentation af borgerinformation skal opdateres med ovenstående forretningsregler som del af dette epic acceptkriterie:

FB'er:

971.54.2 Alle ordninger opfører sig ens, når de oprettes og indsendes af Anden Aktør (FB 178721, FB 164970) 

Status: Godkendt af PO

Ansøgninger fra alle ordninger følger standardflow for ansøgninger, der er indsendt af Anden Aktør jf. /wiki/spaces/CITY/pages/3528949768.

FB'er:

Øvrige observationer:

971.54.3 Alle ordninger med "send kladde" understøtter gensend kladde (FB 142979) 

Status: Godkendt af PO

Det er muligt at gensende e-mails, som tidligere er blevet sendt via ”Gensend”- knap. ”Gensend”-knappen vises på ansøgnings-, forlængelses- og ophørskladder samt på bevillingen, når den har status ”Sendt til arbejdsgiver”. Derudover vises ”Gensend”-knappen på ansøgninger, som er sent til høring – som dermed har status: ”Sendt til medarbejder-rep”. ”Gensend”-knappen vises øverst til højre på sagen, og vises som et papir-flyver ikon, uanset om der er tale om virksomhedens indgang til systemet eller jobcenterets sagsbehandlingsmodul.
Ved tryk på ”Gensend”-knappen fremkommer en dialogboks hvor den oprindelige e-mail adresse er for-udfyldt. Det er muligt at ændre på e-mail-adressen, og herefter sende mailen igen.
E-mails kan gensendes mere end en gang. Hver gang e-mailen gensendes vil dette blive stemplet i historikken og brugeren vil dermed kunne se hvornår der er blevet gensendt e-mails. Bemærk at det ikke er ansøgningen der gensendes, men kun mailen vedrørende ansøgningen.

Knappen aktiverer en dialog, hvor brugeren kan indtaste en ny e-mail adresse.

Findes allerede på virksomhedpraktik (og formentlig øvrige gamle ordninger).

Mangler på Fleksjob (og formentlig på Jobrotation).

FB'er: 

Reference

Fra versionsnote 2: VITAS – Versionsnote pr. 15. April 2016

"Det er nu muligt at gensende e-mails, som tidligere er blevet sendt via en ”Gensend”- knap. ”Gensend”-knappen vises på ansøgnings-, forlængelses- og ophørskladder samt på bevillingen, når den har status ”Sendt til arbejdsgiver”. Derudover vises ”Gensend”-knappen på ansøgninger, som er sent til høring – som dermed har status: ”Sendt til medarbejder-rep”. ”Gensend”-knappen vises øverst til højre på sagen, og vises som et papir-flyver ikon, uanset om der er tale om virksomhedens indgang til systemet eller jobcenterets sagsbehandlingsmodul.
Ved tryk på ”Gensend”-knappen fremkommer en dialogboks hvor den oprindelige e-mail adresse er for-udfyldt. Det er muligt at ændre på e-mail-adressen, og herefter sende mailen igen.
E-mails kan gensendes mere end en gang. Hver gang e-mailen gensendes vil dette blive stemplet i historikken og brugeren vil dermed kunne se hvornår der er blevet gensendt e-mails. Bemærk at det ikke er ansøgningen der gensendes, men kun mailen vedrørende ansøgningen."


971.54.4 Ensartede regler for valg og flytning af sager mellem jobcentre

Status: Klar til PO review

STAR ønsker ensartede regler og funktionalitet vedr. valg og flytning mellem jobcentre, hvor der i dag er forskelle jf.:

Camilla Hagedorn Trolle: Er det kun voksenlærling, som skal understøtte udrejste borgere?

Dokumentation opdateres når ensartning er implementeret.: /wiki/spaces/CITY/pages/3517939736.

FB'er:

Noter:

  • Dette epic acceptkriterie overtager indhold fra epic 971.35, som er slettet.

971.54.5 "Sæt ansvarlig" for jobcenter og Anden Aktør virker ens på alle ordninger (FB 171606) 

Status: Godkendt af PO

Alle ordinger virker ens vedr. "Sæt ansvarlig". Specifikt skal Fleksjob, Jobrotation og kompenserende ordninger virke på samme måde som Virksomhedspraktik.

FB'er:

971.54.6 Indtast og fjern CPR-nummer på ansøgninger og bevillinger fungerer ens på tværs af ordninger (FB 179932, FB 213132, FB 225005) 

Status: Godkendt af PO

Ansøgninger:

  1. Det er kun muligt at aktivere "Hent oplysninger" på dt indtastede / indsatte CPR-nummer når bruger har afkrydset "Jeg erklærer, at borgeren ..."
  2. Når brugeren har indtastet / indsat CPR-nummer og trykket "Hent oplysninger", skal de fire sidste cifre maskes af med "****" og kun fornavn vises.
  3. Når brugeren trykker "Fjern oplysninger" skal alle borgeroplysninger slettes og ansøgningen skal føres tilbage til tilstand før CPR-nummer blev tilføjet. Herunder skal jobcenter ved "Spørgsmål angående ansøgningen" evt. føres tilbage.

Ovenstående gælder både når virksomhed udfylder ansøgning og når jobcenter / anden aktør udfylder ansøgning i virksomhedssupport.

  • Dog kan jobcenter i virksomhedssupport ikke lave opslag på borgere fra anden kommune.
  • Dog kan anden aktør i virksomhedssupport ikke lave opslag på borgere, der ikke er udlagt til anden aktør.

Der må være mindre forskelle i brugeroplevelsen mellem ordninger på VITAS gamle applikation og på VITAS nye applikation, men den egentlige funktionalitet skal være den samme.

Epic acceptkriteriet implementeres ved først at identificere afvigelser, idet den beskrevne funktionalitet forventes at være implementeret. Herunder gentestens nedenstående FB'er. Afvigelser rettes.

FB'er:

971.54.7 Frigiv / overtag fungerer ens på tværs af ordninger (FB 180749, FB 212804) 

Status: Godkendt af PO

Overtag / frigiv findes på alle ordninger og på alle blankettyper (ansøgning, tilbud, bevilling, vurdering, tillægsbevilling) for jobcenter og anden aktør.

Overtag / Frigiv findes ikke i virksomhedssupport (Jobcenter og Anden Aktør).

FB'er:

971.54.8 Beskyttet navn- og adresse håndteres ensartet

Status: Klar til PO review

VITAS håndterer i dag beskyttet adresse, men "IsProtectedAddress" i DFDG's PersonStatusService betyder at BÅDE navn OG adresse er beskyttet. Dvs. der er kun én egenskab, som styrer begge forhold. 

Den nuværende håndtering er beskrevet her: /wiki/spaces/CITY/pages/3391619122

Disse forretningsregler skal implementeres på alle ordninger.

Desuden skal følgende ændringer implementeres:

  • Jobcenter må se adresse med adressebeskyttelse i såvel edit som i read-only view
    • Med meddelelse om "Personen har beskyttet adresse" i såvel edit som i read-only view
    • Hidtil har jobcenter kunnet se  beskyttet adresse i edit, men ikke i read-only (måske kun for nogle ordninger). 
    • Prioritet: Kan fravælges, hvis det er for dyrt (> 2 SP)
  • Tjek for adressebeskyttelse er dynamisk. Tjek mod aktuelle data og ikke mod data på indberetningstidspunkt.

Analyse:

Camilla Hagedorn Trolle: Et det de ønskede forretningsregler? Se også nedenstående:

FA observationer til forretningsafklaring vedr. navne- og adressebeskyttelse:

  1. Er det korrekt, at virksomheden ikke må kende adresse på en potentielt ansat med beskyttet adresse?
    1. Bevillingen handler om at der skal indgås et ansættelses (lignende) forhold
  2. Hvorfor er der ikke oplysning om beskyttet navn til alle aktører?
    1. Hvad er ønsket forretningsregel?
      Det forekommer at være korrekt, at virksomhed, borgers jobcenter og udlagt anden aktør kan se navn på indsendt ansøgning, samt på bevilling, da også virksomheden har behov for at vide hvem virksomheden ansætter.

Dokumentation opdateres med evt. ændringer: /wiki/spaces/CITY/pages/3391619122

FB'er:


971.54.9 Øremærkede ansøgninger fordeles automatisk til Anden Aktør, hvis borger er udlagt til Anden Aktør  (FB 121411)

Status: Klar til PO review

Et jobcenter skal kunne vælge at øremærkede ansøgninger vedr. en borger, der er udlagt til Anden Aktør, automatisk sendes til Anden Aktør. Det gælder kun for Anden Aktør, som er tilknyttet jobcenteret som rolle 3 (myndighed). Hvis borger er udlagt til flere Anden Aktør med myndighedsrolle på jobcenteret, vælger VITAS tilfældigt en af disse Anden Aktør.

Ny tjekboks (default fravalgt svarende til nuværende forretningsregler):

"[ ] Anden Aktør modtager automatisk øremærkede ansøgninger vedrørende borgere, der er udlagt til Anden Aktør"

Tjekboks indsættes på siden "Anden Aktør administration":

Denne fordelingsregel har højere prioritet end øvrige forretningsregler for fordeling af ansøgninger, herunder:

  • Opsatte fordelingsregler for teams jf. "Administration af fordelingsregler"
  • Regler for at AA modtager ansøgning, når virksomhed underskriver ansøgning i AA's session eller virksomhed indsender kladde, som AA har fremsendt til virksomhed. 

Dokumentation opdateres:

FB'er:


971.54.10 Ensartede forretningsregler for borgerrelationer (FB 240522)

Status: Skal afklares med PO

STAR skal fastlægge ensartede forretningsregler for relationer mellem borger og jobcenter. Problemstillingen er beskrevet i FB 240522:

Vi har ifm. Vallensbæk / Ishøj opsplitning fundet ud af at nye og gamle ordninger opfører sig forskelligt mht. fortolkning af relation mellem blanket, borger og jobcenter. VITAS har (af ikke helt forståede årsager) både en relation fra blanket til jobcenter og en relation fra blankettens borger til jobcenter.

"Nye ordninger:
Borgerens jobcentercode er afgørende for om borgeren bliver vist
Efter flytning kan Ishøj ikke se borgeren på øremærkede ansøgninger/bevillinger (Men Vallensbæk kan godt)

Gamle ordninger:
Blankettens jobcentercode er afgørende for om borgeren bliver vist
Efter flytning kan Ishøj se borgeren på øremærkede ansøgninger/bevillinger (Og Vallensbæk kan ikke)"

Ved manuel flytning af sager i VITAS, flyttes kun blankettens jobcenterkode og ikke blankettens borgers jobcenterkode. Det giver problemer på de nye ordninger.

Vi ønsker ensartede regler.
1) Vi skal afklare hvorfor vi har 2 relationer og afklare sammenhæng mellem relationer og forretningsregler i VITAS. Det vil være optimalt, hvis kun den ene relation styrer forretningsregler.
2) Vi skal have en ensartet implementering af jobcenterrelation og forretningsregler på nye og gamle ordninger.
3) VITAS anvender på statiske relationer mellem blanket/borger og jobcenter. Borgerens aktuelle status fra DFDG anvendes ikke. Vi skal sikre, at STAR er enige i den fortolking.
Dokumentation af disse forretningsregler skal opdateres efter afklaring:
/wiki/spaces/CITY/pages/3391619122


971.54.11 Upload underskrift er generelt alternativ til underskrift med pen eller NemID / MitID

VITAS tilbyder i dag mulighed for at en bruger kan underskrive med pen eller eller NemID / MitID, hvis brugeren skal godkende / underskrive i en anden brugers session. Det gælder bl.a. ved:

  • Virksomhed indsender ansøgning i virksomhedssupport (Jobcenter eller Anden Aktør har sessionen)
  • Medarbejderrepræsentant godkender ansøgning (Virksomhed, Jobcenter eller Anden Aktør har sessionen)
  • Virksomhed godkender bevilling i virksomhedssupport (Jobcenter eller Anden Aktør har sessionen)
  • Borger godkender ansøgning / bevilling (Virksomhed, Jobcenter eller Anden Aktør har sessionen)

Medarbejderrepræsentant har desuden mulighed for at godkende ved upload af bilag med underskrift jf. /wiki/spaces/CITY/pages/3523641382

Brugerne ønsker at gøre det muligt at godkende ved upload af bilag med godkendelse som et generelt alternativ til at en bruger kan underskrive med pen eller eller NemID / MitID, når en anden bruger har den aktive session. Det vil bl.a. løse et stort ønske fra jobcentrene for at virksomheder kan godkende via e-mail eller telefonnotat:

  1. Den nuværende mulighed for at godkende ved upload af bilag med underskrift for medarbejderrepræsentant ændres til et generelt alternativ for alle godkendelser i andre brugeres sessioner.
  2. Løsningen generaliseres til at det ikke nødvendigvis skal være et bilag med underskrift, men også kan være en godkendelse i en e-mail eller et telefonnotat.
  3. Det nuværende flow erstattet af et mere brugervenligt flow, da det nuværende flow er for tungt. Se evt. /wiki/spaces/CITY/pages/3523641382. Det nuværende upload flow for bilag på de nye ordninger, fx. for Mentor,kan danne udgangspunkt for et mere brugervenligt flow. 
  4. Der indsættes vejledning om hvad der skal indgå i et bilag med godkendelse.
  5. Bilag med godkendelse skal lagres på sagen som dokumenttype "Bilag med godkendelse".
  6. Signering og historik skal linke til bilaget (fx download af bilaget)


Upload dialog på Mentor ti linspiration:


Særlige krav til test

Test scenarieBerørte systemområder (herunder nye batchjobs*) Identificeret af






* 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 )


Alle borgere

Egne borgere

Tidligere egne borgere

Gæsteadgang

Anden Aktør - egne borgere

Anden Aktør - gæsteadgang

A-kasse


X





JobCenter


X



X


Kommune


X





STAR

X






AUB







UDK







STIL








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





  • No labels

Tilgængelighed: https://starwiki.atlassian.net/was