Po zakończeniu wdrożenia ERP wiele firm wpada w ten sam schemat: projekt został dowieziony, system działa, ale miesięczne koszty infrastruktury zaczynają rosnąć szybciej niż wartość biznesowa. Najczęściej nie wynika to z jednego błędu, tylko z kilku decyzji podjętych „na zapas” w fazie uruchomienia. Zasoby są przewymiarowane, priorytety SLA nie są rozpisane na konkretne procesy, a polityka backupu i odtworzenia istnieje bardziej na papierze niż w praktyce operacyjnej. Dla liderów IT i właścicieli ERP w firmach SMB oraz mid-market to moment, w którym trzeba przejść z myślenia projektowego na model utrzymaniowy: przewidywalny koszt, jasna odpowiedzialność i kontrolowane ryzyko.
Najważniejsza zasada jest prosta: nie optymalizujemy „serwerów”, tylko ciągłość procesów biznesowych. Jeżeli celem jest obniżenie kosztów bez pogorszenia SLA, trzeba najpierw ustalić, które obszary ERP naprawdę muszą działać bez przerwy, a które mogą mieć krótkie okno niedostępności. Bez tego każda redukcja zasobów będzie loterią, a każda awaria zamieni się w kosztowny kryzys. Dlatego pierwszy etap to decyzje biznesowe zapisane językiem IT: SLA, RTO i RPO dla kluczowych procesów.
Od czego zacząć w praktyce.
Warto rozpisać procesy ERP na trzy grupy: krytyczne operacyjnie, ważne biznesowo i wspierające. Dla każdej grupy należy określić akceptowalny czas niedostępności oraz dopuszczalną utratę danych. Dopiero wtedy można sensownie dobrać parametry środowiska, harmonogramy backupu i kolejność odtwarzania. W wielu organizacjach już ten krok pokazuje, że część komponentów utrzymywano na poziomie „krytycznym”, mimo że biznes nie wymagał tak wysokiej dostępności. To pierwszy obszar realnych oszczędności.
Kolejny etap to weryfikacja dopasowania zasobów po okresie stabilizacji. Wdrożenie ERP zwykle zakłada margines bezpieczeństwa na migrację danych, testy i nieprzewidziane obciążenia. Po kilku miesiącach utrzymania profil pracy systemu jest już znany, więc można oddzielić zasoby potrzebne stale od tych, które były potrzebne tylko czasowo. Dobrą praktyką jest analiza obciążenia w cyklu miesięcznym i kwartalnym, z uwzględnieniem zamknięć okresów, sezonowości sprzedaży i działań księgowych. Celem nie jest maksymalne „odchudzenie” środowiska, ale usunięcie trwałego nadmiaru przy zachowaniu rezerwy na przewidywalne piki.
Backup i odtworzenie to obszar, który najczęściej generuje ukryte koszty. Firmy płacą za kopie, ale nie mają pewności, czy odtworzenie zadziała w wymaganym czasie. W modelu utrzymaniowym polityka backupu powinna odpowiadać na cztery pytania: co backupujemy, jak często, jak długo przechowujemy dane i kto odpowiada za test odtworzenia. Dla środowisk ERP-CRM często kluczowe jest połączenie regularnych harmonogramów z cyklicznym testem przywracania, bo dopiero test potwierdza realną gotowość operacyjną. Bez testów RTO i RPO pozostają deklaracją.
W praktyce firm SMB i mid-market dobrze sprawdza się podejście, w którym polityka kopii jest różnicowana według krytyczności modułów ERP. Nie każdy element wymaga identycznej retencji i identycznej częstotliwości. Tam, gdzie potrzebna jest większa kontrola utrzymaniowa dla aplikacji biznesowych i baz danych, można rozważyć środowisko klasy G3 Pro, które jest profilowane pod Business Apps, Database i Workspace, z backupem i retencją 30 dni oraz self-service restore. Taki dobór ma sens wtedy, gdy wynika z wymagań procesowych, a nie z samej chęci „podniesienia” parametrów.
Model kosztowy utrzymania powinien być jawny i cyklicznie przeglądany. Najlepiej podzielić koszty na stałe i zmienne. Koszty stałe to baza niezbędna do utrzymania uzgodnionego SLA. Koszty zmienne to elementy zależne od sezonowości, dodatkowych projektów i okresowych wzrostów obciążenia. Jeżeli organizacja nie rozdziela tych dwóch kategorii, każda faktura wygląda jak „wzrost kosztów”, choć część wydatków może być uzasadniona biznesowo. Przejrzysty model kosztowy pozwala też szybciej podejmować decyzje o skalowaniu i uniknąć nerwowych zmian w momentach szczytowych.
Plan ciągłości działania i DR dla ERP nie musi być rozbudowanym dokumentem na kilkadziesiąt stron. Powinien być przede wszystkim użyteczny operacyjnie. Minimum to lista scenariuszy awarii, kolejność odtwarzania usług, role decyzyjne oraz sposób komunikacji z biznesem. Warto też z góry ustalić, które procesy uruchamiamy najpierw po incydencie i jakie są kryteria powrotu do pełnej pracy. Taki plan ogranicza chaos, skraca czas reakcji i zmniejsza koszt przestoju, który zwykle jest wielokrotnie wyższy niż koszt samej infrastruktury.
Dla zespołów odpowiedzialnych za ERP dobrym rytmem jest kwartalny przegląd utrzymania oparty na jednej checkliście decyzyjnej. Taki przegląd powinien obejmować: aktualność SLA/RTO/RPO, dopasowanie zasobów do realnego obciążenia, skuteczność backupu i testów odtworzeniowych, strukturę kosztów stałych i zmiennych oraz gotowość planu DR. Dzięki temu optymalizacja nie jest jednorazową akcją „cięcia”, tylko stałym procesem poprawy efektywności.
Największy błąd na etapie przejścia z wdrożenia do utrzymania to odkładanie decyzji na później. Im dłużej środowisko działa bez uporządkowanych zasad, tym trudniej i drożej je później korygować. Dlatego warto wykonać krótki, ale konkretny przegląd: 60 minut z właścicielami procesów i zespołem IT często wystarcza, aby wskazać obszary nadmiaru, luki w odtwarzaniu i szybkie działania o wysokim wpływie na koszt całkowity.
Jeżeli chcesz obniżyć koszt infrastruktury ERP bez ryzyka dla ciągłości działania, zacznij od checklisty i zamień ją w plan na najbliższy kwartał. Pobierz checklistę i przeprowadź 60-minutowy przegląd środowiska ERP pod kątem kosztów, SLA oraz gotowości do odtworzenia po awarii.