Es gibt im Markt der IT-Services-Advisory ein Paradox, das mich seit Jahren trifft: jene, die Unternehmen beraten, wie sie ihre Tech-Lieferanten auswählen sollen, sind in der überwältigenden Mehrheit Personen, die nie einen IT-Service gebaut, bepreist, geliefert oder vor einem unzufriedenen Kunden verteidigt haben.
Keine Kritik. Eine strukturelle Beobachtung. Mit realen Folgen dafür, wie Sourcing-Entscheidungen getroffen werden — und wie viele davon sich als falsch erweisen.
Das Handwerk von innen
Ich habe über fünfzehn Jahre auf der anderen Seite des Tisches verbracht. Nicht als Bewerter von IT-Services, sondern als jemand, der sie entwirft, verkauft, liefert und einsteht, wenn etwas nicht funktioniert.
Bei YNAP (Yoox für die Älteren) habe ich gesehen, wie eine der größten europäischen E-Commerce-Plattformen die Beziehung zu ihren Tech-Lieferanten managte. Nicht in Theorie: in der Praxis architektonischer Entscheidungen, der Verhandlung über Lieferungen, der Entscheidungen, die bestimmen, ob ein Projekt Wert oder bloß Code liefert.
Als CTO von Anthis habe ich die technische Infrastruktur und die Lieferprozesse einer Firma von Grund auf gebaut. Diese Erfahrung lehrt: der Unterschied zwischen einem funktionierenden und einem nicht funktionierenden IT-Service liegt fast nie in der gewählten Technologie, sondern in der Qualität des Entscheidungsprozesses, der zu dieser Technologie führt.
Heute leite ich als Head of Tech & Partner von Oltrematica (ja, diese Rolle existiert formal nicht, dazu kommen wir noch) ein Projektportfolio für Kunden von TIM bis Randstad, von der Region Abruzzen bis zu den Handelskammern. Ich schreibe RFPs und antworte auf RFPs. Ich definiere SLAs und muss sie einhalten. Ich preise Managed Services und weiß genau, was jeder Bestandteil der Lieferkette kostet.
Diese Erfahrung gibt Zugang zu einer Wissensart, die von außen schwer — vielleicht unmöglich — zu erwerben ist.
Was man nur von innen sieht
Wenn ich Bewertungsframeworks für IT-Anbieter lese (Magic Quadrant, PEAK Matrix, ISG Provider Lens), erkenne ich Analysequalität und methodische Strenge. Aber ich sehe auch die blinden Flecken. Und es sind immer dieselben.
Die echten Kosten eines IT-Service stehen nicht im Preis
Der in einem Managed-Services-Angebot genannte Preis ist eine Zahl. Die echten Kosten sind ein komplexes System: der Preis plus die Kosten kommunikativer Ineffizienz plus die Kosten technischer Schulden, die anfallen, wenn der Anbieter Ecken kürzt, um im Budget zu bleiben, plus Opportunitätskosten der nicht gelieferten Funktionen, weil sie nicht im Vertrag stehen.
Ein Analyst, der Anbieter über Tagessätze vergleicht, misst die falsche Variable. Ein Anbieter mit 400 €/Tag, der in 20 Tagen liefert, kostet weniger als einer mit 300 €/Tag und 40 Tagen. Aber zu wissen, welcher in 20 und welcher in 40 liefert, verlangt, die vorgeschlagene Architektur, die Teamzusammensetzung, den Automatisierungsgrad der Lieferprozesse lesen zu können.
Das ist eine Kompetenz, die aus dem Bauen dieser Prozesse kommt, nicht aus dem Beobachten.
SLAs sind eine Sprache, kein bloßer Vertrag
Erfahrungsgemäß entstehen die meisten Probleme in IT-Outsourcing-Verträgen nicht aus falschen SLAs. Sie entstehen aus mehrdeutigen SLAs.
Ein SLA, der „Verfügbarkeit 99,9 %“ sagt, ist technisch präzise und operativ leer, wenn er nicht festlegt: wie wird Verfügbarkeit gemessen? Ist geplante Wartung enthalten? In welchem Zeitfenster wird gerechnet? Was passiert, wenn der Ausfall durch einen Dritten verursacht wird (Cloud, CDN, DNS)?
Ich habe jahrelang SLAs geschrieben. Gelernt: ein guter SLA verspricht nicht mehr, er definiert chirurgisch genau, was passiert, wenn es schiefgeht. Denn in IT-Services geht es früher oder später schief. Die Anbietergüte misst sich in der Reaktion, nicht im Versprechen.
Die Teamzusammensetzung wiegt mehr als die Teamgröße
Bewertungsframeworks belohnen tendenziell Anbieter mit großen Teams und mehreren Delivery Centers. Eine beruhigende Metrik für Käufer: mehr Personen = mehr Kapazität. Doch wer Entwicklungsteams geführt hat, weiß: das stimmt nicht.
Ein Team aus 5 gut koordinierten Senioren liefert mehr Qualität als ein Team aus 15 Personen mit drei Management-Schichten und ständigem Rotieren. Vor allem, wenn diese 5 KI-native Methoden nutzen, die individuelle Produktivität multiplizieren.
Bei Oltrematica führen wir gleichzeitig 8–10 aktive Projekte mit etwa 10 Personen. Nicht weil wir Helden sind, sondern weil wir in Automatisierung, effiziente Lieferprozesse, Werkzeuge investiert haben, die Niedrigwert-Arbeit eliminieren. Diese Effizienz erscheint in keinem Quadranten.
Der Wert der operativen Perspektive im Advisory
Ich behaupte nicht, alle Analysten müssten als IT-Anbieter gearbeitet haben. Ich behaupte, dass die operative Perspektive ein strategisches Asset des Advisory ist — heute dramatisch unterrepräsentiert.
Wenn ein CISO mich fragt, ob ein Managed-Security-Anbieter zuverlässig ist, kann ich mich nicht nur auf Zertifizierungen und Referenzen stützen. Ich kann die vorgeschlagene Architektur lesen und erkennen, ob sie für den Betrieb entworfen wurde oder bloß fürs Gewinnen der Ausschreibung. Ich kann den Statement of Work durchgehen und Grauzonen identifizieren, die in 18 Monaten zu Streitfällen werden. Ich kann beurteilen, ob das Staffing-Modell tragfähig ist oder ob ein Team versprochen wird, das es noch nicht gibt und das nachträglich aufgebaut werden müsste.
Diese Art Einblick kommt nicht aus analytischer Strenge. Sie kommt aus dem Erleben derselben Dynamiken auf der anderen Seite. Sie hat enormen Wert für Enterprise-Kunden, die Sourcing-Entscheidungen über Millionen treffen.
Die nötige Konvergenz
Der IT-Services-Advisory-Markt tritt in eine Phase exponentiell steigender Sourcing-Komplexität ein. KI, EU-Compliance, Reshoring, neue Pricing-Modelle, Cybersecurity by Design: lauter Dimensionen, die für eine korrekte Bewertung tiefes technisches Verständnis verlangen.
Generische Frameworks reichen nicht mehr. Kunden verlangen — und haben das Recht darauf — Advisor, die die Sprache der Anbieter ebenso fließend sprechen wie die des Business.
Eine Konvergenz, die der Markt noch nicht systematisch erzeugt hat. Aber sie ist unvermeidlich. Wer sie vorwegnimmt, hat einen enormen Wettbewerbsvorteil.
Dieser Beitrag ist der erste einer Reihe zu meiner Sicht auf den IT-Services-Sourcing-Markt. Im nächsten Stück erkunde ich meinen persönlichen Werdegang — vom Entwickler zum Partner — und wie jede Phase zu einer integrierten Perspektive auf den Markt der IT-Dienstleistungen beigetragen hat.
Was du mitnimmst
Der Preis in einem Angebot ist eine Zahl; die echten Kosten sind ein System aus Ineffizienz, technischer Schuld und nicht gelieferten Funktionen.
Ein guter SLA verspricht nicht mehr, er definiert chirurgisch genau, was passiert, wenn es schief geht.
Fünf gut koordinierte Seniors schlagen fünfzehn Personen mit drei Management-Schichten: Zusammensetzung wiegt mehr als Größe.
Mit KI ist der Personentag eine variable Einheit; Anbieter über Stundensätze zu vergleichen, misst die falsche Variable.
Operative Kompetenz ist Input fürs Advisory, kein Lärm: heute ist sie dramatisch unterrepräsentiert.
Fragen & Antworten
Was ist der strukturelle blinde Fleck der IT-Advisory?
Die meisten, die Unternehmen beim Tech-Einkauf beraten, haben nie einen IT-Service gebaut, bepreist, geliefert oder vor unzufriedenen Kunden verteidigt. Keine persönliche Kritik — eine Beobachtung über die operative Kompetenzlücke zwischen Analyst und Anbieter, die systematisch suboptimale Sourcing-Entscheidungen erzeugt.
Was sieht ein Anbieter, was ein Analyst nicht sehen kann?
Die echte Ökonomie der Lieferung: was jedes Glied wirklich kostet, wo Margen kompromittiert werden, welche Architekturentscheidungen einen SLA in sechs Monaten brechen werden. Wie man einen SLA mit einer Einkaufsabteilung verhandelt, die nicht weiß, was ein SLA ist. Wie man eine Eskalation managt, wenn ein Legacy-System ‚nicht aktualisierbar’ ist und doch funktionieren soll. Dieses Wissen lebt in den Liefernden, nicht in Marktbenchmarks.
Warum reicht der Preis pro Personentag als Metrik nicht mehr?
Weil mit KI der Personentag zur variablen Einheit wird. Ein Anbieter, der Coding-Agenten gut integriert, liefert in 3 Tagen, was ein Konkurrent in 10 liefert. Sie über Stundensatz zu vergleichen, lässt sie auf dem Papier gleichwertig aussehen und im Ergebnis verschieden. Es braucht Outcome-Metriken — Time-to-Prod, Fehlerrate, SLA-Einhaltung —, die klassisches Advisory mangels Liefer-Kenntnis nicht nutzt.
Was sollten Advisory-Frameworks tun?
Anbieter mit Lieferkompetenz als Primärquellen einbeziehen, nicht nur als Bewertungsobjekt. Heute definiert der Advisory-Markt Sourcing-Best-Practices, ohne dass die Liefernden eine Stimme haben. Ergebnis: eine Informationslücke, die Käufern wie Verkäufern reales Geld kostet — schließbar nur, wenn operative Kompetenz als Input anerkannt wird, nicht als Lärm.