Behovsanalyse

Hva kan RT brukes til? Og hva bør det ikke brukes til?

Versjon 2012.03.19

Bakgrunn

Direkt oversatt dreier Request Tracker seg om et verktøy for "sporing av henvendelser". Vi bruker for det meste "sak" for "request". Dessuten ser man snart at RT dreier seg om behandling av saker, og ikke bare "sporing". Her skal vi se på hvilken type saker, og hva slag saksbehandling, RT er egnet for. Og hva RT eventuelt ikke er så godt egnet for.

Før RT tas i bruk på nye områder ved UiO bør det for hver ny kø vurderes om RT er egnet for formålet. Hensikten med dette dokumentet er å bidra ved vurderingen av potensielle nye anvendelser av RT ved UiO. På den måten håper vi å sørge for at RT tas i bruk på områder der det er godt egnet. Og hindre at RT tas i bruk på områder det fins bedre alternativer.


Saksbehandling i offentlig sektor

Siden UiO er et statlig organ må man være spesielt oppmerksom på reglene for saksbehandling i offentlig sektor (etter forvaltningsloven og offentlighetsloven: Lov om behandlingsmåten i forvaltningssaker av 1967-02-10 nr 00, og Lov om offentlighet i forvaltningen av 1970-06-19 nr 69). RT tilfredsstiller ikke disse reglene. RT arkiverer selvfølgelig alle saker med tilhørende dokumenter, men ikke i en form som tilfredsstiller kravene i Noark-standarden. Og journalføring iht samme standard mangler helt i RT.

Vi har ikke undersøkt om RT i kombinasjon med andre verktøy eller manuelle rutiner, kan tilfredsstille kravene i nevnte standard og regelverk. Men vi anser dette for å være lite aktuelt, særlig fordi RT tildels mangler verktøy for å overføre saker til andre systemer. Derfor fraråder vi å bruke RT til behandling av saker som kan falle inn under reglene for offentlig saksbehandling.

Det bør utarbeides rutiner for hva man gjør dersom RT mottar en sak som iht dette ikke bør behandles i RT. Det bør være saksbehandlernes (ikke kundens) ansvar å overføre saken til rette instans/system og deretter avslutte/slette saken i RT.

Mottak av saker

RT er best egnet for saker som kommer i form av e-post til RT. Saker kan eventuelt også opprettes direkte i RT, av kunden selv, eller av saksbehandler på veine av kunden (eventuelt uten å bruke e-post). Men RT er uegner om det er en saksbehandler som vil ta initiativet til en sak ny sak overfor en eller flere kunder. Rollene som kunde og saksbehandler er klart assymtriske i RT

RT har ikke hjelpemidler for å håndtere telefonhenvendelser, hverken tale eller SMS ol. Den som kommer med en telefonhenvendelse må eventuelt få hjelp av en saksbehandler for å få saken inn i RT. RT er derfor uegnet til mottak av store mengder telefonhenvendelser. Det samme gjelder andre muntlige henvendelser.

Saksdefinisjon og -vedlegg

RT egner seg best for spørsmål og problemstillinger som kan beskrives forholdsvis kort og greit i tekstlig form, der man normalt forventer at saken kan avsluttes med et klart svar.

Både ved etablering og senere henvendelser kan saken vedlegges filer, men disse bør være av begrenset omfang/antall. Vedleggene lagres sammen med resten av saken, og stort volum kan ha ugunstig virkning på svartidene i arbeid med saken og hele køen. I likhet med e-postsystemet til UiO har man for RT satt en øvre grense på 10 MB for vedlegg. Et bra alternativ til vedlegg er å lagre dokumentet på et tilgjengelig sted og så sende en peker til dette, et opplegg for slikt finner du i tjenesten UNINET FileSender.

Saker som krever aksjon

E-postlister brukes både i saksbehandling og for distribusjon av felles informasjon til de som står på lista. Når e-postlista erstattes med en RT-kø er det sistnevnte ikke aktuelt. RT egner seg ikke så bra til oppslagstavle og orienteringssaker.

Tids- og ressursavgrensning

RT er beregnet på engangssaker som normalt kan avsluttes på forholdsvis kort tid med begrenset bruk av ressurser. Og RT brukes helst ikke til løpende eller periodiske arbeidsoppgaver. Det blir galt dersom en sak i RT krever ressurser på linje med et lite prosjekt. Normalt kan hver enkelt sak håndteres av én saksbehandler. Det er enkelt å skifte saksbehandler i RT, men det fins ikke verktøy i RT for å håndtere flere samtidige saksbehandlere på en enkelt sak.

Ingen fast saksgang

Med RT får man ingen faste saksgang. Dessuten har man i RT ingen muligheter for å sette opp og håndheve faste rutiner for saksbehandling. For hver enkelt sak avgjør saksbehandleren hvordan saken skal behandles. Alle rutiner for behandling av saker må håndteres manuelt utenfor RT. Det betyr at RT ikke er egnet det hvor man bør ha faste rutiner for saksbehandlingen. RT har i seg selv ikke verktøy for å sikre jevn kvalitet på saksbehandlingen eller for å oppnå likebehandling av beslektede saker.

Antall saker og køer

Antall nye saker pr kø pr uke bør begrenses både oppover og nedover. Erfaring ved UiO antyder at over 100 nye saker pr uke på én kø er håndterbart. Blir det veldig mye mer bør man antakelig vurdere om trafikken kan spres på flere køer. Går det flere dager i snitt mellom hver ny sak, bør man vurdere om en e-postliste er tilstrekkelig for å håndtere sakene. Ellers kan antall køer bli så stort at det ikke er enkelt å håndtere i RT.

UiO har nå (mars 2012) totalt 650 000 saker i RT (de fleste avsluttet), fordelt på 225 køer, uten at dette antallet i seg selv er noe problem.

Konfidensielle saker

RT inneholder ikke personopplysninger eller konfidensiell informasjon ut over det som eventuelt ligger i de enkelte saker i køene. For en gitt kø kan man i RT sette opp en gruppe saksbehandlere slik at bare disse får adgang til å se sakene i køen. På den måten kan man få en kø som er beregnet på konfidensielle saker. USIT har tatt i bruk dette opplegget, men vi har ikke undersøkt grundig hvor sikkert dette opplegget i RT egentlig er. Derfor vil vi inntil videre anbefale forsiktighet ved behandling av konfidensielle saker i RT, selv om vi ikke har grunn til å tvile på opplegget til RT.

RT har ikke muligheter for å begrense tilgangen til enkeltsaker ut over de muligheter som ligger på kønivå. Det samme gjelder vedlegg til saker.

Ordrebehandling

RT egner seg i utgangspunktet ikke for behandling av henvendelser av type ordre/bestillinger. Grunnen til dette er at RT ikke har funksjonalitet for håndtering av lager, leveranser, fakturering og annet som trengs for ordrebehandling. Deler av dette kan muligens håndteres med egendefinerte datafelt i RT, men det vil antakelig ikke kunne bli en tilfredsstillende løsning på sikt.

 

Av torstsk
Publisert 15. juni 2010 16:54 - Sist endret 8. jan. 2015 11:30