ITIL V3 Foundation - Szolgáltatás Bevezetés

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.

 

A bejegyzés trackback címe:

https://erp-blog.blog.hu/api/trackback/id/tr122163938

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.

Macher Judit

macher_judit.jpg

Magamról

Macher Judit vagyok, a Macher Gépészeti és Elektronikai Zrt. második generációjának tagja. A szüleim által 30 éve indított, bérmunkával foglalkozó Bt-ből mára egy közel 100 főt foglalkoztató integrátori szerepkört is ellátó Zrt. lettünk. Az innovatív megoldásokra való nyitottság mindig is jelen volt cégünk életében, így lettünk Magyarország öt Mintagyárának egyike. Ennek kapcsán számos céggel osztottuk meg a tapasztalatunkat a digitalizációval kapcsolatban, mely során mi is rengeteget tanultunk. Ezzel a bloggal az offline térből az online térbe tesszük át a párbeszédet a legújabb technológiákról (elsősorban az ERP-k területén), és az egymástól való tanulás lehetőségét. Időről időre olyan szakértőket kérek fel tapasztalataik megosztására, akiktől hiszem, hogy sokat tanulhatok, tanulhatunk.

Facebook

Elérhetőség

Ha kapcsolatba szeretnél velem lépni, mert véleményed van, meg akarsz osztani velem valamit, segítségre van szükséged, akkor ne habozz, írj nekem!

macherjudit@gmail.com 

Friss topikok

Kiemelt partnerek

 
logo_white_red_1.png

 prodHost Zrt.
Az okos vállalatirányítási rendszer

 

macher.jpg

MACHER Gépészeti és Elektronikai Zrt.

 

Partnerek

 

 cmo_logo.png

 

  

corvinus-logo-400x280.jpg

 kulcs.png

 hrp_logo_new-1024x552.png

 

 sclogo.png

 

 graphit_logo_1.jpg

Computerworld

Nincs megjeleníthető elem

www.erpblog.hu

Macher Judit vagyok, a Macher Gépészeti és Elektronikai Zrt. második generációjának tagja. A szüleim által 30 éve indított, bérmunkával foglalkozó Bt-ből mára egy közel 100 főt foglalkoztató integrátori szerepkört is ellátó Zrt. lettünk. Az innovatív megoldásokra való nyitottság mindig is jelen volt cégünk életében, így lettünk Magyarország öt Mintagyárának egyike. Ennek kapcsán számos céggel osztottuk meg a tapasztalatunkat a digitalizációval kapcsolatban, mely során mi is rengeteget tanultunk. Ezzel a bloggal az offline térből az online térbe tesszük át a párbeszédet a legújabb technológiákról (elsősorban az ERP-k területén), és az egymástól való tanulás lehetőségét. Időről időre olyan szakértőket kérek fel tapasztalataik megosztására, akiktől hiszem, hogy sokat tanulhatok, tanulhatunk.

Search Clear

[-] mínuszos.hu

Nincs megjeleníthető elem

süti beállítások módosítása