Wer Technologieberatung googlet findet auf den ersten zehn Seiten dasselbe. Andere Logos, gleiche Sätze. Manchmal fragt man sich ob da irgendwo ein Textbaustein-Generator läuft.
Das ist kein Zufall. Es ist Absicht. Vage klingt professionell. Unkonkret verpflichtet zu nichts. Und wer nichts verspricht kann nichts nicht halten.
Hier ist eine Übersetzung der gängigsten Phrasen ins ehrliche Deutsch.
Das Phrasen-Wörterbuch
„We help organizations define clear and scalable technology adoption strategies.“ Übersetzt: Wir schreiben auf wie ihr zukünftig mit Technologie umgehen solltet. Ein Dokument. Meistens schön formatiert. Was danach passiert ist nicht unser Problem.
„Aligning IT investments with business goals for maximum ROI and future-readiness.“ Übersetzt: Wir machen eine Präsentation die zeigt dass eure IT-Ausgaben strategisch sind. Das Dokument wandert ins Ablagesystem. Der ROI wird nicht gemessen.
„AI-driven transformation.“ Übersetzt: Wir haben das Wort KI in unsere bestehenden Leistungen eingefügt. Der Prozess dahinter ist derselbe wie 2019. Die Rechnung ist höher.
„Value-add.“ Übersetzt: Wir sind teuer. Aber wir nennen es nicht so.
„Paradigmenwechsel.“ Übersetzt: Irgendetwas ändert sich. Wir wissen noch nicht genau was. Aber es klingt wichtig und rechtfertigt die nächste Workshop-Reihe.
„Synergie-Effekte.“ Übersetzt: Wenn zwei Dinge zusammenpassen, nennen wir das Synergie. Was das konkret bringt, wann und für wen: bleibt offen.
„Deep Dive.“ Übersetzt: Ein Meeting das länger dauert als die anderen. Mit mehr Post-its.
„Tech Roadmap Development.“ Übersetzt: Wir erstellen eine PowerPoint mit Zeitplan. Was auf dem Weg zwischen Folie und Realität verloren geht: nicht unsere Verantwortung.
„Architecture Assessment and Refactoring.“ Übersetzt: Wir schauen uns euren Code an, schreiben auf was kaputt ist, und empfehlen einen Umbau. Wer den Umbau macht, mit welchem Budget und in welchem Zeitraum: Folgeauftrag.
„Digital Product Engineering.“ Übersetzt: Wir haben auch Entwickler.
„Cloud Migration and Optimization.“ Übersetzt: Wir migrieren euch in die Cloud. Ob das günstiger wird als vorher: keine Garantie. Ob es schneller wird: kommt drauf an. Ob jemand hinterher den Betrieb übernimmt: gute Frage.
Warum klingt alles gleich?
Weil Consulting-Sprache nicht dazu da ist zu kommunizieren. Sie ist dazu da Kompetenz zu signalisieren ohne sich festzulegen. Je abstrakter der Satz, desto schwerer ist es hinterher zu messen ob er eingelöst wurde.
Das ist kein Vorwurf an einzelne Berater. Es ist ein strukturelles Problem. Wer nach Stunden- und Tagessätzen bezahlt wird hat keinen Anreiz klar zu sagen was am Ende rauskommt.
Was das Gegenüber denkt: „Du bekommst von mir aus alles, wenn ich lange genug hier bleiben darf.“
Und die Kunden akzeptieren es oft weil es intern einfacher ist. Wenn eine externe Beratung empfiehlt, trägt niemand persönlich die Verantwortung. Das Projekt scheitert? Die Berater waren schuld. Die Entscheidung? War datenbasiert und extern validiert.
Aus der Praxis
Wir haben mal eine Ausschreibung bekommen...
- CRM-Toolauswahl. Mehrere PDFs, dazu eine Ausfüllanleitung auf drei Seiten. Und eine Excel-Liste. 28 Spalten, 372 Zeilen.
- Erster Gedanke: Uii, das war teuer.
- Zweiter Gedanke: Wird das irgendjemand ernsthaft lesen? Wenn sieben andere Anbieter dieselbe Mail erhalten haben?
- Dritter Gedanke: Bevor wir hier Aufwand reinstecken, wollen wir miteinander reden. Alleine schon um drei Fragen zu stellen, weil die Excel-Liste unkonsistent ist. Oder steht die Antwort in einem der anderen PDFs? Schwer zu sagen.
- Wir haben angerufen. Das Gespräch war aufschlussreich.
- Die Beratung hatte die Ausschreibung gebaut, würde die Antworten auswerten und die Anbieterpräsentationen begleiten. Alles korrekt. Alles vereinbart. Die Wahrscheinlichkeit dass jemand aus dem Netzwerk der Beratung ebenfalls auf der Shortlist steht: geschätzte 95 Prozent.
Das ist nicht die Ausnahme. Das ist das Modell.
Was gute Technologieberatung stattdessen sagt
Konkrete Sätze die auf eine konkrete Frage antworten. Und die sich messen lassen.
Nicht: „Wir entwickeln eine skalierbare Technologiestrategie.“
Sondern: „Wir schauen uns eure drei größten Prozessprobleme an und sagen euch in zwei Wochen was davon automatisierbar ist. Mit konkreten Tools, konkreten Kosten, konkretem Zeitaufwand.“
Nicht: „AI-driven transformation.“
Sondern: „Wir testen einen KI-Use-Case direkt bei euch im Betrieb. Wenn er nach 48 Stunden nicht funktioniert, reden wir offen darüber warum.“
Nicht: „Wir begleiten eure Toolauswahl.“
Sondern: „Wir wählen das Tool aus und führen es ein. Weil nur wer beides macht wirklich Verantwortung übernimmt.“
Nicht: „Value-add.“
Sondern: „Am Ende wisst ihr ob es sich gelohnt hat. Wenn nicht, haben wir versagt.“
Und was eine wirklich gute Technologieberatung darüber hinaus ausmacht:
- Fokus auf dem Problem, nicht auf dem Hype. KI, Cloud, Microservices, alles kann sinnvoll sein. Aber der Ausgangspunkt ist immer das Problem, nicht die Technologie. Wer mit einer vorgefertigten Lösung ins Gespräch kommt, sucht einen Kunden für sein Produkt. Keinen Partner für euer Problem.
- Pragmatismus schlägt PowerPoint. Ein funktionierender Prototyp in einer Woche sagt mehr als ein Foliensatz in drei Monaten. Wer erst baut und dann zeigt, steht mit dem Rücken zu euch. Wer erst zeigt und dann baut, steht mit dem Rücken zur Realität.
- Messbare Ergebnisse. Was am Ende nicht gemessen werden kann, war kein Auftrag. Es war ein Gespräch. Gute Technologieberatung definiert vor dem Start was Erfolg bedeutet, und misst hinterher ob er eingetreten ist.
- Radikale Ehrlichkeit. Auch wenn es unbequem ist. Wenn die bestehende Architektur völlig überdimensioniert ist für das was das Unternehmen wirklich braucht, muss das gesagt werden. Auch wenn das bedeutet dass der Auftrag kleiner wird. Wer das nicht sagt, optimiert für die eigene Rechnung.
- Unabhängigkeit von Software-Vendoren. Wer Provisionen von Tool-Herstellern bekommt, empfiehlt keine unabhängigen Lösungen. Das ist keine Verschwörungstheorie, das ist Mathematik. Gute Technologieberatung hat kein Interesse daran welches Tool ihr kauft, solange es euer Problem löst.
- Anpacken statt aufmalen. Hände schmutzig machen. In den Code schauen. Mit dem Team arbeiten das danach damit leben muss. Wer nach dem Abschlussbericht wieder ins Taxi steigt hat nie wirklich verstanden womit ihr es zu tun habt.
Der Unterschied: Wer berät und implementiert hat Skin in the game. Wer nur berät hat immer eine Erklärung warum es am Ende nicht funktioniert hat.
Drei Fragen die den Unterschied zeigen
Bevor man einen Tech-Berater bucht:
- Was genau wird am Ende geliefert, und woran messen wir ob es funktioniert?
- Wer ist verantwortlich wenn das Ergebnis nicht eintritt? Und was passiert dann konkret?
- Wie viele Stunden Präsentation sind dabei, und wie viele Stunden Umsetzung?
Wer auf diese Fragen konkrete Antworten bekommt, hat einen guten Partner gefunden. Wer vage Antworten bekommt, hat einen Satz für die Bullshit-Liste gefunden.
Technologieberatung ist kein schlechtes Konzept. Es ist eine schlechte Branche geworden weil zu viele darin zu lange von Unklarheit profitiert haben.
Wer heute einen Technologiepartner sucht muss das nicht mehr akzeptieren. Die Frage ist nicht welche Phrasen auf der Website stehen. Die Frage ist: baut der jemand mit euch, oder schreibt er auf was ihr bauen solltet?
— Robert
