Metod för verksamhets- och

informationsbehovsanalys

VIA-metoden

Version 6.3 2016-09-01

Torsten Lundmark 070-3733505 torsten.lundmark@llcon.se Jessica Rosenälv 08-12318663 jessica.rosenalv@sll.se

Citera och använd gärna bilder men ange källan.

Sida 1

Förord En verksamhet har alltid ett visst syfte som anger varför den finns. Verksamhet-ens vision är det som driver verksamheten framåt och anger en riktning för verksamhetseffektivisering och därmed verksamhetsutveckling.

För att kunna tydliggöra verksamhetens möjlighet att nå sin vision bör det fin-nas en helhetsbild som beskriver verksamhetens nuläge, börläge samt hur man bör förflytta sig från nuläget till börläget och därmed lättare uppnå sin vi-sion.

För detta behövs någon form av analys och beskrivning av den verksamhet som avses. För att kunna beskriva verksamheten behöver man genomföra en verk-samhets- och informationsbehovsanalys, helst enligt en gemensam och över-enskommen metod som gör att resultaten blir konsekvent beskrivna och jäm-förbara.

I denna handbok beskrivs en metod för verksamhets- och informationsbehovs-analys, VIA-metoden, utgångspunkterna till varför en sådan metod behövs och i vilka sammanhang den är lämplig att använda.

Syftet är att åstadkomma en effektiv och resurssnål verksamhets- och in-formationsbehovsanalys för en optimal verksamhetsbeskrivning.

Vi vill tacka alla som under arbetets gång har bidragit med synpunkter. Vi vill särskilt tacka Sven-Bertil Wallin, Rolf Wohed, Karl-Henrik Lundell, Dipak Kalra, Stephen Kay samt Sebastian Wogenius för deras värdefulla kommenta-rer.

Jessica Rosenälv Torsten Lundmark

Stockholm 2016-09-01

Sida 2

Innehållsförteckning Förord ................................................................................................................................. 11 Inledning ...................................................................................................................... 42 Att uppnå verksamhetens vision ................................................................................. 72.1 Verksamhetens vision, målbild och strategier ........................................................................ 72.2 Olika steg i ett analys- och förändringsarbete ..................................................................... 102.3 Vad ingår i beskrivning av verksamhetens nu- och börläge samt dess

informationshantering? .................................................................................................. 133 Vägen till semantisk interoperabilitet ........................................................................ 163.1 Behov av gemensam verksamhetssyn ................................................................................... 163.2 Förutsättning för en semantisk interoperabilitet ................................................................ 183.3 Behov av gemensam metod för verksamhets- och informationsbehovsanalys ................... 204 Verksamhets- och informationsbehovsanalys utifrån olika aspekter ....................... 214.1 Fokus för VIA-metoden ......................................................................................................... 234.2 Mål- och intressentanalys ..................................................................................................... 304.2.1 Syfte och mål med metodsteget ......................................................................................... 304.2.2 Hur gör man? ..................................................................................................................... 324.2.3 Notationssätt ...................................................................................................................... 324.3 Processanalys ........................................................................................................................ 344.3.1 Analys av processer ur ett värdeförädlingsperspektiv ....................................................... 344.3.2 Verksamhetens processer och dess beroenden ................................................................. 394.3.3 Syfte med metodsteget ...................................................................................................... 404.3.4 Hur gör man? ..................................................................................................................... 404.3.5 Notationssätt ...................................................................................................................... 414.3.6 Analys av processer ur ett samverkansperspektiv ............................................................ 434.3.7 Syfte med detta metodsteg ................................................................................................. 444.3.8 Hur gör man? ..................................................................................................................... 454.3.9 Notationssätt ...................................................................................................................... 454.4 Begreppsanalys ..................................................................................................................... 464.4.1 Syfte med metodsteget ....................................................................................................... 484.4.2 Hur gör man? ..................................................................................................................... 494.4.3 Notationssätt ...................................................................................................................... 494.4.4 Begreppsanalys och terminologiarbete .............................................................................. 514.5 Informationsanalys ............................................................................................................... 524.5.1 Informationsbehovsanalys ................................................................................................. 524.5.2 Syfte med metodsteget ....................................................................................................... 534.5.3 Hur gör man? ..................................................................................................................... 534.5.4 Notationssätt ...................................................................................................................... 534.6 Informationsstrukturanalys ................................................................................................. 55

Sida 3

4.6.1 Syfte med metodsteget ....................................................................................................... 554.6.2 Hur gör man? ..................................................................................................................... 554.6.3 Notationssätt ...................................................................................................................... 564.7 Analys gällande behov av kodverk, klassifikationer och terminologier .............................. 574.7.1 Syfte med detta metodsteg ................................................................................................. 574.7.2 Hur gör man? ..................................................................................................................... 585 Från branschramverk till tillämpade beskrivningar ................................................. 595.1 Förhållandet mellan branschramverk och tillämpade beskrivningar .................................. 595.2 Från det abstrakta till det konkreta inom informationshantering ur ett IT-perspektiv ..... 626 Helhetssyn på hälso- och sjukvård ............................................................................ 647 En effektiv kravställning med VIA-metoden ............................................................. 687.1 Metodik, metod, process ....................................................................................................... 687.2 Verksamhetsdriven IT-utveckling ........................................................................................ 687.3 Utvecklingsprocess ................................................................................................................ 697.3.1 Leverabler från delprocess Verksamhetsanalys ................................................................. 717.4 Process för vägledning av verksamhets- och informationsbehovsanalyser utifrån

gemensamma riktlinjer .................................................................................................. 727.4.1 Information ........................................................................................................................ 737.4.2 Introduktion ....................................................................................................................... 737.4.3 Avstämning ........................................................................................................................ 757.4.4 Granskning ......................................................................................................................... 767.4.5 Leveransmottagande .......................................................................................................... 787.4.6 Koppling mellan PROJEKTiL och VIA funktion ............................................................... 798 Kompetenser, roller och ansvar ................................................................................ 80Bilaga 1. Övergripande bild av metodsteg ....................................................................... 84Bilaga 2. Bild över innehåll i metodsteg .......................................................................... 85Bilaga 3. Problembild för verksamheten, dess informationshantering och IT-stöd . 86Bilaga 4. Kompetenser, roller, ansvar ............................................................................. 93Bilaga 5. Mall för beskrivning av intressenter ................................................................. 97Referenser ........................................................................................................................ 98

Sida 4

1 Inledning En verksamhet har alltid ett visst syfte som anger varför den finns. Verksamhet-ens vision är det som driver verksamheten framåt och anger en riktning för verksamhetseffektivisering och därmed verksamhetsutveckling.

För att kunna tydliggöra verksamhetens möjlighet att nå sin vision bör det fin-nas en helhetsbild som beskriver verksamhetens nuläge, börläge samt hur man bör förflytta sig från nuläget till börläget och därmed lättare uppnå sin vis-ion.

För detta behövs någon form av analys och beskrivning av den verksamhet som avses. Dels en beskrivning av ett nuläge men framförallt också en beskrivning som visar på en, av verksamhetsföreträdare överenskommen, bild av hur en framtida verksamhet bör vara utformad. Denna verksamhetsbeskrivning bör i de flesta fall omfatta flera olika aspekter för en större förståelse av verksamhet-en.

För att kunna beskriva verksamhetens nu- och börläge behöver man genomföra en verksamhets- och informationsbehovsanalys, helst enligt en gemensam och överenskommen metod som gör att resultaten blir konsekvent beskrivna och jämförbara.

I denna handbok beskrivs en metod för genomförande och dokumentation av verksamhets- och informationsbehovsanalys, VIA-metoden, men också ut-gångspunkterna till varför en sådan metod behövs och i vilka sammanhang den är lämplig att använda.

VIA-metoden används för analys och beskrivningar av en verksamhet. De fram-tagna beskrivningarna är underlag för olika syften, bland annat för att ta fram en helhetsbild av verksamheten som grund för verksamhetsutveckling, utveckl-ing av verksamhetens informationsförsörjning, framtagande av IT-strategier samt kravställning av IT-stöd.

Att använda en vedertagen och organisationsgemensam metod i verksamhets-analysarbeten säkerställer att resultatet är användbart för sitt syfte och håller en hög kvalitet samt ökar möjligheterna till att jämföra och återanvända olika ana-lysresultat.

Den beskrivna metoden utgörs av ett antal delar vilka var och en har utvecklats och använts under lång tid för analys av verksamhetsområden inom hälso- och sjukvården samt applicerats på ett antal olika initiativ, både på regional och na-tionell nivå.

En verksamhets- och informationsbehovsanalys tar alltid hänsyn till tre olika delar samtidigt, vilket illustreras i bilden nedan. Det är dessa delar som definie-rar analysens utgångspunkt och innehåll.

Sida 5

Bild 1. Tre olika dimensioner definierar analysens utgångspunkt och innehåll

Perspektiv – Inför en analys måste man bestämma vilket eller vilka perspektiv som ska analyseras och beskrivas. Den egentliga verksamheten, dess informat-ionshantering eller kravställning av IT-stöd som ska stödja verksamheten i dess informationshantering? En analys av informationshanteringen förutsätter dock att man först gjort en analys av verksamheten, och på samma sätt gäller att en kravställning av IT-stöd kräver att en verksamhets- och informationsbehovsa-nalys har genomförts.

Tidsdimension – Man måste ta ställning till vilken tidsdimension som är re-levant för analysen. Är det ett nuläge eller ett börläge som ska analyseras och beskrivas? Om man vill genomföra en förflyttning av respektive perspektiv (verksamheten, dess informationshantering, IT-stöd) till ett börläge är det nöd-vändigt att först ha gjort någon nulägesanalys för att kunna ta fram en plan för denna förflyttning.

Aspekt – Varje perspektiv har ett antal aspekter som bör analyseras och besk-rivas. För verksamhetsperspektivet är det angeläget att till exempel analysera dess mål, intressenter, processer och de begrepp som är centrala i verksamhet-en.

Sida 6

Avgränsning

VIA-metoden fokuserar på framtagande av grundläggande regelverk utifrån verksamhetens behov, det vill säga beskrivningar av verksamheten och dess in-formationshantering. För IT-stödsutveckling behöver man därefter ta fram tek-niska beskrivningar baserade på dessa grundläggande regelverk. Hur man tar fram sådana tekniska beskrivningar hanterar inte VIA-metoden.

Metod för optimal verksamhets- och informationsbehovsanalys

Vår mångåriga erfarenhet med verksamhets- och informationsbehovsanalys ligger till grund för sammanställning av dessa erfarenheter och skapandet av VIA-metoden. Under arbetet med att koppla ihop olika kunskapsområden har vår förståelse av ämnet fördjupats vilket har resulterat i en sammantagen me-todbeskrivning som presenteras i boken.

Under ett iterativt arbete med framtagande av metoden har vi successivt fördju-pat och preciserat beskrivningen av metodstegen och hur de förhåller sig till varandra. Syftet har varit att kunna åstadkomma en effektiv och resurssnål verksamhets- och informationsbehovsanalys för att kunna ta fram en optimal verksamhetsbeskrivning som kan användas för olika syften.

Vi har också beskrivit ett antal olika situationer i vilka en gemensam metod är relevant och är av stort värde som till exempel vid framtagande av branschram-verk, vid framtagande av helhetsbild av en verksamhet men också vid en fördju-pad och detaljerad beskrivning av verksamhets- och informationsbehovsanalys.

Handboken riktar sig till experter som arbetar med strategiska frågor, exempel-vis framtagande av en verksamhets målbild och strategier för att uppnå denna, men också experter som arbetar med framtagande av branschramverk samt verksamhetsutveckling och dess informationsförsörjning. I sådana arbeten in-går bland annat verksamhets- och informationsbehovsanalyser, informations-strukturering samt kravställning av IT-stöd.

För närvarande finns ingen branschstandard inom vård och omsorg vad gäller metod för verksamhets- och informationsbehovsanalys. En sådan gemensam metod bör finnas och dessutom användas inom exempelvis en verksamhet eller bransch. Genom att verksamheten och dess informationshantering är beskriven på ett jämförbart sätt möjliggörs att resultat av verksamhetsanalysarbete kan återanvändas, sammanställas och jämföras mellan olika organisationer.

Sida 7

2 Att uppnå verksamhetens vision En verksamhet har alltid ett visst syfte som anger varför den finns. Verksamhet-ens vision är det som driver verksamheten framåt och anger en riktning för verksamhetseffektivisering och därmed verksamhetsutveckling.

2.1 Verksamhetens vision, målbild och strate-gier Det är av ett stort värde att verksamheten har en gemensam, överenskommen och förankrad vision om vad verksamheten är till för. En vision behöver inte vara mätbar eller ens vara helt realistisk.

Bild 2. Verksamheten strävar efter att nå sin vision

För att kunna tydliggöra verksamhetens möjlighet att nå sin vision bör det fin-nas en helhetsbild som beskriver verksamhetens nuläge, börläge samt hur man bör förflytta sig från nuläget till börläget.

Bild 3. Relation mellan verksamhetens vision, målbild, nuläge och strategi

Sida 8

Många gånger kan man inom verksamheten uppfatta att dess nuläge inte är till-räckligt effektivt för att uppnå sin vision. Genom att effektivisera verksamheten skapas förutsättningar för att snabbare nå visionen. En helhetsbeskrivning som också omfattar verksamhetens börläge är ett underlag för effektivisering av verksamheten. Börläget är därför verksamhetens målbild och beskriver ett önskat, effektivt arbetssätt inom verksamheten.

En överenskommen målbild av verksamheten ligger till grund för strategiska beslut för hur man ska nå dit. I verkligheten kan det dock vara svårt att direkt ta sådana förändringssteg om de innebär stora verksamhetsmässiga förändringar. Man bör inte förledas till att kompromissa med sin målbild, utan istället ta fram en strategi som omfattar beskrivningar av etappsteg för att nå målbilden. Steg som innebär att man successivt närmar sig målbilden och som gör det möjligt att kontinuerligt utvärdera målbildens relevans.

En ytterligare del som behövs för att nå verksamhetens målbild och närma sig sin vision är verktyg som stödjer verksamheten, till exempel IT-stöd. Innan man tar fram målbild för IT-stöd bör man ha klart för sig hur verksamhetens målbild ser ut! Effektiva och ändamålsenliga IT-stöd är många gånger avgörande för verksamhetens förmåga att nå sin vision.

Bild 4. Förflyttning av verksamheten från nuläge till börläge bör synkroniseras med

effektivisering av IT-stöd

Sida 9

Precis som verksamheten uppfattar sitt nuläge som mindre effektivt att nå vis-ionen, kan nuvarande IT-stöd ha brister både med att stödja nuvarande verk-samhet men framförallt att också stödja en framtida verksamhet. På samma sätt behöver det därför beskrivas ett nuläge och en målbild för ett framtida IT-stöd samt en strategi för förflyttning. En framtagen verksamhetsstrategi är underlag för framtagandet av en verksamhetsbaserad IT-strategi.

Samtidigt måste dagens verksamhet kunna fungera och även för IT-stöd behövs därför kortsiktiga åtgärder identifieras som ska lösa akuta problem. Kortsiktiga åtgärder för nuläge beskriver hur man gör mindre och avgränsade förändringar som kan vara av olika karaktär, till exempel hantering av akuta problem och lokala, avgränsade problem som inte fodrar större resurser men som skapar förutsättningar för att verksamheten kan arbeta i sitt befintliga läge.

Målbilden skapar förutsättningar för verksamhetsutveckling och ligger till grund för framtagande av IT-strategi och kravställning av IT-stöd.

Men att effektivisera verksamheten och att ta fram effektiva IT-stöd är dock inte tillräckligt för att effektivt nå visionen. Idag har informationsförsörjning av en verksamhet en avgörande betydelse för verksamheten att nå sin vision.

Det räcker inte att bara effektivisera IT-stöd. En effektiv informationshantering är central för att skapa goda förutsättningar för verksamheten att nå sin målbild och därmed sin vision.

Bild 5. För att uppnå verksamhetens vision behövs inte bara en strategi för verksamhetsutveckling och IT-stöd utan också för informationshantering

Sida 10

Precis på liknande sätt behöver man beskriva dagens informationsförsörjning av verksamheten, ta fram en målbild för effektiv hantering av information samt hur en förflyttning till ett börläge bör göras.

Sammanfattningsvis bör man först ta fram beskrivningar över sin verksamhet och dess informationshantering så att dessa kan användas som underlag för att på ett konsekvent sätt kunna kravställa IT-stöd, vilket är tänkt att stödja och kanske till och med möjliggöra verksamheten.

2.2 Olika steg i ett analys- och förändrings-arbete Bilden nedan visar på några viktiga steg i analys- och förändringsarbeten. Innan man kan identifiera strategier för förflyttning behöver man beskriva dagens verksamhet och ta fram en målbild för verksamheten. Härefter görs en så kallad GAP-analys (gapet mellan nu- och börläge) för att bland annat identifiera vilka verksamhetsområden som ska effektiviseras/förändras. Med denna som un-derlag tas en verksamhetsstrategi fram, som övergripande och långsiktigt visar vägen att nå målbilden. Verksamhetsstrategi är ett styrmedel för verksamhetens förändringsarbete och säger vilka verksamhetsområden som bör prioriteras att starta förändringsarbete med.

