Comarch ERP XL — dla średnich i dużych firm

Comarch ERP XL to rozbudowany system klasy ERP przeznaczony dla średnich i dużych przedsiębiorstw o bardziej złożonej strukturze procesów niż w mniejszych firmach.

Objaw

Zgłoszenia dotyczą bieżącej administracji systemem w firmach już z niego korzystających, błędów technicznych wpływających na pracę wielu działów naraz, a także konfiguracji integracji z innymi systemami wykorzystywanymi w przedsiębiorstwie.

Możliwe przyczyny

Typowe sytuacje: rozbudowa środowiska IT firmy o kolejne moduły systemu, problemy wydajnościowe przy dużej liczbie jednoczesnych użytkowników, albo potrzeba integracji XL z systemami zewnętrznymi — sklepem internetowym, BaseLinkerem, narzędziami analitycznymi.

Co robimy

Wsparcie obejmuje bieżącą administrację systemem, diagnozowanie i naprawę błędów technicznych, optymalizację wydajności przy dużej liczbie stanowisk oraz konfigurację integracji z innymi systemami wykorzystywanymi w firmie. Ze względu na skalę i złożoność środowisk korzystających z Comarch ERP XL, prace prowadzone są z zachowaniem szczególnej ostrożności wobec danych produkcyjnych — zmiany testowane są w miarę możliwości na środowisku testowym przed wdrożeniem na produkcję.

Ile to trwa

Czas realizacji zależy od charakteru zgłoszenia — proste problemy konfiguracyjne bywają rozwiązywane od ręki, bardziej złożone integracje wymagają dłuższego planowania i testów.

Co można zrobić samemu, zanim przyjedzie serwisant

Warto przygotować dokładny opis problemu wraz z informacją, których modułów i działów firmy dotyczy, oraz czy istnieje środowisko testowe, na którym można bezpiecznie sprawdzić proponowane rozwiązanie.

Czego nie robić: nie warto wprowadzać zmian konfiguracyjnych bezpośrednio na środowisku produkcyjnym bez wcześniejszego przetestowania — przy systemie obsługującym wiele działów naraz błąd odbija się na całej firmie.

Warunki

Wsparcie wyceniane jest indywidualnie, zależnie od zakresu i złożoności środowiska. Warunki współpracy ustalane są bezpośrednio z klientem, bez publikowanych stawek.

Specyficzne warianty problemów technicznych ze środowiskiem Comarch ERP XL

Zgłoszenia dotyczące środowiska, w którym funkcjonuje Comarch ERP XL, rzadko mają jedną prostą przyczynę. System ten składa się z wielu powiązanych modułów, a jego stabilność zależy w dużej mierze od infrastruktury serwerowej i sieciowej. Jednym z najczęstszych wariantów problemu jest nagły spadek wydajności bazy danych. Comarch ERP XL opiera się na silniku bazodanowym Microsoft SQL Server. Wraz ze wzrostem ilości przetwarzanych dokumentów handlowych, magazynowych czy księgowych, rozmiar bazy systematycznie rośnie. Brak odpowiedniej konfiguracji planów konserwacji (obszar administracyjny znany jako maintenance plans), takich jak regularna defragmentacja indeksów czy aktualizacja statystyk, prowadzi do sytuacji, w której generowanie zestawień zajmuje kilkanaście minut zamiast kilkunastu sekund.

Innym często diagnozowanym wariantem są trudności z komunikacją sieciową. Aplikacja kliencka instalowana na stacjach roboczych wymaga stabilnego połączenia z głównym serwerem. Nawet niewielkie opóźnienia, gubienie pakietów (packet loss) w wewnętrznej sieci lokalnej (LAN) lub awarie przełączników mogą skutkować przerwaniem sesji i utratą niezapisanych danych wprowadzanych przez pracownika. W dużych środowiskach wielooddziałowych problem ten występuje również w kontekście połączeń szyfrowanych (VPN), które łączą rozproszone lokalizacje biurowe w jedną logiczną sieć prywatną z wykorzystaniem otwartej sieci internetowej.

