Implementation av utvärderingsmetod inom IT-styrning baserad på COBIT

Transkript

1 Implementation av utvärderingsmetod inom IT-styrning baserad på COBIT HANNA WIJKSTRÖM Master Thesis Stockholm, Sweden 2006 XR-EE-ICS 2006:023

2 Sammanfattning. IT-investeringarna är den största kostnad för många företag i dag och hanteras av alla delar av ett företag inte bara IT-avdelningen. Därför är en klar och tydlig struktur i hur man hanterar IT-frågor av stor vikt för att kunna säkerställa beslutsfattandet och kontrollen av IT inom hela företaget. Idag finns det ingen objektiv metod för att utvärdera hur IT-styrning sköts på företag, utan alla befintliga metoder bygger på att perswonen som genomför analysen har god inblick och erfarenhet i ämnet. Detta examensarbete presenterar implementationen och praktiskt testande av en formaliserad metod för utvärdering av IT-styrning, IT Organisation Model Assessment Tool (ITOMAT). Metoden har sin grund i best-practice ramverket Control Objectives for Information and related Technology (Cobit) och bygger på att man skapar och utvärderar modeller av organisationen. Cobit används både för att skapa och utvärdera modellerna. Examensarbetet har haft som mål att praktiskt implementera denna metod och automatisera utvärderingen för ökad tillgänglighet genom utökande av funktionaliteten i modelleringsverktyget METIS. En modell innehållande de entiteter Cobit presenterar skapades som en modell över en perfekt IT-organisation. Denna modell jämfördes sedan med en modell skapad över IT-organisationen på Umeå Energi. Jämförelsen utfördes med vissa bedömningskriterier i beaktande. Resultatet presenteras som en mognad för Umeå Energis ITstyrning. Abstract. The IT investments are increasingly taking a larger part of the budget for many companies today and are distributed all over the organisation. A clear and well-defined structure of the organisation to ensure responsibility and control over IT is utterly important. Today no straightforward method to assess the IT governance of organisations exists. This master thesis presents the implementation and testing of IT Organisation Model Assessment Tool (ITOMAT), a formalized method for assessment of IT governance. ITOMAT is based on the framework Control Objectives for Information and related Technology (Cobit). The method implies the creation and comparison of models of the organisation. The goal of this master thesis was to practically implement and automate the assessments of the method for increased availability by extending the functionality of the modelling tool METIS. The implementation of the method was then tested by a case study conducted at a Swedish electric utility Umeå Energi. A model containing all the entities presented in Cobit was created to represent a perfect IT- governed organisation. This model was then compared with a model of the IT-organisation of Umeå Energi. The comparison was implemented and assessed based on criterias from maturity model in Cobit. The result of the assessment at Umeå Energi is presented as a maturity of the IT governance. 5

3 Översikt Kapitel 1 beskriver bakgrunden till detta examensarbete och hur det passar in i tidigare forskning, samt syftet med detta examensarbete med mål och begränsningar. Kapitel 2 söker presentera teorin och forskningen som är grunden till denna rapport. I kapitel 3 beskrivs examensarbetets projektmodell med vad de olika faserna omfattar. Kapitel 4 förklarar utvärderingsmetoden och kapitel 5 hur man använder det. Kapitel 6 beskriver fallstudiens utförande. I kapitel 7 presenteras resultaten av utvärderingen på Umeå Energi. I kapitel 8 följer diskussion kring projektet med validitets- och tillförlitlighetsanalys av resultaten. I det sista kapitlet, kapitel 9, så framställs rekommendationer för utveckling av metoden. 6

4 Ordlista API Application Programming Interface, ett gränssnitt som beskriver hur man får tillgång till funktioner i en applikation utan att ha tillgång till funktionernas källkod. ATD Architecture Theory Diagrams, en struktur för mätning av verksamhetsmodeller. Best practice empirisk kunskap om bästa förfarandet. CIO Chief Information Officer, den roll som vanligtvis bär ansvaret för frågor gällande ett företags informationsstrukturer CMM Capability Maturity Model, en mognadsmodell för mjukvaruprocesser utvecklad av SEI. COBIT Control OBjectives for Information and related Technology, ett ramverk för IT-styrning utvecklat av IT Governance Institute, ITIG. DoDAF - Department of Defence Architecture Framework, ett ramvek för företagsarkitektur utvecklat av U.S. Department of Defence. EA Enterprise Architecture, verksamhets- och IT-modelleing, en metod för att visualisera ett företags olika entiteter med hjälp av schematiska modeller av företaget. ICS - Avdelningen för industriella informations och styrsystem, KTH Instansmodell En modell i ITOMAT över ett företag baserat på empirisk datainsamling. IT governance IT-styrning, handhavandet av de organisatoriska aspekterna av IT. ITIL IT Infrastructure Library, ett ramverk baserat på best practice för hanteringen av IT- tjänster utvecklat av Office of Government Commerce. ITGI IT Governance Institute, ett fristående amerikanskt institut som bedriver forskning kring ITstyrning. ITOMAT IT- Organization Modeling and Assesment Tool, namnet på den metod utarbetad av doktorand Mårten Simonsson vid ICS och implementerad inom ramen för detta examensarbete. Se vidare kapitel 4. KGI Key Goal Indicator, benämning i Cobit för de mätvärden som presenterar hur väl en process (Process Key Goal Indicator) eller IT (IT Key Goal Indicator) utfört.s KPI Key Performance Indicator, benämning i Cobit för de indikatorer som presenterar hur väl en aktivitet utförts. 7

5 Metamodell - Ramverk som modeller baseras på i Metis. Metis Ett program för verksamhetsmodellerings ägt av Troux Technology. RACI Förkortning av namnen på relationerna mellan roller och aktiviteter i Cobit. Responsible, Accountable, Consulted och Informed Referensmodell En modell i ITOMAT som utifrån Cobit beskriver den ideala IT organisationen. SEI- Carnegie Mellon Software Engineering Institute, ett statligt finansierat amerikanskt institut för forskning och utveckling inom mjukvara, IT-säkerhet och processförbättringar. TOGAF - The Open Group Architecture Framework, ett ramverk för företagsarkitektur utvecklat av Open Group, ett konsortium inom IT med medlemmar över hela världen. 8

6 Innehållsförteckning Ordlista 7 Innehållsförteckning 9 1 Introduktion Bakgrund Syfte Mål Avgränsningar 12 2 Teori IT-styrning Cobit Modelleringsanalys Trovärdighet 17 3 Metod Initieringsfasen Teori och utredning Utveckling av analysstöd Fallstudie Analys Projektavslut 19 4 ITOMAT Metamodeller i Metis Metamodell baserad på Cobit Referensmodell Instansmodell Utvärdering 24 5 Implementation Aktivitetsutförande Ansvarsfördelning Dokumentation och Utförda mätningar Aggregering 34 6 Fallstudie Umeå Energi Respondenter Intervjumetodik Trovärdighet 36 7 Resultat av fallstudien IT-styrningsmognad hos Umeå Energi 36 8 Diskussion Specificering av system under utvärdering Behandling av trovärdigheten Resultat på Umeå Energi Validitet Tillförlitlighet 42 9 Förslag till förbättringar Rekommendationer för utvärderingen Rekommendationer för datainsamlingen Rekommendationer till Umeå Energi APPENDIX REFERENSER 55 9

7 1 Introduktion Denna rapport presenterar ett examensarbete utfört vid avdelningen för industriella informations- och styrsystem (ICS) på Kungliga Tekniska Högskolan i Stockholm. Handledare för examensarbetet var doktor Mathias Ekstedt och doktorand Mårten Simonsson. Examensarbetet initierades av ICS som ett led i arbetet med att förenkla analysen av verksamhetsmodeller Examensarbetet är specifikt del av doktorand Mårten Simonssons forskning kring framtagandet av metoder för utvärdering av företags IT-styrning genom modellanalys. 1.1 Bakgrund Behovet av en integrerad syn på organisationsstruktur, affärsprocesser, IT-applikationer och teknisk infrastruktur är stort hos företag idag. När organisationer växer sig större, slås ihop och globaliseras så ökar komplexiteten hos företagens system och helhetsbilden blir allt mer diffus. Kvaliteten hos system och processer kan inte längre bara bedömas relativt sig själva, hela kontexten där de verkar måste tas i beaktande. För att kraftfullt kunna agera i en värld i ständig omvandling är en klar struktur inom företaget med tydliga ansvarstaganden och mål nödvändigt. Trycket på att IT-processerna verkligen ska stödja verksamheten ökar, och insikten om att en dåligt anpassad IT-organisation driver kostnader har skapat intresse för en övergripande företagsarkitektur. Enterprise architecture (EA), verksamhetsmodellering, är ett sätt för beslutsfattare att nå en strukturerad och övergripande bild över företaget. EA-modeller beskriver abstraktioner av företagets olika entiteter och hur de relaterar till varandra. Modellerna skapas med olika perspektiv beroende på syftet, till exempel ur ett tekniskt perspektiv med funktioner och applikationer eller ur en organisatorisk synvinkel med aktiviteter och roller. Modellerna representerar så samma verklighet men med olika referensramar. För vidare beskrivning av EA se kapitel 2.3. Inom ramen för detta examensarbete har de organisatoriska aspekterna av IT varit i fokus. Struktur för beslutsfattande och mätning av IT, samt kontroll av hur IT påverkar och maximerar företagets affärsmål benämns ofta som IT-styrning. Det av utövare mest använda ramverket för IT-styrning idag är Control Objectives for Information and related Technology (Cobit) utvecklat av institutet för ITstyrning, IT governance institute (ITGI)[4][16]. Ramverket är utvecklat ur best-practice genom att formalisera de olika aktiviteterna, processerna och ansvarstaganden som empiriskt sätt bedöms som viktiga för att nå effektiv IT-styrning. Cobit innehåller även en beskrivande mognadsmodell för att nå och mäta framsteg i processerna. Kapitel 2 ger en bredare presentation av IT-styrning och Cobit. En av de största nackdelarna med Cobit, och kanske den största anledningen till varför det inte används mer av utövarna, är att mycket kunskap om ramverket krävs för att kunna använda det som ett stödeller utvärderingsverktyg för IT-styrning. För att kunna förbättra företagets IT-styrning, hitta tradeoffs och jämföra sig mot andra företag så krävs ett sätt att utvärdera företagets nuvarande prestation. Även om ett stort antal aktiviteter, processer och ansvarstaganden beskrivs i Cobit så finns det ingen tydlig korrelation mellan aktiviteternas utförande och mognadsmodellen. Mognadsmodellen i Cobit ger inte en djuplodande analys över situationen och inte heller ett tillräckligt stöd eller formaliserad metod i utvärderingsprocessen. Stor erfarenhet och expertkunskaper krävs hos utredaren för att kunna utföra en rättvis utvärdering av en IT-organisation med Cobit. Vidare så ges inget stöd för att garantera att den erfarna analytikern A kommer till samma slutsats om ett företags IT mognad som analytiker B[15]. Doktorand Mårten Simonsson vid ICS arbetar med att adressera och avhjälpa detta problem genom skapandet av en formaliserad metod för utvärdering av IT-styrning[15]. Metoden går under beteckningen IT Organization Model Assessment Tool (ITOMAT) och använder sig av EA-modeller med ramverket Cobit som referensram. Metoden kan övergripande beskrivas i tre moment: 1) Skapa en referensmodell, en ideal modell, baserad på kunskap från Cobit om vad som ger effektiv IT- 10