Genom att detaljera och operationalisera verksamhetsstrategin definieras kon-kreta handlingsplaner för förändringsarbete.

På en övergripande nivå gäller samma principer inom alla tre perspektiven, d.v.s. verksamhet, informationshantering och IT-stöd. Samtidigt är det mycket viktigt att förändringsarbeten inom dessa perspektiv koordineras och sker i samverkan.

Sida 11

Bild 6. Steg i ett analys- och förändringsarbete

Planering av allt förändringsarbete ska utgå från helhetsbilden av verksamhet-en. Diskrepansen mellan nuläges- och börlägesbeskrivningar ligger till grund för framtagande av strategier för verksamhetsutveckling, dess informationsför-sörjning samt skapar underlag för framtagandet av IT-strategi.

Sida 12

Bild 7. Koordinering och samverkan mellan olika perspektiv i ett förändringsarbete

Inom varje perspektiv måste strategier för förflyttning tas fram (verksamhets-strategi, informationshanteringsstrategi samt IT-strategi), och dessa strategier måste koordineras. Förändringsarbete ska planeras och genomföras i samver-kan mellan dessa perspektiv.

Vad händer om det inte finns någon helhetsbild av verksamheten, som inklude-rar nulägesbeskrivning, målbild samt strategier för hur målbilden ska uppnås inom en organisation?

Inom verksamheten är det svårt att utan en gemensam målbild bland annat beskriva effektiva processer som ska leverera resultat som i sin tur ska bidra till måluppfyllelse.

Om det inom informationshanteringen inte finns någon målbild och stra-tegi är exempelvis risken stor att information inte blir spårbar och att det skapas ”öar” av informationsmängder som inte är kompatibla med varandra. Arbete med information är ett kontinuerligt arbete och det bör finnas en målbild och en tydlig strategi för hur man vidareutvecklar information.

Inom IT-stöd är det svårt att utan en gemensam målbild och strategier för verksamheten och dess informationsförsörjning ta fram en verksamhetsbaserad och realistisk IT-strategi.

Sida 13

2.3 Vad ingår i beskrivning av verksamhetens nu- och börläge samt dess informationshante-ring? I ett arbete med att beskriva en verksamhet är det önskvärt att inleda med en beskrivning på en övergripande nivå som påvisar hur olika delar i verksamheten relaterar till varandra och vilka ömsesidiga beroenden som finns mellan dessa i verksamheten. Framtagande av en sådan övergripande beskrivning bidrar till att medarbetare får en gemensam syn på sin verksamhet. Genom att man iden-tifierar dessa beroenden underlättas också att man kan prioritera rätt mellan olika initiativ.

Som nämnts tidigare bör man i arbetet med att ta fram en helhetsbild av verk-samheten börja med att beskriva verksamhetens nu- och börläge. Dessa be-skrivningar kan beroende på behov variera i detaljeringsgrad.

En verksamhetsbeskrivning är en av verksamhetsföreträdare överenskommen syn på sin verksamhet. Beskrivningen kan dels visa på dagens verksamhet - ett uppfattat nuläge, dels en framtida verksamhet - ett överenskommet börläge. Det kan inledningsvis vara viktigt att förstå och se skillnaden mellan dessa två typer av beskrivningar:

- Ett nuläge, eller en ”deskriptiv” beskrivning av verksamheten – så ser och uppfattar vi att verksamheten är och fungerar idag.

- Ett börläge, eller en målbeskrivning av verksamheten – så vill vi att verk-samheten ska vara och fungera.

Bild 8. Verksamhetens nu- och börläge

När man tar fram en verksamhetsbeskrivning så är det viktigt att man först är överens om i vilket syfte som beskrivningen ska tas fram. Ska den exempelvis visa på ett nuläge eller börläge? Om nuläge, vilken detaljeringsnivå behövs denna på, hur ska vi använda denna beskrivning? Exempelvis vill man kanske

- klargöra olikheter i vår uppfattning om verksamheten?

- påvisa

o ineffektiva processer?

o tids- och resursslöseri?

att samma ord används för olika begrepp och därmed för olika ändamål?

Sida 14

Ofta är syftet med en nulägesbeskrivning att formulera och konkretisera pro-blemställningar. Det finns kanske en känsla av att man inte är överens, men det går inte riktigt att sätta fingret på vad man inte är överens om. Många gånger när man bestämt sig för att beskriva ett nuläge inser man snabbt att utform-ningen av dagens verksamhet inte är optimal. Man vill hellre beskriva hur man vill arbeta, ett börläge, och inte hur dåligt dagens verksamhet fungerar. Det vi-sar sig därför ofta vara enklare, och ibland mer ändamålsenligt, att ta fram verk-samhetsbeskrivningen i form av målbilder! Det kanske inte ens är möjligt att få fram en hållbar gemensam beskrivning av ”dagens” verksamhet eftersom verk-samhetens företrädare oftast inte har en gemensam bild av eller uppfattning om sin verksamhet.

Samtidigt, om man inte vet hur nuläget är så är det också svårt att ta fram stra-tegier för hur man kan nå ett börläge och definiera en handlingsplan för detta.

Det kan alltså vara svårt att ta fram en nulägesbeskrivning eftersom det kan fin-nas så många sätt att se på och beskriva dagens verksamhet. Ett sätt att komma runt detta är att förenkla nulägesbeskrivningen genom att ta bort/skala av skilj-aktigheter för att därmed ändå få fram en möjlig gemensam verksamhetsbe-skrivning. Oftast kan en sådan beskrivning räcka för att ligga till grund för en förståelse för verksamheten och att man till exempel:

- Arbetar på olika sätt.

- Har olika begreppsuppfattningar.

- Hanterar information som inte är entydig.

Därmed sagt är det oftast viktigt att man på någon nivå tar fram en nulägesbe-skrivning, men som kanske inte beskriver verksamheten på en detaljerad nivå utan enbart påvisar hur olika delar av verksamheten förhåller sig till varandra och därmed vilka beroenden som finns inom organisationen.

Oavsett om man beskriver ett nu- eller ett börläge bör följande aspekter beaktas.

Sida 15

Bild 9. Olika aspekter av verksamheten och dess informationshantering

En verksamhet beskrivs utifrån följande aspekter:

- Vilka mål verksamheten har

- Vilka som är intressenter i verksamheten

- Vilka begrepp som behövs och förekommer i verksamheten

- Vilka processer som behövs och finns i verksamheten

- Vilken typ av information som hanteras i dessa processer och hur denna information är strukturerad

Sida 16

3 Vägen till semantisk inter-operabilitet En gemensam och överenskommen helhetsbild av verksamheten är en viktig grund för semantisk interoperabilitet och skapar förutsättningar för kvalitativt informationsutbyte i en verksamhet.

Semantisk interoperabilitet innebär att både sändare och mottagare av information, som används i en viss kontext inom en viss tidspe-riod, har en gemensam förståelse av informationens betydelse. Detta gäller oberoende om informationen kommuniceras muntligt eller via någon teknik.

Semantisk interoperabilitet innebär ett kvalitativt informationsutbyte mellan olika roller i en verksamhet. Informationsutbyte sker idag vanligtvis med tek-niska hjälpmedel och därför är ett kvalitativt informationsutbyte viktigt även mellan människa och teknik och vise versa.

En gemensam helhetsbild sätter upp ramar för beskrivning av kontext och tids-period. En gemensam helhetsbild är en utgångspunkt för hur man ska kunna förstå och beskriva sin verksamhet och därmed också den information som han-teras i verksamheten.

3.1 Behov av gemensam verksamhetssyn Hur får man till en effektiv och ändamålsenlig samverkan mellan personer som arbetar/utför uppgifter inom en verksamhet? Den grundläggande förutsättning-en är att dessa har en gemensam bild av och förståelse för denna verksamhet. Vad är verksamheten till för? Hur arbetar vi i verksamheten för att uppnå dess syften? Vad menas med alla ord som används i verksamheten? Vilken informat-ion och kunskap behövs för att man ska kunna utföra sina arbetsuppgifter på ett effektivt sätt? Detta låter självklart, men påfallande ofta har personer inom en verksamhet olika bilder av och förståelse för sin verksamhet. Vilken uppgift man har i verksamheten och vilken fackutbildning man har kan vara några av orsakerna till detta. Men inte minst blir denna ”icke gemensamma verksam-hetssyn” påtaglig då man har genomfört omorganisationer, har slagit ihop före-tag/organisationer eller har börjat arbeta på annat sätt än tidigare och skaffat nya samarbetspartners. Den grundläggande kunskapen och förståelsen kan då plötsligt kanske inte längre kännas självklar, samtidigt som den också kan bli ifrågasatt. Det finns så många sätt som man kan uppfatta och beskriva en viss verksamhet på.

Varje persons egen verksamhetskunskap och förståelse har ofta utvecklats un-der lång tid. Först genom att man genomgått en lång utbildning där man förses med grundläggande kunskaper och begreppsapparat. Därefter genom yrkeserfa-

Sida 17

renheter där man tillämpar sina kunskaper och får en ytterligare fördjupad för-ståelse och mer preciserad begreppsapparat. Denna kunskap blir en del av en själv, en del av personligheten. Inte minst gäller detta den egna begreppsvärl-den, d.v.s. hur begreppen hänger ihop och vilka ord eller termer1 man använder för sina begrepp.2 Det är ofta mycket svårt att på kort tid ändra sin föreställning och byta benämningar på begrepp, just därför att det är en så stor del av männi-skans personlighet. Men, för att återgå till den inledande beskrivningen av pro-blematiken, vi måste förstå varandra för att vi ska kunna kommunicera och samverka med varandra på ett säkert och effektivt sätt inom verksamheten.

Hur åstadkommer och säkerställer man då en gemensam verksamhetssyn hos personer inom en verksamhet? Genom verksamhetsanalyser och beskrivningar av dess resultat kan en sådan samsyn uppnås.

I grunden bygger verksamhetsanalyser på att verksamhetsföreträdare diskute-rar med varandra och i denna diskussion formar en gemensam förståelse och kunskap om sin verksamhet. Dock säger erfarenheten att det är svårt att bara föra ett samtal utan att man på ett stringent sätt också successivt dokumenterar sitt resonemang om verksamheten. Dokumentationen bör stödja diskussionen och analysen på ett effektivt sätt. Det är här tekniken med modellering kommer in. Genom att hela tiden synliggöra ett resonemang ges alla deltagare möjlighet att ”se” det som diskuteras och därmed lättare följa med i diskussionen. Att dis-kutera en verksamhetsbeskrivning som ”syns” är mycket lättare än att bara ”höra” den. Att diskutera sin verksamhetssyn kan, som nämnts ovan, kännas jobbigt på grund av att den är så nära kopplad till den egna personligheten och den egna verklighetsuppfattningen. Att fokusera på att diskutera verksamheten runt framtagna modeller upplevs många gånger inte lika ”hotfullt”.

Det är ett ansträngande arbete att ändra på sin begreppsvärld eftersom inarbe-tade associationer mellan begrepp diskuteras och kan börja ifrågasättas. Det är då lättare att i en modell visualisera ändringar av associationer eller skapandet av nya. Detta arbete måste få ta sin tid innan individer känner sig trygga i en ny associationsvärld. Med modeller kan man testa olika alternativ utan att det blir för ”ansträngande för hjärnan”.

Modellerna måste också kompletteras med textuella beskrivningar. Men en text är alltid tolkningsbar och därför kan en verksamhetsbeskrivning, som ska vara tydlig och exakt, inte endast dokumenteras med en text. Modeller och dess textuella beskrivningar kompletterar varandra.

Verksamhetsanalys, och verksamhetsmodellering som är ett instrument i ana-lysarbetet, innebär att på ett strukturerat sätt diskutera och fortlöpande doku-mentera diskussionen/argumentationen och härigenom forma en entydig och gemensam uppfattning om samt beskrivning av verksamheten.

För att kunna samverka med varandra på ett effektivt och ändamålsenligt sätt behövs självklart även redskap/verktyg av olika slag, till exempel IT-stöd. Ett IT-stöd ska ha förmågan att på ett bra sätt stödja och underlätta för verksam- 1 Termer är fackspråkliga ord inom ett visst verksamhetsområde. 2 För mer detaljerad beskrivning av begrepp och termer, se avsnittet om begreppsanalys.

Sida 18

hetsföreträdarna i deras arbete. Vad man dock ofta inte tänker på är att alla verksamhetens IT-system är baserade på en uppfattning om hur verksamheten fungerar och hur dess begreppsvärld är utformat. Denna uppfattning har byggts in i systemet av dess konstruktörer som, förhoppningsvis, har utgått från be-skrivningar av systemets kravställare. Har man inte det bygger systemet på kon-struktörernas egna uppfattningar. En grundläggande förutsättning för att sy-stemet ska fungera bra i verksamheten är i regel att

- kravställarna, d.v.s. verksamhetsföreträdarna, är eniga i sin syn på/uppfattning om sin verksamhet,

- kravställarna kan beskriva och förklara sin verksamhet för konstruktö-rerna på ett entydigt sätt,

- kravställarna kan förklara vad man vill ha stöd för i sin verksamhet, till exempel vilken information man behöver/vill kunna hantera i sitt arbete och på vilket sätt, samt att

- konstruktörerna förstår verksamhetsbeskrivningen, informationsbehovet och utformar IT-stödet efter detta.

Att det sedan också behövs en väl fungerande teknik som passar den beskrivna verksamheten är självklar. Men den grundläggande förutsättningen är att det finns en gemensam och överenskommen verksamhets- och informationsbe-hovsbeskrivning. Detta är verksamhetens ansvar. Att välja en passande teknisk lösning för denna är IT-konstruktörernas ansvar!

3.2 Förutsättning för en semantisk inter-operabilitet

Bild 10. En gemensam förståelse för ”verkligheten” är en förutsättning för semantisk

interoperabilitet

Sida 19

När jag förnimmer en företeelse inom verksamheten uppstår alltid någon tolk-ning av denna företeelse i min hjärna. Hur jag uppfattar och tolkar detta beror helt på min kunskap och tidigare erfarenheter om denna typ av företeelse. Mina kunskaper och erfarenheter formar över tid min begreppsvärld och uppfatt-ningen om verksamheten. Företeelsen kan vara av konkret karaktär, som till exempel ett mätinstrument, eller ha någon mer abstrakt dimension som till ex-empel känslor som glädje, sorg, vemod etc. Jag söker efter egenskaper som jag känner igen hos denna företeelse och försöker placera in detta i min existerande begreppsvärld. Kanske är denna företeelse något välbekant, eller åtminstone jämförbart med tidigare liknande upplevelser. Kanske är det en helt ny förete-else för mig. Även här försöker jag ändå tolka och identifiera denna via dess ibland uppenbara egenskaper som exempelvis utseende, ljud, lukt etc. men också kanske via de ord/termer som företeelsen eventuellt benämns med. Via egenskaper och benämningar försöker jag få in denna nya företeelse i min be-greppsvärld med nya associationer till väletablerade begrepp. Ett nytt begrepp läggs till min begreppsapparat.

För att kunna kommunicera våra begrepp mellan varandra måste vi ange upp-fattbara symboler på begreppen. Vi behöver dessutom i denna kommunikation vara överens om vad som menas när vi använder oss av dessa symboler. Med symboler menas här till exempel ord, tecken, gester, bilder, ikoner, men också koder i ett kodverk.3 I bilden ovan är XYZ ett exempel på en symbol. En person förnimmer något i sin ”verklighet” och tolkar detta som ett XYZ. Detta registre-ras i ett IT-stöd och lagras i en databas. Någon gång senare tar någon annan, eller samma person, del av denna information och tolkar XYZ. Hur denna tolk-ning görs beror då på vilken kunskap denna person har om den ”verklighet” ur vilken denna information har uppstått. Har vi samma referensramar och kun-skap om ”verkligheten” är risken mindre för feltolkning än om vi har helt olika syn på och erfarenheter av denna ”verklighet”.

Denna grundläggande förutsättning har inget att göra med den teknik som valts för informationsöverföringen. Vi kan kanske förstå varandra bättre om vi för ett samtal direkt med varandra, eftersom vi omedelbart kan reda ut eventuella missförstånd. Om vi använder oss av mera indirekta kommunikationssätt som pappersdokument eller information som hanteras i ett IT-stöd ökar risken för missförstånd. Den grundläggande förutsättningen är att vi har en gemensam syn på och kunskap om vår ”verklighet” och därmed vår verksamhet.

3 För klassifikation, koder och kodverk se till exempel www.sv.wikipedia.org/wiki/Klassifikation , www.ne.se/kort/klassifikation

Sida 20

3.3 Behov av gemensam metod för verksam-hets- och informationsbehovsanalys Som vi beskrev i föregående avsnitt är en gemensam beskrivning av ”verklighet-en” en grund för semantisk interoperabilitet. Den ”verklighet” som profession-ella aktörer verkar i benämns för verksamhet. För att kunna ta fram en ge-mensam helhetsbild av sin verksamhet behöver man genomföra verksamhets- och informationsbehovsanalyser.

