Lite sånt vi redan vet Världen vi lever i förändras allt snabbare

En presentation över ämnet: "Lite sånt vi redan vet Världen vi lever i förändras allt snabbare"— Presentationens avskrift:

1 Lite sånt vi redan vet Världen vi lever i förändras allt snabbare
Verksamheten står inför utmaningar och måste kunna anpassa sig snabbare IT – en del av problemet Denna Powerpoint är endast för internt bruk Får ej spridas. Business faces challenges More turbulent environment Less predictability More competitive More knowledgeable / demanding customers Globalization Business must respond Faster processes More flexibility More productivity / lower costs Better risk management IT måste vara en del av lösningen

2 Situationen enligt Gartner
80% av IT-kostnaderna är relaterade till den operativa nivån 50% av incidenterna återupprepas 60% av projekten levererar ej affärsfördelar 40% av personalen används ej effektivt Den operativa nivån är den som drar mest kostnader. Här finns alltså stor effektiviseringspotential. Hälften av alla incidenter återupprepas…det håller inte Beror på att vi varit teknikstyrda inte behovsstyrda Beror inte på att personalen är medvetet ineffektiva utan på att vi inte klarat ut roll-ansvar-befogenhet dvs processerna

3 Ökad komplexitet… E-Strategi E-handel Organi- sation Externa användare
Användar-admin Kapacitets-planering Arkitektur Verktygs- val Integritet för transaktioner Affärs- processer Personberoende 3e-parts leverans Organi- sation Användar- profiler Prioritera IT-tjänster Användares behov E-post Fjärr- support Mjukvaru- distribution Kontors- verktyg Klient- mjukvara Helpdesk Externa användare Ökad komplexitet… Domän- hantering Kapacitet Redundans Hem- arbete Datalagring Navigation Varumärkes- hantering Närvaro Standarder Översättning Content Mgmt WEB Virus- skydd Policies Bandbredd Dokument- hantering Brandväggar Utformning Topologi Övervakning Desktop Nätverk, infrastruktur Hårdvara

4 Ökade krav Tillgänglighet Prestanda Högre värde av IT-tjänsterna

5 IT-tjänsterna måste svara upp till detta!
Mål Höja kvaliteten Minska kostnaderna Öka flexibilitet (minskad tid, risk) Hur gör vi för att lyckas ? Införa strukturerade processer Förenkla processerna Öka automatisering Använda duktiga människor Quality – Reliability, availability and security Process, simplified and automated lead to using fewer, better-skilled and better supported people – reduce costs

6 ITIL – IT Infrastructure Library
Generiskt ramverk Best practise Processer för att leverera IT-tjänster Tydliga roller, ansvar De facto och ISO-standard Stort stöd tals användare

7 Incidenter från användare
Operativa processer Incidenter från användare IT Drift Larm Service Desk Incident Management Problem Management Configuration Management RFC RFC Release Management Change Management

8 Taktiska processer (Framtida) affärsbehov
Kunder (Framtida) affärsbehov Financial Management for IT Services Service Level Management Mätning & Mål Capacity Management Availability Management IT Service Continuity Management Rapporter, larm & avvikelser

9 Service Deskens organisation
Kunder/användare IT-avdelningen Service Desk Specialister Leverantörer First line Koordinator Second line En användare genererar i genomsnitt 7 ärenden/år. (4 incidenter 3 RFC) 1000 anv= 7000 ärenden = ca 30 ärenden om dagen. Har man färre ärenden så är det inte ett tecken på att man är bra. Snarare att det finns ett flöde vid sidan av servicedesk En person i Servicedesk kan serva anv. Om man är uppe på 1000 anv så blir det enbart ett callcenter inte en SD. First line= de som sitter och tar emot tfnsamtal, bevakar web, mail osv. OBS de som sitter i first line bör helst vara en trebarnsmor som arbetar på halvtid den sociala kompetensen viktigast -van vid konfliktlösning -kan ha flera järn i elden samtidigt -bränner inte ut sig på kort tid. Second line= tillhör också SD organisationen men sitter inte i first line. Jobbar istället med ärenden som SD har ansvaret för men som man inte lyckats lösa vid första kundkontakten. First line och second line= SD Personalen roterar mellan first och second line. En person bör inte sitta mer än 6 fyratimmarspass i first line. För att öka samarbetet med IT-avdelningen så kan personal ur IT-avdelningens övriga organisation tjänstgöra ibland i second line. Koordinator ”stridsledningsofficer” den som följer, eskalerar fördelar uppgifter osv i SD. Skall alltid finnas. Skall inte vara personberoende utan en roll som roterar mellan SD-personalen. Koordinatorn är nyckelpersonen. Kommunicerar med third och foruth line samt användarna om incidenter inte hinner åtgärdas inom bedömd tid. Third line= IT organisationen. Indelad i olika kompetens/ansvarsgrupper till vilka ärenden skickas beroende på ärendeklass och om SD inte har som uppgift att lösa dem eller inte kan alternativt hinner med. Foruth line= Leverantörer m.m. utanför den egna organsiationen. Övningsuppgift: Hur många kunder/användare har Ni? Hur många ärenden per dag (x7/350) Hur lång tid tar det i genomsnitt att lösa ett ärende? Hur många ärenden är öppna i genomsnitt varje dag? Third line Fourth line

