KI-Automatisierung im IT-Systemhaus und Beratungshaus: Was wirklich trägt
KI & Automatisierung
7. Februar 2026
9 Min. Lesezeit

KI-Automatisierung im IT-Systemhaus und Beratungshaus: Was wirklich trägt

Zurück zum Blog
KI & Automatisierung

Systemhäuser und Beratungshäuser stehen unter Margendruck und werden gleichzeitig mit Automatisierungs-Versprechen überflutet. Dieser Beitrag sortiert, wo der Hebel real ist, wo er Marketing bleibt und wie Sie die ersten 90 Tage so aufsetzen, dass Aufwand und Ertrag im Verhältnis stehen.

In einer Strategierunde eines mittelgroßen Systemhauses fiel vor einigen Wochen ein Satz, den ich seitdem in mindestens vier weiteren Häusern gehört habe: „Wir müssen das Ganze jetzt automatisieren — sonst arbeiten wir uns zu Tode.“ Auf dem Tisch lag eine Liste von neun Agenten, die irgendein Newsletter empfohlen hatte: Onboarding-Agent, CRM-Agent, Sales-Agent, Finance-Agent, Support-Agent, DevOps-Agent und drei weitere mit klingenden Namen. Der Geschäftsführer wollte sie alle.

Der Satz stimmt — der Druck ist real. Die Lösung aus dem Newsletter ist es nicht. „Neun Agenten ersetzen ein Backoffice“ ist genauso eine Marketing-Erzählung wie das „90-%-Automatisierungspotenzial“ aus dem letzten Beratungsdeck. Dienstleistungsgetriebene Organisationen — und das sind Systemhäuser wie Beratungshäuser im Kern — haben spezifische Strukturen, die manche Prozesse hervorragend für Automatisierung qualifizieren und andere nicht.

Dieser Beitrag sortiert beide Seiten. Aus der Perspektive von jemandem, der diese Häuser von innen kennt und gleichzeitig die Automatisierungs-Werkzeuge täglich einsetzt.

Warum die Agentur-Erzählung für Systemhäuser oft nicht passt

Die meisten Automatisierungs-Playbooks im Markt stammen aus dem Agentur- oder E-Commerce-Umfeld. Dort funktioniert vieles, weil Prozesse stark standardisiert sind: jeder neue Webshop-Kunde durchläuft ähnliche Stationen, jede Kampagne folgt einem ähnlichen Pfad. In Systemhäusern und Beratungshäusern liegen die Dinge anders.

  • Projekte sind selten Vorlagen. Ein M365-Migrationsprojekt für ein 300-Mitarbeiter-Stadtwerk hat strukturelle Ähnlichkeiten mit dem nächsten, aber genug Eigenheiten, dass ein „Standard-Onboarding-Agent“ mehr Arbeit macht als spart.
  • Wissensarbeit ist der Kern. Vertrags-Drafts, Architekturentscheidungen, Aufwandsschätzungen, Lösungsdesigns — diese Tätigkeiten lassen sich KI-unterstützen, aber nicht „automatisieren“ in dem Sinne, wie es Marketing-Decks suggerieren.
  • Vertrauen ist die Währung. Beratungshäuser leben von persönlicher Beziehung. Ein voll automatisierter Sales-Outreach beschädigt diese Währung schneller, als er Leads bringt.
  • Compliance- und Lizenzfragen sind eng. Microsoft-Partner, Datenschutz-Auflagen, Lieferantenkontrollen — viele „selbstheilende Agenten“ entgleisen, sobald sie in regulierte Räume reichen.

Wer das ignoriert und das Agentur-Playbook eins zu eins übernimmt, baut sich Automatisierungen, die in der ersten echten Projekt-Lage versagen.

Wo Automatisierung in dienstleistungsgetriebenen Häusern wirklich liefert

Es gibt klare Sweet-Spots — meistens nicht spektakulär, dafür belastbar.

Pre-Sales und Angebotserstellung

