Der Wert, den Sie fest verdrahtet und dann vergessen haben
Bei einem Audit fand ich eine Automatisierung, die Zahlungsausfälle zwei Jahre lang an das Postfach eines längst ausgeschiedenen Mitarbeiters meldete. Warum hartkodierte Werte in fast jeder gewachsenen Automatisierung stecken und wie Sie die gefährlichen zuerst herauslösen.
Die Meldung ging an ein Postfach, das seit zwei Jahren niemand las
Bei einem Audit im vergangenen Jahr stieß ich auf eine Automatisierung, die jede fehlgeschlagene Zahlung an eine feste E-Mail-Adresse meldete. Der Mitarbeiter hinter dieser Adresse hatte das Unternehmen zweiundzwanzig Monate zuvor verlassen. Sein Postfach lief technisch weiter, nur schaute niemand mehr hinein. Dort lagen, sauber nach Datum sortiert, rund achtzig gemeldete Zahlungsausfälle aus fast zwei Jahren. Der Workflow hatte die ganze Zeit getan, was in ihm stand. Irgendwann hatte ihm jemand eine konkrete Adresse ins Empfängerfeld getippt, und danach hatte diese Adresse niemand mehr angesehen.
Das nennt man einen hartkodierten Wert. Wenn ich mir eine über Jahre gewachsene Automatisierungslandschaft ansehe, finde ich solche Werte zu Dutzenden.
Was hartkodiert bedeutet und warum es so harmlos aussieht
Ein hartkodierter Wert ist eine Information, die direkt in einen einzelnen Schritt geschrieben wurde, statt an einer zentralen Stelle zu liegen. Die Empfängeradresse im Mail-Modul. Die Ordner-ID, in die ein Dokument abgelegt wird. Der Steuersatz von neunzehn Prozent, fest in eine Formel getippt. Die Grenze, ab der ein Auftrag als groß gilt, als nackte Zahl mitten in einer Bedingung.
Beim Bauen fühlt sich das richtig an. Sie brauchen eine Adresse, Sie tragen die Adresse ein, der Test läuft, alles grün. Der Wert stimmt ja auch, an diesem Tag, für diesen Fall. Genau das ist die Falle. Ein hartkodierter Wert ist nicht falsch, wenn Sie ihn setzen. Er wird falsch, wenn sich die Welt darum herum ändert und niemand mehr weiß, dass er dort steht.
Die vier Typen, die ich am häufigsten finde
Der erste Typ ist der Mensch. Eine feste E-Mail-Adresse, ein Name, eine Telefonnummer, ein Zuständiger. Menschen wechseln die Abteilung, gehen in Elternzeit, verlassen das Unternehmen. Der Workflow weiß davon nichts und schreibt weiter an ein totes Postfach.
Der zweite Typ ist die Kennung. Die ID eines Ordners, einer Tabelle, eines Datensatzes, einer Pipeline-Stufe. Diese Kennungen wirken stabil, bis jemand im Zielsystem aufräumt, eine Struktur neu anlegt oder ein Feld umbenennt. Dann zeigt die alte ID ins Leere, und die Automatisierung legt Daten an einer Stelle ab, die es nicht mehr gibt, oder bricht ohne erkennbaren Grund.
Der dritte Typ ist die Regel als Zahl. Ein Steuersatz, eine Preisschwelle, eine Frist, ein Rabatt. Der Steuersatz von heute ist nicht in Stein gemeißelt, und wenn der Gesetzgeber ihn ändert, sitzt die alte Zahl in fünf verschiedenen Workflows, jeder an einer anderen Stelle, keiner dokumentiert.
Der vierte Typ ist die Adresse einer Schnittstelle. Eine Test-URL, die es in Produktion geschafft hat. Ein Endpunkt, der auf ein System zeigt, das längst abgeschaltet wurde. Diese finde ich fast immer erst, wenn schon etwas schiefgelaufen ist.
Warum das Aufräumen so unangenehm ist
Das eigentliche Problem an hartkodierten Werten ist nicht der einzelne Wert. Es ist, dass Sie nicht wissen, wie viele es gibt und wo sie stehen. Ändert sich der Steuersatz, können Sie ihn nicht an einer Stelle nachziehen. Sie müssen jeden Workflow einzeln öffnen, jedes Modul durchsehen und hoffen, dass Sie keinen übersehen. Genau dieses Hoffen ist der Zustand, den Sie vermeiden wollen. Ein übersehener Wert produziert danach still falsche Zahlen, und still falsche Zahlen bemerkt man erst, wenn sie teuer geworden sind.
Wie wir es stattdessen bauen
Die Regel, die wir jedem Setup mitgeben, ist einfach. Jeder Wert, der sich ändern kann oder an mehr als einer Stelle gebraucht wird, gehört nicht in den Workflow, sondern an einen Ort, den der Workflow nachschlägt.
In der Praxis heißt das oft eine kleine Konfigurationstabelle, eine Datenbank oder ein Datastore im Automatisierungswerkzeug selbst. Dort steht: Empfänger für Zahlungsfehler ist diese Rolle, aktueller Steuersatz ist dieser, die Grenze für Großaufträge ist jene. Der Workflow fragt beim Lauf nach dem Wert, statt ihn in sich zu tragen. Ändert sich etwas, ändern Sie es an einer Stelle, und jeder Workflow zieht automatisch nach.
Der zweite Grundsatz betrifft Menschen. Schicken Sie Benachrichtigungen an Rollen, nicht an Personen. Nicht an t.berger persönlich, sondern an ein gepflegtes Funktionspostfach oder einen Verteiler, der aktualisiert wird, wenn jemand geht. Eine Rolle überlebt einen Personalwechsel. Eine private Adresse überlebt ihn nicht.
Der Test, den Sie heute machen können
Sie brauchen kein großes Projekt, um anzufangen. Nehmen Sie sich Ihre drei wichtigsten Automatisierungen vor und stellen Sie bei jedem festen Wert eine einzige Frage: Was passiert, wenn sich dieser Wert ändert und niemand denkt daran, ihn hier anzupassen? Bei den meisten Werten ist die Antwort harmlos. Bei einigen wird Ihnen kalt, und genau die gehören zuerst herausgelöst.
Der Mitarbeiter aus dem Beispiel hätte nie ein Problem sein müssen. Wäre die Meldung an eine Rolle statt an eine Person gegangen, wäre sein Weggang folgenlos geblieben. So aber lagen zwei Jahre unbearbeitete Zahlungsausfälle in einem Postfach, und niemand wusste es, weil der Wert, der sie dorthin schickte, tief in einem Workflow vergraben war, den seit dem Bau niemand mehr geöffnet hatte.
Wenn Sie wissen wollen, welche fest verdrahteten Werte in Ihren Automatisierungen schlummern und welche davon Sie im Ernstfall Geld kosten, schauen wir gern gemeinsam hin. In unserem kostenlosen Automations-Check gehen wir Ihre wichtigsten Workflows durch und zeigen Ihnen, wo ein vergessener Wert zur Falle werden kann.