8 styrning; 2) Skapa en modell över hur det verkligen ser ut på företaget; 3) Utvärdera företagsmodellen med jämförelsekriterier mot referensmodellen. Företagsmodellen kommer fortsättningsvis att refereras som instansmodellen. ITOMAT beskrivs mer detaljerat i kapitel 4. En schematisk bild av metodens tre moment presenteras i figur 1. Idag finns det flera olika mjukvaror på marknaden som stödjer verksamhetsmodellering[18][18], men de saknar alla stöd för att på ett enkelt sätt göra jämförelseanalys av modellerna. Att implementera ITOMAT för användning i modelleringsverktyget Metis[18] är startpunkten för detta examensarbete. Figur 1 Schematisk skiss över ITOMAT 1.2 Syfte Det övergripande syftet med detta examensarbete är att förenkla utvärderingsprocessen av organisationsmodeller med de organisatoriska aspekterna av IT som referensram. 1.3 Mål Målet för detta examensarbete kan presenteras som två särskiljda om än sammankopplade delmål: 1. Utveckling av funktionalitet i Metis Funktionalitetsutveckling av modelleringsprogrammet Metis till att stödja utvärdering av Cobit-modeller. Detta inkluderar att med hjälp av script sammankoppla två olika modeller, en referensmodell och en instansmodell, i modelleringsverktyget Metis, samt att implementera kriterier och beräkningar för jämförelseutvärdering av dessa inom ramen för ITOMAT. Vidare ska stöd för aggregering av resultatet skapas så att ett företagsövergripande resultat för IT-styrning enkelt kan nås. För detaljer se kapitel Fallstudie Praktiskt testa det utvecklade utvärderingsstödet och bedömningsmetoden genom att samla in mätdata medels intervjuer och skapa en instansmodell över Umeå Energis IT-styrning. Instansmodellen ska sedan utvärderas mot en referensmodell, baserad på Cobit, med hjälp av det utvecklade analysstödet och ett mått på Umeå Energis IT-styrning nås. För detaljer se kapitel 6. 11

9 1.4 Avgränsningar Detta examensarbete fokuserar på organisatoriska aspekter inom ICS forskningsområde IT-styrning. Ramverket Control Objectives for Information and related Technology Cobit används som referensramverk i modelleringen av de modeller som användes i analysen. Datainsamlingen som utfördes på Umeå Energi är till för att praktiskt testa implementationen, examensarbetets fokus ligger i att realisera användandet av metoden. 2 Teori I detta kapitel presenteras den teori som ligger till grund för examensarbetet. Detta innefattar förklaring av begreppet IT-styrning och ramverket Cobit. Vidare presenteras teorin bakom den modellanalys som används. 2.1 IT-styrning IT-investeringarna är den största kostnad för många företag i dag och hanteras av alla delar av ett företag inte bara IT-avdelningen, vilket gör det svårt att motivera centralisering av IT[19] Studier visar att de företag som presterar bäst är sådana som har en distribuerad styrningsstruktur så att den är kopplad till prestationen och så kan harmonisera IT-organisation med företagets affärsmål[19]. Det är således av stor vikt att klargöra affärsprocesserna och anpassa IT-strukturen till dem. En tydlig bild över ansvarstagande inför de organisatoriska förändringar som krävs för att nyttja IT:s kapacitet till fullo är av vikt, samt att kontinuerligt lära sig av varje ny implementation för att hela tiden förbättra IT-resurserna. IT-styrning blev ett begrepp i mitten på nittiotalet då vikten av att infoga informationsteknologin i företagets övergripande affärsstrategi blev uppmärksammat[14]. Definitionen av IT-styrning går isär, men det kan ändå fastslås att IT-styrning behandlar de organisatoriska aspekterna av IT och utövas av ledningen för att kontrollera formuleringen och implementationen av IT strategin och tillförsäkra samspelet mellan business och IT[16]. IT-styrning inbegriper även specifikation av beslutsfattande med ett ramverk för ansvarstagande för att uppmuntra önskvärt beteende i användandet av IT. Effektiv IT-styrning handlar så om att försäkra sig om att IT-investeringar går i linje med företagets mål och att uppmärksamma och agera inför ITrisker och möjligheter [6][3]. Forskning inom IT-styrning baseras främst på fallstudier och empirisk data[16][15]. Liksom meningarna om definitionen går isär gör även åsikterna om hur man ska nå effektiv IT-styrning. Det finns således inget facit till vad som är rätt. IT Infrastructure Library (ITIL) utvecklat av Office of Government Commerce [10], samt Control Objectives for Information and related Technology (Cobit), utvecklat av organisationen IT Governance Institute (ITGI)[4] är de mest kända ramverken som stödjer implementationen av effektiva IT-processer[16]. Både ITIL och Cobit är baserade på best practice, ITIL har dock en mer detaljrik struktur och ger mer beskrivande stöd för hur processer bör utföras än vad. ITIL:s fokus är att höja kvaliteten i de levererade IT tjänsterna genom att göra de operativa aspekterna av IT mer effektiva[10]. Cobit är inte alls lika detaljerat som ITIL, men ger istället ett strukturerat angreppssätt på hög nivå till IT-styrning[14]. Cobit valdes som ramverk i utvecklandet av ITOMAT då det behandlar de strategiska IT -frågorna och det anses vara de facto standard inom IT-styrning[15]. 2.2 Cobit Ramverket Control Objectives for Information and related Technology (Cobit) är idag standard för området IT-styrning[15]. Ramverket är, som ovan nämnt, utvecklat av ITGI som ett samlat best practice -dokument inom området. Den första versionen lanserades 1998 och i dags dato finns version fyra presenterad. Som namnet antyder så beskriver Cobit vilka beslut som bör fattas för att 12

10 säkerställa kontroll över IT samt vilka som bör fatta och stå till svars för dessa beslut. Cobit är utformat som ett stöd för företagsledningen i arbete att säkerställa att IT levererar värde, är i linje med företagens affärsmål, att dess prestation mäts, att resurserna är riktigt allokerade och riskerna mildras. Ramverket är positionerat på en hög nivå, drivet av affärskrav och koncentrerat kring vad som ska uppnås hellre än hur. Cobit definierar IT aktiviteter i en generisk processmodell inom fyra olika domäner. Dessa domäner är; Plan and Organize (PO), Aquire and Implement (AI), Deliver and Support (DS) samt Monitor and Evaluate (PO). Det är ett processbaserat ramverk som innefattar de IT funktioner som normalt återfinns i en IT organisation, och söker så ge en gemensam referensmodell förståelig för både den operationella sidan av IT och business managers[4]. Cobit är organiserat i totalt 34 olika processer med beskrivning av de aktiviteter, dokument och mätvärden som varje process innehåller. Cobit innehåller även visst stöd för hur man ska kontrollera, hantera och mäta varje process i en mognadsmodell kopplad till varje process. Varje process är även kopplat till affärsbehov som tillfredsställs av effektivt handhavande av processen. I figur 2 presenteras Cobit:s processer och hur de interagerar med varandra. Nedan presenteras vidare några av de definierade komponenter Cobit innehåller. Figur 2 Cobit:s processmodell[4] Processer och aktiviteter Cobit är som ovan nämnt ett processbaserat ramverk. De 34 olika processer utgör stommen i ramverket och fungerar som underkapitel till de fyra domäner presenterade ovan. Varje process omfattar ett moment som utförs i en IT-organisation. Definiera och hantera servicenivåer är ett exempel på en process i Cobit. Inom processen beskrivs vidare de aktiviteter som bör innefattas i detta moment. Aktiviteten Definiera servicenivåavtal (SLA) för kritisk IT-service tillhör de åtta aktiviteter som nämnda process innehåller. En aktivitet i Cobit representerar det som bör utföras inom varje process. Cobit detaljerar inte hur IT-styrning ska skötas utan processer och aktiviteter ger 13

11 ledning i vad som bör utföras för att nå god IT-styrning. För att nå effektiv IT-styrning krävs, som nämnts tidigare, en klar struktur för beslutsfattande. Cobit ger så även stöd i vem, vilken roll, som bör vara delaktig i och ansvarig för aktiviteterna. Roller Cobit beskriver ett antal olika roller som bör vara tilldelade i en organisation för att klargöra ansvarstagandet inför alla aktiviteter som utförs. De identifierade rollerna listas nedan: Chief executive officer (CEO) Chief information officer (CIO) Business executives Chief financial officer (CFO) Head operations Chief Architect Head development Head IT administration The project manager office (PMO) Compliance, audit risk and security Utöver dessa listade roller förekommer ytterligare roller specifikt för vissa aktiviteter. Cobit specificerar hur dessa roller kopplas till varje aktivitet de är delaktiga igenom en matris. Denna matris beskrivs utförligare nedan. Ansvarsmatris Till varje process i Cobit finns en tillhörande matris som definierar de kopplingar, relationer, som bör finnas mellan rollerna och alla aktiviteter inom processen. Matrisen benämns RACI, vilket är förkortningen för responsible(r), accountable (A), consulted (C) och informed (I). Att vara accountable för en aktivitet innebär att ha auktoriteten att bestämma över aktiviteten. Med responsible avses att vara ansvarig för utförandet av aktiviteten. Informed är den som bör vara informerad om aktiviteten, och consulted är den som bör rådfrågas om en aktivitet. Dessa relationer beskriver så åtagandena för respektive roll rörande varje aktivitet. På detta sätts styrks besluts och ansvarsstrukturen inom varje process då det blir tydligt vem som bör vara, exempelvis, informerad om vad och vem som står ansvarig för varje aktivitet. Till varje aktivitet är kopplat minst en roll som ansvarig (R) och en som auktoritet (A), relationerna informerad och rådfrågad förekommer inte i alla aktiviteter. Nedan presenteras RACI-matrisen för den första processen i domänen Planera and Organisera; Definiera en strategisk IT-plan. För exempelvis aktiviteten Koppla företagsmål till IT-mål är det rollen Business Executive som har högst auktoritet och som även, tillsammans med Chief Information Officer (CIO), ansvarar för att den utförs. Chief Executive Officer (CEO) bör konsulteras liksom den som har rollen som Business Process Owner. Chief Financial Officer (CFO) ska informeras om aktiviteten. 14

12 Figur 3 RACI- matris för processen Definiera en strategisk IT-plan. Key Performance Indicators (KPI) / Key Goal Indicators (KGI) Utöver att definiera vilka aktiviteter som bör utföras att nå god IT-styrning så innehåller Cobit även stöd för att utvärdera prestationerna inom varje process. Cobit listar ett stort antal mätvärden som bör användas för att övervaka fortskridningen av varje process och dess mognad. Ungefär ett dussin mätvärden är kopplat till varje process. KPI definierar de mätvärden som bestämmer hur väl IT processen presterar i att nå de uppställda målen genom att mäta huruvida aktiviteterna uppnått sina mål. KGI ger ledningen ett mått på om en process har uppnått de uppställda kraven, exempelvis om processen drivits kostnadseffektivt och om den är tillförlitlig. Dokument För att effektivisera och möjliggöra repetition av en process är det viktigt att relevant dokumentation finns tillgänglig och utförs. Cobit definierar för varje process de dokument som bör finnas vid processens början och vilka som bör produceras under processens gång. En lista motsvarande den presenterad i figur 4 tillhör varje process i Cobit. Figur 4 Lista med ingångs- och utgångsdata för processen Definiera en strategisk IT-plan. Mognadsmodell För att kunna utföra effektiv IT-styrning så krävs att företaget kan utvärdera sin nuvarande organisation och identifiera var förändringar behövs. Mognadsmodeller används för att befrämja processer och tillhandahålla en metod så att en organisation kan betygsätta sig själv och jämföra sig med andra inom industrin och mot internationella standarder. Cobits mognadsmodell har samma utformning som Capability Maturity Model (CMM) utvecklat av Software Engineering Institute (SEI)[14]. CMM är ett ramverk som beskriver nyckelelementen hos en effektiv mjukvaruprocess och 15

