Introduktion till verksamhetsmodellering

Introduktion till verksamhetsmodellering

1 (20) Dokument: Introduktion till verksamhetsmodellering ID-nr/dnr: Siffror. Beställare: Marcus Matteby IT-direktör, Koncernstaben Sundsvalls kommun Version: 1.1 Skriven av: Petronella Enström Thomas Norlin Adam Stålhult Datum 2019-08-09 Godkänd av: Thomas Norlin Datum 2019-08-09 Webbplats: https://utveckling.sundsvall.se/modeller-och-metoder/

2 (20) 1 Innehållsförteckning 1 Innehållsförteckning... 2 Ordlista... 4 1 Inledning... 5 1.1 Målgrupp... 5 1.2 Syfte... 5 1.3 Avgränsning... 5 2 Beskriva verksamheten & skapa samsyn genom modellering... 6 2.1 Verksamhetsmodeller i olika dimensioner och vyer... 7 2.2 Verksamhetsmodeller i olika nivåer... 8 3 Beskrivning av de olika dimensionerna i modellering... 10 3.1 Processmodellering... 10 3.1.1 Verksamhetsobjekt är vår koppling till informations- och datamodellering... 11 3.2 Informationsmodellering... 11 3.3 Applikationsmodellering... 13 3.4 Datamodellering... 14 3.5 Övriga dimensioner... 14 4 Symboler och språk för att rita modeller... 15 4.1 Processer... 15 4.2 Information... 16 4.3 Applikation... 17 4.4 Data... 18 5 Sundsvalls arkitekturramverk... 19 6 Sammanfattning... 20 7 Kontaktinformation... 20

3 (20) Förändringshistorik Version Datum Status och eventuell förändringsorsak Utfärdare 0.4 2019-03-15 Utdrag hämtade från Handbok för processmodellering 1.0. Thomas Norlin 0.5 2019-05-08 Tillägg av informations-, applikation och datamodellering 1.0 2019-06-27 Slutlig version efter gemensam bearbetning Petronella Enström Petronella Enström Thomas Norlin Adam Stålhult 1.1 2019-07-05 Lagt till ordlista (kapitel 2) Thomas Norlin Relaterade dokument Version Datum Benämning Beslutsinstans 1.0 2016-11-23 Riktlinjer för informationsmodeller Sparx EA 1.0 1.0 2011-02-28 IT-strategi för e-förvaltning för Sundsvalls kommunkoncern år 2011-2021 IT-direktör Kommunfullmäktige, 84

4 (20) Ordlista Modell: Objekt: Dimension: En modell är en beskrivning av något som finns idag eller planeras. Vanligen beskrivs modeller grafiskt i ritningar eller beskrivningar. Varje modell består av ett antal olika objekt Vi har valt att dela upp våra verksamhetsbeskrivningar i dimensioner. De tre primära dimensioner är process, information och applikation. Vy: Vi använder oss av 5 nivåer, där nivå fem är den mest detaljerade. Högnivå (Nivå 1-2), Övergripande (Nivå 3-4), Detaljerad (Nivå 5). Verksamhetsmodeller: Affärsmodell: Processmodell: Informationsmodell: Datamodell: Vanliga modeller i verksamheten är, affärsmodeller, processmodeller och informationsmodeller. Arbetet med att ta fram modellerna görs ofta i mötesform med blandade kompetenser. Affärsmodellerna beskriver i huvudsak hur organisationen skapar värde för sina kunder genom att nyttja kompetenser, processer, IT-stöd och samarbetspartners. Det är genom affärsmodellerna som koncernstrategin förverkligas. En process har en tydlig början, en tydligt slut och ett förväntat resultat/nytta. Arbetet organiseras i en logisk kedja av aktiviteter som kan inkludera flera olika verksamheter, allt beroende på hur komplex processen är. Arbetet med att beskriva dagens process och se hur denna ska utvecklas benämns processutveckling. Arbetet med processutvecklingen resulterar i ett antal processmodeller. En processmodell definieras i ett antal nivåer. En informationsmodell är resultatet av en informationsmodellering. En informationsmodell beskriver hur informationen är strukturerad. En beskrivning av hur databaserna och dess tabeller är organiserade i ett IT-system.

