Serwer lokalny czy chmura – gdzie najlepiej uruchomić system ERP?

Wybór między serwerem lokalnym a chmurą dla systemu ERP wpływa nie tylko na koszty IT, ale również na szybkość obsługi zamówień, dostępność danych i możliwość pracy podczas awarii. Firma produkcyjna, której system zarządza magazynem i zleceniami na hali, ma inne wymagania niż sieć handlowa z kilkunastoma oddziałami. Nie istnieje jeden najlepszy model infrastruktury. Istnieje natomiast zestaw parametrów, które pozwalają podjąć decyzję bez przepłacania za sprzęt lub usługi, których przedsiębiorstwo nie wykorzysta.

Serwer lokalny – większa kontrola, ale również odpowiedzialność za infrastrukturę

ERP na serwerze lokalnym (on-premise) oznacza, że aplikacja i baza danych działają na sprzęcie należącym do przedsiębiorstwa, najczęściej w jego siedzibie lub własnej serwerowni. Firma samodzielnie odpowiada za wydajność, aktualizacje systemu operacyjnego, kopie zapasowe, zabezpieczenia i usuwanie awarii. Może zlecić te czynności zewnętrznemu administratorowi, ale odpowiedzialność organizacyjna pozostaje po jej stronie.

Największą zaletą takiego rozwiązania jest kontrola nad konfiguracją i lokalnym dostępem do danych. Ma to znaczenie szczególnie w zakładach produkcyjnych, w których ERP współpracuje z terminalami magazynowymi, czytnikami kodów kreskowych, wagami przemysłowymi albo systemami MES. Jeżeli aplikacja i urządzenia komunikują się przez sieć lokalną, nie muszą przesyłać każdej operacji przez internet.

Przykładowo zakład produkcyjny zatrudniający 80 osób może obsługiwać 25 jednoczesnych użytkowników ERP, rejestrujących przyjęcia materiałów, zużycie surowców i realizację zleceń. Umieszczenie serwera w tej samej sieci co stanowiska produkcyjne ogranicza zależność tych operacji od zewnętrznego łącza. Nie oznacza jednak pełnej niezależności od internetu. Integracje z bankowością, usługami kurierskimi czy Krajowym Systemem e-Faktur (KSeF) nadal wymagają komunikacji z usługami zewnętrznymi.

Koszt własnej infrastruktury trzeba liczyć szerzej niż cenę komputera serwerowego. Orientacyjny budżet dla małego lub średniego wdrożenia może wyglądać następująco:

• Serwer biznesowy: około 12–30 tys. zł netto za konfigurację z procesorem serwerowym, 64–128 GB RAM i dyskami SSD klasy enterprise.
• Zasilacz UPS i urządzenia sieciowe: około 2–7 tys. zł netto, zależnie od wymaganej autonomii zasilania.
• System kopii zapasowych: około 3–12 tys. zł netto na dodatkowy NAS, nośniki lub początkową konfigurację; osobno należy uwzględnić kopię poza siedzibą.
• Administracja i utrzymanie: orientacyjnie 500–2500 zł netto miesięcznie przy obsłudze zewnętrznej, zależnie od zakresu prac i gwarantowanego czasu reakcji.

Są to przedziały budżetowe dla przykładowej infrastruktury, a nie cennik konkretnego dostawcy. Nie obejmują licencji ERP, baz danych, wszystkich licencji systemowych ani rozbudowanej redundancji.

Przy początkowym nakładzie 30 tys. zł netto i pięcioletnim okresie użytkowania sam zakup sprzętu odpowiada kosztowi 500 zł miesięcznie. Do tego dochodzą energia, serwis, licencje i administracja. Pozornie tani serwer może więc po pięciu latach kosztować więcej niż odpowiednio dobrana usługa chmurowa.

Najbardziej niedocenianym problemem jest pojedynczy punkt awarii. Dwa dyski pracujące w RAID 1 chronią przed awarią jednego nośnika, ale nie przed zaszyfrowaniem danych przez ransomware, przypadkowym usunięciem dokumentów czy pożarem serwerowni. RAID nie zastępuje backupu. Konieczna jest niezależna kopia, najlepiej również poza główną lokalizacją, oraz regularny test odtworzenia bazy ERP.

