Tenere fuori i dati cattivi

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 2 di 6 del capitolo Qualità e governance dei dati, capitolo 5 del corso Data Architect. Ogni modulo si regge da solo. Precedente: La governance si progetta dentro la org · Successivo: Conosci i tuoi dati

La domanda a cui risponde questo modulo: Come si mantengono buoni i dati, e come restano tali?

Ci sono due modi di affrontare i dati cattivi: fermarli prima che entrino, o ripulirli dopo. Farai un po’ di entrambe le cose. Ma potendo scegliere, preferisco prevenire il problema piuttosto che costruire un’organizzazione per ripulirlo all’infinito. Duplicati, identificatori sbagliati, informazioni mancanti, valori non standard, utenti che modificano campi di proprietà di un altro sistema, integrazioni che sovrascrivono dati buoni con dati cattivi: tutto diventa il progetto di pulizia di qualcuno. Quindi la domanda di progettazione è quali dati cattivi posso ragionevolmente tenere fuori fin dall’inizio? E “ragionevolmente” conta, perché la risposta non è bloccare ogni campo finché il sistema diventa inutilizzabile.

“Abbastanza buono” è una definizione di business

Prima di prevenire i dati cattivi, definisci quelli buoni. Non c’è un’unica definizione. Buono può significare abbastanza completo per far girare il processo, abbastanza accurato per decidere, abbastanza aggiornato per il carico di lavoro, abbastanza coerente per combinarlo con altri sistemi, abbastanza unico da sapere di quale cliente parliamo, abbastanza standard per l’automazione, abbastanza tracciabile da sapere da dove viene. Dipende dai dati. Se Steve Trucking fattura a un Partner retail, l’identità legale del partner deve essere giusta. Se un commerciale prende appunti dopo una riunione, nessuno ha bisogno di un comitato che approvi ogni frase. “Abbastanza buono” è una definizione di business; l’architetto la rende misurabile e applicabile.

Previeni gli errori costosi

Non ogni campo sbagliato merita la stessa attenzione. Mi interessano di più gli errori con conseguenze a valle. Un cliente duplicato significa due storici di vendita, due storici di assistenza, due insiemi di contatti, due ID esterni, due integrazioni che sincronizzano la stessa azienda, due versioni nel data warehouse e in Data 360, e alla fine un agente che decide quale cliente è quello vero. È molto più costoso di un refuso in una descrizione. Quindi non partire da “come convalidiamo ogni campo?”. Parti da quali dati cattivi creano il problema di business o architetturale più grande? e metti lì i controlli più forti.

Aperta o bloccata?

La creazione degli account è l’esempio classico. Ogni commerciale dovrebbe poter creare un account? La mia risposta: dipende dalla governance intorno ai dati. Per la maggior parte delle org piccole e medie, la creazione aperta va bene. Un commerciale incontra un potenziale cliente, crea l’account, si mette al lavoro; è a questo che serve un CRM. Regole duplicati, informazioni obbligatorie e stewardship gestiscono la qualità. Non aggiungo un pesante processo di approvazione solo perché la governance suona responsabile.

Ora cambia il panorama. Il cliente legale è gestito come dato master nell’ERP, arriva in Salesforce con un identificatore dell’ERP, e l’ERP è autorevole. Ora creazione aperta significa due modi di creare la stessa entità governata. Quando l’ERP e un commerciale creano entrambi la stessa azienda, quale vince, quale identificatore usano le integrazioni, quale record contiene lo storico? La creazione aperta smette di essere una questione di usabilità e diventa una questione di dati master. Quando gli account sono gestiti come dati master in un ERP o sincronizzati con esso, blocca la creazione.

Ma anche bloccarla del tutto fallisce. Il commerciale ha incontrato un potenziale cliente che non è nell’ERP e vuole aprire un’opportunità, e il modello di governance dice “niente account per te”. Così aspetta tre giorni la Finanza, o aggancia l’opportunità all’account sbagliato, o tiene il potenziale cliente in un campo note o in un foglio di calcolo. Abbiamo protetto il modello dati e danneggiato il business.

La via di mezzo: un tipo di record provvisorio

