To historia o tym, jak ogólnopolska sieć ponad 3500 placówek odzyskała kontrolę nad procesem sprzedaży. Dzięki rozszerzeniu Zabbixa o monitoring POS i drukarek fiskalnych oraz wdrożeniu wizualizacji danych o SLA w Grafanie.

W codziennym funkcjonowaniu sieć współpracuje z szeregiem partnerów zewnętrznych – od dostawców urządzeń (drukarki fiskalne, routery, terminale POS), przez operatorów sieci i łączy zapasowych, aż po twórców i integratorów aplikacji sprzedażowych oraz systemów BI.

Każda z blisko 3 500 lokalizacji korzysta z tuneli VPN/IPsec, urządzeń lokalnych i niezależnych łączy, a do poprawnego działania potrzebuje stałej łączności z centralą. W placówkach działają systemy POS (Point of Sale), czyli zestawy sprzętowo-aplikacyjne obsługujące sprzedaż, komunikujące się z drukarkami fiskalnymi i rejestrujące transakcje zgodnie z wymogami prawnymi.

Dane sprzedażowe oraz informacje operacyjne są lokalnie przetwarzane, a następnie przesyłane do systemów BI w centrali, wspierając raportowanie, controlling i decyzje strategiczne zarządu.

Brakowało zautomatyzowanego mechanizmu powiadomień i jednoznacznej matrycy odpowiedzialności. Nie było jasne, kto powinien reagować, eskalować lub rozliczać dostawcę. Awarie były zgłaszane i obsługiwane ręcznie – często dopiero przez użytkowników końcowych, co znacząco opóźniało reakcję. Problemy najczęściej trafiały do zespołu BI dopiero wtedy, gdy widoczne były już błędy w raportach.

Kto potrzebował bieżących i realnych danych

Zespół BI potrzebował wiarygodnych danych o dostępności urządzeń, by tworzyć dokładne raporty sprzedażowe i operacyjne. Brak danych = błędne analizy, eskalacje i spadek zaufania do systemów.

Zarząd oczekiwał spójnych danych do podejmowania decyzji strategicznych. Potrzebował wglądu w to, co dzieje się w placówkach, bez czekania na ręczne raporty.

Kierownik utrzymania IT musiał kontrolować SLA i reagować na incydenty, zanim wpłyną one na sprzedaż. Potrzebował natychmiastowej informacji o awariach POS i drukarek.

Partnerzy zewnętrzni (np. dostawcy drukarek fiskalnych) oczekiwali automatycznych powiadomień o problemach z urządzeniami, by mogli reagować zgodnie z własnymi SLA.

Helpdesk potrzebował zautomatyzowanego systemu powiadomień, by szybciej lokalizować problemy i nie tracić czasu na weryfikację zgłoszeń ręcznie.

I jakie miał problemy

Dane były niepełne lub błędne i trafiały do BI dopiero wtedy, gdy problem był już widoczny w raportach.

Brak dashboardów z wizualizacją dostępności, zespół nie wiedział, gdzie faktycznie występuje problem.

Zgłoszenia awarii były ręczne, brakowało matrycy odpowiedzialności i ścieżki eskalacji.

Drukarki odpowiadały na ping, ale nie rejestrowały danych – system nie wykrywał takich przypadków.

Opóźnione reagowanie = straty operacyjne, błędne dane w BI i utrata zaufania do systemów.

Brak danych = brak rozliczenia z partnerami i ryzyko kar dla dostawców za niedotrzymanie SLA.

Z pozoru wszystko funkcjonowało: systemy POS, drukarki fiskalne, infrastruktura IT. A jednak brak pełnego obrazu sytuacji, ręczne reakcje na awarie i niepełne dane powodowały opóźnienia, błędy i frustrację. I co najważniejsze – prowadziły do realnych strat finansowych, bo każdy incydent uderzał w sprzedaż.

Z czym mierzył się klient

Brak centralizacji monitoringu i ograniczona widoczność

Środowisko klienta było rozproszone i dynamicznie rozwijane, lecz brakowało w nim jednego punktu centralnego, który zapewniłby pełną kontrolę nad infrastrukturą. Incydenty, takie jak problemy z drukarkami fiskalnymi czy zawieszające się aplikacje lokalne, były zauważane dopiero w momencie zakłócenia sprzedaży. Centrala nie miała bieżącego wglądu w stan infrastruktury, a brak historii zdarzeń utrudniał analizę przyczyn i przewidywanie incydentów. Pracownicy na miejscu często nie potrafili samodzielnie zidentyfikować źródła awarii, co opóźniało reakcję.

Niestabilność kluczowych komponentów i brak automatyzacji

Drukarki fiskalne oraz systemy POS narażone były na awarie zarówno sprzętowe, jak i programowe. W przypadku zatrzymania aplikacji kasowej lub przerwania transmisji danych konieczna była ręczna interwencja techniczna, na przykład restart usługi. Brak automatyzacji aktualizacji, restartów i weryfikacji urządzeń zwiększał obciążenie zespołów IT i ograniczał ich możliwość skupienia się na działaniach rozwojowych.

Problemy z jakością danych i wpływ na raportowanie BI

Dane przesyłane do systemów raportowych były często niepełne lub niespójne. Brakowało jednolitego systemu weryfikacji, a niedoskonałości w interfejsach API i mechanizmach synchronizacji prowadziły do rozbieżności między rzeczywistością a tym, co widział zespół BI. W efekcie raporty traciły wiarygodność, co utrudniało podejmowanie trafnych decyzji przez zarząd.

Trudność w egzekwowaniu SLA i brak przejrzystej odpowiedzialności

Bez twardych danych o dostępności usług trudno było rozliczać partnerów z realizacji umów SLA. Klient nie dysponował narzędziami, które jednoznacznie wskazywałyby, kto ponosi odpowiedzialność za dany incydent. Brak jasnego podziału odpowiedzialności skutkował operacyjną niepewnością, przedłużając reklamację i podnosząc koszty obsługi zgłoszeń.

Rosnąca presja była codziennością

Zespoły IT i helpdesk działali reaktywnie, bez narzędzi do wykrywania anomalii ani analizy trendów. Zespół BI również nie miał dostępu do pełnych, wiarygodnych danych, co skutkowało błędami w raportach zarządczych i coraz większym chaosem decyzyjnym.