Efficacia della responsabilità
Ogni asset critico del tuo catalogo ha un owner, uno steward e un approvatore. I nomi sono compilati. I workflow continuano a instradare verso di loro. La domanda di questa pagina è quella a cui il catalogo non sa rispondere: se oggi quell'asset ha bisogno di una decisione, la persona indicata può davvero agire?
Che cosa significa efficace
L'assegnazione è un record. L'efficacia è uno stato, e ha tre condizioni — tutte vere contemporaneamente, oggi:
01
Attiva
02
Autorizzata
03
Capace di agire
Se ne manca anche solo una, nulla si rompe in modo visibile. L'asset mostra ancora un owner. Il workflow continua a instradare. Il fallimento emerge settimane dopo, sotto forma di una revisione scaduta e di una decisione che nessuno ha preso.
Ecco perché, nel nostro modello, una responsabilità non è mai semplicemente presente o assente:
L'assegnazione è il secondo di questi quattro stati, non l'ultimo. Un campo del catalogo registra il secondo passaggio e dà per scontato il quarto.
Oggi · invisibile
AdventureWorks2025 — HumanResources data product, in uso nelle operazioni HR, nelle buste paga e nella pianificazione della forza lavoro. Quattro ruoli ne rispondono. Ognuno di essi è compilato, e il catalogo non mostra alcun problema.
Proprietario · e approvatore
Hedda M Halvorsen
uscita · entrambi i ruoli se ne sono andati con lei
Steward dei dati
Mindy C Martin
mandato non riconvalidato da maggio 2024
Esperto in materia
Lakshmi A Venkatesan
in congedo · nessuna copertura
Esperto in materia
Ashok X Joshi
assegnato · mai informato
Quattro fallimenti diversi, e nessuno di essi è un dato mancante. Ogni nome era corretto quando è stato scritto. Nulla è bloccato, ed è proprio questo il problema — l'asset viene instradato verso qualcuno che se n'è andato, verso qualcuno il cui mandato è scaduto, verso qualcuno che è assente, e verso qualcuno che non è mai stato informato. Qualsiasi decisione che richieda uno di questi quattro non ha dove approdare, e nulla, da nessuna parte, lo segnala.
Nota che cosa ha causato una sola uscita. Hedda ricopriva due dei quattro ruoli — cosa normale, perché chi è owner di un asset è di solito anche chi ne approva le modifiche. Quando se n'è andata, metà della governance di questo prodotto se n'è andata con lei — e l'asset la indica ancora in entrambi i ruoli, quindi tutto ciò che richiede l'uno o l'altro viene ancora instradato verso qualcuno che non c'è più.
Il secondo esperto è quello su cui vale la pena soffermarsi. Ashok è in organico, autorizzato, e ha l'accesso. Nulla, in nessun sistema, è obsoleto. Semplicemente, nessuno lo ha mai informato che questo asset viene instradato verso di lui quando l'altro esperto è assente — e nessun report, da nessuna parte, è in grado di mostrarlo.
Ecco come appare dall'interno il degrado della governance: non un campo vuoto, ma un campo compilato che ha smesso di essere vero.
Perché il catalogo non può vederlo
In un catalogo · un attributo
Testo su un asset, che punta a una persona di cui l'asset non sa nulla. Il suo rapporto di lavoro, la sua area, le sue autorizzazioni vivono in altri tre sistemi, e il campo non ha modo di chiedere loro nulla.
Un campo non può essere sbagliato, perché un campo non può essere verificato.
In Nodwise · una relazione tipizzata
Tra due nodi che esistono entrambi nello stesso modello — l'asset e la persona. E non si configura asset per asset: ogni tipo di nodo porta con sé la propria matrice delle responsabilità, così un nodo nasce sapendo quali ruoli ne rispondono, e chi li ricopre in questo momento si risolve attraverso il grafo.
Quella matrice dichiara, per ogni ruolo, che cosa ci si aspetta da chi lo ricopre e che cosa qualifica qualcuno a ricoprirlo. Così «data owner» non è un titolo preso in prestito da un documento di policy — è un insieme definito di aspettative e un requisito definito, scritti una volta ed ereditati da ogni nodo di quel tipo.
Il che significa che le tre condizioni smettono di essere un esercizio di audit e diventano un attraversamento:
Dipartimento
Human Resources
Persona
Hedda M Halvorsen
Persona
Mindy C Martin
Persona
Ashok X Joshi
Ruolo aziendale
Human Resources Manager
Ruolo aziendale
Benefits Specialist
Ruolo aziendale
Recruiter
Prodotto dati
HumanResources data product
Tre domande che il catalogo può porre solo a un essere umano, a cui si risponde percorrendo il modello.
Il ciclo
Una volta che la responsabilità è una relazione, una responsabilità inefficace è una condizione che un agente può tenere sotto osservazione. Ciò che segue non è un report che devi leggere.
01
Rilevato
02
Instradato verso chi può decidere
03
Deciso da una persona
04
Registrato
E lo stesso ciclo si attiva prima che la lacuna si apra — per impostazione predefinita, non come qualcosa da configurare. Una responsabilità ha un proprio stato, quindi può essere sospesa senza essere cancellata: quando qualcuno cambia area, va in congedo o rinuncia a un incarico, le responsabilità che porta con sé escono dallo stato effettivo e la domanda raggiunge quella persona quando ha ancora il contesto per rispondere, anziché raggiungere il suo ex team sei mesi dopo.
Il che fornisce anche la versione onesta della domanda con cui si apre questa pagina. Non «c'è un owner?» ma quando è stato confermato l'ultima volta che è vero — una data, per ogni responsabilità, che esiste oppure no.
L'agente osserva ed effettua escalation. Non decide mai. Autonomia dell'attenzione, non dell'autorità.
Cosa costa normalmente
Affrontata come progetto, la pulizia delle responsabilità inefficaci in un catalogo maturo si articola in otto fasi: identificare i titolari inattivi, associare ogni caso a un manager, raggrupparli in una vista per ogni responsabile, notificare con contesto e una scadenza, eseguire un workflow di sostituzione tracciabile, inserire i nuovi titolari, certificare quelli la cui area è cambiata e, infine, trovare i flussi che dipendono da una sola persona.
È un lavoro competente, ed è il motivo per cui questo problema di solito viene rimandato: richiede mesi, richiede di riconciliare a mano tre sistemi sorgente, e il risultato è accurato il giorno in cui viene consegnato.
Ognuna di queste fasi è una query o un workflow su un modello che contiene già la risposta. Non perché il lavoro sia banale, ma perché la riconciliazione a cui il programma dedica la maggior parte del suo tempo è esattamente ciò che il modello è.
Poni la domanda più difficile
Il tenant demo contiene l'asset, i quattro ruoli, le condizioni violate e la query che le segnala — in un modello che puoi aprire subito.