Forward-Deployed Engineering: KI direkt im Betrieb

Ein typischer Verlauf: Der Pilot zur automatischen Rechnungsklassifizierung liefert eine überzeugende Demo und beantwortet die Frage, ob KI grundsätzlich helfen kann. Trotzdem landet Monate später keine Rechnung automatisch im ERP. Das Modell läuft isoliert, die Freigabekette bleibt unangetastet, und die Buchhaltung arbeitet wieder in Excel weiter.

Dieses Muster ist im Mittelstand häufig. Die KI ist nicht das eigentliche Problem. Scheitern lässt die letzte Meile, also die Verbindung zu ERP, CRM, Berechtigungen, Datenqualität, Legacy-Schnittstellen und dem Prozess, für den am Ende jemand Verantwortung trägt. Forward-Deployed Engineering setzt genau an dieser Lücke an. Senior Engineers arbeiten direkt in der Systemlandschaft und im Fachteam, bauen produktive Integrationen und bleiben so lange an Bord, bis ein messbarer Workflow im Betrieb funktioniert.

Warum KI-Projekte im Kerngeschäft stecken bleiben

Der Pilot aus der Kreditorenbuchhaltung ist technisch plausibel. Ein Modell liest Rechnungsdaten, ordnet Konten zu und schlägt eine Klassifizierung vor. In der Demo sieht das nach einem fertigen Produkt aus. Im Tagesgeschäft fehlen jedoch die entscheidenden Verbindungen: Lieferantenstammdaten, Bestellbezug, Vier-Augen-Freigabe, Ausnahmefälle und die Rückmeldung an das ERP.

Nach einigen Monaten ist die Situation ernüchternd. Die IT hat keine freien Kapazitäten für eine saubere Integration, der externe Berater ist nicht mehr an Bord, und die Fachabteilung vertraut dem Modell nicht genug, um die manuelle Kontrolle abzugeben. Die Demo war erfolgreich, der Prozess nicht.

Die letzte Meile ist ein Ownership-Problem

Klassische Projektmodelle trennen häufig zwischen Analyse, Entwicklung und Betrieb. Ein Beratungsteam beschreibt den Use Case, ein Innovationsteam baut den Proof of Concept, und die interne IT soll anschließend die produktive Lösung übernehmen. Jede Übergabe erzeugt Informationsverlust. Wer das Modell mit den Prozessverantwortlichen entwickelt hat, kennt oft weder die Berechtigungslogik noch die Besonderheiten der produktiven Schnittstellen.

Forward-Deployed Engineering verändert diese Verantwortungskette. Der Engineer untersucht nicht nur, welche KI-Funktion möglich wäre. Er kartiert Datenflüsse, schreibt Integrationscode, testet mit realen Ausnahmefällen und verantwortet gemeinsam mit dem Kundenteam den Weg bis zum Go-live. Damit wird aus einem isolierten Experiment ein Systembestandteil.

Praktische Regel: Ein KI-Pilot ist erst dann abgeschlossen, wenn Berechtigungen, Monitoring, Fehlerbehandlung, Übergabe und Betrieb geklärt sind. Eine gute Demo ist ein Anfang, kein Beweis.

Was Forward-Deployed Engineering wirklich bedeutet

Den Begriff hat Palantir geprägt: Engineers, die beim Kunden statt in der Zentrale sitzen, direkt an dessen Daten und Problemen arbeiten und Software vor Ort bauen und ändern dürfen. Im angewandten KI-Kontext heißt das: Erfahrene Engineers werden in die Umgebung eingebettet, in der das Problem entsteht. Das kann physisch beim Kunden geschehen oder virtuell über gemeinsame Repositories, Arbeitsräume und freigegebene Systemzugänge. Entscheidend ist nicht der Ort, sondern die Nähe zu den echten Daten, Entscheidungen und technischen Einschränkungen.

Im ERP bedeutet das: Der Engineer versteht nicht nur ein Sprachmodell, sondern auch das konkrete SAP-Modul, die Salesforce-Konfiguration, die Navision-Datenbank, die DATEV-Prozesse oder die individuellen Freigaberegeln eines Unternehmens.

