Inledning · Web viewMetodiken förbättras ständigt genom erfarenhetsåtervinning från genomförda projekt. Tietos avvecklingsmodell, Shut down, bygger på projektstyrningsmodellen

Tjänstebeskrivning Applikationsförvaltning

Tjänstebeskrivning

Applikationsförvaltning

Sida 1/11


Innehåll

1 Inledning..................................................................................................................................... 3

2 Införande..................................................................................................................................... 3

3 Tjänstebeskrivning..................................................................................................................... 6

4 Avveckling.................................................................................................................................. 9

Sida 2/11


Applikationsförvaltning

1 Inledning

I denna bilaga beskrivs de tjänster som ingår inom området applikationsförvaltning.

2 Införande

I detta avsnitt beskrivs kortfattat hur Tieto arbetar med att säkerställa ett effektivt införande i samband med avrop.

När det gäller införande av tjänster för applikationsförvaltning kommer detta att göras som ett delprojekt eller som en separat del i ett delprojekt i den samlade projektorganisationen för hela införandet. Vilken utformning som väljs beror till största delen på omfattningen och komplexiteten i tjänsteinnehållet för applikationsförvaltningstjänsterna som ska implementeras i det aktuella avropet.

Införandemetodiken omfattar ett antal styrningsprinciper som gör att projektet har såväl en etablerad projektorganisation som tydliga eskaleringsvägar. Dessa gemensamt syftar till att säkerställa ett effektivt införande med ett minimum av påverkan och störning på kundens verksamhet.

Nedan presenteras översiktligt Tietos metodik för införandeprojekt som bygger på Tietos projektstyrningsmodell PPS (Praktisk ProjektStyrning).

Tieto tar helhetsansvar för införandeprojektet och utser en huvudprojektledare. Följande delar behövs i denna typ av projekt:

Styrgrupp: Kunden bör ha ordföranderollen Projektledning: Tieto utser huvudprojektledare, kunden utser en biträdande projektledare Projektdeltagare: Projektet bemannas med resurser från Tieto, kunden och andra berörda

leverantörer för att säkerställa att projektet har tillgång till rätt kompetenser i tillräcklig omfattning

Införande av tjänstSamtliga i denna bilaga beskrivna tjänster har samma leveransmodell och tjänsteimplementering. Vi har valt att beskriva dem övergripande i det följande.

Tieto använder sina standardprocesser, verktyg och metoder genom hela leveranskedjan. Tieto samarbetar med kunden genom självbetjäningskanaler, Service Desk och i olika leverans-styrningsforum.

Sida 3/11


LeveransmodellEn översikt över Tietos leveransmodell presenteras i följande bild.

Beställa Denna process hanterar tjänstebegäran och beställningar som kommer från kunden via tjänstekanalerna.

Request fulfilment Change management Åtgärda Denna process löser incidenter som har rapporterats via tjänstekanalerna eller genom automatisk övervakning. Processen är baserad på följande ITIL Event management:

Incident management Problem management Major incident management Förebygga och kontrollera Dessa processer säkerställer tjänstekvalitet (kapacitet och tillgänglighet) och tillhandahåller rapportering för både ekonomi och kvalitet. Målet är att säkerställa att tjänsten levereras på ett kontrollerat sätt i enlighet med avtalat SLA. Tjänstehanteringen är baserad på följande ITIL-processer: Change management Configuration management Availability management Demand management Capacity management Service level management

Förbättra

Sida 4/11


Tieto förbättrar kontinuerligt våra tjänster samt utvecklar och tillhandahåller tjänster som tillgodoser både kundens och marknadens utvecklingsbehov. Kvalitetsavvikelser förhindras genom kontinuerliga tjänsteförbättringsaktiviteter som exempel analys av data, återkoppling från kunder, rapporter samt initiering av förbättringar vad gäller både tjänstefunktioner och processer. Automatisering och standardisering är huvudfaktorerna i förbättringsarbetet, vilket leder till effektivare tjänster som ger mervärden.

Tjänsteimplementering Tietos standardiserade modell för tjänsteimplementering som presenteras i följande bild, visar Tietos processer för att implementera nya tjänster. Dess gemensamma riktlinjer, verktyg och arbetssätt tillhandahåller strukturen och synligheten för implementeringar och hjälper också till i interna projektstyrningsaktiviteter.

Quality Gates (QG1-QG5 i bilden) är möten där nyckelpersoner för projektleveransen gemensamt tar beslut om att gå vidare till nästa fas i leveransen. Checklistor används för att verifiera att projektet är klart för nästa fas.

Överlämning

Försäljning Projekt Kontinuerlig tjänst

ÖverlämningTjänste-

verifieringImplementeringPlaneringInitieringTjänstespår

KontrollspårTekniskt spår

Teknisk implementering

• Implementering av teknisk lösning

• Installationsbeskrivningar• Test och verifiering

Implementering av tjänst

• Tjänstebeskrivning• Rutiner för support• Samverkan

