Zum Inhalt springen

Alle Beiträge / KI-Engineering · 29. Juli 2026 · 6 min Lesezeit

Wie wir bei SIEL Forward Deployed Engineering machen

Forward Deployed Engineering ist keine Stellenbezeichnung. Es ist das einzige Liefermodell, das wir gefunden haben, mit dem ein KI-System vom Piloten in den echten Betrieb kommt und nach unserem Abschied weiterläuft.

Geschrieben von Engineering-Team von SIEL AI · Veröffentlicht 29. Juli 2026

Ein Engineer sitzt neben einem Betriebsleiter an einem Schreibtisch in einer Lagerhalle, vor ihnen ein Bildschirm mit einem Workflow-Diagramm

Forward Deployed Engineering ist bei uns keine Stellenbezeichnung. Es ist das einzige Liefermodell, das wir gefunden haben, mit dem ein KI-System vom Piloten in den echten Betrieb kommt und nach unserem Abschied weiterläuft. Was folgt, ist die unglamouröse Version davon: was wir tun, was wir ablehnen und woran wir uns messen lassen.

Zu wem wir tatsächlich gehen

Unsere Kunden sind Hersteller, Händler, Gesundheitsanbieter und Dienstleister. Echter Betrieb, echte Budgets, niemand, dessen eigentlicher Job KI ist. Auf der anderen Seite gibt es fast nie einen Engineer, dem man das System übergeben könnte. Die Menschen, die mit dem leben werden, was wir bauen, sind eine Betriebsleiterin, ein Finanzmanager, ein IT-Generalist, der schon vier Systeme verantwortet und nicht um ein fünftes gebeten hat. Wenn sie es nicht verstehen, betreiben und verändern können, haben wir nichts geliefert. Wir haben ihnen eine Abhängigkeit vermietet.

Das Audit entscheidet, was nicht gebaut wird

Jedes Projekt beginnt mit einem zweiwöchigen Workflow-Audit, und sein nützlichstes Ergebnis ist eine kürzere Liste als die, mit der wir hereingekommen sind. Das Erste, worum wir bitten, ist kein Systemzugang. Es ist ein Platz neben der Person, die das Chaos bearbeitet. Wir erfassen, was passiert, nicht, was das Prozessdokument behauptet. Die Arbeit lebt in den Ausnahmen, und die Kosten auch. Kandidaten werden jedes Mal gleich bewertet: eingesparte Zeit, Fehlerquote, Volumen, strategischer Wert, Umsetzungsrisiko. Das Letzte erledigt mehr gut aussehende Ideen als die anderen vier zusammen.

Bevor etwas gebaut wird, kommen Ausgangswert und Ziel schriftlich fest. Dieser Fall dauert heute drei Stunden. Wenn er zwanzig Minuten dauert und die Fehlerquote hält, ist das ein Erfolg? Eine eingeschränkte Antwort bedeutet: Wir sind noch nicht bereit zu bauen.

Bei einem Händler war der Rechnungsabgleich der Workflow, auf den alle zeigten. Der saubere Pfad war schon in Ordnung. Die Kosten steckten ausschließlich in den Rechnungen, die nicht durchgingen, wo eine einzige Abweichung tagelang auf die eine Person wartete, die die Lieferantenhistorie kannte und zufällig im Urlaub war. Wir haben den Ausnahmepfad neu gebaut und den sauberen Pfad in Ruhe gelassen. Bei drei weiteren Workflows auf der Liste haben wir empfohlen, sie ein Jahr lang nicht anzufassen.

Jedes System, das wir liefern, landet bei einem Team ohne Luft. Zu benennen, welche Workflows man in Ruhe lässt, ist die schwierigere Hälfte der Arbeit, und sie verdient das Recht, den Rest zu bauen.

Wir bauen auf dem auf, was schon da ist

Wir binden agentische Systeme an ERPs, CRMs, Dokumentenablagen und das gemeinsame Laufwerk, von dem alle so tun, als trüge es keine Last. Niemand, der Jahre gebraucht hat, um auf seinen heutigen Stack zu kommen, wird für ein KI-Projekt davon migrieren, und niemand sollte darum gebeten werden. Was wir nicht zulassen, ist, dass ein KI-Projekt heimlich zur Infrastrukturmigration wird, denn so verlieren Projekte im dritten Monat ihre Sponsoren.

