Kiedy ITSM to za mało: sygnały, że organizacja potrzebuje ESM
W poniedziałek rano dział IT ma już długą kolejkę zgłoszeń, HR odpowiada na pytania o dostęp i onboarding przez e-mail, administracja prowadzi wnioski w arkuszu, a dział zakupów czeka na akceptacje przesyłane w wiadomościach. Każdy proces działa, dopóki nie trzeba sprawdzić, gdzie utknęła konkretna sprawa i kto właściwie odpowiada za kolejny krok. To zwykle moment, w którym porównanie ITSM vs ESM przestaje być dyskusją o terminologii, a zaczyna dotyczyć organizacji pracy.
Pytanie when to adopt ESM, czyli kiedy warto wdrożyć ESM, pojawia się nie przy okazji zakupu kolejnego narzędzia, lecz wraz z powtarzaniem się podobnych problemów operacyjnych w kilku działach. W praktyce chodzi o sprawdzenie, czy organizacja nadal zarządza pojedynczymi procesami, czy zaczyna już zarządzać wspólnym modelem usług.
ITSM vs ESM staje się realnym problemem, gdy chaos nie kończy się na dziale IT
ITSM porządkuje sposób zarządzania usługami IT: zgłoszeniami, awariami, wnioskami, zmianami, poziomami usług czy wiedzą operacyjną. Samo podejście pozostaje potrzebne również przy bardziej przekrojowym modelu obsługi. Trudność pojawia się w momencie, w którym podobnych mechanizmów potrzebują także inne działy, ale każdy z nich buduje je od początku we własnym zakresie.
HR tworzy osobny formularz do wniosków pracowniczych. Administracja prowadzi zgłoszenia dotyczące wyposażenia i dostępu do biura. Zakupy śledzich zapotrzebowania w arkuszu. Finanse proszą o dodatkowe dane przez e-mail. Dział prawny zapisuje status spraw w jeszcze innym miejscu. Z punktu widzenia poszczególnych zespołów może to wyglądać racjonalnie. Z punktu widzenia organizacji powstaje jednak kilka równoległych sposobów wykonywania bardzo podobnej pracy.
Właśnie tutaj pojawia się ESM, czyli Enterprise Service Management. Nie chodzi o „ITSM dla HR” jako prostą zmianę nazwy, lecz o wykorzystanie sprawdzonych zasad zarządzania usługami do uporządkowania procesów wewnętrznych również w innych obszarach organizacji.
Różnica ma znaczenie praktyczne. Jeżeli kolejne działy potrzebują przyjmowania wniosków, przypisywania odpowiedzialności, statusów, akceptacji, terminów i historii komunikacji, trudno uzasadnić tworzenie dla każdego z nich osobnego mini-systemu. Jeszcze trudniej później zarządzać tym jako całością.
Dobrze pokazuje to szerszy kontekst systemów ITSM: ich wartość nie wynika wyłącznie z rejestrowania zgłoszeń, ale z wprowadzenia czytelnego modelu obsługi. ESM rozszerza tę logikę tam, gdzie podobnej dyscypliny zaczynają wymagać inne funkcje biznesowe.
Pierwszym sygnałem potrzeby ESM jest powtarzanie tych samych mechanizmów w różnych działach
Najbardziej oczywistym sygnałem jest powtarzalność, która nie musi mieć nic wspólnego ze skalą przedsiębiorstwa.
Jeżeli HR, administracja, zakupy i IT niezależnie tworzą formularze, skrzynki kontaktowe, procedury przekazywania spraw i listy statusów, organizacja prawdopodobnie rozwiązuje ten sam problem kilka razy. Zmienia się nazwa wniosku, ale mechanizm pozostaje bardzo podobny: ktoś zgłasza potrzebę, ktoś ją kwalifikuje, ktoś odpowiada za wykonanie, czasem potrzebna jest akceptacja, a na końcu sprawa powinna zostać zamknięta i możliwa do odtworzenia.
Takie rozproszenie początkowo nie musi wyglądać groźnie. Jeden dział używa skrzynki e-mail, drugi formularza, trzeci arkusza. Koszt staje się widoczny dopiero wraz z rosnącą liczbą zależności pomiędzy procesami.
Dobrym przykładem jest onboarding pracownika. Z perspektywy HR proces obejmuje dane pracownika i formalności. IT odpowiada za utworzenie kont oraz przygotowanie dostępu. Administracja może zajmować się stanowiskiem pracy, identyfikatorem lub wyposażeniem. Przełożony zatwierdza zakres uprawnień, a zakupy mogą zostać włączone do procesu, jeżeli potrzebny sprzęt nie jest dostępny.
Przy obsłudze każdego z tych kroków w osobnym kanale onboarding przestaje być jednym procesem. Staje się zestawem lokalnych działań, które dotyczą tej samej osoby, ale są zarządzane niezależnie.
To właśnie taki typ zależności powinien uruchomić dyskusję o ESM. Nie chodzi o identyczny sposób pracy wszystkich działów, lecz o wspólną logikę przekazywania odpowiedzialności.
Gdy status sprawy istnieje tylko w głowie pracownika, problem nie dotyczy już narzędzia
Drugi sygnał jest mniej widoczny, ale zwykle bardziej kosztowny operacyjnie: brak wspólnej informacji o statusie sprawy.
W wielu organizacjach odpowiedź na pytanie „na jakim etapie jest ten wniosek?” wymaga napisania wiadomości do konkretnej osoby. Podczas jej nieobecności proces traci swoją widoczność. Formalnie sprawa nadal istnieje, ale organizacja nie ma prostego sposobu, aby ustalić, co zostało wykonane, czego brakuje i kto powinien działać dalej.
To ważne rozróżnienie. Problemem nie jest sam e-mail czy arkusz. Takie narzędzia mogą być wystarczające w prostych przypadkach. Problem pojawia się wraz z uzależnieniem statusu procesu od wiedzy osoby, która akurat go prowadzi, zamiast od danych dostępnych dla pozostałych uczestników.
W uporządkowanym modelu usługowym zgłoszenie lub wniosek powinien posiadać jednoznaczny stan, właściciela i historię. Dzięki temu nie trzeba odtwarzać procesu na podstawie korespondencji. W mniej zorganizowanym modelu rolę systemu pełni człowiek, który pamięta, kto otrzymał wiadomość i co powinno wydarzyć się dalej.
Takie rozwiązanie potrafi działać zaskakująco długo. Zwykle jednak do pierwszego urlopu, reorganizacji albo wyraźnego wzrostu liczby spraw.
ESM nie eliminuje konieczności odpowiedzialności po stronie ludzi. Wręcz przeciwnie: sprawia, że odpowiedzialność staje się widoczna również dla innych osób uczestniczących w procesie.
Wiele kanałów kontaktu staje się problemem, gdy prowadzą do wielu wersji tej samej sprawy
Kolejnym sygnałem jest rosnąca liczba kanałów, przez które pracownicy zgłaszają potrzeby.
Sam fakt, że organizacja korzysta z poczty, formularzy, portalu czy komunikatorów, nie oznacza jeszcze problemu. Użytkownik powinien mieć możliwość kontaktu w sposób dostosowany do sytuacji. Komplikacje zaczynają się, kiedy każdy kanał uruchamia osobny przebieg procesu.
Pracownik zgłasza problem przez e-mail. Następnie pyta o niego w komunikatorze. Po kilku dniach kontaktuje się z konkretna osobą. Ponieważ sprawa nie ma wspólnego identyfikatora, kolejne osoby zaczynają pracować na różnych fragmentach informacji. Część ustaleń znajduje się w wiadomości, część w prywatnej rozmowie, a ostateczna decyzja trafia do arkusza.
W takiej sytuacji organizacja nie ma już wielu kanałów kontaktu. Ma wiele wersji prawdy.
Podobny problem występuje w samym IT i jest szerzej opisany w kontekście przechodzenia od sortowania e-maili do zarządzania zgłoszeniami. Przy ESM mechanizm jest podobny, ale obejmuje więcej działów. Kanał wejścia może się różnić, natomiast dalsza obsługa powinna prowadzić do jednego kontrolowanego procesu.
ESM staje się potrzebne, gdy proces przechodzi przez kilka działów częściej niż sporadycznie
Najważniejsze procesy wewnętrzne rzadko respektują schemat organizacyjny.
Zmiana stanowiska pracownika może wymagać działania HR, IT, przełożonego i administracji. Zakup nowego narzędzia może przejść przez dział biznesowy, IT, bezpieczeństwo, zakupy i finanse. Zgłoszenie dotyczące dostępu może wymagać zatwierdzenia właściciela systemu, a następnie wykonania przez administratora.
W małej skali takie zależności można obsługiwać ręcznie. Potrzeba bardziej uporządkowanego modelu staje się wyraźna, kiedy procesy międzyodziałowe przestają być wyjątkiem.
W takich warunkach każda lokalna optymalizacja ma ograniczoną wartość. HR może bardzo dobrze zarządzać własną częścią procesu, ale nadal nie widzieć, czy IT wykonało kolejny krok. IT może zamknąć swoje zadanie, mimo że cała sprawa biznesowa nadal pozostaje otwarta. Przełożony może nie wiedzieć, że jego akceptacja blokuje realizację.
ESM porządkuje właśnie ten poziom. Pozwala myśleć o procesie jako o usłudze dostarczanej użytkownikowi, a nie jako o sekwencji niezależnych czynności wykonywanych przez poszczególne działy.
To subtelna zmiana, ale operacyjnie bardzo istotna. W modelu silosowym każdy zespół optymalizuje swój fragment. W modelu usługowym istotne staje się to, czy potrzeba użytkownika została obsłużona od początku do końca.
Rosnąca liczba narzędzi może ukrywać koszt większy niż sama licencja
Czasem potrzeba ESM ujawnia się podczas przeglądu aplikacji używanych przez organizację.
Okazuje się wtedy, że kilka działów korzysta z różnych systemów do formularzy, przepływów pracy, obsługi zgłoszeń lub wewnętrznych baz wiedzy. Każde narzędzie ma właściciela, konfigurację, uprawnienia, integracje i dane. Każde wymaga również utrzymania, a użytkownicy mogą potrzebować osobnych szkoleń. W efekcie koszt rozproszenia wykracza poza samą cenę licencji.
Nie oznacza to automatycznie, że należy zastąpić wszystkie aplikacje jedną platformą. Taka decyzja może być równie uproszczona jak wcześniejsze rozproszenie. Nie każdy proces nadaje się do przeniesienia do modelu ESM, a system specjalistyczny może być potrzebny ze względu na zakres funkcjonalny lub wymagania regulacyjne.
Warto jednak sprawdzić, czy część aplikacji nie istnieje wyłącznie dlatego, że poszczególne działy potrzebowały prostego mechanizmu przyjmowania i obsługi wniosków.
W tym miejscu przydaje się spojrzenie na rzeczywisty koszt systemów ITSM. Podobna logika dotyczy ESM: koszt narzędzia nie kończy się na abonamencie. Obejmuje również administrację, integracje, utrzymanie procesów, szkolenia oraz czas poświęcany na ręczne przekazywanie danych pomiędzy systemami.
ESM ma sens, jeżeli konsolidacja modelu obsługi rzeczywiście upraszcza pracę. Sama redukcja liczby aplikacji nie jest jeszcze wystarczającym uzasadnieniem.
Wdrożenie ESM nie zaczyna się od przeniesienia wszystkich działów na jedną platformę
Jednym z częstszych błędów jest traktowanie ESM jako projektu typu „wdrażamy system w całej firmie”. To zbyt szeroki punkt startowy.
Wdrożenie można rozpatrywać etapami. Na najniższym poziomie każdy dział obsługuje sprawy własnymi metodami, a przekazanie między zespołami odbywa się ręcznie. Kolejny etap rozpoczyna się wraz z opisaniem wybranych procesów i wprowadzeniem spójnych zasad przyjmowania zgłoszeń, statusów oraz odpowiedzialności.
Dopiero później warto budować wspólne katalogi usług, automatyzacje, przekrojowe raportowanie i bardziej złożone procesy międzyodziałowe.
Kolejność ma znaczenie, ponieważ ESM nie naprawi procesu, którego organizacja nie potrafi opisać. Brak jasnej odpowiedzi na pytanie, kto zatwierdza dany wniosek, nie zniknie po uruchomieniu platformy. Zostanie jedynie zapisany w bardziej uporządkowanym interfejsie.
Dlatego przed rozszerzeniem ITSM poza IT warto zacząć od kilku procesów o wysokiej powtarzalności i czytelnej odpowiedzialności. Dobrym kandydatem może być onboarding, wniosek o dostęp, zapotrzebowanie na wyposażenie albo obsługa standardowych spraw administracyjnych. Nie dlatego, że są efektowne, lecz dlatego, że łatwo sprawdzić, czy wspólny model rzeczywiście zmniejsza liczbę ręcznych przekażań odpowiedzialności.
Szerszy kontekst takiego podejścia opisuje również materiał o tym, jak rozszerzyć zarządzanie usługami poza IT bez drugiej platformy.
Gotowość do ESM widac po jakości procesu, a nie po liczbie zainteresowanych działów
Przed rozpoczęciem projektu warto sprawdzić kilka aspektów.
Przede wszystkim należy zweryfikować, czy organizacja potrafi wskazać konkretne procesy, które są powtarzalne i możliwe do oceny. Ogólne stwierdzenie „chcemy usprawnić HR” jest zbyt szerokie. Znacznie lepszym punktem odniesienia jest proces, w którym wiadomo, kto zgłasza potrzebę, jakie informacje są wymagane, kto odpowiada za realizację i kiedy sprawę można uznać za zakończoną.
Kolejnym warunkiem jest wskazanie właściciela procesu. Nie chodzi wyłącznie o administratora systemu. Ktoś musi odpowiadać za zasady działania usługi i podejmować decyzje w razie potrzeby zmiany procesu.
Istotna jest również jakość danych wejściowych. Duża liczba dodatkowych pytań przed rozpoczęciem obsługi może wskazywać, że najpierw należy uporządkować formularz i wymagane informacje.
Należy również rozdzielić procesy wspólne od procesów specjalistycznych. ESM nie oznacza, że każdy system działowy staje się zbędny. Platforma usługowa może przejąć warstwę przyjmowania i koordynowania spraw, podczas gdy właściwa realizacja nadal odbywa się w aplikacji branżowej.
Trzeba także ustalić kryteria pozwalające ocenić efekt zmiany. Może nim być lepsza widoczność statusu, mniej ręcznych przekażań, krótszy czas oczekiwania na akceptację albo bardziej spójna komunikacja. Bez takiego punktu odniesienia łatwo oceniać projekt wyłącznie po tym, czy system został uruchomiony.
W Mint Service Desk ESM można budować jako rozszerzenie uporządkowanego modelu obsługi
W takim kontekście Mint Service Desk może pełnić rolę wspólnego środowiska do obsługi wybranych procesów usługowych poza IT. Zamiast tworzyć osobny mechanizm przyjmowania spraw dla każdego działu, można porządkować zgłoszenia w ramach kolejek, typów, statusów i zdefiniowanych procesów, zachowując czytelną historię obsługi.
Znaczenie ma przede wszystkim wspólny model pracy. HR nie musi działać tak samo jak IT, a administracja nie musi kopiować procesu zakupowego. Poszczególne zespoły mogą zachować własne zasady, jednocześnie pracując w środowisku, w którym łatwiej kontrolować przekazanie odpowiedzialności i status sprawy.
Wdrożenie ESM nie powinno jednak zaczynać się od próby przeniesienia każdego procesu do systemu. Rozsądniejszym podejściem jest wybór kilku dobrze rozpoznanych usług, zdefiniowanie ich przebiegu, a następnie stopniowe rozszerzanie zakresu w obszarach, w których wspólny model przynosi realną korzyść operacyjną. Zakres dostępnych wariantów można zweryfikować na stronie cennika Mint Service Desk.
ESM ma sens, jeśli organizacja chce zarządzać usługą, a nie tylko przekazywać zadania
Nie każda firma korzystająca z ITSM potrzebuje ESM. Przy prostych, lokalnych i dobrze kontrolowanych procesach poza IT dodatkowa warstwa zarządzania może nie przynieść realnej wartości.
Sygnałem do zmiany jest dopiero powtarzający się wzorzec: podobne typy wniosków w wielu działach, brak wspólnego statusu, ręczne przekazywanie spraw, procesy przechodzące przez kilka zespołów i kolejne narzędzia tworzone tylko po to, aby utrzymać porządek w lokalnym fragmencie pracy.
W takim przypadku pytanie ITSM vs ESM nie dotyczy tego, który skrót jest bardziej aktualny. Dotyczy tego, czy organizacja chce nadal zarządzać oddzielnymi skrzynkami z zadaniami, czy zacząć zarządzać usługami od początku do końca.
O jakości procesu nie decyduje liczba automatyzacji. Ważniejsze jest to, czy wiadomo, co powinno wydarzyć się dalej, bez konieczności odtwarzania tego z wiedzy kilku osób.
