RISKANALYS Basdatorarbetsplatstjänst på Chalmers fas 2 BAT

Sidan: 1 (35) RISKANALYS Basdatorarbetsplatstjänst på Chalmers fas 2 BAT

Sidan: 2 (35) INNEHÅLLSFÖRTECKNING 1 REVISIONSINFORMATION... 4 2 OM DETTA DOKUMENT... 5 3 DELTAGARE... 6 4 RISKANALYS... 7 4.1 SYFTE... 7 4.2 MÅLSÄTTNING... 7 4.3 OMFATTNING... 7 4.4 METOD... 7 3 SAMMANFATTNING... 8 5 PROJEKTRISKER... 12 5.1 MÅLGRUPPER, ADMIN, STUDENTER, FORSKARE... 12 5.2 INFORMATION OCH SÄLJA IN DET HOS KUND.... 12 5.3 FÖRANKRA BESTÄLLARE OCH ANVÄNDARE... 12 5.4 SPRÅKSVÅRIGHETER MELLAN PROJEKT OCH MÅLGRUPP... 13 5.5 FÖR FÅ ANVÄNDARE... 13 5.6 SVÅRIGHET ATT HITTA PILOTANVÄNDARE... 14 5.7 OLIKA FÖRVÄNTNINGAR PÅ EN FULLT UTVECKLAD TJÄNST... 14 5.8 TID (DELPROJEKT)... 14 5.9 SLA-FÖRHANDLING, LEGITIMITET PÅ ANVÄNDARSIDAN... 14 5.10 HÅLLER EJ TID OCH PENGAR PGA. TILLÄGG UNDER PERIODEN... 15 5.11 RESPONS PÅ FÖRSLAG BLIR SÄMRE... 15 5.12 OLIKA FÖRVÄNTNINGAR BEROENDE PÅ VEM MAN ÄR ANV/BESTÄLLARE... 15 5.13 FÖR FÅ ANVÄNDARE I TESTET... 16 5.14 ATTITYDER... 16 5.15 EJ NÖJDA ANVÄNDARE... 16 5.16 PERSONBORTFALL, KONKURRERANDE PROJEKT... 17 5.17 SER INTE TILL ATT HELA DRIFTSMILJÖN ÄR TILLRÄCKLIGT BRA... 17 5.18 FÖRANKRING FINANSIÄRER... 17 5.19 TJÄNSTEN EJ TILLRÄCKLIGT GENOMTÄNKT OCH TESTAD... 18 5.20 FÖRTROENDE FÖR LEVERANTÖR... 18 5.21 BASPAKETET OTILLRÄCKLIGT... 18 5.22 KORT TIDSPERIOD, DÅLIG DOKUMENTATION... 19 6 SUPPORTRISKER... 20 6.1 SUPPORT HELPDESK DRIFT APPLIKATIONER OCH SYSTEM... 20 6.2 KOMMA ÖVERENS OM SERVICENIVÅ HELPDESK... 20 6.3 KOMPETENSBRIST, KOMPETENSNIVÅ... 20 6.4 KOMMA ÖVERENS OM NIVÅ PÅ HELPDESK... 21 6.5 EJ FUNGERANDE KRINGUTRUSTNING... 21 6.6 LOKALA RESURSER... 21 6.7 BAT LOKAL IT, VEM GÖR VAD?... 22 6.8 PROGRAMSUPPORT... 22 6.9 DELA UPP HELPDESK/SUPPORT... 22 7 AFFÄRSRISKER... 23 7.1 KOSTNADSKOMPLEXITET... 23 7.2 SVÅRT ATT JÄMFÖRA KOSTNADER INTERNT OCH EXTERNT (TJÄNSTEN)... 23 7.3 INITIALKOSTNAD... 23 7.4 SVÅRT ATT BEDÖMA MARKNADEN, HUR STOR DEN ÄR.... 24 7.5 SERVICE KOMMER UPPLEVAS SOM DYRARE, DE ACCEPTERAR INTE SERVICENIVÅN... 24 7.6 IT-FAKTURA + BAT SEKTIONSUPPDELNING... 24

