Un flow chart, o diagramma di flusso, rappresenta visivamente una sequenza di attività, decisioni e possibili percorsi. Serve a rendere evidente non soltanto che cosa succede, ma anche in quale ordine, quali condizioni modificano il percorso e dove il processo può terminare, tornare indietro o prendere una direzione diversa.
La parte difficile, però, non è disegnare rettangoli, rombi e frecce.
Puoi creare un diagramma graficamente impeccabile e rappresentare comunque male il processo. Succede quando mancano passaggi reali, quando una decisione viene trattata come una semplice attività oppure quando il diagramma contiene così tanto dettaglio da diventare più difficile da leggere del processo originale.
Per questo, prima di scegliere il software, conviene capire che cosa deve mostrare il diagramma e quale decisione deve aiutarti a prendere.
In questa guida vediamo come leggere i simboli, scegliere il tipo di rappresentazione corretto, costruire il diagramma passo dopo passo e usare gli esempi di flow chart per capire dove il modello funziona davvero.
Cos’è un flow chart e a cosa serve
Un flow chart è una rappresentazione grafica di un processo, un algoritmo o una sequenza logica. Le attività vengono mostrate tramite forme, mentre linee e frecce indicano l’ordine con cui devono essere lette e le eventuali diramazioni.
La definizione sembra semplice, ma contiene già il punto essenziale: un diagramma di flusso rappresenta relazioni, non una collezione di caselle.
Se scrivi:
Richiesta ricevuta → Controllo → Approvazione
hai rappresentato una sequenza.
Se però il controllo può dare esito positivo o negativo, il modello cambia:
Richiesta ricevuta → Controllo → È completa? → sì/no
A quel punto non stai più mostrando soltanto una serie di attività. Stai rendendo esplicita una regola del processo.
È qui che il flow chart inizia ad avere un vantaggio rispetto a una normale lista.
Flow chart, flowchart e diagramma di flusso: quale termine usare
In italiano puoi incontrare flow chart, flowchart e diagramma di flusso.
Treccani registra flowchart, o flow chart, come termine inglese equivalente all’espressione italiana diagramma di flusso. Il plurale inglese è flowcharts.
Dal punto di vista pratico, quindi, non stiamo parlando di tre strumenti differenti.
In una guida italiana userei flow chart quando il contesto professionale o software rende naturale il termine inglese e diagramma di flusso quando migliora la comprensione. Alternare le due forme ha senso perché sono equivalenti; inventare sinonimi per evitare di ripetere il termine corretto, invece, rende soltanto la spiegazione meno precisa.
Quando un diagramma di flusso aiuta davvero a capire un processo
Il flow chart è utile soprattutto quando il percorso contiene almeno uno di questi elementi:
- una sequenza che deve essere rispettata;
- una decisione che modifica ciò che succede dopo;
- un’eccezione;
- un controllo;
- un ritorno a una fase precedente;
- più possibili conclusioni;
- passaggi che oggi vengono interpretati in modo diverso dalle persone coinvolte.
Immagina la gestione di una richiesta di assistenza.
Scrivere “ricezione, analisi, risposta, chiusura” dice poco.
Un flow chart può invece mostrare che, dopo l’analisi, il ticket può essere risolto direttamente, richiedere informazioni aggiuntive oppure essere trasferito a un secondo livello. Se mancano dati, il processo torna al cliente e riprende soltanto dopo la risposta.
Il diagramma rende visibile la logica che governa il lavoro.
Non significa però che ogni processo debba diventare un flow chart.
Se vuoi sapere in quale fase si trova una trattativa, può essere più utile una pipeline. Se vuoi sapere quando iniziano e finiscono attività collegate nel tempo, ti serve un’altra rappresentazione. Il modello va scelto in base alla domanda, non all’abitudine di utilizzare sempre lo stesso schema.
Quale tipo di diagramma usare per il problema che devi rappresentare
Flow chart, workflow, swimlane, BPMN, DFD e Gantt possono sembrare variazioni dello stesso concetto perché tutti utilizzano una forma visuale.
In realtà rispondono a domande differenti.
| Se devi capire… | Rappresentazione più naturale |
|---|---|
| Quali passaggi e decisioni compongono un processo? | Flow chart |
| Come cambia il percorso in base a una condizione? | Flow chart decisionale |
| Chi esegue ogni fase? | Swimlane |
| Come modellare formalmente processi business complessi? | BPMN |
| Come si muovono i dati tra processi, archivi ed entità? | DFD |
| Quando avvengono attività, durate e dipendenze temporali? | Gantt |
| In quale stato si trova un elemento? | Pipeline / board di workflow |
Questa distinzione evita un errore frequente: scegliere il diagramma in base a ciò che il software sa disegnare invece che al problema da risolvere.
Nel project management, per esempio, WBS, Kanban e Gantt possono convivere perché mostrano aspetti diversi dello stesso progetto. Non sono alternative intercambiabili.
Flow chart di processo e diagramma decisionale
Un flow chart di processo mette al centro la successione delle attività.
Può descrivere, per esempio:
Richiesta ordine → controllo disponibilità → preparazione → spedizione → chiusura
Se però ciò che conta sono le condizioni che modificano il percorso, il diagramma assume una funzione più decisionale:
Prodotto disponibile?
- sì → prepara ordine;
- no → verifica riordino;
- riordino possibile → comunica nuova data;
- riordino impossibile → annulla o proponi alternativa.
In entrambi i casi stai utilizzando un flow chart. Cambia però dove si concentra l’informazione.
Nel primo caso vuoi rendere evidente la sequenza.
Nel secondo vuoi rendere esplicite le regole.
Workflow e swimlane quando contano attività e responsabilità
Il termine workflow indica in senso ampio il flusso di lavoro: attività, stati, condizioni e passaggi che portano un lavoro dall’inizio alla fine.
Un flow chart può rappresentare quel workflow, ma i due termini non sono sinonimi perfetti. Il workflow è il processo operativo; il flow chart è uno dei modi con cui puoi rappresentarlo.
La distinzione diventa ancora più chiara quando entrano in gioco le responsabilità.
Immagina un ordine che passa da commerciale, amministrazione e magazzino.
Un diagramma tradizionale può mostrare perfettamente l’ordine dei passaggi. Se il problema principale è capire chi deve fare cosa, una struttura a swimlane diventa più informativa perché assegna ogni attività a una corsia relativa al ruolo, al reparto o al sistema responsabile.
Il flusso rimane leggibile, ma aggiungi una seconda dimensione: non soltanto cosa viene dopo, ma anche chi ne risponde.
Quando servono invece BPMN, DFD o un diagramma di Gantt
BPMN diventa utile quando vuoi descrivere processi business con una notazione più formale e con elementi capaci di rappresentare eventi, attività, gateway e interazioni con maggiore precisione.
Un DFD, o data flow diagram, cambia ancora prospettiva: mette al centro il movimento dei dati tra processi, archivi e soggetti esterni. Non nasce per spiegare semplicemente “quale attività viene dopo”.
Il diagramma di Gantt risponde invece a una domanda temporale: quando avviene il lavoro, quanto dura e da quali attività dipende.
Un modo semplice per scegliere è questo:
se la domanda contiene soprattutto “cosa succede dopo?” pensa al flow chart; se contiene “chi?”, valuta una swimlane; se contiene “quando?”, guarda al Gantt; se contiene “dove vanno i dati?”, valuta un DFD.
Non è una classificazione rigida, ma impedisce di partire dallo strumento sbagliato.
Simboli del diagramma di flusso: quali servono e cosa significano
La simbologia dei flow chart può diventare molto ampia, ma per costruire un diagramma comprensibile non devi utilizzare ogni forma disponibile nel software.
In molti casi bastano pochi elementi usati con coerenza.
| Simbolo | Forma tipica | Significato |
|---|---|---|
| Inizio / fine | ovale o rettangolo arrotondato | punto di ingresso o uscita dal processo |
| Processo | rettangolo | attività o operazione |
| Decisione | rombo | condizione che produce percorsi differenti |
| Input / output | parallelogramma | informazione o materiale che entra o esce |
| Flusso | freccia | direzione del percorso |
| Documento | rettangolo con base ondulata | documento prodotto o utilizzato |
| Connettore | piccolo cerchio | collegamento fra parti distanti dello schema |
| Sottoprocesso | rettangolo con marcature laterali | processo descritto altrove o sviluppato separatamente |
Lucidchart utilizza la stessa famiglia di simboli di base nelle proprie guide alla creazione dei diagrammi di flusso.
Inizio e fine, processo, decisione, input/output e frecce
Questi sono gli elementi da capire prima degli altri.
Inizio e fine delimitano il processo. Possono sembrare superflui in un diagramma minuscolo, ma diventano importanti appena il flusso può avere più punti di uscita.
Il rettangolo di processo descrive un’azione.
“Controlla il pagamento”, “invia il preventivo” e “aggiorna il CRM” sono attività.
Il rombo descrive invece una domanda o condizione.
“Pagamento ricevuto?” non è un’attività. È un punto in cui il percorso può cambiare.
Questa differenza è fondamentale.
Se rappresenti tutte le attività e tutte le condizioni con lo stesso rettangolo, il diagramma può essere ancora leggibile, ma perdi una parte importante della sua grammatica visuale.
Le frecce completano la logica. Nei rami decisionali conviene indicare chiaramente il significato dell’uscita — per esempio sì/no, approvato/rifiutato oppure disponibile/non disponibile — invece di obbligare chi legge a dedurlo dalla posizione delle linee.
Documento, dati, connettori e sottoprocessi
I simboli secondari diventano utili quando aggiungono informazione che cambierebbe davvero la lettura.
Se un passaggio genera un contratto, una fattura o un report, il simbolo documento può rendere immediatamente riconoscibile l’output.
Se un processo riceve o produce dati, distinguere input e output può aiutare soprattutto in contesti tecnici.
I connettori evitano invece di trascinare frecce per tutta la pagina. Sono utili quando il diagramma è abbastanza grande da richiedere più aree, ma possono diventare un segnale di allarme: se devi riempire la pagina di connettori per riuscire a seguire il percorso, forse il problema non è il layout. Potresti aver messo troppo processo nello stesso diagramma.
Il sottoprocesso risolve proprio questo problema.
Puoi mantenere nel flow chart principale un blocco come “Verifica antifrode” e sviluppare quella procedura in un diagramma separato, invece di inserire venti passaggi nel flusso generale.
Simboli standard e ISO 5807: cosa significa davvero “standard”
Dire che un simbolo è “standard” richiede un po’ più di precisione che copiare la libreria di forme del proprio software.
ISO 5807 definisce simboli e convenzioni per la documentazione di flowchart relativi a dati, programmi e sistemi.
Questo non significa che ogni diagramma aziendale debba trasformarsi in un esercizio di conformità formale.
Per molti processi interni conta soprattutto che la notazione sia:
- comprensibile;
- coerente;
- spiegata quando utilizza simboli meno comuni;
- interpretata nello stesso modo da chi deve lavorarci.
La conseguenza pratica è semplice: usa pochi simboli correttamente prima di usare molti simboli soltanto perché il software li mette a disposizione.
Come creare un flow chart passo dopo passo
Se stai cercando come fare un flow chart, partire direttamente dal software è quasi sempre troppo presto.
Prima devi costruire il modello.
Disegnare viene dopo.
Definisci scopo, punto di partenza e risultato
Completa prima una frase:
Questo diagramma deve aiutare a capire…
“Il processo ordini” è ancora troppo generico.
“Come gestiamo un ordine dal pagamento alla spedizione, compresi i casi in cui il prodotto non è disponibile” è già molto più utile.
Hai definito:
- l’oggetto;
- il punto di ingresso;
- il risultato;
- una delle eccezioni che il diagramma dovrà gestire.
Poi stabilisci dove inizia e dove può terminare il processo.
Un diagramma senza confini tende a espandersi continuamente: per spiegare un ordine inizi a rappresentare il marketing, poi il CRM, poi l’assistenza, poi la contabilità. Alla fine non hai più un flow chart operativo, ma una mappa indistinta dell’azienda.
Elenca attività, decisioni, eccezioni e loop
Prima delle forme, scrivi gli elementi in linguaggio normale.
Per esempio:
Ricevi ordine
Verifica pagamento
Pagamento ricevuto?
Controlla disponibilità
Prodotto disponibile?
Prepara ordine
Spedisci
Comunica indisponibilità
Attendi decisione cliente
Ora separa azioni e domande.
Le domande sono candidate naturali per i rombi decisionali.
Poi cerca le eccezioni.
Cosa succede se il pagamento fallisce?
Cosa succede se manca un prodotto?
Cosa succede se il cliente sceglie di aspettare?
Infine cerca i ritorni.
Se il cliente aggiorna i dati, il processo riparte da quale controllo?
Queste domande fanno emergere la struttura prima ancora di aprire il programma di diagrammazione.
Scegli il livello di dettaglio prima di disegnare
Più dettagli non significano automaticamente più chiarezza.
“Prepara ordine” potrebbe essere sufficiente in un diagramma destinato al responsabile commerciale.
Per chi lavora in magazzino, la stessa attività potrebbe dover diventare:
genera picking → preleva articoli → controlla quantità → imballa → stampa etichetta → consegna al corriere
Entrambe le rappresentazioni possono essere corrette.
Rispondono semplicemente a domande diverse.
Una regola utile consiste nel creare un nuovo passaggio quando accade almeno una di queste cose:
- cambia la decisione da prendere;
- cambia il responsabile;
- cambia lo stato dell’elemento;
- entra o esce un’informazione importante;
- può verificarsi un errore o un’eccezione;
- il passaggio deve essere verificato separatamente.
Se invece stai dividendo un’attività soltanto per raccontare ogni micro-movimento, probabilmente stai aggiungendo rumore.
Assegna i simboli e collega tutti i percorsi
A questo punto puoi passare alle forme.
Assegna un rettangolo alle attività, un rombo alle decisioni e collega il percorso principale.
Poi verifica ogni rombo.
Se hai una domanda, dovresti poter spiegare dove portano le possibili risposte.
Un errore classico è questo:
Controllo dati → Dati corretti? → Continua
Manca il secondo ramo.
Che cosa succede quando i dati non sono corretti?
Un altro errore è creare un percorso che finisce senza un motivo. Ogni ramo dovrebbe raggiungere una conclusione, rientrare nel flusso oppure puntare chiaramente a un sottoprocesso.
Quando devi incrociare continuamente le linee per ottenere questo risultato, prova prima a riorganizzare il flusso. Una disposizione ordinata dall’alto verso il basso o da sinistra verso destra riduce lo sforzo necessario per seguirlo.
Verifica e semplifica il flow chart con chi conosce il processo
Un diagramma non è validato perché sembra plausibile.
Confrontalo con chi esegue realmente il lavoro.
La domanda più utile non è:
“Ti piace questo schema?”
È:
“Se seguissimo esattamente questo percorso, manca qualcosa?”
Poi usa casi reali o realistici.
Prendi un ordine normale, uno incompleto e uno che richiede un’eccezione. Percorri il diagramma come se fosse una procedura.
Se a un certo punto devi dire “qui normalmente facciamo anche questa cosa, anche se non è scritta”, hai trovato un gap.
Se invece compare una fase che nessuno esegue realmente, hai trovato un altro problema: il diagramma sta documentando il processo ideale, non quello effettivo.
Entrambi possono essere utili, ma non vanno confusi.
Il primo descrive as is: come funziona oggi.
Il secondo può descrivere to be: come vuoi che funzioni.
Flow chart: esempi dalla logica semplice ai processi aziendali
Gli esempi di flow chart diventano realmente utili quando ogni esempio chiarisce un problema diverso.
Vedere tre diagrammi che cambiano soltanto il nome delle caselle insegna poco.
Conviene passare da una decisione elementare a un processo con eccezioni e infine confrontare due livelli di dettaglio dello stesso flusso.
Esempio 1: un flusso semplice con una decisione
Immagina un modulo di contatto.
Il processo può essere:
Richiesta ricevuta → Dati completi?
Se sì:
Dati completi → Assegna la richiesta → Fine
Se no:
Dati incompleti → Chiedi integrazione → Ricevi nuovi dati → Controlla di nuovo
Questo esempio contiene già quattro elementi importanti:
- un inizio;
- un’attività;
- una decisione;
- un loop.
Il ritorno al controllo è ciò che una lista lineare mostrerebbe peggio.
Scrivere semplicemente “se mancano informazioni, richiederle” comunica la regola; il flow chart rende evidente dove il processo torna dopo aver ricevuto la risposta.
Esempio 2: un processo aziendale con eccezione e ritorno
Prendiamo l’approvazione di un acquisto interno.
Richiesta → Verifica budget → Budget disponibile?
Se sì:
Invia al responsabile → Approvato?
- sì → Esegui acquisto → Registra ordine → Fine;
- no → Comunica rifiuto → Fine.
Se il budget non è disponibile:
Richiedi revisione → Importo modificato? → sì → torna a Verifica budget; no → Fine.
Qui il diagramma non serve soltanto a documentare una sequenza.
Fa emergere domande organizzative.
Chi può modificare l’importo?
Una richiesta respinta può essere ripresentata?
Esiste una soglia oltre la quale cambia il responsabile dell’approvazione?
Il valore dei flow chart per i processi aziendali sta spesso proprio qui: disegnare il flusso rende visibili regole che nella descrizione verbale venivano date per scontate.
Esempio 3: lo stesso processo ad alto livello e in dettaglio
Consideriamo la pubblicazione di un articolo.
A livello alto:
Idea → Produzione → Revisione → Pubblicazione
È perfettamente leggibile e può bastare per una panoramica.
Un livello operativo può invece diventare:
Idea → Valutazione → Brief → Ricerca → Stesura → Revisione → Approvato?
- no → modifica → nuova revisione;
- sì → pubblicazione.
Nessuno dei due diagrammi è “più corretto” in assoluto.
Il primo è migliore se vuoi spiegare il sistema in pochi secondi.
Il secondo è migliore se devi governare il lavoro.
Questo criterio è più utile del chiedersi quanti box debba avere un buon flow chart: il livello di dettaglio deve seguire la decisione che il lettore deve prendere.
Gli errori che rendono un flow chart difficile da usare
I problemi dei diagrammi di flusso raramente derivano dalla mancanza di forme sofisticate.
Più spesso nascono da un modello sbagliato, ambiguo o troppo denso.
Inserire troppo dettaglio in un unico diagramma
Il primo segnale è visivo: devi ridurre il carattere, allargare continuamente l’area di lavoro e aggiungere linee che attraversano mezza pagina.
Ma il problema è concettuale.
Probabilmente stai tentando di rispondere contemporaneamente a domande di livello diverso.
Un responsabile può avere bisogno di sapere che esiste una fase “Controllo qualità”. La persona incaricata del controllo deve invece conoscere i test che compongono quella fase.
Mettere entrambe le prospettive nello stesso diagramma penalizza tutti.
Meglio mantenere il processo principale leggibile e trasformare i dettagli in sottoprocessi quando servono davvero.
Lasciare decisioni, eccezioni e percorsi senza una logica chiara
Un rombo con due frecce non è automaticamente una decisione ben descritta.
La domanda deve essere verificabile e i rami devono avere un significato riconoscibile.
“Valuta richiesta” è un’attività.
“Richiesta completa?” è una decisione.
“Richiesta buona?” è probabilmente troppo vaga, perché non definisce il criterio.
Lo stesso vale per le uscite.
Etichette come sì/no funzionano quando la domanda è binaria e chiara. Quando i risultati possibili sono più articolati, nominarli esplicitamente riduce l’ambiguità.
Disegnare bene un processo che nella realtà funziona diversamente
È l’errore più importante.
Un diagramma può essere formalmente corretto, elegante e coerente e descrivere una procedura che nessuno segue.
Succede spesso quando il processo viene disegnato partendo dalle policy anziché osservando il lavoro.
Il commerciale dice che invia sempre tutti i dati.
L’amministrazione spiega che metà delle richieste arriva incompleta e viene corretta via email.
Il flow chart ufficiale mostra un percorso lineare perché nessuno ha rappresentato l’eccezione.
In quel caso l’eccezione non è marginale: è parte del processo reale.
Prima documenta ciò che succede.
Poi, se vuoi migliorarlo, crea una seconda versione e rendi esplicite le differenze fra stato attuale e processo desiderato.
Con quali strumenti creare un flow chart
Per creare un diagramma semplice non serve necessariamente un software specializzato.
La scelta cambia quando aumentano complessità, collaborazione e frequenza degli aggiornamenti.
Office e strumenti generalisti per diagrammi semplici
Per una rappresentazione occasionale puoi utilizzare gli strumenti che hai già.
Microsoft documenta la creazione di diagrammi di flusso tramite SmartArt nelle applicazioni Office e offre in Visio funzioni specifiche per collegare forme e rappresentare processi più strutturati.
SmartArt può bastare quando devi mostrare una sequenza semplice all’interno di un documento o di una presentazione.
Visio ha più senso quando il diagramma stesso diventa un artefatto da costruire e mantenere.
La distinzione non è “strumento semplice contro strumento professionale”.
È più concreta: quanto è importante modificare rapidamente nodi, connessioni e diramazioni senza dover ricostruire il layout ogni volta?
Tool collaborativi quando il processo deve essere condiviso e aggiornato
Quando più persone devono discutere, modificare e commentare lo stesso processo, una lavagna o un diagramming tool collaborativo riduce l’attrito.
Lucidchart mette a disposizione template e librerie di forme dedicate ai flow chart. Miro combina diagrammazione e spazio collaborativo.
Il criterio più importante non è però la quantità di template.
Chiediti cosa succede dopo aver creato il diagramma.
Se deve essere discusso da un team, modificato spesso e utilizzato durante workshop, la collaborazione pesa molto.
Se il processo deve diventare gestione quotidiana delle attività, potresti invece aver bisogno di un sistema che rappresenti lo stato del lavoro, come Trello, anziché di un diagramma statico sempre più complesso.
Il flow chart definisce bene la logica.
Il task manager governa il lavoro mentre quella logica viene eseguita.
AI e text-to-flowchart: utili per la bozza, non per validare il processo
Un cambiamento interessante negli strumenti di diagrammazione è la possibilità di partire da una descrizione testuale.
Miro AI può generare un diagramma a partire da un prompt, mentre Napkin AI trasforma passaggi o documenti di processo in un flow chart modificabile.
È un buon modo per eliminare la tela vuota.
Non elimina però il problema più difficile.
Se scrivi:
Ricevi ordine, verifica pagamento, prepara e spedisci.
il sistema può trasformare correttamente quella descrizione in un diagramma.
Ma non può sapere, dalla frase da sola, che cosa dovrebbe succedere quando il pagamento fallisce, il prodotto manca, l’indirizzo è errato o l’ordine viene annullato dopo la preparazione.
Può visualizzare la logica che gli fornisci.
Non dimostra che quella logica rappresenti correttamente la realtà.
Per questo userei l’AI soprattutto per produrre una prima bozza, riorganizzare uno schema già descritto o velocizzare il layout. La validazione dovrebbe restare un lavoro sul processo: persone coinvolte, casi reali, eccezioni e responsabilità.
Conclusione
Un buon flow chart non è quello con più simboli e nemmeno quello realizzato con il software più sofisticato.
È quello che rende visibile la logica necessaria per capire o eseguire un processo.
Parti quindi dalla domanda che il diagramma deve risolvere. Individua attività, decisioni, eccezioni e ritorni. Scegli un livello di dettaglio coerente con chi lo userà e soltanto dopo passa alle forme e allo strumento.
Se il diagramma cresce fino a diventare difficile da seguire, non cercare subito una tela più grande: verifica se stai mescolando più livelli o più problemi nello stesso schema.
E quando il flow chart sembra completo, fai l’ultimo controllo sul processo reale. Una freccia mancante si corregge in pochi secondi. Una regola sbagliata rappresentata con grande precisione resta una regola sbagliata.