13 evolutionära förbättringar från en ad hoc, omogen process till en disciplinerat mogen process[12]. Den beskriver fem olika mognadsnivåer med definitioner och egenskaper för varje nivå. CMM utvecklades för processer för mjukvaror men modellen har använts av många organisationer för att identifiera best practices som användbar hjälp i att nå högre mognad av processer inom olika områden[10]. Mognadsmodellen i Cobit innehåller sex mognadsnivåer från 0 till 5, där 0 representerar den lägsta mognaden och 5 den högsta. För varje process finns en beskrivning av de observerbara kännetecknen per mognadsnivå. Detta innebär att en process tilldelas mognadsnivå 3 om beskrivningen av den nivån passar bäst in på processens aktuella situation. Då varje process får en mognad ger modellen utöver en måttstock som kan sättas i relation till andra företag även en metod att prioritera projekt genom att identifiera vilken processförbättring som kommer att ha störst verkan och passar bäst in på företagets riktning. 2.3 Modelleringsanalys Enterprise architechture (EA) är en metod att bistå företagens beslutsfattare (ofta Chief Information Officer, CIO) i sitt arbete i att förstå, analysera och agera utifrån de olika tekniska och affärsmässiga förändringarna som potentiellt kan komma att påverka deras företag genom att skapa en bild av hur organisationen ser ut idag. Precis som namnet antyder så är EA en slags ritning, med förbestämda komponenter, över ett företag eller en organisation. Grunden till EA ligger i att schematiskt beskriva företags olika system och de inbördes förhållandena genom att modellera abstraktioner av de olika entiteterna i ett företag och visualisera deras inbördes påverkan med tydliga relationer[11]. Bland de mest namnkunniga allmänna EA-ramverken finns The Open Group Architecture Framework (TOGAF), the Zachman Framework och Department of Defence Architecture Framework (DoDAF). Vilka förutbestämda komponenter, eller ramverk, arkitekturmodellen bygger på är beroende av vad syftet med modellen är.error! Reference source not found.[2][7][8] Givet EA-modeller över ett företag så krävs en formaliserad metod för att kunna utföra mätbara arkitekturanalyser på dem. En metod är att bryta ned modellen i mindre mätbara delar och sedan aggregera ihop resultatet för att få ett mätetal för hela organisationen. Denna struktur kallas Architechture Theory Diagrams (ATDs)Error! Reference source not found.. ATD består av noder kopplade till varandra i en hierarkisk trädstruktur där de mätbara entiteterna representeras av löven och benämns operationell egenskap. Två eller flera operationella egenskaper definierar den intermediära egenskapen, som i sin tur aggregerar till den undersökta abstrakta egenskapen, i trädstrukturen definierad som roten. I metoden ITOMAT som implementeras i detta examensarbete sökes ett mått på ett företags ITstyrning, vilket motsvarar den abstrakta egenskapen i ett ATD. I Cobit bedöms ett företags ITstyrning med dess processmognad, vilket i sin tur mäts med aktivitetsmognad. Aktiviteterna kan så representera de operationella, mätbara egenskaperna som, aggregerade, definierar processen, den intermediära egenskapen. De aggregerade processerna i sin tur definierar företagets IT-styrning. Denna struktur presenteras i figur 5 nedan. Vissa egenskaper kan vara mer eller mindre viktiga för den egenskap de definierar och varje nod kan i ett ATD ha ett viktat värde i förhållande till aggregaten på samma nivå. Summan av vikten av alla egenskaper som definierar samma egenskap uppgår alltid till 1. 16

14 Figur 5 Aktiviteten längs ned i figuren är del av processen, i mitten, som i sin tur är en del av företaget. 2.4 Trovärdighet Vid utvärdering av mätbara egenskaper såsom de operativa egenskaperna beskrivna ovan bör dessa kopplas till ett mått på hur tillförlitligt resultatet är. Till varje operationell egenskap, det vill säga uppmätt egenskap, kopplas förutom egenskapens mätvärde även ett mått på detta värdes trovärdighet. Inom ramen för denna studie har ett mått på trovärdighet valts som varierar mellan 0 % och 100 %, där 100 är full trovärdighet och 0 representerar ingen trovärdighet.[5] Aggregering För att få ett mått för hela företagets mognad så krävs att de operationella egenskaperna med tillhörande trovärdighetsmått kan aggregeras i ATD:s trädstruktur. Aggregeringen görs med Dempster-Shafer matematik då denna till skillnad från Baysiansk matematik tillåter viktning av egenskaperna. Viktningen är, som beskrivits ovan, ett sätt att prioritera de processer som anses viktigare i utvärderingsprocessen för det enskilda företaget. För vidare genomgång av matematiken vid ATD-aggregering se Johnson et. al Formalizing Analysis of Enterprise Architecture.Error! Reference source not found.[20][21][23] 3 Metod Detta kapitel presenterar examensarbetets upplägg och vad som utförts i vilka faser. Arbetet delades upp i två övergripande delar där den första delen innefattade implementation av utvärderingsmetoden ITOMAT och den efterföljande praktiskt testande av metoden i en fallstudie på Umeå Energi. De två delarna är sedan indelade i mindre faser i enlighet med figur 6 nedan och beskrivs i följande respektive underkapitel. Fas 1 Fas 2 Fas 3 Fas 4 Fas 5 Fas 6 Initiering Utredning Utveckling Fallstudie Analys Avslut Figur 6 Projektmodellen 17

15 3.1 Initieringsfasen Initialt söktes en överblick över forskningsområdet genom litteraturstudier i verksamhetsmodellering och ett första försök till avgränsning gjordes. Påbörjande undersökning av modelleringsverktyget Metis utfördes. 3.2 Teori och utredning I denna fas utfördes en grundläggande analys av modelleringsverktyget Metis. Då målet var att koppla script till modelleringsverktyget Metis undersöktes utvecklingsmiljön och grundläggande förståelse för hur programmet är uppbyggt genom studier av det Application Programming Interface (API) som Metis tillhandahåller. Genom studier i Metis vanns förståelse i hur man skapar metamodeller, något som skulle användas i nästa fas då en metamodell baserad på Cobit skapades. För att tydligare förstå institutionens behov och användning av analysstödet som skulle implementeras så gjordes en mindre litteraturstudie av ämnesområdet verksamhetsmodellering och möten med handledarna sökte ytterligare fastställa kravspecifikationen för vad stödet implementerat i Metis ska returnera. 3.3 Utveckling av analysstöd I denna fas skapades i samarbete med doktorand Mårten Simonsson den metamodell baserad på Cobit som användes som grund för de två modellerna i ITOMAT. Den skapades i Metis utifrån de entiteter som Cobit omfattar samt de funktioner för utvärderingen som fastställts i kravspecifikationen från handledarna. För vidare beskrivning av metamodellen se kapitel 4.2. I denna fas skapades även referensmodellen baserad på metamodellen, det första momentet av ITOMAT. Huvuddelen av examensarbetet innefattade implementation av funktionaliteten för ITOMAT i Metis. Denna fas omfattade utvecklingen av de script som används i Metis för kopplingen mellan referensoch instansmodellerna, samt implementation av utvärderingskriterierna av instansmodellen omfattade även implementationen av och av aggregationsmatematiken. 3.4 Fallstudie För att samla in data till skapandet av instansmodellen, moment 2 av ITOMAT, så utfördes intervjuer med de anställda på Umeå Energis IT-avdelningen. För beskrivning av fallstudien se kapitel 6. Utifrån intervjuerna så skapades instansmodellen över företagets aktiviteter och processer i METIS baserad på den metamodell över Cobit som skapades i fas 3. Se Appendix 2 för hela modellen över Umeå Energis IT-avdelning. 3.5 Analys Det sista momentet i ITOMAT behandlar utvärderingen av de två modellerna. Detta görs genom att koppla det utvärderingsstöd som utvecklats i fas 3 till de två modellerna som skapats. Ett mått på Umeå Energis Cobit mognad nåddes. 18

16 3.6 Projektavslut Projektavslutet bestod av validering av resultatet och diskussion kring framtidsutsikter för metoden. Valideringen gjordes med hjälp av tester på vissa utvalda processer och rimligheten i resultaten diskuterades. För en utförligare beskrivning av resultatet av denna fas se kapitel 7. Rapporten skrevs även under denna fas. 4 ITOMAT Som nämnts i kapitel 1 så är en av de största nackdelarna med Cobit att mycket kunskap om ramverket krävs för att kunna använda det som ett stöd- eller utvärderingsverktyg för IT-styrning. Då mognadsmodellen i Cobit lämnar utrymme för tolkningar är det heller inget som garanterar validiteten i utvärderingen, att utredare A kommer fram till samma sak som utredare B. Med detta som bakgrund har doktorand Mårten Simonsson vid ICS framtagit ramverket för metoden IT-Organization Model Assessment Tool (ITOMAT). Målet med ITOMAT är att formalisera en utvärderingsmetod och göra den så rättfram som möjligt för att öka validiteten och förenkla användningen av den kunskap som finns i Cobit. Som nämnts tidigare så är ITOMAT är en utvärderingsmetod i tre steg; skapandet av en referensmodell, skapandet av en instansmodell, och utvärdering av instansmodellen genom jämförelse mot referensmodellen. Referensmodellen baseras på ramverket Cobit och representerar en ideal IT-styrningsstruktur. Instansmodellen baseras på datainsamling om den nuvarande IT-styrningen på företaget under utvärdering. De två modellerna skapas och sammankopplas i modelleringsverktyget Metis. Instansmodellen utvärderas sedan i jämförelse med referensmodellen med kriterier baserade på en tolkning av Cobits mognadsmodell. Då kravet på utvärderingen är att den bygger på en formaliserad metod har försök gjorts att basera utvärderingen på kvantitativt mätbara egenskaper. Utifrån studier av Cobits mognadsmodell har fyra utvärderingsområden med mätbara egenskaper, identifierats. Dessa fyra områden är Aktivitetsutförande, Ansvarsfördelning, Dokumentation, Utförda mätningar. I kommande underkapitel presenteras utförligare vad modellerna innehåller, hur de är skapade och hur utvärderingen är utförd. 4.1 Metamodeller i Metis Idag finns det flera modelleringsverktyg ute på marknaden, varav de mest omtalade är System Architecture som idag ägs av Telelogic[17] och verktyget Metis som ägs av Troux Technologies[18]. Metis är det verktyg som används för verksamhetsmodellering på ICS och har därför varit utvecklingsmiljön i detta examensarbete. Utveckling av användarspecifik funktionalitet i Metis sker genom ett Application Programming Interface (API) som stödjer Visual Basic- och JavaScript. För detaljer kring hur implementationen av ITOMAT är utförd i Metis se kapitel 5. I Metis kan utvecklare skapa egna metamodeller, det vill säga de definitioner, regler och restriktioner av de objekt- och relationstyper som ska modelleras. Metamodeller är definitioner av modellens referensram, de styr vad man kan modellera och så vilket fokus modellen får. Modellen förhåller sig till metamodellen som ett program förhåller sig till grammatiken av det programmeringsspråk det är skrivet i. Vilken referensram som används i metamodellen är naturligtvis beroende av vad analysen har för motiv och mål. Varje instans som modelleras av en specifik objekttyp tilldelas samma uppsättning attribut och utseende. Objekttypen Person, exempelvis, kan definieras till att innehålla attributen namn, anställningsnummer, kontaktuppgifter eller andra egenskaper som anses viktiga i sammanhanget. Varje enskild instans av objekttypen Person kommer så definieras som objekt med de presenterade attributen, alla instanser har olika namn men alla har ett namn. Namnet sätts vid instansieringen av objekten. 19

17 4.2 Metamodell baserad på Cobit Genom att skapa en metamodell baserad på ramverket Cobit ges ett sätt att modellera de aspekter av ett företag som omfattas av IT-styrning. I identifieringen och skapandet av metamodellens komponenter har Cobits struktur, presenterad i kapitel 2.2, följts. Cobit möjliggör enkel identifiering av fem objekt och tillhörande relationer till metamodellen. De fem identifierade objekten motsvarar underkapitlen i kapitel 2.2 och är process, aktivitet, KPI/KGI, roller samt dokument. I figur 7 presenteras komponenterna i den metamodell som används i ITOMAT. I kommande underkapitel beskrivs objekten och relationerna i metamodellen och deras tillhörande attribut. Inom parentes efter attributens namn står de värden attributet kan anta. Figur 7 Komponenterna i metamodellen för IT-styrning. Företag (objekt) Objektet företag är inte hämtat ur Cobit utan är ett objekt som är tillagt metamodellen för att tydliggöra och förenkla modelleringen och utvärderingen. Då ett heltäckande mått för företagets ITstyrning önskas nås aggregerat från de 34 processer som Cobit beskriver som basen för IT-styrning så kopplas alla processer till företaget. Objektet företag representerar så den abstrakta entiteten för ITstyrning i ATD strukturen beskriven i kapitel 2.3. Till objektet Företag kopplas de 34 objekt som representerar processerna. Attribut: Namn Process (objekt) Som beskrivet i kapitel 2.2 är begreppet process vedertaget i beskrivandet av en IT - organisation och är grundentiteten i Cobit. Processen är det objekt som håller samman alla de aktiviteter, all den dokumentation och alla de mätningar som utförs inom processen. Dessa objekt kommer så ha en relation till processen de är beskrivna under i Cobit. Objektet process översattes direkt från Cobit och namnen på processerna i metamodellen är desamma som beskrivna i ramverket. Attribut: Namn 20

