Servicekataloget, en voksen udfordring Om livet, universet og svaret på alt
Introduktion Lidt om taleren Formålet med præsentationen Lidt om case n EnergiMidt A/S opstået gennem fusioner Decentral IT-styring senere samlet i central IT Ca. 700 medarbejdere Ca. 35 medarbejdere i Intern IT (heraf halvdelen i Drift) Ca. 700 servere...
Lidt om mål og strategier Engelsk model Depending on the wind, the striker s position may vary
En italiensk model Iron defense, small ideas in midfield, passes to striker..and Penalty
En franske, analytisk model In their plan, they try all possible hypotesis. Shit! They forgot the goal
En tyrkisk model Note: the red dot is not the ball, it s the referee.
Og sådan kunne vi blive ved længe der er mange måder at sætte en strategi op på. Men.
Som Servicedesk en oplever kampen På en god dag taber vi ikke så stort som ellers..
Så hvorfor Servicekatalog? Skabe overblik over, hvilke tjenester vi skal supportere (Implicit også overblik over, hvad vi IKKE supporterer) Udgangspunkt for at fordele roller og ansvar (hvem tager sig af hvad).
Andre mål med servicekataloget Omdrejningspunkt og grænsesnit mod forretningen (aftaler, understøttede forretningsprocesser, kontaktpersoner ) Indgangsportal til Service Management system Omdrejningspunkt for den tekniske dokumentation. Omdrejningspunkt i transition processen.
Og hvor landede vi så henne Customer Facing Services: 151 (Customer Facing Systems): ca. 100 Supporting Services: 26 Uncategorized: 32 Ingen ejer Ingen aner, hvad den laver, eller hvor den indgår Diskussion om, hvorvidt det skal kaldes en ITservice (ex. support til smartphones)
Indhold Unikt navn Beskrivelse (100 tegn) Status (life-cycle) System Prioritet (Ifht BCM) Understøttede forretningsprocesser Support (hvem giver) Superbrugere (link til liste af) Serviceejer og kontaktperson SLA (ja, nej, vides ikke) Teknisk Serviceejer Kvalitetsikret hvornår Andre aftaler (link)
Første udfordring Skal vi overhovedet organisere os efter services?. Andre måder: Efter infrastrukturdele (fx. netværk, VMWare cluster)? Efter leverandørteknologier (Microsoft, Citrix, ) Efter kunder? Efter projekter? Efter systemer? Efter applikationer?
Forankring af ansvar, næste udfordring Forretningsenheder forgår, men IT-systemer består. Men hvor landede ejerskabet for systemet/servicen lige henne?
Placeringen af det proaktive driftsansvar? ITIL fortæller os, at vi skal udpege serviceejere i forretningen. De ved godt, hvor de vil hen med servicen rent funktionelt, og de skal også nok være der, hvis den er nede. Men hvem sørger for at forebygge driftsproblemer? For at der er styr på backup en, inden der bliver brug for den? For at sikkerheden opretholdes, inden hackeren kommer? Vi mener, at ITIL mangler en rolle og har defineret noget, vi kalder Den tekniske serviceejer. (Evt. den tekniske systemejer ). Det er her, at det proaktive driftsansvar skal forankres efter implementeringsfasen og han/hun bør være med i den sidste del af implementeringsfasen (Transition). Rollen er samtidig SPOC ( Single-Point-of-Contact ) for forretningens serviceejer.
Skillelinjen mellem udvikling og drift ITIL verdensbilledet baserer sig på en lifecycle model, hvor servicen ENTEN er i udvikling ELLER i drift. Dagens iterative udviklingsmodeller, som fx Scrum, udfordrer det verdensbillede og gør det svært at definere en klar skillelinje mellem udvikling og drift. Det betyder også, at systemerne ALDRIG driftsmodnes, og at driften i praksis ikke kan gøre andet end at administrere beskeder til/fra udviklerne. Udviklerne tænker i projekter/sprints, ikke i services. Og dermed udfordres hele ideen om et servicekatalog som omdrejningspunkt for IT-driften.
Værktøjsunderstøttelse Efecte Service management tool? Wiki? (Confluence)?
FLERE SPØRGSMÅL