Uno schema prevedibile, ripetuto su molti team
Parla con abbastanza fondatori o responsabili tecnici di software per la pratica di uno studio commercialista e sentirai, con notevole regolarità, la stessa storia in tre atti: il team costruisce la propria estrazione documenti in casa, funziona sorprendentemente bene per un tempo sorprendente, e poi — di solito quando il portafoglio clienti gestiti dal software attraversa una certa soglia di varietà — qualcuno inizia a chiedersi se non fosse stata la scelta sbagliata fin dall'inizio.
Questo articolo non sostiene che costruire in casa sia sempre un errore. Sostiene qualcosa di più specifico e, crediamo, più utile: esiste uno schema riconoscibile in come questa decisione evolve nel tempo per un software che deve servire molti clienti diversi contemporaneamente, ed è più facile pianificare con successo se conosci lo schema in anticipo invece di scoprirlo un cliente insoddisfatto alla volta.
Perché lo schema si presenta prima qui che in un gestionale generico
Un gestionale pensato per un'unica azienda accumula varietà di documenti lentamente — le stesse banche, gli stessi fornitori, anno dopo anno, con qualche eccezione occasionale. Un software per la pratica di uno studio accumula varietà molto più in fretta, perché ogni nuovo cliente acquisito porta con sé, quasi per definizione, banche e fornitori che il sistema non ha mai visto. Cento clienti significano, nella pratica, cento piccole variazioni sul tema di "come appare un estratto conto o uno scontrino" — non una varietà che cresce gradualmente, ma una che si moltiplica con ogni acquisizione commerciale riuscita.
Questa è la ragione specifica per cui lo schema descritto in questo articolo tende a presentarsi prima, e in modo più acuto, per chi costruisce software per studi rispetto a chi costruisce un gestionale per una singola azienda. Il successo commerciale — più clienti acquisiti — è paradossalmente ciò che accelera il momento in cui il parser interno smette di reggere.
Perché quasi tutti iniziano costruendo
La decisione iniziale è quasi sempre razionale, non un errore di giudizio. Un servizio OCR generico — o anche un modello open source ragionevole — restituisce testo leggibile da un documento pulito abbastanza in fretta perché un ingegnere motivato costruisca un prototipo funzionante in una settimana. Su una manciata di documenti scelti a mano, il prototipo sembra risolvere il problema. Perché pagare un fornitore esterno per qualcosa che sembra già funzionare?
Questo ragionamento non è sbagliato nel momento in cui viene fatto — è semplicemente incompleto, perché misura il costo di costruire nel momento più favorevole possibile: prima che il portafoglio clienti reale abbia avuto la possibilità di mostrare quanto genuinamente vario sia il problema.
C'è anche una ragione più pratica per iniziare costruendo: nelle primissime settimane di un prodotto, nessun fornitore esterno ha ancora dimostrato di essere affidabile per il caso specifico dello studio, mentre il codice scritto internamente è, per definizione, sotto il pieno controllo del team. Questa sensazione di controllo ha un valore reale nella fase più fragile di un prodotto, anche se, come vedremo, tende a rivelarsi meno solida di quanto sembri una volta che il portafoglio cresce.
Fase uno: la demo che funziona su un cliente
Le prime settimane sono le più incoraggianti. Il parser interno legge correttamente gli estratti conto del cliente pilota, magari anche di due o tre clienti simili, e il team giustamente si sente soddisfatto del progresso. Un servizio OCR generico più qualche regola di analisi scritta a mano è sufficiente per questo primo, ristretto insieme di documenti — nessun segnale ancora di quanto fragile sia il sistema al di fuori di quell'insieme.
In questa fase, il team spesso interpreta il successo iniziale come una conferma della bontà dell'approccio, non come un artefatto della ristrettezza del campione. È un errore comprensibile — non c'è ancora alcun dato che suggerisca il contrario, e la pressione di lanciare il prodotto in fretta rende ragionevole non fermarsi a chiedersi cosa succederà con il cliente numero cinquanta.
Fase due: arriva la coda lunga dei clienti
Man mano che il numero di clienti serviti cresce, arrivano documenti da banche mai viste prima, da fornitori con impaginazioni insolite, scontrini fotografati in condizioni di luce scarsa. Ognuno di questi, singolarmente, sembra un'eccezione gestibile — una piccola correzione, una regola in più. Il problema è che le eccezioni non restano rare: crescono in numero proporzionalmente al portafoglio clienti, e ogni nuovo cliente acquisito ha una probabilità non trascurabile di portarne una di nuova.
Ciò che rende questa fase ingannevole è che ogni singola eccezione, presa isolatamente, sembra banale da correggere — una regola in più nel codice, un caso particolare gestito. È solo guardando indietro, dopo mesi, che il team si accorge di quante di quelle piccole correzioni si siano accumulate, e di quanto codice ormai esista solo per gestire il comportamento specifico di un singolo cliente o di un singolo fornitore.
Fase tre: la tassa di manutenzione moltiplicata
Questa è la fase in cui lo schema diventa visibile a livello di team, non solo di singolo bug. Un ingegnere che avrebbe dovuto lavorare su nuove funzionalità del software di studio passa una percentuale crescente del proprio tempo a correggere l'estrazione — un fornitore diverso, una banca diversa, uno scontrino diverso, ogni settimana. La percentuale non è mai enorme in un dato momento, il che è parte del motivo per cui il problema resta a lungo non riconosciuto esplicitamente: cresce troppo gradualmente per apparire come un'emergenza, e troppo costantemente per essere ignorata.
Il momento specifico in cui si ripensa la scelta
Nella maggior parte delle storie che sentiamo, il ripensamento non arriva da una revisione di architettura programmata — arriva da un evento specifico. Un cliente importante, con contabilità genuinamente complessa e molti fornitori esteri, viene acquisito e il parser interno fatica in modo visibile. Un cliente esistente si lamenta di un errore di estrazione che ha causato un problema reale a valle. Un nuovo assunto, guardando la codebase per la prima volta con occhi freschi, chiede semplicemente: "perché stiamo costruendo questo da soli?"
Qualunque sia l'innesco specifico, la domanda che segue è quasi sempre la stessa: quanto ci costerebbe davvero continuare a mantenere questo, contro quanto costerebbe passare a qualcosa costruito per gestire esattamente questa varietà fin dall'inizio?
È interessante notare che, quasi sempre, questa domanda viene posta molto più tardi di quanto i numeri suggerirebbero fosse ragionevole. Il costo di mantenimento cresce gradualmente abbastanza da non superare mai, in un singolo momento, la soglia che farebbe scattare un allarme — finché un evento esterno, come un cliente importante o una lamentela visibile, non costringe qualcuno a fare il conto esplicitamente, invece di continuare a sommare piccoli costi settimanali senza mai fermarsi a guardare il totale.
Non è una storia di un progetto fallito
Vale la pena essere chiari su questo punto, perché è facile leggere questo schema come una storia di fallimento e non lo è. Il parser interno ha fatto esattamente ciò per cui è stato costruito: ha permesso al team di lanciare il prodotto in fretta, senza aspettare una decisione di build-vs-buy perfetta prima di avere clienti paganti. Il ripensamento non significa che la scelta iniziale fosse sbagliata — significa che le condizioni sono cambiate, e il portafoglio clienti di oggi è genuinamente diverso, in varietà, da quello che il parser è stato originariamente progettato per gestire.
Vale la pena dirlo esplicitamente anche a chi sta valutando se costruire oggi: la scelta di costruire per primi non è quasi mai quella sbagliata in assoluto. È una scelta con una data di scadenza implicita, legata alla crescita del portafoglio clienti, non una scelta permanente da difendere per principio anche quando i segnali indicano il contrario.
Cosa si confronta davvero al momento del ripensamento
Il confronto onesto non è "quanto costa questa API" contro "zero" — il sistema interno non è mai stato gratuito, era solo pagato in tempo di ingegneria invece che in fattura mensile. Il confronto reale è tra il costo interamente carico di mantenere il parser esistente — ore di ingegneria, opportunità perse su altre funzionalità, il rischio di un errore di estrazione che raggiunge un cliente — e il costo di un'alternativa esterna, inclusa la migrazione.
Un errore comune in questo confronto è considerare solo il costo diretto in ore di ingegneria e ignorare il costo di opportunità — le funzionalità che il team non ha costruito perché era occupato a correggere l'estrazione. In molti casi, quel costo di opportunità supera di gran lunga il costo diretto, semplicemente perché una funzionalità mancante può costare uno studio cliente insoddisfatto o un'acquisizione mancata, mentre un'ora di manutenzione in più passa quasi sempre inosservata.
Come appare il confronto in pratica
Un fornitore con dodici mesi di storia e ottanta studi clienti attivi si trova a dedicare circa sei ore a settimana di tempo ingegneristico a correzioni di estrazione — nuovi fornitori, nuove banche, scontrini in formati insoliti. A un costo interno approssimativo di ingegneria, questo si traduce in una cifra mensile ricorrente non trascurabile, che cresce ogni volta che lo studio acquisisce un nuovo gruppo di clienti.
| Voce | Costo interno tipico |
|---|---|
| Correzioni di estrazione, ~6 ore/settimana | Cresce con ogni nuovo cliente acquisito |
| Tempo perso su nuove funzionalità del prodotto | Difficile da quantificare, spesso il costo più alto |
| Rischio di un errore che raggiunge un cliente | Variabile, ma non nullo |
Il conto approssimativo dietro la decisione
A una tariffa fissa di €0,035 a pagina, uno studio con ottanta clienti che genera circa 1.500 pagine al mese di documenti fuori SDI paga circa €52,50 al mese in estrazione — una cifra che, confrontata con anche solo una frazione delle sei ore settimanali di ingegneria dedicate a mantenere il sistema interno, rende il confronto abbastanza chiaro da non richiedere un'analisi elaborata.
Il punto non è che costruire in casa sia sempre più caro in assoluto — è che il costo di costruire cresce con la varietà del portafoglio clienti, mentre il costo di un'API a consumo cresce solo con il volume di pagine, che è una curva molto più prevedibile e molto più facile da pianificare.
Cosa succede al team che l'ha costruito
Il team che ha costruito il sistema originale di solito non scompare né viene ridimensionato — si sposta. L'ingegnere che passava sei ore a settimana su correzioni di estrazione torna a lavorare su funzionalità del prodotto, spesso proprio quelle che erano rimaste indietro durante il periodo in cui il parser assorbiva sempre più attenzione. Questo spostamento è di solito la parte del cambiamento più immediatamente visibile internamente, ben prima che il beneficio per i clienti dello studio diventi altrettanto evidente.
Curiosamente, il morale del team tende a migliorare più in fretta di quanto ci si aspetterebbe — mantenere un parser interno frustrante non era mai stato il lavoro che gli ingegneri avevano immaginato di fare quando si erano uniti al progetto, e tornare a costruire funzionalità visibili ai clienti è quasi sempre percepito come un miglioramento, non come una sconfitta.
Chi continua a costruire, giustamente
Non ogni fornitore dovrebbe passare a un'API, e vale la pena essere onesti su chi non dovrebbe. Un fornitore con un portafoglio clienti genuinamente ristretto e omogeneo — per esempio, uno studio specializzato su un solo settore con fornitori ricorrenti — incontra molta meno varietà di documenti per definizione, e il costo di mantenimento del parser interno può restare basso indefinitamente. Allo stesso modo, un team con competenze OCR genuinamente specialistiche già in squadra, e un motivo strategico per possedere quella tecnologia, può fare una scelta diversa in modo consapevole.
Il modo più affidabile per distinguere questi due casi non è la dimensione del fornitore in sé, ma la traiettoria del portafoglio clienti: se la varietà di banche e fornitori incontrata cresce con ogni nuovo cliente, lo schema descritto in questo articolo si applica prima o poi; se invece resta sostanzialmente stabile anno dopo anno, il calcolo può restare a favore di costruire.
Miti da abbandonare
"Un'API esterna è meno accurata di ciò che controlliamo noi"
Nella pratica è spesso il contrario — un fornitore la cui unica attività è l'estrazione documenti investe in quella precisione in modo continuo, cosa che un team interno con priorità concorrenti raramente riesce a sostenere allo stesso ritmo.
"Passare significa ripartire da zero"
Lo schema dati e la comprensione dei propri requisiti, accumulati costruendo la versione interna, restano validi e velocizzano notevolmente l'integrazione di un'alternativa esterna.
"I nostri clienti hanno esigenze troppo particolari per un servizio generico"
Un'API costruita per generalizzare sulla struttura reale dei documenti, non su un modello fisso, gestisce la varietà proprio nel modo in cui un parser interno costruito per pochi casi non riesce a fare.
Segnali precoci da tenere d'occhio
| Segnale | Cosa di solito significa |
|---|---|
| Segnalazioni di bug crescenti, specifiche per cliente o fornitore | Il parser interno sta raggiungendo il limite della propria copertura |
| Un ingegnere passa più tempo su correzioni che su nuove funzionalità | La tassa di manutenzione ha superato la soglia di attenzione ragionevole |
| L'onboarding di un nuovo cliente richiede sempre lavoro di adattamento | L'estrazione non generalizza abbastanza per gestire acquisizioni future senza attrito |
| Un cliente lamenta un errore di estrazione ricorrente | Il problema è ormai visibile fuori dal team, non solo internamente |
Cosa costa davvero il passaggio
Il lavoro di integrazione tecnica in sé — chiamare un'API, mappare il JSON sul modello dati esistente — è di solito la parte più piccola e più prevedibile del progetto, spesso questione di giorni piuttosto che di settimane. La parte più grande e più variabile è disfare tutto ciò che, nel sistema interno, era diventato strettamente legato alle peculiarità specifiche del parser proprietario e ai casi particolari accumulati cliente per cliente nel corso del tempo — codice che va identificato e rimosso con cura, non semplicemente lasciato lì accanto alla nuova integrazione.
Un approccio che funziona bene in pratica è migrare un tipo di documento alla volta, cliente per cliente, invece di tentare un taglio netto su tutto il portafoglio in una sola volta — questo permette al team di verificare che l'alternativa esterna si comporti come atteso su un sottoinsieme controllato prima di impegnare l'intero volume di produzione, e riduce il rischio che un problema di migrazione diventi visibile a tutti i clienti dello studio contemporaneamente.
Cosa verificare prima di scegliere a chi passare
Prima di impegnare volume di produzione su qualunque fornitore di estrazione, vale la pena porre alcune domande dirette: il sistema generalizza davvero sulla struttura del documento, o è comunque calibrato su una lista fissa di formati supportati? La valuta e i riferimenti vengono restituiti come stampati sul documento, o convertiti con una logica opaca? La validazione aritmetica dei saldi è inclusa, o solo estrazione di testo grezzo? Esiste un livello gratuito genuino per pilotare su documenti reali di più clienti prima di impegnarsi? Un fornitore che non risponde chiaramente a queste domande merita un secondo sguardo prima di ricevere volume di produzione.
Vale anche la pena chiedere esplicitamente cosa succede quando un documento non viene letto bene — un fornitore serio restituisce un indice di affidabilità basso invece di restituire un valore indovinato con apparente sicurezza. La differenza tra i due comportamenti è invisibile finché non serve, ed è esattamente il momento in cui conta di più.
Come arrivarci preparati
Un fornitore che sta ancora costruendo la propria estrazione, e che vuole evitare di arrivare impreparato al momento del ripensamento, può fare due cose fin da subito: tracciare esplicitamente il tempo di ingegneria speso in correzioni di estrazione, invece di lasciarlo diluito in un generico "manutenzione", e testare periodicamente il proprio parser contro un'API esterna su un campione reale, così il confronto è già pronto quando la domanda emerge, invece di dover essere costruito da zero sotto pressione.
Un terzo passo, meno ovvio ma altrettanto utile, è fissare in anticipo una soglia esplicita — per esempio, un numero di ore settimanali di correzioni oltre il quale la domanda va posta formalmente al team, invece di lasciarla emergere da sola quando qualcuno finalmente se ne accorge. Avere quella soglia scritta da qualche parte, concordata prima che il problema diventi urgente, rende la decisione successiva molto meno carica di emotività.
Il numero di clienti serviti cambia lo schema?
Sì, in modo prevedibile — più clienti significano più varietà di documenti, il che significa una tassa di manutenzione che cresce più in fretta rispetto a un gestionale per una singola azienda. Un fornitore che serve dieci studi incontra questo schema più lentamente di uno che ne serve duecento, ma la direzione è la stessa: la crescita commerciale accelera, non rallenta, il momento in cui la domanda "dovremmo continuare a costruirlo noi?" diventa inevitabile.
Questo vale anche nella direzione opposta: un fornitore che riesce a rallentare deliberatamente la propria crescita in varietà di clienti — per esempio specializzandosi su un settore più ristretto — può posticipare genuinamente il momento del ripensamento, non solo rimandarlo sulla carta. Non è la scelta più comune, ma è una scelta legittima per chi preferisce un mercato più piccolo ma più omogeneo a uno più ampio ma più vario.
Cosa potrebbe cambiare col tempo
Vale la pena guardare anche alla traiettoria, non solo allo stato attuale. Man mano che sempre più documenti nascono digitali fin dall'origine — fatture elettroniche in più paesi, estratti conto sempre più spesso esportati in formati strutturati dalle banche stesse — la superficie di documenti che restano genuinamente non strutturati potrebbe ridursi nel tempo. In Italia, tuttavia, lo SDI copre solo le fatture B2B tra soggetti IVA: estratti conto, scontrini, fatture estere e note spese restano, per il prevedibile futuro, documenti che un software per studi deve saper leggere da PDF o da scansione, indipendentemente da quanto la digitalizzazione avanzi altrove.
In sintesi
Costruire la propria estrazione documenti è quasi sempre la scelta giusta per iniziare, e ripensarla più tardi non è un fallimento — è il risultato prevedibile di un successo commerciale che porta varietà di documenti a un ritmo che un parser interno, costruito per un portafoglio più piccolo e più omogeneo, non è mai stato progettato per assorbire. Riconoscere lo schema in anticipo — e sapere quali segnali osservare — è ciò che distingue un passaggio pianificato con calma da uno fatto sotto pressione, dopo che un cliente importante ha già notato il problema.