IT kauft nicht nur Technologie: vier Rollen, vier Arten von Risiko

Die Matrix verdichtet die Originalfelder zum wichtigsten Schmerzpunkt, zur größten Angst, zum Nachweisbedarf, zum bevorzugten Kontaktweg und zur gewünschten Situation. Sie beschreibt breite Funktionsprofile, nicht jede einzelne Person.

Beim IT-Manager bleibt der tägliche Betrieb nach dem Kauf im eigenen Team. Eine neue Funktion hilft nur, wenn aus dem kleinen Team nicht noch stärker eine Feuerwehr wird. Der CIO steht gegenüber Geschäftsführung und Aufsicht in der Verantwortung. Architektur, Strategie und Risiken müssen auch über mehrere Jahre tragfähig sein.

Der CTO verantwortet Engineeringqualität und Entwicklungstempo. Eine heute attraktive Plattform kann morgen technische Schulden hinterlassen. Der Head of IT muss aus historisch gewachsenen Einzellösungen eine professionelle Funktion machen. Wer diese Konsequenzen übersieht, präsentiert Features, obwohl der Käufer nach Kontrolle, Belegen oder Entwicklungsfreiheit fragt.

Das größte Problem in der Karte sind zu viele Tickets und operative Aufgaben für ein zu kleines Team. Emotional belastet das Gefühl, ständig Brände zu löschen statt die Umgebung weiterzuentwickeln. Eine weitere Software ohne klares Betriebsmodell bedeutet daher zunächst ein zusätzliches Risiko.

Diese Rolle erwartet erprobte Technik, gute Dokumentation, Support, kontrollierte Einführung und Referenzen vergleichbarer Unternehmen. Beginnen Sie nicht mit einem Versprechen über mehr Innovation, sondern mit der Frage, welche Tickets wegfallen und wer nach dem Go-live welche Verantwortung übernimmt.

Legacy-Systeme, fragmentierte Anwendungen und Digitalisierungsdruck prägen das CIO-Profil. Die größte Angst betrifft einen Sicherheitsvorfall, ein Datenleck oder eine fehlgeschlagene Migration in eigener Verantwortung. Eine neue Lösung muss deshalb in Architektur und Governance passen, Risiken kontrollieren und über ihre Gesamtkosten transparent sein.

Eine eindrucksvolle Demo reicht nicht. Gefordert werden Architekturfit, Security-Dokumente, Total Cost of Ownership, belastbare Großkundenreferenzen und ein angemessener Entscheidungsprozess. Eine unzureichend abgesicherte Innovation abzulehnen ist nicht dasselbe wie Veränderung grundsätzlich abzulehnen.

Der CTO möchte Entwicklungsgeschwindigkeit und technische Qualität erhöhen, ohne das Team langfristig einzuschränken. Technische Schulden, Skalierung, Cloudkosten und Lock-in sind in der Karte konkrete Einwände. Daher können offene Benchmarks, klare Dokumentation und Gespräche mit Engineers mehr bewirken als eine allgemeine ROI-Präsentation.

Der Kontaktweg führt laut Karte häufig über technische Communities und Peers. Danach möchte der CTO einen Proof of Concept selbst durchführen. Geben Sie API-Zugang, zeigen Sie Architekturentscheidungen offen und vereinbaren Sie technische Abbruchkriterien. Eine starke Demo zeigt, was das eigene Team mit dem Produkt bauen kann.

Der Head of IT arbeitet im breiten Profil oft in einem wachsenden Unternehmen, dessen Systeme jahrelang ad hoc eingeführt wurden. Die Umgebung ist nicht mehr ausreichend sicher oder skalierbar. Die größte Angst ist ein Vorfall, der mit besseren Grundlagen vermeidbar gewesen wäre.

Diese Rolle kauft Sicherheit, Überblick und einen realistischen Weg zur Professionalisierung. Referenzen aus Wachstumsunternehmen, Zertifizierungen, Begleitung und eine klare Roadmap sind wertvoller als eine reine Funktionsdemo. Entscheidend ist, ob das vorhandene Team Einführung und Betrieb dauerhaft tragen kann.

Die Werte stammen aus dem Tabellenblatt IT & Technologie, Zeilen 44-46. BIS und BAS beschreiben jeweils eine Dimension auf einer Skala von 0 bis 10. Der Parameter k beschreibt die relative Gewichtung späterer Ergebnisse in einem eigenen Wertebereich. Er ist weder ein Prozentsatz noch eine Kaufwahrscheinlichkeit.

