Il report arriva il 20 del mese: come avere i numeri del giorno prima senza assumere un ufficio data
Il giorno in cui scopri come è andato il mese, il mese è già finito
C’è una scena che si ripete in migliaia di aziende, sempre uguale. È il 18, il 19, a volte il 20 del mese. Arriva finalmente il file: il report vendite del mese precedente. Lo apri, lo guardi, e nella migliore delle ipotesi scopri che è andata come pensavi. Nella peggiore scopri che un prodotto ha smesso di vendere, che un cliente importante ha rallentato, che un canale è crollato — tre settimane fa. Ora lo sai. Ma è tardi: il mese è chiuso, e quello nuovo è già a metà.
Il report vendite in ritardo non è un fastidio amministrativo. È una tassa sulla velocità delle tue decisioni. Ogni giorno che passa tra «è successo qualcosa» e «me ne sono accorto» è un giorno in cui non hai corretto il tiro, non hai richiamato quel cliente, non hai fermato quello sconto, non hai riordinato quel prodotto che stava tirando. E la cosa più frustrante è che quasi sempre non è colpa di nessuno: è colpa di come il report viene fatto.
Questo articolo è per chi aspetta il file del controller — interno o esterno — per sapere come sta andando l’azienda. Ti dico due cose che di solito non ti dicono. La prima: il problema non è la persona che compila il report, e sostituirla o affiancarle un junior non lo risolve. La seconda: la soluzione non è «più reporting», è un prodotto che tiene insieme le fonti e ti dà i numeri del giorno prima senza che nessuno la mattina apra un Excel. Vediamo perché, e cosa serve davvero.
Decidere a mese inoltrato è decidere sul passato
Facciamo un esperimento mentale. Immagina di guidare guardando solo lo specchietto retrovisore, con un ritardo di venti giorni: vedi la strada di tre settimane fa. Finché la strada è dritta, va tutto bene. Ma nel momento in cui c’è una curva — un calo, un picco, un problema — te ne accorgi quando ci sei già dentro. Ecco cosa vuol dire prendere decisioni commerciali sul report del mese scorso.
Il costo non è teorico, è fatto di occasioni mancate concrete:
- Un prodotto che accelera e tu non riordini in tempo: vendite perse che non tornano, perché il cliente nel frattempo ha comprato altrove.
- Un prodotto che rallenta e tu continui a riordinare come prima: capitale immobilizzato, magari finito in saldo a margine zero.
- Un cliente abituale che smette di ordinare: se te ne accorgi a fine mese, la telefonata di recupero arriva quando ha già scelto un altro fornitore.
- Uno sconto o una promo che non stanno funzionando e che continuano a girare per settimane, bruciando margine, perché il dato che lo direbbe arriva troppo tardi.
Nessuna di queste voci finisce in contabilità con la scritta «deciso in ritardo». Spariscono nel rumore, e l’anno dopo si ripetono. Ma sommate, valgono molto più di quanto costi risolvere il problema alla radice. Il punto della velocità è tutto qui: non serve sapere tutto, serve saperlo in tempo per farci qualcosa. Un dato perfetto che arriva il 20 vale meno di un dato «abbastanza buono» che arriva ogni mattina.
Se questo ti suona familiare, probabilmente convivi anche con il fratello di questo problema: i numeri che non sono solo in ritardo, ma sparsi in sei software diversi. Ne ho parlato a fondo nell’articolo su come decidere quando i numeri sono in sei software; qui ci concentriamo sul tempo, non sulla dispersione.
Quanto vale un giorno di ritardo (un conto che puoi rifare)
Proviamo a dare un numero alla velocità, perché il «ritardo» sembra gratis e non lo è. Prendi il tuo fatturato mensile e dividilo per i giorni lavorativi: è quanto passa dalle tue mani ogni giorno. Ora immagina che una decisione presa venti giorni prima — fermare uno sconto che non funziona, richiamare un cliente che rallenta, riordinare un prodotto che tira — sposti anche solo l’1–2% di quel flusso.
Su un’azienda che fa, poniamo, 200.000 € al mese, un 2% recuperato su qualche episodio all’anno sono decine di migliaia di euro. Non è una promessa di risultato: è l’ordine di grandezza della posta in gioco. Il ritardo non costa «il tempo del report». Costa le decisioni che non hai potuto prendere in tempo. E la parte scomoda è che questo costo non lo vedi mai, perché un’occasione mancata non lascia una riga in contabilità: lascia solo un numero più basso di quello che poteva essere. È lo stesso motivo per cui i kpi giornalieri valgono più di un report mensile perfetto: non perché siano più precisi, ma perché arrivano quando puoi ancora farci qualcosa.
Cosa c’è davvero dietro un report «manuale»
Qui arriva il malinteso numero uno. «Il report è in ritardo perché ci vuole tempo a farlo.» Vero, ma perché ci vuole tempo? Perché dietro quel file non c’è uno strumento: c’è una persona. Una persona brava, spesso, che ogni mese fa a mano una catena di operazioni che nessuno vede:
- Scarica i dati dal gestionale (e aspetta che l’ufficio abbia chiuso il mese).
- Esporta gli ordini dall’e-commerce, in un altro formato.
- Va a prendere i dati degli agenti, che arrivano via email in fogli fatti ognuno a modo suo.
- Incolla tutto in un foglio-madre, sistema le colonne che non combaciano, corregge i doppioni.
- Toglie a mano i resi, aggiusta l’IVA dove serve, sistema i nomi dei clienti scritti in cinque modi diversi.
- Costruisce le tabelle e i grafici, li impagina, scrive due righe di commento.
- Manda il file.
Il report è in ritardo non perché la persona è lenta, ma perché ogni mese rifà lo stesso lavoro da capo, a mano, su fonti che non si parlano. E c’è un problema più grave del ritardo: la fragilità. Quel processo vive nella testa di una persona. Quando è in ferie, il report salta. Quando cambia lavoro, se ne va con lei il «come si fa». Quando sbaglia un copia-incolla — capita, siamo umani — il numero è sbagliato e nessuno se ne accorge, perché non c’è nessun controllo automatico che dica «attenzione, questo mese non torna».
Quindi il vero costo del report manuale è doppio: le ore che la persona ci mette (che potrebbe usare per pensare invece che per compilare) e il rischio che tutto dipenda da lei. Ecco perché la soluzione non è «fai prima» o «lavora di più». È togliere il lavoro ripetitivo dalla persona e darlo a una pipeline che lo fa da sola, ogni notte, sempre uguale.
Una giornata tipo di chi «fa i numeri»
Vale la pena guardare da vicino cosa succede davvero, perché aiuta a capire che il problema non è la pigrizia di nessuno. La responsabile amministrativa — chiamala come vuoi — aspetta che l’ufficio abbia chiuso il mese, poi comincia. Apre il gestionale, esporta, aspetta. Apre la casella dove gli agenti mandano i loro fogli: uno è arrivato, due no, uno è in un formato diverso dal solito. Scrive un promemoria per sollecitarli.
Intanto sistema i doppioni dell’e-commerce, toglie i resi a mano, si accorge che un cliente è scritto in tre modi diversi e li unisce. A metà pomeriggio il foglio-madre comincia a prendere forma; il giorno dopo lo impagina, aggiunge i grafici, scrive due righe di commento. Se in mezzo qualcuno le chiede un’altra cosa — e succede sempre — il report slitta di un giorno.
Non è lentezza: è che ogni mese rifà da capo un lavoro che nessun sistema fa al posto suo, su fonti che non si parlano. E il giorno in cui è in ferie, semplicemente, il report non esce. Tieni a mente questa scena: è la stessa che ritroviamo quando i numeri, oltre che in ritardo, sono anche sparsi in sei software diversi.
Assumere un analyst junior non sistema le fonti
La reazione istintiva, quando il report è sempre in ritardo, è: «assumiamo qualcuno che se ne occupi». Un data analyst junior, magari un data analyst esterno a giornata, qualcuno che «ci mette ordine nei numeri». È una mossa comprensibile ed è quasi sempre uno spreco. Ti spiego perché.
Il problema non è la mancanza di mani. È la mancanza di un sistema. Se le fonti sono sporche e non concordano, la persona che assumi passa il primo mese — e spesso il secondo — a fare esattamente quello che faceva già l’amministrazione: pulire, incollare, riconciliare. Solo che ora la paghi di più. Non arriva mai alla parte «insight», perché è sepolta nella parte «pulizia». E soprattutto: quando se ne va (i junior si muovono), il problema torna identico, perché la conoscenza era nella sua testa, non nel sistema.
Mettiamola in tabella, con numeri onesti dichiarati come stime, perché il confronto conta.
| Assumere un analyst junior | Costruire una pipeline + prodotto | |
|---|---|---|
| Costo primo anno | ~30.000–40.000 € (RAL + contributi + postazione) | progetto una tantum + manutenzione |
| Quando dà valore | dopo mesi, se sopravvive alla pulizia | dalle prime settimane, poi ogni giorno |
| Cosa produce | ancora un report, forse più bello | un cruscotto che si aggiorna da solo |
| Se la persona se ne va | riparti da zero | il sistema resta e funziona |
| Le fonti sporche | le pulisce a mano, ogni volta | le regole di pulizia sono scritte nel codice |
| Rischio chiave | dipendenza da una persona | manutenzione (chi tiene vivo il sistema) |
Attenzione: non sto dicendo «mai assumere». Sto dicendo di farlo nell’ordine giusto. Prima costruisci il sistema che pulisce le fonti e produce i numeri da solo; poi, se serve, una persona lo presidia e ci ragiona sopra — e finalmente fa l’analista, non il compilatore. Assumere prima di avere il sistema è come assumere un autista per una macchina che non hai ancora comprato. È lo stesso discorso, ribaltato, di quando assumere un data analyst non basta perché i KPI restano una rissa: la persona da sola non sistema ciò che è rotto a monte.
Il prodotto: aggiornamento e allarmi, non quaranta slide
Allora cosa serve al posto del report mensile in ritardo? Non «più reporting». Un prodotto, e un prodotto fa tre cose che il file del 20 del mese non farà mai.
Primo: si aggiorna da solo. Durante la notte, una pipeline prende i dati dalle fonti, li pulisce con le regole che avete deciso, e li mette in un posto solo. La mattina i numeri sono già pronti. Nessuno «fa il report»: il report non esiste più come attività, esiste come stato sempre aggiornato. Questo è il cuore del reporting automatico aziendale: non un file più veloce, ma l’assenza del file.
Secondo: ti parla, non ti sommerge. Un report da quaranta slide è un modo elegante per non far decidere niente a nessuno. Un prodotto mostra pochi numeri che contano — le quattro domande: vendiamo abbastanza, incassiamo, cosa cambia, dove — e soprattutto ti manda un allarme quando qualcosa è anomalo. «Le vendite del prodotto X sono a −40% da tre giorni.» «Il cliente Y non ordina da due settimane.» «Questo negozio è sotto del 25% rispetto allo stesso periodo.» Non devi ricordarti di guardare: è il sistema che ti chiama quando serve. Questa è la differenza tra kpi giornalieri utili e una dashboard che nessuno apre.
Terzo: è vivo, non fotografato. Il report è una fotografia di un momento; quando lo leggi è già vecchio. Il prodotto è una finestra sempre aperta: apri il telefono alle 8, vedi ieri, vedi il mese fino a ieri confrontato con lo stesso periodo di prima, e decidi. Se vuoi, scendi nel dettaglio; ma il punto è la prima schermata, quella che in venti secondi ti dice se stare tranquillo o alzare il telefono.
La cosa importante da capire, come compratore, è che «aggiornato ogni notte» quasi sempre basta e avanza. Il «tempo reale al secondo» costa molto di più e serve a pochissimi: se qualcuno te lo propone come standard, chiedi perché. Per decidere, i numeri di ieri sono un enorme passo avanti rispetto ai numeri del mese scorso.
Reporting automatico non vuol dire «l’AI fa tutto»
C’è un equivoco da sciogliere, perché genera aspettative sbagliate in tutte e due le direzioni. Automatizzare il reporting non vuol dire «mettere l’AI a fare i numeri». La parte che conta — collegare le fonti, applicare le definizioni, calcolare i totali, far scattare l’allarme quando un valore esce dalla norma — è deterministica: sono regole, non magia. Devono essere esatte, e un modello linguistico che «più o meno» somma le vendite è esattamente ciò che non vuoi vicino ai tuoi numeri.
L’AI, semmai, entra ai bordi: riassumere in una frase l’andamento della settimana, raggruppare le note dei commerciali, scrivere in italiano leggibile un commento sopra numeri già calcolati bene. Ma il numero lo fa il codice, con regole verificabili, non un modello che «sembra plausibile». Chi ti vende «l’AI che ti fa i report» e non ti parla mai di fonti e definizioni ti sta vendendo la parte spettacolare e saltando quella che rende i numeri veri. La fiducia in un cruscotto si costruisce sulla noia delle regole, non sull’entusiasmo del modello.
Il report che ti cerca: allarmi, non ricerche
C’è una differenza sottile ma enorme tra un report che devi aprire e un sistema che ti cerca. Il report, anche quello automatico, presuppone che qualcuno si ricordi di guardarlo. E la memoria è la prima cosa che salta quando l’azienda va di corsa: la settimana intensa è proprio quella in cui nessuno apre la dashboard, ed è anche quella in cui succedono le cose che dovresti vedere.
Un prodotto dati fatto bene ribalta la logica: invece di aspettare che tu lo interroghi, ti manda un segnale quando c’è qualcosa da sapere. Qualche esempio concreto di allarme utile:
- «Le vendite del prodotto X sono a −40% rispetto alla media delle ultime quattro settimane.»
- «Il cliente Y, che ordinava ogni due settimane, non ordina da 20 giorni.»
- «Questa filiale è sotto del 25% rispetto allo stesso periodo del mese scorso.»
- «Ieri gli incassi sono a zero: possibile problema tecnico sul canale online.»
L’ultimo esempio è importante: un buon sistema di allarmi non serve solo a vedere i cali di business, ma anche a beccare i guasti dei dati stessi. Un canale che smette di riportare vendite spesso non è un crollo commerciale: è un’integrazione che si è rotta. Senza allarme, scopri entrambe le cose troppo tardi. Con l’allarme, ricevi un messaggio la mattina e agisci lo stesso giorno. Questo è il passaggio da reporting (io produco, tu leggi se ti ricordi) a prodotto (il sistema ti avvisa quando serve).
Un caso tipo: dal report del 20 ai numeri di ieri
Un profilo tipico, architetturale, senza nomi e senza fatturati inventati. Azienda di servizi con tre linee di ricavo e una rete di venditori. Prima: il report arrivava tra il 18 e il 22, lo faceva a mano una controller esterna, e il titolare «sentiva» l’andamento parlando con i commerciali — salvo poi scoprire a mese chiuso che una linea era in calo da settimane.
Cosa si è fatto. Prima le definizioni: cos’è una vendita per ciascuna delle tre linee, come si trattano gli storni. Poi la pipeline: ogni notte le fonti confluiscono in un posto solo, con un controllo che segnala se una fonte non è arrivata. Poi la schermata: quattro numeri, il confronto con lo stesso periodo del mese precedente, e tre allarmi (linea sotto soglia, cliente fermo, venditore in calo).
Dopo: il titolare guarda i numeri di ieri ogni mattina dal telefono; la controller non passa più tre giorni a compilare, ma un paio d’ore al mese a validare e commentare; e i cali si vedono dopo giorni, non dopo settimane. Il valore non è stato «la dashboard»: è stato accorciare la distanza tra un problema e la reazione. Con una nota onesta: il primo mese ha fatto emergere che una delle tre linee, considerata «sana», in realtà reggeva solo grazie a due clienti. Scomodo da vedere, prezioso da sapere — ed è tipico, perché un cruscotto vero ogni tanto ti dà una brutta notizia in tempo per rimediare.
Cosa deve essere vero nei dati (o costruisci solo un ritardo più veloce)
Qui c’è la parte che quasi nessuno affronta, ed è la ragione per cui tanti progetti di reporting automatico falliscono: se automatizzi dati sporchi, ottieni solo numeri sbagliati più in fretta. Prima di velocizzare, bisogna mettere d’accordo cosa significano le parole. Sembra banale, non lo è.
Prendi tre parole che usi ogni giorno:
- Vendita. È l’ordine ricevuto, la fattura emessa o l’incasso arrivato? Se il commerciale conta gli ordini e l’amministrazione le fatture, avrete sempre due numeri diversi per «quanto abbiamo venduto», e passerete le riunioni a litigare invece che a decidere.
- Reso. Quando lo togli: dal mese in cui il prodotto è stato venduto o dal mese in cui è rientrato? La scelta cambia i numeri di entrambi i mesi, e va fatta una volta per tutte.
- IVA. I tuoi numeri di vendita sono con o senza IVA? Sembra ovvio, ma metà delle discussioni su «abbiamo fatto 40.000» nascono da qui, perché qualcuno la conta e qualcuno no.
La soluzione non è tecnologica, è una decisione messa per iscritto e firmata: «Nel nostro sistema, vendita = fattura emessa, IVA esclusa, reso scalato alla data dell’ordine.» Fine. Da quel momento c’è un solo numero, e chi non è d’accordo discute la definizione, non il grafico. Questo documento — poche righe, non un trattato — è il pezzo più prezioso di tutto il progetto, perché è quello che rende i numeri fidati. Un cruscotto veloce di cui non ti fidi è inutile quanto un report lento.
Questo è anche il motivo per cui un progetto serio parte da qui e non dai colori. Se un fornitore ti propone di «collegare tutto e farti la dashboard» senza mai chiederti come definisci una vendita, sta costruendo un ritardo più veloce, non un prodotto.
Le tre parole di sopra sono le più comuni, ma non le uniche. Prima o poi arrivano anche queste. Cliente attivo: dopo quanti giorni senza ordini uno smette di essere «attivo»? La soglia cambia completamente il numero dei clienti che «stai perdendo». Margine: lo calcoli sul prezzo di listino, sul netto scontato, includendo o no spedizioni e provvigioni? Due aziende identiche possono dichiarare due «marginalità» diverse solo per come le definiscono. Nessuna di queste ha una risposta giusta universale: ha una risposta tua, che va decisa e scritta. Il documento delle definizioni cresce così, una riga alla volta, e ogni riga è una discussione risolta per sempre.
Quanto tempo ci vuole sul serio
Nessun numero magico, ma delle forchette oneste per una PMI con le fonti tipiche (gestionale, e-commerce, agenti, banca).
| Fase | Cosa succede | Tempo indicativo |
|---|---|---|
| Definizioni & fonti | scriviamo cosa conta come vendita/reso/IVA, mappiamo accessi | 1–2 settimane |
| Pipeline dati | colleghiamo le fonti, puliamo, costruiamo lo storico, mettiamo gli allarmi | 3–5 settimane |
| Schermata & allarmi | il cruscotto che si apre in 20 secondi, prima desktop poi mobile | 2–3 settimane |
| Rodaggio | lo usi davvero, aggiustiamo definizioni e viste su ciò che serve | 3–4 settimane |
In pratica: da un cruscotto utile in 6–8 settimane, a un prodotto rodato in tre-quattro mesi. Chi ti promette «in una settimana hai tutto» ti sta vendendo la schermata saltando le definizioni e la pipeline — cioè saltando le uniche due parti che rendono i numeri veri. È esattamente la ragione per cui poi quella dashboard finisce nel cassetto: bellissima, veloce, e sbagliata.
Una cosa che aiuta ad accettare queste settimane: buona parte del lavoro si fa in parallelo alla tua attività normale, senza fermare niente. Il vecchio report continua a uscire finché il nuovo cruscotto non è affidabile; si spegne solo quando ti fidi dei numeri nuovi. Non è un «big bang» in cui un lunedì stacchi tutto e speri: è un passaggio graduale, con un periodo in cui i due mondi convivono e li confronti. È il modo onesto di farlo, e anche il meno rischioso.
I report muoiono se nessuno li possiede
Un errore comune è pensare che, una volta automatizzato, il reporting «giri da solo per sempre». Non è così, ed è giusto saperlo prima di firmare. Le fonti cambiano: il gestionale aggiorna un campo, l’e-commerce cambia un’integrazione, nasce un canale nuovo. Il business cambia: apri una sede, lanci una linea, cambi il modo di scontare. Ogni volta, se nessuno se ne occupa, il numero comincia a mentire in silenzio — ed è peggio di un report in ritardo, perché un report in ritardo sai che è vecchio, mentre un numero sbagliato che sembra fresco ti fa decidere male con sicurezza.
Per questo un prodotto dati serio prevede due cose. Una manutenzione dichiarata (tipicamente il 15–25% del progetto l’anno) per tenere vive le connessioni, aggiungere una vista quando nasce una domanda nuova, sistemare quando una fonte cambia. E un proprietario: qualcuno, in azienda, di cui è il cruscotto — che lo guarda, si accorge quando un numero è strano, e ha un canale per farlo sistemare. Un cruscotto senza proprietario muore come un report senza autore: lentamente, e nessuno se ne accorge finché non serve davvero.
Nota bene: manutenzione non vuol dire dipendere per sempre da un fornitore. Vuol dire che il codice, le definizioni e i dati sono tuoi, e che c’è un accordo chiaro su chi mette le mani quando qualcosa cambia. Se un domani vuoi cambiare cavallo, ti porti via tutto.
Segnali che stai comprando fuffa
Visto che questo è un mercato pieno di promesse, ecco i segnali che stai comprando una demo travestita da prodotto — le red flag da tenere d’occhio quando qualcuno ti propone di risolverti il report in ritardo.
- La dashboard bellissima costruita sui dati d’esempio. Se la demo gira su numeri finti, non hai visto niente: il lavoro vero è sui tuoi dati, che sono sporchi. Chiedi sempre una prova su un campione reale, anche piccolo.
- Il template pronto «lo adattiamo a te in due giorni». Un cruscotto scaricato da un template è veloce da mostrare e inutile da usare, perché non conosce le tue definizioni. Se non ti chiedono come definisci una vendita, scappa.
- Nessuna parola sulle fonti che cambiano. Se non ti spiegano cosa succede quando il gestionale aggiorna un campo o una fonte non risponde, non hanno pensato alla produzione: hanno pensato alla demo.
- «Accuratezza al 99%» senza dirti su cosa. Il 99% sugli header e il 60% sugli importi è un disastro travestito da percentuale. Fatti spiegare cosa misura quel numero.
- Il codice «resta nostro» o gira solo sul loro account. È vendor lock-in. I dati e il sistema devono restare tuoi.
- Il prezzo tutto all’inizio, niente manutenzione. Un prodotto dati senza manutenzione è un prodotto che muore a rate. Un fornitore serio te lo dice; uno che ti fa firmare e sparisce, no.
Se vuoi approfondire questo tema — cosa include davvero un progetto serio e cosa è teatro — lo tratto in modo esteso nella guida ai cruscotti e ai prodotti dati, che raccoglie tutti gli articoli di questo filone.
Prima di spendere: misura il tuo vero ritardo
Prima di valutare qualsiasi progetto, c’è una cosa che puoi fare da solo, questa settimana, gratis: misurare il ritardo vero. Non quello che immagini — quello reale. Per un mese, segnati tre numeri.
- La data. In che giorno ti arriva il report del mese precedente. La data esatta, non «verso metà mese».
- Le ore. Quante ore-persona servono per produrlo. Chiedilo a chi lo fa, sommando scarichi, riconciliazioni, impaginazione, correzioni.
- Le decisioni mancate. Il numero più importante: elenca le decisioni che nell’ultimo trimestre avresti preso diversamente se avessi saputo prima. Un cliente da richiamare, uno sconto da fermare, un riordino da anticipare.
Quei tre numeri — la data, le ore, le decisioni perse — sono il tuo business case, e valgono più di qualsiasi preventivo. Ti dicono se il problema è reale e quanto pesa. Se il report arriva il 20, costa cinque giornate-persona al mese e ti sei perso due decisioni importanti a trimestre, il conto lo fai da solo. Se invece arriva il 3, costa mezza giornata e non ricordi una sola decisione persa, forse questo problema non ce l’hai — e un fornitore onesto te lo dirà, invece di venderti una dashboard che non ti serve.
L’esercizio ha anche un effetto collaterale prezioso: ti costringe a definire cosa significa «in ritardo» e «utile» per te, che è già metà del lavoro. Portalo a chiunque valuti per il progetto, me compreso: si parte da lì.
Cosa cambia per chi oggi fa il report
Una preoccupazione legittima, quando si parla di automatizzare il reporting, è: «e la persona che lo fa?». Vale la pena dirlo chiaro, perché è il timore che blocca più progetti di quanti dovrebbe. Automatizzare il report non toglie lavoro alla persona brava: le toglie il lavoro stupido. Oggi passa tre giorni a impaginare e riconciliare, e zero minuti a chiedersi perché i numeri sono quelli. Domani i tre giorni li recupera, e li usa per la parte che vale: notare che un cliente sta scivolando, capire perché una linea cala, preparare la mossa. Il compilatore diventa un interprete.
Ed è anche una questione di rischio per te. Finché il «come si fanno i numeri» vive nella testa di una persona, sei esposto: ferie, malattia, dimissioni, e il report si ferma. Quando quel sapere vive in un sistema documentato, la persona diventa più preziosa (perché finalmente ragiona) e tu meno fragile (perché non dipendi da un unico eroe con un Excel). Automatizzare non è mai contro le persone brave: è contro il lavoro che le spreca.
È per te se / non è per te se
È per te se: aspetti ogni mese un file per sapere come è andata; il report lo fa una persona a mano e quando è in ferie salta; ti sei accorto più di una volta di un problema quando era troppo tardi per rimediare; stai pensando di assumere qualcuno «per i numeri» ma sospetti che il problema sia a monte.
Non è per te se: hai una sola fonte semplice e i numeri ti bastano davvero così; ti serve un report una tantum per la banca, non uno strumento di guida quotidiana; i tuoi dati non esistono ancora (se vendi da tre mesi senza gestionale, prima sistemiamo quello); cerchi «l’AI che decide al posto tuo» — qui l’automazione pulisce e segnala, le decisioni restano tue.
Domande frequenti
Devo licenziare chi fa il report a mano? No. Devi liberarlo dal lavoro ripetitivo. La persona che oggi compila il file è spesso quella che conosce meglio i numeri: liberata dalla catena di copia-incolla, può finalmente ragionarci sopra e presidiare il cruscotto. Togli il lavoro noioso, non la persona.
Quanto costa rispetto ad assumere? Un progetto di pipeline + prodotto ha un costo una tantum più una manutenzione annuale, e comincia a dare valore in settimane. Un assunto junior costa 30.000–40.000 € il primo anno, dà valore dopo mesi (se sopravvive alla pulizia dei dati) e riparte da zero quando se ne va. Nella maggior parte delle PMI il sistema conviene, e l’eventuale persona ha senso dopo.
In quanto tempo ho i primi numeri automatici? Un cruscotto utile in 6–8 settimane, rodato in tre-quattro mesi. La fase più lunga e preziosa è mettere d’accordo le definizioni all’inizio: è lì che si decide se i numeri saranno veri.
E se i miei dati sono un disastro? È la normalità, non l’eccezione. Parte del lavoro è scrivere le regole per pulirli. Ma nessuno può inventare dati che non esistono: se un’informazione non la raccogli da nessuna parte, prima va raccolta.
Aggiornato ogni notte basta, o serve il tempo reale? Per decidere, ogni notte basta quasi sempre. Il tempo reale al secondo costa molto di più e serve a casi particolari. Meglio investire in numeri giusti ogni mattina che in numeri istantanei di cui non ti fidi.
I dati e il sistema restano miei? Sì, e devono. Codice, pipeline e definizioni restano tuoi: niente vendor lock-in. La manutenzione è un accordo di servizio, non un guinzaglio.
Possiamo partire da una sola fonte e allargare dopo? Sì, ed è spesso la mossa giusta. Si parte dalla fonte che pesa di più (di solito il gestionale), si porta a casa un cruscotto utile in poche settimane, e si aggiungono le altre fonti a strati. Meglio un cruscotto vero su una fonte che un progetto infinito su sei.
Il commercialista non basta per avere i numeri? Il commercialista ti dà numeri fiscali, a mese o trimestre chiuso: ti dice com’è andata, per il fisco. Un cruscotto ti dice come sta andando, mentre puoi ancora agire. Sono due mestieri diversi, non in concorrenza: uno guarda indietro, l’altro guarda ieri per decidere oggi.
E se ogni reparto vuole il suo report diverso? È normale, e non è un problema se le definizioni sono comuni. Stessi numeri di base, viste diverse: il commerciale vede pipeline e clienti, l’amministrazione vede cassa e scaduto, il titolare vede il quadro. Il disastro è quando ognuno ha anche definizioni diverse: lì tornano le riunioni-processo su «di chi è il numero giusto».
Cosa succede se una fonte si rompe di notte? In un sistema fatto bene, non ottieni un numero sbagliato: ottieni un avviso. La pipeline si accorge che il gestionale o l’e-commerce non hanno risposto e segnala «dati incompleti» invece di mostrarti un totale falsato. È la differenza tra un prodotto che sa di non sapere e una dashboard che mente con sicurezza — e nei numeri, il secondo caso è molto più pericoloso del primo.
In una riga
Se il tuo report vendite arriva sempre in ritardo, non ti manca una persona in più né un file più veloce: ti manca un prodotto che tiene insieme le fonti e ti dà i numeri del giorno prima da solo, con gli allarmi quando qualcosa cambia. Prima le definizioni firmate, poi la pipeline, poi la schermata — e la persona brava che oggi compila torna a fare l’unica cosa che vale davvero: decidere sul presente.
Se vuoi capire come sarebbe sui tuoi numeri, guarda i progetti che ho costruito o scrivimi due righe: partiamo dalle tue fonti, non da una demo.
Antonio Trento — System Architect & AI Integrator
Questo è il tuo problema?
Progetto e costruisco dati, backend, interfaccia e agenti AI end-to-end. Niente slide: sistemi che girano e restano tuoi.