Sidan: 3 (35) 7.7 NYTTAN MED BAT/CCM... 25 8 PRODUKT/LEVERANSRISKER... 26 8.1 FÖR FÅ PROGRAM... 26 8.2 FÖR MÅNGA PROGRAM... 26 8.3 TUNN KLIENT OCH MOBILITET... 26 8.4 SVÅRT ATT FÅ MED TYNGRE APPLIKATIONER... 27 8.5 MER JOBB OM ENSTAKA APPLIKATIONER ELLER/OCH HELA PAKET... 27 8.6 KRINGRUSTNING PDA MM... 27 8.7 SÄKERHET MOT ANVÄNDBARHET... 28 8.8 KOSTNADER PRODUKT, URVAL, LICENS... 28 8.9 LICENSER... 28 8.10 KONTROLL... 29 8.11 HANTERING MED SEKRETESS... 29 8.12 TILLGÄNGLIGHET... 29 8.13 SPRÅKPROBLEM PROGRAM... 30 8.14 DISTANSARBETE PÅ VILKET SÄTT... 30 8.15 HELHETSLÖSNING SAKNAR SERVICETJÄNSTER... 30 8.16 VERSIONSHANTERING... 31 9 TEKNISKA RISKER... 32 9.1 KOPPLING TILL CHALMERS KONTOSYSTEM... 32 9.2 IT-LÄRANDE EJ MEDIASTÖD... 32 9.3 PROGRAMKOMPETENS... 32 9.4 BEROENDE AV NÄTVERK... 33 9.5 VIRUSPROBLEM... 33 9.6 SÄKERHET, ANVÄNDARNAS ORO FÖR ATT FINNAS PÅ SAMMA SYSTEM... 33 9.7 PRESTANDA... 33 10 FÖRKLARING TILL KOLUMNRUBRIKER... 35

Sidan: 4 (35) 1 Revisionsinformation Utarbetat av Datum Version Ändringar Niclas Stoldt 2002-02-07 P0.1 Kapitel 1-4 och 10 Marina Hedin 2002-02-28 P0.2 Kapitel 5-9. Granskning av Niclas delar. Niclas Stoldt 1.0 Granskning

Sidan: 5 (35) 2 Om detta dokument Detta dokument beskriver projekt BAT:s risker. Dokumentet är ett resultat av ett riskseminarium som hölls den 28 februari 2002.

Sidan: 6 (35) 3 Deltagare Följande projektmedlemmar var med under analysen: 1. Jan-Martin Löwendahl 2. Görgen Olofsson 3. Michael Morin 4. Peter Strömberg 5. Henrietta Wictorsson 6. Per Andersson 7. Lars Andersson 8. Kristoffer Johansson Följande projektmedlemmar var ej med under analysen: 1. Börje Sennung 2. Björn O. Eriksson 3. Paul Waserbrot 4. Stellan Englèn, Ladok

Sidan: 7 (35) 4 Riskanalys 4.1 Syfte Syftet är att åskådliggöra riskanalysens resultat. Riskanalysen innefattar: Risker Uppskattning av sannolikhet och konsekvens Prioritering 4.2 Målsättning Att identifiera och prioritera de risker som hindrar projektet att uppfylla projektmål (enligt PDF) främst under fas 2. 4.3 Omfattning Riskanalysen omfattar projekt-, support-, affärs-, produkt- och teknikrisker. Riskseminariet avsåg inte ta fram pkt 5 i metoden nedan: åtgärder, ansvarig och färdigtidpunkt. Dokumentet innehåller därför inte heller pkt 5. En risk, Versionshantering, har tillkommit sent på mötet och har därför inte prioriterats. 4.4 Metod Följande steg ingår i riskanalysen: 1. Gemensamt komma överens om projektet mål 2. Lista risker och hot för projektet. Detta görs individuellt i gruppen 3. Sätt ihop en gemensam lista, som grupperas i kategorier (på tavlan) 4. Gör en prioritering av varje risk genom att uppskatta en sannolikhet för att Risken/hotet skall inträffa och konsekvensen om det inträffar. Sannolikhet H M L H 1 3 5 H=Hög 2 4 6 M=Medel L 5 6 6 L=Låg Talen i tabellen avser prioritet och innebär följande: Prio 1 - riskerna skall elimineras Prio 2-4 - riskerna skall elimineras eller hanteras Prio 5-6 - riskerna skall hanteras eller bevakas 5. Föreslå åtgärder för att eliminera, förebygga eller hantera risker, utse ansvarig person och bestämma färdigtidpunkt

