Was 12 Jahre bei BMW mich über Prozessautomatisierung gelehrt haben

Der Moment, in dem es Klick gemacht hat

Es gab ein Meeting — eines von Hunderten, in einem Konferenzraum, der aussah wie jeder andere — in dem ein Projektteam einen Automatisierungs-Rollout präsentierte. Die Folien zeigten Durchsatzzahlen, Fehlerquoten und eine Timeline, die mit "Vollautomatisierung" in Grün endete. Alle nickten.

Drei Monate später machte das Team, das durch diese Automatisierung entlastet werden sollte, Überstunden. Nicht weil die Technologie versagt hatte. Sie funktionierte genau wie geplant. Das Problem war, dass sie für einen Prozess gebaut wurde, der so nicht existierte.

Der dokumentierte Prozess hatte zwölf Schritte. Der echte Prozess — der, dem tatsächliche Menschen mit tatsächlichen Daten von tatsächlichen Lieferanten folgten — hatte eher vierzig, je nachdem wen man fragte und welchen Sonderfall diese Person zuletzt erlebt hatte. Die Automatisierung bewältigte die zwölf Schritte einwandfrei. Die anderen achtundzwanzig brauchten weiterhin Menschen.

Das war nicht das erste Mal, dass ich dieses Muster sah. Aber es war das Mal, ab dem ich ernsthaft darüber nachdachte, warum es sich immer wiederholte.

Wie Enterprise-IT im großen Maßstab wirklich aussieht

Zwölf Jahre in der IT der BMW Group waren nicht glamourös. Ich sage das nicht aus Bescheidenheit, sondern weil es ein weitverbreitetes Missverständnis darüber gibt, was Enterprise-IT bedeutet — besonders in der Automobilindustrie, wo die Leute annehmen, das Interessante sei das Auto und alles andere sei Backoffice.

Die Realität: Enterprise-IT im großen Maßstab dreht sich um Zuverlässigkeit. Es geht darum sicherzustellen, dass Tausende von Prozessen jeden Tag korrekt über Hunderte von Systemen, Dutzende von Abteilungen und mehrere Länder hinweg laufen. Wenn es funktioniert, bemerkt es niemand. Wenn es ausfällt, bemerkt es jeder.

Die meiste Zeit habe ich nicht damit verbracht, neue Dinge zu bauen, sondern zu verstehen, warum bestehende Dinge so funktionierten, wie sie funktionierten. Warum braucht dieser Bericht drei Tage zur Erstellung? Weil er Daten aus sechs Systemen zieht, von denen zwei in unterschiedlichen Zyklen aktualisiert werden und eines einen manuellen Export erfordert, weil die API nie gebaut wurde. Warum läuft dieser Freigabe-Workflow über vier Personen? Weil vor zehn Jahren eine dieser Personen eine andere Rolle hatte und niemand den Prozess aktualisierte, als sie wechselte.

Das ist die Textur von Enterprise-IT. Schichten von Entscheidungen, die aus guten Gründen getroffen wurden, die nicht mehr gelten — zusammengehalten von Menschen, die die Workarounds gelernt und weitergegeben haben.

Die Product-Owner-Perspektive

Im späteren Teil meiner Zeit bei BMW arbeitete ich als Product Owner — die Rolle, die zwischen Geschäftsanforderungen und technischer Umsetzung sitzt. Das stellte sich als die wertvollste Position heraus, um zu verstehen, warum Automatisierungsprojekte gelingen oder scheitern.

Als Product Owner war es meine Aufgabe zu übersetzen. Fachbereiche beschrieben, was sie brauchten: "Dieser Prozess muss schneller werden." Technische Teams beschrieben, was sie bauen konnten: "Wir können diese Schritte automatisieren." Meine Aufgabe war herauszufinden, ob diese beiden Aussagen tatsächlich auf dasselbe zeigten.

Oft taten sie das nicht.

Die Fachbereiche beschrieben den Prozess, wie er funktionieren sollte. Das technische Team baute die Automatisierung für den beschriebenen Prozess. Und die Leute, die die Arbeit tatsächlich erledigten, hatten einen ganz anderen Prozess — einen, der durch Jahre der Auseinandersetzung mit der Lücke zwischen Design und Realität geformt wurde.

Die wertvollste Frage, die ich gelernt habe zu stellen, war: "Was passiert, wenn etwas schiefgeht?"

