La migrazione a un nuovo gestionale in un’azienda di autotrasporto raramente si rompe sul software. Si rompe sui dati. E quasi sempre sullo stesso blocco: l’anagrafica, intesa come insieme di clienti, fornitori, mezzi, autisti, condizioni e codifiche minime per lavorare.
Il paradosso è che l’anagrafica sembra il pezzo più facile: un export, un import, fine. Poi arriva il primo giro di viaggi reali, le prime fatture, la prima contestazione interna, e saltano fuori doppioni, codici incoerenti e campi che nel vecchio sistema non esistevano proprio. Nel trasporto, dove il flusso è continuo e la giornata si misura in partenze, un’anagrafica sporca è un freno a mano tirato.
Il mito dell’importazione “una tantum”
Il vecchio mondo spesso è un mix: un gestionale generico, qualche foglio Excel, cartelle condivise piene di versioni e un paio di persone che sanno “come si fa” perché lo fanno da anni. Quando si passa a un gestionale verticale per trasporti, quel sapere implicito deve diventare campi compilati e regole ripetibili. Non è una questione di burocrazia: è l’unico modo per far girare lo stesso processo su più operatori, più sedi, più mezzi.
Però l’importazione “una tantum” presume che il dato di partenza sia già pulito. E di solito non lo è. Nel trasporto si vive di scorciatoie: clienti inseriti una volta come “Rossi srl” e un’altra come “Rossi”; indirizzi scritti in tre formati diversi; numeri di telefono appiccicati nelle note; riferimenti del referente commerciale infilati dove capita.
E poi c’è il tema più fastidioso: ciò che nel vecchio sistema stava in una sola colonna “Note” adesso viene scomposto in più attributi. È qui che la migrazione diventa un progetto, non un trasferimento file.
Chi pensa di cavarsela con un file CSV si accorge presto che un gestionale non importa “testo”: importa relazioni. Cliente – sede – modalità di fatturazione – condizioni concordate. Se questi legami non reggono, il reparto operativo si ritrova a completare dati a mano mentre i camion partono.
Dove l’anagrafica si sporca davvero
La sporcizia non è un concetto morale. È tecnica: significa che lo stesso oggetto ha più identità, o che la stessa identità ha attributi contraddittori. Nel trasporto questo genera micro-fermi a catena, perché ogni viaggio pesca da anagrafiche e tabelle, anche quando non ce ne accorgiamo.
Un gestionale verticale come SAT, sviluppato da https://www.gestionaletrasportatori.it e orientato alla gestione operativa e alla fatturazione, tende ad avere vincoli più stretti su campi e coerenza rispetto a un foglio libero, e questa rigidità non è un difetto. È un filtro. Il problema è quando si prova a bypassarlo importando dati “così come sono”.
- Clienti e sedi: stesso cliente con più ragioni sociali, oppure sedi trattate come clienti distinti senza una relazione chiara. In pratica: chi emette il documento non sa quale intestazione usare e chi registra il pagamento non sa dove agganciarlo.
- Mezzi, targhe e combinazioni: il mezzo è identificato a volte dalla targa, a volte dal numero interno, a volte dal nome del proprietario. Il giorno che si deve ribaltare un viaggio su un altro trattore, l’operatore si trova davanti a tre “mezzi” che sono lo stesso mezzo o, peggio, a un mezzo che non esiste più ma continua a comparire.
- Condizioni e codifiche: listini e accordi commerciali tenuti in testi liberi o in righe di Excel non versionate. Appena provi a far calcolare al sistema una voce di addebito ricorrente, scopri che mancano unità di misura, arrotondamenti, regole di applicazione. E lì non c’è scorciatoia: o esiste una tabella coerente, o qualcuno dovrà ricostruirla a mano.
Il segnale tipico? La gente in ufficio operativo smette di fidarsi del dato importato e ricomincia a “scrivere come sempre” nelle note. A quel punto la migrazione è formalmente fatta, ma operativamente è fallita: hai due sistemi paralleli, uno ufficiale e uno informale.
Quando l’anagrafica sporca entra in contabilità (e si fa sentire)
Il reparto operativo tollera molte cose. La contabilità no. E non perché sia pignola: perché lavora su quadrature e numerazioni. Se l’anagrafica è sporca, l’effetto è che il documento contabile diventa ambiguo. Il costo non è solo un errore: è tempo buttato in verifiche.
Mettiamo il caso che un cliente sia stato importato due volte, una con denominazione completa e una abbreviata. La fattura esce sul secondo record, il pagamento arriva con la causale del primo. In contabilità parte la caccia al tesoro. Nel frattempo il gestionale, che ragiona per anagrafiche, ti mostra esposizioni spezzate e scadenzari falsati.
Però l’effetto più subdolo non è il pagamento perso. È l’effetto a valle: quando si cerca di capire se una tratta “sta in piedi” o se un cliente è in ritardo cronico, i report non tornano perché i dati sono frammentati. E qui si vede una cosa che sul campo capita spesso: si smette di misurare. Troppo scomodo. Si torna all’intuito.
Un’altra spina è la gestione delle eccezioni. Nel trasporto le eccezioni sono quotidiane: cambio mezzo, cambio autista, ritiro saltato, consegna parziale, attesa lunga. Se l’anagrafica non porta con sé i riferimenti corretti (sedi, contatti, condizioni), l’eccezione non si registra: si “risolve” al telefono e sparisce. Poi ricompare settimane dopo sotto forma di mail interna: “perché questa fattura è diversa da quella volta?”
E no, non è un problema che si risolve con più formazione. La formazione aiuta solo quando c’è un modello dati sano. Se la base è marcia, insegni alle persone a muoversi in una palude.
La routine che evita il fermo: pulizia prima, non dopo
La pulizia dati fatta dopo il go-live è la classica falsa economia. Sulla carta risparmi giorni di progetto. Nella realtà li paghi in settimane di correzioni, con l’operativo che lavora in emergenza e la contabilità che rincorre documenti da sistemare. E nel mezzo c’è il cliente, che non aspetta i tuoi aggiustamenti.
Una migrazione che regge parte da una decisione scomoda: scegliere un’identità univoca per ogni oggetto. Un cliente ha un solo codice. Un mezzo ha un solo identificativo. Una sede non è un cliente “secondario”: è una sede, con attributi propri. Sembra ovvio, ma non lo è quando si convive da anni con dati inseriti “come veniva”.
Serve poi una regola semplice e applicabile: nessun campo libero deve contenere informazioni che altrove esistono come campo strutturato. Se il referente finisce nelle note, prima o poi qualcuno lo riscrive diversamente e il dato diventa inservibile. E, peggio, non è filtrabile né esportabile in modo pulito.
Un altro punto che si sottovaluta è la versione del tariffario. Non basta importare “le tariffe”. Bisogna sapere da quando valgono, per chi valgono, con che eccezioni. Nel trasporto le eccezioni non sono un’anomalia statistica: sono accordi commerciali reali. Se in migrazione le schiacci in un’unica riga, stai seminando correzioni manuali future.
Infine, c’è una pratica poco glamour ma molto efficace: fare un giro di prova con un set di dati ridotto e cattivo. Non quello “bello”, quello che in ufficio sanno già essere problematico: clienti con più sedi, mezzi con storia lunga, accordi stratificati. Se regge lì, regge dopo. Se non regge, almeno lo scopri quando puoi ancora mettere mano alle anagrafiche senza bloccare la produzione.
Un gestionale per autotrasportatori non salva i processi. Li rende più visibili. E quando il dato è sporco, la visibilità fa male: non perché il software sia rigido, ma perché rende impossibile continuare a lavorare a memoria.