Kiedy serwer lokalny ma sens? Gdy firma ma stabilną liczbę użytkowników, własne kompetencje administracyjne, wymagające integracje z urządzeniami na miejscu i infrastrukturę zapewniającą ciągłość działania. Jest mniej atrakcyjny, gdy przedsiębiorstwo nie dysponuje serwerownią, nie ma administratora lub szybko otwiera kolejne oddziały. Wtedy utrzymywanie własnego sprzętu staje się dodatkowym projektem organizacyjnym, zamiast wyłącznie sposobem uruchomienia ERP.

ERP w chmurze – elastyczne zasoby nie oznaczają automatycznie niższych kosztów

System ERP w chmurze może działać w dwóch zasadniczo różnych modelach. Pierwszy to SaaS (Software as a Service), w którym dostawca udostępnia gotową aplikację, zwykle w abonamencie. Drugi to IaaS (Infrastructure as a Service), czyli wynajmowanie serwerów wirtualnych, pamięci masowej i infrastruktury sieciowej, na których firma lub jej partner samodzielnie instaluje i utrzymuje ERP.

Różnica ma konsekwencje finansowe i techniczne. W modelu SaaS aktualizacje infrastruktury i aplikacji są przeważnie częścią usługi, zgodnie z umową. W IaaS, np. na platformie Microsoft Azure lub Amazon Web Services, za konfigurację maszyny wirtualnej, system operacyjny, często bazę danych, monitoring i kopie zapasowe nadal odpowiada klient lub jego administrator.

Chmura jest szczególnie użyteczna w przedsiębiorstwach działających w wielu lokalizacjach. Wyobraźmy sobie dystrybutora części samochodowych z centralą w Poznaniu, magazynem we Wrocławiu i dziesięcioma przedstawicielami handlowymi. Wspólny ERP udostępniany przez internet pozwala pracownikom korzystać z jednej bazy stanów magazynowych, zamówień i rozrachunków bez utrzymywania serwera w każdym oddziale.

Korzyść wynika jednak z centralizacji danych, a nie z samego faktu używania chmury. Podobny efekt można osiągnąć na serwerze lokalnym przez bezpieczny dostęp zdalny. Chmura zwykle ułatwia natomiast skalowanie infrastruktury i organizację dostępu dla rozproszonych zespołów.

Ile kosztuje ERP w chmurze? Nie ma jednej stawki, ponieważ koszt zależy od architektury oraz sposobu licencjonowania aplikacji. Do wstępnego porównania można przyjąć następujące orientacyjne budżety:

• Prosta maszyna wirtualna dla niewielkiego środowiska testowego: około 150–500 zł netto miesięcznie, bez pełnego środowiska produkcyjnego ERP.
• Środowisko produkcyjne dla mniejszej firmy: orientacyjnie 800–3000 zł netto miesięcznie za podstawowe zasoby obliczeniowe, dyski i wybrane usługi infrastrukturalne.
• Rozbudowane środowisko z odseparowaną bazą danych, redundancją i dodatkowymi zabezpieczeniami: od kilku tysięcy złotych miesięcznie, a w większych organizacjach znacznie więcej.

Te kwoty służą wyłącznie do oszacowania rzędu wielkości wydatków. Licencje Microsoft SQL Server, Windows Server, usługi administratora, ruch sieciowy i rozwiązania wysokiej dostępności mogą istotnie zwiększyć rachunek. Dlatego porównywanie ceny pojedynczej maszyny wirtualnej z całkowitym kosztem własnego serwera jest błędem.

Załóżmy, że środowisko chmurowe kosztuje 1800 zł netto miesięcznie. Przez pięć lat firma wyda 108 tys. zł netto, przy niezmienionej stawce i konfiguracji. Własna infrastruktura za 30 tys. zł może wyglądać korzystniej, dopóki nie doliczymy administracji, backupu, licencji, ewentualnej wymiany sprzętu i kosztów przestojów.

W chmurze trzeba również pilnować wydajności bazy danych. ERP wykonuje wiele niewielkich operacji odczytu i zapisu, dlatego opóźnienia dyskowe, liczba IOPS i wydajność pojedynczego rdzenia CPU mogą być ważniejsze niż deklarowana całkowita moc serwera. Zbyt mała maszyna wirtualna potrafi powodować kilkusekundowe oczekiwanie na zapis dokumentu magazynowego, mimo że dostawca gwarantuje wysoką dostępność infrastruktury.