Sidan: 8 (35) 3 Sammanfattning Riskerna är sorterade efter prioritet enligt: 1 har högst prioritet, 6 har lägst prioritet. Risk benämning Beskrivning S K Prio Kategori Ansv proj Målgrupper, admin, studenter, forskare För få program Information och sälja in det hos kund. Förankra beställare, användare Språksvårigheter mellan projekt och målgrupp För få användare Svårighet att hitta pilotanvändare Support helpdesk drift applikationer och system Kostnadskomplexitet Komma överens om servicenivå helpdesk Olika förväntningar på en fullt utvecklad tjänst. Koppling Chalmers kontosystem Vad är BAT tänkt att användas till, vilken gruppering, differentiering av olika programpaket till olika målgrupper, risken är att det inte är klart definierat. Grupperna måste vara klart definierade Användarna får inte tillräcklig funktionalitet. Om projektet mot användarna, att inte förankra i organisationen Användarna har svårt för att tala om vad de vill ha, de talar inte samma språk och tvärt om. Användarna är inte tillräckligt intresserade Vad är det som ingår? Definiera vilken omfattning av support. Komplex supportsituaiton. Vi tror att det är blir billigare, men är det säkert? Vi kan inte bevisa att det blir billigare, svårt att göra en korrekt kostnadsjämförelse Kommer man ha samma syn på service Förväntningar, acceptans på version 1.0 H H 1 P H H 1 L H H 1 P H H 1 P H H 1 P H H 1 P H H 1 P H H 1 S H H 1 A H H 1 S H H 1 P H H 1 T Ansv utanför När Status

Sidan: 9 (35) Kompetensbrist, kompetensnivå Tid (delprojekt) Komma överens om nivå på helpdesk SLA-förhandling, legitimitet på användarsidan För många program Håller ej tid och pengar pga. tillägg under perioden IT-lärande ej mediastöd Tunn klient och mobilitet Respons på förslag blir sämre Svårt att få med tyngre applikationer Olika förväntningar beroende på vem man är anv/beställare Mer jobb om enstaka applikationer eller/och hela paket Programkompetens Ej fungerande kringutrustning Kringrustning PDA mm För få användare i testet Tidsbrist, resursbrist Lokalt eller någon telefonsupport Vem bestämmer? En motpart måste hittas. Skall inte finnas tio olika program för att göra matematiska beräkningar. H H 1 S H H 1 P H H 1 S H H 1 P H M 2 L H M 2 P Teknisk begränsning t. ex distansutbildning H M 2 T Mobila användare H M 2 L Måste kunna gå genom en tungarbetad organisation för att få respons Svårt att tillämpa det i BAT, användaren vet inte vilka stora resurser han begär Om man skall vara tvungen att köpa hela konceptet eller enstaka applikationer Det blir omöjligt i driften att veta hur det fungerar. Måste ha hjälp. T. ex om skrivaren inte fungerar Användaren kommer att vilja ha det i produkten. Kalendertid inget problem utan för få användare H M 2 P H M 2 L H M 2 P H M 2 L H M 2 T H M 2 S H M 2 L H M 2 P Attityder Inställning M H 3 P

Sidan: 10 (35) Ej nöjda användare Personbortfall, konkurrerande projekt Ser inte till att hela driftsmiljön är tillräckligt bra Svårt att jämföra kostnader internt och externt (tjänsten) Initialkostnad Svårt att bedöma marknaden, hur stor den är. Säkerhet mot användbarhet Kostnader produkt, urval, licens Licenser Lokala resurser Service kommer upplevas som dyrare, de accepterar inte servicenivån IT-faktura + BAT sektionsuppdelning BAT lokal IT, vem gör vad? Programsupport Vad händer om folk inte gillar tjänsten? Vad händer med projektet om användarna inte är nöjda? Om någon slutar i projektet eller blir sjuk. Glömmer mer skarp test, tidsbrist. Projektet skall få fram en jämförelse kostnadsmässigt internt och externt. Det kan bli för dyrt, vem betalar, en slags tröskelkostnad. Förutsäga marknaden Många användare, balans mellan säkerhet och användbarhet Hur hanterar vi licenserna, antingen basutbud eller tillägg, hur hanterar man kostanden? Kostnader och lev av ett program kanske ändrar sig plötsligt och en viss grupp kanske inte får använda, dvs. licensregler En helpdeskfråga men svårt att få lokala resurser Kostnaden dyrare eftersom den blir definierad, garanterbarhet Hur får vi ut kostnaden på klienten? Lokal IT vänder sig till lokal IT, har med ansvar att göra. Orkar inte ge support på allt, var skall gränsen gå? M H 3 P M H 3 P M H 3 P M M 4 A M M 4 A M M 4 A M M 4 L M M 4 L M M 4 L M M 4 S M M 4 A M M 4 A H L 5 S H L 5 S Förankring finansiärer L H 5 P