5 (20) 1 Inledning Sundsvalls kommun utgår i sitt arbete med verksamhetsbeskrivningar från befintliga standarder Prime Arch, BPMN, TOGAF och ArchiMate. Dokumentet beskriver i vilken grad vi tagit till oss ovan nämnda standarderna. Arbetet med att vidareutveckla metodik och vårt ramverk för Sundsvalls kommunkoncern sker kontinuerligt och nya versioner av detta dokument kommer att publiceras på https://utveckling.sundsvall.se/ 1.1 Målgrupp Målgruppen för dokumentet är de som arbetar med utveckling av sin verksamhet t.ex. verksamhetsansvariga, verksamhetsutvecklare, projektledare samt externa konsulter. Detta påverkar vanligtvis processer, information, applikation och IT-stöd. 1.2 Syfte Dokumentets syfte är att ge en övergripande bild av vad modellering är, hur det kan vara till hjälp och användas som verktyg i verksamhetsutveckling. 1.3 Avgränsning Figur 1. Visar dokumentets omfattning i förhållande till helhetssynen i kommunkoncernen, hämtat från ITstrategi för e-förvaltning för Sundsvalls kommunkoncern år 2011-2021. Avgränsningen i denna handbok är process, information, applikation och data.

6 (20) 2 Beskriva verksamheten & skapa samsyn genom modellering Sundsvalls kommun är en komplex organisation med många strukturer i samspel och balans. När vi gör förändringar i kommunen vill vi ha bra beslutsunderlag oavsett om det gäller strategi-, organisations-, process-, eller IT-förändringar. Ibland kan det vara svårt att beskriva och förmedla komplexa strukturer, till sig själv, sina medarbetare och organisationen i stort då kan grafiska modeller vara till hjälp! En modell är en förenkling av verkligheten och förmedlar alltså inte allt utan en avvägning måste göras. Man måste till exempel avgöra vilken detaljnivå man ska hålla sig på (1-5) för att bästa tjäna modellens syfte. Man måste även avgöra vad man ska inkludera i modellen och vad som ska exkluderas alltså ett tydligt scope. Processer går till exempel oftast in i varandra i ett komplext nät och det blir därför viktigt att hålla sig till den process man valt att beskriva. Sällsynta felflöden kanske även ska exkluderas eftersom de ofta gör modellen onödigt krånglig och skymmer överblicken. Modeller kan ge oss svar på ett antal frågeställningar i utvecklingsprojekt. Förutom att beskriva hur vår verksamhet ser ut i startläget av vår förändring kan och bör modellering användas för att beskriva det önskade läget. De ska visa på var vi vill genomföra våra förändringar med hjälp av nya eller förändrade krav, system eller aktiviteter. Det vi inte kan beskriva har vi också svårt att förändra. Skillnaden mellan beskrivning av nuvarande verksamhet och det designade önskade läget används för att identifiera konsekvenser och beräkna resursåtgång. Olika faser i vår utveckling söker svar på olika frågor och därför bör vi också anpassa vilken typ av modell vi tar fram utifrån aktuell fas och den gällande frågeställningen. På Sundsvalls kommun tycker vi att verksamhetsmodeller är ett ypperligt verktyg för att analysera sin verksamhet inför föreslagna förändringar eller för att hitta möjligheter till en effektiv kommun, helt i enlighet med kommunens tillväxtstrategi RIKARE. Vi får dessutom en möjlighet att på ett enkelt sätt förklara var vi vill genomföra förändringarna och hur förändringen ska se ut när den är klar, innan vi tar fram en lösning. Beskrivningarna blir ett underlag för den dialog som ligger till grund för analysen, planeringen och genomförandet av förändringarna. Vi kan även mäta och peka på var vi uppnått effekten av våra genomförda förändringar.

