Articoli

Quando un'azienda decide di «automatizzare», il rischio più comune non è sbagliare strumento. È automatizzare l'attività sbagliata, oppure quella giusta senza aver deciso cosa deve succedere quando qualcosa va storto. Un flusso automatico mal progettato lavora velocemente anche quando sbaglia, e può farlo per settimane prima che qualcuno se ne accorga.

Scegliere la prima attività

Una buona candidata per la prima automazione ha quattro caratteristiche: si ripete spesso, segue regole che si possono scrivere in poche righe, oggi richiede di copiare dati tra due sistemi e, se si inceppa, il danno è limitato. La generazione automatica di una bozza di preventivo da un modulo web soddisfa di solito tutte e quattro; la gestione dei pagamenti ai fornitori quasi mai, perché un errore costa caro.

Un esercizio utile: elencare le attività ripetitive di una settimana con frequenza e minuti impiegati. Le attività in cima alla lista per tempo totale, ma in fondo per rischio, sono il punto di partenza.

Scrivere le regole prima di toccare lo strumento

Prima di aprire qualsiasi piattaforma di automazione conviene descrivere il flusso a parole:

• evento iniziale: cosa avvia il flusso (un modulo inviato, un ordine creato, una data raggiunta);
• dati necessari: quali campi servono e da quale sistema arrivano;
• regole: le condizioni che decidono il percorso, scritte come frasi «se… allora…»;
• risultato: cosa deve esistere alla fine (un documento, un record, una notifica);
• eccezioni: cosa succede se un dato manca o un sistema non risponde.

Se le regole non si riescono a scrivere, il problema non è tecnico: il processo non è ancora abbastanza definito per essere automatizzato.

Mantenere il controllo

Tre accorgimenti evitano la maggior parte delle sorprese. Il primo è un responsabile nominato per ogni automazione, che riceve gli errori e sa come intervenire. Il secondo è un registro leggibile delle esecuzioni, anche solo un foglio aggiornato dal flusso stesso, con data, esito e riferimento del dato elaborato. Il terzo è una verifica a campione nelle prime settimane: qualcuno controlla manualmente una parte dei risultati e li confronta con quello che avrebbe fatto a mano.

Va previsto anche come spegnere il flusso. Se un fornitore cambia formato dei file o un campo viene rinominato, deve essere possibile sospendere l'automazione e tornare temporaneamente alla procedura manuale, documentata.

Quando fermarsi

Non ogni attività ripetitiva merita un'automazione. Se l'attività richiede valutazione, cambia spesso o capita poche volte al mese, un buon modello di documento o una regola interna più chiara possono dare lo stesso beneficio con meno manutenzione. Automatizzare ha un costo continuo: ogni flusso è un piccolo software da mantenere.

Per approfondire come si individuano queste attività in un'analisi strutturata, vedi la pagina Riduzione delle operazioni ripetitive.

Una demo di software è costruita per mostrare il prodotto nel suo momento migliore: dati di esempio puliti, flussi lineari, nessuna eccezione. Le domande che seguono servono a riportare la conversazione sul vostro caso. Conviene inviarle al fornitore prima dell'incontro e chiedere che la dimostrazione risponda usando un esempio vostro.

Le domande sul lavoro quotidiano

1. Potete mostrarci il nostro processo più frequente, dall'inizio alla fine? Portate un caso reale, per esempio un ordine con uno sconto particolare e una consegna parziale.
2. Cosa succede quando un dato è sbagliato a metà del processo? Come si corregge una fattura già emessa, un ordine già evaso, un'anagrafica duplicata.
3. Quali operazioni richiedono un intervento del fornitore? Aggiungere un campo, modificare un modello di documento, creare un nuovo utente: quali si fanno in autonomia e quali a pagamento.

Le domande sui dati

4. Come importiamo i dati che abbiamo oggi? Chiedete chi si occupa della migrazione, in quale formato vanno preparati i dati e quanto tempo richiede una prova.
5. Come esportiamo tutti i nostri dati, in qualsiasi momento? Formato, completezza e costo dell'esportazione sono la vostra garanzia di poter cambiare in futuro.
6. Dove sono conservati i dati e chi può accedervi? Sede dei server, sub-responsabili del trattamento e accordo sul trattamento dei dati ai sensi del GDPR.

Le domande sulle integrazioni

7. Con quali sistemi esiste un collegamento già pronto? Verificate quelli che usate davvero: e-commerce, banca, fatturazione elettronica, CRM.
8. Esiste un'interfaccia API documentata e pubblica? Chiedete il link alla documentazione: se non esiste o non è accessibile, le integrazioni future saranno difficili.

Le domande sul contratto

9. Come cambia il prezzo se crescono utenti, documenti o sedi? Fatevi indicare il costo per lo scenario di oggi e per uno scenario con il doppio degli utenti.
10. Come si esce dal contratto? Preavviso, durata minima, cosa succede ai dati alla scadenza e per quanto tempo restano disponibili.

Dopo la demo

Annotate le risposte in una tabella uguale per tutti i fornitori, con una colonna per le risposte vaghe o rinviate. Una risposta «lo verifichiamo e vi facciamo sapere» non è necessariamente negativa, ma va chiusa per iscritto prima della firma. Confrontate infine il costo complessivo su tre anni, compresi migrazione, formazione e personalizzazioni, non solo il canone mensile.

