Start · Rozwiązania · Inne rozwiązania
Rozwiązanie · Inne rozwiązaniaDysk był prawie pełny trzy tygodnie temu. Intune o tym wiedział, tylko nikt nie czytał listy
Awaria laptopa naprawiona, zanim powstanie zgłoszenie
Robot w harmonogramie czyta sygnały z Intune, Defender for Endpoint, skrzynek i certyfikatów, wykonuje zatwierdzoną naprawę rutynowych przypadków i zakłada zgłoszenie tylko wtedy, gdy potrzebny jest inżynier.
Streszczenie dla zarządu
Dysk się zapełnia, certyfikat wygasa, aktualizacja znów pada, a help desk dowiaduje się o tym od użytkownika.
Projekt zaczyna się od harmonogramu, a nie od skrzynki.
Rutynowe usterki są naprawiane w chwili pojawienia się sygnału, a nie telefonu użytkownika, więc cały strumień zgłoszeń przestaje trafiać na help desk.
akcje urządzeń w Microsoft Intune; zgłoszenia i rekordy problemów w ServiceNow; miesięczny dziennik napraw
Problem biznesowy
Urządzenia
Zarządzanie urządzeniami produkuje dane, nie pracę. Intune raportuje zgodność, dysk, aktualizacje i szyfrowanie; Defender for Endpoint raportuje alerty i podatne oprogramowanie; Exchange Online wie, które skrzynki dobiły do limitu; urząd certyfikacji wie, które certyfikaty maszynowe wygasają w przyszłym tygodniu. Żeby cokolwiek z tego wynikło, potrzebny jest człowiek, który przefiltruje, ustali priorytet, skontaktuje się z użytkownikiem i zastosuje poprawkę. Help desk nie ma mocy na pracę, która nie jest jeszcze zgłoszeniem.
Rutynowe awarie są więc obsługiwane od końca. Pełny dysk staje się incydentem, gdy Outlook przestaje się synchronizować. Wygasły certyfikat staje się incydentem, gdy cała lokalizacja odpada od sieci bezprzewodowej w poniedziałek rano. Skrzynka przy limicie staje się incydentem, gdy klient mówi, że odpowiedź nigdy nie dotarła. Inżynierowie naprawiają tę samą usterkę na tym samym modelu laptopa dwadzieścia razy i nikt nie zauważa, że to jeden problem, a nie dwadzieścia.
Użytkownicy wyciągają wniosek, że laptopy są zawodne, a IT powolne, co jest niesprawiedliwe wobec obu stron. Ten wzorzec się utrzymuje, bo monitorowanie i naprawa siedzą w różnych narzędziach należących do różnych zespołów, każda pojedyncza poprawka jest tania, a nikt nie jest rozliczany z zapobiegania.
Jak to wygląda dzisiaj
- SystemTelemetria zapisuje psujący się dysk, trzecią nieudaną aktualizację i certyfikat wygasający za jedenaście dni
- OczekiwanieNikt nie ma przypisanego czytania tych danych, więc ustalenie leży na pulpicie do czasu pojawienia się objawu
- CzłowiekUżytkownik zauważa, że Outlook przestał się synchronizować, obchodzi to przez dwa dni, po czym dzwoni na help desk
- CzłowiekKonsultant zbiera nazwę urządzenia, model i treść błędu, które tenant już miał
- OczekiwanieZgłoszenie trafia do inżyniera i czeka na okno kontaktu pasujące pracownikowi zmianowemu
- SystemInżynier stosuje znaną poprawkę, zwalnia miejsce albo ponawia aktualizację, i zamyka zgłoszenie
- Ryzyko błęduTa sama usterka na tym samym modelu wraca w przyszłym tygodniu; żaden wzorzec nie jest zapisywany, a sprzęt jest wymieniany za wcześnie albo za późno
Dlaczego obecny proces kosztuje więcej, niż widać
Budżet pokazuje etaty. Nie pokazuje, na co idą.
- Minuty help desku to połowa rachunku. Użytkownik traci mniej więcej drugie tyle, i to w najgorszym momencie: przed wizytą u klienta, w trakcie przekazania zmiany, na stacji elektroenergetycznej z dokumentacją bezpieczeństwa na martwym laptopie.
- Urządzenie, które nie przechodzi kontroli zgodności lub nie ma poprawki, pozostaje odsłonięte, dopóki ktoś nie zareaguje, przez co odstęp między sygnałem a naprawą jest liczbą bezpieczeństwa, a nie liczbą serwisową.
- Wygasanie certyfikatów nie przychodzi po jednym urządzeniu. Zabiera całą lokalizację z sieci bezprzewodowej w jeden poranek, a help desk słyszy to jako dwadzieścia równoczesnych telefonów.
- Decyzje o wymianie idą za skargami, a nie za danymi o kondycji, więc budżet kupuje maszyny, które utrzymałaby dwudziestominutowa naprawa, a inżynierowie spędzają wykwalifikowane godziny na skryptach, które już uruchamiali.
Koszt zaniechania
Żaden z dwóch pierwszych wierszy nie wycenia ekspozycji: urządzenie bez poprawki lub niespełniające kontroli zgodności pozostaje w tym stanie, dopóki ktoś nie zareaguje. Odstęp między sygnałem a naprawą to liczba, o którą pyta audyt bezpieczeństwa. Środkowy wiersz dolicza 300 uprzedzonych zgłoszeń miesięcznie po 40 minut, czyli 200 godzin po 36 € za godzinę. Godzina technika na stacji elektroenergetycznej jest warta więcej, a żaden wiersz nie wycenia dokumentacji bezpieczeństwa na martwym laptopie.
Rok takiej pracy zostawia help desk bardziej obciążony, nie spokojniejszy: flota się starzeje, więc awarii przybywa, a zatrudnienie dokłada urządzenia w tym samym czasie. Certyfikaty nadal wygasają przez zaskoczenie, lokalizacje nadal tracą sieć bezprzewodową na poranek, a budżet nadal kupuje zamienniki, których uniknęłaby dwudziestominutowa naprawa.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Spółka energetyczna z 6 000 pracowników, około 7 500 urządzeń Windows i macOS zarządzanych w Microsoft Intune wraz z Microsoft Defender for Endpoint oraz help desk działający na ServiceNow.
Około 600 zgłoszeń dotyczących urządzeń miesięcznie: mało miejsca na dysku, nieudane aktualizacje, błędy zgodności i szyfrowania, usterki baterii i sprzętu, problemy z certyfikatami i skrzynki przy limicie. Technicy na stacjach polegają na laptopach z dokumentacją bezpieczeństwa.
Każde zgłoszenie przychodzi dopiero po tym, jak użytkownik zauważy objaw; help desk zbiera ponownie dane, które tenant już ma, a inżynier stosuje znaną poprawkę.
Około 34 minuty czasu help desku i inżyniera na zgłoszenie oraz około 40 minut czasu samego użytkownika wokół niego; dyrektor IT szacuje, że połowa była widoczna w telemetrii, zanim ktokolwiek to zauważył.
UiPath Robot uruchamiany harmonogramem czyta Intune, Defender for Endpoint, zajętość skrzynek i daty wygaśnięcia certyfikatów. Następnie stosuje progi spółki i sortuje każde ustalenie na trzy sposoby: zatwierdzony runbook, który się wykonuje i informuje użytkownika w Microsoft Teams, karta w Teams z prośbą o dwa kroki albo zgłoszenie w ServiceNow założone z telemetrią i propozycją naprawy, zanim użytkownik zadzwoni.
W modelowanym przypadku połowa z 600 miesięcznych zgłoszeń przestaje trafiać na help desk, inżynierowie otwierają zgłoszenia zawierające już dowody, a powtarzalne usterki zostają zapisane jako problemy. To liczby modelowe, nie pomiar.
Proponowane rozwiązanie
Projekt zaczyna się od harmonogramu, a nie od skrzynki. UiPath Robot działa na wyzwalaczu czasowym Orchestrator. Czyta stan zgodności oraz inwentarz z Microsoft Intune, alerty i stan podatności z Microsoft Defender for Endpoint, zajętość skrzynek z Exchange Online oraz daty wygaśnięcia z raportu Państwa urzędu certyfikacji. Następnie stosuje Państwa własne progi: pięć procent wolnego dysku, trzy nieudane aktualizacje z rzędu, czternaście dni do wygaśnięcia certyfikatu, dziewięćdziesiąt procent limitu skrzynki.
Każde ustalenie powyżej progu dostaje jeden z trzech wyników i ten podział jest istotą projektu. Rutynowe i bezpieczne: robot uruchamia zatwierdzony runbook naprawczy, zwalnia pliki tymczasowe, ponawia aktualizację albo wnioskuje o odnowienie certyfikatu, a potem mówi użytkownikowi w Microsoft Teams, co zostało zrobione. Wymagane działanie użytkownika: karta w Teams z dwoma krokami do wykonania i przyciskiem odłożenia, a help desk nie jest angażowany, dopóki karta nie wygaśnie. Potrzebny inżynier: zgłoszenie powstaje w ServiceNow przez UiPath Integration Service i niesie telemetrię, historię urządzenia oraz proponowaną naprawę, zanim użytkownik zadzwoni.
Tam, gdzie ta sama usterka wraca, UiPath Agent czyta miesięczny dziennik napraw i sporządza notatkę o przyczynie źródłowej: ten model z tym oprogramowaniem stacji dokującej, to biuro z tym szablonem certyfikatu. Projekt notatki pozostaje projektem: trafia do menedżera problemów jako zadanie UiPath Action Center w Teams i staje się rekordem problemu tylko wtedy, gdy człowiek go przyjmie. Model językowy czyta dziennik; nigdy nie wykonuje naprawy i nigdy nie dotyka urządzenia.
Inwentarz, stan zgodności i akcje urządzeń w Microsoft Intune; alerty i stan podatności w Microsoft Defender for Endpoint; Adaptive Cards w Microsoft Teams; wyzwalacze czasowe, magazyn poświadczeń i audyt UiPath Orchestrator; zadania UiPath Action Center wykonywane w Teams; lista dozwolonych modeli i maskowanie danych osobowych w AI Trust Layer dla agenta
Model progów i reguły klasyfikacji, runbooki naprawcze jako przepływy robota, karty użytkownika wraz z logiką ponagleń, szablon zgłoszenia z dołączonymi dowodami, dziennik napraw i raport prewencyjny
Odczyty zarządzanych urządzeń z Intune, zajętości skrzynek z Exchange Online i stanu Defender for Endpoint przez Microsoft Graph na jednej ograniczonej tożsamości; konektor ServiceNow w UiPath Integration Service dla zgłoszeń i rekordów problemów; raport wygasających certyfikatów z urzędu certyfikacji
Jak działa proces po automatyzacji
- AutomatyzacjaZgodnie z harmonogramem robot czyta sygnały z Intune, Defender for Endpoint i skrzynek przez Microsoft Graph oraz daty wygaśnięcia z urzędu certyfikacji
- AutomatyzacjaKażde urządzenie jest mierzone wobec Państwa progów; ustalenia poniżej nich są zapisywane i nic więcej się nie dzieje
- AutomatyzacjaUstalenia rutynowe i bezpieczne uruchamiają zatwierdzony runbook naprawczy, który wykonuje się, a potem weryfikuje własny wynik
- SystemUżytkownik dostaje krótką informację w Microsoft Teams o tym, co zostało naprawione, albo kartę z dwoma krokami, które tylko on może wykonać
- SystemWszystko, co musi zobaczyć inżynier, powstaje jako zgłoszenie w ServiceNow z dołączoną telemetrią, historią i proponowaną naprawą
- CzłowiekInżynier rozwiązuje przypadki nierutynowe, zaczynając od dowodów, a nie od pytań
- AutomatyzacjaKażdy przebieg, runbook i wynik jest zapisywany w dzienniku Orchestrator i w miesięcznym rejestrze
- CzłowiekUiPath Agent sporządza z tego rejestru notatki o przyczynach źródłowych; menedżer problemów przyjmuje lub odrzuca każdą z nich jako zadanie Action Center w Teams
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Czytanie sygnałów o urządzeniach, bezpieczeństwie, skrzynkach i certyfikatach zgodnie z harmonogramem oraz stosowanie Państwa progów
- Klasyfikację każdego ustalenia jako rutynowego, do działania użytkownika albo dla inżyniera, a następnie uruchomienie zatwierdzonego runbooka i potwierdzenie skutku naprawy
- Wysyłanie informacji i kart w Teams oraz zakładanie zgłoszeń z już dołączonymi dowodami
- Sporządzanie notatek o przyczynach źródłowych z miesięcznego dziennika napraw
Ludzie decydują
- Które runbooki mogą działać bez nadzoru i na których grupach urządzeń, zatwierdzane pojedynczo
- Każdą diagnozę, której runbooki nie obejmują, i każdą zmianę na urządzeniu produkcyjnym poza nimi
- Czy sporządzona przyczyna źródłowa staje się rekordem problemu, czy zostaje odrzucona
- Progi, politykę oraz to, kiedy urządzenie jest wymieniane zamiast naprawiane
Przed i po
Systemy i integracje
Nie dokładamy technologii, żeby architektura wyglądała poważniej. Każdy element poniżej ma w tym procesie konkretne zadanie.
Wejścia
- inwentarz i stan zgodności z Microsoft Intune
- alerty i podatności z Microsoft Defender for Endpoint
- zajętość skrzynek w Exchange Online
- daty wygaśnięcia certyfikatów z urzędu certyfikacji
- przypisanie urządzenia do osoby w Microsoft Entra ID
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Agents
- UiPath Action Center
- UiPath Integration Service
Systemy docelowe
- akcje urządzeń w Microsoft Intune
- zgłoszenia i rekordy problemów w ServiceNow
- miesięczny dziennik napraw
- raport prewencyjny
Punkty styku z człowiekiem: informacje i karty dla użytkownika w Microsoft Teams; zadania Action Center w Teams dla menedżera problemów; kolejka inżyniera w ServiceNow
Wykorzystane technologie
inwentarz, stan zgodności i akcje urządzeń wywoływane przez runbooki
Aalerty i stan podatności podnoszące priorytet urządzenia
Aczyta dane o urządzeniach, skrzynkach i bezpieczeństwie na jednej ograniczonej tożsamości aplikacji
Aprzebieg w harmonogramie, runbooki, magazyn poświadczeń, ponowienia i audyt
Ainformacje dla użytkownika i karty z dwoma krokami, które tylko on może wykonać
Aproaktywne zgłoszenia i rekordy problemów z dołączoną telemetrią
Asporządza notatki o przyczynach źródłowych z dziennika napraw w ramach listy dozwolonych modeli
Amenedżer problemów przyjmuje lub odrzuca każdą sporządzoną przyczynę źródłową
AIlustracyjny model ekonomiczny
Ile to jest warte, policzone krok po kroku.
Udział możliwy do uprzedzenia to jedyne założenie, które porusza ten model, i przyjęto go na poziomie połowy. 300 z 600 miesięcznych zgłoszeń traktujemy jako widoczne w telemetrii na tyle wcześnie, by obsłużyć je bez zgłoszenia, więc kalkulator startuje od 300, a nie od 600. Trzydzieści cztery minuty to czas help desku i inżyniera na zgłoszenie, a 51 € to uśredniony pełny koszt godziny. Czas samego użytkownika jest wyceniony w kolejnej sekcji, nie tutaj. Licencje, budowa i tworzenie runbooków są poza tymi liczbami, a nic z tego 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
- Rutynowe usterki są naprawiane w chwili pojawienia się sygnału, a nie telefonu użytkownika, więc cały strumień zgłoszeń przestaje trafiać na help desk
- Użytkownicy dowiadują się, co się stało albo co mają zrobić, z wiadomości w Teams, co zamienia zaskakującą awarię w trzydzieści sekund czytania
- Zgłoszenia, które trafiają do inżyniera, przychodzą z telemetrią, historią i propozycją naprawy, więc diagnoza zaczyna się od dowodów, a nie od pytań
- Powtarzalne usterki na modelu lub w lokalizacji stają się nazwanymi problemami, co ucina dwudziestą identyczną naprawę i skraca okno ekspozycji maszyn bez poprawek
Perspektywa zarządu
- Zapobieganie staje się mierzalne: ustalenia na przebieg, naprawy bez zgłoszenia, wykonane działania użytkowników, zgłoszenia założone przed telefonem
- Ekspozycja na braki poprawek i niezgodności zamienia się w dzienną liczbę z właścicielem, a nie w miesięczny raport docierający po zamknięciu okna
- Czas inżynierów przesuwa się ze skryptowych napraw do prawdziwej diagnozy i widać to w liczbach, a nie we wrażeniu
- Odpowiedzią na pytanie „co działa na naszych urządzeniach bez człowieka” jest wersjonowana lista zatwierdzonych runbooków z imiennymi właścicielami
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Bezpieczeństwo projektujemy razem z procesem, nie po nim.
- Robot czyta przez Microsoft Graph z tożsamością aplikacyjną ograniczoną do odczytów urządzeń, bezpieczeństwa i skrzynek oraz do akcji urządzeń wywoływanych przez runbooki. Sekrety są pobierane w czasie wykonania z magazynu poświadczeń, własnego w Orchestrator albo Państwa Azure Key Vault
- Każdy runbook ma imiennego właściciela, wersję i listę grup urządzeń, których może dotknąć. Ten, który zawiedzie, zatrzymuje się i zakłada zgłoszenie, zamiast ponawiać w ciemno, a pilotaż działa najpierw w trybie samego wykrywania
- Agent czyta dziennik napraw i nic poza nim. Działa za AI Trust Layer z listą dozwolonych modeli, maskowaniem danych osobowych i własnym śladem audytowym, a jego wynik pozostaje projektem, dopóki menedżer problemów go nie przyjmie
- Karty dla użytkownika niosą tylko to, co jest mu potrzebne do działania; przetwarzanie pozostaje w regionach UE UiPath Automation Cloud i Microsoft 365, a każdy przebieg i każdą naprawę da się odtworzyć z dziennika Orchestrator
Dlaczego teraz
Impuls przychodzi zwykle z zewnątrz: audyt bezpieczeństwa pytający, jak długo znana podatność pozostawała otwarta, personel terenowy, który nie może czekać na oddzwonienie, albo budżet sprzętowy wydawany na wymiany, którym zapobiegłaby naprawa
Intune i Defender for Endpoint udostępniają dziś przez Microsoft Graph większość tego, co technik zbierał kiedyś ręcznie, a akcje urządzeń korygujące stany rutynowe są dostępne tą samą drogą, na ograniczonej tożsamości
Robot wykonuje te akcje pod zatwierdzeniem i audytem, a model językowy potrafi przeczytać miesiąc dzienników napraw i zaproponować ukryte w nich wzorce; sam czas help desku i inżynierów jest modelowany na 8 670 € miesięcznie
Role zarządcze, których to dotyczy
Flota urządzeń staje się czymś, czym IT zarządza z wyprzedzeniem wobec awarii, z liczbą prewencyjną do pokazania zarządowi zamiast liczby zgłoszeń
Strumień możliwych do uniknięcia zgłoszeń znika z help desku, a inżynierowie przestają powtarzać skryptowe naprawy na tych samych trzech modelach
Pracownicy terenowi i pierwszej linii tracą mniej godzin na laptopie, który padł w dniu, o którym telemetria już uprzedzała
Częste pytania i zastrzeżenia
Potrafi, dla konkretnych sprawdzeń skryptowych. To, co dochodzi tutaj, to klasyfikacja obejmująca Intune, Defender for Endpoint, Exchange Online i Państwa urząd certyfikacji w jednym przebiegu, wiadomość do użytkownika, zgłoszenie z dowodami i ślad zatwierdzeń dla każdego runbooka.
Każdy runbook jest zatwierdzany przez imiennego właściciela, ograniczony do grup urządzeń i wersjonowany, a pilotaż działa w trybie samego wykrywania, dopóki help desk nie zgodzi się z klasyfikacją. Alternatywą nie jest „brak napraw”: to te same naprawy ręcznie, bez zapisu.
Alerty bez dołączonego działania topią wszystkich. Tutaj każde ustalenie wychodzi z przebiegu jako runbook, karta użytkownika albo zgłoszenie, a liczba każdego z nich mówi, czy próg jest ustawiony dobrze.
Kiedy to nie jest właściwe rozwiązanie
- Mniej niż kilkaset urządzeń, gdzie jeden technik obejmuje wzrokiem całą flotę, a kwartalna kontrola kosztuje mniej niż przepływ
- Urządzenia nie są zarządzane w Intune ani w równoważnym narzędziu, więc nie ma telemetrii do czytania; pierwszym projektem jest zarządzanie urządzeniami, a nie to
- Zewnętrzny dostawca usług utrzymania urządzeń kontraktowo odpowiada już za proaktywne naprawy albo zgłoszenia sprzętowe są rzadkie, a czas help desku idzie gdzie indziej
Pytanie na najbliższe posiedzenie
Czy wolelibyśmy usłyszeć o 212 urządzeniach, które zaraz padną, z dzisiejszego pulpitu, czy od ich użytkowników przez najbliższy miesiąc?
Podejście wdrożeniowe
Co dokładnie dostarczamy i czego potrzebujemy na start.
Dostarczamy
- Zestawienie miesiąca zgłoszeń sprzętowych z telemetrią tych samych urządzeń, które ustala udział możliwy do uprzedzenia na Państwa danych
- Model progów i reguły klasyfikacji, uzgodnione z help deskiem i z bezpieczeństwem
- Pierwsze runbooki naprawcze, zwykle dysk, ponowienie aktualizacji i limit skrzynki, każdy zatwierdzony i ograniczony do grupy urządzeń
- Karty i informacje dla użytkownika w Teams, szablon zgłoszenia ServiceNow z telemetrią i propozycją naprawy oraz drogę od zwalidowanej przyczyny źródłowej do rekordu problemu
- Dziennik napraw, raport prewencyjny i konfigurację agenta do sporządzania przyczyn źródłowych
Potrzebujemy od Państwa
- Tożsamości aplikacyjnej Microsoft Graph dla robota, ograniczonej do odczytów urządzeń, bezpieczeństwa i skrzynek oraz akcji urządzeń wywoływanych przez runbooki
- Imiennie wskazanej osoby zatwierdzającej runbooki i menedżera problemów oraz miesiąca zgłoszeń sprzętowych do zestawienia z telemetrią
- Państwa progów lub ich pierwszej wersji od help desku oraz grup urządzeń, na których może działać pilotaż
Etapy
Analiza
Zestawienie miesiąca zgłoszeń z telemetrią tych samych urządzeń i wyznaczenie udziału możliwego do uprzedzenia
Tylko wykrywanie
Klasyfikacja działa i raportuje; nic nie jest naprawiane, a help desk konfrontuje ustalenia z rzeczywistością
Pierwsze runbooki
Trzy rutynowe naprawy ruszają dla jednej grupy urządzeń, z przeglądem każdego przebiegu
Skalowanie
Kolejne runbooki i grupy urządzeń, progi dostrajane na podstawie tego, co znajdują przebiegi
Wzorce
Agent sporządza przyczyny źródłowe, gdy dziennik jest już wart czytania, a menedżer problemów je waliduje
Działowe. O nakładzie decyduje liczba źródeł telemetrii, to, ile runbooków help desk chce zautomatyzować, oraz jak restrykcyjny jest proces zmian dla urządzenia produkcyjnego.
Awaria była na pulpicie trzy tygodnie wcześniej niż w słuchawce telefonu.
Prosimy przesłać jeden eksport zgodności z Intune i miesiąc zgłoszeń sprzętowych. Zestawiamy je i oddajemy zgłoszenia, które były widoczne w telemetrii, zanim ktokolwiek je zgłosił, wraz z trzema runbookami, które zamknęłyby je jako pierwsze.
Porównajmy eksport z Intune ze zgłoszeniamiTen sam problem ma zwykle sąsiedni proces
Cztery zgłoszenia IT na dziesięć mają znaną procedurę, a każde z nich i tak czeka w kolejce na analityka.
Zobacz rozwiązanie Inne rozwiązaniaStatusy, awarie i zmiany ogłaszane, zanim ktoś zapytaMail o awarii wychodzi po awarii, a co piąty komentarz w kolejce zgłoszeń to te same dwa słowa.
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