Så här kan du modellera ärendehanteringen i din verksamhet

Tio modellmönster för ärendehantering, från de enklaste till de lite mer omfattande. Samt om hur du kan gestalta din modell grafiskt för att den ska förmedla det du vill säga så tydligt som möjligt.

/Peter Tallungs, IRM, 2025-06-26

Ärendehantering

De flesta verksamheter behöver hantera ärenden av något slag, det vill säga att man behöver organisera och dokumentera sina aktiviteter i flöden. Då behövs en gemensam förståelse, gemensamt språk (begrepp och benämningar) och gemensamma informationsstrukturer för detta. Vi behöver informationsmodellera.

I den här artikeln visar jag några vanliga modellmönster som är användbara för ärendehantering.

Samtidigt vill jag visa det som gäller för all modellering generellt, hur man kan utforma sin modell så den blir tydlig och begriplig utan att överförenkla genom att hoppa över det vi faktiskt behöver beskriva och hantera. Det handlar om att lyfta fram den nödvändiga inneboende komplexitet som faktiskt finns i verksamheten. Att inte gömma undan saker utan visa allt det som behöver visas så enkelt, klart och tydligt som det bara går.

Det är svårt att överskatta betydelsen av detta. Hur vi gestaltar våra modeller, hur vi kan använda grafik och text för att uttrycka vår gemensamma förståelse.

Vi börjar med den mest rudimentära versionen av en modell och bygger sedan vidare steg för steg. Det är ett bra sätt att se modellmönster, att börja i det enkla och bygg på med entiteter, ämnesområden, attribut och relationer tills modellen täcker allt vi behöver undersöka, prata om och skapa gemensam förståelse kring.

För exemplets skull tänker vi oss att vi har att göra med kundärenden, men dessa grundläggande mönster är tillämpliga för alla slags ärenden.

Jag utgår här från kråkfotsnotation (Crow’s foot notation, eller JMIE – James Martin Information Engineering) som är den mest spridda notationen för informationsmodeller, både här i Sverige och världen över.

Mönster 1: Ärende som en serie av aktiviteter

Ett ärende är att betrakta som en behållare och identitet för en serie av aktiviteter som vi behöver hålla samman som en helhet. Det vill säga de aktiviteter som ingår som delar i ett och samma ärende.

De finns alltid regler i en verksamhet, uttalade eller outtalade, som styr när en aktivitet ska starta ett nytt ärende eller ingå i ett redan pågående.

Först något om den speciella typ av relation som finns mellan ett ärende och dess aktiviteter. Aktiviteterna är existentiellt beroende av sitt ärende. De kan inte finnas fristående från ett ärende och kan inte heller byta ärende. Aktiviteterna är att betrakta som ingående komponenter i ett ärende. Det här är något som går utöver det mer vanliga förhållandet där en förekomst av en entitet alltid måste vara kopplad till en förekomst av en annan entitet, men tillåts att kunna byta vilken förekomst den relaterar till. Här är beroendet starkare.

Jag tycker att det är viktigt att i modellen markera detta starkare beroende. Det är också något som kan ha en särskild symbol på relationslinjen. Olika notationer för informationsmodeller använder olika symboler för detta. I UML (Unified Modeling Language) kallas denna typ av relation för komposition och markeras med en fylld romb, vilken jag lånat in här. Den säger i detta fall att ett kundärende är en komposition av aktiviteter. I flera vanliga ER-notationer sägs aktiviteterna i stället vara beroendeobjekt till ärendet.

Ett ärende kan ha noll, en eller flera aktiviteter. En lite knivig, men egentligen ganska oviktig, fråga är om ett ärende verkligen kan sakna aktiviteter. Det känns kanske konstigt med ett ärende utan aktiviteter. Men man kan tänka sig att man i sitt ärendehanteringssystem först registrerar själva ärendet och först därefter den första aktiviteten. Därmed finns det ett tillfälle där vi kan tillåta att ärendet saknar aktivitet, men det torde vara ett högst övergående tillstånd.

Observera att jag skriver definitionen av entiteten direkt under entitetens namn. Det är ett enkelt och kraftfullt sätt att göra modellen tydlig och hela modelleringsarbetet effektivare. Ty det är väsentligt att vi verkligen är överens om betydelsen av den företeelse som entiteten representerar. Entiteten står för ett begrepp. Det vill säga en företeelse med en viss betydelse, inte för hur vi råkar benämna denna företeelse. Det är definitionen som ger begreppet sin betydelse. Namnet kan vi ändra längs vägen, men betydelsen måste vi vara helt överens om. Det är annars vanligt att man lägger olika betydelser i en term, och först mycket senare, eller kanske aldrig, inser att man inte menat exakt samma sak. Subtila och okända skillnader i uppfattning om vad termer står för orsakar ofta stora problem längre fram. Det är något vi behöver undvika.

