Projektplan: Nilex-projektet

Transkript

1 1 (7) Projektplan: Nilex-projektet Projektledare: Björn Pettersson Uppdragsgivare: Stefan Lindkvist Datum: Bakgrund och motiv IT-enheten har under en längre tid brottats med problem att få processer som spänner över flera funktioner att fungera nöjaktigt. Ofta så upplever medarbetarna att det är svårt att eskalera ärenden till andra delar av ITenheten. Det finns även situationer då ingen är utpekat ansvarig för ett ärende. När nya funktioner utvecklas eller gamla tas bort så uppstår fel. Allt detta drabbar oftast kunden i form av förseningar, fördyringar och bristande kvalitet. Orsaken till problemen finns att finna i följande tre faktorer: Avsaknad av tydliga processer där det alltid finns ett tydligt ansvar för ett ärende oavsett var ärendet befinner sig i processen. Avsaknad av en korrekt bemanning och rollfördelning för olika funktioner som borde ingå i processerna. Avsaknad av en gemensam plattform som fungerar som kommunikationskanal och som definierar ansvaret för ett ärende för alla berörda medarbetare inom IT-enheten samt berörda användare. Detta projekt syftar till att driftsätta och anpassa ett programvertyg för att förenkla och tydliggöra ärendeflödet inom IT-enheten och mellan IT-enheten och SLU s IT-användare. Anpassning innebär konkret att programverktygets flöden, ärendetyper, roller etc. avspeglar SLU-IT arbetssätt. Eftersom ärendeflödena och rollerna inte är identifierade så krävs det även att projektet måste ta fram hur de viktigaste ärendeflöden skall se ut och vilka funktioner som måste finns för att hantera dessa flöden. Det kommer naturligtvis inte vara möjligt att på en kort tid identifiera alla funktioner och flöden som krävs i en mogen IT-organisation. Inriktningen är att påbörja ett gemensamt arbetssätt och registrera så många av de inkommande ärendena.

2 2 (7) Parallellt med detta så skall även grunddata identifieras. Med grunddata menas kontaktuppgifter för användarna, inventarieuppgifter om datorutrustning och de kontrakt som IT-enheten har tecknat med kunderna. 2. Syfte - nytta med projektet Projektets primära verksamhetsnytta är genom att IT-enheten börjar att arbeta enligt best practice så ökar kundnyttan av IT-enhetens tjänster genom att tjänsterna är bättre anpassade till kundens situation, bättre effektivitet i ITenhetens processer och att möjligheter att skapa mätetal för olika processer inom IT. 3. Mål - resultat av projektet Projektets direkta mål är att införa ett gemensamt ärendehanteringssystem över hela IT-enheten. I ärendehanteringssystemet skall ITIL-processerna incident management, request fulfilment, access management samt change management (till authority/changelevel 4 och level 3) implementeras så det skall gå att registrera och agera på ärenden i enlighet med ITIL i dessa processer. Det skall även finnas stöd till rudimentär problem management i där ortsberedningsgruppen ansvarar för att hantera problemärendena. Projektets indirekta mål är att bidra till den effektivisering och kvalitetshöjning som ligger inom GAIA-projketets målbild. 4. Avgränsningar samt påverkan på annan verksamhet Även om systemverktyget har stöd för att införa de flesta av ITIL s processer, debitering, configuration management database och avtalshantering så kommer detta införande inte att omfatta dessa processer/funktioner. Dessa processer/funktioner bör hanteras i själva servicedeskinförandet. Även ITIL s olika roller hanteras inte i detta införande utan hänvisas till IT-avdelningens organisationsöversyn som sker i annat forum. Projektet påverkar hela IT-enheten eftersom alla funktioner som ingår inom IT är delaktiga i de processflöden som hanteras i systemverktyget. Det måste finnas en gemensam medvetenhet om ansvar och prioriteringar inom alla inblandade IT-funktioner.

