Introduktion till verksamhetsmodellering

Introduktion till verksamhetsmodellering

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

2 (26) 1 Innehållsförteckning 1 Innehållsförteckning... 2 Ordlista... 5 1 Inledning... 6 1.1 Målgrupp... 6 1.2 Syfte... 6 1.3 Avgränsning... 6 2 Beskriva verksamheten & skapa samsyn genom modellering... 7 2.1 Verksamhetsmodeller i olika dimensioner och vyer... 8 2.2 Verksamhetsmodeller i olika nivåer... 9 3 Beskrivning av de olika dimensionerna i modellering... 11 3.1 Affärsmodellsmodellering... 11 3.2 Processmodellering... 11 3.2.1 Verksamhetsobjekt är vår koppling till informations- och datamodellering... 12 3.3 Informationsmodellering... 13 3.4 Applikationsmodellering... 15 3.5 Datamodellering... 16 3.6 Övriga dimensioner... 16 4 Symboler och språk för att rita modeller... 17 4.1 Processer... 17 4.2 Information... 18 4.3 Applikation... 19 4.4 Data... 20 5 Sundsvalls arkitekturramverk... 21 6 Sammanfattning... 22 7 Att dokumentera utvecklingsarbetet... 23 7.1 Gör rätt från början!... 23 7.2 Komma igång med modelleringen... 23 7.2.1 Meddela EA-center att ni är intresserade av att modellera i ert projekt... 23 7.2.2 Få tillgång till Sparx EA... 24 7.2.3 Utveckla modeller... 24

3 (26) 7.3 Checka in modeller... 24 7.3.1 Kvalitetssäkring av modell... 24 7.3.2 Begäran om incheckning av modell... 25 7.3.3 Granskning av modell... 25 7.3.4 Incheckning av modeller... 25 7.3.5 Publicering... 25 8 Kontaktinformation... 26

4 (26) 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 1.2 2019-10-03 Lagt till affärsmodellsdimensionen Lagt till kapitel om in- och utcheckning Petronella Enström Thomas Norlin Adam Stålhult Filippa Danared 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

5 (26) Ordlista Modell: Objekt: Dimension: Perspektiv: 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. För oss synonymt med dimension. Nivå: 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). Vy: Verksamhetsmodeller: Affärsmodell: Processmodell: Informationsmodell: Datamodell: EA-Center: Arkitekturvyer är representationer av den övergripande arkitekturen som är betydelsefull för en eller flera intressenter i arkitekturen. Arkitekten väljer och utvecklar en uppsättning vyer som gör att arkitekturen kan kommuniceras till och förstås av alla intressenter och att arkitekturvyn besvarar de frågeställningar som verksamheten har. 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. EA är en förkortning för Enterprise Architecture. I Sundsvall finns ett team med arkitekter som jobbar tillsammans i det som kallas EA-Center.

6 (26) 1 Inledning Sundsvalls kommun utgår i sitt arbete med verksamhetsbeskrivningar från befintliga standarder Prime Arch, BPMN, TOGAF och ArchiMate. När det gäller definitioner har vi utgått ifrån SS-ISO/IEC/IEEE 42010 (en internationell standard för systemarkitektur). system.) 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 affärsmodell, process, information, applikation och data.

7 (26) 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.

8 (26) 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. Varje verksamhet har på översta nivån en affärsmodell. Affärsmodellen kopplar vidare till 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.

9 (26) 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.

10 (26) 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.

11 (26) 3 Beskrivning av de olika dimensionerna i modellering 3.1 Affärsmodellsmodellering 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. Som beskrivs i figur 1 är affärsmodellerna lagret mellan strategi och process. Affärsmodellerna innehåller främst värdeerbjudande men kopplar också till processer, kompetenser och kunder. Vi utgår ifrån Alex Osterwalders ramverk. Utöver det ramverket har vi också lagt till nivå 2 och 3 inspirerat från Cordial. Figur 5. Ett exempel på en affärsmodell nivå 1. 3.2 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 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

