IT koopt niet alleen technologie: vier rollen, vier soorten risico

Deze matrix is rechtstreeks samengesteld uit de velden belangrijkste pijnpunt, grootste angst, bewijs, voorkeurskanaal en gewenste situatie van de vier oorspronkelijke doelgroepkaarten. De samenvattingen zijn redactioneel ingekort; de achterliggende rolbeschrijvingen zijn behouden.

Voor de IT-manager blijft na een aankoop het beheer liggen. Een nieuwe mogelijkheid is pas aantrekkelijk wanneer het team niet opnieuw de brandweer wordt. Bij de CIO ligt de verantwoordingslijn bij directie en toezicht: de architectuur en het risico moeten over meerdere jaren kloppen.

De CTO draagt de kwaliteit en snelheid van de ontwikkeling. Een platform kan vandaag indrukwekkend lijken maar morgen een technische schuld blijken die het team jaren meedraagt. De head of IT moet juist een versnipperde omgeving professionaliseren zonder een nieuw afhankelijkheidsprobleem te maken. Wie die verschillende rekeningen niet begrijpt, praat over features terwijl de koper om beheersbaarheid, bewijs of bouwvrijheid vraagt.

Het belangrijkste pijnpunt in de kaart is een teveel aan tickets en operationeel werk voor een te klein team. De emotionele pijn is dat de IT-manager voortdurend incidenten moet oplossen, zonder tijd om de omgeving structureel te verbeteren. Verkoop je nieuwe tooling zonder te laten zien wie deze beheert, dan voeg je vooral een nieuwe verantwoordelijkheid toe.

Deze rol verwacht een bewezen oplossing met documentatie, support, een beheerste implementatie en referenties van vergelijkbare organisaties. De eerste geloofwaardige belofte is daarom niet dat alles sneller en slimmer wordt, maar dat de omgeving stabiel blijft en het team minder tijd kwijt is. Vraag in het eerste gesprek hoeveel tickets het team nu verwerkt en wie na livegang welke taak beheert.

De CIO ziet een landschap met legacy, versnipperde applicaties en digitaliseringsdruk. Het grootste risico in de kaart is niet een gemiste feature, maar een beveiligingsincident, datalek of mislukte migratie onder eigen verantwoordelijkheid. De relevante vraag is hoe een oplossing past in het architectuur- en governancekader, welke risico's verschuiven en welke totale kosten volgen.

Daarom volstaat een mooie demo niet. De kaart vraagt om architectuurfit, security-documentatie, total cost of ownership, enterprise-referenties en een zorgvuldig besluitproces. Een CIO kan een goede innovatie afwijzen wanneer implementatie en beheersing onvoldoende inzichtelijk zijn. Dat is geen afkeer van verandering, maar een andere maatstaf voor de kwaliteit van verandering.

De CTO wil de ontwikkelsnelheid en engineeringkwaliteit verhogen zonder een platform in te kopen dat later beperkt of afhankelijk maakt. Technische schuld, schaalbaarheid, cloudkosten en lock-in zijn concreet benoemde bezwaren. Een generiek ROI-deck kan daardoor minder overtuigen dan goede documentatie, een open benchmark en toegang tot engineers.

Het voorkeurskanaal begint volgens de kaart vaak bij technische communities en peers. Vervolgens wil de CTO zelf een proof of concept uitvoeren. Geef toegang tot API's, leg architectuurkeuzes uit en maak een technische stopconditie zichtbaar. De beste demo voor deze rol laat niet alleen zien wat jouw product kan, maar vooral wat zijn team ermee kan bouwen.

De head of IT werkt in het bronprofiel vaak bij een groeiende organisatie waar keuzes jarenlang ad hoc zijn gemaakt. Het kernprobleem is een IT-omgeving die niet veilig of schaalbaar genoeg meer is. De grootste angst is dat een vermijdbaar incident alsnog gebeurt omdat niemand de basis goed heeft geregeld.

Deze rol koopt daarom grip, veiligheid en een haalbare route naar professionalisering. Een implementatiecase uit een vergelijkbaar groeibedrijf, certificeringen, duidelijke begeleiding en een roadmap zijn sterker dan een technisch veelbelovende productpresentatie. De vraag is niet alleen of het platform kan schalen, maar ook of het huidige team de invoering en het beheer kan dragen.

De cijfers staan in de doelgroepkaart IT & Technologie, rijen 44-46. BIS en BAS zijn beschrijvende dimensies op een schaal van 0 tot 10. De afzonderlijke k-parameter beschrijft de tijdsweging binnen dit profielmodel. k is geen percentage of aankoopkans en hoort niet op dezelfde as als BIS of BAS.