So arbeitet ein eingebetteter Engineer

Die Arbeitsweise lässt sich in vier Verantwortungsbereiche zerlegen:

• Verstehen: Der Engineer beobachtet den Prozess, spricht mit den Sachbearbeitern und prüft, welche Daten tatsächlich verfügbar sind.
• Bauen: Er entwickelt Adapter, Services, Agenten und Oberflächen in der bestehenden technischen Umgebung.
• Absichern: Er integriert Tests, Berechtigungskontrollen, Protokollierung und Monitoring, statt nur einen funktionierenden Happy Path zu liefern.
• Übergeben: Das interne Team erhält Code, Runbooks, Architekturentscheidungen und praktische Erfahrung aus gemeinsamen Reviews.

Oft arbeiten mehrere Profile zusammen: jemand, der Modelle und Evaluationen bewertet, jemand, der APIs, Datenbanken, Dateien und Legacy-Systeme verbindet, und jemand, der Deployment, Versionierung und Monitoring verantwortet.

Seniorität ist dabei keine Komfortoption. In einer unbekannten ERP-Landschaft muss jemand gleichzeitig technische Risiken erkennen, mit Finance oder Operations sprechen und zwischen Geschwindigkeit und Stabilität abwägen. Ein weniger erfahrener Entwickler kann einzelne Tickets abarbeiten. Er erkennt aber nicht zwingend, dass ein scheinbar einfacher API-Aufruf eine Buchungslogik, ein Berechtigungskonzept oder eine Revisionsanforderung verletzt.

Was das Modell nicht ist

Forward-Deployed Engineering ist keine Beratung mit mehr Workshops. Es ist auch keine klassische Personalüberlassung, bei der zusätzliche Entwickler nach einem bestehenden Backlog arbeiten. Der zentrale Unterschied liegt in der Ergebnisverantwortung. Das Team baut gemeinsam mit dem Kunden eine Lösung, die unter realen Bedingungen funktioniert, und macht die dafür notwendigen technischen Entscheidungen sichtbar.

Der Unterschied zu klassischer Beratung und Staff Augmentation

Unternehmen kaufen externe KI-Kompetenz meist in einem von drei Modellen ein. Die Wahl entscheidet darüber, wer das Ergebnis verantwortet, wie nah das Team an der Produktionsumgebung arbeitet und ob Wissen nach dem Projekt im Unternehmen bleibt.

Beratung liefert Orientierung

Beratung ist sinnvoll, wenn das Problem noch nicht eingegrenzt ist. Sie kann Prozesse aufnehmen, Optionen vergleichen und eine Investitionsentscheidung vorbereiten. Sie wird aber nicht automatisch zur Betreiberin einer Schnittstelle, wenn die Analyse abgeschlossen ist.

Das typische Risiko ist ein sauberer Zielzustand ohne belastbaren Weg dorthin. Eine Roadmap beschreibt, dass Rechnungen automatisiert werden sollen. Sie beantwortet aber nicht zwingend, wie Ausnahmen behandelt werden, welcher Service-Account zugreifen darf oder wer einen Modellfehler im Monatsabschluss untersucht. Worauf Sie bei der Auswahl von KI-Beratern achten sollten, beschreibt der Leitfaden KI Consulting.

Staff Augmentation liefert Kapazität

Staff Augmentation hilft, wenn ein Unternehmen bereits eine klare Architektur, ein priorisiertes Backlog und interne Steuerung besitzt. Ein zusätzlicher Entwickler kann eine API anbinden oder einen Service erweitern. Die Verantwortung für Produktentscheidung, Prozessdesign und Abnahme bleibt jedoch beim Auftraggeber.

Das Modell scheitert dort, wo das Ticket das Problem nicht präzise beschreibt. Ein Auftrag wie „LLM an das CRM anbinden“ sagt wenig über Datenhoheit, Antwortqualität, Eskalationen oder die gewünschte Prozessverbesserung aus. Wer nur das Ticket erfüllt, kann technisch korrekt liefern und trotzdem am Geschäftsziel vorbeiarbeiten.

