it SMF

1. itSMF

2. itSMFerfamøde hos BankdataJens Ole Christiansen 20. juni 2012

3. Program for 20. juni 2012 - I • 10.00 Velkommen og dagens program • Projektleder, Service & Support, Jens Ole Christiansen. • 10.10 Bankdata i dag • Hvad vi er og hvad vi fokuserer på lige nu. Underdirektør Rasmus Sørensen. • 10.30 Bankdatas Service & Support koncept • Hvordan vi håndterer det. Afdelingsleder, Basissystemer, Michael Wognsen. • Flere kunder, større mængder, flere deske mv. • Debat om scalering og hastige forandringer. • Pause og networking • 11.15 Koncept og ikke koncept • Om koncept / ikke koncept, ensartethed, standardydelser. Projektleder Jens Ole Christiansen. • Debat om konceptualisering vs. dagligdag. • 12.00 Frokost • Bankdatas kantine.

4. Program for 20. juni 2012 - II • 13.00 Ledelse af ressourcer • I Service Deske og i Produktafdelinger – samarbejde mellem deske, ledelsesgruppen, den fælles linje. Afdelingsleder, Betalingssystemer, Kim Løhde. • Debat om ledelsesopgaven. • 13.45 Overdragelse / Transition • Nye produkter fra udvikling til produktafdeling og support. Afdelingsleder, E-Banking produkter Michael C. Andersen. • Debat om effektiv transition af nye produkter. • Pause og networking • 14.30 Kundesamarbejdet • Hvordan samarbejdet mellem konkurrerende banker foregår i et fællesskab. Projektleder, Service & Support, Jens Ole Christiansen. • Produktråd, Ressortgrupper, Portefølje Management. • Debat om hvor vidt samarbejdet kan drives – hvordan foregår det hos jer? • 15.00 Afrunding

5. Bankdata i dagRasmus Sørensen

6. Bankdatas Service & Support KonceptVækst og andre store forandringerMichael Wognsen

7. Bankdatas Service & Support Koncept • Projektforløbet

8. Bankdatas Service & Support Koncept • Projektforløbet • Ledelsesmæssig opbakning • Projektet bemandet med deltagere frahotlines, der skulle indgå i det nye Service Desk Koncept • Ekstern konsulent, der introducerede ITIL • Ambassadører tilbage til Service Desken • Fokus • Service Management Board • Ledermøde for Service Deske

9. Bankdatas Service & Support Koncept • Projektforløbet • Materialer, uddannelse, orienteringsmøderblev varetaget af projektet selv

10. Bankdatas Service & Support Koncept • Vigtige grundelementer i konceptet

11. Bankdatas Service & Support Koncept • Vigtige grundelementer i konceptet

12. Bankdatas Service & Support Koncept • Service Desk…………fra udsat til værdsat

13. Bankdatas Service & Support Koncept • Ny kunde på Bankdata • Bankdatas koncept og governance harværet en positiv oplevelse for den nye Bank • Bankdata giver kunden tryghed og sikkerhedfor, at vi kan håndtere og servicere dem på en fuld professionel måde • Business as usual i Service Desken

14. Bankdatas Service & Support Koncept • Ny Service Desk Kredit i Silkeborg • Kultur og koncept stiller krav om, at derudspringer en Service Desk fra en beståendeService Desk • Koncept, opfølgning, roller mv. skal læresfra en bestående Service Desk

15. Koncept og ikke konceptJens Ole Christiansen

16. Koncept - og dagligdag • ”Det er udtænkt i et elfenbenstårn”. • ”--- hvad med at se ned til os i den virkelige verden?”. • Det er et møgkoncept ! • Det er et møgsystem ! • Det er noget møg det hele! • Det koncept du’r ikke!

17. 9 skarpe fra brugerne Må jeg så ikke mere kontakte dem jeg kender i Bankdata? Skal jeg så skrive alting ned? Bankdata siger det ikke er en fejl, men det er det altså! Jeg må ikke bestemme prioritet på en Incident (fejl) Nu får jeg får masser af ligegyldige spørgsmål. Hvorfor det? Service Desken ved ikke nok Hvorfor skal der laves om på noget som virkede ok? Bankdata gør det jo ikke alligevel Service-systemet er irriterende…. Selvbetjening er irriterende

18. Koncept - og dagligdag • Koncept • Visitering • Forudsigelighed, faste aftaler / leveringstider • Incidents, Prioritering, Impact, Urgency • Ydelser – Standardydelser ogKonsulentydelser • Rådgivning / hjælp • Arbejdsregler – pending koder • Web/Net, transparens, information, skriftlighed • Produkt, Produktråd • Produktforbedring og RFC • Ikke koncept • Afdelingernes opgavestyring • Service – måden • Den enkelte sag • Faglighed og viden • ”Det er udtænkt i et elfenbenstårn”. • ”--- hvad med at se ned til os i den virkelige verden?”. • Det er et møgkoncept ! • Det er et møgsystem ! • Det er noget møg det hele! • Det koncept du’r ikke!

