W większości MŚP zmiany w ERP wprowadza się tam, gdzie się da — czyli wprost na bazie produkcyjnej, w piątek po szesnastej, „bo wtedy nikt nie pracuje". Do czasu, aż w poniedziałek rano nie da się wystawić faktury. Środowisko testowe to nudna sprawa, ale zwykle zwraca się po pierwszej uniknietej awarii.
Scenariusz, który widzimy regularnie. Firma używa Comarch Optimy, enova365 albo Subiektu od kilku lat. Po drodze dorobiła sobie dodatek pod własny obieg dokumentów, integrację z WMS-em, kawałek wymiany danych z bankiem i pół tuzina raportów w SQL-u. Wszystko działa — dopóki ktoś nie kliknie „aktualizacja" albo nie zmieni planu kont. Wtedy okazuje się, że jeden z dodatków przestał współpracować z nową wersją, a obieg faktur kosztowych po cichu przestał generować zapisy księgowe.
Środowisko testowe nie chroni przed wszystkimi tymi rzeczami. Ale wyłapuje większość z nich, zanim zablokują pracę 30 osób w poniedziałek rano.
Czym właściwie jest „środowisko testowe" w realiach MŚP
Pomińmy korpolingo. W praktyce chodzi o drugą, oddzielną instancję ERP, na której można psuć. To może być osobna instalacja Optimy na innym serwerze (albo wirtualce), kopia bazy danych z weekendu, albo nawet osobny komputer z postawionym Subiektem i przeniesioną bazą. Ważne są dwie rzeczy:
- Dane wyglądają jak prawdziwe — wystarczająco, żeby testować realne scenariusze (ten sam plan kont, te same magazyny, podobne ilości dokumentów).
- Nic, co tam zrobisz, nie trafia do prawdziwej księgowości, na prawdziwy magazyn ani do prawdziwego banku.
To nie musi być drogie. Dla większości MŚP wystarczy kopia bazy odświeżana raz na tydzień albo raz na miesiąc, postawiona na tym samym serwerze pod inną nazwą, z odciętym dostępem do produkcyjnego SMTP i do API banku. Koszt: jeden wieczór pracy administratora plus trochę miejsca na dysku.
Co konkretnie warto testować, zanim trafi na produkcję
Lista jest dłuższa, niż większość firm myśli. Najczęstsi „klienci" sandboxa to:
- Aktualizacje ERP (np. roczny upgrade Optimy do nowej wersji, łatki kwartalne enova365). Tu kryją się rozjazdy z dodatkami napisanymi pod starsze wersje.
- Zmiany w planie kont, schematach księgowych, definicjach dokumentów. Łatwo zablokować wystawianie WZ albo generowanie zapisu kosztowego jedną źle zaznaczoną opcją.
- Nowe dodatki, integracje, raporty. Każdy dodatek od zewnętrznego dostawcy trzeba zweryfikować na własnych danych — demo u dostawcy zawsze działa.
- Import dużych paczek danych (np. cennik od dostawcy, paczka 5000 produktów z hurtowni). Łatwo zaorać kartotekę towarową źle zmapowanym importem.
- Zmiany w uprawnieniach — kto co widzi, kto może zatwierdzać. Niewinna modyfikacja roli potrafi odciąć handlowcom dostęp do cennika.
- Procedury awaryjne — przywracanie z backupu, przełączenie bazy. Jeśli pierwszy raz uruchamiasz tę procedurę w trakcie prawdziwej awarii, to znaczy, że nie masz procedury.
Reguła jest prosta: jeśli zmiana dotyka czegokolwiek, co ma „księgowy" w nazwie albo wpływa na fakturowanie — testuj na sandboxie. Punkt.
Jak to zwykle kończy się bez sandboxa
U jednego z naszych klientów — 30-osobowego producenta mebli z Comarch Optimą i dedykowanym WMS — zmiany wprowadzało się tradycyjnie: w piątek po 16:00, „bo wtedy nikt nie pracuje". W ciągu pół roku zdarzyły się trzy poniedziałki, w których nie dało się wystawić faktury, bo coś się rozjechało. Każdy z nich kosztował średnio 4 godziny przestoju w fakturowaniu (księgowa szukała źródła problemu, dwie osoby z handlu czekały, klient czekał) plus nerwy. Razem: 12 godzin produktywnej pracy zmarnowanej + reputacja u kilku klientów, którzy nie dostali faktur na czas.
Po wprowadzeniu sandboxa (kopia bazy odświeżana co środę, ten sam plan kont, odcięty SMTP) zasada stała się prosta: każda zmiana najpierw na środowisku testowym, dopiero potem produkcja, i tylko w piątek między 16:00 a 17:00. Przez kolejne 12 miesięcy: zero zablokowanych poniedziałków z powodu zmian. Czas potrzebny na test jednej zmiany wzrósł średnio o 30–45 minut. Zwrot z inwestycji policzysz sobie sam.
„Oszczędności", które kosztują najwięcej
Najczęstsze argumenty przeciwko sandboxowi w MŚP — i co zwykle wychodzi w praniu:
- „Mamy backup, w razie czego wrócimy." Prawda. Tylko że przywrócenie bazy o godzinie 9:00 w poniedziałek oznacza utratę wszystkich dokumentów wystawionych od soboty rano i blokadę pracy na 1–3 godziny. Backup to ostatnia deska ratunku, nie narzędzie testowe.
- „Zmiana jest mała, nie ma co testować." Większość poważnych awarii zaczyna się od „małej zmiany". W Optimie jedno źle zaznaczone pole w definicji dokumentu potrafi spowodować, że dwa tygodnie WZ-tek nie wygenerowały zapisów kosztowych — i odkrywasz to przy zamknięciu miesiąca.
- „Dostawca przetestował u siebie." Dostawca przetestował na swoim środowisku, ze swoim planem kont i swoimi dodatkami. Twoje są inne. To, że u nich działa, nic nie gwarantuje.
- „Sandbox jest drogi." Nie jest. Najprostsza wersja to dodatkowa instancja Optimy na tym samym serwerze, kopia bazy odświeżana skryptem co tydzień, odcięte połączenia zewnętrzne. Realny koszt: kilka godzin pracy raz, plus odrobina dyscypliny.
Jak to wdrażamy w 2 tygodnie
W praktyce projekt jest prostszy, niż brzmi:
- Druga instancja systemu. Najczęściej na tym samym serwerze, pod inną nazwą bazy. W Optimie / enovie / Subiekcie to kwestia jednej instalacji i podłączenia kopii bazy.
- Odcięcie zewnętrznych integracji. Sandboxowy SMTP nie wysyła maili do prawdziwych klientów. Sandboxowe API banku nie wykonuje przelewów. Sandboxowy WMS nie rusza prawdziwym magazynem. Brzmi oczywisto — i właśnie dlatego się o tym zapomina.
- Skrypt odświeżający dane. Raz w tygodniu (zwykle w nocy z piątku na sobotę) baza testowa nadpisywana jest świeżą kopią produkcji. Dzięki temu testujesz na realnych danych, nie na muzeum sprzed pół roku.
- Krótka procedura na kartce. Trzy zdania: każda zmiana w ERP najpierw na sandboxie, dokumentowana w jednym pliku, dopiero potem produkcja. Bez tej procedury sandbox po dwóch miesiącach zarasta kurzem.
Razem: 5–10 godzin pracy administratora w pierwszym tygodniu, potem 1–2 godziny miesięcznie na utrzymanie.
Częste pułapki
- Sandbox za stary. Jeśli kopia ma pół roku, testy są bezwartościowe, bo plan kont w produkcji już dawno wygląda inaczej. Odświeżaj.
- Sandbox z prawdziwymi danymi klientów wysyłany na zewnątrz. Jeżeli dostawca prosi o „kopię bazy do analizy", pomyśl o RODO, zanim spakujesz ZIP-a. Najlepiej: zanonimizować nazwiska i NIP-y przed wysyłką.
- Sandbox bez właściciela. Jeżeli nikt nie odpowiada za to, że jest aktualny i odcięty od świata, po roku okazuje się, że ktoś podpiął go pod prawdziwy SMTP i wysłał testowe faktury do 200 klientów. Wyznacz jedną osobę.
Od czego zacząć
Najprostszy pierwszy krok to odpowiedź na pytanie: gdzie ostatnio testowaliśmy zmianę w ERP? Jeśli odpowiedź brzmi „na produkcji, w piątek po szesnastej", masz odpowiedź na to, czy sandbox jest Ci potrzebny.
Jeżeli używasz Comarch Optimy, enova365 albo Subiekta i chcesz przestać grać w ruletkę z fakturowaniem, pogadaj z kimś, kto stawiał już sandboxy pod te systemy i wie, co odciąć w pierwszej kolejności. Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Środowisko testowe to nie luksus dla korporacji. To najtańsza polisa, jaką możesz mieć na ERP — pod warunkiem, że ktoś jej naprawdę używa.