Il nostro servizio di consulenza nella scelta del software segue esattamente questo schema, con uno scenario di prova preparato sui vostri dati.

In molte aziende il collegamento tra e-commerce, gestionale, CRM e contabilità è una persona: qualcuno che ogni mattina esporta gli ordini, li reinserisce e aggiorna il magazzino. Funziona finché quella persona è presente e i volumi sono bassi. Esistono tre modi principali per sostituire questo lavoro, ognuno con vantaggi e limiti precisi.

Interfacce API

Un'API è un canale con cui un programma permette ad altri programmi di leggere o scrivere dati secondo regole documentate. È il metodo più flessibile: lo scambio può avvenire in tempo reale e riguardare esattamente i dati necessari. Richiede però competenze di sviluppo, un ambiente in cui far girare il codice di integrazione e qualcuno che lo mantenga quando una delle due piattaforme cambia versione.

È la scelta giusta quando i volumi sono alti, i dati devono essere aggiornati in pochi minuti o le regole di trasformazione sono complesse.

Connettori pronti

Molti software offrono collegamenti già pronti con le piattaforme più diffuse, oppure si appoggiano a servizi di integrazione che permettono di configurare flussi senza scrivere codice. Si attivano in fretta e costano poco all'inizio. Il limite è che fanno ciò per cui sono stati progettati: se il vostro processo richiede un passaggio particolare, il connettore potrebbe non prevederlo, e le personalizzazioni diventano presto fragili.

È la scelta giusta quando il processo è standard e i due sistemi sono tra quelli supportati ufficialmente.

File di scambio programmati

Un sistema esporta periodicamente un file, per esempio CSV o XML, in una cartella condivisa; l'altro lo importa a orari stabiliti. È il metodo più vecchio e meno elegante, ma anche il più robusto con software datati che non hanno API. I dati non sono in tempo reale e servono controlli per gestire file incompleti o importati due volte.

È la scelta giusta per sincronizzazioni notturne, listini, giacenze aggiornate una o due volte al giorno.

Un criterio per scegliere

Per ogni coppia di sistemi conviene rispondere a quattro domande:

• ogni quanto deve essere aggiornato il dato perché il lavoro funzioni?
• quanti record vengono scambiati in un giorno normale e in un giorno di picco?
• chi in azienda o tra i fornitori sarà responsabile del collegamento tra un anno?
• quale dei due sistemi è la fonte ufficiale del dato in caso di differenze?

L'ultima domanda è la più trascurata. Se cliente e prezzo possono essere modificati in entrambi i sistemi, prima o poi esisteranno due versioni diverse. Decidere quale prevale, e impedire le modifiche nell'altro, vale più della scelta della tecnologia.

Approfondisci l'approccio nella pagina Integrazione degli strumenti digitali.

In una piccola o media impresa la «strategia IT» spesso non esiste come documento: esiste una lista di problemi, qualche abbonamento da rinnovare e un progetto grande rinviato da anni. Un piano su dodici mesi serve a trasformare questa lista in decisioni con un ordine, un responsabile e una verifica. Non deve essere lungo: due o tre pagine bastano, se sono aggiornate.

Partire da un inventario onesto

Il primo passo è sapere cosa c'è. Un inventario minimo comprende i programmi in uso con il loro costo annuale e il referente interno, i dispositivi principali con età indicativa, dove sono conservati i dati importanti e come vengono salvati. Spesso l'inventario stesso rivela abbonamenti duplicati, licenze intestate a persone che non lavorano più in azienda o dati critici salvati su un solo computer.

Trasformare i problemi in obiettivi

«Il gestionale è lento» è un problema; «ridurre il tempo di inserimento di un ordine» è un obiettivo. Per ogni voce della lista conviene scrivere quale risultato si vuole ottenere e come lo si riconoscerà. Gli obiettivi che non si riescono a descrivere così vanno chiariti prima di investire.

Dividere l'anno in quattro trimestri

• Primo trimestre — sicurezza e basi: copie di sicurezza verificate, accessi e password, aggiornamenti, inventario completo.
• Secondo trimestre — interventi rapidi: configurazioni mancanti, licenze inutilizzate, modelli di documento, piccole automazioni a basso rischio.
• Terzo trimestre — un progetto strutturato: un'integrazione tra due sistemi o la scelta di un nuovo software, uno solo alla volta.
• Quarto trimestre — verifica e budget: misura dei risultati, revisione della lista, preventivo per l'anno successivo.

La sequenza non è obbligatoria, ma ha una logica: senza basi solide i progetti successivi poggiano su sistemi fragili, e senza interventi rapidi il piano perde credibilità all'interno dell'azienda.

Responsabili e verifiche

Ogni voce del piano ha un nome accanto: non necessariamente un tecnico, ma qualcuno che si assicura che l'attività venga svolta e che ne riferisce. Una riunione breve ogni mese, con lo stato di ciascuna voce, è sufficiente per mantenere il piano vivo. Quando una voce resta ferma per due mesi va discussa: forse non era una priorità, forse mancano risorse.

Cosa lasciare fuori

Un piano realistico dice anche cosa non si farà quest'anno. Scriverlo evita che ogni nuova idea diventi urgente e protegge il progetto principale. Le voci escluse non spariscono: tornano nella revisione del quarto trimestre.

Se vuoi un punto di partenza strutturato, la fase di analisi dei processi produce proprio l'inventario e la lista di criticità da cui costruire il piano.