Make czy n8n, a może własna integracja: pięć progów przełączenia

Make czy n8n to pytanie, które zwykle pada za wcześnie. Zanim wybierzesz narzędzie, rozstrzygasz coś większego: gdzie ma mieszkać logika biznesowa Twojej firmy — w scenariuszu wyklikanym w cudzym interfejsie czy w kodzie, który należy do Ciebie i da się przetestować. Oba warianty bywają dobre i przez długi czas są wymienne. Przestają być wymienne w chwili, w której awaria przepływu zaczyna kosztować pieniądze, a nikt w firmie nie potrafi powiedzieć, co dokładnie ten przepływ robi.

Make czy n8n — czym te narzędzia są, jeżeli odjąć marketing

Make i n8n to narzędzia do budowania przepływów danych między aplikacjami bez pisania kodu: wskazujesz zdarzenie startowe, dokładasz kolejne kroki i mapujesz pola między systemami. Make działa wyłącznie w chmurze dostawcy. n8n jest oprogramowaniem open source — można uruchomić je u siebie, na przykład w Dockerze, albo skorzystać z chmury n8n z serwerami w Niemczech. To jedyna różnica konstrukcyjna, która realnie zmienia rozkład odpowiedzialności; reszta to kwestia interfejsu i zestawu gotowych łączników.

Oba narzędzia należą do klasy iPaaS. iPaaS (Integration Platform as a Service) to model, w którym dostawca chmurowy hostuje platformę integracyjną i odpowiada za aktualizacje, dostępność oraz bezpieczeństwo, a klient buduje na niej przepływy bez utrzymywania własnego middleware. Obok iPaaS w polskich materiałach branżowych opisuje się jeszcze połączenia punkt-punkt i szynę danych ESB, a wybór między tymi architekturami porządkuje osobny tekst o integracji systemów w firmie. Do tej samej klasy narzędzi należą Zapier, Microsoft Power Automate, Node-RED i Pipedream, a w handlu internetowym rolę gotowego integratora pełnią BaseLinker, Apilo i Sellasist.

Pięć progów przełączenia, po których scenariusz no-code przestaje się opłacać

Scenariusz no-code przestaje się opłacać wtedy, gdy przekroczysz którykolwiek z pięciu progów poniżej — nie wtedy, gdy narzędzie przestanie działać. Każdy z nich da się sprawdzić w firmie w jedno popołudnie, bez udziału programisty.

1. Scenariusz przestał mieścić się w głowie jednej osoby. Jak sprawdzić: poproś kogoś, kto go nie budował, żeby w pięć minut opisał, co przepływ robi i co się stanie, gdy siódmy krok zwróci błąd. Jeżeli nie potrafi, masz oprogramowanie bez dokumentacji i bez testów, tylko w innym formacie.
2. Przez przepływ przechodzą dane, których nie pokazałbyś na ekranie w sali konferencyjnej. Jak sprawdzić: wypisz pola, które faktycznie wędrują przez scenariusz, a nie te, które miały wędrować. Dane osobowe, dokumenty kadrowe, dane płatnicze i całe rekordy klientów zmieniają rozmowę z technicznej na formalną.
3. Ktoś czeka na wynik. Jak sprawdzić: ustal, czy przetwarzanie może być wsadowe, czy użytkownik stoi przed ekranem i patrzy na spinner. Scenariusze no-code działają w kolejce dostawcy, więc opóźnienie jest zmienne i nie masz nad nim kontroli — przy procesach interaktywnych to dyskwalifikacja, przy nocnym imporcie nie ma znaczenia.
4. Musisz odtworzyć, co się stało trzy miesiące temu. Jak sprawdzić: spróbuj dziś odpowiedzieć, kto ostatnio zmienił scenariusz, co dokładnie zmienił i jak wyglądał stan przed zmianą. Jeżeli branża, klient korporacyjny albo audytor wymagają śladu zmian i historii przetwarzania, potrzebujesz wersjonowania, a nie przycisku „cofnij”.
5. Koszt rośnie szybciej niż obsłużony wolumen. Jak sprawdzić: policz kroki przypadające na jeden dokument i pomnóż przez liczbę dokumentów ze szczytu sezonu, nie ze średniej miesięcznej. Nie chodzi o cennik, bo ten zmienia się kilka razy w roku, tylko o kierunek: rozliczenie za operacje premiuje proste przepływy i karze rozbudowane.

Do tego dochodzi ograniczenie, na które nie ma wpływu żadne narzędzie: część starszych systemów obecnych na polskim rynku nie ma publicznego, wspieranego interfejsu. Wtedy pytanie „Make czy n8n” nie ma sensu, bo problemem nie jest platforma, tylko brak drzwi po drugiej stronie. Decyzja przenosi się wtedy o poziom niżej — na to, jak połączyć dwa systemy bez API, od wymiany plików po odczyt danych wprost z panelu.

