Lohnt sich das? Automatisierungspotenzial erkennen

Worum es geht

Montag, 7.30 Uhr, Alpina Reisen AG in Chur. Bettina, Teamassistentin der Geschäftsleitung, öffnet drei Partnerportale, lädt die Buchungen der Vorwoche als CSV herunter, kopiert sie in eine Excel-Mappe, schlägt für jede Euro-Buchung den Wechselkurs nach, bildet Summen und schreibt der Geschäftsleitung eine Mail mit dem Wochenbericht. Um 10 Uhr ist sie fertig. Jede Woche. Und etwa einmal im Monat fragt der Geschäftsführer zurück, weil eine Zahl nicht stimmt.

Dario, Entwickler digitales Business im 2. Lehrjahr, soll diesen Ablauf im ÜK-Projekt automatisieren. Sein erster Impuls: Python öffnen und loslegen. Sein Berufsbildner bremst ihn: «Zeig mir zuerst, was das Skript bringt und was es nicht tun soll.»

Genau darum geht es in dieser Lektion. Bevor du eine einzige Zeile Code schreibst, klärst du drei Fragen:

1. Welche Schritte eines Ablaufs eignen sich überhaupt für ein Skript?
2. Wie viel Zeit und Geld spart die Automatisierung, und wann hat sie ihren Entwicklungsaufwand wieder eingespielt?
3. Ist ein Skript die richtige Lösung, oder wäre ein Low-Code-Werkzeug, eine Funktion im bestehenden System oder gar keine Automatisierung besser?

Wer diese Fragen mit Zahlen beantworten kann, überzeugt Vorgesetzte und Fachabteilungen. Und im Kompetenznachweis bringt genau diese Begründung viele Punkte.

Prozesse beobachten: messen statt raten

Frag nie «Wie lange dauert das ungefähr?». Die Antwort ist fast immer falsch, meistens zu tief. Setz dich stattdessen mit einer Stoppuhr neben die Person, die den Ablauf heute erledigt, und notiere jeden einzelnen Schritt. Das klingt aufwendig, dauert aber nur einen Durchlauf lang, und du lernst dabei Dinge, die in keiner Anleitung stehen.

So sehen Darios Notizen vom Montagmorgen aus:

Für jeden Schritt stellst du dir dieselben Fragen. Gut automatisierbar ist ein Schritt, wenn er drei Merkmale erfüllt:

• Häufig: Er kommt regelmässig vor, täglich, wöchentlich oder monatlich. Eine Aufgabe, die einmal im Jahr anfällt, lohnt sich selten.
• Regelbasiert: Man kann die Entscheidungen als klare Regeln aufschreiben («Wenn die Währung EUR ist, rechne mit dem Kurs des Buchungstags um»). Braucht ein Schritt Erfahrung oder Bauchgefühl, kann ihn ein Skript höchstens vorbereiten.
• Digital und strukturiert: Die Daten liegen als Datei, Tabelle oder über eine Schnittstelle vor. Papierbelege oder frei formulierte Mails sind schwierig.

Zusätzlich schaust du auf zwei Punkte, die den Nutzen erhöhen oder senken: Wie fehleranfällig ist die Handarbeit heute (Tippfehler, vergessene Zeilen)? Und wie stabil sind die Eingaben (ändert ein Portal alle paar Wochen sein Exportformat, wird das Skript oft angepasst werden müssen)?

Bei Schritt 5 erkennt Dario genau so einen Fall: Ob eine Buchung über CHF 9'000 ein Fehler oder eine echte Gruppenreise ist, weiss Bettina aus Erfahrung. Das Skript soll solche Buchungen deshalb nur markieren. Die Prüfung bleibt beim Menschen. Man nennt das Teilautomatisierung oder «Human in the Loop».

Nutzen in Stunden und Franken