Sidan: 11 (35) Kontroll Hantering med sekretess Tillgänglighet Beroende av nätverk Nyttan med BAT/CCM Baspaketet otillräckligt Virusproblem Språkproblem program Tjänsten är ej tillräckligt genomtänkt och testad Förtroende för leverantör Dela upp HelpDesk/support Säkerhet, användarnas oro för att finnas på samma system Distansarbete på vilket sätt Prestanda Kort tidsperiod, dålig dokumentation Helhetslösning saknar servicetjänster Versionshantering Användarna vill gärna installera spel mm, gäller att få acceptans hos användarna, användarna kanske tycker att de tappar kontrollen. Måste ha samman regler för alla, vad man får göra. Man kan oroa sig för att man får sämre tillgänglighet, ökat beroende t. ex om man arbetar hemma. Fungerar inte detta då står allt stilla, kommer inte att kunna göra något alls. Måste jämföra de olika alternativen och peka på nyttan, titta på konkurrerande lösningar H L 5 L L H 5 L L H 5 L L H 5 T L H 5 A H L 5 P Idealsikt om alla kör samma program. H L 5 T Engelska rakt H L 5 L igenom? Bristfällig testning L H 5 P Intern eller extern lev? L H 5 P Risken är att vi tar L H 5 S för lätt på frågan Behörighet L M 6 T Vem skall vi hänvisa till när produkten skall fixas? Ta hand om distansarbete Vad gör jag om prestandan är för låg? Allt som görs skall dokumenteras Ta hand om t. ex e- mailkonton M L 6 L L M 6 T L M 6 P M L 6 L L

Sidan: 12 (35) Prioritet 1 5 PROJEKTRISKER 5.1 Målgrupper, admin, studenter, forskare 5.1.1 Beskrivning Vad är BAT tänkt att användas till, vilken gruppering, differentiering av olika programpaket till olika målgrupper, risken är att det inte är klart definierat. Grupperna måste vara klart definierade 5.1.2 Indikatorer Inga indikationer. 5.1.3 Förebyggande Information (på tex projektets hemsida) om att fler grupper än administratörer kommer att kunna läggas till efter hand. 5.1.4 Hantering Information om att fler grupper kommer att läggas till pga att deras applikationer kan var mer komplicerad och kräver mer kraft. Prioritet 1 5.2 Information och sälja in det hos kund. 5.2.1 Beskrivning Om projektet mot användarna, att inte förankra i organisationen 5.2.2 Indikatorer Vissa önskar mobilitet i tjänsten. 5.2.3 Förebyggande Tydlighet genom information till olika grupperingar. Projektet tar fram en lista/infoplan där ansvariga för informationsspridningen finns för att få ut det till viktiga personer. Ledning och experter skall testa och köra miljön. 5.2.4 Hantering Prioritet 1 5.3 Förankra beställare och användare

Sidan: 13 (35) 5.3.1 Beskrivning Skillnaden vem som skall använda tjänsten, vem som beställer och den som betalar tjänsten. 5.3.2 Indikatorer 5.3.3 Förebyggande Ta fram information till köparen av tjänsten där tjänsternas innehåll skall presenteras. Den som betalar och den som beställer, skall se vad man köper. Användaren kan få information genom tjänsten hemsidan eller av beställare/köparen. Generell information genom vanliga kanaler att tjänsten nu finns tillgänglig. 5.3.4 Hantering Prioritet 1 5.4 Språksvårigheter mellan projekt och målgrupp 5.4.1 Beskrivning Användarna har svårt för att tala om vad de vill ha, de talar inte samma språk och tvärt om. 5.4.2 Indikatorer 5.4.3 Förebyggande Tjänsten säljs som ett baspaket. Nyttja tespilotanvändarna för införsäljning/ambassadörer av tjänsten mot andra administratörer, använda dom som informatörer för att förklara tjänsten. 5.4.4 Hantering Prioritet 1 5.5 För få användare 5.5.1 Beskrivning Användarna är inte tillräckligt intresserade 5.5.2 Indikatorer 5.5.3 Förebyggande Öva in bra argument, billigare bättre. 5.5.4 Hantering Anpassa/ändra tjänsten efterhand.