Behov av verksamhets- och informationsbehovsanalys uppstår också när det finns ett problem avseende hur en verksamhet bedrivs eller ska bedrivas.

Det finns många sätt att genomföra verksamhets- och informationsbehovsana-lyser, men det är viktigt att det används en verksamhetsgemensam metod.

Varför behövs en gemensam metod?

Det är viktigt att man genomför verksamhets- och informationsbehovsanalyser utifrån samma utgångspunkter. Om man inom en organisation samtidigt an-vänder flera metoder för verksamhetsanalys kan det bli svårare att jämföra och återanvända analysresultat. Dessutom bör modellerna ha samma detaljerings-grad och beskrivas med samma notation för att vara jämförbara med varandra. Med en gemensam metod kan resultat som beskriver olika delar av verksamhet-en sammanställas i en övergripande modell.

Om till exempel en process endast är beskriven i text, hur förhåller sig då denna beskrivning till andra processbeskrivningar som är utformade som modeller? Det blir svårt att sammanställa alla dessa processbeskrivningar till exempelvis en sammantagen processkarta.

Dock är varje analyssituation unik och därför kan behovet av vilka perspektiv som bör analyseras och beskrivas vara olika från tillfälle till tillfälle. Det behövs därför en metod som utgörs av ett antal metodsteg som kompletterar varandra och ger en djupare förståelse av verksamheten, men där varje steg också kan användas självständigt och ändå ge en verksamhetsbeskrivning som är tillräck-lig för behovet.

I denna handbok beskrivs metoden för verksamhets- och informationsbehovsa-nalys (VIA-metoden) som består av ett antal metodsteg som också kan använ-das självständigt.

Sida 21

4 Verksamhets- och informa-tionsbehovsanalys utifrån olika aspekter I detta avsnitt beskrivs genomförandet och dokumentationen av en verksam-hets- och informationsbehovsanalys utifrån olika aspekter. Denna del av meto-den består av ett antal metodsteg. Varje metodsteg innefattar en eller flera mo-delltyper som beskriver verksamheten och dess informationshantering på ett konsekvent sätt som möjliggör att spårbarhet mellan dessa modeller uppnås.

VIA-metoden används för analys och beskrivningar av en verksamhet. De fram-tagna beskrivningarna skapar underlag för olika syften, bland annat för verk-samhetsutveckling, utveckling av verksamhetens informationsförsörjning, fram-tagande av IT-strategier samt kravställning av IT-stöd.

Att använda en vedertagen och organisationsgemensam metod i verksamhets-analysarbeten säkerställer att resultatet av analysen är användbart för sitt syfte, håller en hög kvalitet och är återanvändbart.

Vad händer om man inte har en gemensam metod för analys? Nedan beskrivs ett antal problemställningar inom tre olika perspektiv – verksamheten, dess informationshantering och IT-stöd.

Om det inte finns en gemensam metod för analys så…

Inom verksamheten:

• Projekt och initiativ arbetar enligt olika metoder och resultatet blir att framtagna verksamhetsbeskrivningar kan ha varierande detaljeringsgrad och inte kan jämföras och återanvändas på ett korrekt sätt.

• Innehållet i framtagna modeller är inte kongruenta med branschram-verk, standarder eller med andra analysresultat inom verksamheten.

• Det förekommer ofta att analysresultat beskrivs på olika sätt. Det an-vänds inte en gemensam notation i modeller samt modeller ritas i olika verktyg som inte är kompatibla med varandra. Det orsakar att modeller-na blir svåra att förvalta och sammanställa.

• Analysarbetet resulterar i att spårbarhet saknas mellan olika verksam-hetsbeskrivningar.

Sida 22

Inom informationshantering:

• Om man inte använder en gemensam metod innebär detta bland annat att risken är stor att olika modeller och dess beskrivningar över informat-ion inte är kompatibla med varandra.

Inom utveckling av IT-stöd:

• Varje IT-utvecklingsprojekt tar ofta fram egna verksamhetsbeskrivningar för att kunna kravställa IT-stöd. Arbete med verksamhetskrav är en tids- och resurskrävande del i ett IT-utvecklingsarbete. Avsaknad av en ge-mensam metod innebär ofta att resultat av verksamhets- och informat-ionsbehovsanalys inte kan återanvändas. Att inte kunna återanvända dessa resultat innebär ofta att IT-utvecklingsprojekt blir ekonomiskt in-effektiva.

• Dessutom blir konsekvensen ofta även att kravbeskrivningarna för ut-veckling av IT-stöd, som är framtagna inom olika IT-utvecklingsprojekt, inte uppfyller verksamhetens behov. Risken är också stor att de dessutom inte är kompatibla med varandra.

VIA-metoden bör därför användas som en gemensam metod inom verksamhet-en inför kravställning och utveckling av IT-stöd men bör också användas vid enbart verksamhetsutveckling eller vid förbättringsarbeten avseende verksam-hetens informationsförsörjning.

Sida 23

4.1 Fokus för VIA-metoden En verksamhets- och informationsbehovsanalys syftar till att medarbetarna inom en verksamhet ska få en gemensam förståelse av sin verksamhet och dess informationshantering, och att det framtagna analysresultatet är användbart för olika ändamål, till exempel som underlag för verksamhetsutveckling, utveckling av informationshantering och kravställning av IT-stöd.

Bild 11. VIA-metoden fokuserar på att analysera och beskriva verksamheten och dess

informationshantering

Resultatet av analysen bör beskriva verksamheten ur olika aspekter så att be-skrivningen ger en sammantagen, djup förståelse av verksamheten, som till ex-empel:

- Vad verksamheten är till för, vad man ska uppnå

- Vilka centrala/bärande begrepp som används inom verksamheten

- Hur man arbetar/agerar på mest effektiva sätt för att uppnå uppställda mål inom verksamheten

Sida 24

- Vilka som är verksamhetens direkta och indirekta intressenter och vilka mål som kan kopplas till dessa. Intressenter kan vara beställare, utförare, resursallokerare, kund, medarbetare, etc.

- Vilka roller som finns i verksamheten, deras ansvar samt vilket informat-ionsbehov som dessa har i sitt agerande

- Hur information struktureras i verksamheten

Bild 12. En verksamhetsanalys syftar till att beskriva och förklara en verksamhet och dess

informationsförsörjning utifrån olika aspekter

En verksamhetsanalys görs av verksamhetsföreträdare. Syftet är att de ska komma överens om och ska beskriva olika aspekter av en viss avgränsad verk-samhet. Dessa aspekter kan kortfattat beskrivas som verksamhetens

- mål – vad har verksamheten för mål, vad vill man uppnå med verksam-heten? Brukar struktureras i en målmodell.

- intressentanalys – vilka är verksamhetens intressenter, direkt och in-direkt? Brukar beskrivas med hjälp av en intressentmodell.

- processer ur ett värdeförädlingsperspektiv – vilka värden skapas, på vilket sätt ska beskrivna mål uppnås och vilka är mottagare av proces-sens åstadkomna värden? Brukar beskrivas med hjälp av en processmo-dell.

- processer ur ett samverkansperspektiv – hur agerar och samver-kar olika roller för att genomföra processerna?

- begrepp – vilka begrepp är grundläggande och måste vara förankrade inom verksamheten så att rollerna ska kunna samverka på ett effektivt sätt? Brukar beskrivas med hjälp av begreppsmodeller.

Sida 25

- informationsbehov – vilken typ av information behöver olika roller för att kunna utföra sina arbetsuppgifter? Brukar beskrivas som inform-ationsmängder i form av mallar, blanketter, checklistor etc.

- informationsstruktur – en sammanfattande och strukturerad be-skrivning av den typ av information som rollerna behöver och skapar i processen brukar ofta formuleras i en så kallad ”logisk och lösningsneu-tral” informationsmodell. Med detta menas bland annat att modellen inte beskriver hur till exempel en databas i praktiken ska struktureras utan hur information uppfattas ”hänga ihop” på ett logiskt sätt.

- kodverk, klassifikationer och terminologier – ett antal över-enskomna och fördefinierade värden som beskriver en viss typ av in-formation.

Nedan följer en kort beskrivning av de olika stegen i en verksamhets- och in-formationsbehovsanalys. Det är viktigt att förstå att detta är en översiktlig be-skrivning av VIA-metoden. I ett praktiskt genomförande kan det ibland vara motiverat att genomföra dessa steg i annan ordning och i flera iterationer.

För att skapa goda förutsättningar för effektivisering och optimering av en verk-samhet bör alla steg i metoden genomföras. Detta ger en djup förståelse av verksamheten. Ibland kan det dock vara svårt att genomföra alla steg under en avgränsad period. Man kan i stället välja att börja med ett eller flera av metod-stegen och inledningsvis analysera inom vilket verksamhetsområde det krävs mest åtgärder. Analysarbetet kan startas med de metodsteg som är mest rele-vanta utifrån verksamhetens aktuella behov.

En framtagen verksamhetsbeskrivning bör vara stabil över tid men får inte ses som statisk. Den kan behöva uppdateras av flera olika skäl, till exempel för att

- målen för verksamheten förändras,

- nya insikter och kunskaper motiverar att processer utformas på annat sätt, eller att

- nya roller inom området motiverar att samverkan i processerna ses över.

En förändring av någon aspekt i verksamhetsbeskrivningen kan föranleda att övriga beskrivningar också behöver ses över. En förändring av verksamhetens målformulering motiverar till exempel en översyn av alla övriga verksamhets-aspekter. En förändring av processbeskrivning ur ett värdeförädlingsperspektiv bör föranleda uppdateringar av beskrivningar av process ur ett samverkansper-spektiv, begrepp, informationsbehov och informationsstruktur.

I den följande tabellen beskrivs ett antal steg som ingår i VIA-metoden. I me-todstegen analyseras och beskrivs en verksamhet ur olika aspekter, på ett logiskt och konsekvent sätt.

Resultatet är en av verksamhetsföreträdare överenskommen beskrivning av sin egen verksamhet.

Sida 26

Metodsteg Resultat Syfte 1. Mål- och intressentana-lys

Intressentmodell Målmodell

VARFÖR och FÖR VEM finns verksamheten?

2. Processanalys 4 2a. Processanalys ur ett värdeförädlingsperspektiv 2b. Processanalys ur ett samverkansperspektiv

Processmodeller VAD, d.v.s. vilket eller vilka värdeförädlings-objekt, hanteras i verk-samheten, HUR, FÖR VEM och MED VEM arbe-tar man i verksamheten? Enligt standarder är pro-cesser följande: “set of interrelated or interact-ing activities which transforms inputs into outputs NOTE 1 to entry: Inputs to a process are generally outputs of other processes. In that sense, because their output can be used as an input to another process, activities may be con-sidered as resources in a pro-cess.” [ISO 9000:2005]

3. Begreppsanalys Begreppsmodell VAD menas med ord och begrepp i verksamheten, d.v.s. i ett visst verksam-hetssammanhang? ”Att mena samma sak”

4. Informationsanalys 4a. Informationsbehovs-analys 4b. Informationsstruktur-analys

Informationsmäng-der Informationsmodell

VILKEN INFORMATION BEHÖVER och SKAPAR rollerna i processen? HUR hänger INFORMA-TION på ett strukturerat sätt ihop?

5. Kodverk, klassifikationer och terminologier

Beslut att ta fram eller att använda be-fintliga kodverk etc. samt i så fall vilka delar i dessa som ska

Ett antal överenskomna och fördefinierade värden som beskriver en viss typ

4 Se definition av begreppet process i prEN ISO/DIS ISO TC 215/ WG 3 Health informatics — System of concepts to support continuity of care

Sida 27

användas av information.

”Att mäta samma sak”

Metodstegen visas också överskådligt i följande bild. Bildens delar inleder varje beskrivning av metodsteg nedan. För större bild, se även bilaga 2.

Bild 13. En sammanhållen metod för verksamhets- och informationsbehovsanalys med olika metodsteg

De flesta metodsteg kan användas som en självständig del utan krav på att öv-riga steg genomförs i alla arbeten.

Dock belyser varje metodsteg en ny aspekt av verksamheten och tillför en ny detaljeringsgrad i förståelsen av denna och dess informationsbehov. Den fram-tagna beskrivningen får en detaljrikedom och ett djup.

Det är också viktigt att poängtera att en verksamhets- och informationsbehovs-analys oftast aldrig sker sekventiellt, d.v.s. att man använder sig av ett metod-steg i taget och sedan inte utför detta metodsteg igen5. I stället genomförs näst-an alla verksamhetsanalyser i iterationer. Det är också vanligt att man inte alltid påbörjar analysen med en intressent- och målanalys, utan likaväl kan starta med begrepps- eller processanalyser. Varje situation är unik.

