Start · Rozwiązania · Inne rozwiązania
Rozwiązanie · Inne rozwiązaniaKażde zgłoszenie, awaria i zmiana same wysyłają komunikat do osób, których dotyczą
Statusy, awarie i zmiany ogłaszane, zanim ktoś zapyta
Zmiana statusu, ogłoszony incydent i zatwierdzona zmiana tworzą komunikat z szablonu do wyznaczonych odbiorców w Microsoft Teams, z jednym dotknięciem akceptacji przy komunikatach ogólnofirmowych.
Streszczenie dla zarządu
Mail o awarii wychodzi po awarii, a co piąty komentarz w kolejce zgłoszeń to te same dwa słowa.
Zdarzenia już są.
Pytania o status znikają, bo każda zmiana statusu dociera do zgłaszającego w Teams razem z następnym krokiem.
Microsoft Teams; Outlook i Exchange Online; strona statusu na SharePoint
Problem biznesowy
Komunikacja IT
Komunikacja o zdarzeniach IT jest ręczna, spóźniona i nieadresowana. Status zgłoszenia mieszka w narzędziu, do którego zgłaszający nie zaglądają, więc zamiast tego pytają. Komunikat o awarii wymaga kogoś, kto awarię zauważy, kogoś, kto go napisze, i kogoś wyższego, kto go zaakceptuje, a każdy krok czeka na poprzedni.
Odbiorców się zgaduje. Komunikat idzie do wszystkich, bo nikt nie wie, kto korzysta z danej aplikacji, a wpis w CMDB wiążący ją z lokalizacjami i grupami użytkowników nigdy nie posłużył do dystrybucji. Zawiadomienia o zmianach wychodzą raz, na tydzień przed terminem, i w dniu zmiany nikt ich nie pamięta.
Skutki wchłania dział wsparcia: telefony o status, zduplikowane zgłoszenia incydentu przy jednej awarii, pretensje o zmiany, o których nikt nie pamięta, by mu je zapowiedziano. Problem trwa, bo informacja leży w trzech systemach, a odbiorcy w czwartym, i nikt tego nie połączył. Wysyłka jest zadaniem człowieka, więc dzieje się wtedy, kiedy ten człowiek ma czas.
Jak to wygląda dzisiaj
- SystemZgłoszenie zmienia status w ServiceNow i poza narzędziem nikt tego nie widzi
- CzłowiekZgłaszający dopisuje komentarz „jakieś postępy?” albo dzwoni do działu z tym samym pytaniem
- CzłowiekAnalityk wpisuje odpowiedź powtarzającą to, co rekord już zawiera
- CzłowiekAwarię rozpoznaje się po liczbie telefonów; kierownik incydentu otwiera Worda i zaczyna pisać
- OczekiwanieProjekt komunikatu czeka na sprawdzenie brzmienia przez dyrektora IT na czacie Teams
- Ryzyko błęduMail wychodzi po przywróceniu usługi, do wszystkich pracowników, więc kolejny czyta już mniej osób
- Ryzyko błęduZawiadomienie o zmianie idzie raz, na tydzień przed terminem; zakłady dowiadują się o niej w dniu zmiany, z hali
Dlaczego obecny proces kosztuje więcej, niż widać
Rachunek, którego nie widać w budżecie.
- Zduplikowane zgłoszenia incydentu przy awarii zniekształcają rejestr i raport SLA, więc obsada planowana jest na liczbach opisujących zamieszanie, a nie popyt.
- Nieadresowane maile do wszystkich uczą ludzi ignorowania komunikatów IT, więc ten ważny również ginie; wiarygodność wydana na rutynowe zawiadomienie nie jest już dostępna przy prawdziwym.
- Kierownicy zakładów tracą czas na planowanie, gdy o zmianie dowiadują się z hali, a płaci za to grafik ułożony tydzień wcześniej.
- W trakcie incydentu uwaga kierownika incydentu jest najrzadszym zasobem w pokoju, a pisanie prozy zużywa ją w najgorszym momencie.
- Ręczna wysyłka nie zostawia dowodów: po incydencie nikt nie pokaże, kogo i kiedy poinformowano, więc przegląd toczy się na wspomnieniach.
Koszt zaniechania
Każda przejęta lokalizacja i każdy nowy zakład dokłada krąg odbiorców, którego nikt nie odwzorował, więc komunikaty stają się szersze i mniej czytane, a im szersze, tym mniej zauważa się ten ważny. Kontakty o status rosną wraz z liczbą zgłoszeń, liczba zgłoszeń rośnie wraz z zatrudnieniem i systemami, a pisanie nadal odbywa się w środku incydentu. Po dwunastu miesiącach przeglądy wciąż nie pokażą, kogo i kiedy poinformowano, zakłady wciąż będą mówić, że nikt ich nie uprzedził, a IT wciąż odpowie, że zawiadomienie wysłano. Mały podatek, pobierany codziennie, który nigdy nie pojawia się jako pozycja w żadnym budżecie.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Zakład produkcyjny z 4 500 pracownikami w trzech fabrykach i centrali; ServiceNow do zgłoszeń, incydentów i zmian; Microsoft 365; CMDB, w której powiązanie aplikacji z lokalizacjami istnieje, ale nie jest używane do dystrybucji.
Około 840 kontaktów w sprawie statusu miesięcznie (komentarze, telefony, wiadomości w Teams) oraz 24 incydenty i okna zmian wymagające komunikatu, każdy po około 50 minut pracy kierownika incydentu na napisanie, akceptację i rozesłanie.
O status trzeba pytać, zamiast go dostawać; komunikaty o awariach powstają w Wordzie, są sprawdzane na czacie i wysyłane mailem do wszystkich; zawiadomienia o zmianach idą raz. Kierownicy zakładów dwukrotnie prosili o wcześniejsze i węższe zawiadomienia.
Każdy komunikat czeka, aż człowiek zauważy zdarzenie i napisze tekst, a każdy krąg odbiorców jest zgadywany, więc komunikaty są jednocześnie za szerokie i niepełne.
Wyzwalacze zdarzeń Orchestrator na rekordach ServiceNow; robot, który dobiera zatwierdzony szablon, wyznacza odbiorców z CMDB i grup Microsoft Entra ID oraz wysyła Adaptive Card w Microsoft Teams; jedno dotknięcie akceptacji przy komunikatach ogólnofirmowych; strona statusu na SharePoint i zapis doręczenia przy zdarzeniu.
W modelowanym przypadku trzy kontakty o status na cztery nie docierają do działu wsparcia. Komunikat o awarii wychodzi w ciągu minut od jej ogłoszenia, a nie po niej, a każde okno zmiany niesie trzy zawiadomienia do lokalizacji, których dotyczy. Ilustracyjnie, nie jako wynik klienta.
Proponowane rozwiązanie
Zdarzenia już są. Zgłoszenie zmienia status, incydent zostaje ogłoszony, zmiana zostaje zatwierdzona na konkretny termin: każde z tego jest rekordem w ServiceNow i każde jest komunikatem, który ktoś powinien był dostać. Wyzwalacze zdarzeń Orchestrator czytają te rekordy przez UiPath Integration Service, więc komunikat idzie za zdarzeniem, a nie za czyjąś dostępnością.
Dla każdego zdarzenia robot UiPath dobiera zatwierdzony szablon i wyznacza odbiorców: zgłaszającego przy aktualizacji zgłoszenia, a przy awarii lub zmianie użytkowników danej aplikacji. Krąg odbiorców wynika z powiązania w CMDB i odpowiadających mu grup Microsoft Entra ID według zakładu i roli, ustalanych w momencie wysyłki, a nie z ręcznie utrzymywanej listy. Aktualizacje zgłoszeń idą jako Adaptive Cards w Microsoft Teams ze statusem, następnym krokiem i spodziewanym terminem; osoby bez otwartego Teams dostają ten sam tekst mailem.
Wszystko, co ogólnofirmowe, i każdy komunikat o poważnym incydencie zatrzymuje się u kierownika incydentu, który akceptuje go lub redaguje jako zadanie UiPath Action Center wykonywane w Microsoft Teams. Rutynowe aktualizacje przy już ogłoszonym incydencie idą bez akceptacji, a strona statusu na SharePoint niesie te same fakty. Zawiadomienia o zmianie idą w terminach z rekordu zmiany: pięć dni przed, dzień przed i po zakończeniu, do grup, których dotyczą. Wszystko, co wysłano, zapisuje się przy zdarzeniu, i to właśnie czyta później przegląd poincydentalny.
Wyzwalacze zdarzeń i wyzwalacze czasowe, kolejki oraz log audytowy UiPath Orchestrator; zadania UiPath Action Center wykonywane w Microsoft Teams; Adaptive Cards w Teams; grupy Microsoft Entra ID; strona statusu na SharePoint
Bibliotekę szablonów wraz z wersjonowaniem, reguły doboru odbiorców na CMDB i grupach katalogowych, robota wysyłkowego i jego postępowanie zastępcze przy braku powiązania, harmonogram przypomnień, krok akceptacji i zapis doręczenia
Odczyt zgłoszeń, incydentów, zmian i CMDB oraz zapis doręczenia w ServiceNow przez konektor UiPath Integration Service; konektory Microsoft Teams i Microsoft Outlook 365 do wysyłki; grupy odczytywane przez konektor Integration Service o nazwie „Microsoft Azure Active Directory” (wcześniejsza nazwa usługi Microsoft Entra ID, nadal używana w katalogu konektorów)
Jak działa proces po automatyzacji
- AutomatyzacjaZdarzenie w ServiceNow, zmiana statusu, ogłoszony incydent albo zatwierdzona zmiana, uruchamia wyzwalacz Orchestrator
- AutomatyzacjaRobot dobiera zatwierdzony szablon i wyznacza odbiorców z powiązania w CMDB oraz odpowiadających mu grup Entra ID
- CzłowiekKomunikaty ogólnofirmowe i dotyczące poważnych incydentów trafiają do kierownika incydentu jako zadanie akceptacji w Teams, z gotowym i edytowalnym tekstem
- AutomatyzacjaKomunikat wychodzi jako Adaptive Card w Microsoft Teams, a mailem do osób, które nie mają w tym momencie Teams
- AutomatyzacjaStrona statusu na SharePoint niesie te same fakty i godzinę kolejnej aktualizacji
- AutomatyzacjaZawiadomienia o zmianie idą za rekordem zmiany: pięć dni przed, dzień przed i po zakończeniu, do grup, których dotyczą
- AutomatyzacjaKogo, o czym i kiedy poinformowano, zapisuje się przy zdarzeniu; brak powiązania odbiorców albo nieudana wysyłka trafia do działu wsparcia
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Wykrywanie zdarzeń: zmian statusu zgłoszeń, ogłoszeń incydentów, zatwierdzonych okien zmian
- Wyznaczanie odbiorców z CMDB i grup katalogowych w momencie wysyłki
- Skomponowanie komunikatu z zatwierdzonego szablonu i faktów samego zdarzenia
- Wysyłkę, aktualizację strony statusu, prowadzenie przypomnień i zapis doręczenia
Ludzie decydują
- Ogłoszenie incydentu oraz akceptację lub redakcję wszystkiego, co idzie ogólnofirmowo
- Własność szablonów, tonu i reguł doboru odbiorców
- Kiedy nietypowe zdarzenie wymaga komunikatu, którego szablony nie obejmują
Przed i po
Systemy i integracje
Tam, gdzie wystarczy reguła, nie używamy modelu. Tam, gdzie potrzebny jest osąd, decyduje człowiek.
Wejścia
- rekordy zgłoszeń, incydentów i zmian w ServiceNow
- powiązanie aplikacji z lokalizacjami i grupami użytkowników w CMDB
- grupy Microsoft Entra ID według zakładu i roli
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Systemy docelowe
- Microsoft Teams
- Outlook i Exchange Online
- strona statusu na SharePoint
- ServiceNow, w którym leży zapis doręczenia
Punkty styku z człowiekiem: zadanie akceptacji kierownika incydentu w Teams; biblioteka szablonów po stronie komunikacji wewnętrznej; przegląd reguł doboru odbiorców; miesięczny raport komunikacji
Wykorzystane technologie
wyzwalacze zdarzeń na rekordach ServiceNow, wyzwalacze czasowe do przypomnień, kolejki i audyt
Awyznaczenie odbiorców, wypełnienie szablonu, wysyłka, aktualizacja strony statusu i zapis doręczenia
Azdarzenia i odczyty z ServiceNow; konektory Microsoft Teams, Microsoft Outlook 365 i tożsamości
Azadanie akceptacji kierownika incydentu, wykonywane w Microsoft Teams, z zapisem akceptującego
Akomunikaty o statusie, awarii i zmianie ze statusem, następnym krokiem i przyciskiem
Agrupy zakładowe, lokalizacyjne i rolowe rozstrzygające, kogo dotyczy zdarzenie
Aten sam komunikat mailem dla osób bez Teams
Astrona statusu utrzymywana na bieżąco w trakcie incydentu
AIlustracyjny model ekonomiczny
Zacznijcie od kwestionowania założeń.
Czas pracy tracony w zakładach podczas awarii jest w tej sprawie największą liczbą i tą, której nie zamierzamy wymyślać; należy do rozmowy z COO, a nie do tych wierszy. Kalkulator wycenia sam dział wsparcia: z 840 kontaktów o status miesięcznie trzy na cztery stają się zbędne, gdy status jest wysyłany. To 630 kontaktów, od których startuje wolumen, po 8 minut każdy i 42 € za godzinę pełnego kosztu. Druga pula leży w sekcji 14: 24 komunikaty miesięcznie po 50 minut pracy kierownika incydentu, po 71 € za godzinę, to 20 godzin i 1 420 € miesięcznie; obie razem dają 4 948 € miesięcznie. Licencje i wdrożenie są poza modelem, a nic tu nie zostało zmierzone u klienta.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Pytania o status znikają, bo każda zmiana statusu dociera do zgłaszającego w Teams razem z następnym krokiem
- Przy awarii spada liczba zduplikowanych zgłoszeń incydentu, bo osoby, których dotyczy, wiedzą wcześniej, niż zdążą zadzwonić
- Komunikat o awarii wychodzi w ciągu minut od jej ogłoszenia: pisanie to szablon, a akceptacja jedno dotknięcie
- Komunikaty docierają do lokalizacji i ról, których dotyczą, i właśnie to sprawia, że komunikaty IT znów są czytane
- Każdy komunikat niesie zapis doręczenia, więc przegląd poincydentalny czyta dowody, a nie wspomnienia
Perspektywa zarządu
- Komunikacja przestaje zależeć od tego, kto ma czas; komunikat wysyła zdarzenie, a komunikat zostawia zapis
- Kontakty o status stają się mierzalną liczbą, a ich spadek jest bezpośrednim dowodem, że zgłaszający są informowani
- Zakłady dostają zawiadomienia, wokół których da się planować, co zamienia zmianę w IT z przerwania w pozycję w grafiku
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Bezpieczeństwo projektujemy razem z procesem, nie po nim.
- Robot wysyła na dedykowanej tożsamości serwisowej uprawnionej do publikowania w wskazanych kanałach Teams i wysyłania z jednej skrzynki komunikacji IT, i do niczego więcej; jej sekret leży w magazynie poświadczeń Orchestrator
- Odbiorcy są wyznaczani z przynależności do grup i powiązań w CMDB w momencie wysyłki, nigdy z ręcznie prowadzonych list dystrybucyjnych, więc odchodzący i przenoszeni wypadają sami
- Komunikaty ogólnofirmowe i dotyczące poważnych incydentów nie wyjdą bez zapisanej akceptacji kierownika incydentu, zebranej w Microsoft Teams wraz z tożsamością akceptującego i możliwej do prześledzenia w Microsoft Purview
- Szablony są wersjonowane i należą do komunikacji wewnętrznej; zmiana tonu to zmiana w jednym miejscu, a wysłana wersja zostaje przypięta do zdarzenia
- Treść komunikatów nie zawiera danych osobowych poza własnym zgłoszeniem zgłaszającego; przetwarzanie odbywa się w regionie UE UiPath Automation Cloud, a Microsoft 365 pozostaje w granicy danych UE
Dlaczego teraz
Pracownicy czytają Teams, nie intranet, a Adaptive Card niesie status, następny krok i przycisk; w zakładzie, który układa grafik tydzień naprzód, mail do wszystkich nie liczy się już jako poinformowanie
Ścieżka publikowania przez webhooki, z której wiele firm korzystało przy automatycznych komunikatach w Microsoft Teams, została wycofana w maju 2026, więc i tak trzeba ją odbudować. Odbudowa na wyzwalaczach zdarzeń zamiast na czyjejś czujności kosztuje tyle samo
Minuty działu wsparcia i minuty kierownika incydentu to razem 4 948 € miesięcznie w modelowanym przypadku, wydawane na komunikaty, do których fakty systemy już mają
Role zarządcze, których to dotyczy
Reputację IT w firmie wyznacza to, jak komunikuje w trakcie incydentu, a to czyni tę komunikację szybką i udokumentowaną
Dział wsparcia przestaje odpowiadać na pytania, na które system zgłoszeń zna odpowiedź
Zakłady dostają adresowane i terminowe zawiadomienia o awariach i zmianach, wokół których da się planować
Ton i szablony zostają pod jego kontrolą, a zespół nie jest pod telefonem przy każdej awarii
Częste pytania i zastrzeżenia
Wysyła maile przy zmianie statusu, a to nie to samo. To rozwiązanie dokłada adresowanie z CMDB, karty w Teams z następnym krokiem, bramkę akceptacji dla komunikatów poważnych i przypomnienia idące w terminach z samego rekordu zmiany.
Dostaną mniej. Komunikaty adresowane zastępują maile do wszystkich, a karta statusu zastępuje odpowiedź, którą i tak wpisałby analityk; znika ta objętość, której nikt nie chciał.
Wtedy pilot startuje na dwóch aplikacjach, których użytkowników Państwo znają, a luki, które ujawni, stają się listą porządkowania CMDB, uszeregowaną według liczby osób, których każda dotyczy.
Kiedy to nie jest właściwe rozwiązanie
- Organizacja jest na tyle mała, że jeden wpis na kanale dociera do wszystkich, którzy się liczą
- Nie ma ani CMDB, ani struktury grup, z których dałoby się wyznaczyć odbiorców, ani chęci, by je zbudować
- Narzędzie do obsługi zgłoszeń jest wymieniane w ciągu roku; budować po migracji, nie przed nią
Pytanie na najbliższe posiedzenie
Dlaczego zakłady dowiedziały się o naszej ostatniej zmianie z hali, skoro rekord z terminem, usługą i lokalizacjami, których dotyczy, leżał w ServiceNow od momentu zatwierdzenia?
Podejście wdrożeniowe
Zaczynamy od jednego wycinka procesu i rozszerzamy dopiero po dowodzie.
Dostarczamy
- Proces docelowy komunikacji o statusie, incydentach i zmianach, zbudowany na zeszłokwartalnych mailach o awariach i kalendarzu zmian
- Bibliotekę szablonów uzgodnioną z komunikacją wewnętrzną, wersjonowaną i pozostawioną w jej gestii
- Reguły doboru odbiorców na CMDB i grupach Microsoft Entra ID, z określonym postępowaniem zastępczym przy braku powiązania
- Wyzwalacze zdarzeń i czasowe, robota wysyłkowego, zadanie akceptacji w Teams, stronę statusu i zapis doręczenia
- Testy równolegle z procesem ręcznym, wdrożenie, krótką instrukcję dla kierowników incydentu i miesięczny raport
Potrzebujemy od Państwa
- Powiązania aplikacji z lokalizacjami i grupami użytkowników w CMDB, w takim stanie, w jakim jest
- Struktury grup Microsoft Entra ID według zakładu i roli
- Kierownika incydentu jako właściciela przepływu i komunikacji wewnętrznej jako właściciela szablonów
- Zeszłokwartalnych maili o awariach, kalendarza zmian i próbki komentarzy o status
Etapy
Rozpoznanie
Tydzień czytania: maile o awariach, kalendarz zmian, komentarze o status i powiązania w CMDB w obecnym stanie
Projekt
Szablony, reguły doboru odbiorców, progi akceptacji i rytm przypomnień, każde uzgodnione z właścicielem
Budowa
Wyzwalacze zdarzeń, robot wysyłkowy, zadanie akceptacji w Teams, strona statusu i zapis doręczenia
Pilot
Karty statusu dla jednej grupy przypisania i komunikaty o awarii dla dwóch aplikacji o znanych użytkownikach, obok procesu ręcznego
Skalowanie
Kolejne aplikacje w miarę potwierdzania powiązań w CMDB, potem przypomnienia w całym kalendarzu zmian
Optymalizacja
Miesięczny raport o kontaktach o status, zduplikowanych incydentach i czasie do pierwszego komunikatu; reguły strojone na tym, co pokazuje
Szybki efekt. O nakładzie decyduje stan powiązań w CMDB i liczba odrębnych kręgów odbiorców, a nie sama automatyzacja; narzędzie do obsługi zgłoszeń niewiele tu zmienia.
Co piąty komentarz w Państwa kolejce zgłoszeń to te same dwa słowa.
Prosimy o zeszłokwartalne maile o awariach i tydzień komentarzy ze zgłoszeń. Odeślemy mapę odbiorców dla pięciu najbardziej obciążonych aplikacji i pisemną ocenę, które komunikaty mogły wysłać się same.
Prześlijmy zeszłokwartalne maile o awariachTen sam problem ma zwykle sąsiedni proces
Co trzeci kontakt klienta to pytanie, gdzie jest zamówienie; odpowiedź jest już w SAP i na portalu przewoźnika.
Zobacz rozwiązanie Inne rozwiązaniaZgłoszenia posortowane, zanim przeczyta je analitykPriorytet nadają wielkie litery zgłaszającego, a P1 czeka w kolejce, aż dyspozytor znajdzie czas, by je przeczytać.
Zobacz rozwiązanie Inne rozwiązaniaIncydenty obsadzone i zamknięte jednym procesemNarzędzie zapisuje, co się stało. Szukanie właścicieli, gonienie statusów i nieczytanie w piątek robią ludzie.
Zobacz rozwiązanieBranże, w których wdrażamy to najczęściejProdukcja i przemysłTransport i logistykaUsługi i ITCentra usług wspólnych