Standardabschnitte in Angeboten (Leistungsbeschreibungen, AGB, Standard-Architekturkapitel) lassen sich aus einer gepflegten Bibliothek zusammenstellen. Ein Sprachmodell mit Zugriff auf vorhandene Angebote, Templates und Preislisten kann den ersten Entwurf in 30 Minuten erzeugen statt in drei Stunden. Das funktioniert robust, weil der Wissensraum eng ist und ein Mensch die Schlussfassung ohnehin durchgeht.

Strukturierte Übergabe aus Sales an Delivery

Der klassische Bruch zwischen Vertrieb und Delivery — Sales hat alles im Kopf, Delivery sitzt im Kick-off ohne Kontext — ist in vielen Häusern teuer. Ein Tool, das aus CRM-Notizen, Mail-Threads und Angebotsdokumenten ein strukturiertes Übergabe-Briefing erzeugt, ist ein klarer Hebel. Kein Agent ersetzt das Übergabegespräch, aber er entlastet es deutlich.

Wissensmanagement quer über Projekte

Wer in vergangenen Projekten ähnliche Probleme gelöst hat, weiß das oft nur, wenn er zufällig dabei war. Ein durchsuchbarer Index über Projektdokumentation, ADRs, Lessons Learned und Code-Snippets — verbunden mit semantischer Suche — bringt Erfahrung schnell an die Stelle, wo sie gebraucht wird. Das ist klassische RAG-Architektur, kein Agent.

Standard-Anfragen im Service-Desk

Tier-1-Anfragen im Managed-Service-Geschäft (Passwort-Reset, Status-Auskünfte, Standardprozeduren) lassen sich gut automatisieren. Wichtig: Klar definierte Eskalationspfade. Tier-2 und höher sind kein gutes Automatisierungs-Ziel — die Kosten einer falschen Antwort übersteigen den Aufwand der manuellen Bearbeitung deutlich.

Reporting und Stundenauswertung

Aufbereitung der Stunden- und Projektdaten in Reports für Kunden oder interne Steuerung. Hier ist die Datenbasis strukturiert, die Anforderungen sind klar — ein hervorragender Anwendungsfall, der oft monatlich mehrere Personentage spart.

Compliance- und Lizenz-Recherche

Microsoft-Lizenzierung, Cloud-Service-Verträge, Datenschutz-Auflagen — die Recherche-Komponente lässt sich mit gut konfigurierten Modellen beschleunigen. Die Beurteilung bleibt Sache eines Menschen, die Vorrecherche kann in Minuten geliefert werden.

Code-Reviews und Architekturskizzen im Entwicklungs-Service

Wer Software-Service anbietet, profitiert von einem disziplinierten KI-Workflow in der Entwicklung. Nicht „Vibe Coding“, sondern strukturierte Review- und Vorschlagsschritte. Das ist messbar produktivitätssteigernd, ohne Qualitätsverlust — vorausgesetzt, die Disziplin stimmt.

Was sich nicht (oder schlechter) automatisieren lässt

Die ehrliche Liste ist genauso wichtig wie die der Sweet-Spots.

  • Beratungsgespräche und Anforderungs-Workshops. Hier zählt menschliches Zuhören, Nachfragen, Lesen zwischen den Zeilen. KI als Unterstützung beim Protokollieren und Strukturieren ja, KI als Ersatz nein.
  • Komplexe Aufwandsschätzungen. Schätzungen leben von Erfahrungswissen, Risikoeinschätzung und Annahmen, die selten dokumentiert sind. Modelle liefern hier oft plausibel klingende, aber gefährlich falsche Werte.
  • Architekturentscheidungen mit langfristigen Konsequenzen. Ein Modell kann Optionen sammeln und vergleichen. Die Entscheidung trifft die Architektin, weil sie das politische und technische Umfeld kennt.
  • Verhandlungen, Eskalationen, Beziehungspflege. Diese Bereiche sind nicht nur schwer automatisierbar, sie sind genau die Tätigkeiten, für die Kunden Beratungsstunden bezahlen.
  • Personalführung und Mentoring. Es klingt offensichtlich, wird in Automatisierungs-Decks aber oft mit „HR-Agent“ subsumiert. Lassen Sie es bleiben.