5 Se till exempel den s.k. Vattenfallsmetoden (http://sv.wikipedia.org/wiki/Vattenfallsmodellen)

Sida 28

Bild 14. En verksamhets- och informationsbehovsanalys genomförs oftast i iterationer

Det är viktigt att påpeka att man i steg 5, kodverk etc., kopplar dessa till attribut som behöver detaljeras i en informationsstruktur. Det räcker inte med att bara arbeta med kodverk etc. Dessa används i ett visst sammanhang som måste iden-tifieras.

I bilden nedan visas översiktligt de fem metodstegens innehåll, d.v.s. vad man gör i de olika analysstegen, se även bilaga 2. Detta beskrivs i respektive metod-stegs kapitel nedan.

Sida 29

Bild 15. Innehåll i varje metodsteg

De flesta metodsteg kan användas som en självständig del, utan krav på att öv-riga steg genomförs i alla arbeten.

För att underlätta förståelse och analys av en komplex verksamhet används mo-deller. Ett av flera syften med modeller är att kunna förenkla, d.v.s. framhäva viktiga delar i förhållande till mindre relevanta aspekter. Poängen med modeller är att man försöker fånga mönster i en verksamhet som är komplex och mång-tydig. Beroende på sina syften förenklar modeller verkligheten genom att ute-sluta vissa detaljer och i stället fokusera på egenskaper som är relevanta i de delar som beskrivs.

Att ta fram verksamhetsmodeller innebär att man på ett förenklat sätt visuali-serar uppfattningen om en verksamhet. En visualisering har i sig ett värde, till exempel vad gäller att vara en del i ett diskussionsunderlag och därmed en vik-tig del av en förankringsprocess. Har vi en gemensam bild av/uppfattning om vår verksamhet? En sådan diskussion underlättas om det finns något som man

Sida 30

kan se på och diskutera utifrån, d.v.s. modeller som beskriver en verksamhet.

Modelleringsprocessen i sig är oftast mycket värdefull. Genom att verksamhets-företrädare börjar beskriva sin nuvarande verksamhet ser de ofta väldigt tydligt och snabbt vilka delar inom verksamheten som kan förbättras och effektivise-ras. Genom modelleringen kan man börja se verksamheten i sin helhet.

4.2 Mål- och intressentanalys

Bild 16. Målamalys resulterar i en målmodell

Det första steget i metoden syftar till att komma överens om och beskriva mål i den avgränsade verksamhetens, d.v.s. vad man vill uppnå med den bedrivna verksamheten som analyseras. Varför finns verksamheten, vad ska uppnås? Må-len brukar ofta beskrivas i en målstruktur, ibland kallad för målhierarki, som visar på övergripande och underordnade mål. Det finns beroenden mellan mål som till exempel att ett visst underordnat mål förutsätts ha uppnåtts innan ett övergripande mål kan nås.

I en måldiskussion ingår också att belysa eventuella problem som innebär att mål inte nås, samt att identifiera hur dessa problem kan lösas.

Målanalysen resulterar i en modell som på ett strukturerat sätt beskriver verk-samhetens mål, ibland kallat för verksamhetens motiv, syfte eller intention. En anledning till att klargöra verksamhetens mål är att kunna påvisa om det arbete som utförs ger önskad effekt i verksamheten och för dess intressenter, kunder, leverantörer etc.

Att genomföra en målanalys är önskvärt som ett första steg i en verksamhets-analys eftersom det ger viktig input till det fortsatta arbetet. Målanalysen hjäl-per också till att ringa in och avgränsa den verksamhet som ska fokuseras. Utan klargjorda verksamhetsmål är det svårt att avgöra vilka processer som skall/bör utvecklas och i vilken ordning processerna bör tas fram.

4.2.1 Syfte och mål med metodsteget VARFÖR och FÖR VEM finns verksamheten?

Sida 31

Syftet med en målanalys är bland annat att

- belysa verksamhetens mål, problem och åtgärder för att eliminera dessa problem men också åtgärder för att uppnå verksamhetens mål,

- identifiera verksamhetens processer samt vilka av dessa som behöver analyseras,

- skapa samsyn inom verksamheten om ovanstående. I en målanalys beskrivs verksamhetens mål och hur dessa relaterar till varandra. Vilka underordnade mål som först ska uppnås, och i vilken ordning, så att övergripande mål sedan kan nås. Målanalysen syftar också till att klargöra eventuella målkonflikter och påvisa möjliga hinder för att uppnå mål samt hur dessa hinder bör hanteras. Målmodellen är härmed ett viktigt underlag för att kunna ta fram strategier, både vad gäller att få verksamheten att fungera opti-malt på kort sikt men också för framtagandet av mer långsiktiga strategier. Un-derordnade mål utgör grund för input till en handlingsplan.

För varje mål bör kriterier för måluppfyllelse beskrivas och preciseras. Det på-pekas ofta att beskrivna verksamhetsmål bör vara mätbara, d.v.s. det ska kunna mätas om eller när ett mål har nåtts. I en målstruktur kan de mer övergripande målen oftast ses som visioner och de blir därför svåra att mäta en måluppfyllelse för. De underordnade målen bör dock alltid kunna mätas och kriterier för måluppfyllelse bör därför också preciseras.

Ett annat syfte med detta metodsteg är att klargöra och beskriva verksamhetens intressenter i en intressentmodell. Intressenter kan till exempel vara roller, kompetenser, organisatoriska enheter, verksamheter eller motsvarande. Intres-sentanalys görs bland annat för att

- skapa tydligt kundfokus genom att beskriva vilka som är kunder och som

därmed ska kunna dra nytta av det som verksamheten åstadkommer, - kartlägga verksamhetens sammanhang, till exempel samarbetspartners, - identifiera intressenter för att dessa i en verksamhetsanalys kan bidra till

kravbilden av en viss del i verksamheten.

Efter man har identifierat intressenter kan man prioritera vilka intressenters mål som man vill fokusera på att uppnå. I samband med detta görs tydliga av-gränsningar av utvecklingsarbetets syfte och omfattning. Intressentanalysen bidrar till att prioritera mål för verksamheten.

Intressenter brukar ofta indelas i direkta intressenter, till exempel kunder (eller vad man kallar de roller som ska ha nytta av verksamheten), ledning, medarbe-tare etc. och indirekta intressenter, exempelvis samarbetspartners, samhället, medborgare i allmänhet samt övriga intressenter. Vilka som spelar rollen av att vara direkta respektive indirekta intressenter skiftar självklart från verksamhet till verksamhet.

Det är viktigt att man i målanalysen funderar över vems mål som beskrivs. Vad menas med ”verksamhetens” mål? Är det ägarnas mål? Är det ledningens mål?

Sida 32

Mål som beskrivs i målmodellen kan ibland visas ur olika perspektiv, exempel-vis

- ledningens mål, - medarbetarnas mål, - samhälleliga mål.

En målmodell utgår från en viss intressents perspektiv. Man skall inte blanda olika intressenters mål i en och samma målmodell. När man har ett antal olika målmodeller som beskriver olika intressenters perspektiv är det önskvärt att man gör en analys över om det finns målkonflikter mellan dessa.

4.2.2 Hur gör man?

Bild 17. Steg i en intressent- och målanalys

Analysarbetet kan delas in i fyra steg.

- Klargöra och beskriva verksamhetens intressenter, välja vilka intressen-ters mål som ska identifieras och prioriteras

- Ta fram målformuleringar och en målstruktur som visar på beroenden mellan mål, till exempel vilka mål som måste vara uppfyllda för att mer övergripande mål ska anses vara uppfyllda.

- Precisera och beskriva kriterier för måluppfyllelse. - Beskriva möjliga problem för måluppfyllelse och åtgärder för dessa.

4.2.3 Notationssätt En målmodell innehåller oftast följande delar

- mål, det som man vill uppnå i verksamheten - målrelationer som visar hur de olika målen förhåller sig till varandra, till

exempel kräver, bidrar till, etc. Genom dessa relationer kan man beskriva underordnade mål och huvudmål

- problem, d.v.s. sådant som kan förhindra att mål uppnås - åtgärder, d.v.s. sådant som bör göras för att hantera eller eliminera pro-

blem samt för att uppnå mål

Sida 33

Bild 18. Exempel på notation för målmodell

Sida 34

4.3 Processanalys Processanalys genomförs utifrån två perspektiv – analys ur ett värdeförädlings-perspektiv och analys ur ett samverkansperspektiv.

Bild 19. Steg i en processanalys

4.3.1 Analys av processer ur ett värdeförädlingsperspektiv

Bild 20. Process ur ett värdeförädlingsperspektiv

Nästa metodsteg innebär att klargöra hur man på mest effektivt sätt kan uppnå målen, bland annat vilka processer som behöver beskrivas och implementeras i verksamheten. Med utgångspunkt från bland annat målformuleringar som be-skrivs i den framtagna målmodellen avgör man vilka typer av processer som verksamheten bör identifiera, fastställa, kartlägga, följa upp och förbättra. Mål som till exempel säger att en verksamhet ska ha nöjda och återkommande kun-der, indikerar att man bör definiera en process som används för att kontinuer-ligt följa upp och mäta kundernas nöjdhet.

Alla verksamheter kan beskrivas utifrån ett processperspektiv. För att tydliggöra en verksamhets innehåll är det önskvärt att man identifierar och kartlägger verksamhetens processer samt vad dessa ska åstadkomma utifrån verksamhet-ens mål.

Sida 35

Typer av processer

En verksamhet karaktäriseras ofta med att det finns en så kallad kärnverksam-het, den del som utgör grunden i verksamheten och där man kan påstå att verk-samhetens kärnkompetens finns.

Kärnverksamhet definieras ibland som ”verksamhet som är specifik och absolut nödvändig för en organisations värdekedja”. 6

Vad som är en kärnverksamhet eller inte beror naturligtvis på vilken avgränsad del av verksamheten som studeras. En lönehantering kan i en viss verksamhet ses vara stödjande, medan i en annan vara själva kärnverksamheten.

Kärnverksamheten beskrivs med en eller flera kärnprocesser, och som stöd till denna finns alltid styr- och stödprocesser. Kärnprocessen inom hälso- och sjuk-vård är en klinisk process, till exempel process för behandling av kronisk hjärt-svikt. Exempel på en styrprocess är process för avtal mellan vårdbeställare och vårdproducent. Exempel på stödprocesser är anskaffning och allokering av me-dicinskteknisk utrustning.

Bild 21. Beroenden mellan kärnprocessen och dess styrande och stödjande process

Verksamhets- och informationshanteringsprocess

Vad som också kan noteras är att det är viktigt att skilja mellan renodlade verk-samhetsprocesser och informationshanteringsprocesser. I de senare fokuserar de olika delarna av processen på att hantera information (läsa, skapa, förändra) gällande det som bedrivs i verksamheten. Denna analys ligger inom området informationshantering och skapar underlag bland annat för kravställning av IT. I en verksamhetsanalys är det verksamhetsprocesserna som är i fokus, inte hur man dokumenterar. Analys av verksamhetsprocesserna ligger till grund för ana-lys avseende vilken typ av information som verksamhetens roller behöver ha tillgång till och/eller skapar i genomförandet av sina processer.

Kriterier för en process

En beskriven process måste uppfylla vissa kriterier. Dessa är följande

- ska vara ett mönster för agerande, 6 Svensk Byggtjänsts "Aff-definitioner"

Sida 36

- ska vara värdehöjande, har ett förädlingsobjekt,

- har alltid en avnämare (kund),

- kan bestå av delprocesser och har en utsträckning i tiden,

- har processmål som ska uppnås och som processen styr mot,

- har en ägare,

- har definierade start och slutkriterier som processmålet definie-rar,

- är organisatoriskt oberoende.

Processens beståndsdelar

En process har följande beståndsdelar. Dels ett mål som processen ska styra mot, dels ett objekt som tillförs värde (värdeförädlingsobjekt) och dels det mönster för agerande som ska tillföra detta värde.7

En process är ett överenskommet mönster för agerande som syftar till att skapa ett fördefinierat mervärde för ”någon”, en avnämare. Det som hanteras i proces-sen och det som skapas mervärde på brukar i processteorin kallas förädlingsob-jekt. Syftet med processen är att värdeförädlingsobjektet ska uppnå det tillstånd som beskrivs i processmålet.

Genom att på förhand beskriva hur det optimala mönstret, processen, bör se ut för hantering av ett visst förädlingsobjekt, och vilket mål som ska uppnås, har man också bättre förutsättningar än annars att senare utvärdera om verksam-heten lyckas i sitt faktiska arbete. Det går att koppla kvalitetsaspekter till pro-cesser och till det genomförande som görs utifrån detta mönster.

En process, mönstret för ett överenskommet och medvetet agerande, omfattar beskrivningar om vad som ska åstadkommas och vilka delprocesser som ska genomföras. Sammantaget ska genomförandet av dessa delprocesser resultera i att det skapas ett mervärde åt en avnämare. Processen kan betraktas som en serie aktiviteter som ska tillföra ett positivt värde till ett förädlingsobjekt. Pro-cessen ur ett värdeförädlingsperspektiv är organisationsneutral och visar inte vilka roller eller organisationer som involveras för att genomföra olika delar av processen. Denna beskrivning definierar inte hur linjeorganisationen som ge-nomför processen ska vara utformad.

Processen kan vid en implementering involvera flera olika organisationer som var och en ansvarar för olika delar av processen. Processbeskrivningen kan därmed vara giltig oavsett hur till exempel en viss organisation är uppbyggd.

7 Se definition av process i till exempel ledningssystemstandarden ISO 9000:2005

Sida 37

Kvalitetsaspekter

Man kan tala om olika aspekter att mäta processen på:

Processkvalitet • Processen är motiverad utifrån verksamhetens mål. • Processmålet är rimligt och realistiskt att uppnå. • Beskrivet mönster är väl komponerat och optimalt för att uppnå målet. • Värdeförädlingsobjektet är tydligt beskrivet. • Värdeförädlingsobjektet får ett sluttillstånd som motsvarar målbeskri-

ningen. • Ägare och förvaltning av processbeskrivningen är utsedd.

Processimplementeringskvalitet • Hur stor del av processen är implementerad i verksamheten, både vad

gäller detaljeringsgrad och omfattning av aktiviteter

Processföljsamhetskvalitet • Hur väl följer det verkliga genomförandet processens mönster, både vad

gäller mål och aktiviteter

Processen beskriver ett optimalt sätt att uppnå processmål, men det är bara det verkliga genomförandet utifrån processen som skapar faktiska resultat och som ger nytta för avnämaren. Resultatet jämförs sedan med det tänkta resultat (pro-cessmålet) som definieras i processen.

Med effekt-/resultatkvalitet avses förhållandet mellan processmål (sluttill-stånd för värdeförädlingsobjekt) och det faktiska utfall som föreligger efter fak-tiskt genomförande utifrån processen. Hur mycket avviker det faktiska utfallet från det uppsatta processmålet? Hur stor får avvikelsen vara för att säga att ef-fekten är rimlig? Detta kan självklart vara väldigt olika mellan olika typer av verksamheter. Man måste också ta med i beräkningen att det mål som faktiskt gäller i det enskilda fallet också kan avvika från det uppsatta ”teoretiska” pro-cessmålet.

Sida 38

Bild 22. Relationen mellan processen, d.v.s. mönstret, och det faktiska genomförandet

Det beskrivna ”mönstret”, d.v.s. vilka delprocesser som ska genomföras och i vilken ordning - sekventiellt, parallellt, repetitivt, har tagits fram därför att man tror sig veta att målet kan uppnås, eller att effekten/ resultatet på ett bättre sätt kan säkras, om man i verksamheten följer detta mönster.

Sida 39

Bild 23. Olika kvalitetsaspekter vid processframtagande, -implementering och -genomförande

Om verksamheten inte lyckas följa den överenskomna processbeskrivningen kan detta kan till exempel bero på följande

- en dålig processkunskap, d.v.s. bristfällig utbildning av medarbetare som ska ingå i den aktuella processen,

- en bristfällig förankring i verksamheten – motivationen hos medarbetare kan vara låg,

- att processen är dåligt förankrad hos ledningen, vilket till exempel kan innebära att man inte säkrar nödvändiga resurser, eller utbildning av medarbetare, för att processen ska kunna genomföras,

- att det ofta saknas nödvändiga och kritiska resurser i olika delar i proces-sen, exempelvis nödvändig information, eller

- att nya kunskaper kräver en förändring av samverkan mellan olika roller.

4.3.2 Verksamhetens processer och dess beroenden Utifrån klargjorda målbeskrivningar ska lämpliga processer identifieras och se-dan utformas. Det tenderar ofta att börja kartlägga processer innan man har identifierat vilka mål som ska uppnås inom verksamheten! Utifrån målformule-ringar identifieras vad som är verksamhetens kärnverksamhet och därmed dess kärnprocess/kärnprocesser. Om verksamheten har flera kärnprocesser är det viktigt att klarlägga beroende mellan dessa samt förstå i vilken ordning dessa bör beskrivas. Till kärnprocesser kopplas de styrande och stödjande processer

Sida 40

som också behövs. Alla dessa processer med identifierade beroenden utgör verksamhetens processkarta.

Bild 24. Exempel på processkarta där verksamhetens processer finns översiktligt beskrivna

samt beroende dem emellan

4.3.3 Syfte med metodsteget VAD, d.v.s. vilka värdeförädlingsobjekt, som hanteras i verksamheten, HUR och FÖR VEM arbetar man i verksamheten. Hur bör vi systematiskt arbeta för att skapa värde för våra ”mottagare av värde” (avnämare) samt därmed uppnå våra mål? Att beskriva ett mönster för agerande som syftar till att på säkert och ef-fektivt sätt uppnå verksamhetens olika mål.

4.3.4 Hur gör man? En processanalys ur ett värdeförädlingsperspektiv har tre huvudaktiviteter, se bilden nedan.

Bild 25. Steg i analys av processen ur ett värdeförädlingsperspektiv

Sida 41

- Identifiera processer utifrån definierade mål, se målanalysen i metodsteg

1. - Ta fram en processkarta. Vad är verksamhetens kärnpro-

cess/kärnprocesser? Vilka stödjande respektive styrande processer finns? I vilken ordning bör processerna kartläggas.

- Beskriv verksamhetens processer.

4.3.5 Notationssätt Hur processer ur ett värdeförädlingsperspektiv beskrivs i processmodeller base-ras i huvudsak på IDEF0.8

En processmodell byggs upp av

- förädlingsobjekt, - delprocesser, och - beskrivning av förädlingsväg.

Bild 26. Symboler i en processmodell

Förädlingsobjekt är det som förädlas (tillförs värde till) i processen. Alla delpro-cesser ska tillföra mervärde till det inkommande förädlingsobjektet, ur avnäma-rens synvinkel (avnämare kallas ibland för kund). Det är avnämaren som ska använda eller dra nytta av processens resultat.

En process och dess delprocesser kan ”brytas ned” i mer detaljerade beskriv-ningar. Det är viktigt att det är samma förädlingsobjekt som tillförs värde, oav-sett detaljeringsnivå i beskrivningen. Det vill säga ingångsvärdet (tillstånd 1 i

8 Integration DEFinition for Function Modeling, FIPS Publication 183 released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST) http://www.idef.com/idef0.htm

Sida 42

bild 2 nedan) till den övergripande processen ska tas om hand i delprocesser på alla nivåer och resultatet (tillstånd 2) av den övergripande processen skapas i tillhörande delprocesser, så att kedjan hänger ihop.

Bild 27. Illustration av hur en processmodell brutits ned i mer detaljerade beskrivningar

För vissa processer vars nedbrytning är relativt enkel går det att istället visa in-nehållet direkt i samma diagram, som visas i bilden nedan.

Bild 28. Nedbrytning kortform

Processmodellen ska läsas från vänster till höger. En delprocess ska alltid för-ädla det inkommande objektet till något som är bättre, och i slutänden till ett sådant tillstånd som möjliggör att uppnå uppsatta mål. En delprocess behöver oftast resurser av olika slag för att åstadkomma resultat. De ritas på pilar som kommer underifrån i grafen (se nedan). Dessutom behöver man styrning av delprocesser av olika slag, vilket ritas på pilar ovanifrån. Dessa riktningar för samband kommer ursprungligen från IDEF0.

Sida 43

Bild 29. En processmodells beståndsdelar

Enbart en processbeskrivning ur ett värdeförädlingsperspektiv är dock inte till-räcklig för att kunna implementeras. Det finns alltid en viss abstraktionsnivå i en sådan processbeskrivning. Därför bör den kompletteras med en processbe-skrivning ur ett samverkansperspektiv för att denna ska kunna appliceras på en verksamhet och dess olika organisationer.

Processbeskrivning ur ett samverkansperspektiv ska ses som en konkretisering av värdeförädlingsperspektivet. I samverkansperspektivet definieras vilka roller som har ansvar och samverkar för att utföra processen och därmed åstad-komma värdeförädling. Genom det här perspektivet anpassas processen till konkreta förutsättningar hos en viss verksamhet med dess olika organisationer. Vilka olika medarbetare i dessa organisationer som ska kunna åta sig de roller som definieras är något som kan skilja sig mellan olika organisationer. Man måste alltså ta hänsyn till lokala förutsättningar vid implementation av proces-sen.

4.3.6 Analys av processer ur ett samverkansperspektiv

Bild 30. Analys av processen ur ett värdeförädlingsperspektiv resulterar i en flödesmodell