Der Nutzen einer Automatisierung ist die Zeit, die nachher nicht mehr gebraucht wird, abzüglich der Zeit, die das Skript selbst kostet. Rechne in drei Schritten.

1. Aufwand heute pro Jahr

Aufwand pro Jahr = Dauer pro Durchlauf × Anzahl Durchläufe pro Jahr

Bei wöchentlichen Abläufen rechnest du realistisch mit etwa 50 Durchläufen (Feiertage und Betriebsferien fallen weg), bei monatlichen mit 12.

2. Aufwand nachher pro Jahr

Kaum eine Automatisierung bringt den Aufwand auf null. Es bleibt eine Restarbeit (Bericht kurz kontrollieren, markierte Fälle prüfen), und das Skript braucht Wartung: Ein Portal ändert sein Format, ein Passwort läuft ab, eine Bibliothek muss aktualisiert werden. Rechne für ein kleines Skript mit etwa einer Stunde Wartung pro Monat, wenn du keine besseren Zahlen hast.

3. Amortisation

Die Amortisationszeit sagt, nach wie vielen Monaten sich der Entwicklungsaufwand ausbezahlt hat:

Amortisation in Monaten = Entwicklungsaufwand ÷ Netto-Ersparnis pro Monat

Ein Beispiel aus einem anderen Betrieb: Die Controllerin einer Bäckereikette mit 12 Filialen braucht für den monatlichen Umsatzreport 2.5 Stunden. Das sind 2.5 × 12 = 30 Stunden pro Jahr oder 2.5 Stunden pro Monat. Die Entwicklung eines Skripts schätzt du auf 12 Stunden inklusive Tests. 12 ÷ 2.5 = 4.8, also ist die Automatisierung nach rund 5 Monaten amortisiert. Weil die Controllerin heute regelmässig Tippfehler korrigieren muss, kommt ein Nutzen dazu, der sich schwer in Stunden fassen lässt: Der Report stimmt.

Skript, Low-Code oder gar nicht?

Nicht jede lohnende Automatisierung ist ein Python-Skript. Als Entwickler/in digitales Business kennst du die Alternativen und wählst begründet.

Zwei Kriterien entscheiden oft mehr als die gesparte Zeit:

• Wartungsaufwand: Wer betreut die Lösung in zwei Jahren? Ein Python-Skript, das nur du verstehst, ist ein Risiko für den Betrieb. Ein Low-Code-Flow, den die Fachabteilung selbst anpassen kann, kann trotz geringerer Eleganz die bessere Wahl sein.
• Fehlerfolgen: Was passiert, wenn die Automatisierung still einen Fehler macht? Ein falscher interner Wochenbericht ist ärgerlich. Eine falsch ausgelöste Zahlung an Lieferanten ist teuer. Je höher die Fehlerfolgen, desto mehr Prüfung durch Menschen gehört in den Ablauf.

Schritt für Schritt: Dario rechnet den Montagsbericht durch

Dario rechnet mit seinen Notizen den Nutzen aus und hält das Ergebnis für das Gespräch mit dem Berufsbildner fest.

Schritt 1: Aufwand heute. 150 Minuten pro Montag, rund 50 Montage pro Jahr: 150 × 50 = 7'500 Minuten = 125 Stunden pro Jahr.

Schritt 2: Restaufwand nachher. Bettina prüft weiterhin die markierten Buchungen und liest den Bericht kurz gegen, geschätzt 20 Minuten pro Woche: 20 × 50 = 1'000 Minuten ≈ 16.7 Stunden pro Jahr.

Schritt 3: Wartung. Eine Stunde pro Monat: 12 Stunden pro Jahr.

Schritt 4: Netto-Ersparnis. 125 - 16.7 - 12 = 96.3 Stunden pro Jahr, also 96.3 ÷ 12 ≈ 8 Stunden pro Monat.

Schritt 5: Entwicklungsaufwand. Dario schätzt: Analyse und Entwurf 6 Std., Programmierung 18 Std., Tests mit Fehlerfällen 8 Std., Betrieb und README 4 Std. Total 36 Stunden.

