W poprzednich artykułach opisywałem strumienie wartości „Jak utworzyć nową usługę” i „Jak przywrócić usługę do działania”. Żeby strumień wartości był efektywny, skuteczny i dostarczał wartości, musimy mierzyć jego parametry i podejmować działania aby te wartości były jak najlepiej dopasowane do danego strumienia. Jakie to parametry?

1.  Czas cyklu (Cycle time)

Czas cyklu określa ile czasu jest wykonywana określona jednostka pracy, zadanie, przekształcając dane wejściowe w wyniki. Jest to czas, który faktycznie poświęcamy na realizację zadania. Przykładowo, jeżeli service desk rozwiązuje incydent zgłoszony przez użytkownika w ciągu 30 minut, to oznacza że czas cyklu wynosił 30 minut.

Jeżeli to możliwe, to optymalizujemy i skracamy czas cyklu, dzięki temu możemy skrócić czas realizacji strumienia wartości.

2.  Kolejka (Queue)

Kolejka wskazuje na ilość jednostek pracy, zadań, działań, które oczekują na wykonanie. Im krótsza kolejka tym lepiej. Na długość kolejki może mieć wpływ sposób jej obsługi, rozładowania. Dlatego zalecane jest aby zadania z kolejki były pobierane (pull), wtedy gdy wykonujący zadanie, pracę zakończył wykonywanie poprzedniego zadania. Wydłużać kolejkę może podejście wypychania zadań z kolejki (push), bez weryfikacji czy poprzednie zadanie zostało już zakończone.

W kolejce mogą oczekiwać zgłoszenia, które trafiają do service desku, zanim zostaną obsłużone przez pierwszą lub kolejne linie wsparcia.

3.  Czas oczekiwania (Wait time)

Czas oczekiwania jest ściśle powiązany z kolejką i określa ile czasu dana jednostka pracy, zadanie czeka, zanim zostanie pobrana do realizacji. Parametr ten może w znaczący sposób wydłużać czas jaki jest potrzebny do przejścia danej pracy przez cały strumień wartości. Na skracaniu czasu oczekiwania można uzyskać największe optymalizacje w strumieniu wartości.

Czasem oczekiwania może być czas od przekazania zgłoszenia od użytkownika do service desk do potwierdzenia użytkownikowi przyjęcia zgłoszenia.

4.  Czas realizacji (Lead time)

Czas realizacji to suma czasu cyklu i czasu oczekiwania. Jest to całkowity czas jaki jest potrzebny do ukończenia jednostki pracy od momentu kiedy znalazła się w kolejce do czasu zakończenia zadania.

Czasem realizacji może być czas od przekazania zgłoszenia (incydentu) od użytkownika do service desk do rozwiązania incydentu przez service desk.

5.  Praca w toku (Work-in-Progress, WiP)

Praca w toku to ilość jednostek pracy, które zostały rozpoczęte ale nie zostały jeszcze zakończone. Dążymy do minimalizowania pracy w toku, tak aby nie zaczynać nowych zadań, jeżeli nie zakończyliśmy już rozpoczętych. Minimalizacja pracy w toku, jest to jeden z głównych celów optymalizacji działania strumienia wartości.

Ilość zgłoszeń otwartych w service desk, określa nam pracę w toku.

6.  Przepustowość (Throughput)

Przepustowość to ilość jednostek pracy, które mogą być wykonane w określonym przedziale czasu, np. 8 godzin.  Jest to zdolność strumienia wartości do przetwarzania określonej ilości zadań/pracy, wskazując na jego wydajność i potencjał.

Ilość zgłoszeń jakie service desk może obsłużyć w ciągu dnia roboczego wyznacza nam przepustowość danego strumienia wartości.

Wszystkie opisane parametry strumienia wartości należy na bieżąco mierzyć i monitorować dla wszystkich strumieni wartości w organizacji, aby mieć wiedzę jak one działają i podejmować aktywności gdy występują problemy z przepływem pracy.