Ecco la via di mezzo che mi piace. Lascia che le vendite creino l’account con un tipo di record specifico, un tipo potenziale cliente o provvisorio, e controlla la sua conversione nel tipo governato. Le vendite registrano l’azienda e iniziano a vendere. Il record dice chiaramente: non ancora stabilito nel sistema autorevole. Poi un processo controllato lo converte: la Finanza lo approva, o un’integrazione lo sottopone all’ERP, che lo abbina a un cliente esistente o ne crea uno nuovo e rimanda l’identificatore autorevole. Ora il record attraversa un confine, provvisorio → governato, il che è molto diverso da due sistemi che creano ciascuno quello che credono sia il record master.

Il tipo di record è il meccanismo che insegno. Qualunque cosa usi, rendi visibile lo stato nei dati: da dove viene il record, se ha attraversato il confine, chi può modificarlo ora, e l’identificatore che lo lega al sistema autorevole. L’ID cliente dell’ERP, che esiste solo dopo la conversione, è il segnale più chiaro di tutti.

Un tipo di record per ogni flusso

Metti l’intero flusso in un’unica immagine e vedrai perché funziona. Clienti e prodotti arrivano in entrata dall’ERP. Le opportunità e le loro voci escono in uscita e diventano gli ordini dell’ERP. E gli account? Alcuni entrano, altri escono. Per questo uno schema comune che ho visto in diverse implementazioni sono due tipi di record sull’Account, uno per ogni direzione. Un account Sales nasce in Salesforce: i commerciali lo creano, lo modificano, gli vendono, e quando diventa cliente viene inviato all’ERP. Un account ERP (l’ho chiamato Customer, o semplicemente SAP) nasce nell’ERP ed entra tramite l’integrazione. Nessuno crea quel tipo di record tranne l’integrazione, e i suoi campi di dati master (ragione sociale, indirizzi, condizioni di pagamento) sono di sola lettura per gli utenti. Il tipo di record ti dice in che direzione scorre il record, quindi la direzione della gestione dei dati master è lì, sul record.

Click to enlarge

Un tipo di record per ogni flusso: gli account Sales escono, gli account ERP entrano.

Il caso difficile non sparisce. Un commerciale converte un lead per Steve’s Plumbing, ma Steve’s Plumbing esiste già come account ERP, e in qualche modo il controllo dei duplicati non l’ha intercettato. Ora stai unendo i record, riassegnando i figli e decidendo quale record sopravvive (capitolo 6, modulo 3).

E non fissarti sul tipo di record in sé. Di solito evito i tipi di record, a meno che non ci sia un motivo forte. Qui li ho usati perché, prima dei Moduli dinamici (Dynamic Forms), il tipo di record sceglieva il layout di pagina, e un layout mostrava i campi dell’ERP in sola lettura. Con i Moduli dinamici, le regole di visibilità possono mostrare e nascondere i campi in base al valore di un campo, un campo può essere di sola lettura su una data pagina, e Salesforce stessa dice che i Moduli dinamici riducono il numero di layout di pagina e di tipi di record che ti servono (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab), in inglese). Ma di sola lettura su una pagina significa di sola lettura su quella pagina: l’API, un caricamento di dati o un’integrazione possono ancora scrivere il campo. La vera applicazione è la sicurezza a livello di campo o una regola di convalida; la convalida nell’interfaccia non è convalida dei dati (capitolo 3, modulo 9). I tipi di record si guadagnano ancora il loro posto quando i due tipi di account hanno bisogno di valori di elenco di selezione o processi di business diversi. Ciò che conta davvero è che qualche campo dica chiaramente da dove viene il record: la chiave dell’ERP stessa, un flag di dati master o un elenco di selezione dell’origine. Poi fai dipendere la modificabilità da quel campo.

Click to enlarge

Da provvisorio a governato: le vendite iniziano subito a vendere; solo il processo autorevole rende governato il record.

Proteggi il record governato

