Bodovna tablica sa šest pitanja za odabir procesa koji prvi automatizirati
Prvo automatizirajte proces koji se često ponavlja, stiže u predvidljivom obliku, slijedi pravila koja netko može zapisati i kod kojeg pogrešan rezultat ne košta puno. Kod mnogih timova s kojima razgovaramo to nije proces koji ih najviše živcira. To je onaj dosadni, s velikim brojem slučajeva i jasno određenom osobom koja za njega odgovara.
Šest pitanja u nastavku to pretvara u bodove. Primijenite ih na svoj uži izbor prije nego što razgovarate s ijednim dobavljačem, uključujući nas. Dovoljan je jedan kratki sastanak s osobom koja taj posao danas radi.
Bodovna tablica
Svako pitanje ocijenite od 1 do 3. Najviše je 18 bodova.
15 do 18: dobar kandidat za prvi projekt.
12 do 14: drugi projekt, uz korak provjere.
Ispod 12: ostavite za kasnije.
Jedno pravilo vrijedi bez obzira na zbroj. Ocjena 1 na pitanju 4 ili pitanju 6 isključuje proces kao prvi projekt, koliko god dobro prošao na ostalim pitanjima.
Volumen. Koliko se često događa? 1: nekoliko puta mjesečno. 2: nekoliko puta tjedno. 3: svaki dan, mnogo puta.
Oblik ulaznih podataka. Što stiže? 1: slobodan tekst, telefonski pozivi, rukom pisane bilješke. 2: PDF-ovi i e-mailovi poznatog izgleda. 3: obrasci, CSV izvozi ili API.
Jasnoća pravila. Može li osoba koja to danas radi zapisati kako odlučuje na jednoj stranici? 1: „ovisi, jednostavno znam“. 2: jasna pravila s nekoliko poznatih iznimki. 3: jasna pravila, iznimke su rijetke.
Cijena pogrešnog rezultata (viša ocjena = sigurnije). Ako automatizacija pogriješi u jednom slučaju, što se dogodi? 1: novac izlazi iz tvrtke ili grešku vidi kupac. 2: interni zapis je pogrešan dok ga netko ne ispravi. 3: netko to ionako uhvati u sljedećem koraku.
Pristup sustavu. Može li ciljni sustav primiti rezultat? 1: nema API-ja ni uvoza, samo ručni unos na ekranu. 2: uvoz datoteke ili ograničen API. 3: dokumentiran API.
Odgovorna osoba. Postoji li jedna osoba koja poznaje proces i koja će prvih tjedana provjeravati rezultate? 1: ne. 2: da, uz ostale obaveze. 3: da, i ona to želi.
Srodne usluge
Opišite nam svoj projekt
Odgovaraju vam inženjeri koji bi ga gradili, pisanim putem, čim prije, obično u roku od nekoliko dana.
Pretplatite se na naš newsletter i jednom mjesečno primajte praktične savjete o webu, softveru i AI-ju.
Pitanje 4 timovi najčešće preskoče. Proces može imati visoke ocjene na svemu ostalom, a ipak biti loš prvi projekt ako jedan pogrešan rezultat stigne do kupca.
Primjer bodovanja
Evo kako bi četiri česta kandidata mogla proći u distribucijskoj tvrtki s 50 zaposlenih. Ovo ilustrira metodu. Nisu to podaci klijenta i vaše će se ocjene razlikovati.
Razvrstavanje dolazne pošte (usmjeravanje pristiglih e-mailova pravoj osobi ili redu čekanja): volumen 3, ulaz 2, pravila 2, cijena pogreške 3, pristup 3, odgovorna osoba 2. Ukupno 15. Krivo usmjeren e-mail jednostavno se proslijedi. Mali rizik, brza povratna informacija.
Unos ulaznih računa (čitanje PDF-a, popunjavanje zapisa u računovodstvu): volumen 3, ulaz 2, pravila 3, cijena pogreške 2, pristup 2, odgovorna osoba 3. Ukupno 15. Dobar izbor, pod uvjetom da čovjek odobri prije nego što se išta plati.
Unos narudžbi iz narudžbenica poslanih e-mailom: volumen 3, ulaz 2, pravila 2, cijena pogreške 1, pristup 2, odgovorna osoba 2. Ukupno 12. Pogrešna količina ode kupcu, pa ga pravilo o isključenju eliminira kao prvi projekt. Napravite ga kao drugi, uz korak provjere.
Izrada ponuda: volumen 2, ulaz 1, pravila 1, cijena pogreške 1, pristup 2, odgovorna osoba 2. Ukupno 9. Logika određivanja cijena postoji samo u nečijoj glavi. Prvo zapišite pravila, a automatizirajte kasnije.
Ističu se dvije stvari. Proces koji najviše muči (ponude) ima najmanje bodova. A oba pobjednika imaju jeftin način da se pogreške uhvate.
Koliko košta rad
Izrada se plaća jednom. O tome ima li projekt smisla i u drugoj godini odlučuje trošak rada. On se sastoji od četiri dijela.
Hosting. Sustavu koji izvodi workflowe treba server. Pokrenite n8n na vlastitom hostingu u EU-u ili na svojim serverima, kako bi podaci ostali ondje gdje to očekuje vaš službenik za zaštitu podataka.
AI pozivi po izvođenju. Ako neki korak čita dokument pomoću jezičnog modela, svako se izvođenje naplaćuje prema količini teksta koji model pročita i napiše. Trošak je dakle otprilike broj stranica po dokumentu puta broj dokumenata mjesečno. Ispred poziva modela postavite ograničenje, primjerice najveći broj stranica ili limit tokena po izvođenju, kako jedan neobičan PDF od 80 stranica ne bi pojeo mjesečni budžet.
Vrijeme za ljudsku provjeru. Slučajevi koje automatizacija označi kao nesigurne idu čovjeku. Predvidite to vrijeme u budžetu. To je cijena toga što nesigurne slučajeve ne puštate dalje.
Održavanje. API-ji se mijenjaju, dobavljači mijenjaju izgled računa, pružatelji modela izdaju nove verzije. Netko to mora primijetiti i prilagoditi. Taj se trošak najlakše izostavi iz ponude.
Neka workflow ne ovisi o jednom pružatelju AI usluga. Ako pružatelj podigne cijene ili promijeni model, prelazak na drugog trebao bi biti promjena konfiguracije, a ne izrada iznova.
Što se kvari nakon puštanja u rad
Neuspjelo izvođenje je lakši slučaj. U n8n-u postavku Error Workflow svakog workflowa usmjerite na jedan workflow koji počinje čvorom Error Trigger i netko dobije poruku. Teški su slučajevi izvođenja koja izgledaju uspješno.
To smo naučili na vlastitim sustavima. U rujnu 2026. otkrili smo da jedan od naših internih workflowa za potencijalne klijente ima grešku u mapiranju podataka zbog koje je sedam dana davao pogrešne rezultate. Svako je izvođenje završilo zeleno. Nitko nije dobio obavijest jer tehnički ništa nije palo. Sada greške svih workflowa šaljemo na jedno zajedničko upozorenje i provjeravamo rezultate, a ne samo greške.
Istog mjeseca otkrili smo da je jedan naš stariji sustav za prosljeđivanje upozorenja utihnuo. Krajnja točka koja ih je primala vraćala je HTTP 404, a JavaScript poziv fetch() koji je slao upozorenje sam po sebi ne tretira 404 kao grešku. Sva su upozorenja nestajala bez traga dok na to nismo naišli radeći na nečem drugom.
Treći rizik su dvostruka izvođenja. U jednoj prijavi problema za n8n na GitHubu, koja je u studenom 2026. još otvorena (#31837, github.com/n8n-io/n8n/issues/31837), jedan zahtjev prema webhook triggeru pokrenuo je nekoliko izvođenja s istim ID-jem događaja. Kod razvrstavanja pošte to znači dupli tiket. Kod unosa računa znači dvostruko knjiženje. Svaki korak koji stvara zapise bitne za novac trebao bi spremati ID svakog događaja u tablicu baze podataka s ograničenjem jedinstvenosti (unique constraint) i preskočiti izvođenje ako je taj ID već ondje.
Dakle, provjera „radi li još“ ima tri stavke, a ne jednu:
Je li palo? Odgovor daje upozorenje o grešci.
Je li se uopće pokrenulo? Odgovor daje dnevna provjera, primjerice upozorenje kad današnji broj izvođenja padne ispod polovice uobičajenog dnevnog broja.
Je li rezultat točan? Odgovor daje tjedni uzorak, primjerice pet rezultata usporedi se s odgovorima koje već znate.
Kako znati je li AI to napravio točno
Ne iz zapisnika izvođenja. Zeleno izvođenje govori vam samo da su pozivi vratili odgovor.
Prije pokretanja skupite testni skup iz vlastitih stvarnih slučajeva, za svaki s poznatim točnim odgovorom. Rezultat ocjenjujte polje po polje, uz obavezno potpuno podudaranje na poljima koja su bitna, kao što su iznos, datum i IBAN. Nakon svakog ažuriranja modela ponovno pokrenite isti skup. Neka svaki AI odgovor pokaže svoj izvor: s koje stranice i iz kojeg retka računa dolazi iznos. I neka čovjek i dalje odobrava rizičan korak, poput plaćanja ili poruke kupcu, dok vam rezultati testova ne daju razlog da to olabavite.
Taj smo test detaljno opisali u ranijem članku „Kako provjeriti je li AI točno pročitao račun“.
Odakle početi
Iz svog užeg izbora odaberite dva procesa s najviše bodova. Prvo izgradite onaj kod kojeg su pogreške jeftinije. Neka mjesec dana radi s uključenom provjerom i s tri gore navedene kontrole. Zatim o drugom odlučite na temelju stvarnih brojki umjesto procjena.
Ako želite drugo mišljenje, pošaljite nam kratak opis procesa pa ćemo ga zajedno s vama ocijeniti prema ovih šest pitanja. Na stranici objašnjavamo kako određujemo opseg prvog workflowa, uključujući testni skup i korak odobravanja.