Analys av processer ur ett samverkansperspektiv ska ses som en konkretisering av processer ur ett värdeförädlingsperspektiv. Detta perspektiv har till syfte att beskriva hur mål i verksamheten ska uppnås på samverkansnivå, d.v.s. beskriva aktiviteter som utförs samt i vilken ordning och av vem. Fokus ligger på hur olika roller samverkar i processen för att åstadkomma uppsatta mål genom att tillföra mervärde till ett förädlingsobjekt.

Aktiviteter, ansvarsroller och aktivitetssekvenser beskrivs i detta perspektiv.

Sida 44

Roller ställer krav på vilken information som behövs för att kunna genomföra aktiviteter. I ett följande metodsteg kompletteras analysen med informations-behov beskrivet i form av informationsmängder som input och output till varje aktivitet. Modeller som beskriver processen ur ett samverkansperspektiv kan då också utgöra underlag till beskrivningar av användningsfall och ansvarsroller.

När processen implementeras i verksamheten anpassas beskrivningar ur ett samverkansperspektiv till verksamhetens förutsättningar. Detta perspektiv är rollorienterad och situationsanpassad. Det kan innebära att till exempel olika organisationer i praktiken kan komma att behöva implementera en process ur ett samverkansperspektiv på olika sätt. Beskrivning av en process ur ett föräd-lingsperspektiv förändras inte, däremot bör beskrivningen ur ett samverkans-perspektiv anpassas till lokala förutsättningar. Hur den i verkligheten kommer att implementeras kan bero på vilken kompetens och vilka övriga resurser som finns tillgängliga under en tidsperiod.

Processen ur ett värdeförädlingsperspektiv kan över tid ändras i sin utformning beroende på nya kunskaper, förändrade resultatkrav eller andra faktorer. Pro-cessen ur ett samverkansperspektiv kan ändras beroende på organisationsför-ändringar, ändrade rollbeskrivningar, förändrad tillgång till kompetenser etc.

En viktig anledning till att genomföra en processanalys ur ett samverkansper-spektiv är att verksamhetens olika roller ska få en bättre förståelse för sina ar-betsrutiner.

En annan viktig anledning till att göra en processanalys ur ett samverkansper-spektiv är att underlätta kartläggning av informationsmängder som olika roller behöver för att utföra sina aktiviteter samt att komma överens om var den in-formation skapas, eller bör skapas, som behövs för att mäta processföljsamhet och effekt-/resultatkvalitet samt hur denna information ska göras åtkomlig.

4.3.7 Syfte med detta metodsteg HUR och MED VEM arbetar man i verksamheten? Analysen fokuserar på ett samverkansperspektiv.

Att komma överens om hur en process implementeras i verksamheten samt hur roller i verksamheten, inklusive kunden, samverkar för att åstadkomma det re-sultat som processen ska uppnå.

Processanalys ur ett samverkansperspektiv är en viktig förutsättning för att i nästa metodsteg kunna analysera de olika rollernas informationsbehov, d.v.s. vilken information som behövs och skapas i de olika aktiviteterna för att roller-na ska kunna utföra sina aktiviteter på ett effektivt och säkert sätt.

Sida 45

4.3.8 Hur gör man? Processanalys ur ett samverkansperspektiv brukar av många upplevas som det enklaste momentet i metoden.

Bild 31. Steg i en analys ur ett samverkansperspektiv

- Ta fram processer ur ett samverkansperspektiv utifrån processer ur ett förädlingsperspektiv d.v.s. beskriva samverkan mellan olika roller.

Denna beskrivning är därefter underlag för analys om informationsbehov, se nästa metodsteg.

4.3.9 Notationssätt

Notationen bör följa regelverket i Business Process Model and Notation, BPMN 2.0.9 Se bilaga.

Bild 32. Exempel på en processbeskrivning ur ett samverkansperspektiv enligt BPMN

Modellen byggs upp av

- roller med tilldelat ansvar – grå fält, ibland kallat för ”simbanor” (eng-elska swimlane)

- starthändelse – grön cirkel

- sluthändelse – röd cirkel

- aktivitet – grön fyrkant

9 http://www.bpmn.org/

Sida 46

- port – val eller alternativ

- aktivitetssekvens – pilar

- meddelandesignaler – om aktivitetssekvenser går mellan roller som inte tillhör samma rollsamling.

4.4 Begreppsanalys

Bild 33. En begreppsanalys resulterar i en begreppsmodell

I en verksamhetsanalys är det viktigt att genomföra en begreppsanalys eftersom det i varje verksamhet hanteras begrepp som alla roller måste förstå och vara överens om för att kunna samverka på ett effektivt sätt. Vad menas med de ut-tryck som används i verksamheten? Begreppsanalysen fokuserar på den egent-liga betydelsen av ett visst begrepp i verksamheten, inte på den eller de termer (ord inom ett visst fackområde, fackspråk) som används för att uttrycka och kommunicera begreppet. VIA-metodens metodsteg för begreppsanalys ska inte förväxlas med terminologiskt arbete. VIA-metodens analys av begrepp syftar framförallt till att klargöra de mest centrala begreppen inom en verksamhet och beskriva hur dessa förhåller sig till varandra. Parallellt med denna analys bör också alltid ett terminologiskt arbete bedrivas. Se avsnitt 2.3.4.

Begreppsmodellering inom en viss verksamhet uppfyller flera syften. Det finns många fackbegrepp som redan är definierade och används inom respektive bransch. Under begreppsanalysen diskuteras dessa begrepp och överenskom-melse om deras betydelse inom organisationen uppnås. Använder vi dessa be-grepp på rätt sätt? Har vi samma uppfattning om dem? Använder vi dessa be-grepp på samma sätt? I ett sådant begreppsförankringsarbete inom en organi-sation förekommer ofta att fackbegrepp får en mer sammanhangsanpassad be-tydelse som är relevant för just den här organisationen. Innebörden i begreppen blir ibland smalare än den som motsvarande fackbegrepp har, ibland med fokus på en viss egenskap eller nyans. Därför är det viktigt att gå igenom och disku-tera förståelse av redan etablerade fackbegrepp inom en organisation.

Sida 47

Det finns också begrepp som är väldigt specifika för en viss organisation och då är det viktigt att komma överens inom verksamheten om vad vi menar med dessa begrepp samt hur och i vilket sammanhang vi använder dem.

Kanske måste vi också använda andra, mer ändamålsenliga, begrepp som vi inte tidigare använt i en viss verksamhet men som används inom annan verksamhet. Men när ett begrepp introduceras i ett nytt sammanhang så kan det sannolikt få någon nyansskillnad i förhållande till hur de används inom andra verksamhets-områden. Det är därför viktigt att man noga överväger valet av en term för be-greppet. Är det lämpligt att använda en term som många andra verksamheter använder sig av, men där betydelsen och förståelsen avviker något? I dessa fall är ett terminologiskt arbete mycket viktigt, se avsnitt 2.3.4.

Begreppsanalysen utgår från företeelser som diskuteras i mål- och processana-lyser. Sedan identifieras de centrala begrepp som ska analyseras djupare. Be-greppsanalys är, som alla övriga metodsteg, ett iterativt arbete. Redan under processalysen har man behov av att identifiera centrala begrepp.

Begreppsanalys resulterar i en begreppsmodell som beskriver innebörden i be-greppen genom att påvisa samband mellan dem. En begreppsanalys kan göras med hjälp av tekniken begreppsmodellering. Med detta menas att analysen ge-nomförs genom att begreppen och dess samband till varandra åskådliggörs.

Begreppsanalysen baseras på det synsätt som beskrivs i meningstriangeln, ibland kallad för Ogdens triangel10, d.v.s. förhållandet mellan en företeelse, en term och ett begrepp. I normalt språkbruk antas en term referera till en viss fö-reteelse. I själva verket används termen till att namnge en uppfattning om någonting i verkligheten som en person betraktar eller upplever. Det är alltid en person som uppfattar och det är denna uppfattning som utgör begreppet.

10 Charles K. Ogden and I. A. Richards, The Meaning of Meaning: A Study of the Influence of Language upon Thought and of the Science of Symbolism, 8th ed.; (New York: Harcourt, Brace &World, 1946).

Sida 48

Bild 34. Ogdens triangel

Begreppsmodellering är en teknik som används vid analys av begrepp (utför begreppsanalys). Tekniken bygger på att man separerar begreppet (uppfatt-ningen/idén) från termen (ord/symbol) som används för att kommunicera om begreppet. Konkret betyder det att

- en term namnger bakomliggande begrepp,

- begrepp definieras av sina samband till andra begrepp,

- samband också är begrepp.

Ett och samma begrepp kan ibland tilldelas flera olika termer. Dessa termer, som alltså namnger samma begrepp, sägs då vara synonymer. Om en term där-emot används för flera olika begrepp kallas detta för att termen är en homonym. I en specifik verksamhet är det särskilt besvärligt om det förekommer homony-mer. Vilket begrepp som avses när termen används kan oftast framgå ur det sammanhang som det används i. Att hantera information i IT-stöd runt homo-nymer skapar dock alltid problem.

Synonymer är dock inte alltid helt överlappande, d.v.s. betyder inte exakt samma sak. Oftast finns en viss glidning i nyanser av betydelse mellan olika sy-nonymer.

4.4.1 Syfte med metodsteget VAD menas med termer och begrepp i verksamheten? Vad kommunicerar/ talar vi om i verksamheten? Vilka grundläggande begrepp och termer i verksamheten måste vi vara överens om?

Sida 49

Syftet med detta metodsteg är att få en gemensam uppfattning om verksamhet-ens grundläggande begrepp och termer genom att beskriva och åskådliggöra en begreppsstruktur, d.v.s. hur begreppen relaterar till varandra. Hur hänger det vi talar om i verksamheten ihop med varandra? Vilka ord/termer använder vi som etiketter för våra begrepp? Denna begreppsstruktur är också viktig att bli över-ens om inför en analys av verksamhetens informationsbehov. Jämför ”Att mena samma sak” och ”att mäta samma sak”.

Ett exempel på några grundläggande begreppsområden som utgångspunkt för begreppsanalysen är

- roller, - agerande/aktiviteter, - vad vi agerar på/vad vi hanterar (vad vi utreder, skapar, bearbetar, åt-

gärdar etc.), - resultat/utfall av aktiviteter, - resurser som används i aktiviteterna.

4.4.2 Hur gör man? Begreppsanalysen kan delas in i två huvudaktiviteter.

Bild 35. Steg i en begreppsanalys

- Lista de begrepp som indikeras av mål och process - Ta fram en begreppsstruktur och beskriv begreppen samt dess relationer

i en begreppsmodell.

4.4.3 Notationssätt Det finns ett flertal olika notationssätt för begreppsmodeller. I många fall an-vänds samma notationssätt som för informationsmodeller (se metodsteg 2.5.3 nedan) vilket gör det svårt att direkt se syftet med modellen, d.v.s. om den visar begrepp eller informationsklasser. Exempel på ett sådant notationssätt är UML, Unified Modeling Language11, se bilden nedan. Om UML används för be-greppsmodeller så kan ett alternativ vara att använda sig av andra färger på be-greppen än för informationsklasser för att direkt kunna se att modellen är en begreppsmodell.

11 Se Object Management Group (OMG), http://www.omg.org

Sida 50

Bild 36. Exempel på begreppsnotation med UML

Ett annat exempel är begreppsmodell enligt STANLI-språket, i grunden utveck-lat inom SISU12 och använt i ett arbete inom SIS, Standardiseringen i Sverige som just benämndes STANLI13. Nedan visas en sådan begreppsmodell.

12 Svenska institutet för systemutveckling, www.sisuportal.se 13 Stanli – SIS, tk323, www.sis.se

Sida 51

Bild 37. Exempel på begreppsnotation enligt STANLI14

4.4.4 Begreppsanalys och terminologiarbete För att kunna åstadkomma ett bra resultat i begreppsanalysen bör på ett tidigt stadium två kompetenser samverka, nämligen terminologikompetens och verk-samhets- och informationsanalytiker. Terminologikompetens definierar begrepp på typnivå och sätter in dessa i ett visst fackspråkligt sammanhang. Ett väldefinierat fackspråk möjliggör entydig kommunikation mellan verksamhetsföreträdare inom ett visst fackområde. Analytiker strukturerar begrepp både på typ- och instansnivå vilket resulterar i en begreppsstruktur som utgörs framförallt av atomära, d.v.s. inte delbara i mindre beståndsdelar, element i ett visst sammanhang. Denna struktur skapar förutsättningar för att åstadkomma en effektiv kommunikation, inte bara mel-lan verksamhetsföreträdare utan även mellan IT-system. Ett syfte med atomära element i begreppsstrukturen är bland annat att kunna återanvända informat-ion som sedan skapas i IT-system för olika ändamål, d.v.s. att kombinera atom-ära element till utsagor om verksamheten, exempelvis för verksamhetsuppfölj-ning, analys och statistik.

14 Begreppsmodell från Nationell Informationsstruktur, delrapport Modeller med beskrivningar, artikel-nummer 2010-4-4

Sida 52

Innebörd i begreppen som är definierade inom ett eller flera fackområden preci-seras ytterligare i en begreppsanalys och kopplas till ett visst sammanhang i en verksamhet. Samverkan mellan terminologer och analytiker bör ske under hela begreppsana-lysen. När begreppsstrukturen är stabil bör terminologisk kompetens gå igenom alla involverade begrepp i strukturen, ta fram begreppsdefinitioner, föreslå re-kommenderade termer och ta fram en lista över synonymer för begreppen.

4.5 Informationsanalys Metodsteget informationsanalys utgörs av två delar – informationsbehovs- och informationsstrukturanalys.

Bild 38. Informationsanalysen består av två delar

4.5.1 Informationsbehovsanalys

Bild 39. Analys av informationsbehov är kopplat till aktiviteter i processen

Resultatet av processanalysen ur ett samverkansperspektiv möjliggör identifie-ring av informationsbehov, d.v.s. vilken information som behövs och skapas i de olika aktiviteterna för att de olika rollerna ska kunna utföra dessa på ett effektivt och säkert sätt. En informationsbehovsanalys görs också för att kunna be-stämma vilken information som behövs för att kunna följa upp olika kvalitetsa-spekter av en viss process. Var uppstår denna information och hur ska den gö-ras åtkomlig för uppföljning?

Sida 53

En informationsbehovsanalys av det senare skälet kan göras vid olika tillfällen, om behovet av information för uppföljning förändras. Behovet av uppföljning av processer är nästan aldrig konstant, utan skiftar över tiden. Ibland uppstår be-hov av att under en tidsperiod detaljstudera olika delar av en process. Om det då har gjorts en informationsbehovsanalys tidigare kan man lättare avgöra vilken befintlig information som kan användas, eller vilken roll som under denna tids-period bör bidra med ytterligare, mer detaljerad information. Det är viktigt att hela tiden ifrågasätta den information som registreras för uppföljning och som inte används ”operativt” vid genomförandet. Det bör vara tydligt vem som verk-ligen behöver informationen!

4.5.2 Syfte med metodsteget VILKEN INFORMATION BEHÖVER OCH SKAPAR rollerna i sina aktiviteter? Informationen beskrivs som informationsmängder in till eller ut från aktivite-ter. I detta metodsteg inventeras behov av information. Denna information be-höver inte vara strukturerad utan detta görs i nästa metodsteg. Det samlade in-formationsbehovet kan ses som en bruttolista över den information som efter-frågas. Denna behöver i nästa steg analyseras och struktureras.

4.5.3 Hur gör man? Arbetet utgår från processanalysen ur ett samverkansperspektiv och komplette-rar denna med de olika rollernas informationsbehov.

Bild 40. Steg i en informationsbehovsanalys

- Samla in och beskriv rollernas informationsbehov i form av informat-ionsmängder

- Ta bort informationsmängder som förekommer på flera ställen, d.v.s. dubbletter

- Analysera innebörden av det beskrivna informationsbehovet, d.v.s. ana-lysera förekomster av homonymer och synonymer.

Informationen beskrivs som informationsmängder in till eller ut från aktivite-ter. Den detaljerade beskrivningen av informationsmängderna kan göras i form av tabeller i till exempel ett worddokument.

4.5.4 Notationssätt Här används också, som i processanalys ur ett samverkansperspektiv, med för-del notationssätt enligt BPMN 2.0. Den detaljerade beskrivningen av informat-ionsmängderna kan göras i form av tabeller i till exempel ett worddokument.

Processmodellen ur ett samverkansperspektiv kompletteras med

Sida 54

- beskrivning av informationsmängd – in till en viss aktivitet från ett visst informationslager eller ut från en viss aktivitet till ett visst informations-lager

- informationslager – någonstans där information hålls, exempelvis ett visst datalager.

Bild 41. Exempel på beskrivning av en process ur ett samverkansperspektiv med identifierat

informationsbehov enligt BPMN

Sida 55

4.6 Informationsstrukturanalys

Bild 42. Informationsstrukturanalys resulterar i en informationsmodell

