Kommentarer til kravspesifikasjon

Kommentarer til kravspesifikasjon

1 Innledning Universitets- og høgskolesektoren(uh-sektoren) har gått sammen om anskaffelse av rekrutteringssystem. Prosjektet har 26 rettighetshavere. Prosessen eies og drives av UNINETT AS på oppdrag fra rettighetshaverne. Flere av rettighetshaverne har eller har hatt egne systemer for rekruttering, men ønsker å delta gjennom denne felles anskaffelsen for så på kortere eller lengre sikt ta i bruk systemet. De 26 virksomhetene som har meldt sin interesse for å kunne gjøre avrop på nytt system er spredt over hele Norge. 1.1 Besvarelse av kravspesifikasjonen Dokumentene som ligger til grunn for anbudsprosessen er i tillegg til standardavtalen for Staten (Del 2), følgende: Kravspesifikasjon, inkludert beskrivelser Kravspesifikasjonen er delt i to hovedområder: A: FUNKSJONALITET B: TEKNISKE KRAV OG INTEGRASJONER I hvert delkapittel, beskrives krav til leveransen som skal besvares JA/NEI/. Kravene er gradert som SKAL eller BØR. I tillegg følger en oversikt over de punkter som krever skriftlige beskrivelser fra leverandør. Disse ønskes gjerne levert i ett dokument, med tydelig merking på hva som er besvart hvor. Dette er beskrevet i arkfanen «BESKRIVELSER» C: BRUKERVENNLIGHET Det vil i vurderingen av tildelingen foretas en brukertest med et utvalg av de påmeldte institusjonene. Dette er beskrevet i kravspesifikasjonen. Med brukervennlighet mener vi blant annet: Enkle fremgangsmåter / få klikk for å komme til ønsket funksjonalitet Intuitive menyer Likhet i skjermbilder på tvers av funksjonalitet God tilrettelegging for effektive arbeidsmetoder i verktøyet Kommentarer til kravspesifikasjonen (dette dokumentet) Dokumentet tar for seg en dypere forklaring på kravene i kravtabellen. Vi har tatt med en del generelle betraktninger, og også forsøkt å flette inn tilbakemeldinger fra høringsrunde som har vært blant rettighetshaverne, og som kan gjøre avrop på rammeavtalen når den foreligger. Dokumentet er delt inn etter de samme hoved- og delkapitler som kravspesifikasjonen. 2 Generelle krav til leverandør og system 2.1 Lover, regelverk og juridiske bestemmelser Alle rettighetshaverne er statlige institusjoner som til enhver tid må følge lover og regelverk som vedtas. Det forventes at leverandør har oversikt over gjeldende lovverk og implementerer endringer løpende. 3 Overordnete krav

Nedenfor følger kommentarer til krav til funksjonalitet, og tekniske krav og integrasjon, inndelt etter kravene i kravspesifikasjonen (vedlegg 1). 3.1 Funksjonalitet Rekrutteringsverktøyet (REKV) skal være en essensiell del av rekrutteringsarbeidet for de omfattede virksomheter. Det skal gjøre det enkelt og effektivt for brukere, administratorer og interessenter i UH-sektoren å gjennomføre aktivitet knyttet til rekruttering, samt gjøre det enkelt for søkere å finne utlysningen og gjennomføre søknadsprosessen. For søkere skal det være enkelt og intuitivt å logge inn, fylle ut søknad og legge ved all nødvendig og ønskelig vedlegg og informasjon. 3.1.1 Søkerprofil I denne delen skal systemet gi søker mulighet å velge målform eller språk for både søknaden og for videre kommunikasjon fra arbeidsgiver. Det er ønskelig å tilby følgende: Bokmål, nynorsk og engelsk. De to første målformene er påkrevd å skal tilbys ved norsk offentlig saksbehandling, og engelsk er nødvendig for å gi søkere med utenlandsk bakgrunn mulighet å søke stillinger hos virksomhetene. Med «Portable CV» menes et system hvor søker kan ta med seg sin CV fra en system over til andre systemer. Funksjonaliteten ønskes bygget på HR-XML og opprettes slik at at søker skal kunne gjenbruke sine CVer på tvers av leverandører av CV-databaser og rekrutteringssystemer. Mulighet å overføre CV-data fra søkers LinkedIn-profil til søknadsskjemaet i systemet er også en funksjonalitet som er ønsket og som er framtidsrettet og tilrettelegger for smidig bruk av denne type sosiale medier inn i rekrutteringsprosessen. Varsler om ledige stillinger i virksomheten er ønskelig, det må kunne bestilles og sendes til e- postadresse spesifisert av søker. 3.1.2 Søknadsregistrering Åpne søknader er etter hvert blitt mer vanlig å bruke innen offentlig sektor, og muligheten for å definere parametere for pre-screening av søkere med hvilke felter som skal fylles ut, er viktig funksjonalitet for saksbehandlingen. Eksempler som ønskes som forhåndsdefinerte alternativer er virksomhetens hjemmeside, finn.no, nav.no, LinkedIn med flere. Virksomhetene er i stadig økende grad opptatt av synliggjøring i sosiale medier. 3.1.3 Vedlegg Bruk av store vedlegg er vanlig i en søknadsprosess, søker kan for eksempel ha vitnemål, publikasjoner, artikler og attester samlet i en fil og må ha mulighet til å legge ved denne. Det er her ønskelig å kunne sette krav til hvilke dokumenttyper som kan legges ved søknader. 3.1.4 System og brukerdokumentasjon For administratorer skal det være enkelt å planlegge, administrere og gjennomføre hele rekrutteringsprosessen i og med REKV. Dette innebærer å gi ønskede tilganger til rekruttere, ledere og interessenter så som utvalg- og komitemedlemmer som skal ha innsyn i enkeltprosesser. 3.1.5 Rekrutteringsarbeid

