Pewnego dnia przyszedł do Ciebie szef i powiedział, że właśnie rozmawiał „z górą”. Została podjęta decyzja, że uruchamiacie profesjonalny service desk. Macie już Jira Core więc zdecydowaliście się kupić Jira Service Desk. Acha, nie ma pieniędzy na zatrudnienie firmy, która wdroży Wam JSD i przy okazji Was wyszkoli, ale to przecież niepotrzebne, no bo Ty jesteś administratorem Jira więc wszystko wiesz. Jira, to Jira, nie? Ogarniesz.
Sytuacja brzmi znajomo? Jeśli tak, to wiesz, że owszem Jira to Jira, jednak Jira Service Desk dodaje całą masę nowych funkcjonalności, które w bazowej aplikacji – Jira Core, są niedostępne. Kiedy ja zostałem poproszony o zajęcie się Jira Service Desk byłem w tej szczęśliwej sytuacji, że znałem filozofię na bazie której ta aplikacja została stworzona. To znacząco ułatwiło mi zrozumienie tego, w jaki sposób działa i jak się nią posługiwać, dzięki czemu mogłem się skoncentrować na technicznej stronie konfiguracji. Poniżej opisuję co i jak, żeby i Tobie było łatwiej.
ITSM
Funkcjonalności Jira Service Desk nie zostały zaprojektowane tak sobie, jako „widzimisię” jej twórców. Są oparte na solidnych fundamentach, o wiele starszych niż sam Atlassian. Filozofia o której mówię to ITSM czyli Information Technology Service Management. Pod tą nazwą kryje się ogół sposobów na podstawie których zespoły IT świadczą usługi swoim klientom. Mówimy tutaj o klientach wewnętrznych – użytkownikach infrastruktury IT danej organizacji, ale także o klientach zewnętrznych – tych, którzy kupują usługi firmy.
W ITSM kluczowe jest założenie, że wszystko co ma związek z IT powinno być traktowanie jako usługa. Dosłownie wszystko. Nie tylko proste działania, takie jak problemy z laptopem czy drukarką. Usługi ITSM obejmują również dostarczanie rozwiązań informatycznych będących krytycznymi dla całej organizacji. Głównym zadaniem ITSM jest dostosowanie działania IT do potrzeb biznesu.
Usługami o których mowa trzeba zarządzać. Odbywa się poprzez zestawy procesów m.in. takich jak:
- Service Request Management
- IT Asset Management
- Incident Management
- Problem Management
- Change Management
- Knowledge Management
- i wieloma innymi
ITSM to pojęcie ogólne, bardziej filozofia, która ma swoje odzwierciedlenie w różnych praktykach takich jak COBIT, VeriSM czy ITIL. Ta ostatnia jest najpopularniejsza. Do tego stopnia, że często pojęcie ITIL jest uznawane za tożsame z ITSM co jest błędem.
ITIL
Czym jest ITIL? To skrót od Information Technology Infrastructure Library. Jest to istniejący od lat 80-tych XX wieku, zbiór najpopularniejszych praktyk ITSM. Oczywiście w miarę rozwoju technologii ITIL również się zmieniał. Na przełomie 2019 i 2020 światło dzienne ujrzała najnowsza wersja oznaczona ITIL 4. Wersja ta odchodzi od sztywnego procesowego podejścia i skłania się ku tak popularnemu Agile, DevOps czy Lean IT, stawiając na piedestale dostarczanie wartości.
Jednym z elementów ITIL 4 są 34 praktyki (już nie procesy) o których wspomniałem wyżej.
Przejście z wersji 3 do 4 zdaniem wielu stanowi najpoważniejszą zmianę jaka miała miejsce w tej praktyce od lat. Myślę, że tak poważna zmiana jest zrozumiała. Technologia wokół nas się zmienia w zastraszającym tempie wymuszając również zmiany w sposobach zarządzania w IT.
Jeśli chcesz poznać podstawy ITIL 4, koncepcje takie jak Service Value System, Guiding Principles czy Four Dimension, zapraszam do pobrania mojego darmowego eBooka. Warto poznać chociażby podstawy tego, co chcąc nie chcąc w jakiś sposób Cię dotyka. A może będzie to dla Ciebie punkt wyjścia do dalszej nauki? 🙂
Jira Service Desk
Atlassian w 2011 roku certyfikował swoją aplikację pod kontem ITIL. Dokładniej mówiąc w zakresie czterech praktyk:
- Service Request Management
- Incident Management
- Problem Management
- Change Management
Certyfikat został wydany przez organizację Pink Elephant za pomocą stworzonego przez nią zestawu narzędzi Pink VERIFY™. Co to znaczy? To znaczy, że korzystając z Jira Service Desk masz pewność, że masz narzędzie, które spełnia kryteria ITSM i dzięki któremu możesz działać w duchu ITIL 4.
Poniżej parę zdań czym są te cztery praktyki.
Service Request Management
W ramach dostarczania usługi klientom będziesz mieć do czynienia z różnymi prośbami z ich strony. To właśnie jest Service Request. Na polski tłumaczy się to jako wniosek o usługę. Co bardzo ważne, wnioski nie obejmują sytuacji w których coś działało i przestało działać lub działa gorzej. Tym zajmuje się praktyka Incident Management, o której za chwilę.
To, co klient może zgłosić powinno być uprzednio określone i zatwierdzone. Dzięki temu obsługa może być sformalizowana, szybka a nawet zautomatyzowana. Nie zachodzi potrzeba zastanawiania się kto? Kiedy? Czy ma prawo? A co na to umowa? Kto ma to zatwierdzić? A ja nie wiem o co tak na prawdę mu chodzi. I tak dalej…
Niektóre wnioski mogą być bardzo proste – np. udzielenie informacji. Niektóre bardziej skomplikowane, kiedy np. dział HR wnioskuje o przygotowanie systemów dla nowego pracownika. Inne z kolei mogą wymuszać konieczność wprowadzenia zmiany w działających systemach, co z kolei wiąże je z inną praktyką – Change Enablement.
Incident Management
Celem tej praktyki jest zminimalizowanie negatywnego wpływu incydentów poprzez przywrócenie usługi do normalnego działania tak szybko jak to możliwe. Czym jest incydent?
Zgodnie z definicją ITIL 4 jest to nieplanowana przerwa w świadczeniu usługi lub pogorszenie jej parametrów.
Będziesz mieć do czynienia z incydentem kiedy np. padnie aplikacja albo baza danych, przestanie działać łącze internetowe, klienci nie będą mogli realizować płatności na stronie Twojej firmy lub klienta, drukarka odmówi posłuszeństwa.
Incydentem będzie także sytuacja, w której nastąpi pogorszenie działania usługi – „internet działa, ale wolno”, spadnie jakość odtwarzanego materiału video i wszelkie podobne sytuacje, w których usługa działa, ale nie w 100%.
Do tego rodzaju zdarzenia zaliczyć musisz także sytuację, w której nastąpiła awaria jakiegoś komponentu usługi, który nie wpłynął jeszcze na działania usługi. Przykładowo padł jeden z dysków w macierzy. W takiej sytuacji serwis działa poprawnie jednak pewien jego element nie i wymaga to podjęcia działań.
Incydenty należy rozwiązywać tak szybko jak to możliwe i jest to kluczowe. Podczas reagowania na incydent nie masz czasu na dokładną i wnikliwą analizę co się wydarzyło. Na to przyjdzie czas później. Teraz kiedy masz awarię musisz zrobić wszystko co w Twojej mocy, żeby to co przestało działać, zaczęło działać i to jak najszybciej.
Temat incydentów jest mi szczególnie bliski więc może rozwinę go przy okazji innego artykułu. A jest o czym rozmawiać. Kwestie klasyfikacji, priorytetyzacji, komunikacji wewnętrznej, zewnętrznej, działań po rozwiązaniu incydentu. Mega ciekawy temat. Na razie jednak idźmy dalej.
Problem Management
Problemem to przyczyna, albo potencjalna przyczyna jednego lub więcej incydentów. To znów definicja ITIL 4.
Problemy powodują występowanie incydentów i są z nimi ściśle powiązane jednak wymagają innego podejścia. Dlatego w ITIL 4 mamy osobną praktykę – Problem Management.
Tak jak napisałem wyżej, incydent musisz rozwiązać tak szybko jak to możliwe. Kiedy już wszystko działa, jest czas (a przynajmniej powinien być) na zastanowienie się nad tym, co spowodowało wystąpienie incydentu. Zidentyfikowanie przyczyn, przygotowanie rozwiązań tymczasowych, zwanych w nomenklaturze ITIL workarounds, lub stałych, takich które całkowicie wyeliminują występowanie incydentów w przyszłości. Jest jeszcze jednak opcja w przypadku problemu. Przeanalizujesz kwestię, poznasz przyczynę incydentu i… nic z tym nie zrobisz. Bo nie ma pieniędzy, czasu, nie jest to aż tak istotne. W takiej sytuacji mówimy o znanym błędzie (known error).
Problem Management ma trzy główne fazy:
- Problem identification. Do czynienia z problemem możesz mieć wtedy, kiedy taki sam incydent się powtarza. Informacje możesz też uzyskać zanim coś padnie. Od programistów, testerów, czy dostawcy rozwiązania.
- Problem control. Jeśli już wiesz, że masz problem to musisz ustalić jego priorytet (najczęściej na bazie ryzyka jakie ze sobą niesie) i przeanalizować. ITIL 4 proponuje analizować problemy pod kontem tak zwanych Four Dimensions.
- Error control. Na tym etapie powinieneś zidentyfikować czy istnieje jakieś permanentne rozwiązanie, czy jesteś w stanie przygotować jakiś workaround. A może uznasz, że jest to known error o niskim priorytecie?
Change Enablement
W poprzednich wersjach ITIL ta praktyka nazywała się Change Management. W obecnym kształcie jej celem jest zapewnienie, że jak największa liczba zmian wprowadzanych w środowisku usługi zakończy się sukcesem. Osiągnąć to można poprzez prawidłowe oszacowanie ryzyka, wprowadzenie mechanizmów autoryzacji wprowadzania zmian a także prawidłowego zarządzania kalendarzem zmian.
A czym jest zmiana? To dodanie, modyfikacja lub usunięcie czegokolwiek co może mieć bezpośredni lub pośredni wpływ na usługę.
ITIL 4 rozróżnia trzy rodzaje zmian:
- Standard. Zmiana, która niesie za sobą małe ryzyko a jej wprowadzenie jest najczęściej z góry zatwierdzone.
- Normal. Każda zmiana, która nie mieści się w pozostałych dwóch kategoriach.
- Emergency. Zmiana, która musi zostać przeprowadzona najszybciej jak to możliwe.
OK, powyżej w telegraficznym skrócie napisałem czym są praktyki z których został certyfikowany Jira Service Desk. Ale co to w ogóle jest ten Service Desk?
Service Desk
Zajmijmy się na chwilę koncepcją Service Desk. W ITIL 4 jest on wymieniany jako osobna, jedna z 34 praktyk. Jej zadaniem jest obsługa incydentów i wniosków o usługi. Stanowić ma także tak zwany pojedynczy punkt kontaktu (single point of contact) dla odbiorców usług.
Zgodnie z definicją Service Desk jego pracownicy powinni potwierdzić fakt zarejestrowania zgłoszenia a następnie je sklasyfikować (żeby określić kto powinien się nim zająć), wziąć za nie odpowiedzialność i podjąć działanie.
Dodam jeszcze, że Service Desk to nie to samo co Help Desk. Dokładne różnice są osobnym tematem, w tym miejscu wspomnę tylko, że Help Desk jest nastawiony na rozwiązywanie awarii, a Service Desk jest miejscem gdzie nie tylko rozwiązuje się awarie, ale można uzyskać pomoc, poradę, wskazówki dotyczące usługi. Service Desk może być odpowiedzialny za koordynowanie działań innych zespołów, których praca jest niezbędna do tego, żeby usługa była świadczona w najlepszy możliwy sposób.
W tym kontekście Help Desk może być częścią Service Desk.
W tym miejscu warto jeszcze wspomnieć, że osoby pracujące w Service Desk mogą, ale nie muszą być mocno techniczne. Najważniejszymi umiejętnościami są umiejętności analityczne, komunikacyjne, wiedza o tym jak funkcjonuje organizacja i jakie są jej priorytety oraz jakkolwiek dziwnie by to nie zabrzmiało w świecie technologii – empatia i inteligencja emocjonalna. W końcu niejednokrotnie to Service Desk będący pierwszą linią kontaktu przyczynia się w znacznym stopniu do budowania wizerunku firmy.
Incydent? Problem? Portal Klienta? WTF?!
OK, jak to wszystko ma się do Jira Service Desk, który udało Ci się właśnie zainstalować? Tworzysz projekt i widzisz wiele nowości. Powstały nowe typy zgłoszeń, na przykład Incydent i Problem. Widzisz Portal Klienta, mechanizmy pozwalające wskazanym osobom na zaakceptowanie dalszych prac nad zgłoszeniem, raporty liczące SLA i tak dalej.
To wszystko są właśnie mechanizmy pozwalające za działanie w duchu ITSM/ITIL. Porozmawiajmy o nich.
Portal klienta
Dwie kluczowe koncepcje opisywanej wcześniej praktyki Service Desk to samoobsługa (self service) oraz automatyzacja. O automatyzacji później, na razie o samoobsłudze.
Jedną z funkcjonalności Jira Service Desk jest tak zwany Portal Klienta (Customer Portal).
Na pierwszy rzut oka można powiedzieć – o fajne klienci będą mogli sobie zakładać zgłoszenia. Za Portalem Klienta jednak, jak pewnie się domyślasz, też stoi coś głębszego. Kolejna koncepcja ITSM – „Shift Left”, której założeniem jest przesuwanie obsługi serwisowej, jak sama nazwa mówi, jak najbardziej w lewo.
Shift Left
W lewo to znaczy gdzie? W stronę zgłaszającego. Obrazek rzuci na to więcej światła:
Złośliwy by powiedział, że jak nie wiadomo o co chodzi to chodzi o pieniądze. W tym przypadku owszem, redukcja kosztów jest jednym z czynników, ale nie jedynym. Shift-left jest strategią Service Desk polegającą na tym, żebyś robił wszystko, aby obsługa zgłoszeń była przesuwana jak najbliżej klienta. Dzięki temu:
- ograniczysz koszty obsługi zgłoszeń
- zredukujesz czas potrzebny na rozwiązanie zgłoszenia
- zwiększysz satysfakcję klienta
Dlaczego? Spójrz na powyższy rysunek. Im głębiej pozwolisz zgłoszeniu wniknąć w prawą stronę, tym więcej ludzi jest zaangażowanych. Ludziom trzeba zapłacić. Wzrastają koszty. Im dalej zgłoszenia trafia w głąb organizacji rośnie także czas potrzebny na jego rozwiązanie.
Jeśli przyjrzałeś się temu obrazkowi wnikliwie to zauważyłeś pewnie jeszcze jedną rzecz. Idealną sytuacją jest przesunięcie się w lewo tak daleko, żeby klient nie musiał nam nic zgłaszać. To oznacza pracę w innych obszarach niż Service Desk – projektowaniu usług, ich realizacji i wdrażania tak, żeby wszystko działało tak jak powinno. Marzenia ściętej głowy? Pewnie tak, ale stare porzekadło mówi, że do ideału się dąży, lecz nigdy go nie osiąga.
No dobra, ale co do tego ma Portal Klienta?
Jira Service Desk pozwala na podpięcie do projektów tak zwanej Knowledge base (Bazy Wiedzy). Spójrz na umieszczony wyżej zrzut ekranu Portalu Klienta. Zwróć uwagę pole wyszukiwania:
Twój użytkownik logując się do Portalu, zanim utworzy zgłoszenie może samemu poszukać informacji, które go interesują. Także w sytuacji kiedy zacznie wypełniać zgłoszenie, Jira Service Desk na podstawie wpisywanych przez niego informacji będzie sugerować poszczególne artykuły pomocy.
Dzięki temu jest szansa, że zgłoszenie klienta zostanie rozwiązane zanim jeszcze zostanie zarejestrowane.
To oczywiście wymaga po pierwsze – narzędzia Confluence, które doskonale integruje się z Jira Service Desk, a po drugie dobrze zredagowanych artykułów pomocy.
Jeśli chcesz dowiedzieć się więcej na temat Shift-left to polecam m.in. ten artykuł:
https://www.joetheitguy.com/5-tips-for-shift-left-success-on-the-it-service-desk/
Przy okazji – to podejście jest również wykorzystywane w testowaniu oprogramowania i redukcji kosztów jego wytwarzania. Możesz o tym poczytać na przykład tutaj: https://www.bmc.com/blogs/what-is-shift-left-shift-left-testing-explained/
Bazy wiedzy
Skoro już przy bazach wiedzy jesteśmy. Jira Service Desk i Confluence zapewniają szybki dostęp do wiedzy nie tylko dla Klientów. Również pracownicy Service Desk, w nomenklaturze Atlassiana nazywani Agentami mogą zyskać na tej funkcjonalności.
Kiedy użytkownik nie znalazł w Portalu Klienta potrzebnej mu informacji i założył zgłoszenie, Agent widząc je z poziomu Jira Service Desk dostaje automatyczne podpowiedzi rozwiązania z Bazy Wiedzy:
Dzięki temu czas do rozwiązania problemu znacząco się skraca. Po pierwsze nie trzeba szukać ręcznie informacji. Po drugie unikamy przesunięcia zgłoszenia w prawo.
Oczywiście warunkiem sprawnego działania tego mechanizmu, jest znów – posiadanie bazy wiedzy i sensownych artykułów. Od razu napomknę, że funkcjonalność ta pozwala na ustalenie jakie informacje mają być dostępne „na zewnątrz”, a jakie wewnątrz. Nie chcesz przecież, żeby klienci mieli dostęp do Twojej wewnętrznej dokumentacji.
Automatyzacja
To kolejny element sprawnie działającego Service Desku i strategii „shift left”. Automatyzacja pozwoli Ci na zwiększenie szybkości pracy Agentów albo wręcz wyeliminowanie ich udziału przy niektórych zadaniach. Jira Service Desk posiada wbudowane narzędzie do automatyzacji, gdzie używając prostej logiki when-if-then będziesz mógł wywoływać zdarzenia na bazie kryteriów które ustalisz.
Jeśli wbudowane narzędzie nie spełni Twoich oczekiwań, zawsze możesz poszukać jakiegoś dodatku, który zaoferuje Ci to czego szukasz. Jednym z popularniejszych jest Automation for Jira posiadający także swoją darmową wersję Automation for Jira – server lite.
Zanim jednak rzucisz się w wir automatyzowania wszystkiego co się da, zachęcam Cię do zapoznania się ITIL 4 a dokładniej Guiding Principles. Jedna z zasad Optimize and automate mówi m.in. o tym, że zanim się przystąpi do automatyzowania należy jak najbardziej zoptymalizować to, co ma być wykonywane automatycznie. Więcej o Guiding Principles przeczytasz w moim darmowym eBooku „Wprowadzenie do ITIL 4”.
Problemy
W jaki sposób możesz realizować praktykę Problem Management w Jira Service Desk? Jeśli informacja o problemie pochodzi od zespołu developerów, testerów czy dostawcy rozwiązania, możesz Ty, albo ktoś z innego zespołu założyć zgłoszenie o typie Problem. Do zgłoszenia może być podlinkowany artykuł w Confluence, który będzie opisywał błąd i czy istnieją do niego jakieś workarounds.
Kiedy pojawi się Incydent, dzięki mechanizmowi baz wiedzy opisywanemu wcześniej, informacja o problemie jaki go wywołał może automatycznie podlinkować się do zgłoszenia. Dzięki temu zespół Service Desk będzie mógł szybciej zareagować i w zależności od incydentu rozwiązać go samemu lub skierować do właściwego zespołu.
Możesz też działać w drugą stronę. Kiedy masz zarejestrowane incydenty i prawidłowo określone i skonfigurowane tak zwane komponenty (to kolejny mechanizm Jira) możesz pokusić się o analizę. Przygotuj dashboard (jeszcze jeden mechanizm Jira), który pokaże Ci ile awarii występuje w jakim komponencie. Jeśli zauważysz, że jakiś się wyróżnia pod tym względem to być może masz do czynienia z problemem?
Zmiany
Jira Service Desk dostarcza Ci także mechanizmów umożliwiających zarządzanie zmianami. M.in. mechanizm akceptowania. Co to znaczy? Jeżeli zgłoszenie wymaga czyjejś akceptacji, możesz skonfigurować workflow w taki sposób, żeby dalsza praca nad zgłoszeniem była niemożliwa bez wcześniejszego uzyskania zgody konkretnej osoby lub osób.
Wcześniej wspomniałem, że zgodnie z praktyką Change Enablement mamy do czynienia z trzema rodzajami zmian. Standardową, normalną i awaryjną. Jira Service Desk pozwala Ci obsłużyć każdy z tych rodzajów zmian.
W przypadku kiedy masz do czynienia ze zmianą standardową najczęściej jest ona już z góry zaakceptowana. Jeśli tak jest to automatyka Jira Service Desk pozwala na automatyczne zatwierdzenie zmiany i umożliwienie dalszej pracy.
Jeśli zmiana jest normalna, to w workflow możesz skonfigurować kto jest odpowiedzialny za jej zatwierdzenie. Możesz podać jedną osobę, wiele, określić czy zgodę ma wyrazić tylko jedna z wielu ,czy może wszystkie. Do zgłoszenia możesz podpiąć stronę w Confluence, która szczegółowo opisuje czego dotyczy zmiana. Co ważne osoby wskazane jako te, które mają uprawnienia do akceptacji niekoniecznie muszą mieć licencje service desk.
Zmiana awaryjna może mieć konfigurację umożliwiającą zaakceptowanie jednej z wielu osób w przypadku kiedy ktoś byłby niedostępny. Np. możesz tam dodać wszystkich dyżurnych administratorów zespołu supportowego (nigdy nie wiesz, który z nich będzie na dyżurze), którzy mogą zaakceptować wprowadzenie zmiany w razie incydentu. Z reguły jest tak, że cała dokumentacja zmiany awaryjnej jest robiona po jej wprowadzeniu.
Na koniec możesz skorzystać z dashboardu lub kalendarza w którym będziesz widzieć cały plan zmian.
Podsumowanie
Szczerze? Nie jestem zadowolony z tego artykułu 😉 Czytając go zdaje sobie sprawę jak wiele rzeczy pominąłem, jak wiele nie dopowiedziałem, jak bardzo przeskakuję pomiędzy tematami. ITSM/ITIL i zastosowanie narzędzi Atlassiana w tym obszarze jest zagadnieniem bardzo obszernym i nie sposób opisać go w jednym artykule.
Problematykę ITIL 4 częściowo rozwijam w eBooku, do zaciągnięcia którego ponownie Cię zachęcam. Dowiesz się z niego nieco więcej czym jest ITIL 4 (serio, sporo się w nim zmieniło od czasu poprzedniej wersji). Na pewno też będę chciał napisać więcej artykułów skupiających się dokładniej na tym w jaki sposób wykorzystać Jira Service Desk wraz z Confluence do pracy i wykorzystania w praktykach ITIL 4.