Efter att man beskrivit informationsbehov i form av informationsmängder be-höver informationen analyseras och struktureras. Detta arbete resulterar ofta i en informationsmodell. Informationsmodeller beskriver den information som hanteras i en verksamhet samt hur den hänger ihop på ett strukturerat sätt. In-formationsklasser identifieras, tillhörande attribut beskrivs och regelverk för multiplicitet definieras. Informationen normaliseras enligt normaliseringsreg-ler.15

Resultat av tidigare metodsteg är underlag till analys av informationsstruk-turen. Kriterier för måluppfyllelse, begreppsmodell, processmodeller är input till att kunna ta fram en korrekt informationsmodell, d.v.s. en modell som av-speglar och stödjer verksamhetens behov. En informationsmodell som är verk-samhetsnära och även beskriver regler för hur information ska hanteras i verk-samhetens processer. Den framtagna begreppsmodellen är grunden till inform-ationsmodellen för att kunna identifiera informationsklasser, attribut och regel-verk. Den framtagna informationsmodellen är ”lösningsneutral”, d.v.s. den tar inte hänsyn till vilken teknik som kommer att användas för realisering.

4.6.1 Syfte med metodsteget HUR HÄNGER INFORMATION IHOP PÅ ETT STRUKTURERAT SÄTT?

4.6.2 Hur gör man?

Bild 43. Steg i analys av informationsstruktur

15 Connolly, Thomas M.; Begg Carolyn E. (2004) (på eng). Database solutions: a step-by-step guide to building databases (2. ed.). Harlow: Addison-Wesley. Libris 9326776. ISBN 0-321-17350-3

Sida 56

- Analysera, strukturera och normalisera information. - Testa informationsstruktur mot målbeskrivningens kriterier och inform-

ationsmängder.

4.6.3 Notationssätt För en informationsmodell används med fördel UML.16

Bild 44. Exempel på informationsmodell enligt UML

Informationsmodellen byggs upp av bland annat

- klasser – representerar företeelser man vill hålla information om

- förhållanden (ibland kallade för associationer) mellan klasser, inklusive specialiseringar/generaliseringar

16 Unified Modeling Language, www.uml.org

Sida 57

- attribut – egenskaper som beskriver en klass

- multiplicitet – antalsregler för förekomst av klasser och attribut.

4.7 Analys gällande behov av kodverk, klassi-fikationer och terminologier

Bild 45. Analys av behov av kodverk, klassifikationer och terminologier i en

informationsstruktur I en verksamhet kommer det nästan alltid att finnas behov av att använda sig av kodverk, klassifikationer och terminologier för att rollerna inom verksamheten ska kunna hålla information om verksamheten och kommunicera med varandra på ett entydigt sätt. I informationsmodellen struktureras information på två ni-våer – på klassnivå och på attributnivå. För vissa attribut behövs en ytterligare precisering och för detta används kodverk etc. Kodverk möjliggör strukturering av informationen på en tredje, mer detaljerad nivå. Kodverken minimerar att felaktigheter uppstår vid återanvändning av information. Informationen kan sammanställas på ett korrekt sätt.

Om en verksamhet har behov av kodverk måste informationsstrukturen peka ut de attribut där kodverk behövs. Det är viktigt att valda kodverk i detta steg kopplas till en informationsstruktur.

Ur alla förekomster i kodverken identifieras de som är relevanta att använda i ett visst sammanhang. Dessa förekomster samlas i ett urval som ska användas i detta sammanhang.

4.7.1 Syfte med detta metodsteg Fördjupa detaljeringsgraden av attribut i en informationsstruktur. Tillför ytter-ligare en dimension till informationen.

Resulterar i ett beslut om att ta fram eller använda befintliga/existerande kod-verk, klassifikationer, terminologier samt vilka delar i dessa som ska användas i verksamheten.

Sida 58

4.7.2 Hur gör man?

Bild 46. Steg i analys av behov av kodverk, klassifikationer, terminologier

- Identifiera vilka attribut som behöver kodverk etc. - Analysera om befintliga kodverk etc. uppfyller behovet - Initiera utveckling/ uppdatering av befintliga eller framtagandet av nya

kodverk etc. - Gör urval i kodverk etc.

Sida 59

5 Från branschramverk till till-lämpade beskrivningar 5.1 Förhållandet mellan branschramverk och tillämpade beskrivningar Verksamhets- och informationsbehovsanalys har till syfte att uppnå en gemen-sam uppfattning om bland annat

- syfte med verksamheten,

- arbetssätt,

- språkbruk i verksamheten och

- information som stödjer verksamheten.

Inom varje bransch finns etablerade normer och regler för hur verksamheten ska bedrivas. Internationellt uttrycks dessa bland annat genom standarder som är en norm som gäller vissa aspekter av en bransch.

Vad är en standard?

Formellt definieras en standard som ett dokument, upprättat i konsensus och fastställt av erkänt standardiseringsorgan (exempelvis, ISO, CEN och SIS).17

Vad är ett branschramverk?

Branschramverk är inte formaliserat på samma sätt som standarder. Ett branschramverk kan utgöras av ett antal formella standarder men kan också inkludera andra, inom branschen, gemensamma överenskommelser för hur verksamheter ska beskrivas och därmed bedrivas.

Både standarder och ramverk kan vara internationella men också nationella. På den nationella nivån kan ramverket dessutom hänvisa till lagar och föreskrifter.

Standarder och branschramverk har oftast en hög abstraktionsnivå och är där-för svåra att direkt omsätta och tillämpa i verksamheten. Det behövs en konkre-tisering av innehållet för en praktisk användning. Standarder och branschram-verk utgör en referensnivå som behöver konkretiseras.

Vad är VIA-metoden i förhållande till branschramverket?

17 Från Socialstyrelsen: Standarder – verktyg för säkerhet, kvalitet och effektiv upphandling inom tandvård

Sida 60

VIA-metoden ska ses som en verktygslåda som innehåller ett antal analysin-strument. Dessa instrument för analys och beskrivning av en verksamhet och dess information ska användas efter behov.

Bild 47. VIA-metoden är en verktygslåda med olika analysinstrument

Så länge det inte finns ett överenskommet branschramverk måste verksamheter inom samma bransch analyseras och beskrivas utan att utgå ifrån existerande referenser. Så småningom utkristalliseras betydelsebärande aspekter av verk-samheter och formar ett överenskommet ramverk.

Bild 48. Betydelsebärande delar av en verksamhetsbeskrivning kommer att upphöjas och

forma överenskommet branschramverk

Om ett branschramverk existerar bör resultat av ett analysarbete inom en verk-samhet referera till detta i syfte att uppnå slutmålet med en hög kvalitet på in-formation. Under arbetets gång stäms verksamhetsbeskrivningar av mot branschramverket för att resultatet ska följa överenskomna regler.

Sida 61

Genom att resultat som är framtagna i en verksamhetsanalys är kongruenta med branschramverket uppnås en spårbarhet mellan olika organisationer, då verksamhetsbeskrivningar kan jämföras med varandra.

Verksamhetsbeskrivning som utgår från branschramverket kan dessutom åter-användas för att underlätta analyser av närliggande verksamheter.

Verksamhetsbeskrivningar kan i sin tur vara en källa för vidareutveckling av branschramverket.

Bild 49. Branschramverket och tidigare analysresultat används som utgångspunkt i nästa

verksamhetsalys

Sida 62

5.2 Från det abstrakta till det konkreta inom informationshantering ur ett IT-perspektiv Här beskrivs ett arbetssätt som syftar till att som slutmål uppnå en hög kvalitet av informationshantering vid teknisk realisering.

Bild 50. Från abstrakt till konkret

Arbetssättet omfattar fyra områden.

- Standarder och branschramverk är ofta svåra att förstå och behöver där-för konkretiseras för att kunna användas. Oftast är det bara expertis inom området som behöver djup kunskap om och arbeta med dessa. Uti-från ett IT-perspektiv är denna nivå abstrakt.

- För att kunna använda standarder och branschramverk som ligger på hög abstraktionsnivå behöver dessa omvandlas till konkreta tillämpade beskrivningar. Men innan sådana kan tas fram behöver man omvandla regelverk och dessa beskrivningar till en så kallad referensnivå. Inom denna nivå brukar man tala om till exempel referensstrukturer, kliniska referensmodeller, referensmallar etc. En viktig frågeställning som exper-tis inom området arbetar med är bland annat att ta fram olika strategier för hur man på ett effektivt sätt kan omvandla abstrakta beskrivningar till mer konkreta. En av de viktigaste förmågorna inom detta område är att kunna ”se”, analysera, förstå och beskriva mönster (patterns) som är generella för verksamheten. Regelverk och dessa mönster kompletterar varandra och skapar en helhet. Detta område är ganska komplext och upplevs många gånger som svårt att förstå. Inom denna nivå arbetar ex-

Sida 63

pertis som har djupa kunskaper om standarder, branschramverk, seman-tik, informationsarkitektur m.m. men även djup kännedom om verksam-hetens behov. Genom framtagna strategier ges förutsättningar för att hitta en effektiv och framkomlig väg för tillämpning och konkretisering av informationsstrukturer samt dess realisering i IT-stöd.

- Härefter bör referensinformationsstrukturer omvandlas till tillämpade informationsbeskrivningar som är konkreta och lätta att förstå både för tekniker, som t ex leverantörer av IT-system, och för slutanvändare från verksamheten samt patienter. Exempel på tillämpade informationsbe-skrivningar är ”mallar”, webbformulär etc.

- Till sist finns den mest konkreta nivån, det som realiseras eller imple-menteras i tekniken. Denna del kan ses utgöras av minst två områden.

o Hur man lagrar data i IT-system18, d.v.s. hur datastrukturen ut-formas för lagring. Krav som ställs från bland annat vald teknisk plattform, databashanterare etc. kompletterar verksamhetsregel-verken.

o Meddelandeformat för överföring av data mellan olika IT-stöd/IT-tjänster. Verksamhetskraven kompletteras med bland annat den valda tekniska lösningens krav på dataöverföring.

För att kunna ta fram ett ramverk för branschen måste man först skapa en hel-hetssyn på branschen. I nästa avsnitt ger vi ett exempel på en sådan helhetssyn på hälso- och sjukvården. Denna helhetssyn är också väsentlig som utgångs-punkt för genomförande av verksamhets- och informationsbehovsanalys, oav-sett vilket verksamhetsområde inom hälso- och sjukvården som denna avser.

18 Data – det som lagras i IT-system (fysisk lagring)

Sida 64

6 Helhetssyn på hälso- och sjukvård När man påbörjar en verksamhets- och informationsbehovsanalys ska man identifiera vilket eller vilka verksamhetsområden analysen omfattar.

Hälso- och sjukvård som en bransch beskrivs utifrån olika verksamhetsområden som alla är lika viktiga för att uppnå slutmålet god vård. Dessa områden är

- kärnverksamhet,

- ledande och styrande samt

- stödjande och resursallokerande verksamhet.

En organisation som bedriver verksamhet inom hälso- och sjukvården måste utifrån denna indelning identifiera vilken eller vilka av dessa områden som or-ganisationen är verksam inom. Detta visas i bild 51 som är en vidareutveckling av Socialstyrelsens indelning i olika fokusområden utifrån ett processperspektiv och som togs fram inom arbetet med Nationell Informationsstruktur.19

19 Se Socialstyrelsens rapport Nationell informationsstruktur för vård och omsorg, Modeller med beskriv-ningar, 2010-4-4

Sida 65

Bild 51. Helhetssyn på hälso- och sjukvården

Oavsett verksamhetsområde spelar informationshantering en central roll. Information flödar mellan olika organisationer inom en bransch och dessa kan befinna sig på olika nivåer enligt bilden ovan. Informationshantering tar i detta fall ingen hänsyn till indelningen i verksamhetsområden. Det är viktigt att den information som hanteras ska vara kongruent och kompatibel med överens-kommet regelverk.20 Informationshanteringen måste vara gemensam för alla verksamhetsområden inom hälso- och sjukvården.

Hälso- och sjukvården delas in i följande verksamhetsområden.

Generella förutsättningar för hälso- och sjukvården inkluderar bland annat de lagar, föreskrifter, förordningar, etiskt förhållningssätt m.m. som finns inom branschen.

Området ledning och styrning av hälso- och sjukvård delas in i en strate-gisk och en operativ nivå. Den strategiska nivån sätter mål för verksamheten och har ansvar för implementation av politisk styrning, bland annat genom be-ställning, ersättning och uppföljning av vård. Den operativa nivån ansvarar för att kärnverksamheten existerar och bedrivs. 20 Kongruent – fullt överensstämmande i innebörd Kompatibel – icke motstridig, möjlig att passa samman. Se Nationalencyklopedin

Sida 66

I kärnverksamheten hälso- och sjukvård skapas mervärde för patienten.

Området verksamhetsstöd delas in i underlag för verksamhetsstöd samt operativt verksamhetsstöd. Inom underlag för verksamhetsstöd skapas personella, materiella och andra resurser. I nivån operativt verksamhetsstöd görs dessa tillgängliga för kärnverksamheten.

Det finns beroenden mellan olika verksamhetsområden och varje område in-kluderar i sin tur minst tre olika typer av processer.

Sida 67

Bild 52. Varje verksamhetsområde består av minst tre typer av processer

Sida 68

7 En effektiv kravställning med VIA-metoden 7.1 Metodik, metod, process Inledningsvis kan det vara viktigt att förklara skillnaden mellan begreppen me-todik, metod och process. Som nämnts tidigare bör en organisation ha ett meto-diskt arbetssätt. En metodik utgörs av ett antal metoder som täcker olika kun-skapsområden. Metoder används i processer. En process strävar efter att bli mer och mer effektiv och metoder kan bytas ut eller vidareutvecklas till exempel på grund av nytillkommen kunskap. Det är dock alltid viktigt att metodiken stödjer processen!

VIA-metoden i denna handbok beskriver ett antal steg för att kunna skapa en gemensam förståelse av verksamheten och dess informationsbehov. En organi-sation behöver tillämpa en ”kravställnings-/utvecklingsprocess” för att kunna applicera denna metod och andra relevanta metoder på.

Bild 53. VIA-metoden som en del i en utvecklingsprocess

7.2 Verksamhetsdriven IT-utveckling All IT-utveckling bör vara verksamhetsdriven! För att åstadkomma detta ge-nomförs verksamhets- och informationsbehovsanalys innan kravställning av IT-komponenter. För att kunna effektivisera utvecklingsarbete samt minimera fel-aktigheter vid framtagandet av verksamhetsnära- samt tekniska krav bör verk-samhetsföreträdare samarbeta med tekniska kompetenser. Verksamhetsanalys genomförs därför innan teknisk kravställning.

Det är viktigt att påpeka att kravställningsarbete är ett iterativt arbete där olika kompetenser samverkar. Ett iterativt arbetssätt kräver samtidigt att ändrade och nytillkomna krav ska hanteras enligt en tydligt beskriven ändringhante-ringsprocess.

Sida 69

Modeller som är resultat av verksamhets- och informationsbehovsanalys är inte alltid tillräckliga för att kunna tillgodose en IT-nära kravställning. Verksam-hetsmodellerna behöver ofta kompletteras med andra perspektiv, som exempel-vis användningsscenarios och verksamhetsanvändningsfall för funktioner i verksamheten som inte omfattas av processbeskrivningar.

7.3 Utvecklingsprocess Denna processbeskrivning avgränsas endast till utvecklingsprocessen, som är en del i till exempel en portföljstyrningsprocess. Den beaktar arbeten både med verksamhetsutveckling, informationshantering samt kravställning och reali-sering av IT-stöd.

Bild 54. Utvecklingsprocess

Processen Utveckling startas med att det tas ett beslut i en beredning som ger klartecken till att påbörja en förstudie som kan omfatta delar av verksamhets- och informationsbehovsanalys, validering och IT-kravställning på en grov, idémässig nivå. En förstudie kan vara av olika dignitet, det vill säga vara en kortfattad förstudie på övergripande nivå eller en mer ingående förstudie med djupare analys av problemställningar. Analysarbetet resulterar i ett underlag för

Sida 70

beredningen att ta ställning till i frågan och fatta beslut om nästa steg. Bered-ningen beslutar att starta ett utvecklingsarbete exempelvis som projekt, upp-drag eller linjearbete med verksamhetsanalys som kan inkludera eller exkludera informationsbehovsanalys. Verksamhets- och informationsbehovsanalys bör genomföras enligt en vedertagen och beslutad metod som resulterar i verksam-hets- och informationsbeskrivningar och därför bör arbetet genomföras enligt VIA-metoden.

Utifrån problemanalysen identifieras vilka steg som ska genomföras i verksam-hetsanalysen och en handlingsplan bör tas fram för denna.

Resultatet av verksamhets- och informationsbehovsanalysen i form av olika modeller och beskrivningar har en lång livscykel inom verksamheten. Eftersom verksamhetsanalysen är

- tidskrävande, - kompetenskrävande (många olika kompetenser bör samarbeta), och - resurskrävande

så bör resultatet förvaltas och vidareutvecklas inom organisationen.

Kravställning av IT-komponenter har en kortare livscykel. Resultat av en verk-samhetsanalys kan ge input till flera olika IT-utvecklingsarbeten/-projekt.