7 (20) 2.1 Verksamhetsmodeller i olika dimensioner och vyer Modeller är en förenkling av verkligheten och genom att rita olika delar i olika modeller så kan vi se verksamheten i olika perspektiv till skillnad från om vi gör en modell med allt i. Figur 2. Visar hur olika dimensioner används för att visa ett hus i olika dimensioner. Att jämföra med att process och information som dimension för att beskriva verksamheten. Vi har valt att dela upp våra verksamhetsbeskrivningar i dimensioner. De tre primära dimensioner är process, information och applikation. Dessa dimensioner kan man välja att titta på och beskriva i olika vyer beroende på vilka frågor vi behöver ha svar på. Vyer anpassas utifrån betraktares egna utgångspunkter d.v.s. vad man vill se och vilken fråga man behöver ha svar på. Ledningen vill se övergripande beskrivningar över mål och strategier och It-teknikern vill se vilka delar av applikationerna som kopplar till vilka databaser. Verksamheten vill se vilka processer som koppla till vilka applikationer. Ekonomen vill se fastighetsförteckningen i Excel och lantmätaren vill se en karta med fastigheter. I vår metodik ingår standardiserade vyer efter nivåer och behov.

8 (20) 2.2 Verksamhetsmodeller i olika nivåer Modeller beskriver verksamheten i flera nivåer. Nivå 1 är den mest övergripande nivån för verksamhetsbeskrivningar medan nivå 5 beskriver verksamheten mer i detalj. Figur 3. Beskriver nivåerna 1-4. De övergripande nivåerna används för styrning, planering och uppföljning. De mer detaljerade nivåerna används för analys och utveckling av en specifik verksamhet. De vanligaste dimensionerna i Sundsvall är process, information och applikation. Det finns även objekt för till exempel styrning (mål, nyckeltal etc.), organisation, data och förmågor. För att skapa störst värde av våra verksamhetsbeskrivningar och förstå vad som styr vår utveckling och vilka förändringar som ska prioriteras vill vi gärna koppla dimensioner till varandra. Till exempel koppla kartlagda processer till de strategier och mål som definierats i verksamhetsplaner, eller koppla processer till applikationer och information för att uppnå återanvändning och nytta. Då får vi en röd tråd som leder oss och gör att vi kan ta bättre beslut vid design och utveckling.

Figur 4. Beskriver nivåerna 3-5 där nivå 5 är den mest detaljerade nivån. Vidare ses i hur dimensioner Process, Information och Applikation bryts ner och benämns i de olika nivåerna. För att se hela se figur 11, Sundsvalls kommuns arkitekturramverk. 9 (20)

3 Beskrivning av de olika dimensionerna i modellering 3.1 Processmodellering En process är en aktivitet eller en serie av aktiviteter som i ett återkommande flöde skapar värde för kund. - Definition av Sundsvalls kommun Koncernutveckling IT 10 (20) Processer uppstår omkring oss dagligen, både i vårt arbete och i våra privatliv. Att vakna, äta frukost, åka till jobbet och stämpla in är en process i sig. Det kan finnas många orsaker till att fundera på hur våra processer fungerar, till exempel för att se var man kan spara tid, genom att åka taxi till jobbet, eller för att se om det finns ett billigare sätt, kanske genom att ta bussen. Då kanske man även kan äta sin frukost i bussen för att spara tid? Processmodellering och processanalys har etablerats sen sent 1700-tal och sättet att notera och förändra genom processarbete har praktiserats och förfinats till att idag vara ett av de viktigaste verktygen inom verksamhetsutveckling. Processmodellering är ett effektivt verktyg för att skapa gemensam kunskap om vår verksamhet. När man kartlägger eller designar sina processer flyter mycket upp till ytan som är användbart när man utvecklar sin verksamhet. Det är inte bara processen som hamnar i fokus utan vi talar även om Organisationen Informationen Applikationer och IT-stöd Problemställningar Idéer till förbättringar Aha-upplevelser och samsyn Det centrala i processmodellen är processerna, men det centrala i processmodellering är att få fram så mycket bra kunskap om verksamheten så att vi täcker mer än endast processen. När vi modellerar processer skapar vi ofta modeller som är linjära i sin exekvering av aktiviteter, möjligen med en eller annan alternativ väg. Verklighetens processer är ofta mer komplexa företeelser, speciellt i manuella processer där interaktionen mellan människor är central. Så hur väljer vi vilket flöde eller scenario vi ska modellera? Om vi vänder på det hela och skulle dokumentera hur vi utfört våra aktiviteter över tid skulle vi hitta ett antal centrala mönster som vi oftast använder oss av. Dessa mönster liknar de modeller som vi tar fram i vår processkartläggning och försöker skapa i vår design av vårt framtida läge. Om vi skulle kartlägga alla möjliga vägar en process kan ta får vi i det närmaste ett oändligt antal processmodeller. Detta vill vi undvika.