Nicht "was soll passieren" — das stand in der Dokumentation. Sondern was tatsächlich passiert. Wenn ein Lieferant die falsche Menge schickt. Wenn das System an einem Freitagnachmittag ausfällt. Wenn eine neue Vorschrift in Kraft tritt und noch niemand das Handbuch aktualisiert hat.

Die Antworten auf diese Fragen offenbarten den echten Prozess. Und der echte Prozess war immer komplexer, adaptiver und abhängiger von menschlichem Urteilsvermögen als alles in der Dokumentation.

Drei Muster, die sich ständig wiederholten

Über zwölf Jahre tauchten bestimmte Fehlermuster immer wieder auf. Sie waren nicht BMW-spezifisch — ich habe sie seitdem überall gesehen.

Muster 1: Die Illusion der sauberen Daten

Jedes Automatisierungsprojekt beginnt mit einem Proof of Concept. Der Proof of Concept nutzt Testdaten. Testdaten sind sauber.

Echte Daten sind es nicht. Lieferantennamen sind falsch geschrieben. Datumsangaben haben verschiedene Formate. Felder, die Pflichtfelder sein sollten, sind leer, weil jemand vor fünf Jahren einen Workaround gefunden hat. Referenznummern, die eindeutig sein sollten, sind es nicht, weil zwei Systeme sie unabhängig voneinander generieren.

Die Automatisierung, die mit Testdaten perfekt funktioniert, bricht innerhalb von Tagen an echten Daten zusammen. Nicht weil die Logik falsch ist, sondern weil die Annahmen über die Daten falsch waren.

Nach unserer Erfahrung sind Datenqualitätsprobleme für mehr gescheiterte Automatisierungsprojekte verantwortlich als jede technische Einschränkung. Die Modelle sind leistungsfähig. Die Daten sind das Problem.

Muster 2: Die siebenundvierzig undokumentierten Ausnahmen

Das hartnäckigste Muster. Ein Prozess sieht von außen einfach aus. Drei Schritte: empfangen, bearbeiten, weiterleiten. Aber die Person, die das seit acht Jahren macht, weiß, dass "bearbeiten" eigentlich bedeutet:

• Prüfen, ob der Lieferant auf der Vorzugsliste steht (wenn ja, andere Bearbeitung)
• Den Betrag anschauen (wenn über dem Schwellenwert, zusätzliche Freigabe)
• Die Währung prüfen (wenn nicht EUR, den internen Wechselkurs nachschlagen, der in einer Tabelle steht, nicht im System)
• Gegen den Vertrag abgleichen (aber nur wenn der Vertrag nach der neuen Richtlinie unterzeichnet wurde, sonst gelten die alten Konditionen)
• Prüfen, ob diese Kostenstelle noch Budget hat (aber das Budgetsystem wird nur monatlich aktualisiert, also muss man auch die informelle Tracking-Tabelle prüfen)

Jeder dieser "Teilschritte" hat eigene Ausnahmen. Die bearbeitende Person navigiert sie unbewusst — sie sind zur zweiten Natur geworden. Aber sie sind unsichtbar für jeden, der nicht von jemandem eingearbeitet wurde, der sie auf die gleiche Weise gelernt hat.

Wenn Sie den dokumentierten Drei-Schritte-Prozess automatisieren, bekommen Sie die dokumentierten Ergebnisse: Es funktioniert für Fälle, die den drei Schritten folgen. Alles andere — und das ist ein überraschend hoher Prozentsatz — fällt durch.

Muster 3: Die stille Rückkehr

Das traurigste Muster. Eine Automatisierung geht live. Es wird gefeiert. Metriken zeigen Adoption. Und dann, leise, über die folgenden Monate, beginnt das Team, drumherum zu arbeiten.

Sie stellen fest, dass die Automatisierung die Standardfälle bewältigt, aber für die Nicht-Standard-Fälle mehr Arbeit schafft — weil sie den Fall jetzt aus dem Automatisierungssystem herausnehmen, manuell bearbeiten und dann das Ergebnis wieder eingeben müssen. Das dauert länger, als ihn von Anfang an manuell zu bearbeiten.

