Field Note: Warum ich reproduzierbare Prozesse baue statt Einmal-Lösungen

Wenn sich eine Aufgabe wiederholt

Wenn ich etwas zum dritten Mal manuell mache, beginne ich darüber nachzudenken, ob daraus ein reproduzierbarer Prozess werden sollte. Nicht zwingend eine Automatisierung. Aber eine Arbeit, die ich nachvollziehen, wiederholen und überprüfen kann.

Der dritte Durchlauf ist für mich kein magischer Schwellenwert. Er ist ein Moment, in dem sich eine Frage aufdrängt: Wiederhole ich gerade nur dieselben Handgriffe – oder treffe ich jedes Mal dieselben Entscheidungen, ohne sie irgendwo festzuhalten?

Einmaliges Arbeiten darf improvisiert sein. Beim Wiederholen wird Improvisation teuer: Ich muss mich erneut erinnern, worauf es ankam, welche Ausnahme relevant war und woran ich erkenne, dass das Ergebnis stimmt. Dann geht es nicht mehr nur um Zeit. Es geht auch darum, ob ich später erklären kann, wie ein Ergebnis zustande gekommen ist.

Systematisieren ist nicht dasselbe wie automatisieren

Mein erster Impuls kann sein, eine wiederkehrende Aufgabe technisch zu lösen. Inzwischen versuche ich, diesen Impuls kurz zurückzustellen. Ein unklarer Ablauf wird durch Automatisierung nicht automatisch besser. Er wird zunächst nur schneller ausgeführt – und seine Unklarheiten wiederholen sich mit.

Bevor ich etwas automatisiere, muss ich verstehen, was hineinläuft, welche Entscheidungen unterwegs getroffen werden und woran ein brauchbares Ergebnis zu erkennen ist. Manchmal reicht es, diese Schritte und Zuständigkeiten sauber zu ordnen. Manchmal braucht es ein Datenmodell oder ein kleines spezialisiertes Werkzeug. Und manchmal ist eine Automation sinnvoll. Die Technik folgt für mich dem Verständnis des Prozesses, nicht umgekehrt.

Was ich zuerst prüfe: Kann ich den Ablauf beschreiben, ohne mich auf mein Gedächtnis zu verlassen? Sind Ausnahmen erkennbar? Und lässt sich am Ergebnis prüfen, ob der Prozess richtig gearbeitet hat?

Diese Fragen trennen eine wiederholbare Arbeitsweise von einer bloßen Abfolge automatisierter Handgriffe. Ein Prozess muss nicht vollständig ohne Menschen auskommen. Gerade bei Inhalten oder Daten kann ein klarer Prüf- und Freigabeschritt Teil der Lösung sein.

Wiederholbarkeit braucht einen Beleg

Für mich besteht ein reproduzierbarer Prozess nicht nur aus Eingabe und Ausgabe. Ich möchte auch wissen, was sich verändert hat und wie ich die Wirkung beurteilen kann. Darum arbeite ich bei meinen eigenen Engines nach dem Prinzip Know → Change → Prove: erst den Zustand erfassen, dann eine Änderung nach Vorschau und Freigabe ausführen und anschließend ihre Wirkung belegen.

Das ist keine Forderung, jeden kleinen Handgriff mit zusätzlicher Bürokratie zu versehen. Es ist eine Frage der Angemessenheit. Je stärker eine Änderung in ein bestehendes System eingreift, desto wichtiger wird es, ihren Ausgangspunkt und ihr Ergebnis nachvollziehen zu können. Eine Änderung, die sich nicht prüfen lässt, ist schwerer zu verantworten – und schwerer sicher zu wiederholen.

In der Engine Room Suite zeigt sich das auf unterschiedliche Weise. Die Link Engine bildet interne Verlinkungen als Graph ab und arbeitet mit begrenzten Linkkampagnen. Die Performance Engine überschreibt keine Originale, sodass Änderungen rücknehmbar bleiben. Die Static Engine erzeugt isolierte, versionierte und validierte Releases. Das sind verschiedene Werkzeuge, aber die Haltung dahinter ist ähnlich: Arbeit soll nicht nur ausgeführt, sondern kontrollierbar sein.