10 Incident Management Fokus: Återställ till normal funktion av tjänsten snarast möjligt Återställer till tjänstens normalläge snarast möjligt, genom ”work around”, rättning, åtgärd, kunskap Minimera effekter för verksamheten Proaktivt identifiera förbättringar för verksamheten Minimera risker för förlorade incidenter/ärenden Betona följande: Definitionen Minimera effekterna för verksamheten (oftast genom workaround) Exempel koppla om användaren till en annan skrivare om man inte kan skriva ut på den oridinarie. (Incidenten åtgärdad däremot inte problemet) Definition av incident: ”Alla händelser som avviker från normal funktion av en tjänst och som orsakar eller kan orsaka ett avbrott i eller störning av tjänsten.”

11 Problem Management Fokus: Identifiera orsaken till incidenter och skapa en lösning Minimera effekter för verksamheten av incidenter och problem Förhindra att samma fel (incidenter) återkommer Skapa lösningar på problem Uppdatera ”Known Errors”/kunskapsdatabas Known Error = Ett problem för vilket orsaken fastställts och en permanent eller temporär lösning tagits fram Proaktivt identifiera möjliga (troliga) framtida problem och lösningsförslag för att förekomma Betona definitionen. Underhåller kunskapsdatabasen Definition av problem: ”Den underliggande orsaken till en eller flera incidenter.”

12 Change Management Skapa standardmetoder för att hantera förändringar
Fokus: Säkerställa att beslutade metoder och rutiner används för att hantera alla ändringar med syfte att minimera incidenter som följd av ändringar Skapa standardmetoder för att hantera förändringar Beslut om ändringar ska fattas av behörig Minimera antal och betydelsen av incidenter orsakade av förändringar RFC kan komma från problem, kund, omvärldsbevakning… En RFC (Request for Change) kategoriseras och beslut kan fattas på olika nivåer. Många beslut fattas av Change Advisory Board – en tillsatt grupp som behandlar större förändringar

13 Release Management Release Management används för
Fokus: Genomföra utrullningar av mjuk- och hårdvara Release Management används för större eller viktigare hårdvaruutrullningar större mjukvarutrullningar paketering av flera ändringar Skapar och kontrollerar installationsprocedurer Genomför korrekta, testade och auktoriserade förändringar enligt en Release Policy Underhåller ”bibliotek” med godkända programvaror Mall att använda och jämföra med i övriga processer Release Management är den process som verkställer beslutade förändringar. Release Management svarar för planläggningen av införandet och tester sett i ett större sammanhang innan genomförandet verkställes. Liknelse: Antag att Du skadat huvudet, bröstet och benen i en bilolycka. Man konstaterar att Du måste opereras i samtliga fall. Release Management är den som bestämmer i vilken ordning och hur många dagar det skall gå mellan operationerna för att du skall klara av det hela. Release: auktoriserad förändring av mjuk- och/eller hårdvara Versionshantering ett nyckelbegrepp

14 Microsoft Operations Framework
Process-modell Organisations-modell Risk-modell Referens-arkitektur

15 MOF - omfattning Strukturer att bemöta komplexitet
Processmodell Situation Behov Lösning Ökad komplexitet inom IT Anspänningar pga olika fokus Mekanism att hantera spänningar Organisationsmodell Process Model: Strong disciplined processes to meet the business objectives Team Model: Handle multiple objectives simultaneously Risk Model: Live with risks Ökat beroende av tillgänglighet till IT Inbyggd, proaktiv riskhantering Riskmodell

16 MOF Innehåll Processmodell Organisationsmodell Riskmodell
Föreskrivande innehåll ITILs grundprocesser + tillägg / komplettering Tydligare granskningsanvisningar Organisationsmodell Roller och ansvar Riskmodell Riskhantering som en naturlig del av alla processer Process Model Focuses on guidance that is prescriptive versus descriptive Adds prescriptive content to ITIL-defined processes Adapts ITIL core processes and others as SMFs Places all service management functions on a single diagram that simultaneously: Allows operations practitioners to better understand and manage Shows concurrent operational activity Associates explicit review activities with the model Team Model ITIL defines roles, but not IT operations functional roles Embedded Risk Model Ongoing risk management

17 MOFs Riskhantering Varje processägare måste:
Identifiera potentiella risker Utvärdera sannolikheten av risken Planera aktiviteter för att minska eller eliminera risken Förstå konsekvensen / sårbarheten av risken Planera för att mildra kvarvarande risker Identifiera indikatorer för övervakning och att initiera plan för att hantera konsekvens

18 Riskhantering

19 MOF Continuous Improvement Roadmap
När är vi framme? Var är vi nu? Hur kommer vi dit? Var vill vi vara?

20 Infrastructure Optimization
IT personal upptagna med eldsläckning Användare skapar egna lösningar IT personal utbildade i best practice, exvis MOF, ITIL, etc. Användare vill ha grundläggande IT-tjänster IT personalen hanterar effektiva, kontrollerade miljöer Användare har de rätt verktyg, hög tillgänglig-het och tillgång till info IT är en strategisk resurs Användare ser IT som en partner och katalysator för affärsprocesser IT processer ej definierade Hög komplexitet pga dåliga processer och minimal central kontroll Central administration av säkerhet Standardarbetsplats används, dock ej genomgående SLA kopplade till affärsbehov Tydliga och genomgående använda standarder, säkerhet, processer (MOF, ITIL) Ständig förbättring en del av kulturen Information lättåtkomlig och säker överallt Versioner och release-status på PC okänd Ingen gemensam struktur för åtkomst Flera katalogtjänster för autentisering Viss automation för distribution av program Automatisk identitets- och tillgångshantering Automatiserad system management Självbetjäning och karantänzoner används av systemen för att säkerställa efterlevnad och hög tillgänglighet