Takim przykładem mogą być wąskie gardła (bottleneck) w strumieniu wartości, które objawiają się piętrzeniem, zatorami  w wykonywaniu zadań w kroku strumienia wartości, podczas gdy w innych, dalszych krokach pracy jest niewiele. Usunięcie wąskiego gardła w jednym roku, może skutkować, że pojawi się ono w kolejnym, dlatego trzeba usuwać wąskie gardła aż do końca strumienia wartości i optymalizować cały strumień a nie tylko jeden krok.

Jakie parametry strumienia wartości mierzysz i monitorujesz?

Artykuł Prosto o ITIL – Jak mierzyć strumień wartości? pochodzi z serwisu Mariusz Siek.

Na pierwszy ogień, w ocenie narzędzi klasy ITSM idzie Atlassian Jira. Dlaczego? Bo to chyba najbardziej popularne i najczęściej stosowane narzędzie, które jest wykorzystywane przez działy IT. Co ważne nie tylko przez zespoły utrzymania ale również przez zespoły wytwarzania oprogramowania, działające zgodnie z metodyką Agile. Nie jest to bez znaczenia, ponieważ do obsługi zgłoszeń błędów, zarówno na etapie wytwarzania jak i utrzymania (operacji), można wykorzystać to samo narzędzie a to już połowa sukcesu. Jest to jednocześnie jedno z najbardziej łatwych w dostosowaniu do własnych wymagań i intuicyjnych w użytkowaniu narzędzi. Osobiście miałem z nim do czynienia w różnych organizacjach i na różnym poziomie i zawsze się sprawdzało.

Która Jira?

Mamy obecnie, tak naprawdę dwa produktu Jira Software oraz Jira Service Desk. Jira Software nazywam „starą” Jirą, bo jest to produkt, który funkcjonuje już bardzo długo na rynku. Za jego pomocą można zaimplementować dowolny proces ITSM, jak również procesy wytwarzania oprogramowania w oparciu o Agile (Scrum). Chociaż nie jest przeznaczony do obsługi zgłoszeń produkcyjnych to może być wykorzystywany, tylko brakuje w nim liczenia czasów SLA związanych z obsługa zgłoszeń. Tę funkcjonalność ma Jira Service Desk ale jeżeli się uprzemy to z pomocą programisty, możemy taką funkcjonalność sobie napisać w Jira Software. Tak jak obiecałem, będę starał się oceniać narzędzia według tych samych kryteriów opisanych w artykule „Jakie narzędzie ITSM wybrać?”

Wymagania ogólne

Jira Software jest narzędziem, które łatwo można dopasować do własnych potrzeb i wymagań. Ma zaimplementowane podstawowe workflow procesów ITSM ale jednocześnie można zaprojektować własny przepływ działań, za pomocą interfejsu graficznego. Właściwie nie ma ograniczeń.

Definiując odpowiednie filtry i widoki, można monitorować i raportować zdefiniowane parametry (KPI), które mają za zadanie kontrolować określone procesy zarządzania usługami IT. Interfejs narzędzia jest bardzo intuicyjny i nie powinien sprawić problemów, nawet użytkownikom korzystającym po raz pierwszy.

Jira Software pozwala na utworzenie dowolnych formatek z polami różnych typów od zwykłego pola tekstowego, przez listę wyboru do pól z wyborem wskazanej opcji. Możemy zdefiniować dowolne role i nadać im określone uprawnienia do wykonywania określonych czynności w narzędziu. Użytkownicy mogą logować się do narzędzia wykorzystując swoje konta domenowe.

Service Desk

Tutaj mamy dwie możliwości. Możemy wykorzystać dedykowany produkt Jira Service Desk, który jest specjalnie zaprojektowany w tym celu i zawiera wszystkie wymagane funkcjonalności, takie jak np mierzenie czasów SLA obsługi zgłoszeń. Musimy tylko pamiętać, że w tym celu będziemy musieli kupić dodatkowe licencje, niezależnie od już posiadanych do Jira Software.

Możemy jednak wkładając trochę wysiłku i własnych prac programistycznych, wykorzystać Jira Software do pełnienia funkcji Service Desk.