Aus einem Projekt: Bei der Migration von Garten 1x1 wurde WordPress-Inhalt mit einem einmaligen TypeScript-Skript aus einem WXR-Export in Markdown überführt. Die wiederholbare Struktur steckt hier nicht darin, dass jedes Mal dieselbe Migration ausgeführt werden muss. Sie steckt auch im Zielmodell: Content Collections mit Zod-Schema für unterschiedliche Inhaltstypen. Der einmalige Schritt und die systematische Struktur widersprechen sich nicht.

Wo der Prozess Teil des Produkts wird

Bei größeren digitalen Systemen ist Wiederholbarkeit nicht nur eine interne Arbeitserleichterung. Sie beeinflusst, ob Daten konsistent bleiben, ob Inhalte kontrolliert ergänzt werden können und ob ein System mit seinen Aufgaben wächst, statt bei jeder Erweiterung neu zusammengesetzt zu werden.

Wendewerk verbindet auf einer gemeinsamen WordPress-Plattform rund 17 eigene Plugins mit einem Datenmodell in ACF-Feldern. Dazu gehören unterschiedliche Rollen sowie Werkzeuge für Besucher. Bei der KI-gestützten Extraktion von Satzungstexten gibt es ein Staging und eine Prüfung, bevor Inhalte zusammengeführt werden. Für mich ist daran wichtig: Die Extraktion wird nicht als unsichtbarer Automatismus behandelt. Sie ist in einen Ablauf eingebettet, in dem ein Zwischenergebnis geprüft werden kann.

Ähnlich denke ich über Datenpipelines und Content-Workflows. Eine Folge von Schritten wird erst dann belastbar, wenn die Übergänge klar sind: Welche Daten kommen an? In welcher Form? Was wird daraus? Was darf veröffentlicht werden – und was braucht noch eine Freigabe? Die Antworten müssen nicht alle in einem großen System stecken. Manchmal ist eine kleine, klar abgegrenzte Lösung verständlicher und leichter zu betreiben als ein allgemeines Werkzeug, das viele Dinge zugleich verspricht.

Das heißt nicht, dass ich alles selbst bauen möchte. Es heißt, dass ich die Grenze zwischen Werkzeug und Prozess ernst nehme. Ein gekauftes System kann gut passen, wenn es den Ablauf tatsächlich abbildet. Wenn es wichtige Entscheidungen versteckt oder den Prozess unnötig verbiegt, löst ein weiterer Tool-Kauf das eigentliche Problem nicht.

Was sich bei mir verändert hat

Früher hätte ich eine wiederkehrende Aufgabe leichter als Anlass genommen, den nächsten technischen Schritt zu bauen. Heute frage ich zuerst, welche Teile überhaupt gleich bleiben und wo jedes Mal eine menschliche Entscheidung gebraucht wird. Damit wird auch sichtbar, was nicht automatisiert werden sollte.

Reproduzierbarkeit bedeutet für mich deshalb nicht, jede Abweichung auszuschließen. Sie bedeutet, dass der normale Ablauf verständlich ist, Änderungen nicht heimlich passieren und Abweichungen nicht mit dem Prozess verwechselt werden. Wenn ein Sonderfall auftaucht, kann ich ihn bewusst behandeln, statt ihn in eine unübersichtliche Ausnahme-Logik einzubauen.

Das hat eine praktische Konsequenz: Ich entwerfe Prozesse lieber in überschaubaren Schritten. Ein Schritt sollte eine erkennbare Aufgabe haben, ein Ergebnis liefern und – wenn es wichtig ist – überprüfbar sein. Daraus kann später Software werden. Es kann aber auch bei einer dokumentierten Arbeitsweise bleiben. Beides ist besser als eine Lösung, deren Funktionsweise nur noch die Person kennt, die sie einmal eingerichtet hat.

Meine Faustregel: Wenn ich etwas zum dritten Mal manuell mache, prüfe ich, ob es systematisiert werden sollte. Erst wenn ich den Ablauf verstanden und das Ergebnis überprüfbar gemacht habe, entscheide ich, ob Automatisierung wirklich hilft.

Weiterführend

• Know → Change → Prove: Wie WordPress-Änderungen sicher werden
• Field Note: Was eine gute Übergabe enthält
• Engine Room