Wenn der Workflow die Technische Redaktion ausbremst

Automatisierung soll eigentlich beschleunigen. Prozesse laufen im Hintergrund, die Redaktion kann sich auf ihre eigentliche Arbeit konzentrieren, lästige Routinetätigkeiten erledigen sich quasi von selbst. So die Theorie. In der Praxis erleben wir manchmal das Gegenteil: Ein Workflow, der gut gemeint war, bremst plötzlich die Technische Redaktion aus, statt sie zu entlasten.

Ein Projekt bleibt mir dabei besonders in Erinnerung. Ein Abgleich zwischen Redaktionssystem und Dokumentenmanagementsystem, der eigentlich Arbeit abnehmen sollte, hat stattdessen die Clients im gesamten Team einfrieren lassen – für einen kompletten Arbeitstag. Wie es dazu kam und wie wir das Problem beheben konnten, erzähle ich hier.

Technisch korrekt, aber langsam

In vielen Technischen Redaktionen reicht es nicht, nur die eigentliche Anleitung zu pflegen. Zusätzlich müssen oft zahlreiche Dokumente referenziert werden, etwa Zertifikate oder Sicherheitsdatenblätter. Diese Dokumente liegen typischerweise in einem eDMS (elektronisches Dokumentenmanagementsystem) und werden von dort aus im Redaktionssystem verlinkt. In der Praxis zeigt sich oft: Ohne einheitliche Schreibweisen und ohne Prüfung, ob ein referenziertes Dokument überhaupt noch verfügbar ist, entstehen Inkonsistenzen.

Unser Kunde hatte diese Herausforderung bereits erkannt und schon bei der Einführung seines Redaktionssystems SCHEMA ST4 einen Workflow bauen lassen, der die Verlinkung automatisiert hat. Ein guter erster Schritt.

Das eigentliche Problem lag woanders: Die Dokumente im eDMS enthalten Metadaten, die auch für die Inhaltserstellung im CCMS wertvoll sind – etwa für die Zuordnung zu Taxonomien. Also wurde der bestehende Workflow so erweitert, dass er diese Metadaten ausliest und auf entsprechende Datenknoten im System mappt. Fachlich eine saubere Lösung. Nur leider eine, die kaum praktikabel war, wie sich herausstellte.

Bei rund 1000 Datenknoten hat ein vollständiger Abgleich mit dem eDMS etwa 24 Stunden gedauert. Das allein ist schon schlimm genug. Richtig problematisch wurde es dadurch, dass der Vorgang extrem ressourcenintensiv war: Während der Workflow lief, sind bei den Redakteur:innen die Clients eingefroren. Parallel im System zu arbeiten? Praktisch unmöglich.

Workflows arbeiten anders als Menschen

Woran lag das? Bei unserer Analyse hat sich gezeigt, dass die Ablauflogik des Workflows im Grunde menschliches Vorgehen nachgebildet hat: einen Datenknoten nach dem anderen abarbeiten, Taxonomie mappen, weiter zum nächsten. Für eine Person am Schreibtisch ist das ein gangbarer Weg. Für eine Maschine, die potenziell tausende Vorgänge parallel verarbeiten könnte, ist es das genaue Gegenteil von effizient.

Diese Beobachtung ist übrigens kein Einzelfall. Immer wieder sehen wir bei Digitalisierungsprojekten in der Technischen Redaktion, dass automatisierte Prozesse zwar funktionieren, aber schlicht die Denkweise sequenzieller, manueller Arbeit übernehmen, statt die Möglichkeiten der Systeme wirklich auszuschöpfen. Ein Workflow, der wie ein Mensch arbeitet, ist in der Geschwindigkeit immer limitiert.

Wie schnell kann ein Workflow werden?

Der entscheidende Hebel war, den Prozess von Grund auf neu zu denken, statt ihn nur zu optimieren. Statt Datenknoten einzeln und nacheinander zu bearbeiten, haben wir die Aufgabe parallelisiert und als Batchjob umgesetzt. Zusätzlich hat sich gezeigt, dass sich die zugrunde liegende Abfrage über die erweiterte Suchfunktion des Systems deutlich performanter lösen lässt als über den bisher genutzten ST-Path-Ansatz.

Das Ergebnis hat selbst uns überrascht: Aus 24 Stunden Laufzeit wurden 90 Sekunden. Kein Tippfehler – anderthalb Minuten. Ein Abgleich, der früher den kompletten Arbeitstag der Technischen Redaktion lahmgelegt hat, lässt sich heute kurz vor Feierabend nebenbei anstoßen, ohne dass jemand überhaupt etwas davon mitbekommt.

Automatisierung ist nicht automatisch besser

Was diesen Fall aus unserer Sicht besonders macht: Die Lösung lag nicht in mehr Rechenleistung oder einer neuen Softwarelizenz, sondern in einer anderen Herangehensweise an ein bestehendes Problem. Genau solche Stellschrauben zu finden, ist oft der Unterschied zwischen einem Workflow, der auf dem Papier gut aussieht, und einem, der die Technische Redaktion wirklich unterstützt.

Dieses Beispiel zeigt gut, dass Automatisierung allein noch keine gute Lösung garantiert. Entscheidend ist, wie ein Prozess intern aufgebaut ist – und ob er die Stärken des jeweiligen Systems tatsächlich nutzt. Ein Workflow, der zwar Arbeit abnimmt, dabei aber ganze Teams für Stunden ausbremst, hat sein Ziel nur halb erreicht.

Wenn Sie in Ihrer eigenen Redaktion ähnliche Erfahrungen mit trägen Workflows oder Systemintegrationen gemacht haben: Wie sind Sie damit umgegangen? Wir freuen uns über den Austausch – schreiben Sie uns gerne, welche Stolpersteine Ihnen bei der Automatisierung Ihrer Redaktionsprozesse begegnet sind.