System ticketowy dla helpdesk

Ostatnio opisywałem jak audyt wewnętrzny może pomóc w poprawieniu jakości pracy działu IT. Dziś kolejny sposób na kontrolę jakości IT. Będziemy mówić o najlepszym sposobie na rozliczanie oraz zapanowanie nad pracą informatyków jakim jest odpowiedni system helpdeskowy. Inaczej zwanym jako „system ticketowy” lub „system service desk”. Dziś o nim mowa!

Zapanuj nad IT

“ System ticketowy ” jest częścią cyklu artykułów poświęconych kontroli jakości w IT. Wcześniejsze materiały znajdziesz tu:

Kontrola jakości w IT – Zweryfikuj prace informatyka
SLA w IT
Dokumentacja informatyczna
Zarządzanie zasobami informatycznymi
Zarządzanie ryzykiem
Audyt wewnętrzny działu IT

Prawdopodobnie każdy zarządzający działem IT staje w pewnym momencie przed dylematem mierzenia skuteczności oraz wyników swojego zespołu. Jak wiadomo ludzie pracujący w nowych technologiach to często osoby o wysokiej inteligencji oraz doświadczeniu. Niestety, także czasami zbyt pewni siebie oraz posiadający ego wystrzelone w kosmos.

Czasy nieśmiałych chłopaków siedzących w piwnicy firmy to jedynie stereotypy odwołujące się do dawnych czasów, gdy informatyk był człowiekiem wiecznie wpatrzonym w monitor. Chodzącym we flanelowej kozuli i pozbawionych innych pasji poza komputerami. Obecnie człowiek pracujący w branży IT to osoba dobrze zarabiająca i jednocześnie potrafiący o siebie zadbać. Po godzinach pracy woli poświecić czas na swoje hobby. Jak choćby taniec lub nurkowanie niż konfigurowanie serwerów klienta. Człowiek ten zdaje sobie sprawę, iż jest na niego zapotrzebowanie na ryku pracy i nie boi się powiedzieć „nie” swojemu szefowi. Szczególnie gdy posiada wąską specjalizację. I jednocześnie zdaje sobie sprawę, że w zagadnieniach technicznych to on jest górą nad kierownictwem.

Monitoring… informatyka

Jak w takim razie radzić sobie z kontrolą jakości i sprawić by nasz dział IT spełniał swoje zadania według najwyższych standardów? Z pomocą przychodzi nam… informatyka. Nowoczesne praktyki zarządzania IT pozwalają w sposób mierzalny sprawdzić jak swoją pracę wykonują nasi podwładni.

Pierwszym, niezwykle pomocny narzędziem jest system monitoringu. Ci co mnie znają – wiedzą, że system monitoringu sieci informatycznej jest mi niezwykle bliski. Promuję to narzędzie od dawna. Często piszę o nim na blogu, a nawet wydałem „Podręcznik Administratora Systemu Monitorowania Zabbix”. W 2015 roku moja firma pozyskała nagrodę „Innowacja Roku ” Produkt/Usługa Roku IT 2015 r. Właśnie za nowoczesne podejście do monitoringu informatyki u naszych klientów.

Nie muszę wiec chyba dodawać, iż ten aspekt jest dla mnie niezwykle ważny. W skrócie, jest to narzędzie, które pozwala nam na bieżąco otrzymywać powiadomienia o problemach wewnątrz naszej sieci informatycznej. Nie działa aplikacja, strona internetowa czy po prostu kończy się miejsce na dysku serwera? Monitoring ma za zadania nas o tym poinformować.

Pozostaje kwestia jak wykorzystać tą aplikację do mierzenia jakości pracy działu IT? Z pomocą przychodzą tu dwie funkcjonalności.
Pierwszym jest samo alarmowanie o problemach w obrębie infrastruktury informatycznej. W momencie gdy informatyk otrzymuje wiadomość email z systemu o tym, iż nie działa serwer, nie może już się tłumaczyć, że nie wiedział, bo nikt mu nie dał znać. Obowiązkiem osoby, która ma za zadanie czuwać nad monitoringiem jest wykonanie odpowiedniej reakcji na wydarzenie…

Dodatkowo, aby upewnić się, ze dział IT na bieżąco śledzi stan systemu monitorującego warto postawić duży telewizor w pokoju informatyków. Coś nie działa, a na ekranie pojawia się odpowiedni komunikat z sygnałem dźwiękowym.

SLA

Ponadto, system monitoringu pozwala nam śledzić poziom wykonania SLA. A ten ma często dosyć kluczowe znaczenie. Czym jest SLA? Z angielskiego jest to to tzw. Service Level Agreement. W skrócie, pozwala skontrolować w jakim czasie konkretna awaria powinna zostać usunięta. Natomiast system monitoringu pozwala na weryfikację jego wykonania. Przykładowo w SLA mamy zapis, iż konkretna awaria musi zostać usunięta po czterech godzinach od pojawienia. Tymczasem monitoring pokazuje, iż trwało to dłużej. Dzięki ewidentnemu dowodowi wiemy już, że coś w naszym zespole nie zadziałało poprawnie. Należy wtedy porozmawiać z ekipą i wyjaśnić sytuację.