Forward-Deployed Engineering verbindet die Ebenen

Ein Forward-Deployed Engineer übernimmt Discovery und Umsetzung als zusammenhängende Arbeit. Er prüft die Annahmen im System, baut einen lauffähigen Pfad und bringt die offenen Fragen in die Entscheidungen des Kundenteams. Wenn Sie gezielt erfahrene Engineers für Ihr Team suchen, finden Sie die Details auf unserer englischsprachigen Seite zum Einsatz unseres Teams.

Der Preis dieser Nähe ist höherer Abstimmungsaufwand. Der Engineer muss Fachbereiche, Security, IT und Management gleichzeitig verstehen. Das Modell lohnt sich deshalb nicht für jedes kleine, standardisierte Vorhaben. Es passt dort, wo die Integration selbst den Wert bestimmt.

Der Ablauf von Discovery bis Produktion

Ein produktives Projekt beginnt nicht mit einem Modellvergleich. Es beginnt mit der Frage, wo im Prozess eine Entscheidung, Übergabe oder Kontrolle tatsächlich hängen bleibt. Der Ablauf schafft dafür technische Artefakte und verbindliche Abnahmepunkte. Wie wir das in der Praxis strukturieren, beschreibt unsere englischsprachige Seite So arbeiten wir.

Discovery schafft ein belastbares Bild

In der ersten Phase untersuchen Engineer und Fachbereich gemeinsam Systemlandschaft und Arbeitsablauf. Der Engineer kartiert API-Zugänge, Datenbanken, Dateien, Queues, Identitäten und bestehende Integrationsplattformen. Parallel prüft er mit den Prozessverantwortlichen, welche Fälle häufig auftreten, welche Ausnahmen kritisch sind und wo heute manuell nachgearbeitet wird.

Das wichtigste Ergebnis ist ein Integration Blueprint. Er beschreibt Datenquellen, Transformationen, Modell- oder Agentenlogik, Zielsysteme, Berechtigungen und Rückfallpfade. Ein Use Case geht nur weiter, wenn fachliche Wirkung und technische Machbarkeit zusammenpassen.

Build bringt kleine, prüfbare Systeme

In der Build-Phase entstehen lauffähige Teilsysteme statt einer großen Lösung am Ende. Jeder Sprint zeigt einen konkreten Teil des Workflows, etwa das Einlesen eines Dokuments, die Validierung gegen Stammdaten oder die Übergabe eines genehmigten Ergebnisses an das ERP.

Die Tests laufen in einer Staging-Umgebung mit repräsentativen Daten und bewusst ausgewählten Grenzfällen. Parallel entstehen CI/CD-Pipelines, Monitoring, Konfiguration und Betriebsdokumentation. Wer nur das Modell testet, prüft den wichtigsten Teil zu spät. In der Produktion entscheidet die gesamte Kette über die Qualität.

Go-live bleibt kontrolliert

Der Rollout erfolgt hinter Feature-Flags oder für klar abgegrenzte Nutzergruppen. In einem Shadow-Run erzeugt die KI Ergebnisse parallel zum manuellen Prozess, ohne sofort Buchungen oder Kundenkommunikation auszulösen. Das Team vergleicht Modellentscheidung, menschliche Entscheidung, Ausnahmequote und Bearbeitungsweg.

Erst wenn die definierten Abnahmekriterien erfüllt sind, folgt die vollständige Umstellung. Jede Phasengrenze erhält eine dokumentierte Go- oder No-Go-Entscheidung. Die entscheidende Frage ist nicht nur, ob ein Modell antwortet, sondern ob der Workflow sicher weiterläuft, wenn das Modell keine Antwort geben kann.

Stabilisierung gehört zum Projekt

Nach dem Go-live ändern sich Daten, Nutzerverhalten und Geschäftsregeln. Das Team beobachtet Fehlermuster, Antwortqualität, Latenz, Kosten und manuelle Eingriffe. Erst diese Betriebsphase zeigt, ob aus dem Prototyp ein verlässlicher Bestandteil des Unternehmensprozesses geworden ist. Woran Sie Produktionsreife erkennen, beschreibt der Beitrag Production Readiness für KI-Anwendungen.

