Vor einigen Wochen erhielt ich den Bericht eines bekannten Advisory-Hauses zur Bewertung des IT-Service-Marktes in unserem Segment. Ich las ihn aufmerksam, denn meine Kunden lesen so etwas, bevor sie sich entscheiden. Der Bericht war gut geschrieben, die Marktanalysen solide, die identifizierten Trends zutreffend. Und doch dachte ich beim Lesen ständig: wer das geschrieben hat, hat nie ein Software-Projekt für einen Kunden der italienischen öffentlichen Verwaltung geliefert. Hat nie einen SLA mit einer Einkaufsabteilung verhandelt, die nicht weiß, was ein SLA ist. Hat nie einer Klinikleiterin erklärt, warum ihr Legacy-System nicht einfach „aktualisiert“ werden kann, ohne die ganze Integration mit dem regionalen Informationssystem neu zu machen.
Keine Kritik. Eine Beobachtung über einen strukturellen blinden Fleck im IT-Advisory-Markt. Die Personen, die Unternehmen beim Tech-Einkauf beraten, haben in der überwältigenden Mehrheit nie Tech verkauft. Und die, die Tech verkaufen und ausliefern, haben keine Stimme in der Definition von Sourcing-Best-Practices. Resultat: ein Informationsdefizit, das Käufer wie Verkäufer reales Geld kostet.
Ich sage das aus Erfahrung. Ich führe eine kleine ICT-Firma, die von Verträgen mit Mid-Market-Kunden und der öffentlichen Verwaltung lebt. Ich habe Angebote geschrieben, Verträge verhandelt, SLAs definiert, Eskalationen gemanagt, Strafen kassiert, Projekte zu spät und früher geliefert. Ich habe den IT-Service-Markt von der Tischseite gesehen, die Sourcing-Analysten selten sehen. Und was ich sehe, deckt sich nicht immer mit den Beschreibungen der Advisory-Frameworks.
Erster blinder Fleck: das Pricing
Die meisten Advisory-Frameworks bewerten IT-Anbieter nach Kosten pro Personentag oder Funktionspunkt. Verständliche, vergleichbare und im Grunde überholte Metriken. KI macht das Verhältnis zwischen Arbeitszeit und geliefertem Wert vollständig nichtlinear. Ein Fünfer-Team mit agentischem Coding liefert in einer Woche, was ein Fünfzehner-Team in einem Monat lieferte. Identischer Wert für den Kunden. Ein Fünftel der Personentage. Zahlt der Kunde nach Personentagen, hat der Anbieter den perversen Anreiz, KI nicht zu adoptieren — er fakturiert weniger. Adoptiert der Anbieter KI und der Kunde misst weiter Personentage, wirkt der Anbieter pro Tag fünfmal teurer, auch wenn der Gesamtkostenpunkt sinkt.
Kein theoretisches Problem. Ich begegne ihm jeden Monat in Angeboten. Ich preise seit über einem Jahr nicht mehr nach Personentagen. Ich preise nach Liefergegenstand: hier das Ergebnis, hier der Preis, hier die Bedingungen. Manche Kunden schätzen das. Andere — vor allem in der PA, deren Ausschreibungen um Personentage herum gestrickt sind — wissen nicht, wie sie damit umgehen sollen. Der Beschaffungsrahmen sieht keinen Anbieter vor, der mehr Wert in weniger Zeit liefert.
Zweiter blinder Fleck: Compliance als Sourcing-Kriterium
Frameworks beginnen, sie aufzunehmen — als Häkchen: „Anbieter DSGVO-konform? Ja/Nein“. Radikal unzureichend. Compliance ist nicht binär. Sie ist ein Spektrum. Ein Anbieter kann eine Datenschutzerklärung auf der Website haben und keinen technischen Mechanismus zur Datenminimierung im Code. Behaupten, AI-Act-konform zu sein, ohne zu wissen, was eine Risikobewertung für Hochrisiko-KI-Systeme ist. Das SBOM-Häkchen setzen, ohne eine Pipeline, die SBOMs bei jedem Build automatisch erzeugt.
Ein ernstes Sourcing-Framework, im heutigen EU-Kontext, sollte Compliance nicht als Erklärung, sondern als technische Fähigkeit bewerten. Hat der Anbieter einen dokumentierten Schwachstellenprozess? Beinhaltet seine CI/CD-Pipeline einen Dependency-Scan? Werden SBOMs automatisch erzeugt oder per Hand zusammengestellt? Hat seine Software automatisierte Tests, die Privacy-Eigenschaften prüfen? Diese Fragen offenbaren mehr als jede Zertifizierung. Und nur wer operative Liefererfahrung hat, kann sie formulieren.
Dritter blinder Fleck: die IT-KMU
Der Advisory-Markt ist um die großen Systemintegratoren strukturiert. Bewertungsmatrizen, Magic Quadrant, Wave, Provider Lens — alle auf Unternehmen mit Hunderten Millionen Umsatz geeicht. IT-KMU — die in Europa die überwältigende Mehrheit der Software-Service-Anbieter darstellen — sind in diesen Frameworks unsichtbar. Nicht weil sie keinen Wert liefern, sondern weil sie nicht die Skala haben, an Bewertungsprozessen teilzunehmen.
Daraus ein Paradox. Der Mid-Market-Kunde — die Firma mit 200-500 Mitarbeitenden, die Klinik, die Kommune, die Handelskammer — liest die Berichte und sieht nur große Namen. Aber die Großen bedienen den italienischen Mid-Market nicht oder mit Junior-Teams unter Aufsicht eines nie sichtbaren Partners. Der Anbieter, der die Arbeit wirklich liefert — die lokale Zehn-Personen-KMU mit einer Senior pro Projekt und direkter Beziehung zum Entscheider —, taucht in keinem Framework auf. Vollständige Informationslücke.
Vierter blinder Fleck: Vertragsgovernance
Frameworks sind sehr gut darin, die Auswahlphase zu bewerten: wie man wählt, vergleicht, verhandelt. Sehr viel schlechter in der Ausführungsphase: wie man überwacht, eingreift, Scope-Änderungen managt. Aus meiner Erfahrung entstehen 90 % der Probleme nicht aus falscher Wahl des Anbieters. Sie entstehen aus schlechter Vertragsführung danach.
Ich habe Projekte scheitern sehen, nicht weil der Anbieter unfähig war, sondern weil der Kunde keine interne Governance hatte, um Anforderungsänderungen zu entscheiden. SLAs auf Cent-Genauigkeit verhandelt, die niemand überwachte. Vertragsstrafen, die nie angewandt wurden, weil der Kunde zu sehr vom Anbieter abhing, um ihn zu sanktionieren. Wiederkehrende Muster, die jeder IT-Anbieter intim kennt und die Frameworks als Ausnahmen behandeln.
Fünfter blinder Fleck: technische Qualität und Business
Vielleicht der tiefste: das Verhältnis zwischen technischer Qualität und Geschäftserfolg. Frameworks bewerten Preis, Track Record, Teamgröße, Zertifikate. Selten die technische Qualität der gelieferten Software. Wie viele automatische Tests im Codebase? Welche Coverage? Wie ist die Architektur strukturiert? Ist der Code wartbar? Ist die Doku aktuell? Diese Dimensionen bestimmen die echten Total Cost of Ownership — nicht die deklarierten — und Sourcing-Analysten sind nicht ausgerüstet, sie zu beurteilen.
Resultat: der Markt belohnt die Verkaufsfähigkeit — überzeugende Präsentationen, solide Referenzen, große Teams — statt der Baufähigkeit. Das erklärt, warum so viele IT-Projekte das Doppelte des Geplanten kosten und die Hälfte des Versprochenen liefern: die Auswahl erfolgt anhand von Kriterien, die die Ausführungsqualität nicht vorhersagen.
Ich schreibe das nicht aus Lust, eine Branche zu kritisieren, die ich respektiere und ehrlich gesagt interessant finde. Ich schreibe es, weil der IT-Advisory-Markt an einem Wendepunkt steht. KI verändert die Ökonomie der Lieferung. EU-Compliance verändert die Einkaufskriterien. Der europäische Mid-Market braucht Bewertungsframeworks, die keine vereinfachten Versionen der Enterprise-Frameworks sind. Und IT-Anbieter — jene, die wirklich bauen und liefern — haben ein operatives Wissen, das, in Advisory-Frameworks integriert, sie viel nützlicher machte.
Ich beanspruche keine Lösung. Aber nach fünfzehn Jahren auf der anderen Tischseite weiß ich, welche Fragen gestellt werden sollten und nicht gestellt werden. Welche Metriken Projekterfolg vorhersagen und welche nur die Qualität der ersten Präsentation. Was sich im Pricing ändert, wenn KI in den Lieferzyklus tritt. Was Compliance in einer Produktions-Codebase heißt, nicht in einem Policy-Dokument.
Wissen, das der Advisory-Markt nicht hat — nicht aus Inkompetenz, sondern weil er strukturell von der Lieferung getrennt ist. Vielleicht ist es Zeit, eine Brücke zu bauen.
Was du mitnimmst
Kosten pro Personentag sind veraltet: KI macht den Personentag zur variablen Einheit, und so zu bewerten bestraft jene, die KI eingeführt haben.
Compliance wird als Häkchen behandelt statt als technische Fähigkeit — nur wer Lieferung kennt, weiß, welche Fragen sie wirklich offenbaren.
IT-KMU bedienen den europäischen Mid-Market, sind aber in auf Großanbieter geeichten Frameworks unsichtbar: total fehlende Information.
90 % der Misserfolge entstehen nicht aus falscher Anbieterauswahl, sondern aus schlechter Vertragsführung danach — die Advisory bewertet diese Phase kaum.
Der Markt belohnt Verkaufsfähigkeit, nicht Bauen; deshalb kosten Projekte das Doppelte und liefern die Hälfte.
Fragen & Antworten
Was macht einen gut geschriebenen Advisory-Bericht operativ blind?
Der Autor hat den Markt mit Strenge analysiert, aber nie ein Software-Projekt für die italienische öffentliche Verwaltung geliefert, nie einen SLA mit einer Einkaufsabteilung verhandelt, nie einer Klinikleiterin erklärt, warum ihr Legacy nicht ‚aktualisierbar’ ist, ohne die Integration mit dem regionalen Informationssystem neu zu machen. Marktanalysen solide, operative Schlüsse nicht. Es entstehen Sourcing-Entscheidungen, die informiert wirken und es nicht sind.
Warum wird der Personentag als Metrik obsolet?
Weil KI ihn zur variablen Einheit macht. Ein Anbieter mit gut integrierten Coding-Agenten liefert in drei Tagen, was ein Konkurrent in zehn liefert. Ein Stundensatz-Vergleich lässt sie auf dem Papier gleichwertig wirken und zeigt den Unterschied erst im Ergebnis. Es braucht Outcome-Metriken — Time-to-Prod, Fehlerrate, SLA-Einhaltung —, die klassisches Advisory mangels Liefer-Kenntnis nicht nutzt.
Was sehen Advisory-Frameworks an der echten Ökonomie der IT-Services nicht?
Was jedes Glied der Lieferkette wirklich kostet, wo Margen gepresst werden, welche Architekturentscheidungen einen SLA in sechs Monaten brechen werden. Diese Daten leben in den liefernden Firmen, nicht in Marktbenchmarks. Ein Framework kann das ‚Was’ des Sourcings beschreiben — ohne das ‚Wie’ der Lieferung produziert es plausible, keine informierten Entscheidungen.
Was sollte ein IT-Käufer einen Anbieter vor der Wahl fragen?
Nicht nur was er bepreist, sondern wie. Wie er eine Eskalation managt, wenn ein SLA bricht. Mit jemand aus dem Team sprechen, das ein ähnliches Projekt geliefert hat und es sechs Monate später verteidigen musste. Antworten auf diese Fragen sagen mehr über den Tagessatz aus als jede Spalte im Spreadsheet — und sind genau die Fragen, die Advisory-Berichte nicht zu formulieren helfen.