Drugim ograniczeniem jest internet. Jeżeli pracownicy korzystają z ERP przez przeglądarkę lub pulpit zdalny, awaria podstawowego łącza może wstrzymać pracę. W magazynie wysyłającym kilkaset paczek dziennie oznacza to realne opóźnienia. Rozsądnym zabezpieczeniem jest drugie łącze od niezależnego operatora, najlepiej wykorzystujące inną technologię dostępową. Sam router z dwoma portami WAN nie pomoże, jeżeli oba połączenia korzystają z tej samej uszkodzonej infrastruktury operatora.

Chmura ma przewagę, gdy użytkownicy pracują w różnych lokalizacjach, zapotrzebowanie na zasoby się zmienia, a przedsiębiorstwo chce ograniczyć zakup własnego sprzętu. Nie jest oczywistym zwycięzcą w firmach z intensywną komunikacją ERP z lokalnymi urządzeniami, bardzo słabą łącznością lub wymaganiami dotyczącymi niestandardowej konfiguracji, której dostawca SaaS nie udostępnia.

Jak wybrać środowisko ERP i nie popełnić kosztownego błędu?

Najlepszą metodą jest porównanie całkowitego kosztu posiadania (TCO) i przetestowanie kilku rzeczywistych procesów biznesowych. Decyzji nie należy rozpoczynać od pytania, który serwer ma więcej RAM. Najpierw trzeba ustalić, co stanie się z firmą, gdy ERP będzie niedostępny przez dwie godziny.

Dla hurtowni może to oznaczać brak możliwości kompletowania zamówień i drukowania dokumentów WZ. Dla biura usługowego – przede wszystkim opóźnienie pracy księgowości. Infrastruktura o takim samym poziomie niezawodności nie musi być ekonomicznie uzasadniona w obu przypadkach.

Podczas analizy należy sprawdzić pięć parametrów:

1. Liczbę jednoczesnych użytkowników, nie tylko całkowitą liczbę wykupionych licencji. Pięćdziesięciu zatrudnionych nie oznacza pięćdziesięciu aktywnych sesji ERP.
2. Wielkość i przyrost bazy danych. Baza zajmująca obecnie 100 GB, powiększająca się o 5 GB miesięcznie, osiągnie około 400 GB po pięciu latach, bez uwzględnienia dodatkowych zmian.
3. Wymagania integracyjne. Trzeba zweryfikować współpracę z KSeF, WMS, platformami e-commerce, terminalami, wagami i zewnętrznymi API.
4. Dopuszczalny czas przestoju (RTO) oraz maksymalną akceptowaną utratę danych (RPO). RTO wynoszące 4 godziny oznacza cel przywrócenia działania w tym czasie, natomiast RPO równe 15 minut oznacza projektowanie ochrony danych tak, by utrata nie przekroczyła kwadransa.
5. Koszt użytkowania przez 36–60 miesięcy, obejmujący sprzęt lub abonament, licencje, administrację, backup, rozbudowę, aktualizacje i procedurę wyjścia od dostawcy.

Szczególną uwagę należy poświęcić RPO. Jeżeli kopia bazy powstaje raz na dobę, utrata danych od ostatniego backupu może objąć niemal 24 godziny pracy. Deklarowanie RPO na poziomie 15 minut bez odpowiedniej częstotliwości zabezpieczania logów transakcyjnych, replikacji lub innej właściwej technologii nie ma technicznego uzasadnienia.

Nie można też automatycznie przyjmować, że serwer w Polsce zapewnia zgodność z RODO, a chmura zagraniczna jej nie zapewnia. Znaczenie mają umowa powierzenia przetwarzania danych, rzeczywiste lokalizacje przetwarzania, podwykonawcy, uprawnienia administratorów, mechanizmy zabezpieczeń i ewentualne transfery poza Europejski Obszar Gospodarczy. W przypadku dostawcy chmurowego trzeba osobno sprawdzić, gdzie znajdują się kopie zapasowe oraz z jakich państw może być realizowane wsparcie techniczne.