11 (20) Figur 5. Processmodell nivå 3 exempelvis Planera projekt kopplat till Verksamhetsobjekt projektplan. Alla processer färgkodas grön och information beige. 3.1.1 Verksamhetsobjekt är vår koppling till informations- och datamodellering I de flesta av modellerna vill vi även kunna utläsa vilket värde det är som skapas i våra processer och vi visualiserar dem ofta i våra processmodeller. Värdet representeras av så kallade verksamhetsobjekt som ofta noteras i en processmodell. Ett verksamhetsobjekt ska beskriva resultatet av en process (vad vi vill producera). På så sätt får vi reda på vilken typ av information som omfattas av vår förändring samt nya krav på information. Varje verksamhetsobjekt innehåller information om olika saker i verksamheten som vi vill hantera, spara eller presentera på något sätt. Vi använder oss av så kallade informationsobjekt för att beskriva dessa objekt och visar dessa i grafiska diagram. 3.2 Informationsmodellering I en process får man fram verksamhetsobjekt. Ett verksamhetsobjekt kan t.ex. vara en ansökan. Informationen som finns i ansökan går att dela upp, exempelvis i vilken typ av ansökan det är, vad den heter och vilken åtgärd som efterfrågas. För att få störst nytta av informationen i ansökan är det viktigt att informationen inte är bunden till papperet/blankett utan information bör struktureras och finnas tillgänglig via en databas. På så sätt blir värdefull information till data som kan användas i en applikation. För att lyckas med detta är det viktigt att i nära samarbete med verksamheterna ta fram informationsmodeller. Det gör att vi kan hitta återanvändbar information som kan användas i beräkningar och statistik eller visualiseras i en karta eller ett diagram. En informationsmodell visar verksamhetenskrav på informationen och ligger till grund för datamodellen.

12 (20) Figur 6. Beskriver hur vi kommer från verksamhetens krav utifrån process och hur data och applikation ska utformas. Informationsobjektet skiljer sig från den övriga arkitekturramverkets struktur, se figur 6, då den är komponerad efter värde, inte efter en hierarkisk struktur. Jämför med processen då den bryts ner hierarkisk från nivå 1 till nivå 5, in zooming. Se gärna filmen om nivåer på utveckling.sundsvall.se https://youtu.be/bophug7sza8 Figur 7. Exemplet ovan visar hur processer zoomas från nivå 1 till nivå 5. Detta görs inte i informationsdimensionen där Entitetsgrupp inte är en in zoomning av Informationsobjekt.

