Hier is een kijkje achter de schermen van ICT-budgetroulette
Leveranciersrisico is geen theorie meer; het staat op de agenda van het dagelijks bestuur. Een recent onderzoek bij de overheid laat zien wat er gebeurt als een handvol partijen de ruggengraat vormt van de ICT: valt er één om - technisch, financieel of contractueel - dan ligt er zomaar een hele software straat stil. Kunnen diverse mensen niet meer werken. Vallen delen van processen uit. Dat is overigens geen probleem dat alleen speelt bij de overheid. Dat is een concentratierisico dat in bijna elke (middelgrote) organisatie sluimert.
De vraag die ik met regelmaat stel, wanneer ik bijvoorbeeld een intake bij een nieuwe klant doe is: Hoeveel “single points of failure” heb jij uitbesteed?
Want dit is wat er kan gebeuren, zomaar een greep uit de problematiek die men deelt. Een identity-provider die hapert. Een cloudregio die vastloopt. Een softwareleverancier die de stekker uit updates trekt door een verkoop. Een datalek of simpelweg strategische koerswijziging. Ik kan nog wel even doorgaan. Uren of dagen uitval is geen uitzondering meer. En alsof het de gewoonste zaak van de wereld is geworden … elke minuut gaat rechtstreeks ten koste van omzet, reputatie en compliance. Dat kan en moet anders.
De pijn zit vaak dieper dan uptime. Contractvoorwaarden die je dwingen tot één stack. Closed data-formaten die een exit praktisch onmogelijk maken. Licentiemodellen die “groeien” als een olievlek terwijl prestaties achterblijven. Security-patches die pas komen als het nieuws al lekt. Je merkt het pas als je geen knoppen meer hebt om aan te draaien.
Best practices van leveranciers lossen dit niet voor je op. Want … ze beschermen vooral hún businessmodel. Jouw taak als C-level of IT-verantwoordelijke is anders: afhankelijkheden zichtbaar maken, concentratierisico verlagen en hersteltijd verkorten.
Dat begint met drie vragen:
- Welke kritieke processen zijn bij één partij of in één cloudregio ondergebracht?
- Hoe lang kun je je veroorloven ‘down te zijn’? En kun je binnen die tijd herstellen?
- Wie heeft de sleutel van jullie data, technisch én juridisch?
De antwoorden die je zojuist hebt gegeven kunnen je doen fronsen. Mocht je – al is het maar een klein beetje – zorgen maken omdat er serieus leveranciers-risico is, dan is hier een eerste stap om zo snel mogelijk op de agenda te zetten: levenanciers-risico-spreiding.
In het kort: wees radicaal pragmatisch: ontwerp voor exit (technisch én contractueel), vermijd monoculturen, borg data-portabiliteit, en test je failover alsof het morgen misgaat. Resilience is geen tool. Het is een bestuurskeuze. En die keuze kun je niet outsourcen.
Vendor Lock-in is geen bug — het is hun business
Vendor lock-in is geen bijwerking; het ís het verdienmodel. Geen nieuws, maar wel hardnekkig. Het begint onschuldig: gratis credits, bundelkorting, “naadloze” integraties. Voor je het weet hangen identity, data, collaboration en billing aan hetzelfde infuus. Handig hoor, tot je merkt dat elke knop die je indrukt geld kost of niet meer van jou is. Of allebei.
Lock-in werkt langs drie lijnen:
1) Identiteit als knellende handboeien. Koppel je alles aan één identity-provider, dan krijgt die partij de master-sleutel. IAM-policies, conditional access, device trust: prachtig, maar je exitpad krimpt. Zelfs on-prem resources worden via diezelfde sleutel bediend; uitzetten betekent koudzwemmen.
2) Data als dure tolweg. “My Documents” staat al lang niet meer lokaal. Versleuteling, versiebeheer, DLP - allemaal nuttig - maar wel in een gesloten ecosysteem. Uitstappen betekent migraties, datatransformaties en nieuwe licenties. Vaak zó pijnlijk dat je blijft betalen om niet te bewegen.
3) Contract als onzichtbare fuik. Bundels, minimum spends, egress-kosten, API-ratelimits, verplichte upgrades: elk clauseetje duwt je een stap verder de fuik in. “Best practices” en “reference architectures” maken het gezellig … en homogeen.
Wat te doen? Hoe bescherm je jezelf en krijg je die leveranciers weer onder controle?
- Ontwerp altijd voor exit. Documenteer een technisch én juridisch exit-plan: data-export (open formaten), identity-scheiding, DNS/PKI-overname, en een draaiboek voor 48-uurs cutover.
- Decouple identity. Gebruik een neutrale broker of houd een tweede IdP warm. Zorg dat kritieke apps kunnen authenticeren buiten het primaire domein.
- Vermijd monoculturen. Standaardprotocollen (SAML/OIDC, SMTP/IMAP, SQL/Parquet) boven propietary glue. Kies tooling die buiten het ecosysteem draait.
- Prijs de lock-in mee. Reken TCO met egress, migratie, training en “compliance-belasting”. Goedkoop instappen is duur uitstappen.
- Test je vrijheid. Voer elk kwartaal een mini-exit uit: exporteer datasets, laat een app in een alternatieve stack draaien, simuleer IdP-uitval.
Vrijheid is geen mening; het is een capability. Als je het vandaag niet kunt testen, bezit je haar morgen niet.
Vierde-partij risico: de blinde vlek in je SLA
Leveranciersrisico stopt niet bij je contractpartij. Het sluipt door de hele keten heen. Grote platformen lijken robuust - tot een fout in DNS, identity of networking duizenden klanten tegelijk raakt. Kleinere specialisten ogen wendbaar - tot blijkt dat hun back-end op precies datzelfde platform draait. Dan zit je dubbel met de gebakken peren: jij direct én daarbovenop van je leverancier.
Dit is vierde-partij risico en concentratierisico in één. Je abonnement bij Canva? Indirect kocht je (delen van) AWS mee. Je deal met die niche-SaaS? Je tekende impliciet voor hun cloud, hun CDN, hun e-mailprovider, hun IdP. Elke component is een dominosteen die potentieel … kan omvallen.
Wat nu wél concreet te doen:
- Maak de keten zichtbaar. Vraag, nee eis een dependency map van kritieke diensten: hosting, storage, CDN, IdP, e-mail, logging, payments. Geen inzicht = geen akkoord.
- Vraag om keten-SLA’s. Niet alleen uptime van je leverancier, maar ook afspraken over hun cruciale toeleveranciers (met flow-down verplichtingen).
- Elimineer single points. Stimuleer multi-region/multi-provider designs of kies alternatieven die dat al standaard bieden.
- Test keten-failover. Oefen IdP-uitval, DNS-switches, egress-blokkades. Meet RTO/RPO in de praktijk, niet in een brochure.
- Borg data-portabiliteit. Open formaten, gedocumenteerde exports, ‘break-glass’ toegangssleutels. Vandaag geregeld = morgen beschikbaar.
- Calculeer risico in. Neem ketenuitval en migratiefrictie op in je TCO. Goedkope SaaS zonder ketenhelderheid is duurkoop.
Je koopt geen product; je koopt een ecosysteem. Als je de keten niet kent, koop je risico met open ogen.
Minder afhankelijk. Meer opties. Jouw keuze.
Als één leverancier stilvalt, wil jij kunnen doorwerken. Zonder vertraging of paniek. Zonder politieke gedoe. Zonder dat je eerst toestemming hoeft te vragen aan de partij die je vastzet.
Wil je minder afhankelijk zijn van een handvol leveranciers? Laten we praten.
Wij zijn niet van de verkooppraatjes. Geen tool-geduw. Geen PowerPoint-circus. Gewoon een nuchter gesprek over regie: hoe je lock-in beperkt, je opties openhoudt en sluiprisico’s voorkomt. Jij bepaalt wat je wilt bespreken: identiteit, data, contracten, cloud, keten, of iets heel anders. Wij luisteren. We denken mee. Wij lossen op. Punt.
Waarom nu?
- Lock-in wordt nooit kleiner als je wacht.
- Ketenrisico’s worden niet zichtbaar door hoop.
- Exit-mogelijkheden ontstaan niet vanzelf.
Je hoeft niets te beloven. Geen traject. Geen budget. Alleen een open gesprek om te toetsen waar je staat en welke speelruimte je wilt creëren. Past het bij je? Mooi. Past het niet? Ook goed.
Wil je minder afhankelijk worden van een paar leveranciers en meer strategische bewegingsruimte terugpakken?
👉 Plan een vrijblijvende afspraak.
Regie is niet iets wat je krijgt. Het is iets wat je neemt. Start vandaag.