Kontrolę nad SLA ułatwia również system ticketowy. Tak potocznie mówi się na aplikację do zarządzania zgłoszeniami (czyli tzw. ticketami wysyłanymi do działu IT). Dotyczą one wszelkiego rodzaju awarii i problemów. Dzięki odpowiednio zaprojektowanemu i skonfigurowanemu systemowi ticketowemu możliwe jest rozliczanie czasu dostępnego i wykorzystywanemu na realizację zgłoszenia.

Informatycy żonglujący zgłoszeniem

Przykładowo, w mniejszej organizacji gdy zgłoszenie zostanie przypisane do konkretnego informatyka, ma on konkretny czas na realizację zadania. W większych już bywa trochę inaczej. Niestety, z reguły bywa tak, iż po zgłoszeniu odpowiedniego problemu odpowiadający mu ticket trafia do jednego, wielkiego „worka ze zgłoszeniami”. System ticketowy odnotował wiadomość od użytkownika i teraz czeka na podjęcie pałeczki przez informatyka.

Zarządzający systemem zgłoszeniowym pracownicy przekazują ticket dalej. Przypisują go do konkretnego działu. Dział ten weryfikuje dalej problem. W czasie analizy może się okazać, iż problem leży po stronie innego działu. Nie wykluczone, że oni również przekażą go dalej. I w ten sposób poszczególne działy żonglują zgłoszeniem, by nie przekroczyć dostępnego im czasu SLA.

Jak to wygląda w praktyce?

Przykładowo, może to wyglądać następująco:

Pani Ania z działu rozliczeń zgłasza problem z aplikacją do księgowania. Nazwijmy ją Skarbnik. Aplikację, nie panią Anię 🙂
Pierwsza linia wsparcia weryfikuje problem. Okazuje się, iż występuje u większej liczby pracowników. Przekazują go do działu administracji Skarbnikiem.
Administratorzy Skarbnika analizują działanie aplikacji. Stwierdzają, iż jest problem z dostępem do bazy. Przekazują ticket do administratorów baz danych.
„Bazodanowcy” stwierdzają, iż baza działa, jednak jest problemem z dostępem do niej z zewnątrz. Przypisują zadanie administratorom sieci.
Administratorzy sieci zauważają, iż problem jest w zaporze sieciowej. Rozwiązują usterkę i zamykają ticket.
Do użytkownika trafia wiadomość o naprawieniu problemu.

System ticketowy szyty na miarę

I na takiej zasadzie poszczególne działy IT przekazują sobie piłkę. Grunt, by nie przekroczyć dostępnego im czasu i nie przetrzymać piłki. Tymczasem użytkownik czeka na realizację jego zgłoszenia. Jeżeli dodatkowo w firmie informatycy podzieleni są na takie zespoły jak zarządzanie zaporą lub poszczególnymi systemami to tych etapów przekazywania piłki może być jeszcze więcej. Niestety, bez odpowiedniego i zdroworozsądkowego zaplanowania systemu zgłoszeń, wymiana zadań jest często nieefektywna. Poświęcenie czasu na zaprojektowanie i dostosowanie aplikacji jest konieczne. System ticketowy to świetne narzędzie. Grunt jednak, by odpowiednio je dostosować do firmy.

A skoro już wspomnieliśmy SLA to warto powiedzieć więcej o tym jak jego integracja wpływa na wartość naszego systemu zgłoszeniowego. Przede wszystkim, konieczne jest by narzędzie to potrafiło wyliczyć czas wymagany na rozwiązanie. Oczywiście, w zależności od rodzaju konkretnego problemu. Przykładowo, możemy w firmie mieć awarie o następujących poziomach:

niski

średni

wysoki

Czasami jeszcze dodaje się poziom krytyczny.

Niski to P3
Średni to P2
Wysoki to P1

Co Cię może kosztować najwięcej?

W momencie wdrożenia system helpdesku ustalamy brak , których usług oznacza dla nas największy, a który najmniejszy problem. W uproszczeniu – po awarii którego systemu firma straci najwięcej pieniędzy? Przykładowo, nie działa wspomniany wcześniej system księgowości. Wdrażając system ticketowy przedstawiciele biznesu razem z działem IT ustalili, iż aplikacja ma dla firmy znaczenie o najwyższym priorytecie – P1.

Użytkownik zgłaszając problem ze Skarbnikiem automatycznie tworzy zgłoszenie P1. Ustalono, iż na jego rozwiązanie nie może zając więcej niż 8 godzin. Dział IT ma również 30 minut czasu reakcji.

Zespół Helpdesku podejmując zgłoszenie ma w obowiązku zweryfikować czy zdarzenie dotyczy jednej osoby, określonej grupy czy może całej firmy. W zależności od skali, pracownik pierwszej linii ma za zadanie pozostawić bez zmian lub zwiększyć priorytet zadania. Przykładowo, oznaczając problem jako globalny, czas na rozwiązanie ticketu ulegnie zmniejszeniu. Oczywiście, do zaprojektowania takiego systemu należy przysiąść przed wdrożeniem z pełnym zaangażowaniem i wspólnie z zarządzającymi firmą ludźmi ustalić, które zasoby informatyczne są dla przedsiębiorstwa kluczowe, a bez których można się na jakiś czas obejść.