Dieselben Bausteine tauchen jedes Mal auf. Ausnahme-Routing, Freigabeschritte, Kostenobergrenzen, Prüfpfade, Tests, die beweisen, dass sich ein Workflow richtig verhält, bevor er in den Betrieb geht. Beim ersten Mal bauen wir es für den Kunden, beim zweiten Mal zur Wiederverwendung, und ein drittes Mal schreiben wir es nicht von Grund auf neu. Nur Workflow-Logik und Anbindungen bleiben kundenspezifisch. Wer die Grundlagen bei jedem Projekt neu baut, erzeugt mit jeder Auslieferung dauerhafte Wartung, die niemand mit seinem Personal tragen kann.

Lesbarkeit ist eine Architekturanforderung

Wegen derer, die es hinterher pflegen, treffen wir Entscheidungen, die konservativ wirken. Weniger bewegliche Teile, selbst wo ein cleverer Entwurf existiert. Jede Entscheidung hinterlässt eine Spur, die ein Nicht-Engineer lesen kann. Kostenobergrenzen sind harte Grenzen, keine Warnungen. Alles Folgenreiche hält an und fragt einen Menschen. Nichts davon ist Vorsicht. Es ist das, was ein System am Leben hält, wenn wir weg sind.

Der Neuentwurf muss zwei Hürden zugleich nehmen: anders genug als der alte Prozess, damit der Ertrag echt ist, und nah genug, dass das Team seine eigene Arbeit darin noch wiedererkennt. Das Zweite haben wir teuer gelernt. Ein früher Bau übernahm mehr von einem Workflow, als das Team des Kunden zu beaufsichtigen bereit war, und innerhalb von Wochen wurde er stillschweigend umgangen. Nichts ist ausgefallen. Die Leute hörten auf, einem Ergebnis zu trauen, das sie nicht prüfen konnten, also prüften sie es trotzdem von Hand. Das System hat die ganze Zeit perfekt funktioniert, während es ignoriert wurde.

Die Übergabe ist die Lieferung

Wir sind nicht fertig, wenn das System funktioniert. Wir sind fertig, wenn es ohne uns funktioniert. Die Leute des Kunden bauen von der ersten Woche an mit, denn das Team, das zugesehen hat, wie ein System entsteht, ist das einzige, das es später verändern kann. Deshalb ist die letzte Strecke bewusst langweilig. Betriebshandbücher. Fehlerbilder in einfacher Sprache. Ihre Leute betreiben es, während wir zuschauen und still bleiben.

Was wir nicht gelöst haben, sind die Menschen. Der Sponsor wechselt. Der Generalist, den wir geschult haben, nimmt eine andere Stelle an. Dokumentation überlebt das. Urteilsvermögen nicht, und wir lernen noch, wie viel von unserem wir aufschreiben sollten.

Die Arbeit, die wir ablehnen

Wir lehnen Arbeit ab, die als zusätzliche Hände beschrieben wird. Eine Personallücke hat kein Ergebnis, also gibt es am Ende nichts zu beweisen und keinen Grund, das Ding am Laufen zu halten. Eine Frage klärt es: Wer auf Ihrer Seite arbeitet mit uns daran? Keine Antwort heißt: eine Personalanfrage im Gewand eines Projekts. Dem unbefristeten Rahmenvertrag geht es genauso. Ohne Enddatum gibt es keinen Zwang, und ein System, das nie auf eigenen Beinen stehen muss, lernt es auch nie.

Das Maß

Nichts davon ist exotisch. Es ist die unglamouröse Version von Forward Deployed Engineering, geprägt von Kunden, die nie eine Engineering-Abteilung betreiben wollten und damit auch nicht anfangen werden. Das Maß ist eines, das sie ohne uns prüfen können: Läuft es sechs Monate nach unserem Abschied noch, und können sie es verändern, ohne uns anzurufen?

Bringen Sie uns einen Workflow wie diesen

Festpreis, vereinbart bevor wir anfangen. Ein Senior Engineer antwortet innerhalb von zwei Werktagen.

Weiterlesen