19. Service & Support Arter af hændelser og leveringstider Service Desk I Bankdata Produktafdeling I Bankdata Bank Hvad det er Leveringstid Der regnes i hele bankdage. Løbende dag plus det viste antal dage (undtagen Incidents prioritet A1) Ydelses- katalog Tid efter prioritet. A1: 3 timer A2:1 dag B1:3 dage B2:10 dage B3:20 dage Incident Fejl i Bankdatas daglige drift Bestilles via Bankdatas Service Shop, som indeholder alle de standardiserede ydelser Bankdata leverer til din bank. Leveringstid er fastlagt for den enkelte ydelse. Bruger kan bede om senere levering. Bruger A Web Standardydelse Visitering Konsulentbistand til individuel analyse, udredning, uddannelse mv. Op til 10 dage til respons. Herefter jf. aftale med kunde. Interaction Konsulentydelse Bruger B Telf, mail Service Request Rådgivning, vejledning og anden hjælp til generelle systemer og services. Op til 3 dage. Senere Levering kan aftales. Rådgivning Løses straks Slut Beslutning efter op til 50 dage. Respons fra Produktråd 10 dage efter møde. Ønsker og forslag til ændring og forbedring systemer og services. Produktforbedring

20. Om Incidents vs. Service Requests Service Requests Incidents • Service Requests er defineret som alt hvad Bankdata tilbyder af services til bankerne, og som ikke er Incidents. • Det indebærer at bankerne kun kan efterspørge Incidents og Service Requests i Bankdata. • Incident betyder i Service & Support: ”en uplanlagt afbrydelse af normal it-service” eller ”reduktion af kvaliteten af it-servicen”. • Dvs. at Incidents kun kan forekomme når der findes ”en normal service”– altså at en service er i ordinær drift.

21. Prioriteten bestemmes af Urgency og Impact 21 Tidsfrister på prioriteter – kernen i SLA Ændringer i denne revision: • Prioriteten A1 ændres fra 2 timer til 3 timer • Prioriteten A2 ændres fra 4 timer til løbende bankdag plus én (dag-til-dag) • Prioriteten B1 ændres fra 5 bankdage til 3 bankdage (plus løbende dag) • Prioriteten B2 ændres ikke, er uændret 10 bankdage (plus løbende dag) • Prioriteten B3 ændres fra 15 bankdage til 20 bankdage (plus løbende dag) Prioritet Impact Urgency

22. Bankdatas NETService & Support Velkommen i rummet

23. Erfaringer man måske kan bruge Store udfordringer med at strukturere processer, tidsfrister, sagsstyring. Stjæl hvad I kan. Vi havde flere standardydelser end vi selv troede. Og de er go’e. Konceptet strukturerer lige så meget på produktsiden som på supportsiden. Gi’ det lidt tid – man skal vænne sig til det. Et spørgsmål om temperament: Hvor meget involvering af medarbejdere?? Service & Support er 80% ”people”, 15% system og 5% x-faktor. Tænk i ”what’s in it for me” for kollegerne.

24. FrokostStarter igen kl. 13.00

25. Ledelse af ressourcerKim Løhde

26. Ledelse af ressourcer Styring af en produktafdeling Struktur Roller Mål Servicedesken Produktteamet • Struktur • S&S koncept • Roller • Teamleder • Serviceleder • Servicekonsulent • Supportkonsulent • Supportudviklere • Mål • SLA tal • Daglige mål • Struktur • Månedsiterationer • Roller • Teamleder • Forretningsanalytikere • Produktkonsulenter • Udviklere • Mål • Månedsmål

27. Ledelse af ressourcer Styring på tværs af organisationen • ServiceManagementBoard (SMB) • Chefgruppen for de områder der har SD • Mødes hver anden måned • SLA tal • Kundetilfredshed • Strategi for Service & Support • Ledergruppen for Service & Support • Afdelingslederne for produktafdelingerne med SD • Mødes en gang hver måned • Opfølgning på SLA tal • Opfølgning på kundetilfredshed • Nyt fra ”Erfa gruppen” og fra ”SMB” • Nye fælles tiltag • Generelle problemstillinger • Alignment • Input til ”ServiceManagementBoard” • Erfa gruppen for Service & Support • Teamlederne for de enkelte servicedesks • Mødes en gang hver måned • Konkrete problemstillinger • Implementering af nye tiltag • Erfaringsudveksling • Input til ”Ledergruppen for S&S”

28. Overdragelse / transition i Udviklingsområde 5Michael C. Andersen Fra Udvikling til Produkt, Service & Support

29. itSMF erfamøde 20.06.12 • Præsentation, 20 – 25 minutter - hvordan vi i UO5 har grebet transition an. I daglig tale kalder vi det for ”overdragelse”! • Noget om: • baggrund • proces • konkrete tiltag • vores erfaring – og læring