Typische Pain Points und wie das Modell sie löst

Mittelständische Unternehmen scheitern selten an fehlender Motivation. Sie scheitern an einer heterogenen Realität: Ein ERP läuft lokal, ein CRM in der Cloud, Rechnungen kommen als Dateien, und wichtige Regeln stehen in den Köpfen erfahrener Mitarbeitender.

In Österreich nutzten 2025 bereits 30 % der Unternehmen mit mindestens zehn Beschäftigten KI-Technologien, nach 20 % im Jahr 2024 und 9 % im Jahr 2021. Österreich lag damit über dem EU-Durchschnitt von 20 %, wie Statistik Austria berichtet. Der Engpass verschiebt sich dadurch von der grundsätzlichen Einführung zur produktiven Verbindung mit den vorhandenen Systemen.

Legacy-Systeme verlangen Adapter statt Wunscharchitektur

Viele Kernsysteme bieten keine moderne API für jeden benötigten Vorgang. Ein eingebetteter Engineer wartet dann nicht monatelang auf ein vollständiges ERP-Upgrade. Er bewertet kontrollierte Alternativen, etwa Middleware, Datenbankzugriffe, dateibasierte Exporte oder eine RPA-Brücke, und kapselt diese über klare Adapter.

Das Ziel ist nicht, eine fragile Sonderlösung zu verstecken. Jede Brücke braucht Berechtigungen, Tests, Protokollierung, einen Owner und einen späteren Ablösepfad. So bleibt sichtbar, welche technische Schuld bewusst eingegangen wurde. Mehr dazu im Beitrag zur Legacy-Modernisierung für ERP und CRM.

Fragmentierte Prozesse brauchen die Sicht auf das Ganze

Eine KI kann einen einzelnen Arbeitsschritt beschleunigen, während der Gesamtprozess unverändert bleibt. Ein Dokument wird schneller klassifiziert, wartet aber weiterhin auf eine manuelle Übertragung ins ERP. Ein CRM-Agent erstellt einen Vorschlag, doch niemand bearbeitet die anschließende Aufgabe.

Value-Stream-Mapping zeigt, wo die eigentliche Verzögerung entsteht. Der Engineer verfolgt den Vorgang vom Eingang bis zum Abschluss und misst nicht nur die Modellleistung, sondern auch Übergaben, Wartezeiten, Rückfragen und Eskalationen.

Kompetenzlücken schließen sich im Code

Viele österreichische Unternehmen haben die digitale Basis noch nicht erreicht: Laut Statistik Austria erreichten 2025 73 % der kleinen und mittleren Unternehmen zumindest ein grundlegendes Digitalisierungsniveau, das EU-Ziel für 2030 liegt bei 90 %. Und 77 % der Unternehmen ohne KI-Nutzung hatten den Einsatz noch gar nicht erwogen, wie die Auswertung zur KI-Nutzung 2025 zeigt.

Pair Programming, gemeinsame Code-Reviews und betriebliche Runbooks wirken hier besser als eine Schulung ohne Bezug zum Alltag. Entscheidend ist, dass das interne Team die gelieferte Integration selbst weiterführen kann.

Erfolgskennzahlen und Governance im Enterprise-Einsatz

Ein Pilot kann mit einer beeindruckenden Modellantwort überzeugen. Ein Produktionssystem muss mehr leisten. Es muss zeigen, ob der Ablauf schneller wird, ob Fehler sinken, ob Mitarbeitende Entscheidungen nachvollziehen können und ob das Unternehmen den Betrieb kontrolliert.

Die Messung beginnt vor dem ersten Build. Das Team dokumentiert eine Baseline und definiert, welche Veränderung als Erfolg gilt. Geeignete Kennzahlen sind:

• Durchlaufzeit: Wird ein Vorgang vom Eingang bis zur Freigabe tatsächlich schneller?
• Fehlerrate: Wie häufig entstehen falsche Zuordnungen, fehlende Felder oder manuelle Korrekturen?
• Skalierbarkeit: Kann das System mehr Vorgänge verarbeiten, ohne dass jeder zusätzliche Fall proportional mehr Personal bindet?
• Time-to-Value: Wann trifft die erste produktive KI-Entscheidung unter kontrollierten Bedingungen?