Die Faustregel: Tätigkeiten, bei denen ein Mensch nicht ersetzbar ist, sind kein Automatisierungs-Kandidat. Sie sind höchstens ein Kandidat für Unterstützung durch KI.

Wo Beratungshäuser anders ticken als Systemhäuser

Beide Welten sind nicht identisch. Wer in einer Organisation startet, sollte die Unterschiede kennen.

AspektIT-SystemhausBeratungshaus
GeschäftsmodellImplementierung, Managed ServicesKonzeption, Begleitung, Sub-Contracting
StandardisierungsgradMittel bis hochEher niedrig
Sweet-Spot der AutomatisierungService-Desk, Lizenz-Tracking, ReportingWissensmanagement, Pre-Sales, Recherche
Größtes RisikoFalsche Tier-1-Antwort beim KundenVerlust der persönlichen Beziehung
DatenlageStrukturiert (Ticket-Systeme, Monitoring)Halbstrukturiert (Mails, Docs, Mitschriften)
Compliance-DruckHoch (Lizenz, Datenschutz)Mittel (Mandanten-Trennung)

Systemhäuser haben in der Regel das robustere Datenfundament für Automatisierung. Beratungshäuser haben den größeren Hebel bei der Wissensmanagement-Dimension — und gleichzeitig die größere Vorsicht bei kundenseitiger Sichtbarkeit.

Die typischen Fehler beim ersten Anlauf

Wer ohne Erfahrung in diesen Häusern startet, läuft fast immer in dieselben Fallen.

Zu viele Agenten gleichzeitig. Die Newsletter-Inspiration mit neun Agenten endet meist mit vier halbfertigen Setups, deren Pflege niemand übernehmen kann. Besser: ein Agent oder ein Use Case, in den drei Monate Fokus gehen.

Automatisierung in beziehungsgetriebenen Prozessen. Voll automatisierter Outreach an Bestandskunden ist eine Möglichkeit, vertrauensvolle Beziehungen schnell zu beschädigen. Wer das nicht erkennt, lernt es in der ersten Beschwerde.

Schatten-IT in der Wissensbasis. Wenn ein Berater seine Mail-Historie in einem Cloud-Tool indizieren lässt, das die IT nicht kennt, ist die Datenschutzlage angespannt. Automatisierung muss Teil der IT-Strategie sein, nicht des Berater-Heimwerks.

Falsche KPIs. „Zeitersparnis pro Agent“ ist ein interessanter Wert für Marketing, sagt aber wenig über den realen Nutzen. Sinnvolle KPIs sind etwa: Anteil der Tier-1-Anfragen, die automatisiert beantwortet werden; durchschnittliche Bearbeitungszeit für Pre-Sales-Antworten; Trefferquote der Wissens-Suche.

Fehlende Eigentümerschaft. Ein Onboarding-Agent ohne fachlichen Eigentümer veraltet innerhalb von sechs Monaten. Wer keinen Verantwortlichen pro Use Case benennt, baut Automatisierung auf Sand.

Compliance als Nachgedanke. EU AI Act, DSGVO, mandantenspezifische Auflagen — diese Themen müssen vor dem Bauen geklärt werden, nicht danach. Sonst stoppt der erste Kunden-Audit das ganze Setup.

Ein realistischer 90-Tage-Pfad

Statt eines „Roll-out-Plans mit fünf parallelen Initiativen“ hier ein nüchterner Pfad, der in einem Quartal echte Ergebnisse liefert.

Wochen 1–2 — Bestandsaufnahme

Welche Prozesse fressen tatsächlich Zeit? Ein einfacher Workshop mit Delivery-, Sales- und Operations-Verantwortlichen reicht. Ziel: ein Backlog von 10–15 Kandidaten mit grober Aufwand-/Nutzen-Bewertung.

Wochen 3–4 — Use-Case-Auswahl

