Automatisierung im Betrieb: wann eine Regel NICHT starten darf
Vier Schritte für eine Regel, die nichts kaputt macht: Ereignis, Bedingungen, Aktionen, Trockenlauf. Und warum ein übersprungener Lauf kein Fehler ist.
Die meisten Texte über Automatisierung erklären, was eine Regel alles auslösen kann. Die schwierige Frage ist eine andere: wann sie besser nichts tun soll. Eine Regel, die zu oft feuert, schreibt Kunden an, die nichts erwarten, und nach zwei Wochen schaltet sie jemand ab. Dieser Text zeigt den Aufbau, der das verhindert, und wie man hinterher erkennt, ob eine Regel arbeitet oder nur so aussieht.
Eine Regel besteht aus vier Teilen
Der Name. Der Teil, den man am ehesten unterschätzt. In sechs Monaten steht er in einer Liste mit zwanzig anderen, und wer ihn dann liest, muss ohne Nachdenken wissen, was die Regel tut. „Benachrichtigung 3“ weiß es nicht.
Das Ereignis. Eine Regel wartet nicht auf eine Uhrzeit, sondern auf etwas, das im Betrieb passiert: ein Datensatz wird angelegt, geändert oder gelöscht. Dazu gehört, in welchem Modul und in welcher Tabelle: „ein Ticket entsteht“ ist etwas anderes als „ein Angebot ändert sich“.
Die Bedingungen. Der eigentliche Kern, und der Teil, den man am liebsten überspringt. Ohne Bedingung läuft die Regel bei jedem Ereignis. Mit „Priorität gleich hoch“ läuft sie bei den Tickets, um die es geht. Der Unterschied zwischen einer nützlichen Automatisierung und einer, die abgeschaltet wird, liegt fast immer hier.
Die Aktionen. Was danach geschieht: eine E-Mail, ein Hinweis an das Team, eine WhatsApp-Nachricht, eine Aufgabe, ein aktualisiertes Feld, ein Eintrag in der Historie. Mehrere hintereinander sind erlaubt.
Vor dem Aktivieren: der Trockenlauf
Bevor eine Regel scharf geschaltet wird, gehört sie einmal leer geprüft. Ein Trockenlauf wertet die Bedingungen aus und sagt, ob sie erfüllt gewesen wären und wie viele Aktionen gelaufen wären — ohne dass jemand etwas bekommt. Das ist der Knopf, der die Angst vor dem Einschalten nimmt, und der einzige seriöse Weg, eine Regel zu testen, die E-Mails an echte Kunden schickt.
Warum „übersprungen“ kein Fehler ist
Nach ein paar Tagen ist die interessanteste Frage nicht, ob die Regel aktiv ist, sondern was sie tatsächlich getan hat. Dafür braucht es ein Protokoll, und dieses Protokoll muss drei Ausgänge auseinanderhalten:
- Erfolgreich — die Arbeit ist getan: die E-Mail ist raus, der Hinweis kam an.
- Übersprungen — das Ereignis war da, aber die Bedingung war nicht erfüllt, oder dem Datensatz fehlte schlicht die Angabe (ein am Telefon aufgenommenes Ticket ohne E-Mail-Adresse des Kunden). Die Regel sollte hier gar nicht laufen.
- Fehler — etwas ist schiefgegangen, und der Grund steht dabei: kein Empfänger hinterlegt, falsche Zugangsdaten, ein Feld, das eine Automatisierung nicht ändern darf.
Viele Systeme kennen nur „gelaufen“ und „fehlgeschlagen“. Die Folge: Das Protokoll einer völlig gesunden Regel füllt sich mit roten Zeilen, weil bei zwanzig Tickets die Bedingung nicht erfüllt war — und der eine echte Fehler dazwischen fällt niemandem mehr auf. Wer eine Software prüft, sollte genau danach fragen: Wird eine nicht erfüllte Bedingung als Entscheidung gezeigt oder als Defekt?
Was eine Automatisierung nicht anfassen sollte
Eine Regel, die jedes Feld überschreiben darf, ist ein Risiko, kein Werkzeug. Sinnvoll ist eine feste Liste beschreibbarer Felder: Status, Zuständigkeit, Priorität, ein Vermerk. Summen, Bestände, Buchhaltungswerte und Schlüssel gehören nicht dazu — die ändert ein Mensch, oder ein Vorgang mit Beleg dahinter.
Genauso wichtig: Eine Regel, die selbst schreibt, darf sich nicht selbst auslösen. Ohne Bremse ruft sich eine Automatisierung, die ein Feld aktualisiert, in einer Schleife endlos auf.
Der Ansatz von Blina Desk
In Blina Desk werden die vier Schritte in einer Maske ausgefüllt, in dieser Reihenfolge, mit dem Trockenlauf am Ende. Die Aktionen sind eine feste Liste statt eines offenen Zugriffs auf die Datenbank, und die aktualisierbaren Felder stehen fest.
Das Protokoll trennt erfolgreich, übersprungen und Fehler, mit dem Grund im Klartext — so sieht man auf einen Blick, ob eine Regel nicht arbeitet oder schlicht nicht musste. Und weil Automatisierungen dem Betrieb gehören und nicht der einzelnen Person, entscheidet die Unternehmensleitung, welche Regeln aktiv sind und wer sie anpassen darf.
Der Test für jede Automatisierungssoftware ist am Ende derselbe: Nicht wie viele Vorlagen sie mitbringt, sondern ob Sie nach zwei Monaten noch nachvollziehen können, warum eine Regel an einem Dienstagmorgen nicht gelaufen ist.