18 Aktivitet (objekt) Aktiviteterna representerar det som faktiskt utförs inom varje process i IT-organisationen och är beskrivna under varje process de tillhör i Cobit. Objektet Aktivitet representerar de aktiviteter som Cobit presenterar för varje process. Objektet Aktivitet kopplas till respektive processobjekt som aktiviteten definieras under i Cobit. För att kunna representera i modellen hur väl en aktivitet utförs så skapades ett attribut tillhörande objektet aktivitet kallad Aktivitetsutförande. I tidigare studier av Cobits mognadsmodell av doktorand Mårten Simonsson [15] konkluderades det att varje aktivitet kan representeras av a) huruvida ledningen är medveten om vikten av de frågor som är relaterade till aktiviteten, b) om övervakning av aktiviteten sker, c) om aktiviteten och dess ingångs och utgångsdata är dokumenterade, och d) om förbättringar av aktiviteten sker på en kontinuerlig basis.[15] Dessa fyra kännetecken kombinerades till attributet Aktivitetsutförande. Se kapitel 4.5 som närmare beskriver utvärderingen av instansmodellen för mer utförlig beskrivning av begreppet aktivitetsutförande. Attribut: Namn, Aktivitetsutförande (Never; Reactively, as needed; Project by project; Defined by policy; Standard practice; Optimized & Benchmarked) Roll (objekt) De roller som listas i Cobit och som presenterades i kapitel 2.2 representeras av objektet Roll i metamodellen. De befintliga rollbeteckningarna representerade i Cobit bestäms för varje instans ur en lista kopplad till rollobjektets attribut Rolltyp. Varje objekt Roll i Cobit kopplas till den eller de aktivitetsobjekt som den har ansvar eller auktoritet för och/eller rådgör eller informeras om. Attribut: Namn, Rolltyp (Som listade i Cobit, se kapitel 2.2) Key Performance Indicators (KPI) / Key Goal Indicators (KGI) (objekt) Cobit listar, som tidigare nämnts, ett stort antal mätningar som bör utföras för att övervaka framskridandet av varje process. Dessa mätningar representeras som objektet KPI/KGI i metamodellen och är kopplade till den process mätningen tillhör. De är direkt översatta från Cobit och har samma namn som i ramverket. Attribut: Namn Dokument (objekt) Det framläggs frekvent i Cobit att dokumentation är av vikt för att fastställa att processen utförs korrekt varje gång. Objektet Dokument i metamodellen har skapats på grundval av de ingångs och utgångsdata som finns specificerat till varje process som beskrivet i kapitel 2.2. Varje dokument modelleras endast en gång, då det antas att dokumentnamnen är unika, men det kan vara kopplat till flera olika processer. Attribut: Namn (Som listade i Cobit som input/output för alla processer) Relationer De fem olika komponenterna, eller objekten, presenterade ovan är kopplade till varandra med relationer i Metis. Tillåtna kopplingar och namn på relationerna definieras i skapandet av metamodellen. RACI-matrisen (se kapitel 2.2) beskriver vilken roll som bör vara associerad med vilken aktivitet, antingen som Accountable, Responsible, Counsulted eller Informed. Dessa relationer finns direkt implementerade i metamodellen som relationsobjekt och kan kopplas mellan objektet Aktivitet och objektet Roll. För att kunna representera skillnaden i ingångs- och utgångsdokument till processen så krävs relationer som betecknar dem. Inputs och Outputs är relationsobjekt i metamodellen som kan kopplas mellan objektet Dokument och objektet Process. Ett dokument i modellen kan så vara utgångsdata från en process och ingångsdata till en annan. Kopplingen mellan aktiviteter och den process de tillhör beskrivs i metamodellen med relationen Is part of, är en del av. Varje aktivitet är så en del av någon process. De mätningar i Cobit av utförandet av en aktivitet eller process, benämns KPI/KPG i metamodellen och har relationen measures, mäter, till processobjektet som 21

19 representerar den process de presenteras inom i Cobit. I figur 8 presenteras de objekt och relationerna de kan anta. Ursprungsobjekt Relation Målobjekt Företag Is part of Process Process Is part of Aktivitet Process Measures KPI/KGI Process Input Dokument Process Output Dokument Aktivitet Accountable Roll Aktivitet Responsible Roll Aktivitet Consulted Roll Aktivitet Informed Roll Figur 8 Relationer som finns representerade i metamodellen 4.3 Referensmodell Med byggstenarna definierade kan referensmodellen, moment 1 i ITOMAT, skapas. Referensmodellen är, som tidigare nämnt, en ideal modell och alla de entiteter Cobit definierar ska modelleras. Referensmodellen fungerar så som ett facit över hur det ser ut i en perfekt anpassad ITorganisation. Referensmodellen innehåller alla de 34 processer Cobit presenterar och för att på ett strukturerat sätt hitta mätdata har referensmodellen en struktur av ett ATD, där de mätbara delarna representeras av löven. I denna studies implementation av ITOMAT representeras även resultatet av utvärderingen i referensmodellen på så sätt att objekten i referensmetamodellen innehåller även egenskaper för att representera mognadsnivåer. I figur 9 visas två av de 34 processerna, PO4 och PO5, modellerade i sitt ideala utförande enligt Cobit, med de aktiviteterna, mätvärden och de dokument som finns representerade som ingångs- och utgångsdata. De två processerna kopplas via relationen aggregate till objektet Företag, för att få ett mått på de aggregerade processernas mognad. 22

20 Process Dokument Utförda mätningar Aktivitet Figur 9 Referensmodell som representerar två av de 34 processerna i Cobit 4.4 Instansmodell När referensmodellen är modellerad är nästa moment i ITOMAT att modellera instansmodellen som visualiserar ett företags existerande, eller hypotetiska, IT-styrning. Instansmodellens utformning och objektattributens innehåll är resultatet av datainsamling på företaget under utvärdering. För att skapa en instansmodell krävs så först att data om företagets IT-styrning finns tillgängligt. Detta innefattar data om alla de entiteter som Cobit beskriver, det vill säga de 34 processerna identifierade i Cobit med respektive aktiviteter, dokument och utförda mätningar samt aktiviteternas ansvarsfördelning och utförande. Med all data om företagets IT-styrning tillgänglig kan en instansmodell över företagets ITorganisation skapas. Om en aktivitet, exempelvis, bedömdes utföras på företaget med den beskrivande termen Reactively, as needed så representeras detta i instansmodellen genom att modellera den aktuella aktiviteten med attributet Aktivitetsutförande bestämt till Reactively, as needed. Datainsamlingen gjordes i denna studie i form av intervjuer, för vidare information om denna se kapitel 6, Fallstudie. Observera att med referensmodellen skapad kan den användas till att utvärdera obegränsat antal instansmodeller då det är instansmodellen som representerar företaget som ska utvärderas. Referensmodellen är en ritning över Cobit, ett facit för effektiv IT-styrning. En instansmodell är en ritning över ett företags nuvarande IT-styrning. Till varje modellerad aktivitet, dokument och utförd mätning kopplas även ett mått på insamlade datas trovärdighet i form av ett objektattribut benämnt Existens. Detta attribut togs inte upp i diskussion om metamodellen (kapitel 4.2) då detta attribut endast berör instansmodellen. Alla objekt i instansmodellen innehar detta attribut. Se kapitel 5.3 för kriterier som påverkar trovärdighet hos den insamlade informationen. Det som faktiskt mäts och modelleras har tilldelats en trovärdighet i modellen för att kritiskt kunna granska datainsamlingens validitet. Då huvudsaklig fokus i detta examensarbete var att praktiskt implementera metoden ITOMAT har mindre vikt lagts på insamlingen av data. Inom ramen för denna studie har, av prioriteringsskäl, ansvarsfördelningen givits ett generellt trovärdighetsvärde för alla aktiviteter. Se vidare beskrivning i nästa kapitel. Trovärdigheten tas i beaktning vid representationen av mognadsresultatet i form av en sannolikhetsmassa som fördelas över de olika nivåerna. Den största delen av sannolikhetsmassan placeras på den mognadsgrad som är troligast och resten delas ut på de övriga nivåerna. Se vidare under sektion 4.5 som behandlar implementationen av de olika utvärderingsområdena för en närmare beskrivning av sannolikhetsfördelningen i dagsläget. Påpekas bör även att, inom ramen för detta examensarbete, så modelleras komponenterna i instansmodellen endast om de kan bedömas existera med sannolikhet större än 0 på företaget. Instansmodellen är en representation av vad som faktiskt finns och utförs på företaget. Denna representation har valts för att öka tydligheten i visualiseringen av företagets nuvarande IT-organisation. I figur 10 visas ett exempel på en process i instansmodell. 23

21 Figur 10 Exempel på modell baserad på Cobit-metamodellen. Det mörkblå objektet i mitten representerar processen och under den de två ljusblåa objekt som representerar de aktiviteter som utförs inom processen. Objekten längst ner i figuren representerar de roller som är ansvariga för respektive rådfrågade om aktiviteterna. Objektet ovanför processen är den mätning som utförs för att mäta prestationer i processen. Till vänster om processen visas det dokument som inkommer till processen och till höger de dokument som produceras i processen. 4.5 Utvärdering Med referensmodellen klar och företaget modellerat i instansmodellen är det moment 3 av ITOMAT kvar att utreda; utvärderingen. Som tidigare nämnts så är det instansmodellen som utvärderas, referensmodellen fungerar som ett jämförande facit. Kriterierna för utvärderingen är baserade på tidigare forskning av Cobits mognadsmodell utförd av doktorand Mårten Simonsson[15]. Ramverket Cobit presenterar, som tidigare nämnts, en mognadsmodell för varje process med beskrivande kriterier per nivå. För att undvika subjektivitet i mognadsbedömningen så skapades inom ramen för ITOMAT en formaliserad procedur där separata mätvärden aggregerats till en total mognad för varje aktivitet eller process, eller för hela företaget. Mognadsmodellen i ITOMAT utgår ifrån fyra områdena: Aktivitetsutförande, Ansvarsfördelning, Dokumentation och Utförda mätningar. Mognaden för utförandefrekvens och ansvarstagande mäts på aktivitetsnivå medan dokumentation och mätvärden har mognad på processnivå. Se figur 11 för en bild över var de olika utvärderingarna görs i modellen. I kommande underkapitel presenteras de fyra utvärderingsområdena närmare. Mognadsgraderna i ITOMAT är de samma som i Cobit, det vill säga från 0 till 5 i stigande ordning. Som nämnts ovan så tas trovärdigheten i beaktning vid representationen av mognadsresultatet i form av en sannolikhetsmassa som fördelas över de olika nivåerna. Den största sannolikhetsmassan kommer så att placeras på den mognadsgrad som är troligast och resten delas ut på de övriga nivåerna. För att representera den resterande sannolikhetsmassan, om trovärdigheten för den insamlade informationen inte var 100 %, har en sannolikhetsnivå, utöver mognadsnivåerna, kallad Okänd även definierats. Exakt hur sannolikhetsmassan fördelas är i nuläget olika för de fyra ovan nämnda bedömningsområdena och presenteras i detalj i underkapitlen nedan. Fokus i detta examensarbete har varit på att utveckla metoden för mognadsbedömning och implementera stödet för detta i Metis, det vill säga framtagandet av ett formaliserat och automatiserat metodförfarande. De mätningar som görs i denna utvärdering är ett initialt försök att nå en utvärdering, den optimala utformningen av utvärderingskriterierna är föremål för vidare forskning. Se vidare diskussion kring detta i kapitel