Pierwszym krokiem jest znalezienie rozwiązania w bazie wiedzy. Może za mało korzystałem z tego narzędzia ale nie spotkałem się z dobrą implementacja bazy wiedzy w Jira. Pewnie można to zrobić ale domyślenie nie ma takiej funkcjonalności.
Oczywiście użytkownicy mogą samodzielnie zgłaszać wszelkie zgłoszenia, muszą mieć tylko konto założone w narzędziu. Projektujemy prostą formatkę do zgłaszania i już. Możemy również ustawić tak, aby mail wysłany na odpowiedni adres i odpowiednio sformatowany założył zgłoszenie. Jeżeli chodzi o rejestrowanie zgłoszenia na podstawie telefonu, na podstawie IVR to nie ma takiej funkcjonalności.
Zgłaszający jest powiadamiany mailowo o wszystkich aktywnościach, działaniach wykonywanych w ramach zgłoszenia. Oczywiście w zakresie czasów reakcji i rozwiązania wymagane jest dorobienie ich liczenia i związane z nimi akcje. Po rozwiązaniu można potwierdzić ten fakt a zgłoszenie może być zamknięte. Nie spotkałem się jednak z prostą oceną, ankietę po rozwiązaniu zgłoszenia.
Zarządzanie incydentami
Możemy zaprojektować i wdrożyć własny workflow dla procesu zarządzania incydentami. Dla każdego zgłoszenia możemy nadawać wymaganą kategorię, uprzednio zdefiniowaną oraz jeden z domyślnych priorytetów. Nie ma możliwości

• określania priorytetu na podstawie piloności i ważności,
• komunikatów o stopniu wykorzystania czasów obsługi,
• bazy znanych błędów,

chyba że skorzystamy z Jira SD. Mamy oczywiście łatwość komunikacji przez komentarze ale już nie ma funkcji chat. Możesz oczywiście kupić produkt Atlassiana Hipchat albo skorzystać z skype lub innego komunikatora.

Zarządzanie problemami

Bez problemu zaimplementujemy ten proces w Jira Software. W większości przypadków nie mamy SLA na problemy więc nie potrzebujemy mierzyć czasów. Możemy powiązać rekord problemu z jednym lub więcej incydentami. Kategorie możemy mieć takie same jak w incydentach. Niestety ale czasów SLA standardowo nie mamy. Musimy posiłkować się dodatkową wtyczką, programistą lub Jira SD.

Zarządzanie zmianą

Jira pozwala na obsługę wszystkich trzech typów zmian. Tylko od zaprojektowanego procesu zależy, kto może akceptować zmianę. Można wskazać element konfiguracji, którego dotyczy zmiana, najczęściej z listy rozwijanej ale o CMDB więcej w kolejnym punkcie. Możemy połączyć zmianę z incydentami lub problemami i mamy pełną historię przebiegu zmiany i wszystkich jej krokach. Nie spotkałem się z ograniczeniami dla tego procesu w narzędziu.

Zarządzanie zasobami i konfiguracją

Ten proces jest chyba najsłabszą stroną Jira Software. Oczywiście są informacje o pewnych zasobach ale są niekompletne oraz brakuje relacji pomiędzy zasobami, co jest podstawową cechą CMDB. Może to wynikać z tego, że jest to raczej narzędzie dla rozwoju a nie utrzymania (operacji). Dodatkowo utrzymanie aktualności danych o zasobach wymaga dużego nakładu pracy i nie można myśleć o automatyzacji.

Zarządzanie poziomem usług (katalogiem usług)

Tego procesu nigdy nie widziałem w Jira Software. Nie można zdefiniować usług ani określić dla nich SLA, które następnie mogłoby być udostępniane dla innych procesów ITSM. O monitorowaniu i raportowaniu poziomu usług, nawet nie wspominam. Żeby jednak nie było, to nie widziałem żadnego narzędzia, które spełniałoby te wymagania

Podsumowanie