Kontroll och styrning

• Projekthantering• Leveransstyrning• Uppföljning

QG1 QG2 QG3 QG4 QG5

Överlämning

Sida 5/11


3 Tjänstebeskrivning

Tjänsten applikationsförvaltning ansvarar för applikationens funktionalitet under dess hela livscykel. Det innebär ansvar för felrättning, versionshantering, löpande underhållsäkerhet, kvalitetssäkring samt övergripande styrning.

Applikationsförvaltning fokuserar på två områden:

Hög tillgänglighet till applikationer och de tjänster som levereras Ständiga förbättringar av applikationer och de tjänster dessa levererar så att optimalt värde

skapas för verksamheten

Applikationsförvaltning omfattar följande:

Samtliga aktiviteter som krävs för att effektivt förvalta avtalade applikationer Processer och flöden genom Service Desk Kontinuerlig koordinering och rapportering så att resultatet av applikationsförvaltningen alltid

är tillgängligt och transparent

Då kravbild, förväntningar och önskade tjänstenivåer varierar mellan olika applikationer, grupper av applikationer och över tid kommer applikationsförvaltning att levereras i olika former. Dessa skiljer sig åt beträffande omfattning (innehåll) och definierade tjänstenivåer, vilket ger valfrihet i anpassningen av förvaltningsinsatsen.

Applikationsförvaltningen paketeras enligt följande:

Applikationsförvaltning – BasBas utgör det enklaste paketet. Det omfattar endast de huvudaktiviteter som är nödvändiga för att felrättning ska kunna hanteras och enklare frågor och beställningar ska kunna göras. Bas är främst avsett för äldre och driftstabila applikationer vars tillgänglighet och prestanda inte är direkt avgörande för verksamheten. Tjänstenivåerna är justerade för ett minimalt förvaltningsåtagande.

Omfattar aktiviteter nödvändiga för felrättning, hantering av enklare frågor samt support Mycket låga SLA-krav Ingen utveckling sker inom applikationen För applikationer under avveckling

Applikationsförvaltning – Utökad BasUtökad Bas har en ökning av antalet ingående aktiviteter, samtidigt som ytterligare en reglering av tjänstenivåerna har gjorts. Utökad Bas inkluderar ej verksamhetskritiska eller ny-/vidareutvecklade applikationer, utan inkluderar främst mogna och driftstabila applikationer med få incidenter.

Grundläggande kravhantering samt test Låga SLA-krav Låg grad av utveckling sker inom applikationen Stabila och ej verksamhetskritiska applikationer För applikationer under avveckling

Applikationsförvaltning – StandardStandard omfattar samma uppsättning av aktiviteter som Premium som redovisas nedan. Det som skiljer är tjänstenivåerna i SLA. Standard är tänkt för prioriterade applikationer vars tillgänglighet och pålitlighet är mycket viktiga för kunden, men där verksamheten vid avbrott inte blir lidande av en längre åtgärdstid än den som Premium medger.

Sida 6/11


Inkluderar merparten av tjänsterna Något lägre SLA-krav än Premium Applikationer där tillgänglighet och pålitlighet är mycket viktigt

Applikationsförvaltning – PremiumPremium är det mest kompletta och omfattande paketet. Premium ska nyttjas för de mest verksamhetskritiska applikationerna där pålitlighet och tillgänglighet är av central betydelse. Även helt nyutvecklade applikationer, som initialt kan förväntas ha ett stort incidentflöde, inordnas i denna kategori.

Inkluderar samtliga tjänster som behövs för att tillgodose verksamhetens krav och behov Höga SLA-krav För direkt verksamhetskritiska applikationer För nyutvecklade applikationer

Nedan beskrivs de paket som ingår i applikationsförvaltningen. Paketen ska bereda bästa möjliga anpassning av förvaltningsinsats per applikation och pris. Paketen kan tillhandahållas i olika nivåer för att ge optimal precision av förvaltningsåtagande per applikation.

Nivåindelningen sker utifrån nedanstående fem huvudgrupperingar av faktorer:

Teknisk uppbyggnad och komplexiteto Mängd programkod och programmeringsspråko Antal systemsambando Övergripande arkitektur

Applikationens ålder och mognado Standardsystem (grad av anpassning) eller kundunik lösningo Ålder/position i livscykelno Systemdokumentation (omfattning och kvalitet)

Verksamhet som ska stödjaso Hög verksamhetskritisk nivåo SLA-kravo Antal användareo Antal samtidiga användare

Sida 7/11


Stabilitet utifrån antalet supportärendeno Antal ärenden (Incident management)o Antal komplexa ärenden (Problem management)o Antal beställningar (Service requests)o Antal begärda förändringar (Change management)

Förändringstakto Antal förändringar som inte startats av Problem managemento Antal planerade releaser per åro Påverkande projekt (pågående/planerade)

Sida 8/11


4 Avveckling

