Projektmodellens betydelse i framgångsrika ITIL projekt – del 1

Published

ITIL Ramverket, Projektledning

Projektmodellen framför allt…

En projektmodell ger struktur, fokus, gemensamt språk och tydliga roller.
Tanken med en projektmodell är inte att ”ITIL projektet” ska följa dess ramverk slaviskt utan dess främsta uppgift är att tjänstgöra som ett stödjande och vägledande ”verktyg.”

Då alla ITIL projekt anses vara unika behöver man göra anpassningar av den för stunden tänkta modellen. Hur ska denna anpassning göras? Och Vad ska anpassningen innefatta? Dessa är frågeställningarna som har legat till grund för den korta artikelserie.

Den empiriska bakgrunden bygger på studier av allehanda projektlitteratur samt samtal och diskussioner med projektledare och seniorkonsulter. Mycket av innehållet bygger på egna resonemang och erfarenheter men även från ingående diskussioner med kollegor med insyn i ämnet och branschen. Artikelserien utgår från ett resonemang från en generell projektmodell.

”Det är inte modellen eller metoden som avgör hur bra man lyckas med ITIL projektet utan hur den tillämpas av de inblandade.”
Projektmodell - en förenkling av verkligheten
Projektmodell – en förenkling av verkligheten

Projektmodell/metod – när, var, hur och varför

En projektmodell är ett samlat ”dokument” som innehåller ett företags regler, riktlinjer och dokumentation m.m.. Modellen är tänkt att användas vid företagets projektgenomförande. En projektmodell ger struktur, fokus, gemensamt språk och tydliga roller.

Beroende på vilken projektmodell man talar om, kan den användas på enskilda isolerade projekt eller innefatta hela flerprojektorganisationer. En projektmodell ska också vara ett hjälpmedel för personer som normalt inte jobbar med ITIL projekt och som blivit utsedda eller ombedda att medverka i projektarbete. Med det inte sagt att allt ska drivas efter en projektmodell.

Reflektioner bör inte bara göras utifrån om en projektmodell ska användas eller inte. Man bör även fråga sig hur respektive projektmodell bäst utnyttjas av ett projekt, d.v.s. hur en projektmodell anpassas till en viss typ av projekt. Vi vet ju att projekt per definition innebär att en unik (Marttala, A. & Karlsson, Å. (1999), s. 10) företeelse utförs. Så hur skulle det bli om man använde exakt samma projektmodell till alla typer av projekt. Ett kliniskt utvecklingsprojekt har ju inte samma förutsättningar som ett anläggningsprojekt. Efter en jämförelse mellan olika projektmodeller ser man tydligt att det är mer som är lika än vad som skiljer dem åt.

Innan man ens funderar på att använda en projektmodell måste man vara väl medveten om hur organisationen har använt modeller i tidigare sammanhang. Om projektdeltagarna inte är bevandrade i en specifik modell bör den helt enkelt inte användas. En annan otroligt viktig aspekt på modellanvändandet är att modellen har en acceptans och att den är förankrad i organisationen från högsta ledning. Detta för att ge legitimitet för användandet och basen till att modellutbildning ska ingå för respektive projektdeltagare. Det är således inte projektledarens ansvar att se till att deltagarna är kunniga i modellen utan företagsledningen.

Tanken med en modell är inte att ”projektet” ska följa dess ramverk slaviskt utan modellens främsta uppgift är som beskrivits ovan att var ett stödjande ”verktyg.” Ett hjälpmedel att gå tillbaks till under projektprocessen för att få vägledning och hjälp när det gäller allt från styrning, kommunikation och resurshantering till aktiviteter och osäkerhetshantering.

Att jobba med och i projekt kräver ordning och reda. Klara ramar, riktlinjer och roller är byggstenarna i ett lyckat ITIL projekt. Att starta projekt helt utan några som helst fördefinierad riktlinjer kan självklart lyckas men det rekommenderas varmt att åtminstone om än skriven på en servett följa någon typ av ”roadmap”, vad som behövs är en projektmodell eller som det ibland även kallas projektmetod (Marcusson, L. & Ahlin, A. (2002), s. 14). I resterande text kommer uttrycket projektmodell att användas.

Major Incident Management – Vad är det?

Major Incident Management – En procedur inte en process

Den övergripande målsättningen med Incidentprocessen är att återställa störningar hos IT-tjänster så snart som möjligt. Allt i linje med att användaren känner sig väl- och professionellt bemött.

Vid större störningar som kan leda  till stor negativ och påverkan på verksamheten bör en separat rutin eller som ITIL kallar det en procedur aktiveras, den s.k. Major Incident Management rutinen, en rutin med kortare tidsfrister, snabba eskaleringsvägar och högre prioritet.