Patrząc na wszystkie wymagania i potrzeby większości organizacji, mogę z czystym sumieniem polecić Jira Software, każdej organizacji, która chce usprawniać funkcjonowanie swoich procesów wytwarzania oprogramowania i jego późniejszego utrzymania. Intuicyjność narzędzia i prostota użycia oraz niski poziom wejścia, powoduje że powinien sobie z nim poradzić prawie każdy. Trzeba mieć jednak świadomość, że narzędzie ma bardzo duże możliwości i jeżeli tylko będziemy chcieli to możemy je wykorzystać, gdy będziemy mieli taką potrzebę. Oczywiście Atlassian w swoim portfolio posiada bardzo dużo innych produktów np. Confluence, które pozwalają z czasem rozwijać zestaw narzędzi, które wspierają organizację IT w efektywnym funkcjonowaniu. Dużym atutem jest również bogata biblioteka wtyczek, które rozszerzają funkcjonalności Jira, jednak większość przydatnych jest płatna.

Pytanie: Jakie masz doświadczenia z Atlassian Jira?

Artykuł Atlassian Jira pochodzi z serwisu Mariusz Siek.

Zaczynam nową serię artykułów, które mam nadzieję, będą bardzo atrakcyjne i pomocne dla osób, które je przeczytają. Często spotykam się z pytaniem jakie narzędzie wybrać do wsparcia obsługi procesów ITIL. Obecnie rynek dostarcza bardzo dużo rozwiązań, które pomogą nam zapanować nad sprawnym wdrożeniem, uruchomienie i działaniem procesów zarządzania usługami IT. Są to zarówno proste narzędzia pomagające w obsłudze zgłoszeń od użytkowników, po kombajny, które pomogą zaimplementować dowolny, wymyślony przez nas proces. Które z nich wybrać? Czym się kierować? Jakie kryteria przyjąć aby dopasować narzędzie do potrzeb i nie zapłacić fortuny? Czy lepiej wybrać narzędzie świadczone w modelu SaaS (Software as a Service) czyli w chmurze, czy może jednak uruchomić je na własnych zasobach sprzętowych? Dzisiaj opiszę jakie kryteria będę stosował do weryfikacji narzędzi. W kolejnych artykułach, które będę chciał publikować raz w miesiącu, opiszę jak dane narzędzie spełniło określone przeze mnie kryteria. Mam nadzieję, że w miarę upływu kolejnych miesięcy powstanie subiektywny ranking narzędzi klasy ITSM. Świadomie piszę, że subiektywny, bo oprócz kwestii merytorycznych, będę chciał pokazać moje wrażenia i odczucia z krótkiego testowania narzędzia.

Wymagania ogólne

Na początek kilka wymagań ogólnych, które powinno spełniać narzędzie.

• Wdrożenie dowolnego work flow dla procesów zarządzania usługami IT, który został zaprojektowany w organizacji
• Monitorowanie i raportowanie zdefiniowanych KPI dla procesów ITSM
• Intuicyjny interfejs dla użytkowników i pracowników I, II i III linii wsparcia
• Możliwość tworzenia prostych formatek do wsparcia procesów ITSM
• Tworzenie i nadawanie uprawnień dla ról występujących w procesach ITSM
• Integracja narzędzia z usługą katalogową (np. Active Directory, LDAP) aby nie trzeba było zakładać użytkownikom dodatkowych kont do narzędzia

Service Desk

Chyba nikt nie wyobraża sobie narzędzia ITSM bez funkcji Service Desku. Jest to podstawowa funkcjonalność pozwalająca na:

• Wyszukanie rozwiązania w bazie wiedzy, zanim jeszcze użytkownik wyśle zgłoszenie
• Samodzielne zgłaszanie przez użytkowników incydentów i problemów oraz service requestów
  • Prosty formularz zgłoszeniowy, dostępny przez stronę WWW lub dedykowaną aplikację
  • Email, na podstawie którego zostanie zarejestrowane automatycznie zgłoszenie
  • Telefon ze skonfigurowanym IVR, który na podstawie prostych wyborów, pozwoli na zarejestrowanie zgłoszenia