Kolejny wariant usterki wiąże się ze środowiskiem usług terminalowych. Aby zredukować obciążenie komputerów biurowych oraz ułatwić zarządzanie aktualizacjami na poszczególnych stanowiskach, przedsiębiorstwa decydują się na uruchamianie systemu poprzez pulpit zdalny (protokół RDP). Problemy techniczne w tym obszarze obejmują niewłaściwe zarządzanie profilami użytkowników, konflikty sterowników drukarek lokalnych ze środowiskiem serwerowym oraz niewystarczające zasoby pamięci operacyjnej (RAM) alokowane dla poszczególnych sesji terminalowych. Diagnozowanie takich zjawisk wymaga wnikliwej analizy logów systemowych zarówno na poziomie głównego serwera zintegrowanego, jak i różnorodnych urządzeń końcowych.

Infrastruktura sprzętowa a stabilność systemu do zarządzania firmą

Awarie samego oprogramowania stanowią tylko część wyzwań pojawiających się podczas eksploatacji dużych systemów zarządczych. Często przyczyna niestabilności środowiska aplikacyjnego leży w przestarzałej, nieserwisowanej lub niewłaściwie dobranej infrastrukturze sprzętowej. Oprogramowanie bazodanowe pracujące dla kilkudziesięciu użytkowników jednocześnie generuje bardzo wysokie, ciągłe obciążenie operacjami odczytu i zapisu na dyskach (IOPS). Wykorzystywanie zwykłych dysków talerzowych (HDD) lub konsumenckich dysków SSD w serwerach to jeden z głównych błędów, z którymi spotykamy się przy diagnozowaniu spadków wydajności — sprzęt tej klasy nie jest przystosowany do ciągłej, intensywnej pracy systemu obsługującego wiele stanowisk jednocześnie. Właściwym rozwiązaniem są dyski klasy serwerowej połączone w macierz RAID (technologia zabezpieczająca dane przed utratą przy awarii pojedynczego nośnika), co podnosi wydajność i zapewnia ciągłość pracy nawet przy uszkodzeniu jednego dysku.

Awarie sprzętowe dotyczą też urządzeń peryferyjnych używanych w magazynie i na hali — skanerów kodów kreskowych, kolektorów danych współpracujących z systemem WMS (systemem zarządzania magazynem) czy drukarek etykiet logistycznych. Słaby zasięg sieci bezprzewodowej w hali, gdzie sygnał tłumią wysokie metalowe regały, powoduje rozłączanie terminali z systemem inwentaryzacyjnym. Diagnostyka obejmuje wtedy pomiar zasięgu sieci, optymalizację kanałów w punktach dostępowych Wi-Fi oraz ich przeniesienie w miejsce, gdzie sygnał dociera bez zakłóceń.

Błędy podczas samodzielnych prób przywracania środowiska produkcyjnego do działania

Architektura oprogramowania przeznaczonego do obsługi złożonych procesów firmowych cechuje się tak dużą ilością powiązań między obszarami księgowymi, magazynowymi, kadrowymi i analitycznymi, że próby szybkiego modyfikowania ustawień potrafią doprowadzić do paraliżu wielu oddziałów. Ryzykownym krokiem, podejmowanym najczęściej przez załogę informatyczną pod dużą presją czasu, jest bezpośrednia modyfikacja tabel konfiguracyjnych SQL z pominięciem interfejsu graficznego programu obsługującego procedury walidacji. Modyfikacje realizowane z poziomu języka skryptowego w celu zlikwidowania zdublowanego zapisu lub błędnej sygnatury dokumentu wywołują zazwyczaj naruszenie referencyjnej spójności bazy. Likwidacja powiązanych rekordów tylko w jednej tabeli prowadzi do wystąpienia logicznych braków, uniemożliwiających wygenerowanie bilansu finansowego dla wskazanego okresu księgowego.

Zauważalnym zaniechaniem w wielu firmach jest brak cyklicznego sprawdzania mechanizmów odzyskiwania sprawności z kopii bezpieczeństwa (backupów). Przechowywanie skryptów do archiwizacji i tworzenie harmonogramów zapisów na urządzenia zewnętrzne nie przekłada się automatycznie na faktyczną, praktyczną zdolność do odzyskania cyfrowych aktywów. System tworzenia kopii może poinformować o zakończeniu procedury z sukcesem, tymczasem wynikowy plik archiwum jest uszkodzony na poziomie binarnym w wyniku błędów w transferze, lub nie zawiera niezbędnego do podniesienia bazy pliku dziennika transakcyjnego (transaction log). W przypadku krytycznej awarii dysków głównych, okazuje się, że jedyna zgromadzona paczka archiwalna jest nieczytelna i nie pozwala na wznowienie zadań systemowych.