Sidan: 14 (35) Prioritet 1 5.6 Svårighet att hitta pilotanvändare 5.6.1 Beskrivning 5.6.2 Indikatorer 5.6.3 Förebyggande Fysik och CA samt I för att lägga till ytterligare. 5.6.4 Hantering Prioritet 1 5.7 Olika förväntningar på en fullt utvecklad tjänst 5.7.1 Beskrivning Förväntningar, acceptans på version 1.0 5.7.2 Indikatorer 5.7.3 Förebyggande Information och tydlighet. 5.7.4 Hantering Prioritet 1 5.8 Tid (delprojekt) 5.8.1 Beskrivning Tidsbrist, resursbrist 5.8.2 Indikatorer 5.8.3 Förebyggande Lagt till 80 timmar för delprojektet Tunn klient. 5.8.4 Hantering Sannolikhet 5.9 SLA-förhandling, legitimitet på användarsidan H

Sidan: 15 (35) Prioritet 1 5.9.1 Beskrivning Vem bestämmer? En motpart måste hittas. 5.9.2 Indikatorer 5.9.3 Förebyggande Vi kan definiera tjänsten till motparten (Rektor). Tjänsten är en standardtjänst som skall säljs in. Förankra detta i HLG genom Björn O och JML. 5.9.4 Hantering Prioritet 2 5.10 Håller ej tid och pengar pga. tillägg under perioden 5.10.1 Beskrivning 5.10.2 Indikatorer 5.10.3 Förebyggande 5.10.4 Hantering Prioritet 2 5.11 Respons på förslag blir sämre 5.11.1 Beskrivning Måste kunna gå genom en tungarbetad organisation för att få respons 5.11.2 Indikatorer 5.11.3 Förebyggande 5.11.4 Hantering Prioritet 2 5.12 Olika förväntningar beroende på vem man är anv/beställare

Sidan: 16 (35) 5.12.1 Beskrivning 5.12.2 Indikatorer 5.12.3 Förebyggande 5.12.4 Hantering Prioritet 2 5.13 För få användare i testet 5.13.1 Beskrivning Kalendertid inget problem utan för få användare 5.13.2 Indikatorer 5.13.3 Förebyggande 5.13.4 Hantering Sannolikhet M Prioritet 3 5.14 Attityder Inställning. 5.14.1 Beskrivning 5.14.2 Indikatorer 5.14.3 Förebyggande 5.14.4 Hantering Sannolikhet M Prioritet 3 5.15 Ej nöjda användare 5.15.1 Beskrivning Vad händer om folk inte gillar tjänsten? Vad händer med projektet om användarna inte är nöjda?

Sidan: 17 (35) 5.15.2 Indikatorer 5.15.3 Förebyggande 5.15.4 Hantering Sannolikhet M Prioritet 3 5.16 Personbortfall, konkurrerande projekt 5.16.1 Beskrivning Om någon slutar i projektet eller blir sjuk. 5.16.2 Indikatorer 5.16.3 Förebyggande 5.16.4 Hantering Sannolikhet M Prioritet 3 5.17 Ser inte till att hela driftsmiljön är tillräckligt bra 5.17.1 Beskrivning Glömmer mer skarp test, tidsbrist. 5.17.2 Indikatorer 5.17.3 Förebyggande 5.17.4 Hantering Sannolikhet L Prioritet 5 5.18 Förankring finansiärer

Sidan: 18 (35) 5.18.1 Beskrivning 5.18.2 Indikatorer 5.18.3 Förebyggande 5.18.4 Hantering Sannolikhet L Prioritet 5 5.19 Tjänsten ej tillräckligt genomtänkt och testad 5.19.1 Beskrivning Bristfällig testning. 5.19.2 Indikatorer 5.19.3 Förebyggande 5.19.4 Hantering Sannolikhet L Prioritet 5 5.20 Förtroende för leverantör 5.20.1 Beskrivning Intern eller extern leverantör? 5.20.2 Indikatorer 5.20.3 Förebyggande 5.20.4 Hantering Konsekvens L Prioritet 5 5.21 Baspaketet otillräckligt