• Otrzymanie potwierdzenia przyjęcia zgłoszenia oraz monitorowanie statusu jego obsługi (czas reakcji, czas rozwiązania)
• Potwierdzanie rozwiązania zgłoszenia oraz zamykanie zgłoszeń po ustalonym czasie (np. 7 dni)
• Ocena, ankieta w jaki sposób zostało obsłużone zgłoszenie (pozytywnie, neutralnie, negatywnie)

Zarządzanie incydentami

Pierwszym najczęściej wspieranym przez narzędzie ITSM i wdrażanym w organizacjach procesem jest zarządzanie incydentami. Co powinno zapewniać narzędzie aby proces ten funkcjonował efektywnie?

• Nadawanie kategorii i priorytetów dla incydentów
• Określanie priorytetu na podstawie wpływu i ważności incydentu (SLA)
• Wysyłanie komunikatów, alertów o stopniu wykorzystania czasu rozwiązania
• Rejestrowanie na podstawie incydentów i problemów rozwiązań dla znanych błędach (baza znanych błędów)
• Łatwość komunikacji pomiędzy liniami wsparcia (komentarze, chat)

Zarządzanie problemami

Uzupełnieniem do zarządzaniami incydentami jest zarządzanie problemami, które powinno zawierać:

• Rejestrowanie problemów na podstawie jednego lub więcej incydentów
• Powiązanie problemu z incydentem lub incydentami
• Nadawanie kategorii takich samych jak dla incydentów
• Określanie SLA dla obsługi problemów
• Monitorowanie wykorzystania czasu obsługi problemu

Zarządzanie zmianą

Drugim najważniejszym i najczęściej implementowanym w narzędziu procesem jest zarządzanie zmianą. Jak narzędzie może pomóc w funkcjonowaniu procesu?

• Obsługiwać zmianę standardową, normalną i pilną
• Wspierać proces akceptacji zmiany przez Menedżera zmian oraz Radę ds. Zmian
• Umożliwiać wskazanie z bazy konfiguracji usługi, elementu konfiguracji, którego dotyczy zmiana
• Gromadzić informację o historii zmiany, w całym jej cyklu życia
• Powiązanie zmiany z incydentami i problemami

Zarządzanie zasobami i konfiguracją

Bez procesu zarządzania zasobami i konfiguracją nie mogą skutecznie i efektywnie funkcjonować pozostałe procesy ITSM, dlatego ważne jest aby móc:

• Zarejestrować wszystkie typy elementów konfiguracji składające się na usługi
• Zdefiniować wymaganą ilość atrybutów dla EK
• Określić relacje pomiędzy elementami konfiguracji i usługami (jeden do jeden, jeden do wielu, wiele do jednego i wiele do wielu)
• Zdefiniować kategorie i podkategorie dla każdego EK
• Automatycznie aktualizować informacje o zmianach wprowadzanych do EK

Zarządzanie poziomem usług (katalogiem usług)

Zarządzanie poziomem usług jest bardzo ważnym procesem, chociaż nie zawsze tak jest postrzegane. Jak powinno być wspierane przez narzędzia ITSM?

• Zarejestrować i opisać usługi wraz z atrybutami
• Wprowadzić SLA dla usług i odpowiednio powiązać z usługami
• Tworzyć słowniki dla parametrów SLA takich jak dostępność, wydajność, obsługa zgłoszeń itp
• Udostępniać usługi i SLA dla innych procesów ITSM (zarządzanie incydentami, problemami, zmianą, zasobami i konfiguracją)
• Monitorować i raportować rzeczywisty poziom usług (SLA)

To są podstawowe kryteria, jakimi będę się kierował sprawdzając i weryfikując narzędzia ITSM. Test pierwszego narzędzia jeszcze w tym miesiącu. Jeżeli macie propozycje innych kryteriów, bardzo chętnie dodam je do swojej listy i będę stosował podczas weryfikacji. Jeżeli macie również swoje typy narzędzi ITSM, które mam wziąć pod lupę, to dajcie znać a ja podejmę rękawicę i prześwietlę swoimi metodami.