3 3 (7) De enskilda användarna påverkas då de får möjlighet att följa sina ärenden via ett webb-gränssnitt. 5. Kritiska faktorer Vilka kritiska faktorer finns det för projektets genomförande? Här kan man antingen använda den framtagna mallen eller helt enkelt skriva ett stycke om de problem och risker som finns inom projektet. Finansiering Projektet saknar finansiering och kommer att drivas inom ramen för IT:s driftsbudget. Det skapar vissa begränsningar vad gäller nyttjandet av externa resurser och de interna resursernas tid är inte finansierad då de deltar i projektet. Notera att själva investeringen av programverktyget samt stöd för anpassning är finansierade. Verksamheten och attityder Det finns en stor risk att det arbetssätt som införs kommer att kännas begränsande av en del medarbetare och att de känner sig styrda. Det finns även risk att de verksamhetsansvariga vissa lägen kan känna sig trampade på tårna då de är tvungna att lämna ifrån sig eller ta nya ansvarsområden eller bli tvungna att bidra till andra ansvarsområdens finansiering. Det finns även en risk att gamla vanor gör sig gällande; Medarbetare har sin egen prioritering och inte systemets; Användarna vänder sig till den man känner och inte Service desk. Tekniska hinder För att det skall vara enkelt att arbeta med systemet så måste en stor del av de grunduppgifter som systemet arbetar med vara inlagda i systemet. Många av dessa uppgifter måste även uppdateras med automatik. Målsättningen är att så få uppgifter som möjligt måste upprätthållas manuellt eftersom detta medför en risk. Det finns risk att SLU:s tekniska infrastruktur inte klarar av att leverera de uppgifter som behövs med en tillräcklig kvalitet. Om systemet känns betungande att arbeta med så kommer det med all sannolikhet att minska motivationen. 6. Genomförande Projektet har fyra faser: Kartläggning av processer:

4 4 (7) De ITIL processer som bedömts att de behövs för att skapa en grundläggande ärendehantering inom IT-enheten implementeras. Dessa processer är incident management, request fulfilment, access management och change management för level 3 och 4. Processkartläggningen av skall ske i workshop-form med deltagare från varje SLU-huvudort och varje funktion inom IT-enheten. Detaljnivå i processkartläggningen skall ha en detaljeringsgrad som lämpar sig för anpassningsarbetet i systemverktyget. Workshopen skall dokumenteras så att processflöden finns dokumenterade. De checklistor och mallar som krävs för ärendeeskalering och ärendehantering skall även identifieras och dokumenteras. För att få en koppling till systemverktygets möjligheter skall personer från leverantören med expertkunskaper om verktyget delta i workshopen. Identifiering av funktioner: Men funktioner menas en indelning av verksamheten med avseende på funktionsansvar t.ex ansvar för ett visst system, nätverksdrift etc. Syftet är att det för de införda ITIL processerna skall finnas en obruten kedja av funktionsansvar från Servicedesk till de olika specialiserade driftsfunktionerna. Det är eftersträvansvärt att ett ärende aldrig hamnar mellan två ansvarsområden. Projektet skall identifiera de funktioner som ingår i de kartlagda processflödena under workshopen för processkartläggningen. Grunddata: För att systemverktyget skall upplevas som rationellt och enkelt att arbeta med så bör så mycket av data om användarna och datorer finns inlagt i systemet. Syftet är naturligtvis att slippa manuella inmatningar och de fel som kan uppstå i samband med det samt en upplevd rationalisering av arbetet. Data om användarna importeras automatiskt från Active Directory varje natt. Det kräver i sin tur att AD:ets data har en tillräckligt hög kvalitet. Eftersom det finns tydliga brister i AD:ets kvalitet så skall projektet ta fram och driftsätta en metod att höja AD:ets kvalitet med data från personalsystemet. Detta kommer att ske med en temporär metod i avvaktan att SLU s katalog och identitetshantring löses på ett korrekt sätt. Datorer inventeras idag av SMS som är det verktyg som SLU valt för hantering av klientdatorer. Projektet skall kartlägga och säkerställa att de datorer som IT stöd ger användarstöd för är med i SMS. Det krävs dock en viss manuell

