Zaczyna się niewinnie: ktoś buduje pierwszy scenariusz, uruchamia go po godzinie i od razu widać efekt. Po roku firma ma ich czterdzieści. Dwa liczą premie handlowców, kilka przerzuca dane między systemami, a osoba, która to wszystko poukładała, od marca pracuje już gdzie indziej. Wtedy automatyzacja przestaje być tylko wygodą. Staje się kosztem, zależnością i ryzykiem, które da się policzyć, najczęściej wcześniej w rachunku za operacje niż w tabelce działu finansowego.
Trzy drogi prowadzą do tego samego celu, ale rozliczają się inaczej
Automatyzację procesu można dziś zbudować na trzy sposoby i wszystkie trzy są uczciwe. Pierwszy to platforma no-code, czyli narzędzie do składania przepływów bez pisania kodu: Zapier, Make albo n8n. Drugi to własne skrypty uruchamiane z harmonogramu, trzeci to dedykowany system pisany pod konkretny proces. Różnica nie leży w tym, który sposób jest lepszy, tylko w tym, gdzie każdy z nich się kończy i kto za to zakończenie płaci.
| Kryterium | Platforma no-code | Własne skrypty | Dedykowany system |
|---|---|---|---|
| Czas do pierwszego działającego procesu | godziny | dni | tygodnie |
| Kto może wprowadzić zmianę | osoba z działu | programista | zespół lub dostawca |
| Model kosztu | abonament plus opłata za wolumen | serwer plus czas programisty | projekt plus utrzymanie |
| Co się psuje najczęściej | limity i zmiany w API dostawcy | brak monitoringu i dokumentacji | rozjazd między systemem a procesem |
| Gdzie się kończy | wolumen, nietypowa logika, brak historii zmian | wiedza jednej osoby | koszt startu |
Jak platformy naliczają koszt i dlaczego ten sam proces kosztuje różnie
Tutaj zaczyna się pierwsza niespodzianka. Trzy najpopularniejsze platformy liczą zupełnie inne rzeczy. Ten sam proces przeniesiony między nimi potrafi zmienić rachunek o dwa rzędy wielkości.
Zapier liczy udane akcje
Zgodnie z dokumentacją Zapiera zadaniem jest każda akcja zakończona powodzeniem. Wyzwalacz nie zużywa nic, krok odrzucony przez filtr nie zużywa nic, akcja zakończona błędem również nie. Ma to praktyczną konsekwencję: dobrze ustawiony filtr na początku przepływu realnie obniża rachunek, bo wszystko za nim się nie uruchamia.
Make nalicza kredyty za uruchomienia modułów, paczka po paczce
W Make jednostką rozliczeniową planu są dziś kredyty, które w dokumentacji zastąpiły w tej roli operacje. Sama operacja nadal oznacza jedno uruchomienie modułu, a dla modułów niezwiązanych ze sztuczną inteligencją jedna operacja kosztuje jeden kredyt. Liczba uruchomień zależy przy tym od liczby przetwarzanych paczek danych: wgranie trzech plików to trzy operacje, wysłanie pięciu wiadomości to pięć operacji. Wyzwalacz jest wyjątkiem i zużywa jedną operację niezależnie od tego, ile rekordów zwróci.
n8n liczy wykonania całego przepływu
W n8n jednostką rozliczeniową jest wykonanie, czyli jedno uruchomienie przepływu od początku do końca. Plan startowy daje 2 500 wykonań miesięcznie. Nie ma przy tym znaczenia, czy przepływ ma trzy węzły, czy trzydzieści.
Policzmy to na jednym procesie
Firma przetwarza dziennie 200 nowych zamówień. Automatyzacja sprawdza status klienta w systemie sprzedażowym, tworzy dokument i wysyła powiadomienie do handlowca. To trzy operacje na każdym rekordzie.
W Make każdy z trzech modułów uruchomi się osobno dla każdej paczki. Dzienny koszt to około 600 operacji, a miesięczny przekracza 18 000 kredytów. W Zapierze rachunek wygląda podobnie: trzy udane akcje razy 200 rekordów to 600 zadań dziennie, a filtr odsiewający połowę zamówień ścina go o połowę.
W n8n ten sam proces uruchamiany raz dziennie w jednej partii to 30 wykonań miesięcznie. Wolumen danych wewnątrz przepływu nie ma wpływu na licznik, ale jeśli przepływ startuje osobno dla każdego zamówienia, rośnie on tak samo jak wszędzie indziej. Ta sama automatyzacja mieści się więc albo w najtańszym planie, albo wyczerpuje limit w połowie miesiąca. Decyduje o tym architektura przepływu, nie skala firmy.
Cztery progi, po których automatyzacja z pudełka przestaje wystarczać
Próg pierwszy: wolumen rośnie szybciej niż plan
Limity operacji planuje się na podstawie średniej, a wyczerpuje w szczycie. Kampania, koniec kwartału albo jeden większy klient potrafią podnieść dzienny wolumen kilkukrotnie. Zwykle w tygodniu, w którym nikt tego nie obserwuje.
Co się wtedy stanie, zależy od platformy i od ustawień planu. W Zapierze przy włączonym rozliczeniu nadwyżkowym każde kolejne zadanie kosztuje więcej, a przy wyłączonym automatyzacja staje do końca cyklu rozliczeniowego. Gdzie indziej trzeba dokupić pakiet albo przejść na wyższy plan.
Zatrzymanie jest gorsze, niż brzmi. Proces nie zgłasza się komunikatem, tylko przestaje przetwarzać zamówienia. Dowiaduje się o tym klient, który nie dostał potwierdzenia.
Próg drugi: historia zmian jest krótsza niż cykl życia procesu
Platformy no-code mają historię zmian, ale jej zasięg zależy od narzędzia i planu. Zapier pozwala tworzyć szkice i wrócić do wcześniejszej wersji. W planie Professional widać wersje z ostatniego miesiąca, w Team z sześciu, w Enterprise z roku, a w darmowym nie ma ich wcale. W n8n kontrola wersji przez Git, czyli śledzenie zmian w kodzie, jest dopiero w planie Business. Miesiąc historii wystarcza do cofnięcia wczorajszej pomyłki. Nie wystarcza, gdy audytor pyta o naliczenie sprzed pół roku i trzeba odtworzyć, jak proces wyglądał w kwietniu.
Drugą częścią tego progu jest brak osobnego środowiska do testów, co nie jest tym samym co brak szkicu. W Zapierze zmianę można przygotować bez ruszania opublikowanej wersji, ale test akcji potrafi zapisać dane w podłączonym systemie. Prawdziwa izolacja wymaga kont testowych, osobnych danych albo środowiska deweloperskiego.
Ten próg widać najlepiej wtedy, gdy proces zaczyna dotykać pieniędzy. Rozwiązaniem bywa przeniesienie przepływów do postaci, którą da się trzymać w repozytorium. Opisywaliśmy to szerzej przy okazji pisania przepływów n8n w edytorze kodu zamiast klikania w interfejsie.
Próg trzeci: integracja z ERP wychodzi poza gotowe konektory
Katalogi gotowych połączeń obejmują setki usług, ale są to głównie popularne narzędzia z rynku globalnego. System ERP, czyli oprogramowanie do planowania zasobów firmy, albo magazynówka wdrożona w polskiej firmie dziesięć lat temu zwykle się w tym katalogu nie znajduje. Zostaje wtedy integracja przez interfejs programistyczny systemu, czyli API, o ile taki w ogóle istnieje. Alternatywą bywa wymiana plików w uzgodnionym formacie. Jedno i drugie da się zrobić w narzędziu no-code. Tylko że to już nie jest składanie klocków, a programowanie w środowisku, którego do programowania nie zaprojektowano.
Drugą warstwą jest logika biznesowa, która w takich systemach rzadko siedzi tam, gdzie się jej spodziewamy. Rabat zależny od historii płatności albo rezerwacja towaru pod zamówienie to reguły zaszyte w polach niestandardowych. Żaden gotowy konektor ich nie zna.
Próg czwarty: błąd, którego nikt nie zauważa
Awaria jest łatwa, bo widać ją od razu. Znacznie groźniejszy jest przepływ, który wykonuje się poprawnie, świeci na zielono i robi złą rzecz. Kopiuje dane do niewłaściwej kolumny albo pomija rekordy, bo dostawca zmienił nazwę pola. Platformy no-code raportują status wykonania, nie poprawność wyniku, a to są dwie różne rzeczy. Pisaliśmy o tym osobno przy okazji cichego błędu automatyzacji, w którym wszystko działa, tylko efekt jest zły.
Cenniki milczą przy tym o jednej rzeczy. Darmowa wersja n8n uruchomiona na własnym serwerze nie ma limitu wykonań. Próg wolumenowy jest więc granicą konkretnego abonamentu, a nie granicą technologii. Firma, która ma kogo poprosić o utrzymanie serwera, przesuwa go bardzo daleko.
Własne skrypty są tańsze na starcie i droższe w utrzymaniu
Skrypt uruchamiany z harmonogramu na firmowym serwerze przesuwa trzy pierwsze progi daleko, ale nie usuwa ich automatycznie. Nie podlega limitowi abonamentu, dopóki wystarcza wydajność serwera. Pełną historię zmian ma wtedy, gdy ktoś od początku trzyma kod w repozytorium, czyli we wspólnym archiwum kodu razem z historią. Integracja jest kwestią czasu, o ile system w ogóle daje się podłączyć przez API, bazę danych albo wymianę plików.
Czwartego progu skrypt nie zdejmuje wcale, a zwykle go pogłębia. Nie ma nawet tego skromnego widoku wykonań, który daje platforma, bo nikt nie zaplanował monitoringu na etapie, gdy narzędzie miało być tymczasowe. Cichy błąd potrafi w takim miejscu żyć miesiącami.
Rachunek przychodzi jeszcze z jednej strony. Skrypt nie ma interfejsu, więc zmiana najprostszej reguły wymaga programisty, a nie osoby, która zna proces. Po roku o awarii dowiadujemy się od użytkownika, token dostępowy wygasł w środę, a cała dokumentacja mieści się w komentarzu na górze pliku. Najdroższy jest jednak koszt osobowy. Wiedza o tym, co skrypt robi i dlaczego akurat tak, zostaje w głowie jednej osoby. Jej odejście zamienia działające narzędzie w czarną skrzynkę, której nikt nie chce dotykać.
Ile realnie kosztuje utrzymanie każdej z trzech dróg
Abonament jest najmniejszą i najłatwiejszą do sprawdzenia częścią rachunku. Reszta siedzi w godzinach, których nikt nie fakturuje, bo płaci je własny zespół. Poniższe wyliczenie jest przykładem opartym na założeniach, nie cennikiem. Przyjmijmy, że godzina pracy technicznej kosztuje firmę 150 zł, a proces jest ten sam co wyżej: 200 rekordów dziennie.
Platforma no-code za 250 zł miesięcznie, przy dwóch godzinach obsługi, kosztuje realnie 550 zł. Te dwie godziny to poprawki po zmianach u dostawców i dokładanie wyjątków, a nie budowanie czegokolwiek nowego. Własny skrypt na serwerze za 100 zł, przy czterech godzinach utrzymania, kosztuje 700 zł. W papierach jest więc dwa i pół raza tańszy od platformy, a po doliczeniu pracy wychodzi o 150 zł drożej. Dedykowany system wypada na tym tle najdrożej. Przyjmijmy wdrożenie za 60 000 zł rozłożone na trzy lata, tysiąc złotych opieki miesięcznie i cztery godziny rozwoju. Razem daje to około 3 270 zł.
Ta ostatnia kwota ma sens dopiero wtedy, gdy zestawi się ją z tempem wzrostu pozostałych dwóch. Koszt systemu dedykowanego zwykle nie rośnie liniowo z liczbą rekordów, więc podwojenie wolumenu nie musi podwoić rachunku. W no-code rośnie właśnie wolumen, w skryptach rosną godziny, a w systemie dedykowanym rośnie koszt każdej zmiany. Przy 200 rekordach dziennie i jednym procesie rachunek wychodzi bezdyskusyjnie na korzyść platformy. Przy kilkunastu procesach i wolumenie w tysiącach rekordów proporcje potrafią się odwrócić, i to jest moment, w którym warto go przeliczyć od nowa.
Kiedy przechodzi się na rozwiązanie szyte na miarę
Dedykowany system nie jest kolejnym szczeblem drabinki, na który wchodzi się z rozpędu. To decyzja, którą uzasadniają cztery konkretne sytuacje.
Pierwsza to proces będący realną przewagą firmy. Sposób wyceny albo obsługi zgłoszeń bywa tym, czym firma wygrywa z konkurencją. Trzymanie takiego procesu w cudzym narzędziu oznacza oddanie kontroli nad własnym rdzeniem.
Druga to dane, które nie mogą opuścić firmowej infrastruktury. Dane osobowe, medyczne albo objęte umową z kontrahentem bywają wykluczone z przetwarzania w usłudze zewnętrznej, niezależnie od jej zabezpieczeń. Sam ten warunek nie przesądza jednak o dedykowanym systemie, bo spełni go też skrypt albo platforma postawiona na własnym serwerze. Przesądza dopiero w połączeniu z pozostałymi trzema sytuacjami.
Trzecia to logika, która przestała mieścić się na diagramie. Kilkanaście gałęzi warunkowych, wyjątki od wyjątków i reguły zależne od historii to jasny sygnał. Proces jest już programem, tylko napisanym w narzędziu do rysowania.
Czwarta jest najbardziej prozaiczna i najczęstsza. Rachunek za abonamenty i za czas ludzi łatających przepływy przekracza koszt utrzymania własnego rozwiązania. Wtedy sensowniejszym wyborem bywa oprogramowanie do automatyzacji procesów pisane pod konkretny przebieg pracy, razem z interfejsem dla osób, które obsługują ten proces na co dzień. Warto przy tym pamiętać, że taki system rzadko zastępuje wszystko naraz. Najczęściej powstaje wokół istniejącego ERP albo CRM i przejmuje tylko tę część przebiegu, która najbardziej doskwiera.
Jak policzyć próg, zanim się o niego uderzy
Wybór między trzema drogami nie wymaga analizy strategicznej, tylko czterech odpowiedzi zapisanych na kartce.
Policz operacje w szczycie, nie w średniej. Weź najgorszy tydzień z ostatniego roku. Pomnóż liczbę rekordów przez liczbę kroków w przepływie i porównaj wynik z limitem planu.
Sprawdź, co się stanie po przekroczeniu limitu. Czy dostaniesz wyższy rachunek, czy proces stanie, i czy ktokolwiek dostanie o tym powiadomienie.
Sprawdź, kto ma dostęp i czy istnieje historia zmian. Jeśli odpowiedź brzmi “jedna osoba” i “nie ma”, to jest ryzyko operacyjne, nie techniczny drobiazg.
Wyceń czas utrzymania. Policz godziny spędzane co miesiąc na poprawkach po zmianach u dostawców i na tłumaczeniu nowym osobom, jak to działa. Pomnóż je przez stawkę, tak jak w rachunku wyżej.
Dopiero z tymi czterema odpowiedziami widać, gdzie leży granica dla konkretnego procesu, a nie dla branży w ogólności. Dobrze zaplanowana automatyzacja procesów w firmie zaczyna się od takiego rachunku, a nie od wyboru platformy.
Co z tego wynika w praktyce
Platforma no-code jest właściwym wyborem dla większości procesów w większości firm. Pozostaje nim dłużej, niż sugerują cenniki, zwłaszcza gdy przepływ przetwarza dane w partiach zamiast rekord po rekordzie. Własne skrypty sprawdzają się tam, gdzie proces jest stabilny i ma właściciela technicznego. Dedykowany system ma sens wtedy, gdy proces jest przewagą firmy, dane nie mogą wyjść na zewnątrz albo logika przerosła diagram. Cztery odpowiedzi z poprzedniej sekcji zajmują pół godziny i wystarczą, żeby ten wybór był świadomy. Najgorszy scenariusz to bowiem nie zły wybór, tylko brak wyboru. Czterdzieści przepływów, które powstały jeden po drugim, bez decyzji i bez osoby, która wie, który z nich liczy premie.
Artykuł sponsorowany.