Pytanie: Które jedno kryterium z powyższych jest dla Was najważniejsze i dlaczego?

Artykuł Jakie narzędzie ITSM wybrać? pochodzi z serwisu Mariusz Siek.

Proces zarządzania incydentami (Incident Management) jest najczęściej wdrażanym i wykorzystywanym procesem ITIL. Ma na to wpływ wiele czynniki ale najważniejszym jest fakt, że w każdej organizacji występują jakieś zdarzenia w działaniu usług IT, które wymagają pomocy ze strony zespołów wsparcia. Nie oznacza to, że jest to najłatwiejszy proces. Wręcz przeciwnie według mnie to jeden z bardziej złożonych i jednocześnie ważnych procesów. Jego wdrożenie wymaga dobrego przygotowania i przemyślenia jak proces powinien funkcjonować w naszej organizacji. Zobaczmy, na jakie aspekty należy zwrócić uwagę.

Narzędzie ITSM

Zaczynam od narzędzia aby obalić mit, że do obsługi incydentów wystarczy wdrożyć narzędzie klasy ITSM i już wszystko będzie działać jak w szwajcarskim zegarku. Sam ITIL podpowiada, że „głupiec z narzędziem, jest nadal głupcem”. Zobacz mój artykuł „Czy narzędzia pomogą Ci w utrzymaniu usług IT?”. Nie oczekujmy, że jak wdrożmy narzędzie to, rozwiąże ono wszystkie nasze problemy. Tak się nie stanie. Narzędzie może pomóc w zarządzaniu incydentami ale wcześniej trzeba je odpowiednio skonfigurować i dopasować do naszych realiów. Narzędzie upraszcza pewne czynności ale nie gwarantuje, że incydenty będą rozwiązywane w SLA. Za to odpowiadają pracownicy, którzy są tylko ludźmi.

Wybór narzędzi ITSM, które wspierają procesy ITIL, w tym zarządzanie incydentami jest wiele. Wybór trzeba poprzedzić analizą, która pomoże nam porównać ich możliwości z naszymi wymaganiami.

SLA

Wymagania na poziom usług, bardzo często zawierają dwa parametry: czas reakcji i czas rozwiązania. Oba one związane są z obsługą incydentów. Po pierwsze musimy je dobrze mierzyć, ustalając z biznesem ich czas rozpoczęcia i zakończenia. Częstym błędem jest pomijanie tej kwestii i liczenie czasów reakcji i rozwiązania według uznania IT, bez weryfikacji z biznesem. Rodzi to dużo sytuacji stresowych na styku IT-biznes i nie pomaga w budowaniu dobrych relacji. Opisałem to zagadnie w artykule „Jak mierzyć parametry SLA cz1”.

Musimy również pamiętać aby monitorować stopień wykorzystania czasu reakcji i rozwiązania. Tutaj pomaga nam narzędzie, które liczy upływający czas i wysyła komunikaty, zgodnie ze zdefiniowanymi regułami do osób obsługujących incydent jak i menedżerów zarządzających. Monitorowanie, pozwala podejmować działania, które zapobiegną przekroczeniu dopuszczalnych wartości czasów reakcji i naprawy. Komunikaty powinny być wysyłane, już po upłynięciu połowy czasu na obsługę.

Kategoryzacja i priorytetyzacja

Kolejnym bardzo ważnym elementem w procesie zarządzania incydentami, jest poprawne przypisanie kategorii do zgłoszonego incydentu. To jest odpowiedzialność pierwszej linii wsparcia czyli Service Desk (Help Desk). Dlaczego jest to takie ważne? Na podstawie kategorii, zgłoszenie przydzielane jest do właściwej grupy wsparcia. Jeżeli zrobimy to niepoprawnie, tracimy cenny czas rozwiązania, ponieważ incydent trafi do niewłaściwej osoby, która zwróci go ponownie do Service Desk. Może to być od 30 minut do kilku godzin, w zależności jak szybko zgłoszenie zostanie „odbite” do SD.

