Nachdem ich im letzten Blog Post vorgestellt habe, was Continuous Business Monitoring überhaupt ist, welchen Nutzen es für die einzelnen Beteiligten offenbart und die Treiber identifiziert habe, stelle ich in diesem Beitrag die verschiedenen Komponenten, ein Vorgehen zur Umsetzung und beispielhafte Anwendungsfälle für ein CBM vor.
Sie haben den erstel Teil der zweiteiligen Serie verpasst? Kein Problem. Folgen Sie diesem Link zum Artikel:
Continuous Business Monitoring: Ein Ansatz für die Unternehmensüberwachung
Komponenten des Continuous Business Monitoring
Im Folgenden wird aufgezeigt, aus welchen Komponenten CBM bestehen kann. Hierbei wird besonderes Augenmerk auf Aspekte der Ordnungsmäßigkeit gelegt und weniger auf Leistungsgesichtspunkte, da Leistungsindikatoren stärker von Geschäftsmodell und Branche abhängen als Anforderungen an die Ordnungsmäßigkeit. Aus Sicht des Kontroll- und Überwachungssystems in Verbindung mit der Verwendung von geschäftsprozessunterstützenden ERP-Systemen lassen sich diverse Fragestellungen formulieren (für Komponenten des Internen Kontrollsystems siehe auch: [ID06 R 211, S. 2000]). Da CBM auf dem vorhandenen strukturierten Informationsgehalt der vom Unternehmen verwendeten ERP-Systeme aufbaut, können für ein kontinuierliches Überwachen aufgrund zuvor geschilderter Fragestellungen folgende Datenbestände herangezogen werden:
| Anforderung Kontrollsystem | Kontinuierlich auszuwertender Datenbestand |
| Wie wird sichergestellt, dass Geschäftsvorfälle hinreichend arbeitsteilig abgewickelt werden und somit das 4-Augen-Prinzip stets eingehalten wird (Funktionstrennung) [HeTa07][ID06, R 229, S. 2004]? | Zugriffsrechte aller Systemnutzer, Berechtigungsrollen |
| Wie wird sichergestellt, dass das System grundsätzlich Geschäftsprozesse wie geplant und integer abwickelt? | Systemeinstellungen (Customizing) mit Bezug auf das Interne Kontrollsystem (sog. Anwendungskontrollen [ID06, R 231, S. 2005]; [FA02, Tz. 95]. Diese Systemeinstellungen steuern den Prozessfluss im System. |
| Wie wird sichergestellt, dass tatsächliche Geschäftsvorfälle den Richtlinien und Vorgaben des Unternehmens entsprechen und außergewöhnliche Geschäftsvorfälle bemerkt und verfolgt werden? | Transaktionsbelege: Buchungsbelege des Rechnungswesens, Einkaufsbelege, Materialbelege, Verkaufsbelege |
Tabelle 1: Anforderungen an das Kontrollsystem und dafür relevante Datenbestände
Die Anforderungen an das Kontrollsystem weisen sowohl präventive als auch detektive Maßnahmen auf. Insgesamt ergibt sich ein „Dreisäulensystem“ zur Beschreibung der Bestandteile von CBM: 1. Zugriffsberechtigungen & Funktionstrennung (präventiv), 2. Anwendungskontrollen (präventiv), 3. Analyse von Geschäftsvorfällen (detektiv). Die drei Säulen werden jeweils näher beleuchtet. Die dargestellten Beispiele wurden während eines Projektes bei einem großen DAX-Mandat entwickelt.
Vorgehensweise und Phasenmodell
Um ein CBM für alle genannten Analysegegenstände zu implementieren bedarf es einer Vorgehensweise, welche in Phasen zu strukturieren ist. Die Abbildung verdeutlicht eine mögliche Vorgehensweise [WoGe09].
Abbildung 1: Vorgehensweise zur Implementierung von CBM
Die stetige Überwachung der Analysegegenstände kann in sechs Aktivitätsphasen zerlegt werden. Dabei ist zu beachten, dass die Aktivitäten eins bis vier einmalige Aktivitäten sind, die zur Implementierung benötigt werden. Die Aktivitäten fünf und sechs werden kontinuierlich und periodisch (z.B. täglich oder wöchentlich) wiederholt und stellen insofern den Charakter der kontinuierlichen Überwachung heraus.
In den Aktivitäten eins und zwei (Geschäftsprozessauswahl und Prozessanalyse) wird zunächst festgelegt, welche Geschäftsprozesse (z.B. Einkauf, Verkauf, Rechnungswesen, Systemadministration) in die kontinuierliche Überwachung miteinbezogen werden sollen. Dies sollte anhand von Risikoüberlegungen passieren. Nachdem die Auswahl feststeht, müssen die Prozessabläufe untersucht und die einzelnen Prozessschritte innerhalb des Prozesses identifiziert werden. Die Aktivitäten eins und zwei werden im Folgenden nicht noch einmal für jeden Analysegegenstand erklärt, da es sich insgesamt um gemeinsame Elemente handelt. Die Aktivitäten drei bis sechs werden im Folgenden jeweils für den Analysegegenstand genauer beleuchtet und erklärt.
Kontinuierliche Überwachung der Zugriffsrechte und Funktionstrennung
Die Funktionstrennung (engl. auch Segregation of Duties) dient der Einhaltung des Vier- Augen-Prinzips. Es soll hierdurch sichergestellt werden, dass ein Geschäftsprozess oder mehrere arbeitsteilige Schritte eines Geschäftsprozesses nicht von derselben Person durchgeführt werden, um die Möglichkeit von Fehlern und dolosen Handlungen zu minimieren ([PS06, Tz. 52]; für die Bedeutung von Wirtschaftskriminalität in Unternehmen siehe auch: [PW07]). Für eine Analyse der Zugriffsmöglichkeiten sind die Benutzerberechtigungen in Bezug auf Funktionstrennungsverletzungen zu untersuchen. Für eine kontinuierliche Überwachung dieser Berechtigungen müssen die Daten der Berechtigungen kontinuierlich aus dem System extrahiert (Datenexport) und in einer Auswertelogik, in der Regel eine externe Spezialanalysesoftware, analysiert werden. Für den Bereich der Analyse von Berechtigungen in Hinblick auf Funktionstrennungsverletzungen gibt es inzwischen Standardsoftware wie z.B. Virsa für SAP, Approva oder Security Weaver (für eine Übersicht über sog. Compliance-Software bzgl. Funktionstrennung siehe auch [Ga08]). Der Einsatz dieser Spezialsoftware ist jedoch mit erheblichem Konfigurationsaufwand verbunden, um den spezifischen Anforderungen des Unternehmens Rechnung zu tragen. Im Folgenden wird erläutert, wie die kontinuierliche Überwachung der Funktionstrennung ermöglicht wird.
In der Aktivität 3 (Fachliche Definition der sogenannten Funktionstrennungsmatrix) wird definiert, wann ein Funktionstrennungskonflikt vorliegt. Dazu werden die in Aktivität 2 identifizierten Prozessschritte wechselseitig gegenübergestellt und dann entschieden, ob ein Funktionstrennungskonflikt vorliegt, wenn beide Prozessschritte von einer Person durchgeführt werden können. Es ergibt sich somit eine Regelmatrix, welche durch Kombination zweier Prozessschritte die Funktionstrennungsverletzungen definiert. Relevante Prozessschritte sind hierbei z.B. „Lieferantenstammdatenpflege“, „Verarbeiten von Eingangsrechnungen“ oder „Verarbeiten von ausgehenden Zahlungen“. Ein Funktionstrennungskonflikt ergibt sich immer dann, wenn durch Vereinigung der Prozessschritte in einer Hand ein Risiko denkbar ist. Auf dieser Ebene wird noch nicht auf technische Einzelheiten der verwendeten ERP-Systeme eingegangen. In der folgenden Tabelle sind exemplarisch typische Funktionstrennungskonflikte für den Einkauf aufgezeigt.
| Funktionstrennungskonflikt & Risiko |
| „Lieferantenstammdatenpflege“ gegen „Verarbeitung von Eingangsrechnungen“: Der Nutzer könnte Lieferantenstammdaten manipulieren (z.B. Bankdaten) und eine entsprechende Kreditorenrechnung eingeben und somit Geldmittel aus dem Unternehmen führen. |
| „Verarbeiten von Eingangsrechnungen” gegen „Verarbeiten von ausgehenden Zahlungen“: Zahlungen für fingierte Rechnungen könnten durchgeführt werden. |
| „Lieferantenstammdatenpflege“ gegen „Verarbeiten von ausgehenden Zahlungen“: Der Nutzer könnte Lieferantenstammdaten manipulieren (z.B. Bankdaten) und im Zahlungslauf Geldmittel auf falsche Bankkonten überweisen. |
Tabelle 2: Beispiele von Funktionstrennungsverletzungen
Zusätzlich zur Definition der Konflikte an sich wäre eine Zuweisung einer Risikoziffer (z.B. 1 – 10) pro Konflikt denkbar, um der Schwere von Risiken aufgrund Funktionstrennungskonflikten Rechnung zu tragen.
In der Aktivität 4 (Technische Spezifikation der Regelmatrix) wird das fachliche Regelwerk auf das verwendete ERP-System technisch abgestimmt. Die einzelnen Programme der ERP-Software (in z.B. SAP die Transaktionen) müssen den fachlichen Prozessschritten der Regelmatrix zugeordnet werden, soweit diese relevant sind. Dabei kommt es in der Regel vor, dass mehrere Programme der Software einem Prozessschritt zugeordnet werden, da es stets alternative oder redundante Funktionen für denselben Prozessschritt gibt.
In Aktivität 5 (Datenextraktion) werden zunächst die Benutzer und Benutzerberechtigungen aus dem Quellsystem extrahiert und der Analysesoftware zugeführt. In Aktivität 6 (Funktionstrennungsanalyse) wird die technische Regelmatrix auf den Datenextrakt angewendet und die Funktionstrennungsverletzungen ermittelt. Auch die Darstellungen dieser Analyse und entsprechende Reaktionen zur Verminderung von Konflikten gehören in diese Aktivität. Hier sind verschiedene alternative Darstellungsweisen möglich, die jeweils von der Funktion des Informationsadressaten abhängen. Auf oberster Ebene und zum Vergleich des Status verschiedener (Tochter)firmen können die Kennzahlen „Anzahl der Funktionstrennungsverletzungen“ („Number of violations“) und „Durchschnittliche Anzahl von Verletzungen pro betroffenem Nutzer“ („Average number of violations per affected user“) errechnet werden (Abbildung 2). In einem Koordinatensystem kann dann der Status verschiedener (Tochter)Firmen bzw. Organisationseinheiten verglichen werden (Benchmarking). Auch Verbesserungen bei der Behebung von Funktionstrennungskonflikten im Zeitablauf können als Pfad dargestellt werden.
In ständiger Wiederholung von Analyse und Bereinigung aufgrund der kontinuierlichen Überwachung wird das System somit zunehmend frei von Funktionstrennungskonflikten. Kleine Organisationseinheiten haben regelmäßig Probleme, ihre Arbeitsteilung auszuweiten, um Konflikte zu umgehen. In diesem Fall sollte ein Prozess für begründete Ausnahmebeantragungen etabliert werden. Ausnahmen sollten dabei durch alternative Kontrollmaßnahmen kompensiert werden, um die Kontrolllücke im Berechtigungssystem zu schließen (kompensierende Kontrollen).
Abbildung 2: Darstellung der Funktionstrennungskonflikte verschiedener
Einheiten an zwei verschiedenen Zeitpunkten
Mit den Funktionstrennungskonflikten habe ich ein Beispiel für die Ausgestaltung eines CBM, und damit einer präventiven Kontrolle aufgezeigt. Neben den präventiven Kontrollen zur Untersuchung von Funktionstrennungskonflikten, ist auch eine Anwendungskontrolle denkbar. Vom Ablauf der CBM Gestaltung sind diese Kontrollen identisch. Aktivität 3 (Fachliche Definition von relevanten Anwendungskontrollen) umfasst eine fachliche Auswahl von Systemeinstellungen mit relevantem Bezug zum Internen Kontrollsystem. Folgende Tabelle zeigt mögliche Systemeinstellungen für z.B. ein SAP-System.
| Geschäfts- prozess | Anwendungs- kontrolle | Systemeinstellung mit Bezug zum Internen Kontrollsystem |
| System- administration | Passwortregel | Passwortlänge muss hinreichend lang sein und periodisch geändert werden. |
| System- administration | Protokollierung | Alle Änderungen von Stammdaten des Rechnungswesens müssen protokolliert werden. |
| Einkauf | Doppelte Eingangsrechnungen | Das System muss derart eingestellt sein, sodass bei der Eingabe von Eingangsrechnungen vom System geprüft wird, ob diese Rechnung bereits eingegeben wurde. |
| Einkauf | Logistische Bestellungen | Wenn im System Ware bestellt wird, erwartet das System aufgrund der Bestellung einen Wareneingang und einen Rechnungseingang. Diese Vorgänge müssen zwingend vom Mitarbeiter im System miteinander verknüpft werden. |
| Einkauf | Toleranzwerte bei Bestellungen | Bei einer Warenbestellung überwacht das System automatisch bei Waren- bzw. Rechnungseingang, dass nicht zu viel bzw. zu wenig an Menge geliefert bzw. an Preis abgerechnet wird. |
Tabelle 3: Beispielsystemeinstellungen mit Relevanz zum Internen Kontrollsystem (sogenannte
Anwendungskontrollen) – Fachliche Sicht
In dem wissenschaftlichen Paper mit dem Titel „Zur Automatisierung von Revisionsdienstleistungen zwecks
Unternehmensüberwachung – Ein Überblick“ finden Sie weitere Beispiele, z.B. für die laufende Überwachung von Geschäftstransaktionen und Prozessen (detektive Kontrolle). Das Paper erhalten Sie unter folgendem Link zum direkten Download:
Gesamtsichtweise auf das Überwachungssystem
Eine Ergebnisdarstellung der einzelnen Teilbereiche reicht nicht aus. Hohe Entscheidungsträger und der Aufsichtsrat als Adressaten benötigen eine hochaggregierte Darstellung aller Teilbereiche zusammen. Es muss eine Gesamtbewertung stattfinden, um den Status des Überwachungssystems des Unternehmens schnellstmöglich zu erfassen. Hierfür eignet sich ein Scoringmodell, welches alle Einzelergebnisse geeignet summiert, sodass sich für jede definierte Aggregationsebene ein Prozentwert ergibt.
Als Aggregationsebenen eignen sich z.B. die folgenden 7 Ebenen: 1. Konzern, 2. Konzernbereich, 3. Tochterunternehmen, 4. Geschäftsprozess, 5. Risiko, 6. Kontrollziel, 7. Kontrollmaßnahme. Hinter jeder Kontrollmaßnahme (unterste Ebene) befindet sich eine Auswertelogik, welche durch ein Scoringmodell die technische Ausprägung der Kontrollmaßnahme bewertet. Die Aggregationsebenen summieren alle Punkte innerhalb der Ebene und berechnen einen Prozentwert. Es ist Aufgabe der Geschäftsführung Maßnahmen festzulegen, wenn bestimmte Schwellwerte unterschritten werden.
Fazit
Dieser Post hat die Möglichkeiten einer weitgehend automatisierten Unternehmensüberwachung im Rahmen eines Continuous Business Monitoring Konzeptes aufgezeigt. Aufgrund zunehmenden Einsatzes von Informationstechnologie und vor allem höherer Integration von Informationssystemen gewinnt auch die Automatisierung von Überwachungsfunktionen innerhalb des Unternehmens an Attraktivität. Erhöhte Strukturierung und schnellere Verfügbarkeit von Ergebnissen der Unternehmensüberwachung werden nicht zuletzt durch immer größere Organisationen in globalen Märkten und stärkerer Öffentlichkeitswirksamkeit aufgrund von z.B. Wirtschaftskrisen zunehmend notwendiger. Gerade Aufsichtsräte müssen Möglichkeiten finden, ihrer gesetzlichen Kontrollfunktion nachzukommen und sollten insofern starkes Interesse haben, hinreichende Überwachungsmaßnahmen zu installieren.
Wenn Sie wissen wollen, wie man ein solches System auch umsetzen kann, dann schreiben Sie uns. Mit unserem fortschrittlichen Datenabzug ist die Umsetzung eines CBM Systems problemlos möglich.
Erstmalig erschienen in: Gehrke, N.: Zur Automatisierung von Revisionsdienstleistungen zwecks Unternehmensüberwachung – Ein Überblick, Lecture Notes in Informatics, Proceedings der Jahrestagung Informatik 2009, Lübeck, 2009
Quellen:
[FA02] Institut der Wirtschaftsprüfer Stellungnahmen, Grundsätze ordnungsmäßiger Buchführung bei Einsatz von Informationstechnologie, IDW RS FAIT 1, 2002.
[Ga08] Gartner Research: MarketScope for Segregation of Duty Controls within ERP and Financial Applications, 2008.
[HeTa07] Hendrawirawan, D.; Tanriverdi, H.; Zetterlund, C.; Hakam, H.; Kim, H.; Paik, H: ERP Security and Segregation of Duties Audit: A Framework for Building an Automated Solution, Information Systems Control Journal, Vol. 2, 2007.
[ID06] Institut der Wirtschaftsprüfer, Wirtschaftsprüferhandbuch 2006 Band I, 2006.
[PS06] Institut der Wirtschaftsprüfer, PS 261: Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die beurteilten Fehlerrisiken, Stand 06.09.2006, 2006.
[PW07] PricewaterhouseCoopers: Economic crime: people, culture and controls – The 4th biennal Global Economic Crime Survey, 2007.
[WoGe09] Wolf, P.; Gehrke, N.: Continuous Compliance Monitoring in ERP Systems – A Method for Identifying Segregation of Duties Conflicts, Proceedings Konferenz Wirtschaftsinformatik, Wien, 2009.
