Wann sich das Automatisieren von Rechenläufen lohnt, und wann nicht

Eine Parameterstudie mit vierzig Varianten läuft über Nacht. Am nächsten Morgen sind achtunddreißig durch, zwei sind abgestürzt, und niemand weiß warum. Also startet man die zwei neu, wartet wieder, und am Nachmittag beginnt die Auswertung, die von Hand zwei Stunden dauert.

Das ist der Zustand, den Automatisierung ändern soll. Sie tut es nicht immer, und die Frage, wann sie es tut, wird selten gestellt.

Die Rechnung, die vorher fällig ist

Automatisierung kostet einmal Zeit und spart danach jedes Mal. Dafür braucht man drei Zahlen: wie lange der Vorgang von Hand dauert, ehrlich gemessen statt geschätzt; wie oft im Jahr er läuft; und wie lange es dauert, ihn zu automatisieren.

Der Fehler steckt meistens in der ersten Zahl. Gefühlt dauert die Auswertung zwanzig Minuten. Gemessen sind es fünfzig, weil das Suchen der Dateien, das Öffnen der Vorlage und das dreimalige Nachrechnen mitzählen.

Der zweite Fehler steckt in der dritten. Ein Skript, das den Normalfall abdeckt, ist an einem Tag geschrieben. Eines, das auch mit einem abgestürzten Lauf umgeht, mit einer halb geschriebenen Datei und mit dem Kollegen, der die Ordnerstruktur anders benennt, braucht eine Woche.

Was zuerst automatisiert gehört: nicht der Lauf, die Auswertung

Ein Rechenlauf läuft ohnehin allein, sobald er gestartet ist. Was Zeit frisst, ist das, was davor und danach passiert: Varianten aufsetzen, Ergebnisse einsammeln, Kennwerte herausziehen, in eine vergleichbare Form bringen.

[BELEG NÖTIG: konkretes Beispiel aus einem eigenen Projekt. Welches Werkzeug, welche Art von Lauf, wie viele Varianten, was vorher wie lange dauerte und was danach.]

Der Punkt, an dem die meisten Skripte scheitern

Ein Skript, das vierzig Läufe startet, muss wissen, was zu tun ist, wenn Lauf siebzehn abstürzt. Die drei Möglichkeiten sind abbrechen, überspringen, wiederholen. Alle drei sind in bestimmten Fällen richtig, und die Entscheidung gehört in eine Konfiguration, nicht fest ins Skript.

Wichtiger noch: Ein abgestürzter Lauf muss erkennbar abgestürzt sein. Ein Solver, der eine unvollständige Ergebnisdatei hinterlässt, sieht für ein naives Skript aus wie ein erfolgreicher Lauf. Die Auswertung liest dann Zahlen, die nichts bedeuten, und niemand merkt es, weil die Zahlen plausibel aussehen.

Die Prüfung gehört deshalb vor die Auswertung: Ist die Datei vollständig, steht die Abschlussmeldung des Solvers darin, stimmt die Anzahl der Zeitschritte.

Drei Fälle, in denen man es lassen sollte

Der Vorgang läuft zweimal im Jahr. Dann ist die eingesparte Zeit kleiner als die Pflege. Skripte veralten: Der Solver bekommt eine neue Version, das Ausgabeformat ändert sich, und dann sitzt man an einem Skript, das man seit acht Monaten nicht angefasst hat.

Der Vorgang ändert sich jedes Mal. Automatisieren lohnt für Wiederholung, nicht für Ähnlichkeit.

Niemand außer einem versteht das Skript. Dann ist es keine Automatisierung, sondern eine Abhängigkeit. Das gilt besonders in Instituten mit wechselnden Bearbeitern.

Was daraus folgt

Der häufigste Fehler ist nicht, zu wenig zu automatisieren. Er ist, etwas zu automatisieren, das man danach dreimal im Jahr braucht und jedes Mal reparieren muss.