Zapier a Make umřely? Proč automatizace patří dovnitř systému

Propojovače neumřely a nezmizí. Většina scénářů, které v nich firmy staví, ale existuje jen proto, že jejich nástroje spolu neumí mluvit. Kdy dává propojovač smysl, kdy je to náplast a co se stane, když se odstraní příčina.

Marek Raja

Provokativní otázka v titulku si zaslouží poctivou odpověď hned na začátku: ne, neumřely. Zapier, Make a jejich příbuzní jsou dobré nástroje a v určitých situacích nemají náhradu.

Zajímavější je jiná věc. Když si projdete scénáře, které v nich firmy reálně mají, velká část z nich neřeší automatizaci. Řeší to, že dva nástroje nesdílí databázi.

K čemu jsou propojovače skutečně dobré

Začněme tím, co dělají dobře, protože to se v podobných textech obvykle přeskočí:

  • Propojení dvou cizích služeb. E-shop a účetnictví. Rezervační systém a kalendář. Věci, které nikdy nebudou pod jednou střechou.
  • Rychlý test nápadu. Než někdo něco naprogramuje, scénář ověří, jestli má proces vůbec smysl.
  • Jednorázové přenosy. Migrace, jednorázové zpracování dat.
  • Věci, na které váš systém prostě nemá funkci.

Tohle jsou legitimní úlohy a propojovač je na ně správný nástroj.

Kde to začne být drahé

Problém vzniká, když se z propojovače stane lepidlo držící provoz firmy. Tři konkrétní důvody:

Účtuje se po operacích. Každý krok scénáře je operace. Scénář o čtyřech krocích, který se spustí u každé poptávky, u pěti set poptávek měsíčně znamená dva tisíce operací. Ceníky jsou postavené přesně na tomhle.

Tichý výpadek. Scénář se přeruší uprostřed. Data v prvním systému jsou, ve druhém ne. Nikdo se nic nedozví - pokud si někdo nevšimne, že něco chybí. A všimne si obvykle klient.

Údržba navíc. Změní se pole v jednom systému, scénář přestane fungovat. Přibyla vám čtvrtá věc, kterou je potřeba udržovat, vedle tří systémů, které jste chtěli propojit.

Stejný výsledek, dvě různé cesty

Čtyři přeskoky mezi nástroji jsou čtyři místa, kde se to může přerušit. Uvnitř systému se nic nepřenáší, protože data už jsou na místě.

Co znamená automatizace uvnitř systému

Rozdíl je jednoduchý: propojovač data přenáší, vestavěná automatizace s daty pracuje na místě.

Konkrétní příklad. Přijde vyplněný formulář a má se stát tohle:

  1. založit záznam poptávky,
  2. přiřadit ho obchodníkovi podle regionu,
  3. poslat klientovi potvrzení,
  4. za tři dny připomenout, pokud nikdo neodpověděl.

Přes propojovač: formulářový nástroj → propojovač → CRM → e-mailový nástroj → plánovač. Pět služeb, minimálně čtyři operace na jednu poptávku, čtyři místa, kde se to může rozpadnout.

Uvnitř systému: jedno pravidlo se čtyřmi kroky. Formulář zapisuje přímo do databáze, protože je její součástí. E-mail se posílá ze systému, který zná záznam. Připomínka je podmínka nad polem, které už existuje.

Žádný přenos dat neproběhne, protože není mezi čím.

Externí propojovačVestavěná automatizace
Kde jsou dataVe dvou a více systémechNa jednom místě
ÚčtováníZa operaceSoučást systému
Když to spadneData zůstanou rozpůlenáKrok se neprovede, záznam je celý
Kdo to opravíKdo scénář postavilKdokoli, kdo umí upravit pravidlo
Historie běhůV propojovačiU záznamu, kterého se to týká

Nejde o to zakázat propojovače

Rozumný stav bývá tenhle: uvnitř systému běží všechno, co se týká vašich vlastních dat. Propojovač zůstává na to, co opravdu vede ven - třeba spojení e-shopu s účetním programem.

Jak poznat scénář, který je jen náplast

Projděte si svoje scénáře a u každého se zeptejte: kolik z jeho kroků je jen přenos stejné informace mezi nástroji?

Když jsou to všechny kroky kromě posledního, máte náplast. Když scénář skutečně něco počítá, rozhoduje nebo mluví s cizí službou, je na svém místě.

Druhý test: kdyby oba nástroje byly jeden, existoval by ten scénář vůbec? Tahle otázka odhalí většinu případů rychleji než jakákoli analýza.

Co se stane, když se odstraní příčina

Firmy, které si sjednotí datový základ, obvykle hlásí tři věci:

Většina scénářů zmizí. Ne že by se přesunuly - přestanou být potřeba, protože přenos, který zajišťovaly, nemá kam a odkud.

Přestane se řešit, jestli data sedí. Nemůžou se rozejít, protože existují jednou.

Automatizace jsou čitelné pro víc lidí. Pravidlo popsané v systému, kde ta data žijí, přečte i netechnický kolega. Scénář v samostatném nástroji čte jen ten, kdo ho stavěl.

Kompletní úvod do toho, jak nocode automatizace fungují, je v návodu Automatizace v Apexloopu. Proč má smysl vidět pod pokličku každého kroku, rozebírá článek Automatizace bez černé skříňky. Technické detaily napojení na cizí služby jsou na stránce Webhooky a API. Celé téma od hledání kandidátů po výpočet návratnosti vede průvodce automatizací firemních procesů.

Časté otázky k propojovačům a automatizaci

Znamená to, že máme zrušit Make nebo Zapier?

Ne. Znamená to projít si scénáře a zjistit, kolik z nich existuje jen kvůli tomu, že vaše nástroje nesdílí data. Ty ostatní nechte být - na propojení s cizími službami je propojovač dál nejrozumnější volba.

Co když potřebujeme něco, co vestavěná automatizace neumí?

Od toho existují úniková cesty - webhook nebo volání API v rámci automatizace. Rozdíl oproti propojovači je v tom, že se řeší jen ta jedna výjimka, ne celý tok dat.

Jak zjistím, kolik nás propojovač reálně stojí?

Podívejte se na spotřebu operací za poslední tři měsíce a vydělte ji počtem scénářů. Většinou vyjde, že dva až tři scénáře spotřebují osmdesát procent kreditu - a právě ty bývají tou náplastí.

Popište, co se má dít samo.

Apexloop postaví aplikaci na míru