Sidan: 19 (35) 5.21.1 Beskrivning 5.21.2 Indikatorer 5.21.3 Förebyggande 5.21.4 Hantering Sannolikhet L Prioritet 6 5.22 Kort tidsperiod, dålig dokumentation 5.22.1 Beskrivning Allt som görs skall dokumenteras 5.22.2 Indikatorer 5.22.3 Förebyggande 5.22.4 Hantering

Sidan: 20 (35) Prioritet 1 6 SUPPORTRISKER 6.1 Support helpdesk drift applikationer och system 6.1.1 Beskrivning Vad är det som ingår? Definiera vilken omfattning av support. Komplex supportsituation. 6.1.2 Indikatorer 6.1.3 Förebyggande Erbjuda en standardtjänst. IT-chefer skall komma överens om nivå på tjänsten. Kostnadsfråga, tiden mot kostnaden. 6.1.4 Hantering 6.2 Komma överens om servicenivå helpdesk Prioritet 1 6.2.1 Beskrivning Kommer man ha samma syn på service 6.2.2 Indikatorer 6.2.3 Förebyggande Specificera WM-datasupport på applikationsnivå. Specificera nivån ut mot användare för den intern supporten. 6.2.4 Hantering 6.3 Kompetensbrist, kompetensnivå Prioritet 1 6.3.1 Beskrivning Rätt kompetens på supportpersonal, rätt person på rätt plats. Vem kan vad, inte slösa hög kompetens på enkla ärenden.

Sidan: 21 (35) 6.3.2 Indikatorer 6.3.3 Förebyggande Rätt kompetens på supportpersonal, rätt person på rätt plats. Vem kan vad. Gå igenom personal och se över deras kunskaper. 6.3.4 Hantering 6.4 Komma överens om nivå på helpdesk Prioritet 1 6.4.1 Beskrivning Lokalt eller någon telefonsupport 6.4.2 Indikatorer 6.4.3 Förebyggande 6.4.4 Hantering 6.5 Ej fungerande kringutrustning Prioritet 2 6.5.1 Beskrivning T. ex om skrivaren inte fungerar 6.5.2 Indikatorer 6.5.3 Förebyggande 6.5.4 Hantering 6.6 Lokala resurser Sannolikhet M Prioritet 4 6.6.1 Beskrivning En helpdeskfråga men svårt att få lokala resurser

Sidan: 22 (35) 6.6.2 Indikatorer 6.6.3 Förebyggande 6.6.4 Hantering Konsekvens L Prioritet 5 6.7 BAT lokal IT, vem gör vad? 6.7.1 Beskrivning Lokal IT vänder sig till lokal IT, har med ansvar att göra. 6.7.2 Indikatorer 6.7.3 Förebyggande 6.7.4 Hantering Konsekvens L Prioritet 5 6.8 Programsupport 6.8.1 Beskrivning Orkar inte ge support på allt, var skall gränsen gå? 6.8.2 Indikatorer 6.8.3 Förebyggande 6.8.4 Hantering Sannolikhet L Prioritet 5 6.9 Dela upp HelpDesk/support 6.9.1 Beskrivning Risken är att vi tar för lätt på frågan 6.9.2 Indikatorer 6.9.3 Förebyggande 6.9.4 Hantering

Sidan: 23 (35) Prioritet 1 7 AFFÄRSRISKER 7.1 Kostnadskomplexitet 7.1.1 Beskrivning Vi tror att det är blir billigare, men är det säkert? Vi kan inte bevisa att det blir billigare, svårt att göra en korrekt kostnadsjämförelse. 7.1.2 Indikatorer 7.1.3 Förebyggande Kontroll på alla ingående kostnader. Ju tidigare detta tas fram desto bättre. Lätt att beräkna kostnad/användare, verksamheten borde kunna uppskatta kostnader idag när det gäller installationer osv. När det gäller konkreta bevis så är det vid uppgraderingar vid tex. virusskydd eller programpaket som skall bytas ut. Vad kostar detta att göra mot enskilda kunder än genom tjänsten. 7.1.4 Hantering Sannolikhet M Prioritet 4 7.2 Svårt att jämföra kostnader internt och externt (tjänsten) 7.2.1 Beskrivning Projektet skall få fram en jämförelse kostnadsmässigt internt och externt 7.2.2 Indikatorer 7.2.3 Förebyggande 7.2.4 Hantering Sannolikhet M Prioritet 4 7.3 Initialkostnad 7.3.1 Beskrivning Det kan bli för dyrt, vem betalar, en slags tröskelkostnad

