Az előző ITIL témájú cikkekben szó volt az ITIL kialakulásáról valamint a stratégia megalkotásáról és a tervek felvázolásáról. Most lépjünk tovább. A következő téma magának az informatikai szolgáltatásnak a bevezetése (ami lehet egy ERP rendszer, vagy egy egyszerűbb dobozos termék, esetleg egy új internet előfizetés aktiválása az ügyfélnél, rendszerintegrációs projekt, egyszóval bármi). A fő cél, hogy olyan szolgáltatás bevezetés történjen, ami kielégíti az üzleti igényeket. Ezt úgy valósítja meg a módszertan, hogy a tervezés minden adatát átveszi és felhasználja a bevezetés során, hogy utána a következő fázisban a működtetés során minden megfelelően működjön.

A mai cikkben a következő részelemekre fogjuk felbontani a Szolgáltatás Bevezetést (Service Transition):

1. Szolgáltatási eszköz és konfiguráció menedzsment
2. Változáskezelés
3. Kiadás és üzembe állítás menedzsment
4. Ismeretmenedzsment
5. Szolgáltatás validálás és tesztelés

A Szolgáltatás Bevezetés céljai:

• Megfelelni az ügyfél elvárásoknak
• Megfelelni a hatóság elvárásainak (Apeh, Pszáf)
• Ismert hibák csökkentése
• Kockázat minimalizálása
• Költség, minőség, idő szem előtt tartása
• Szolgáltatások gördülékeny bevezetése
• Tervezés, tesztelés, implementálás

1.       Szolgáltatási eszköz és konfiguráció menedzsment (Service Asset and Configuration Management):

Informatikai termékeknél szükséges egy hely ahol az összes informatikai szolgáltatás leírása szerepel, ez volt a Szolgáltatás Katalógus, viszont szükséges egy olyan adatbázis is, ahol a szolgáltatásokhoz kapcsolódó eszközök, szoftverek, leírások, szerződések megtalálhatóak, ez az ún. CMDB, azaz a Konfiguráció Menedzsment adatbázis (Configuration Management Database).

Ez egy olyan adatbázis, ahol a szolgáltatásban részt vevő elemek állapotát, életciklusát és kapcsolatát is meg lehet tekinteni. Azonosíthatóak, ellenőrizhetőek az adatbázis egyes elemei (CI – Konfiguráicós elem). Ezt az adatbázist pedig az ún. CMS (Configuration Management System), azaz a Konfigurációs Menedzsment rendszer működteti.

A CMDB egy lehetséges tartalma:

• Eszközök (hardverek)
• Szoftverek
• Hol található az adott eszköz
• Milyen verzió van az adott helyen
• Kapcsolódó szerződések
• Kiadott árajánlatok
• Költségek
• Incidensek
• Dokumentumok
• Rendelkezésre állások
• Engedélyek
• Felhasználók, stb.

2.       Változás kezelés menedzsment (Change Management):

A Változás menedzsment célja, hogy minden változtatás a bevezetés során rögzítésre kerüljön, minden változtatási igény megfelelően legyen kezelve, értékelve, ha kell ellenőrizve és jóváhagyva. Fontos, hogy egy olyan sztenderdizáld módszer 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.

 A változáskezelés alapkérdései, azaz a 7R (ezek az angol terminológiából jönnek):

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)

A változtatás kérésnek van egy „hivatalos formája” ez az ún. RFC (request for change), a hivatalos pusztán 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

Fontos: egy ilyen RFC nem összekeverendő a hibabejelentéssel, ami majd a bevezetést követően a napi működés során merül fel.

3.       Kiadás és üzembeállítás menedzsment (Release and Deployment Management):

Akik nagyobb multinacionális vállalatnál dolgoznak azok biztosan találkoztak azzal a személlyel, aki az ún. Kiadás menedzser. Ez a személy felel azért, hogy a cégen belül mindig megfelelő verzió számú (kipróbált, lehetőleg hibamentes) szoftverek fussanak, valamint megfelelő legyen a hardver állomány. Ezek az adatok természetesen a CMDB-ben vannak tárolva és kezelve.

A kiadás menedzsment célja:

• átfogó képet alkotni az IT folyamatokról
• szolgáltatások hatékony használatának biztosítása
• a hardver és szoftver komponenesek tervezésének, elkészítésének, tesztelésének, implementálásának támogatása
• jogtisztaság biztosítása
• üzembe állítási terv készítése
• kiadási csomagok konzisztenciájának, kompatibilitásának biztosítása (pl. frissítésekkor, Windows update)
• hatékony üzemeltetés

A kiadás menedzsment hatásköre kiterjed a szoftverekre, használati jogokra, hardverekre, dokumentációkra és a képzésekre is.

De mi is az a kiadás? Mit jelent ez a szó? 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. Mindig 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.

4.       Ismeret menedzsment (Service Knowledge Management):

Az ismeret menedzsment lényege, hogy a megfelelő személy megfelelő tudással rendelkezzen, a megfelelő időben, amikor a szolgáltatást nyújtani kell. A féltudás nem tudás!

Az alábbi képben minden benne van:

Vajon melyik a jobb? Ha valaki tudja, hog hogyan kell megoldani egy feladatot pl. Excelben vagy az, aki tudja, hogy hol kell megnézni, hogy hogyan lehet megoldani a feladatot (pl. súgó)?

5.       Szolgáltatás validálás és tesztelés (Service Validation and Testing Management):

Minden bevezetéskor szükséges a megfelelő tesztelés. De ahhoz, hogy megfelelően lehessen tesztelni szükséges a szolgáltatás pontos megértése, hogy mit és hogyan is kell tesztelni.Akár vásárolt vagy saját készítésű egy termék akkor is szükséges a tesztelés. A cél, hogy objektív bizonyítékunk legyen arra, hogy egy új bevezetés megfelel az üzleti igényeknek, pl. az SLA-nak.