In sintesi
Per una piccola azienda di trasporto il gestionale migliore non è quello con più funzioni. È quello che viene usato tutti i giorni, riduce passaggi manuali e rimane comprensibile quando il titolare non è davanti al computer.
Una scelta sbagliata può fallire in due modi:
- software troppo semplice, che dopo pochi mesi torna a essere affiancato da Excel e WhatsApp;
- software troppo complesso, che richiede così tanta configurazione da essere rifiutato dagli operatori.
La selezione dovrebbe quindi essere un piccolo progetto operativo, non una decisione presa dopo una demo commerciale di un'ora.
Partire dai problemi, non dalle funzioni
Prima di cercare fornitori, descrivere i cinque problemi che fanno perdere più tempo o generano più rischio.
Esempi:
- gli ordini arrivano su tre canali;
- il piano esiste solo sul PC di una persona;
- una modifica comunicata all'autista non viene riportata nel file;
- si riscrive lo stesso indirizzo ogni giorno;
- il POD arriva dopo giorni e non viene collegato all'ordine;
- non si sa quali ordini siano ancora aperti;
- è difficile capire quanto lavoro è stato svolto per cliente.
Per ogni problema definire una misura semplice:
“Oggi ricopiamo ogni ordine tre volte. Obiettivo: inserirlo una volta sola.”
Questa frase vale più di “vogliamo digitalizzare”.
Scrivere 10 requisiti prima di vedere le demo
I requisiti devono essere descritti come attività, non come parole di moda.
Esempio di lista
- Creare un ordine in meno di due minuti.
- Riutilizzare clienti e sedi già inseriti.
- Vedere tutti gli ordini non pianificati.
- Assegnare camion e autista dalla stessa schermata.
- Spostare un'attività senza ricrearla.
- Far vedere all'autista la versione aggiornata.
- Conservare chi ha modificato il dato, dove disponibile.
- Cercare uno storico per cliente/data/riferimento.
- Esportare gli ordini in formato leggibile.
- Gestire account separati per le persone che lo usano.
Aggiungere poi requisiti specifici dell'azienda: più ritiri, groupage, casse mobili, bilici, vincoli cliente, documenti, import Excel, API, ecc.
Provare il software con ordini reali
Non usare soltanto il dataset preparato dal venditore. Prendere cinque casi veri, eliminando dati personali o riservati non necessari alla prova.
Testare:
Caso 1 — ordine normale
Un ritiro, una consegna, un autista, un camion.
Caso 2 — modifica
Dopo l'assegnazione il cliente cambia orario o indirizzo. Verificare dove compare la modifica e se la versione precedente rimane ricostruibile.
Caso 3 — eccezione
Autista indisponibile: quanto è semplice riassegnare?
Caso 4 — più attività
Un viaggio con più ritiri o consegne, se fa parte dell'operatività reale.
Caso 5 — chiusura
Consegna completata, stato aggiornato, eventuale documento collegato, ordine ricercabile dopo un mese.
Cronometrare i passaggi. Se per dimostrare una funzione serve continuamente l'intervento del consulente, chiedersi se l'operatore quotidiano riuscirà a usarla.
Valutare facilità d'uso e adozione
Il software non viene scelto soltanto per il titolare. Coinvolgere almeno una persona che pianifica e, se esiste una componente driver, uno o due autisti.
Osservare:
- capiscono dove iniziare senza spiegazioni continue?
- gli errori sono recuperabili?
- i nomi dei campi corrispondono al linguaggio usato in azienda?
- la schermata del giorno mostra ciò che serve davvero?
- su telefono le informazioni essenziali sono leggibili?
- servono troppi click per un'attività ripetuta decine di volte?
Una funzione tecnicamente potente ma che nessuno utilizza ha valore operativo zero.
Controllare proprietà, export e portabilità dei dati
Una delle domande più importanti è spesso trascurata:
Se tra tre anni cambio software, come porto via i miei dati?
Chiedere per iscritto:
- quali dati sono esportabili;
- in quali formati;
- se l'export è self-service o richiede assistenza;
- se esistono costi per l'estrazione;
- se si possono esportare allegati/documenti;
- come vengono mantenuti i collegamenti tra ordine e allegati;
- per quanto tempo i dati restano disponibili dopo la cessazione;
- come avviene la cancellazione finale.
CSV/XLSX può essere sufficiente per molti dati tabellari; per sistemi più articolati può essere importante avere API o esportazioni strutturate.
Evitare una dipendenza in cui l'azienda può vedere i dati ma non recuperarli in modo ragionevole.
GDPR: cosa chiedere al fornitore
Un gestionale trasporti può contenere nomi, recapiti, dati degli autisti, documenti e informazioni operative riferibili a persone fisiche. Il ruolo privacy dipende dal servizio e dai trattamenti concreti, ma nei normali servizi SaaS il fornitore può operare, per varie attività, come responsabile del trattamento per conto dell'impresa cliente.
L'articolo 28 del GDPR disciplina il rapporto tra titolare e responsabile e richiede che il trattamento sia regolato da un contratto o altro atto giuridico con gli elementi previsti dalla norma.
Prima della firma chiedere:
- DPA/accordo sul trattamento dati;
- elenco o meccanismo di informazione sui sub-responsabili;
- dove sono trattati/conservati i dati;
- misure di sicurezza dichiarate;
- gestione delle violazioni di dati personali;
- supporto a richieste di accesso/cancellazione quando applicabile;
- regole di restituzione/cancellazione a fine contratto;
- tempi di conservazione e backup;
- eventuali trasferimenti internazionali e relative basi giuridiche.
Non basta una pagina con scritto “GDPR compliant”: servono informazioni coerenti con il servizio concreto.
Sicurezza, backup e continuità
Per una piccola impresa una giornata senza piano viaggi può essere più grave di molte funzioni mancanti. Chiedere quindi come il fornitore gestisce l'affidabilità.
Account
- utenti individuali;
- password policy;
- MFA se disponibile;
- revoca accessi;
- ruoli e permessi.
Backup
- esistono backup?
- con quale frequenza?
- quanto sono conservati?
- sono provate le procedure di ripristino?
Continuità
- esiste una pagina di stato o un canale per incidenti?
- quali livelli di servizio sono contrattualmente previsti, se presenti?
- come si lavora se internet o il servizio non sono disponibili?
Log
Per operazioni importanti, sapere chi ha modificato un dato può ridurre discussioni e tempi di ricostruzione.
Una PMI non deve necessariamente pretendere l'architettura di una banca, ma deve capire se il proprio piano operativo dipende da un sistema senza misure adeguate.
Leggere il contratto e i costi nascosti
Verificare almeno:
- durata minima;
- rinnovo automatico;
- termini di disdetta;
- modalità di revisione prezzi;
- numero utenti/mezzi inclusi;
- costi per moduli;
- costi API;
- costi di onboarding;
- assistenza inclusa;
- SLA, se rilevanti;
- responsabilità e limitazioni;
- esportazione dati;
- periodo di accesso dopo cessazione;
- condizioni per personalizzazioni;
- proprietà di eventuali sviluppi specifici.
La domanda “quanto costa al mese?” non è sufficiente.
Evitare personalizzazioni premature
Durante la demo è facile dire: “noi facciamo diversamente, fateci questa modifica”. Dieci personalizzazioni dopo, il progetto diventa costoso e difficile da aggiornare.
Prima di chiedere sviluppo specifico distinguere:
Requisito legale/contrattuale. Va gestito correttamente.
Requisito operativo essenziale. Senza di esso il processo non funziona.
Abitudine. “Abbiamo sempre fatto così” non è necessariamente un requisito.
Preferenza. Può essere sacrificata se il nuovo processo è più semplice.
Provare prima il prodotto standard. Personalizzare soltanto ciò che crea un vantaggio reale o evita un problema concreto.
Piano di migrazione
Una piccola azienda non dovrebbe trasferire automaticamente dieci anni di file sporchi.
Un piano semplice può essere:
Fase 1 — pulizia
Eliminare duplicati e standardizzare almeno clienti, sedi, autisti e mezzi.
Fase 2 — import
Caricare le anagrafiche e, se serve, un periodo limitato di ordini storici.
Fase 3 — prova parallela breve
Usare il nuovo sistema con un gruppo limitato o per pochi giorni, evitando mesi di doppio lavoro.
Fase 4 — data di taglio
Stabilire: “da lunedì tutti i nuovi ordini nascono qui”.
Fase 5 — archivio
Conservare il vecchio materiale secondo gli obblighi applicabili, ma non usarlo più come piano corrente.
Scheda punteggio per confrontare 3 software
Usare un punteggio 1-5 e attribuire un peso.
| Criterio | Peso suggerito |
|---|---|
| Ordini e piano giornaliero | 25% |
| Facilità d'uso | 20% |
| Gestione autisti/mezzi | 15% |
| Export e portabilità | 10% |
| Affidabilità/sicurezza | 10% |
| Assistenza | 5% |
| Integrazioni necessarie | 5% |
| Costo totale | 10% |
I pesi vanno adattati. Il valore della tabella è evitare che una demo spettacolare su una funzione secondaria domini la scelta.
Checklist finale
- Abbiamo scritto i problemi prima di vedere i prodotti?
- Esistono 10 requisiti verificabili?
- Abbiamo provato ordini reali?
- Chi pianifica ha testato il software?
- Gli autisti hanno testato la parte che li riguarda?
- Abbiamo misurato il numero di passaggi?
- Possiamo esportare dati e allegati?
- Abbiamo letto DPA/privacy e sub-responsabili?
- Backup e continuità sono chiari?
- Abbiamo calcolato il costo a tre anni?
- Il contratto spiega uscita e disdetta?
- Possiamo partire senza personalizzazioni pesanti?
- Esiste un piano di migrazione concreto?
Fonti e riferimenti
- EUR-Lex — Regolamento (UE) 2016/679, GDPR, in particolare artt. 5, 28 e 32
- Garante per la protezione dei dati personali — sito istituzionale e provvedimenti
Le fonti sono indicate come punto di partenza per la verifica. Per casi concreti consultare il testo vigente e professionisti competenti.
