Processbeskrivning mall: en färdig struktur du kan använda direkt

En processbeskrivning mall är en färdig uppsättning rubriker som du fyller i för att beskriva hur en process går till: vad den är till för, vem som gör vad, vilka steg som ingår och hur resultatet ska se ut. Med en gemensam mall blir alla processbeskrivningar i företaget uppbyggda på samma sätt, och den som läser vet var svaret står. Här får du en mall att kopiera, ett ifyllt exempel, de vanligaste misstagen och en genväg för dig som redan har rutinen nedskriven.

Processbeskrivning mall: rubrikerna att fylla i

En bra mall är kort. Varje rubrik ska svara på en fråga som läsaren faktiskt ställer. Här är en uppsättning som fungerar för de flesta processer:

• Processens namn. Ett verb och ett objekt säger mest: "Hantera reklamation" i stället för "Reklamationer".
• Syfte. Varför finns processen? En till två meningar.
• Omfattning. Var börjar och slutar processen? Vad ingår inte?
• Processägare. Vilken roll ansvarar för att beskrivningen stämmer och förbättras?
• Start (trigger). Vad får processen att sätta igång? En order, ett mejl, ett datum?
• Indata och förutsättningar. Vad måste finnas på plats för att kunna börja?
• Steg. Vem gör vad, i vilken ordning. Med beslut och deras utgångar.
• Resultat (utdata). Vad är klart när processen är slut, och vem tar emot det?
• Hjälpmedel och dokument. System, blanketter och andra rutiner som används.
• Version och godkännande. Vem godkände beskrivningen, när, och vad ändrades senast? Du kan lägga till rubriker, men tänk efter först om läsaren verkligen behöver dem. Varje extra rubrik är något som någon ska fylla i och hålla aktuellt.

Så fyller du i mallen steg för steg

• Börja med omfattningen. Det är där de flesta processer blir otydliga. Skriv ned var den börjar och slutar innan du skriver något annat.
• Fyll i stegen tillsammans med dem som gör arbetet. Be dem berätta hur det faktiskt går till, inte hur det står i en gammal instruktion.
• Skriv steg med verb och roll. "Kundtjänst registrerar ärendet" är tydligare än "Ärendet registreras".
• Markera besluten. Skriv frågan och vad som händer vid varje svar.
• Fyll i resten. Syfte, ägare, indata och resultat blir enklare när stegen är klara.
• Låt någon annan läsa. En person som inte kan processen ska kunna följa den. Där hon fastnar saknas något.
• Godkänn och datera. Först när någon med ansvar sagt ja är det en gällande beskrivning.

Ifyllt exempel: onboarding av en ny medarbetare

Här är mallen ifylld för en påhittad, generisk process. Den passar många företag, men detaljerna är bara ett exempel. Namn: Introducera ny medarbetare Syfte: Att en ny medarbetare har konto, utrustning och en tydlig plan innan första arbetsdagen, och vet vad som förväntas första veckan. Omfattning: Från att anställningsavtalet är påskrivet till att den nya medarbetaren och chefen haft uppföljningssamtal efter första veckan. Löneadministration ingår inte. Processägare: Personalansvarig. Start: Påskrivet anställningsavtal. Indata: Startdatum, roll, närmaste chef. Steg:

• Personalansvarig skickar uppgifter om den nya medarbetaren till IT-ansvarig och chefen.
• IT-ansvarig beställer utrustning och skapar konton.
• Chefen tar fram en plan för första veckan.
• Personalansvarig skickar välkomstmejl med praktisk information.
• Beslut: Är allt på plats dagen före start? Om nej, personalansvarig följer upp med den som är försenad. Om ja, gå vidare.
• Chefen tar emot den nya medarbetaren, går igenom planen och visar arbetsplatsen.
• Chefen håller uppföljningssamtal i slutet av första veckan. Resultat: Medarbetare som kan sitt uppdrag och har det som behövs för att göra det. Hjälpmedel: Checklista för konton, välkomstmejl, plan för första veckan. Version: Godkänd av personalansvarig. Datum och senaste ändring anges här. Notera att exemplet är kort. Den som behöver mer detalj för ett enskilt steg kan länka till en egen beskrivning av det steget, i stället för att göra huvudbeskrivningen oläslig.

