SZOLGÁLTATÁSMENEDZSMENT 4. előadás: ITIL V3 / Service Transition I. 1

SERVICE TRANSITION Szolgáltatás-létesítés és -változtatás (Service Transition) A megtervezett szolgáltatás létesítéséhez és a környezet módosításához szükséges folyamatok leírása. Fontos fejezetek a Change Management Projektmanagement (Transition Planning and Support) Release und Deployment Management Service Validation and Testing Application Development and -Customizing Service Asset and Configuration Management Knowledge Management 2

SERVICE TRANSITION 3

MA TÁRGYALT RÉSZEK Change Management Projekt management (Transition Planning and Support) Release índ Deployment Management Service-Validierung und -Test (Service Validation and Testing) Application development und -Customizing Service Asset índ Configuration Management Knowledge Management 4

Change Management A Változás menedzsment célja: - változtatások a bevezetés során rögzítésre kerüljenek, - minden változtatási igény megfelelően legyen kezelve: értékelve / kell ellenőrizve és jóváhagyva. Egy olyan eljárásrend kerüljön kialakításra, amellyel bármilyen változtatást meg lehet oldani, ha szükséges. A változtatás egyébként bármi lehet, módosítás, bármilyen új elem felvétele, új elem törlése. Illetve a változtatás kapcsolatos lehet bármivel, egy rendszerrel, egy jogosultsággal, egy szolgáltatás részelemével, egy hardver egységgel, vagy akár a dokumentációval. 5

Change Management (2): A változáskezelés alapkérdései (7R-modell): 1. Ki indította a változtatást? (raised) 2. Változtatás oka (reason) 3. Mit vár a változtatásoktól az illető? (return) 4. Kockázatok (risk) 5. Erőforrások (resources) 6. Felelősök (responsible) 7. Kapcsolatok relationship)

Change Management Adminisztráció A változtatás kérésnek van egy „hivatalos formája” ez az ún. RFC (request for change). Ez azt jelenti, hogy kell ilyennek lenni, enélkül nem lehet változtatást eszközölni. A változtatásokat pedig mindig több munkatárs közösen hagyja jóvá (CAB – Change Advisory Board), akik vizsgálják a változtatások típusát is: * sztenderd változtatás: alacsony kockázatú változtatások, amelyek már valamilyen szinten jóvá vannak hagyva * sürgős változtatás: általában valamilyen hibás működést javítanak ki, vagy olyan hatást, aminek nagy negatív hatása lenne az egész szervezetre Az RFC nem azonos a hibabejelentéssel, ami majd a bevezetést követően a napi működés során használnak. https://docs.google.com/fileview?id=0B3PBkTnUCM UeOGFkYzQxZTQtNzBhZi00NmM4LTlkN2UtYzE5OT QyNmJlMDc1&hl=en 7

Fontosabb mérőszámok (KPI) Lényegesebb változások időszakra. (Érdemes dinamikusan mérni!) Változtatásokkal kapcsolatos meetingek száma ( Hatékonyság / idő!) RFC-k átfutásának ideje RFC elfogadásának mértéke Sürgős változtatások absz. / rel. mértéke

ITIL Transition Planning and Support Nem teljes PM; (PMBOK, illetve Prince2) Bevezetés tervezés és -támogatás; azaz projekt megvalósul („prototípus”), azt be kell vezetni Gyakorlati egy terv, kifejezetten (szolg.) a bevezetésre Ez lehet „soft” és „hard” értelmű is ITILV3 ezen alfolyamata ezt a bevezetést tervezi meg és allokál erőforrást Projekteken átnyúló sok esetben!

ITIL Transition Planning and Support: RACI Modell RACI=Responsible, accountible, Consulting, informed - Több helyen használják (COBIT), illetékességi körök elhatárolására jó

ITIL Transition Planning and Support: Logikai modell A Bevezetési terveket négy irányból érdemes vizsgálni: 1./ Milyen folyamatok érintettek? 2./ Kik (emberek) érintettek? 3./ Milyen technológiai háttér érintett? 4./ Hogyan kapcsolódik a szervezeti struktúrához?

ITIL Transition Planning and Support: KPI-k Projektek száma Projektek alkalmazkodása az időtervekhez Projektek alkalmazkodása a ktsvetéshez Az egyes projektek különböző kiadásainak (Relase) száma

Kiadás és üzembe állítás menedzsment A kiadás „jóváhagyott változtatások gyűjteménye, amelyeket együtt tesztelnek, együtt vezetnek be”. A kiadást mindig egy változtatási kérelem előzi meg, azaz egy RFC. Biztosítani kell a visszaállíthatóságot, azaz egy kiadás (update, frissítés, bármilyen változtatás) után vissza kell tudni állni az eredeti állapotra.Érdemes még megemlíteni, hogy többféle kiadási típus létezik: * Teljes kiadás (Full release), amikor valamilyen funkció teljesen megváltozik. Például kijön az új Windows operációs rendszer. * Csomag kiadás (Package release): Például kijön az új service pack a Windowshoz. * Nagy mértékű kiadás (Major release): Számos új funkció kerül beépítésre, esetleg hardver bővítéssel is jár. * Kis mértékű kiadás (Minor release): Csak néhány új funkció kerül beépítésre. * Sürgős kiadás, javítócsomag (Emergency release): Klasszikus javítócsomagokra kell gondolni, ami egy hibás funkció működését javítja és tartósan beépül.

Relase and Support: alfolyamatok Release Management Support: Irányelvek, és terméktámogatások nagyobb Relasekhez Minor Release Deployment Release Build: Kezeli a relase működéséhez szükséges munkaigény, beszerzési kényszert Release Deployment: Relase Live környezetbe való illesztését menedzseli. (Pl.: Dokumentáció, és végfelhasználók felkészítése, terméktámogatás) Early Life Support: Operatív problémák kezelése a kezdettők (initial) a bevezetéséig Release Closure:adminisztratív lezárás http://www.rallydev.com/agile_products/integrati ons/product_management/

Relase and Support: KPI → Relase-k száma → Nagyobb deplymentek telepítésének ideje → szükségessé váltVerzió-visszalépések” száma → Automatikusan telepített deploy-ok száma

SERVICE Validate and Testing -Cél: arról meggyőződni, hogy → a kifejlesztett szolgáltatás → a hozzá kapcsolódó főbb relase-ek → és az IT háttér Keresztül ment egy minőségbiztosítás folyamaton, illetve készen áll az éles környezetben való működésre.

TESTING Test Model Definition: meghatározzuk, hogyan lesz a relase tesztelve és minőségbiztosítva. Részletes teszt-terv teszt esetekre bontva. Service Design Validation: meghatározzuk azokat a kritériumokat, amelyeknek értelmében az IT szolgáltatásoknak funkcionalitásban és minőségben illeszkednie kell Process Objective: To ensure that an IT service meets its functionality and quality requirements and that the service provider is ready to operate the new service when it has been deployed. Release Component Acquisition Release Test Service Acceptance Testing

TESTING http://www.iit.uni- miskolc.hu/iitweb/export/sites/default/users/ficso rl/Targyak/Infterv/Segedletek/03.tesztfogalmakh and.pdf http://istqb.hu/ http://en.wikipedia.org/wiki/International_Software _Testing_Qualifications_Board

Köszönöm a figyelmet! 19