Fachbeitrag · Wirtschaftsinformatik ·
Freigaben in automatisierten Prozessen: Warum die geprüfte Version mitentscheiden muss
Eine Person prüft einen Vorgang und klickt auf Freigeben. In der Zwischenzeit wurde der Vorgang jedoch geändert. Wenn das System nur die Zustimmung speichert, kann eine fachlich korrekte Prüfung plötzlich eine andere Datenfassung autorisieren. Dieses Problem entsteht besonders bei längeren Freigabezeiten, paralleler Bearbeitung und automatisierten Folgeaktionen. Eine belastbare Freigabe muss deshalb nachvollziehbar an genau den Zustand gebunden sein, den die prüfende Person tatsächlich gesehen hat.
Die zeitliche Lücke sichtbar machen
Zwischen dem Anzeigen eines Datensatzes und dem Ausführen einer Aktion liegt eine Zeitspanne. Währenddessen können andere Personen, Schnittstellen oder Hintergrundläufe dieselben Daten verändern. Eine technische Versionsnummer oder ein geeigneter Änderungsindikator ermöglicht einen Vergleich. Die Freigabe lautet dann nicht nur auf eine Vorgangskennung, sondern auf eine bestimmte Version dieses Vorgangs. Solche Bedingungen müssen beim Übergang in den freigegebenen Zustand verbindlich geprüft werden, nicht erst nach dem Versand einer Bestätigung.
Ein Beispiel mit einer Bestelländerung
Eine Bestellung über zwölf Geräte wartet auf interne Prüfung. Nach Öffnen der Prüfmaske ergänzt ein anderer Prozess weitere Positionen. Der angezeigte Gesamtumfang ist damit veraltet. Beim Freigeben vergleicht das System die geprüfte Version mit dem aktuellen Stand. Stimmen sie nicht überein, wird die Entscheidung nicht stillschweigend auf die neue Fassung übertragen. Stattdessen erscheinen die Änderungen zur erneuten Prüfung. Für rein beschreibende Ergänzungen kann eine andere Regel gelten als für Änderungen an Mengen, Empfängern oder Ausführungszielen.
Prüfung und Zustandswechsel zusammenführen
Der Versionsvergleich und das Setzen des Freigabestatus dürfen nicht wiederum durch eine ungeschützte Lücke getrennt sein. Technisch eignen sich bedingte Schreiboperationen, die nur bei passender Version ausgeführt werden. Auch nachgelagerte Aktionen benötigen eine stabile Freigabe- und Vorgangskennung, damit ein wiederholter Aufruf keine zweite Ausführung erzeugt. Das Protokoll hält fest, wer welche Version geprüft hat, welche Entscheidung getroffen wurde und welcher Folgeauftrag daraus entstanden ist. Es muss dafür keine geheimen Anmeldedaten enthalten.
Ausnahmen fachlich definieren
Nicht jede Datenänderung verlangt zwingend einen vollständigen Neustart der Prüfung. Das lässt sich aber nicht pauschal aus einem Zeitstempel ableiten. Fachlich relevante Felder und zulässige Nachträge werden ausdrücklich festgelegt und getestet. Die Prüffälle umfassen parallele Änderungen, abgelaufene Freigaben und wiederholt gesendete Entscheidungen. Eine menschliche Bestätigung ersetzt keine technische Zustandskontrolle. Umgekehrt kann eine Versionsprüfung nicht beurteilen, ob die inhaltliche Entscheidung richtig war. Beide Aufgaben ergänzen sich und brauchen jeweils eigene Verantwortung.
Technical insight · Business information systems ·
Approval in automated processes: Why the reviewed version must be part of the decision
A person reviews a request and selects Approve. In the meantime, however, the request has changed. If the system only records consent, a sound business review can unexpectedly authorise a different set of data. This is particularly relevant to long approval delays, concurrent editing and automated follow-up actions. A dependable approval must therefore be tied to the precise state that the reviewer actually saw.
Make the time gap explicit
Time passes between displaying a record and performing an action. During that period, other people, interfaces or background jobs can change the same information. A technical version number or suitable change indicator supports comparison. Approval then refers not just to a request identifier but to a particular version of that request. These conditions must be checked when the request moves into its approved state, rather than after a confirmation has already been sent.
An example involving an order change
An order for twelve devices is awaiting internal review. After the reviewer opens the screen, another process adds further items. The displayed scope is now outdated. When approval is submitted, the system compares the reviewed version with the current one. If they differ, the decision is not silently transferred to the new version. The changes are presented for renewed review instead. Purely descriptive additions may follow a different rule from changes to quantities, recipients or execution destinations.
Combine the check with the state transition
The version comparison and the approval update must not themselves be separated by another unprotected gap. Conditional writes can perform the update only when the expected version still matches. Follow-up actions also need stable approval and request identifiers so that repeating a call does not create a second execution. The record should show who reviewed which version, what decision was made and which subsequent task resulted. It does not need to contain authentication secrets.
Define exceptions in business terms
Not every change necessarily requires an entirely new review. However, this cannot be decided universally from a timestamp. Business-relevant fields and permissible later additions should be defined explicitly and tested. Test cases cover concurrent changes, expired approvals and repeatedly submitted decisions. Human approval cannot replace technical state control. Equally, a version check cannot determine whether the underlying business judgment was correct. The two responsibilities complement each other and need clearly assigned ownership.