Effectiviteit van verantwoordelijkheid

Het grootste risico is niet het ontbreken van verantwoordelijkheden.
Het is geloven dat u ze hebt.

Elk kritiek asset in uw catalogus heeft een eigenaar, een datasteward en een goedkeurder. De namen zijn ingevuld. De workflows worden nog steeds naar hen gerouteerd. De vraag waar deze pagina over gaat, is de vraag die de catalogus niet kan beantwoorden: als dat asset vandaag een beslissing nodig heeft, kan de persoon die erbij vermeld staat dan daadwerkelijk handelen?

Wat effectief betekent

Een verantwoordelijkheid heeft alleen waarde zolang ze wordt uitgeoefend.

Toewijzing is een registratie. Effectiviteit is een status, en die heeft drie voorwaarden — allemaal tegelijk waar, vandaag:

01

Actief

De persoon zit nog in de organisatie, en is beschikbaar. Geen naam die een uitdienstproces overleefde omdat niemand wist waarvan hij eigenaar was — en niet iemand met langdurig verlof van wie niemand de taken overnam.

02

Bevoegd

Hij heeft nog steeds het mandaat dat de rol veronderstelt — de scope, de senioriteit, de rechten. Een overstap naar een ander gebied trekt dat stilzwijgend in, en niets in de catalogus merkt het.

03

In staat om te handelen

Hij kan bij het ding komen waarvoor hij verantwoordelijk is, en hij weet wat de rol van hem verwacht. Identiteitssystemen trekken toegang in volgens hun eigen schema, en het intrekken van toegang verwijdert geen verantwoordelijkheid.

Ontbreekt er één, dan breekt er niets zichtbaar. Het asset toont nog steeds een eigenaar. De workflow wordt nog steeds gerouteerd. Het falen komt pas weken later aan het licht, als een beoordeling die is verlopen en een beslissing die niemand nam.

Daarom is een verantwoordelijkheid in ons model nooit simpelweg aanwezig of afwezig:

Voorgesteld Toegewezen Geïnformeerd Opgeleid

Toegewezen zijn is de tweede van die vier, niet de laatste. Een catalogusveld registreert de tweede stap en veronderstelt de vierde.

Vandaag · onzichtbaar

Vier rollen toegewezen. Niet één ervan kan vandaag antwoorden.

AdventureWorks2025 — HumanResources data product, in gebruik binnen HR-operaties, salarisadministratie en personeelsplanning. Vier rollen zijn ervoor verantwoordelijk. Ze zijn allemaal ingevuld, en de catalogus toont geen enkel probleem.

Eigenaar · en goedkeurder

Hedda M Halvorsen

uit dienst · beide rollen vertrokken met haar

Datasteward

Mindy C Martin

mandaat niet herbevestigd sinds mei 2024

Materiedeskundige

Lakshmi A Venkatesan

met verlof · geen vervanging

Materiedeskundige

Ashok X Joshi

toegewezen · nooit geïnformeerd

Vier verschillende tekortkomingen, en bij geen ervan ontbreekt er data. Elke naam klopte toen hij werd genoteerd. Niets is geblokkeerd, en dat is het probleem — het asset wordt gerouteerd naar iemand die is vertrokken, naar iemand van wie het mandaat is verlopen, naar iemand die afwezig is, en naar iemand die nooit is geïnformeerd. Elke beslissing die een van deze vier nodig heeft, kan nergens terecht, en nergens staat dat vermeld.

Let op wat één vertrek teweegbracht. Hedda had twee van de vier rollen — wat normaal is, want de eigenaar van een asset is meestal ook degene die wijzigingen eraan goedkeurt. Toen zij vertrok, vertrok de helft van de governance van dit product met haar mee — en het asset noemt haar nog steeds in beide rollen, dus alles wat een van beide nodig heeft, wordt nog steeds gerouteerd naar iemand die er niet meer is.

De tweede expert is degene bij wie het de moeite waard is stil te staan. Ashok is in dienst, bevoegd, en heeft de toegang. Niets in enig systeem is verouderd. Hij is simpelweg nooit geïnformeerd dat dit asset naar hem wordt gerouteerd wanneer de andere expert afwezig is — en geen enkel rapport, waar dan ook, kan dat laten zien.

Zo ziet verval van governance eruit van binnenuit: geen leeg veld, maar een ingevuld veld dat ophield waar te zijn.

Waarom de catalogus het niet kan zien

Een eigenaarveld bevat een naam. Het bevat geen enkele verplichting.

In een catalogus · een attribuut

Tekst op een asset, die verwijst naar een persoon over wie het asset niets weet. Het dienstverband, het werkgebied en de rechten van die persoon staan in drie andere systemen, en het veld kan hun niets vragen.

Een veld kan niet fout zijn, omdat een veld niet kan worden gecontroleerd.

In Nodwise · een getypeerde relatie

Tussen twee knooppunten die allebei in hetzelfde model bestaan — het asset en de persoon. En die wordt niet per asset geconfigureerd: elk knooppunttype draagt zijn eigen verantwoordelijkheidsmatrix, zodat een knooppunt vanaf zijn ontstaan weet welke rollen ervoor verantwoordelijk zijn, en wie die rollen op dit moment vervult, volgt uit de graaf.

Die matrix legt per rol vast wat er wordt verwacht van wie de rol vervult en wat iemand kwalificeert om haar te vervullen. Zo is “data owner” geen functietitel die uit een beleidsdocument is geleend — het is een gedefinieerde set verwachtingen en een gedefinieerde lat, één keer vastgelegd en overgeërfd door elk knooppunt van dat type.

