Ein Kunde ruft an, ihm sei ein anderer Preis berechnet worden als im Auftrag. Du schaust auf die Rechnung — dort steht ein Rabatt, an den sich niemand erinnert. Du fragst das Team — drei Leute sagen „nicht ich". Das ERP zeigt den aktuellen Stand, sagt dir aber nicht, wer wann was geändert hat. Genau das fehlt den meisten ERP-Rollouts im KMU.
Die Änderungshistorie (Audit Trail, Änderungsprotokoll) ist eine Funktion, die jedes ernstzunehmende ERP hat — Comarch Optima, Comarch ERP XL, enova365, Subiekt (über Erweiterungen), Microsoft Dynamics — und die standardmäßig niemand einschaltet. Ergebnis: der Kunde reklamiert, jemand zahlt den Verlust aus der Marge, und drei Personen schieben sich gegenseitig die Schuld zu.
Was loggen, was nicht
Das Schlüsselwort ist „materiell". Du musst nicht alles protokollieren. Du brauchst Historie dort, wo eine Änderung Geld kostet oder Risiko schafft:
- Preislisten und Rabatte — wer hat einen Artikelpreis, einen Kundenrabatt, eine Aktion geändert.
- Kundenstammdaten — Zahlungsziele, Kreditlimits, Steuernummern.
- Verkaufsbelege — wer hat eine Rechnung nach der Ausstellung bearbeitet (wo das System es überhaupt zulässt).
- Lagerbestände — manuelle Mengenkorrekturen, Umbuchungen zwischen Lagern.
- Zahlungsdefinitionen — Bankkonten von Kunden, Zahlungsarten.
- Benutzerrechte — wer hat wem Zugriff auf welches Modul gegeben.
Du musst nicht jedes geöffnete Fenster protokollieren. Ein Log über jeden Klick ist eine Falle: die Datenmenge wächst in einem Tempo, das später niemand mehr durchsieht, und die Systemleistung fällt. Konzentrier dich darauf, was den Geschäftszustand ändert — nicht darauf, wer was angesehen hat.
Einmal einschalten und prüfen, dass es läuft
In Comarch Optima ist es ein Häkchen in der Programmkonfiguration — „Änderungskontrolle" pro Modul. In enova365 — „Datenänderungsregister", pro Objekt (Kunde, Preisliste, Beleg) zu aktivieren. In Dynamics — SQL Server Audit oder Change Tracking, vom Administrator konfiguriert. In Subiekt gibt es das nativ nicht; man braucht eine Erweiterung (z. B. Sfera plus eigene Datenbank-Trigger).
Zwei Dinge nach dem Einschalten prüfen:
- Mach eine Teständerung — ändere einen Produktpreis, prüfe, ob das Log ihn mit Benutzer und Zeitstempel zeigt.
- Prüfe, dass Nutzer das Log nicht löschen können — wenn ein Vertriebsmitarbeiter seinen eigenen Eintrag entfernen kann, ist das Log wertlos.
Das ist eine Sache von 30 Minuten. Der Trick ist nicht, es zu tun — sondern, dass es jemand wirklich tut, bevor es gebraucht wird.
Wer die Änderungshistorie wirklich nutzt
Nicht der Vorstand. Der Vorstand schaut einmal im Quartal rein, wenn die Marge komisch aussieht. Die Rollen, die den Audit Trail wirklich brauchen:
- Die Hauptbuchhalterin — wenn sie sucht, warum und von wem ein Beleg storniert wurde.
- Der Vertriebsleiter — wenn ein Kunde einen Preis reklamiert.
- Die für Stammdaten verantwortliche Person — wenn sie überwacht, dass niemand Preislisten außerhalb des vereinbarten Prozesses ändert.
- Der externe Prüfer — einmal im Jahr, bei der Jahresabschlussprüfung.
Wenn keine dieser Rollen weiß, dass das Log existiert — dann ist die Funktion da, aber effektiv nicht vorhanden. Setz einmal 15 Minuten für eine kleine Einweisung an: „wo klicken, um zu sehen, wer den Preis auf dieser Rechnung geändert hat".
Ein konkretes Beispiel
Bei einem unserer Kunden — ein Distributor technischer Ersatzteile (35 Personen, Comarch Optima) — bemerkte die Finanzleiterin einen Rückgang der Durchschnittsmarge um 2,7 Prozentpunkte in einem Monat. An der Preispolitik hatte sich nichts geändert. Analysten gingen drei Tage lang Produktkategorien, Kunden und Saisonalität durch — ohne Ergebnis.
Das Aktivieren der Änderungshistorie in der Preisliste (5 Minuten in der Konfiguration) und ein Vergleich mit demselben Monat ein Jahr zuvor lieferte die Antwort in 20 Minuten: eine neue Person im Vertrieb hatte beim Einlernen ins System den Gruppenrabatt „Strategische Kunden" von 8 % auf 18 % geändert. Die Änderung wirkte sofort für 140 Kunden. Fix: den alten Rabatt wiederherstellen und ein Vier-Augen-Gespräch mit der neuen Person darüber, dass das Feld „Gruppenrabatt" global gilt. Ohne das Log wäre das nie geklärt worden, und im nächsten Monat hätte jemand das Gleiche noch einmal gemacht.
Kosten der Aktivierung: eine halbe Stunde des ERP-Administrators. Kosten der Nicht-Aktivierung: rund 12 000 zł verlorener Marge und drei Tage, an denen zwei Personen ermittelten.
Was diese Woche zu tun ist
Konkrete Liste, insgesamt 60 Minuten:
- Frag den ERP-Administrator, ob die Änderungshistorie eingeschaltet ist und für welche Objekte.
- Wenn nicht — schalte sie mindestens ein für: Preislisten, Kundenstammdaten, Lagerkorrekturen.
- Mach eine Teständerung und prüfe, dass das Log sie aufgezeichnet hat.
- Setz 15 Minuten für eine Einweisung mit Hauptbuchhalterin und Vertriebsleiter an.
- Ergänze in deiner Prozedur „Preisreklamation" den Schritt: „Schau in die Änderungshistorie der Preislisten-Position".
Dafür brauchst du kein Projekt, kein Budget und keine Vorstandsfreigabe. Du brauchst einen Nachmittag.
Wann du uns anrufen solltest
Wenn dein ERP die Änderungshistorie nicht nativ hat (z. B. älterer Subiekt), oder wenn sie aktiviert ist, aber es keine vernünftige Möglichkeit gibt, sie durchzusehen (das SQL-Server-Log existiert, aber niemand öffnet es) — dann ist das eine typische Aufgabe von wenigen Stunden: eine kleine Erweiterung oder ein einfaches Web-Panel, das der Buchhalterin das zeigt, was sie sucht, ohne dass sie sich in die Datenbank einloggen muss. Kein großes Projekt — eine konkrete Sache, die man in einer Woche erledigt.
Ohne Änderungshistorie endet jedes „wer hat das geändert?!" ohne Antwort. Mit ihr — in 20 Minuten.