Trzecim wariantem jest infrastruktura hybrydowa. Zakład produkcyjny może utrzymywać część systemów obsługujących maszyny lokalnie, a centralny ERP, analitykę i wybrane integracje uruchamiać w chmurze. Taka architektura pozwala ograniczyć skutki awarii internetu dla procesów lokalnych, ale wymaga zaprojektowania synchronizacji. Jeżeli dwie bazy przyjmują zmiany niezależnie, trzeba ustalić, co dzieje się przy konflikcie zapisów i która baza jest nadrzędnym źródłem danych.

Przed wyborem architektury należy też sprawdzić warunki licencji producenta ERP. Nie każdy system dopuszcza identyczny sposób instalacji w środowisku lokalnym i chmurowym. Niektóre starsze rozwiązania wymagają określonych wersji SQL Server, dostępu do lokalnych zasobów lub licencjonowania zależnego od infrastruktury. Przeniesienie maszyny wirtualnej bez sprawdzenia tych warunków może skończyć się dodatkowymi opłatami i problemami ze wsparciem producenta.

Dobrym testem jest dwutygodniowy pilotaż obejmujący rzeczywistą kopię bazy, wybrane integracje i najbardziej obciążające operacje: generowanie raportów, import zamówień, zamykanie okresu księgowego oraz równoczesną pracę użytkowników. Pomiar czasu wykonania tych operacji daje więcej niż sama specyfikacja procesora. Dane produkcyjne używane podczas testu muszą być odpowiednio chronione, a w razie potrzeby zanonimizowane.

Od czego zacząć? Najpierw zmierz obciążenie obecnego ERP i określ maksymalny dopuszczalny przestój. Następnie poproś o dwie wyceny na identyczne wymagania: serwer lokalny z backupem i serwisem oraz środowisko chmurowe z równoważnym RTO, RPO i wsparciem. Dopiero porównanie takich ofert pokaże, które rozwiązanie jest rzeczywiście tańsze i mniej ryzykowne. Więcej informacji na: https://acomit.pl.

FAQ – najczęstsze pytania o serwer lokalny i ERP w chmurze

Czy ERP w chmurze jest bezpieczniejszy niż na własnym serwerze?
Nie automatycznie. Profesjonalna infrastruktura chmurowa oferuje zaawansowane mechanizmy ochrony, ale klient nadal musi prawidłowo zarządzać dostępami, konfiguracją i ochroną danych. Własny serwer również może być bezpieczny, jeśli jest regularnie aktualizowany, monitorowany i zabezpieczony kopiami zapasowymi.

Ile internetu potrzeba do obsługi ERP w chmurze?
Dla kilkunastu użytkowników korzystających z lekkiego interfejsu ERP łącze symetryczne 50–100 Mb/s często stanowi rozsądny punkt wyjścia. Przy pulpitach zdalnych, dużych załącznikach i intensywnej transmisji wymagania rosną. Ważniejsze od samej przepustowości bywają stabilność połączenia, opóźnienia i utrata pakietów.

Czy można przenieść istniejący ERP z serwera lokalnego do chmury?
Tak, jeśli producent wspiera docelowe środowisko. Przed migracją należy zweryfikować zgodność wersji systemu i bazy danych, licencje, integracje oraz czas przeniesienia. Konieczny jest także plan powrotu do poprzedniego środowiska, jeśli uruchomienie produkcyjne się nie powiedzie.

Czy chmura wymaga wykonywania własnych kopii zapasowych?
To zależy od modelu usługi i umowy. W IaaS zazwyczaj trzeba samodzielnie skonfigurować odpowiednią ochronę danych. W SaaS dostawca może realizować backup, ale należy sprawdzić częstotliwość kopii, okres retencji, możliwość odtworzenia pojedynczych danych oraz gwarantowane czasy przywrócenia.

Kiedy rozwiązanie hybrydowe jest lepsze od obu pozostałych?
Gdy przedsiębiorstwo potrzebuje lokalnej obsługi krytycznych urządzeń produkcyjnych, ale jednocześnie centralnego dostępu do ERP dla wielu oddziałów. Nie warto jednak budować hybrydy bez uzasadnienia operacyjnego, ponieważ synchronizacja, monitoring i utrzymanie dwóch środowisk zwiększają złożoność oraz koszty.