Request fulfilment

Detta är en förkortad text, du hittar mer utförliga beskrivningar i boken

Den primära kommunikationsvägen mellan IT och användarna är funktionen service desk. När en användare kontaktar service deskkan ärendet beröra i princip vad som helst. Det kan vara en fråga, en beställning eller någon som behöver hjälp med en IT-tjänst som inte fungerar. Det vill säga en begäran av något slag som ska uppfyllas av service desk. Processen request fulfilmentär till för att hantera det som kommer från användare till service desk.

Alla ärenden från användare startar i processen request fulfilmentsom en service request för att sedan vid behov skickas vidare till andra processer. Service request (eller request for service), har blivit ett vedertaget samlingsnamn som beskriver beställningar eller förfrågningar som kommer till service deskfrån en användare.

En service request kan till exempel vara en användare som har frågor om hur en applikation används, har önskemål om att få installera en ny applikation, eller som vill beställa en ny telefon eller PC.

Syfte

Syftet med processen är att ansvara för hela genomförandet av service requests. Detta uppnås genom att:

  • Tillhandahålla en kanal där användarna kan beställa och få IT-tjänster, förutsatt att de finns att beställa och att godkännanden finns, när så krävs, från den som ska betala.
  • Tillhandahålla information om IT-tjänster och hur de kan beställas.
  • Genomföra beställningar av standardtjänster
  • Svara på frågor, ta emot klagomål och andra kommentarer
  • Hjälpa användarna att komma till rätt funktion med sitt ärende.

Omfattning

Alla ärenden från en användare startar som en service request. Den vida definitionen medför att request fulfilmentofta består av flera rutiner beroende på vad som efterfrågas. Fel i IT-miljön som inte är kända ska skickas vidare till incident management-processen och förbättringsförslag ska till berörd funktion via processen kontinuerlig förbättring. Det som därefter kvarstår och ska slutföras inom processen är supportfrågor och beställningar.

För supportfrågor är det av stor vikt att kontaktvägar för eskalering finns dokumenterade för de applikationer som ingår i service desksansvar så att man snabbt kan lösa ärendet eller skicka vidare ärendet till rätt supportgrupp.

Föra att tydligt avgränsa omfattningen på vad som går att beställa ska varje beställningsbar komponent eller IT-tjänst vara gediget dokumenterad med tydliga rutiner för genomförande och eventuellt godkännande.

Det är vanligt att service desktillhandahåller en webbportal där användarna själva kan registrera sina beställningar. Processen är därefter mer eller mindre automatiserad. Ett exempel är att en användare beställer MS Project genom att fylla i uppgifterna i en webbportal. Efter det skickas e-post för godkännande till berörd chef. När ärendet godkänts installeras applikationen automatiskt på användarens dator.

Det är här viktigt att den automatiserade varianten bibehålls som en del av request fulfilment– processen och service deskistället för att hanteras av en annan funktion inom IT-avdelningen. Faran är att det blir skillnad mellan vad webbportalen tillhandahåller och vad som ingår i request fulfilmentmed dubbel dokumentation, information och statistik som följd.

Eftersom allt som hanteras inom request fulfilment-processen bör vara dokumenterat i rutiner ligger det inom processens ansvar att tillhandahålla mallar och rutiner för att etablera nya beställningsbara objekt och tjänster. Ansvaret för att informationen fylls i och är aktuell ligger dock på tjänsteägaren för respektive tjänst.

Service request katalog

En stor del av processens uppgift är att hantera beställningar från användare. För att kunna säkerställa en snabb och säker hantering måste alla beställningsbara produkter och tjänster finnas dokumenterade med rutiner som beskriver innehåll, leveranstid, produktion och eventuellt auktorisering. Det som finns beskrivet med en sådan rutin publiceras till användarna av service desksom en service request katalog.

Skillnaden mot en tjänstekatalog, som beskrivs närmare i kapitlet hantering av tjänstekatalog, är att tjänstekatalogen visar IT-tjänster som kan köpas av kunder, medan servcie request katalogen visar produkter och tjänster som kan beställas av användare. Ett exempel är IT-tjänsten ”arbetsplats” som köps av verksamheten, denna kan då innehålla då flera extraapplikationer som kan beställas enskilt av användarna som en service request.

Finns inte det användaren vill beställa i service request katalogen hanteras förfrågan som ett förslag till förbättring och skickas vidare i processen kontinuerlig förbättringtill berörd funktion.

Aktiviteter

Registrering– Alla ärenden måste registreras med berörd användare, utrustning och en utförlig beskrivning av ärendet. Det är oftast i det här statusläget som automatgenererade ärenden via till exempel en portal hamnar där en handläggare kan ta vid och komplettera informationen. Om ett ärende ska skickas vidare till en annan grupp/organisation för vidare bearbetning underlättas arbetet väsentligt när bra och komplett information är inskriven i ärendet.

Kategorisering– Kategorisera ärendet enligt en fördefinierad lista. Kategoriseringen är samma oavsett ärendetyp och speglar tjänstekatalogens uppbyggnad för att bland annat underlätta ansvarsfrågor och statistik.

Ärendetyp– Fel i IT-miljön som rapporteras in ska kontrolleras mot listan med kända fel. Om det är ett känt fel ska den tillfälliga lösningen genomföras och ärendet skickas vidare till kontinuerlig förbättring. Fel som inte finns med i listan går vidare i incident management-processen. Frågor hanteras enligt dokumenterad support rutin. Finns ingen rutin eller om supportteknikern inte kan svara med hjälp av egen kunskap hanteras ärendet som ett förslag till förbättring i processen kontinuerlig förbättring.

Prioritering– Prioriteten avgörs genom att en kombination av nuvarande påverkan, framtida påverkan och tidsram enligt prioriteringsmodellen.

Auktorisation– Vissa beställningar kan behöva godkännande från behörig person i verksamheten. Detta ska framgå av de rutiner som finns för beställningen som även ska inkludera av vem och hur ett godkännande ska hanteras.

Genomförande– Genomför beställningen enligt den dokumenterade rutinen.

Stängning– Alla lösningsgrupper kan stänga ett ärende efter att ha kontrollerat med användaren att allt är som det ska.

©2019 OpenTRIM® a model to ease the adoption of ITIL®, OpenTRIM® is a registered trademark of OpenTRIM AB. All rights reserved. ITIL® is a registered trademark of AXELOS AB. All rights reserved.

KONTAKTA OSS

VI är inte online just nu, men skicka oss ett meddelande så svarar vi dig så fort vi kan.

Sending

Log in with your credentials

Forgot your details?