Automatizzare un processo ti sembra un salto nel vuoto?

Automatizzare un processo parte dal lavoro che fate già

Automatizzare un processo, in una piccola o media impresa, vuol dire prendere un lavoro che oggi una persona svolge al computer e farlo eseguire dal software nella parte che si ripete. Non significa comprare uno strumento e sperare che dialoghi con gestionale, posta e fogli. Si parte da come il lavoro avviene: chi lo fa, quali dati usa, dove si blocca e cosa non può andare storto. Il primo risultato utile è una fetta piccola del problema, abbastanza chiara da andare in produzione e da giudicare sul campo.

In molte PMI il rallentamento sta nei passaggi di mano. Un dato nasce in un messaggio, viene ricopiato in un foglio, poi nel gestionale, poi in un documento. Ogni copia è un punto in cui manca un campo o un prezzo non coincide con ciò che la persona ha davanti. Chi guarda da fuori vede il ritardo. Chi esegue il lavoro sa che il tempo se ne va a cercare e riscrivere. Partire dallo strumento, senza questi passaggi, sposta il caos in un software che non conosce le eccezioni.

Quel lavoro lento che tutti vedono e nessuno sistema

Si riconosce perché il tempo se ne va in copie e correzioni, mentre i passaggi non sono scritti da nessuna parte.

Succede in ufficio commerciale, in amministrazione, in chi prepara documenti per i clienti. Il lavoro fa perdere il pomeriggio, eppure vive nella testa di poche persone e in fogli che non usano lo stesso nome per la stessa cosa. Chi è esperto salta delle fasi a memoria. Chi è nuovo chiede a chi è libero. Il risultato cambia a seconda di chi c'è. Se si automatizza questa versione muta, il software rende obbligatoria l'abitudine di una sola persona.

Chi ripete gli stessi passaggi ogni settimana

Chi ricopia le stesse voci, controlla gli stessi campi e invia lo stesso tipo di documento ha già un candidato sotto gli occhi. La ripetizione conta più della complessità. Un passaggio noioso e stabile si presta a essere eseguito dal software. Un passaggio raro, pieno di giudizi, no. La domanda utile non è quale tecnologia sia di moda. È quale gesto, se tolto dalle mani, libera attenzione senza togliere il controllo sulle eccezioni.

Chi non ha nessuno che tenga i sistemi

Molte PMI non hanno un responsabile dei sistemi. Il gestionale lo conosce chi lo usa, la posta la segue chi risponde ai clienti, i fogli li tiene chi chiude il mese. Si può partire lo stesso, se c'è una persona che conosce il lavoro e può dire come si fa davvero. Manca spesso un perimetro, non un reparto interno. Il tema è lo stesso di chi vuole automazione dei processi senza un responsabile IT.

Tre domande per capire da dove iniziare con l'automazione

Da dove iniziare con l'automazione si decide sul lavoro che si ripete, sui dati già disponibili e sull'errore che si vede tardi.

La prima fetta deve valere lo sforzo, avere regole abbastanza stabili e rendere visibile uno sbaglio. Se manca una di queste condizioni, si ottiene una prova che il lunedì nessuno apre. L'automazione dei processi in una PMI parte meglio da un passaggio stretto che da un ridisegno dell'intero ufficio.

1. Si ripete ogni settimana, con un inizio e una fine che tutti riconoscono?
2. I dati esistono già, anche se sono sparsi tra posta, fogli e gestionale?
3. Se il passaggio resta manuale, l'errore si scopre tardi o il tempo se ne va in copie?

Chi ricostruisce documenti copiando dati sparsi

Un preventivo, un ordine o una scheda che nasce incollando pezzi da tre posti è un segnale chiaro. Non perché quel documento sia tutto il lavoro, ma perché il percorso dei dati si può seguire. Si parte dalla richiesta e si arriva al file inviato. Dove la persona si ferma a cercare, di solito manca un campo o manca una regola. Quella sosta è il punto da cui partire, non l'intero ufficio in un colpo solo.

