Proces jest pojęciem bardzo ogólnym: każdy z nas ma jakieś wyobrażenie, jak go zdefiniować. Jedno jest pewne – w wielu organizacjach, czy zdajemy sobie z tego sprawę, czy nie, większość z procesów ITSM już działa. Lepiej lub gorzej, w mniej czy bardziej zamierzony sposób, ale gdzieś już tam istnieją.
Powiedzmy, że mamy aplikację; w sekcji “Pomoc” czytamy: “W razie problemów wyślij maila na podany adres”. To nic innego, jak bardzo podstawowa wersja Incident Managementu.
Procesy najczęściej trzeba usprawniać i optymalizować, a nie ustawiać od nowa, dlatego lubię wracać do jednego z moich ulubionych cytatów:
“Nie można zrozumieć procesu przez zatrzymanie go. Zrozumienie musi podążać z biegiem procesu, musi przyłączyć się i płynąć razem z nim” – Frank Herbert, “Diuna”.
To samo ma zastosowanie w świecie IT Service Managementu. Czy to zarządzanie incydentami, czy problemami, te procesy istnieją (w jakiejś formie) praktycznie w każdej organizacji, lecz wszędzie też jest możliwość ich optymalizacji.
Czym jest proces z definicji? Encyklopedia zarządzania mówi, że “proces w organizacji i zarządzaniu najczęściej definiowany jest jako zbiór czynności, wzajemnie ze sobą powiązanych, których realizacja jest niezbędna dla uzyskania określonego rezultatu”[1]. Definicja ta doskonale oddaje istotę procesów ITSM. Żeby efektywnie osiągać zamierzone rezultaty, potrzebne są pewne konkretne kroki. Procesy ITSM pomagają w zarządzaniu usługami informatycznymi. Wspierają możliwości i wydajność organizacji oraz działania, podejmowane w przypadku zmian czy problemów z usługami.
Istnieje wiele procesów ITSM, przybierają one różne formy. Wybrałem osiem procesów, które – z mojego punktu widzenia – są najważniejsze:
- Incident Management,
- Problem Management,
- Request Management (Fulfillment),
- Knowledge Management,
- Change Management,
- Release and Deployment Management,
- Service Level Management,
- (Service Asset and) Configuration Management.
Pierwsze cztery opiszę w tym, pozostałe – w następnym artykule.
Procesy vs. praktyki
Gwoli wyjaśnienia: poruszamy się w terminologii ITIL [2], musimy więc odróżnić procesy od praktyk. Skupię się na procesach, ponieważ zarówno my, jak i nasi klienci czy partnerzy używamy tego określenia. Pojęcie praktyk pojawia się w nowej wersji ITIL (4).
Ale czym w sumie jest praktyka i jaki jest jej związek z procesem? Proste wyjaśnienie tej koncepcji byłoby najwygodniejsze: proces = praktyka. Jednakże w ITIL 4 założenie jest odrobinę bardziej skomplikowane niż „od teraz zamiast określenia 'proces’ używaj słowa 'praktyka’”. Procesy i funkcje opisane w ITIL V3 zostały uwzględnione w ITIL 4 jako praktyki. Pozwala to uniknąć częstych rozbieżności między ITIL a codziennością. Wiele organizacji stosowało to, co ITIL V3 określa mianem procesów, ale istniały również funkcje o tej samej nazwie.
ITIL 4 definiuje zarówno proces, jak i praktykę i “pozwala” na używanie obu terminów. Praktyka to “zestaw zasobów organizacyjnych przeznaczonych do wykonywania pracy lub osiągania celu”, proces z kolei to “zestaw (…) działań, które przekształcają dane wejściowe w dane wyjściowe”. Już z tych definicji wynika, że procesem jest to, co jest robione, a praktyka dotyczy tego, kto i jak to robi. Oznacza to, że „praktyka” bardziej przypomina „funkcję” z ITIL V3, ale z jedną różnicą: ten zestaw zasobów został teraz „zaprojektowany” konkretnie do wykonania danego zadania.
Najważniejsze procesy ITSM
Incident Management
Jest to jeden z najważniejszych i najczęściej stosowanych w praktyce procesów ITSM.
Ale czym właściwie jest incydent?
ITIL definiuje go jako “nieplanowaną przerwę w usłudze informatycznej lub obniżenie jakości usługi informatycznej”. Jednocześnie zwraca uwagę, że incydentem może być również coś, co nie jest widoczne dla użytkownika, np. awaria jednego z komponentów, wykryta przez narzędzia monitorujące system.
Głównym celem zarządzania incydentami jest jak najszybsze przywrócenie normalnego działania usługi przy jednoczesnym zminimalizowaniu negatywnego wpływu na działalność biznesową. “Normalne działanie” z kolei powinno być zdefiniowane w ramach umowy SLA [3].
Dlaczego warto wdrożyć Incident Management?
W świecie IT incydenty zawsze będą się zdarzać, nie da się ich uniknąć. Odpowiednio zdefiniowany proces pozwala jak najszybciej przywrócić prawidłowe działanie usługi, minimalizując koszt biznesowy. Brak takiego procesu wydłuża czas usuwania usterki, co realnie przekłada się na większe koszty dla organizacji. Incident Management pozwala w sposób ustrukturyzowany podejść do tego zagadnienia i zapewnić odpowiednią jakość dostarczanych usług.
Problem Management
To kolejny bardzo ważny proces w zarządzaniu usługami. Problem Management i Incident Management są ze sobą blisko związane. Czym jest problem? To przyczyna jednego lub wielu incydentów. Problem Management odpowiada za badanie i diagnozę tej przyczyny.
Cele:
- Zapobieganie problemom i wynikającym z nich incydentom.
- Eliminowanie powtarzających się incydentów.
- Minimalizowanie wpływu incydentów, którym nie można zapobiec.
Zakres:
- Diagnozowanie pierwotnej przyczyny incydentów i określanie sposobu rozwiązywania związanych z nimi problemów.
- Zapewnienie obejścia problemu (workaround), tak aby zminimalizować wpływ incydentów na usługę.
- Przeprowadzenie przeglądu powdrożeniowego w celu zapewnienia, że zmiany rozwiązały problemy (i nie generują nowych).
- Przechowywanie informacji związanych z problemami, w tym obejść i dostarczonych rozwiązań.
- Aktualizacja bazy wiedzy, tak aby informacja o rozwiązaniu była dostępna dla wszystkich pracowników wsparcia technicznego.
- Ujednolicenie z zarządzaniem incydentami przy użyciu tej samej kategoryzacji, co ułatwia komunikację między tymi dwoma procesami.
Request Management (Fulfilment)
Proces ten dotyczy rozwiązywania formalnych zapytań od użytkowników. Gdy użytkownik zgłasza zapytanie: o zmianę hasła, nowy sprzęt, oprogramowanie lub cokolwiek innego, czego potrzebuje (naturalnie, w ramach usługi) – nazywa się to Service Requestem.
Formalna definicja zgłoszenia serwisowego to „prośba użytkownika o informację, poradę, standardową zmianę lub dostęp do usługi”. Czym więc jest zmiana standardowa? To po prostu zmiana wstępnie zatwierdzona, która jest obarczona niskim ryzykiem i przebiega zgodnie ze standardową procedurą.
Ogólnie rzecz biorąc, zgłoszenia serwisowe są często obarczone mniejszym ryzykiem i wymagają mniejszej liczby formalności.
W rzeczywistości wiele zgłoszeń może dotyczyć sytuacji, które zostały już wstępnie zatwierdzone (na przykład przyznanie dostępu do drukarki, uaktualnienie laptopa do najnowszej wersji zatwierdzonego wcześniej pakietu oprogramowania produkcyjnego firmy itd.). Tego typu żądania są częste (ale też mniej ryzykowne niż incydenty), ITIL odróżnia je więc i sugeruje, aby stosować do nich odrębny zestaw procesów.
W związku z tym niniejszy proces jest po prostu procesem obsługi zgłoszeń serwisowych (Service Requests).
Knowledge Management
Na deser jeden z moich ulubionych (a często zaniedbanych) procesów: zarządzanie wiedzą.
Wiedza, którą dysponuje organizacja, często jest imponująca. Wiedzy przybywa wraz z rozwojem firmy, poszerzaniem obszaru działania, zmianą podejścia do biznesu. Ten kapitał jest dla firmy bezcenny, a jego przekazywanie nowym lub mniej doświadczonym pracownikom to jeden z warunków skutecznego działania. Niestety, ten potencjał nie zawsze jest wykorzystywany. Wiedza bywa “uśpiona”, bo nie wychodzi poza ramy działu albo pozostaje nieodkrytym “skarbem” pracownika.
Zarządzanie wiedzą pomaga dotrzeć do jej ukrytych zasobów, przechowywać je i udostępniać w organizacji, co przynosi wymierne korzyści biznesowe. Podstawowym celem tego procesu jest ułatwienie kontaktu – tym pracownikom, którzy poszukują informacji z tymi, którzy ją mają.
W odniesieniu do IT Service Managementu zarządzanie wiedzą jest zawarte w innych procesach zarządzania usługami. Sam proces gwarantuje, że wszystkie informacje wykorzystywane w zarządzaniu usługami informatycznymi, przechowywane w systemie zarządzania wiedzą o usługach, są spójne i łatwo dostępne.
Dotarliśmy do półmetka: za nami pierwsze cztery procesy. Zgodnie z zapowiedzią, cztery pozostałe opiszę w następnym artykule. A może już teraz macie do mnie pytania, dotyczące nie tylko procesów, ale ogólnie IT Service Managementu? Piszcie do mnie!
Bibliografia:
[1] – https://mfiles.pl/pl/index.php/Proces
[2] – Information Technology Infrastructure Library
[3] – Service Level Agreement – Umowa między dostawcą usług IT a ich odbiorcą. Opisuje usługę, dokumentuje docelowy poziom świadczenia usługi, określa obowiązki dostawcy usług.
- Service Management Team Manager
-
Doświadczenie w branży IT zdobywa od 14 lat, przede wszystkim w roli Service Managera. W Craftware od prawie 5 lat, do niedawna leader zespołu SM, obecnie jego manager. Aktualnie zajmuje się usługami dla sektora farmaceutycznego, ale, jak mówi, inne branże i kultury (jak np. kultura koreańska) nie są mu obce. Jako Service Manager skupia się głównie na zagadnieniach operacyjnych, ale project management również jest mu znajomy. Najważniejszą wartością dla niego w każdym aspekcie zawsze będą ludzie.