Ile naprawdę kosztuje n8n na własnym serwerze

Self-hosting nie usuwa kosztu, tylko przenosi go z faktury dostawcy na infrastrukturę i czas Twojego zespołu. To najczęściej pomijana pozycja w porównaniach narzędzi, a jednocześnie ta, która najczęściej wywraca kalkulację po roku pracy.

Firma, która stawia narzędzie u siebie, bierze na siebie pięć obowiązków:

• Aktualizacje. Nowe wersje wychodzą regularnie, a odkładanie ich kończy się skokiem przez kilka wersji naraz i przepływami, które przestają działać.
• Kopie zapasowe. Liczy się nie samo robienie kopii, tylko przetestowane odtworzenie — łącznie z zaszyfrowanymi danymi uwierzytelniającymi do wszystkich podpiętych systemów.
• Dostępność. Ktoś musi wiedzieć, że narzędzie przestało działać w sobotę o dwudziestej, i mieć uprawnienia, żeby je podnieść.
• Bezpieczeństwo. Narzędzie integracyjne trzyma tokeny OAuth 2.0, klucze API i hasła do systemów firmy. To jeden z najbardziej wrażliwych elementów infrastruktury, a nie zwykła aplikacja wewnętrzna.
• Osoba, która to rozumie. Bez niej wszystkie powyższe punkty są teoretyczne.

Te godziny wycenia się dokładnie tak samo jak każdy inny nakład pracy w projekcie — tym samym mechanizmem, który decyduje o tym, ile kosztuje aplikacja mobilna czy dowolne wdrożenie rozliczane zakresem. Dopóki ich nie policzysz, porównanie „chmura kontra własny serwer” jest porównaniem jednej kolumny z pustą.

Gdzie fizycznie przechodzą Twoje dane

Dane przechodzą przez infrastrukturę dostawcy narzędzia i przez każdy zewnętrzny łącznik użyty w scenariuszu — także wtedy, gdy oba integrowane systemy stoją w Polsce. Przy danych osobowych to jest pytanie do umowy powierzenia przetwarzania i do dokumentacji konkretnego planu, a nie do artykułu porównawczego.

Sprawdź trzy rzeczy w dokumentach dostawcy, zanim zbudujesz pierwszy przepływ: w jakim regionie przetwarzane są dane, kto występuje jako podprocesor oraz jak długo przechowywana jest historia wykonania scenariuszy razem z treścią przesyłanych rekordów. Ta ostatnia pozycja zaskakuje najczęściej — logi przepływu potrafią zawierać całe rekordy klientów. Ten materiał ma charakter informacyjny i nie jest poradą prawną; zakres obowiązków w Twojej firmie potwierdź z osobą odpowiedzialną za ochronę danych.

Wariant mieszany, którego prawie nikt nie proponuje

Najczęściej najlepsze rozwiązanie nie jest wyborem jednego narzędzia dla całej firmy, tylko podziałem: no-code do prostych przepływów, własny kod do jednego procesu krytycznego. Powiadomienia na Slacku, przepisywanie leadów z formularza do CRM-u, cykliczne raporty i wysyłka plików przez SFTP mogą spokojnie zostać w Make albo n8n — są proste, wsadowe i tanie w odbudowie po awarii.

Osobno traktuj proces, na którym stoi przychód. Najczęściej jest to synchronizacja stanów magazynowych między sklepem, magazynem a marketplace’ami, obieg zamówień albo wystawianie dokumentów sprzedaży. Ten jeden przepływ wart jest własnej integracji z testami, kolejką i logami, nawet jeżeli reszta firmy działa na scenariuszach. Niezależnie od wybranej drogi każda integracja potrzebuje logów, monitoringu, kolejki nieudanych komunikatów, procedury ponowienia i właściciela po stronie firmy — to zestaw minimum opisany szerzej przy integracji systemów w firmie.

Kryterium po kryterium: scenariusz no-code czy własna integracja

Tabela nie wskazuje zwycięzcy, bo go nie ma. Wskazuje, którą kolumnę wybierasz dla konkretnego procesu — i dlatego decyzję podejmuje się osobno dla każdego przepływu, a nie raz dla całej firmy.

Pytania, które zadaj przed wyborem narzędzia

Zanim porównasz interfejsy Make i n8n, odpowiedz na pytania o własną firmę. Odpowiedzi rozstrzygają wybór szybciej niż jakikolwiek ranking funkcji, a przy okazji stanowią gotowy materiał do dokumentu, na podstawie którego napiszesz brief dla software house’u.

Jeżeli odpowiedzi wskazują, że co najmniej jeden proces przekroczył próg przełączenia, potraktuj to jako osobny projekt z zakresem, a nie jako kolejny scenariusz do dobudowania. Opisz ten proces w kreatorze briefu — sześć kroków wystarczy, żeby rozmowa zaczęła się od tego, co dokładnie ma się wydarzyć między systemami, zamiast od nazwy narzędzia.