Servicedesk bevezetés tapasztalatai Nagy Gábor
Bevezetés előtti helyzet, kiinduló állapot Szervezet: 4 megoldó csoport, 40 fő megoldó, 20 sap 10 kliens 5 alkalmazás 5 szerver hálózat, területileg széttagolt 7 fő területi informatikus 50-150 közötti bejelentés szám / 1400 felhasználó 5*8 nyitva tartás manuális kiosztás OneOrZero MySQL, PHP alapú free szoftver 2005.11-2011.09 Csak telefonos és email alapú bejelentés, 1 kezelő rögzítette Csak incidenseket kezelt, nem létezett felhasználói felület, státuszt nem tudták követni Primitív riportolás, nem létezett támogatás, nem integrált Papír alapú eszköz, jogosultság és fejlesztés igénylési rendszer Teljesen Microsoft alapú architectúra (System Center, stb.)
Probléma: Nincs szolgáltatás katalógus Ellenállás a mérhetőség, kontrollálhatóság miatt megnövekedett adminisztráció miatt. Felhasználók megkerülik a bejelentési csatornákat Erőforrás hiány 2
Sense of urgency IT oldalon ITIL módszertan hatása v2
ITaaS
Üzleti szolgáltatás-üzleti folyamatok-IT szolgáltatás-IT folyamatok IT mint szolgáltatás (hasznosság, garancia) értéket teremt (gyorsabb, költséghatékonyabb üzleti folyamat)
rendelkezésre áll Szolgáltatások és komponensek számának növekedése (szerverek száma 270) Az IT arca: a jó servicedesk egy rosszul működő IT-ről is mutathat jó képet. Sok felhasználó számára az IT = servicedesk (hiszen egykapus) Felhasználói oldalon Gyorsabb reagálás, megoldás Bejelentések, igények követhetősége Folyamatok: incidens, probléma , esemény, hozzáférés kezelés, felhasználói kérések teljesítése, változáskezelés ->servicedesk
3
4
Kitűzött célok Felhasználói elégedettség növelése (bejelentések követése) Online webes bejelentés, önkiszolgálás preferálása, telefonos visszaszorítása, telefon integráció (IVR) nem cél Minél kevesebb felesleges, de elégséges adatot kelljen rögzíteni Magyar nyelvű felület Egykapus legyen (informális csatornák visszaszorítása, eszköz-jogosultság igénylés, minden bejelentés rögzítésre kerüljön)
Támogassa az incidens, problémakezelést, felhasználói kérések kiszolgálását Tevékenységek mérhetőségének biztosítása (SLA) Felhasznált erőforrások nyomon követése Kezelői beavatkozás nélkül, bejelentési kategóriák alapján kerüljön megoldó csoporthoz 5
Kitűzött célok Megoldó csoportok az incidenseket könnyen átlássák. Támogassa a tömeges hibák kezelését Szolgáltatás katalógus kialakítását segítse Nyújtson információkat az egyes alkalmazásokkal kapcsolatos hibák mennyiségét illetően Integrálható legyen a jelenlegi System Center környezetbe Integrálódjon a jelenlegi Office communicátor, Lync rendszerbe
Segítse a tudásbázis felépítését Belső elfogadottság kialakítása Felső vezetői támogatás elnyerése, (folyamatok megváltozása igényli)
Legyen gyorsan bevezethető (quick win)
6
Servicedesk Ütemterv: 2011.01 interjúzás, felhasználói és megoldói, vezetői igények felmérése, koncepcionális tervezés 2011.02 architectúra kiépítése, integráció 2012.03 incidens kezelési funkció kialakítása, nézetek, end user felület 2012.04 SAP változáskezelési és alkalmazás jogosultság igénylési folyamatok leképezése
2012.05 eszköz és hozzáférés igénylési folyamatok megvalósítása 2012.06
tesztelés, finomítás
2012.07.01
éles indulás pilot
2012.08.01
Teljes kiterjesztés
Architectúra: éles (1 sql, 3 guest) és teszt-fejlesztői (1 fizikai, 5 guest) rendszer Kritikus feladatok: bejelentői felület magyarítása és kialakítása Igénylési folyamatok kialakítása Pilot:földrajzi terület alapú kiterjesztés
7
Demo
8
Eszközigénylés
9
Jóváhagyás
10
Sikerek Online bejelentések preferálása 11672-ból 84% portal, 2,6% telefon, 12% konzol Servicedesk kezelők terheltsége csökkent Jelenleg 1 SAP-os, 1 infrás kezelő A portál használatát megszokták a felhasználók, pozitív visszajelzéseket kaptunk Bejelentési kategória alapján kerül megoldó csoporthoz (szolgáltatáshoz rendelése a megoldó feladata) Legfontosabb, jóváhagyást igénylő folyamatok megvalósítása
11
Mi nem vált be? Sok nézet kialakítása (néhány nézet és szűrés) Automatikus meghibásodás rögzítés SCOM-mal connectoron keresztül működne (SMS ) Email a megoldóknak, megoldó csoportoknak (Több szempont alapján szűrhetőek a nyitott és megoldott esetek) Excel alapú riportok (csak néhány jól megválasztott mutatóra van szükség) Megoldásra fordított idő mérése Minden egyedi fejlesztést kerüljünk, univerzális megoldásokat használjunk.
12
Fejlesztendő Kihívások: Ne kerüljék meg a servicedesket (vezetők – VIP, informatikusok, projektek, kritikus incidensek) Tudásbázis felépítése (a folyamat, motiváció nincs kidolgozva) Megfelelő folyamatok kialakítása (magas prioritású esetek, eszkaláció) SLA alapú jelentések (reagálási, elhárítási idők) Szolgáltatások-incidensek-configurációs elemek- összerendelése Felső vezetői támogatás (bevezetés, riportolás) Támogatók, külső support cégek saját servicedesk alkalmazása A felhasználó számára mindegy hogy ki, mikor, mivel, amit nekünk kell mögé tennünk People – oktatás, beszéljünk egy nyelvet, bevonni a tervezésbe és bevezetésbe, megnyerni Process – mérhető, dokumentált,tulajdonos, felelős, kontrollált
Product – segít, csak eszköz, folyamat fontosabb Partners – Kersoft (Köszönjük )
13
Mi hiányzik Print screen-t nem lehet csatolni egy lépésben. Knowledge management megvalósítása nem felhasználó barát, nincs teljes szöveges keresés. Felhasználó által nem lehet saját nézeteket definiálni A incidens, igény managementen kívüli folyamatok kialakítása nehézkes (heti, havi feladatlisták, ütem tervek hiányoznak ) Outlook naptár, feladatok szinkronizáció. Sharepoint csoport naptára és faladat kiosztási lehetősége, OneNote rugalmas jegyzetelési lehetőségei
14
ITIL szerint….
Szolgáltatás fejlesztés lépései 1. lépés: Visió, stratégia, célok meghatározása (mire van szüksége az üzletnek?) 2. Határozzuk meg mit fogunk mérni. (mit kellene, mit lehet , a végfelhasználó szemszögéből, hol vagyunk, hová akarunk eljutni) 3. Adatok összegyűjtése 4. Adatok feldolgozása 5. Adatok értelmezése (ha csökken a bejelentések száma..) 6. Információ megosztása az érdekeltekkel (riporting) 7. Implementáció, fejlesztés megvalósítása 15
You Can't Manage What You Don't Measure
Köszönöm a figyelmet!
16