Major incidenthantering är en speciell form av Incident Management hantering där samordning och kommunikation internt och externt betonas för att åtgärda incidenten med högsta möjliga fokus.

Rutinen för Major incidenter anropas av rollen Incident Manager.

Syftet med Major incident management rutinen är att säkerställa att rätt resurser allokeras för att på snabbast möjliga sätt åtgärda en incident vilken kräver insatser utöver det vanliga, samt att styra informationsflödet till berörda parter så att rätt beslut kan tas av rätt beslutsfattare.

Major Incident definition:

En incident med en hög påverkan, eller potentiellt hög påverkan på verksamheten och/eller dess intressenter (användare, kunder m.m.) vilken kräver en hantering som ligger utanför det som anges för normala incidenter. Vanligtvis (men inte alltid) klassas en incident som en Major Incident om den har en direkt påverkan på verksamhetskritiska tjänster.

Observera att en incident kan klassas som en Major Incident trots att det inte existerar ett regelrätt tjänsteavbrott. En driftstörning likt en överdriven ”tröghet” (långa svarstider) i exempelvis ett affärssystem kan vara föremål för en Major incident klassning.

Incident Management Processen
Incident Management Processen

 

– Mognadsanalys av Incident Management

Ladda ner verktyg för mognadsanalys av Incident Management

En gap-analys är ett verktyg som gör det möjligt för en organisation att jämföra sin aktuella prestation med sin potentiella prestation. Målet med mognadsanalysen (GAP-analysen) är att identifiera gapet mellan den nuvarande och den optimala situationen för att ge insikt inom vilka områden det finns en förbättringsmöjlighet.

Detta verktyg kan användas för att göra en enkel Mognadsanalys på Incident Management processen. Du kan skapa nya eller ersätta befintliga frågor om du önskar komplettera eller ändra.
Verktyget har utvecklats som en utgångspunkt för att belysa områden inom Incident Management processen som kräver särskild uppmärksamhet och för att ge dig en uppfattning om er processmognad.

Verktyget Mognadsanalys på Incident Management processen är konstruerad för 10 respondenter.

Du kan använda flera kalkylblad för att göra en större analys.

Syftet är att använda verktyget som utgångspunkt för förbättringar och etablera en eller flera utgångspunkter (Base line) för era visioner och strategier gällande Incident Management processen. Frågorna och verktyget kan naturligtvis även användas på andra processer.

LADDA NER VERKTYGET GRATIS

Mognadsanalys av Incident Management processen
Mognadsanalys av Incident Management processen

Verktygets skapare: www.ucisa.ac.uk


 

Incident Management – Processbeskrivning

Incident Management – ITIL processen framför andra

Incident Management (den formella ITIL-förkortningen = IM) är supportprocessen framför andra. Ingen ITIL process är så spridd och utvecklade som just Incident Management-processen. Incident Management har till syfte att hantera alla incidenter. Den officiella ITIL definitionen på en incident är:

– En oplanerad störning av en IT-tjänst (eller försämring av kvaliteten)

                                            och/eller

– Fel på ett konfigurationsobjekt som ännu inte har påverkat en IT-tjänst

Incidenter kan nå Servicedesk genom olika kanaler, exempelvis kan incidenter rapporteras av slutanvändare, genom teknisk personal eller automatiskt via övervakningsverktyg (ITIL processen Event Management). Syftet med Incident Management processen är att återställa IT-tjänster/system så snabbt som möjligt och minimera de negativa effekterna på verksamheten. En Servicedesk/Helpdesk kan uppnå detta genom att använda en dokumenterad, kommunicerad, begriplig och mätbar Incident Management process och tillhörande verktyg.

Funktionen Servicedesk/Helpdesk är användarens/kundens centrala kontaktyta, en så kallad Singel Point Of Contact eller SPOC mot IT-organisationen. Funktionen äger ansvaret för att snabbt och effektivt hantera Incidenter, förfrågningar (service requests) och infrastrukturella larm (events).

Huvudaktiviteterna i incidentprocessen är upptäcka, registrera, analysera, hitta åtgärd och åtgärda, bekräfta åtgärd och stänga incidenter, förfrågningar och larm. Arbetet i incidentprocessen utförs främst med hjälp av ärendehanteringsverktyg. En incident som inkommer till Servicedesk/Helpdesk följer ett flöde (se nedan, Klicka för större bild) med olika aktiviteter. Exempel på aktiviteter är identifiera, logga, kategorisering, prioritera, diagnostisera och hantera Major Incident (Allvarlig Incident med behov att hanteras brådskande).

 

Incident Management Processen
Incident Management Processen