RISKANALYS Basdatorarbetsplatstjänst på Chalmers fas 2 BAT

Relevanta dokument
RISKANALYS Basdatorarbetsplatstjänst på Chalmers fas 2 BAT

PROJEKTDEFINITION. Syftet med projektdefinitionen är att identifiera, definiera och avgränsa åtagandet i projektet.

SLUTRAPPORT. Syftet med slutrapporten är att redovisa måluppfyllelse, erfarenheter och rekommendation till ett förbättrat arbetssätt.

RF, AB, SK 4 Tid FIM Tid 01-jul Frigör från övrigt utvecklingsabete ÅJ 4 Regelverk (Hårda regler, Inga quick fixes, Tid för synk

RISKANALYS Projekt KA

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Riskhantering. Tieto PPS AH006, , Sida 1

PROJEKTDEFINITION. Syftet med projektdefinitionen är att identifiera, definiera och avgränsa åtagandet i projektet.

Projekt KA Magnus Holmström. Chalmers gemensamma system för kursadministration

Helpdesk/ärendehantering

Mötesanteckningar: Helpdesk/ Ärendehantering Referensgruppsmöte 2, Förvaltningsgruppen ekonomi

Mötesanteckningar: Persondatabas fas 3, Styrgruppsmöte 3

Riskhantering Landstinget Gävleborg Margareta Petrusson

Mötesanteckningar: Helpdesk/ Ärendehantering Projektgruppsmöte 4

ANVISNINGAR OCH MALL FÖR RISKANALYS 2016

Arbetsplatstjänsten / SUA

Mötesanteckningar: Persondatabas fas 3, Styrgruppsmöte 1

Projekt KA KA-system v1.0

RISKANALYS JMG, Institutionen för journalistik, medier och kommunikation, inkl SOMinstitutet DNR V 2015/965 DATUM:

Riktlinjer. Informationssäkerhetsklassning

Införandeplan. Handlingsplan. KA-system Version 1.0

Författare Version Datum. Visi System AB

Projekt KA KA-system v1.0. Projekt KA Siw Bengtsson

Mötesanteckningar: Persondatabas fas 3, Styrgruppsmöte 6

Informationssäkerhet är ett medel som bidrar till att uppnå kommunens övergripande mål.

Installationsanvisningar VISI Klient

Riskhantering för administrativa projekt inom Karolinska Institutet

FunktionsIT Lönsamt, enkelt och tryggt

Mobilitet- Mobil standardterminal, PIM, mobilapplikation samt Campuskarta. Ett delprojekt under IT-strategiska insatser

Tekis-FB Systemkrav

KRAVSPECIFIKATION. Hr Björkmans Entrémattor AB - Framtida Mobila Lösningen. Examensarbetaren: Avan Omar Ismail. Kund: Hr Björkmans Entrémattor AB

LEDNINGSÄGARMODUL. Systemkrav 1(6)

1. Revisionsinformation

RISKANALYS FÖR Humanistiska fakulteten. DATUM: Förslag BESLUTAD AV: Humanistiska fakultetsstyrelsen. KONTAKTPERSON: Mats Andrén

Rubrikförklaringar till projektmallar

Välja säkerhetsåtgärder

Riktlinjer. Telefoni. Antagen av kommundirektören

Mötesanteckningar: Persondatabas fas 3, Styrgruppsmöte 7

Bilaga 22 till kundval hemtjänst IT relaterade beskrivningar

Ärende Beslut eller åtgärd. 1 Fastställande av dagordning Inga ärenden anmäldes till Övrigt.

RISKANALYS Humanistiska fakulteten. Dnr V 2016/705. DATUM: Förslag till beslut BESLUTAD AV: Humanistiska fakultetsstyrelsen

Tomas Axelsson

MJÖLBY KOMMUN UTBILDNINGSFÖRVALTNINGEN. Roller och ansvar inom utbildningsförvaltningens IT-verksamhet IT-strategigruppen

Europeisk standard för kundkontaktcenter. Bakgrund status - framtid

UNG KRAFT Processtöd för ett inkluderande arbetsliv för unga funktionshindrade

Plan för riskhantering

Smart Service Manual Service system. Document id: Date: 28 Nov 2012 Version: 0.9

Rapport Informationsklassning och riskanalys Mobila enheter Umeå Fritid

Delprojektbeskrivning

Våra älskade och hatade applikationer! Våra älskade och hatade applikationer! Atea Application Center Applikationshantering dyrt och tidsödande, eller

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10

Riktlinjer för säkerhetsarbetet vid Uppsala universitet

Testfrågor till Onedrive for Business - Pilot

SF Bio App. Repport. Test summary. 1- Syfte. 2. Produktöversikt. Författare: Zina Alhilfi Datum: Version: v1,0

Metodstöd 2

Övergripande granskning av ITverksamheten

E- möten Snabbguide till Adobe Connect

Undervisningen i ämnet mobila applikationer ska ge eleverna förutsättningar att utveckla följande:

Innehåll (3) Innehåll (2) Innehåll (5) Innehåll (4) Innehåll (6) Innehåll (7) Dokumenthistorik. beställare, Översiktlig beskrivning av projektet

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga B. Servicenivåer konsument, SLA. Version: 1.

Roller. Student. Institutionen för informationsteknologi

Checklista för Driftsättning - Länsteknik

Roller. Student. Institutionen för informationsteknologi

RUTIN FÖR RISKANALYS

Jag ska göra en skiss. Jag gör ett diagram. Jag ska gissa!

Projektplanering. Projektplanen. Om inte projektet planeras noga, kommer det garanterat att misslyckas

Systemförvaltningshandbok

SLA-användning i kommunerna

Intraservice. Mobil arbetsplats. För legitimerade medarbetare i hemsjukvården

Så här skapar du en katastrofplan för oförutsedda händelser

Rätt informationssäkerhet är A&O vid införande av välfärdsteknologi. Jeanna Thorslund, Sveriges Kommuner och Landsting Thomas Nilsson, Certezza

Olivia Hemtjänst AB - Kungsholmen 2015

Information om den Europeiska standarden för kundkontaktcenter. Bakgrund status - framtid

WebOrderInstallation <====================>

Från idé till projektplan

Beslut och risker i inköpsprocessen. Upphandlingsdagarna

Med Reality Energy Log REL kan du hålla koll på dina elkostnader med hjälp av ett knapptryck.

Regelverk. Infrastrukturen för vidareförmedling av grundläggande uppgifter om företag. Bilaga C. Servicenivåer Producent, UC. Version: 1.

Användarhandbok för Windows v6

Säkerhet genom simpel nätverksutrustning. Högskoleingenjörsexamensarbete Fredrik Folke

Projektledning: Kommunikation och Risk

NPÖ konsument över Internet/Kunskapsöversikt NPÖ. Lars Törnblom/ Marita OlssonNarving Sveriges kommuner och landsting

Tillägg 3 till PBS 4.12A sp 02

Installationsanvisningar. till IST Analys

Mötesanteckningar: Arbetsmöte 1 Persondatabas fas 3 - Realisering

REGLEMENTE FÖR. Intern kontroll. Antaget Tillsvidare, dock längst fyra år från antagande

Beslut om genomförande av anskaffning av tjänst för systemintegration

Verksamhetsplan för Mejeritekniskt Forum

Postens outsourcing av driften av IT-infrastrukturen

Mittuniversitetets riktlinjer för systemförvaltning

Medarbetarundersökning Göteborgs Stad 2014

På denna dialog på fliken Avancerat kan man även byta databas samt skapa en ny databas.

Kravlista. Konvertering av UX04 UPP-T Version: Beteckning:

Riskanalys för signaltekniska anläggningsprojekt

Riktlinjer för IT i Lilla Edets kommun. 2. Syftet med IT i Lilla Edets kommun

Lösning Lösningsgranskning

Dokumenttyp: Projekt: Projektnummer: Beskrivning av teknikprojekt inom kommunerna Strömstad och Tanum

Checklistor för riskidentifiering

Skapa förväntat deltagande på kurstillfälle eller kurspaketeringstillfälle (Manuell antagning i Ladok)

Frågor att ställa om IK

Transkript:

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... 13 5.7 OLIKA FÖRVÄNTNINGAR PÅ EN FULLT UTVECKLAD TJÄNST... 13 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... 14 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... 15 5.14 ATTITYDER... 16 5.15 EJ NÖJDA ANVÄNDARE... 16 5.16 PERSONBORTFALL, KONKURRERANDE PROJEKT... 16 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... 17 5.20 FÖRTROENDE FÖR LEVERANTÖR... 18 5.21 BASPAKETET OTILLRÄCKLIGT... 18 5.22 KORT TIDSPERIOD, DÅLIG DOKUMENTATION... 18 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?... 21 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... 24 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... 32 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 5.1.3 Förebyggande 5.1.4 Hantering 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 5.2.3 Förebyggande 5.2.4 Hantering Prioritet 1 5.3 Förankra beställare och användare 5.3.1 Beskrivning 5.3.2 Indikatorer 5.3.3 Förebyggande 5.3.4 Hantering

Sidan: 13 (35) 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 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 5.5.4 Hantering Prioritet 1 5.6 Svårighet att hitta pilotanvändare 5.6.1 Beskrivning 5.6.2 Indikatorer 5.6.3 Förebyggande 5.6.4 Hantering Prioritet 1 5.7 Olika förväntningar på en fullt utvecklad tjänst

Sidan: 14 (35) 5.7.1 Beskrivning Förväntningar, acceptans på version 1.0 5.7.2 Indikatorer 5.7.3 Förebyggande 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 5.8.4 Hantering Prioritet 1 5.9 SLA-förhandling, legitimitet på användarsidan 5.9.1 Beskrivning Vem bestämmer? En motpart måste hittas. 5.9.2 Indikatorer 5.9.3 Förebyggande 5.9.4 Hantering Prioritet 2 5.10 Håller ej tid och pengar pga. tillägg under perioden

Sidan: 15 (35) 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 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

Sidan: 16 (35) 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? 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.

Sidan: 17 (35) 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 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.

Sidan: 18 (35) 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 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

Sidan: 19 (35) 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 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 6.2.4 Hantering 6.3 Kompetensbrist, kompetensnivå Prioritet 1 6.3.1 Beskrivning 6.3.2 Indikatorer 6.3.3 Förebyggande 6.3.4 Hantering

Sidan: 21 (35) 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 6.6.2 Indikatorer 6.6.3 Förebyggande 6.6.4 Hantering Sannolikhet 6.7 BAT lokal IT, vem gör vad? H

Sidan: 22 (35) Konsekvens L Prioritet 5 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 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 7.3.2 Indikatorer 7.3.3 Förebyggande 7.3.4 Hantering

Sidan: 24 (35) 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? 7.6.2 Indikatorer 7.6.3 Förebyggande 7.6.4 Hantering Sannolikhet L Prioritet 5 7.7 Nyttan med BAT/CCM

Sidan: 25 (35) 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 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 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 Sannolikhet 9.4 Beroende av nätverk L

Sidan: 33 (35) Prioritet 5 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