|
|||||||||||||||
|
|||||||||||||||
|
|
|
 |
|||||||||||||
 |
|||||||||||||||
|
Artykuł
Kategoria: Project Management
Autor: Joanna Droździel
W większości przedsiębiorstw wyodrębniony został oddział odpowiedzialny za bezpośredni kontakt z użytkownikiem. Najpopularniejszą jednostką realizującą to zadanie jest Help Desk, ale pojawiają się również inne rozwiązania takie jak: Call Center, Customers Service Center oraz Customer Hotline. Bez względu na bardzo rozbudowane obowiązki, jednostki te mają jedno wspólne zadanie do wykonania: jak najszybsze rozwiązanie awarii oraz incydentów zgłaszanych przez użytkowników. Działania całego działu informatycznego postrzegane są przez działalność Help Desku, ponieważ stanowi on pierwszy i jedyny bezpośredni kontakt dla użytkownika. Z badań Forrester Research wynika, że prawie połowa z 2000 badanych użytkowników jest niezadowolona z jakości świadczonych usług. Narzekają przede wszystkim na wydłużający się czas rozwiązywania zgłoszonych incydentów.
Menedżerowie działów informatycznych oraz przedstawiciele zarządu prześcigają się w wymyślaniu coraz to ciekawszych nazw dla jednostek odpowiedzialnych za bezpośredni kontakt z użytkownikiem. Chcą tym samym zamknąć epokę nie lubianych działów Help Desk. Jednak nie w nazwie tkwi problem ale w sposobie organizacji pracy. Dlatego metodyka ITIL wychodzi z propozycją Service Desku. Jego zadaniem jest nie tylko szybka reakcja na zgłoszenie czyli realizacja procesu zarządzania incydentem, ale również wspieranie procesów zarządzania problemem, zmianą, konfiguracją, wersją, dostępnością oraz procesu zarządzania poziomem usług. Na czym polega unikalność działu Service Desk? Przede wszystkim na poprawnie określonych zadaniach, procesach a w szczególności na pełnej odpowiedzialności, ponieważ od efektywności pracy działu Service Desk zależy poprawność pozostałych procesów Service Support. Jednak by działania te przebiegały sprawnie i efektywnie, potrzeba zrozumiałych dla wszystkich zasad. Wytyczne muszą być jasne zarówno dla pracowników działu, użytkowników jak i przede wszystkim dla osób odpowiedzialnych za poprawną realizację pozostałych procesów Service Support. Informacje uzyskane dzięki ciężkiej i efektywnej pracy zespołu Service Desk przekazywane są osobom odpowiedzialnym za realizacje pozostałych procesów omawianego obszaru. Błędnie wykorzystane mogą skutkować załamaniem się całego obszaru Service Support. Dlatego współpraca na linii Service Desk - pozostałe procesy musi być rozwinięta na bardzo wysokim poziomie. 2.Zarządzanie incydentem Jednym z głównych zadań pracowników Service Desk jest zagwarantowanie stałej dostępności usługi informatycznej (Zarządzanie dostępnością). Jednak nawet w sytuacji, gdy firma dysponuje sprzętem najnowszej generacji, trudno wykluczyć możliwość wystąpienia awarii. Dlatego pracownicy tego działu powinni być gotowi na szybką reakcję.
Użytkownicy każdego dnia zgłaszają do działu Service Desk kilkadziesiąt a niekiedy i kilkaset awarii. Proces, który jako pierwszy przychodzi z pomocą w sytuacji awaryjnej to proces zarządzania incydentem. Na wstępie warto zapoznać się z pojęciem incydentu. Otóż incydent - według metodyki ITIL - to każde zdarzenie (które nie jest częścią normalnego działania) powodujące lub mogące spowodować przerwę w dostarczeniu usługi. Powodów wystąpienia incydentów może być bardzo wiele. Zasadniczo incydenty ze względu na powód wystąpienia podzielone zostały na dwie grupy: incydenty wynikające z awarii sprzętu (awaria drukarki, monitora) oraz incydenty wynikające z awarii oprogramowania (brak dostępu do bazy danych, aplikacji). Cykl życia incydentu od momentu wykrycia do momentu zamknięcia został omówiony w podrozdziale przedstawionym poniżej. Proces zarządzania incydentem Celem procesu jest jak najszybsze przywrócenie usługi oraz zminimalizowanie niekorzystnego wpływu na działalność biznesu. Nie ma tutaj miejsca ani czasu na szukanie przyczyn wystąpienia awarii. Na tym etapie stosuje się gotowe i wypróbowane procedury przywracające usługę informatyczną. Każdy wykryty incydent powinien zostać zgłoszony i zarejestrowany przez osobę z działu Service Desk. Metodyka ITIL nie podaje jednej konkretnej drogi zgłoszenia incydentu, więc nie jest ważne czy odbywa się to drogą telefoniczną, za pomocą poczty elektronicznej czy też osobiście. Istotną kwestią na tym etapie procesu jest stworzenie takiego klimatu pracy by użytkownicy wykrywając awarię nie bali się zgłaszać jej pracownikom Service Desku. Ważne też jest by nie doszło do takiej sytuacji gdy każdy użytkownik w obawie przed trudnymi pytaniami informatyków podejmuje próbę samodzielnej naprawy awarii, co w rezultacie może doprowadzić do jeszcze większych szkód. Dlatego by uniknąć takich zachowań, pracownik działu Service Desk, przyjmując zgłoszenie o awarii, powinien zadawać tylko pytania potrzebne do identyfikacji obszaru czy części infrastruktury. Użytkownik zgłaszając awarię nie musi znać numeru seryjnego uszkodzonego monitora czy drukarki; wystarczy, że wskaże miejsce, gdzie dana część infrastruktury się znajduje. W tym przypadku wystarczy informacja, iż drukarka znajduje się w dziale księgowym a wszystkimi pozostałymi potrzebnymi informacjami powinien dysponować Service Desk. Informacje te powinny znajdować się w Bazie Konfiguracji - CMDB, która zawiera najdrobniejsze szczegóły o danym sprzęcie i oprogramowaniu oraz relacjach miedzy nimi. Po przyjęciu zgłoszenia ma miejsce określenie przyczyny wystąpienia incydentu. Pełen cykl obsługi incydentu przedstawiono na rysunku 1. Rysunek 1. Cykl życia incydentu. Z reguły Service Desk jest przeciążony pracą ponieważ użytkownicy generują setki zgłoszeń dziennie. Ważne jest by w gąszczu błahych awarii nie zostały przeoczone zdarzenia, dla których każda minuta zwłoki przynosi działalności biznesowej wysokie straty. Dlatego bardzo pomocne na tym etapie pracy jest właściwe określenie priorytetu zgłoszenia przez pracownika przyjmującego informację o awarii. Osoba przyjmująca zgłoszenie powinna posiadać odpowiednią wiedzę techniczną niezbędną w szybkim naprawianiu awarii, ale również powinna znać realia działania przedsiębiorstwa oraz hierarchię priorytetów określoną w ramach umowy SLA tak, by swoją decyzją nie narażała firmy na niepotrzebne koszty. Po określeniu priorytetu incydentu następuje przypisanie do odpowiedniej grupy wsparcia. Rysunek 2 przedstawia strukturę grup wsparcia wymienionych przez autorów metodyki ITIL. Jeżeli jest to awaria dobrze znana pracownikom Service Desku oraz dysponują oni gotową do realizacji procedurą naprawienia, wówczas zgłoszenie jest kierowane na pierwszą linie obsługi incydentu. 3.Zarządzanie problemem  Jeżeli natomiast ma miejsce sytuacja, gdzie pracownik Service Desk nie potrafi określić przyczyny wystąpienia awarii, wówczas takie zgłoszenie kierowane jest do drugiej linii wsparcia odpowiedzialnej za poszukiwanie rozwiązania. Wskazane jest aby przed przekierowaniem zdarzenia do drugiej grupy wsparcia udało się je naprawić, nie czyniąc tym samym szkód finansowych dla działalności biznesowej przedsiębiorstwa. Jednak przypadków, które zostały naprawione bez poznania przyczyny ich powstania jest niewiele. Z reguły na drugą linię wsparcia trafiają nierozwiązane problemy, których bez wnikliwego procesu zarządzania problemem nie sposób naprawić. Dlatego wielu praktyków metodyki ITIL uważa, iż druga i trzecia linia wsparcia w procesie zarządzania incydentem realizuje założenia procesu zarządzania problemem (będzie o tym mowa w rozdziale następnym). Niekiedy pracownicy drugiej linii wsparcia nie mogąc znaleźć rozwiązania problemu, korzystają z pomocy trzeciej linii wsparcia, którą z reguły stanowią konsultanci z firm zewnętrznych. W procesie zarządzania incydentem nie ma czasu na szukanie przyczyny wystąpienia awarii. Na tym etapie prac w obszarze Service Support stosuje się procedury oraz rozwiązania stanowiące Bazę Wiedzy. Zawiera ona scenariusze postępowania na wypadek konkretnych awarii. Gdy brakuje w bazie danego rozwiązania, wówczas jest to jednoznaczne z sytuacją, iż pracownicy Service Desk mają do czynienia z nowym typem awarii, dotychczas nieopisanym. W takiej sytuacji incydent staje się problemem i trafia do procesu zarządzania problemem. Zarówno użytkownicy jak i pracownicy Service Desku wiedzą, jak wiele awarii naprawianych jest na bieżąco. Jest jednak również grupa nierozwiązanych incydentów, dlatego Service Desk powinien cały czas śledzić oraz monitorować przebieg realizacji incydentów. Nie może dojść do sytuacji, w której pracownicy zapomną o naprawieniu awarii, co w rezultacie narazi przedsiębiorstwo na straty finansowe. By tego uniknąć wiele firm, których użytkownicy generują setki zgłoszeń dziennie, decyduje się na zakup dodatkowego oprogramowania pomocnego w obsłudze incydentów. Po określeniu procedury w Bazie Wiedzy następuje etap naprawienia incydentu i w efekcie jego zamknięcie. Według autorów metodyki ITIL Service Desk powinien rozwiązać 85% wszystkich zgłoszeń już w pierwszej linii wsparcia, bez korzystania z pomocy pozostałych grup. Działania proaktywne procesu zarządzania incydentem Zadaniem działu Service Desk nie jest tylko naprawianie zgłaszanych awarii ale przede wszystkim podjęcie działań eliminujących awarie drobne, błahe. Wiadomo, że nie sposób przeszkolić wszystkich użytkowników tak, by nie generowali niepotrzebnych zgłoszeń ale warto czasami zwrócić uwagę na błędy popełniane przez użytkowników. Zazwyczaj użytkownicy z braku wiedzy, bojąc się zapytać pracowników działu informatycznego, drogą prób i błędów poznają tajniki nowej aplikacji bądź sprzętu. Częściej jednak poszerzają swoją wiedzę drogą popełnianych błędów, za które strona biznesowa zmuszona jest płacić, a Service Desk naprawiać. Dlatego warto przyjrzeć się zachowaniom użytkowników oraz ich starym, złym nawykom. Jeden szybki telefon do działu Service Desk z krótkim zapytaniem uchroni organizację przed niepotrzebnymi kosztami. Jako przykład negatywnego zachowania użytkownika może posłużyć problem drukowania na foliach. Wystarczyło aby użytkownik wykonał jeden telefon do Service Desku z zapytaniem, na której drukarce można w ten sposób drukować. Uchroniłoby to firmę przed niepotrzebną wymianą drukarki. Jednak nie wszystkie awarie wynikają z nieprofesjonalnych zachowań użytkowników, tego typu awarie stanowią niewielką część wszystkich incydentów. Zdecydowana większość awarii wynika z przestarzałego sprzętu zalegającego w wielu przedsiębiorstwach. Zasada, że im starsze tym lepsze sprawdza się w przypadku wina. W przypadku komputerów jest odwrotnie - trzyletnia maszyna może już spowodować właścicielowi niemałe kłopoty. Amerykańscy specjaliści wyliczyli, iż koszt obsługi starego komputera jest od 3 do 5 razy większy niż zakup nowego sprzętu. Dlatego strona biznesowa nie powinna ograniczać funduszy na zakup nowej infrastruktury informatycznej. Zwłaszcza, że przestarzały sprzęt wymusza na użytkownikach bardzo groźne dla całej infrastruktury działania. Użytkownicy aby przyśpieszyć działanie komputerów wyłączają programy antywirusowe, co sprowadza na przedsiębiorstwo kolejne straty finansowe spowodowane incydentami naruszeń bezpieczeństwa informatycznego. Według raportu magazynu CIO oraz firmy PricewaterhauseCoopers, opracowanego w roku 2003, w 17% firm miało miejsce powyżej 10 wypadków dotyczących naruszeń bezpieczeństwa firmy w ciągu roku, co było równoznaczne z przestojem w pracy o całkowitym wymiarze od 4 do 8 godzin. Dlatego zamiast wydawać pieniądze na „gaszenie pożarów”, warto zainwestować w działania profilaktyczne eliminujące możliwość wystąpienia takiego pożaru. Dzięki takiej postawie ilość zakłóceń w normalnej pracy zarówno dla pracowników Service Desku, jak i użytkowników zostanie zmniejszona do niezbędnego minimum. Menedżerowie różnych działów informatycznych mieli zapewne niejednokrotnie do czynienia z sytuacją, uznawaną przez nich za sytuację bez wyjścia: co zrobić w wypadku, gdy następuje przerwa w dostawie usługi z przyczyn nie rozpoznanych przez personel Service Desku. Z pomocą może przyjść proces zarządzania problemem. Niezależnie od tego Service Desk powinien próbować przywrócić usługę w stopniu, na jaki pozwalają realia zaistniałej awarii. Jeżeli podjęte działania nie przyniosły oczekiwanych rezultatów należy poddać problem szczegółowej analizie. Względy formalne określają, iż awarie zgłoszone przez użytkowników stają się problemami wówczas, gdy pierwsza linia wsparcia Service Desk nie dysponuje gotowym rozwiązaniem bądź procedurą. Efektywne zarządzanie problemem zależy w dużym stopniu od poprawnej implementacji procesu zarządzania incydentem. Proces zarządzania problemem Proces zarządzania incydentem miał na celu jak najszybsze przywrócenie usługi, natomiast proces zarządzania problemem odpowiada za minimalizowanie niekorzystnego wpływu na działalność biznesową incydentów i problemów.
Nie ma określonej kolejności wdrażania procesu zarządzania problemem; najlepszym rozwiązaniem jest wdrażanie go równolegle z procesem zarządzania incydentem. Zazwyczaj na proces zarządzania problemem nakłada się kilka incydentów, dlatego też warto spojrzeć na to zagadnienie z szerszej perspektywy. Pracownicy Service Desku obserwują każdy indywidualny incydent; w procesie zarządzania problemem jest czas by przejrzeć się całej grupie. Proces zarządzania problemem składa się z dwóch podprocesów: kontroli problemu oraz kontroli błędu. Podproces kontroli problemu ma za zadanie przekształcić nieznaną awarię w znany błąd, natomiast podproces kontroli błędu ma za zadanie rozwiązać znane błędy przygotowując tym samym RfC dla procesu zarządzania zmianą. Service Desk nie posiada gotowych scenariuszy postępowania w przypadku każdej możliwej awarii. W procesie zarządzania problemem następuje więc identyfikacja przyczyn występowania incydentów oraz poszukiwanie rozwiązań. Dana awaria kierowana jest do grupy pracowników odpowiedzialnych za proces zarządzania problemem. Zespół ten pracuje w bardziej komfortowych warunkach, niż te z jakimi mają do czynienia pracownicy Service Desku. Przede wszystkim działania w procesie zarządzania problemem nie mają określonych ram czasowych, toteż pośpiech jest tutaj wręcz niewskazany. Należy jednak zachować w tej kwestii zdrowy umiar. Grupa poszukująca rozwiązania dla danego problemu powinna mieć szczególnie na uwadze względy finansowe, starając się wykluczyć sytuacje narażające stronę biznesową na jakiekolwiek dodatkowe straty. Dlatego bardzo ważne jest aby zespół składał się zarówno z osób bardzo dobrze wyszkolonych technicznie, jak również osób posiadających konieczną wiedzę biznesową. Z reguły problemy, które kierowane są do tej grupy, wymagają bardzo wnikliwej analizy. Ważne by w trakcie procesu korzystano z różnych technik pomocnych w analizie problemu. Do najczęściej stosowanych należą:
Proces zarządzania problemem rozpoczyna się od identyfikacji oraz wstępnej klasyfikacji problemu. Po określeniu przyczyn wystąpienia problemu należy zaproponować scenariusz postępowania zmierzający do naprawy problemu. Bardzo ważne aby takich scenariuszy było kilka, tak by osoby odpowiedzialne za realizację podprocesu kontroli błędu mogły wybrać rozwiązanie optymalne zarówno dla strony informatycznej jak i biznesowej. Na tym etapie procesu zarządzania problemem jest wystarczająco dużo czasu by opracować klika wariantów naprawy problemu. Po wykryciu przyczyny wystąpienia awarii zadaniem osoby odpowiedzialnej za podproces zarządzania problemem jest opracowanie dokumentacji, tak by stanowiła ona podstawę do reakcji dla pracowników Service Desk. Nie chodzi tutaj o produkowanie zbędnej dokumentacji, ale o udokumentowanie rozwiązania, z którego w przyszłości mogliby korzystać pracownicy mający bezpośredni kontakt z użytkownikiem. Takie działania mają na celu zwiększenie liczby rozwiązywanych przez Service Desk awarii już na pierwszej linii wsparcia. Podprocesy składające się na proces zarządzania problemem przedstawiono na rysunku 3.  Rysunek 3. Proces zarządzania problemem. Gdy działania w podprocesie zarządzania problemem zakończą się sukcesem rozpoznany problem zostaje przekazany do podprocesu zarządzania błędem. Osoby odpowiedzialne za podproces kontroli błędu zmuszone są korzystać z pomocy grupy realizującej proces zarządzania zmianą. Naprawa błędu wymaga wprowadzenia dodatkowych zmian. Dlatego proces zarządzania problemem zależy nie tylko od efektywności procesu zarządzania incydentem ale również od skuteczności procesu zarządzania zmianą.
Jednak na zamknięciu błędu proces się nie kończy. Przed osobami odpowiedzialnymi za realizację procesu zarządzania problemem stoi dodatkowe zadanie: sprawdzenie naprawionych elementów. O ile w przypadku małych incydentów wystarczy telefon do użytkownika z zapytaniem o sposób rozwiązania, to już w przypadku dużych problemów taka forma nadzoru może nie wystarczyć. Dlatego konieczny jest formalny przegląd sprawdzający założone cele oraz sposób ich realizacji. Tak przeprowadzony proces pomoże w usystematyzowaniu procesów zasilających Bazę Wiedzy w rekordy o znanych błędach i sposobie ich rozwiązania. Działania proaktywne procesu zarządzania problemem Proces zarządzania problemem przez niektórych praktyków metodyki ITIL uważany jest za przedłużenie procesu zarządzania incydentem. Ma on na celu nie tylko opracowanie strategii naprawy problemu, ale przede wszystkim podejmuje działania proaktywne, polegające na analizie infrastruktury informatycznej oraz raportów pochodzących z aplikacji wsparcia. Proaktywne działania zmierzające do realizacji procesu zarządzania problemem muszą mieć poparcie w danych zgromadzonych przez proces zarządzania incydentem. Jeżeli proces zarządzania incydentem będzie prowadzony bardzo chaotycznie, bez możliwości sprawdzenia całej historii zdarzenia, wówczas proaktywny proces zarządzania problemem nie będzie przynosił oczekiwanych rezultatów. W rzeczywistości będzie sprowadzony do koniecznego minimum, a w ostateczności całkowicie zaniknie. Działania proaktywne realizują założenia ustalone w procesach zarządzania dostępnością oraz ciągłością (Proces zarządzania dostępnością) oraz (Proces zarządzania pojemnością). Nie tylko zdarzenia na które brakuje scenariuszy w Bazie Wiedzy trafiają do procesu zarządzania problemem; kieruje się tam również i te incydenty, które udało się naprawić, ale przyczyna ich wystąpienia jest nadal nieznana. Wówczas rekord dotyczący tego incydentu zostaje zamknięty w procesie zarządzania incydentem, a w jego miejsce zostaje otwarty rekord w procesie zarządzania problemem. Warto nie tylko rozwiązanie każdego problemu przedstawić pracownikom Service Desku ale również opracować wstępny koszt naprawy takiego problemu oraz strat finansowych, jakie poniósł biznes z racji wystąpienia. Należy takie oszacowanie przedstawić stronie biznesowej na jednym z licznych spotkań. Przedstawiony raport napewno przekona stronę biznesową do inwestycji w działania proaktywne zapobiegające wystąpieniu problemów. Tylko takie działania mogą uchronić firmę przed zwiększającą się liczbą incydentów mających negatywny wpływ na działalność biznesową, co jest równoznaczne z poprawieniem jakości świadczonych usług. O Autorze (email: secured) Joanna Droździel jest absolwentem Informatyki na Wydziale Elektrycznym Politechniki Warszawskiej. Obroniła pracę magisterską z zakresu metodyki ITIL. Posiada certyfikat ISEB Foundation. Prowadzi blok wykładów „Zarządzanie usługami IT” na Podyplomowym Studium Prowadzenia Projektów Informatycznych na Politechnice Waszawskiej. Obecnie pracuje w firmie CS Stars na stanowisku starszego analityka do spraw zapewnienia jakości, biorąc udział w projektach dla klientów zagranicznych. Scisle wspolpracuje z portalami: www.ITlife.pl oraz www.sjsi.org. > Interesuje Cię ten temat? Zapisz się na szkolenie! Masz ciekawy artykuł związany z Project Management? Opublikuj go, proszę, poprzez dostępne narzędzie: "Moje artykuły" |
||||||||||||||
|
|||||||||||||||
| Copyright © by Business Project Management Group - BPMG | Polityka Prywatności | Regulamin | Wszystkie prawa zastrzeżone. | |||||||||||||||