30. Baggrund (1)… • Før foråret 2010 sagde vi: • ”Nye systemer er ved overdragelse fra projekt til forvaltning ikke forvaltningsklar • Ringe kvalitet og robusthed kan give bøvl i den daglige forvaltning. Bøvl defineres som brandslukning. Mange fejl og problemer bevirker stort tidsforbrug til fejlsøgning og - rettelse, det er til stor ærgrelse i forvaltningsafdelingen”

31. Baggrund (2)… • Før foråret 2010 sagde vi: • ”Udviklere i en forvaltningsafdeling kan savne faglig udfordring og – udvikling • Fejlsøgning og rettelse af problemer kan være en stor del af udviklerens arbejdsdag (dag ud, dag ind) og det giver ikke just den store faglige udfordring. Udvikleren kan ”stå stille” og det faglige niveau kan endda blive degenereret. Det er til tider problematisk at fastholde – samt tiltrække – fagligt dygtige udviklere til en forvaltningsafdeling”

32. Hva’ skulle der til? • Fortsat fokus på Service & Support konceptet • Få styr på overdragelsen • Vores produkt = vores ansvar

33. Få styr på overdragelse (1)… • Der blev nedsat et projekt som skulle arbejde med: • roller, processer og procedurer for at overdrage viden og dokumentation

34. Få styr på overdragelse (2)… • Projektet blev sammensat af repræsentanter fra Service Desk, produktafdelinger og udviklingsafdelinger • Ultimo 2011 kom projektet i mål med et færdigt koncept • Konceptet ”trykprøves” i UO5, måske mindre justering ellers implementering i hele Bankdata…

35. Få styr på overdragelse (3)… • Langtrukken proces pga. forskellige organisationsændringer. Det har også været svært at finde tiden i dagligdagen, men… • det nytter at holde fokus  • i dag oplever VBS større interesse for at lave gode overdragelse til både Produktafdeling og Service Desk 

36. UO5 i dag… Service Desk for UO5 (Virtuel Bank Service) • Support og produktansvar for: • HOB adminstration • Netbank og Netbank Erhverv • CMS (Tangora) • Netboks • Beskedservice (NFI, Notifikationssystem) • 1203 - Saldoforespørgsel (SMS-løsning) • Netbank aftaler og vilkår (Virtuel Bank Automatisering) (Virtuel Bank Fundament) (Virtuel Bank Udvikling)

37. Support og produktansvar for: • dokumenter - både decentralt og centralt udskrevne dokumenter • de decentrale dokumenter udskriver pengeinstitutterne selv via ASF • de centrale dokumenter udskrives af KMD • eArkiv - Bankdatas elektroniske arkiv UO5 i dag… Support og produktansvar for pengeinstitutternes pengeautomater

38. UO5 i dag… e-Banking sikkerhed – support og produktansvar for sikkerhedsløsninger i Netbanken e-Banking fundament – support og produktansvar for mobile devices

39. UO5 i dag… Support af brugervenlighed, design og usability til brug for resten af Bankdata på tværs af browser og Medarbejderportal

40. Overdragelse… Fredericia Silkeborg

41. Det nye (1)… • Krav til projekter: • tidlig ”overdragelse” • afholde tekniske demo’er • evaluering af overdragelser og – af produktet

42. Det nye (2)… • Der er udarbejdet: • Kvik-guide

43. Det nye (3)… • Der er udarbejdet: • fælles guide-lines og struktur for dokumentation • fælles gemme-struktur i SharePoint

44. ODA – hvaf’for en? (1) • ODA (OverDragelsesAnsvarlig) er en rolle! • ODA skal udpeges i alle produktafdelinger! • ODA’s arbejde er aftalebaseret og strukturen skal i høj grad afspejle produkt verden, ikke projekt verden

45. ODA – hvaf’for en? (2) • ODA: • er projekters indgang til den produktafdeling der skal overdrages til • følger et projekt fra start til slut, herefter slutter ODA’s opgave (og den produktansvarlige tager over)

46. ODA – hvaf’for en? (3) • ODA og overdragelsesaftale: • Overdragelsesaftalen er grundlaget for enhver overdragelse fra projekt til produktafdeling • Overdragelsesaftalen kan dog fraviges efter aftale med ODA • Som supplement til overdragelsesaftalen, arbejder ODA ud fra tjekliste målrettet dennes produktafdeling

47. ODA – hvaf’for en? (4) • ODA og overdragelsesaftale: • Det er ODA som skal sikre, at overdragelsesaftalen kommer i spil ved opstart af projekt og holde den i spil igennem hele projektforløbet • Det er den enkelte projektleders ansvar at oprette og skrive overdragelsesaftalen og holde denne ajour igennem hele projektforløbet!

48. ODA – hvaf’for en? (5) • Vigtige ODA opgaver: • Sikre, at projektet er forberedt og specifik i forbindelse med overdragelsesmøder. Det samme gælder ODA’s afdeling • Fokusere på projektets aktive fravalg og sørge for, at projektet dokumenterer fravalgene

49. Overdragelse i UO5 Slut

50. Debat • Får I lukket udviklingsprojekterne? • Kan I finde jeres dokumentation?