Sidan: 24 (35) 7.3.2 Indikatorer 7.3.3 Förebyggande 7.3.4 Hantering Sannolikhet M Prioritet 4 7.4 Svårt att bedöma marknaden, hur stor den är. 7.4.1 Beskrivning Förutsäga marknaden 7.4.2 Indikatorer 7.4.3 Förebyggande 7.4.4 Hantering Sannolikhet M Prioritet 4 7.5 Service kommer upplevas som dyrare, de accepterar inte servicenivån 7.5.1 Beskrivning Kostnaden dyrare eftersom den blir definierad, garanterbarhet 7.5.2 Indikatorer 7.5.3 Förebyggande 7.5.4 Hantering Sannolikhet M Prioritet 4 7.6 IT-faktura + BAT sektionsuppdelning 7.6.1 Beskrivning Hur får vi ut kostnaden på klienten?

Sidan: 25 (35) 7.6.2 Indikatorer 7.6.3 Förebyggande 7.6.4 Hantering Sannolikhet L Prioritet 5 7.7 Nyttan med BAT/CCM 7.7.1 Beskrivning Måste jämföra de olika alternativen och peka på nyttan, titta på konkurrerande lösningar. 7.7.2 Indikatorer 7.7.3 Förebyggande 7.7.4 Hantering

Sidan: 26 (35) Prioritet 1 8 PRODUKT/LEVERANSRISKER 8.1 För få program 8.1.1 Beskrivning Användarna får inte tillräcklig funktionalitet. 8.1.2 Indikatorer 8.1.3 Förebyggande Definiera ett standardpaket. 8.1.4 Hantering Prioritet 2 8.2 För många program 8.2.1 Beskrivning Skall inte finnas tio olika program för att göra matematiska beräkningar. 8.2.2 Indikatorer 8.2.3 Förebyggande 8.2.4 Hantering Prioritet 2 8.3 Tunn klient och mobilitet 8.3.1 Beskrivning Mobila användare.

Sidan: 27 (35) 8.3.2 Indikatorer 8.3.3 Förebyggande 8.3.4 Hantering Prioritet 2 8.4 Svårt att få med tyngre applikationer 8.4.1 Beskrivning Svårt att tillämpa det i BAT, användaren vet inte vilka stora resurser han begär. 8.4.2 Indikatorer 8.4.3 Förebyggande 8.4.4 Hantering Prioritet 2 8.5 Mer jobb om enstaka applikationer eller/och hela paket 8.5.1 Beskrivning Om man skall vara tvungen att köpa hela konceptet eller enstaka applikationer. 8.5.2 Indikatorer 8.5.3 Förebyggande 8.5.4 Hantering Prioritet 2 8.6 Kringrustning PDA mm 8.6.1 Beskrivning Användaren kommer att vilja ha det i produkten.

Sidan: 28 (35) 8.6.2 Indikatorer 8.6.3 Förebyggande 8.6.4 Hantering Sannolikhet M Prioritet 4 8.7 Säkerhet mot användbarhet 8.7.1 Beskrivning Många användare, balans mellan säkerhet och användbarhet. 8.7.2 Indikatorer 8.7.3 Förebyggande 8.7.4 Hantering Sannolikhet M Prioritet 4 8.8 Kostnader produkt, urval, licens 8.8.1 Beskrivning Hur hanterar vi licenserna, antingen basutbud eller tillägg, hur hanterar man kostanden? 8.8.2 Indikatorer 8.8.3 Förebyggande 8.8.4 Hantering Sannolikhet M Prioritet 4 8.9 Licenser 8.9.1 Beskrivning Kostnader och lev av ett program kanske ändrar sig plötsligt och en viss grupp kanske inte får använda, dvs. licensregler

