Ønske 1/2021 Overlappende grader
Formulert utenfor RT av SV 4.1.2021 i samråd med HF og MN og etter erfaringsutveksling i FS-nettverket 7. desember 2020, sak 8. Sendt Unit i deres RT#412581, 11. januar 2021.
Status: Løst i databaseversjon FS8.3.1 og klient 8.3.2, i FSPROD mot slutten av mai 2021:
Bildene “Oppnådd kvalifikasjon samlebilde” og “Oppnådd kvalifikasjon protokoll samlebilde”: Fane Emne: Lagt til kolonne “Annen kvalif.” som viser antall studiepoeng som inngår i annen kvalifikasjon. Mouseover på kolonne med verdi vil vise hvilken kvalifikasjonsoppnåelse det gjelder (kode og dato). Det er lagt til en sum under kolonnen, og denne blir rød når summen overstiger 60.
Rutinen “FS651.002 Beregning av oppnådd kvalifikasjon – utdanningsplanbasert”: For emner som inngår i annen kvalifikasjon vises det nå en merknad med rød tekst. Denne beregningen gjøres kun for studenter som det opprettes kvalifikasjonsoppnåelse for.
Status 18.10.2021 om eksterne resultater: I FS8.3.6 revisjon 2 (i fsprod i slutten av oktober 2021), i bildene Oppnådd kvalifikasjon og Oppnådd kvalifikasjon protokoll er det under fanen Ekstern resultat innført ny kolonne "Annen kvalifik.". Denne har samme funksjonalitet som tilsvarende kolonne under fanen Emne.
Det som gjenstår er en generell visning i bildet om overlappende studiepoeng mot annen kvalifikasjon, uten at en må se innom disse to fanene.
I rutinen FS651.002 er det lagt til merknad også for eksternresultater om disse inngår i tidligere oppnådd kvalifikasjon.
Status 18.11.2021 om eksterne resultater: Det er lagt på varseltrekant og "mouseover"-tekst der det er overlapp for hhv. interne og eksterne resultater. Kommer en gang etter FS8.3.7, som kom 17.11.2021.
Beskrivelse
I henhold til UiO-forskriftens § 2.8 Krav til grad ved tildeling av samme grad på ny eller av flere grader må emner til sammen minst 60 studiepoengs omfang være avlagt i tillegg til tidligere grad ved tildeling av graden bachelor på ny eller på et grunnlag som helt eller delvis inkluderer en tidligere tildelt grad. I tillegg må den nye graden ha et annet faglig tyngdepunkt enn den tidligere graden.
Eksempel på faglig tyngdepunkt:
Ved Det samfunnsvitenskapelige fakultet vil en student som har en bachelorgrad i utviklingsstudier med fordypning i statsvitenskap ikke oppfylle kravet til et annet faglig tyngdepunkt og kunne få utstedt en bachelorgrad i statsvitenskap.
For å sjekke at det registreres grader og skrives ut vitnemål som er i tråd med regelverket, må dette sjekkes manuelt. Det er tidkrevende å kontrollere om studenten har oppnådd tidligere kvalifikasjoner og manuelt kontrollere (telle) antall overlappende studiepoeng på de to kvalifikasjonene. En manuell kontroll åpner også opp for feil og er sårbart.
Per nå får saksbehandler et kontrollspørsmål om man virkelig vil legge inn et emne i utdanningsplan om dette inngår i en tidligere grad. På UiO er det oftest ulik saksbehandler som endrer utdanningsplanen og som registrerer grad og skriver ut vitnemålutskrift. I tillegg kan det gå lang tid mellom tidspunktet for endring av utdanningsplan og registrering av grad og utskrift av vitnemål, slik at denne funksjonen ikke vil være til hjelp i disse tilfellene.
Løsningsforslag
- Vi ønsker at det kommer en merknad i rutinen FS651.002 Beregning av oppnådd kvalifikasjon – utdanningsplanbasert for emner som allerede inngår i en annen kvalifikasjon.
Vi ønsker merknadstekst i rødt for emner som inngår i en grad allerede, helst med GRADKODE. Eksempelvis slik: Emnet inngår allerede i grad SVB-KS.
Hvis emnet inngår i flere grader, ønsker vi at alle gradene skal listes opp.
Eksempelvis slik: Emnet inngår allerede i grad SVB-KS, SVB-STV
På denne måten vi vi raskt oppdage om det er mange emner som inngår i utdanningsplanen som allerede inngår i en kvalifikasjon fra før og at disse må sjekkes spesielt.
FS651.002 benyttes i gradfangst og er dermed egnet for en slik merknad da det blir tydelig om det bør vurderes nærmere før saksbehandler overfører kvalifikasjonen til protokoll. - Vi ønsker i tillegg at det kommer en ny kolonne i bildet Oppnådd kvalifikasjon med overskriften Inngår i tidl. grad eller tilsvarende. Vi ønsker også gjerne at det kan summeres nederst hvor mange studiepoeng som finnes i tidligere grad (i blått). Hvis dette overskrider grensen på 60 studiepoeng må vi sjekke spesielt om det er i samme grad eller om det ev. er ulike grader.
Forskrift
Kunnskapsdepartementets Forskrift om godskriving og fritak av høyere utdanning § 4 om krav til 60 stp. og at den nye graden må som hovedregel ha en annen faglig fordypning enn tidligere grad.
Ønske 2/2021 Løsninger for å håndtere ulike vurderingsordninger på samme emne
Ønsket av SV i RT#3588054 og RT#4182853, jf. FS-nettverket 5. oktober 2020, sak 6. Sendt Unit 14.01.2021 i RT#412976
Status 17.02.2022: Avvist av FS-planleggingsgruppe da det er ikke ønskelig å gjøre endringer i dette på nåværende tidspunkt, med så få tilfeller dette gjelder. Ønsker å prioritere ressursene på fornying av FS.
Navn på bilde/rutine/rapport/annet det gjelder
- Mulighet til å styre studenter med plass på gitte undervisningsparti mot gitt eksamensordning i Studentweb
- Oppdatere rutine 511.001
- Ny rutine 5xx.xxx overføring av studenter på undervisningspartier fra én vurderingsordning til en annen
Opprinnelig RT-nummer til Unit ved tidligere behandling
Usikker, mulig noe tilsvarende er innmeldt før 2011
Begrunnelse
Ønsker å kunne fjerne behovet for SQL og gjøre sammenhenger mellom undervisningsvalg og eksamensmuligheter tydeligere.
Beskrivelse av problemstilling
I FS er det mulig å ha flere vurderingsordninger på samme emne i samme termin. Ved UiO brukes dette for eksempel ved examen philosophicum og examen facultatum ved SV-fakultetet, hvor studenter på ett gitt undervisningsparti «selvstudium» (enten ved direkte oppmelding eller ved søknad) egentlig skal ha en gitt eksamensordning (ofte skriftlig eksamen med tilsyn).
Slik det virker i dag, så kan studentene velge eksamensordning fritt. Til tross for at de har valgt selvstudium på undervisningen får de meldt seg til eksamensordningen som krever at man er meldt på og følger seminarundervisning. Dette medfører at administrasjonen må flytte studenter som har valgt feil ved å bruke SQL. For emner som har SØKNAD/ undervisningsopptak er det heller ikke mulig for administrasjonen å opprette vurderingsmelding på forskjellige eksamensordninger ut fra hvor studentene får plass.
Administrasjon av emner med flere samtidige vurderingsordninger må altså gjøres med SQL. Det er tidkrevende, både for lokal administrasjon, som må vente på at oppgaver utføres sentralt, og for sentral administrasjon, som må utføre oppgaver for fakultetene som de burde kunne utføre selv.
Vi mener at når det er teknisk mulig å legge opp til flere vurderingsordninger på samme emne i samme semester, så bør det kunne administreres, i hvert fall med rutiner.
Løsningsforslag
Løsningsforslaget er tredelt:
- For emner med DIREKTE påmelding til undervisning i Studentweb (enten det gjelder påmeldings- eller etteranmeldingsperiode) ønsker vi å kunne angi at studenter som melder seg til ett eller flere angitte undervisningspartier kun får mulighet til å velge vurderingsordning X.
- For emner med SØKNAD/undervisningsopptak eller MANUELL påmelding ønsker vi en endring i rutine 511.001 Oppmelding av undpåmeldte til vurdering. Her bør saksbehandler få velge undervisningsenhet og undervisningsparti også, og ikke bare emne.
- Vi trenger i tillegg en ny rutine 5xx.xxx for å administrere endringer etter oppmeldingsfrist som kan brukes istedenfor SQL. Vi ser for oss noe som ligner FS456.002 Kopiering av partiplasserte fra undenhet til undenhet, men hvor saksbehandler kan kopiere (og slette) eksisterende vurderingsmeldinger for studenter på undervisningsparti x til vurderingsenhet y.
Vi forstår at Unit har begrenset med utviklingsressurser, og vil prioritere løsningsforslag 3 høyest siden saksbehandlere dermed kan korrigere registreringer selv fortløpende ved å kjøre denne rutinen. Dernest løsningsforslag 2 som vil gjøre det enklere å ha SØKNAD/administrere undervisningsopptak for slike emner.
Løsningsforslag 1 hadde vært mest brukervennlig for studentene på slike emner med DIREKTE påmelding, men det kan omgås ved å bruke SØKNAD dersom rutinene over prioriteres.
Vurdering av konsekvenser
Tydeligere for studentene, bedre brukeropplevelse. Mindre administrativ tidsbruk.
Ønske 3/2021 FS515.001: Nytt slettegrunnlag: Bestått emne med emnesperre
Løst 08.11.2021: Rutinen FS515.001 er til FS8.3.7 utvidet med valg for sletting på grunnlag av bestått emne som gir emnesperre.
25.01.2022: Fra Studentweb 3.3.29.2 (januar 2022) kommer det varsel før man melder seg: "Du kan melde deg til undervisning, men meldingen vil bli slettet dersom du får resultat i emnet (#1)" + varsel om viktig på startsiden: "Meldingen din til emnet (#1) vil bli slettet dersom du får resultat i emnet (#2)":
Ønsket av SV i RT#4234806 22. januar 2021, etter samråding i RT#4218287. Sendt Unit 1. februar i RT#414840.
Problemstilling
På UiO, og på noen institutter i stor grad, som på Økonomisk institutt er det restriksjoner på å ta eksamen på lavere faglig nivå, når visse emner på høyere faglig nivå er bestått. Grunnen kan være at emnene bygger på hverandre, og man skal ikke kunne ta visse emner på lavere faglig nivå når man har startet på et høyere faglig nivå. Emnenes studienivåkode er ikke direkte relevant her.
På emne samlebilde på det høyere faglige nivået, fanen emnesperre, legger vi inn emne(r) som instituttet vurderer at er på lavere faglig nivå. Det sperrer for at studenten i Studentweb får melde seg for de oppgitte emnene på lavere faglig nivå hvis det foreligger et resultat i emnet på høyere faglig nivå.
Emnesperren tar utgangspunkt i protokollført eksamensresultat i emnet på det høyere faglige nivået. Dette medfører at studenter får melde seg til emner på lavere faglig nivå for påfølgende semester i perioden før sensur på emnet i det høyere faglige nivået er protokollført.
Eksempel: Student får melde seg til ECON1410 for våren 2021 før resultat i ECON3220 er registrert i protokoll for høsten 2020.
Det er per i dag ingen måte å kontrollere de som ev. har fått meldt seg til et emne som er registrert i emnesperre-fanen på lavere faglig nivå før resultatet er registrert i protokoll på emnet på høyere faglig nivå.
Løsningsforslag
1) Vi ønsker at det legges inn et valgpunkt om emnesperrer i FS-rutinen 515.001 Sletting av vurderings- og undervisningsmeldinger under under "Slette på grunnlag av", slik at vi kan slette oppmeldingen i et emne på lavere faglig nivå hvis et emne på høyere faglig nivå har blitt bestått.
Vi vil da eksemplevis legge inn ECON1410 i FS515.001 og velger det nye punktet om emnesperre. Da skal rutinen ta hensyn til alle emner der ECON1410 er registrert i fanen "emnesperre". Eksempelvis ECON3220.
Forslag til navn på nytt punkt: *Bestått emne med emnesperre
2) I Studentweb, i form av redigerbar tekstkode, varsel til studenter som melder seg til et emne (på lavere faglig nivå) som er oppført under emnesperre på et annet emne (på høyere faglig nivå), og som studenten har vurderingsmelding i, dersom studenten melder seg til dette første emnet (det på lavere faglig nivå) før resultat på det emnet med høyere faglig nivå er protokollført. Varselet på meldingen til det lavere emnet kan eksempelvis være: "Melding til [ #EMNEKODE på emnet på lavere faglig nivå] vil bli slettet dersom du består [#EMNEKODE (på emnet på høyere nivå)] og som du ikke har fått resultat på ennå. Les mer på emnebeskrivelsen."
Hvordan er endringsønsket vurdert lokalt?
Økonomisk institutt har veldig mange emner med emnesperrer. Se restriksjonene som gjelder. Det er i all hovedsak i Økonomisk institutt som har dette behovet ved SV-fakultetet og forslaget er diskutert med dem.
Konsekvenser og regelverk
Vi vil bli i stand til å kontrollere, håndheve og informere om regler for emnesperre. Vi har vurdert det slik at det ikke er tilstrekkelig med et nytt valg for emnesperre i FS-rutine 515.001 og informasjonstekst på emnebeskivelsen, for studenten må få vite hva som kan skje der studenten foretar handlingen. Regler om emnesperre for enkelteemner er ikke egnet til å lov- og forskriftsfesting, og vi kan kan dermed ikke forutsette at emnesperre er allment kjent for studenten.
Ønske 4/2021 FS460.002 Beregning av kvalifisert - und. påmeldte: Merknad og funksjon ved klagesak
Ønsket av SV 2. februar 2021 i RT#4252394 og bearbeidet i dialog med studieavdelingen. Sendt Unit i RT#444373 10. mai 2021.
Problemstilling
Vi følger opp studenter som er meldt til et emne som har forkunnskapskrav (=videregående emne) og venter på sensur på emnet som utgjør forkunnskapet (=begynneremnet) ved å kjøre FS460.002 "Beregning av kvalifisert - und. påmeldte" når sensur har falt i begynneremnet. Vi haker av for "Oppdater tilbudsstatus til AV og slett evt. partiplassering, for studenter som beregnes ikke-kvalifisert" - altså for de som ikke har bestått begynneremnet/forkunnskapskravet.
Studenter som stryker på begynneremnet kan imidlertid klage på karakter og kan potensielt få bestått i begynneremnet etter klagebehandlingen. Disse ønsker vi ikke å slette i det videregående emnet før vi vet at studenten har får behandlet klagen på resualtatet på begynneremnet.
Nå må vi ev. sjekke hvem som har klaget på karakter og så melde dem opp igjen etterpå. Alternativt blir de slettet og så må de ev. meldes opp igjen og partiplasseers etter at studenten tar kontakt. Dette krever mye manuell håndtering, med fare for å overse noen.
Vi har behov for å vite, når vi kjører FS460.002, om det er noen av dem som ligger an til å få slettet oppmeldingen sin i det videregående som har en aktiv (ikke-ferdigbehandlet) klagesak gående i FS, slik at vi kan holde dem utenfor rutineoppdateringen. Det ville hjulpet litt med en merknad om klagesak i FS460.002, men det er ikke tilstrekkelig for å unngå manuelt etterarbeid. Med en merknad om aktiv klagesak, må vi likevel håndtere en ev. gjenoppmelding manuelt dersom vi kjører FS460.002 med oppdatering av database. Vi må også notere oss bak øret hvem vi skal holde øye med og ev. oppdatere i etterkant. Vi har altså behov for at de som har en aktiv klagesak ikke skal omfattes av rutineoppdateringen i FS460.002. Vi ser for oss en ny hake i FS460.002 som sier noe slikt som "Unnta studenter som venter på klagebehandling".
Vi må normalt kjøre FS460.002 flere ganger for at også studenter venter på sensur i utsatt eksamen på begnneremnet også blir tatt hånd om i FS460.002-kjøring. Så lenge de er vurderingsmeldt vil de ikke slettes med FS460.002, men rutinen må dermed kjøres en gang til ev. etter at sensur har falt.
Det vil alltid være enkeltstudenter som av ulike grunner får opperette klagesak veldig sent eller som får den ferdigbehandlet etter veldig lang tid, og langt inn i neste semester, og etter at vi har kjørt FS460.002 med oppdatering. Det kan også være studenter som langt inn i neste semester får ugyldiggjort eksamensresultatet på begynneremnet som følge av vedtak i klagenemda. Slike saker vil likevel være få av, og de vil vi håndtere manuelt og skjønnsmessig vurdere hva som skal skje med opptaket på det videregående emnet. Et mulig utfall kan være at de som ev. har klaget på karakter får avlegge emnet på høyere nivå til tross for at de har strøket i forkunnskapsemnet.
Løsningsforslag
- Merknad om klagesak i forkunnskapsemnet i kolonnen for merknad i FS460.002 Beregning av kvalifisert - und. påmeldte. Eksempelvis: "Klagesak finnes i ECON1100".
På denne måten vil vi se hvilke studenter som ev. har klagesak som ikke er ferdigbehandlet i ett eller flere forkunnskapsemner
og - Ny hake i FS460.002 "Unnta studenter som venter på klagebehandling"
Ønske 5/2021 Dato_tid_komplett_søknad
Ønsket av studieavdelingen. Sendt Unit 26.3.2021 og 6.4.2021 i RT#439710 / Unit arkiv ref. 21/00354-1. Jira-ref. FS-1041
Løst i FS8.3.6 (høsten 2021):
FS101.001 og FS101.014: Lagt til kolonner for om søknad er komplett, og dato for når siste dokument ble lastet opp i saken. FS tar i dag ikke vare på tidspunktet når en søknad er komplett - dette bør Unit ev. se nærmere på dersom tidspunktet for siste dokument ikke er ok.
Begge rapportene har allerede søkernr som kolonne. I FS101.001 kan denne velges bort til fordel for visning av jnr.
I rapporten FS101.014 er det lagt på et nytt standard sorteringsvalg for søkernr (når sortering velges fra meny).
Det er ikke lagt på kolonne for dato-tid-tilbudsstatus-registrert da FS ikke tar vare på denne informasjonen i dag.
Navn på rapport ønsket gjelder
101.014 Mottatt dokumentasjon, samt 101.001 Søkerliste
Begrunnelse
For å kunne håndtere løpende opptak uten konkret søknadsfrist, trenger saksbehandlere verktøy for å sjekke når søknader er komplette og klare for videre saksbehandling all den tid systemet tillater innsending av søknader som ikke er komplette. Dato og tidspunkt for når en søknad er komplett er også viktig for å kunne se om man overholder saksbehandlingsfrister i et løpende opptak. Der det ikke er angitt konkret saksfrist, utledes dette fra forvaltningsloven, samt eventuell konkret info til søkere. I hht. forvaltningslovens § 11a skal søkere varsles om søknad ikke behandles innen fire uker.
Beskrivelse av problemstilling
Søknadsweb er ikke rigget for å håndtere løpende opptak, og i påvente av en søknadsløsning som håndterer dette, ønsker vi å få tilrettelagt rapporter i FS, så saksbehandlere lettere kan følge med på komplette søknader og overholde tidsfrister.
Ph.d.-opptak har ikke konkrete søknadsfrister, men søkere dukker opp løpende gjennom året. Komplette søknader skal behandles uten ugrunnet opphold, med mindre annet er eksplisitt angitt. Dersom søknaden ikke kan behandles innen fire uker, skal søker varsles.
Løsningsforslag
Vis-valg for søkernummer og dato_tid_komplett søknad, først og fremst i primærrapporter for ph.d.-opptaket, FS101.014 og FS101.001. Vi prioriterer endring i 101.014 foran 101.001 dersom endringer i sistnevnte rapport er vanskelig. Dersom det er vanskelig å gjennomføre endringer i eksisterende rapporter, så ønsker vi oss en ny rapport hvor følgende er mulig:
Det er mulig å sortere på søkernummer ved å velge sortering og dra REGNR til øverst i sorteringsbildet i dag, men ideelt sett hadde det vært fint å kunne velge det i rapportene som et «vis» valg på linje med fødselsnummer. Ved å velge sortering på søkernummer, vil rapportene kunne vise en kronologisk liste over søkernummer framfor alfabetisk liste på navn. Dersom man i tillegg velger vis-valg for dato_komplett_søknad, så ønsker vi at søkere blir sortert først på dato_tid_komplett søknad og deretter på søkernummer. Dersom det gjøres endringer slik at det ikke blir mulig å levere ufullstendig søknader i Søknadsweb, vil det være tilstrekkelig å kunne sortere på søkernummer, men det er fremdeles ønskelig å kunne få inn dato_tid_for_komplett søknad, for å beregne om man overholder saksbehandlingsfristene i løpene opptak.
Vi ønsker oss ideelt også dato for ferdig saksbehandling. Vi anser saksbehandlingen for å være ferdig når tilbudet er registrert og søker kan takke ja, så operasjonalisering kan være dato_tid_tilbudsstatus_registrert.
Vurdering av konsekvenser
Ingen negative konsekvenser ved institusjonen. Gjør det lettere også for flere løpende opptak å ta i bruk Søknadsweb og opptaksmodulen til saksbehandling.
Vurdering av juridiske forhold og henvisning til sentrale og lokale regler
Gjøre det mulig å vite hvorvidt man overholder saksbehandlingstid ihht. forvaltningsloven.
Ønske 6/2021 FS155.002 Søkere med studierett: Vise studentnr.
Ønsket av SADM ved OPP. Sendt Unit dato 20.5.2021
Begrunnelse
Vi ønsker at studentnummer skal kunne vises i rapporten FS155.002, ikke bare søkernummer og fødselsnummer for å lette arbeidet.
Problemstilling
Rapporten FS155.002 brukes til å finne søkere som allerede har studierett på et studieprogram de har søkt om opptak til på nytt.
De aktuelle søkerne må slås opp i Student samlebilde for å sjekke om de trenger å søke på nytt eller ikke. I rapporten får vi ut liste med kun søkernummer. Søkerne må derfor først slås opp i Søknad samlebilde NOM for deretter å gå inn i Student samlebilde. Dette gjør at operasjonen får unødvendig mange ledd. Vi ønsker derfor at listen også inneholder studentnummer, slik at vi kan slå opp søkerne direkte i Student samlebilde.
Det er mulig å få opp søkerne med fødselsnummer i rapporten, men listene blir ofte sendt per e-post til aktuelle på fakultetene som skal sjekke studierettene. Det er av personvernhensyn derfor ikke aktuelt å ta ut lister med fødselsnummer i denne sammenhengen.
Løsningsforslag
Det legges inn et ekstra valg under Vis (under Fødselsnr og Journalnr) om å vise studentnummer i rapporten FS155.002.
Vurdering av konsekvenser
Vi kan slå opp studentene direkte i Student samlebilde, uten å gå via Søknad samlebilde NOM. Dette vil gjøre sjekken av de aktuelle søkerne mer smidig, og man sparer ressurser ved å ikke måtte slå de aktuelle søkerne opp i flere bilder.
Ønske 7/2021 Arbeidslivsportalen (ALP): praksisaktiviteter
Ønsket av studieavdelingen og UiOs prosjektgrupp for forprosjekt for Arbeidslivsportalen (ALP). Sendt Unit 27.5.2021 i deres RT#445967
Gjelder
Arbeidslivsportalen (ALP) praksisaktiviteter i praksiskalender
Begrunnelse
Effektivisering og tidsbesparelser for saksbehandlere i ALP.
Problemstilling
Endringer av detaljinfo på praksisaktiviteter må gjøres pr enkeltklasse. Det leder til mange tastetrykk og merarbeid for saksbehandler. Vi ønsker at ALP legger mer til rette for å velge å utføre endringer for flere klasser av gangen.
Løsningsforslag
Med tanke på emner med svært mange praksisklasser, så er vi usikre på om dagens løsning, hvor man må klikke seg inn på de enkelte klassene, er den mest hensiktsmessige. Men slik løsningen foreligger i dag, så ønsker vi altså i alle fall å kunne velge å la endringer gjelde for en eller flere klasser av gangen ved å hake av for dette, eller lignende.
Vi er altså usikre på hva som er akkurat det beste løsningsforslaget med tanke på utvikling av ALP som helhet, men ser for eksempel behov for å kunne:
- Under fanen steder, velge å gjennomføre endring av nivå (opp eller ned) for avtale for en eller flere klasser samtidig.
- Under fanen roller, velge å knytte underviser til en eller flere klasser.
Vi ønsker også at man skal kunne velge å importere FS-klasser som praksisklasser i ALP, så man slipper å opprette og tildele studentene til flere klasser der det allerede er gjort en fordeling av studentene på forhånd i FS. Dette ønsket er dog underordnet det å finne en løsning på at man slipper unna med færre tastetrykk i de klassene som finnes i ALP. Mulig det kunne vært løst med at man kan velge å kopiere klasse A framfor å bare opprette nye klasser ved å trykke på plusstegnet i praksiskalenderen.
Ønske 8/2021 Kopiere kommisjoner fra en vurderingsenhet til en annen
Ønsket av MN i RT#4387057 21. mai 2021.
Sendt Unit 10. juni 2021 i deres RT#447621 og presiseringer i sikt.no RT#303550 april 2022.
Status 07.02.2022: Løst i 8.4.
Følgende er på plass til FS8.4:
- Ny rutine FS551.003 Kopiere kommisjoner fra en vurderingsenhet til en annen. Parametere for rutinen er Fra vurderingsenhet og Til vurderingsenhet. Rutinen kopierer alle kommisjoner fra vurderingsenhet til vurderingsenhet.
Merk at dersom det allerede eksisterer minst en kommisjon for til-enheten, så vil ikke rutinen kopiere noen nye kommisjoner til denne.
02.05.2022 Rutinen endret til: Det er mulig å kopiere kommisjoner til en vurderingsenhet som allerede har en eller flere kommisjoner. Hvis kommisjonsnummeret allerede eksisterer, kopieres kun de øvrige kommisjonene. - Ny rutine FS551.004 Opprette enkeltkommisjoner for vurderingsmeldte
Parametere for rutinen er Vurderingsenhet og om navn for kommisjon skal være kandidatens nr eller kandidatens navn (siste tilfelles gir ikke anonymitet).
Rutinen gjennomgår alle vuderingsmeldte og opprettet kommisjon for dem som ikke allerede er knyttet til en kommisjon. Rutinen vil for disse knytte meldingen til den nyopprettede kommisjonen.
Problemstilling fra MN
På MN gjennomfører vi masteroppgaveinnlevering i Inspera. Eksempelvis på IFI er det typisk 150 kandidater som leverer masteroppgaven på vårsemesteret. På en masteroppgave må hver kandidat ha en egen kommisjon i FS. Med andre ord oppretter studiekonsulenter 150 kommisjoner på vurderingsenheten for den skriftlige oppgaven. Hvis vi skal kunne gjennomføre muntlig sensuren i Inspera må det opprettes sensurprøve for denne biten. Dette betyr at man må lage alle kommisjoner i FS på nytt. Spørsmålet mitt er da: Er det noe funksjon i FS som tillater kopiering av kommisjoner slik at vi kan "kopiere" kommisjoner, uten å manuelt måtte opprette alle på nytt?
Vurdering i studieavdelingen
Kopieringsmuligheten finnes ikke i dag. Vi antar at behovet også gjelder andre fakulteter. Stemmer det? Behovet vil være tilsted enten man benytter Inspera eller Fagpersonweb til sensur av muntlige eksamen, så vi tror derfor ønsket vil være av interesse også for andre FS-institusjoner.
Behov og begrunnelse
Effektivisering: Ny rutine i vurderingsmodulen for å kopiere sensurkommisjoner fra én vurderingsenhet til en annen: FS5xxx.xxx
Beskrivelse
Med innføringen av digital sensur er det nødvendig å registrere sensurkommisjon på alle vurderingsdeler for at systemene skal virke. Dette er særlig aktualisert på masteroppgaveemner der sensur på masteroppgaven ofte har en muntlig eksamen som bruker et system for sensurregistrering, eksempelvis Inspera eller Fagpersonweb. På masteroppgaveemner er sensurkommisjonene i høy grad helt individuelle og på emner med svært mange kandidater, i f.eks. størrelsesorden 100-200, er registrering av sensurkommisjoner nå blitt tidkrevende
Løsningsforslag
Ny rutine hvor vi kan velge å kopiere kommisjoner fra én vurderingsenhet til en annen vurderingsenhet for å unngå dobbeltregistreringer, FS5xx.xxx Kopiere sensurkommisjon.
Ønske 9/2021 Filter-funksjon i Søknad samlebilde
Ønsket av MN i RT#4439115 29. juni 2021.
Vurdert og bearbeidet i studieavdelingen (SADM).
Sendt Unit 5.10.2021 i deres RT#463284.
Problemstilling fra MN
Kunne filtrere i søknad samle bilde, for eksempel med følgende filter:
( dokstatkode = 'DUE') or ( dokstatkode = 'BEH') and ( kvalgrunnlag not in ('EU'))
Dette ser ut til å kun fungere i søkerlisten (FS101.001), men det hadde vært flott dersom denne funksjonen også kan bli tilgjengelig i søknad samlebilde.
Tilbakemelding fra SADM
I søknad samlebilde heter dokstatkode i stedet dokumentasjonstatuskode, så det kan man filterere på. Kvalgrunnlagkode er det dessverre ikke mulig å filtere eller sortere på i bildet idag.
Vi antar det er mulig å få inn dette feltet blant filter-mulighetene, men det ligger i en annen tabell enn søknadstabellen (som er utgangstabellen for samlebildet), så det vil kreve utviklingsressurser hos UNIT.
Er det mye arbeid å spare for opptaksfolket, hvis vi får denne filteringsmuligheten?
Begrunnelse
I rapporten FS101.001 Søkerliste kan saksbehandlerne filtrere på datafelt fra flere tabeller slik at de kan se på søkere som bare er relevante .
Eksempel: dokstatkode = 'BEH' and not kvalgrunnlag= 'EU'
Noe liknende kan man gjøre i Søknad samlebilde, men der finner vi ikke igjen kvalgrunnlag, altså data fra tabellen fs.persongrunnlag.
Løsningsforslag
1) Inkludere tabellen fs.persongrunnlag i filtrerings- og sorteringsdataene i Søknad samlebilde
2) I rapport FS101.001 Søkerliste brukes ordet dokstatkode, mens i Søknad samlebilde brukes ordet dokumentasjonstatuskode om det samme. Bruk samme begrep både i bilde og i rapport.
Vurdering av konsekvenser
Saksbehandlerne kan raskere komme gjennom sine saker i søknads-"bunken" i Søknad samlebilde hvis de slipper å bla forbi "uinteressante" søkere.
Ønske 10/2021 Opptaksgrunnlag søknad samlebilde
Ønsket av SADM i forbindelse med Utvikling av opptaksmodulen fra ph.d.-opptakspiloten. Sendt Unit 5.10.2021 i deres RT#463290.
Navn på bilde/rutine/rapport/annet det gjelder
Søknad samlebilde (SOKNAD_OPPTAKSGRLAG)
Begrunnelse
I ph.d.-opptak er det nødvendig å registrere ett opptaksgrunnlag (typisk én grad) i fanen grunnutdanning. Dette er data som rapporteres for ph.d.-nivå og det er derfor nødvendig at vi får dette registrert og med over i student samlebilde.
Det er i tillegg ønskelig å registrere graden som er grunnlaget for opptaket til master. Dette gjøres i dag i varierende grad, siden fanen krever manuell registrering og er tidkrevende for saksbehandler.
Beskrivelse av problemstilling
Opptaksgrunnlaget registreres manuelt under fanen grunnutdanning, hvilket leder til dårlig datakvalitet. Dette til tross for at de fleste søkerne i de fleste opptak har registrert kvalifikasjoner i intern kvalifikasjonsprotokoll eller i person eksternstudium. Vi forventer i tillegg en økning av kvalifikasjoner i person eksternstudium etter hvert som utenlandsk utdanning også blir delt digitalt fra søkere, via for eksempel Emrex og/ellerErasmus without paper (EWP).
Løsningsforslag
Vi ønsker en løsning som gjør det enkelt for saksbehandler å knytte én (1) grad til søknaden som opptaksgrunnlag. Hvis kun én grad finnes i resultatgrunnlaget, så ønsker vi at denne kommer inn automatisk i opptaksgrunnlaget. Dersom en søker har flere tilgjengelige grader/opptaksgrunnlag ønsker vi for eksempel en knapp for hent kvalifikasjon/grad hvor saksbehandler får et valg om å legge til én enten fra protokoll eller fra person eksternstudium, litt som i legg til intern eller ekstern utdanning i utdanningsplan. Valget må kunne gjøres om, og saksbehandler må også kunne registrere opptaksgrunnlag manuelt for søkere som kun har papirdokumentasjon.
Vurdering av konsekvenser
Lettere for saksbehandler å registrere gode data om opptaksgrunnlag, leder til mer effektiv saksbehandling og bedre datakvalitet, større sikkerhet for søker og bedre statistisk grunnlag for master- og ph.d.-opptak.
Ønske 11/2021 Dokumentkrav til søknadsalternativ
Ønsket av SADM i forbindelse med Utvikling av opptaksmodulen fra ph.d.-opptakspiloten.
Sendt Unit 05.10.2021 i deres RT#463301
Navn på bilde/rutine/rapport/annet det gjelder
Søknadsweb og opptaksmodulen
Begrunnelse
UiO fikk opprettet obligatoriske dokumentkrav til ett opptak i forbindelse med pilotering av ph.d.-opptak i Søknadsweb. Vi ser imidlertid behov for å kunne knytte obligatoriske dokumenter til de enkelte søknadsalternativene også. For ph.d.-nivå kan det være nyttig å ha forskjellige dokumentkrav dersom man for eksempel har ett søknadsalternativ pr. institutt/saksbehandlerenhet under fakultet, men først og fremst er dette et behov for masteropptak, hvor opptakskrav og dokumentkrav kan være svært forskjellig fra søknadsalternativ til søknadsalternativ.
Beskrivelse av problemstilling
I ett opptak kan forskjellige søknadsalternativer ha forskjellige opptakskrav, herunder dokumentkrav. Typisk kan noen søknadsalternativer ha krav om prosjektskisser eller motivasjonsbrev, mens andre ikke har det. Dokumentkrav kan også endres ut fra hvilken søkergruppe søker tilhører, for eksempel språkkrav.
Løsningsforslag
Vi ønsker at det blir utviklet mulighet til å knytte dokumentkrav også til søknadsalternativ.
Ideelt sett, ville vi sett at forskjellige søkerkategorier også blir møtt med forskjellige dokumentkrav: typisk vil norsk/nordisk søker, EU/EØS-søker og søker utenfor EU/EØS være tre hovedkategorier. Men vi ser ikke helt at det er mulig før ny, felles, løsning for masteropptak.
Vurdering av konsekvenser
Tydeligere og mer spisset informasjon til søkere. Økt sannsynlighet for å få fullstendige/komplette søknader. Lettere å følge opp søkere med mangler for saksbehandler.
Ønske 12/2021 Dato levert søknad og forventet svartid
Ønsket av SADM i forbindelse med Utvikling av opptaksmodulen fra ph.d.-opptakspiloten.
Navn på bilde/rutine/rapport/annet det gjelder
Søknadsweb, opptak og søknad samlebilde, samt aktuelle søkerlister, først og fremst 101.014 mottatt dokumentasjon
Opprinnelig RT-id
Kan sees i sammenheng med Unit RT#439710 fra mars 2021
Begrunnelse
I løpende opptak uten felles søknads- og saksbehandlingsfrist, er det nødvendig både for søker og saksbehandler å vite når en søknad er levert for å kunne overholde saksbehandlingsfristen.
Det er i tillegg ønskelig å kunne vise tentativ svardato.
Beskrivelse av problemstilling
Søkere i løpende opptak, som ph.d.-opptak, lurer ofte på når de kan forvente svar. Dersom ikke noe annet er angitt gjelder forvaltningslovens regler (i praksis 3-4 uker). Så langt har vi løst problemstillingen med å informere søkere på nett og i teksten på Søknadsweb, men vi ser at dette ikke er tydelig nok. I tillegg kan det være vanskelig for saksbehandlere å vite hvilke søkere som står for tur da hverken dato for innkommet (fullstendig) søknad eller saksbehandlingsfrist er datofelter i FS.
Løsningsforslag
Vi ønsker et datofelt som viser tidspunkt for innlevert og fullstendig søknad for søker i Søknadsweb og for saksbehandler i FS. Dvs. at dersom opptaket har obligatorisk dokumentkrav, ønsker vi at dato for innlevert søknad = dato for alle obligatoriske dokumenter levert.
Vi ønsker i tillegg at man kan sette generell saksbehandlingstid i antall dager på opptak samlebilde, og at individuell saksbehandlingsfrist regnes ut på bakgrunn av dato fullstendig søknad+generell saksbehandlingstid.
Datofelt for individuell saksbehandlingstid må vises og kunne gjenfinnes på den individuelle søknaden og helst kunne vises for søker i Søknadsweb.
I rapporten 101.014 hadde det vært hensiktsmessig å kunne vise og sortere på dato for fullstendig søknad og saksbehandlingsfrist. Det er da mulig at løpende opptak ikke nødvendigvis må ha regnr for å kunne behandle søknader i riktig rekkefølge.
Dersom det er mulig å få utviklet løsning i FS for saksbehandler, men det ikke er kapasitet i Søknadswebutviklingen, vil vi prioritere å få på plass en løsning som hjelper saksbehandler å sortere saker i riktig rekkefølge.
- pri er altså å få inn dato fullstendig søknad i 101.014 og på søknadsalternativet til den enkelte søker
- pri er å få inn mulighet til å legge inn antall dager saksbehandlingstid i opptak samlebilde og dermed også få beregnet individuell saksbehandlingsfrist for søknadsalternativ i opptaket, og at dette kan vises i 101.014 og på søknadsalternativet til den enkelte søker
- pri er å få vist individuelt beregnet saksbehandlingstid for søker i Søknadsweb
Vurdering av juridiske forhold og henvisning til sentrale og lokale regler
Lettere for saksbehandler å holde kontroll på rekkefølgen av søknader til behandling i løpende opptak, samt overholde saksbehandlingsfrist. Lettere for søker å se om saksbehandlingsfrist er oversittet.
Ønske 13/2021 Fjerne tabellen DRGRAD_FAG
Ønsket av SADM 23.09.2021. Ønsket er støttet av Forum for forskerutdanning (FFF), og av representanter fra UiB og UiA i den gamle ekspertgruppen for doktorgradsmodulen.
Sendt Unit 5. september 2021 i deres RT#463306.
Navn på bilde/rutine/rapport/annet det gjelder
DRKAND_FAG (FAGKODE) – hele tabellen ønskes utfaset
Dersom det fortsatt er ønske om denne type data:
STUDENTOPPGAVE FAGKODE erstattes av STUDENTOPPGAVE NUSKODE
Og/eller STUDPROGSTUD_EMNE tilsvarende OPPGAVETITTEL som NUSKODE
Opprinnelig RT-id/saksdokument dersom saken har vært behandlet tidligere
Ikke tidligere behandlet
Begrunnelse
For ph.d.-nivå er fagkoding en vesentlig del av rapporteringsgrunnlaget. Dessverre har fokus ligget på FAGKODE framfor NUSKODE eller tilsvarende kodeverk for forskning, og det har vært lite fokus på samordning og fellestabeller med øvrige studienivåer. Dette ønsker vi å få bort fra. Målsettingen er å få utfaset så mange særegne tabeller for doktorgrad som mulig og i størst mulig grad bruke tabeller felles med øvrige studienivåer, samt å bruke nasjonalt kodeverk framfor lokale koder, og i størst mulig grad oppnå automatisert overføring av data, framfor å registrere ting manuelt.
Beskrivelse av problemstilling
Våre saksbehandlere på ph.d.-nivå bruker mye tid på å tolke arbeidstitler og prosjektskisser for å registrere fagkode på student samlebilde. Dette registreres, slik vi forstår, kun fordi NIFU ønsker disse dataene i forbindelse med rapportering.
Dataene følger ikke noen nasjonal, eller internasjonal, standard. Detaljeringsnivået er svært varierende, mellom fagområder, og mellom hvor nidkjære i tjenesten saksbehandlere har vært. Datakvaliteten er dermed ikke god, og den statistiske verdien ansees reelt sett å være lav.
Løsningsforslag
Vi ønsker at tabellen DRKAND_FAG sperres for nyregistreringer så snart som mulig, og at tabellen fases ut.
Siden ph.d.-programmene ofte er svært generiske, sier de lite om ph.d.-kandidatenes tilknytning til fagmiljø. Dersom det fortsatt er ønske om å ha data om avhandlingens fagtilknytning, hvilket vi forstår er primærfunksjonen til tabellen, så ønsker vi at dette skal kunne registreres av kandidaten selv på et egnet sted, for eksempel via Studentweb. Vi ser for oss at aktuelle steder dette kan bli registrert i FS i dag er i tabellene STUDENTOPPGAVE og/eller STUDPROGSTUD_EMNE (tilsvarende oppgavetittel), avhengig av hvorvidt dette er data som først er aktuelt ved innlevering av oppgave, eller tidligere i utdanningsforløpet. Da ved å bruke for eksempel nus-kodeverk eller et annet aktuelt standardisert kodeverk for forskning.
I påvente av modernisering av FS, ser vi for oss at opplysning om tilknytning for den enkelte kandidaten i mellomtiden bør kunne hentes ut på annet vis, for eksempel via studieprogramstudent-institusjon-fakultet-institutt-gruppe.
Vurdering av konsekvenser
Mindre manuell registrering, bedre datakvalitet og rapporteringsdata på tvers av studienivåer.
Ønske 14/2021 Fag opptaksgrunnlag drgrad
Ønsket av SADM 23.09.2021. Ønsket er støttet av Forum for forskerutdanning (FFF), og av representanter fra UiB og UiA i den gamle ekspertgruppen for doktorgradsmodulen.
Sendt Unit 5. september i RT#463309.
Navn på bilde/rutine/rapport/annet det gjelder
OPPTAKSGRLAGSOKNAD_DR
STUDPROGSTUD_OPPTAKSGRL
SOKAND_OPPTAKSGRL
Opprinnelig RT-id/saksdokument dersom saken har vært behandlet tidligere
Søknad samlebilde (SOKNAD_OPPTAKSGRLAG) ønske om mer automatisk oppdatering av søknadsgrunnlag, hvor vi ønsker at kvalifikasjoner/grader fra person eksternstudium også skal bli valgbare i hhv søknad opptaksgrl og student opptaksgrl, har noe overlapp med dette ønsket. Se ønske 10/2021 lenger oppe på denne siden.
Begrunnelse
For ph.d.-nivå har fagkoding vært en vesentlig del av rapporteringsgrunnlaget. Dessverre har fokus ligget på FAGKODE framfor NUSKODE, og det har vært lite fokus på samordning og fellestabeller med øvrige studienivåer. Dette ønsker vi å få bort fra. Målsettingen er å få utfaset så mange særegne tabeller for doktorgrad som mulig og i størst mulig grad bruke tabeller felles med øvrige studienivåer, samt å bruke nasjonalt kodeverk framfor lokale koder, og i størst mulig grad oppnå automatisert overføring av data, framfor å registrere ting manuelt.
Beskrivelse av problemstilling
Våre saksbehandlere på ph.d.-nivå bruker mye tid på å registrere fagkode i forbindelse med opptak. Etter kontakt med DBH fikk vi vite at FAGKODE er utfaset til fordel for NUSKODE i opptaksgrunnlaget, men hverken OPPTAKSGRLAGSOKNAD_DR, SOKAND_OPPTAKSGRL eller STUDPROGSTUD_OPPTAKSGRL gjenspeiler dette.
Dersom en saksbehandler går via doktorgradssøknad samlebilde så er OPPTAKSGRLAGSOKNAD_DR FAG et gult felt, og obligatorisk å fylle ut, mens OPPTAKSGRLAGSOKNAD_DR NUSKODE er hvitt, og ikke obligatorisk å fylle ut. Dersom saksbehandler legger dette rett i student samlebilde STUDPROGSTUD_OPPTAKSGRL, som mange gjør, så er ingen av feltene gule/obligatoriske. Det samme gjelder SOKAND_OPPTAKSGRL. Saksbehandler får dermed ingen hjelp, og heller litt villedning, dersom de bruker drgradssøknad samlebilde, når det gjelder å registrere disse dataene.
Løsningsforslag
Vi ønsker primært at tabellen OPPTAKSGRLAGSOKNAD_DR slettes og i sin helhet erstattes av SOKAND_OPPTAKSGRL som fellestabell for opptaksgrunnlagsinformasjon for søkere uavhengig av studienivå. Dersom dette ikke er mulig å gjøre noe med før moderniseringen av FS er i gang, så ønsker vi uansett at FAGKODE-feltene deaktiveres/fjernes fra alle tabellene og at NUS-kode innføres som obligatorisk/gult felt for registrering i alle tabellene slik:
OPPTAKSGRLAGSOKNAD_DR FAGKODE – erstattes av OPPTAKSGRLAGSOKNAD_DR NUSKODE
STUDPROGSTUD_OPPTAKSGRL FAGKODE – erstattes av STUDPROGSTUD_OPPTAKSGRL NUSKODE
SOKAND_OPPTAKSGRL FAGKODE erstattes av SOKAND_OPPTAKSGRL NUSKODE
Vurdering av konsekvenser
Mindre manuell registrering, bedre rapporteringsdata og standardisering på tvers av studienivåer.
Ønske 15/2021 Rapporteringsfelter forskerutdanning
Ønsket av SADM 23.09.2021. Ønsket er støttet av Forum for forskerutdanning (FFF), og av representanter fra UiB og UiA i den gamle ekspertgruppen for doktorgradsmodulen.
Sendt Unit 5. september 2021 i RT#463310
Navn på bilde/rutine/rapport/annet det gjelder
Endring i rapporteringsfelter for forskerutdanning
- STUDIEPROGRAMSTUDENT STATUS_STIPENDIATSTILLING
- STUDIEPROGRAMSTUDENT DATO_STUDIERETT_TILDELT/DRKAND_ARBEIDSFORHOLD_DATO_FRA
- DRGRAD_FAG
Opprinnelig RT-id/saksdokument dersom saken har vært behandlet tidligere
Ønske 13/2021 Fjerne tabellen DRGRAD_FAG har sammenheng med denne saken, hvor vi beskriver mer operative problemstillinger knyttet til DRGRAD_FAG
Begrunnelse
Rapportere på færrest mulig ikke-standardiserte og automatiserte datafelter, med tanke på standardisering og forenkling av registreringer og fs-behov for ph.d.-nivå på sikt.
Beskrivelse av problemstilling
Vi ønsker å endre litt på datautplukket til DBH for ph.d.-nivå, siden vi mener det skal gå an å utlede ønsket informasjon fra andre datafelter enn de DBH får fra Unit pr dags dato. Rent spesifikt dreier det seg i denne omgang om DBH-variablene:
- Vitenskapsdisiplin
- Stipendiatstilling
- Dato for finansiering
Vi ser behov for det siden saksbehandlere da, slik vi ser det, kan spare noen dobbeltregistreringer, og det vil også sette institusjonene i stand til å gjenbruke data til andre formål enn rapportering, for eksempel ved tilgangsstyring og brukerkontotildeling.
Løsningsforslag
Vitenskapsdisiplin hentes i dag fra DRGRAD_FAG som vi ønsker utfaset. Primært tenker vi at det ikke er behov for å registrere disse dataene i det hele tatt, men sekundært tenker vi at den i så fall må erstattes av standardkoder for studier (NUS) eller tilsvarende innen forskningsområdet, knyttet til kandidatenes innleveringer som skissert i et annet innmeldt ønske.
Stipendidatstilling hentes i dag fra STUDIEPROGRAMSTUDENT STATUS_STIPENDIATSTILLING, men vi tenker at informasjon om dette er en kandidat med tilsetting ved samme institusjon som tilbyr utdanningsprogrammet og ph.d.-graden (stipendiat), eller en eksternfinansiert kandidat, kan utledes fra institusjonskode studieprogram=institusjonskode arbeidsgiver i finansieringen (DRKAND_ARBEIDSFORHOLD INSTITUSJONSNR_ARBEIDSGIVER), ev. med merinformasjon av finansieringstype (FINANSKILDEKODE) ved behov.
Dato for finansiering hentes overraskende nok i dag fra STUDIEPROGRAMSTUDENT DATO_STUDIERETT_TILDELT, altså studierettstarten, men dataene burde hentes fra finansieringsfanen DRKAND_ARBEIDSFORHOLD_DATO_FRA.
Hovedgrunnen til dette er at vi ellers er tvunget til å sette studierettstart=finansieringsstart for å få riktige rapporteringsdata. Dette hindrer oss i å bruke studierettstartsdato til andre formål, for eksempel å kunne sette en standard startdato for flere kandidater av gangen ved opptak slik at kandidatene kan få brukerkonto som studenter tidligere enn finansieringsstart, slik at de kan bruke Studentweb til å registrere seg på emner før de faktisk begynner på utdanningsløpet. Dette vil igjen potensielt kunne gjøre det enklere for oss å gi riktige tilganger til kandidatene, slik at disse er på plass og aktive til finansieringsstart på sikt.
Vurdering av konsekvenser
Mindre dobbelregistrering, bedre rapporteringsdata, og muliggjøre gjenbruk av data til andre formål enn rapportering.
Ønske 16/2021 Studieretning under "Perm" i Student samlebilde
Konklusjon 12.11.2021: Ønsket blir ikke sendt til Unit. HF klarer seg med kull/klasse-utplukket i rapport FS290.001 og ikke trenger eget utplukk for studieretning.
Ønsket av HF 23.09.2021 i RT#4561306
Problemstilling
HF har behov for å kunne registrere studieretning når vi registrerer permisjon i fanen "Perm" i Student samlebilde. Som en følge av dette ønsket, ønsker vi også muligheten til å kunne velge studieretning i rapporten FS290.001 Innvilgede permisjoner.
Det er primært to grunner til at vi ønsker å kunne registrere permisjon på studieretningsnivå:
- Vi har studenter som har opptak til to ulike studieretninger på samme program samtidig. I en del av disse tilfellene søker studentene seg inn på studieretning nr. 2 kort tid før de gjør seg ferdig med studieretning nr. 1. Og det hender da at studentene søker permisjon fra studieretning nr. 2 for å fullføre studieretning nr. 1. Når vi skal registrere permisjon, er dette bar mulig å registrere på programnivået selv om permisjonen bare skulle registreres for og omfatte den ene studieretningen. Dette skjer bla. ved at endringen av studentstatus fra AKTIV til PERMISJON automatisk gjøres for begge studieretningene. Tilsvarende at nattjobben som endrer utløpt permisjonsperiode fra PERMISJON til AKTIV endrer på begge studieretningene.
- På flere av de største programmene våre er det ulike studiekonsulenter som har ansvar for de ulike studieretningene. Det vil derfor være mer hensiktsmessig at de kan registrere permisjonen for den studieretningen de administrerer, samt at de kan hente ut oversikt over innvilgede permisjoner på egen studieretning og ikke for hele programmet.
I dag får vi ikke egentlig løst problemet med at studenter skal ha permisjon fra én av to studieretninger de har opptak til. En løsning er å skrive inn en merknad med informasjon om hvilken studieretning permisjonen gjelder, men det krever at man fanger opp dette manuelt.
Studiekonsulentene kan i dag finne fram til aktive permisjoner på egen studieretning via andre rapporter som både angir studieretning og permisjon (f.eks. FS301.010 Studenter i studiekull), men vi kjenner ikke til at man kan få oversikt over ikke-aktive permisjoner på studieretning. De må dermed gjøre dette manuelt.
Løsningsforslag og hvordan dette kan lette arbeidet
Et felt med nedtrekksmeny for studieretning i fanen "Perm" i Student samlebilde og i rapporten FS290.001 Innvilgede permisjoner.
Dette vil kunne forbedre arbeidet med permisjonsregistrering for studenter med opptak til to studieretninger og permisjon på den ene av dem. Da vil permisjonen kunne registreres på riktig måte, slik at permisjon kun gjelder for den aktuelle studieretningen og ikke feilaktig for begge studieretningene studenten går på. Det vil også gjøre det enklere å holde oversikt for de studiekonsulentene som administrerer en studieretning, og mindre behov for manuelt arbeid.
Vurderering av ønsket lokalt
Ønsket er ikke diskutert i et større forum på HF, men det er generelt et tilbakevendende tema at instituttene i større grad ønsker å kunne hente ut informasjon på studieretningsnivå.
Vurdering i Avdeling for studieadministrasjon (SADM)
Et betimelig ønske i og med at UiO har flere store studieprogrammer med mange studieretninger med mange studenter og mange ansatte å fordele arbeidet på. Se også RT#4546664 der dette osgå kan få konsekenser for gradfangsten.
SADM vurderer det imidlertid slik at antallet studenter problemet omfatter ikke er mange nok til å forsvare nye felter i FS med tilhørende funksjonalitet og rapport. SADM har brukt FS265.002 "Studenter med flere studieretter" for å finne tall, og det ser ut til å dreie seg om opptil to studenter på HF høsten 2021. Problemet bunner i store programmer med mange studieretninger fremfor flere mindre studieprogrammer. Denne problemstillingen finnes det nok ikke entydige gode løsninger på per i dag.
Tilbakemelding fra HF på SADMs vurdering
HF mener likevel at det ville vært hensiktsmessig å få fikset problemet siden det rett og slett blir feilregistreringer. Men har forståelse for at dette ønsket ikke prioriteres.
Når det er sagt, meldte vi også inn en annen årsak til at vi ønsker endringen. Ved HF har ulike studiekonsulenter ansvar for ulike studieretninger innenfor samme program og at det derfor vil være mer hensiktsmessig at de kan registrere permisjonen for den studieretningen de administrerer. Men nyttigere vil det nok være å kunne hente ut oversikt over innvilgede permisjoner på egen studieretning og ikke for hele programmet. Det krever muligens ikke et
nytt felt for studieretning under fanen "Perm" i Student samlebilde, men det vil kreve et felt med nedtrekksmeny for studieretning i rapport FS290.001. Men dette er kanskje heller ikke omfattende nok (det er kanskje bare HF dette er aktuelt for?) til å prioritere å melde videre et ønske om endring av FS290.001?
Ønske 17/2021 Nytt felt for pensumliste i und.enhet og und.aktivitet
Ønsket av SADM 6. oktober 2021.
Hvilken del av FS gjelder endringsønsket for?
FS-klienten og integrasjon (FS-API)
Beskrivelse av behovet som skal dekkes eller problemet som skal løses
USIT v/UiO skal lage en Leganto-integrasjon, som overfører undervisningsenheter og undervisningsaktiviteter fra FS til Leganto, UiOs pensum- og litteraturlistesystem.
Denne integrasjonen trenger et flagg som angir om emnets undervisningsenhet og/eller undervisningsaktivitet skal overføres til Leganto. Vi trenger å kunne angi at studenter på ulike undervisningsaktiviteter kan ha ulikt pensum i tillegg til et felles pensum for alle på undervisningsenheten.
Vi kan ikke dra nytte av feltene på arkfanen Pensum på Emne samlebilde da vi for det første ikke skriver inn pensumlisten i FS (men i det separate pensumsystemet), og for det andre trenger vi å kunne skille på ulikt pensum knyttet til ulike undervisningsaktiviteter og knyttet til hver enkelt student. Av samme grunner kan heller ikke dra nytte av info-teksten Pensum.
Løsningsforslag
Vi trenger et J/N-felt for pensumliste i Undervisningsenhet samlebilde og Undervisningsaktivitet samlebilde som kommer frem i relevante endepunkt i FS-APIet.
Med et slikt felt vil integrasjonen ha et flagg som kun overfører undervisningsenhetene og undervisningsaktivitet som skal ha egen pensumliste.
Hvor viktig er endringen for din institusjon?
Svært viktig
Hvilken verdi/gevinst vil endringen gi for din institusjon?
Et slikt pensumfelt er avgjørende for å kunne utvikle integrasjonen mellom FS og Leganto.
I dag overføres langt flere undervisningsenheter til Leganto enn hva som trengs, og så må man ta en ryddejobb i etterkant av overføringen. Et pensum-felt i FS vil derfor være tidsbesparende for alle som administrerer pensumlister i Leganto.
Tror du at endringen får konsekvenser for andre institusjoner? Hvis ja, beskriv de antatte konsekvensene.
Et slikt pensumliste-felt i FS er uavhengig av Leganto, og kan derfor nyttiggjøres av alle institusjoner, uavhengig av hvilket pensumsystem som benyttes.
Ønske 18/2021 Historikk poenggrensene i opptaksrundene og statistikk
Status 08.11.2021: Løst i FS8.4 med nye hist-tabeller for Kvote og Kvoterunde. Disse vil fylles ved kjøring av FS180.001 Overføring til historikk.
Ønsket av SADM 22. oktober 2021. Sendt Unit 25.10.2021 i deres RT#464427.
Gjelder FS-klienten og Tableau (statistikk)
Beskrivelse av behovet
Vi har behov for å kunne lage rapporter i Tableau som viser historikk på poenggrenser for lokalt masteropptak. Per nå finnes det kun poenggrenser for inneværende opptak i FS og Tableau.
Når et lokalt opptak kjøres, blir poenggrensene registrert for hver enkelt studietype i opptaksrundene i kvotebildet. Disse opptaksrundene blir slettet når det klargjøres for nytt opptak. Når opptaksrundene slettes, slettes også poenggrensene for alle studietypene i opptaket. Dette medfører at vi ikke har mulighet til å lage oversikter i Tableau over utvikling i poenggrenser over tid uten at vi lagrer poenggrensene på annet vis før opptaksrundene for aktuelt opptak slettes.
Løsningsforslag
At poenggrensene i opptaksrundene blir lagret i historikk for aktuelt opptak i FS, slik at det kan hentes ut historikk på poenggrenser i Tableau. Vi er usikre på hvordan dette best kan løses. Vi kjører en rutine for å slette opptaksrunder (160.005). Kan det legges inn et valg om historikkoverføring i denne rutinen?
Eventuelt at det blir mulig å kjøre også opptaksrundene til historikk når et opptak kjøres til historikk?
Eller er det mulig å løse dette på en annen måte?
Kommentar: Vi gjenbruker studietypenummer for masteropptaket, dvs. at hvis et studieprogram legges ned, kan det samme studietypenummeret bli brukt for et nytt studieprogram. Opptaket blir kjørt til historikk før vi eventuelt gjenbruker studietypenummer.
Hvor viktig er er ønsket på skalaen svært viktig, viktig, litt viktig, ikke veldig viktig?
Viktig
Hvilken verdi/gevinst vil endringen gi for UiO?
Mulighet til å lage oversikter i Tableau over utvikling i poenggrenser over tid også for lokale opptak.
Tror du at endringen får konsekvenser for andre institusjoner?
Ja, at de andre institusjonene kan dra nytte av det samme statistikkgrunnlaget på sin institusjon.
Ønske 19/2021 Studentnummer i FS525.002 Kontroll av manglende sem.reg/studkomp
Løst i FS8.3.7 (senhøst 2021). Studentnummer kommer som standardisert del av rapporten, og ikke som visningsvalg.
Ønsket av MF i RT#4596112, 18. oktober 2021, bearbeidet av SADM. Sendt Unit 28.10.2021 i deres RT#464666.
Ønsket gjelder FS-klienten
Beskrivelse av behovet
Vi trenger studentnummer i FS525.002 Kontroll av manglende sem.reg/studkomp. Rapporten har i dag kun valg for fødselsnummer eller fødseldato, hvilket gjør det mer arbeidskrevende dersom vi trenger å kommunisere om studenter til andre saksbehandlere.
På UiO skal vi ikke sende fullt fødselsnummer (11 siffer) i e-post, verken i emnefeltet, inne i e-posten eller som vedlegg da det ikke er noen sikkerhetsforskjell mellom disse. Dette følger både av personvernforordningen artikkel 32 Sikkerhet ved behandlingen, UiOs interne reglement om elektronisk kommunikasjon punkt 6 og Datatilsynets veileder for behandling av fødselsnummer. Dersom et fødselsnummer skal sendes i e-post skal det krypteres. Vi velger å holde dette prinsippet også i intern kommunikasjon på UiO, for å oppmuntre til gode vaner ved behandling av personopplysninger, selv om noen av kommunikasjonstjenstene våre er krypterte.
Studentnummer sikrer identifikasjon av riktig person, ev. sammen med navn. Når rapporten ikke viser studentnummer, utgjør det å finne frem til studentenes studentnummer et ekstra steg i arbeidsprosessen, som burde være overflødig.
Løsningsforslag
Studentnummer som visvalg i FS525.002 Kontroll av manglende sem.reg/studkomp., inklusive ved lagring av datafil.
Vi ønsker generelt at studentnummer er et mulig valg i alle rutiner og rapporter.
Hvor viktig er er ønsket på skalaen svært viktig, viktig, litt viktig, ikke veldig viktig?
Litt viktig