12 (26) 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. Figur 6. Processmodell nivå 3 exempelvis Planera projekt kopplat till Verksamhetsobjekt projektplan. Alla processer färgkodas grön och information beige. 3.2.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å

13 (26) 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.3 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. Figur 7. 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

14 (26) Figur 8. 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.

15 (26) Figur 9. Förklarar skillnaden mellan informationsobjekt och entitetsgrupp. 3.4 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. Arbete med att applikationsmodeller är också direkt koppat till systemförvaltningsarbete t.ex. hur IT-system grupperas och beskrivs.

16 (26) Figur 10. Utdrag ur applikationsmodell nivå 1 och 2. 3.5 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.6 Övriga dimensioner Det finns fler dimensioner som kommer att bearbetas i framtida uppdatering i arkitekturmetodiken t.ex. styrning, organisation och förmåga.

17 (26) 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 11. Beskriver de objekt vi använder idag när vi tar fram en processmodell.

18 (26) 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 12. 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

19 (26) 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 13. Beskriver de objekt vi använder idag när vi tar fram en applikationsmodell.

20 (26) 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 14. Beskriver de objekt vi använder idag när vi tar fram en datamodell.

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

22 (26) 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 16. Beskriver ett exempel på hur nivåer, grafisk beskrivning och namnsättning samt vyer hör ihop.

7 Att dokumentera utvecklingsarbetet 7.1 Gör rätt från början! 23 (26) Skapandet av modeller kan ske på olika sätt, men ofta sker det genom någon typ av workshop där olika delar av verksamheten slår sina kloka huvuden ihop för att skapa en dokumenterad bild av verkligheten. Det slutgiltiga resultatet ska dokumenteras i kommunens modelleringsverktyg Sparx EA. För att slippa dubbelarbete är det mest effektivt att dokumentera allt material där på en gång. Dock är inte alla helt bekanta med Sparx EA så för att kunna sätta igång arbetet kan arbetsmaterial dokumenteras på olika sätt: post-it-lappar på väggen, PowerPoint, Visio etc. När ett slutgiltigt resultat har fastställts kan man i efterhand modellera in det i Sparx EA för att få det incheckat i kommunens gemensamma databas. Dock är det viktigt att komma ihåg skillnaden mellan metod och verktyg. Flera verktyg kan användas under arbetet även om materialet i ett sista steg av projektet till slut måste modelleras in i Sparx EA. Däremot borde metoden följas genom hela arbetets gång. Med metod menas vilka objekt som används, vilka definitioner objekten har, att objekten ligger på rätt nivå, att objekt och modeller är namnsatta korrekt och att modellen ser ut så som kommunen har bestämt. Om man inte följer metoden från början utan modellerar på sitt eget sätt i t.ex. Visio kan det uppstå problem när projektet är klart och man vill checka in sina modeller eftersom modeller som inte följer metoden inte kan checkas in. Då kanske projektgruppen i efterhand måste omvalidera vilka nivåer man håller sig på, kanske bryta isär objekt som inte håller samma nivå, döpa om objekt etc förändringar som kräver ytterligare diskussion och förankring i projektgruppen. Då är det bättre att gå igenom metoden ordentligt innan man sätter igång så att man följer rätt metod från början, oavsett vilket verktyg man väljer att jobba i. 7.2 Komma igång med modelleringen När du ska modellera finns EA-center som ett stöd i processen. För att komma igång tar man ofta följande steg. 7.2.1 Meddela EA-center att ni är intresserade av att modellera i ert projekt EA-center distribuerar material och handböcker som har tagits fram som stöd, både för metod och verktyg. EA-center sätter upp en projektmapp för ert projekt i Sparx EA. Om projektet ska vidareutveckla befintligt material kommer detta checkas ut av EAcenter och läggas i projektmappen. Länk att läsa mer om modelldriven utveckling: https://utveckling.sundsvall.se/modelldriven-utveckling/

