Strumenti di automazione aziendale: il criterio non è quale, è dove stanno scritte le regole
Gli strumenti di automazione aziendale sono i programmi che eseguono da soli una sequenza di passaggi che prima faceva una persona, a un orario stabilito oppure quando succede qualcosa. La domanda con cui quasi tutti arrivano è quale sia il migliore, e quella domanda non ha una risposta utile: su un flusso semplice funzionano tutti, e il primo mese non distingue niente. La differenza si vede sei mesi dopo, il giorno in cui qualcuno deve cambiare una regola e va a cercare dove quella regola è scritta.
Questo è il criterio con cui ho scelto gli strumenti di automazione aziendale che fanno girare il sito che stai leggendo, ed è diverso da quello che trovi negli elenchi dei migliori.
Gli strumenti di automazione aziendale si dividono per dove stanno scritte le regole
Gli strumenti di automazione aziendale si dividono in quattro categorie, e la cosa che le separa non è cosa sanno fare ma in che formato conservano le decisioni che qualcuno ha preso. Le funzioni si somigliano tutte, il formato no, ed è il formato a decidere chi potrà metterci mano quando chi l'ha costruita non c'è più.
Le quattro categorie, e cosa resta in mano all'azienda
| Categoria | Dove stanno le regole | Chi le può cambiare | Dove si rompe |
|---|---|---|---|
| Piattaforme visuali (Make, Zapier, n8n) | dentro l'account della piattaforma | chi ha accesso all'account | quando il flusso supera i venti passaggi e nessuno lo sa più rileggere |
| RPA | dentro un robot che ripete i clic su una schermata | chi ha la licenza e ha fatto il corso | quando il fornitore del gestionale sposta un pulsante |
| Script nel repository | in file di testo versionati, accanto al codice | chi sa leggere quei file | quando l'unica persona che li sa leggere cambia lavoro |
| Agenti | in un prompt e in un elenco di permessi | chi scrive il prompt | quando il permesso è più largo del compito |
La tabella non dice quale categoria è migliore, perché la risposta cambia con chi la deve mantenere. Dice però che la scelta è già stata fatta nel momento in cui si apre il primo account, e che quasi sempre viene fatta senza saperlo.
La categoria giusta dipende da quanto vive il processo
Un processo che vive tre mesi e poi cambia si automatizza dove si costruisce più in fretta, e va benissimo una piattaforma visuale. Un processo che vive tre anni si automatizza dove si legge meglio, perché in tre anni cambierà almeno cinque volte e almeno due di quelle volte lo cambierà qualcun altro.
La domanda che distingue i due casi si fa su un foglio, prima di aprire qualsiasi account: quante persone diverse metteranno mano a questa cosa prima che venga spenta. Se la risposta è una, il formato non conta. Se la risposta è tre, il formato conta più dello strumento.
Il criterio pratico: cosa succede quando l'automazione si ferma da sola
Un'automazione aziendale si ferma prima o poi, e il criterio di scelta più utile è quanto rumore fa mentre si ferma. È la parte che nessun confronto di funzioni misura, e conviene guardarla nella documentazione dello strumento prima di comprarlo.
La documentazione di GitHub Actions è un buon esempio di fornitore che lo scrive chiaro invece di nasconderlo. La documentazione dichiara che l'intervallo più corto con cui si può schedulare un workflow è di cinque minuti, e che l'evento schedule può subire ritardi nei periodi di carico alto. Scrive anche quali sono quei periodi: fra i momenti di carico alto c'è l'inizio di ogni ora. E aggiunge che in un repository pubblico i workflow schedulati vengono disattivati da soli quando non c'è attività per sessanta giorni. Sono righe che stanno nella documentazione degli eventi che avviano un workflow.
Quelle quattro righe valgono più di una pagina di funzionalità. Dicono che un'automazione programmata allo scoccare dell'ora partirà tardi, e dicono che può spegnersi da sola per inattività senza che nessuno riceva niente.
Le tre domande da fare al fornitore prima di firmare
Chi vende uno strumento di automazione risponde volentieri a cosa succede quando tutto funziona. Le tre domande che contano riguardano il resto: con quale ritardo massimo parte un'automazione programmata, cosa succede a un flusso a metà strada quando un servizio esterno non risponde, e in che formato si esporta la logica il giorno in cui si cambia fornitore.
La domanda sull'esportazione della logica è quella che fa cambiare espressione al venditore, perché la risposta onesta quasi sempre è che la logica non si esporta e che cambiare fornitore vuol dire riscrivere tutto.
Automazione AI: cosa cambia quando dentro il flusso decide un modello
L'automazione AI cambia una cosa sola rispetto all'automazione tradizionale, ed è che il risultato non è più prevedibile leggendo le regole. Un flusso deterministico con gli stessi dati in ingresso dà sempre la stessa uscita, e si collauda una volta. Un passaggio affidato a un modello dà uscite che variano, quindi si collauda su un campione e si sorveglia nel tempo.
Questo sposta il costo dalla costruzione alla verifica, e sposta anche il punto in cui conviene mettere il confine. La regola che uso è tenere separata la parte ripetitiva da quella che decide, così da poterle spegnere una alla volta. Sul modo di contare i costi dei due mondi ho scritto come si contano davvero i costi di n8n e Make. Sul confine fra una sequenza fissa e un agente che sceglie il passo dopo ho messo il criterio in cos'è un workflow automatizzato.
Chi sta decidendo fra un robot che ripete i clic e un modello che interpreta trova il criterio nell'articolo sulla differenza tra RPA e intelligenza artificiale. La classificazione degli stessi strumenti per grado di autonomia sta invece nelle quattro famiglie di software di intelligenza artificiale per aziende.
Come è automatizzato questo sito, e quali limiti ci ho scritto dentro
L'automazione di marcomasut.com sta dentro il repository del sito e non su nessuna piattaforma, in diciotto file .mjs dentro scripts/geo/ richiamati da dieci comandi seo: dichiarati in package.json. Non è una scelta ideologica contro le piattaforme visuali: è che questi passaggi vivono accanto al codice che pubblicano, quindi tenerli altrove avrebbe voluto dire mantenere due posti invece di uno.
La parte che conta però non sono gli script, sono i limiti scritti accanto. Il giro settimanale che corregge titoli e descrizioni ha un tetto di cinque pagine per volta e una quarantena di ventuno giorni su ogni pagina toccata. Quei due numeri non stanno in testa a nessuno: stanno nel codice come TETTO_SETTIMANALE = 5 e QUARANTENA = 21 dentro scripts/lib/storico.mjs. Il prompt della routine sta in chiaro in scripts/geo/ROUTINE-SETTIMANALE.txt, e la prima pagina di quel file spiega perché: sta lì e non solo dentro la routine "perché così si può correggere, discutere e ritrovare fra sei mesi".
I quattro numeri da scrivere prima di far partire qualsiasi automazione
Prima di accendere un'automazione aziendale scrivi quattro numeri in un file che resta, non in una chat. Quanti elementi può toccare in un giro. Quanti giorni deve aspettare prima di rimettere mano alla stessa cosa. Quante volte può ritentare quando un servizio non risponde. Dopo quanti errori consecutivi si ferma da sola invece di continuare.
Sono quattro numeri e ci vogliono dieci minuti, e sono la differenza fra un'automazione che si può lasciare accesa e una che va guardata tutti i giorni. Quando imposto progetti di automazione dei processi con l'AI per i clienti, quei quattro numeri li decidiamo prima di scegliere lo strumento, perché sono l'unica parte che poi non cambia quando lo strumento cambia. Sul modo di applicare la stessa logica a un agente che lavora da solo ho scritto i controlli in far girare Claude Code in automatico.
Gli strumenti di automazione aziendale si assomigliano molto più di quanto dicano le loro pagine di confronto. Quello che non si assomiglia è cosa resta in mano a un'azienda quando la persona che ha costruito l'automazione non c'è più, e quella differenza si decide il primo giorno.
Domande frequenti
Serve saper programmare per usare uno strumento di automazione aziendale?
Per far partire un'automazione no, per mantenerla quasi sempre sì, e le due cose vengono separate da mesi di distanza. Le piattaforme visuali sono costruite perché il primo flusso lo monti chi non scrive codice, e su quel primo flusso mantengono la promessa. Il conto arriva al decimo flusso, quando la catena ha rami, eccezioni e ritenti, e leggerla richiede le stesse capacità che richiederebbe leggere del codice, senza però gli strumenti che il codice ha per farsi leggere.
Chi risponde in azienda se un'automazione fa un errore?
Risponde chi risponde del processo, non chi ha costruito l'automazione, e conviene metterlo per iscritto prima di accendere qualsiasi cosa. Un'automazione non crea una nuova responsabilità: prende quella che c'era già e la esegue più in fretta e più volte. La domanda utile da fare in fase di progetto non è chi ha sbagliato, è quanti casi passano prima che qualcuno se ne accorga, perché quel numero è il vero costo dell'errore.
Come si cambia fornitore senza perdere le automazioni già costruite?
Si esporta la logica prima di averne bisogno, e nella maggior parte dei casi si scopre che non è esportabile. Una catena costruita dentro una piattaforma visuale si porta via come file di configurazione che solo quella piattaforma sa rileggere, quindi il cambio di fornitore è una riscrittura. Il modo per non trovarcisi è tenere fuori dalla piattaforma i pezzi che contengono la logica di business vera, lasciandole il compito per cui è brava, cioè collegare servizi.
L'automazione AI si può provare senza cambiare il gestionale?
Sì, e nella quasi totalità dei casi è il modo giusto di iniziare. Se il gestionale produce esportazioni regolari in un formato stabile, un'automazione AI può leggerle, fare il proprio lavoro e restituire un file, senza toccare il gestionale né chiedere niente al fornitore. Il gestionale diventa un problema solo quando i dati si possono leggere soltanto dentro le sue schermate, e in quel caso la prima cosa da costruire non è l'automazione ma una via d'uscita ai dati.