Una volta che il cliente torna dall’ERP, il suo ID ERP, la ragione sociale, il codice fiscale e i dati di fatturazione sono attributi governati. Il commerciale dovrebbe modificarli? No, se li possiede l’ERP. È la politica del modulo 1 che ha bisogno del suo punto di applicazione: l’ID ERP in sola lettura, l’identità legale controllata, mentre il commerciale modifica ancora territorio, note sulla relazione e le classificazioni proprie di Salesforce. L’obiettivo non è un account intoccabile. È una linea chiara tra i dati che Salesforce possiede e i dati che Salesforce referenzia. (Il prefisso erp_ del capitolo 4 rende visibile quella linea nello schema.)

Quello che ottieni alla fine è un golden record che in realtà è ibrido. I campi di dati master dell’ERP entrano: ragione sociale, indirizzi di fatturazione e di spedizione, condizioni di pagamento. Poi Salesforce aggiunge i propri campi che non tornano mai indietro: una valutazione commerciale, la data dell’ultimo ordine, praticamente tutto ciò che usa il marketing. Stesso account, due tipi di campo, e ogni tipo ha una sola origine.

La cosa più difficile sono i bidirezionali. Supponi che un commerciale abbia bisogno di cambiare la ragione sociale nell’ERP da Steve’s Plumbing a Steve’s Plumbing LLC. In quegli stessi cinque minuti, qualcuno nell’ERP la cambia in Steve’s Plumbing L.L.C. Quale modifica vince? Ecco la mentalità: se un campo è gestito come dato master nell’ERP, non stai cambiando il campo, stai chiedendo di cambiarlo. Decidi cosa succede quando la richiesta entra in collisione: vince l’ERP, la richiesta viene rifiutata se nel frattempo il valore è cambiato, oppure attende che una persona la risolva. E decidi se i campi correlati viaggiano insieme come un’unica modifica o uno alla volta. Il capitolo 6 approfondisce le collisioni (Loop e collisioni).

Ferma i duplicati alla porta

I duplicati si accumulano. Intercettane uno prima che venga creato ed è un piccolo problema. Trovalo due anni dopo, con opportunità, casi, contatti, fatture, integrazioni e analisi appesi a entrambi, ed è un grande problema. Il modulo 7 del capitolo 3 ha trattato i meccanismi (regole di corrispondenza, regole duplicati, ID esterni univoci), quindi non li rispiego. La domanda di governance è dove dobbiamo impedire la duplicazione, e dove la tollereremo per risolverla più tardi? Un lead di marketing occasionale può convivere con l’ambiguità. Un cliente governato dall’ERP con transazioni finanziarie no.

Standardizza ciò che leggono le macchine

Il testo libero è meraviglioso per le persone e terribile quando un sistema deve interpretarlo. Metti Arizona, AZ, Ariz., Phoenix area e Southwest in un campo che guida l’assegnazione dei percorsi, e hai un problema di qualità. Se un valore guida automazione, integrazione, reportistica, sicurezza, assegnazione o l’azione di un agente, pensa bene a quanto deve essere standard. Non ogni campo di testo diventa un elenco di selezione, ma distingui le informazioni che leggono le persone da quelle su cui decidono le macchine. Le seconde meritano un controllo più forte.

Non lasciare che i campi obbligatori creino dati finti

Decidiamo che un campo conta e lo rendiamo obbligatorio. L’utente non conosce la risposta, il sistema non lo lascia proseguire, così scrive N/A, Unknown, 999999 o test@test.com. Il campo è compilato; il dato è spazzatura. Prima di rendere obbligatorio qualcosa, chiediti se l’utente lo conosce davvero in quel momento. Se no, rendilo obbligatorio più avanti nel processo, lascia che lo fornisca un altro sistema, usa lo stato provvisorio, o offri un esplicito Sconosciuto quando sconosciuto è una risposta legittima. Una regola di convalida può far rispettare una politica. Non può far sapere a qualcuno ciò che non sa.

Ogni confine dei dati ha bisogno di una decisione sulla qualità

