Kategoria: Automatyzacja i autonomia
„U nas wszystko jest zautomatyzowane”. Słyszę to na pierwszym spotkaniu niemal zawsze. Potem okazuje się, że księgowość ma makro w VBA, analityk ma Power Query, a logistyka odpala z palca skrypt SQL, który co rano ciągnie raport wprost z bazy produkcyjnej ERP. To nie jest automatyzacja. To dług technologiczny, który na razie jeszcze spłaca sam siebie.
W tym tekście nie ma ani jednej liczby z firmy klienta. Liczby, które podaję, pochodzą z odczytu mojego własnego środowiska: 223 przepływy w jednej instancji n8n i rozkład ich wyzwalaczy odczytałem z bazy 29 i 30 października 2026, konfigurację puli połączeń przed bazą odczytałem 3 listopada 2026. Nie zmierzyłem natomiast tego, o czym ten artykuł mówi najwięcej: nie mam pomiaru, o ile spada obciążenie bazy ERP po rozdzieleniu analityki od operacji w konkretnej firmie, bo każda firma ma inny profil zapytań. Opisuję więc architekturę i to, czego się po niej spodziewać, a nie wynik testu wydajności.
Dlaczego zapytanie wprost do bazy produkcyjnej jest ślepą uliczką
Jedno ciężkie złączenie potrafi zatrzymać magazyn
W układzie, który zastaję najczęściej, narzędzie raportowe albo skrypt uderza bezpośrednio w główną bazę systemu ERP. Na początku to działa i dlatego nikt tego nie rusza. Problem rośnie razem z firmą: analitycy piszą coraz szersze zapytania, bo coraz więcej chcą wiedzieć.
W pewnym momencie jedno ciężkie złączenie tabel, uruchomione w godzinach szczytu przez dział sprzedaży, zajmuje zasoby serwera na kilka minut. W tych kilku minutach magazyn nie wydaje towaru, a księgowość nie wystawia faktury. System operacyjny firmy dusi się pod ciężarem własnej analityki. Co ważne, nikt tego nie zgłosi jako awarii raportu, bo raport w końcu się policzył. Zgłoszenie przyjdzie z magazynu.
Druga strona tego samego problemu to liczba dróg dostępu. Kiedy każde narzędzie łączy się z bazą po swojemu, nie ma jednego miejsca, w którym można ustawić limit, nadać uprawnienia albo zobaczyć, kto właściwie pyta. U siebie rozwiązałem to jedną wspólną drogą, którą opisałem osobno, pokazując, jak osiem baz danych dostaje jedną drogę dostępu.
Plik z makrem nie ma wydań
Do tego dochodzi brak jakiejkolwiek kontroli wersji. Gdy ktoś nadpisze plik .xlsm na dysku sieciowym, powrót do działającej wersji zajmuje godziny, a czasem dni. Wersję trzeba odtworzyć z kopii zapasowej całego udziału sieciowego, bo historii jednego pliku nie ma.
Gorsze jest to, czego nie widać w pliku. Cała wiedza o tym, jak firma liczy marżę albo rozpoznaje zamówienie pilne, siedzi w głowie jednego analityka i w kodzie, którego nikt nigdy nie czytał. Kiedy ten człowiek odchodzi, proces formalnie dalej istnieje, a praktycznie przestaje. To nie jest ryzyko informatyczne. To ryzyko operacyjne, tylko zapisane w technologii.
Architektura zmiany: trzy kroki, które wykonuję w tej kolejności
Rozwiązaniem nie jest zakup kolejnego drogiego systemu klasy enterprise. Rozwiązaniem jest zmiana układu: odseparowanie analityki od operacji. Kolejność ma znaczenie, bo każdy krok opiera się na poprzednim.
1. Odcięcie warstwy produkcyjnej
Zamiast uderzać zapytaniami w główny system ERP, stawiam dedykowaną bazę analityczną, u siebie PostgreSQL na Linuksie, i od tego momentu Power BI, Excel i każde inne narzędzie raportowe czytają wyłącznie z niej. Replika jest zoptymalizowana pod odczyt, a nie pod zapis transakcji, więc znosi zapytania, które w bazie produkcyjnej były niebezpieczne.
Przed bazą stoi pula połączeń. To drobny element, o którym łatwo zapomnieć, a decyduje o tym, czy dwudziestu użytkowników raportu wyczerpie limit połączeń bazy. Jej ustawienia u siebie rozłożyłem osobno, przy PgBouncerze w Dockerze.
Efekt tego kroku jest jakościowy, nie procentowy: najcięższe zapytanie w firmie przestaje mieć dostęp do systemu, który obsługuje magazyn. Nie obiecuję tu żadnej liczby, bo jej nie zmierzyłem.
2. Mikro-wsady zamiast ręcznego uruchamiania
Baza analityczna jest przydatna tylko wtedy, gdy dane w niej są dzisiejsze. Nie osiąga się tego skryptem, który użytkownik odpala sam, bo użytkownik któregoś dnia go nie odpali. Zamiast tego w tle pracuje orkiestrator. U mnie jest to n8n, który stoi w kontenerze na własnym serwerze. Co kilka minut pobiera z systemu głównego wyłącznie wiersze nowe i zmienione, nie całe tabele.
Ten jeden wybór, różnica zamiast pełnego przebiegu, jest tym, co pozwala skrócić okno odświeżania z „raz na noc” do „raz na kilka minut” bez wzrostu obciążenia. Pełny przeładunek raz na dobę jest prostszy w napisaniu i prawie zawsze kończy się tym, że nikt nie ma odwagi uruchamiać go częściej.
Warto też wiedzieć, czym taki przepływ jest uruchamiany, bo to nie jedna decyzja, a kilka. W moich 223 przepływach odnalazłem 334 bloki wyzwalaczy: 63 czekają na zegar, 40 na webhook, a 79, najwięcej ze wszystkich, na wywołanie przez inny przepływ (odczyt z bazy 29 i 30 października 2026). Cały rozkład rozpisałem osobno, przy pytaniu, co uruchamia automatyzację.
3. Konteneryzacja i rygor wydań
W trzecim kroku logika przestaje być plikiem na pulpicie i staje się kodem. Skrypty w Pythonie i przepływy pakuję w izolowane kontenery, a zmiana trafia na produkcję przez repozytorium i automatyczne testy, nie przez wklejenie nowej wersji do działającego systemu.
To jest krok, który najczęściej wypada z zakresu, bo nie widać go w raporcie. Widać go dopiero przy pierwszym błędzie: albo wyłapie go maszyna przed wdrożeniem, albo wyłapie go księgowość na danych finansowych. Jak to wygląda w praktyce w najmniejszej możliwej skali, pokazałem na własnym domu, wersjonując automatyzacje w Home Assistant.
Drugi element rygoru to podział. Jeden duży przepływ, który robi wszystko, jest nie do przetestowania i nie do naprawienia w pośpiechu. Powody, dla których trzymam wiele małych, rozpisałem osobno, pokazując, dlaczego nie mam jednego dużego workflow.
Poligon doświadczalny: po co utrzymuję własny klaster
Nie proponuję w firmie mechanizmu, którego wcześniej celowo nie zepsułem u siebie. Od lat rozwijam własne laboratorium: środowisko hybrydowe oparte na kilku maszynach wirtualnych, lokalnych i chmurowych, z wieloma instancjami PostgreSQL, orkiestratorem n8n, zarządzaniem sekretami przez Bitwarden i własnym zestawem bibliotek w Pythonie.
Po co tak rozbudowana infrastruktura do procesów domowych? Bo to jedyne środowisko, w którym wolno mi wyłączyć węzeł w środku dnia. Podczas testów integracji odciąłem jeden z węzłów i sprawdziłem, co robi reszta. Zwykły skrypt odpytujący wszedłby w nieskończoną pętlę ponowień i dociążył bazę w najgorszym możliwym momencie. Z wzorcem bezpiecznika (circuit breaker) połączenie zostało odcięte po kilku nieudanych próbach, a po powrocie maszyny praca wznowiła się sama.
Będę tu uczciwy co do granic tego porównania: mój klaster nie ma skali firmowego ERP i nigdy nie będzie jej miał. Sprawdzam na nim zachowanie mechanizmu, nie wydajność pod obciążeniem produkcyjnym. To pierwsze przenosi się do firmy dobrze, to drugie trzeba zmierzyć na miejscu.
Trzy rzeczy, których ta zmiana nie załatwia
Rozdzielenie analityki od operacji nie naprawi procesu, który jest zły sam w sobie. Jeżeli dane trafiają do arkusza, bo nikt nie ustalił, kto odpowiada za cennik, to po przeniesieniu całości na PostgreSQL i do kontenerów nadal nikt nie będzie za niego odpowiadał, tylko szybciej.
Nie dostanie się też z tego automatycznie liczby oszczędzonych godzin. Sam jej u siebie nie mam i napisałem o tym osobny tekst: nie wiem, ile czasu oszczędza mój system, bo nie zmierzyłem stanu przed zmianą. Jeżeli ta liczba ma być argumentem w Twoim projekcie, pomiar trzeba zrobić przed pierwszą zmianą, nie po niej.
I rzecz najbardziej niewygodna: ten układ wymaga kogoś, kto go utrzyma. Kontenery, repozytorium i orkiestrator to mniej pracy niż trzydzieści skryptów na pulpitach, ale to nie zero pracy. Firma, która nie ma dla tego właściciela, po roku wróci do arkuszy, tylko tym razem obok działającej infrastruktury.
Granice tego opisu
Zebrałem je w jednym miejscu, żeby nie trzeba było ich szukać w tekście.
- Nie mam pomiaru, o ile spada obciążenie bazy ERP po rozdzieleniu analityki od operacji, więc korzyść z pierwszego kroku opisuję jakościowo i żadnej liczby tu nie obiecuję.
- Wszystkie liczby pochodzą z jednej instancji n8n na moim serwerze domowym i opisują stan z końca października oraz z 3 listopada 2026; nie są tendencją.
- Mój klaster nie ma skali firmowego ERP. Sprawdzam na nim zachowanie mechanizmu przy zerwanym połączeniu, nie wydajność pod obciążeniem produkcyjnym.
- Nie podaję tu żadnej liczby ze środowiska klienta: trzy kroki to opis mojej praktyki, nie wynik badania na próbie firm.
- Sama liczba przepływów nie świadczy o niczym poza skalą, co pokazałem przy odczycie całej bazy n8n.
