Een ICT-dienstverlener bestaat uit lagen werk die weinig met elkaar te maken hebben. Er is de bouw en het onderhoud van code, er is het oplossen van tickets en incidenten, er is architectuur en ontwerp, er is projectmanagement richting de klant, en er is presales: offertes, proof of concepts, technische onderbouwing van een aanbesteding. Van deze categorieën verschillen de uren enorm per opdracht. Een supportafdeling draait op volume en herhaling. Een architectuurteam draait op een klein aantal mensen met veel ervaring. De uitkomst van een deal wordt gestuurd door welke van deze lagen de klant het zwaarst laat wegen, en dat verschilt per aanbesteding, per klant en per moment in het project.
De drie categorieën die overal spelen — AI neemt de taak over, AI werkt toe met een mens die goedkeurt of afkeurt, of het werk blijft mensenwerk — lopen dwars door de ICT-sector heen, en niet gelijkmatig. Ticketafhandeling voor bekende problemen is voor een deel te automatiseren; de eerste triage, het herkennen van een patroon, het aandragen van een oplossing uit eerdere cases. Codegeneratie voor routinematige stukken software verschuift richting AI met een reviewer die de output goedkeurt. Architectuurbeslissingen, de vertaling van een vage klantwens naar een werkend systeem, en het onderhouden van vertrouwen bij een opdrachtgever blijven vooralsnog mensenwerk, omdat daar oordeel nodig is dat niet uit een patroon in bestaande data te halen is.
De verschuiving die dit veroorzaakt gaat niet over of AI goed is in coderen. Ze gaat over wat er met de vergelijking tussen leveranciers gebeurt zodra een deel van dat werk zichzelf doet. Responstijd op support was een resultaat van bezetting en planning; als triage grotendeels geautomatiseerd verloopt, is snelheid niet langer het bewijs van een goed team, maar van een goed geconfigureerd systeem, en dat systeem is voor concurrenten net zo goed te kopen of te bouwen. Wat dan overblijft als onderscheid is niet de snelheid zelf, maar wat er gebeurt in de gevallen waarin het systeem het niet oplost — wie daar wél doorheen komt en wie een klant laat wachten.
Hetzelfde patroon zit in offertetrajecten. Een technisch voorstel samenstellen uit bestaande componenten is werk dat een deel geautomatiseerd kan worden. Zodra dat bij meerdere partijen in een aanbesteding gebeurt, verschuift het waar een klant nog verschil ziet: niet in de snelheid van het voorstel, maar in de vraag of het voorstel klopt voor deze specifieke situatie, en in wie dat kan uitleggen zonder terug te vallen op een sjabloon.
Of een ICT-bedrijf dit al zo georganiseerd heeft, hangt af van waar het zijn mensen op zet. Een partij die zijn ervaren architecten nog grotendeels inzet op het schrijven van standaardcode, houdt weinig capaciteit over voor het gesprek met de klant waar de deal wordt beslist. Een partij die dat werk al heeft verschoven — AI voor het routinematige deel, mensen voor het oordeel — heeft die uren vrijgemaakt voor precies het onderdeel waarop nu wordt gewonnen. Dat is geen keuze die in een kwartaal wordt gemaakt; het volgt uit eerdere beslissingen over tooling, over wie welk type werk doet, en over hoeveel vertrouwen een organisatie heeft in het toezicht op geautomatiseerde output. Wat een werkgever daarbij met zijn personeelsbestand doet, is aan de werkgever; daarvoor gelden eigen wettelijke vereisten, los van de vraag welk werk technisch overdraagbaar is.
Deze dynamiek is niet uniek voor ICT. Dezelfde verschuiving — van volume en snelheid naar oordeel en uitleg — speelt zich anders af in de financiële dienstverlening, waar advies en risico-inschatting het aangrijpingspunt zijn, en weer anders in de bouw, waar planning en calculatie verschuiven maar de uitvoering op de bouwplaats mensenwerk blijft. De vraag welk werk in dit specifieke bedrijf al is verschoven en welk niet, is met een [werkscan die per taak beoordeelt of AI die overneemt, deels overneemt met toezicht, of niet](https://ftetoai.nl) te beantwoorden — een aparte stap, los van de vergelijking met concurrenten.
Het risico van deze verschuiving is niet dat een leverancier verliest, maar dat hij niet weet waarop. Een offerte die zegt sneller te zijn, een website die stabiliteit belooft, een salespitch die op expertise leunt — dat zijn allemaal claims, en claims zijn pas een voordeel als ze te onderbouwen zijn tegenover wat een klant elders ziet. Wie eenmaal een achterstand op een dimensie heeft geconstateerd, kan bij een aanpak voor het inhalen van een achterstand op een specifieke dimensie lezen wat daarin de opties zijn, en wie een claim wil hardmaken voordat een klant ernaar vraagt, vindt bij een toetsing van eigen kwaliteitsclaims op onderbouwing hoe dat systematisch te doen is.
Benoem waarop uw bedrijf denkt te winnen — snelheid, prijs, expertise, betrouwbaarheid — en toets welke van die claims u vandaag met bewijs kunt staven tegenover een concurrent. Dat is precies wat de gratis dimensiecheck doet: geen volledige benchmark, wel een eerste beeld van welke claims stevig staan en welke nog los in de lucht hangen. De volledige concurrentiebenchmark, met bewijsmatrix per dimensie, is in aanbouw.
Vraag maar waarop er in uw markt gewonnen wordt. Ik vergelijk liever dan dat ik uitleg.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.