22 Figur 11 - Schematisk bild över de fyra utvärderingsområdena i ITOMAT. Aktivitetsutförande (Execution i bilden) och Ansvarsfördelning (Responsibility) utförs på aktivitetsnivå. Dokumentation och Utförda mätningar (KPI/KGI) utförs på processnivå. Resultatet för varje nivå är aggregerat uppåt i strukturen men kan även avläsas för varje nivå i modellen. Aktivitetsutförande Inom varje process i Cobit beskrivs ett antal aktiviteter som ska utföras, men väldigt lite stöd ges för hur en process eller aktivitet ska mognadsbedömas. Genom doktorand Mårten Simonssons tidigare studier av mognadsmodellen i Cobit[15] och generalisering därav till separata aktiviteter så extraherades slutsatser för utförandekriterier för varje mognadsnivå. Generellt bedöms utförandet av aktiviteten ha högre mognad ju oftare och mer strukturerat aktiviteten utförs. I tabell X nedan presenteras de kriterier som hör till varje mognadsnivå. Observera att mognadsgraden för aktivitetsutförande motsvarar det värde som sätts på aktivitetsobjektets attribut Aktivitetsutförande vid modellering av den insamlade datan om aktiviteten på företaget. Sannolikhetsmassan för aktivitetens mognadsnivåer kommer så att centreras kring den mognadsnivå som representerar det värde aktivitetens attribut Aktivitetsutförande motsvarar och resten delas ut till de övriga nivåerna. För utförligare beskrivning av hur implementationen är utförd se kapitel 5. Exempelvis så om trovärdigheten av informationen rörande en viss aktivitet är bedömd till 78 % och utförandet av aktiviteten på företaget bedömt till Reactively, as needed, så kommer så 78 % av sannolikhetsmassan för den aktuella aktiviteten att hamna på mognadsnivå 1 enligt figur 12. Mognadsnivå Mognadskriterier för Aktivitetsutförande Kriterier 0 1 Never No awareness of the importance of issues related to the process No monitoring is performed No documentation exists No process improvement activities take place Reactively, as needed Some awareness of the importance of issues related to the process 25

23 No monitoring is performed No documentation exists No process improvement activities take place 2 3 Project by project Individuals have knowledge about issues related to the process and take actions accordingly No monitoring is performed No documentation exists No process improvement activities take place Defined by policy Affected personnel are trained in the means and goals of the process No monitoring is performed Documentation is present No process improvement activities take place 4 Standard practice Affected personnel are trained in the means and goals of the process Monitoring is performed Documentation is present The process is under constant improvement. Automated tools are employed in a limited and fragmented way 5 Optimized & Benchmarked Affected personnel are trained in the means and goals of the process Monitoring is performed Documentation is present Automated tools are employed in an integrated way, to improve quality and effectiveness of the process Figur 12 - Mognadsnivåerna för Ansvarsfördelningen för aktiviteter i ITOMAT. Ansvarsfördelning Likt mognaden för aktivitetens utförande så ger Cobit heller inget riktigt stöd för bedömningen av mognadsgrader gällande de ansvarsfördelningar som RACI-matrisen specificerar. Matrisen innehåller mycket information, men inom ramen för detta examensarbete valdes en enkel form av analys av dess innehåll. Det finns i denna studie två kriterier nyttjade i bedömningen av ansvarsfördelningens mognad för en aktivitet i ITOMAT: 1. Finns det åtminstone en roll Accountable (A) för aktiviteten? [sann/falsk] 2. Finns det åtminstone en roll Responsible (R) för aktiviteten? [sann/falsk] Det ansågs viktigast att någon bedömdes ansvarig än att just den rollen som Cobit definierar är ansvarig. Existensen av relationerna R och A tilldelas en trovärdighet som indikerar säkerheten i deras samexistens. Om trovärdigheten är lika med 0 innebär det en total osäkerhet i huruvida R och A- relationer är tilldelade till roller som RACI-matrisen förespråkar. Om trovärdigheten är lika med 100, betyder det att det är helt säkert att R och A är tilldelade. Hur mognadsnivåerna för ansvarsfördelningen utvärderas presenteras i figur 13. Variabeln notr tilldelas 0 och R tilldelas 1 om en relationen Responsible finnes kopplad mellan ett rollobjekt och aktivitetsobjektet. På respektive sätt tilldelas variblerna som motsvarar Accountable. Vairanbeln C representerar ett generellt trovärdighetsmått för förekomsten av relationerna i modellen. I denna studie sattes C till 70 % efter 26

24 en bedömning av rollerna och ansvarsfördelningen på Umeå Energi. Det finns således fyra olika tillstånd för ansvarsfördelningen; 1) Varken A eller R finns, 2) A finns men inte R, 3) R finns men inte A, 4) A finns och R finns. Dessa fyra tillstånd har sedan fördelats på de de sex mognadsnivåerna. Mognadsnivå 0 och 1 tilldelas hälften var av sannolikhetsmassan (i detta fall 70 % av den totala, resten tilldelas okänd ) ifall det första tillståndet råder, varken R eller A finns tilldelad. Detta representeras av sannolikhetsmassans fördelning i figur 14. Om R eller A finns kommer sannolikhetsmassan att fördelas över nivåerna 2, 3, 4 och 5 enligt figur 15. Om R och A finns tilldelade aktiviteten kommer sannolikhetsmassan fördelas över mognadsnivåerna 4 och 5 enligt figur 16. Mognadsnivå Mognadskriterier för Ansvarsfördelning Värde 0 Om inte R och inte A: C/2 Om R eller A: 0 1 Om inte R och inte A : C/2 Om R eller A: 0 2 Om R eller A : C/4 Om inte R och inte A : 0 3 Om R eller A : C/4 Om inte R och inte A : 0 4 Om R eller A: C/4 Om R och A: C/2 Om inte R och inte A : 0 5 Om R eller A: C/4 Om R och A: C/2 Om inte R och inte A : 0 1 C Okänd Figur 13 - Mognadsnivåerna för Ansv arsfördelningen. 27

25 Probability distribution for RACI-relations per maturity level, R=0, A=0, C=0.7 1 Probability 0,8 0,6 0,4 0,2 0 nknown Figur 14 - Sannolikhetsmassans fördelning för R=0, A=0, C= Probability distribution for RACI-relations per maturity level, R=1, A=0, C=0.7 1 Probability 0,8 0,6 0,4 0,2 0 nknown Figur 15 Sannolikhetsmassans fördelning för R=1, A=0, C= Probability distribution for RACI-relations per maturity level, R=1, A=1, C=0.7 1 Probability 0,8 0,6 0,4 0,2 0 nknown Figur 16 Sannolikhetsmassans fördelning för R=1, A=1, C= Dokumentation De två ovan nämnda områdena utgör en aktivitets bedömda totala mognad. Fördelningen av sannolikhetsmassan över mognadsnivåerna för Aktivitetsutförande och Ansvarsfördelning aggregeras till en mognadsfördelning för den aktiviteten. Mognadsfördelningen på processnivå bestäms av den aggregerade mognaden för alla aktiviteter som tillhör processen, samt mognaden för Dokumentation av processen och mognaden för Utförda mätvärdena kopplade till processen. Bedömningen av mognadsgraden gällande dokument och mätvärden baseras på existensnivåer. Dokument kopplade till 28

26 processen i instansmodellen jämförs med antalet givna i referensmodellen. Det tas så inte i beaktning om ett dokument är ingångs- eller utgångsdata till processen. Det som mäts är antalet dokument kopplade till en viss process i instansmodellen jämfört med hur många som finns kopplade till just den processen representerad i referensmodellen. Trovärdigheten kopplad till de modellerade dokumenten tas i beaktning, och trovärdigheten för varje antal möjliga objekt räknas ut. Om det exempelvis finns tre dokument i instansmodellen så beräknas sannolikhet som motsvarar att det bara finns ett objekt, samt två och tre. Sannolikhetsmassa delas så ut mellan de olika möjliga mognadsnivåerna som respektive antal representerar. Om det, till exempel, finns tre dokument i instansmodellen och det finns tio dokument kopplade till samma process i referensmodellen så motsvarar tre dokument 30 procent av idealet. Den sannolikhet som motsvarar att det finns tre dokument kommer så att placeras på mognadsnivå 2 enligt figur 17, vilken presenterar mognadskriterierna för dokumentation. Eftersom all sannolikhetsmassa delas ut kommer inget att hamna på nivån Okänd. Om inga dokument finns kopplade till processen i instansmodellen så kommer all sannolikhetsmassa att finnas på mognad 0. Mognadsnivå Mognadskriterier för Dokumentation Dokument på plats (som listade i Inputs/Outputs) 0 0 % 1 < 20 % 2 < 40 % 3 < 60 % 4 < 90 % % Figur 17 Mognadskriterier för Dokumentation Utförda mätningar Mognaden för Utförda mätningar i processen mäts på samma sätt som Dokumentation, baserat på existensnivåer. Sannolikhetsfördelningen över mognadsnivåerna på processnivå är som ovan nämnt baserad på fördelningen för aggregatet av alla processens aktiviteter, fördelningen för dokumentationen, samt fördelningen för Utförda mätningar. I figur 18 nedan presenteras så mognadskriterierna för utvärderingsområdet Utförda mätvärden. Mognadskriterier för Utförda mätningar Mognadsnivå Antalet mätningar som utförs jämfört med antalet i referensmodellen. 0 0 % 29

27 1 < 20 % 2 < 40 % 3 < 60 % 4 < 90 % % Figur 18 - Mognadskriterier för Utförda mätningar Utvärderingsobjekt I denna implementation av ITOMAT så utförs alla utvärderingar i modellen av olika utvärderingsobjekt kopplad till alla aktiviteter och processer som ska bedömas. Vidare har ett objekt som underlättar och tydliggör aggregeringen av alla aktiviteter som processen innehåller skapats. Dessa objekt med respektive metod och beräkningar beskrivs närmare i kapitel 5. I figur 19 presenteras ett exempel över hur utvärderingsobjekten är kopplade till de respektive objekten i referensmodellen. Då det är två utvärderingar som görs på aktivitetsnivå är så två utvärderingsobjekt kopplade till varje aktivitet. Ett som utvärderar aktivitetens utförande och ett som utvärderar aktivitetens ansvarsfördelning. Resultatet från aktiviteterna, representeras som aggregerad sannolikhetsfördelning i objektet kallat Aktiviteternas Mognad. Vidare utförs två utvärderingar processnivå, utvärdering av processens dokumentation samt utförda mätningar. Två utvärderingsobjekt kopplade till processobjektet ger ett resultat som aggregerats ihop med aktivheternas mognad till en sannolikhetsfördelning över mognadsnivåerna för processen. I nästa kapitel beskrivs hur implementation av beräkningarna är utförd för de ovan beskrivna utvärderingsområden. 30

28 Figur 19 Referensmodell med utvärderingsobjekt för processerna PO4 och PO5 i Cobit 5 Implementation Detta kapitel presenterar hur implementationen av utvärderingen i ITOMAT utförts. Som beskrevs ovan så kopplas i denna implementation utvärderingsobjekt till varje objekt i referensmodellen för att sedan jämföra referensmodellens objekt med respektive objekt i instansmodellen. Exempelvis så är utvärderingsobjektet Aktivitetsutförande kopplat till aktiviteten Identifiera och kategorisera tredjeparts service och relationer i referensmodellen. Metoden tillhörande objektet Aktivitetsutförande söker i instansmodellen efter samma aktivitet som den är kopplad till i referensmodellen. Om aktiviteten finns modellerad, det vill säga om Identifiera och kategorisera tredjeparts service och relationer utförs på företaget, så hämtar utvärderingsobjektet information från aktiviteten i instansmodellen, utför beräkningar baserad på informationen och levererar sedan ett resultat i form av sannolikheten av de olika mognadsvärdena till aktiviteten i referensmodellen. Om aktiviteten inte finns i instansmodellen sätts mognaden till noll för den aktiviteten. Utvärderingsobjekten är visualisering och hållare av data. Beräkningen i utvärderingen utförs av metodscript kopplade till utvärderingsobjektet. Totalt har sex metoder kopplats till utvärderingsobjekt, en metod för de fyra utvärderingsområdna, en metod som handhar aggregeringen av mognadsdata i referensmodellen samt en metod som initierar utvärderingen. Initieringen görs från det översta objektet i ATD-strukturen, objektet Företag. Nedan presenteras metoderna i detalj med redogörelse för hur mognad implementerades i de respektive områdena. 31

