Er is één iemand die weet hoe het werkt. Niet omdat dat zo is afgesproken, maar omdat hij er het langst zit. Hij lost op wat er misgaat, kent de koppelingen die nergens beschreven staan, en weet welke oplossing ooit tijdelijk was en het nog steeds is.

Op een dinsdag zegt hij zijn baan op.

Dat is het moment waarop veel organisaties voor het eerst zien waar hun afhankelijkheid werkelijk zit. Niet in de systemen, maar in de kennis eromheen. En dat inzicht komt dan met een opzegtermijn erbij.

Afhankelijkheid is op zichzelf geen probleem. Zij hoort bij moderne bedrijfsvoering. Het risico ontstaat wanneer die afhankelijkheid sneller groeit dan het inzicht erin. Dan wordt IT niet alleen ondersteunend, maar bedrijfskritisch en zonder dat eigenaarschap, alternatieven en herstelbaarheid scherp genoeg zijn geregeld.

Waarom dit bestuurlijk relevant is

U hoeft niet elk systeem, contract of technisch detail te kennen. U moet wel weten waarvan de organisatie werkelijk afhankelijk is.

De kernvraag is niet of IT draait. De kernvraag is wat er gebeurt wanneer een kritisch systeem, een leverancier, een koppeling of een sleutelpersoon tijdelijk niet beschikbaar is.

Die vraag raakt direct aan continuïteit. Kunnen klanten nog worden bediend? Kan productie doorgaan? Kunnen orders, betalingen en planningen nog worden verwerkt? En wie beslist wanneer het antwoord onzeker is?

Afhankelijkheid wordt gevaarlijk wanneer zij impliciet blijft. Dan oogt de organisatie stabiel, terwijl de feitelijke weerbaarheid rust op aannames, leveranciersbeloftes en individuele kennis.

Wat ik typisch zie

  • er is één persoon die weet hoe het werkelijk in elkaar zit, en dat staat nergens vastgelegd
  • een systeem dat ooit tijdelijk zou zijn draagt inmiddels een deel van de bedrijfsvoering
  • de leverancier is kritiek geworden zonder dat iemand dat besluit heeft genomen
  • de afspraken met die leverancier gaan over reactietijden, niet over de vraag of u daarna weer kunt werken
  • er is een continuïteitsplan dat is geschreven voor een organisatie die niet meer bestaat
  • bij de laatste groeisprong is de IT meegegroeid en het overzicht niet
  • niemand kan zeggen hoe lang de organisatie het zonder een bepaald systeem uithoudt, dus wordt die vraag ook niet gesteld
  • technische schuld wordt intern herkend en bestuurlijk nooit gewogen, omdat het nooit op de bestuursagenda staat
  • de vraag komt pas op tafel bij een overname, een auditbevinding of het vertrek van een sleutelpersoon.

Het gevolg is dat de organisatie wel weet dát IT belangrijk is, maar niet scherp weet welke afhankelijkheden werkelijk bedrijfskritisch zijn.

Welke vragen dit oproept

Deze vragen zijn niet technisch. Zij gaan over wat u zich kunt permitteren.

  • Welke diensten, processen of klantverplichtingen mogen niet stilvallen?
  • Welke systemen, leveranciers, koppelingen en mensen zijn daarvoor kritiek?
  • Wat gebeurt er als één van die afhankelijkheden wegvalt?
  • Hoe snel moet herstel plaatsvinden om zakelijke schade te beperken?
  • Waaruit blijkt dat herstel ook werkelijk mogelijk is?
  • Wie is eigenaar van de afhankelijkheid, niet alleen van het systeem?
  • Welke kennis zit bij één persoon, en wat gebeurt er als die vertrekt?
  • Welke risico's zijn aanvaard, bewust of onbewust?
  • Welke afhankelijkheden zijn zo groot geworden dat een expliciet besluit nodig is?

Deze vragen maken IT bespreekbaar als bedrijfsrisico. Niet als beheerprobleem, maar als vraag over continuïteit en verantwoordelijkheid.

Wat een Reality Check hier oplevert

Een Reality Check onderzoekt niet uw volledige IT-omgeving. Hij begint bij een concrete bestuurlijke vraag en kijkt welke afhankelijkheden daaronder liggen.

Bij dit onderwerp levert dat bijvoorbeeld op:

  • scherp beeld van de processen of diensten die centraal staan
  • overzicht van de systemen, leveranciers, koppelingen en mensen waarvan die afhangen
  • onderscheid tussen gewone afhankelijkheid en bedrijfskritische afhankelijkheid
  • zicht op herstelbaarheid, eigenaarschap en besluitpunten
  • signalering van kennis die bij één persoon zit
  • overzicht van aannames over leveranciers, afspraken en herstel
  • besluitpunten voor directie of bestuur, scherp genoeg om de afweging zelf te kunnen maken
  • concrete prioriteiten voor vervolgactie.

Wat een Reality Check niet levert, is een kosteninschatting of een verbeterprogramma. Wat een oplossing kost, hangt af van keuzes die u daarna nog maakt. Die keuzes blijven van u.

De waarde zit niet in een volledige inventarisatie. De waarde zit in het zichtbaar maken van afhankelijkheden die bestuurlijk relevant zijn geworden.

Kern

Afhankelijkheid is niet riskant omdat zij bestaat. Zij wordt riskant wanneer de organisatie niet scherp weet welke afhankelijkheden kritiek zijn, wie ervoor aanspreekbaar is, en wat er gebeurt wanneer ze falen.

Uitbesteden verplaatst uitvoering, niet verantwoordelijkheid.