Eftersom verksamheten redan aktivt har deltagit i verksamhets- och informat-ionsbehovsanalysen bör det vara tillräckligt att verksamhetsföreträdare säker-ställer att IT-kompetenser uppfattar verksamhetskraven på ett korrekt sätt.

Den framtagna verksamhetsbeskrivningen bör valideras i en större gruppering som består av verksamhetsföreträdare, metodspecialister, EA-, verksamhets-, informations- och IT-arkitekter. Genom att resultatet granskas i ett större sammanhang blir det också förankrat inom verksamheten.

Det validerade och förankrade resultatet ligger till grund för att kunna identifi-era vilken typ av utvecklingsarbete som är relevant samt att besluta om fortsätt-ningsarbete. Detta beskrivs i en handlingsplan. Fortsättningsarbete kan vara en eller kombination av flera typer;

- verksamhetsutveckling - framtagande och/eller vidareutveckling av informationsarkitektur - framtagande av IT-komponent.

Arbete inom en av dessa typer ställer dock krav på förändringsarbete inom de andra två typerna!

En verksamhetsbeskrivning kan användas som underlag för många olika typer av IT-utvecklingsarbeten. Tid och resurser sparas genom att INTE genomföra verksamhetsanalyser i varje enskilt projekt utan återanvända tidigare arbeten. Dessa kan visserligen behöva kompletteras.

Verksamhetsanalys skapar underlag för

- verksamhetsutveckling

Sida 71

o Kartläggning och implementering av processer i verksamheten - framtagande av IT-strategi - informationsarkitektur

o arbete med begrepp o informationsmodeller o kodverk och urval ur kodverk o tjänstekontrakt

- kravställning av IT-komponent. För att genomföra en kvalitativt bra verksamhetsanalys bör verksamhetsföre-trädare arbeta aktivt i olika metodsteg. Engagemang av verksamhetsexpertis på en sådan nivå är svårt att åstadkomma i varje enskilt IT-utvecklingsprojekt.

Återanvändbara och kvalitativt bra verksamhetsbeskrivningar minimerar därför avsevärt kostnader för IT-utvecklingsprojekt. Man åstadkommer också spår-barhet, och därmed skapas förutsättningar för semantisk interoperabilitet, mel-lan olika IT-realiseringar.

Resultat av implementering blir en viss åstadkommen förändring inom respek-tive typ av delprocess.

Den implementerade förändringen bör valideras/testas i förhållande till krav-bild. Beroende på typ av delprocess finns olika angreppssätt för validering/test.

När verksamhets- och informationsbehovsanalysen är genomförd bör man vali-dera framtaget resultat genom ”instansiering” av modellerna. Med detta menas att man ”kör” ett antal scenarios/case/fall. Jämför rollspel inom en viss process där verksamheten använder framtagen begreppsapparat samt hanterar struktu-rerade informationsmängder som har direkt spårbarhet till informationsstruk-turen. Urval ur kodverk etc. kan användas i detta rollspel för att ytterligare granska begrepps- och informationsstruktur och modeller.

Detta arbete kan aldrig ge en fullständig validering av resultatet, det finns alltid en viss abstraktionsnivå som man måste ta hänsyn till. Modeller är inte verklig-het!

Den åstadkomna förändringen enligt kravbilden bör analyseras utifrån ef-fekt/nytta i verksamheten.

Resultatet av utvecklingsarbetet ska överlämnas till en förvaltningsorganisation som har ett tydligt ägarskap för vidare realiseringsarbete.

7.3.1 Leverabler från delprocess Verksamhetsanalys Verksamhets- och informationsbehovsanalys resulterar i en eller flera leverabler i form av modeller och textuella beskrivningar:

- målmodell - intressentbeskrivning - processmodeller - begreppsmodell - beskrivningar av informationsmängder

Sida 72

- informationsmodeller - utpekade och/eller egna definierade kodverk etc. - urval ur kodverk etc.

I de fall man ska fortsätta med IT-kravställning räcker inte bara leverabler från verksamhetsanalysen. Dessa måste kompletteras med IT-relaterade verksam-hetskrav, exempelvis

- verksamhetsnära use cases - scenariobeskrivningar - användargränssnitt - icke funktionella krav - informationssäkerhet - etc.

7.4 Process för vägledning av verksamhets- och informationsbehovsanalyser utifrån ge-mensamma riktlinjer På nationell och regional nivå behövs en funktion som ansvarar för regelverk, riktlinjer och rekommendationer avseende verksamhets- och informationsbe-hovsanalyser (här kallas denna funktion för VIA funktion). Funktionen faststäl-ler normer och regelverk för hur modeller och beskrivningar ska utformas i verksamhets- och informationsbehovsanalyser. Dessa modeller är en del av le-veranser från olika projekt.

När ett nytt arbete ska startas kan det finnas behov av en verksamhets- och in-formationsbehovsanalys. Projekten och uppdragen måste få hjälp med vägled-ning och metodstöd för att kunna genomföra dessa analyser på ett effektivt och korrekt sätt. Dessutom bör de framtagna resultaten granskas för att uppfylla kvalitetskriterier. Nystartade projekt ska därför kontakta VIA funktion inom sin organisation för vägledning och stöd.

I detta avsnitt beskrivs en process för samverkan mellan VIA funktion och olika projekt/uppdrag.

Processen utgår från PROJEKTiL21 och består av fem delprocesser

- information

- introduktion

- avstämning

- granskning

21 PROJEKTiL - Projektstyrningsmodell framtagen av Stockholms läns landsting

Sida 73

- leveransmottagande.

7.4.1 Information När det finns ett beslut om att en idébeskrivning ska gå vidare till en initierings-fas, och att därmed en kortare förstudie ska genomföras, bör man ta kontakt med VIA funktion för ett första informationsmöte. Under mötet ska VIA funkt-ion hjälpa till med att identifiera om det finns behov av en verksamhets- och/eller informationsbehovsanalys och i vilken omfattning, vilka typer av ana-lyser som bör genomföras och därmed vilka kompetenser som behövs för detta. Dessutom hjälper VIA funktion till med att peka ut tidigare kunskapskällor som kan ha betydelse för den aktuella förstudien.

Bild 55. Informationsmötet ska stödja arbetet att omforma idé till projektdirektiv

7.4.2 Introduktion När det finns ett projektdirektiv startas en etableringsfas. I förstudien har man diskuterat vilka typer av analyser gällande verksamhets- och/eller informations-behov som är aktuella. I inledningen av etableringsfasen bör man ta kontakt med VIA funktion för ett introduktionsmöte. I detta ingår att funktionen ska hjälpa till med följande:

- Identifiera inom vilken eller vilka verksamhetsområden som analys ska göras.

- Informera om det finns referensbranschramverk och standarder inom det område som ska analyseras.

- Identifiera vilka typer av modeller eller terminologiskt arbete som ska beskriva resultat av analysen, t ex målmodell, begreppsmodell, informat-ionsmodell, ordlista.

- Informera om metoder som ska användas i analysarbetet.

- Informera om regler för hur analysresultat ska dokumenteras.

- Tillhandahålla mallar för modeller och dokumentation.

- Identifiera behov av utbildning för olika målgrupper i projektet.

Sida 74

Bild 56. Introduktionsmötet består av ett antal steg

Efter det att projektet har fått introduktion, utbildningsmaterial, mallar för mo-delleringsarbete m.m. har man möjlighet att kontakta VIA funktion om det finns ytterligare frågor.

Sida 75

7.4.3 Avstämning När projektet har genomfört en del av sitt analysarbete görs en avstämning med VIA funktionen. Det genomförda analysarbetet diskuteras och förutsättningar klargörs för en ”kvalitetsstämpel” av detta. Detta innebär att projektet har ge-nomfört analysarbetet enligt bestämd metodik och att resultatet har dokumen-terats på ett korrekt sätt. Avstämningen omfattar följande:

- Diskutera innehåll i dokumentationen utifrån verksamhetens behov.

- Att innehåll i modeller är kongruent mot branschramverk och valda standarder.

- Att modeller är beskrivna enligt modelleringsregler.

- Att ordlistor är överensstämmande med terminologiska källor.

- Att det finns en plan för hur modellerna ska testas/verifieras.

- Att det finns en plan för förankrings- och eventuellt förändringsarbete.

- Diskutera vilka delar av leveransen som eventuellt ska förvaltas av VIA funktionen.

- Att det finns utpekade ägare och förvaltningsansvariga för övriga leve-ranser.

- Att projektet har beskrivit spårbarhet mellan verksamhetens krav och framtagen IT-lösning.

Bild 57. Avstämningsmöte under genomförandet av verksamhets- och

informationsbehovsanalys

Sida 76

Efter avstämning kan projektet eventuellt behöva bearbeta och komplettera analysresultatet.

7.4.4 Granskning När projektet ska leverera sitt resultat granskar VIA funktionen aktuella leve-ranser. Följande granskas:

- Att innehållet motsvarar verksamhetens krav.

- Att modeller är kongruenta och kompatibla22 med övriga verksamhets-komponenter som förvaltas inom VIA funktionen.

- Att resultatet följer referensbranschramverk och standarder om sådana har pekats ut.

- Att modeller har en sådan detaljeringsgrad som möjliggör att det går att sätta samman levererade modeller i en övergripande modell och att de därmed också kan återanvändas.

- Att dokumentationen följer regelverk, d.v.s. att modeller är beskrivna en-ligt beslutad notation och att man har använt beslutat modelleringsverk-tyg.

- Att modellerna är validerade genom att exempelvis några verksamhets-exempel har testats i modellen.

- Beslut om vilka leveranser som ska förvaltas av VIA funktionen.

22 Kongruent – fullt överensstämmande i innebörd Kompatibel – icke motstridig, möjlig att passa samman. Se Nationalencyklopedin

Sida 77

Bild 58. Granskning av leveranser

Sida 78

7.4.5 Leveransmottagande Denna delprocess avser de leveranser som ska överlämnas till VIA funktionen för förvaltning. Delprocessen utgörs av följande delar:

- VIA funktionen planerar för mottagande av leveranser, vilket innebär att man tar fram en handlingsplan för förvaltning av leveranser. Denna kan se olika ut för olika typer av leveranser.

- VISA funktionen utser en resurs inom förvaltningen som ska ha ansvar för själva mottagandet och vidarehantering av leveranserna inom för-valtningen.

- Mottagande av leveranser.

Bild 59. Mottagande av leveranser

Sida 79

7.4.6 Koppling mellan PROJEKTiL och VIA funktion Under projektens gång behöver möten genomföras mellan projekten och VIA funktionen för de olika syften som beskrivs ovan. I bilden nedan visas när dessa möten bör äga rum utifrån PROJEKTiL:s23 projektlivscykel.

Bild 60. Bilden visar när möten mellan ett projekt och VIA funktionen bör äga rum

23 PROJEKTiL är framtagen av Stockholms läns landsting (SLL)

Sida 80

8 Kompetenser, roller och an-svar För att kunna bedriva en framgångsrik verksamhetsutveckling och informat-ionshantering inom en verksamhet samt kunna vidareutveckla och förvalta re-sultat av analysarbete, behöver man bygga upp en kompetensbas inom organi-sationen och tillsätta ett antal olika roller med tydligt definierade uppgifter och ansvarsområden. I detta avsnitt beskrivs kompetenser, roller och ansvar inom respektive område som behöver etableras inom verksamheten.

Eftersom en verksamhet bör arbeta enligt en viss beprövad metod är det viktigt att bygga upp kompetenser för metodutveckling och -tillämpning inom organi-sationen. Här behövs kunskap om hela metoden och hur den bör implementeras i verksamheten. Inom många branscher pågår arbete med metodutveckling för att kunna effektivisera verksamheten och optimera dess informationsförsörj-ning. Inom vård och omsorg finns idag ingen gemensam metod för verksam-hets- och informationsbehovsanalys. Det finns inte heller vedertagna rollbe-skrivningar som täcker detta område.

Minst tre olika roller som bör etableras inom organisationen för arbete med me-todutveckling och implementering. Vissa roller bör bemannas med personal från den egna organisationen, medan andra kan bemannas av externa resurser för tydligt avgränsade uppgifter.

Metodägare ansvarar för metodutveckling i helheten och skapar förutsätt-ningar för att kunna tillämpa metoden i verksamheten. Denna roll bör beman-nas av egen personal.

Metodstödsspecialist deltar i projekt som vägledare och utbildare, stödjer projekt i helheten och ser till att arbete genomförs enligt beslutad metod. Det är önskvärt att en verksamhet har flera metodstödsspecialister i proportion till or-ganisationens storlek. Denna roll kan bemannas med externa resurser.

Kvalitetsgranskare granskar alla projekts resultat och ser till att alla projekt arbetar enligt beslutad metod samt att alla projektens leverabler är i linje med verksamhetens helhetsbild. Denna roll kan bemannas antingen med egen per-sonal eller med externa resurser.

För att kunna bedriva verksamheten på ett optimalt sätt, och dessutom kunna ta fram en tydlig handlingsplan för hur verksamhetens vision ska uppnås, bör or-ganisationen beskriva verksamhetens helhetsbild. Helhetsbilden bör omfatta både en nulägesbeskrivning och en beskrivning av ett börläge, d.v.s. ett önskat framtida läge. Helhetsbilden omfattar en processkarta där alla verksamhetens processer är beskrivna på en övergripande nivå, begreppsstruktur i form av en verksamhetsgemensam begreppsmodell, ett tydligt definierat fackspråk samt en verksamhetsgemensam och övergripande informationsmodell.

Sida 81

I arbete med verksamhetens helhetsbild bör följande kompetenser ingå

- kompetens avseende verksamheten,

- ledningskompetens,

- kompetens inom Enterprise architecture,

- metodkompetens,

- för fackspråk behövs terminologikompetens,

- för informationsmodell behövs kompetens inom informationshantering.

Framtagen helhetsbild ska förvaltas, kommuniceras och förankras inom organi-sationen.

För arbete med fackspråk bör en terminolog involveras. Denna roll har ansvar för att ta fram, vidareutveckla och förvalta fackspråk och kan bemannas med extern kompetens.

För arbete med en övergripande informationsstruktur behövs rollen informat-ionsarkitekt. Denna roll har ansvar för att ta fram, vidareutveckla och förvalta övergripande informationsmodell samt kommunicera och förankra denna med verksamheten. Rollens ansvar innebär också att harmonisera verksamhetens informationsmodell med befintliga nationella och internationella standarder och branschramverk. Denna roll bör bemannas av egen personal.

Bild 61. Exempel på beroenden mellan informationsmodeller som beskriver

informationsstrukturer med olika abstraktionsnivåer

Sida 82

För att nå verksamhetens börläge krävs att tydliga strategier för verksamhets-förändring och informationshantering tas fram. De roller som ansvarar för detta är verksamhetsstrateg och informationsstrateg. Dessa roller bör beman-nas av egen personal.

Verksamhetsföreträdare bör delta i arbetet med sin kunskap om verksam-heten och stå för detaljerad verksamhetskunskap i analysarbetet.

För att kunna ta fram verksamhets- och informationsbehovsbeskrivningar be-hövs olika roller.

Workshops- och modelleringsledare samt dokumenterare innehar workshopslednings- och modelleringskompetens samt kompetens i modelle-ringsverktyg. Denna roll har ansvar för att leda, modellera och beskriva resultat av workshops. Rollen kan bemannas med extern resurs.

Metodstödsspecialist har kunskap om beslutad metod och bistår i analysar-beten med helhetsbilden. Rollen kan bemannas med extern resurs.

För att kunna ta fram fackspråk och lokala kodverk behöver man samverka med en terminolog. Rollen kan bemannas med extern resurs.

För förvaltning av framtagna resultat behövs rollen förvaltare som besitter modelleringskompetens, kompetens i modelleringsverktyg samt har en viss verksamhetskunskap. Förvaltare ansvarar för vidareutveckling av dessa be-skrivningar samt tillgängliggör dessa för verksamheten. Det är viktigt att påpeka att rollen förvaltare förekommer inom varje verksamhetsområde där man har arbetat med verksamhets- och informationsbehovsanalys. Denna roll bör be-mannas av egen personal.

Utifrån ett lednings- och styrningsperspektiv bör det finnas roller som pro-cessägare och informationsägare. Deras ansvar är att skapa förutsättningar för att kartlägga och beskriva, vidareutveckla, implementera, förvalta beskriv-ningar samt följa upp processer och informationshanteringen inom ett visst verksamhetsområde. Dessa roller bör bemannas av egen personal.

Kartlagda och beskrivna process ska implementeras inom en viss verksamhet. Detta arbete ska ledas av rollen förändringsledare som besitter förändrings-ledningskompetens samt viss verksamhetskompetens och har ansvar för pro-cesser inom ett visst verksamhetsområde. Rollen kan bemannas med extern resurs.

För att kunna följa upp och granska följsamhet till och effekt av processer bör en roll som processgranskare etableras inom verksamheten. Denna roll har kunskap om verksamhetens börläge (målbild) samt viss verksamhetskompetens och ansvarar för uppföljning och granskning av följsamhet till och effekt av pro-cesser samt tillhörande informationshantering. Denna roll kan bemannas med extern resurs.

