Poznaj 6 najczęstszych wyzwań wdrożenia ITSM. Nie są to problemy, błędy czy krytyka kierowana w stronę klientów – raczej wskazówki, które mają uczulić na niektóre kwestie podczas rozmów o implementacji rozwiązania ITSM.
Artykuł jest związany z szóstym odcinkiem podcastu „ITSM od podstaw”, dołącz do grona słuchaczy:
Podczas nagrań przeszliśmy wspólnie od podstawowych pojęć, do opisów najważniejszych czynności i procesów związanych z ITSM. Jeśli przesłuchaliście wszystkie odcinki, a dodatkowo przeczytaliście blogposty, które są z nimi związane, jesteście uzbrojeni w wiedzę potrzebną do rozmów o ITSM. Ostatnim etapem jest przekazanie Wam wskazówek, dzięki którym łatwiej zapanujecie nad różnymi sytuacjami i wyzwaniami w czasie wdrożenia. Zaczynajmy.
1. Brak zaangażowania
To określenie może odnosić się do różnych sytuacji. Jedną z nich jest brak zaangażowania zespołu po stronie klienta – tzn. brak zaangażowania osób odpowiedzialnych za kształt, jaki procesy wdrożone w ITSM powinny przybrać, żeby zaspokoić potrzeby firmy. Kryje się pod tym przekładanie lub nieprzychodzenie na spotkania czy niewywiązywanie się z ustalonych zadań. Takie zachowanie powoduje wydłużenie czasu realizacji projektu, ryzyko błędów i perspektywę powtarzających się poprawek. A na tym nie zależy ani nam jako dostawcy, ani zleceniodawcy.
Innym przypadkiem jest unikanie dołączenia do rozmów jakiejś osoby lub zespołu, o czym wspominałem w odcinku czwartym i w tekście: ITSM: Analiza biznesowa. 4 najczęstsze wyzwania.
Rekomendacja: nawet jeśli obawiacie się kogoś włączyć do projektu, bo może utrudniać rozmowy, to mimo wszystko powinniście to zrobić. Dzięki temu unikniecie sytuacji, gdy ktoś pojawia się na zaawansowanym etapie i całkowicie zmienia koncepcję, przez co prace wracają do punktu wyjścia.
Trzecią sytuacją jest brak zaangażowania wykonawcy, czyli skupienie się na otrzymaniu zapłaty, a niekoniecznie na wdrożeniu wartościowego rozwiązania. Nie byłbym sprawiedliwy, pomijając taki scenariusz, a z rozmów z klientami wynika, że to wcale nie są rzadkie przypadki. Jeśli firma, której zleciliście wdrożenie rozwiązania ITSM nie dopytuje o nic w zakresie wymagań, nie próbuje dokładnie zrozumieć procesów, nie wnika w to jak działają – to coś jest nie tak.
Rekomendacja: podczas wdrożenia najważniejsza jest współpraca – klient nie musi mieć doświadczenia czy bardzo dobrej znajomości ITIL i dobrych praktyk. To nasza rola. Jako wykonawca mamy budować świadomość rozwiązania, rekomendować najlepsze praktyki w odniesieniu do potrzeb klienta, czasem musimy coś odradzić, wiedząc, że pomysł po prostu się nie sprawdzi. Zaangażowanie musi być po obu stronach.
2. Stawianie nieprzemyślanych wymagań względem systemu
Częstym utrudnieniem jest także stawianie nieprzemyślanych wymagań względem systemu. Rozumiem przez to między innymi tworzenie bardzo zawiłych ścieżek procesowych oraz nierzeczywiste wymagania tzn. oczekiwanie, że rozwiązanie od początku będzie obsługiwało ogromną ilość procesów dla kilku lub kilkunastu oddziałów firmy jednocześnie. Takie podejście nie jest dobre przynajmniej z dwóch, głównych powodów:
- Im wyższy próg wejścia (czyli im większa trudność nauki nowego rozwiązania), tym większa niechęć pracowników i dłuższy czas opanowania narzędzia.
- Im więcej procesów wdrożonych jednocześnie, tym bardziej skomplikowane, dłuższe testy, większe ryzyko błędów oraz trudniejszy rozwój infrastruktury o kolejne elementy.
Wysoki stopień skomplikowania i bardzo duża ilość procesów wdrożonych jednocześnie, wiążą się także z ogromnymi nakładami pracy nad dokumentacją – należy sporządzić mnóstwo opisów procesów, funkcjonalności, przepływów informacji co często okazuje się niepraktyczne i niepotrzebne (chociaż dokumentacja sama w sobie jest kluczowa, nie odbierajcie tego jako krytyki dokumentacji jako takiej!). Z kolei zbyt duża ilość automatyzacji może zablokować elastyczność procesu, ograniczyć możliwości wykonania czynności w systemie dla danej roli, opóźnić czas obsługi czy uniemożliwić reakcję w nagłych, wyjątkowych sytuacjach.
Nieprzemyślanym wymaganiem bywa też oczekiwanie ogromnej ilości customizacji z pominięciem dostępnych na rynku rozwiązań. W takim wypadku praca jest wykonywana niepotrzebnie, ponieważ już ktoś daną funkcjonalność stworzył, nie ma sensu tracić na to czasu i środków.
Rekomendacja: metoda małych kroków daje znacznie lepsze rezultaty zarówno pod kątem technicznym – bo łatwiej jest przetestować, wdrożyć, a potem uzupełnić mniejsze składowe, niż zajmować się od razu bardzo rozbudowanym systemem; jak i z punktu widzenia pracowników, którzy muszą się do nowego rozwiązania przyzwyczaić, opanować wszystkie ścieżki przepływu informacji i oswoić z nowym sposobem pracy.
3. Standaryzacja bez marginesu na wyjątki
Usilne dążenie do ustandaryzowania wszystkich czynności tak, żeby dla każdego działały w ten sam sposób, może powodować zamieszanie. Nie każdy zespół ma bowiem takie same potrzeby i model działania; dobrze jest zachować przestrzeń na wprowadzenie wyjątków czy zmian. Czasami musimy też nagiąć najlepsze, idealne w teorii zasady do specyfiki działania firmy; zostawić pole do ewentualnych lub planowanych usprawnień, których w danym momencie firma jeszcze nie posiada, natomiast wie, że z biegiem czasu do nich dojrzeje.
Rekomendacja: Kierujmy się dobrymi praktykami z zakresu ITIL świadomie i jednocześnie elastycznie. Czasami konieczne jest odejście od wzorcowego modelu. Na pierwszym miejscu stawiajmy wartość i cele, jakie ma spełniać rozwiązanie dla firmy.
4. Brak budowania świadomości nowego rozwiązania wśród pracowników
Pracownicy nie lubią zmian, a nowe narzędzia wymagają nauki i wypracowania innych nawyków. Będą też powodowały dyskomfort z powodu np. braku możliwości przejścia z daną czynnością dalej, bez otrzymania akceptacji przełożonego lub przez usprawnione rozwiązania do monitorowania czasu pracy potrzebnego na wykonanie danej usługi. Jeśli zespoły mają zmienić narzędzia pracy, powinny wiedzieć, z czego to wynika, jaki jest cel zmian i do czego dąży organizacja.
Rekomendacja: firma powinna zaplanować komunikację dotyczącą zmian i postępów nad ich wprowadzaniem. Szkolenie z nowych narzędzi to konieczność, nie może natomiast być jedynym działaniem związanym z budowaniem świadomości nowego rozwiązania.
5. Brak środowiska testowego i testów
Dużym niedopatrzeniem jest brak środowiska testowego i samych testów rozwiązania. Na szczęście są to sytuacje marginalne. Firma powinna przetestować wszystkie wdrożone procesy w środowisku testowym, czyli zanim trafią na produkcję. Dzięki temu identyfikujemy i poprawiamy ewentualne błędy.
6. Migracja ze starego narzędzia, do nowego
Brzmi niewinnie, ale przenoszenie starych zgłoszeń procedowanych wcześniej w inny sposób niż będzie się to odbywało po wdrożeniu zmian, może bardzo skomplikować proces obsługi. Niesie też ryzyko utraty danych.
Rekomendacja: stare zgłoszenia lepiej zarchiwizować i zachować w pierwotnym stanie, niż próbować je dopasować do nowego środowiska. Podobnie obecne, aktualne zgłoszenia – powinny dokończyć cykl życia w wygaszanym narzędziu; nowe narzędzie potraktujmy jak czystą kartkę i nie zaśmiecajmy jej niepotrzebnymi danymi.
Podsumowanie – wskazówki:
Na koniec przekazuję jeszcze kilka dodatkowych wskazówek:
- Nie podchodźcie do wdrożenia ITSM jak do czynności jednorazowej. Jeśli tak to potraktujecie, nie będziecie gotowi na prawidłowe utrzymanie i rozwój tego rozwiązania.
- Nie bójcie się angażować siebie i innych. Postawcie na komunikację, bo nawet najlepsze algorytmy nie zastąpią ludzi.
- Zwróćcie się do partnerów, którzy mają w portfolio wdrożenia ITSM. Pytajcie, dyskutujcie, korzystajcie z ich doświadczenia. ITSM obejmuje wiele obszarów i coś, co wydaje się niepotrzebne dziś, jutro może być pożądane. Doświadczeni wdrożeniowcy są w stanie takie kwestie zauważyć.
- Nie wszystko na raz: konsekwentne, rozłożone w czasie wygaszanie starego narzędzia i wdrożenie nowego krok po kroku, usługa po usłudze, według przyjętych kryteriów to najlepszy sposób na przejście do ITSM.
Zachęcam Was do zapisania się na listę odbiorców podcastu na temat ITSM – nie tylko dla samych nagrań, ale także dla uzyskania dodatkowych materiałów i informacji o kolejnych działaniach. Możecie tego dokonać, klikając w baner:
Pozostałe wpisy z serii:
- Czym jest ITSM? Wprowadzenie do systemu typu IT Service Management
- Wprowadzenie do ITSM: pojęcia, które musisz znać rozmawiając o rozwiązaniu IT Service Management
- Tworzenie katalogu usług w systemie ITSM
- Proces budowy usługi w ITSM
- Analiza biznesowa. 4 najczęstsze wyzwania
- Incydent i zmiana – dlaczego ważna jest synergia tych procesów