Det är information om ett verkligt föremål (verksamhetsobjekt) som är av betydelse för verksamheten. Det är en mängd informationsentiteter som vi tar med oss t.ex. ut på en picknick. Det hämtas ur sorterade lådor entitetsgrupper, t.ex. besticklådan, kylen, skafferiet och filtlådan. Informationsobjektet dokumenterar det vi vill flytta mellan applikationer, organisationer m.m. det vill säga gränssnitt eller informationsöverföringsformat. 13 (20) Figur 8. Förklarar skillnaden mellan informationsobjekt och entitetsgrupp. 3.3 Applikationsmodellering Applikationer (IT-system) beskrivs precis som övriga dimensioner i olika nivåer, se figur 14. Ofta vill vi veta vilka applikationer (system) vi använder i vårt arbete och ställa krav på förbättringar eller nya funktioner när vi förändrar i vår verksamhet. När vi gör vår processmodellering så är det väldigt enkelt att ställa frågan vilken eller vilka applikationer som används i en viss process. På så sätt kan vi snabbt kartlägga och koppla vilka applikationer som omfattas av kravställning och var vi till exempel saknar IT-stöd idag. Applikationsdimensionen kopplas ofta till informationsdimensionen, vilket ger stor nytta. Vi kan då säkra att informationen i våra system återanvänds på ett strukturerat, säkert och systematiskt sätt till exempel om en databas eller applikation stängs ner vilka konsekvenser det ger.

14 (20) Arbete med att applikationsmodeller är också direkt koppat till systemförvaltningsarbete t.ex. hur IT-system grupperas och beskrivs. Figur 9. Utdrag ur applikationsmodell nivå 1 och 2. 3.4 Datamodellering Data är implementationen av informationen. Informationsmodellen är önskat läge av verksamheten och kan användas i kravställning t.ex. vid upphandling eller utveckling av ett system medan datamodellen är det som applikationen använder. I arbetet att följa Dataskyddsförordningen har applikationsmodeller och datamodeller tagits fram för att t.ex. hitta personuppgifter. Alla personuppgiftsbehandlingar ska föras i ett register över personuppgiftsbehandlingar. 3.5 Övriga dimensioner Det finns fler dimensioner som kommer att bearbetas i framtida uppdatering i arkitekturmetodiken t.ex. styrning, organisation och förmåga.

15 (20) 4 Symboler och språk för att rita modeller Nedan presenteras de vanligaste objekten för respektive dimension. 4.1 Processer Nivå Objekt (Symbol och namn på de olika nivåerna) Definition 1 En logisk gruppering av processgrupper som skapar struktur och översikt i processkartan. Exempel på processområden är Ledningsprocesser, Kärnprocesser och Stödprocesser. 2 En logisk gruppering av processer som tillsammans skapar ett värde i verksamheten. Exempel på processgrupper är "Hantera Ekonomi", "Planera Verksamhet", och "Erbjuda vara/tjänst". 3 En kedja av aktiviteter som i ett återkommande flöde skapar ett värde för en eller flera kunder. Exempel på processer är "Fakturera kund", "Rekrytera personal" och "Utforma lösning". 4 Ett processteg är en serie aktiviteter som tillsammans, men inte var för sig, skapar en artefakt. Exempel på processteg är "Attestera leverantörsfaktura", "Skapa kravprofil" och "Tillaga mat". 5 En uppgift som utförs av en person (vanligtvis), vid ett tillfälle utan tidsluckor. Exempel på aktiviteter är "Stämma av erhållen vara/tjänst mot faktura", "Stämma av kravprofil med beställare" och "Paketera mat i matlåda". Aktivitetsflödesmodeller modelleras med BPMN-objekt. Figur 10. Beskriver de objekt vi använder idag när vi tar fram en processmodell.

16 (20) 4.2 Information Nivå Objekt Definition 1 En gruppering av informationsgrupper i syfte att skapa översikt och struktur. Exempel på informationsdomäner är Ledningsinformation, Kartinformation och Stödinformation. 2 En gruppering av informationsobjekt eller entitetsgrupper i syfte att skapa översikt och struktur. Exempel på informationsdomäner är Verksamhetsplaneringsinformation, Produktionsinformation och Ekonomiinformation. 3 Representationen av den information om ett verkligt föremål (verksamhetsobjekt) som är av betydelse för verksamheten. Används i verksamhetens tjänsteflöden för att beteckna input och output för en verksamhetsfunktion och för att beskriva kravställning på information avseende struktur och innehåll. Exempel på informationsobjekt är: Kundbeställning, Utleverans av varor, Verksamhetsplan och bokslut. 4 En gruppering av informationsentiteter i syfte att skapa en effektiv informationsförsörjning och hög informationskvalitet. Exempel på entitetsgrupper är Organisation, Anläggning, Produkt och Order. 5 En inkapsling av information som representerar en unikt identifierbar informationsmängd med ingående informationsattribut, relationer till andra entiteter samt exempel på förekomster. Exempel på informationsentiteter är "Order", "Orderrad" och "Leveransadress". Figur 11. Beskriver de objekt vi använder idag när vi tar fram en informationsmodell. Se även dokumentet Riktlinjer för informationsmodeller Sparx EA 1.0

