Łączniki nie umarły i nie znikną. Większość scenariuszy, które firmy w nich budują, istnieje jednak tylko dlatego, że ich narzędzia nie potrafią ze sobą rozmawiać. Kiedy łącznik ma sens, kiedy jest tylko plastrem i co się dzieje, gdy usunie się przyczynę.
Prowokacyjne pytanie w tytule zasługuje na uczciwą odpowiedź od razu na początku: nie, nie umarły. Zapier, Make i im podobne to dobre narzędzia i w pewnych sytuacjach nie mają zamiennika.
Ciekawsze jest co innego. Kiedy przejrzycie scenariusze, które firmy w nich naprawdę mają, duża część z nich wcale nie rozwiązuje automatyzacji. Rozwiązuje to, że dwa narzędzia nie dzielą bazy danych.
Do czego łączniki naprawdę się nadają
Zacznijmy od tego, co robią dobrze, bo w podobnych tekstach zwykle się to pomija:
- Połączenie dwóch obcych usług. Sklep internetowy i księgowość. System rezerwacji i kalendarz. Rzeczy, które nigdy nie będą pod jednym dachem.
- Szybki test pomysłu. Zanim ktoś coś zaprogramuje, scenariusz sprawdza, czy proces w ogóle ma sens.
- Jednorazowe przenoszenie danych. Migracje, jednorazowe przetwarzanie danych.
- Rzeczy, na które wasz system po prostu nie ma funkcji.
To są uzasadnione zadania i łącznik jest do nich właściwym narzędziem.
Gdzie zaczyna się robić drogo
Problem pojawia się, gdy łącznik staje się klejem trzymającym działanie firmy. Trzy konkretne powody:
Rozliczanie za operacje. Każdy krok scenariusza to operacja. Scenariusz o czterech krokach, uruchamiany przy każdym zapytaniu, przy pięciuset zapytaniach miesięcznie oznacza dwa tysiące operacji. Cenniki są zbudowane dokładnie na tym.
Cicha awaria. Scenariusz przerywa się w połowie. Dane w pierwszym systemie są, w drugim nie ma. Nikt się o tym nie dowie - chyba że ktoś zauważy, że czegoś brakuje. A zauważa to zwykle klient.
Dodatkowe utrzymanie. Zmieni się pole w jednym systemie, scenariusz przestaje działać. Przybyła wam czwarta rzecz do utrzymania, obok trzech systemów, które chcieliście połączyć.
Ten sam wynik, dwie różne drogi
Cztery skoki między narzędziami to cztery miejsca, w których może się to przerwać. Wewnątrz systemu nic się nie przenosi, bo dane już są na miejscu.
Co oznacza automatyzacja wewnątrz systemu
Różnica jest prosta: łącznik przenosi dane, wbudowana automatyzacja pracuje z danymi na miejscu.
Konkretny przykład. Przychodzi wypełniony formularz i ma się stać to:
- założyć rekord zapytania,
- przypisać je handlowcowi według regionu,
- wysłać klientowi potwierdzenie,
- po trzech dniach przypomnieć, jeśli nikt nie odpowiedział.
Przez łącznik: narzędzie formularzy → łącznik → CRM → narzędzie e-mailowe → planer. Pięć usług, minimum cztery operacje na jedno zapytanie, cztery miejsca, w których może się to rozpaść.
Wewnątrz systemu: jedna reguła z czterema krokami. Formularz zapisuje bezpośrednio do bazy danych, bo jest jej częścią. E-mail wysyła system, który zna rekord. Przypomnienie to warunek nad polem, które już istnieje.
Żaden transfer danych nie zachodzi, bo nie ma między czym.
| Zewnętrzny łącznik | Wbudowana automatyzacja | |
|---|---|---|
| Gdzie są dane | W dwóch i więcej systemach | W jednym miejscu |
| Rozliczanie | Za operacje | Część systemu |
| Gdy coś padnie | Dane zostają połowiczne | Krok się nie wykona, rekord jest cały |
| Kto to naprawi | Kto zbudował scenariusz | Każdy, kto potrafi zmienić regułę |
| Historia uruchomień | W łączniku | Przy rekordzie, którego to dotyczy |
Nie chodzi o zakazanie łączników
Rozsądny stan bywa taki: wewnątrz systemu działa wszystko, co dotyczy waszych własnych danych. Łącznik zostaje na to, co naprawdę wychodzi na zewnątrz - na przykład połączenie sklepu internetowego z programem księgowym.
Jak rozpoznać scenariusz, który jest tylko plastrem
Przejrzyjcie swoje scenariusze i przy każdym zapytajcie: ile z jego kroków to tylko przenoszenie tej samej informacji między narzędziami?
Jeśli to wszystkie kroki oprócz ostatniego, macie plaster. Jeśli scenariusz naprawdę coś liczy, decyduje albo rozmawia z obcą usługą, jest na swoim miejscu.
Drugi test: gdyby oba narzędzia były jednym, czy ten scenariusz w ogóle by istniał? To pytanie odsłania większość przypadków szybciej niż jakakolwiek analiza.
Co się dzieje, gdy usunie się przyczynę
Firmy, które ujednolicą swoją bazę danych, zwykle zgłaszają trzy rzeczy:
Większość scenariuszy znika. Nie dlatego, że się przeniosły - przestają być potrzebne, bo transfer, który zapewniały, nie ma skąd i dokąd.
Przestaje się rozwiązywać, czy dane się zgadzają. Nie mogą się rozjechać, bo istnieją tylko raz.
Automatyzacje są czytelne dla większej liczby osób. Regułę opisaną w systemie, gdzie te dane żyją, przeczyta też nietechniczny kolega. Scenariusz w osobnym narzędziu czyta tylko ten, kto go zbudował.
Kompletne wprowadzenie do tego, jak działają automatyzacje nocode, znajdziecie w przewodniku Automatyzacja w Apexloop. Dlaczego warto widzieć pod maską każdego kroku, rozkłada artykuł Automatyzacja bez czarnej skrzynki. Techniczne detale połączenia z obcymi usługami są na stronie Webhooki i API. Cały temat od szukania kandydatów po obliczenie zwrotu prowadzi przewodnik po automatyzacji procesów firmowych.
Najczęstsze pytania o łącznikach i automatyzacji
Czy to znaczy, że mamy zrezygnować z Make lub Zapiera?
Nie. Oznacza to przejrzenie scenariuszy i sprawdzenie, ile z nich istnieje tylko dlatego, że wasze narzędzia nie dzielą danych. Pozostałe zostawcie tak, jak są - do połączenia z obcymi usługami łącznik nadal jest najrozsądniejszym wyborem.
A co, jeśli potrzebujemy czegoś, czego wbudowana automatyzacja nie potrafi?
Od tego są ścieżki ucieczki - webhook albo wywołanie API w ramach automatyzacji. Różnica względem łącznika jest taka, że rozwiązuje się tylko ten jeden wyjątek, nie cały przepływ danych.
Jak sprawdzić, ile nas łącznik realnie kosztuje?
Spójrzcie na zużycie operacji za ostatnie trzy miesiące i podzielcie je przez liczbę scenariuszy. Zwykle wychodzi, że dwa do trzech scenariuszy zużywają osiemdziesiąt procent limitu - i to właśnie one zwykle są tym plastrem.