Eficacitatea responsabilității
Fiecare activ critic din catalogul dumneavoastră are un proprietar, un administrator de date și un aprobator. Numele sunt completate. Fluxurile de lucru sunt încă direcționate către ei. Întrebarea de care se ocupă această pagină este cea la care catalogul nu poate răspunde: dacă acel activ are nevoie astăzi de o decizie, poate persoana menționată acolo să acționeze efectiv?
Ce înseamnă eficace
Atribuirea este o înregistrare. Eficacitatea este o stare și are trei condiții — toate adevărate în același timp, astăzi:
01
Activ
02
Autorizat
03
Capabil să acționeze
Dacă lipsește oricare dintre ele, nimic nu se strică vizibil. Activul afișează în continuare un proprietar. Fluxul de lucru este în continuare direcționat. Eșecul iese la suprafață după câteva săptămâni, sub forma unei revizuiri care a expirat și a unei decizii pe care nu a luat-o nimeni.
De aceea, în modelul nostru, o responsabilitate nu este niciodată pur și simplu prezentă sau absentă:
Atribuirea este a doua dintre aceste patru trepte, nu ultima. Un câmp din catalog înregistrează a doua treaptă și o presupune pe a patra.
Astăzi · invizibil
AdventureWorks2025 — HumanResources data product, utilizat în operațiunile de HR, salarizare și planificarea forței de muncă. Patru roluri răspund pentru el. Toate sunt completate, iar catalogul nu semnalează nicio problemă.
Proprietar · și aprobator
Hedda M Halvorsen
a plecat · ambele roluri au plecat odată cu ea
Administrator de date
Mindy C Martin
mandat nerevalidat din mai 2024
Expert în domeniu
Lakshmi A Venkatesan
în concediu · fără înlocuitor
Expert în domeniu
Ashok X Joshi
atribuit · niciodată informat
Patru eșecuri diferite și niciunul nu înseamnă date lipsă. Fiecare nume era corect atunci când a fost scris. Nimic nu este blocat, și tocmai aceasta este problema — activul este direcționat către cineva care a plecat, către cineva al cărui mandat a expirat, către cineva care lipsește și către cineva care nu a fost niciodată anunțat. Orice decizie care are nevoie de unul dintre acești patru nu are unde să ajungă și nimic, nicăieri, nu semnalează acest lucru.
Observați efectul unei singure plecări. Hedda deținea două dintre cele patru roluri — ceea ce este normal, pentru că persoana care deține un activ este de obicei cea care aprobă modificările aduse acestuia. Când a plecat, jumătate din guvernanța acestui produs a plecat odată cu ea — iar activul o menționează încă în ambele roluri, așa că orice are nevoie de unul dintre ele este încă direcționat către cineva care nu mai este acolo.
Al doilea expert este cel asupra căruia merită să ne oprim. Ashok este angajat, autorizat și are acces. Nimic din niciun sistem nu este învechit. Pur și simplu nu a fost niciodată informat că acest activ este direcționat către el atunci când celălalt expert lipsește — și niciun raport, nicăieri, nu poate arăta acest lucru.
Așa arată degradarea guvernanței din interior: nu un câmp gol, ci unul completat care a încetat să mai fie adevărat.
De ce catalogul nu poate vedea asta
Într-un catalog · un atribut
Text pe un activ, care indică o persoană despre care activul nu știe nimic. Statutul de angajat, aria de activitate și drepturile de acces ale acesteia se află în alte trei sisteme, iar câmpul nu are cum să le întrebe ceva.
Un câmp nu poate fi greșit, pentru că un câmp nu poate fi verificat.
În Nodwise · o relație tipizată
Între două noduri care există amândouă în același model — activul și persoana. Iar relația nu se configurează pentru fiecare activ în parte: fiecare tip de nod are propria matrice de responsabilitate, așa că un nod se naște știind ce roluri răspund pentru el, iar cine le ocupă în prezent se determină prin graf.
Această matrice declară, pentru fiecare rol, ce se așteaptă de la cel care îl deține și ce îl califică pe cineva să îl dețină. Astfel, „proprietar de date” nu este un titlu de post împrumutat dintr-un document de politici — este un set definit de așteptări și un prag definit, scrise o singură dată și moștenite de fiecare nod de acel tip.
Ceea ce înseamnă că cele trei condiții încetează să mai fie un exercițiu de audit și devin o traversare:
Departament
Human Resources
Persoană
Hedda M Halvorsen
Persoană
Mindy C Martin
Persoană
Ashok X Joshi
Rol în întreprindere
Human Resources Manager
Rol în întreprindere
Benefits Specialist
Rol în întreprindere
Recruiter
Produs de date
HumanResources data product
Trei întrebări pe care catalogul le poate adresa doar unui om, la care se răspunde parcurgând modelul.
Bucla
Odată ce responsabilitatea este o relație, una ineficace este o condiție pe care un agent o poate urmări. Ce urmează nu este un raport pe care trebuie să îl citiți.
01
Detectat
02
Direcționat către cineva care poate decide
03
Decis de o persoană
04
Înregistrat
Iar aceeași buclă rulează înainte ca golul să apară — implicit, nu ca ceva ce trebuie configurat. O responsabilitate are propria stare, așa că poate fi suspendată fără a fi ștearsă: când cineva își schimbă zona, intră în concediu sau renunță la o atribuție, responsabilitățile pe care le poartă ies din starea eficace, iar întrebarea ajunge la acea persoană cât timp încă are contextul necesar pentru a răspunde, în loc să ajungă la fosta sa echipă după șase luni.
Ceea ce oferă și versiunea onestă a întrebării cu care începe această pagină. Nu „există un proprietar?”, ci când a fost confirmat ultima dată că acest lucru este adevărat — o dată, pentru fiecare responsabilitate, care fie există, fie nu.
Agentul urmărește și escaladează. Nu decide niciodată. Autonomie a atenției, nu a autorității.
Ce costă în mod normal acest lucru
Realizată ca proiect, curățarea responsabilităților ineficace dintr-un catalog matur se desfășoară în opt faze: identificarea deținătorilor inactivi, asocierea fiecărui caz cu un manager, gruparea lor într-o singură vedere pentru fiecare lider, notificarea cu context și termen limită, derularea unui flux de lucru de înlocuire trasabil, integrarea noilor deținători, certificarea celor a căror zonă s-a schimbat și, în final, identificarea fluxurilor care depind de o singură persoană.
Este o muncă solidă și este motivul pentru care această problemă este de obicei amânată: durează luni, necesită reconcilierea manuală a trei sisteme sursă, iar rezultatul este exact în ziua în care este livrat.
Fiecare dintre aceste faze este o interogare sau un flux de lucru asupra unui model care deține deja răspunsul. Nu pentru că munca ar fi trivială, ci pentru că reconcilierea căreia programul îi dedică cea mai mare parte a timpului este exact ceea ce este modelul.
Puneți întrebarea mai dificilă
Tenantul demo conține activul, cele patru roluri, condițiile nerespectate și interogarea care le semnalează — într-un model pe care îl puteți deschide acum.