Forsøg på at forbedre service for vores brugere sker ikke fra den ene dag til den anden. Efter at der er holdt adskellige møder for at lave forslag til en bedre måde at gøre tingene på, og disse forslag er vedtaget, er der stadig lang vej.

Nye rutiner skal implementeres, vaner skal udryddes og så er det jo menneskets natur at holde fast ved det gamle, det kendte og i mange tilfælde det som man er tryg ved. Det gælder såvel hos brugerne, der af gammel vane henvender sig direkte til dem de er vandt til, men også hos de medarbejdere der skal servicere brugerne. Dels er der det med at finde den rette måde, dels at huske at nu gør vi det må en ny måde, men også i mange tilfælde at se det fornuftige i at tingene nu tager længere tid. For en periode i hvert fald.

Bl.a. kan servicemedarbejderen ikke lige lave en hurtig ændring af systemet, for det kan i yderste konsekvens påvirke andre systemer i stor negativ retning, så det tager længere tid at undersøge afhængigheder, dokumentere ændringen, og foretage de nødvendige tests på test-systemer, inden en ændring føres ud i livet og implementeres på produktionssystemerne.

Det kan også være svært at forstå at man skal dokumentere hvad der kan synes som hver lille detalje man laver. Men i mange tilfælde sparer det tid, fordi man ofte skifter mellem opgaverne, f.eks. mens man venter på svar fra brugeren eller en leverandør, og ikke hele tiden kan huske hvor langt man nu lige kom med en opgave, og det sparer også tid hvis en anden servicemedarbejder overtager en opgave, og ikke skal stille brugeren de samme spørgsmål eller undersøge de samme ting, som forgængeren allerede har spurgt om eller undersøgt, fordi det står i sagen.

Men det er også svært for brugeren at se det fornuftige i at man ikke lige kan få svar på et simpelt lille spørgsmål. For ofte tager dét, som umiddelbart synes som et simpelt lille spørgsmål, en del tid at undersøge svaret på. Det er nemlig ikke alt der lige er paratviden. Og det tager tid fra andre opgaver.

En af de andre opgaver kan f.eks. være et system med måske 300-400 brugere eller mere, som benyttes konstant, men som der nu er fejl på. Det er et vigtigt system (urgency) og det har stor indflydelse (impact), mens dét som brugeren henvender sig om, måske kun benyttes lidt en gang imellem eller kun af meget få brugere.

Derfor behandler vi sagerne i en prioriteret rækkefælge. Hver sag får en prioritet ud fra urgency og impact, og sammenholdt med den rækkefølge sagerne kom ind har sagerne derfor en deadline, altså en dato for hvornår de bør være løst.

Det betyder ikke at man ikke får sit problem løst hvis man har et problem der er mindre vigtig eller har færre brugere end andre. For som nævnt har det også indflydelse hvilken rækkefølge sagerne er kommet ind. Men prioritet 1 sager bliver prioriteret over alle andre, for her er der tale om at store dele af organisationen ikke kan arbejde. Det gælder f.eks. når det studieadministrative system, Fønix, eller økonomisystemer, ØSS, er ude af drift.

Med tiden vil rutinerne blive implementeret bedre, sagerne vil begynde at tage kortere tid fordi de bliver udført på en mere hensigtsmæssig måde og man vil kunne se en nedgang i de sager der ligger. Sagerne tager måske 20% længere tid i starten, men skulle så gerne gøre det måske 40-50% hurtigere i den anden ende. Og så vil brugerne opleve en bedre service, som i mange tilfælde kan blive løst så snart brugeren henvender sig til helpdesken.