17 (20) 4.3 Applikation Nivå Objekt Definition 1 En samling av applikationer som tillsammans gör det möjligt för verksamheten att utföra arbetet på ett effektivt sätt. Exempel på applikationsområde är "Kartsystem", "Ekonomisystem" och "HR-system". 2 Det IT-stöd som användarna vanligen talar om när de beskriver vilka system som de arbetar med. Kallas även i dagligt tal för System*. Exempel på applikationer är Bokningssystem och Ärendehanteringssystem (vanligen med namn som givits av leverantören exempelvis Heroma). 3 En applikationsmodul är en självständig logisk del av en större applikation som har givits ett specifikt syfte, t ex att samla in data, stödja en verksamhetsprocess eller skapa rapporter. Exempel på moduler kan vara fakturamodul. 4 En applikationsfunktion grupperar automatiserade uppgifter som kan utföras av en applikationsmodul. Exempel på applikationsfunktioner är Hantera faktura, Beställa dator. 5 En applikationsuppgift är den automatiserade funktionen av en processaktivitet utförd av en applikation. Exempel på applikationsuppgifter är "Lägga till artikel på faktura", "Ändra beställt antal" och "Bekräfta lagd beställning". Figur 12. Beskriver de objekt vi använder idag när vi tar fram en applikationsmodell.

18 (20) 4.4 Data Nivå Objekt Definition 1 En gruppering av datagrupper i syfte att skapa översikt och struktur. Exempel på datadomäner är Ledningsdata, Kartdata, och HR-data. 2 En gruppering av datakomponenter i syfte att skapa översikt och struktur. Exempel på Datagrupper är Verksamhetsplaneringsdata, Produktionsdata och Ekonomidata. 3 En sammanhängande samling av data som är en del av en applikation. Exempel på datakomponenter är "Orderdata" och "Kunddata". 4 En logisk gruppering av relaterad data som representerar en vy av ett informationsobjekt. Exempel på dataobjekt är "Kund" som omfattar data relaterad till Person och Adresser. Ett annat exempel är Order" som omfattar data relaterad till ingående Orderrader och dess produkter samt Leveransadress. 5 En abstraktion av den fysiska implementationen av en eller flera datatabeller. Exempel på dataentiteter är "Order", "Orderrad", "Leveransadress" och Faktureringsadress. Figur 13. Beskriver de objekt vi använder idag när vi tar fram en datamodell.

19 (20) 5 Sundsvalls arkitekturramverk Figur 14. Beskriver dimensioner och vilka grafiska beskrivningar samt namn på de olika nivåerna som används idag.

20 (20) 6 Sammanfattning Verksamheten kan beskrivas med hjälp av olika objekt som sätts ihop i modeller. Beskrivningarna kan göras i olika dimensioner och på olika detaljnivåer. Nedan ses ett exempel på hur det kan se ut för dimensionen process i flera nivåer. Bilden beskriver nivåerna, objekten och dess olika vyer. NIVÅ DIMENSION VY Figur 15. Beskriver ett exempel på hur nivåer, grafisk beskrivning och namnsättning samt vyer hör ihop. 7 Kontaktinformation Sundsvalls kommuns utvecklingsportal innehåller mer information och matrial: https://utveckling.sundsvall.se/ Kontakta gärna Sundsvalls kommuns, kommunstyrelsekontoret, (EA-Center) via it-stab@sundsvall.se för mer information och hur du kan få stöd i ditt utvecklingsarbete.