„ERP zwolnił, chyba trzeba go wymienić" — to jedno z najdroższych zdań, jakie da się powiedzieć na spotkaniu zarządu MŚP. W 8 na 10 przypadków, które widzieliśmy w ostatnich latach, prawdziwa przyczyna była do znalezienia w ciągu jednego popołudnia i do naprawienia w tydzień. Bez wymiany, bez migracji, bez dwuletniego projektu.
To nie znaczy, że ERP nigdy nie „starzeje się" naprawdę. Znaczy, że zanim pójdziesz ścieżką za 300–800 tysięcy złotych, warto najpierw wykluczyć rzeczy, które kosztują dziesiątą część tego i można je zrobić w weekend. Ten tekst jest o tym, jak wygląda taka diagnostyka w realiach Comarch Optima, enova365, Subiekta i podobnych systemów, które w polskich MŚP działają zwykle na Microsoft SQL Serverze.
Najpierw fakty, nie wrażenia
Pierwsza rzecz, która zaskakuje właścicieli, to jak subiektywna jest ocena „ERP działa wolno". Ktoś mówi: „w piątek po południu wszystko stoi". Inny: „od dwóch miesięcy jest gorzej". Trzeci: „wystawienie faktury trwa wieczność". Trzy różne problemy, trzy różne przyczyny, jedno wspólne zdanie w mailu do zarządu.
Zanim ktokolwiek zacznie zaglądać do bazy, warto zebrać konkrety:
- Które operacje są wolne — otwarcie kartoteki klienta, generowanie faktury, raport sprzedaży za miesiąc, zamknięcie okresu? To zupełnie różne rzeczy technicznie.
- Kiedy zwalnia — cały dzień, tylko rano przy „odpalaniu", tylko przy dużym raporcie na koniec miesiąca, tylko dla wybranych użytkowników?
- Jak długo już tak jest — od jednego update'u, od poszerzenia zespołu o 3 osoby, od momentu, gdy baza przeszła 10 GB, od kiedy przyszedł nowy dostawca internetu?
- Ile trwa konkretnie — z zegarkiem w ręku. „Wolno" to nie liczba. „18 sekund" to liczba.
To brzmi jak biurokracja, ale bez tych czterech odpowiedzi każda dalsza diagnostyka będzie zgadywaniem, a każdy dostawca oprogramowania z chęcią sprzeda coś, czego może nie potrzebujesz.
Realny przykład z terenu
Konkret, żeby to nie było w powietrzu. U jednego z naszych klientów — 12-osobowe biuro rachunkowe pracujące na Comarch Optima od 5 lat — otwarcie kartoteki VAT trwało po nowym roku około 40 sekund. Do tego okresowe „zamrożenia" po kilkanaście sekund w środku dnia, dokładnie wtedy, gdy dwie osoby jednocześnie zapisywały fakturę.
Diagnoza zajęła pół dnia i wyglądała tak: baza SQL Server rosła nieprzerwanie od 5 lat, tabele VatZakup i VatSprzedaz miały łącznie ponad 8 milionów wierszy, indeksy były sfragmentowane w 92%, a Auto Update Statistics ktoś kiedyś wyłączył „bo zwalniało pod koniec miesiąca". Do tego serwer miał 16 GB RAM na maszynie, która obsługiwała ERP, plik wymiany na tym samym HDD co baza i dziesięć włączonych zaplanowanych zadań, z których cztery robiły to samo.
Naprawa: rebuild indeksów w oknie serwisowym (2 godziny), włączenie Auto Update Statistics z sensownym harmonogramem, przeniesienie pliku wymiany na osobny dysk, wyczyszczenie duplikatów w zadaniach. Koszt zewnętrzny: jeden dzień pracy. Efekt: otwarcie kartoteki VAT z 40 sekund do 3 sekund, „zamrożenia" zniknęły. Wymiana ERP, o której rozmawiano na trzech ostatnich zarządach, została odłożona na czas nieokreślony.
To nie jest ekstremalny przypadek. To jest przypadek typowy.
Cztery warstwy, w których szukamy przyczyny
Kiedy już wiesz, co konkretnie zwalnia, przechodzimy przez cztery warstwy — od najtańszej diagnostyki do najdroższej. W tej kolejności, bo statystycznie tak wygląda rozkład prawdopodobieństwa.
Warstwa 1 — baza danych. To tu leży 60–70% problemów, które widujemy. Fragmentacja indeksów, przestarzałe statystyki, brakujące indeksy na kolumnach używanych w raportach, tabele „śmieciowe" po wyłączonych modułach, log transakcyjny puchnący do 40 GB. Wszystko diagnozowalne w kilku zapytaniach do sys.dm_db_index_physical_stats i sys.dm_exec_query_stats. Wszystko naprawialne bez ingerencji w sam ERP.
Warstwa 2 — serwer i infrastruktura. RAM przydzielony SQL Serverowi (default 2 GB dla Express to najczęstsza pułapka), typ dysku (HDD kontra SSD to różnica rzędu 20–50 razy), plik wymiany, antywirus skanujący pliki MDF/LDF w locie, kopia zapasowa robiona co godzinę w środku dnia roboczego. Diagnostyka: Task Manager, Performance Monitor, sprawdzenie konfiguracji SQL Servera. Naprawa: często sam upgrade RAM z 16 do 32 GB załatwia problem, dopisanie wyjątków w antywirusie to 15 minut.
Warstwa 3 — sieć i klienci. Jeśli ERP jest hostowany na serwerze w biurze, a użytkownicy łączą się przez Wi-Fi, którego access point ma 6 lat, to problem nie jest w ERP. Sprawdź RDP zamiast pełnego klienta, przejrzyj konfigurację VPN, sprawdź, czy między serwerem a stacją nie ma jednego przeciążonego switcha. Osobny wątek: użytkownicy pracujący zdalnie na słabym łączu na plikach wsadowych — jeden import na 5000 pozycji potrafi zawiesić serwer, jeśli sieć klienta jest wąskim gardłem.
Warstwa 4 — sam ERP i jego konfiguracja. Dopiero teraz, kiedy trzy pierwsze warstwy są wykluczone, zaglądamy do konfiguracji ERP: włączone moduły, których nikt nie używa (ale liczą się do każdego zapytania), własne modyfikacje w Optimie (SDK, dodatki), źle zaprojektowane wydruki generujące zapytania po kilkaset tysięcy razy, cache raportów zajmujący 20 GB. Naprawa tu jest droższa i wymaga często dostawcy, ale przynajmniej wiesz, że rozmawiasz o rzeczywistej przyczynie.
Kiedy jednak wymiana ma sens
Wymiana ERP jest uzasadniona wtedy, gdy diagnostyka przez cztery warstwy pokazuje coś jednego z trzech: dostawca przestał wspierać wersję, której używasz i nie da się jej już aktualizować; system nie obsługuje procesu, który dziś jest krytyczny dla biznesu (np. dodałeś sprzedaż online, a ERP nie ma sensownej integracji z e-commerce); albo skala danych i użytkowników po prostu wyszła poza architekturę systemu — typowe dla firm, które z 15 osób urosły do 60 i wciąż siedzą na wersji „małego biura".
Wszystkie trzy powody są realne. Ale są też stosunkowo rzadkie. Znacznie częściej pod „ERP zwolnił" kryje się jedno z tych, o których pisaliśmy wyżej. Warto to sprawdzić, zanim zarząd podpisze umowę na dwuletni projekt migracyjny.
Co zrobić w tym tygodniu
Nie musisz od razu zamawiać audytu. Cztery rzeczy, które możesz zrobić samodzielnie lub z własnym informatykiem w ciągu tygodnia:
- Zbierz konkretne pomiary od zespołu — które operacje, kiedy, jak długo. Bez tego nie ruszaj dalej.
- Sprawdź rozmiar bazy, wersję SQL Servera i ile RAM ma przydzielone. Jeśli to SQL Server Express z 2 GB RAM przy bazie 30 GB — to jest ta warstwa 2.
- Zajrzyj do zaplanowanych zadań SQL Servera. Jeśli od 5 lat nikt nie robi rebuild indeksów i update statistics — to jest ta warstwa 1.
- Zapytaj dostawcę ERP wprost: „jaka jest aktualnie zalecana konfiguracja bazy i serwera dla naszej wielkości?". Sam mail często wystarcza, żeby dostać krótką listę „a sprawdziliście państwo…".
Jeśli po tych czterech krokach nadal nie wiesz, gdzie leży problem — to jest właśnie moment, żeby zadzwonić po kogoś z zewnątrz, ale już z konkretami, a nie z „chyba trzeba wymienić system".
Zanim wydasz 300 tysięcy na nowy ERP, warto sprawdzić, czy stary nie potrzebuje po prostu jednego dnia pracy z SQL Serverem.