24 (26) 7.2.2 Få tillgång till Sparx EA För att få tillgång till Sparx EA krävs att ni både får själva applikationen och får tillgång till Sundsvalls gemensamma databas. För detta kontaktar ni digitaliseringochinnovation@sundsvall.se I samband med att du skickar in och önskar tillgång till den gemensamma databasen får du ett användarnamn och lösenord samt en manual som beskriver hur du ansluter externt eller internt. 7.2.3 Utveckla modeller Utveckla modeller i ert projekt. Även här finns stöd att få från EA-center i form av facilitering och metodstöd. 7.3 Checka in modeller När era modeller är klara ska de checkas in i kommunens gemensamma databas. För att få checka in modeller i kommunens gemensamma databas måste de följa kommunens metod. Innan ni meddelar att ni vill checka in material behöver ni därför säkerställa att modellerna gör det. 7.3.1 Kvalitetssäkring av modell Modellerna ska vara korrekta enligt designregler Rätt objekt ska användas för rätt nivåer och dimensioner. I Processmodelleringshandboken (kontakta digitaliseringochinnovation@sundsvall.se för tillgång) finns tydliga instruktioner för hur processmodeller på olika nivåer ska se ut och vad man ska tänka på. Fler dimensioner finns övergripligt beskrivna i detta dokument. Relationer mellan modeller ska vara korrekta Om dina modeller hänger ihop med annat incheckat material i databasen måste denna koppling markeras. Om ett flöde är en fortsättning på ett redan existerande flöde ska angränsande flöden ritas in i modellen. Om en modell är en mer detaljerad bild (lägre nivå) på en existerande modell ska ramobjekt ritas in i modellen. Återanvändning av objekt ska vara korrekt Om objekt redan finns i databasen ska dessa återanvändas för att inte skapa dubbletter. Särskilt troligt att objekt redan finns är för applikations-dimensionen. Objekt och modeller ska vara korrekt sorterade i Project Browser Allt skapat material sorteras hierarkiskt i Project Browser. Om objekt på flera nivåer har skapats betyder det att objekt och modeller ska ligga i det objekt de ingår i. Om alla nyskapade objekt är på samma nivå betyder det att ni behöver identifiera det överliggande objektet i redan incheckat material. Om materialet är helt nytt och inte är relaterat till något

25 (26) annat i databasen behöver detta anges vid begäran om incheckning. Se även till att alla oanvända objekt är borttagna. Figur 17. Project Browser i verktyget Sparx. 7.3.2 Begäran om incheckning av modell När era modeller är kvalitetssäkrade sickar ni in en begäran om incheckning till EA-center: digitaliseringochinnovation@sundsvall.se Information som behöver anges är: Projektnamn Modellnamn Var i befintligt material modellen ska checkas in (om inte detta påvisas i modellen genom ramobjekt och/eller angränsande flöden) 7.3.3 Granskning av modell EA-center gör en granskning av materialet innan det checkas in. Om det finns brister i materialet kommer ni ombes korrigera det. 7.3.4 Incheckning av modeller Materialet placeras in enligt förvaltningsstrukturen i databasen. När materialet är incheckat meddelar EA-center projektet att materialet är incheckat samt var i strukturen man kan hitta det. 7.3.5 Publicering

En gång i månaden publicerar EA-center allt incheckat material i databasen. Publiceringen finns tillgänglig på https://utveckling.sundsvall.se/modellbibliotek-beta/ 26 (26) 8 Kontaktinformation Sundsvalls kommuns utvecklingsportal innehåller mer information och material: https://utveckling.sundsvall.se/ Kontakta gärna Sundsvalls kommuns, kommunstyrelsekontoret, (EA-Center) via digitaliseringochinnovation@sundsvall.se för mer information och hur du kan få stöd i ditt utvecklingsarbete.