Równie istotne jest nadanie incydentowi właściwego priorytetu, z którym wiąże się długość czasu rozwiązania. Z jego wyborem związana jest pilność, czyli jak szybko powinien być rozwiązany oraz wpływ, czyli skutki jakie wywołuje incydent np. na ilu użytkowników oddziaływuje. Jeżeli wybierzemy za niski priorytet, może się okazać, że przy jego zmianie, upłynął już cały czas rozwiązania i mamy przekroczenie wartości dopuszczalnej czasu rozwiązania.

Eskalacja funkcjonalna i hierarchiczna

Obie eskalacje są bardzo ważne. Nie wyobrażam sobie funkcjonowania procesu zarządzania incydentami bez tych mechanizmów. Ponieważ o tym zagadnieniu napisałem oddzielny artykuł zapraszam do zapoznania się z nim „Eskalacja funkcjonalna a hierarchiczna – czy ich używasz?”.

Incydent manager

Incydent manager, to kluczowa rola dla efektywnie i sprawnie funkcjonującego procesu zarządzania incydentami. Jeżeli ktoś tego nie rozumie, niech nie oczekuje, że proces będzie działał sam. Osoba ta lub w dużych organizacjach wiele osób, pilnuje przede wszystkim aby incydenty były rozwiązywane zgodnie z SLA. Jest to szczególnie ważne, gdy dostawca zewnętrzny, musi płacić kary umowne, za nie dotrzymanie czasów reakcji lub czasu rozwiązania. To jednak nie jedyna jego rola. Incydent manager koordynuje obsługę incydentów, rozstrzyga kwestie sporne, motywuje grupy wsparcia do działania, analizuje kategorie i ilość incydentów. To bardzo ważna rola, bez której proces zarządzania incydentami, nie może działać poprawnie.

Obsługa incydentów, to ciągła gonitwa i walka o dotrzymanie SLA. Warto jednak od czasu do czasu się zatrzymać i sprawdzić czy nasz proces działa poprawnie i jest optymalnie dopasowany do naszej organizacji. To będzie wymagało wysiłku i dodatkowej pracy ale opłaci się nam ona. To zadanie również dla incydent managera, pamiętaj aby mieć go zawsze na pokładzie.

Pytanie: Co możesz poprawić w swoim procesie zarządzania incydentami?

Artykuł Czy dobrze zarządzasz incydentami? pochodzi z serwisu Mariusz Siek.

Bardzo lubię określenie z ITILa, które mówi „A fool with a tool is still a fool”. W wolnym tłumaczeniu oznacza ono, że głupiec z narzędziem jest nadal głupcem. Dlaczego tak mi się ono podoba? Pokazuje ono, żeby nie pokładać zbyt dużych nadziei w różnych narzędziach, które maja być remedium na wszystko. Narzędzie jest tylko dodatkową umiejętnością, z której trzeba umieć odpowiednio skorzystać. To nie oznacza, że wszelkie narzędzia są niepotrzebne, tylko trzeba wiedzieć jak ich prawidłowo użyć.

Narzędzia klasy ITSM

W utrzymaniu bardzo często wykorzystujemy narzędzia klasy ITSM. Jest to oprogramowanie, które w większości przypadków pomaga w:

• Obsłudze incydentów, service requestów i problemów
• Zarządzaniu zmianą
• Zarządzaniu konfiguracją
• Zarządzaniu poziomem usług

Właściwie trudno sobie wyobrazić np obsługę incydentów, w dużej organizacji, gdzie zgłoszeń jest kilkaset dziennie bez wsparcia takiego oprogramowania. Jednak aby to wsparcie było odpowiednie, należy takie narzędzie dobrze skonfigurować w szczególności w zakresie przepływu aktywności (work flow). Do tego potrzebny jest dobrze zaprojektowany proces np. obsługi incydentów, który jest dopasowany do organizacji i jej potrzeb oraz wymagań. Oczywiście można organizację dopasować do narzędzia ale w większości przypadków, nie daje to dobrego efektu.