29 5.1 Aktivitetsutförande Objektet Aktivitetsutförande är kopplad till alla aktivitetsobjekt i referensmodellen. Dess metod kontrollerar hur väl en aktivitet utförs och med vilken sannolikhet. Informationen om hur väl aktiviteten utförs är bedömt vid datainsamlingen och sätts vid modelleringen av instansmodellen till attributet Aktivitetsutförande i objektet Aktivitet som beskrivet i kapitel 4.4. Metoden som tillhör utvärderingsobjektet översätter attributets värde till mognadsnivåerna enligt nedan: Select Case Case "Never" executionproperty= 0 Case "Reactively, as needed" executionproperty= 1 Case "Project by project" executionproperty= 2 Case "Defined by policy" executionproperty= 3 Case "Standard practice" executionproperty= 4 Case "Optimized & benchmarked" executionproperty= 5 Case Else MsgBox "Something s wrong" End Select Sannolikhetsmassan kommer så centreras kring den mognad som motsvaras av utförandefrekvensen. Om en aktivitet utförs Project by project och har sannolikheten 70 % så kommer således 70 % av sannolikhetsmassan att hamna på mognad 3. Resten av sannolikhetsmassan normalfördelas kring mognad 3 med hjälp av en integrerande normalfördelningsfunktion i metoden. Då normalfördelningsfunktionen är kontinuerlig kommer vid låg sannolikhet för aktiviteten viss del av funktionen att hamna utanför mognadsintervallet och fördelas så till attributet Okänd. Om metoden finner att ingen aktivitet finns modellerad i instansmodellen innebär det som diskuterat i kapitel 4.4 och ovan att aktiviteten inte utförs, det vill säga att den utförs med sannolikhet 0. I detta fall har mognaden satts till 0 med hela sannolikhetsmassan, det vill säga 1, för aktiviteten. 5.2 Ansvarsfördelning Objekten för Ansvarsfördelning, som hyser denna metod, är även de kopplade till objekten Aktivitet i referensmodellen då det är aktiviteternas ansvarsfördelning som utvärderas. För varje aktivitet som utvärderingsobjektet är kopplat till i referensmodellen, det vill säga alla aktiviteter som Cobit omfattar, så kontrolleras existensen av motsvarande aktivitet och dess relationer i instansmodellen. Som beskrivet i kapitel 4.5 om utvärderingen av ansvarsfördelning, så kontrollerar denna utvärdering huruvida relationerna ansvarig (R) eller auktoritet (A) finns kopplade till varje aktivitet. Som nämnts så sätts i denna implementering en trovärdighet för alla relationer i instansmodellen till samma trovärdighetsvärde. I denna studie sattes denna övergripande sannolikhet för relationerna till 70 %. Hur implementationen av fördelningen av sannolikhetsmassan över mognadsnivåerna per de aktiviteter som modellerats i indtansmodellen beskrivs med pseudokod nedan: Sätt variabeln C till 0.7 För varje aktivitet i instansmodellen Kontrollera om relationen A finns (samma kontroll görs för relationen R) I så fall Sätt variabeln nota till 0 och variabeln A till 1 Om inte Sätt variabeln nota till 1 och variabeln A till 0 32

30 Sätt mognadsnivå 0 och 1 till notr*nota*c/2 Sätt mognadsnivå 2 och 3 till notr*nota*c/2 Sätt mognadsnivå 4 och 5 till (R*notA+notR*A)*C/4+R*A*C/2 Sätt Okänd till notr*nota*(1-c) + (R*notA+notR*A)*(1-C) +R*A*(1-C) 5.3 Dokumentation och Utförda mätningar Mognadsgraden för dokumentationen och utförda mätningar bedöms båda i förhållande till hur stor andel av de objekt som är kopplade till en viss process i referensmodellen som återfinns i instansmodellen. Då de båda beräknas på samma sätt beskrivs nedan förfarandet vid utvärderingen av Dokumentation. Vid funnet antal dokument kopplade till den aktuella processen i instansmodellen krävs att det modellerade dokumentets trovärdighetsmått tas i beaktning. För att kunna representera den totala sannolikhetsmassans fördelning så sökes sannolikheten för att varje möjligt antal dokument existerar. Detta innebär uträkning av sannolikheten för att inget dokument finns, att ett dokument finns, och så vidare till totalt antal funna dokument i instansmodellen. Nedan beskrivs förfarandet i beräkningarna med pseudokod: För varje process i referensmodellen Finn antalet dokument som är kopplade till processen i referensmodellen Hitta den process i instansmodellen som är av samma typ som utvärderingen exekveras från Sätt N = antalet dokument som är kopplade till processen i instansmodellen Om N > 0 (Finn sannolikheten att inget dokument finns) Multiplicera (1 trovärdigheten) för alla N dokument (Finn sannolikheten för varje antal 1 N-1 dokument) Från K = 1 till N - 1 Hitta alla möjliga kombinationer (N,K) (Se Appendix för fullständig kod för denna funktion) För varje möjlig kombination av K Multiplicera sannolikheten av kombinationen med sannolikheten att resten av dokumenten inte finns Addera alla sannolikhetskombinationer per K (Finn sannolikheten att alla dokument finns) Multiplicera trovärdigheten för alla N dokument För C=0 till N Finn ration C/antalet dokument kopplade till processen i referensmodellen Placera sannolikhetsmassan för C uträknad ovan på korresponderande mognadsnivå, i.e. Om ration = 0.1 placera sannolikhetsmassan på mognad 1 och så vidare i enlighet med kriterierna för mognadsnivåerna givna i kapitel

31 5.4 Aggregering Aggregeringen av mognadsdata sker på tre olika nivåer, aktivitets, process och företagsnivå. Mognadsfördelningen för alla aktiviteter inom en process aggregerat till det intermediära objektet Aktiviteternas Mognad, som beskrivet i kapitel 4.5, figur 20 nedan är en schematisk bild över aggregeringen. Resultatet från aktiviteterna aggreggeras tillsammans med resultatet från dokumentationen och de utfördamätningarna till varje process. Företagets resultat är sedan ett aggregerat resultat för alla de 34 processerna. Som diskuterats i kapitel 2.4 så sker aggregeringen med Dempster-Shafer matematik och viktning är så tillåtenerror! Reference source not found.[20]. I denna studie har dock ingen viktning av aggregaten gjorts. Figur 20 Schematisk bild över de olika aggregeringsnivåerna i ITOMAT 6 Fallstudie För att praktiskt testa utvärderingsmetoden ITOMAT så utfördes en mindre fallstudie på Umeå Energi. Datainsamlingen skedde genom intervjuer med de anställda på Umeå Energis IT-avdelning i juni Umeå Energi Umeå Energi är ett energi- och kommunikationsföretag verksamt i och helägt av Umeå kommun. Företaget producerar, distribuerar och säljer energi till ca privat- och företagskunder. Umeå Energi äger även Umeås fiberoptikiska bredbandsnät. Totalt har koncernen 270 medarbetare varav sex personer arbetar på IT-avdelningen. Umeå Energi har en årlig omsättning på cirka en miljard kronor. 6.2 Respondenter IT-avdelningen på Umeå energi består av sex medarbetare och fem av dessa medverkade i studien. Respondenterna fick svara på frågor om de processer och aktiviteter som de kunde anses vara ansvariga för. Denna bedömning gjordes efter diskussion med avdelningschefen om de kunskaps 34

32 och ansvarsområden de anställda ansågs ha. Ingen respondent namnges i denna rapport. Vissa processer fick flera respondenter svara kring, detta berodde på att de alla var involverade i processen eller att den självbedömda trovärdigheten var låg. 6.3 Intervjumetodik Följande sektion ger en översikt över intervjuförfarandet i datainsamlingen. Varje intervju innehöll ungefär 3-4 processer och tog drygt 1 timme att genomföra. Vissa respondenter medverkade i flera intervjuer. Sammanlagt tog intervjuerna cirka 15 timmar. Varje intervju gjordes i enrum med respondenten. Alla intervjuer följer de 34 processbeskrivningarna i ramverket Cobit. Intervjuerna hade i regel följande disposition: 1. Förklarande av bakgrund och syfte En kort genomgång över vad Cobit innehåller gjordes och syftet med utvärderingen förklarades. Sedan presenterades överskådligt för respondenten vad de aktuella processerna innefattade. Vidare informerades respondenten om varför just han/hon var utvald att delta i intervjun och svara på frågor om utvalda processerna. Respondenten ombads även berätta om sitt arbete i organisationen samt göra en självbedömning av sin egen trovärdighet rörande varje process. 2. Genomgång av de olika komponenterna i processen Respondenten tilldelades en kopia av Cobit för att underlätta förståelsen för intervjuförfarandet. För att förbereda respondenterna på vilka frågor som skulle ställas så presenterades de komponenterna som ingår i processen. 3. Utvärdering av processen I denna del av intervjun fick respondenten svara på de frågor kring de aktuella processerna som ligger till grund för utvärderingen. Denna fas itererades för varje process som respondenten var utvald att svara på. Trovärdigheten bedömdes av intervjuaren i samband med svaret på de respektive frågorna. Det var naturligast att börja på aktivitetsnivå då aktiviteterna beskriver vad som faktiskt utförs inom varje process. Aktivitetsnivå Varje aktivitet listad i processens RACI-matris presenterades, en i taget, för respondenten. Respondenten tillfrågades om aktiviteten utfördes, och om så var fallet hur ofta samt vilka som var ansvariga, rådfrågade och informerade om varje aktivitet. Processnivå Vidare frågades om vilka dokument samt mätvärden som kunde anses vara kopplade till den aktuella processen. Den lista med dokument som under den aktuella processen presenteras som Inputs/Outputs gicks igenom och förfrågning om existens för dokumenten gjordes. På samma sätt listades de KPI/KGI som finns kopplade till den studerade processen. All information som samlades in under intervjuerna översattes sedan till en instansmodell över ITorganisationen på Umeå Energi. Modellen presenterades för chefen på IT-avdelningen för kommentarer kring dess korrekthet. 35

33 6.4 Trovärdighet I detta examensarbete utfördes mätningarna genom intervjuer och tre kriterier valdes att ligga till grund för trovärdigheten. Då detta examensarbetes fokus ligger kring att utveckla implementationen för utvärderingen har valet av trovärdighetskriterier inte prioriterats och tre kriterier har så fastställts i samarbete med handledarna. Nedan presenteras de tre kriterierna för trovärdighet som mättes i denna studie. Inom parantes finns de respektive värden kriterierna kan anta: A) Self assessed credibility (1-3) 1. Not certain at all 2. Quite certain 3. Perfectly certain B) Presentation (1-3) 1. Sloppy 2. Average 3. Detailed (e.g. document is shown) C) Age of answer (1-3) 1. A year ago 2. A month ago 3. Yesterday Det första kriteriet, Självbedömd trovärdighet, svarar intervjurespondenten för inför varje mätvärde som utvärderas. Kriteriet Presentation bestäms av intervjuaren beroende på hur respondenten presenterar sitt svar. Det tredje kriteriet tar hänsyn till hur länge sedan informationen om det aktuella mätvärdet kom respondenten till handa. Dessa tre kriterier definierar så sammanslagna trovärdigheten för det aktuella mätvärdet. Varje kriterium tilldelas en siffra enligt ovan och dessa siffror adderas och divideras med det högsta möjliga värdet. Se Appendix 1 för en tabell över de olika möjliga kombinationerna och deras respektive trovärdighetsmått. 7 Resultat av fallstudien Nedan presenteras resultatet av utvärderingen med ITOMAT på Umeå Energi. Resultatet representeras som sannolikhetsmassa fördelad över de sex olika mognadsnivåerna definierade i ITOMAT samt en pott som representerar ovissheten i svaret under posten Okänd. 7.1 IT-styrningsmognad hos Umeå Energi Resultatet av utvärderingen med ITOMAT är, som ovan nämnt, ett aggregerat värde av processerna och de påverkas i sin tur av det aggregerade värdet från aktiviteterna. Denna struktur tillåter nedbrytning av resultatet till aktivitets eller processnivå, vilket möjliggör att tendenser och områden i behov av förbättringar kan urskiljas. Först presenteras resultatet för Umeå Energis IT-styrning på företagsövergripande nivå, det vill säga de totala aggregerade mognadsfördelningen för alla de 34 processerna. För att nå en tydligare bild över tendenserna i resultatet presenteras sedan resultatet för tre av de 34 utvärderade processerna. De två första tillhör domänen Planering och Organisation i Cobit och benämns PO6 Kommunicera ledningens mål och riktning, PO9 Utvärdera och hantera IT-risker och den tredje tillhör domänen Leverera och Stödja, DS2 Hantera tredjepartsservice. 36