Aus dem Backlog die zwei bis drei Use Cases auswählen, die folgende Kriterien erfüllen: hoher Wiederholungsgrad, strukturierte Datenbasis, klarer fachlicher Eigentümer, akzeptables Risiko bei Fehlern. Den anderen zwölf Kandidaten freundlich „später“ sagen.

Wochen 5–8 — Erste Umsetzung

Ein Use Case wird umgesetzt — nicht parallel. Ein einfaches Setup, sauberer Test, klare Erfolgskriterien. Wenn nach vier Wochen kein messbarer Effekt da ist, ist es ein Lerngewinn — kein Misserfolg, der weiter ausgebaut werden müsste.

Wochen 9–12 — Stabilisierung und Lernen

Den ersten Use Case in den Regelbetrieb bringen, Pflegeprozess etablieren, KPIs ablesen. Erst danach den zweiten Use Case angehen, mit dem Wissen aus dem ersten Durchgang.

Dieser Pfad sieht weniger spektakulär aus als ein Sechs-Streams-Plan. Er hat aber eine Eigenschaft, die der Sechs-Streams-Plan selten hat: Er wird zu Ende gebracht.

Was es braucht, damit Automatisierung in der Organisation hält

Über die Tools hinaus gibt es organisatorische Voraussetzungen, ohne die Automatisierung im ersten Jahr wieder einschläft.

  • Klare Eigentümerschaft pro Use Case. Wer fachlich verantwortlich ist, wer technisch betreibt, wer den KPI prüft — alle drei müssen benannt sein.
  • Datenpflege als Daueraufgabe. Wissensbasen veralten. Pflege-Slots im Kalender, nicht „wenn Zeit ist“.
  • Schulung und Akzeptanz. Berater und Engineers nutzen Werkzeuge, die ihnen vertraut sind. Eine kurze Schulungsphase pro Use Case ist Pflicht.
  • Governance-Rahmen. Welche Daten dürfen wohin, welche Modelle sind freigegeben, welche Logs werden aufbewahrt — Antworten gehören in eine Richtlinie, nicht in den Köpfen einzelner Personen.
  • Realistisches Erwartungsmanagement gegenüber der Geschäftsführung. Wer nach drei Monaten 50 % Effizienzgewinn verspricht und 12 % liefert, verliert intern Glaubwürdigkeit. Lieber konservativ versprechen, dann übertreffen.

Das sind unspektakuläre Punkte. Sie sind aber der Grund, warum manche Häuser nach einem Jahr stabile Automatisierung haben und andere wieder am Anfang stehen.

Fazit

Automatisierung in IT-Systemhäusern und Beratungshäusern lohnt sich — aber nicht in der Form, in der die meisten Marketing-Decks sie verkaufen. Die Sweet-Spots liegen in strukturierten, wiederkehrenden Tätigkeiten mit klarem fachlichem Eigentümer: Pre-Sales-Vorbereitung, Service-Desk-Tier-1, Reporting, Wissensmanagement, Stundenauswertung, Compliance-Recherche. Die Tabu-Zonen liegen dort, wo Vertrauen, Erfahrungswissen und Beziehung den Kern der Wertschöpfung bilden.

Wer in den ersten 90 Tagen nicht versucht, „alles“ zu automatisieren, sondern einen Use Case sauber zu Ende bringt, hat nach einem Jahr eine belastbare Plattform. Wer das große Agent-Fleet-Versprechen kauft, hat nach einem Jahr meistens eine Sammlung halbfertiger Setups und eine Geschäftsführung, die das Vertrauen verloren hat.

Die spannende Frage ist nicht, wie viele Agenten ein Haus laufen lässt. Sie lautet: Welche zwei Prozesse soll ich in diesem Quartal so automatisieren, dass sie in zwölf Monaten noch laufen — und an welcher Stelle bleibt der Mensch bewusst der Engpass, weil dort die Marge meines Hauses entsteht?

Teilen:X / TwitterLinkedIn

Weiterlesen