Der CIO hat in dieser Gruppe mit 8 den höchsten BIS-Wert und mit 0,08 den niedrigsten k-Wert. Dazu passt die langfristige Perspektive auf Strategie und Risikokontrolle. Der CTO weist mit BAS 8 und k 0,30 eine stärkere Orientierung auf technische Chancen und früher sichtbaren Entwicklungsfortschritt auf.

Daraus folgt nicht, dass CIOs Innovation meiden oder CTOs sorglos entscheiden. Gerade der CTO möchte Lock-in und technische Schulden verhindern. Auch lässt sich aus k keine individuelle Dauer bis zur Kaufentscheidung berechnen. Die Daten helfen, bessere Fragen zu stellen. Ob sie für das konkrete Angebot passen, muss anschließend geprüft werden.

Angenommen, Sie bieten eine Plattform an, die Prozesse automatisiert, APIs bereitstellt und Cloudbetrieb vereinfacht. Das folgende Szenario ist ein redaktionelles Beispiel und keine protokollierte Untersuchung.

Der IT-Manager fragt, wer Störungen bearbeitet, wie viel Migrationsarbeit entsteht und ob Tickets abnehmen. Der CIO fragt nach Architekturfit, Sicherheitsanforderungen, Gesamtkosten und Governance. Der CTO möchte wissen, ob seine Engineers ohne Lock-in selbst einen Proof of Concept umsetzen können. Der Head of IT fragt, ob sich die gewachsene Umgebung damit sicher in ein skalierbares Betriebsmodell überführen lässt.

Eine Plattform, vier Voraussetzungen für das nächste Gespräch. Ein identisches Folienset für alle Rollen überlässt dem Käufer die eigentliche Übersetzungsarbeit.

Ein Funktionsprofil ist nur dann nützlich, wenn es die Vorbereitung verändert. Starten Sie mit der vorhandenen Karte und klären Sie anschließend, welche Systeme, Verantwortlichkeiten und Entscheidungsrechte in der konkreten Organisation wirklich vorliegen.

Die Sätze sind redaktionelle Anwendungen der Kartendaten. Sie sind weder getestete Claims noch wörtliche Aussagen von Studienteilnehmern.

In realen Beschaffungsprozessen ergänzen sich diese Rollen. Ein CTO kann eine Lösung technisch bevorzugen, während der CIO Architektur und Risiken prüft. Der IT-Manager muss das Ergebnis betreiben. Der Head of IT macht aus der Planung einen machbaren Einführungspfad.

Daraus sollten keine vier widersprüchlichen Angebote werden. Entwickeln Sie eine gemeinsame Nutzenlogik mit Problem, erwarteter Wirkung, Grenzen und Umsetzung. Stellen Sie die jeweils relevanten Nachweise daneben. Benennen Sie Zielkonflikte offen, etwa zwischen schnelleren Releases und zusätzlichem Betriebsrisiko oder zwischen Entwicklerfreiheit und Governance.

Die Karten beschreiben Aktivität aller vier Rollen auf LinkedIn. Gleichzeitig unterscheiden sich die weiteren Informationsquellen: IT-Manager nutzen Fachmedien, Tweakers und Anbieternewsletter; CIOs folgen auch Analystenberichten. CTOs bewegen sich zusätzlich auf GitHub, Hacker News, X und in Tech-Podcasts; Heads of IT nutzen Communities und Webinare.

Daraus ergeben sich unterschiedliche Inhalte: eine Betriebs- und Implementierungscase für den IT-Manager, Architektur- und Risikoanalysen für den CIO, technische Dokumentation und Demo für den CTO sowie ein Wachstumsfahrplan für den Head of IT. Das sind profilgestützte Empfehlungen und keine gemessenen Conversionraten pro Kanal.

Weitere Vertiefung bieten Tonalität und Umgang mit Einwänden. Lesen Sie anschließend unsere Vergleiche CIO versus CTO und IT-Manager versus Head of IT.

Der eine IT-Verantwortliche muss Störungen verhindern, der nächste die Architektur verantworten, der dritte sein Engineeringteam schneller machen und der vierte eine gewachsene Umgebung professionalisieren. Deshalb aktiviert dasselbe Angebot vier unterschiedliche Fragen.

Eine gute IT-Proposition erklärt nicht nur die Technik. Sie zeigt für jede Rolle, welches Ergebnis besser wird, welches Risiko beherrschbar bleibt und welcher Nachweis die Entscheidung trägt. Erst das Entscheidungsproblem, dann die Funktionen.