Mappare un processo aziendale prima di toccare il software

Si segue un caso vero accanto a chi lo esegue e si annotano attese, copie e correzioni a voce, non lo schema ideale della riunione.

Spesso il blocco non è dove sembrava. Una regola che tutti credono scritta vive solo in un messaggio vecchio. Un campo che il gestionale ha non viene usato, e un campo che serve non esiste. Mappare un processo aziendale serve a vedere questa differenza prima di scrivere codice. Altrimenti si automatizza una versione che in ufficio non esiste.

1. Chi esegue il passaggio e chi lo corregge quando qualcosa non torna.
2. Da dove arriva ogni dato e in quale sistema deve finire.
3. Quali eccezioni oggi si gestiscono a voce o per messaggio.
4. Quale azione, se sbagliata, non si può annullare da sola.
5. Quale fetta piccola può andare in produzione per prima.

Se la mappa non contiene le eccezioni, non è ancora un processo: è il racconto di una giornata andata bene.

Software su misura per PMI, scritto sul processo

Il software su misura per PMI serve quando il lavoro non coincide con il modello di uno strumento già pronto.

Uno strumento già fatto aiuta se i passaggi sono quelli previsti da chi lo ha disegnato. Se il flusso ha eccezioni, sistemi che non si parlano e conferme che solo una persona può dare, incastrare un prodotto generico sposta il lavoro manuale ai bordi. L'alternativa è scrivere il software sul processo: applicazione, dati e ambiente in cui gira, così la parte ripetitiva viene eseguita e il resto resta leggibile. È lo stesso nodo di quando uno strumento pronto inizia a frenare il lavoro.

A volte il gestionale c'è già e non va sostituito. Il limite può essere il modo in cui i dati gli arrivano, non il gestionale in sé. Cambiare tutto perché un passaggio è lento è un salto più grande del problema. Il criterio sta in quando ha senso cambiare il gestionale e quando basta collegarlo.

Cosa è cambiato nel preventivo di ERP Costruzioni

Tra i lavori documentati c'è ERP Costruzioni, costruzioni: da 8 ore a 5 click la redazione di un preventivo, in 30 giorni. È l'esito di quel progetto, non una promessa valida per ogni ufficio. Il meccanismo da guardare è un altro: il preventivo era lento perché la redazione ripeteva a mano passaggi che si potevano rendere eseguibili. La fetta era chiara, il perimetro anche, e il risultato si è potuto giudicare sul lavoro vero, non su una presentazione.

Cosa chiedere prima di partire, tra perimetro e sicurezza

Prima di partire vanno scritti il perimetro, ciò che resta alle persone e il modo in cui si conferma un'azione delicata.

Un partner utile dice anche cosa non conviene automatizzare. Un tratto che cambia ogni settimana, un giudizio che solo chi conosce il cliente può dare, un'azione che non si può annullare: meglio lasciarli fuori dal primo giro. Un software che esegue tutto, senza una persona che possa fermarlo, non toglie fatica. Sposta il rischio in un punto meno visibile.

• Cosa entra nel perimetro e cosa resta fatto a mano.
• Quali sistemi vanno collegati e quali dati mancano oggi.
• Dove serve una conferma umana prima di un'azione delicata.
• Come si osserva il sistema dopo il rilascio, e come si ripristina.
• Cosa resta nel perimetro dei dati e, se serve un modello, cosa ne esce.

Cosa non conviene automatizzare al primo giro

Non conviene partire dal processo più discusso dell'azienda, né da quello di cui non esiste nemmeno un esempio completo. Non conviene nemmeno fissare un tempo o un risparmio prima di aver visto i passaggi: sarebbero numeri vuoti. Conviene una fetta che chi lavora riconosce, che si può provare su casi reali e che, se sbaglia, si ferma prima di toccare un cliente o un documento definitivo.

