Prozessautomatisierung im Engineering: Welche Prozesse sich lohnen – und welche man besser nicht automatisiert

Ich automatisiere seit Jahren Prozesse in der Konzern-Vorentwicklung. Nicht weil es mein Auftrag war, sondern weil mich wiederkehrende Handarbeit stört. Aus dieser Zeit sind Werkzeuge entstanden, die heute täglich laufen – und andere, die nach drei Wochen niemand mehr angefasst hat.

Der Unterschied lag nie in der Technik. Er lag in der Entscheidung davor.

Das eigentliche Problem ist nicht der Aufwand, sondern die Frage

Die meisten Automatisierungsprojekte beginnen mit dem Satz: „Das machen wir jede Woche von Hand, das muss doch automatisch gehen." Das stimmt fast immer. Es ist trotzdem der falsche Ausgangspunkt.

Denn dass etwas automatisierbar ist, sagt nichts darüber aus, ob es automatisiert werden sollte. Ein Prozess, der jede Woche zwanzig Minuten kostet, aber alle drei Monate seine Eingangsdaten ändert, ist ein Wartungsfall – kein Effizienzgewinn. Ein Prozess, der nur eine Person betrifft, die ihn ohnehin im Kopf hat, gewinnt durch ein Tool wenig. Und ein Prozess, den niemand richtig beschreiben kann, wird durch Automatisierung nicht klarer, sondern nur schneller falsch.

Die ehrliche Rechnung

Automatisierung hat drei Kostenblöcke, von denen in der Regel nur der erste betrachtet wird:

• Erstellung. Der sichtbare Aufwand. Skript schreiben, Tool aufsetzen, Schnittstellen anbinden. Wird meist realistisch geschätzt – und dann trotzdem um den Faktor zwei überschritten, weil die Sonderfälle erst beim Bauen auftauchen.
• Pflege. Der unsichtbare Aufwand. Jede Änderung an Eingangsdaten, Dateiformaten, Freigabeprozessen oder IT-Umgebung trifft die Automatisierung. Wer sie gebaut hat, muss sie nachziehen – oder sie stirbt leise.
• Vertrauen. Der unterschätzte Aufwand. Ein automatisiertes Ergebnis wird nur genutzt, wenn die Anwender ihm glauben. Das braucht Nachvollziehbarkeit, Plausibilitätsprüfungen und in der Anfangsphase Doppelarbeit: manuell und automatisch parallel, bis das Vertrauen da ist.

Wer nur den ersten Block rechnet, kommt fast immer zu dem Schluss, dass sich Automatisierung lohnt. Wer alle drei rechnet, wird deutlich selektiver – und trifft die besseren Entscheidungen.

Vier Kriterien, die ich vor jeder Automatisierung prüfe

1. Frequenz und Stabilität. Ein Prozess muss regelmäßig laufen und stabile Eingangsgrößen haben. Hohe Frequenz allein reicht nicht. Ein täglicher Export, dessen Quelltabelle monatlich umgebaut wird, erzeugt mehr Pflege als Nutzen. Faustregel aus der Praxis: Wenn sich Datenstruktur oder Ablauf öfter als einmal pro Quartal ändern, zuerst den Prozess stabilisieren – dann automatisieren.

2. Beschreibbarkeit. Kann der Prozess so beschrieben werden, dass eine fachfremde Person ihn nach Anleitung durchführen könnte? Wenn nein, ist er nicht reif für Automatisierung. Das ist der häufigste Grund, warum Automatisierungsprojekte im Engineering scheitern: Der Prozess existiert nur im Kopf der Person, die ihn seit Jahren macht – inklusive aller Ausnahmen, die sie längst nicht mehr als Ausnahmen wahrnimmt.

3. Fehlerkosten. Was passiert, wenn die Automatisierung ein falsches Ergebnis liefert – und niemand es merkt? Bei einer Wochenübersicht für das Team: ärgerlich. Bei einer Bewertung, die in eine Freigabe einfließt: teuer. Je höher die Fehlerkosten, desto mehr Aufwand muss in Plausibilitätsprüfung und Nachvollziehbarkeit fließen. Manchmal frisst genau das den gesamten Effizienzgewinn auf.

