Was wirklich in die Produktion kam, und wer es erlaubt hat.
SAP-Change-Management zu prüfen heißt, für jede Änderung vier Fragen zu beantworten. Wurde sie beantragt? Hat ein Berechtigter sie freigegeben? Entspricht das Ausgelieferte dem Genehmigten? Und hat sie etwas Finanzrelevantes berührt? Die meisten Prüfungsansätze prüfen Dokumente. Der verlässliche Ansatz korreliert Systeme, denn die Dokumente schreiben die Geprüften selbst.
Das Nachweis-Dreieck.
Drei unabhängige Aufzeichnungssysteme beschreiben jede SAP-Änderung. Das Transportprotokoll zeigt, welche Objekte tatsächlich in die Produktion gelangten, wann und freigegeben von wem. Das Ticketsystem, ob Jira, ServiceNow oder ChaRM, zeigt, was beantragt und genehmigt wurde. Die Versionsverwaltungs- und Deployment-Spur, einschließlich der Deployment-Logs auf Ihren Servern, zeigt, was der Entwickler tatsächlich gebaut und ausgeliefert hat. Jedes dieser Systeme lässt sich einzeln frisieren. Ihre Schnittmenge ist der Ort der Wahrheit. Eine Prüfung, die nur das Ticket liest, prüft den Papierkram. Eine Prüfung, die alle drei korreliert, prüft die Änderung.
Die vier Feststellungen, die überall wiederkehren.
- Umfangsausweitung. Der Transport enthält mehr Objekte, als das Ticket genehmigt hat. In den zusätzlichen Objekten stecken die interessanten Änderungen.
- Insichgeschäft. Der Entwickler hat seine eigene Änderung beantragt, genehmigt oder freigegeben. Funktionstrennung gilt für den Änderungsprozess, nicht nur für Buchungen.
- Berechtigungsdrift. Die Freigabe liegt formal vor, aber der Freigeber erhielt sein Freigaberecht erst Tage zuvor, auf einem Eilantrag. Prüfen Sie die Änderungshistorie der Berechtigtenliste selbst.
- Verwaiste Änderungen. Produktionsänderungen ganz ohne Ticket, typischerweise über Notfallverfahren, deren versprochene Nachdokumentation nie kam.
Finanzrelevanz ist eine Eigenschaft, keine Vermutung.
Nicht jeder Transport berührt die Finanzberichterstattung. Ob einer es tut, ist bestimmbar: Welche Objekte fasst er an, liegen diese in Buchungs-, Bewertungs- oder Berichtspfaden, welche Buchungskreise sind betroffen. Wer Änderungen nach Finanzwirkung kategorisiert, kann die Aufmerksamkeit einer schlanken Revision dorthin lenken, wo das Fehlerrisiko der Abschlüsse tatsächlich liegt, und liefert dem Abschlussprüfer eine belastbare Scoping-Begründung.
Das Ganze kontinuierlich.
Die beschriebene Korrelation ist mechanisch. Transport-IDs, Ticketreferenzen, Commit-Metadaten und Berechtigtenlisten abgleichen, die vier Muster markieren, jeden Datenpunkt seinem Quellsystem zuschreiben. Mechanisch heißt automatisierbar, und genau so betreibt es RiskForge: fortlaufend, über SAP, Jira, ServiceNow, SAP GRC und Server-Deployment-Logs hinweg, jedes Urteil mit seinen Quellen. Die Methode trägt aber auch allein. Selbst quartalsweise von Hand schlägt das Korrelieren des Dreiecks das Lesen von Tickets.
Sehen Sie RiskForge auf Ihren eigenen Prozessen.
30 Minuten am lebenden Produkt: Zahlläufe, Buchungen, Transporte. Keine Folien, das echte System.