Tietos metodik för avveckling bygger på ett antal verktyg, stödfunktioner, processer och tjänster som har sammanfogats till ett sammanhållet koncept. Metodiken förbättras ständigt genom erfarenhetsåtervinning från genomförda projekt.

Tietos avvecklingsmodell, Shut down, bygger på projektstyrningsmodellen PPS. När det gäller avveckling av tjänster för applikationsförvaltning kommer detta att göras som ett delprojekt eller som en separat del i ett delprojekt i den samlade projektorganisationen för hela avvecklingsarbetet. Vilken utformning som väljs beror till största delen på omfattningen och komplexiteten i tjänsteinnehållet för applikationsförvaltningstjänsterna som ska avvecklas. Nedan beskrivs de olika komponenterna i avvecklingsmodellen Shut down.

Processen anpassas beroende på vilken tjänst som ska avvecklas.

Avtalade förutsättningar vid avvecklingFörutsättningar för avvecklingsarbetet är i de flesta fall reglerade i befintlig leverantörs avtal med kunden. Dessutom har kunden tecknat ett nytt avtal med den tillträdande leverantören. Dessa båda avtal utgör basen för hur avvecklingsarbetet ska utformas.

Projektstyrningsmodell PPSAlla våra större uppdrag som avser avveckling bedrivs i projektform. Genom Tietos projektstyrningsmodell PPS erhålls en strikt metodik för att inleda, bedriva och avsluta projekt med olika inriktning och innehåll.

Tietos avvecklingsmodell - Shut down Shut down innebär att med hjälp av Tietos projektstyrningsmodell PPS och för uppdraget berörda ITIL-processer på ett strukturerat och säkert arbetssätt avveckla Tietos uppdrag eller delar av ett uppdrag. Nedan beskrivs aktiviteter i Shut down:

Sida 9/11


I det följande beskrivs de åtta huvudaktiviteterna i Shut down:

Avtal och beställningTill grund för avveckling ligger aktuellt avtal som berör avvecklingen mellan kunden och leverantören. Dessutom kan avtal om tredjepartsprodukter påverka avvecklingsarbetet. Förekommer tredjepartskontrakt bör dessa överföras till kunden eller kundens nya leverantör. Därutöver är det av stor vikt att för leveransen säkerställa att ingående tjänster och gjorda, men inte utförda beställningar. Till detta kommer en från kunden tydligt utformad beställning på avveckling som täcker in berörda parters intressen i samband med avveckling.

Specifika processflödenAktuella tjänster och för dessa tjänster ingående processer och rutiner ska säkerställas. Allt i syfte att ny leverantör ska få information om leveransens innehåll och utformning. Exempel på viktiga flöden är att säkerställa och överföra kunskap och statistik (volym, peak-tider, ärendehantering m m) avseende incidenthantering, förändringshantering, dokumentation, Service Desk, programvaror och licenser.

Maskinell konverteringOm en ny leverantör och kunden är överens om att konvertering av något skäl är ett krav vid avveckling och överlämning till ny leverantör, fastställs detta i avvecklingsprojektet och hanteras i en separat överenskommelse. Om inte specifik överenskommelse träffats avseende konvertering av data, genomförs avveckling till den nya leverantören med så kallad ”as is-överlämning”.

ÖverlämningÖverlämning till ny leverantör beslutas i samråd mellan berörda parter avseende tidplan och förutsättningar. Överlämningen sker i projektform.

Datalager och statistik

Sida 10/11


Data och för leveransen överenskommen statistik överförs till ny leverantör och hanteras inom avvecklingsprojektet. Efter beslut från kunden raderas data, certifikat och dokumentation som använts i de avvecklade tjänsterna/leveranserna.

Hantering av produkterProdukter och system som ska överföras fastställs i samråd mellan kunden och Tieto. Kunden säkerställer att ny leverantör har förutsättningar att ta emot berörda produkter. Tieto samverkar med den nya leverantören i dennes övertagandeprojekt.

Om åtgärder ska utföras i någon produkt innan överföringen, hanteras detta separat och i god tid före avvecklingsprojektets starttidpunkt. Förändringshantering får normalt inte ske under en fastställd ”frysperiod” såvida inte specifik överenskommelse träffats mellan kunden och Tieto.

Ekonomi och faktureringEkonomi och fakturering regleras av gällande avtal. Tillkommande insatser som inte reglerats i befintligt avtal överenskommes separat. Fakturering av befintlig leverans pågår till dess att avvecklingen är klar samt att kunden acceptansgodkänt överföringen.

GenomförandeFör genomförandet fastställs en separat och av berörda parter accepterad avvecklingsplan med tillhörande tidplan. Avvikelser i tidplan på grund av störningar i avvecklingsarbetet hanteras av styrgruppen för projektet.

Sida 11/11

Documents

Inledning · Web viewMetodiken förbättras ständigt genom erfarenhetsåtervinning från genomförda projekt. Tietos avvecklingsmodell, Shut down, bygger på projektstyrningsmodellen