Oprócz właściwego work flow, ważne jest odpowiednie dodanie SLA, tak aby prawidłowo liczone były czas reakcji i czas rozwiązania. Ważne jest również powiadamianie o upływającym czasie reakcji i rozwiązania, aby zespoły oraz managerowie mieli informację czy dotrzymamy wymaganego SLA.

Dobrze jest również aby obsługa narzędzia pozwalała na wybieranie wartości określonych pól ze słownika (tzw lista rozwijana). Przyśpiesza to korzystanie z narzędzia i standaryzuje wartości wprowadzane w oprogramowaniu. Łatwiej jest później analizować zgłoszenia względem różnych aspektów.

Generalnie w wyborze i konfiguracji narzędzia, powinna przyświecać zasada, że im prościej tym lepiej.

Jako przykład wybrałem proces zarządzania incydentami, ponieważ jest on najlepiej rozwinięty w różnych narzędziach. Jest to przykład procesu, który jest dobrze wspierany przez oprogramowanie. Niestety nie wszystkie procesy są tak dobrze unarzędziowione. W przypadku procesu zarządzania poziomem usług, nie spotkałem się jeszcze z narzędziem, które w kompletny sposób obsłużyłoby jego wymagania.

Narzędzia monitorowania infrastruktury sprzętowo-programowej

To druga grupa narzędzi najczęściej wykorzystywanych przez utrzymanie. Nie wyobrażam sobie aby można było zapanować nad rozbudowaną infrastrukturą bez takiego narzędzia. Wybór na rynku jest bardzo duży i możliwości również.

Wdrożenie takiego narzędzia to jednak nie tylko jego jednorazowa instalacja i konfiguracja. Ponieważ infrastruktura „żyje” i się zmienia, wymaga to również wprowadzania zmian w narzędziu monitorowania. Bez wprowadzania tych zmian, otrzymywane z narzędzia informacje szybko się zdezaktualizują.

Jednak poprawna konfiguracja narzędzia i zapewnienie komunikacji o występowaniu niepożądanych zdarzeń, nie gwarantuje, że na czas będziemy zapobiegać incydentom i awariom. Informacje dostarczane przez narzędzie należy odpowiednio wykorzystać i przygotować procedury postępowania, w przypadku pojawiania się określonych komunikatów.

Automatyzacja i robotyzacja

Obecnie, co raz częściej wykorzystujemy do obsługi procesów lub ich części automaty i roboty. To również są narzędzia, które mają nam pomagać i zwiększać efektywność działania IT. Im bardziej złożone zadanie do wykonania, tym wymagana jest większa wiedza do skonfigurowania oprogramowania do automatyzacji i robotyzacji. Takie narzędzia aby zaczęły nam pomagać muszą najpierw zostać przez nas skonfigurowane i zaprogramowane.

Głupiec nie wystarczy

Im mamy większy postęp i rozwój w narzędziach, które mają wspierać utrzymanie systemów IT, tym rosną wymagania co do umiejętności jakie trzeba posiadać aby z nich, we właściwy sposób skorzystać. Przysłowiowy „głupiec” już nie wystarczy aby obsługiwać te narzędzia. Dlatego należy pamiętać, że inwestując w narzędzia, trzeba również zainwestować w ludzi, którzy te narzędzia będą wdrażać i konfigurować oraz później z nich na co dzień korzystać. W przeciwnym wypadku wiara w moc narzędzi spowoduje, że sami okażemy się tym głupcem.

Dlatego dobrym narzędziom mówimy tak, pamiętając, że to ludzie je stworzyli i ludzie będą używać. Tylko od tych ludzi zależy czy narzędzia te zostaną użyte rewelacyjnie, poprawnie czy staną się kulą u nogi.

Pytanie: Jakie narzędzie, oprogramowanie uważasz za najlepiej wspierające Twoją codzienną pracę?

Artykuł Czy narzędzia pomogą Ci w utrzymaniu usług IT? pochodzi z serwisu Mariusz Siek.