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.

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

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

Helpdesk/ärendehantering

RISKANALYS Projekt KA

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

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

Riskhantering. Tieto PPS AH006, , Sida 1

Arbetsplatstjänsten / SUA

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

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

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

Införandeplan. Handlingsplan. KA-system Version 1.0

Tekis-FB Systemkrav

Riskhantering Landstinget Gävleborg Margareta Petrusson

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

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

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

1. Revisionsinformation

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

Riktlinjer. Telefoni. Antagen av kommundirektören

Projekt KA KA-system v1.0

Författare Version Datum. Visi System AB

VAD MAN BÖR TÄNKA PÅ INNAN MAN INVESTERAR I EN NY TELEFONVÄXEL

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

Riktlinjer. Informationssäkerhetsklassning

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

Business research methods, Bryman & Bell 2007

Europeisk standard för kundkontaktcenter. Bakgrund status - framtid

FunktionsIT Lönsamt, enkelt och tryggt

Installationsanvisningar VISI Klient

Bilaga 1. Definitioner

Övergripande granskning av ITverksamheten

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

ANVISNINGAR OCH MALL FÖR RISKANALYS 2016

Sammanställning 2. Bakgrund

Delprojektbeskrivning

BVS Riskanalys för signaltekniska anläggningsprojekt

Mittuniversitetets riktlinjer för systemförvaltning

Riskhantering för administrativa projekt inom Karolinska Institutet

Riskanalys för signaltekniska anläggningsprojekt

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

LEDNINGSÄGARMODUL. Systemkrav 1(6)

Tomas Axelsson

Systemförvaltningshandbok

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

Rubrikförklaringar till projektmallar

Bilaga, Definition av roller och begrepp, till policy för IT-säkerhet. Publiceringsdatum Juni 2007 ( rev. September 2011)

SLUTRAPPORT för projektet Helpdesk/Ärendehantering Sammanfattning

SLA-användning i kommunerna

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

Informationssäkerhet i. Torsby kommun

Anvisningar för intern styrning och kontroll vid Karolinska Institutet

Kommunikationspolicy

Riktlinjer för projekt i Nacka kommun

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

Plan för riskhantering

Lathund: kurstillfällesbyte Innevarande version vid senaste uppdatering: 1.6.0

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

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10

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

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

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

Installationsanvisningar. till IST Analys

Användarguide Dialog

Projektledning: Kommunikation och Risk

Kompetensprojekt På det mänskliga planet

Att välja verktyg för portföljhantering. - Vad vet en leverantör om det?

Mötesanteckningar: Helpdesk/ Ärendehantering styrgruppsmöte 2

Dokumenttyp: Projekt: Projektnummer: Utfärdat av: Utf datum: Godkänt av : Godk datum: Linn Wallér Odette Escobar

Checklista för Driftsättning - Länsteknik

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

FileMaker. Köra FileMaker Pro 10 på Terminal Services

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

Förvaltningsmodell e- tjänsteplattform

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

Revisionsrapport. 1 Inledning. Revision av uppbördsprocessen Moms. Skatteverket Solna. Datum Dnr

Lathund: Programplanering Innevarande version vid senaste uppdatering:

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

Metodstöd 2

EBITS Energibranschens IT-säkerhetsforum

IT och användbarhet. KIA-projektet. Kvalitet i (IT-)användning Uppsala universitet

Bilaga 5 b: Mall för projektplan

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

Testfrågor till Onedrive for Business - Pilot

Rapport Informationsklassning och riskanalys Mobila enheter Umeå Fritid

PTS synpunkter på remissen av digitalforvaltning.nu (SOU 2017:23) Delbetänkande av Utredningen om effektiv styrning av nationella digitala tjänster

Värdeflödeskartläggning, Eslövs kommun (IT) - med fokus på ständiga förbättringar. Kundreferens, Eslövs kommun Version 1.0 År 2015

Addtech spränger gränserna med Smart Office och Mashup Johan Kvick Addtech, Björn Torold Infor

Välja säkerhetsåtgärder

Riktlinjer för säkerhetsarbetet vid Uppsala universitet

Innehå llsfö rteckning

Medarbetarundersökning Göteborgs Stad 2014

Bilaga 22 till kundval hemtjänst IT relaterade beskrivningar

Kom igång med Topocad ArcGIS

Tillsynsutveckling i Väst. Ämnen, förslag och prioriteringar från Open Space om yrkesrollen

EVALD manual. Evald version

Riktlinjer för telefoni

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... 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