Also beginnen sie mit Vorauswahl. Bevor ein Fall in die Automatisierung geht, schauen sie kurz drauf, ob er "automatisierungsfreundlich" ist. Die komplexen Fälle bearbeiten sie manuell, ohne es dem System mitzuteilen. Die Adoptionsmetriken sehen weiterhin gut aus, weil die einfachen Fälle durchfließen. Aber die Menschen erledigen die gleiche Arbeitsmenge — nur mit einem zusätzlichen Triage-Schritt.

Niemand meldet das, weil niemand die Person sein möchte, die sagt, das Projekt sei gescheitert. Die Automatisierung wird zum Feigenblatt über dem gleichen manuellen Prozess.

Warum ich ging, um etwas anderes zu bauen

Nach zwölf Jahren verstand ich das Problem klar. Automatisierungsprojekte scheitern nicht an schlechter Technologie, sondern an unzureichendem Prozessverständnis. Die Lücke zwischen dem dokumentierten und dem tatsächlichen Prozess ist dort, wo Wert verloren geht — und diese Lücke ist unsichtbar für jeden, der nicht gezielt danach sucht.

Ich verstand auch, dass die neue Generation von KI-Modellen — die großen Sprachmodelle, die unstrukturierte Informationen lesen, interpretieren und darüber nachdenken können — diese Lücke auf eine Weise schließen konnten, die frühere Automatisierungswerkzeuge nicht konnten.

Nicht durch mehr Regeln. Nicht durch ausgeklügeltere Skripte. Sondern durch echtes Verständnis: die Fähigkeit, ein Dokument so zu lesen, wie ein Mensch es liest, zu erkennen, dass zwei unterschiedlich formulierte Positionen sich auf dasselbe beziehen, zu bestimmen, was wahrscheinlich richtig ist und was eine menschliche Prüfung braucht.

Ich habe Jevolution gegründet, weil ich Automatisierung bauen wollte, die beim Prozess beginnt, nicht bei der Technologie. Automatisierung, die die 30% Ausnahmen bewältigt, die 80% der qualifizierten Arbeitszeit verbrauchen. Automatisierung, bei der der erste Schritt immer ist: verstehen, was tatsächlich passiert, nicht was passieren soll.

Was "Prozess zuerst, Technologie danach" in der Praxis bedeutet

Wenn wir ein Projekt beginnen, starten wir nicht mit einer Demo oder einem Architekturdiagramm. Wir starten mit Beobachtung.

Wir nehmen uns Zeit zu verstehen, wie Arbeit tatsächlich durch das Unternehmen fließt. Wir sprechen mit den Leuten, die die Arbeit machen — nicht nur den Managern, die sie beaufsichtigen. Wir kartieren die Ausnahmen, die Workarounds und die informellen Regeln.

Erst dann designen wir den Agenten. Und wir designen ihn für den realen Prozess — einschließlich der unordentlichen Teile. Der Agent weiß, dass Lieferant X immer Rechnungen in einem nicht-standardmäßigen Format schickt. Er weiß, dass Beträge unter einem bestimmten Schwellenwert beschleunigt werden können. Er weiß, welche Ausnahmen er bearbeiten kann und welche einen Menschen brauchen.

Das ist langsamer als eine Plattform zu verkaufen. Es skaliert nicht wie ein SaaS-Produkt. Aber es funktioniert — in dem Sinne, dass die Automatisierung tatsächlich die Fälle bearbeitet, die die Zeit Ihres Teams verbraucht haben, nicht nur die, die ohnehin einfach waren.

Die Erkenntnis

Zwölf Jahre in der Enterprise-IT haben mich gelehrt, dass die ausgefeilteste Technologie der Welt keinen Prozess automatisieren kann, den niemand richtig verstanden hat. Die Modelle sind leistungsfähig genug. Die Tools sind ausgereift genug. Der Engpass ist immer, immer die Lücke zwischen dem, wie wir denken, dass Arbeit abläuft, und wie sie tatsächlich abläuft.

In dieser Lücke arbeitet Jevolution. Nicht weil es technisch interessant ist (obwohl es das ist), sondern weil dort der Wert liegt — für das Unternehmen und für die Menschen, deren Expertise an Arbeit verschwendet wurde, die ein gut gestalteter Agent hätte übernehmen können.

Jedes Projekt beginnt mit der gleichen Frage: "Was passiert tatsächlich, wenn etwas schiefgeht?" Die Antworten sind immer interessanter, als die Dokumentation vermuten lässt.