4. Anzahl der Nutzer. Ein Werkzeug, das eine Person entlastet, konkurriert mit der Alternative, dass diese Person den Prozess einfach weiter macht. Ein Werkzeug, das zehn Personen denselben Handgriff erspart, hat eine völlig andere Rechnung. Und es hat noch einen Effekt: Es standardisiert. Zehn Personen, die dieselbe Auswertung mit demselben Tool machen, produzieren vergleichbare Ergebnisse. Das ist oft der größere Gewinn als die eingesparte Zeit.

Wann Automatisierung hilft – und wann nicht

• Automatisierung hilft: bei wiederkehrenden Auswertungen mit stabiler Datenbasis. Bei Berichten, die aus mehreren Quellen zusammengeführt werden müssen. Bei Prüfungen gegen Regelwerke, die sich selten ändern. Bei allem, was mehrere Personen gleich machen sollten, aber jeder anders macht.
• Automatisierung hilft nicht: bei Prozessen, die noch nicht verstanden sind. Bei Einmalaufgaben, die nur nach Wiederholung aussehen. Bei Abläufen, deren Wert im Gespräch liegt – ein Review, das automatisiert wird, ist kein Review mehr. Und bei Prozessen, deren eigentliches Problem nicht der Aufwand ist, sondern die fehlende Entscheidung dahinter.

Der letzte Punkt ist der wichtigste. Ich habe mehr als einmal erlebt, dass ein Team einen Prozess automatisieren wollte, der eigentlich abgeschafft gehörte. Automatisierung war der Weg, eine unangenehme Diskussion zu vermeiden. Das Tool lief dann – und produzierte effizient etwas, das niemand brauchte.

Die typischen Fehlentscheidungen

„Das Makro läuft doch." Ein Werkzeug, das nur eine Person versteht, ist kein Prozess, sondern ein Risiko. Sobald diese Person das Team wechselt, steht der Prozess still – und niemand kann ihn manuell nachvollziehen, weil das Wissen im Code steckt. Ob die Lösung dann Excel bleibt oder ein anderes Werkzeug wird, habe ich hier eingeordnet: Excel-Automatisierung vs. Power BI.

„Wir bauen das gleich richtig." Die vollständige Lösung mit Oberfläche, Datenbank und Rechtekonzept für einen Prozess, der noch nie stabil gelaufen ist. Erst das kleine Skript, das den Kern automatisiert. Wenn es drei Monate gebraucht wird, ist die Erweiterung gerechtfertigt. Wenn nicht, hat man drei Tage statt drei Monate verloren.

„Der Berater macht das." Externe Unterstützung ist sinnvoll für Methodik, Architektur und den kritischen Blick auf die vier Kriterien. Sie ist nicht sinnvoll als Dauerbetreiber. Ein Werkzeug, das nur der Externe pflegen kann, ist eine Abhängigkeit – keine Effizienz. Die Frage, was intern bleiben muss und was extern sinnvoll ist, folgt derselben Logik wie beim Aufbau von Simulationskompetenz: Frequenz, Kompetenz, Abhängigkeit.

Was das für die Praxis bedeutet

Prozessautomatisierung ist eine Entscheidung, keine Technik. Die Werkzeuge sind heute verfügbar und günstig – Python, Power Automate, Low-Code-Plattformen, zunehmend KI-gestützte Assistenten. Der Engpass liegt nicht mehr in der Umsetzung. Er liegt in der Auswahl.

Wer die vier Kriterien ehrlich durchgeht, wird bei etwa der Hälfte der Kandidaten zu dem Schluss kommen, dass Automatisierung nicht die Antwort ist. Das ist kein schlechtes Ergebnis. Es ist der Grund, warum die andere Hälfte dann tatsächlich läuft – und nach einem Jahr noch genutzt wird.

Genau das ist der Ansatz meiner Prozessautomatisierung für Engineering-Teams: Nicht zuerst bauen, sondern zuerst entscheiden. Der Prozess wird beschrieben, die Kosten werden ehrlich gerechnet, die Kriterien geprüft – und erst dann wird umgesetzt. Manchmal ist das Ergebnis ein Werkzeug. Manchmal ein klar beschriebener Prozess ohne Werkzeug. Und manchmal die Erkenntnis, dass die eigentliche Frage eine methodische war, keine technische.