Sida 83

När informationsbehov är analyserat och beskrivet är nästa steg att implemen-tera informationsmängder och informationsstruktur inom ett visst verksam-hetsområde, exempelvis genom att utveckla ett effektivt IT-stöd.

Informationshantering inkluderar även arbete med kodverk, terminologier, klassifikationer och begreppssystem som tas fram på olika nivåer

- internationellt

- nationellt

- regionalt.

För att kunna genomföra ett sådant arbete behövs rollen förändringsledare som har informationsmodellkompetens för att kunna förstå modeller samt kompetens inom förändringsledning. Denna roll ansvarar för implementering av informationsmängder (mallar, web-formulär, blanketter etc.) och informat-ionsstruktur inom ett visst verksamhetsområde. Rollen kan bemannas med ex-tern resurs.

Sida 84

Bilaga 1. Övergripande bild av metodsteg

Sida 85

Bilaga 2. Bild över innehåll i me-todsteg

Sida 86

Bilaga 3. Problembild för verksamheten, dess informationshantering och IT-stöd

Område

Perspektiv

Vision, målbild och strategi

Verksamhet

Informationshantering IT-stöd

Eftersom det inte finns nå-gon gemensam helhetsbild av nuvarande verksamhet, dess målbild samt strategi för hur målbilden ska upp-nås så…

Utan gemensam helhetsbild av nuvarande verksamhet, dess målbild samt strategi är det svårt att beskriva effek-tiva processer som ska leve-rera resultat som i sin tur ska ge måluppfyllelse.

Utifrån verksamhetens mål-bild och strategi bör även målbild och strategi för in-formationshantering tas fram. Eftersom det inte finns någon sådan målbild och strategi blir resultatet att information inte blir spårbar och att det skapas ”öar” av informationsmängder som inte är kompatibla med varandra. Arbete med inform-ation är ett kontinuerligt ar-bete och det måste finnas en tydlig målbild och strategi för hur man vidareutvecklar in-formation.

Eftersom det inte finns en ge-mensam målbild för verksam-heten och inte heller för in-formationshanteringen så är det nästan omöjligt att ta fram en verksamhetsbaserad och realistisk IT-strategi.

Sida 87

Område

Perspektiv

Metodik Verksamhet Informationshantering IT-stöd Eftersom det inte finns nå-gon gemensam metod för arbete med verksamhets-utveckling och informations-hantering så…

Resultat kan inte åter-användas. Det förekommer ofta att olika projekt och ini-tiativ inom organisationen arbetar på olika sätt, kravbe-skrivningarna blir på olika detaljeringsnivåer och foku-serar på olika saker. Resultat beskrivs på olika sätt, ingen gemensam notat-ion och olika verktyg an-vänds. Det finns ingen ge-mensam plats att spara och förvalta resultat på. Det saknas metodkompe-tenser för att stödja verk-samheten i sitt utvecklings-arbete. Projekten brukar ha väldigt stort behov av att få metodstöd i sitt arbete. Metodspecialister bör ha ett tydligt definierat mandat att kunna driva frågor om ett metodiskt arbetssätt. Eftersom olika projekt arbe-tar på olika sätt och att det

Om man inte använder en gemensam metod så är risken stor att olika modeller för in-formationsstruktur inte är kompatibla med varandra.

Resultat kan inte åter-användas. Det förekommer ofta att olika projekt och ini-tiativ inom organisationen arbetar på olika sätt, kravbe-skrivningarna blir på olika detaljeringsnivåer och fokuse-rar på olika saker.

Sida 88

inte finns en gemensam hel-hetsbild resulterar detta i att spårbarhet saknas mellan olika perspektiv.

Område

Perspektiv

Huvudprocesser Verksamhet Informationshantering IT-stöd Eftersom man inte arbetar enligt en gemensam metod så…

Verksamheten arbetar inte på ett enhetligt sätt enligt enhetliga processbeskriv-ningar som är framtagna en-ligt en inom organisationen beslutad metod. Det fattas en gemensam och beslutad nomenklatur för hur processer ska beskrivas. Detta kommer att innebära att processbeskrivningar som tas fram inom olika projekt inte blir jämförbara och inte kan sättas samman till en större helhetsbild. Det sak-nas ägarskap för framtagna processer och ingen control-lerfunktion som ska säker-ställa att verksamheten följer de framtagna processerna.

Eftersom man inte arbetar enligt beskrivna processer så innebär detta att man inte hanterar information på ett enhetligt sätt. Eftersom processbeskriv-ningarna inte är jämförbara så kan det innebära att informat-ion inte enkelt och konsekvent kan återanvändas för olika processer. Nya informations-mängder skapas för ”samma sak” eller samma behov och ett resultat av detta är redun-dant information.

Eftersom verksamheten inte arbetar efter beskrivna pro-cesser och det inte finns tyd-liga rutiner för informations-hantering i dessa processer är konsekvensen att det blir svårt att kravställa ett effektivt IT-stöd. Även om IT-stödet är avance-rat utifrån ett tekniskt per-spektiv kan det ändå inte stödja verksamheten effektivt eftersom det inte finns ett ge-mensamt arbetssätt inom verksamheten.

Sida 89

Område

Perspektiv

Begrepp Verksamhet Informationshantering IT-stöd Eftersom man inte har en gemensam begreppsapparat så…

Verksamhetens begrepp upp-fattas på olika sätt. Samtidigt benämns samma begrepp olika. Detta leder till att det är mycket svårt att på ett ef-fektivt sätt samverka mellan olika organisationer/ aktö-rer. Det blir också svårt att ge-nomföra kvalitativa uppfölj-ningar samt att ta fram kvali-tativt statistiskt underlag.

Informationen blir inte ge-mensamt definierat och där-med felaktig.

Information som hanteras i IT-stöd blir av dålig kvalitet, det förekommer redundans. När olika termer för samma begrepp, eller samma term för olika begrepp, används blir information som hanteras i IT-stöd felaktig.

Sida 90

Område

Perspektiv

Informationsstruktur Verksamhet Informationshantering IT-stöd Eftersom det saknas en ge-mensam informations-struktur så…

Eftersom det inte finns en beskriven gemensam in-formationsstruktur och in-formationsmängder (i form av checklistor, mallar etc.) blir resultatet att det före-kommer mycket dubbelregi-strering inom verksamheten. Det blir också svårt att ge-nomföra kvalitativa uppfölj-ningar samt att ta fram kvali-tativt statistiskt underlag.

Eftersom det saknas en ge-mensam informationsstruktur innebär detta att information inte hanteras på ett optimalt sätt. Det förekommer extra administrativt arbete för regi-strering av information sam-tidigt som det förekommer felaktig hantering av inform-ation. Information kan inte jämföras och återanvändas på ett korrekt sätt för olika än-damål. Risken är stor för dubbelregi-strering av information.

Avsaknad av gemensam in-formationsstruktur resulterar i att man inte hanterar in-formation vid källan. Det är nästan omöjligt att återan-vända information. IT-stöd kan inte kommunicera med varandra eller kommunikation sker på ett felaktigt sätt (miss-uppfattningar). Det förekom-mer mycket dubblerad in-formation som leder till att många felaktigheter uppstår. Detta leder till ett resurs- och tidskrävande administrativt arbete.

Sida 91

Område Perspektiv

Regelverk för beskrivning av informationsstruktur

Verksamhet Informationshantering IT-stöd

Eftersom det saknas ett gemen-samt regelverk för beskrivning av informationsstruktur så…

Det saknas regelverk för be-skrivning av informations-poster, exempelvis - format - datatyper - benämningar - multiplicitet Detta innebär att samma typ av information definieras på olika sätt. Det finns ingen styrning för hur information ska definieras/beskrivas. Detta skapar mycket fel i in-formationshanteringen samt att information blir av så då-lig kvalitet att den inte kvali-tativt kan återanvändas för olika ändamål. Idag rapporterar vården en mängd olika parametrar för olika uppföljningar, men ef-tersom informationskvali-teten är så pass låg är det meningslöst att använda dessa till analysarbete.

Det resulterar i många fel-sökningar i IT-system som kräver många administra-tiva och tekniska resurser. Även om det går att tek-niskt kommunicera mellan olika system så blir denna kommunikation meningslös eftersom informationskvali-teten är väldigt låg. Resultatet blir också att information inte kvalitativt kan återanvändas för olika ändamål. Eftersom information inte lagras enligt ett gemensamt regelverk behövs omfat-tande mappningsarbete mellan olika system.

Sida 92

Område

Perspektiv

Kodverk Verksamhet Informationshantering IT-stöd Eftersom det inte finns gemen-samma kodverk så…

Det saknas förutsättningar för verksamheten att följa upp sin verksamhet på ett kvalitativt sätt.

Det går inte att kvalitativt återanvända och samman-ställa information för olika ändamål.

Förutsättningar för seman-tisk interoperabilitet be-gränsas.

Sida 93

Bilaga 4. Kompetenser, roller, ansvar I tabellen nedan beskrivs kompetenser, roller och ansvar som behövs inom en organisation för att man ska kunna genomföra verksam-hetsutveckling, förvalta resultat av analysarbeten samt bedriva en effektiv informationshantering på ett metodiskt sätt.

Område

Kompetens Roller Ansvar

Metodutveckling och -tillämpning (kunskap om hela metoden samt hur den appliceras på verksam-heten)

Metodkompetens Metodägare Ansvara för metodutveckl-ing i helheten samt skapa förutsättningar i organisa-tionen för tillämpning av metoden

Metodkompetens Metodstödsspecialist Delta i projekt som vägle-dare och utbildare, stödja projekt i helheten och se till att arbete genomförs enligt metoden

Metodkompetens Kvalitetsgranskare Granska alla projekts resul-tat och se till att alla arbetar enligt metoden och att alla leverabler är kompatibla med organisationens hel-hetsbild

Verksamhetens helhetsbild Nu- och börlägesbeskrivningar - processkarta där alla verksam-hetens processer är beskrivna på övergripande nivå - begreppsstruktur och fackspråk

Verksamhetskunskap Ledningskompetens EA-arkitektur Metodkompetens

Funktion som består bland annat av - Enterprise architect - Verksamhetsarkitekt - Metodspecialist

Ta fram verksamhetens helhetsbild samt förvalta, kommunicera och förankra denna inom organisationen

För fackspråk behövs termi-nologikompetens

Terminolog Ta fram, vidareutveckla och förvalta fackspråk

Sida 94

- övergripande informationsmo-dell

För informationsstruktur behövs informationsmodell-kompetens

Informationsarkitekt Ta fram, vidareutveckla och förvalta övergripande in-formationsmodell. Kommunicera och förankra denna till verksamheten. Harmonisera informat-ionsmodellen med nation-ella och internationella standarder och bransch-ramverk.

Verksamhetsstrategi Kompetens inom verksam-hetsstrategi

Verksamhetsstrateg Utifrån vision samt nu- och börläge (målbild) för verk-samheten ta fram och hålla en aktuell verksamhetsstra-tegi som syftar till att nå målbilden

Informationshanterings-strategi

Kompetens inom informat-ionshanteringsstrategi

Informationsstrateg Utifrån vision samt nu- och börläge (målbild) för verk-samheten och dess inform-ationshantering ta fram och hålla en aktuell informat-ionshanteringsstrategi som syftar till att nå målbilden för informationshantering

Analys inom olika metodsteg Verksamhetens - målbeskrivning - processbeskrivningar - begreppsstruktur och fackspråk - informationsbehov i form av informationsmängder samt in-formationsstruktur - kodverk etc.

Workshopslednings- och modelleringskompetens samt kompetens i modelle-ringsverktyg

Workshops- och modelle-ringsledare samt dokumente-rare

Leda, modellera och besk-riva resultat av workshops

Verksamhetskompetens

Verksamhetsföreträdare Stå för verksamhetskun-skap

Metodkompetens Metodstödsspecialist Metodstöd och helhetsbild

För fackspråk och kodverk etc. tillkommer terminologi-

Terminolog Stödja framtagande av ändamålsenligt fackspråk

Sida 95

kompetens och kodverk etc.

Förvaltning av resultat inom ett verksamhetsområde Verksamhetens - målbeskrivning - processbeskrivningar - informationsbehov i form av informationsmängder samt in-formationsstruktur - kodverk etc.

Modelleringskompetens Kompetens i modellerings-verktyg En viss verksamhetskompe-tens

Förvaltare Ansvara för vidareutveckl-ing av resultat. Tillgänglig-göra beskrivningar för verk-samheten.

Processmanagement

Lednings- och styrnings-kompetens

Processägare Ansvara för att skapa förut-sättningar för att kartlägga och beskriva, vidareut-veckla, implementera, för-valta beskrivningar samt följa upp processer inom ett visst verksamhetsområde

Implementering av proces-ser inom ett verksamhets-område

Verksamhetskompetens Förändringsledning

Förändringsledare Ansvara för implemente-ring av processer inom ett visst verksamhetsområde

Uppföljning/granskning av följsamhet till och effekt av processer

Verksamhetskompetens Kunskap om verksamhetens börläge (målbild)

Processgranskare Ansvara för uppfölj-ning/granskning av följ-samhet till och effekt av processer samt tillhörande informationshantering

Informationshantering

Lednings- och styrnings-kompetens

Informationsägare Ansvara för att skapa förut-sättningar för att kartlägga och beskriva, vidareut-veckla, implementera, för-valta och följa upp informationshanteringen

Sida 96

inom ett visst verksamhets-område

Implementering av inform-ationsmängder och inform-ationsstruktur inom ett visst verksamhetsområde. Arbete med kodverk, termi-nologier och klassifikationer som tas fram på följande ni-våer Internationellt Nationellt Regionalt Lokalt

Informationsmodellkompe-tens för att kunna förstå modeller Förändringsledning

Förändringsledare Ansvara för implemente-ring av informationsmäng-der och informationsstruk-tur inklusive urval ur kod-verk, terminologier och klassifikationer inom ett visst verksamhetsområde

Sida 97

Bilaga 5. Mall för beskrivning av intressenter

Scope: _______

Intressent Beskrivning Varför intressent Direkt/ indirekt

Sida 98

Referenser Nationell eHälsa – strategin för tillgänglighet och säker information inom vård och om-sorg, 2010, http://www.nationellehalsa.se/Content/Cms/img/temp/b38c1b84.pdf

Nationell Informationsstruktur – ett regeringsuppdrag inom Nationell IT- strategi för vård och omsorg, artikelnr 2009-12-27

Nationell informationsstruktur för vård och omsorg. Modeller med beskrivningar. En del-rapport från projektet Nationell Informationsstruktur, artikelnr 2010-4-4

Informationsspecifikation. Verksamhetsdokumentation för Verksamhetsorienterad Till-lämpad InformationsModell V-TIM 2.2, CeHis 2012-12-18

VIFO-kartan, http://www.socialstyrelsen.se/SiteCollectionDocuments/vifo-kartan.pdf

Socialdepartementet, Uppdrag om nationell informationsstruktur och nationellt fackspråk, S2007/4754/FS, Utgiven: 7 april 2014, http://www.regeringen.se/sb/d/108/a/238187

Anita Hedin, Lena Jernberg, H-C Lenner, Torsten Lundmark, Sven-Bertil Wallin. Att mena och mäta samma sak – en begreppsorienterad metod för terminologiskt arbete. u.o. : Stu-dentlitteratur, 2000

RIV - Regelverk för Interoperabilitet inom Vård och omsorg, CeHis, http://www.cehis.se/images/uploads/dokumentarkiv/RIV-V-TIM_v_22.pdf

VITS-handboken, CeHis, http://www.cehis.se/images/uploads/dokumentarkiv/VITS_boken_regelverk_till_arkitektur_for_eHalsa_1_0_1.pdf

Kort om klassifikationer: www.sv.wikipedia.org/wiki/Klassifikation www.ne.se/kort/klassifikation

Vattenfallsmetoden, http://sv.wikipedia.org/wiki/Vattenfallsmodellen

Svensk Byggtjänsts "Aff-definitioner"

Integration DEFinition for Function Modeling, FIPS Publication 183 released of IDEFØ De-cember 1993 by the Computer Systems Laboratory of the National Institute of Stand-ards and Technology (NIST), http://www.idef.com/idef0.htm

Charles K. Ogden and I. A. Richards, The Meaning of Meaning: A Study of the Influence of Language upon Thought and of the Science of Symbolism, 8th ed.; (New York: Harcourt, Brace &World, 1946).

Object Management Group (OMG), http://www.omg.org

Svenska institutet för systemutveckling, www.sisuportal.se

Stanli – SIS, tk323, www.sis.se

BPMN, http://www.bpmn.org/

UML - Unified Modeling Language, www.uml.org

Zachmans Framework - http://www.zachman.com

Sida 99

TOGAF - http://www.opengroup.org/togaf/

http://www.socialstyrelsen.se/lists/artikelkatalog/attachments/8352/2009-126-130_2009126131.pdf

Connolly, Thomas M.; Begg Carolyn E. (2004) (på eng). Database solutions: a step-by-step guide to building databases (2. ed.). Harlow: Addison-Wesley. Libris 9326776. ISBN 0-321-17350-3