Większość MŚP dowiaduje się o problemie od klienta. Zadzwonił, bo zamówienie nie wyszło. Napisał, bo czeka na ofertę trzeci tydzień. Zrobił awanturę, bo faktura jest po terminie, choć zapłacił dwa tygodnie temu. W ERP wszystko to było widać — tylko nikt nie patrzył, bo nikt nie miał powodu, żeby patrzeć akurat w ten raport, akurat tego dnia.
Alert biznesowy odwraca sytuację. To system sam mówi: „kierowniku zakupu — ta pozycja leży już 90 dni, a jutro masz spotkanie z dostawcą". „Panie prezesie — marża na kliencie X spadła o 15% w tym miesiącu". „Handlowcze — klient Y czeka na ofertę od pięciu dni roboczych". Nie trzeba logować się do ERP, nie trzeba otwierać raportu. Problem przychodzi do człowieka, zanim klient zdąży się zdenerwować.
Problem w tym, że pierwszym odruchem jest „to ustawmy alerty na wszystko". A po dwóch tygodniach cały zespół wyłącza powiadomienia, bo w Teamsach brzęczy co pięć minut i nikt już nie wie, które naprawdę coś znaczą.
Czym jest alert biznesowy — i czym nie jest
To nie jest monitoring IT. Monitoring IT pilnuje, czy serwer żyje, czy łącze stoi, czy backup się zrobił — o tym napisaliśmy osobno (patrz monitoring IT w MŚP). Alert biznesowy pilnuje czegoś innego: zdarzeń w procesach biznesowych, które wymagają reakcji człowieka.
Różnica jest praktyczna. Monitoring IT dzwoni do administratora o trzeciej w nocy, bo serwer stanął. Alert biznesowy dzwoni do handlowca we wtorek o 9:15, bo klient czeka na ofertę od pięciu dni. Pierwsze są binarne (działa/nie działa). Drugie są progowe (coś się dzieje za wolno, za rzadko, poniżej normy).
Alert biznesowy ma trzy właściwości, których nie ma zwykły raport:
- Dociera do konkretnej osoby, nie do skrzynki ogólnej firmy. „Alert do handlowca prowadzącego ofertę", a nie „alert do działu handlowego".
- Jest zaadresowany do działania, nie do przeczytania. „Oferta OF/2026/0421 czeka 5 dni — zadzwoń do klienta" ma sens; „Lista otwartych ofert w załączniku" nie ma.
- Ma próg uruchomienia, nie wysyła się za każdym razem, kiedy coś się zdarzy.
Jeśli nie spełnia tych trzech warunków, to nie jest alert, tylko spam.
Co warto pilnować w typowej MŚP
Lista alertów, które zwrotniej pracują w firmach 10–50-osobowych, nie jest długa. Ciekawe jest to, że to nie są zaawansowane rzeczy. To są podstawowe sygnały, które każdy właściciel i tak chciałby znać — tylko do tej pory znał je dwa dni za późno.
- Oferta bez odpowiedzi. Oferta wystawiona ponad X dni temu, bez statusu „wygrana" ani „przegrana". Trafia do handlowca prowadzącego ofertę i do jego kierownika. Próg: zwykle 5–7 dni roboczych.
- Zamówienie zablokowane na etapie. Zamówienie klienta leży ponad X dni w statusie innym niż „zrealizowane" lub „anulowane". Trafia do kierownika obsługi klienta. Próg: 3 dni, jeśli normalny cykl to jeden.
- Faktura przeterminowana z progiem kwotowym. Nie każdy brak płatności — tylko te powyżej kwoty, która realnie boli (np. 10 tys. zł) i więcej niż 7 dni po terminie. Trafia do księgowości i handlowca.
- Stan magazynowy poniżej minimum na towarze A/B. Nie na wszystkim — tylko na tych pozycjach, które leżą w podstawowej ofercie i których brak natychmiast widzi klient. Analizy ABC/XYZ to osobny temat.
- Marża kontraktu / klienta poniżej progu. Pozycja w zamówieniu z marżą poniżej X% — alert do kierownika sprzedaży, nie blokada systemu.
- Zgłoszenie reklamacyjne nieprzydzielone w 24h. Jeśli nikt nie podjął sprawy w ciągu doby roboczej — alert do kierownika serwisu/obsługi.
Jedno z klasycznych przeciążeń: alert po każdym zalogowaniu administratora, alert po każdym nowym pracowniku, alert po każdej zmianie ceny. To są zdarzenia techniczne. Mają trafić do loga, nie do skrzynki prezesa.
Alert fatigue — największa pułapka
Jeśli człowiek dostaje więcej niż 5–7 alertów dziennie, zaczyna je ignorować. Nie dlatego, że jest leniwy. Dlatego, że ludzki mózg filtruje szum. A szum to wszystko, co nie jest akcją, którą mogę wykonać teraz.
Objawy, że alerty w waszej firmie się zepsuły, są takie:
- „A, to się dzieje codziennie, nie patrzę już." Alert, na który nikt nie reaguje, powinien zostać wyłączony — albo trzeba zmienić próg.
- Alerty idą na wspólną skrzynkę („biuro@", „zamowienia@"), gdzie ktoś je przegląda „jak znajdzie czas". To nie są alerty, to jest kolejka maili.
- Alerty mówią, co się stało, ale nie mówią, co z tym zrobić. „Oferta ma 10 dni" to raport. „Oferta ma 10 dni — zadzwoń do klienta Y lub oznacz jako przegraną" to alert.
- Powiadomienie dociera na pięciu kanałach jednocześnie (mail + Teams + SMS + powiadomienie w ERP + telefon). Jeden kanał na jeden alert.
Dobra zasada: w pierwszym miesiącu działa 60–70% alertów, które ustawiliście. Reszta musi zostać wyłączona albo doprecyzowana, inaczej pociągnie resztę w dół.
Narzędzia: od filtra w Optimie po Power Automate
Nie trzeba kupować oddzielnego systemu alertów. W większości MŚP wystarczą trzy rodzaje narzędzi, których firma i tak już używa.
Opcja 1 — natywne mechanizmy ERP. Comarch Optima, enova365, Subiekt, Microsoft Dynamics AX — każdy z nich ma jakąś formę filtrów, zapisanych list, przypomnień. Nie są to pełne silniki alertów, ale do kilku kluczowych zdarzeń (przeterminowane faktury, stany minimalne) wystarczają. Zaleta: nie trzeba integracji. Wada: alert zwykle „siedzi" w ERP i nie wyjdzie na Teams/SMS bez pomocy z zewnątrz.
Opcja 2 — Power Automate / Zapier / Make. Jeśli ERP ma API albo przynajmniej eksport do CSV/SQL, Power Automate (w ramach Microsoft 365, który i tak macie) potrafi uruchamiać alerty po harmonogramie: codziennie o 7:30 sprawdza bazę, wysyła e-mail lub wiadomość na kanał Teams. To jest realistyczne narzędzie dla 90% MŚP — niska bariera wejścia, wszystko w jednym koncie Microsoftowym, logi dostępne, działa od pierwszego dnia.
Opcja 3 — zapytania SQL + prosty skrypt. Jeśli macie informatyka albo zewnętrznego programistę od ERP, najtańszy wariant to zapytanie SQL do bazy ERP uruchamiane cyklicznie przez skrypt, który wysyła maila/wiadomość. Działa stabilnie, kosztuje jednorazowo kilka godzin pracy, ale wymaga ręki, która zna strukturę bazy — i następca tej osoby musi wiedzieć, gdzie te skrypty żyją (patrz bus factor w IT).
Jeśli ERP ma własny moduł workflow (Comarch DMS, enova365 Workflow), warto się mu przyjrzeć, zanim doklei się trzecie narzędzie — ale u 10-osobowego klienta często okazuje się, że własny workflow w ERP jest przerostem formy.
Jeden konkretny przykład
U jednego z naszych klientów — 24-osobowej hurtowni materiałów elektrycznych, która handluje głównie z elektrykami i małymi firmami instalacyjnymi — zaczęliśmy od 23 proponowanych alertów. „Niech system mówi nam wszystko". Po trzech tygodniach właściciel sam napisał: „ludzie wyłączają Teamsy, bo nie mogą pracować".
Zostało sześć:
- Oferta bez odpowiedzi >6 dni roboczych — do handlowca prowadzącego i kopia do kierownika sprzedaży. Przed alertami średni czas „do zamknięcia oferty" wynosił 18 dni roboczych, po trzech miesiącach spadł do 11.
- Zamówienie klienta zablokowane >48 h w statusie „do kompletacji" — do kierownika magazynu. Wcześniej średnio raz w tygodniu zdarzało się, że zamówienie leżało 4–5 dni, bo „brakuje jednej pozycji, zaraz ją zamówimy". Po wdrożeniu — statystycznie zero takich przypadków w kwartale.
- Faktura powyżej 8 tys. zł, >7 dni po terminie — do księgowej i handlowca prowadzącego. Windykacja (patrz automatyzacja windykacji) przestała wyglądać jak akcja ratunkowa na koniec miesiąca.
- Stan magazynowy poniżej minimum na top 50 pozycji — raz dziennie o 7:00 do kierownika zakupów. Pozostałe 2 000 indeksów ma inny mechanizm (reorder point w ERP), bo nie wymagają reakcji człowieka.
- Reklamacja bez przypisania >24 h — do kierownika serwisu. Wcześniej zdarzały się reklamacje leżące tydzień, bo „trafiły na skrzynkę zbiorczą".
- Marża pozycji na zamówieniu <12% — do kierownika sprzedaży, nie do systemu blokującego. Pozycje poniżej progu to zwykle świadome decyzje handlowe, ale ktoś z zarządu powinien je widzieć.
Narzędziowo: trzy pierwsze alerty w Power Automate, które o 7:30 odpytywało SQL w Optimie i wrzucało wiadomość na konkretny kanał Teams. Czwarty i piąty natywnie w ERP + powiadomienie mailowe. Szósty — zapytanie SQL uruchamiane po stronie bazy. Jednorazowy koszt wdrożenia: około 20 godzin pracy integratora rozłożonych na trzy tygodnie. Utrzymanie: 1–2 godziny miesięcznie na dostrajanie progów.
Oszczędność czasowa była trudna do zmierzenia dokładnie, ale właściciel pod koniec kwartału podsumował to inaczej: „pierwszy raz od dawna nie dowiedziałem się o problemie od klienta".
Jak zacząć w dwa tygodnie
Nie trzeba robić rewolucji. Kolejność, która sprawdza się u klientów:
- Tydzień 1 — rozmowa z zespołem. Nie z integratorem, nie z zarządem. Z ludźmi, którzy codziennie siedzą w ERP. „Co byś chciał wiedzieć wcześniej niż się dowiadujesz dzisiaj?" Zbiera się listę kilkunastu propozycji — tak powstają prawdziwe alerty, nie te wymyślone na slajdach.
- Tydzień 1 — przyszpilenie 5–7 najważniejszych. Nie więcej. Reszta czeka na drugą turę. Dla każdego: kto dostaje, jakim kanałem, co ma zrobić po otrzymaniu, kiedy alert znika.
- Tydzień 2 — wdrożenie technicznie. Preferencyjnie w narzędziach, które już macie (ERP + Power Automate). Nowe narzędzie dokupujecie tylko wtedy, gdy coś naprawdę nie wychodzi.
- Po miesiącu — przegląd. Które alerty zadziałały? Które są ignorowane? Które powinny mieć wyższy próg? Jeden wtorek po południu wystarczy.
Jeśli nie wiecie, od których alertów zacząć w waszej firmie — pół godziny rozmowy z kimś, kto podobne listy układał już kilkanaście razy, oszczędza dwa tygodnie błądzenia po omacku.
Dobry alert nie mówi „coś się stało". Dobry alert mówi „zrób to teraz, bo za trzy dni będzie za późno".
Porozmawiajmy o alertach biznesowych w Twojej firmie →