Sidan: 29 (35) 8.9.2 Indikatorer 8.9.3 Förebyggande 8.9.4 Hantering Konsekvens L Prioritet 5 8.10 Kontroll 8.10.1 Beskrivning Användarna vill gärna installera spel mm, gäller att få acceptans hos användarna, användarna kanske tycker att de tappar kontrollen. 8.10.2 Indikatorer 8.10.3 Förebyggande 8.10.4 Hantering Sannolikhet L Prioritet 5 8.11 Hantering med sekretess 8.11.1 Beskrivning Måste ha samman regler för alla, vad man får göra. 8.11.2 Indikatorer 8.11.3 Förebyggande 8.11.4 Hantering Sannolikhet L Prioritet 5 8.12 Tillgänglighet 8.12.1 Beskrivning Man kan oroa sig för att man får sämre tillgänglighet, ökat beroende t. ex om man arbetar hemma.

Sidan: 30 (35) 8.12.2 Indikatorer 8.12.3 Förebyggande 8.12.4 Hantering Konsekvens L Prioritet 5 8.13 Språkproblem program 8.13.1 Beskrivning Engelska rakt igenom? 8.13.2 Indikatorer 8.13.3 Förebyggande 8.13.4 Hantering Sannolikhet M Konsekvens L Prioritet 6 8.14 Distansarbete på vilket sätt 8.14.1 Beskrivning Vem skall vi hänvisa till när produkten skall fixas? Ta hand om distansarbete. 8.14.2 Indikatorer 8.14.3 Förebyggande 8.14.4 Hantering Sannolikhet M Konsekvens L Prioritet 6 8.15 Helhetslösning saknar servicetjänster 8.15.1 Beskrivning Ta hand om t. ex e-mailkonton.

Sidan: 31 (35) 8.15.2 Indikatorer 8.15.3 Förebyggande 8.15.4 Hantering Sannolikhet Konsekvens Prioritet 8.16 Versionshantering Ej definierad Ej definierad Ej definierad 8.16.1 Beskrivning 8.16.2 Indikatorer 8.16.3 Förebyggande 8.16.4 Hantering

Sidan: 32 (35). Prioritet 1 9 TEKNISKA RISKER 9.1 Koppling till Chalmers kontosystem 9.1.1 Beskrivning 9.1.2 Indikatorer 9.1.3 Förebyggande Inledande förstudie. 9.1.4 Hantering Prioritet 2 9.2 IT-lärande ej mediastöd 9.2.1 Beskrivning Teknisk begränsning t. ex distansutbildning. 9.2.2 Indikatorer 9.2.3 Förebyggande 9.2.4 Hantering Prioritet 2 9.3 Programkompetens 9.3.1 Beskrivning Det blir omöjligt i driften att veta hur det fungerar. Måste ha hjälp. 9.3.2 Indikatorer 9.3.3 Förebyggande 9.3.4 Hantering

Sidan: 33 (35) Sannolikhet L Prioritet 5 9.4 Beroende av nätverk 9.4.1 Beskrivning Fungerar inte detta då står allt stilla, kommer inte att kunna göra något alls. 9.4.2 Indikatorer 9.4.3 Förebyggande 9.4.4 Hantering Konsekvens L Prioritet 5 9.5 Virusproblem 9.5.1 Beskrivning Idealsikt om alla kör samma program. 9.5.2 Indikatorer 9.5.3 Förebyggande 9.5.4 Hantering Sannolikhet L Prioritet 6 9.6 Säkerhet, användarnas oro för att finnas på samma system Behörighet. 9.6.1 Beskrivning 9.6.2 Indikatorer 9.6.3 Förebyggande 9.6.4 Hantering Sannolikhet L Prioritet 6 9.7 Prestanda

Sidan: 34 (35) 9.7.1 Beskrivning Vad gör jag om prestandan är för låg? 9.7.2 Indikatorer 9.7.3 Förebyggande 9.7.4 Hantering

Sidan: 35 (35) 10 FÖRKLARING TILL KOLUMNRUBRIKER Risk nr: Riskens nummer P = Projektrisk S = Supportrisker A = Affärsmässig risk L = Produktrisk, Leveransrisk T = Teknisk risk Risk benämning: Riskens benämning (riskens namn, riskens rubrik) S: Sannolikhet K: Konsekvens P: Prioritet, Produkten av S och K. Prio 1 - riskerna skall elimineras Prio 2-4 - riskerna skall elimineras eller hanteras Prio 5-6 - riskerna skall hanteras eller bevakas Åtgärd: Vad som skall göras för att åtgärda risken. Ansvarig: Vem som är ansvarig för att åtgärden blir utförd. När: När åtgärden senast skall vara åtgärdad. Status: (tomt) = Ej påbörjat P = Påbörjad A = Avslutad