For omfattende prosesser (rekrutteringsprosjekter) må det være mulig å bruke systemet til prosjektstyring av disse. I rekrutteringsarbeidet er mulighet for skriveregler ved opprettelse av nytt prosjekt viktig for å sikre fast, søkbar oppbygging. Det betyr at alle pågående og historiske rekrutteringssaker registreres med informasjon som er søkbar. 3.1.6 Maler Registrering av egendefinerte maler i hvert trinn i rekrutteringsprosessen ønskes. 3.1.7 Kunngjøring For brukere som skal lyse ut stillinger, vil utlysning skje i systemet, og de skal derfra kunne publisere på både naturlige interne og eksterne nettsteder, samt på epostlister. Det må kunne lenkes direkte til den aktuelle utlysningen. Ekstern kunngjøring ivaretas som beskrevet i systemet. Intern kunngjøring skal også ivaretas i systemet, uten at den er synlig eksternt. 3.1.8 Rekrutterer registrerer søknad Rekrutterer skal ha frihet til å registrere endringer og legge til opplysninger for søker etter søknadsfristen og manuelt legge inn søknad på vegne av søker. Det kan ofte forekomme at søkere henvender seg til rekrutterer for å gi mer opplysninger til søknaden etter at søker har sendt søknad. Det kan også forekomme at søkere blir forhindret fra å søke innen søknadsfrist, og kontakter virksomheten om tillatelse til å søke etter frist. 3.1.9 Kommunikasjon med søkere I henhold til offentlighetsloven har søker krav på å kunne be virksomheten om å sende utvidet søkerliste til stillingen som er søkt. Kommunikasjon gjennom e-post er forutsetning, det samme er bruk av kalenderfunksjon i Outlook ved innkalling av søkere til intervju. 3.1.10 Søkerlister og rapporter Offentlighetsloven gir også søker rett til å se søkerliste, foruten søkere som har valgt og fått innvilget reservasjonsrett mot oppføring. Funksjonalitet for å definere innhold i kandidatrapport med informasjon om søker er viktig for rekrutteringsprosessen. Det er viktig med gode muligheter for å lage egne rapporter/spørringer blant søkerinformasjonen, blant annet for å oppfylle rapporteringskrav fra offentlige myndigheter. 3.1.11 Gjenbruk og sletting av brukerdata En viktig forutsetning er automatisert avvikling av søkerdata og profil når en stilling er besatt og søker ikke ønsker at opplysninger beholdes. Mulighet for søkere til å søke andre stillinger fra en søkbar CVdatabase er arbeidsbesparende for både søker og virksomhet. 3.1.12 Vurdering og rangering av søkere Systemet bør understøtte parameterisert sortering og filtrering. Mulighet for kommentarer på søkere i utvalgsprosessen er viktig for å sikre samarbeid og flyt mellom aktørene som er med på å velge ut. 3.1.13 Arbeidsflyt og varsler Automatisk arbeidsflyt sikrer en smidig og strømlinjeformet rekrutteringsprosess. Det er ønskelig at leverandør beskriver mulighetene for styring av manuell og automatisk arbeidsflyt. Det er viktig at ulike

