Der Finance-Leiter hat alles richtig gemacht. Der Pilot zur automatischen Rechnungsklassifizierung liefert eine überzeugende Demo, arbeitet mit einer Klassifizierungsgenauigkeit von 94 Prozent und beantwortet die Frage, ob KI grundsätzlich helfen kann. Trotzdem landet heute keine Rechnung automatisch im ERP. Das Modell läuft isoliert, die Freigabekette bleibt unangetastet und die Buchhaltung führt ihre Arbeit 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 Fachteams, bauen produktive Integrationen und bleiben so lange an Bord, bis ein messbarer Workflow im Betrieb funktioniert.
Inhaltsverzeichnis
- Warum KI-Projekte im Kerngeschäft stecken bleiben
- Was Forward-deployed Engineering wirklich bedeutet
- Der Unterschied zu klassischer Beratung und Staff Augmentation
- Der Ablauf von Discovery bis Production
- Typische Pain Points und wie das Modell sie löst
- Erfolgskennzahlen und Governance im Enterprise-Einsatz
- So prüfen Sie ob Forward-deployed Engineering zu Ihnen passt
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-Abteilung hat keine freien Kapazitäten für eine saubere Integration, der externe Berater liefert keine laufende Wartung mehr und die Fachabteilung vertraut dem Modell nicht ausreichend, 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. Die Personen, die das Modell mit echten Prozessverantwortlichen entwickelt haben, kennen dann 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.
Österreichs Markt zeigt, dass diese Arbeitsweise zunehmend als konkrete Engineering-Rolle verstanden wird. Stellenanzeigen in Wien, unter anderem bei accilium, Google Cloud und NTT DATA, beschreiben kundennahe Arbeit, Prototyping, Legacy-Integrationen und den Übergang von KI-Use-Cases in produktionsfähige Systeme. Eine ausgeschriebene Rolle nennt 55.000 bis 75.000 Euro brutto pro Jahr und ordnet die Position als produktionsorientierte, kundeneingebettete Engineering-Funktion ein, wie die österreichische Ausschreibung für einen Forward Deployed Engineer zeigt.
Praktische Regel: Ein KI-Pilot ist erst dann abgeschlossen, wenn Berechtigungen, Monitoring, Fehlerbehandlung, Übergabe und Betrieb geklärt sind. Eine gute Demo ist dafür ein Anfang, kein Beweis.
Was Forward-deployed Engineering wirklich bedeutet
Forward-deployed Engineering bedeutet, dass erfahrene Engineers direkt in die Umgebung eingebettet werden, in der das Problem entsteht. Das kann physisch beim Kunden geschehen oder virtuell über gemeinsame Arbeitsräume, Repositories, Meetings und freigegebene Systemzugänge. Entscheidend ist nicht der Ort, sondern die Nähe zu den echten Daten, Entscheidungen und technischen Einschränkungen.
Die passende Analogie ist ein eingebetteter Spezialist im Einsatz. Er schreibt keinen Bericht aus sicherer Entfernung, sondern arbeitet dort, wo die Operation stattfindet. Im ERP bedeutet das: Er 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 Benutzeroberflä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.
Typischerweise arbeiten mehrere Profile zusammen. Ein Machine-Learning-Engineer bewertet Modelle und Evaluationen. Ein Integration-Specialist verbindet APIs, Datenbanken, Dateien und Legacy-Systeme. Ein MLOps-Praktiker kümmert sich um Deployment, Versionierung, Monitoring und den sicheren Betrieb.
Seniorität ist dabei keine Komfortoption. In einer unbekannten ERP-Landschaft muss jemand gleichzeitig technische Risiken erkennen, mit Finance oder Operations sprechen und eine Entscheidung über Geschwindigkeit und Stabilität treffen. 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 Staff Augmentation, bei der zusätzliche Entwickler nach einem bestehenden Backlog arbeiten. Der zentrale Unterschied liegt in der Outcome-Verantwortung. Das Team baut gemeinsam mit dem Kunden eine Lösung, die unter realen Bedingungen funktioniert, und macht die dafür notwendigen technischen Entscheidungen sichtbar.
In Österreich ist dieser Bedarf besonders greifbar. Digitalisierungs- und Integrationsleistungen für ERP, WMS und Automatisierung begleiten Unternehmen traditionell von der Analyse bis zum Go-live, inklusive Training und laufender Unterstützung. Forward-deployed Engineering überträgt dieses Umsetzungsmodell auf KI. Die Technologie wird nicht neben dem Prozess installiert, sondern in die Wertschöpfungskette eingebaut.
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.
| Kriterium | Klassische Beratung | Staff Augmentation | Forward-deployed Engineering |
|---|---|---|---|
| Ownership | Analyse, Empfehlungen und Roadmap | Umsetzung definierter Tickets | Gemeinsame End-to-End-Verantwortung bis zum produktiven Ergebnis |
| Zeitrahmen | Häufig abhängig von Studien, Konzepten und Entscheidungszyklen | Abhängig von Backlog und interner Steuerung | Iterativ von Discovery über Build bis zum Betrieb |
| Produktionsnähe | Meist indirekt | Technisch möglich, aber vom Auftrag abhängig | Direkte Arbeit in Repositories, Pipelines und Kundensystemen |
| Wissenstransfer | Workshops und Dokumentation | Vor allem während der Ticketbearbeitung | Pair Programming, Code-Reviews und Runbooks |
| Kostenstruktur | Bezahlung für Beratungsleistung und Projektumfang | Bezahlung für verfügbare Entwicklerkapazität | Bezahlung für seniorige Umsetzung und Verantwortung |
| Passender Einsatz | Strategie, Zielbild, unabhängige Bewertung | Temporärer Kapazitätsengpass | Komplexe Integration mit unklarer letzter Meile |
Beratung liefert Orientierung
Eine 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.
Staff Augmentation liefert Hände
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 meist beim Auftraggeber.
Das Modell scheitert dort, wo das Ticket selbst 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. Für Unternehmen, die gezielt einen AI Engineer mieten und dabei auf produktive Mitarbeit statt auf reine Kapazität setzen wollen, kann Rent an AI Engineer eine passende Beschaffungsoption sein.
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 und ein isolierter Entwickler oder eine reine Strategiephase die entscheidenden Risiken nicht löst.
Der Ablauf von Discovery bis Production
Ein produktives FDE-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.
Discovery schafft ein belastbares Bild
In der ersten Phase werden Systemlandschaft und Arbeitsablauf gemeinsam untersucht. Der Engineer kartiert API-Zugänge, Datenbanken, Dateien, Queues, Identitäten und bestehende Integrationsplattformen. Parallel prüft er mit Prozessverantwortlichen, welche Fälle häufig auftreten, welche Ausnahmen kritisch sind und an welcher Stelle 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 die fachliche Wirkung und die technische Machbarkeit zusammenpassen.
Build bringt kleine, prüfbare Systeme
In der Build-Phase entstehen lauffähige Teilsysteme statt einer grossen Lösung am Ende. Jeder Sprint sollte einen konkreten Teil des Workflows zeigen, 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-Dashboards, Konfigurationsdateien und Betriebsdokumentation. Wer nur das Modell testet, prüft den wichtigsten Teil zu spät. In der Produktion entscheidet die gesamte Kette über 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 der Full Cutover. Jede Phasengrenze erhält eine dokumentierte Go/No-Go-Entscheidung. Für Teams, die dafür ein wiederverwendbares Process Framework für KI-Implementierungen benötigen, ist die entscheidende Frage 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.
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 Mitarbeiter.
Österreich nutzte 2025 bereits 30 Prozent der Unternehmen KI-Technologien, nach 20 Prozent im Jahr 2024 und 9 Prozent im Jahr 2021. Damit lag Österreich über dem EU-Durchschnitt von 20 Prozent, wie Statistik Austria zur KI-Nutzung 2025 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-Patterns.
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.
Fragmentierte Prozesse brauchen End-to-End-Sicht
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 in das ERP. Ein CRM-Agent erstellt einen Vorschlag, doch niemand bearbeitet die anschliessende 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.
Skill-Gaps werden im Code übertragen
Österreichische Unternehmen verfügen nicht überall über die nötige digitale Reife. 73 Prozent haben mindestens ein grundlegendes Digitalisierungsniveau erreicht, liegen damit aber unter dem EU-Ziel von 90 Prozent bis 2030. Bei Unternehmen, die KI noch nicht nutzen, sehen 77 Prozent die Technologie bislang nicht einmal in Einführung, laut Statistik Austria zum Digitalisierungsstand 2025.
Pair Programming, gemeinsame Code-Reviews und betriebliche Runbooks wirken besser als eine Schulung ohne Bezug zum Alltag. Für fachliche Detailfragen kann zusätzlich eine Ressource wie die Schufa Analyse von CreditWise24 helfen, komplexe Daten- und Entscheidungslogik verständlich zu strukturieren. Entscheidend bleibt, 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 KPI-Kategorien 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 Transaktionen verarbeiten, ohne dass jeder zusätzliche Fall proportional mehr Personal bindet?
- Time-to-Value: Wann trifft die erste produktive KI-Entscheidung unter kontrollierten Bedingungen?
Die im Projektplan genannten Beispielwerte, etwa eine Verkürzung der Rechnungsbearbeitung von 12 auf 3 Minuten, eine Reduktion manueller Dateneingabefehler um 85 Prozent, eine produktive Entscheidung innerhalb von 6 bis 8 Wochen statt 6 bis 12 Monaten, dürfen nur als vorher definierte Zielgrössen verwendet werden. Sie sind keine allgemeinen Marktwerte und müssen im konkreten Unternehmen erst gemessen werden.
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. Explainability-Reports machen die Entscheidung für Fachbereich und Revision prüfbar. 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.
Auch Facility Management zeigt, warum operative Daten erst durch saubere Prozesse wertvoll werden. Die datengetriebene Reinigung von mr. clean AG ist dafür ein anschaulicher Kontext: Sensorik, Aufträge und Ressourcenplanung müssen zusammenwirken, damit aus Daten eine steuerbare Leistung entsteht. Bei KI in Finance oder CRM gilt dasselbe Prinzip. Der einzelne Modelloutput ist weniger wichtig als die kontrollierte Prozesskette.
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 Datei-Zugänge zu ERP, CRM und Backoffice?
- Prozessklarheit: Ist ein konkreter End-to-End-Workflow 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 automatisch, dass das Modell ungeeignet ist. Sie zeigen, welche Voraussetzungen zuerst geschaffen werden müssen. Besonders 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.
Österreichs Kompetenzlage verstärkt diesen Prüfpunkt. Das Digital Skills Barometer nennt einen Technology Skills Gap von 28 Punkten und einen besonders ausgeprägten KI-Rückstand von 30 Punkten. Nur 42 Prozent verfügen laut Digital Skills Barometer des Bundesministeriums über Kompetenzen für einen selbstständigen, sicheren und reflektierten Einsatz digitaler Technologien.
Die ersten drei Schritte
- System-Audit: Lassen Sie Datenflüsse, Schnittstellen, Berechtigungen und manuelle Übergaben dokumentieren.
- Stakeholder-Alignment: Bringen Sie Finance, Operations, IT, Security und Revision an einen Tisch und bestimmen Sie einen gemeinsamen Prozess-Owner.
- Fokussierte Discovery: Starten Sie einen Workshop, der innerhalb von zwei Wochen ein Integration Blueprint, Risiken, KPI-Baseline und eine Go/No-Go-Empfehlung liefert. Für eine strukturierte AI Self-Assessment-Prüfung können Sie diese Fragen vorab systematisch bewerten.
Specialty Tokens bietet eingebettete Senior-Engineers, die ERP-, CRM- und Legacy-Systeme mit KI verbinden, Integrationen gemeinsam mit Ihrem Team bauen und den Rollout bis in den produktiven Betrieb begleiten. Besuchen Sie Specialty Tokens, wenn Sie aus einem isolierten KI-Pilot einen kontrollierten, messbaren Workflow machen wollen.