Det är grundläggande inom begreppsanalys att vi skiljer på företeelsen i sig (begreppet, som är det definitionen pekar på) och benämningen (det namn vi råkar använda). Att lyfta fram definitionen är ett enkelt och effektivt sätt att göra detta.

Observera att jag placerar entiteten Ärendeaktivitet under Ärende. Det markerar att aktiviteterna är underställda ärendena. Jag låter den underställda entiteten vara något indragen åt höger. Det underlättar den fortsatta layouten av diagrammet, då flera entiteter tillkommer.

Jag brukar inte ge denna typ av relation, alltså kompositioner, något namn. Romben talar redan om vilken typ av relation det rör sig om – att en aktivitet är en ingående del i ett kundärende.

Jag strävar efter att namnge saker så tydligt som möjligt. Jag skriver ut fullständiga namn, använder flera ord där det behövs och undviker förkortningar.

Mönster 2: Ärendets koppling till intressent

Det är nästan alltid så att ett ärende är kopplat till en eller flera intressenter. När det handlar om kundärenden är ett ärende kopplat till en kund.

Låt oss här tänka oss att rör sig om organisationskunder.

Observera att jag ger relationen namnet Kund. Därmed frångår jag konventionen att namnge relationer med adjektiv (har, tillhör) eller verb (registreras av).

Detta av följande skäl:

• En relation är ju egentligen samtidigt alltid en egenskap, ett attribut, hos en företeelse: i detta fall en uppgift i ett ärende om vilken kund som ärendet handlar om. Det vill säga att relationen är ett verksamhetsbegrepp precis som vilket attribut som helst, och därför behöver namnges, definieras och dokumenteras. Den term vi väljer behöver kunna leva vidare i databaskolumner, tjänster, användargränssnitt, rapporter och dokument.
• Dessutom, så fort vi använder verb eller verbsatser, till exempel registreras av, hanteras av, inför vi ett intryck av att vi har ett intryck av processer i vår modell, som ju är något främmande för en informationsmodell. Det kan missleda läsare av modellen. En informationsmodell får aldrig ha något av process i sig. Den ska uttrycka vilka företeelser vi hanterar information om och hur de relaterar till varandra; inte hur informationen tillkommit eller används. Med ett finare ord kan man säga att en informationsmodell ska vara processagnostisk.

Jag markerar läsriktningen på relationen med en pil, vilket skapar ytterligare tydlighet.

Allt detta handlar om en sak: att skapa tydlighet. Tydlighet inte bara för läsare av modellen utan också, och kanske framför allt, för mig själv under arbetets gång. För att skärpa min egen förståelse. En modell är inte bara ett kommunikationsverktyg utan också ett tankeverktyg. Esaias Tegnér sa ”Det dunkelt sagda är det dunkelt tänkta”. Detta gäller i hög grad när vi modellerar. När jag formulerar min förståelse så tydligt som möjligt, så utvecklar jag samtidigt min förståelse. Jag klargör mina oklarheter och upptäcker mina tankefel.

Mönster 3: Ämnesområden

Vi kan dela in en modell i ämnesområden, det vill säga saker som hör ihop. Att på detta sätt ge modellen en meningsfull struktur är verkligen kraftfullt.

Att skapa ämnesområden handlar inte enbart om att förmedla vad vi redan vet. Det handlar kanske ännu mer om att för mig själv reda ut vad jag vill se som sammanhang. En modell är, som jag nämnt, inte bara ett verktyg att förmedla en förståelse, utan också, och inte minst, ett tankeverktyg. Att modellera är att se vad som hänger ihop och bildar sammanhang.

Jag ritar ämnesområdena som ljusgråa ytor och justerar höjd och bredd så att de tillsammans bildar en rektangel. Detta ger ett lugnt intryck och gör modellen mer läsbar.

Jag ger ämnesområdena namn som, om möjligt, skiljer sig från namnen på entiteterna. Namnen skrivs i mörkgrå fetstil för att visa att de hör till den diskreta bakgrund som utgör modellens ämnesområden.

Mönster 4: Kundkontakt

Ett ärende är kopplat till en kund, men vi behöver normalt också veta vilken kontaktperson vi har att göra med hos kunden. Vi kallar en person med den uppgiften för Kundkontakt.