Do katalogu działań niepożądanych należy dopisać siłowe i nagłe wyłączanie pracujących serwerów, wymuszone przez zatrzymanie pracy końcówek klienckich. Przerwanie napięcia na sprzęcie serwerowym bez zachowania procedur zamykania otwartych plików skutkuje tym, że operacje transakcyjne rozpoczęte przez stacje biurowe, a nieukończone przez silnik bazy, muszą zostać wycofane poprzez procesy przywracające spójność (rollback). Sam ten proces samonaprawczy przedłuża czas oczekiwania na uruchomienie usług. Odpowiedzialnym postępowaniem informatycznym jest analiza logów aktywności bieżącej, wyodrębnienie zawieszonej sesji lub zapętlenia algorytmów (deadlock) i precyzyjne zamknięcie pojedynczego zablokowanego wątku programistycznego.

Kiedy objawy sugerują błąd aplikacji, a problem leży w innym obszarze

Podczas wsparcia systemów informatycznych występują incydenty błędnie klasyfikowane jako awaria samej głównej platformy zarządzającej działaniami rynkowymi firmy. Pracownicy powiadamiają, że interfejs bazy całkowicie przestał realizować ich polecenia lub brakuje komunikacji z wybranymi podzespołami. Tymczasem wnikliwe analizy logów konfiguracyjnych stacji roboczych bardzo często demaskują jako winnego proces aktualizacji systemu Windows, zablokowanie ruchu przez zaporę chroniącą sieć (firewall), problemy z odnawianiem wygasłych poświadczeń domenowych, bądź błąd sterownika druku zawieszający działanie zintegrowanego w pamięci podsystemu obsługi peryferiów.

Podobna skala błędnych diagnoz pojawia się przy rozwiązywaniu kłopotów z komunikacją w przypadku usług e-commerce i platform kurierskich zintegrowanych z modułem handlowym przedsiębiorstwa. W momencie zatrzymania importu zamówień pochodzących ze sklepów B2B lub zewnętrznych placówek handlowych, odpowiedzialności zazwyczaj poszukuje się w rdzeniu oprogramowania Comarch. Jednak proces diagnostyczny nierzadko wykazuje zablokowanie wymiany cyfrowej na poziomie interfejsów programistycznych (API) przez podwykonawców zewnętrznych, zmianę protokołów uwierzytelniających serwery zdalne, albo błąd certyfikatu szyfrującego ruch sieciowy na sprzęcie pośredniczącym (routerach brzegowych). Aplikacja z obszaru ERP działa zatem poprawnie, lecz odbiera odrzucone z zewnątrz pakiety sieciowe, wywołując spadek sprawności łańcucha logistycznego.

Zauważalne spowolnienie pojedynczego stanowiska księgowego czy analitycznego przy analizie obszernych statystyk rocznych może wcale nie wynikać ze stanu bazy danych, lecz z przegrzewania się komputera. Wyschnięta pasta termoprzewodząca lub zapchane kurzem wentylatory podnoszą temperaturę procesora, przez co procesor automatycznie obniża swoją wydajność, by się nie przegrzać (throttling), a czas wyświetlania zestawień wyraźnie rośnie. W takim przypadku żadna optymalizacja bazy danych nie pomoże — potrzebne jest czyszczenie komputera i wymiana pasty lub chłodzenia.

Analiza wydajności na poziomie serwerowym i sieciowym

Diagnostyka wydajności obejmuje monitorowanie obciążenia procesora i pamięci serwera oraz wyszukiwanie wąskich gardeł w sieci, czyli miejsc, które ograniczają przepustowość całego połączenia. Ponieważ pracujemy wyłącznie w modelu dojazdu do klienta, pomiary wykonują technicy na miejscu, przy normalnym obciążeniu systemu wynikającym z bieżącej pracy biura — dzięki temu wyniki odzwierciedlają rzeczywiste warunki, a nie sztuczny test.

Sprawdzana jest też konfiguracja oprogramowania antywirusowego. Antywirusy monitorują każdą operację zapisu i odczytu plików, a jeśli katalogi systemu ERP nie są dodane do wyjątków, każde zapytanie do bazy jest dodatkowo skanowane, co wyraźnie wydłuża czas odpowiedzi. Dodanie właściwych wyjątków skraca ten czas bez obniżania poziomu ochrony komputera.