Waardoor de drie voorwaarden geen auditoefening meer zijn, maar een doorloop worden:

Afdeling

Human Resources

vormt
vormt
vormt

Persoon

Hedda M Halvorsen

Persoon

Mindy C Martin

Persoon

Ashok X Joshi

fungeert als
fungeert als
fungeert als

Bedrijfsrol

Human Resources Manager

Bedrijfsrol

Benefits Specialist

Bedrijfsrol

Recruiter

EigenaarGoedkeurder
Datasteward
Materie­deskundige

Dataproduct

HumanResources data product

Drie vragen die de catalogus alleen aan een mens kan stellen, beantwoord door het model te doorlopen.

De lus

Gedetecteerd, gerouteerd naar iemand met het mandaat, beslist, geregistreerd.

Zodra verantwoordelijkheid een relatie is, is een ineffectieve verantwoordelijkheid een toestand waarop een agent kan letten. Wat volgt, is geen rapport dat u moet lezen.

01

Gedetecteerd

Op twee manieren, en de tweede is net zo belangrijk als de eerste. Een bronsysteem verandert — iemand vertrekt, wisselt van werkgebied, verliest een recht — en elke verantwoordelijkheid die op die persoon rust, valt uit de effectieve status. Of een persoon laat het u weten: de houder geeft de verantwoordelijkheid terug, of een collega die het werk kent, stelt de juiste naam voor. Een voorgestelde verantwoordelijkheid is een echte status in het model, in afwachting van goedkeuring, geen verzoek in iemands inbox.

02

Gerouteerd naar iemand die kan beslissen

Niet naar een governance-postbus. Het model kent de manager van de persoon al, en het weet welke assets en rollen zijn geraakt — zodat één leidinggevende één samengesteld overzicht krijgt van wat er in zijn gebied nu niet meer gedekt is.

03

Beslist door een persoon

Behouden, overdragen of vervangen. De opvolger wordt getoetst aan de kwalificaties die het knooppunttype voor die rol vereist, en de toewijzing geldt pas als afgerond wanneer die persoon geïnformeerd en opgeleid is — u kunt een dode verantwoordelijkheid niet overdragen aan een tweede dode verantwoordelijkheid.

04

Geregistreerd

Elke verantwoordelijkheid draagt haar eigen geschiedenis: wanneer ze werd toegewezen, wanneer ze voor het laatst werd herbevestigd tegen de huidige status van het knooppunt, wanneer ze werd beëindigd en door wiens besluit. Niets wordt overschreven en niets wordt verwijderd, dus “wie was in maart verantwoordelijk voor dit asset” is een vraag met een antwoord. Audit is niet langer een reconstructieoefening.

En dezelfde lus draait al voordat het gat ontstaat — standaard, niet als iets wat u moet configureren. Een verantwoordelijkheid heeft een eigen status, zodat ze kan worden opgeschort zonder te worden gewist: wanneer iemand van werkgebied wisselt, met verlof gaat of een taak neerlegt, verlaten de verantwoordelijkheden die hij draagt de effectieve status en bereikt de vraag hem terwijl hij nog de context heeft om haar te beantwoorden, in plaats van zes maanden later zijn voormalige team.

Dat levert ook de eerlijke versie op van de vraag waarmee deze pagina opent. Niet “is er een eigenaar”, maar wanneer is voor het laatst bevestigd dat dit klopt — een datum, per verantwoordelijkheid, die ofwel bestaat, ofwel niet.

De agent observeert en escaleert. Hij beslist nooit. Autonomie van aandacht, niet van gezag.

Wat dit normaal kost

Dit is normaal gesproken een programma.

Als project uitgevoerd, verloopt het opschonen van ineffectieve verantwoordelijkheden in een volwassen catalogus in acht fasen: de inactieve houders identificeren, elk geval koppelen aan een manager, ze groeperen in één overzicht per leidinggevende, informeren met context en een deadline, een traceerbare vervangingsworkflow uitvoeren, de nieuwe houders inwerken, degenen certificeren van wie het werkgebied is veranderd, en ten slotte de processen vinden die van één persoon afhankelijk zijn.

Het is vakkundig werk, en het is de reden waarom dit probleem meestal wordt uitgesteld: het duurt maanden, het vereist dat drie bronsystemen handmatig op elkaar worden afgestemd, en het resultaat klopt op de dag dat het wordt opgeleverd.

Elk van die fasen is een query of een workflow op een model dat het antwoord al bevat. Niet omdat het werk triviaal is, maar omdat de afstemming waaraan het programma het grootste deel van zijn tijd besteedt, precies is wat het model is.

De achtste fase — de processen die gegijzeld worden door één persoon — heeft een eigen pagina: Bedrijfscontinuïteit →

Stel de moeilijkere vraag

Uw catalogus kan u vertellen wie er is toegewezen. Vraag hem wie kan handelen.

De demo-tenant heeft het asset, de vier rollen, de verbroken voorwaarden en de query die ze signaleert — in een model dat u nu kunt openen.

zie het in werking

Open de demo

Eén klik met uw werkaccount. Geen formulier, geen gesprek.

Open de demo

of lees het model

Hoe het model trouw blijft

Een levenscyclus op elk knooppunt en elke verantwoordelijkheid — waarom een ingevuld veld toch kan worden gesignaleerd als niet langer waar.

Hoe het model trouw blijft →