5 5 (7) inläggning av data för att ge en komplett bild av datorbeståndet, information som ex.vis användare, enhet och anskaffningsdatum. Detta kommer inte att ingå i införandeprojektet. SLA: SLA står för service level agreement, dvs den överrenskommelse som skall finnas mellan utföraren IT-enheten och kunden om vilken kvalitet och vilka tjänster som skall levereras av utföraren. I dag finns ingen enhetlig SLA definierad för alla berörda tjänster inom hela IT-enheten. Inom projektets ramar måste därför en temporär SLA definieras. En slutgiltig hantering av frågan kräver en relativt stor arbetsinsats och involverar bl.a. systemägarna inom SLU. Detta ligger dock utanför ramen för införandeprojektet. 7. Tidsplan Workshop för framtagande av processer och utkast till dokumentation: en heldag under v7. Sammanställning av dokumentation från workshop. Ca tre dagar. Klart v8. Remiss till styrgruppen under v9. Kräver ca en heldag av styrgruppen under v9. Anpassning av systemet under v1. Kräver konsultinsats på ca 3 dagar tillsammans med Tony Lindberg och Ingemar Broman Metod för att höja AD:ets kvalitet, förslag under v5. Kräver ca en halvdag av Pär Igsell och Martin Norrsken vardera. RFC till AD-gruppen om införandet av förslaget under v6. Införandet av kvalitetshöjningen under v7. Utbildning av IT-enhetens handläggare under v11 och v Projektorganisation Projektorganisationen innefattar: En användargrupp av handläggare från IT-enheten som kartägger och dokumenterar de aktuella ITIL-processerna; Deltagarna är Sven-Erik Bylund IT-stöd i Umeå, Pär Igsell Uppdragsenheten i Umeå, Rolf Ericsson IT-stöd i Uppsala, Tony Lindberg Nät & server i Uppsala, Tom Johans IT-säkerhet i Uppsala, Janne Nilsson IT-stöd i Skara och Anna Wallander IT-stöd i Alnarp. Som ledare för workshops och stöd för arbetet deltar Cecilia Wolkert Avd f. Infrastruktur i Uppsala.

6 6 (7) En styrgrupp bestående av Lars Fällman Chef/Uppdrag, Björn Lindell Chef/ITstöd, Johannes Schmidt Chef/Nät & server samt Cecilia Wolkert Controller Avd. f Infrastruktur som granskar användargruppens förslag till processflöde, checklistor och mallar. Styrgruppen beslutar även vilken temporär SLA som ska tillämpas. En driftsgrupp bestående av Tony Lindberg Uppsala och Ingemar Broman Umeå som handhar tekniska driftsfrågor under och efter projektets slutförande. 9. Resurser och budget Inköp av programvara, konsultstöd, utbildning av handläggare ingår i det upphandlade anbudet vilket har hanterats genom upphandlings/installationsprojektet. Således belastar inte dessa kostnader införandeprojektet. Övriga deltagare från SLU, dvs dels de som ingår i projektorganisationen samt övriga vid IT-enheten deltar utan särskild finansiering. Det krävs resor för fyra workshopdeltagare och tillhörande övernattning. Det krävs resa för en person inom styrgruppen och tillhörande övernattning. Detta tas av resp funktion inom IT-enheten inom ordinarie driftsbudget eftersom det inte finns en avsatt budget för själva införandet. 1. Kommunikation/ förankring under och efter projektet Projektet kommer att kommuniceras till alla deltagare via epost under v5. Alla medarbetare vid IT-enheten kommer att utbildas i det anpassade system första halvan av mars. 11. Godkännande av projektplanen Projektets planering och förutsättningar godkänns samt uppdraget accepteras av uppdragsgivaren och projektledaren. Uppdragsgivare Ort och datum Projektledare Ort och datum

7 Tidplan Projektnamn: Nilex Projektledare: Björn Pettersson Uppdragsgivare: Stefan Lindkvist ID Aktivitet Ansvarig Varaktighet Start Slut Avslutat? v5 v6 v7 v8 v9 v1 v11 v12 Antal timmar S Projektstart Informera deltagare Björn P 1 dag Workshop Björn P 1 dag Dokumentation workshop Björn P 3 dagar Remiss till styrgrupp Björn P 1 dag Anpassning av systemverktyg Björn P 3 dagar Förslag höja AD:ets standard Björn P 1 dag RFC AD-standard Björn P 2 dagar Införande av RFC Björn P 3 dagar Utbildning handläggare Björn P 4 dagar Antal timmar