Karlsruhe, 07.09.2026 – Die Opereon Consulting GmbH ist zum 07.09.2026 vollständig auf die Consileon Business Consultancy GmbH verschmolzen. Damit tritt Opereon künftig nicht mehr als eigenständige Gesellschaft auf, sondern bietet ihre Leistungen unter der Marke Consileon an. Als Teil der Consileon-Gruppe war Opereon bereits eng mit dem Unternehmen verbunden, mit der Verschmelzung wird diese Verbindung nun auch gesellschaftsrechtlich vollzogen.
In den vergangenen Jahren hat sich Opereon durch methodische Prozessberatung und Prozessoptimierung ausgezeichnet. Neben einem Schulungsangebot in Lean Six Sigma sowie Kompetenz in Business-Analyse, Requirements Engineering und Product Ownership, bot Opereon seinen Kunden zudem die Entwicklung von KI-gestützter Individualsoftware an. Diese Stärken werden nun ergänzender Bestandteil des Leistungsportfolios von Consileon.
Stefan Grabatin, Principal bei Consileon, erklärt: „Von der Verschmelzung profitieren vor allem unsere Kunden. Durch unser gebündeltes Leistungsangebot können wir einen noch stärkeren Fokus auf die Lösung wichtiger Herausforderungen für das Geschäft unserer Kunden legen. Unsere Kompetenz in der Analyse und Optimierung geschäftskritischer Prozesse auf der einen Seite, sowie der Umsetzung von KI-getriebenen Individuallösungen auf der anderen Seite.“
Das Prozessberatungswissen und die Lean-Six-Sigma-Methodik werden branchenübergreifend eingesetzt und finden insbesondere in der Finanzbranche breite Anwendung. Opereon unterstützt ab sofort außerdem den Bereich Software Solutions und bringt dort ihre IT- und KI-Entwicklungskompetenz mit ein. Damit stärkt der Bereich seine Kompetenz in der Umsetzung individueller, KI-getriebener Softwarelösungen.
LLMs verändern die Softwareentwicklung spürbar. Code und Tests können schneller erzeugt, Prototypen schneller generiert und Dokumentationen effizienter erstellt werden. Doch der erfolgreiche Einsatz von KI im Software Development Life Cycle (SDLC) entsteht nicht durch ein einzelnes Tool. Gerrit Verse erklärt im Interview, warum Unternehmen klare Leitplanken benötigen, welche Fehler häufig passieren und wie Consileon KI-gestützte Entwicklung praxisnah, sicher und wirksam in Teams integriert.
KI ist in der Softwareentwicklung angekommen und wird nicht wieder verschwinden. Der Grund dafür ist einfach: Sie kann viele Aufgaben schneller und effizienter erledigen. Dieser Support erstreckt sich mittlerweile über den gesamten SDLC: vom konzeptionellen Sparring und der Qualitätssicherung von User Storys über konkrete Implementierungshilfe und Testgenerierung bis zu Architekturanalysen und detailliertem Reporting.
Gleichzeitig verändert KI nicht nur einzelne Arbeitsschritte, sondern zunehmend die Art, wie Software entwickelt wird. Entwicklungsteams können sich stärker auf fachliche Anforderungen, Lösungsdesign und Qualitätssicherung konzentrieren, während repetitive Tätigkeiten automatisiert werden.
Viele Unternehmen starten mit einem leistungsfähigen Modell und erwarten automatisch bessere Ergebnisse und sofortige Produktivitätsgewinne, die ausbleiben. KI ist kein Selbstzweck. Sie kann ein sehr leistungsfähiges Werkzeug sein, wenn sie gezielt eingesetzt wird. In der Praxis zeigt sich schnell, dass dafür oft wichtige Voraussetzungen fehlen. Daten sind nicht in der benötigten Qualität verfügbar, Verantwortlichkeiten sind unklar oder bestehende Prozesse sind gar nicht darauf ausgelegt, KI sinnvoll zu integrieren.
Ein weiterer Fehler ist, bei ersten Prototypen stehen zu bleiben. Häufig werden beeindruckende Demos gebaut, ohne die dahinterliegenden Arbeitsabläufe grundlegend zu hinterfragen. Das eigentliche Potenzial entsteht aber erst, wenn Unternehmen den Mut haben, ihre Entwicklungsprozesse neu zu denken und KI systematisch in den Software Development Lifecycle einzubinden.
Hinzu kommt das Risiko des blinden Vertrauens. KI kann sehr überzeugend wirken, auch wenn der erzeugte Code fachlich, architektonisch oder qualitativ nicht den Anforderungen entspricht. Dann entstehen Logikfehler, unnötige Komplexität oder andere technische Schulden. KI beschleunigt deshalb nicht automatisch gute Softwareentwicklung, sondern zunächst einmal das, was man ihr vorgibt.
Auf ein kurzes Hoch kommt schnell die ernüchternde Erkenntnis, dass die KI nicht die Qualitätsziele langfristig erfüllen kann, die man sich vorstellt. Ab diesem Punkt beginnt die KI-Ingenieursleistung und die muss gekonnt sein. Erfolgreiche KI-gestützte Softwareentwicklung beginnt deshalb nicht mit dem Tool, sondern mit klaren Prinzipien für den Einsatz von KI. Erst dann können Unternehmen die Potenziale der Technologie nachhaltig und kontrolliert nutzen.
Unser Ansatz basiert auf drei Säulen: passende Rahmenbedingungen, klare Leitsätze und das richtige Tooling.
Die wichtigste Grundlage sind die Rahmenbedingungen. Unternehmen müssen zunächst klären, welche KI-Lösungen genutzt werden dürfen, wie Beschaffung und Zugriff organisiert sind, welche Sicherheitsanforderungen gelten und wie der Einsatz von KI durch Management und Organisation unterstützt wird. Ohne diese Voraussetzungen scheitern viele Initiativen bereits, bevor sie einen echten Mehrwert erzeugen.
Die zweite Säule sind klare Leitsätze und befähigte Mitarbeiter. Dazu gehört etwa der Grundsatz: so wenig KI wie nötig, so viel wie sinnvoll. Ein weiterer wichtiger Leitsatz lautet: Kontext ist eine Ressource. Jede Information, die einem Modell bereitgestellt wird, muss verarbeitet werden. Deshalb sollte Kontext bewusst ausgewählt und nicht wahllos vergrößert werden. Gleichzeitig müssen Teams verstehen, wie KI funktioniert, wo ihre Grenzen liegen und wie Ergebnisse kritisch bewertet werden können.
Erst die dritte Säule ist das Tooling / AI-Engineering. Hier geht es darum, für jede Aufgabe die passenden Werkzeuge auszuwählen. Ein Teil ist das Modell, jedoch viel wichtiger ist es, wie die Daten durch clevere Ingenieursleistung ihren Weg in den Kontext finden.
Weil KI nicht automatisch die beste Lösung für jede Aufgabe ist. Klassische, deterministische Software ist in vielen Situationen deutlich schneller, günstiger und verlässlicher als das neueste und größte KI‑Modell. Wenn eine Aufgabe durch klare Regeln beschrieben werden kann, sollte sie auch regelbasiert gelöst werden. KI kommt primär dort zum Einsatz, wo klassische Ansätze an ihre Grenzen stoßen, etwa bei der Verarbeitung unstrukturierter Daten.
Daraus ergeben sich für uns zwei wichtige Grundsätze: Erstens: deterministisch, wo möglich – KI, wo nötig. Zweitens: Das KI-Modell sollte immer so klein wie möglich gewählt werden. Kleinere Modelle sind häufig kosteneffizienter, schneller und für viele Aufgaben völlig ausreichend. Deshalb betrachten wir jeden Anwendungsfall sehr genau. Geht es um Recherche, Dokumentation, Codegenerierung, Refactoring, Testing oder eine Softwarelösung mit KI? Je nach Aufgabe unterscheiden sich die Anforderungen an Qualität, Geschwindigkeit, Kosten und Kontrolle. Genau diese Differenzierung fehlt in vielen Unternehmen noch. Dabei entscheidet sie häufig darüber, ob KI wirtschaftlich und nachhaltig eingesetzt wird.
KI sollte nicht reflexhaft überall eingesetzt werden. Manchmal ist ein klarer Prozess, ein gutes Template oder eine saubere Architekturentscheidung wirksamer als ein KI-Agent. Der Punkt ist: KI soll Komplexität reduzieren, nicht neue schaffen. Wenn ein Entwickler mehr Zeit damit verbringt, KI-Ausgaben zu prüfen, zu korrigieren oder wieder aufzuräumen, weil die Qualität nicht stimmt, ist nichts gewonnen. Deshalb muss man sehr bewusst entscheiden, wo KI wirklich hilft und wo klassische Softwareentwicklung überlegen bleibt.
Eine zentrale Rolle. Wir sprechen bewusst von KI-gestützter Softwareentwicklung und nicht von autonomer Softwareentwicklung. Der Mensch bleibt verantwortlich für Architektur, Qualität, Sicherheit und die fachliche Korrektheit einer Lösung.
Ein großes Risiko besteht darin, dass Teams die Kontrolle über ihre eigenen Systeme verlieren. Wenn KI große Mengen Code erzeugt, ohne dass nachvollzogen wird, warum bestimmte Entscheidungen getroffen wurden, entstehen sogenannte kognitive Schulden. Die Software funktioniert zunächst, aber nach einiger Zeit versteht niemand mehr vollständig, wie sie aufgebaut ist oder welche fachlichen Anforderungen ursprünglich dahinterstanden. Wartung, Weiterentwicklung und Fehlerbehebung werden dadurch deutlich schwieriger.
KI-generierter Code muss deshalb konsequent geprüft, getestet und in den fachlichen Kontext eingeordnet werden. Code Reviews werden dadurch sogar anspruchsvoller. Ziel ist nicht, möglichst viel Arbeit an die KI abzugeben, sondern die Kontrolle über die eigene Lösung jederzeit zu behalten. Deshalb sehen wir die Rolle der KI eher als die eines sehr leistungsfähigen Junior-Partners: Sie unterstützt bei der Umsetzung, liefert Vorschläge und beschleunigt viele Arbeitsschritte. Die Verantwortung für die fachlichen Entscheidungen und die Bewertung der Ergebnisse bleibt jedoch beim Menschen.
Der größte Mehrwert entsteht überall dort, wo unstrukturierte Informationen verarbeitet werden müssen. Genau das war lange eine Schwäche klassischer Software. KI kann Texte, Dokumente, E-Mails, Quellcode oder andere unstrukturierte Daten verarbeiten und in eine nutzbare Form bringen.
In der Softwareentwicklung betrifft das beispielsweise bestehende Codebasen, Anforderungen, User Storys oder Dokumentationen. KI kann helfen, Zusammenhänge zu erkennen, Informationen zu strukturieren, fehlende Dokumentation zu ergänzen oder dabei helfen, sich schneller in komplexe Systeme einzuarbeiten. Auch die Generierung von Code, Tests oder technischen Dokumentationen profitiert davon.
Wichtig ist dabei, dass der eigentliche Mehrwert nicht im Schreiben einzelner Codezeilen liegt. Der größere Hebel entsteht, wenn KI dabei hilft, Wissen zugänglich zu machen, Zusammenhänge sichtbar zu machen und Informationen effizient aufzubereiten. Denn genau diese Tätigkeiten waren bislang oft zeitaufwendig, manuell und schwer zu automatisieren.
Gleichzeitig gilt auch hier: KI liefert Unterstützung und Vorschläge, aber keine absolute Wahrheit. Die fachliche Bewertung und die Verantwortung für das Ergebnis bleiben beim Menschen.
Wenn die organisatorischen und technischen Rahmenbedingungen geschaffen sind, ist Befähigung der wichtigste Erfolgsfaktor. Entwickler müssen verstehen, wie KI arbeitet, wo ihre Stärken liegen, aber auch, wo ihre Grenzen sind. Die bloße Kenntnis von Prompt-Techniken wird oft überschätzt und ist nur der erste Schritt. Der eigentliche Wert entsteht erst durch ein fundiertes Systemverständnis: Wie steuere ich den Kontext gezielt? Wo liegen die architektonischen Grenzen des Modells? Und vor allem: Wie validiere ich den Output methodisch? KI ist ein massiver Beschleuniger, aber die Endverantwortung für Code-Qualität und Wartbarkeit lässt sich nicht an ein LLM wegdelegieren, sie bleibt rundum beim Entwickler.
Gleichzeitig verändert KI die Zusammenarbeit in Entwicklungsteams. Niemand möchte ungeprüften, KI‑generierten Code reviewen, dessen Entstehung oder fachlicher Hintergrund nicht nachvollziehbar ist. Deshalb müssen Rollen, Verantwortlichkeiten und Qualitätsprozesse teilweise neu gedacht werden. Die Frage lautet nicht mehr nur: Wer schreibt den Code? Sondern auch: Wer versteht ihn, bewertet ihn und übernimmt langfristig die Verantwortung dafür?
Deshalb setzen wir auf praxisnahe Unterstützung direkt im Team. Nicht abstrakt in Schulungen, sondern am echten Code, an realen Anforderungen und innerhalb bestehender Entwicklungsprozesse. So entsteht Schritt für Schritt die Kompetenz, KI sinnvoll, effizient und verantwortungsvoll im Arbeitsalltag einzusetzen.
Wir beginnen bei der Problemstellung. Jedes Unternehmen, jedes Entwicklungsteam und jeder Anwendungsfall ist anders. Deshalb hören wir genau zu, welche Herausforderungen bestehen, welche Ziele erreicht werden sollen und warum bisherige Ansätze möglicherweise nicht den gewünschten Erfolg gebracht haben.
Dabei verbinden wir langjährige Erfahrung in der Softwareentwicklung mit fundierter KI-Expertise. Consileon entwickelt seit vielen Jahren selbst Software und beschäftigt sich bereits seit 2018 intensiv mit dem Einsatz von KI in unterschiedlichen Anwendungsfeldern. Diese Erfahrung und die kontinuierliche Weiterentwicklung helfen uns, Grenzen dieser Technik auszuweiten und Lösungen zu entwickeln, die viele für schwer bis unmöglich hielten.
Je nach Situation unterstützen wir auf unterschiedlichen Ebenen: von strategischen Fragen rund um Governance, Toolauswahl und Entwicklungsprozesse über den fachlichen Austausch auf Expertenebene bis hin zur direkten Mitarbeit in Projekten. Gemeinsam mit unseren Kunden entwickeln wir passende Vorgehensweisen, etablieren Leitplanken für den verantwortungsvollen Einsatz von KI und helfen dabei, Teams nachhaltig zu befähigen.
Dabei geht es uns nicht darum, möglichst viel KI einzusetzen. Unser Ziel ist, für jeden Anwendungsfall die sinnvollste Lösung zu finden – effizient, nachvollziehbar und langfristig tragfähig.
Stellen Sie sich nicht zuerst die Frage, welches Tool Sie kaufen sollten. Stellen Sie sich die Frage: Welches Problem möchten wir eigentlich lösen? KI ist kein Ziel an sich, sondern ein Werkzeug. Wenn sie dabei hilft, ein konkretes Problem besser, schneller oder wirtschaftlicher zu lösen, kann sie einen enormen Mehrwert schaffen. Wenn nicht, ist möglicherweise ein anderer Ansatz die bessere Wahl.
Wichtig ist außerdem, dem Thema die notwendige Rückendeckung zu geben. Erfolgreiche KI-Initiativen entstehen nicht allein durch Technologie. Sie benötigen klare Rahmenbedingungen, die Unterstützung des Managements und die richtigen Menschen, die den Wandel gestalten können. Gleichzeitig sollten Unternehmen den Mut haben, bestehende Prozesse zu hinterfragen und neu zu denken. Das größte Potenzial entsteht oft nicht dadurch, dass man bestehende Abläufe etwas schneller macht, sondern dadurch, dass man sie grundlegend verbessert.
Und vielleicht der wichtigste Punkt: Nehmen Sie die Menschen mit. Trotz aller technologischen Fortschritte spielt der Mensch weiterhin die entscheidende Rolle. Er definiert die Ziele, bewertet die Ergebnisse, übernimmt Verantwortung und sorgt dafür, dass aus technologischen Möglichkeiten tatsächlich nachhaltiger Mehrwert entsteht. KI kann vieles beschleunigen, aber gute Entscheidungen bleiben eine menschliche Aufgabe.
Consileon begleitet Unternehmen entlang der gesamten KI-Reise: von der strategischen Beratung über Governance und Toolauswahl bis hin zur Integration in Entwicklungsprozesse und der Umsetzung konkreter KI-Lösungen. Dabei verbinden wir KI-Expertise mit langjähriger Erfahrung in der Softwareentwicklung – praxisnah, technologieoffen und immer mit Fokus auf nachhaltigen Mehrwert.
KI ist in Unternehmen angekommen, aber ohne übergreifende Steuerung. Copilot-Lizenzen sind ausgerollt, im Schadenmanagement laufen erste automatisierte Prozesse und HR-Abteilungen erproben KI-gestützte Recruiting-Tools. Wie der EU AI-Act genau diese Praxis regulatorisch einholt und welchen Ausweg technologiegestützte Compliance-Lösungen bieten, zeigt Rüdiger Lang im aktuellen Fachbeitrag „Regulatorik: Zwischen Innovation und Compliance“ im Themendossier der Versicherungsforen Leipzig.
Der EU AI-Act reguliert dabei nicht in erster Linie Technologien, sondern deren Verwendungszweck. Ein und dieselbe Software kann je nach Einsatzszenario unkritisch oder hochriskant sein. Setzen Versicherer KI-Systeme zur Risikobewertung und Tarifierung in der Kranken- oder Lebensversicherung ein, unterstützen sie Entscheidungen über Leistungsauszahlungen oder tragen sie zur Betrugserkennung bei, klassifiziert Anhang III des EU AI-Acts diese Systeme explizit als hochriskant. Das betrifft keine Randphänomene, sondern Kernprozesse der Branche mit umfangreichen Dokumentations-, Bewertungs- und Meldepflichten.
Hinzu kommt ein strukturelles Problem. In vielen Häusern ist unklar, welche KI-Systeme überhaupt im Einsatz sind. Fachbereiche beschaffen eigenständig, die IT hat keinen vollständigen Überblick und Compliance war bislang nicht systematisch eingebunden. Eine mittelgroße Versicherung, die KI in der Tarifierung, Schadensbearbeitung, HR und im Kundenservice einsetzt, hat schnell sechs bis zehn potenzielle Hochrisiko-Systeme im Einsatz. Ohne vollständiges KI-Inventar lässt sich jedoch keine Risikoklassifizierung vornehmen. Ohne Klassifizierung bleibt jede Compliance-Maßnahme lückenhaft, unabhängig davon, wie viele Schulungen zuvor durchgeführt wurden.
Für jedes Hochrisiko-System schreibt der EU AI-Act eine vollständige technische Dokumentation vor: Zweck, Funktionsweise, eingesetzte Daten, Leistungsgrenzen und bekannte Risiken. Hinzu kommen die Konformitätsbewertung vor dem produktiven Einsatz, die Registrierung in der EU-Datenbank für KI-Systeme sowie im laufenden Betrieb lückenlose Auditierbarkeit gegenüber Aufsichtsbehörden wie der BaFin. Seit dem 2. August 2026 ist zudem die Transparenzpflicht nach Artikel 50 wirksam. Wer jetzt mit dem Inventar beginnt, hat noch die Chance, strukturiert vorzugehen. Wer wartet, wird unter Druck dokumentieren, und das sieht man den Ergebnissen dann meistens an.
Genau hier liegt der Ansatzpunkt für technologiegestützte Compliance-Lösungen, kurz RegTech. Statt manuelle Prüfprozesse hochzuskalieren, überwachen moderne Plattformen regulatorische Anforderungen kontinuierlich, gleichen interne Dokumente und Prozesse automatisch mit dem aktuellen Regelwerk ab und überführen identifizierte Lücken in strukturierte Handlungsempfehlungen. Gap-Analysen, die manuell Wochen dauern würden, lassen sich so in Stunden durchführen. Lösungen wie der Consileon Compliance Manager adressieren diese Anforderungen bereits für Rahmenwerke wie DORA, MaRisk und NIS-2, ein spezifisches Modul für den EU AI-Act befindet sich in der Entwicklung. RegTech ersetzt dabei nicht die strategische Entscheidung, das Thema als unternehmensweite Managementaufgabe anzugehen; es macht den operativen Aufwand jedoch beherrschbar.
Wie verschaffen sich Versicherer einen vollständigen Überblick über ihre KI-Systeme? Welche Rolle spielt RegTech dabei, den Aufwand beherrschbar zu machen? Und wie gelingt der Übergang von punktuellen Maßnahmen zu einer echten KI-Governance? Mehr dazu lesen Sie im Artikel.
Ein kaufmännischer Direktor eines Krankenhauses hat gerade ein KI-Projekt durchgerechnet, das Dokumentationszeit spart und sich innerhalb weniger Monate amortisieren würde. Die Wirtschaftlichkeit stimmt, die Fachabteilung ist überzeugt. Dann meldet der Datenschutzbeauftragte Bedenken an und die Investitionsentscheidung landet auf unbestimmte Zeit in der Warteschleife. Genau in dieser Situation zeigt lokale KI im Krankenhaus ihren Wert: Sie löst das Datenschutzproblem an der Wurzel, bevor es zum Investitionsrisiko wird.
Der Grund ist fast immer derselbe: Die KI läuft in der Cloud. Und sobald Gesundheitsdaten das Krankenhaus verlassen, greifen Art. 9 DSGVO und die ärztliche Schweigepflicht nach § 203 StGB in voller Härte. Es braucht einen Auftragsverarbeitungsvertrag, ein C5-Testat für den Cloud-Anbieter und Klarheit über den Serverstandort. [1] Für viele IT-Abteilungen im Krankenhaus ist genau das der Punkt, an dem ein eigentlich vielversprechendes Projekt scheitert. Der Grund ist nicht die Qualität oder Verfügbarkeit der Technologie, sondern der administrative und rechtliche Rahmen.
Im Gesundheitswesen kommt ein Faktor hinzu, der sich nicht in Paragrafen fassen lässt: ein grundsätzlich sensibler Umgang mit Patientendaten, der tief in der Berufskultur verankert ist. Selbst wenn Auftragsverarbeitungsvertrag, C5-Testat und Serverstandort formal geklärt sind, bleibt bei vielen Ärzten ein ungutes Gefühl zurück, sobald Patientendaten das eigene Haus verlassen. Dieses Unbehagen ist kein Zeichen von Überängstlichkeit, sondern Ausdruck eines Vertrauensverhältnisses, das der Beruf seit jeher verlangt. Eine Lösung, bei der Daten das Krankenhaus erst gar nicht verlassen, nimmt genau dieses Gefühl ernst, unabhängig davon, wie wasserdicht die vertragliche Absicherung einer Cloud-Lösung im Zweifel wäre.
Das Problem liegt nicht bei einzelnen Anbietern oder schlechten Verträgen, sondern in der Architektur selbst. Cloud-KI schickt Anfragen an Rechenzentren, die meist von US-amerikanischen Konzernen betrieben werden. [3] Damit entsteht automatisch eine Kette von Abhängigkeiten: von einer stabilen Internetverbindung, von der Cloud-Verfügbarkeit des Anbieters, von dessen Preisgestaltung pro Anfrage und nicht zuletzt von dessen Entscheidungen über Modellversionen und Updates, auf die das Krankenhaus keinen Einfluss hat.
Für Gesundheitsdaten kommt erschwerend hinzu, dass jede Cloud-Anbindung eine zusätzliche Angriffsfläche für Cyberattacken darstellt. Gerade Krankenhäuser sind für Angreifer ein besonders lohnendes Ziel, weil Patientendaten hochsensibel und Systeme oft unter chronischem IT-Ressourcenmangel betrieben werden. Jede zusätzliche Schnittstelle nach außen vergrößert dieses Risiko.
Hinzu kommt der EU AI-Act. Er verlangt von Krankenhäusern als Betreiber von KI-Systemen Nachweise über Trainingsdaten, Entscheidungslogik und Monitoring, gestaffelt nach der Risikoklasse des jeweiligen Systems. [7] Bei einer Cloud-Lösung, deren Innenleben man nicht kontrolliert, ist das deutlich schwerer zu belegen als bei einem System, das vollständig im eigenen Haus läuft. Das strukturelle Dilemma lautet also: Genau die leistungsstarken KI-Modelle, die den größten Mehrwert versprechen, sind aus regulatorischer Sicht am schwersten zu rechtfertigen.
Für die Verwaltungsleitung kommt eine persönliche Dimension hinzu. Setzt ein Krankenhaus eine unzureichend geprüfte KI-Lösung ein, kann das als Organisationsverschulden gewertet werden, mit Haftungsfolgen für die Geschäftsführung selbst. [2] Auch die NIS-2-Richtlinie verschärft diese persönliche Verantwortung zusätzlich. Eine Lösung, die Daten von vornherein im Haus hält und deren Funktionsweise vollständig dokumentierbar ist, reduziert dieses Haftungsrisiko spürbar, nicht nur das Risiko für die Patientendaten selbst.
Lokale KI im Krankenhaus bedeutet, dass ein KI-Modell direkt auf einem Gerät in der Klinik läuft, ohne Anbindung an ein externes Rechenzentrum. Der entscheidende Unterschied zur Cloud-KI liegt dabei nicht in der Geschwindigkeit, sondern in der regulatorischen Eleganz: Läuft das Modell direkt auf einem Gerät im Krankenhaus, verlassen die Daten das Haus schlichtweg nicht. Damit entschärfen sich die Anforderungen aus Art. 9 DSGVO und § 203 StGB von selbst, weil der Grund für ihre Verschärfung, die Datenweitergabe an Dritte, gar nicht erst entsteht. Ein Auftragsverarbeitungsvertrag wird überflüssig, ein C5-Testat ebenso, die Frage nach dem Serverstandort stellt sich nicht mehr.
Möglich wird das durch eine neue Generation von Prozessoren, die CPU, Grafikeinheit und einen dedizierten KI-Beschleuniger auf einem Chip vereinen und dabei auf einen gemeinsamen Arbeitsspeicher von bis zu 128 Gigabyte zugreifen können. [4] Diese Architektur ermöglicht es, Sprachmodelle mit bis zu 200 Milliarden Parametern vollständig lokal und in Echtzeit zu betreiben, ganz ohne Cloud-Anbindung. [5] Seit 2025/26 ist diese Technik serienreif und findet sich bereits in Business-Notebooks und kompakten Desktop-Geräten führender Hersteller.
Ein offenes Modell wie GPT-OSS-120B zeigt, was damit möglich ist: Im medizinischen Testverfahren HealthBench erreicht es Werte nahe an denen deutlich größerer, ausschließlich cloudbasierter Modelle und liegt spürbar vor älteren Generationen wie GPT-4o. [6] Für hochspezialisierte Forschungsfragen mögen die größten Cloud-Modelle noch die Nase vorn haben. Für die konkreten Anwendungsfälle im Krankenhausalltag reicht die Leistungsfähigkeit lokaler Modelle heute in aller Regel völlig aus.
Im direkten Vergleich wird der Unterschied zwischen beiden Ansätzen greifbar:
| Dimension | Cloud-KI | Lokale KI |
|---|---|---|
| Datenschutz | Art. 9 DSGVO und § 203 StGB greifen voll, AV-Vertrag und C5-Testat nötig | Daten verlassen das Haus nicht, Anforderungen entschärfen sich strukturell |
| Haftung der Geschäftsführung | Organisationsverschulden möglich, wenn Prüfung unzureichend war | Geringeres Haftungsrisiko durch volle Kontrolle und Dokumentierbarkeit |
| Regulatorik (EU AI-Act) | Nachweise über Trainingsdaten und Monitoring schwer belegbar | Transparenz- und Dokumentationspflichten leichter erfüllbar |
| Kosten | Laufende Cloud- und Token-Kosten pro Anfrage | Einmalige, klar kalkulierbare Investition |
| Verfügbarkeit | Abhängig von stabiler Internetverbindung und Anbieter-Verfügbarkeit | Läuft offline, unabhängig von externer Anbindung |
| Kontrolle über Modell | Keine Kontrolle über Modellversion und Updates des Anbieters | Volle Kontrolle über Modell, Version und Update-Zeitpunkt |
| Angriffsfläche | Zusätzliche Angriffsvektoren durch Cloud-Anbindung | Reduzierte Angriffsfläche durch Kapselung im Haus |
| Ausfallsicherheit | Internetzugang, Provider-Risiko | Lokale Verfügbarkeit ist sichergestellt |
Wo lohnt sich der Umstieg auf lokale KI konkret? Fünf Anwendungsfälle stechen hervor:
Der Umstieg auf lokale KI ist kein Alles-oder-Nichts-Entscheid und lässt sich als planbare Investition steuern. Sinnvoll ist ein gestufter Einstieg: Zunächst ein oder zwei der oben genannten Anwendungsfälle in einer Abteilung pilotieren, Erfahrungen sammeln und anschließend mit überschaubarem Budgetrisiko skalieren. Anders als bei Cloud-Lösungen mit laufenden Kosten pro Anfrage lässt sich der Invest bei lokaler KI als einmalige, klar kalkulierbare Ausgabe planen, ein Vorteil, der sich in jeder Wirtschaftlichkeitsrechnung bemerkbar macht. Wichtig ist dabei, die IT-Abteilung von Anfang an einzubinden, damit keine unkontrollierte Schatten-KI entsteht, die dieselben Haftungsrisiken durch die Hintertür wieder hereinholt, die man mit der lokalen Lösung eigentlich vermeiden wollte.
Ebenso wichtig ist eine ehrliche Erwartungssteuerung im Personalbereich. Lokale KI ersetzt keine ärztliche Entscheidung, sie entlastet bei Dokumentation, Übersetzung und Recherche. Wer das von Anfang an klar kommuniziert, vermeidet Enttäuschungen und erhöht die Akzeptanz im Team.
Cloud-KI und Gesundheitsdatenschutz passen strukturell nicht gut zusammen, das zeigt sich immer wieder in der Praxis. Lokale KI-Systeme lösen genau dieses Dilemma auf, ohne auf die Vorteile moderner Sprachmodelle verzichten zu müssen. Für die zentralen Anwendungsfälle im Krankenhausalltag, von der Dokumentation bis zur Pseudonymisierung, ist die Technologie heute bereits ausgereift genug, um echten Mehrwert zu schaffen und gleichzeitig regulatorisch auf der sicheren Seite zu bleiben.
Welcher dieser Anwendungsfälle für Ihr Haus den größten Hebel bietet, hängt von der individuellen Ausgangslage ab, von der IT-Infrastruktur bis zur Belastung einzelner Abteilungen. Lassen Sie uns gemeinsam herausfinden, wo Ihr Krankenhaus am dringendsten entlastet werden muss, und wie sich lokale KI dort konkret einsetzen lässt.
[2] datenschutz notizen (24.03.2026): KI-Systeme im Krankenhaus – Betreiberpflichten und Haftungsfragen.
[3] Kiteworks (Mai 2026): Herausforderungen bei KI-Datengovernance im Gesundheitswesen.
[4] AMD: Ryzen AI Halo – Produktspezifikationen (NPU-Leistung, Unified Memory).
[5] StorageReview: AMD Ryzen AI Halo Review – A Dual-OS, 200B-Parameter Desktop.
[6] OpenAI: gpt-oss-120b & gpt-oss-20b Model Card, Abschnitt HealthBench.
Am 12. Juni 2026 hat die US-Regierung Anthropic per Exportkontrolldirektive angewiesen, die Modelle Claude Fable 5 und Mythos 5 für alle Nutzer weltweit zu deaktivieren. Vier Tage nach dem offiziellen Launch. Unternehmen, die diese Modelle bereits in produktive Prozesse integriert hatten, standen von einer Stunde auf die andere vor einem leeren Endpunkt. Das KI-Modell-Risiko, das viele Unternehmen bislang für theoretisch hielten, ist damit erstmals real geworden. Gerrit Verse, Senior Specialist und KI-Experte bei Consileon, ordnet ein, was das bedeutet und was Unternehmen daraus lernen müssen.
Anthropic hat am 9. Juni 2026 Claude Fable 5 gelauncht, ein leistungsstarkes Modell der sogenannten Mythos-Klasse, das für komplexe, langfristige Aufgaben konzipiert war. Drei Tage später hat die US-Regierung, gestützt auf nationale Sicherheitsbehörden, eine Exportkontrolldirektive erlassen. Die Begründung: Ein Jailbreak-Verfahren soll es ermöglichen, bestimmte Sicherheitsmechanismen des Modells zu umgehen. Anthropic war daraufhin gezwungen, beide Modelle für alle Kunden weltweit abzuschalten. Nicht nur für ausländische Nutzer. Für alle. Eine selektive Sperrung nach Nationalität war technisch nicht kurzfristig umsetzbar.
Das Entscheidende daran: Das ist kein Ausfall. Kein Bug. Kein Infrastrukturproblem. Das ist ein regulatorisches Eingreifen in ein kommerziell verfügbares Produkt, über Nacht, ohne Vorankündigung, ohne Übergangsfrist.
Als Warnsignal. Wer KI-Modelle von US-Anbietern in kritische Geschäftsprozesse integriert, ohne eine Governance-Strategie dahinter zu haben, sitzt auf einem KI-Modell-Risiko, das er selbst nicht kontrollieren kann. Die meisten Unternehmen haben sich bislang Gedanken gemacht über Datenschutz, über DSGVO-Konformität, über Kosten. Das ist richtig und wichtig. Aber die Frage „Was passiert, wenn dieses Modell morgen nicht mehr verfügbar ist?“ haben die wenigsten wirklich durchdacht.
Der Fable-5-Vorfall ist in dieser Hinsicht ein Präzedenzfall. Zum ersten Mal wurde ein bereits allgemein verfügbares Frontier-Modell durch eine Regierungsmaßnahme abgeschaltet. Das wird nicht das letzte Mal sein.
Es gibt aber noch ein zweites, langfristigeres Risiko, das bislang kaum diskutiert wird: den strukturellen Wettbewerbsnachteil. Wenn europäische Unternehmen dauerhaft keinen oder nur eingeschränkten Zugang zu den leistungsstärksten KI-Modellen bekommen, während amerikanische Wettbewerber ungehindert damit arbeiten, entsteht eine Schere, die sich nicht mehr einfach schließen lässt. Wer mit deutlich besseren Modellen Software entwickelt, Prozesse optimiert oder Entscheidungen trifft, arbeitet schlicht schneller und mit besseren Ergebnissen. KI könnte damit zu einer geopolitisch geschützten Ressource werden, ähnlich wie Halbleiter oder Militärtechnologie. Das ist keine Dystopie, das ist eine reale strategische Weichenstellung, die gerade stattfindet.
Besonders exponiert sind Unternehmen, die Automatisierungsworkflows oder KI-Agenten produktiv betreiben, also nicht nur experimentell nutzen, sondern fest in Geschäftsprozesse eingebettet haben. Dokumentenanalyse, Vertragsprüfung, automatisierter Kundensupport, Code-Generierung im Entwicklungsprozess: Überall dort, wo Menschen und KI in einem definierten Ablauf zusammenarbeiten, entsteht eine operative Abhängigkeit.
Wenn der Endpunkt plötzlich wegfällt, bricht der Prozess zusammen. Retry-Logik im Code hilft nicht. Ein anderes Modell einzuwechseln ist kurzfristig möglich, aber selten nahtlos, weil Modelle unterschiedlich reagieren, unterschiedliche Kontextlängen haben und unterschiedliche Stärken mitbringen. Das erfordert Anpassung, Tests, im schlimmsten Fall eine komplette Neukalibrierung der Prompts und Workflows.
Es gibt europäische Alternativen und sie sind ernstzunehmen. Mistral AI aus Paris ist heute der prominenteste europäische Anbieter mit einem Frontier-fähigen Modell. Die Infrastruktur liegt in Europa, das Unternehmen unterliegt europäischem Recht, ein DSGVO-konformer Auftragsverarbeitungsvertrag ist verfügbar. Für viele Anwendungsfälle reicht die Leistung von Mistral Large inzwischen vollständig aus, insbesondere für deutschsprachige Dokumente, strukturierte Analysen oder regelbasierte Workflows.
Die ehrliche Antwort lautet aber: Wer heute ausschließlich auf europäische Modelle setzt, nimmt bei bestimmten Aufgaben Leistungseinbußen in Kauf. Bei hochkomplexen Reasoning-Aufgaben, bei multimodalen Anwendungen oder bei sehr langen Kontextfenstern sind US-Modelle wie GPT oder Claude aktuell noch führend. Das ist kein Argument gegen europäische Anbieter, aber ein Argument dafür, differenziert vorzugehen.
Eine vollständige Unabhängigkeit ist eine Illusion, das sollten wir nicht versprechen. Aber es gibt erhebliche Unterschiede zwischen einer ungeplanten Abhängigkeit und einer bewusst gestalteten. Wer heute eine KI-Strategie aufbaut, sollte drei Ebenen unterscheiden.
Die Leistungsfähigkeit lokaler Modelle hat sich in den letzten zwei Jahren fundamental verändert. Was früher nur auf teurer Serverinfrastruktur lief, läuft heute auf einem modernen Arbeitsrechner oder einem aktuellen MacBook. Tools wie Ollama machen den Einstieg technisch trivial: Modelle wie Llama 3.3, Mistral Small oder Phi-4 lassen sich in wenigen Minuten lokal installieren und über eine standardisierte API ansprechen, ganz ohne Cloudanbindung, ganz ohne dass ein einziges Zeichen der Anfrage das Unternehmensnetz verlässt.
Für Aufgaben wie Textzusammenfassungen, Dokumentenklassifizierung, einfache Datenextraktion oder interne Suchfunktionen reicht die Qualität dieser Modelle heute vollständig aus. Selbst auf Consumer-Hardware erreichen quantisierte 8-Milliarden-Parameter-Modelle Benchmark-Werte, die vor zwei Jahren noch GPT-4-Niveau entsprachen. Die Grenzen liegen bei sehr langen Dokumenten, komplexen Mehrschritt-Analysen und multimodalen Aufgaben.
Interessant ist, was Apple hier gerade auf Endgerätebene vorantreibt. Apple Intelligence läuft auf neueren iPhones und Macs direkt auf dem Gerät, ohne Serveranbindung, für einfache Aufgaben wie Textkorrekturen, Zusammenfassungen oder Kalendereinträge. Das ist kein Frontier-Modell, aber für genau diese Alltagsaufgaben ist es gut genug. Apple zeigt damit ein Prinzip, das für Unternehmen verallgemeinerbar ist: Routineaufgaben gehören auf die lokale Ebene. Nur was wirklich komplexer Reasoning-Kapazität bedarf, sollte nach außen gehen.
Mistral AI aus Paris ist heute der relevanteste europäische Anbieter mit Frontier-naher Leistung. Die Modelle sind über europäische Infrastruktur verfügbar, DSGVO-konforme Auftragsverarbeitungsverträge existieren, und die Leistung bei deutschsprachigen Texten, strukturierten Analysen und regelbasierten Workflows ist solide. Für viele Unternehmensanwendungen in regulierten Branchen ist das ausreichend.
Die ehrliche Einschränkung bleibt: Wer ein Frontier-Modell für komplexe juristische Analysen oder multimodale Aufgaben braucht, stößt mit Mistral heute noch an Grenzen. Das ist aber kein Argument gegen den Einsatz europäischer Modelle, sondern ein Argument für eine differenzierte Strategie.
Für hochkomplexe Reasoning-Aufgaben, für autonome Agenten, die über mehrere Schritte und Werkzeuge hinweg arbeiten, für die Analyse sehr langer Dokumente oder für multimodale Anwendungen sind US-Modelle wie Claude oder GPT aktuell noch führend. Das wird sich verschieben, aber es ist die ehrliche Bestandsaufnahme für heute.
DeepSeek aus China ist eine Open-Source-Alternative, die bei bestimmten Aufgaben, insbesondere bei Code und strukturierten Analysen, überraschend stark abschneidet und sich lokal betreiben lässt. Wer DeepSeek nutzt, sollte allerdings die datenschutzrechtliche Situation sorgfältig prüfen. Der Fable-5-Vorfall hat gezeigt, dass geopolitische Risiken nicht nur bei US-Anbietern existieren.
Die Kunst liegt darin, diese drei Ebenen bewusst zu kombinieren, statt blind auf eine einzige Plattform zu setzen. Und die Grundregel dabei lautet: So lokal wie möglich, so extern wie nötig.
Kurzfristig sind die Kosten für Inferenz, also das tatsächliche Abfragen von Modellen, gesunken. Frontier-Modelle wie Sonnet oder Opus 4.8 kosten heute einen Bruchteil dessen, was vergleichbare Leistung vor zwei Jahren gekostet hätte. Dieser Trend wird sich fortsetzen, weil der Wettbewerb zwischen Anbietern intensiv ist und weil Modelle effizienter werden.
Was aber steigen wird: der Gesamtaufwand für KI-Governance. Unternehmen, die KI ernsthaft und sicher einsetzen wollen, müssen in Kompetenz investieren, in die Fähigkeit, Modelle zu evaluieren, Risiken zu beurteilen, Fallback-Szenarien zu definieren und Compliance sicherzustellen. Das ist kein einmaliges Projekt, sondern eine dauerhafte Aufgabe. Wer das unterschätzt, wird feststellen, dass die scheinbar günstigen Modellkosten nur ein Teil der Rechnung sind.
Hinzu kommt: Geopolitische Risiken wie der Fable-5-Vorfall zeigen, dass Modellverfügbarkeit kein selbstverständliches Gut ist. Unternehmen, die das in ihre Planung einbeziehen, mit Redundanz, mit Alternativen und mit Abstraktionsschichten zwischen Anwendung und Modell, werden langfristig resilienter und damit auch wirtschaftlich im Vorteil sein.
Drei Dinge, die sofort umsetzbar sind:
Der Fable-5-Vorfall ist ein unangenehmer, aber lehrreicher Moment. Er zeigt, dass das KI-Modell-Risiko kein abstraktes Zukunftsszenario ist, sondern heute in der Produktionsumgebung ankommen kann. Wer KI-Strategie und IT-Governance jetzt zusammendenkt, hat einen echten Vorsprung.
Frank Westendorf ist seit über 30 Jahren in der SAP-Welt zuhause, zunächst als Entwickler und Teamleiter beim Hersteller selbst, später als Berater und seit 2019 als Geschäftsführer der Consileon Applied Business GmbH. Im Interview spricht er offen über die häufigsten Fehler bei SAP S/4HANA-Migrationsprojekten, warum Transformationen trotz jahrelanger Ankündigung immer noch scheitern und was Unternehmen tun können, um es besser zu machen.
Das Gefühl kann ich gut verstehen, und ich höre es regelmäßig. SAP hat die Deadlines tatsächlich mehrfach nach hinten geschoben: erst 2025, dann 2027, inzwischen gibt es mit der Extended Maintenance eine Option bis 2030. Das hat viele Unternehmen in eine gefährliche Komfortzone gewiegt.
Aber die Situation hat sich fundamental verändert. Der Mainstream-Support für SAP ECC endet Ende 2027. Das ist ein harter Schnitt. Danach gibt es keine Sicherheits-Updates mehr, keine neuen gesetzlichen Anforderungen werden eingespielt, keine regulatorischen Anpassungen. Wer bis 2030 weitermachen will, zahlt für die Extended Maintenance extra und läuft trotzdem auf einer Plattform ohne Weiterentwicklung.
Hinzu kommt ein praktisches Problem, das viele unterschätzen: SAP S/4HANA Migrationsprojekte dauern in der Realität deutlich länger als geplant. Die Horváth-Studie aus dem ersten Quartal 2025, für die 200 SAP-Anwenderunternehmen befragt wurden, zeigt: Im Durchschnitt dauern Projekte 30 Prozent länger als geplant. Nur 8 Prozent der Unternehmen, die die Migration abgeschlossen haben, lagen im Zeitplan. Wer 2026 noch nicht ernsthaft mit der Planung begonnen hat, hat ein reales Fristproblem.
Beides ist wahr, aber ich würde die Reihenfolge umdrehen. Das Support-Ende erzeugt natürlich Druck. Aber wer die SAP S/4HANA Migration nur als Compliance-Übung betrachtet, weil SAP es verlangt, macht einen grundlegenden Fehler. Er wird viel Geld ausgeben und wenig zurückbekommen.
S/4HANA ist eine fundamental andere Architektur. Das Universal Journal zum Beispiel: Statt vieler getrennter Nebenbücher gibt es eine einzige Datentabelle für alle Finanztransaktionen. Das klingt technisch, hat aber konkrete Auswirkungen. Periodenabschlüsse, die früher Tage gedauert haben, können in Stunden erledigt werden. Echtzeit-Auswertungen, die bisher einen separaten BI-Stack erforderten, laufen direkt im System.
Was mich in der Beratung wirklich begeistert: S/4HANA öffnet die Tür für KI-Anwendungen, die auf SAP ECC schlicht nicht möglich waren. Automatisierte Rechnungsprüfung, prädiktive Cashflow-Analysen, intelligente Abweichungserkennung in der Kreditorenbuchhaltung: Das sind keine Zukunftsvisionen, das setzen wir heute in Projekten um. Wer die SAP S/4HANA Migration nur als Pflichtübung abarbeitet und seine Prozesse eins zu eins kopiert, verspielt diese Chance.
Die ehrliche Antwort ist: Es kommt darauf an, wie man die SAP S/4HANA Migration angeht. Wer einen reinen Lift-and-Shift macht, also das alte System technisch umzieht, ohne Prozesse anzufassen, wird keinen überzeugenden ROI nachweisen können. Die Kosten sind real, der Nutzen bleibt gering.
Wer die Migration aber als Transformationsprojekt begreift, sieht ein anderes Bild. Konkret: Viele unserer Kunden im FiBu-Umfeld haben nach der SAP S/4HANA Migration ihren Periodenabschluss um 40 bis 60 Prozent beschleunigt. Manuelle Abstimmungsaufwände in der Hauptbuchhaltung sinken erheblich, weil das Universal Journal viele der alten Übertragungs- und Abstimmungsschritte überflüssig macht. Die Integration von KI in Folgeprozesse, etwa in der Rechnungsverarbeitung, bringt weitere Effizienzgewinne.
Für den CFO ist noch ein anderer Aspekt relevant: Ein ECC-System, das nicht mehr gewartet wird, ist ein operatives Risiko. Fehlende Sicherheitsupdates, keine Unterstützung bei gesetzlichen Änderungen: Das kann teuer werden. Die Alternative „nichts tun“ hat also auch einen Preis, der in der ROI-Berechnung oft vergessen wird.
Das ist wahrscheinlich die Frage, mit der ich am häufigsten konfrontiert bin, und bei der ich am direktesten antworten kann, weil ich die Muster über viele Projekte hinweg kenne.
Der größte Fehler: Die SAP S/4HANA Migration wird als IT-Projekt behandelt. Der CIO ist verantwortlich, die Fachabteilungen sind Zulieferer. Das scheitert regelmäßig. S/4HANA-Migrationen sind Transformationsprojekte. Sie verändern, wie Finanzbuchhaltung, Controlling, Einkauf und Logistik arbeiten. Wenn der CFO nicht aktiv mitgestaltet und die Fachabteilungen nicht von Beginn an eingebunden sind, entstehen Lösungen, die technisch funktionieren, aber operativ nicht funktionieren.
Der zweite klassische Fehler: unterschätzte Datenkomplexität. Viele Unternehmen haben über 15 oder 20 Jahre ihr SAP-System individuell angepasst: eigene Transaktionen, eigene Reports, gewachsene Schnittstellen. Diese technische Schuld verschwindet nicht durch eine Migration. Sie muss bewusst aufgelöst oder bewusst übernommen werden. Wer das nicht vorher analysiert, erlebt böse Überraschungen in der Testphase.
Und dann ist da die Governance. ISG hat in einer Studie festgestellt, dass viele Projekte an unklaren Entscheidungsrechten scheitern: zu viele Beteiligte, zu wenig klare Verantwortung, Entscheidungen werden verschleppt. Das ist kein technisches Problem, das ist ein Führungsproblem.
Ich fange mit dem Offensichtlichsten an: Ich bin seit 1994 in der SAP-Welt, davon 12 Jahre beim Hersteller selbst, zunächst als Entwickler, dann als Teamleiter. Das bedeutet, ich verstehe SAP nicht nur als Berater von außen, sondern kenne die Architektur, die Designentscheidungen und die Schwachstellen von innen. Das ist ein echter Unterschied in der Projektkommunikation, mit SAP und auch mit dem Kunden.
Was uns darüber hinaus unterscheidet: Wir kommen bei vielen Kunden über den laufenden Betrieb. Wir übernehmen erst die Wartung und Administration des bestehenden Systems, lernen es wirklich kennen: die individuellen Anpassungen, die gewachsenen Prozesse, die neuralgischen Punkte. Wenn wir dann in eine SAP S/4HANA Migrationsdiskussion einsteigen, reden wir nicht über ein System, das wir aus Dokumenten kennen, sondern eines, das wir von innen kennen. Das reduziert Überraschungen erheblich.
Und wir machen Prozessmodellierung vor der Migration zur Pflicht, nicht zur Option. Bevor wir ein einziges Byte migrieren, verstehen wir gemeinsam mit dem Kunden, wie seine FiBu- und Controlling-Prozesse heute laufen und wie sie nach der SAP S/4HANA Migration laufen sollen. Das kostet am Anfang Zeit, spart sie aber vielfach später.
Drei Dinge, die ich immer wieder erlebe.
Erstens der Umfang des Customizings. Deutsche Unternehmen haben historisch stark in individuelle SAP-Anpassungen investiert: steuerrechtliche Besonderheiten, branchenspezifische Anforderungen, interne Prozesslogiken. Im Krankenhaus kommt beispielsweise die KHBV hinzu, die eigene Buchführungsanforderungen mitbringt, die sich von handelsrechtlichen Regelungen teils erheblich unterscheiden. All das muss analysiert, bewertet und in der SAP S/4HANA Migration berücksichtigt werden.
Zweitens: Datenmigration und Datenqualität. Das wird systematisch unterschätzt. Ein Migrationstool, das die Datenbank technisch überführt, gibt es. Aber saubere, konsistente, vollständige Stammdaten sind Vorarbeit, die Monate dauern kann und intensive Zusammenarbeit zwischen IT und Fachbereich erfordert.
Drittens: Change Management. Menschen müssen mit einem neuen System arbeiten, anders als bisher. Wenn die Anwenderseite nicht mitgenommen wird, passiert Folgendes: Das System ist technisch live, aber die Mitarbeiter arbeiten mit Workarounds, pflegen Excel-Listen parallel und rufen im Helpdesk an. Das ist teuer und frustrierend. Wir investieren deshalb bewusst in Schulung und Begleitung der Anwender, nicht als Pflichtprogramm am Ende, sondern als Teil des Projekts von Beginn an.
Die entscheidende Erkenntnis zuerst: Eine SAP S/4HANA Migration kann nicht allein von der IT geführt werden. Es braucht zwingend Führung aus den Fachbereichen und Rückendeckung von ganz oben.
Auf Kundenseite brauche ich einen Projektleiter, der Mandat hat und Entscheidungen treffen kann, ohne sechs Eskalationsstufen durchlaufen zu müssen. Ich brauche Key User aus FiBu und Controlling, die den Ist-Prozess wirklich kennen und die Soll-Prozesse mitgestalten. Und ich brauche IT-Kompetenz, die versteht, welche Systemlandschaft vorhanden ist und wohin wir wollen.
Auf unserer Seite stellen wir gemischte Teams auf: Fachberater mit tiefer FICO-Kenntnis, technische Berater für Systemkonversion und Datenmigration sowie einen Projektmanager, der die Steuerung übernimmt. Was wir nicht machen: ein riesiges Team aufstellen, das Kapazität signalisiert, aber in dem keiner das Projekt wirklich durch und durch kennt. Wir arbeiten mit überschaubaren, verantwortlichen Teams.
Und ein Punkt, der oft unterschätzt wird: Der Übergang von der Testphase zum Go-live. Genau in dieser Phase muss das Gesamtteam aus Kunde und Berater wirklich funktionieren. Das ist kein Moment für Zuständigkeitsdebatten.
Ich gebe Ihnen eine ehrliche Antwort, keine Marketing-Antwort.
Für ein mittelständisches Unternehmen mit einer überschaubaren SAP-Landschaft, wenig individuellem Customizing und gut vorbereiteten Daten: 12 bis 18 Monate von der Prozessmodellierung bis zum Go-live. Das ist das untere Ende, und es setzt voraus, dass die Entscheidungen auf Kundenseite zügig getroffen werden.
Für Organisationen mit komplexeren Systemlandschaften, etwa Krankenhausverbünde, die mehrere Häuser zusammenführen, oder Industrieunternehmen mit vielen individuellen Anpassungen und Schnittstellen, können das 24 bis 36 Monate sein, manchmal mehr. SAP S/4HANA Migrationsprojekte in diesem Umfang laufen oft in Wellen: erst ein Kernprozess oder Standort, dann weitere.
Was die Horváth-Studie zeigt und was ich aus der Praxis bestätigen kann: Die meisten Projekte planen zu optimistisch. Der realistische Puffer liegt bei 20 bis 30 Prozent auf der Gesamtlaufzeit. Wer das nicht einrechnet, gerät unter Druck und trifft in der Endphase schlechte Entscheidungen.
Deshalb mein klarer Rat: Wer bis Ende 2027 fertig sein will, muss jetzt starten. Nicht in sechs Monaten, jetzt.
Das Risiko ist real. Ich wäre nicht ehrlich, wenn ich das kleinreden würde. Die Zahlen sprechen eine klare Sprache: Laut Horváth-Studie 2025 haben mehr als 60 Prozent der Unternehmen bei ihrer SAP S/4HANA Migration Budget, Zeitplan oder Qualitätsziele verfehlt. 65 Prozent stellen nach der Migration erhebliche Qualitätsmängel fest.
Aber diese Risiken sind nicht schicksalhaft. Sie entstehen aus bekannten, vermeidbaren Fehlern. Und wer das weiß, kann gegensteuern.
Was Risiko bei der SAP S/4HANA Migration wirklich reduziert: Erstens eine ehrliche Bestandsaufnahme vor Projektstart. Wie komplex ist die aktuelle Systemlandschaft wirklich? Wie sauber sind die Daten? Welche individuellen Anpassungen gibt es, und welche davon werden tatsächlich noch gebraucht? Zweitens klare Projektsteuerung mit echten Entscheidungskompetenzen, nicht Komitees, die Empfehlungen aussprechen, sondern Menschen, die entscheiden können. Drittens ausreichend Zeit für Test und Datenmigration: Das ist der am häufigsten unterschätzte Teil des gesamten Projekts.
Was wir bei Consileon explizit tun: Wir machen vor der eigentlichen SAP S/4HANA Migration eine Prozess- und Systemanalyse. Wir wissen, worauf wir uns einlassen, bevor wir starten. Und wir empfehlen lieber einen phasenweisen Ansatz, erst den Kernprozess, dann ausbauen, als den Big-Bang, der alles auf einmal umstellt. Das Risiko ist beherrschbarer, die Lernkurve steiler, und der erste Go-live-Erfolg motiviert das gesamte Team für das, was noch kommt.
Ich sage das ohne Überheblichkeit: Die großen Integratoren haben ihre Stärken. Wenn Sie ein Konzernprojekt mit 50 Standorten weltweit stemmen müssen, brauchen Sie entsprechende Kapazitäten.
Aber was ich in der Praxis immer wieder erlebe: Große Teams sind keine Garantie für gute Ergebnisse. Im Gegenteil: Je mehr Beteiligte, desto diffuser wird oft die Verantwortung. Die ISG-Studie hat das auf den Punkt gebracht: Viele SAP S/4HANA Migrationsprojekte scheitern nicht an fehlender Kompetenz, sondern an unklaren Entscheidungsrechten und fehlenden Verantwortlichkeiten zwischen zu vielen Beteiligten.
Was wir bieten: Tiefe statt Breite. Ein überschaubares, erfahrenes Team, das Ihr Projekt wirklich kennt, von der Prozessanalyse bis zum Go-live. Direkte Kommunikation, kurze Entscheidungswege. Und einen Berater, der Ihre SAP-Landschaft nicht nur aus der Projektdokumentation kennt, sondern im besten Fall schon aus dem laufenden Betrieb.
Dazu kommt: Wir sind SAP Silver Partner mit zertifizierter Kompetenz, aber wir sind kein verlängerter Arm von SAP. Wir sagen Ihnen auch, wo der SAP-Standard sinnvoll ist und wo individuelle Lösungen mehr bringen. Dieses unabhängige Urteil ist in einer SAP S/4HANA Migration, die viele Jahre Ihres Unternehmens prägen wird, viel wert.
Stellen Sie sich vor, Ihr Finanzteam könnte dem eigenen ERP-System eine Frage stellen wie einem erfahrenen Kollegen: „Zeig mir die Ausreißer im Cashflow der letzten 90 Tage und erkläre, woher die Abweichungen kommen.“ Und das System antwortet in natürlicher Sprache, sofort, mit den richtigen Zahlen aus dem laufenden Betrieb.
Das ist kein Zukunftsszenario. SAP hat im vierten Quartal 2025 rollenbasierte KI-Assistenten in SAP Joule eingeführt, darunter einen explizit für Finanzmanager. Controlling, Cashflow-Prognose, Verrechnungslaufergebnisse: SAP Joule im Finanzwesen ist keine Spielerei mehr, sondern produktive Software, die in S/4HANA-Umgebungen heute eingesetzt wird.
Für viele CFOs und CIOs ist das eine gute Nachricht. Und gleichzeitig eine unbequeme: Denn wer SAP Joule im Finanzwesen nutzen will, muss eine Voraussetzung erfüllen, die nicht jedes Unternehmen heute hat.
SAP Joule ist der generative KI-Assistent von SAP, direkt in die SAP-Produktlandschaft eingebettet. Im Finanzbereich bedeutet das: Joule greift auf Echtzeitdaten im System zu, versteht den betriebswirtschaftlichen Kontext und kann in natürlicher Sprache mit Controllern, Buchhaltern und Finanzmanagern interagieren.
Im vierten Quartal 2025 hat SAP konkrete Funktionen für das Finanzwesen ausgerollt. Business-Analysten und Controller erhalten einen direkten Überblick über Verrechnungslaufergebnisse per Joule-Funktion. Finanzmanager können Cashflow-Prognosen mit KI-Unterstützung erstellen, ohne separate BI-Tools aufzurufen. Seit dem ersten Quartal 2026 ist zudem der Joule Studio Agent Builder allgemein verfügbar, mit dem Unternehmen eigene Joule-Agenten für ihre spezifischen Finanzprozesse entwickeln können.
Das ist ein Qualitätssprung gegenüber dem, was bisher unter KI im SAP-Umfeld verstanden wurde. Keine isolierten Add-ons, keine externe KI-Plattform, die an SAP andockt. Joule ist in S/4HANA integriert, arbeitet mit den echten Unternehmensdaten und hält dabei Rollen und Berechtigungen ein.
Hier liegt das Problem, das in vielen CFO-Gesprächen noch zu wenig Raum findet: SAP Joule im Finanzwesen entfaltet seinen Nutzen nur dann, wenn die Datenbasis stimmt. Und die Datenbasis stimmt nur dann, wenn das Unternehmen auf S/4HANA migriert ist und seine Prozesse und Datenstrukturen dabei sauber aufgeräumt hat.
Wer noch auf SAP ECC läuft, hat keinen Zugang zu Joule. Die KI-Funktionen sind exklusiv für die S/4HANA-Plattform. Das klingt nach einem Detail, ist aber für die aktuelle Lage im Markt hochrelevant: Laut der Horváth-Studie aus dem ersten Quartal 2025 haben von 200 befragten SAP-Anwenderunternehmen erst 37 die Migration abgeschlossen. Die große Mehrheit läuft noch auf Altsystemen.
Hinzu kommt ein Qualitätsproblem, das unabhängig von der Migrationsplattform existiert: Viele Unternehmen haben über Jahre hinweg historisch gewachsene Datenstrukturen, inkonsistente Stammdaten und individuell angepasste Prozesse. Eine KI, die auf dieser Basis arbeitet, produziert unzuverlässige Ergebnisse. Garbage in, garbage out, nur schneller.
Das bedeutet: Wer SAP Joule im Finanzwesen wirklich nutzen will, muss zwei Dinge sicherstellen. Erstens die technische Migration auf S/4HANA. Zweitens die Prozess- und Datenqualität, die diese Migration idealerweise mitbringt, wenn sie als Transformationsprojekt und nicht als reiner technischer Umzug angegangen wird.
Die gute Nachricht: Beides ist planbar. Die schlechte Nachricht: Beides braucht Zeit, mehr als viele CFOs und CIOs heute einplanen.
SAP S/4HANA Migrationsprojekte dauern in der Praxis 12 bis 36 Monate, je nach Komplexität der Systemlandschaft. Der Mainstream-Support für SAP ECC endet Ende 2027. Wer also bis zur Deadline auf S/4HANA sein und gleichzeitig die Voraussetzungen für sinnvolle KI-Nutzung wie SAP Joule im Finanzwesen schaffen will, muss jetzt mit der ernsthaften Planung beginnen, nicht in sechs Monaten.
Drei Dinge sollten dabei von Anfang an mitgedacht werden. Erstens die Datenstrategie: Welche Stammdaten müssen bereinigt werden? Welche Strukturen entstehen im neuen System, die Joule später sinnvoll nutzen kann? Zweitens die Prozessmodellierung: Welche Finanzprozesse sollen nach der Migration KI-gestützt laufen? Diese Antwort beeinflusst, wie das S/4HANA-System konfiguriert wird. Drittens die Rollendefinition: Joule arbeitet rollenbasiert. Wer darf was sehen und steuern? Berechtigungskonzepte müssen von Beginn an mitgedacht werden.
Wer diese drei Punkte erst nach dem Go-live klärt, verschenkt einen erheblichen Teil des Potenzials, das die Migration eigentlich freisetzen sollte.
SAP Joule im Finanzwesen ist kein Versprechen mehr, das irgendwann eingelöst wird. Es ist ein verfügbares Werkzeug, das heute in produktiven S/4HANA-Umgebungen eingesetzt wird und konkrete Effizienzgewinne in Controlling und Rechnungswesen bringt.
Aber es ist kein Werkzeug, das man einfach einschaltet. Es setzt eine Plattform und eine Datenqualität voraus, die sich Unternehmen im Rahmen einer durchdachten S/4HANA-Migration erarbeiten müssen. Die Frage ist also nicht: Wollen wir KI im Finanzwesen? Die Frage ist: Schaffen wir jetzt die Grundlage dafür?
Wer diese Frage zu lange aufschiebt, wird 2027 nicht nur ohne modernen SAP-Support dastehen, sondern auch ohne die KI-Fähigkeiten, die Wettbewerber dann bereits produktiv nutzen.
Mehr zur S/4HANA-Migration und zu den Voraussetzungen für KI-gestützte Finanzprozesse lesen Sie auf unserer Seite zur SAP FICO Beratung. Wie eine durchdachte Migration konkret aussieht, erklärt Frank Westendorf im Interview zur S/4HANA-Migration.
Viele Unternehmen haben heute Zugriff auf leistungsfähige KI-Tools. Trotzdem bleibt der erhoffte Produktivitätsschub in der Softwareentwicklung oft aus. Der Grund ist selten die Technologie. Es ist die fehlende Erfahrung im Einsatz. Was Unternehmen jetzt anders machen müssen und warum Experten on demand dabei eine zentrale Rolle spielen, erklären Gerrit Verse, Senior Software Engineer und KI-Experte, sowie Rüdiger Lang, Principal bei Consileon.
Gerrit Verse:
KI ist heute in der Lage, entlang des gesamten Software Development Lifecycles Mehrwert zu liefern. Im Requirements Engineering kann sie dabei helfen, Anforderungen zu strukturieren, User Stories zu formulieren oder Inkonsistenzen aufzudecken. In der Entwicklung unterstützt sie bei Code Generierung, Refactoring und der schnellen Umsetzung von Standardlogik.
Auch im Testing sehen wir große Potenziale, etwa bei der Generierung von Testfällen, Testdaten oder beim Erkennen von Edge Cases. Und nicht zuletzt spielt KI eine wichtige Rolle bei der Dokumentation und der Wissensaufbereitung.
Die Grenzen liegen aktuell primär bei komplexen Systemen, bei Architekturentscheidungen und überall dort, wo tiefes fachliches Verständnis erforderlich ist. Außerdem ist die Qualität stark abhängig vom Kontext, den man der KI gibt. Ohne saubere Inputs und klare Leitplanken entstehen schnell mittelmäßige oder sogar falsche Ergebnisse.
Rüdiger Lang:
Aus strategischer Sicht ist entscheidend: Die Technologie ist weit genug, um echten Business Impact zu liefern. Aber dieser Impact entsteht nicht automatisch. KI ist kein Selbstläufer, sondern muss aktiv gesteuert und in bestehende Prozesse integriert werden.
Rüdiger Lang:
Viele Unternehmen starten mit einem toolgetriebenen Ansatz. Sie stellen KI-Lösungen zur Verfügung, erwarten jedoch, dass sich der Mehrwert von selbst einstellt. Was fehlt, ist ein klares Zielbild dafür, wie KI konkret im Entwicklungsprozess genutzt werden soll.
Gerrit Verse:
Aus technischer Sicht sehen wir häufig eine Lücke zwischen Tool und Anwendung. Entwickler haben Zugriff auf leistungsfähige Systeme, aber keine Orientierung, wie sie diese sinnvoll im Alltag einsetzen. Es fehlt an Best Practices, an Erfahrungswerten und an konkreten Anwendungsbeispielen. Dadurch bleibt KI oft auf punktuelle Nutzung beschränkt, statt systematisch entlang des gesamten SDLC eingesetzt zu werden.
Gerrit Verse:
Die erste große Herausforderung ist die Integration in bestehende Entwicklungsprozesse. KI muss dort funktionieren, wo Entwickler ohnehin arbeiten, also in bestehenden IDEs, Repositories und Toolchains.
Die zweite Herausforderung ist Qualitätssicherung. KI-generierter Code muss überprüft, getestet und in bestehende Qualitätsprozesse integriert werden. Ohne klare Regeln entstehen schnell technische Schulden oder schwer nachvollziehbare Fehler.
Die dritte Herausforderung ist die Auswahl der richtigen Tools und Modelle. Es gibt eine Vielzahl an Lösungen am Markt, aber nicht jede ist für jeden Use Case geeignet.
Rüdiger Lang:
Ich würde ergänzen, dass viele Unternehmen an der Skalierung scheitern. Einzelne Teams erzielen gute Ergebnisse, aber es gelingt nicht, diese Ansätze unternehmensweit auszurollen. Genau an diesen Punkten sehen wir den größten Bedarf für erfahrene Unterstützung. Unternehmen brauchen Zugriff auf Expertise genau dann, wenn diese Herausforderungen konkret auftreten.
Gerrit Verse:
KI kann die Geschwindigkeit erheblich steigern, insbesondere bei repetitiven Aufgaben oder beim Prototyping. Entwickler kommen schneller zu ersten Ergebnissen und können Ideen schneller validieren. Gleichzeitig besteht die Gefahr, dass die Qualität leidet, wenn Ergebnisse ungeprüft übernommen werden. KI erzeugt oft plausiblen Code, der jedoch nicht immer korrekt oder optimal ist. Deshalb ist es entscheidend, den Umgang mit KI zu professionalisieren. Dazu gehören klare Review-Prozesse, Teststrategien und ein bewusster Umgang mit den Ergebnissen.
Rüdiger Lang:
Unternehmen müssen lernen, Geschwindigkeit und Qualität gleichzeitig zu steuern. Wer das beherrscht, kann Entwicklungszyklen deutlich verkürzen und schneller auf Marktanforderungen reagieren.
Gerrit Verse:
Ein zentrales Missverständnis ist, dass KI fertige Lösungen liefert. In der Praxis ist sie ein Werkzeug, das Erfahrung im Umgang erfordert. Ohne diese Erfahrung entstehen schnell ineffiziente oder fehleranfällige Lösungen. Ein weiteres Thema ist das blinde Vertrauen in KI-Ergebnisse. Viele unterschätzen, wie wichtig Validierung und Kontext sind.
Rüdiger Lang:
Aus Managementsicht sehen wir oft die Annahme, dass KI ein reines Technologiethema ist. In Wahrheit geht es um Arbeitsweisen, Rollen und Prozesse. Wer das nicht berücksichtigt, wird den Mehrwert nicht realisieren.
Rüdiger Lang:
Wir verbinden strategische Perspektive mit operativer Umsetzung. Wir entwickeln selbst Software und KI-Lösungen und kennen die Herausforderungen aus eigener Erfahrung.
Gerrit Verse:
Und wir arbeiten nicht isoliert, sondern direkt im Team. Unsere Experten unterstützen Entwickler im laufenden Projekt, an realen Fragestellungen und im konkreten Code Kontext. Dadurch entsteht kein theoretisches Wissen, sondern sofort anwendbare Erfahrung.
Rüdiger Lang:
Der größte Vorteil liegt in der Flexibilität: Unternehmen erhalten genau die Expertise, die sie benötigen – und zwar genau dann, wenn sie gebraucht wird. Das reduziert Einstiegshürden und beschleunigt die Umsetzung erheblich. Es müssen keine langfristigen Strukturen aufgebaut werden, bevor erste Ergebnisse entstehen.
Gerrit Verse:
Aus technischer Sicht ist entscheidend, dass wir direkt im Kontext arbeiten. Wir lösen konkrete Probleme im Projekt, arbeiten mit bestehenden Systemen und vermitteln Best Practices im laufenden Betrieb. Das ist deutlich effektiver als klassische Schulungen oder theoretische Konzepte.
Rüdiger Lang:
Wir sind davon überzeugt, dass jede Session einen klaren Mehrwert für unsere Kunden liefern muss – sonst lohnt sie sich nicht. Statt vorab fixierter Trainingsbudgets oder reiner T&M-Verrechnung bemessen wir unsere Vergütung anhand des Feedbacks unserer Kunden zur jeweiligen Session. Damit nehmen wir den klassischen Anbieterspagat aus dem Markt: Der Kunde zahlt nicht für Aufwand, sondern für Wirkung. Und wir setzen ein klares Signal: Wir lassen uns am Ergebnis messen.
Gerrit Verse:
Aus technischer Sicht ist das ein starkes Modell, weil es uns als Experten direkt in die Pflicht nimmt, in jeder Session relevant zu sein – ob im Pair Programming, bei der Architekturklärung oder im Code Review. Theoretische Konzepte oder Standardfolien passen in dieses Modell nicht. Praxisrelevanz schon.
Gerrit Verse:
Typischerweise startet es mit einer konkreten Fragestellung, zum Beispiel wie KI im Testing eingesetzt werden kann oder wie sich ein bestimmter Use Case umsetzen lässt. Dann arbeiten wir gemeinsam mit dem Team an genau diesem Thema, oft im Pair Programming oder in fokussierten Sessions. Dabei entstehen direkt nutzbare Ergebnisse.
Rüdiger Lang:
Parallel sorgen wir dafür, dass diese Ansätze strukturiert verankert werden. Ziel ist immer, dass das Unternehmen langfristig eigenständig mit KI arbeiten kann.
Rüdiger Lang:
Unsere Kunden kommen deutlich schneller von ersten Experimenten in die produktive Nutzung. Sie vermeiden typische Fehler und erzielen schneller messbare Ergebnisse.
Gerrit Verse:
Und sie bauen internes Know how auf. Das ist entscheidend, um KI nachhaltig erfolgreich einzusetzen.
Gerrit Verse:
Wir sehen eine zunehmende Integration von KI in bestehende Toolchains und mehr Systeme, die eigenständig Aufgaben übernehmen. Gleichzeitig steigt die Komplexität, was Architektur und Steuerung betrifft.
Rüdiger Lang:
Für Unternehmen bedeutet das: Der Bedarf an Erfahrung wird weiter steigen. Wer jetzt beginnt, Kompetenzen aufzubauen, wird langfristig profitieren.
Unternehmen, die KI erfolgreich einsetzen wollen, brauchen mehr als Technologie. Sie brauchen Zugang zu Erfahrung im richtigen Moment. Genau das leisten Experten on demand.
Greifen Sie flexibel auf erfahrene KI-Experten für Ihre Softwareentwicklung zu und bringen Sie gezielt neue Impulse in Ihre Projekte. Weil wir von der Wirksamkeit dieses Modells überzeugt sind, orientiert sich unsere Vergütung an Ihrem Feedback zu den Sessions – so tragen wir das kommerzielle Risiko, nicht Sie.
Stellen Sie sich vor, Sie stellen eine neue Marketingleiterin ein. Exzellente Referenzen, jahrelange Erfahrung in der Kampagnenproduktion, versiert in allen gängigen Tools. Drei Monate später stellen Sie fest: Sie koordiniert vor allem. Texte entstehen in Sekunden per KI-Prompt. Grafiken, Landingpages, E-Mail-Strecken, alles läuft schneller als je zuvor. Und trotzdem fragen Sie sich: Was unterscheidet uns eigentlich noch vom Wettbewerb?
Das ist eine zentrale Herausforderung für CMOs und Marketingverantwortliche in den nächsten Jahren: Die Marketing-Skills der Zukunft liegen nicht in der Produktion, denn KI übernimmt Content, Grafiken, Broschüren, Websites und Anzeigen schneller und günstiger als je zuvor. Was KI nicht kann: entscheiden, wofür eine Marke steht, wen sie ansprechen will und warum ein Kunde genau dieses Angebot wählen soll und nicht das des Wettbewerbers. Diese strategische Klarheit lässt sich nicht automatisieren.
Die Frage ist nicht mehr, ob künstliche Intelligenz Marketing verändert. Die Frage ist, welche Menschen und welche Fähigkeiten Sie brauchen, wenn der alte Engpass Produktionskapazität wegfällt und ein neuer entsteht: Urteilsvermögen, Datenverständnis und Gestaltungswille.
Klassische Marketingabteilungen waren im Kern Produktionsbetriebe: Texter, Grafiker, Kampagnenmanager, Projektkoordinatoren, Agentursteuerer. Ein Großteil der Ressourcen (Menschen und Geld) floss in die Herstellung von Inhalten. Gut gemachte Kreation war knapp und teuer.
Diese Knappheit existiert nicht mehr. KI im Marketing produziert in Minuten, was früher Tage dauerte. Das ist keine Bedrohung, wenn Marketing-Teams die frei gewordene Kapazität für das einsetzen, was wirklich Wirkung erzeugt: die Fähigkeit zu definieren, was relevant ist, was gesagt werden soll, zu wem, in welchem Ton zu welchem Zeitpunkt.
In einer Welt, in der jedes Unternehmen dieselbe Marketingautomatisierung und dieselben KI-Werkzeuge nutzen kann, wird Differenzierung zur eigentlichen Arbeit. Markenidentität, Positionierung, Zielgruppenverständnis, Wettbewerbseinordnung sind der eigentliche Engpass moderner Marketingstrategie. Wer hier Klarheit hat, gewinnt. Wer sich auf KI-Output verlässt ohne diese Klarheit, produziert schnell viel Mittelmäßiges.
Welche Marketing-Skills brauchen Unternehmen in Zukunft wirklich? Die Antwort lässt sich auf drei Kompetenzfelder verdichten, die in modernen Marketing-Teams vertreten sein müssen, nicht als Jobtitel, sondern als Fähigkeiten.
1. Strategische Markenklarheit
Gefragt ist, wer präzise beantworten kann: Was wollen wir bei wem bewirken und warum sollten die das glauben bzw. so handeln, wie wir das möchten? Diese Fähigkeit klingt selbstverständlich, ist es aber nicht. In der Praxis verschwimmt sie hinter Kampagnenplanung, Budgetdiskussionen und Abstimmungsschleifen.
Gefragt sind Menschen mit tiefem Marken- und Wettbewerbsverständnis, das über Styleguides hinausgeht. Menschen, die die richtigen Fragen stellen und Urteile treffen können. Auch unbequeme: Ist dieser KI-generierte Text gut genug? Passt diese Kampagne zu dem, wofür wir stehen? Trifft diese Botschaft den richtigen Nerv? Und die KI-Werkzeuge nicht als Maschinen bedienen, sondern als Tool einsetzen, präzise Briefings formulieren, Ergebnisse einordnen, Richtung vorgeben.
2. Datenverständnis als Grundvoraussetzung
Daten sind im Marketing kein neues Thema. Neu ist, dass Datenkompetenz zur Grundvoraussetzung wird. Nicht nur für Data Analysten oder CRM-Spezialisten, sondern für jeden, der Marketingentscheidungen trifft oder verantwortet.
Gemeint ist nicht, dass Marketingkollegen programmieren oder statistisch modellieren müssen. Gemeint ist: Können sie eine Auswertung lesen und die richtigen Fragen stellen? Erkennen sie den Unterschied zwischen einer Korrelation und einem Kausalzusammenhang und wissen sie, wann das relevant ist? Verstehen sie, was Datenqualität bedeutet und warum schlechte Daten zu schlechten Entscheidungen führen, auch wenn das Dashboard gut aussieht?
Dieses Verständnis ist die Voraussetzung für alles andere. Ohne es kann niemand beurteilen, ob eine Kampagne wirklich gewirkt hat oder ob gerade ein Zufallseffekt gemessen wird. Algorithmen optimieren auf das, was gemessen wird. Aber was gemessen wird, muss ein Mensch ebenso entscheiden wie über die Interpretation der Ergebnisse.
3. Customer Journey als Gestaltungsaufgabe
Das dritte Kompetenzfeld ist weniger eine neue Disziplin als eine Grenzverschiebung. Marketing steuert heute mehr als Kampagnen. Es gestaltet Kundenerlebnisse in Echtzeit von der ersten Wahrnehmung über den Kaufprozess bis in die Nachbetreuung. Die Grenze zu Vertrieb und Service ist dabei längst durchlässig.
Das verlangt Menschen, die das große Bild verstehen: Wie erleben Kunden die gesamte Interaktion mit unserem Unternehmen? Wo entstehen Brüche? Welche Automatisierungen helfen und welche machen das Erlebnis kälter? Gefragt ist die Fähigkeit, CRM- und Marketing-Automation-Systeme nicht nur zu bedienen, sondern zu gestalten: Welche Trigger sollen welche Reaktionen auslösen? Wann braucht ein Kunde eine menschliche Ansprache, wann reicht eine automatisierte E-Mail? Wann ist Personalisierung ein Gewinn und wann wirkt sie aufdringlich?
Das erfordert Menschen, die die Sprache von Vertrieb und Service sprechen, technische Systeme verstehen, ohne selbst zu entwickeln und vor allem: die Kundenperspektive nicht aus den Augen verlieren, wenn sie in Systemkonfigurationen versinken.
Wenn Sie heute eine Marketingstelle besetzen oder Ihr Team weiterentwickeln, lohnt es sich, die klassischen Anforderungsprofile zu hinterfragen. Stellen Sie sich drei Fragen:
Diese Fähigkeiten lassen sich entwickeln. Unternehmen, die ihre Marketingteams weiterhin vor allem nach Produktionskompetenz aufbauen, werden feststellen, dass sie zwar schneller werden. Aber nicht besser.
Was macht modernes Marketing aus? Nicht die Geschwindigkeit der Produktion, die liefert immer mehr die KI. Sondern die Qualität der Entscheidungen dahinter: Was kommunizieren wir? An wen? Auf Basis welcher Daten? Und mit welchem Erlebnis entlang der gesamten Customer Journey?
KI verändert Marketing-Teams nicht, indem sie Menschen ersetzt. Sie verändert sie, indem sie andere Menschen wichtig macht. Wer heute in strategische Markenklarheit, in Datenkompetenz und in Journey-Verständnis investiert, baut ein Marketingteam, das mit KI besser wird – nicht eines, das von ihr ersetzt wird.
Die entscheidende Frage für CMOs und Geschäftsführer lautet nicht: Wie viele KI-Tools nutzen wir? Sondern: Haben wir die Menschen, die wissen, wozu?
CRM- und CX-Systeme allein lösen das Problem nicht. Auch wer hier bereits investiert hat, holt aus diesen Systemen nur dann wirklich Leistung heraus, wenn die Menschen dahinter strategisch denken, Daten verstehen und Customer Journeys gestalten können und nicht nur Systeme bedienen.
Viele Unternehmen treiben aktuell die Automatisierung ihres Kundenservices massiv voran. Neue Technologien machen es möglich, eingehende Anfragen über E-Mail, Chat oder Voice automatisiert zu verstehen, zu klassifizieren und zu beantworten. KI-Agenten sind dabei zentrale Enabler.
Die Erwartungen sind hoch: geringere Kosten, schnellere Reaktionszeiten und eine bessere Skalierbarkeit des Services.
In der Praxis zeigt sich jedoch ein differenzierteres Bild. Unternehmen, die ihren Service konsequent automatisieren, gewinnen zwar an Effizienz, verlieren aber oft an Qualität, Differenzierung und Kundenbindung.
Nachhaltig erfolgreicher Service entsteht daher selten durch maximale Automatisierung. Entscheidend ist vielmehr die gezielte Orchestrierung von automatisierten und menschlichen Interaktionen.
Serviceeffizienz beschreibt das Verhältnis zwischen eingesetzten Ressourcen und der Qualität sowie Geschwindigkeit der Kundeninteraktion.
Typische Ziele sind:
Viele Unternehmen fokussieren sich dabei vor allem auf die Kostenseite. Automatisierung scheint hier der naheliegende Hebel zu sein.
Doch Service ist mehr als eine Kostenstelle. Er ist gleichzeitig ein zentraler Kontaktpunkt zum Kunden und damit ein wichtiger Treiber für Zufriedenheit, Bindung und zusätzliche Wertschöpfung.
Die technologischen Möglichkeiten haben sich in den letzten Jahren deutlich weiterentwickelt:
Viele Unternehmen nutzen diese Möglichkeiten bereits intensiv, insbesondere im First-Level-Support.
Die Vorteile liegen auf der Hand.
| Perspektive | Vorteile |
| Unternehmen | geringere Servicekosten, hohe Skalierbarkeit, konsistente Qualität |
| Kunde | schnelle Antworten, 24/7-Verfügbarkeit, einfache Anliegen sofort gelöst |
| Service-Organisation | strukturierte Prozesse, bessere Datenbasis, höhere Transparenz |
| Mitarbeiter | Entlastung von Routineaufgaben, Fokus auf komplexe Fälle |
Automatisierung ist damit ein zentraler Hebel, um Service effizienter zu gestalten. Doch genau hier liegt auch die Gefahr.
In vielen Unternehmen wird Automatisierung zum Selbstzweck. Ziel ist es, möglichst viele Interaktionen ohne menschliches Eingreifen abzuwickeln.
Dabei entstehen mehrere strukturelle Nachteile.
1. Verlust von echten Kundenkontakten
Service ist häufig der wichtigste – manchmal sogar der einzige – direkte Kontaktpunkt zwischen Unternehmen und Kunde. Wenn dieser vollständig automatisiert wird, gehen persönliche Interaktionen verloren.
Damit verschwindet auch:
2. Sinkende Differenzierung
Automatisierter Service lässt sich leicht kopieren. Wenn alle Unternehmen ähnliche Bots und Prozesse einsetzen, wird Service austauschbar.
Der Wettbewerb verlagert sich dann schnell wieder auf den Preis.
3. Weniger Cross- und Upselling-Potenzial
In vielen Branchen entstehen zusätzliche Geschäftsabschlüsse im Servicekontext:
Diese Potenziale lassen sich rein automatisiert nur begrenzt nutzen.
4. Verlust von Kundenverständnis
Viele wertvolle Informationen entstehen im persönlichen Austausch. Automatisierte Systeme können Daten strukturieren – aber nicht immer interpretieren.
Das Risiko: Kundenbedürfnisse werden weniger tief verstanden.
5. „Silent Churn“
Unzufriedene Kunden äußern sich in digitalen Kanälen oft weniger. Sie brechen Interaktionen ab – oder wechseln direkt den Anbieter.
Das macht Probleme im Service schwerer sichtbar.
In der Praxis lassen sich – ähnlich wie im Vertrieb – zwei grundlegende Ansätze beobachten.
| Atomatisierter Service (Automation-first) | Menschzentrierter Service (Human-first) |
| Standardanfragen werden automatisiert bearbeitet | persönliche Interaktion steht im Vordergrund |
| Prozesse sind stark strukturiert und datengetrieben | individuelle Problemlösung |
| hohe Geschwindigkeit und Skalierbarkeit | Aufbau von Vertrauen und Beziehung |
| geringe Kosten pro Interaktion | hohe Qualität bei komplexen Anliegen |
| Dieser Ansatz funktioniert besonders gut bei klar standardisierbaren Anliegen. | Dieser Ansatz ist insbesondere bei beratungsintensiven oder sensiblen Themen entscheidend. |
Viele Unternehmen bewegen sich zu stark in eines der beiden Extreme.
Wenn Service zu stark automatisiert ist…
Wenn Service zu stark menschlich geprägt ist…
Die größte Wirkung entsteht dort, wo Automatisierung und menschlicher Service gezielt kombiniert werden.
Fünf Ansätze sind dabei besonders relevant.
1. Automatisierungspotenziale systematisch identifizieren
Nicht jede Interaktion eignet sich für Automatisierung. Unternehmen sollten klar unterscheiden zwischen:
Nur im ersten Fall entfaltet Automatisierung ihren vollen Nutzen.
2. Wert von Kunden und Situationen berücksichtigen
Nicht jede Interaktion ist gleich wichtig.
Beispiele:
In solchen Situationen ist menschlicher Service oft entscheidend, unabhängig vom Automatisierungspotenzial.
3. Service als Werttreiber verstehen
Service sollte nicht nur als Kostenfaktor betrachtet werden.
Gezielt eingesetzte menschliche Interaktion kann:
Gerade an wichtigen Touchpoints entsteht oft mehr Wert als im klassischen Vertrieb.
4. Klare Routing- und Orchestrierungslogiken etablieren
Die zentrale Frage ist nicht: „Was können wir automatisieren?“
Sondern: „Was sollten wir automatisieren – und was bewusst nicht?“
Dafür braucht es klare Entscheidungsregeln, z. B.:
5. CRM- und CX-Systeme als Steuerungszentrale nutzen
CRM-Systeme spielen eine entscheidende Rolle bei der Serviceautomatisierung, allerdings nicht nur als Dokumentationswerkzeug.
Sie ermöglichen:
Damit werden sie zur zentralen Instanz, um automatisierte und menschliche Interaktionen sinnvoll zu orchestrieren.
Unternehmen können ihren Service mit drei einfachen Fragen hinterfragen:
Wenn mehrere dieser Fragen nicht klar beantwortet werden können, besteht meist ein erhebliches Optimierungspotenzial.
Die technologischen Möglichkeiten im Service werden weiter zunehmen. Automatisierung und KI werden in vielen Bereichen zum Standard.
Der entscheidende Unterschied liegt jedoch nicht in der Technologie.
Er liegt in der Frage, wie Unternehmen sie einsetzen.
Organisationen, die Service erfolgreich gestalten,
Damit wird Service nicht nur effizienter, sondern auch wirksamer – für Kunden und für das Unternehmen.