Text eller karta?

En processbeskrivning kan vara text, en processkarta eller båda. Text är bra för syfte, omfattning och förutsättningar. Kartan är bättre för stegen, eftersom den visar ordningen, rollerna och överlämningarna med en blick. Ofta fungerar det bra att ha textrubrikerna ovan och en karta på platsen för "Steg". Om du vill läsa om hur en karta ritas finns en genomgång i guiden Processkarta: så gör du en och får den läst.

Vanliga misstag med processbeskrivningar

• För många rubriker. En mall med tjugo fält fylls i slarvigt, eller inte alls.
• Syfte som bara upprepar namnet. "Syftet med reklamationsprocessen är att hantera reklamationer" säger ingenting. Skriv vad företaget vill uppnå.
• Passiv form utan roller. "Ärendet hanteras" svarar inte på vem. Skriv alltid vem som gör vad.
• Beskrivningen visar hur det borde vara. Skriv hur det är, och ändra processen i ett separat steg om den inte fungerar.
• Ingen version eller godkännande. Utan det vet ingen om beskrivningen gäller.
• Olika mallar på olika avdelningar. Då får läsaren lära sig flera sätt att läsa.
• Beskrivningen ligger i en mapp ingen öppnar. En färdig mall som ingen hittar hjälper inte.

Snabbare med AI: från rutin i text till processkarta

Har ni redan rutiner nedskrivna i Word eller PDF behöver du inte skriva om dem. I Swimloop laddar du upp dokumentet, eller klistrar in en beskrivning med egna ord, och AI:n bygger en processkarta av det. Det tar ett par minuter. Underlaget kan vara en PDF, ett Word-dokument, en textfil eller en bild. Kartan är ett utkast som du granskar mot mallens rubriker: stämmer rollerna, saknas något beslut, är ordningen rätt? När kartan är rättad går den vidare i ett flöde som motsvarar sista rubriken i mallen:

• Granskning och godkännande. Kartan skickas för granskning, godkänns och publiceras. Varje statusbyte sparas med vem och när.
• Versioner. Versionsjämförelsen visar vad som ändrats på stegnivå: tillagda, borttagna och ändrade steg.
• Ett bibliotek för läsarna. Processbiblioteket visar bara den publicerade versionen, aldrig ett utkast. Läsare är gratis.
• Export. Behöver du kartan i ett dokument kan den exporteras, bland annat till PNG, SVG och PowerPoint. Nya konton får fjorton dagars provperiod med full Pro utan kort.

Vanliga frågor

Vad är skillnaden mellan processbeskrivning och rutinbeskrivning? I vardagen används orden ofta om samma sak. En processbeskrivning handlar vanligen om ett helt flöde över flera roller, medan en rutin kan vara en enskild arbetsuppgift. Mallen ovan fungerar för båda. Hur lång ska en processbeskrivning vara? Så kort att den blir läst. Är den längre än ett par sidor, dela upp den i delprocesser. Måste en processbeskrivning innehålla en karta? Nej, men stegen blir ofta lättare att följa med en. Särskilt när flera roller är inblandade. Vem ska godkänna beskrivningen? Någon med ansvar för området, som inte själv skrev den. Det viktiga är att det går att se vem som godkände och när.

Nästa steg

Kopiera rubrikerna ovan och fyll i en process som ni redan kan väl. Vill du hellre låta AI göra första utkastet kan du skapa ett konto på Swimloop och ladda upp en befintlig rutin. Provperioden kräver inget kort. Har du ritat kartor tidigare och vill veta hur du får rutinerna ur huvudet och in i en karta, läs Dokumentera processer: så får du rutinerna ur huvudet och in i en karta. Läs vidare: AI-processkarta: så beskriver du en process och får en karta och Processbibliotek: så läser alla i företaget rätt version av era processer.