Kundkontakten har ingen självständig existens och är därmed ett beroendeobjekt till kund. (Eller som UML uttrycker det: En kund har en komposition av möjliga personer med roll som möjliga kundkontakter.)

Mönster 5: Handläggare

Ett ärende är normalt kopplad till flera intressentroller. Förmodligen finns det en handläggare som ansvarar för ärendet.

Nu ser vi hur det vuxit fram ett övergripande mönster för modellens struktur. Den har fått en tydlig geografi. Till vänster: de resurser eller företeelser som finns till vårt förfogande, utanför vår organisation, i det här fallet kundsidan. Till höger: motsvarande resurser på insidan av vår verksamhet. Än så länge bara handläggaren, men fler kan tillkomma.

Dessa entiteter, kund och handläggare, är statiska företeelser i förhållande till själva ärendehanteringen. De kan ha en mer eller mindre kontinuerlig existens oberoende av hur ärenden kommer och går. Förekomsterna i dessa entiteter indikerar inte att något har hänt egentligen. All ”action”, alla aktiviteter och all verksamhet i detta sammanhang sker i modellens mitt, i ämnesområdet för ärendehantering.

Detta är ett vanligt övergripande mönster i en modell, och som man vinner på att framhäva i själva grafen. Verksamhetens i sig själv (här: Handläggare) och verksamhetens kunder (här: Kunder), samt allt det som händer däremellan, det vill säga alla transaktioner mellan verksamhet och kund (här: Ärendehantering Kundärenden).

Mönster 6: Aktiviteter med egna aktörer

En aktivitet i ett ärende kan ibland ha en annan handläggare än den som är huvudansvarig för själva ärendet, samt kan kanske involvera en annan kundkontakt än den ordinarie kundkontakten för ärendet.

Vi behöver kunna hantera detta i modellen. På så sätt kan vi spåra vem som gjort vad och med vem.

Mönster 7: Ärendetyp

Vanligen vill man kategorisera ärenden i ärendetyper. Kanske skiljer vi på sälj- återköps- och supportärenden. Då behöver vi ett attribut i ärendet för ärendetyp, samt på något sätt ange värdeförrådet, det vill säga tillåtna, namngivna och definierade värden för detta attribut.

Värdeförrådet blir en egen entitet, som kan heta Ärendetyp. Observera att denna entitet inte representerar vilken ärendetyp ett visst ärende har, utan i stället en ärendetyp ett ärende kan ha. Eftersom entiteter alltid namnsätts i singular, betecknande en förekomst av entiteten blir namnet Ärendetyp, inte Ärendetyper.

Entiteter av detta slag, som samlar ett antal definierade uppräknade värden som utgör värdeförråd för attribut – typisk det vi kallar koder av olika slag – följer ett visst mönster. De har få och bestämda attribut:

• Kod: Fungerar som kortnamn för värdet där det utskrivna namnet inte får plats, som till exempel kolumnvärde i en rapport. Är vanligen också primärnyckel.
• Namn: Det korrekta utskrivna namnet på värdet.
• Definition: Definition av värdet. Då kan man visa upp definitionen i olika sammanhang, inte minst i de dialoger där en användare ska välja värde. Många brister i datakvalitet har sin grund i att koder av detta slag är otydligt definierade och slarvigt använda.

Det kan ibland behövas fler attribut än dessa för uppräknade värden. Man kan ibland behöva ett attribut som anger sorteringsordning när värdena ska visas i användargränssnitt, och där den alfabetiska ordningen inte är den mest logiska.

För uppräknade värden av detta slag vill jag ha med själva värdena i informationsmodellen, och då inte bara i modellens textdel utan även i ER-diagrammet. Ty vilka värden som finns och vad de betyder är en viktig del av verksamhetslogiken och informationsarkitekturen. Jag gör då en särskild ruta i ER-diagrammet för en uppräkning av förekomsterna. För att skilja rutan från de vanliga entitetsrutorna ritar jag denna i en avvikande färg och med ett streck kopplad till den entitet som beskrivs.

Detta är inget som ingår i vanliga notationer för informationsmodeller, men jag tycker att det är något väsentligt för verksamhetslogiken och informationsarkitekturen som vi bör tillföra våra modeller.