Le persone non sono l’unica fonte di dati cattivi; le integrazioni li producono più in fretta. Il manifesto di carico di un Partner retail arriva con qualche centinaio di righe. Una manciata ha codici postali non validi, un paio indicano un centro di distribuzione sconosciuto, due ripetono lo stesso riferimento d’ordine. Cosa succede? Rifiutiamo l’intero file? Accettiamo le righe buone e restituiamo quelle cattive? Carichiamo tutto e ripuliamo dopo? Mettiamo in quarantena le eccezioni? Chi viene avvisato, e come scopre il partner cosa è fallito? Non c’è una risposta universale, ma una risposta ci deve essere. Il capitolo 4 diceva che ogni freccia ha bisogno di un meccanismo. Aggiungi: ogni confine dei dati ha bisogno di una decisione sulla qualità: cosa accettiamo, rifiutiamo o mettiamo in quarantena, e chi è responsabile dell’eccezione.

Click to enlarge

Ogni confine dei dati ha bisogno di una decisione sulla qualità.

I dati storici sono diversi

RouteDesk contiene otto anni di storico di Steve Trucking, e la sua qualità varia da un centro di distribuzione all’altro. Dovremmo ripulire tutti gli otto anni secondo lo standard di oggi prima di spostarli? Probabilmente non automaticamente. A cosa servono: operazioni quotidiane, consultazione, reclami, reportistica, analisi delle tendenze? Devono stare tutti in Salesforce, o una parte può restare altrove? Il capitolo sulla migrazione approfondisce. Il punto di governance: lo storico non ha automaticamente bisogno dello stesso standard dei dati attivi. Se ci prenderai decisioni, la qualità conta. Se lo conservi per consultazione, può bastare uno standard diverso. Sappi lo scopo prima di spendere una fortuna per ripulire il passato.

Misura ciò su cui qualcuno agirà

La governance non è mai finita, quindi devi vedere quando la qualità scivola: tassi di duplicazione in aumento, più record in quarantena, più rifiuti dalle integrazioni, valori segnaposto che si diffondono, più richieste di esclusione, report che non tornano più. Ma non costruire 150 metriche per ignorarne 143. Per Steve Trucking forse sono le consegne senza un riferimento valido del partner, le consegne senza un indirizzo utilizzabile, i riferimenti d’ordine ripetuti, i messaggi rifiutati dai partner, gli account bloccati nello stato provvisorio. Un dashboard pieno di cerchi verdi non significa che i dati siano buoni. Misura ciò su cui qualcuno è pronto ad agire.

Oltre l’esame: cosa cambia l’IA. I dati cattivi diventano sempre più spesso azioni sbagliate. Una persona potrebbe accorgersi che un numero di telefono sembra sbagliato prima di chiamarlo; un agente usa semplicemente il valore che riceve. Clienti duplicati, stati non aggiornati, valori obbligatori finti e identificatori sbagliati si trasformano direttamente nel messaggio sbagliato o nell’aggiornamento sbagliato. Questo alza il valore della prevenzione. Non elimina il bisogno di stewardship.

Cosa decide qui un architetto

• Quali difetti di qualità fanno abbastanza danni da giustificare controlli preventivi.
• Se i record governati si creano liberamente, solo dal sistema autorevole, o attraverso un percorso da provvisorio a governato.
• Quali attributi Salesforce possiede e quali si limita a referenziare.
• Cosa succede ai dati in entrata che non superano i controlli (accettati, rifiutati o messi in quarantena) e chi è responsabile dell’eccezione.
• Quali segnali di qualità si misurano, perché gli steward vedano lo scivolamento.

Non impedirai mai ogni record cattivo. Il lavoro non sono dati perfetti; è evitare che dati cattivi evitabili diventino dati costosi. Ferma il duplicato prima che abbia due anni di storico. Proteggi l’identificatore prima che dieci integrazioni dipendano da quello sbagliato. Lascia che le vendite creino il potenziale cliente, ma non fingere che sia il cliente governato finché non lo è. E quando qualcosa di cattivo passa, assicurati che qualcuno possa vederlo, prenderlo in carico e correggerlo.

Per approfondire

• Guida di Salesforce, Things to Know About Duplicate Rules (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Guida di Salesforce, Break Up Your Record Details with Dynamic Forms (opens in a new tab) e Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (in inglese), consultato il 2026-10-14.