34 Resultatet i processen DS2 bryts sedan ner till aktivitetsnivå och resultatet för aktiviteten Identifiera och kategorisera tredjeparts servicerelationer presenteras. För resultaten för alla processer se Appendix 4-6. Figur 21- Resultatet presenteras på företags-, process- och aktivitetsnivå Företagsnivå I figur 22 presenteras det övergripande resultatet för utvärderingen av IT-styrning på Umeå Energi. Den största delen av sannolikhetsmassan ligger placerad på mognadsnivå 2, drygt 25 %. Cirka 15 % av massan är fördelad till nivå 0 och nästan lika mycket ligger på nivå 3 och även nivå 4Stapeln på mognad 0 härrör från aktiviteter och mätningar som inte utförs och dokument som inte finns. Detta indikerar att Umeå Energi når en relativt hög mognadsnivå för de aktiviteter och processer de faktiskt utför. Stapeln på posten Okänd har ett värde på 25 %, vilket innebär att 25 % av sannolikhetsmassan vet vi ingenting om. Ett annat sätt att representera resultatet, som kanske är mer pedagogiskt, är att använda begreppet utility, upplevd nytta. Figur 23 presenterar den upplevda nyttan av ITstyrningens mognad. Utility förklaras inte vidare i denna rapport, för den intresserade läsaren kan sägas att uträkningarna för utility utfördes enligt Yang, 2002, eq [20] Enterprise Figur 22 Resultatet för sannolikhetsfördelningen för mognadsnivåerna av IT-styrningen på Umeå Energi 37

35 5 Total Maturity Figur 23 - Den totala upplevda nyttan av IT-styrning på Umeå energi. PO6 Kommunicera ledningens mål och riktning Som nämndes tidigare kan resultatet på företagsövergripande nivå brytas ned i de 34 olika processer som utgör mätningarna i denna studie. I figur 23 presenteras resultaten för process PO6. Även denna process har dominans av sannolikhetsmassan på mognadsnivå 2, med drygt 70 % sannolikhet är mognaden för processen på denna nivå. Genom att studera instansmodellen finnes att alla aktiviteter inom processen utförs, och dessutom relativt väl, så denna siffra är inte förvånande. Två av aktivitetens processer har attributet Aktivitetsutförande bestämda till Defined by policy vilket bidrar till mognadsnivå centrerad runt 3 enligt mognadsbedömningen beskriven i kapitel 4.5. Processen innehåller även två av de fem dokument som Cobit specificerar vilket enligt kriterierna för mognadsnivåerna beskrivna i figur 12 bidrar till mognad 2. Osäkerhetsattributet Okänd är dessutom mycket lägre än för företaget som helhet. Detta indikerar att trovärdigheten hos de modellerade objekten i processen är mycket hög. Det låga antalet mätningar som utförs inom processen, enbart ett av nio, representeras av stapeln på mognad PO6 38

36 Figur 24 - Resultat för PO6 Kommunicera företagets mål och riktning PO9 Utvärdera och hantera IT-risker Resultatet av utvärderingen visar att Umeå Energi har hög mognad i sitt handhavande av risker, vilket indikeras av en koncentrerad sannolikhetsmassa på mognad 3 enligt figur 24 nedan. Process PO9 har generellt lägre trovärdighet än förra processen vilket indikeras av den höga stapeln på Okänd. Att alla aktiviteter utförs, samt utförs mycket väl, de flesta med Standard Practice, vilket placerar mycket av sannolikhetsmassan för aktiviteternas utförande på en mognad kring 4. Alla aktiviteter har även åtminstone en ansvarig eller auktoritet kopplad till sig, vilket indikeras av fördelning av sannolikhetsmassa på nivåerna 2-5. Dock drar den bristande dokumentationen av processen ner mognaden något, sex av tretton dokument ger mognad kring 2. Stapeln på mognad noll kan representera den totala avsaknaden av mätvärden i processen PO9 Figur 25- Resultat för PO9 Utvärdera och hantera IT-risker DS2 Hantera tredjepartsservice Den höga stapeln på mognad 0 representerar den totala avsaknaden av dokumentation och utförda mätningar i processen som kan avläsas i modellen. Alla processens aktiviteter utförs dock och fem av sex av dessa med mognadsgrad Defined by Policy, vilket representerar de dryga 10 % av sannolikhetsmassan som återfinns på stapel 3. Att aktiviteterna även har en tydlig ansvarsfördelning med åtminstone en ansvarig eller auktoritet representeras av värdena på staplarna 2-5. Som beskrivet i kapitel 4.5 så aggregeras mognaden för dokumentation, mognaden för mätvärden tillsammans med mognaden för processens aktiviteter till processens mognad. Om två av tre aggregat påvisar mognad 0 kommer processen få stor sannolikhetsmassa på mognad 0. 39

37 DS2 Figur 26- Resultat för DS2 Hantera tredjepartsservice DS2 en aktivitet Figur 20 presenterar resultatet för en av de sex aktiviteter som tillhör processen Hantera tredjepartsservice, presenterad ovan. Aktivitetens mognad beror både av mognaden för Ansvarsfördelning för aktiviteten samt mognaden för dess utförande. Aktiviteten utförs med 78 % sannolikhet och har utförandegrad Defined by Policy, som indikerar mognadsgrad 3. Vidare finns det åtminstone en auktoritet kopplad till aktiviteten, vilket indikeras av värdena på staplarna 2-5. Activity DS2 Identify and categorise third-party service relationships Figur 27 - Resultat för aktiviteten DS2 Identifiera och kategorisera tredjeparts servicerelationer 8 Diskussion Detta examensarbete ingick i doktorand Mårten Simonssons forskning som första försök till att skapa en utvärderingsmetod baserad på Cobit. Målet var att implementera metoden, ITOMAT, i modelleringsverktyget Metis för automatiserad utvärdering. Vidare utfördes en studie för att praktiskt testa metoden som implementerats. Viss förfining som större enhetlighet och stringens av 40

38 utvärderingskriterierna kan önskas i framtiden, dels för att underlätta förståelse för metoden som sådan, dels för att analysen av resultatet ska bli mer rättfram. Dock fungerar implementationen av metoden som väntat, utvärderingsprocessen av företags IT-styrning kan med ITOMAT radikalt förenklas. Nedan diskuteras utvärderingen utförande i denna rapport, metodens validitet och tillförlitlighet samt resultaten för utvärderingen på Umeå Energi. 8.1 Specificering av system under utvärdering Cobit presenterar en hög-nivå approach till hur man ska effektivisera IT styrningen på ett företag, men det kan vara svårt att omfatta hela organisationen i utvärderingen. Cobit är ett ramverk för ITorganisationen som ett centralt begrepp och särskiljer inte hanteringen av verksamhetskritiska systemprocesser från processer för stödsystem som är mindre tids- och kostnadskritiska. Om, exempelvis, de verksamhetskritiska processerna är ur funktion så kommer det att ha större effekt för företaget och så är ramverk och kontroll i större grad viktiga. Cobit specificerar endast att detta bör göras för varje process, hur detaljerat eller hur ofta lämnas till andra ramverk såsom ITIL, att definiera. Aktiviteten i process DS11 Skapa backup på data enligt schema definierar inte vilken data det gäller. Implicit bör aktiviteten utföras för all data. På Umeå Energi finns en väl utvecklad procedur för backup och felhantering av det data som tillhör det produktionskritiska värmeverket Dåva. Dock görs inte backup i samma organiserade utsträckning av IT-system på företaget som har mindre kritisk roll för företagets kärnverksamhet. Exempelvis så innefattar aktiviteten Hantera servicedisk och incidenter på Umeå Energi hanteringen av de problem som rapporteras av användare av ickekritiska system såsom administrativa eller kommunikativa. De två aktiviteterna utvärderar hanteringen av två olika typer av system i denna studie. Detta beror på att respondenterna oftast besitter kompetens inom det område de arbetar med specifikt, och relaterar frågan till det system de är kopplade till. En respondent med generell överblick och förståelse för alla företagens system besitter ofta inte specialistkunskaper om hanteringen av de enskilda systemen och processerna. Detta försvårade i viss mån intervjuerna då de olika typerna av system på Umeå Energi oftast hanteras väldigt olika. En uppdelning av utvärderingen till att omfatta de olika systemen individuellt är så av vikt. 8.2 Behandling av trovärdigheten Alla modellerade objekt i instansmodellen har i denna studie en trovärdighet större än 0. Instansmodellen representerar så vad som har någon som helst trovärdighet att det faktiskt finns eller utförs. Referensmodellen kan ses som facit dels över entiteterna definierade i Cobit men även över vilken information datainsamlingen omfattar. Denna studie har omfattat hela IT-styrningen på Umeå Energi och alla de 34 processer som enligt Cobit utgör denna IT-styrning har således frågats om. Om utvärderare i kommande studier är intresserad endast av en viss domän av IT-styrning, exempelvis att utvärdera ett företags prestation inom domänen Planera och Organisera, så ska endast processer under den domänen modelleras i referensmodellen. 8.3 Resultat på Umeå Energi Det som går att utläsa ur resultatet för Umeå energi beskrivit i kapitel 7 pekar i mångt och mycket på att det som påverkar mognadsgraden negativt för Umeå Energi är att de inte dokumenterar och mäter sina processer i så stor grad som Cobit förespråkar. Naturligtvis kan det ifrågasättas om dokumentation i en organisation av Umeå Energis storlek är av stor vikt. På Umeå Energi existerar en företagskultur som möjliggör och uppmuntrar till ett dagligt kunskapsutbyte mellan medarbetarna och dokumentation kan så tyckas överflödig. Vilka som är, exempelvis systemägare är allmänt känt på Umeå Energi fastän ett dokument som heter Dokumenterade systemägare inte existerar. Kunskapsöverföringen underlättas på grund av den specifika kulturen som existerar på Umeå Energi, där socialt samspel mellan de olika avdelningarna och rollerna stimuleras genom gemensamma fikapauser och luncher. Medarbetarna är ofta insatta i vad de andra arbetar med, och dokumentation 41

39 känns överflödigt. Kunskapsöverföringen försvåras visserligen för nytillträdda av avsaknaden av dokumentation. Fortfarande är det dock av största vikt att utföra mätningar av processen för att mäta sina prestationer och stimulera till och möjliggöra framsteg. Ökade mätningar av processen på Umeå Energi skulle leda till högre mognad av processerna och så effektivare IT-styrning. På Umeå Energi är IT-ansvaret distribuerat till de olika avdelningarna och avdelningschefen är systemägare för de system som avdelningen använder internt. Ingen intervju utfördes med systemägare som respondent vilket kunde ha varit relevant i utvärderingen av flera processer i Cobit. Systemägarna på Umeå energi är nämligen de som är ansvariga för huruvida användarna av systemen får rätt träning. Detta är således inte IT-avdelningens ansvar, en intervju med systemägarna hade således varit relevant och önskvärd för att utreda processer som DS7, Utbilda och träna användare. I process DS9 Hantera konfigurationen har leverantören en stor roll i både att ansvara och kontroller konfigurationen. Varje avdelningschef ansvarar för systemen och så även att kontrollerna utförs. Om en intervju med systemägarna hade utförts så vet man om det finns manualer och liknande för varje nytt system. Det fanns så inte tillräcklig information för att avgöra om DS9 exempelvis utförs korrekt, inga direktiv fanns utstakade. Detta kan även ha påverkat fördelningen av sannolikhetsmassan till posten Okänd. 8.4 Validitet Validitet mäter att det som var menat att utvärderas var det som verkligen utvärderades[22]. Validitet syftar till att granska metoden som används. Ger denna metod verkligen ett tillförlitligt mått på utvärderingsområdet? Är rätt saker mätta? Det är så viktigt att metoden verkligen mäter det som kan anses vara IT-styrning. Cobit är det mest vedertagna ramverket för IT-styrning inom branschen[16][14]. De intervjuer som utgör datainsamlingen i ITOMAT är baserad på exakt de processer, aktiviteter, dokument och mätvärden som Cobit presenterar. Till varje process medföljer en beskrivning av processens mål vilket minimerar subjektiviteten i vad som efterfrågas i intervjuerna. Syftet med ITOMAT är att förenkla processen för utvärdering av företags IT-styrning och framta en metod som kan användas av utvärderare utan expertkunskap om Cobit. Då själva utvärderingen, genom ITOMAT och detta examensarbetes implementation av metoden, har automatiserats så är det endast datainsamling och modellering av instansmodellen baserad på insamlingen som krävs för att nå en kvalificerad utvärdering av området. Underlaget till datainsamlingen följer Cobits processer i detalj och instansmodellen bygger helt på resultatet av datainsamlingen vilket förenklar även dessa moment av utvärderingen. ITOMAT är så en kostnadseffektiv och enkel metod som genererar en kompetetnt utvärdering av IT-styrning vilken kan tillämpas på företag generellt. 8.5 Tillförlitlighet För att en metod ska vara tillförlitlig krävs det att den är upprepbar[22]. Detta innebär att två utvärderare som använder samma metod ska komma fram till samma resultat. Detta krav sammanfaller med det övergripande målet med ITOMAT, att skapa en formaliserad metod som kan användas och ge samma resultat utan större kunskap om Cobit. För att kunna göra fallstudier och datainsamlingar upprepbara, så måste de dokumenteras noggrant[22]. Metoden för intervjuerna till datainsamlingen i ITOMAT följer ett strukturerat arbetssätt, där varje del i datainsamlingen följer upplägget i Cobit (se kapitel 6.3). Respondenterna svarar i varje intervju på existensfrågor gällande de aktiviteter, dokument och mätningar som Cobit definierar. Då dessa är utförligt och lättillgängligt dokumenterade i Cobit minimeras risken för oklarheter och metoden är upprepbar. Vidare baseras utvärderingen på metoder som exekveras genom modelleringsprogrammet Metis, vilket kan användas, på exakt samma sätt gång på gång. 42