Un'automazione è affidabile solo se fa i passaggi scritti nella mappa e si ferma dove la mappa chiede una persona.

Come Leomat porta in produzione la prima fetta di processo

Leomat costruisce software e ambiente su una fetta di processo che si può giudicare in produzione, dopo averla descritta con chi la esegue.

Lo studio di ingegneria software Leomat progetta applicazioni web complete e ciò che le fa funzionare: dati, interfaccia, infrastruttura, messa in produzione, sicurezza e osservazione nel tempo. Il primo confronto serve a capire i passaggi, chi li fa, dove si rompono e cosa deve restare alle persone. Se un pezzo non conviene automatizzarlo, va detto prima. Gli agenti che agiscono sui dati partono sotto supervisione: una persona osserva e corregge, e l'autonomia cresce solo dove il comportamento si dimostra affidabile. Sulle azioni delicate resta una conferma.

La sicurezza è disegnata dall'inizio, non aggiunta alla fine, sui riferimenti che lo studio applica al web e ai sistemi di intelligenza artificiale, tra cui OWASP, MITRE ATLAS e NIST AI RMF. I dati restano nel perimetro concordato. Se entra un modello, si dice cosa esce da quel perimetro e cosa no. Gli obblighi che riguardano l'azienda li valuta il suo consulente. La base è a Napoli e, per il resto d'Italia, il lavoro si fa da remoto; se l'azienda è in Campania, il primo sguardo al processo si può fare di persona. Non si danno tempi prima di aver visto il processo. Si parte da una fetta piccola e utile, che va in produzione e si giudica sul campo.

Da dove si parte per automatizzare un processo?

Si parte dal lavoro com'è oggi, non da un catalogo di strumenti. Conviene seguire chi esegue il passaggio e annotare i passi, i dati, le attese e i punti in cui qualcuno corregge a mano. Da lì si sceglie una fetta ripetitiva, con regole abbastanza stabili, e la si porta in produzione, così si può giudicare se il software fa davvero quel pezzo. Il resto resta com'è finché quella fetta non è chiara. Se un tratto non conviene automatizzarlo, è meglio dirlo prima di scrivere codice.

Quale processo conviene automatizzare per primo?

Il candidato migliore si ripete spesso, ha un inizio e una fine riconoscibili e usa dati che già esistono, anche se sono sparsi. Deve pesare se resta manuale, per il tempo che assorbe o per errori che si vedono tardi, ma non deve essere il processo più delicato. Meglio un preventivo standard o un passaggio di dati tra due sistemi che un'eccezione rara piena di giudizi. Se le regole cambiano ogni settimana, prima si stabilizzano, poi si automatizza.

Si può partire senza un responsabile dei sistemi?

Sì, se il perimetro è chiaro e in azienda c'è chi conosce il lavoro, anche senza scrivere codice. Quella persona descrive i passaggi, segnala le eccezioni e conferma le azioni che non possono partire da sole. Il partner tecnico tiene architettura, collegamenti e messa in sicurezza. Il rischio, senza un referente del processo, è automatizzare una versione ideale che in ufficio nessuno segue. Il primo confronto serve a vedere chi fa cosa oggi, non a scegliere un linguaggio.

Automazione software e automazione industriale sono la stessa cosa?

No. L'automazione industriale riguarda macchine, impianti e robot di fabbrica. L'automazione software riguarda i processi che le persone svolgono al computer: documenti, ordini, posta, cataloghi, dati che passano da un sistema all'altro. Una PMI che vuole togliere lavoro ripetitivo in ufficio ha bisogno del secondo tipo. Confondere i due porta a chiedere la cosa sbagliata. Il punto di partenza resta il processo d'ufficio, mappato com'è, con una fetta che il software può eseguire e con le conferme dove l'errore costa.

Questo post è stato realizzato con AI