Zielwerte legen Sie vor dem Projekt gemeinsam fest und messen sie im eigenen Prozess. Allgemeine Marktwerte ersetzen diese Messung nicht.

Governance muss im Design beginnen

Datensouveränität lässt sich nicht nachträglich in eine fertige Demo einbauen. Das Team entscheidet früh, ob On-Premise, Private Cloud oder ein anderer kontrollierter Betriebsweg zur Datenklasse und zum Risiko passt. Zugriff erhält nur, wer ihn für den jeweiligen Workflow benötigt.

Decision-Logs halten fest, welche Eingaben, Regeln, Modellversionen und Freigaben zu einem Ergebnis geführt haben. Revisionssichere Audit-Trails protokollieren Änderungen und menschliche Eingriffe, ohne sensible Inhalte unnötig zu vervielfältigen.

Governance beginnt nicht beim Audit. Sie beginnt bei der ersten Schnittstelle, die ein KI-Agent aufrufen darf.

Die Einwände aus Enterprise-Teams sind berechtigt. Ein externer Engineer kann interne Verantwortliche überlasten, wenn Rollen, Zugänge und Entscheidungswege unklar bleiben. Deshalb braucht jedes Projekt einen Product Owner, einen technischen Owner, feste Review-Termine und eine Übergabeplanung ab dem ersten Sprint.

So prüfen Sie, ob Forward-Deployed Engineering zu Ihnen passt

Forward-Deployed Engineering passt nicht zu jedem KI-Vorhaben. Wenn ein Standardtool ohne tiefe Anpassung funktioniert, reicht ein gutes Onboarding. Das eingebettete Modell wird interessant, sobald mehrere Systeme, unklare Anforderungen oder kritische Freigaben zusammenkommen.

Die kurze Entscheidungshilfe

Beantworten Sie diese Fragen mit Ja oder Nein:

• Systemzugang: Gibt es API-, Datenbank- oder kontrollierte Dateizugänge zu ERP, CRM und Backoffice?
• Prozessklarheit: Ist ein konkreter Workflow von Anfang bis Ende benannt, statt nur ein allgemeines KI-Ziel?
• Governance: Sind Datenklassen, Berechtigungen, Protokollierung und menschliche Freigaben definiert?
• Ownership: Gibt es einen internen Product Owner und einen technischen Ansprechpartner?
• Messbarkeit: Existiert eine Baseline für Durchlaufzeit, Fehler, manuelle Arbeit oder Eskalationen?
• Betrieb: Kann das interne Team Code, Monitoring und Runbooks nach der Übergabe betreuen?

Mehrere Nein-Antworten bedeuten nicht, dass das Modell ungeeignet ist. Sie zeigen, welche Voraussetzungen zuerst geschaffen werden müssen. Gerade bei komplexen Systemlandschaften sollte die Organisation nicht mit einem freien Chat-Interface starten, sondern mit einem begrenzten Prozess, dessen Eingang, Ausgang und Verantwortlichkeit klar sind.

Die ersten drei Schritte

1. System-Audit: Lassen Sie Datenflüsse, Schnittstellen, Berechtigungen und manuelle Übergaben dokumentieren.
2. Abstimmung der Beteiligten: Bringen Sie Finance, Operations, IT, Security und Revision an einen Tisch und bestimmen Sie einen gemeinsamen Prozess-Owner.
3. Fokussierte Discovery: Starten Sie mit einer kurzen Discovery, die einen Integration Blueprint, Risiken, eine KPI-Baseline und eine Go- oder No-Go-Empfehlung liefert.

Wie wir dieses Modell für Unternehmen in Wien und im DACH-Raum umsetzen, beschreibt unsere Seite zur KI-Agentur Wien.

Sprechen Sie mit uns

Wenn Sie aus einem isolierten KI-Pilot einen kontrollierten, messbaren Workflow machen wollen, sprechen Sie mit uns.