Non tutto quello che si può automatizzare va automatizzato con l’AI. E la microapp, che di questi tempi sembra la risposta a qualsiasi problema di ufficio, in quattro situazioni è la risposta sbagliata.
Meglio conoscerle prima di costruire.
Quando il compito è davvero sempre uguale
Se l’input ha sempre la stessa forma e l’output si ricava con una regola, non serve un modello linguistico. Serve una formula, una macro, un flusso di automazione classico.
Non perché quelle non sbaglino: sbagliano eccome, e in silenzio. La differenza è che sbagliano sempre allo stesso modo, quindi un errore lo trovi una volta e lo correggi una volta. Un modello che interpreta può rispondere bene oggi e male domani sullo stesso input, e quello rileggendo non lo becchi.
Il criterio è secco: se sai scrivere le istruzioni complete per fare quel lavoro senza usare la parola “dipende”, allora è una regola. Le regole si scrivono, non si delegano a un modello.
Quando l’errore non è recuperabile
Le microapp sbagliano. Non in modo evidente, ma sbagliano.
Il punto non è la percentuale di errore: è cosa succede quando capita. Se l’output passa sotto gli occhi di qualcuno prima di produrre effetti, l’errore si intercetta. Se parte da solo verso un cliente o verso un ordine di produzione, diventa un danno.
La domanda non è “quanto è affidabile”, ma “cosa succede la volta che sbaglia”. Se la risposta fa paura, fra lo strumento e l’effetto ci vuole una persona.
Ed è qui che il caso si chiude: se controllare costa quasi quanto fare il lavoro a mano, la microapp non risolve niente. Sposta la fatica da chi eseguiva a chi controlla.
Quando il processo sta per cambiare
Se fra tre mesi cambia il gestionale, o si sta rivedendo il flusso di approvazione, aspetta. Che un processo instabile sia un cattivo candidato vale per qualsiasi automazione, e sta in come capire se un processo aziendale è automatizzabile con l’AI. Qui il punto è più stretto.
Il rischio vero non è sprecare il tempo di costruzione. È che lo strumento, una volta fatto, diventi un argomento per non cambiare più niente. Si smette di vedere il processo come rivedibile, perché adesso c’è una cosa costruita sopra.
Quando il problema non è il tempo, è il processo
Questa è la più difficile da vedere dall’interno.
Mettiamo che qualcuno passi un paio d’ore al giorno a ricopiare dati fra due sistemi. Sembra il candidato perfetto. Ma la domanda a monte è: perché quei due sistemi non si parlano? A volte nessuno ha mai chiesto al fornitore se esiste un’integrazione. A volte quei dati non dovrebbero proprio esistere in due posti.
Automatizzare un passaggio che non dovrebbe esistere lo rende permanente. Smette di fare male, quindi smette di essere un problema, e resta lì per anni.
È la differenza con il primo caso: lì il problema era giusto e lo strumento sbagliato, qui è il problema a non doverci essere. Prima ci si chiede se il passaggio deve esistere, poi si sceglie con cosa risolverlo.
Prima di costruire il ponte, conviene chiedersi se il fiume è nel posto giusto.
Cosa fare invece
In tre casi su quattro la risposta non è “niente”, è “un’altra cosa”. Compito sempre uguale: automazione classica, senza AI. Errore non recuperabile: lo strumento si costruisce, ma come supporto a una decisione umana. Problema di processo: si guarda il processo, che è il lavoro meno gratificante e quasi sempre quello che ripaga di più.
Solo nel caso del processo che sta per cambiare la risposta giusta è aspettare.
Come si riconosce il caso buono
Per contrasto, un problema adatto ha quattro caratteristiche insieme: input variabile nella forma ma costante nella sostanza, output che passa sotto gli occhi di qualcuno prima di avere effetti, processo stabile, e un passaggio che ha senso esista.
Quando ne manca una, la microapp non è la risposta.
Per la distinzione fra automazione classica e AI, che risolve il primo dei quattro casi, cos’è l’automazione aziendale e quando ha senso usarla in una piccola impresa.
La tecnologia più utile è quella che non costruisci, perché ti sei accorto in tempo che il problema era un altro.