aktører i virksomhetene har mulighet til å ha ulike innstillinger til arbeidsflyt, og at dette kan defineres av systemadministratorer. 3.2 Tekniske krav og integrasjon Nedenfor følger forutsetninger til tekniske krav og integrasjoner. 3.2.1 Integrasjoner UH-sektoren er i ferd med å rulle ut saksbehandlings- og arkivsystemet Public 360. Integrasjon mellom rekrutteringssystemet og Public 360 er avgjørende for å oppnå de gevinster som sektoren er ute etter. Dette må være på plass til produksjonssetting. Programmeringsgrensenitt (API) tilgjengeliggjøres for integrasjon med andre systemer. Teknologi/protokoller, autentiseringsmetoder, event-basert integrasjon dokumenteres. Det er et ønske at systemet har et fleksibelt integrasjonsgrensesnitt som er i stand til å utveksle data på flere områder. 3.3 Tekniske krav og sikkerhet For deltakerne som tilhører universitets- og høgskolesektoren er det et felles system for pålogging, FEIDE, som driftes av UNINETT. Deltakerne utenfor UH-sektoren vil bruke det nye systemets egen autentiseringsmekanisme for pålogging (for eksempel LDAP, RADUS eller AD). Opprettelse av brukere vil også foregå via FEIDE for de som har felles drift i sektoren i dag, mens for de andre må programmet ivareta automatisk oppretting fra lokal BAS. Informasjonssikkerhet Leveransen skal tilfredsstille regulatoriske krav, og dette er et område som vi forutsetter at leverandøren håndterer på en tilfredsstillende måte. Informasjonssikkerhet er et område som vi mener at leverandøren har et ekstraordinært ansvar for å ivareta. Arbeidet med informasjonssikkerhet setter krav både til leverandørens organisasjon, rutiner og utvikling i systemet. Det vil være krevende, samt gi oppdragsgiver betydelige merkostnader for å få verifisert at leverandør og system har ivaretatt informasjonssikkerheten på en god nok måte. Disse forholdene tatt i betraktning har leverandøren et utvidet krav til å informere kunden om kjente feil, sikkerhetsproblemer eller andre forhold som kan påvirke kundens bruk av funksjonalitet i systemet negativt. 3.3.1 Systemet som driftet tjeneste (SaaS) Løsningen skal driftes av leverandøren, som en driftet tjeneste (SaaS, software as a service). 3.3.2 Innføringsstøtte og opplæring Det er avgjørende for anskaffelsesprosjektet at vi ivaretar en hurtig innføring av det nye systemet. Innføringsstøtte og opplæring er to faktorer som vi legger stor vekt på skal fungere godt, både i utrullingsfasen og i driftssituasjon. Mulighetene for kurs er viktige; en til en, en til mange, felles for flere deltakende institusjoner, webbasert, videobasert mm. I pilotfasen ønsker vi å samle aktuelle brukere fra pilotene til opplæring delt inn etter funksjoner/roller. Her er det ønskelig med tilbud på både webbasert opplæring og en felles opplæringssesjon. Oppdragsgiver tror at det å samles til opplæring også har en god effekt i forhold til erfaringsutveksling, og det er spesielt nyttig i en oppstartsfase. Oppdragsgiver ønsker tilbakemelding på hvordan leverandør ser for seg en utrullingsfase for prosjektet. Tidligere har vi startet med pilotinstitusjoner som først har testet nytt system, endringer

ol. Videre er deltakerne delt inn i puljer, og utrulling har tatt tid. Vi imøteser leverandørens tanker om hvorvidt dette kan gjøres på en mer effektiv måte, evt. om det vil være dette som er den beste løsningen. Prosjektet har klare formeninger om at vi ønsker piloter og utrulling i puljer, men finnes det andre fullgode systemer, er vi lydhøre for det. Konsulentbistand må kunne ytes innen rimelig tid til samtlige deltakere i prosjektet, uansett størrelse og geografisk plassering. 3.3.3 Support Support (brukerstøtte) har to målgrupper: En for søkerne og en for saksbehandlere. Viktig for oss er at support er tilgjengelig utover arbeidstid (at leverandør har vaktordning). Vi legger også vekt på hvordan leverandør deler informasjon om brukerstøttesakene de registrerer hos seg. Enkel tilgang til oversikter for feilmeldinger og systemer på feilene i webbaserte system/portaler er ønskelig. 3.3.4 Dokumentasjon Et viktig moment for oss er at brukerdokumentasjon alltid gjøres tilgjengelig. Det gjelder både kursdokumentasjon og dokumentasjon til hvordan systemet fungerer/forklaring på konfigurasjon ol. En forklaring på konsekvenser ved forskjellige konfigurasjonsvalg er også ønskelig.