ESM: jak rozszerzyć zarządzanie usługami poza IT bez drugiej platformy
Pracownik wysyła wiadomość do działu HR z pytaniem o dokument, chwilę później zgłasza do administracji problem z kartą dostępu, a następnie pisze do IT, bo nie działa aplikacja. Każda sprawa trafia gdzie indziej, każda jest obsługiwana według innej logiki, a organizacja widzi jedynie fragmenty pracy. Właśnie tutaj zaczyna się praktyczny sens ESM: enterprise service management nie polega na modnym rozszerzeniu ITSM, tylko na ograniczeniu chaosu, gdy każdy dział buduje własny sposób przyjmowania i realizacji spraw.
ESM nie zaczyna się od narzędzia, tylko od powtarzalnego problemu organizacyjnego
Jednym z częstszych nieporozumień wokół ESM jest sprowadzanie go do jednego systemu przeznaczonego dla wszystkich działów. Takie ujęcie wydaje się wygodne, ale nadmiernie upraszcza problem i kieruje uwagę przede wszystkim na technologię. Tymczasem punkt wyjścia znajduje się wcześniej: organizacja ma wiele usług wewnętrznych, lecz tylko część z nich jest obsługiwana w sposób widoczny, mierzalny i kontrolowany.
Enterprise service management oznacza wykorzystanie zasad znanych z zarządzania usługami IT do porządkowania pracy także w innych obszarach organizacji. Nie chodzi przy tym o przeniesienie całego modelu ITSM do HR, finansów czy administracji, lecz o zastosowanie wspólnej logiki obsługi. Sprawa powinna trafić do właściwego zespołu, mieć jasno określoną odpowiedzialność, widoczny przebieg i sposób zakończenia. ESM porządkuje więc nie tyle same działy, ile usługi wewnętrzne i sposób, w jaki pracownicy z nich korzystają.
IT przez lata wypracowało język zgłoszeń, priorytetów, kolejek, SLA, historii komunikacji i eskalacji. Poza IT często nadal funkcjonują skrzynki e-mail, formularze, arkusze i ustalenia przekazywane między osobami. Taki model działa, dopóki spraw jest niewiele, zespół stabilny, a odpowiedzialność łatwa do ustalenia. Problem pojawia się wtedy, gdy rośnie liczba spraw, zmieniają się osoby odpowiedzialne, a menedżerowie pytają już nie tylko o zamknięcie tematu, ale także o przyczyny opóźnień.
Podejście ESM beyond IT staje się istotne, gdy organizacja zauważa, że podobne mechanizmy obsługi są potrzebne także w HR, administracji, finansach, zakupach, operacjach, obsłudze reklamacji lub innych zespołach wewnętrznych. Nie chodzi o kopiowanie IT jeden do jednego. Chodzi o przeniesienie elementów, które porządkują pracę: jedno miejsce przyjęcia sprawy, jasny status, właściciel odpowiedzialności, historia działań i możliwość raportowania.
Osobne narzędzia porządkują pracę jednego działu, ale zwiększają koszt całej organizacji
Naturalną reakcją działu, który nie ma uporządkowanego procesu obsługi spraw, jest wybór własnego narzędzia. HR wdraża system do obsługi zapytań pracowniczych, administracja korzysta z osobnego rozwiązania do zgłoszeń biurowych, dział zakupów tworzy formularze, a operacje opierają pracę na arkuszach i wiadomościach. Każde z tych rozwiązań może odpowiadać na potrzeby konkretnego zespołu. Z perspektywy całej organizacji powstaje jednak problem: każde narzędzie tworzy odrębny rejestr pracy, własny sposób raportowania i inną definicję „sprawy zamkniętej”.
Dział może więc uporządkować własną pracę, a jednocześnie zwiększyć koszt funkcjonowania całej organizacji. Dzieje się tak wtedy, gdy nowe narzędzie tworzy kolejny kanał obsługi, osobny model danych i odrębny sposób raportowania. Lokalna poprawa nie zawsze oznacza poprawę systemową. Czasem jedynie przenosi chaos do lepiej wyglądającego interfejsu.
Wdrożenie kolejnego systemu rzadko oznacza wyłącznie dodanie nowej aplikacji. W praktyce pojawia się osobny model danych, odrębne uprawnienia, inna struktura statusów, kolejny sposób mierzenia terminowości oraz dodatkowy kanał zgłoszeń dla pracowników. Gdy liczba takich rozwiązań rośnie, użytkownik nie zawsze wie, gdzie skierować sprawę, menedżer nie widzi obciążenia między działami, a organizacja traci możliwość spójnego porównywania jakości obsługi.
Największym kosztem nie musi być sam abonament za narzędzie. Obciążenie rośnie wraz z liczbą integracji, zakresem administracji, potrzebą szkoleń, rozproszonym raportowaniem, kontrolą dostępu oraz koniecznością utrzymywania spójności procesów. Warto więc ocenić, czy dany obszar rzeczywiście wymaga osobnej platformy, czy wystarczy wyodrębnić dla niego proces w ramach wspólnego środowiska obsługi.
Poza IT procesy też mają kolejki, priorytety i właścicieli, nawet jeśli nikt tak ich nie nazywa
W wielu organizacjach działy poza IT nie używają języka ITSM, ale wykonują podobną pracę. HR odpowiada na wnioski pracowników, administracja obsługuje zgłoszenia dotyczące biura, dział finansowy wyjaśnia sprawy dokumentów, a operacje koordynują zadania między zespołami. Różnica polega na tym, że te procesy często nie są opisane jako usługi, mimo że mają użytkownika, wynik, termin i osobę odpowiedzialną.
W efekcie pojawiają się powtarzalne problemy z odpowiedzialnością i kontrolą przebiegu sprawy. Nie wiadomo, kto ją przejął, czy termin został przekroczony, ani czy odpowiedź została udzielona pracownikowi, czy jedynie przekazana wewnętrznie. Jeżeli informacji trzeba szukać w skrzynce e-mail lub historii komunikatora, organizacja nie zarządza usługą, lecz odtwarza przebieg zdarzeń po fakcie.
Właśnie dlatego enterprise service management powinno zaczynać się od identyfikacji typowych spraw, a nie od projektowania rozbudowanego katalogu usług. Najpierw warto sprawdzić, jakie zgłoszenia powtarzają się najczęściej, kto je obsługuje i gdzie proces się zatrzymuje. Dopiero potem ma sens określanie formularzy, statusów, priorytetów i reguł odpowiedzialności.
Dobry kandydat do pierwszego procesu ESM nie musi być najbardziej skomplikowany. Znacznie lepiej zacząć od obszaru, w którym sprawy są powtarzalne, odpowiedzialność można jasno przypisać, a wynik obsługi da się jednoznacznie rozpoznać. Pozwala to sprawdzić, czy wspólny model rzeczywiście poprawia widoczność pracy, zanim zostanie rozszerzony na procesy z dużą liczbą wyjątków, zależności i decyzji eksperckich.
Wspólna platforma ma sens tylko wtedy, gdy nie niszczy różnic między działami
Część oporu wobec ESM wynika z obawy, że organizacja narzuci wszystkim działom sposób pracy wypracowany przez IT. Takie zastrzeżenie może być uzasadnione, jeśli projekt jest prowadzony zbyt technicznie. HR nie powinien być zmuszany do myślenia kategoriami awarii, administracja nie musi przejmować całego słownika ITIL, a dział finansowy nie powinien dostosowywąć procesu do nazw statusów, które powstały z myślą o zgłoszeniach technicznych.
Rozszerzanie zarządzania usługami poza IT powinno działać odwrotnie. Wspólna platforma ma porządkować elementy wspólne, ale pozwalać na różnice tam, gdzie wynikają one z charakteru pracy. Wspólne mogą być kanały zgłoszeń, historia komunikacji, podstawowe zasady odpowiedzialności, raportowanie oraz ślad działań. Różne powinny pozostać typy spraw, wymagane pola, ścieżki akceptacji, komunikaty do użytkowników i szczegółowe procedury.
Warto rozróżnić standaryzację od uniformizacji. Standaryzacja oznacza, że wiadomo, jak zgłoszenie trafia do organizacji, kto je przejmuje i gdzie można sprawdzić jego przebieg. Uniformizacja oznacza, że każdy dział ma pracować tak samo. Standaryzacja wzmacnia kontrolę operacyjną. Uniformizacja często prowadzi natomiast do obchodzenia systemu i powrotu do ustaleń prowadzonych poza nim.
Wspólna platforma nie musi też zastępować każdego specjalistycznego systemu. Jeżeli dany proces wymaga zaawansowanej obsługi płac, księgowości, logistyki lub danych branżowych, osobne narzędzie może nadal być uzasadnione. Granica nie przebiega więc między jednym a wieloma systemami, lecz między koordynacją sprawy a jej specjalistyczną realizacją. Wspólna platforma może rejestrować wniosek, przypisywać odpowiedzialność i prowadzić komunikację, podczas gdy właściwa operacja nadal odbywa się w systemie kadrowym, finansowym lub branżowym.
Rozproszone zgłoszenia ograniczają widoczność operacyjną
Z perspektywy kadry odpowiedzialnej za operacje i zarządzanie IT problem ESM nie dotyczy wyłącznie wygody pracowników. To także kwestia widoczności operacyjnej. Jeżeli każdy dział obsługuje sprawy w innym miejscu, trudno odpowiedzieć, gdzie rośnie obciążenie, które sprawy zajmują najwięcej czasu i gdzie powstają opóźnienia.
Raportowanie oparte na fragmentach zwykle potwierdza intuicję, ale rzadko pomaga zarządzać. Jeden dział liczy wiadomości, drugi zadania, trzeci zamknięte formularze, a czwarty opiera ocenę sytuacji głównie na bieżących obserwacjach zespołu. Dopóki organizacja nie ma wspólnego modelu rejestrowania spraw, trudno odróżnić realną poprawę od chwilowego spadku liczby wiadomości.
W tym miejscu warto odwołać się do praktyki ITSM, ale bez przenoszenia jej bezrefleksyjnie na całą firmę. Artykuł o tym, czym są systemy ITSM, dobrze pokazuje, że dojrzałość nie wynika z samej obecności narzędzia, ale z uporządkowania pracy wokół usług, odpowiedzialności i danych. ESM rozszerza tę logikę poza IT, ale nie zwalnia z myślenia procesowego.
Wspólny widok spraw ułatwia też rozmowę o priorytetach. Jeżeli każdy dział zarządza zgłoszeniami osobno, priorytet często zależy od tonu wiadomości, pozycji osoby zgłaszającej albo tego, kto akurat jest dostępny. Gdy sprawy mają status, właściciela i historię, łatwiej rozmawiać o realnym wpływie, terminach i zależnościach.
SLA poza IT wymaga innego podejścia niż w usługach technicznych
Jednym z ryzyk przy wdrażaniu ESM jest zbyt mechaniczne przenoszenie SLA poza IT. W technicznym zarządzaniu usługami SLA często dotyczy dostępności, czasu reakcji lub czasu rozwiązania. Poza IT część tych pojęć nadal ma sens, ale wymaga ostrożniejszego użycia. Nie każda sprawa administracyjna, kadrowa lub finansowa powinna być mierzona tak samo jak awaria systemu.
W praktyce warto zacząć od prostych pytań: które sprawy wymagają szybkiej reakcji, które mają termin wynikający z procedury, które zależą od akceptacji, a które są informacyjne. Dopiero wtedy można określić, czy potrzebne są formalne SLA, cele operacyjne, czy tylko widoczność czasu obsługi. W części procesów wystarczają cele obsługi i jasny termin realizacji, bez formalizowania pełnego SLA.
Sam licznik nie poprawi procesu. Może natomiast ujawnić, że proces był niejasny od początku. Problem naruszeń terminów często polega na tym, że są zauważane za późno. Jeżeli dział widzi opóźnienie dopiero wtedy, gdy użytkownik ponownie pyta o sprawę, kontrola ma charakter reaktywny. W szerszym ujęciu podobny mechanizm opisuje tekst o tym, jak brak monitoringu SLA w czasie rzeczywistym wpływa na jakość usług. W kontekście ESM najważniejszy nie jest jednak sam skrót SLA, tylko zdolność do wcześniejszego zauważenia, że sprawa utknęła.
ESM warto rozwijać etapami, zaczynając od jednego dobrze opisanego procesu
Najbezpieczniejszym sposobem rozwoju ESM jest podejście etapowe. Na początku warto wybrać jeden lub dwa obszary poza IT, w których liczba spraw jest duża, a obecny sposób obsługi powoduje widoczne tarcia. Często są to zapytania pracownicze, sprawy administracyjne, wnioski dostępowe, prośby o wyposażenie, obsługa dokumentów albo powtarzalne zgłoszenia operacyjne.
Na początkowym poziomie rozwoju dominują skrzynki e-mail i wiedza poszczególnych osób. Na kolejnym poziomie działy tworzą własne formularze i rejestry, ale organizacja nadal nie widzi wspólnego obrazu. Bardziej rozwinięty model łączy wspólne zasady przyjmowania i monitorowania spraw z odrębnością procesów poszczególnych działów.
Pierwszy etap powinien koncentrować się na uporządkowaniu sposobu przyjmowania spraw. Chodzi o to, aby użytkownik wiedział, gdzie zgłosić sprawę, a zespół otrzymywał komplet podstawowych informacji. Drugi etap dotyczy odpowiedzialności: kto przejmuje zgłoszenie, jakie są statusy, kiedy potrzebna jest akceptacja i kiedy sprawa może zostać zamknięta. Dopiero trzeci etap powinien obejmować raportowanie, automatyzację i optymalizację.
Automatyzację warto wprowadzać dopiero po uporządkowaniu odpowiedzialności i przebiegu procesu. W przeciwnym razie może ona jedynie przyspieszyć przekazywanie sprawy do niewłaściwego zespołu lub utrwalić niejasne zasady obsługi. Podobnie sam formularz nie rozwiąże problemu, jeśli wcześniej nie określono, jakie informacje są potrzebne do realizacji zgłoszenia. Dlatego lepiej najpierw zbudować jeden stabilny proces, a następnie stopniowo rozszerzać model na kolejne obszary organizacji.
Wspólne środowisko obsługi pozwala rozwijać ESM bez mnożenia narzędzi
W rzeczywistości rozwój ESM wymaga środowiska, które porządkuje obsługę spraw w różnych obszarach organizacji, ale nie narzuca wszystkim zespołom identycznego sposobu pracy. Poszczególne działy mogą zachować własne typy spraw, statusy i zasady odpowiedzialności, korzystając jednocześnie ze wspólnego miejsca do rejestrowania zgłoszeń, prowadzenia komunikacji i śledzenia postępu.
Mint Service Desk może wspierać taki model poprzez organizowanie zgłoszeń według kolejek, typów, priorytetów i statusów. Po odpowiednim skonfigurowaniu kolejek, typów zgłoszeń, statusów, uprawnień i zasad odpowiedzialności sprawy z obszaru IT, HR, administracji czy operacji mogą być obsługiwane w jednym środowisku, bez narzucania wszystkim zespołom identycznego przebiegu pracy. Wspólna platforma nie oznacza więc ujednolicenia całej organizacji, lecz zapewnienie spójnych zasad przyjmowania spraw, przypisywania odpowiedzialności i monitorowania ich realizacji.
Wspólne środowisko ogranicza zależność od skrzynek e-mail i rozproszonych ustaleń, ponieważ informacje o przebiegu sprawy pozostają powiązane ze zgłoszeniem. Narzędzie nie zastępuje jednak decyzji organizacyjnych. Jego wartość rośnie dopiero wtedy, gdy wcześniej określono, jakie sprawy mają być obsługiwane, kto za nie odpowiada i według jakich zasad powinny przebiegać.
Dlatego pierwszym krokiem nie powinno być przeniesienie wszystkich procesów do jednego systemu. Lepszym rozwiązaniem jest wybór jednego obszaru, uporządkowanie sposobu przyjmowania i realizacji spraw, a następnie stopniowe rozszerzanie modelu. W ocenie, od których procesów warto zacząć, może pomóc kontakt z zespołem Mint Service Desk.
Największą korzyścią ESM jest przejrzystość procesów między działami
Rozszerzanie zarządzania usługami poza IT przynosi największą wartość wtedy, gdy łączy rozproszone procesy we wspólnym modelu obsługi, bez odbierania poszczególnym działom ich specyfiki. Dzięki temu prośby, wiadomości i ustalenia stają się sprawami, które można przypisać, monitorować, mierzyć i systematycznie usprawniać.
Nie każda organizacja potrzebuje od razu rozbudowanego modelu enterprise service management. Wraz ze wzrostem organizacji koszt pracy wykonywanej poza kontrolowanym procesem staje się jednak coraz bardziej widoczny, choć nadal trudno przypisać go do konkretnego działu lub narzędzia. Osobny system może chwilowo uporządkować pracę jednego zespołu, ale jeśli odtwarza te same problemy w nowym środowisku, rozproszenie pozostaje bez zmian.
Wartość ESM nie polega na tym, że wszystkie działy pracują identycznie. Polega na tym, że różne działy zachowują własną logikę działania, a organizacja nadal widzi wspólny obraz obsługi. Najbardziej dojrzały proces często jest po prostu tym, którego nie trzeba odtwarzać z pamięci po fakcie.
