Versionierung und Audit-Trail: Wer hat was geändert, wann und warum
Rexfin führt für das Modell eine hash-verkettete Versionshistorie und für Admin-Aktionen ein separates transaktionales Protokoll, damit Zahlen und Einstellungen jederzeit zurückverfolgbar bleiben.
Von The Rexfin team
Sobald mehr als eine Person an einem Modell arbeitet, tauchen zwei unterschiedliche Fragen auf. Erstens: Was hat sich an den Zahlen geändert, seit der Vorstand sie zuletzt gesehen hat? Zweitens: Wer hat die Einstellungen, Rollen und Einladungen des Workspace geändert, und wann? Rexfin führt für jede Frage eine eigene, dafür gebaute Spur, weil das Vermischen von „das Modell hat sich geändert” mit „eine Admin-Einstellung hat sich geändert” ein Protokoll ergibt, das niemand wirklich nutzen kann.
Modellversionen: Snapshot, Kette, Diff
Jeder bedeutsame Zustand eines Modells wird als Snapshot festgehalten – nicht einfach über die letzte Version gespeichert, sondern als unveränderliche Version erfasst und in einer Hash-Kette verankert, die spezifisch für dieses Deal oder Mandat ist. Jede neue Version verweist über einen verketteten Hash zurück auf die vorherige, sodass jeder die Abfolge unabhängig von Rexfin selbst überprüfen kann. Man muss dem Tool nicht einfach glauben, dass Version sechs wirklich aus Version fünf hervorgegangen ist; die Kette beweist es strukturell.
Der eigentlich nützliche Teil ist nicht der Snapshot, sondern das Diff. Version N im Vergleich zu Version N-1 zeigt exakt, welche Zeilen, Treiber oder Annahmen sich bewegt haben, um wie viel, und wem das zuzuschreiben ist. Dieses Diff speist die Zeile „was hat sich seit dem letzten Vorstandstermin geändert” im Vorstandsbericht. Es ist nicht die Erinnerung einer Person daran, was sie bearbeitet hat, sondern ein berechneter Vergleich zwischen zwei verketteten, unveränderlichen Zuständen.
Die Beförderung eines Entwurfsmodells zur veröffentlichten Version, die Vorstand oder Prüfer zu sehen bekommen, folgt derselben Disziplin: Die Beförderung wird vor ihrer Durchführung per Diff geprüft, die entstehende veröffentlichte Version wird wie jeder andere Snapshot in der Kette verankert, und sie lässt sich zurückrollen, falls etwas rückgängig gemacht werden muss. Ein veröffentlichtes Modell überschreibt den Entwurf nie stillschweigend; es ist ein geprüfter Schritt mit angehängtem Protokoll.
Admin-Aktionen: ein separates Protokoll auf Mandantenebene
Neben der Modellversionierung gibt es eine schlichtere Art von Audit-Trail: wer die eigenen Einstellungen des Workspace geändert hat. Präferenzänderungen, Compliance-Einstellungen wie Rechtsraum oder Geschäftsjahresende, Änderungen an Teamrollen sowie das Erstellen oder Widerrufen von Einladungen werden in dem Moment, in dem sie passieren, in ein Workspace-Audit-Log geschrieben.
Das Detail, das dieses Log verlässlich statt dekorativ macht: Die Audit-Zeile wird in derselben Datenbank-Transaktion geschrieben wie die Änderung selbst. Schlägt die Aktualisierung der Einstellung fehl, wird auch der Audit-Eintrag nie geschrieben – es kann also nie einen Log-Eintrag geben, der eine Änderung beschreibt, die gar nicht wirksam wurde, oder eine Änderung, die stattgefunden hat, ohne dass es dafür einen Nachweis gibt. Auch der „Vorher”-Wert in jedem Eintrag wird innerhalb derselben Transaktion gelesen, damit er nicht veraltet, wenn zwei Personen gleichzeitig Einstellungen bearbeiten.
Dieses Log liegt auf einer nur für Inhaber zugänglichen Aktivitätsseite, neueste Änderungen zuerst – genau damit ein Workspace-Inhaber Fragen wie „wer hat diese Person zum Team hinzugefügt” oder „wer hat unsere Geschäftsjahreseinstellung geändert” beantworten kann, ohne erst herumfragen zu müssen.
Warum diese Trennung sinnvoll ist
Ein Modell-Versions-Diff und ein Einstellungs-Audit-Log beantworten unterschiedliche Fragen für unterschiedliche Zielgruppen. Ein Vorstandsmitglied interessiert, ob sich die Treiberannahmen seit dem letzten Quartal geändert haben. Einen Workspace-Inhaber interessiert, ob jemand unerwartet mit Bearbeitungsrechten hinzugefügt wurde. Beides zu einem einzigen Feed zu verschmelzen würde das modellseitige Signal, das ein CFO braucht, unter routinemäßigem Admin-Rauschen begraben – und die Admin-Verantwortlichkeit unter Modelldetails, die außerhalb des Finanzteams niemand sehen will. Zwei disziplinierte, jeweils unveränderliche und zurechenbare Spuren zu führen bedeutet, dass jede für das Publikum nützlich bleibt, das sie tatsächlich liest.
Wo das einzuordnen ist
Die Versionierung untermauert die Versions-Diff-Zeile des Vorstandsberichts und gibt der Export-Schleuse etwas Konkretes zum Abgleichen: Ein Modell lässt sich nicht als final exportieren, wenn seine eigene Versionshistorie diese Behauptung nicht stützt. Zusammen mit der rollenbasierten Zugriffskontrolle macht der Audit-Trail aus „wir glauben zu wissen, wer das getan hat” ein „hier ist der Nachweis”.
Die vollständige Vertrauenskette zeigt die Rexfin-Produkttour.
Teil von Rexfin Product Tour: jede Zahl nachvollziehbar