40 Trovärdigheten i respondenten svar är information i metoden som kan anses var föremål för subjektiv bedömning av utvärderaren. Klara kriterier för trovärdighetsbedömningen och redundans av data minimerar subjektivitet. 9 Förslag till förbättringar Som ovan nämnts så är detta det första steget till en utvärderingsmetod för IT-styrning som överkommer problemen med höga kostnader, validitet och tillförlitlighet som associeras med metoder för dylika utvärderingsförfaranden idag. Utvärderingen är automatiserad med implementationen av ITOMAT i Metis och en viktig fördel med ITOMAT är att en person med begränsade kunskaper om Cobit och IT-styrning kan utföra en kvalificerad utvärdering. Nedan presenteras förslag till förbättringar för att optimera ITOMAT. 9.1 Rekommendationer för utvärderingen Idag mäts de fyra olika utvärderingsområdena i ITOMAT, ansvarsfördelning, aktivitetsutförande, dokumentation och mätvärden, med olika ansatser. Dokumentation och mätningarna av processen har samma tillvägagångssätt och ges så lika stor betydelse, men både ansvarsfördelning, och aktivitetsutförande mäts med olika metodik. Detta beror naturligtvis på den skilda naturen i vad som bör mätas, men enhetlighet och stringens i beräkning av utvärderingen är av vikt för att öka förståelsen för metoden och analysen av dess resultat. 9.2 Rekommendationer för datainsamlingen Detta kapitel innehåller rekommendationer specifikt för datainsamlingsfasen, vilket innefattar både förarbetet för intervjuerna och själva intervjugången. En av anledningarna till att ansvarsfördelningens bedömdes som ett generellt mått på trovärdigheten var att datainsamlingen kring ansvarsfördelningen var svår att utföra. Det var svårt att översätta de roller som Cobit presenterar till de roller som faktiskt finns på företaget. Ofta sitter en och samma person på två eller flera stolar i förhållande till rollerna i i Cobits ansvarsmatris. RACI-matrisen definierad för varje process i Cobit (se kapitel 2.2) innehåller mycket information om hur strukturen för beslutsfattande kan leda till effektivare IT-styrning, så det är av vikt att denna information implementeras i utvärderingsskedet. En klarare definition av vad de olika rollerna har för betydelse innan datainsamlingsskedet är att rekommendera inför framtiden. 9.3 Rekommendationer till Umeå Energi Umeå Energi utförde många av de aktiviteter som specificeras i Cobit, det som bidrog till att mognadsnivån inte blev högre härrör till avsaknaden av dokument och utförda mätningar i processerna. Som diskuterat i kapitel 8.3 så är dokumentation av mindre vikt för Umeå Energi då kunskapsöverföringen sker på många andra sätt. Det är viktigt att hela tiden mäta hur väl man utför en process för att kunna förbättra sin prestation. Det som Umeå Energi behöver för att nå högre Cobit mognad är så att i större utsträckning utföra de mätningar av KPI/KGI inom varje process som Cobit presenterar. 43

41 10 APPENDIX Appendix 1 - Trovärdighetstabell Tabell över de trovärdighetsvärden som de tre olika kriterierna för trovärdighet sammanslagna genererar. Dessa översätts till procenttal och presenteras i de respektive modellerade objekten i instansmodellen. Self assessed credibility: Not certain at all (A=1) Presentation: Sloppy (B=1) Self assessed credibility: Not certain at all (A=1) Presentation: Average (B=2) Self assessed credibility: Not certain at all (A=1) Presentation: Detailed (B=3) Self assessed credibility: Quite certain (A=2) Presentation: Sloppy (B=1) Self assessed credibility: Quite certain (A=2) Presentation: Average (B=2) Self assessed credibility: Quite certain (A=2) Presentation: Detailed (B=3) Self assessed credibility: Perfectly certain (A=3) Presentation: Sloppy (B=1) Self assessed credibility: Perfectly certain (A=3) Presentation: Average (B=2) Self assessed credibility: Perfectly certain (A=3) Presentation: Detailed (B=3) Age of Answer A year ago (C= 1) Age of Answer A month ago (C=2) Age of Answer Yesterday (C=3) 3/9 4/9 5/9 4/9 5/9 6/9 5/9 6/9 7/9 4/9 5/9 6/9 5/9 6/9 7/9 6/9 7/9 8/9 5/9 6/9 7/9 6/9 7/9 8/9 7/9 8/9 9/9 44

42 Appendix 2 - Modell över Umeå Energis IT-styrning Modellen nedan är en översikt av den instansmodell som är resultatet av datainsamlingen på Umeå Energi. I mitten ses de objekt som representerar de roller som är definierade och trådarna ut är de relationer de har med aktiviteterna i varje process. 45

43 Appendix 3 - Modell över processen Definiera IT-processer, organisation och relationer på Umeå Energi. Exempel på hur en modellerad process ser ut på Umeå Energi. Inom denna processen utförs tre aktiviteter på Umeå Energi. Fyra mätningar utförs inom processen och två dokument genereras. 46

44 Appendix 4 - Resultattabeller för processerna inom domänen Aquire and Implement på Umeå Energi AI AI2 Identifiera automatiserade lösningar Förvärva och underhåll mjukvaruapplikationer AI AI4 Förvärva och underhåll teknologisk infrastruktur Möjliggör drift och användning AI AI5 Uppköp IT resurser Hantera förändringar 47

45 AI7 Installera och ackreditera lösningar och förändringar 48

46 Appendix 5 - Resultattabeller för processerna inom domänen Deliver and Support på Umeå Energi DS DS2 Definiera och hantera servicenivåer Hantera tredjepartsservice DS DS4 Hantera prestation och kapacitet Säkerställ kontinuerlig service DS DS6 Säkerställ systemsäkerhet Identifiera och allokera kostnader 49

47 DS DS8 Utbilda och träna användare Hantera servicedisk och incidenter DS DS10 Hantera konfigurationen Hantera problem DS DS12 Hantera data Hantera den fysiska omgivningen DS13 Hantera drift 50

48 Appendix 6 - Resultattabeller för processerna inom domänen Monitor and Evaluate på Umeå Energi ME ME2 Övervaka och evaluera IT-prestation Övervaka och evaluera intern kontroll ME ME4 Säkerställ efterföljning av regleringar Tillhandahåll IT-styrning 51

49 Appendix 7 - Resultattabeller för processer inom domänen Plan and Organise på Umeå Energi PO PO2 Definiera en strategisk IT-plan Definiera informationsarkitekturen PO PO4 Bestäm teknologisk riktning Definiera IT-processerna, organisationen och relationerna PO PO6 Hantera IT-investeringarna Kommunicera ledningens mål och riktining 52

50 PO PO8 Hantera IT humankapital Hantera kvalitet PO PO10 Utvärdera och hantera IT-risker Hantera projekt 53

51 Appendix 8 - Subset Select-algoritm Denna algoritm finner antalet möjliga kombinationer av subsets som kan plockas ur ett set. Implementationen nedan tillhör metoderna för beräkning av dokumentation och utförda mätningar. Algoritmen används för att finna fördelningen av sannolikhetsmassan för alla möjliga antal dokument/mätningar. ' ' allcombos returns an array ' with all the possible combinations ' of true for n choose k ' Function allcombos(n,k) Dim i, j, clength ReDim combo(k+1) csize = nchoosek(n,k) ReDim combinations(csize+1,k+1) ' 'Initilize the array with the first combination ' for i = 1 to k combo(i) = i next clength = 1 Dim h j = 1 while j <> 0 wend end function for h = 1 to k+1 combinations(clength,h) = combo(h) next clength = clength + 1 j = k while combo(j) = n-k+j j= j-1 wend combo(j) = combo(j) + 1 for i = j + 1 to k combo(i) = combo(i-1) +1 next allcombos = combinations 54

52 11 REFERENSER [1] Bernus P., Nemes L. and Schmidt G., (Eds.) (2003). Handbook on Enterprise Architecture. Heidelberg: Springer-Verlag [2] Ekstedt M. (2004), Enterprise Architecture for IT Management. Thesis (PhD). Royal Institute of Technology, Sweden [3] Gammelgård M., Lindström Å., Simonsson M. (2006) A Reference Model for IT Management Responsabilities, ECIS 06. [4] IT Governance Institute. (2005) Control Objectives for Information and related Technology, 4 th edition 2005, USA [5] Johnson P. Credibility Assessment Methodology EARP Internal (2005) [6] Johnson P., Nordström L., Lindström R., (2006) Formalizing Analysis of Enterprise Architecture, I- ESA 06 [7] Lankhorst M. et al., (2005). Enterprise Architecture at Work. Heidelberg: Springer-Verlag [8] Lindström Å., (2006) On the Syntax and Semantics of Architectural Principles, 39 th Hawaii International Conference on System Science [9] McGovern J., Ambler S. W., Stevens M. E., Linn J., Sharan V. and Jo E. (2004). A Practical Guide to Enterprise Architecture, Upper Saddle River, NJ: Pearson [10] Office of Government Commerce, IT Infrastructure Library, [11] O Rourke, Fishman and Selkow, (2003). Enterprise Architecture Using the Zachman Framework. Boston, MA: Course Technology [12] Paulik C. M. et al., (1993) Key Practices of the Capability Maturity Model, Version 1.1. Software Engineering Institute. Pittsburg, Pennsylvania: Carnegie Mellon University [13] Scheisser R., (2002), IT Systems Management. Upper Saddle River, NJ: Pearson [14] Simonsson M., and E. Hultgren, (2005) Administrative Systems and Operation Support Systems - A Comparison of IT Governance Maturity, Proceedings of the CIGRÉ International Colloquium on Telecommunications and Informatics for the Power Industry, Cuernavaca, Mexico [15] Simonsson M., Johnsson P. Model-based IT Governance Maturity Assessments with Cobit, (2006) EARP [16] Simonsson M., Johnsson P., (2006) Assessment of IT governance A Prioritization of Cobit EARP [17] Telelogic AB, System Architect, [18] Troux Technology, Metis [19] Weil P., Ross J. W., (2004) IT Governance, Boston, Massachusetts: Harvard Business School Printing [20] Yang (2002) Nonlinear information aggregation via evidential reasoning in multiattribute decision analysis. [21] Yang (2002) On the evidential reasoning algorithm for multiple attribute [22] Yin K. R., (2003) Case Study Research Design and Methods [23] Wang (2005) The evidential resoning approach for multiple attribute decision analysis using belief degrees 55

53 56