I consigli che già conosci sono corretti. Nomina un owner. Inizia in piccolo. Collegalo a un problema di business. Acquista software che si adatta.
Non è lì che i programmi muoiono. Muoiono nei meccanismi sottostanti: quel momento specifico quando una voce di catalogo va storta e nessuno la corregge, la riunione dove due dipartimenti scoprono di intendere cose diverse per "cliente", la fattura che arriva quando il tuo volume di dati triplica. Questo articolo parla di quei momenti, perché è lì che un'implementazione di data governance viene effettivamente vinta o persa.
La Previsione che Vale la Pena Leggere Attentamente
Gartner prevede che entro il 2027, l'80% delle iniziative di data governance fallirà. Viene citata ovunque, solitamente privata della parte che conta. È una previsione, non un risultato misurato, e Gartner dà una causa specifica: i programmi falliscono perché mancano di una crisi reale o creata ad hoc attorno a cui organizzarsi.
Leggilo come una diagnosi. Una governance creata per soddisfare un audit non ha una crisi dietro, quindi produce policy che nessuno applica. Una governance creata per fermare un problema che sta attualmente costando soldi a qualcuno viene utilizzata, perché qualcuno la sta controllando.
La figura spesso ripetuta secondo cui i dati difettosi costano a un'organizzazione 12,9 milioni di dollari all'anno merita lo stesso trattamento. È una stima del 2020, ancora recitata come attuale, senza una metodologia pubblicata dietro il numero tondo. Usala per indicare la direzione, non per dimensionare un budget. Il tuo tasso di duplicati e le ore di rielaborazione sono prove migliori di una media vecchia di cinque anni, e raccoglierle è la prima cosa utile che un programma fa.
Il Loop di Obsolescenza che Uccide i Cataloghi
Ecco il fallimento che ho descritto in una riga l'ultima volta, mostrato per intero, perché la riga nasconde l'intero problema.
Un catalogo è un insieme di affermazioni sui tuoi dati: cosa significa un campo, da dove viene, chi lo possiede. Quelle affermazioni diventano obsolete nel momento in cui un sistema sorgente cambia. Appare una nuova colonna. Una definizione si sposta. Una pipeline viene reindirizzata. Per restare veritiero, ogni uno di quei cambiamenti deve essere riflesso nel catalogo.
Se quella riflessione è manuale, qualcuno deve notare il cambiamento, aprire lo strumento e modificare la voce. Quel lavoro compete con tutto il resto nel loro piatto, e non ha una scadenza. Quindi scivola via. Poche voci diventano obsolete. Una persona colpisce una voce sbagliata, perde fiducia, e smette di controllare il catalogo. Una volta che smettono di controllare, nessuno nota la prossima voce sbagliata, e la deriva accelera. Entro il mese sei, il catalogo descrive un sistema che non esiste più.
Un catalogo non fallisce tutto in una volta. Fallisce una voce alla volta che rimane incustodita, e la prima voce sbagliata che un utente trova è quella che gli insegna a smettere di fidarsi.
La soluzione è l'automazione: raccolta di metadati, rilevamento di modifiche allo schema, voci che si aggiornano quando la fonte si sposta. Costa soldi. Il denaro ha bisogno di uno sponsor. E uno sponsor appare solo quando il programma è legato a una crisi di cui qualcuno si importa. Ecco perché la previsione di Gartner e il catalogo obsoleto sono lo stesso problema con due volti. Nessuna crisi, nessuno sponsor. Nessuno sponsor, nessuna automazione. Nessuna automazione, mantenimento manuale. Il mantenimento manuale scivola nel primo trimestre impegnato.
Quindi non acquistare un catalogo che manterrai a mano. Acquista la capacità di mantenerlo aggiornato, o governa un ambito più piccolo che puoi effettivamente mantenere veritiero.
Quando Due Dipartimenti Possiedono Entrambi "Cliente"
Questa riunione decide se la governance è reale, e la maggior parte dei rollout non la pianifica mai.
Sales intende un account, un'azienda che ti compra, mentre finance intende un'entità legale che paga le fatture, che potrebbe essere una società madre che copre tre account di Sales. Marketing intende una persona, un contatto nominativo che ha aperto un'email. La stessa parola porta tre definizioni in tre sistemi, e ognuna è corretta all'interno del dipartimento che la usa.
Il conflitto emerge il giorno in cui qualcuno costruisce un report su tutti e tre e i conteggi dei clienti non corrispondono. O una deduplicazione unisce due record che non sono mai stati la stessa cosa, perché la regola assumeva una definizione di "cliente" e i dati ne contenevano tre.
Un owner non risolve questo dichiarando un vincitore. Il meccanismo è più ristretto e più utile. L'owner costringe le definizioni a essere messe per iscritto, il che da solo termina metà della confusione, poiché i tre team solitamente non sapevano di non essere d'accordo. Quindi l'owner prende una decisione strutturale: è "cliente" un concetto con un attributo di tipo, o tre entità separate collegate da relazioni, un account che appartiene a un'entità che paga e contiene contatti? Quella decisione di modellazione è la governance effettiva. Tutto il resto a valle, come deduplicazione, reporting e accesso, ne consegue.
La governance non è il documento di policy. È avere una persona con l'autorità di terminare un argomento che altrimenti tornerebbe ogni trimestre.
La ragione per risolvere questo prima di acquistare software è che la risposta forma quello che hai bisogno che il software faccia. Tre entità collegate hanno bisogno di uno strumento con un modello di dati relazionale flessibile. Un concetto piatto ha bisogno di molto meno. Acquista prima, e potresti acquistare uno strumento che non può rappresentare la struttura su cui il tuo stesso business funziona.
In lavori che abbiamo visto su dati di prodotto e fornitore, lo stesso pattern si mostra a un livello inferiore: un "fornitore" in procurement è un "vendor" in finance e un "produttore" nel record del prodotto, e i tre venivano mantenuti in fogli di calcolo separati che silenziosamente non concordavano. Consolidarli su un unico modello di dati con relazioni definite è meno un compito software che una decisione su quale di quelle tre viste è la fonte di verità. Lo strumento applica solo la decisione una volta che è stata presa.
Leggi il Modello di Prezzo, Non l'Elenco delle Funzionalità
Gli elenchi di funzionalità convergono. I modelli di prezzo sono dove il costo a lungo termine si nasconde, e ti puniscono in un modo specifico: quasi ogni modello tassa la cosa che significa che il tuo programma sta funzionando.
La governance ha successo coprendo più dati, collegando più sistemi e ottenendo la partecipazione di più persone. Guarda cosa fa ogni asse di prezzo per quel successo.
- Per record.
Come esempio pratico, supponi che uno strumento costi una tariffa fissa per 10.000 record gestiti, e inizi con 40.000 record di prodotto. La fattura è piccola. La governance funziona, quindi incorpori dati dei clienti e assorbi il catalogo di un'acquisizione, e ora sei a 400.000 record. Il costo è dieci volte quello per cui ti sei iscritto, e a quel punto i tuoi workflow e le integrazioni si appoggiano sullo strumento, quindi andarsene è costoso. - Per fonte o connettore.
Inizi a governare quattro sistemi. Il successo significa estendere la governance su tutta la proprietà, e due anni dopo stai pagando per venti connettori. - Per utente.
Sembra conveniente finché non ricordi che la governance funziona solo quando gli steward in ogni dipartimento possono agire. Più il programma si diffonde, più utenti compri.
Ogni asse ti addebita di più proprio mentre hai successo. La mossa non è trovare un modello senza costi. È scegliere l'asse che puoi prevedere e controllare. Se il tuo conteggio di record è volatile e il tuo elenco di fonti è stabile, il prezzo per fonte è più sicuro, e il contrario vale ugualmente.
Sul software stesso, il mercato si divide in due. Le suite enterprise di grandi dimensioni come Collibra e Informatica gestiscono catalogazione ampia e lineage tra proprietà complesse, con prezzo e personale per correspondervi. Per i dati master come prodotti, fornitori e dati di riferimento, le piattaforme open source sono un punto di ingresso più leggero. AtroCore è una, con un modello di dati configurabile, accesso basato su ruoli e cronologia dei cambiamenti che coprono i meccanismi di governance core senza un contratto enterprise; si affianca a opzioni come Apache Atlas e OpenMetadata, ognuno più forte in un compito diverso. Crea una shortlist di due o tre e mettili alla prova usando il test sotto prima di impegnarti con qualsiasi modello di prezzo.
Cosa Un Pilota Espone che Una Demo Nasconde
Una demo di un vendor gira sui dati del vendor, e i dati del vendor sono puliti. Questa è l'intera ragione per cui la demo sembra impeccabile e ti dice quasi nulla.
Invece esegui il pilota sui tuoi record peggiori. Per la deduplicazione, questo significa alimentare lo strumento con il tuo vero elenco di clienti o fornitori, quello con "Acme Inc", "Acme, Inc." e "ACME INCORPORATED" come tre righe, più i refusi, i codici paese mancanti e l'azienda che legittimamente opera sotto due nomi. Poi etichetta manualmente alcune centinaia di quelle righe tu stesso così sai la risposta giusta, e misura lo strumento contro di esse.
Due numeri escono. Quanti veri duplicati ha catturato, e quante righe distinte ha erroneamente unito. Un'unione falsa è quella pericolosa, perché distrugge dati combinando due clienti che non sono mai stati la stessa cosa, e una demo pulita non la farà mai emergere. Quei due numeri ti dicono se il motore di matching funziona sui tuoi dati. Nulla di quello che il vendor ti mostra lo farà.
Fai lo stesso per qualsiasi meccanica importa di più nel tuo caso: un cambio di schema che il catalogo deve catturare, un workflow di approvazione sotto un carico realistico, una regola di accesso con un vero caso limite. Prova il pilot della cosa che si romperà, non della cosa che demo bene.
L'implementazione della data governance si riduce a una manciata di questi meccanismi. Mantieni il catalogo veritiero, risolvi le definizioni prima di modellare, prezza per la crescita che ti aspetti, e prova il pilot sui tuoi dati più sporchi. Fai quelli giusti, e il consiglio generico si prende cura di se stesso.