De CIO heeft in de vier kaarten de hoogste BIS-score, 8, en de laagste k-waarde, 0,08. Dat past bij strategische risicobeheersing over meerdere jaren. De CTO heeft de hoogste BAS-score, 8, en k 0,30. In die rol krijgen technische mogelijkheden en eerder ontwikkelresultaat relatief meer gewicht.

Dat betekent niet dat de CIO geen innovatie wil of dat de CTO risico negeert. De kaart noemt bij de CTO juist expliciet lock-in en technische schuld als af te wijzen risico's. Bovendien is k geen stopwatch waarmee je kunt voorspellen hoe snel een specifieke persoon tekent. De waarden helpen je de eerste vragen en bewijsvorm te kiezen, waarna je de werkelijke context toetst.

Stel dat je een platform aanbiedt dat processen automatiseert, API's ontsluit en cloudbeheer vereenvoudigt. Het volgende is een fictief verkoopscenario, geen geobserveerde Neurofactor-test.

De IT-manager vraagt: wie vangt incidenten op, hoeveel werk levert de migratie op en daalt het ticketvolume? De CIO vraagt: past dit binnen onze architectuur, security-eisen, totale kosten en governance? De CTO vraagt: kan mijn team via API's een eigen proof of concept draaien zonder lock-in? De head of IT vraagt: brengt dit ons veilig van ad hoc beheer naar een schaalbare inrichting, zonder dat mijn team overvraagd wordt?

Viermaal hetzelfde platform. Vier verschillende voorwaarden om verder te praten. Een productdemo die alle vier meteen dezelfde slides toont, mist precies het verschil dat de doelgroepkaart zichtbaar maakt.

Een functieprofiel is nuttig als het je commerciële voorbereiding verandert. Gebruik bij ieder gesprek eerst de kaart en controleer vervolgens welke verantwoordelijkheden, bestaande systemen en beslissers daadwerkelijk aanwezig zijn.

De voorbeelden hieronder zijn redactionele toepassingen van de kaarten, geen geteste slogans of letterlijke respondentcitaten.

In echte inkooptrajecten kunnen deze functies elkaar aanvullen. De CTO kan technisch enthousiast zijn en toch afhankelijk zijn van een CIO die architectuur en risico beoordeelt. De IT-manager moet het systeem kunnen beheren en de head of IT kan het implementatiepad bewaken.

Maak daarom geen vier tegenstrijdige proposities. Werk met een gedeelde basis - aantoonbaar probleem, verwacht resultaat, randvoorwaarden en implementatie - en vier bewijsbijlagen. Benoem waar trade-offs zitten: bijvoorbeeld sneller lanceren tegenover extra beheerrisico, of vrijheid voor engineers tegenover governance. Een besluit wordt sterker wanneer iedere rol ziet hoe zijn eigen risico serieus wordt genomen.

De kanaalvelden in de kaarten laten zien dat alle vier op LinkedIn aanwezig kunnen zijn, maar daarnaast andere informatiebronnen gebruiken. De IT-manager leest Tweakers, vakmedia en leveranciersupdates. De CIO volgt vakmedia en analistenrapporten. De CTO beweegt ook in GitHub, Hacker News, X en tech-podcasts. De head of IT gebruikt onder meer Tweakers, vendorcommunities en webinars.

Daarom geef je de IT-manager een compacte implementatiecase met meetbare vermindering van beheerlast, de CIO een inhoudelijke architectuur- en risicobijdrage, de CTO een technische demo met documentatie en de head of IT een groeiscenario met stappenplan. Dit zijn voorstellen vanuit de profielkaarten, geen gemeten kanaalconversieratio's.

Bekijk ook hoe tone of voice en bezwaren onderdeel van een doelgroepkaart worden. In de vervolgartikelen gaan we dieper in op CIO versus CTO en IT-manager versus head of IT.

De ene IT-beslisser moet een incident voorkomen, de andere de architectuur verdedigen, een derde het engineeringteam sneller laten bouwen en een vierde een groeiende omgeving professionaliseren. Dat is waarom hetzelfde aanbod bij vier mensen een andere vraag activeert.

Een sterke IT-propositie legt dus niet alleen uit wat de technologie kan. Ze maakt per rol zichtbaar welke consequentie beter wordt, welk risico beheerst blijft en welk bewijs nodig is om de beslissing te dragen. Eerst het beslisprobleem, dan pas de features.