Schritt 6: Amortisation. 36 ÷ 8.0 ≈ 4.5 Monate. Nach einem knappen halben Jahr hat das Skript seine Entwicklung eingespielt.

Schritt 7: Risiken nennen. Die Portale könnten ihr Exportformat ändern, die Wechselkurs-Schnittstelle könnte ausfallen. Deshalb plant Dario eine Formatprüfung und eine Fehlermeldung per Mail ein. Die Prüfung auffälliger Buchungen bleibt bei Bettina.

Damit er die Rechnung für andere Abläufe wiederverwenden kann, schreibt Dario sie gleich als kleines Python-Programm:

def aufwand_pro_jahr(minuten_pro_durchlauf, durchlaeufe_pro_jahr):
    """Aufwand in Stunden pro Jahr, auf eine Nachkommastelle gerundet."""
    return round(minuten_pro_durchlauf * durchlaeufe_pro_jahr / 60, 1)


def amortisation_monate(entwicklung_std, vorher_std_jahr, nachher_std_jahr, wartung_std_jahr):
    """Monate bis zur Amortisation oder None, wenn sich die Automatisierung nie lohnt."""
    ersparnis_pro_monat = (vorher_std_jahr - nachher_std_jahr - wartung_std_jahr) / 12
    if ersparnis_pro_monat <= 0:
        return None  # Skript kostet mehr Zeit, als es spart
    return round(entwicklung_std / ersparnis_pro_monat, 1)


vorher = aufwand_pro_jahr(150, 50)      # 125.0
nachher = aufwand_pro_jahr(20, 50)      # 16.7
monate = amortisation_monate(36, vorher, nachher, 12)
print(f"Aufwand heute: {vorher} Std./Jahr")
print(f"Amortisiert nach {monate} Monaten")   # 4.5

Jetzt bist du dran: Programmiere die Nutzenrechnung selbst. Das Labor prüft deine Funktionen automatisch.

Typische Fehler

• Schätzen statt messen. «Das dauert etwa eine Stunde» ist oft nur die Hälfte. Miss mindestens einen echten Durchlauf mit allen Unterbrechungen, dem Suchen nach Dateien und dem Nachfragen.
• Den Restaufwand vergessen. Kaum ein Ablauf fällt ganz weg. Wer mit null Stunden nachher rechnet, verspricht zu viel und verliert Glaubwürdigkeit, sobald jemand nachrechnet.
• Wartung ignorieren. Ein Skript ohne Wartungszeit in der Rechnung amortisiert sich nur auf dem Papier. Plane mindestens eine Stunde pro Monat ein.
• Alles automatisieren wollen. Schritte mit Ermessensentscheiden (ist diese Buchung echt?) gehören beim Menschen. Das Skript markiert, der Mensch entscheidet.
• Nur auf die Zeit schauen. Ein Ablauf mit hohen Fehlerfolgen oder ohne jemanden, der das Skript später betreut, kann trotz guter Amortisation die falsche Wahl sein.

Zusammenfassung

• Beobachte den Ablauf mit Stoppuhr und notiere jeden Schritt mit Dauer, Regelklarheit und Datenform.
• Gut automatisierbar ist, was häufig, regelbasiert und digital strukturiert ist. Schritte mit Ermessen werden höchstens vorbereitet.
• Nutzen = Aufwand heute - Restaufwand - Wartung, gerechnet in Stunden pro Jahr.
• Amortisation in Monaten = Entwicklungsaufwand ÷ Netto-Ersparnis pro Monat.
• Wähle begründet zwischen Systemfunktion, Low-Code, Skript und keiner Automatisierung. Wartbarkeit und Fehlerfolgen zählen mit.
• Nenne Risiken (Formatänderungen, Ausfälle) gleich mit und plane dagegen Prüfungen ein.