L’aspettativa comune durante la gestione dei flussi informativi nella transizione verso un sistema CRM è l’istantaneità: l’idea che un insieme di fogli di calcolo possa essere riversato in un database relazionale e produrre immediatamente valore. Nella realtà dei fatti la gestione del dato senza una fase di normalizzazione preventiva si limita ad automatizzare e amplificare il disordine strutturale, inficiandone l’utilità nel tempo.

Il dato grezzo, nell’istante in cui risiede nei fogli di calcolo dell’organizzazione, è quasi sempre affetto da un vizio d’origine: è strutturato per la decodifica dell’occhio umano e non per l’elaborazione di una macchina. Questo principio si applica sia a chi sta pianificando l’adozione di un software avanzato (come CiviCRM), sia a chi intende semplicemente mantenere la propria base dati su fogli Excel o Google Sheets in modo sicuro e scalabile.

L’illusione del foglio di calcolo “ordinato”

Un foglio di calcolo definito ordinato da chi lo ha compilato spesso basa il proprio significato su elementi visivi e contestuali: righe evidenziate in rosso per indicare i donatori ricorrenti morosi, celle in corsivo per i contatti da richiamare, note testuali a margine per tracciare lo storico delle relazioni.

Questo modello presenta tre criticità sistemiche per la governance e la tenuta del dato:

1. Perdita delle informazioni visive e strutturali: l’algoritmo di importazione di un CRM, o qualsiasi sistema di analisi automatica, mappa esclusivamente i campi di testo e numerici, ignorando le proprietà grafiche (colori, stili o formattazioni condizionali). Per la macchina una cella rossa e una cella bianca contenenti lo stesso testo sono identiche. Se il motivo dell’evidenziazione non è tradotto in un valore testuale o numerico esplicito, quell’informazione svanisce durante qualsiasi transizione o elaborazione esterna.
2. Dipendenza dal fattore umano (assenza di autosufficienza): il dato deve essere indipendente dal suo autore e comprensibile a chiunque senza bisogno di spiegazioni verbali. Se il significato di un file è depositato esclusivamente nella memoria storica della persona che lo ha configurato, non siamo in presenza di un asset informativo aziendale, ma di un registro di appunti personale ad alto rischio di obsolescenza in caso di turnover o assenza della risorsa.
3. Decadimento dei metadati e delle formule operative: le note inserite a margine della casella (i commenti fluttuanti di Excel) o le formule logico-matematiche (come =SOMMA(...)) non hanno corrispondenza diretta nella struttura di un database relazionale. Il database importa esclusivamente valori scalari puri. La nota fluttuante attaccata a una cella viene scartata dal processo di impot perché l’architettura della tabella di destinazione non prevede un campo destinato a ospitare annotazioni strutturalmente isolate. Le formule vengono appiattite al loro valore statico finale registrato al momento del salvataggio, o generano interruzioni del flusso se il file contiene stringhe di errore (es. #VALORE!).

La svalutazione della tipizzazione (data typing)

Un elemento di frizione ricorrente risiede nell’incomprensione della natura della casella, ovvero il tipo di dato (stringa, intero, decimale, data) richiesto per un’elaborazione corretta. Se in un foglio di calcolo ad uso personale la gestione dei tipi è permissiva, nei sistemi strutturati e negli automatismi relazionali rappresenta un vincolo rigido e non negoziabile.

L’errore sistemico si manifesta nella gestione degli identificativi, dei contatti e dei campi tecnici:

• La distruzione dello zero iniziale: se un campo destinato a ospitare numeri di telefono, prefissi o Codici di Avviamento Postale (CAP) viene trattato dall’applicazione (Excel o Sheets) come “Numero”, il sistema applica le regole matematiche standard, eliminando lo zero iniziale. Il CAP 00100 viene convertito nel numero 100, provocando la corruzione irreversibile dell’informazione prima ancora dell’importazione o della segmentazione.
• Mancanza di omogeneità della colonna: un tracciato dati sicuro richiede che l’attributo sia identico per tutta la colonna. Non è ammesso che nella colonna “Data di nascita” o “Data donazione” coesistano record formattati come DD/MM/YYYY, stringhe testuali come Metà Maggio o numeri seriali arbitrari. La mancata normalizzazione preventiva della natura del campo comporta il rigetto del record o il troncamento del dato in fase di esecuzione.
• L’inquinamento testuale dei campi funzionali: l’inserimento di annotazioni operative o note di processo all’interno di una cella destinata a un valore standardizzato corrompe l’integrità del record. L’anomalia tipica è la presenza di stringhe come contatto@email.com (non inviare email massive) all’interno della colonna email. Per l’occhio umano, il testo tra parentesi è un’istruzione chiara; per la macchina, l’intero blocco diventa una stringa invalida che fallisce la validazione sintattica del pattern di posta elettronica. Il risultato è il rigetto del contatto o il blocco dei motori di invio e degli orchestratori di flussi. Le regole di business (come il diritto di opt-out) devono essere mappate su campi booleani (Vero/Falso) o attributi dedicati, mai fuse con il dato tecnico principale.

Il principio di atomicità della cella

Un ulteriore errore che blocca l’operatività è la saturazione della singola cella con informazioni eterogenee. L’anomalia tipica si riscontra nell’inserimento di due indirizzi email separati da una virgola nello stesso campo, o nella compressione di un indirizzo di residenza completo (via, civico, CAP, città) all’interno di un’unica stringa di testo.

I sistemi relazionali operano secondo logiche di atomicità: ad ogni colonna deve corrispondere un solo attributo specifico, standardizzato e catalogato.

• Implicazioni nei flussi: un campo anagrafico che contiene due email separate da una virgola invalida i motori di invio massivo, interrompe le routine di deduplica automatica e impedisce la corretta indicizzazione del database.
• Soluzione architetturale: la normalizzazione scompone l’informazione alla sorgente. La via diventa un attributo isolato, il numero civico un altro, e gli indirizzi email multipli popolano record distinti, legati all’anagrafica principale da una relazione logica uno-a-molti.

Riconciliazione multi-fonte e identificazione della chiave comune

Quando i dati provengono da sorgenti differenti (ad esempio, il software di contabilità, la piattaforma di donazioni online e un file Excel compilato durante un evento), l’intersezione dei record non può essere affidata a verifiche manuali posteriori.

È indispensabile individuare o generare un fattore comune, ovvero un identificativo univoco (ID) che funga da chiave di volta per l’unione dei file. Senza un ID condiviso o una regola rigida di pulizia preventiva dei campi chiave (come l’estrazione e la validazione dei codici fiscali o la standardizzazione dei registri dei nomi), l’unione dei tracciati genera una duplicazione massiva dei profili o la sovrascrittura distruttiva di dati non omogenei.

Cognizione umana vs. Analisi computazionale

Per comprendere la necessità della modellazione, occorre mappare le differenze strutturali tra il modello cognitivo umano e l’elaborazione logica della macchina:

La co-progettazione come investimento e non come sovraccarico operativo

Dedicare sessioni di lavoro congiunte tra il progettista dei dati e i referenti dell’organizzazione non costituisce un rallentamento burocratico, bensì l’attività cardine dell’intera ingegneria dei processi. La modellazione e la mappatura preliminare servono a tradurre la conoscenza informale del cliente in uno schema rigido, scalabile e sicuro.

Bonificare il dato all’interno di un foglio di calcolo corrotto o all’interno del CRM dopo un’importazione massiva eseguita alla rinfusa comporta, in termini di ore uomo e di rischio di corruzione irreversibile, un costo nettamente superiore rispetto alla normalizzazione preventiva eseguita sul dato grezzo all’origine.

Principio di Governance (DAMA-DMBOK): La qualità del dato è una funzione della sua accuratezza, completezza e coerenza. Introducendo o mantenendo dati non normalizzati all’interno di un’architettura informativa, si automatizza e si amplifica l’inefficienza operativa, compromettendo la stabilità dei flussi e la sopravvivenza stessa del patrimonio informativo aziendale.