Vi kan nu se hur ett mönster framträder. Vi kan med hjälp av horisontella rubriklinjer, dela upp ämnesområdet Ärendehantering – Kundärenden i två delar. Till vänster själva ärendena med sina aktiviteter, det vill säga de entiteter som motsvarar de värdemängder som populeras då man opererar verksamheten. När ärenden och aktiviteter skapas och ändras är det här det speglas. Till höger redovisar vi några av de regler som gäller för ärenden och aktiviteter. Tills vidare visar modellen bara vilka ärendetyper som finns, hur de benämns och vad de betyder. Mer kommer när vi modellerar vidare.

Vi kan se detta som två plan i modellen. Ett operativt plan som beskriver de direkta operativa strukturerna, och ett regelplan som enkom är till för att bestämma regler, det vill säga styr vad som kan hända.

När vi populerar det operativa planet med förekomster, det vill säga de lagringsstrukturer som motsvaras av entiteterna, avspeglar det hur vi opererar verksamheten. När vi populerar regelplanet innebär det att vi konfigurerar verksamheten, det vill säga att när vi till exempel inför en ny ärendetyp så har det inte hänt något operativt i verksamheten. Inget ärende eller någon aktivitet har tillkommit eller ändrats, vi har bara ändrat det regelverk som gäller för ärendet, det vill säga styr hur vi opererar.

Denna skillnad visar hur det är skillnad på data och data. Det finns data som utgör regler för verksamheten, och andra som avspeglar vad som händer i verksamheten. Reglerna kan sägas finnas på en meta-nivå i förhållande till operativa data. Modellen blir mycket tydligare om vi avspeglar detta i vår layout.

Mönster 8: Ärendestatus

Vanligen vill man kunna se vilket tillstånd ett ärende befinner sig i. Inte minst för att kunna skilja på: öppna (pågående) ärenden, stängda (avslutade) ärenden och eventuellt pausade ärenden.

Detta är viktigt för att kunna styra och även analysera ärendeflödet. Till exempel: hur lång tid befinner sig typiskt ett ärende i ett visst tillstånd?

Därför utökar vi regelplanet med definierade ärendestatusar som används både för ärenden och aktiviteter. Vi utgår från att ärenden och aktiviteter har samma värdeförråd för status. Det kan senare visa sig att vi behöver skilja på dessa.

Mönster 9: Samband mellan ärenden

I många verksamheter kan man behöva dela upp ett stort ärende i flera delärenden av olika typer.

Det kan också vara så att man behöver hålla reda på att ett ärende är relaterat till ett tidigare ärende. Detta är två olika sätt som ett ärende kan vara relaterat till ett annat. Vi behöver då relationer för detta i vår modell, med tillhörande attribut.

När en entitet som exempelvis Kundärende, börjar få många attribut är det lämpligt att ge dessa någon slags logisk ordning och gruppering med rubriker.

Mönster 10: Ärendedokument

I många verksamheter finns ofta behov av att kunna hålla reda på dokument av olika slag och kunna koppla dessa till ärenden.

Dokumenthantering och ärendehantering hör ofta samman, men det är ändå lämpligt att se dokumenthanteringen som något separerat från ärendehanteringen. För det finns vanligtvis gott om dokument som inte har direkt koppling till med specifika ärenden.

Ett dokument är någon form av lagrad artefakt, digital eller analog. Det handlar inte bara om textdokument utan också bilder, videos, ritningar, med mera. Ett dokument kan också vara en samling av andra dokument, till exempel en akt, dossier eller mapp med flera foton som dokumenterar en händelse. I sådana fall kan vi behöva identifiera varje enskilt foto som ett separat dokument, och samtidigt också hela dossiern som ett dokument. Ett dokument kan alltså i vissa fall ingå som en egen identifierad del i ett annat dokument.

Det är också lämpligt att klassificera dokument i typer. Vissa dokument hör till ärenden, andra till kunder utan att vara kopplade till ett specifikt ärende. Andra dokument är inte kopplade till vare sig kunder eller ärenden.

Observera att detta inte visar en fullständig dokumenthantering utan exemplifierar bara hur man kan koppla dokument till ärenden.

Nu är det din tur

De mönster jag visat här är en hyfsat generisk grund för all ärendehantering. Men för att modellen ska passa din specifika verksamhet behöver du antagligen bygga på med mer.

Man kan till exempel behöva olika typer av aktiviteter för olika ärendetyper. Man kan också behöva koppla ärenden till produkter eller tjänster.

Det jag inte visat här är modellens textdel. En informationsmodell är sällan bara ett diagram, en graf, utan behöver också omfatta strukturerad text för att vara användbar.

Har du tankar om hur vi kan förbättra modellen? Eller idéer kring hur vi kan utveckla våra sätt att modellera i stort? Hör av dig! Den dialogen är viktig.