De flesta IT-organisationer har dokumenterade processer i någon form. Färre har processer som faktiskt speglar hur arbetet utförs i praktiken. Processkartläggning är arbetet med att översätta verkligt arbetsflöde till en visuell modell som går att analysera, förbättra och automatisera. För service management är det också grunden för en fungerande ITIL-implementation, ett konfigurerbart ärendehanteringssystem och meningsfull mätning av tjänsteleverans. Den här guiden går igenom syftet med processkartläggning, vilka notationer som används i praktiken, en konkret steg-för-steg-metod och en mall som kan användas direkt.
Vad processkartläggning innebär
Processkartläggning är att systematiskt beskriva en arbetsprocess som en sekvens av aktiviteter, beslut, roller och informationsflöden. Resultatet är en processkarta – en visuell representation som visar vem som gör vad, i vilken ordning, och vilka system och dokument som är involverade.
För service management har kartläggningen tre primära syften. Det första är transparens: att alla inblandade ser samma bild av hur ett ärende eller en serviceförfrågan rör sig genom organisationen. Det andra är förbättring: en karta gör flaskhalsar, dubbelarbete och otydliga övergångar synliga. Det tredje är automatisering: en process som inte är kartlagd kan inte konfigureras korrekt i ett ärendehanteringssystem.
Tre vanliga notationer – när används vad
Tre notationer dominerar i praktiken. Valet styrs av syftet med kartan och vem som ska läsa den.
| Notation | Användningsområde | Styrka | Begränsning |
| Flödesschema (enkel) | Översiktlig kommunikation, workshopunderlag | Lätt att läsa för icke-tekniska intressenter | Saknar standardiserad semantik för komplexa flöden |
| Swimlane | Tydliggöra rollfördelning och överlämningar | Visar ansvar per roll/avdelning explicit | Blir snabbt rörig vid många parallella aktörer |
| BPMN 2.0 | Detaljerade processer som ska automatiseras | Standardiserad, exekverbar, stödjer undantagsflöden | Brant inlärningskurva, kräver verktygsstöd |
För de flesta ITSM-processer räcker swimlane-notation. Den synliggör överlämningar mellan användare, servicedesk, andra IT-team och externa leverantörer – vilket är där de flesta processproblem uppstår. BPMN används när en process ska bli en konfigurerad workflow i ett ärendehanteringssystem och kräver formell beslutslogik. Enkla flödesscheman fungerar för kommunikation till verksamhet och ledning.
Steg-för-steg: så genomför du processkartläggningen
En användbar kartläggning följer en strukturerad metod. Hoppa inte över steg ett – det är där de flesta initiativ blir för vaga för att leverera värde.
- Avgränsa processen. Definiera start- och slutpunkt och vilken nivå av detalj som ska kartläggas. ”Incidenthantering” är inte en avgränsning – ”från användarrapporterad incident till stängt ärende, exklusive eskalering till leverantör” är en avgränsning.
- Identifiera intressenter och roller. Vem initierar processen, vem utför, vem godkänner, vem informeras? Använd RACI-modellen för att undvika gråzoner.
- Genomför observation och intervju. Bygg inte kartan från policydokument. Sitt med servicedesken under några timmar, följ ett urval ärenden från initiering till stängning, och intervjua handläggare om de undantag som inte finns dokumenterade.
- Rita as-is-flödet. Visualisera processen som den faktiskt utförs idag, inte som den borde utföras. Inkludera workarounds och informella steg – de är där de viktigaste insikterna finns.
- Validera med deltagarna. Gå tillbaka till dem som utför processen och bekräfta att kartan stämmer. Förvänta dig korrigeringar.
- Analysera och identifiera förbättringar. Markera väntetider, dubbelarbete, manuella överlämningar och beslutspunkter utan tydliga kriterier. Detta är förbättringsbacklog.
- Designa to-be-flödet. Utforma den önskade processen baserat på analysen. Beslut här bör vara baserade på data från as-is, inte på antaganden.
- Implementera och mät. Konfigurera processen i ärendehanteringssystemet, träna handläggare och mät utfallet. Utan mätpunkter går det inte att avgöra om förbättringen fungerade.
Mall: minimalt innehåll i en processkarta
En processkarta som ska vara användbar för både kommunikation och systemkonfiguration behöver innehålla följande element.
| Element | Syfte | Exempel för incidenthantering |
| Processnamn och version | Identifiering och versionshantering | Incidenthantering v2.3, gäller från 2026-06-01 |
| Processägare | Tydlig accountability för förvaltning | Service Desk Manager |
| Start- och slutpunkt | Avgränsning | Start: incident rapporterad. Slut: ärende stängt och CSAT-enkät skickad |
| Roller och swimlanes | Vem gör vad | Användare, Servicedesk N1, Specialistteam N2, Problemhantering |
| Aktiviteter | Konkreta arbetsmoment | Registrera, kategorisera, prioritera, lösa, dokumentera, stänga |
| Beslutspunkter med kriterier | Logik som styr flödet | Är incidenten major? (kriterier för major incident definierade i bilaga) |
| Trigger för nästa process | Koppling till angränsande flöden | Återkommande incident → trigger problemhantering |
| Mätpunkter | Var i flödet KPI:er samlas in | Tid från registrering till tilldelning, FCR-rate, SLA-uppfyllnad |
| Undantagshantering | Vad händer när det normala flödet bryts | Kunden ej nåbar för bekräftelse → pausa SLA-klocka |
Konkret exempel: kartläggning av incidenthantering
För att illustrera principerna används incidenthantering som genomgående exempel. As-is-flödet i en typisk organisation utan tidigare formell kartläggning ser ofta ut så här:
Användaren rapporterar problemet via mejl, telefon, chatt eller direkt till en känd kollega. Servicedesken registrerar – eller inte – ärendet beroende på kanal. Klassificering sker subjektivt utan tydliga kategorier. Tilldelning baseras på vem som råkar vara ledig. Eskalering till specialistteam sker informellt, ofta via personligt meddelande. Status uppdateras inte konsekvent och kunden får besked först när problemet är löst.
En kartläggning gör dessa brister synliga. To-be-flödet adresserar dem på följande sätt: en kanalstyrd registreringspunkt säkerställer att alla ärenden hamnar i systemet. En klassificeringsmatris (kategori × påverkan × brådska) ger en repeterbar prioritetstilldelning. Automatisk tilldelning enligt definierade regler ersätter ad hoc-fördelning. Eskalering till N2 utlöses av definierade kriterier i ärendehanteringssystemet, inte av handläggarens bedömning. Statusuppdateringar triggas automatiskt vid övergångar i flödet. SLA-mätning sker mot dokumenterade trösklar i prioritetsmatrisen.
Resultatet är inte bara en bättre process utan en process som faktiskt kan konfigureras i ett ärendehanteringssystem och mätas konsekvent.
Vanliga fallgropar i processkartläggningsarbetet
- Att kartlägga ideal i stället för verklighet. As-is-kartan ska visa hur processen utförs idag, även om det är obekvämt. Annars förbättras fel sak.
- Att gå för djupt för tidigt. En första karta ska visa huvudflödet – inte varje tänkbart undantag. Detaljering byggs in när huvudflödet är validerat.
- Att kartlägga utan processägare. Utan en utpekad ägare blir kartan ett engångsdokument som snabbt blir inaktuellt.
- Att inte koppla kartan till ärendehanteringssystemet. En process som lever i Visio men inte i NSP, Jira eller motsvarande är en process som inte styr beteende.
- Att hoppa över mätpunkter. Utan baseline och uppföljning går det inte att skilja en bättre process från en tröttare organisation.
- Att betrakta kartläggningen som klar. Processer förändras när verksamhet, regelverk och teknik förändras. Versionera och revidera kartan minst årligen.
Från karta till konfigurerad workflow i Nilex Service Platform
Värdet av en processkarta realiseras först när processen faktiskt styr ärendeflödet. I Nilex Service Platform översätts den kartlagda processen direkt till en konfigurerad workflow: roller, beslutspunkter, eskaleringsregler, SLA-trösklar och mätpunkter implementeras enligt kartan utan kodning.
NSP stödjer både enkla flöden och processer med komplex beslutslogik och parallella aktivitetsspår. Eftersom workflowmotorn arbetar mot samma datamodell som ärenden, CMDB, kunskapsbas och rapportering, blir varje steg i den kartlagda processen mätbart i samma rapportvy. Det innebär att förbättringar som identifierats i kartläggningen kan följas upp i konkret data – inte bara i uppfattningar.
För organisationer som står inför en första formell processkartläggning kan implementationen ske parallellt: as-is dokumenteras, to-be konfigureras i NSP, och flödet driftsätts stegvis med möjlighet att justera baserat på faktiskt utfall.
Vill du se hur en kartlagd process konkret översätts till en exekverbar workflow i NSP? Boka en genomgång med en av våra konsulter.
