Workflow automation: 5 procesów, które warto zautomatyzować od razu po wdrożeniu Mint Service Desk
Pracownik wysyła wniosek o dostęp do aplikacji, ale zgłoszenie przez kilka godzin czeka w niewłaściwej kolejce. Agent przekazuje je do administratora, uzupełnia kategorię i prosi o informacje, których zabrakło w formularzu. Automatyzacja przepływów pracy, określana również jako workflow automation, powinna eliminować właśnie taką pracę: przewidywalną, powtarzalną i niewymagającą każdorazowo nowej decyzji.
Nie oznacza to jednak, że pierwsze reguły należy uruchamiać bezpośrednio po technicznym wdrożeniu systemu. Najpierw warto sprawdzić, czy proces jest wystarczająco uporządkowany, aby automatyzacja nie utrwaliła jego błędów. Narzędzie może przyspieszyć obieg spraw, ale nie zastąpi decyzji o tym, kto odpowiada za proces, jakie dane są potrzebne i kiedy zgłoszenie można uznać za zakończone.
Automatyzacja nie naprawia procesu, którego nikt wcześniej nie uporządkował
Pierwsze trudności pojawiają się jeszcze przed skonfigurowaniem reguł automatyzacji. Organizacja próbuje zautomatyzować sposób pracy, który funkcjonuje głównie w pamięci pracowników, wiadomościach e-mail i ustnych ustaleniach.
Workflow, czyli uporządkowany przebieg działań, określa, co dzieje się ze zgłoszeniem od momentu jego utworzenia do zakończenia obsługi. Może obejmować kolejne statusy, przypisania, decyzje, akceptacje oraz działania uruchamiane po spełnieniu określonych warunków. Aby można było go zautomatyzować, jego logika musi być jednoznaczna i zrozumiała dla wszystkich uczestników procesu.
Zgłoszenie dotyczące dostępu może zostać zaklasyfikowane jako problem techniczny, zamówienie usługi albo wniosek wymagający zatwierdzenia. Każda z tych ścieżek może ostatecznie prowadzić do przyznania uprawnienia, ale trudno zbudować na ich podstawie jeden stabilny mechanizm automatyzacji.
Przed uruchomieniem workflow warto opisać zdarzenie rozpoczynające proces, wymagane dane, właściciela kolejnego kroku, warunki zmiany statusu oraz wyjątki wymagające decyzji człowieka. Nie wiąże się to z koniecznością tworzenia rozbudowanych diagramów. Wystarczy ustalić, które działania zawsze przebiegają tak samo, a które zależą od kontekstu.
Automatyzować należy przede wszystkim część przewidywalną. Decyzje wymagające oceny ryzyka, interpretacji sytuacji lub uzgodnienia między działami powinny nadal należeć do wskazanej osoby. System może wykonać określone działanie po spełnieniu warunków, ale nie ustali samodzielnie, kto powinien być właścicielem źle zdefiniowanego procesu.
W tym sensie workflow automation jest częścią szerszej logiki zarządzania usługami. Dobrze pokazuje to artykuł o tym, czym są systemy ITSM: wartość systemu nie wynika wyłącznie z rejestrowania zgłoszeń, ale z uporządkowania odpowiedzialności, danych i przebiegu pracy.
Pierwszy workflow powinien być łatwy do sprawdzenia
Po wdrożeniu systemu łatwo zacząć od najbardziej rozbudowanych procesów. Wieloetapowy onboarding albo obsługa poważnej awarii dobrze pokazują możliwości platformy, ale nie zawsze są właściwym punktem startowym.
Pierwsze automatyzacje powinny dotyczyć spraw częstych, powtarzalnych i łatwych do zweryfikowania. Dobrze wybrany proces pozwala szybko sprawdzić, czy reguły wykonują właściwe działania, formularze zbierają potrzebne dane, a pracownicy rozumieją nowy sposób obsługi.
Warto ocenić, czy przebieg sprawy jest podobny w większości przypadków, czy dane można zebrać w formularzu, czy odpowiedzialność za poszczególne etapy jest znana oraz czy pomyłkę można szybko wykryć. Im więcej odpowiedzi twierdzących, tym bardziej dany proces nadaje się do objęcia pierwszą automatyzacją.
Po uruchomieniu reguły należy również sprawdzić, czy zmniejszyła liczbę ręcznych przekazań, czy zgłoszenia trafiają do właściwego zespołu oraz czy agenci nie muszą regularnie omijać jej działania. Automatyzacja, którą stale trzeba korygować ręcznie, zwykle nie rozwiązuje problemu. Przenosi go jedynie do konfiguracji.
Z perspektywy kosztów wdrożenia jest to szczególnie ważne. Każda reguła, która wymaga ciągłego poprawiania, zwiększa rzeczywisty koszt utrzymania systemu. Podobny mechanizm opisuje artykuł o tym, co firmy liczą źle, analizując prawdziwy TCO systemów ITSM.
1. Workflow automation najlepiej zacząć od standardowych wniosków wewnętrznych
Wnioski o dostęp, sprzęt, instalację oprogramowania, dokument lub zmianę danych zwykle rozpoczynają się podobnie. Pracownik opisuje potrzebę, wskazuje podstawowe parametry i oczekuje przekazania sprawy do właściwej osoby.
Mimo to pierwszy etap obsługi często polega na ręcznym czytaniu wiadomości i ustalaniu, kto powinien się nimi zająć. Dział wsparcia staje się wtedy skrzynką rozdzielczą z lepszym interfejsem.
Podstawą automatyzacji wniosków wewnętrznych powinny być odpowiednio zaprojektowane formularze. Wybór rodzaju sprawy, lokalizacji, systemu lub jednostki organizacyjnej może uruchamiać wcześniej określone działania. Zgłoszenie trafia wtedy do właściwej kolejki, otrzymuje odpowiedni typ, priorytet albo zestaw danych potrzebnych do rozpoczęcia obsługi.
Przykładowa logika może wyglądać następująco: pracownik wybiera wniosek o dostęp, wskazuje system i jednostkę organizacyjną, a zgłoszenie zostaje przypisane do zespołu odpowiedzialnego za daną aplikację.
Podstawą stabilnej automatyzacji powinny być dane zapisane w określonych polach, a nie swobodny opis zgłoszenia. Rozpoznawanie intencji na podstawie treści należy traktować jako odrębny mechanizm, a nie domyślną cechę standardowego workflow.
Formularz nie powinien jednak przypominać ankiety urzędowej. Należy zbierać wyłącznie informacje potrzebne do rozpoczęcia obsługi. Najważniejsze jest, aby zgłoszenie od początku trafiało do zespołu odpowiedzialnego za jego realizację.
2. Onboarding i offboarding wymagają koordynacji między zespołami
Onboarding obejmuje działania związane z przygotowaniem nowego pracownika do rozpoczęcia pracy, a offboarding porządkuje czynności wykonywane przy zakończeniu współpracy.
Przyjęcie lub odejście pracownika angażuje zwykle kilka działów. HR zna termin, przełożony określa potrzebne dostępy, IT przygotowuje konta i urządzenia, a administracja odpowiada za kartę wejściową lub miejsce pracy.
Bez uporządkowanego procesu każda ze stron realizuje własny fragment na podstawie osobnej wiadomości. Zmiana terminu nie zawsze dociera do wszystkich, a brak jednego działania wychodzi na jaw dopiero w pierwszym dniu pracy albo po zakończeniu współpracy.
Po zarejestrowaniu wniosku onboardingowego lub offboardingowego uporządkowany workflow może rozpocząć wcześniej uzgodnione działania. Na podstawie danych z formularza można określić zakres zadań dla zaangażowanych zespołów, przypisać odpowiedzialność i zachować wspólny punkt odniesienia dla całego procesu.
Przykładowo wskazanie stanowiska, lokalizacji i daty rozpoczęcia pracy może stanowić podstawę do rozpoczęcia działań związanych z przygotowaniem konta, urządzenia, miejsca pracy oraz podstawowych uprawnień.
Zakres czynności nie musi być identyczny dla każdego pracownika. Może zależeć od stanowiska, lokalizacji lub rodzaju umowy. Warto jednak oddzielić elementy standardowe od decyzji indywidualnych. Przygotowanie podstawowego konta i urządzenia może stanowić część powtarzalną. Dostępy administracyjne, niestandardowe wyposażenie albo dodatkowe licencje mogą wymagać zatwierdzenia.
Workflow nie powinien usuwać punktów kontrolnych. Powinien wskazywać, gdzie się znajdują i kto podejmuje decyzję.
Takie podejście wpisuje się w szerszy model ESM, czyli rozszerzenia zarządzania usługami poza IT bez wdrażania drugiej platformy. Wspólne środowisko nie powinno zmuszać wszystkich działów do identycznej pracy, lecz zapewniać widoczność odpowiedzialności i kolejnych etapów procesu. Więcej o takim podejściu opisuje artykuł o tym, jak rozszerzyć zarządzanie usługami poza IT bez drugiej platformy.
3. Akceptacje powinny zatrzymywać właściwe sprawy, a nie cały proces
Wnioski dotyczące zakupu, nowych uprawnień lub zmian w systemach często wymagają zatwierdzenia. Trudność pojawia się, gdy akceptacja odbywa się poza systemem obsługi zgłoszeń.
Agent wysyła wiadomość do przełożonego, po kilku dniach ponawia prośbę, a następnie próbuje ustalić, czy brak odpowiedzi oznacza odmowę, przeoczenie czy nieobecność. Zgłoszenie pozostaje otwarte, ale nie wiadomo, czy ktokolwiek rzeczywiście nad nim pracuje.
Dobrze zaprojektowany workflow powinien określać, które sprawy wymagają zatwierdzenia, kto może podjąć decyzję, jakie informacje musi otrzymać oraz co dzieje się po akceptacji lub odrzuceniu.
Przykładowa logika może obejmować zatrzymanie wniosku o uprawnienie administracyjne, przekazanie go do osoby zatwierdzającej oraz skierowanie do realizacji dopiero po podjęciu pozytywnej decyzji.
Standardowy dostęp zgodny z rolą pracownika może być obsługiwany inaczej niż uprawnienie o podwyższonym poziomie ryzyka. Niewielki zakup może podlegać innej kontroli niż licencja obejmująca cały zespół.
Automatyzacja akceptacji jest uzasadniona, gdy odzwierciedla realne zasady decyzyjne. Dodawanie zatwierdzenia „na wszelki wypadek” tylko wydłuża proces. Celem nie jest maksymalizowanie liczby etapów, lecz zatrzymanie dokładnie tych spraw, w których decyzja jest rzeczywiście potrzebna.
4. Brak odpowiedzi nie powinien pozostawiać zgłoszenia bez kolejnego kroku
Część zgłoszeń nie jest opóźniona dlatego, że zespół nie potrafi ich rozwiązać. Sprawy zatrzymują się, ponieważ brakuje informacji od użytkownika, decyzji przełożonego albo odpowiedzi innego zespołu.
Bez reguł czasowych takie zgłoszenia pozostają w kolejce, a agent musi ręcznie sprawdzać ich stan i wysyłać przypomnienia. W modelowym procesie po upływie ustalonego czasu może zostać wykonane kolejne działanie przewidziane w procedurze, na przykład wysłanie przypomnienia, zmiana statusu albo przygotowanie sprawy do zamknięcia. Zakres możliwej automatyzacji zależy jednak od funkcji i konfiguracji wykorzystywanego systemu.
Przykładowy przebieg może wyglądać następująco: zgłoszenie otrzymuje status oczekiwania na użytkownika, po określonym czasie użytkownik otrzymuje przypomnienie, a dalszy brak odpowiedzi prowadzi do kolejnego kroku ustalonego w procedurze.
Istotne jest rozróżnienie między zgłoszeniem oczekującym na użytkownika a sprawą, nad którą powinien pracować dział wsparcia. W przeciwnym razie raporty będą przedstawiać opóźnienia w sposób mylący.
Podobny problem dotyczy SLA. Samo mierzenie czasu nie poprawia obsługi, jeżeli informacja o zbliżającym się terminie nie wpływa na kolejność pracy. Dlatego monitoring SLA w czasie rzeczywistym powinien wspierać bieżące działania zespołu, a nie służyć wyłącznie do późniejszego opisywania naruszeń.
Jeżeli większość spraw regularnie wymaga eskalacji, problemem prawdopodobnie nie jest brak kolejnej reguły. Warto ponownie sprawdzić priorytety, zobowiązania i dostępność zespołu.
5. Zamykanie rozwiązanych zgłoszeń nie powinno wymagać kilku ręcznych kroków
Po wykonaniu właściwej pracy zgłoszenie często nadal wymaga kilku mechanicznych czynności. Należy zmienić status, przekazać informację użytkownikowi, odczekać na potwierdzenie i zakończyć sprawę.
Automatyzacja może uporządkować działania wykonywane po rozwiązaniu zgłoszenia. Zmiana statusu może uruchomić standardową komunikację, rozpocząć ustalony okres oczekiwania na odpowiedź i wykonać kolejne działanie, jeżeli użytkownik nie zgłosi dodatkowego problemu.
Przykładowy przebieg może obejmować oznaczenie zgłoszenia jako rozwiązane, wysłanie informacji o wykonanych działaniach, oczekiwanie na ewentualne uwagi użytkownika oraz zamknięcie sprawy po upływie ustalonego czasu.
Automatyczne zakończenie najlepiej sprawdza się w powtarzalnych zgłoszeniach o niskim ryzyku. Awarie o dużym wpływie, zgłoszenia bezpieczeństwa lub procesy wymagające formalnego potwierdzenia mogą nadal wymagać ręcznej kontroli.
Warto również zadbać, aby użytkownik otrzymał czytelną informację o wykonanych działaniach i planowanym zamknięciu. Reguła, która zmienia status bez wyjaśnienia, oszczędza czas zespołu, ale niekoniecznie poprawia doświadczenie osoby zgłaszającej.
Sposób kończenia zgłoszeń ma znaczenie także dla raportowania. Jeżeli rozwiązane zgłoszenia pozostają otwarte przez przypadek, dane o czasie obsługi i obciążeniu kolejki przestają odpowiadać rzeczywistości. Ma to wpływ również na ocenę jakości obsługi, dlatego warto łączyć automatyzację z analizą satysfakcji użytkowników. Więcej o tym kontekście opisuje artykuł o tym, jak mierzyć satysfakcję użytkowników w ITSM.
Skuteczność workflow zależy od tego, czy jego logika pozostaje zrozumiała
Na podstawowym poziomie reguły ograniczają ręczne przypisywanie i porządkowanie zgłoszeń. Z czasem mogą łączyć kilka kroków procesu, uwzględniać akceptacje oraz działania zależne od czasu. W bardziej rozbudowanym modelu workflow obejmuje procesy międzydziałowe, ale nadal zachowuje czytelny podział odpowiedzialności.
Rozwój automatyzacji nie powinien polegać wyłącznie na dodawaniu kolejnych warunków. Warto ustalić, kto jest właścicielem konkretnego workflow, kto może zmieniać konfigurację, jak testuje się zmiany i kiedy nieużywana reguła powinna zostać usunięta.
Łatwo przeoczyć wpływ zmian organizacyjnych. Powstaje nowy zespół, zmienia się osoba zatwierdzająca albo inaczej dzielone są obowiązki. Workflow nadal działa zgodnie z konfiguracją, ale konfiguracja przestaje odpowiadać rzeczywistości.
Z perspektywy operacyjnej nie należy oceniać automatyzacji wyłącznie przez liczbę zaoszczędzonych kliknięć. Ważniejsze jest to, czy proces ma wskazanego właściciela, czy opóźnienia są widoczne oraz czy jego przebieg nie zależy od wiedzy jednej osoby.
Automatyzacji nie należy więc traktować jako jednorazowego etapu wdrożenia. Jest częścią modelu operacyjnego, który wymaga okresowego przeglądu podobnie jak formularze, role i zobowiązania SLA.
Przy procesach wykraczających poza IT pomocne może być również spojrzenie na ESM jako rozszerzenie zarządzania usługami bez wdrażania drugiej platformy. Wspólne środowisko powinno porządkować odpowiedzialność, a nie zmuszać wszystkie działy do identycznej pracy.
W Mint Service Desk automatyzację warto oprzeć na uporządkowanych danych
W Mint Service Desk można konfigurować automatyzacje uruchamiane przez zdarzenia związane ze zgłoszeniem oraz reguły wykonywane według harmonogramu. Na podstawie określonych warunków system może między innymi przypisywać zgłoszenia, zmieniać ich status lub priorytet oraz aktualizować wybrane pola.
Pozwala to wspierać obsługę standardowych wniosków wewnętrznych, powtarzalne etapy procesów onboardingowych i offboardingowych, sprawy wymagające akceptacji, reakcje na brak aktywności oraz czynności związane z kończeniem zgłoszeń. Nie oznacza to jednak, że każdy z tych procesów powinien zostać od razu zautomatyzowany w całości.
Podstawą reguł powinny być uporządkowane dane, takie jak typ zgłoszenia, wartości pól formularza, status lub kolejka. Reguły automatyzacji nie powinny być traktowane jako mechanizm samodzielnie interpretujący swobodną treść zgłoszenia. Więcej o bezpiecznym podejściu do tego obszaru opisuje artykuł o AI on-premises w service desk, a zakres samego dodatku produktowego można sprawdzić na stronie modułu AI.
Mint Service Desk zachowuje również historię działań wykonywanych podczas obsługi zgłoszenia. Powstający w ten sposób ślad audytowy może pomagać porządkować dane potrzebne do kontroli procesu i przygotowania audytu, ale sam w sobie nie oznacza zgodności z określonymi regulacjami.
Przed rozszerzeniem automatyzacji warto więc sprawdzić, czy kolejki, typy zgłoszeń, statusy i formularze rzeczywiście odpowiadają sposobowi pracy organizacji. Reguła może przyspieszyć dobrze opisany proces, ale w źle zaprojektowanym procesie najczęściej tylko szybciej powiela jego błędy. Informacje o dostępnych planach i modelach wdrożenia przedstawia cennik Mint Service Desk.
Pierwsza automatyzacja powinna potwierdzić logikę procesu, a nie możliwości systemu
Pierwsze reguły warto zastosować w procesach, w których regularnie wykonuje się te same czynności: porządkuje standardowe wnioski, rozpoczyna powtarzalne działania onboardingowe, przekazuje sprawy do akceptacji, reaguje na brak odpowiedzi albo kończy rozwiązane zgłoszenia.
Przed uruchomieniem workflow należy ustalić, jakie zdarzenie rozpoczyna regułę, jakie działanie ma zostać wykonane i kto odpowiada za sytuację, w której wynik okaże się nieprawidłowy. Jeżeli tych zasad nie da się wyjaśnić bez rozbudowanego komentarza, proces prawdopodobnie nie jest jeszcze gotowy do automatyzacji.
Jeżeli organizacja chce ocenić, od których procesów warto zacząć po wdrożeniu Mint Service Desk, punktem wyjścia powinny być sprawy częste, przewidywalne i łatwe do zweryfikowania. Dopiero później warto rozszerzać automatyzację na procesy bardziej złożone, międzydziałowe lub zależne od akceptacji.
Największą wartością workflow nie jest to, że system wykonuje więcej działań. Jest nią to, że ludzie rzadziej muszą wykonywać działania, które od początku nie wymagały ich decyzji.
