Firma dystrybucyjna zatrudniająca 150 pracowników obsługiwała 340 zgłoszeń miesięcznie. Każde przechodziło przez ręczne przypisanie, ręczne powiadomienie i ręczne przypomnienie o zbliżającym się SLA. Dział IT poświęcał na tę "administrację" 23 godziny tygodniowo. Po wdrożeniu Oxari Workflow (3 tygodnie konfiguracji, zero nowych etatów) czas obsługi skrócił się o 45%, a 80% zgłoszeń trafia do właściwego technika bez żadnej ręcznej interwencji. Poniżej masz dokładnie ten sam przepis.
Spis treści
Co to jest Oxari Workflow?
Oxari ITSM to polskie oprogramowanie do zarządzania usługami IT, tworzone i rozwijane z myślą o średnich i dużych organizacjach na rynku europejskim. Moduł Workflow to wbudowany silnik reguł automatyzacji, który reaguje na zdarzenia zachodzące w systemie zgłoszeń i uruchamia określone akcje bez udziału człowieka.
W odróżnieniu od prostych reguł przypisania (które działają jednorazowo przy tworzeniu ticketu), Oxari Workflow monitoruje cały cykl życia zgłoszenia: od momentu wpłynięcia, przez zmiany statusu, odpowiedzi klienta, zbliżający się termin SLA, aż po zamknięcie i ocenę jakości obsługi.
Architektura reguły w Oxari składa się z trzech elementów:
- Trigger: zdarzenie, które uruchamia regułę (np. "zgłoszenie zmienia priorytet na Krytyczny")
- Warunki: filtry zawężające, kiedy reguła ma zadziałać (np. "tylko kategoria Infrastruktura", "tylko w godzinach pracy")
- Akcje: operacje wykonywane automatycznie (przypisanie technika, zmiana statusu, wysłanie powiadomienia, eskalacja do przełożonego)
Kluczowe triggery: od czego zaczyna się automatyzacja
Oxari dzieli triggery na dwie kategorie: zdarzeniowe (reagują natychmiast po zajściu zdarzenia) oraz czasowe (uruchamiają się po upływie określonego czasu).
Triggery zdarzeniowe
- Nowe zgłoszenie: najczęstszy punkt startu; uruchamia routing i pierwsze powiadomienie do technika
- Zmiana priorytetu: gdy ticket jest "ulepszany" do Krytycznego, automatycznie trafia na dashboard on-call i wysyła SMS
- Komentarz klienta na zamkniętym tickecie: Oxari może automatycznie ponownie otworzyć zgłoszenie i powiadomić technika
- Zmiana statusu: np. "W trakcie → Oczekuje na klienta" wstrzymuje zegar SLA i wysyła email z prośbą o odpowiedź
- Przypisanie do technika: wyzwala powiadomienie Teams z linkiem bezpośrednim do ticketu
Triggery czasowe
- X minut przed przekroczeniem SLA: np. 30 minut przed deadline'em wysyła alert do technika i team leadera
- Brak aktywności przez N godzin: przypomnienie dla technika lub automatyczne przekazanie do koordynatora
- Rano o 8:00: codzienny digest otwartych ticketów po priorytecie; wysyłany do kierowników działu IT
- X dni od zamknięcia: automatyczne wysłanie ankiety satysfakcji (CSAT)
Jeśli Twój helpdesk pracuje na Jira Service Management zamiast Oxari, analogiczne konfiguracje znajdziesz w artykule o SLA i kolejkach w JSM.
Każdy trigger można łączyć z warunkami za pomocą operatorów AND/OR i grup nawiasowych. Oxari nie ogranicza liczby warunków na regułę.
Budowanie reguł krok po kroku
Poniższy przepis odwzorowuje pierwszą regułę, którą wdrożyliśmy u klienta dystrybucyjnego: automatyczny routing oparty na kategorii zgłoszenia i lokalizacji użytkownika. To dobry punkt startowy dla każdej organizacji z więcej niż jednym działem IT.
Wejdź do Administracja → Workflow → Nowa reguła
Oxari grupuje reguły w zestawy (rule sets). Zanim dodasz pierwszą regułę, utwórz zestaw tematyczny, np. "Routing i Przypisanie". Ułatwia to późniejszy audyt i wyłączanie konkretnych zestawów podczas testów.
Wybierz trigger: "Nowe zgłoszenie"
Dla reguł routingu zawsze startuj od triggera zdarzeniowego "Nowe zgłoszenie". Uruchamia się w momencie rejestracji ticketu, zanim jakikolwiek technik go zobaczy. Ważne: Oxari pozwala wybrać, czy reguła działa na zgłoszenia z portalu self-service, z emaila, z API. Każde źródło można filtrować osobno.
Dodaj warunki filtrujące
Przykładowy zestaw warunków: Kategoria = "Infrastruktura sieciowa" AND Lokalizacja użytkownika = "Warszawa". Oxari obsługuje porównania tekstowe (równe, zawiera, zaczyna się od), wartości liczbowe (większy niż, mniejszy niż) oraz listy wartości (jest jednym z). Pola niestandardowe (custom fields) również są dostępne jako warunki.
Zdefiniuj akcje
Dla reguły routingu typowy zestaw akcji to: (1) Przypisz do grupy "IT Sieć Warszawa", (2) Ustaw priorytet na podstawie pola "Pilność" z formularza, (3) Wyślij powiadomienie Teams do kanału #it-siec-waw z linkiem do ticketu. Akcje wykonują się sekwencyjnie, więc kolejność ma znaczenie.
Przetestuj w trybie "Dry run"
Oxari posiada tryb symulacji reguł na historycznych danych. Wybierz 20–30 ticketów z ostatnich 30 dni i uruchom symulację. System pokaże, ile reguła "trafiłaby" i jakie akcje zostałyby wykonane. Sprawdź, czy odsetek pasujących ticketów zgadza się z oczekiwaniami. Jeśli reguła trafia w 100% przypadków, prawdopodobnie jest za szeroka.
Aktywuj i monitoruj przez 5 dni
Po aktywacji reguły przejdź do zakładki "Logi Workflow" i obserwuj pierwsze rzeczywiste wykonania. Oxari loguje każde uruchomienie z informacją: która reguła, na którym tickecie, z jakim wynikiem. Błędy konfiguracji (np. technik nieistniejący w systemie) widoczne są natychmiast.
Jak zredukowali MTTR z 14h do 3h w ciągu 3 tygodni
Klient obsługiwał 340 zgłoszeń miesięcznie przez 4-osobowy dział IT. Problem: wszystkie tickety trafiały do jednej kolejki, a przypisanie było ręczne. Skutek: 14h średniego MTTR, częste przekroczenia SLA, frustracja techników.
Co skonfigurowano:
- 8 reguł routingu (4 kategorie × 2 lokalizacje)
- Macierz priorytetów Impact × Urgency: automatyczne ustawienie priorytetu przy tworzeniu ticketu
- Eskalacja 30 min przed SLA do team leadera przez Teams
- Powiadomienie SMS przy Krytycznym priorytecie poza godzinami pracy
- Dzienny digest o 8:00 z listą ticketów starszych niż 24h
Wyniki po 60 dniach: MTTR 3h (vs 14h), SLA compliance 96% (vs 71%), czas poświęcony na "administrację" ticketów 4h/tydz. (vs 23h/tydz.).
Najlepsze praktyki konfiguracji
Po wdrożeniu kilkunastu instancji Oxari u klientów z sektora produkcji, dystrybucji i usług, zidentyfikowaliśmy zestaw zasad, które oddzielają udane wdrożenia od tych wymagających ponownej konfiguracji po trzech miesiącach.
Zacznij od routingu, nie od eskalacji
Najpierw upewnij się, że każde zgłoszenie trafia do właściwej grupy. Bez tego eskalacje i SLA nie mają sensu. Routing to fundament. Buduj eskalacje dopiero gdy odsetek ręcznych przepisań ticketów spadnie poniżej 10%.
Używaj grup, nie konkretnych techników
Przypisuj reguły do grup/kolejek, nie do imiennych techników. Technik może być na urlopie, zwolnieniu, może zmienić pracę. Reguły przypisujące po imieniu stają się punktem awarii. Oxari obsługuje round-robin w obrębie grupy, więc po prostu go włącz.
Jedno zdarzenie, maksymalnie 3 akcje
Jeśli jeden trigger wywołuje 6+ akcji, system jest zbyt skomplikowany do debugowania. Podziel logikę na kilka reguł z wąskim zakresem. Oxari umożliwia ustawienie kolejności wykonywania reguł, więc korzystaj z tego.
Dokumentuj każdą regułę w polu "Opis"
Oxari pozwala dodać opis do każdej reguły. Wpisuj tam: kto zdefiniował regułę, datę, cel biznesowy i kogo powiadomić przy problemie. Za 6 miesięcy nie będziesz pamiętać, dlaczego reguła nr 17 działa tylko w nocy.
Testuj na środowisku staging przed produkcją
Oxari wspiera eksport i import zestawu reguł między instancjami. Buduj i testuj na środowisku testowym. Jeden błąd w regule produkcyjnej może zalać techników setkami nieuzasadnionych powiadomień w środku nocy.
Oxari vs Jira Automation vs ManageEngine SDP
Pytanie "który silnik workflow jest najlepszy" nie ma jednej odpowiedzi. Poniższa tabela zestawia trzy systemy w obszarach, które mają znaczenie operacyjne dla działu IT 50–500 osób.
| Kryterium | Oxari Workflow | Jira Automation | ManageEngine SDP |
|---|---|---|---|
| Interfejs konfiguracji | Wizualny, PL | Wizualny, EN | Formularze, EN/PL |
| Triggery czasowe (SLA) | Natywne, granulacja 1 min | Natywne, godziny | Natywne, granulacja 1 min |
| Integracja z MS Teams | Natywna, bez kodu | Natywna, bez kodu | Webhook, wymaga konfiguracji |
| Round-robin przypisania | Wbudowany | Brak natywnie | Wbudowany |
| Tryb symulacji (dry run) | Tak | Nie | Nie |
| Wsparcie SLA wielopoziomowe | Tak (SLA per kategoria) | Wymaga pluginu | Tak (natywnie) |
| Warunki na polach custom | Tak | Tak | Tak |
| Wsparcie w języku polskim | Tak (producent PL) | Nie (Atlassian, EN) | Częściowe (dokumentacja EN) |
| Model licencyjny | Per instancja / per agent | Per użytkownik (drogie przy skali) | Per technik |
| Krzywa uczenia się | Niska | Średnia | Średnia |
Werdykt: Oxari wygrywa w kontekście polskich organizacji: polskojęzyczny interfejs, wsparcie i producent na miejscu, niższa krzywa uczenia się. Jira Automation sprawdzi się lepiej, jeśli organizacja już intensywnie korzysta z ekosystemu Atlassian (Jira Software, Confluence). ManageEngine SDP jest lepszym wyborem gdy potrzebujesz głębokiej integracji z narzędziami ManageEngine (CMDB, OpManager, AD Manager).
Typowe błędy przy wdrożeniu Oxari Workflow
Błąd 1: Zbyt wiele reguł od razu
Zespoły, które próbują zautomatyzować wszystko w ciągu pierwszego tygodnia, kończą z 40 regułami, których nikt nie rozumie i które wzajemnie się nadpisują. Zacznij od 5 kluczowych reguł routingu. Dodawaj kolejne co 2 tygodnie, po ocenie skuteczności poprzednich.
Błąd 2: Brak warunków filtrujących, czyli reguła "catch-all"
Reguła bez warunków działa na wszystkich ticketach. To szczególnie niebezpieczne dla akcji "Wyślij powiadomienie". Jeden błąd i kilkuset użytkowników dostaje email, który nie był dla nich przeznaczony. Zawsze dodawaj co najmniej jeden warunek kontekstowy.
Błąd 3: Nieaktywny użytkownik jako odbiorca eskalacji
Reguły eskalacji wpisane z konkretnym adresem email technika przestają działać poprawnie po odejściu tej osoby. Używaj ról systemowych ("Kierownik działu IT") lub grup. Oxari obsługuje dynamiczne referencje do ról w polach odbiorcy.
Błąd 4: Ignorowanie logów workflow
Oxari przechowuje historię uruchomień każdej reguły. Większość administratorów nie sprawdza tych logów, przez co niedziałające reguły "siedzą" w systemie miesiącami. Ustaw miesięczny przegląd: reguły z 0 uruchomieniami w ciągu 30 dni albo są zbędne, albo mają błąd warunku.
Błąd 5: Brak testowania po aktualizacji systemu
Aktualizacje Oxari mogą zmieniać nazwy pól, strukturę API lub dostępne triggery. Po każdej aktualizacji uruchom symulację dry run na kluczowych regułach zanim przejdą na produkcję.
Czytaj dalej
NinjaOne RMM: kompletny przewodnik dla IT managerów 5 błędów przy wdrożeniu systemu MES/APS, które kosztują firmy miesiące ProGet MDM: jak zabezpieczyć urządzenia mobilne w firmie Oxari: funkcje systemu ITSM dla firm produkcyjnych i MSPFAQ: najczęstsze pytania o Oxari Workflow
Czym różni się Oxari Workflow od zwykłych reguł przypisania zgłoszeń?
Zwykłe reguły przypisania to jednorazowe akcje uruchamiane przy tworzeniu ticketu (np. przypisz do działu X). Oxari Workflow to silnik wielostanowy, który reaguje na zmiany w całym cyklu życia zgłoszenia: zmianę priorytetu, upływ SLA, odpowiedź klienta czy brak aktywności. Możesz definiować łańcuchy warunków (AND/OR), opóźnienia czasowe i akcje zbieżne.
Ile czasu zajmuje wdrożenie Oxari Workflow od zera?
Podstawowy zestaw reguł (routing, SLA, jedno powiadomienie eskalacyjne) można skonfigurować w ciągu 2–4 godzin. Pełne wdrożenie obejmujące wielopoziomowe eskalacje, integracje z AD i powiadomienia SMS/Teams zajmuje zwykle 2–5 dni roboczych. Czas zależy od liczby kategorii zgłoszeń i złożoności macierzy priorytetów.
Czy Oxari Workflow integruje się z Microsoft Teams i Active Directory?
Tak. Oxari posiada natywny konektor do Microsoft Teams (powiadomienia kanałowe i wiadomości prywatne do technika), synchronizację użytkowników z Active Directory/Azure AD oraz webhook do dowolnego systemu zewnętrznego. Integracja z Teams nie wymaga dodatkowych licencji, jest wbudowana w moduł Workflow.
Jakie triggery są dostępne w Oxari Workflow?
Oxari obsługuje triggery zdarzeniowe (nowe zgłoszenie, zmiana statusu, komentarz klienta, zmiana priorytetu, zamknięcie) oraz triggery czasowe (X minut/godzin po zdarzeniu, koniec okna SLA, cykliczne reguły poranne). Każdy trigger można filtrować warunkami: kategoria, priorytet, dział, lokalizacja, wartość pola niestandardowego.
Czy Oxari Workflow zastępuje ManageEngine ServiceDesk Plus?
To zależy od kontekstu. Oxari to system tworzony z myślą o polskim rynku, z polskojęzycznym interfejsem, wsparciem i producentem dostępnym lokalnie. ManageEngine SDP oferuje głębszą integrację z ekosystemem ManageEngine (CMDB, AD Manager, OpManager) i jest lepszym wyborem dla organizacji już korzystających z tej rodziny produktów. Rotech Group wdraża oba systemy. Wybór zależy od istniejącej infrastruktury klienta.
Podsumowanie
Oxari Workflow to jeden z najbardziej niedocenianych modułów polskiego rynku ITSM. Organizacje, które traktują go poważnie (budują reguły iteracyjnie, testują przed produkcją i regularnie audytują logi) osiągają rezultaty, które w liczbach brzmią jak marketingowa przesada: 45% krótszy czas obsługi, MTTR poniżej 4 godzin, niemal zerowe ręczne przypisania.
Kluczowe wnioski z tego artykułu:
- Zacznij od 5 reguł routingu, nie od 40 reguł "wszystkiego"
- Używaj grup, nie imiennych techników: reguły muszą przetrwać zmiany kadrowe
- Trigger + Warunki + Akcje to formuła każdej reguły, trzymaj się jej
- Tryb dry run przed aktywacją to obowiązek, nie opcja
- Sprawdzaj logi co miesiąc: martwe reguły to dług techniczny
Jeśli chcesz zobaczyć, jak Oxari Workflow zadziała w Twoim środowisku, skontaktuj się z nami. Oferujemy bezpłatną sesję konfiguracyjną, podczas której zmapujemy Twoje procesy i pokażemy, które reguły dadzą najszybszy zwrot.
Wdrożymy Oxari Workflow w Twojej firmie
Bezpłatna konsultacja i mapa reguł skrojona pod Twoje procesy. Pierwsze wyniki widoczne w ciągu 2 tygodni od startu konfiguracji.
Umów bezpłatną konsultacjęRozważasz wdrożenie systemu ITSM? Sprawdź jak wygląda wdrożenie z Rotech Group →