Weryfikowany jest również zasilacz awaryjny (UPS), który chroni serwer przed nagłą utratą zasilania w trakcie zapisu danych — nagłe wyłączenie prądu w takim momencie może uszkodzić bazę danych. UPS wymaga okresowego sprawdzenia, czy nadal utrzymuje napięcie pod pełnym obciążeniem i czy poprawnie uruchamia bezpieczne zamknięcie serwera, zanim jego akumulator się wyczerpie.

Dodatkowe pytania od użytkowników środowisk wielostanowiskowych

Czy weryfikacja obciążenia bazy danych zmusza nas do zatrzymania pracy we wszystkich podległych działach?

Weryfikacja parametrów pracy odbywa się pod rutynowym obciążeniem systemu. Do uzyskania właściwych wskaźników statystycznych o usterkach wymagane jest, aby komputery biurowe przetwarzały rzeczywiste operacje biznesowe, a zapytania obciążały struktury nośników pamięci oraz przepustowość sieci w typowy dla danej firmy sposób. Czytanie samych liczników wydajności systemów bazodanowych nie spowalnia ani nie wstrzymuje działań w programie. Konieczność planowanego zatrzymania pracy wszystkich aplikacji pojawia się dopiero przy wdrażaniu obszernych poprawek kodowych na serwerach, które to modyfikacje planujemy po zakończeniu zmian roboczych i zwolnieniu zasobów, aby uniknąć paraliżu komunikacyjnego stanowisk pracowniczych.

Jak zachowujecie integralność zebranych danych firmy przy realizacji prac konfiguracyjnych w kodzie programu?

Żadne fundamentalne zadanie techniczne, polegające na przetasowaniu uprawnień sieciowych, konfigurowaniu ról i powiązań pomiędzy użytkownikami systemu czy wymianie wersji silnika bazy na nowszą generację, nie przebiega bez bezwarunkowej realizacji całościowej, przetestowanej kopii zawartości logicznej systemu. Gdy pojemność techniczna na to pozwala, tworzymy w siedzibie środowiska podmiotu odizolowaną, specjalistyczną sieć testową, będącą kompletną kalką środowiska sprzętowego używanego w działaniach roboczych, w celu przetestowania spójności modyfikacji bez wywoływania perturbacji na strukturze produkcyjnej oprogramowania.

Czy usuwacie przyczynę awarii urządzeń peryferyjnych związanych z programem sprzedażowym?

Tak. Typowe problemy to przerywana łączność na kablach sieciowych, kłopoty z drukiem zdalnym, uszkodzone płytki w drukarkach igłowych na halach oraz problemy z kolektorami danych po podłączeniu nowych skanerów 2D. Sprawdzamy sygnał, poprawność portów oraz konfigurację sieci. Naprawy i wdrożenia infrastruktury wykonujemy wyłącznie dojeżdżając do klienta, bez przewożenia sprzętu do zewnętrznych punktów serwisowych.

Ile wynosi czas dojazdu w przypadku unieruchomienia systemu zarządzania danymi w firmie?

Brak dostępu do danych na wielu stanowiskach jednocześnie traktujemy jako zgłoszenie priorytetowe. Dojeżdżamy na miejsce na terenie Warszawy i gmin podwarszawskich z reguły do 1 godziny od zgłoszenia i wstępnego wywiadu technicznego. Diagnoza logów i przyczyn awarii odbywa się na miejscu, przy sprzęcie źródłowym, a czas naprawy zależy od charakteru usterki. Zgłoszenia przyjmujemy pod numerem 22 378 48 09, całodobowo, 7 dni w tygodniu.

Spójność środowiska IT jako podstawa działania dużego przedsiębiorstwa

Rozwiązywanie problemów w środowisku obsługującym wiele stanowisk wymaga innego podejścia niż naprawa pojedynczego komputera — konieczna jest znajomość struktury bazy danych, powiązań między stanowiskami w sieci oraz konfiguracji sieciowej. Poprawne odczytanie logów błędów, w połączeniu ze znajomością warstwy sieciowej, pozwala zapobiegać przestojom i utracie spójności danych przy kolejnych aktualizacjach czy wymianach sprzętu. Wszystkie te prace wykonujemy na miejscu, dojeżdżając bezpośrednio do siedziby firmy.

22 378 48 09