Arbeitspapier. des Lehrstuhls für Wirtschaftsinformatik Technische Universität München. Nr. 38

Transkript

1 Technische Universität München Arbeitspapier des Lehrstuhls für Wirtschaftsinformatik Technische Universität München Nr. 38 Automatische Prozesskontrollen als Wegbereiter für eine nachhaltige Unternehmenstransparenz am Beispiel von SAP GRC Process Control 10.0 Bernhard Lichtinger, Manuel Wiesche, Stephan Gradl, Helmut Krcmar Herausgeber: Prof. Dr. Helmut Krcmar Technische Universität München, Institut für Informatik, Lehrstuhl für Wirtschaftsinformatik (I 17) Boltzmannstraße 3, Garching b. München Tel , Fax: Garching, November 2011

2 Vorwort Die Erstellung der vorliegenden Arbeit wäre ohne die Mithilfe vieler Menschen nicht möglich gewesen. Mein erster Dank gilt meinem Betreuer, Herrn Manuel Wiesche, der mich stets auf den richtigen Weg brachte und mich mit spannenden Fragestellungen inspirierte. Ganz besonders bedanken möchte ich mich bei Herrn Stephan Gradl, der mir stets mit Rat und Tat zur Seite stand. Ohne ihn wäre ein großer Teil der Arbeit nicht möglich gewesen. Ebenso danken möchte ich Herrn Prof. Dr. Helmut Krcmar für die spannende Themenstellung und fördernde Betreuung. Im gleichen Zuge möchte ich Maxim Chuprunov, dem Geschäftsführer und Berater der RISCOMP GmbH, danken. Er hat mit seiner Hilfe, in einer entscheidenden Phase, maßgeblich zum Gelingen dieser Arbeit beigetragen. Mein aufrichtiger Dank gilt auch dem SAP University Competence Center der TU München, das mir die nötige Infrastruktur und Serverkapazität zur Verfügung gestellt hat. An dieser Stelle möchte ich mich bei allen Mitarbeitern bedanken, die stets ein offenes Ohr für meine Fragen hatten. Ebenso bedanken möchte ich mich bei den SAP University Alliances, die mir die verwendete Software im Rahmen eines Ramp Ups zur Verfügung gestellt haben. Bedanken möchte ich mich auch bei meinen Kommilitonen und Freunden, insbesondere bei Herrn Maximilian Könnings und Herrn Willibald Dirmeier, die vor allem zur abschließenden Endkontrolle beigetragen haben. Meinen Eltern und meiner Schwester danke ich für die fortwährende Unterstützung in jeglicher Hinsicht. Bernhard Lichtinger I

3 Zusammenfassung Automatische Prozesskontrollen dienen in der betrieblichen Praxis als Wegbereiter für eine nachhaltige Unternehmenstransparenz. Basierend auf den Potentialen der Informationstechnologie (IT) wird in dieser Arbeit der Aufbau eines IT-gestützten internen Kontrollsystems (IKS) zur automatischen Überwachung interner und externer Anforderungen untersucht. In einer grundlegenden Literaturrecherche werden zunächst die Nachteile manueller Kontrollen herausgestellt und anschließend in Verbindung mit identifizierten IT-Potentialen gebracht. Anschließend wird die theoretische Linse der Organisationskontrolltheorie angewandt um einen grundlegenden Einblick in die Konstruktion von Kontrollen zu erhalten. Zur Implementierung von automatischen Prozesskontrollen in SAP GRC Process Control 10.0 wird Design Science angewandt. Als Überwachungsgrundlage dient der Einkaufsprozess in SAP ERP, welcher dazu logisch mit SAP GRC Process Control 10.0 verbunden wird. Basierend auf den Potentialen der IT, wie die Automatisierung oder das Tracking von Informationen über geografische Grenzen hinweg, wurde ein kontinuierliches automatisches Prozesskontrollsystem implementiert, das den aktuellen Compliance Status eines Unternehmens in nahezu Echtzeit wiedergibt. Dadurch wurde zum einen eine Entscheidungsgrundlage für das Top-Management geschaffen und zum andern kann die Einhaltung regulatorischer Anforderungen sichergestellt werden. Dies trägt einerseits dazu bei, dass das Unternehmen vor dem Wirtschaftsprüfer besteht und andererseits wurde dadurch eine Vertrauensgrundlage für externe Stakeholder geschaffen. Die angewandte Theorie zur Klassifizierung von Kontrollen bot keine eindeutige Entscheidungsunterstützung, daher sei auf die Entwicklung geeigneter Dimensionen verwiesen. Da diese Arbeit lediglich einen Proof-of-Concept erbringt, sei auf eine weiterführende Betrachtung unter verstärkter Einbindung des Risikomanagements und der Gewichtung von Kontrollen verwiesen. Stichworte: Internes Kontrollsystem, Automatische Prozesskontrollen, Kontinuierliche Kontrollüberwachung, Informationstechnik, Organisationskontrolltheorie, Kontrolltheorie, Compliance, Risikomanagement, Governance, GRC. II

4 Abstract Automated process controls are becoming vital in the industrial practice and serve as a precursor for sustainable corporate transparency. Technological capabilities of information technology (IT) allow the application of new processes in internal control systems such as monitoring internal and external requirements automatically. This work describes the implementation and use of an IT-based internal control system using the example of SAP GRC Process Control A profound literature review is carried out in order to analyze process control systems used in the past, to find disadvantages of manual controls and to combine them with benefits of today s IT. The theoretical lens of organizational control theory is applied to obtain a basic insight in the design of controls. The implementation is guided by Design Science Research. To outline the benefits of continuous controls monitoring the SAP ERP procure-to-pay process is monitored. Therefore SAP GRC Process Control 10.0 was logically connected to SAP ERP. Based on the potentials of IT, such as the automation and tracking of information without geographical boundaries, a continuous automatic process control system is implemented to monitor and to make the current compliance status of a company available in almost real time. This serves decision making processes of the top management, secures internal and external regulatory compliances and audit requirements and provides a trustworthy basis for other stakeholders. The theory applied to structure controls did not provide explicit decision support. Therefore the development of appropriate dimensions is suggested. Since this work only meets a proof of concept, a secondary consideration with greater integration of risk management and the scoping of risks is recommended. Keywords: Internal Control System, Automatic Process Controls, Continuous Controls Monitoring, Information Technology, Organizational Control Theory, Compliance, Riskmanagement, Governance, GRC. III

5 Inhaltsverzeichnis Vorwort... I Zusammenfassung... II Abstract... III Abbildungsverzeichnis... VII Tabellenverzeichnis... IX Abkürzungsverzeichnis... X 1 Einleitung Forschungsmethoden und -design Forschungsmethoden Design Science Definition und Ziele von Design Science Aufbau und Ablauf Anwendung auf die vorliegende Arbeit Motivation, Problemstellung und Aufbau der Arbeit Motivation Problemstellung und Aufbau der Arbeit Governance, Risk und Compliance Chancen und Risiken in einer multipolaren Welt GRC Eine ganzheitliche Betrachtung Compliance Anforderungen und ihre Beherrschung durch ein Internes Kontrollsystem Theoretische Grundlagen Definition und Ausgestaltung eines internen Kontrollsystems IKS Empfehlungen für das Management: COSO und COBIT Internationale und nationale Anforderungen Umsetzung eines IKS durch Prozesskontrollen Klassische Kontroll-Definition Erweiterte und für diese Arbeit gültige Definition Zeitpunkt von Kontrollen: Präventive vs. Detektive Kontrollen Kontrollgrund: Error oder Fraud Häufigkeit von Kontrollen Manuelle und Automatische Kontrollen Kontrollumgebung: Der (Geschäfts-)Prozess Kontrollkategorien IV

6 5.5.9 Zusammenfassung: Kontrollverständnis Rollen und Aufgaben in einem IKS Herausforderungen bei der Umsetzung eines IT-gestützen Prozesskontrollsystems Schwachstellen manueller Kontrollen IT-Potentiale und deren Einfluss auf Kontrollen Umsetzung eines IT-gestützten Prozesskontrollsystems am Beispiel von SAP GRC Process Control SAP GRC Process Control Kurzvorstellung Szenario: Automatische Überwachung von SAP ERP Vorstellung und Klassifizierung der Kontrollen als Vorbereitung auf die Implementierung Auswahl einer geeigneten Klassifizierungstheorie Skalenerstellung Vorgehen bei der Durchführung der Klassifizierung Ergebnis der Klassifizierung und Vorstellung der Kontrollen Einpflegen der Kontrollen in SAP Process Control Kurzvorstellung der Arbeitsoberfläche Risiken im Einkaufsprozess Organisationsstruktur, Geschäftsprozesse und Kontrollen Kontrollaufbau und -konzept Proof-of-Concept aus strategischer Unternehmenssicht: Einplanen der automatischen Überwachung Zu erfüllende Anforderungen und Evaluationsbedingungen Durchführen der Automatischen Überwachung Ergebnis der Evaluation Diskussion IT als Parallelverschiebung von Ouchi s Dimensionen Disparität zwischen Vorstellung und Realisierung von Kontrollen Grundlegende Veränderung der Accounting-Profession Kritische Reflektion: Risikoaversion durch CCM? Einschränkungen Showcase Fazit und Ausblick Literaturverzeichnis Anhang A SAP BusinessObjects GRC Process Control Installation and Configuration V

7 Anhang B Detailübersicht der Klassifizierung VI

8 Abbildungsverzeichnis Abbildung 1: Information Systems Research Framework... 5 Abbildung 2: Spannungsfeld Unternehmen... 8 Abbildung 3: GRC Eine integrierte, ganzheitliche, unternehmensweite Betrachtung Abbildung 4: Aufbau - Internes Kontrollsystem Abbildung 5: COSO Cube Abbildung 6: Erweiterter COSO Cube (COSO ERM) Abbildung 7: IKS zwischen IDW und COSO/COBIT Abbildung 8: Gesetze, Frameworks und regulatorische Standards Abbildung 9: Hype Zyklus für Regularien und Standards, Abbildung 10: Kontrollverständnis Abbildung 11: Fraud Triangel Abbildung 12: Regelkreis - Detektive und Präventive Kontrollen Abbildung 13: Rollen im IKS Abbildung 14: Automatische Überwachung Abbildung 15: SAP Einkaufsprozess Abbildung 16: Grundprinzip der Implementierung und Evaluierung Abbildung 17: Ouchi Framework Abbildung 18: Empirische Studien die Ouchi anwenden Abbildung 19: Grundüberlegung zur Klassifizierung Abbildung 20: Bewertungsschema für Dimensionen Abbildung 21: Ergebnis bezüglich der Dimensionen Abbildung 22: Ergebnis der Klassifizierung bezüglich der Kontrollen selbst Abbildung 23: Process Control Startseite Abbildung 24: Risiken im Einkaufsprozess Abbildung 25: Organisationshierarchie Abbildung 26: Geschäftsprozesse und Teilprozesse Abbildung 27: Risikodeckung auf Teilprozessebene Abbildung 28: Zuordnung auf Organisationsebene Abbildung 29: Aufbau Kontrolle_ Abbildung 30: Funktionsweise von Regeln Abbildung 31: Überwachungseinplaner Abbildung 32: Job Monitor Abbildung 33: Job Monitor - Kontrolle_ Abbildung 34: Dashboard - Automatische Überwachung Abbildung 35: Ouchi Framework Abbildung 36: Disparität zwischen Kontrolle und Umsetzung VII

9 Abbildung 37: Steigende Kontinuität - Abnehmende Effektivität? VIII

10 Tabellenverzeichnis Tabelle 1: IT-Einflüsse nach Davenport Tabelle 2: Verbesserungspotentiale der IT Tabelle 3: Skala - Fähigkeit das Ergebnis zu messen Tabelle 4: Skala - Wissen über den Prozess Tabelle 5: Skala - Ergebniskontrolle Tabelle 6: Skala - Verhaltenskontrolle Tabelle 7: Ergebnis der Klassifizierung Tabelle 8: Ergebnis der Evaluation Tabelle 9: Kontrolle_09 - Verhaltens- sowie Ergebniskontrolle IX

11 Abkürzungsverzeichnis ACFE AG AktG AtmO BC BilMog BPR BRIC(A) CA CCM CCO CEO CMMI COBIT COSO EAM ERM ERP esac GAIT GmbHG GRC HGB HRM IDES IDW IEEE IKS IKT IT ITAF ITIL J-SOX KonTraG KPI KTP MCL MIS MKWI OC OCT OECD OECG PC PCARIPA PwC SEC Association of Certified Fraud Examiniers Aktiengesellschaft Aktiengesetz Ability to measure Output Behavior Control Bilanzmodernisierungsgesetz Business Process Reengineering Brasilien, Russland, Indien, China, (Afrika) Continuous Auditing Continuous Controls Monitoring Chief Compliance Officer Chief Executive Officer Capability Maturity Model Integration Control Objectives for Information and Related Technology Committee of Sponsoring Organizations of the Treadway Comission Embedded Audit Monitoring Enterprise Risk Management Enterprise Resource Planing Electronic Security Assurance and Control Model Guide to Assessment of IT-Risk Gesellschaft mit beschränkter Haftung Gesetz Governance, Risk und Compliance Handelsgesetzbuch Human Resource Management International Demonstration and Education System Institut der Wirtschaftsprüfer in Deutschland e.v. Institute of Electrical and Electronics Engineers Internes Kontrollsystem Informations- und Kommunikationstechnologie Informationstechnologie Information Technology Assurance Framework Information Technology Infrastructure Library Japanese - Sarbanes-Oxley Act Gesetz zur Kontrolle und Transparenz im Unternehmen Key Performance Indicator Knowledge of the Transformation Process Monitoring Control Layer Management Information Systems Multikonferenz Wirtschaftsinformatik Output Control Organizational Control Theory Organisation for Economic Co-operation and Development Open Compliance and Ethics Group Process Control Public Company Accounting Reform and Investor Protection Act PricewaterhouseCoopers Securites and Exchange Comission X

12 SoD SOX TI US Segregation of Duties Sarbanes-Oxley Act Transparency International United States XI

13 1 Einleitung Vertraue, aber prüfe nach! (Wladimir Iljitsch Uljanow) Diesen Satz hat Wladimir I. Uljanow, der besser unter dem Namen Lenin bekannt war, oft in seinen Schriften verwendet (Drösser 2000). Diese Aussage ist manch einem besser bekannt als Vertrauen ist gut, aber Kontrolle ist besser. Dass nach prüfen oder Kontrollen allgemein durchaus berechtigt sind, zeigt eine Reflektion auf vergangene, prominent gewordene Accounting-Skandale: Im Frühjahr 2002 bezeugte der damalige Chief Executive Officer (CEO) Jeff Skilling ungläubig, dass Enron in guter Verfassung war, als er das Unternehmen verlassen hatte und dass er nichts über die außerbilanziellen Transaktionen wusste, die das Unternehmen in Grund und Boden gewirtschaftet hatten (Pershkow 2002, 16). Am 2. Dezember 2002 hat das Unternehmen mit 31,2 Milliarden Dollar Schulden, Konkurs angemeldet und war damit das größte Konkursverfahren in der US-Geschichte. Zuvor noch galt der Energiekonzern Enron fünf Jahre lang als das innovativste Unternehmen des Landes, mit einem Marktwert von 63 Milliarden Dollar (Beams 2001). Als Außenstehender war es unmöglich geworden, die komplexen Finanzstrukturen von Enron zu verstehen und niemand wusste so richtig mit was Enron sein Geld verdiente. Erst als Enron die Gewinne für die vergangenen vier Jahre rückwirkend um eine halbe Milliarde Dollar nach unten korrigierte, wurde klar, dass Enron nie so viel verdiente hatte, wie es angab (Hillenbrand 2002). Die Bilanzverfälschungen, konnte auch die Informationspolitik von Enron nicht aufdecken, weil es schlichtweg keine gab (Healy/Palepu 2003, 3f.). Im Jahr 2002, verkauft HealthSouth CEO Richard M. Scrushy Aktien im Wert von 75 Millionen Dollar. Wenige Tage später gibt der im Gesundheitswesen tätige Anbieter einen großen Verlust bekannt. Daraufhin wurde HealthSouth von der US Bösenaufsicht, der U.S. Securites and Exchange Commission (SEC), wegen des Bilanzbetrugs angeklagt. Konkret ging es um eine Überwertung im Wert von 1,4 Billionen Dollar. Die Gewinne wurden verfälscht um neue Investoren zu gewinnen. Das Unternehmen war in bestimmten Jahren um 4700% überbewertet. Scrushy wurde des Betrugs angeklagt und es wurde festgestellt, dass dem Unternehmen ein Kontrollsystem fehlte, das die Finanzen überwacht (Gherai/Balaciu 2011, 39). Als 2006 die Schmiergeldaffäre von Siemens bekannt geworden war, stellte sich heraus, dass 1,3 Milliarden Euro auf schwarze Konten ins Ausland gezahlt wurden. Die Angelegenheit hat damals selbst Korruptionsexperten überrascht. So sagte der stellvertretende Vorsitzende der Anti-Korruptions-Organisation Transparency International (TI) Peter von Blomberg: Bei dieser Größenordnung kann man die Frage verstehen, ob Korruption bei Siemens Teil der Geschäftspolitik ist, mit Wissen oder Duldung der Geschäftsführung oder das Unternehmen das Opfer eigenmächtig handelnder leitender Angestellter ist. Peter von Blomberg gab weiter an, dass bei dem Münchner Konzern sämtliche Kontrollsysteme versagt [haben] (SpiegelOnline 2006). Den damaligen Vorstandsmitgliedern wurde am 15. Dezember 2008, am Tag des Gerichtsverfahrens, schmerzlich bewusst, dass ihr nicht regelkonformes Handeln nicht nur dem Unternehmen geschadet hatte, sondern auch sie persönlich mit einer strafrecht- 1

14 lichen Verfolgung zu rechnen hatten. Die Folge war, dass der damalige Vorstandsvorsitzende Klaus Kleinfeld und Aufsichtsratsvorsitzender Heinrich von Pierer das Unternehmen verlassen mussten. Insgesamt haben die Gerichtsverfahren Siemens mehr als 2 Milliarden Euro gekostet und damit war Siemens nur die Spitze des Eisbergs deutscher Unternehmen die gegen nationales und internationales Korruptionsrecht verstoßen haben. Der Skandal hatte zur Folge, dass Siemens kurz darauf 500 Vollzeit Chief Compliance Officer (CCO) einstellte, die eine umfassende Compliance-Initiative einrichteten, die sich um die Einhaltung gesetzlicher Bestimmungen und interner Standards kümmerte (Sidhu 2009, 1344f.) war das Jahr der Finanzkrise. Doch diese fand ihren Beginn nicht von heute auf morgen. Auf einmal konnten sich Menschen Häuser kaufen, obwohl sie kein Geld hatten. Ermöglicht wurde dies durch so genannte Subprime Loans (Gherai/Balaciu 2011, 39f.). Diese waren zwar teurer, jedoch wurde darüber hinweggesehen, wenn Schuldner wenig oder über überhaupt keine Sicherheiten verfügten. Die Folge war, dass nicht wenige Häuser ohne Eigenkapital finanziert wurden. Nachdem das Angebot die Nachfrage überschritten hatte, gingen die Häuserpreise nach unten. Die steigenden Zinsen sorgten schließlich bei Hausbesitzern für ein böses Erwachen, sie konnten ihre Raten nicht mehr bezahlen. Die Immobilienfinanzierer verkauften die Kredite einfach weiter an Banken und Hedge Fonds setzte dann bereits die Abwärtsspirale ein und riss alle faulen Kredite mit nach unten. Nach den Hypothekenfinanzierern erwischte es schlussendlich auch die Banken, die diese Kredite, welche oft bis zur Unkenntlichkeit zerstückelt wurden, aufgekauft hatten. Die Krise war schließlich allen bewusst, als 2007 das Traditionshaus Lehmann Brothers, Amerikas viertgrößte Investmentbank, Konkurs anmeldete (Krüger 2008). Im Nachhinein hat sich gezeigt, dass die internen Kontrollsysteme der Banken und Rating Agenturen mangelhaft waren (Bernholz/Faber/Petersen 2009, 14). Die Gemeinsamkeiten all dieser Skandale liegt darin, dass ihnen entweder ein ausreichendes internes Kontrollsystem gefehlt hat, oder schlichtweg keines vorhanden war. Als Reaktion auf die Skandale wurden oftmals Gesetze erlassen, wie z.b.der Sarbanes-Oxley Act (SOX), welcher nach dem Enron Skandal ins Leben gerufen wurde. Die offizielle Bezeichnung Public Company Accounting Reform and Investor Protection Act (PCARIPA) wurde in der Praxis in SOX umbenannt, in Anlehnung an seine Verfasser Paul Sarbanes und Michael Oxley. Im Folgenden sollen die vier wichtigsten Paragraphen kurz vorgestellt werden (Sarbanes-Oxley Act 2002): - 302: Dieser Paragraph fordert direkt ein internes Kontrollsystem (IKS) um eine verlässliche Finanzberichterstattung zu gewährleisten. Das Management eines Unternehmens muss dafür schriftlich die eigene Verantwortung, ein IKS einzurichten und zu unterhalten, unterschreiben. Ferner muss das Management Aussagen über die Effektivität der Kontrollen veröffentlichen und auf mögliche Schwächen hinweisen : Im Rahmen eines IKS-Reports soll das Management über Umfang und Effektivität der internen Kontrollen zur Finanzberichterstattung berichten. Zudem muss ein externer Wirtschaftsprüfer ebenfalls eine solche Bestätigung abliefern. Damit wird 302 nochmals erweitert. 2

15 - 802: Wenn SOX-relevante Nachweise der Finanzberichterstattung absichtlich geändert, gefälscht, zerstört oder verschleiert werden, droht 20 Jahre Gefängnisstrafe : Wenn Personen, die über SOX-Verstöße im Unternehmen an die zuständigen Behörden berichten, verfolgt werden, so werden die Verfolger mit bis zu 10 Jahren Haft bestraft. In dem Zusammenhang spricht man auch vom Schutz der Whistleblower. So werden Personen genannt, die Verstöße im Unternehmen an die Behörden weitergeben (Dworkin 2006, 1764). Aus diesen Paragraphen geht nicht nur hervor, dass Unternehmen regulatorische Anforderungen im Rahmen eines internen Kontrollsystems einzuhalten haben, sondern dass auch das Management im Falle einer Unterlassung dafür haftet. Unternehmen müssen sich also in Zukunft mit Fragestellungen wie Wie werden wir den regulatorischen Anforderungen gerecht? und Wie können wir unser Management in ihren Entscheidungen hinsichtlich dieses Problems unterstützen? auseinandersetzten. Dazu verfolgt die vorliegende Arbeit mit dem Titel Automatische Prozesskontrollen als Wegbereiter für eine nachhaltige Unternehmenstransparenz am Beispiel von SAP GRC Process Control 10.0 den Ansatz, diese Transparenz sowohl gegenüber der Einhaltung der Anforderungen, als auch gegenüber dem Management mit Hilfe von automatischen Prozesskontrollen zu adressieren. Dass dies in Zeiten der Informationstechnologie nicht mehr manuell erfolgen kann, ist evident. Daher muss eine Möglichkeit gefunden werden, automatisierte Prozesskontrollen in einem IT-System abzubilden. Daraus abgeleitet ergeben sich folgende Forschungsfragen, welche im Rahmen der vorliegenden Arbeit behandelt werden: FF1: Was sind die Herausforderungen bei der Umsetzung einer unternehmensweiten Prozesskontrolle an ein IT-System und wie muss dieses ausgestaltet werden? FF2: Wie können Kontrollen als Vorbereitung auf eine Implementierung in einem Monitoring Tool systematisiert werden? FF3: Welche Bedeutung hat SAP GRC Process Control 10.0 aus strategischer Unternehmenssicht und welchen Mehrwert bringt es dem Top-Management? Automatische Prozesskontrollen dienen in der betrieblichen Praxis als Wegbereiter für eine nachhaltige Unternehmenstransparenz. Basierend auf den Potentialen der Informationstechnologie wurde der Aufbau eines IT-gestützten internen Kontrollsystems zur automatischen Überwachung interner und externer Anforderungen untersucht. So ermöglicht die IT den Einsatz unternehmensweiter automatisierter Kontrollen über geographische Grenzen hinweg. Damit sind diese effektiver und wirtschaftlicher als die fehlerbehafteten und nur sehr langsam durchführbaren manuellen Kontrollen. Das implementierte und evaluierte System sorgt dafür, dass das Unternehmen vor dem Wirtschaftsprüfer besteht und gibt dem internen Audit Auskunft über die Effektivität und Effizienz von Kontrollen. Neben der Schaffung einer Vertrauensgrundlage gegenüber externen Stakeholdern, dient es dem Top-Management als Entscheidungsgrundlage. 3

16 2 Forschungsmethoden und -design Im Folgenden werden die Forschungsmethoden präsentiert, mit deren Hilfe die Forschungsfragen behandelt werden. Zudem wird der Design Science Ansatz vorgestellt, der zur Behandlung der dritten Forschungsfrage herangezogen wird. 2.1 Forschungsmethoden FM1: Zur Behandlung von Forschungsfrage 1 wird eine Literaturrecherche in den Bereichen Accounting (Buchführung/Rechnungslegung), Information Systems (Informationssysteme), Accounting Information Systems (Rechnungslegungs-Informationssysteme) Management, Compliance (Regelkonformität), Organisation, Management Accounting (Rechnungswesen), Information Technology (Informationstechnologie), Information and Communication Technology (Informations- und Kommunikationstechnologie) und Business Process Reengineering (Geschäftsablaufoptimierung) angesetzt. Dabei folgt die Literaturrecherche den Richtlinien von Webster und Watson (Webster/Watson 2002). FM2: Forschungsfrage 2 wird mit der Suche nach einer geeigneten Klassifizierungstheorie aus dem Bereich der Organizational Control Theory (Kontroll-Theorie im Unternehmen) behandelt. Um ein fundiertes Verständnis von organisatorischen Kontrollmechanismen zu bekommen wird eine Literaturrecherche in den Bereichen Management Control (Management/Verwaltungs-Kontrolle), Organizational Control (Kontrolle im Unternehmen) und Control Theory (Kontrolltheorie) angesetzt. Anschließend soll eine geeignete Klassifizierungstheorie ausgewählt und angewandt werden. Zur Anwendung wird eine Operationalisierung angesetzt. FM3: Die Forschungsfrage 3 wird dadurch behandelt, dass Design Science nach Hevner et a. angewandt wird um IKS-Kontrollen in einem IT-Tool zu implementieren (2004). Ein Proofof-Concept bestätigt im Rahmen einer Evaluierung die Annahmen. 2.1 Design Science Definition und Ziele von Design Science Diese Arbeit zielt darauf ab, aus Bestehendem etwas Neues mit Hilfe von Informationstechnologie zu kreieren. Daher soll das Konzept der Design Science, Anwendung finden. Bei Design Science handelt es sich um eine Forschungsmethode, die im Gegensatz zur Behavorial Science, problemlösungsorientiert vom Menschen erschaffene Phänomene untersucht um bestimmte Ziele zu erreichen (Simon 1996, 20ff.). Ziel ist es Artefakte zu erschaffen, diese zu evaluieren und anschließend zur Problemlösung zu verwenden. Den grundlegenden Unterschied zwischen Behavorial Science und Design Science beschreiben Hevner et al. (2004, 98) folgendermaßen: The behavioral-science paradigm seeks to find what is true. In contrast, the design-science paradigm seeks to create what is effective. In diesem Sinne wird in dieser Arbeit ein effektives automatisches Prozesskontrollsystem innerhalb einer IT-gestützten Umgebung umgesetzt. 4

17 2.1.2 Aufbau und Ablauf Design Science startet mit dem Vorliegen eines Problems. Dieses gilt es innerhalb der Dauer eines Projektes mit einem geeigneten Artefakt zu lösen. Der Aufbau wird von Hevner et al. (2004, 80) durch ein Information Systems Research Framework beschreiben, das wie folgt aufgebaut ist: Abbildung 1: Information Systems Research Framework Quelle: Eigene Darstellung in Anlehnung an (Hevner 2007, 88) Die drei Säulen Environment, Design Science Research und Knowledge Base bilden die Basis dieses Frameworks: - Environment: Das Umfeld der Forschung definiert Probleme und gibt daher den Anstoß für die eigentliche Forschung. Dabei besteht das Forschungsumfeld aus Personen, Organisationen und Technologie. Aus dieser Umgebung entstehen letztlich die auschlaggebenden Probleme, die Hevner et al. (2004, 80) Business Needs nennen. - Design Science Research: In diesem Bereich werden neue Theorien und neue Artefakte erstellt und entwickelt. In der anschließenden Evaluation, werden die Techniken der Analyse, der Fallstudien etc. eingesetzt, um zu zeigen, wieso und weshalb die neue Theorie oder das neue Artefakt den Business Needs entspricht - Knowledge Base: Diese wird als ein weiterer Output der Design Science mit neuem Wissen angereichert. Dazu stellt die Knowledge Base aber auch die fundierte Basis der Theorien und Methoden bereit. Sie bildet das Fundament für Information Systems Research und gibt dem Forscher die notwendigen Werkzeuge in die Hand. 5

18 Zusammengehalten werden diese Säulen durch drei jeweils übergreifende Kreisläufe (Hevner 2007, 88ff.): - Relevance Cycle: Hier werden die Anforderungen aus der Umgebung (Environment) in die Forschung aufgenommen und anschließend werden die erstellten Artefakte wieder in der Umgebung getestet. - Design Cycle: Der Design Cycle stellt den zentralen Kreislauf dar und besteht aus, für die Design Science typisch, zwei grundlegenden Aktivitäten: Erstellen und Evaluieren (March/Smith 1995, 254). Beim Erstellen wird versucht ein Artefakt zu kreieren, das anschließend im Rahmen der Evaluation auf dessen Tauglichkeit, das Problem zufriedenstellend zu lösen, untersucht wird. Da nicht davon ausgegangen wird, dass das erste kreierte Artefakt das Problem löst, ist der Design Science Ansatz, als Kreislauf zu sehen, der solange abläuft, bis das Problem gelöst ist. Dabei wechseln sich Erstellen und Evaluieren ständig ab (Hevner et al. 2004, 89). Ist ein Artefakt entstanden, das das Problem löst, so wird untersucht, wie und warum das Artefakt im gegebenen Kontext zur Lösung des Problems beigetragen hat. Ziel dieses Vorgangs ist es, eine Theorie basierend auf dem erstellten Artefakt zu entwickeln und anschließend zu validieren. - Rigor Cycle: In diesem Zyklus werden die grundlegenden Theorien und Methoden aus der Knowledge Base benutzt um ein Artefakt zu kreieren. Anschließend wird das neu hinzugewonnene Wissen wieder in die Knowledge Base aufgenommen Anwendung auf die vorliegende Arbeit Hevner et al. (2004) schlagen sieben Grundsätze vor, die helfen sollen Wissen und Verständnis eines Design-Problems und dessen Lösung zu erwerben, indem ein Artefakt gebildet und angewendet wird (Hevner et al. 2004, 83). Im Folgenden sollen die Grundsätze kurz vorgestellt und direkt auf die vorliegende Arbeit angewendet werden: 1) Design als Artefakt: Design-Science Forschung muss ein realisierbares Artefakt schaffen, in Form eines Konstrukts, eines Models, einer Methode oder eine Instanziierung. In der vorliegenden Arbeit wird die Instanziierung eines IT-gestütztes Kontrollsystems implementiert. 2) Problemrelevanz: Ziel ist es technologiebasierte Lösungen zu wichtigen und sachbezogenen Problemen in Unternehmungen zu entwickeln. Die Erstellung von normalen IKS-Kontrollen im IT-System wird wissenschaftlich untersucht. 3) Design-Evaluierung: Nutzen, Qualität und Wirksamkeit eines Design-Artefakts müssen konsequent bewiesen werden, durch gut ausgeführte Evaluationen. Nachdem Kontrollen in das System implementiert wurden, werden sie durch bewusst falsche Eingaben im Zielsystem getestet. Dies passiert mit dem Ziel, die Kontrol- 6

19 len auszulösen und durch ihr korrektes Funktionieren einen Proof-of-Concept zu erreichen. 4) Beitrag zur Forschung: Effektive Design Science Forschung muss klare und nachprüfbare Beiträge in den Bereichen Design-Artefakte, Design-Grundlagen und/oder Design-Methoden liefern. Die Arbeit setzt sich mit den Fragen auseinander, wie IKS-Kontrollen in einem IT- System abgebildet werden können und was es heißt ein IKS im IT-System abzubilden. 5) Stringenz in der Forschung: Design Science Forschung stützt sich auf die Anwendung von strikten Methoden sowohl in der Konstruktion als auch in der Evaluation von Design-Artefakten. Bei der Konstruktion des Artefakts wird Design Science selbst angewandt; Die Evaluierung wird im Rahmen eines Proof-of-Concepts durchgeführt. 6) Design als Suchprozess: Die Suche nach einem effektiven Artefakt erfordert die Nutzung der verfügbaren Mittel, um das gewünschte Ziel zu erreichen. Dabei werden geltende Gesetze im Problemumfeld befriedigt. Das Artefakt wird nach der Erstellung evaluiert. 7) Weitergabe und Kommunikation der Forschung: Design Science Forschung muss sowohl technologieorientiertem, als auch managementorientiertem Publikum effektiv präsentiert werden. Ein Zwischenstand dieser Arbeit wurde bereits einem technologieorientiertem Publikum präsentiert. Zusätzlich befindet sich im Anhang (siehe Anhang A) eine Installations- und Konfigurationsanleitung, die sowohl für technische- als auch managementorientierte Anwender geschrieben wurde. 7

20 3 Motivation, Problemstellung und Aufbau der Arbeit 3.1 Motivation Die regulatorischen Anforderungen an Unternehmen haben in den letzten Jahren immer mehr zugenommen (Kley 2008, 14). Dies ist nicht zuletzt Ereignissen wie den Börsenskandalen von Enron und Worldcom im Jahre 2002 zu verdanken oder aber auch der Schmiergeld Affäre von Siemens im Jahre Als prominentestes Beispiel ist das bereits in der Einleitung angesprochene SOX zu nennen, das eben auf jenen Vorfall von Enron hin ins Leben gerufen wurde (Pershkow 2002, 16). So ist es nicht verwunderlich, dass Unternehmen zunächst viel dafür investieren müssen um nicht gegen diese Gesetze zu verstoßen, zumal ein Verstoß fatale finanzielle Konsequenzen nach sich ziehen kann (Pershkow 2002, 16ff.; Anon/Filowitz/Kovatch 2007, 40ff.). Mit Hilfe von Prozesskontrollen ist es möglich, die geforderte Regelkonformität, auch Compliance genannt, zu gewährleisten. Dabei überwacht die Compliance durch ein vorgelagertes Risikomanagement die Risiken eines Unternehmens (Marekfia/Nissen 2009, 4). Prozesskontrollen sind in diesem Kontext innerhalb eines internen Kontrollsystems eines Unternehmens anzusiedeln. Das IKS sammelt die Anforderungen, die sich aus der Compliance ergeben und kümmert sich um die Einhaltung (Brauer et al. 2009, 22). Neben den rechtlichen Konsequenzen, gibt es noch andere Gründe für ein Unternehmen compliant zu sein. Dazu macht es Sinn das Spannungsfeld Unternehmen und seine Stakeholder genauer zu betrachten: Abbildung 2: Spannungsfeld Unternehmen Quelle: Eigene Darstellung 8

21 So bestehen auf der einen Seite des Unternehmens Beziehungen zu Lieferanten und auf der anderen zu Kunden. Wenn beim Lieferanten eine Leistung, egal ob in Form einer Ware oder einer Dienstleistung, bestellt wird, so erwartet dieser im Gegenzug, ganz im Sinne eines Kaufvertrags, dafür bezahlt zu werden. Auf der anderen Seite erwartet der Kunde für seinen finanziellen Aufwand vom Unternehmen eine Leistung geliefert zu bekommen. Ist das Unternehmen compliant, so erfüllt es die ihm obliegenden Vorschriften über das Vorhalten von ausreichend finanzieller Mittel. Der Lieferant kann somit sichergehen, bezahlt zu werden. Für den Kunden ist durch die Compliance eines Unternehmens sichergestellt, dass dieses nicht in rufschädigende Skandale verwickelt ist und sich so eine Zusammenarbeit nicht Imageschädigend auswirken kann. Für die Banken liegt der Fokus auf der Kreditwürdigkeit des Unternehmens. Der Judikative und den externen Prüfern ist dahingehend gedient, dass die regulatorischen Anforderungen eingehalten werden und keine Strafzahlungen oder Verhandlungen fällig sind. Zuletzt seien noch die Aktionäre (Shareholder) des Unternehmens genannt. Wenn das Unternehmen regelkonform ist, dann können die Aktionäre getrost investieren ohne die Befürchtung hegen zu müssen, dass ihr Kapital z.b. durch Strafzahlungen verloren gehen könnte. Auch das Rating ist für Unternehmen mit einer funktionierenden Compliance höher, als das derer mit einer weniger intakten Compliance. Ein höheres Rating impliziert neben einer höheren Absicherung gegen Risiken und Rückschläge auch einen höheren Wertzuwachs der Aktien (Holtschke/Heier/Hummel 2008, 160). Für das Unternehmen bedeutet das im Umkehrschluss einen Zufluss an Kapitel durch das somit geschaffene Vertrauen, dieses wiederrum hilft Reputationsrisiken zu minimieren und somit die Wettbewerbsfähigkeit zu erhalten (Damianides 2005, 77). Dass es für eine Firma Sinn macht, sich mit dem Thema Compliance auseinander zu setzten, zeigte jüngst eine Studie von der digital spirit GmbH, die eine Umfrage unter rund 100 Compliance Verantwortlichen durchgeführt hat. Das Ergebnis war, dass die strategische Bedeutung von Compliance in Zukunft weiter zunehmen wird. Konkret sind 79% der Befragten davon überzeugt, dass Unternehmen mit einer funktionierenden Compliance-Einheit wettbewerbsfähiger sind als andere ohne (digital spirit GmbH2011). Die wichtigste Folge der zuvor erwähnten Vertrauensbildung ist, dass damit finanzielle Mittel in das Unternehmen fließen, was wiederum dem höchsten Ziel eines Unternehmens, dem Wirtschaften, dienlich ist. Dies kann nur dann gewährleistet werden, wenn alle Risiken durch Kontrollen abgedeckt sind (Romeike 2008, 35). Neben den bereits vorgestellten externen Adressaten (Kunden, Lieferanten, etc.) gibt es auch im Unternehmen selbst Zielgruppen, die sehr daran interessiert sind, wie es um die Compliance steht: Das interne Audit und das Top-Management. Dieses im Falle des SOX Sektion 302: CEO und CFO - unterzeichnet schriftlich die eigene Verantwortung für eine verlässliche interne Finanzberichterstattung und haftet dann auch dafür (Sarbanes-Oxley Act 2002). So kann es nur in deren Sinne sein, ein ausgereiftes Kontrollsystem vorzuhalten. Um dies sicherzustellen muss das Top-Management stets mit der aktuellen Situation vertraut sein denn nur so kann auf mögliche Verstöße reagiert werden. Eine weitere interne Zielgruppe stellen die internen Prüfer dar. Ihre Aufgabe ist es effiziente und effektive Kontrollsysteme zu implementieren. Nur wenn sie über den aktuellen Compliance-Stand des Unternehmens informiert sind, können sie Kontrollen adäquat abbilden und einsetzen. Diese Arbeit zielt darauf ab, den Spagat zwischen diesen Anforderungen zu meistern. Konkret bedeutet dies, die Erstellung eines IT-gestützten Prozesskontrollsystems, zur kontinuierlichen 9

22 Überwachung des Compliance-Status in Echtzeit. Dieses Konzept, v.a. mit Einbindung der Informationstechnik, hat in den letzten Jahren immer mehr an Bedeutung gewonnen, wie eine kurze Reflektion auf die Investitionen in den Bereichen IT und GRC zeigt: Unternehmen haben nach einer kurzen Anlaufphase die Vorzüge einer GRC Plattform, die sich um die Überwachung, Einhaltung und Steuerung eines Unternehmens kümmert, erkannt. So wurden Milliarden Dollar in GRC investiert. Das ist eine Steigerung von 4% im Vergleich zu den Jahren 2008 und 2009, in denen die Wirtschaftskrise noch deutlich spürbar war (Hagerty/Kraus 2009). Dabei können etwa ein Drittel der Ausgaben, der IT zugeschrieben werden. Dennoch hat eine Umfrage unter 130 Unternehmen ergeben, dass sich immer noch 62% auf manuelle Kontrollen verlassen (Bishop/Rupprecht/Shapiro 2011, 6). Doch das soll sich ändern. Der Schritt weg von manuellen Kontrollen hin zu automatischen Kontrollen findet auch bei Wirtschaftsprüfungsunternehmen immer mehr Anklang. So hat Pricewaterhouse Coopers kürzlich seine Meinung zu der Zukunft des Internen Audit Prozesses verkündet: Ein technologiebasiertes Framework, dass nicht nur jährlich oder periodisch die Risiken überwacht sondern kontinuierlich (PricewaterhouseCoopers 2011, 10). Ähnliches berichtet eine Studie von KPMG, die 149 deutsche mittelständische Unternehmen zu dem Thema befragt hat. Die Unternehmen sehen dabei den größten Vorteil von automatischen Kontrollen in der Erhöhung der Sicherheit, der kontinuierlichen Verbesserung der Prozesse und der Reduzierung von Wirtschaftskriminalität. Die Befragung bezüglich des Automatisierungsgrades des IKS hat ergeben, dass etwa 60% der Kontrollen in den Unternehmen automatisiert sind. Derzeit wird die automatische Überwachung von etwa 70% zumindest in Teilbereichen genutzt. Dabei setzt ist der Finanzsektor mit 80% am dominantesten. Erstaunlich ist, dass derzeit nur 37% der Befragten dafür auf IT-gestützte Systeme und Tools zurückgreifen. Doch dies ist nur eine Momentaufnahme. Der Markt für Lösungen in dem Bereich der automatischen und kontinuierlichen Überwachung wird weiter zunehmen. Immerhin beabsichtigen 90% der befragten Unternehmen die Einführung oder den Ausbau von IT-Lösungen. Ein Problem ist auch die unternehmensweite Nutzung: Bisher nutzen nur etwa 10% eine unternehmensweite automatische und kontinuierliche Prozessüberwachung (KPMG 2011). Es steckt also ein enormes Potential in diesem Thema, das es noch zu erforschen gibt. Diese Arbeit präsentiert einen ersten Ansatz zu einer kontinuierlichen, integrierten, unternehmensweiten, automatischen Prozessüberwachung. 3.2 Problemstellung und Aufbau der Arbeit Doch wie soll nun dieser Trend der steigenden regulatorischen Anforderungen adressiert werden? Die Fülle an Vorschriften nimmt stetig zu, so dass diese von Hand nicht mehr zu bewältigen sind. Gesucht ist ein durch die Informationstechnologie gestütztes Tool, das es ermöglicht alle Compliance Anforderungen zu erfassen und im Rahmen eines internen Kontrollsystems durch die Implementierung einer automatischen Prozesskontrollüberwachung zu adressieren. Dazu ist es zunächst notwendig, die Anforderungen an ein IT-gestütztes System anhand den bereits benutzen manuellen Kontrollen herauszustellen. Wo liegen die Schwierigkeiten und besonders: An welche Grenzen stößt ein manuelles Kontrollsystem? Dann stellt sich die Frage, welche Potentiale die IT bereitstellt und wie diese helfen können automatische Kontrollen zu entwickeln. Anschließend gilt es, basierend auf identifizierten Risiken, die Kontrollen zu erstellen und in ein IT-System einzupflegen. 10

23 Dazu ist die Arbeit folgendermaßen aufgebaut: - In Kapitel 4 und 5 werden die Grundlagen für diese Arbeit geschaffen. Zunächst werden die Chancen und Risiken von Governance, Risk und Compliance vorgestellt. Dort werden Definition der jeweiligen Teilkomponenten und deren Funktionen in der integrierten Betrachtung herausgestellt. Anschließend erfolgt die Vorstellung der theoretischen Grundlagen dieser Arbeit in Kapitel 5. Begonnen wird mit dem aktuellen Stand der Forschung im Bereich Management Control, gefolgt von der Einführung eines internen Kontrollsystems im Zuge der steigenden Anforderungen an ein Unternehmen. Dazu werden nationale und internationale Beispiele vorgestellt. In einer letzten Instanz des Kontrollsystems werden anschließend die Eigenschaften von Kontrollen dargelegt. - Das Kapitel 6 geht auf die Herausforderungen bei der Umsetzung eines unternehmensweiten Prozesskontrollsystems ein. Dazu werden zunächst die Nachteile manueller Kontrollen identifiziert und anschließend mit den IT-Potenzialen, im Bereich des Business Process Reengineerings fusioniert. - Kapitel 7 befasst sich umfassend mit der Umsetzung eines IT-gestützten Prozesskontrollsystems. Dazu werden die Systemumgebung und eine generelle Erwartungshaltung vorgestellt. Als Vorbereitung der Kontrollen auf die Implementierung erfolgt eine Klassifizierung, die Entscheidungshilfe bezüglich dem Design von Kontrollen geben soll. Die Implementierung von ausgewählten automatischen Kontrollen, die den Einkaufsprozess im SAP ERP System überwachen wird im Rahmen einer Evaluierung durch einen Proof-of-Concept bestätigt. - Die Diskussion der Ergebnisse aus den Forschungsfragen erfolgt schlussendlich in Kapitel 8. Dort wird zudem auf weiterführende Problemstellungen und auf Auswirkungen für Theorie und Praxis eingegangen. - In Kapitel 9 und 10 wird die Unterstützung der wissenschaftlichen Lehre mit Hilfe der vorliegenden Arbeit dargelegt. Ein prägnantes Fazit und ein kurzer Ausblick runden die Arbeit ab. 11

24 4 Governance, Risk und Compliance 4.1 Chancen und Risiken in einer multipolaren Welt Mit dem Aufstreben der BRIC(A) Staaten ergeben sich für Unternehmen zunehmend neue Möglichkeiten. Erwähnenswert ist die enorme Geschwindigkeit der Veränderungen, welche nicht zuletzt durch die Informations- und Kommunikationstechnologie (IKT) ermöglicht wird. Für Unternehmen, die in dieser multipolaren Welt agieren, bedeuten diese Veränderungen neue Konsumentenmärkte, neue Lieferanten und Produzenten, erweiterte Finanzierungsmöglichkeiten und ein größerer Pool an hoch qualifizierten Arbeitskräften (Accenture 2007, 21ff.). Doch sollte man sich bei solch einer Entwicklung immer auch der damit verbundenen Risiken bewusst sein. Wie bereits erwähnt, stellen die steigenden regulatorischen Anforderungen hohe Bedingungen an Unternehmen. Vor allem global tätige Unternehmen, die an unterschiedlichen Finanzmärkten agieren, stehen vor der Herausforderung je nach Land unterschiedlichen Auflagen zu genügen. Weitere Risiken innerhalb den BRIC(A) Staaten ergeben sich durch die dort vorherrschende politische und soziale Instabilität. So kann ein Lieferant oder ein Produzent ausfallen, was ein großes Risiko für eine Vertragserfüllung bedeuten kann. Zudem können unterschiedliche Geschäftskulturen und rückläufige Mitarbeiterbindungen ungeahnte Probleme darstellen (Brauer et al. 2009, 8f.). Um diese Gefahren beherrschbar zu machen ist es notwendig, Risiken adäquat zu adressieren. Dazu wird eine integrierte Betrachtung herangezogen, die sich sowohl um die Risiken, als auch um deren Überwachung und Steuerung kümmert. 4.2 GRC Eine ganzheitliche Betrachtung Das Akronym GRC (Governance, Risk and Compliance) hat in den letzten Jahren, getrieben durch die wirtschaftliche Entwicklung, zunehmend Einzug in die Managementetagen vieler Unternehmen gehalten(gill/purushottam 2008, 37). Die Definitionen für diesen Begriff sind sehr vielfältig und gehen fließend ineinander über. Ein einheitliches Verständnis existiert noch nicht, wie zahlreiche wissenschaftliche Untersuchungen gezeigt haben (Racz/Weippl/Seufert 2010, 1). Interessant ist auch, dass die meisten Veröffentlichungen in dem Bereich GRC von Softwarehäusern, Analysten und Beratungsunternehmen stammen. Wobei der Begriff GRC an sich nicht neu ist. Die jeweils einzelnen Themen: Governance, Risk und Compliance stellen seit Jahren eine Herausforderung für Unternehmen und deren Manager dar. Was neu ist, ist die aufstrebende Wahrnehmung von GRC als ein integriertes Set an Konzepten das, wenn ganzheitlich unternehmensweit angewandt, erheblichen Mehrwert und Wettbewerbsvorteile für das Unternehmen liefert (PricewaterhouseCoopers 2008, 3; Gericke et al. 2009, 3; Chatterjee/Milam 2008, 167). Eine Vernachlässigung hingegen kann zu gravierenden ökonomischen Konsequenzen führen (Marekfia/Nissen 2009, 2). Dennoch sehen Unternehmen GRC vorwiegend als Kostentreiber und verpassen dadurch zum einen die direkten Vorteile eins GRC Systems, aber auch die indirekten Vorteile, die sich durch eine Geschäftsprozessoptimierung im Rahmen der Erschließung und Neuordnung von Geschäftsprozessen ergeben. 12

25 Eine für diese Arbeit passende Definition, liefert die Open Compliance & Ethics Group (OCEG): GRC ist ein System, bestehend aus Menschen, Prozessen und Technologie, das es Organisationen ermöglicht: - die Erwartungen der Stakeholder zu verstehen und zu priorisieren, - geschäftliche Ziele in Bezug auf Mehrwert und Risiken festzulegen, - Ziele zu erreichen, dabei Risikoprofile optimieren und Werte schützen, - innerhalb von legalen, vertraglichen, internen, sozialen und ethischen Grenzen zu agieren, - relevante, verlässliche und zeitgerechte Informationsbereitstellung für den jeweils passenden Stakeholder zu gewährleisten - und Effektivität und Leistung eines Systems messbar zu machen (Mitchell/Switzer 2009, 8). Kombiniert mit der Definition von Racz/Weippl/Seufert, die GRC als einen integrierten, ganzheitlichen und unternehmensweiten Ansatz betrachten (2010, 8), ist damit eine solide Grundlage für diese Arbeit geschaffen. Dabei bestehen zwischen den einzelnen Komponenten, Governance, Risk und Compliance folgende Abhängigkeiten: Abbildung 3: GRC Eine integrierte, ganzheitliche, unternehmensweite Betrachtung Quelle: Eigene Darstellung in Anlehnung an (Racz/Weippl/Seufert 2010, 8) Ein Risiko ist eine negative/positive Abweichung eines tatsächlichen von einem erwarteten Ergebnis (Gleißner 2011, 8f.). Mehrere Risiken werden im Rahmen eines Risikomanagements verwaltet. Dieses gilt als der Kernbereich von GRC und besitzt die Aufgabe, die Gesamtheit 13

26 der Aktivitäten und Maßnahmen zur zielgerichteten Identifikation, Analyse, Steuerung und Überwachung von Risiken sicherzustellen (vom Brocke 2008, 1554). Der typische Ablauf ist jedoch nur die Identifizierung und die Analyse der Risiken. Die Risikosteuerung übernimmt die Governance und die Risikoüberwachung wird von der Compliance getragen (Wiggert 2009, 217). Damit dient ein vorgelagertes Risikomanagement als Wegbereiter für Governance und Compliance. Rückwirkend bestimmen die Unternehmensziele, die aus der Governance kommen, wie wichtig diese Risiken für das Unternehmen sind. Die Compliance hilft, durch ihre Überwachung, das Risikomanagement aktuell zu halten (Stoneburner/Goguen/Feringa 2002, 4). Es besteht also ein regelrechter Kreislauf aus gegenseitigen Abhängigkeiten zwischen den einzelnen Komponenten. Diese Betrachtung unterstützt den integrierten Ansatz, den GRC verfolgt. Daher spricht man in dem Zusammenhang häufig auch von einem Enterprise Risk Management (ERM), das sich unternehmensweit um Risiken und deren Steuerung kümmert. Der Hauptunterschied zum normalen Risikomanagement besteht in der ganzheitlichen Betrachtung. Da in dieser Arbeit ohnehin nur die Gesamtbetrachtung eine Rolle spielt, seien im Folgenden die Begriffe Risikomanagement und Enterprise Risk Management synonym verwendet (D Arcy/Brogan 2001, 2f.). Die Governance stellt eine weitere Teilkomponente des GRC Ansatzes dar und kümmert sich um interne Anforderungen an ein Unternehmen (Mallin 2011, 227). Es hat die Aufgabe für eine verantwortungsvolle Unternehmensführung, basierend auf einer wertorientierten Grundlage, zu sorgen (Teubner/Feller 2008, 400). Basierend auf den Daten aus dem Risikomanagement und den Vorgaben durch die Compliance übernimmt die Governance die Führung, Kontrolle und Steuerung des Unternehmens (Götz et al. 2008, 89), mit dem Ziel, einen Interessensausgleich zwischen allen Stakeholdern (Top-Management, Aufsichtsrat, Anteilseigner, Kunden und Lieferanten) herzustellen (OECD 2004). Seit dem Platzen der Dotcom-Blase in 2001, haben Veröffentlichungen im Bereich der Compliance stark zugenommen (El Kharbili et al. 2008a). Dabei hat die Compliance das Ziel, regulatorische Anforderungen, gesetzliche Meldepflichten, Qualitätsstandards und Vertragspartnerpflichten zu überwachen (El Kharbili et al. 2008b, 2). Ziel ist es Investoren und Stakeholder vor Betrug, Korruption und unternehmerischem Fehlverhalten zu schützen (Daniel et al. 2009, 113). Im Gegensatz zur Governance bezieht sich das nicht nur auf das Management, sondern auf die gesamte Organisation (Turki/Bjekovic-Obradovic 2010; El Kharbili et al. 2008a; Syed Abdullah/Sadiq/Indulska 2010). Aufgrund dessen bedarf es einer detaillierteren Betrachtung. Der Begriff Compliance wurde bereits an vielen Stellen der Arbeit als regelkonformes Verhalten beschrieben. Grundsätzlich lässt sich der Begriff in ein enges und ein weites Begriffsverständnis unterteilen. Eng gefasst, geht es um die Einhaltung gesetzlicher Anforderungen (Hauschka 2007, 2; Klotz 2007, 14ff.). Im weiteren Sinne meint Compliance, die Einhaltung interner und externer Vorgaben (Apreda 2007, 146; Tarantino 2008, 21). Diese können verpflichtend oder aber auch freiwillig sein und können Verträge, Richtlinien, Best Practices und Standards darstellen. Neben der Einhaltung der Gesetzte und Vorschriften trägt Compliance und damit das Ganze GRC zu einem besseren Ansehen in der Öffentlichkeit bei und fördert das Vertrauen bei den Stake- und Shareholdern (Mossanen/Amberg 2008, 59). Die Folgen bei Nichteinhaltung reichen von Imageschäden bis hin zur strafrechtlichen Verfolgung aufgrund persönlicher Haf- 14

27 tung (s. SOX Sektion 802). Da dies in erster Linie das Top-Management betrifft, soll ein integriertes, ganzheitliches und unternehmensweites GRC auch als Informationsgrundlage für Entscheidungsunterstützungen dienen. Außer der Befriedigung der Stakeholder, bestehen auch für das Unternehmen durch den Einsatz eines GRC-Mangements große Nutzenpotentiale. Diese resultieren zum einen direkt aus der Zufriedenheit der Stakeholder und zum andern indirekt durch die Verbesserung der Prozesse. In dem Zusammenhang spricht man auch von Business Process Reengineering (BPR). Dabei versteht man unter BPR, das fundamentale Überdenken und die radikale Neuerstellung von Geschäftsprozessen (Akhalumeh/Ohiokha/Oseni 2010, 141). Im Zuge der Implementierung von Kontrollen in das System müssen in einem ersten Schritt die Geschäftsprozesse im Unternehmen analysiert werden. Dabei werden oft Ineffizienzen oder redundante Vorgänge festgestellt. So kann ein GRC System also auch zur Prozessverbesserung beitragen und dadurch dem Unternehmen von Nutzen sein. Dies ist allerdings nur ein Seiteneffekt, der zunächst nicht relevant für diese Arbeit ist. Die IT-Unterstützung ist ein essenzieller Teil in einem GRC System. In einem späteren Teil der Arbeit wird der Einfluss von IT auf bestehende Accouting-Systeme untersucht. Dazu ist es notwendig die Begriffe IT-GRC, IT-Risikomanagement, IT-Governance und IT- Compliance von dem IT-gestützten Verständnis abzugrenzen: Während IT-gestützt meint, dass die Prozesse mit Hilfe von IT ablaufen, geht es beispielsweise bei IT-Risikomanagement speziell um die Risiken, die die IT eines Unternehmens betreffen (Weill/Ross 2006, 4). Im Folgenden wird, wenn von IT-Compliance/IT-Governance/IT-Risikomanagement gesprochen wird, immer auch impliziert, dass die Prozesse nicht nur die IT betreffen, sondern auch ITgestützt ablaufen. IT-GRC beinhaltet folglich, das Abstützen von Prozessen durch die Informationstechnologie und behandelt Probleme der Informationssicherheit, IT-Compliance, IT- Governance und IT-Riskmanagement (Racz/Weippl/Seufert 2010, 9). 15

28 5 Compliance Anforderungen und ihre Beherrschung durch ein Internes Kontrollsystem Das Aufkommen von regulatorischen Compliance Anforderungen, wie dem SOX, erfordert die Implementierung eines effektiven internen Kontrollsystems (Zhang/Zhou/Zhou 2007, 301f.; Namiri/Stojanovic 2007) zumal Vertrauen allein nicht ausreichend ist. Dabei wurden interne Kontrollsysteme vorwiegend von Praktikern, wie z.b. Audit-Unternehmen wie die Big4, eingeführt. So werden im Folgenden nicht nur Erkenntnisse aus der Forschung sondern auch Definitionen aus der Praxis zur Beschreibung benutzt. Dennoch wird zunächst versucht eine theoretische Grundlage zu schaffen. 5.1 Theoretische Grundlagen Kontrollsysteme stellen eine fundamentale Grundlage in allen Unternehmen dar (Scott/Davis 2007, 9). Sind es doch sie, die Managern helfen, die Fähigkeiten, Aktivitäten und Leistungen ihrer Mitarbeiter mit den Unternehmenszielen zu vereinen (Cyert/March 1992; Merchant 1985). Kontrollen tragen dazu bei, die Unsicherheit zu reduzieren, die Vorhersagbarkeit zu erhöhen und vereinen unterschiedliche Verhaltensursprünge zu einem gemeinsamen Ziel für das gesamte Unternehmen (Egelhoff 1984, 73). Eine der ersten Definitionen von Kontrollen im unternehmerischen Kontext stammt von Child (1973), der annahm, dass Kontrolle die Aktivtäten einer Organisation, mit dessen Plänen, Vorschriften und Zielen vereint. Diese Definition kann mit Taylor s verbunden werden, in der Menschen und deren soziale Umgebung als Ressourcen gesehen werden, die in Prozessen dafür eingesetzt werden, Input in Output umzuwandeln (Taylor 1911). Da sich die vorliegende Arbeit mit Kontrollen im Unternehmen befasst, soll zudem eine Definition von Management Control gegeben werden. Eine der ersten auf dem Gebiet stammt von Anthony (1965), der vorschlug, dass Manager sicherstellen müssen, dass die Ressourcen erhalten bleiben und effizient und effektiv, im Rahmen einer Verankerung in den Unternehmenszielen, genutzt werden müssen (Nelson/Machin 1976, 276). Dennoch haben sich bisherige Forschungen, im Bereich Organizational Control nahezu ausschließlich darauf konzentriert Eigenschaften, Effektivität und Auswirkungen von Kontrollen (Viator/Curtis 1998; Hornik/Ruf 1997; Doty/Sen/Wang 1989; Cushing 1974; Bodnar 1975; Ashton 1974) in großen ausgereiften Unternehmen zu untersuchen. Wie die Kontrollen entstanden sind, bzw. wie sie zu dem wurden, was sie sind, dem wurde bisher wenig Aufmerksamkeit zugeteilt (Aldrich 1999, 1; Kimberly/Bouchikhi 1995). Dabei reichen die Wurzeln der Forschung in Oganizational Control bis hin zu den Ursprüngen der Modern- Organizational und Management-Science Forschung. Erste Theorien wurden von Cyert und March angestellt (1992), gefolgt von Weiteren (Perrow 1970; Woodward/Dawson/Wedderburn 1980; Thompson 1967; Williamson 1975). Doch die wohl berühmteste Theorie stammt von Ouchi (1979, 1977; 1975). Ouchi s Forschung hat ausgeprägte Ansätze entwickelt, wie Kontrollen in Unternehmen genutzt werden können (Markt-, Hierarchie-, und Clankontrollen). Dabei untersucht der Ansatz der Organizational Control Theory (OCT), die Ouchi maßgeblich geprägt hat, wie das Management spezifische Kontrollen auswählt, inklusiver der Wahl zwischen Behavior Control (Verhaltenskontrolle) und Output Control (Ergebniskontrolle). Eine Verhaltenskontrolle kontrolliert das Verhalten der Mitarbeiter während eines Prozesses; eine Ergebniskontrolle hingegen kontrolliert das Ergeb- 16

29 nis eines Prozesses und greift nicht in den laufenden Prozess ein (Eisenhardt 1985, 135). Im Laufe der Zeit wurde Ouchi s Framework von vielen weiteren Forschern aufgenommen und als Entscheidungsunterstützung beim Design von Kontrollen verwendet. 5.2 Definition und Ausgestaltung eines internen Kontrollsystems Laut dem Institut der Wirtschaftsprüfer in Deutschland (IDW), werden unter einem internem Kontrollsystem die vom Management im Unternehmen eingeführten Grundsätze, Verfahren und Maßnahmen (Regelungen) verstanden, die auf die organisatorische Umsetzung der Entscheidungen des Managements gerichtet sind - zur Sicherung der Wirksamkeit und Wirtschaftlichkeit der Geschäftstätigkeit (inklusive Schutz des Vermögens, einschließlich der Verhinderung und Aufdeckung von Vermögensschädigungen), - zur Ordnungsmäßigkeit und Verlässlichkeit der internen und externen Rechnungslegung sowie - zur Einhaltung der für das Unternehmen maßgeblich rechtlichen Vorschriften (IDW 2011, 8). Dabei obliegt die Einrichtung eines internen Kontrollsystems der Verantwortung des Managements, das laut SOX Sektion 302 auch dafür haftet und lässt sich daher im Bereich der Governance ansiedeln (Namiri/Stojanovic 2007, 1). Jedoch ist die Unternehmensleitung auch auf die Mitwirkung bestimmter Abteilungen und Interessensgruppen angewiesen. Diese sind zum einen die Fachabteilungen, die Unregelmäßigkeiten in ihren Prozessen identifizieren können, die interne Revision, die die Wirksamkeit eines IKS nachhaltig überprüft, externe Prüfer, sie sich im Rahmen der Abschlussprüfung mit dem IKS befassen und externe Interessensvertreter wie Investoren oder Gewerkschaften (Brauer et al. 2009, 32f.). Generell besteht ein IKS aus Regelungen zur Steuerung der Unternehmensaktivitäten (internem Steuerungssystem) und Regelungen zur Überwachung der Einhaltung dieser Regelungen (internes Überwachungssystem): 17

30 Abbildung 4: Aufbau - Internes Kontrollsystem Quelle: Eigene Darstellung in Anlehnung an IDW (2011, 8f.) Dabei besteht das interne Überwachungssystem aus prozessintegrierten und prozessunabhängigen Überwachungsmaßnahmen, die vor allem von der Internen Revision durchgeführt werden. Letztere prüft und beurteilt die Strukturen und Aktivitäten innerhalb eines Unternehmens. Dieser Überwachungsträger darf weder für das Ergebnis des überwachten Prozesses verantwortlich sein, noch in den Arbeitsablauf integriert werden. Daneben können sonstige prozessunabhängige Maßnahmen zur Überwachung beispielsweise vom gesetzlichen Vertreter oder in dessen Auftrag vorgenommen werden. Auf der prozessintegrierten Seite der Überwachung finden sich organisatorische Sicherheitsmaßnahmen, die durch laufende automatische Einrichtungen wahrgenommen werden. Sie beinhalten Maßnahmen, die Fehler verhindern sollen, die sich sowohl in die Ablauf- als auch in die Aufbauorganisation eines Unternehmens integrieren lassen und dadurch ein definiertes Niveau an Sicherheit gewährleisten. Die zweite prozessintegrierte Komponente stellen Kontrollen dar (IDW 2011, 8f.). Da diese in der vorliegenden Arbeit einen erhöhten Stellenwert haben, wird an dieser Stelle auf eine genauere Definition verzichtet und auf ein eigens dafür geschaffenes Kapitel verwiesen (siehe 5.5). 5.3 IKS Empfehlungen für das Management: COSO und COBIT Viele Gruppen und Organisationen haben im Laufe der Zeit Standards und Frameworks hervorgebracht, die eine Art Weisungs-Empfehlung geben, wie ein internes Kontrollsystem zu implementieren ist. Ein oft verwendetes Framework, ist das COSO (Committee of Sponsoring Organizations of the Treadway Comission). Es gilt in der heutigen Praxis de facto als Standard Framework, nicht zuletzt aufgrund der Anerkennung durch die amerikanische Börsenaufsicht SEC. Das von der Treadway Comission entwickelte Modell wird durch den so genannten COSO-Cube dargestellt (Singleton 2007, 1f.) und besteht aus Kontrollzielen, Kon- 18

31 trollkomponenten und mehreren Organisationsebenen, die sich durch ihre jeweilige Verantwortung abgrenzen (Bungartz 2009, 37-58): Abbildung 5: COSO Cube Quelle: Eigene Darstellung in Anlehnung an COSO (1992, 15) Die Kontrollziele eines internen Kontrollsystems beinhalten alle von der Unternehmensleitung festgelegten Grundsätze und Maßnahmen, um Wirksamkeit und Wirtschaftlichkeit der Geschäftstätigkeit (Operativ), Ordnungsmäßigkeit und Verlässlichkeit der internen und externen Rechnungslegung (Finanzielle Berichterstattung) sowie die Einhaltung von rechtlichen Vorschriften (Compliance) sicherzustellen. Selbstverständlich sollen alle Unternehmensprozesse ordnungsgemäß durchgeführt werden, doch ist die Finanzberichterstattung ein kritischer Prozess und bedarf daher einer besonderen Betrachtung. Weiterhing beinhaltet das COSO fünf zusammenhängende Kontrollkomponenten, die zu implementieren sind, um ein effektives IKS zu gewährleisten: - Kontrollumfeld: Hier handelt es sich um die Einstellungen, das Bewusstsein und die Maßnahmen der Führungskräfte. Ferner werden eine Management-Philosophie und die Kompetenz der Leitung festgelegt, zusammen mit ethischen Werten. Eine Qualitätssicherung ist obligatorisch. - Risikobeurteilung: Risiken müssen zunächst identifiziert werden um anschließend beurteilt und ordnungsgemäß adressiert werden zu können. Eine Erfassung erfolgt in einem Risikokatalog und auf einer Risk Map. 19

32 - Kontrollaktivitäten: Dabei geht es um die Umsetzung der Ergebnisse aus der Risikobeurteilung. Dazu müssen Kontrollziele definiert werden, die das Beherrschen der Risiken zum Ziel haben und die Erreichung der Geschäftsziele sicherstellen. - Information und Kommunikation: Ein funktionierendes IKS muss ausreichend kommuniziert werden. Das Personal muss die notwendige Information besitzen um Entscheide zu treffen. - Monitoring: Die systematische Überprüfung und Überwachung soll die Zweckmäßigkeit und dauernde Wirksamkeit des internen Kontrollsystems sicherstellen. Dabei gelten die vorgestellten Kontrollkomponenten für alle Kontrollziele und umgekehrt. Das IKS ist unternehmens- bzw. konzernweit, d.h. die Ziele und Komponenten gelten für alle Organisationseinheiten, die nach ihren jeweiligen Verantwortungen unterteilt werden können. Das dargestellte Modell von COSO stammt von 1992 und wurde im Laufe der Zeit um mehrere Komponenten erweitert. Während sich das COSO I noch vorwiegend auf die finanzielle Berichterstattung bezog, wird es im Rahmen des 2002 und damit 10 Jahre später entwickeltem COSO II um die strategische Zielsetzung und zusätzlichen Kontrollkomponenten erweitert (Ruud/Sommer 2006, 126f.): Abbildung 6: Erweiterter COSO Cube (COSO ERM) Quelle: Eigene Darstellung in Anlehnung an DIIR (2004, 5) Im Bereich der Kontrollkomponenten sind folgende Bereiche dazugekommen: Internes Umfeld bezüglich Risiko, Kontrolle, Integrität und Ethik; Zielsetzung; Identifikation von relevanten Ereignissen (Risiken, Chancen), Risikobeurteilung und Risikohandhabung. Neu hinzugekommen im Bereich der Kontrollziele ist die strategische Ausrichtung, welche sich auf das Risikomanagements auswirkt, dessen Kernelemente im Zuge der Erweiterung des COSO Cubes integriert und miteinander verknüpft wurden (durch Pfeile verbunden in Abb. 6). Dadurch wird der Enterprise Risk Management (ERM) Ansatz widergespiegelt. Das 20

33 COSO II ist damit noch risikoorientierter als das COSO I und zudem unternehmensweit ausgelegt. Ein weiteres bekanntes Framework für ein internes Kontrollsystem ist das Control Objectives for Information and Related Technology (COBIT), welches auf der Definition des COSO aufbaut. Das COBIT ist ein vertrauenswürdiger offener Standard (Pathak 2003, 33), der Unternehmen hilft ihre IT mit ihren Unternehmenszielen in Einklang zu bringen und fungiert damit als eine effektive und effiziente Grundlage für die IT-Governance (Colbert/Bowen 1996, 28). Konkret beinhaltet es 34 Kontrollziele die aus 41 internationalen Quelldokumenten entwickelt und validiert wurden, um die Balance zwischen IT-Risiko und Investitionen in IT- Kontrollen zu halten. Das COBIT ist damit ein ideales Instrument, das das Management nutzen kann um ein angemessenes Kontrollsystem für die IT zu implementieren (Lainhart 2001, 20) und diese auf die Geschäftsziele auszurichten. Zusammen mit dem COBIT wurde ein Best Practise Rahmenwerk entwickelt. Dieses stellt eigens für die IT ein Modell mit international anerkannten und anwendbaren Kontrollzielen bereit. Eine Anwendung dieser soll die Sicherheit der IT-gestützten Geschäftsprozesse gewährleisten. Neben dem COSO und dem COBIT existieren noch weitere Frameworks für interne Kontrollsysteme, auf die hier aber nicht näher eingegangen werden soll, dennoch der Vollständigkeit halber erwähnt werden (Ridley/Young/Carroll 2004, 1): Electronic Security Assurance and Control Model (esac); IT Infrastructure Library (ITIL); Guide to Assessment of IT Risk (GAIT); Information Technology Assurance Framework (ITAF); Risk IT; Val IT; Capability Maturity Model Integration (CMMI); Vergleicht man die Ansätze die das COSO und das COBIT verfolgen mit der Definition eines IKS aus der Sicht der Wirtschaftsprüfer (IDW), so lassen sich klare Unterschiede festmachen: So fordert etwa ein Wirtschaftsprüfer Einhaltung gesetzlicher Rahmenbedingungen. Das Management hingegen ist mehr auf die Erfüllung von für das Unternehmen kritische Erfolgsfaktoren und wichtigen Zielsetzungen bedacht, so genannten Key Performance Indicators (KPI). Diese können je nach Unternehmen sehr unterschiedlich sein. Denkbar sind folgende: Wettbewerbsfähigkeit steigern; Qualität steigern; Mitarbeiterfluktuation senken; Fehler auf ein Minimum reduzieren; Kundenzufriedenheit steigern etc. Diese beiden Ansichten, einmal die rechtliche und einmal die Management-Perspektive zwängen natürlich auch das IKS in eine Art Korsett: Abbildung 7: IKS zwischen IDW und COSO/COBIT Quelle: Eigene Darstellung 21

34 So muss ein effizientes und effektives IKS beiden Perspektiven Rechnung tragen. Das in dieser Arbeit untersuchte Tool von SAP, ist in der Lage das hat die Evaluation ergeben beides abzubilden. Kontinuierliche Automatische Kontrollen (CCM in Abb. 7) können sowohl rechtliche Rahmenbedingungen als auch kritische Erfolgsfaktoren adressieren. Unter einem Continuous Controls Monitoring (CCM) versteht man den Prozess der Bewertung der Wirksamkeit der internen Kontrollen in der Aufdeckung von Fehlern und Anomalien auf kontinuierlicher Basis (COSO 2008, 42). Die Ergebnisse dessen werden an das Management berichtet und tragen einerseits dazu bei die Unternehmensziele/kritische Erfolgsfaktoren zu erreichen und andererseits den rechtlichen Rahmenbedingungen (IDW) zu genügen. Die immer komplexer werdenden Accounting Informationsysteme sind heutzutage in der Lage Finanzdaten in nahezu Echtzeit zu liefern (Hunton/Mauldin/Wheeler 2008, 1551). Die Nachfrage des Managements Schwachstellen kontinuierlich und nicht nur in bestimmten Zeitintervallen zu identifizieren hat zur Entwicklung von robusten CCM Plattformen und Programmen geführt. Dies haben Brown/Wong/Baldwin in einer 80 Artikel umfassenden Literaturstudie über das Thema Continuous Auditing herausgefunden (Brown/Wong/Baldwin 2007). Continuous Auditing (CA) besitzt jedoch eine etwas andere Zielgruppe als CCM. Während CCM vorwiegend das Management adressiert, betrifft CA die interne Revision (KPMG 2011). In der Forschung werden die beiden Begriffe klar getrennt, in der Praxis jedoch ist man weniger über den Begriff, als über die Anwendung von kontinuierlichen Methoden und Technologien, besorgt (Alles/Kogan/Vasarhelyi 2008, 195). In dieser Arbeit ist CA als Teilbereich von CCM zu sehen, da dadurch die kontinuierliche Kontrollüberwachung sowohl das Management als auch die interne Revision befriedigt werden kann. CCM ist von GRC dadurch abzugrenzen, als dass CCM den kontinuierlichen Ansatz der Überwachung von automatischen Prozesskontrollen in nahezu Echtzeit verfolgt und dadurch menschliche Fehler im Prozess eliminiert und eine operative Entscheidungsunterstützung aufgrund der Aktualität der Daten liefert. Durch die ständige Überwachung können Schwachstellen mit Hilfe von CCM dauerhaft und nachhaltig aufgedeckt werden und nicht erst wenn der Verdacht besteht. CCM ist dabei als ein Werkzeug von GRC zu betrachten, das unter Einbindung von Risiken die integrierte, kontinuierliche und unternehmensweite Überwachung, gesteuert von der Governance, verfolgt. Bei den IT-Tools für CCM lassen sich zwei Varianten unterscheiden: Embedded Audit Modules (EAM), das sind Systeme die direkt in Informationssysteme (wie z.b. SAP ERP) integriert sind um die Systemaktivitäten zu überwachen (Groomer/Murthy 1989) und Monitoring Control Layer Systeme (MCL). Bei letzteren handelt es sich um externe Software die unabhängig von dem Zielsystem funktioniert aber dennoch mit diesem verbunden ist (Vasarhelyi/Alles/Kogan 2004). In dieser Arbeit wird ein MCL System verwendet. Der Vorteil in diesem System besteht darin, dass dadurch eine redundante Datenhaltung vermieden werden kann, da die Abfragen nur im Zielsystem ausgeführt werden und dann an SAP GRC Process Control weitergegeben werden. 22

35 5.4 Internationale und nationale Anforderungen Die Anforderungen an Unternehmen in Form von Gesetzen und Standards haben in den letzten Jahren immer mehr zugenommen: Abbildung 8: Gesetze, Frameworks und regulatorische Standards Quelle: Eigene Darstellung Besonders auffällig ist, dass nachdem das SOX, auf Reaktion des Bilanzskandal von Enron ins Leben gerufen wurde, weitere ähnliche Gesetze folgten. So wurden beispielsweise in Asien das Japanese- und Chinese-SOX erlassen, die ähnlich wie das amerikanische Vorbild, die Einrichtung eines IKS fordern. In Europa wurde die 8. EU-Richtlinie erlassen, die von allen Mitgliedsstaaten die Umsetzung in nationales Recht bis zum Juni 2008 forderte. Dieses Kapitel soll einen Überblick geben, welche Anforderungen es gibt und welchen Bereichen sie entstammen. Da die Compliance ein IKS bedingt, gibt es also eine Fülle von Gesetzen die zu beachten sind. Hinzu kommen oft relevante Standards, die eine Art Empfehlung abgeben und deshalb von Unternehmen übernommen werden. Eine Übersicht über bestehende Regularien und Standards, sowie deren Präsenz in der breiten Öffentlichkeit liefert das IT- Marktforschungsinstitut Gartner, in Form des alljährlich erscheinenden Hype Cycles : 23

36 Abbildung 9: Hype Zyklus für Regularien und Standards, 2010 Quelle: (Caldwell 2010) Der Hype-Zyklus von Gartner stellt dar, welche Phasen der öffentlichen Aufmerksamkeit eine neue Technologie, oder in diesem Fall die Regularien, bei deren Einführung durchlaufen. Auf der vertikalen Achse wird die Aufmerksamkeit und die Erwartung der Öffentlichkeit aufgetragen, auf der horizontalen die Zeit. Hierbei unterscheidet man zwischen fünf Phasen: Technologischer Auslöser; Gipfel der überzogenen Erwartungen; Tal der Enttäuschungen; Pfad der Erleuchtung und Plateau der Produktivität. Erst dort ist die Entwicklung bzw. Einführung der Regularien ausgereift. Dieser Hype-Zyklus unterscheidet sich vom traditionellen Zyklus dadurch, dass an der Spitze der Erwartungen die Ausgaben für Compliance sehr hoch sind. Die Regularien und Standards, die in diesem Hype-Zyklus dargestellt sind, haben signifikanten Einfluss auf die IT Organisation. Einerseits muss die IT die geforderten Anforderungen erfüllen und andererseits, tritt die IT als Unterstützer in Kraft. Im Folgenden soll an ein paar ausgewählten Gesetzen, Standards und Frameworks die Notwendigkeit eines internen Kontrollsystems herausgestellt werden: Das schon oft erwähnte SOX, schreibt im 302 explizit ein internes Kontrollsystem vor, um eine verlässliche Finanzberichterstattung zu gewährleisten. Dafür muss das Management schriftliche die eigene Verantwortung dafür unterschreiben. Das SOX hat aufgrund seiner Berühmtheit weltweit Ableger gefunden, sei es das NI in Kanada (Canadian-SOX), das Financial Instruments and Exchange in Japan (Japanese- SOX/J-SOX) oder das Basic Standard for Enterprise Internal Control in China (Chinese- SOX). Allen gemein ist, dass sie direkt ein internes Kontrollsystem fordern. 24

37 In Europa sehen die meisten Länder im Rahmen eines Corporate Governance Kodex vor, dass ein börsennotiertes Unternehmen ein Überwachungssystem einzurichten hat, dessen Kontrolle dem Prüfungsausschuss obliegt. Die 8. EU-Richtlinie ist für alle EU- Mitgliedsstaaten Pflicht und schreibt in Artikel 41, ein internes Kontrollsystems vor. In Deutschland schreiben das Aktiengesetz im 93, Abs.1 und das GmbH-Gesetz im 43, Abs. 1 deutschen Unternehmen im Rahmen ihrer Sorgfaltspflicht ein internes Kontrollsystem vor (Aktiengesetz/GmbHG 2007). Weitere wichtige deutsche Gesetzte sind das Bilanzmodernisierungsgesetz (BilMoG), das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) und das Handelsgesetzbuch (HGB), auch sie schreiben ein internes Kontrollsystem vor. Neben diesen allgemeinen Gesetzen existieren speziell für die Finanzbranche weitere Gesetze, wie das Solvency II, das Versicherungsunternehmen neben der Höhe des Minimumsolvenzkapitals auch die Einrichtung eines internen Kontrollsystems vorschreibt. Laut Gartner dauert es aber noch 2 bis 5 Jahre bis es von der Allgemeinheit angenommen wird. Basel II und bald auch Basel III sind Regularien, die an Banken gerichtet sind (Chuprunov 2011, 40-55). Auch sie schreiben ein internes Kontrollsystem vor und wie aus dem Hype-Zyklus gut ersichtlich ist, befindet sich Basel II bereits in weniger als zwei Jahren auf einem produktiven Niveau (siehe Abb. 9). 5.5 Umsetzung eines IKS durch Prozesskontrollen Klassische Kontroll-Definition In der deutschsprachigen Literatur der Betriebswirtschaft herrscht ein eindeutiges Verständnis, über das Wesen einer Kontrolle: Kontrollieren bedeutet im Grunde immer einen Soll-Ist Vergleich (Hasenack 1952, 339; Küpper 1987, 110; Wall 1999, 21). Diese Definition impliziert bereits eine prozessuale Betrachtung. D.h. es existiert ein Vergleich von einer vorgegebenen Größe mit einer tatsächlich erreichten Größe Erweiterte und für diese Arbeit gültige Definition Aufbauend auf der klassischen Definition sollen Kontrollen in dieser Arbeit auch im Hinblick auf die zu Grunde liegenden Risiken definiert werden. So sind Kontrollen Aktivitäten, die unternommen werden um entweder Risiken zu eliminieren oder sie auf ein Level zu reduzieren das akzeptierbar ist um ein angestrebtes Ziel zu erreichen (Hollander/Denna/Cherrington 2000). Dies ergibt folgendes Kontrollverständnis: Abbildung 10: Kontrollverständnis Quelle: Eigene Darstellung 25

38 Die Grafik impliziert, dass Kontrollen helfen Ziele zu erreichen, indem sie die Risiken, die eine Zielerreichung gefährden, minimieren und im besten Falle ausschließen. An dieser Stelle sei auf die Definition des internen Kontrollsystems, wie es in dem COSO Modells definiert wird, hingewiesen. Dort wird sichergestellt, dass die Unternehmensziele erreicht werden. Das erreichte Ziel kann neben der Einhaltung regulatorischer Anforderungen auch die zuverlässige externe Berichterstattung, oder aber auch operativer und strategischer Art sein Zeitpunkt von Kontrollen: Präventive vs. Detektive Kontrollen Kontrollen können zu zwei Zeitpunkten wirken: Ex ante, d.h. bevor ein Risiko überhaupt auftritt, oder im Nachhinein (ex post) um festzustellen, dass ein Risiko möglicherweise bereits aufgetreten ist (Stoneburner/Goguen/Feringa 2002, 20). In diesem Zusammenhang spricht man auch von präventiven und detektiven Kontrollen. Eine präventive (verhindernde) Kontrolle, dient der Vorbeugung und stellt sicher, dass das Risiko, das sie adressiert, gar nicht erst eintritt. Ein Beispiel für eine präventive Kontrolle ist das Prüfen des Finanzstatus und der Kreditlinie eines Kunden bevor der zugehörige Kundenauftrag erstellt wird. Wenn der Kunde die Kreditlinie überschritten hat, so wird der Mitarbeiter der den Kundenauftrag erstellen möchte darauf hingewiesen. Dieses Beispiel zeigt, dass dadurch verhindert werden kann, dass ein Auftrag angenommen wird, für den der Kunde finanziell gar nicht aufkommen kann. Eine detektive (aufdeckende) Kontrolle sammelt Daten und versucht basierend auf dieser Datenbasis zu erkennen ob ein Risiko nicht bereits eingetreten ist (Mitchell/Switzer 2009, 117). Ein Beispiel hierfür ist das Prüfen von allen Wareneingängen und allen bezahlten Rechnungen. Dabei werden die Systemreferenznummern der Wareneingänge mit den dazugehörenden Rechnungsnummern verglichen. Gibt es für eine Systemreferenznummer mehr als eine dazugehörende Rechnungsnummer, so wurde eine Rechnung mehrmals bezahlt. An diesem Beispiel ist bereits erkennbar, warum es nicht nur präventive Kontrollen geben kann. Eine derartige Prüfung stellt sich erst im Nachhinein als sinnvoll heraus, wenn ein gewisser Datenbestand als Grundlage vorhanden ist (Chen/Lee 1992, 54; Firozabadi/Tan/Lee 1999, 275) Kontrollgrund: Error oder Fraud In dieser Arbeit existieren zwei mögliche Ursachen warum eine Kontrolle implementiert werden kann: Error oder Fraud (IDW 2009, 7). Dass eine Kontrolle immer auch aufgrund von Compliance Anforderungen oder aber auch auf andere Ziele hin ausgerichtet ist, ist selbstverständlich. Es ist von einem Error die Rede, wenn unbewusst eine falsche/rechtswidrige Handlung vollzogen wird. Von Fraud, zu Deutsch auch dolose Handlung spricht man, wenn bewusst eine rechtswidrige Handlung vollzogen wird. Rechtwidrig bedeutet in diesem Falle, dass einer derartigen Handlung eine strafrechtliche Verfolgung droht. In den USA schätzt die Association of Certified Fraud Examiniers (ACFE), dass rund 5% der Gewinne, die Unternehmen machen, durch Fraud verloren gehen. Dies führte im Jahr 2009 zu einem einen Total- Verlust von 2,9 Billionen Dollar. Zum Vergleich, im Jahr 2004 betrug der Total-Verlust 0,6 Billionen Dollar. Erwähnenswert ist auch, dass es im Schnitt 18 Monate dauert, bis eine dolose Handlung aufgedeckt wird. Der Bericht basiert auf eine Studie von 1843 Fällen von Fraud, der weltweit in einem Zeitraum von Januar 2008 bis Dezember 2009 aufgezeichnet wurde (ACFE 2010, 4). Dies zeigt, dass das Thema Fraud mehr und mehr an Bedeutung gewonnen hat und eine Auseinandersetzung mit dem Thema notwendig ist. Die Forschung über Fraud beschreibt diesen, als die Interaktion von drei kausalen Einflüssen, die einen potentiellen Tä- 26

39 ter dazu veranlassen, eine dolose Handlung zu begehen (Loebbecke/Eining/Willingham 1989; Cressey 1973). Dazu hat Donald Cressey 1973 die so genannte Fraud-Triangel entwickelt (1973, 30), die die Ursachen und Formen der Wirtschaftskriminalität erklärt: Abbildung 11: Fraud Triangel Quelle: Eigene Darstellung in Anlehnung an Cressey (1973, 30) - Gelegenheit: Damit ein möglicher Täter eine dolose Handlung begeht muss er die Gelegenheit dazu haben und über die Schwächen im internen Kontrollsystem Bescheid wissen. Ferner ist es wichtig, dass der Mitarbeiter die technischen Fähigkeiten besitzt. Er muss sich zudem sicher sein, dass sein Handeln unerkannt bleibt (Albrecht/Williams/Wernz 1995, 30). Dies bedeutet, im Umkehrschluss, dass die internen Kontrollen nicht vorhanden oder ineffektiv sind. Im Vergleich zu den anderen beiden Elementen Druck und innere Rechtfertigung, besitzt Gelegenheit eine relativ geringe individuelle Komponente und kann daher vergleichsweise einfach vom Unternehmen beeinflusst werden (Odenthal 2005, 49). - Druck: Der Täter erfährt wahrgenommenen Druck bzw. befindet sich in einer Notoder Zwangslage. Laut Cressey handelt es sich um ein nach Empfinden des Täters - nicht mitteilbares, finanzielles Problem. Neuere Erkenntnisse haben jedoch ergeben, dass auch vom Management ausgesprochene Vergütungen eine Art Druck darstellen (Matoussi/Gharbi 2011). Auch das Gefühl ungerecht vergütet zu werden, Überarbeitung und fehlende Anerkennung können in diese Kategorie eingeordnet werden. Wichtig ist zudem, dass der Täter der Ansicht ist, dass sein Problem geheim gehalten werden muss (Cressey 1973, 30f.). - Innere Rechtfertigung: Der Täter muss die Tat vor der Begehung sich selbst gegenüber rechtfertigen können, da sich ein (Erst-)Täter in der Regel selbst nicht als Krimineller sieht. Klassische innere Rechtfertigungen sind Das Geld ist ohnehin nur ausgelie- 27

40 hen, Wenn das Management hohe Bonuszahlung erhält, dann ist es nur rechtens, wenn auch ich hohe Zahlungen beziehe (Loebbecke/Eining/Willingham 1989, 4); Beispiele für Fraud sind dabei vielseitiger Natur. Gängige Arten sind: Anbieterbevorzugungen, Bestechungen, Preisabsprachen, Manipulation bei Anzahlungsbeträgen, Leistungen für private Zwecke auf Unternehmenskosten (z.b. Büromaterial), unvollständige oder ausbleibende Lieferungen, minderwertige Produkte, überbewertete Rechnungen oder gar Scheinfirmen die der Mitarbeiter im Einkauf aufbaut, um sich dadurch selbst zu bereichern (Huntington/Davies 1999, 53-69). Verhindert werden kann dies nur durch den Einsatz intelligenter präventiver Kontrollen. So wird beispielsweise in Unternehmen sichergestellt werden, dass derjenige Mitarbeiter, der eine Bestellung erstellt diese nicht auch bezahlt. Das muss von einem anderen Mitarbeiter erledigt werden. Diese Aufteilung nennt man auch das Prinzip der Funktionstrennung - im Englischen Segregation of Duties (SoD) genannt und soll helfen die Möglichkeit von Fehlern und dolosen Handlungen minimieren (IDW 2006, 52). Die Funktionstrennung dient der Einhaltung des Vier-Augen Prinzips, das besagt, dass wichtige Entscheidungen nicht von einer einzelnen Person durchgeführt werden dürfen, wie z.b. die Vornahme von Kassenauszahlungen und deren Verbuchung (Bungartz 2009, 313). So ist der Einkaufsvorgang in einem ERP System auf mehrere Personengruppen aufgeteilt: Einkäufer (Bedarfsermittlung und Bestellanforderung), Materialmanager (Bestellabwicklung und Wareneingang) und Anlagenbuchhalter (Rechnungsprüfung). Um bereits begangenem Fraud, oder Verstöße an den diesen verhindernden Mechanismen aufzudecken, ist der Einsatz von detektiven Kontrollen notwendig. Jedoch kann eine dauerhafte Vermeidung von Fraud erst durch das Zusammenspiel präventiver und detektiver Kontrollen gewährleistet werden: Abbildung 12: Regelkreis - Detektive und Präventive Kontrollen Quelle: Eigene Darstellung Die detektiven Kontrollen nehmen dabei eine initiale Rolle ein, indem sie Fraud entdecken und die notwendigen Informationen zum Beheben der Schwachstelle weitergeben. Die daraus 28

41 gewonnenen Erkenntnisse fließen dann wiederrum in das Design präventiver Kontrollen ein, sodass diese in Zukunft Fraud verhindern können. Zu Beginn der Einrichtung eines IKS wird es deswegen mehr detektive Kontrollen als präventive geben, schlicht und einfach deswegen, weil eine initiale Kontrollgrundlage geschaffen werden muss. Mit steigendem Kontrollreifegrad wird sich das jedoch ausgleichen und der Idealzustand präventive und detektive Kontrollen wird sich einstellen. Die Funktionsweise erinnert dabei an einen klassischen Regelkreis (Brauer et al. 2009, 73f.) der sich selbst optimiert und dadurch eine kontinuierliche Kontrollüberwachung gewährleistet. Doch neben all diesen Vorkehrungsmaßnahmen und Aufdeckungsmechanismen darf eines nicht in Vergessenheit geraten: Selbst eine perfekt gestaltete Kontrolle ist wirkungslos, wenn der Verantwortliche, der sie einbaut, den Druck oder die innere Rechtfertigung findet, Fraud zu begehen. Die Gelegenheit ist allein durch die Tatsache, dass er die Kontrolle einbaut und damit sie und den umliegenden Prozess kennt, bereits vorhanden Häufigkeit von Kontrollen Kontrollen können zudem nach der Häufigkeit, nach der sie eingesetzt werden, unterteilt werden. Denkbar ist etwa der jährliche Einsatz, beispielsweise im Rahmen der Jahresabschlussprüfung. Zudem werden gängige Häufigkeiten eingesetzt, die sich je nach Dringlichkeit, Wichtigkeit und Umfang gliedern lassen: täglich, wöchentlich, monatlich; Je nach Anwendungsfall sind selbstverständlich auch halbmonatliche, vierteljährige oder auch halbjährliche Zeiträume denkbar. In dieser Arbeit wurden ausschließlich kontinuierliche Kontrollen erstellt. Dazu wurde ein Kontrollzeitraum festgelegt, in dem die Kontrollen auf kontinuierlicher Basis durchgeführt werden Manuelle und Automatische Kontrollen Eine weitere Klassifizierung für Kontrollen lässt sich hinsichtlich ihrer Automatisierung vornehmen. Dabei unterscheidet man zwischen manuellen und automatischen Kontrollen. Eine automatische Kontrolle wird dabei von einem System durchgeführt und erfordert in der Regel keinen manuellen Eingriff. Ist dennoch ein solcher notwendig, dann handelt es sich um eine halbautomatische Kontrolle. Dies ist der Fall, wenn beispielsweise zwei Datenbanken miteinander verglichen werden und der Mitarbeiter die vergleichenden Spalten auswählt. Automatische Kontrollen sind die wirtschaftlichsten Kontrollen für ein Unternehmen, da zum einen kein Mitarbeiter dafür eingesetzt werden muss, den man ansonsten bezahlen müsste und zum anderen eine größere Abdeckung erreicht werden kann Kontrollumgebung: Der (Geschäfts-)Prozess Nachdem der Begriff der Kontrolle mit all seinen Klassifizierungen definiert wurde, soll an dieser Stelle die Kontrollumgebung, der (Geschäfts-)Prozess vorgestellt werden. Da die Kontrollen innerhalb eines Unternehmens betrachtet werden, handelt es sich bei einem Prozess, immer auch um einen Geschäftsprozess. Die Definition eines Geschäftsprozesses hat in der Literatur sehr unterschiedliche Meinungen (Berkau/Hirschmann 1996; Hammer/Champy 1994; Jost/Scheer 1996; Österle 1995) hervorgebracht daher werden an dieser Stelle, die wichtigsten Eigenschaften eines Prozesses genannt: Ein Geschäftsprozess beinhaltet eine 29

42 zielgerichtete Aktivität, wird kollaborativ von einer Gruppe durchgeführt, überquert oftmals funktionale Grenzen und ist unweigerlich von äußeren Einflüssen oder Kunden getrieben (Ould 1995, 4ff.). Gadatsch erweitert diese Eigenschaften in dem er sagt, ein Geschäftsprozess ist eine zielgerichtete, zeitlich logische Abfolge von Aufgaben, die arbeitsteilig von mehreren Organisationen oder Organisationseinheiten unter Nutzung von Informations- und Kommunikationstechnologien ausgeführt werden können (Gadatsch 2003, 29). Diese Definition ist besonders wichtig, da sie den Einsatz von Informations- und Kommunikationstechnologie beinhaltet. In einem späteren Teil der Arbeit, wenn es um IT-gestützte Prozesse geht, ist diese Definition essenziell. Das bisher Definierte lässt sich sowohl auf technische als auch auf betriebswirtschaftliche Geschäftsprozesse anwenden. Dabei beziehen sich letztere eher auf kaufmännische Tätigkeiten, wie z.b. das Bezahlen von Rechnungen, wohingegen technische Prozesse vorwiegend in der Fertigungsindustrie anzutreffen sind (Berkau/Hirschmann 1996, 27). Diese Arbeit grenzt sich von dem technischen Begriff ab und eine Prozesskontrolle ist folglich eine Kontrolle die einen betriebswirtschaftlichen IT-gestützten Geschäftsprozess kontrolliert um die zugrunde liegenden Risiken zu eliminieren oder sie auf ein akzeptierbares Level zu minimieren Kontrollkategorien Die Kontrollen in dieser Arbeit können in drei Kontrollkategorien unterteilt werden: - Stammdatenkontrollen, überwachen Änderungen in Lieferanten-, Material-, und Informationsstammdaten. - Konfigurationskontrollen, überwachen Änderungen an Toleranzeinstellungen oder anderen Schwellenwerten im System. Allgemein gesagt, verhindern und beschränken sie Änderungen an Hardware, Software und Systemeinstellungen (Mitchell/Switzer 2009, 74). - Transaktionskontrollen, analysieren, vergleichen und bewerten bereits abgeschlossene Transaktionen im System. Diese können im Falle des Einkaufsprozesses bezahlte Rechnungen, getätigte Bestellungen, Inventurtransaktionen oder Bestandsänderungen darstellen Zusammenfassung: Kontrollverständnis An dieser Stelle soll das Kapitel der Kontrolle noch einmal zusammengefasst und in den Gesamtkontext eingeordnet werden. Kontrollen sind eine Instanz eines IKS und helfen mögliche Risiken, die auftreten können, zu verhindern oder zu eliminieren. Einteilen kann man Kontrollen hinsichtlich ihres Grundes, Häufigkeit, Automatisierungsgrades und ihrer Kategorie. Anwendet werden sie innerhalb eines Geschäftsprozesses. Mit diesem Verständnis wird deutlich, dass Kontrollen, durch ihre Anwendung im IKS helfen, die Compliance eines Unternehmens aufrecht zu erhalten und somit für eine nachhaltige Unternehmenstransparenz sorgen. Das in diesem Kapitel aufgezeigt Grundverständnis dient damit als Voraussetzung und Basis für die weiteren Ausführungen. 30

43 5.6 Rollen und Aufgaben in einem IKS Dieses Kapitel soll als Überblick dienen, welche Rollen in einem IKS eingenommen werden können und welche Aufgaben ihnen zugeteilt sind. Ein sowohl in der Praxis (Chuprunov 2011, 477), als auch in der täglichen Beratung und Prüfung (KPMG 2008, 5) typisches IKS- Szenario beinhaltet dabei Verantwortlichkeiten: Abbildung 13: Rollen im IKS Quelle: Eigene Darstellung Der IKS-Verantwortliche steht an der Spitze eines Unternehmens und hat Zugriff auf alle IKS-Objekte im Unternehmen. Angefangen von den Risiken über Kontrollen bis hin zu den Prozessen und Organisationseinheiten. Seine Aufgaben sind es das IKS zu dokumentieren, Effektivitäts-, Designtests (prüft beispielsweise ob SoDs eingehalten werden) und die Selektion und Priorisierung von Kontrollaktivitäten durchzuführen. In diesem Zusammenhang spricht man auch von Scoping. Das Ziel von Scoping ist das Priorisieren von Kontrollen. Dabei erhalten Kontrollen, die eine erhöhte Aufmerksamkeit erfordern eine höhere Gewichtung als andere. Eine hohe Priorität gilt den Kontrollen, die am wahrscheinlichsten sind, das Kontrollziel nicht erreichen. Eine weitere Aufgabe es IKS-Verantwortlichen ist die Dokumentation des IKSs. Dies geschieht in der Regel durch so genannte Risiko- und Kontrollmatrizen, aus denen ersichtlich ist, welche Risiken durch Kontrollen abgedeckt sind. Dem IKS-Verantwortlichen unterstellt ist das Management, das Zugriff hat, auf die eigene Organisation und aller sich darin befindlichen Objekte, wie Risiken, Prozesse und Kontrollen. Hauptaufgabe ist das Reporting. Es dient dazu einen Überblick über alle IKS-Objekte zu schaffen und stellt damit das Kernstück des IKSs dar, ohne dass eine automatische Prozesskontrollüberwachung nicht möglich ist. Eine weitere wichtige Aufgabe, wenn nicht die wichtigste ist das Abzeichnen aller durchgeführten Aktivitäten. In internen Kontrollsystemen 31

44 nennt man dies auch Sign-Off. Dabei kann es sich um die Kenntnisnahme von Problemen (ineffektive Kontrollen) oder um die Bestätigung der Wirksamkeit von Kontrollen handeln. Der Sign-Off stellt dabei eine systemgetriebene Unterschrift dar, mit der es auch möglich ist, die Wirksamkeit des internen Kontrollsystems abzuzeichnen. Da die Einrichtung eines solchen in US börsennotierten Unternehmen laut SOX dem CEO und dem CFO unterliegt, liegt dies in deren Verantwortung. Zudem ermöglicht diese elektronische Unterschrift eine hierarchische Reihenfolge. D.h. wenn etwas abgezeichnet wurde, kann auf den darunterliegenden Ebenen nichts mehr geändert werden. Der Zustand wird eingefroren und an die nächst höhere Ebene zur Begutachtung weitergegeben. Der Prozessverantwortliche hat wie der Name schon sagt, Zugriff auf den Prozess selbst und die einen Prozess betreffenden Objekte, wie Risiken und Kontrollen. Organisatorisch gehört der Prozessverantwortliche dem internen Audit an. Seine Aufgabe ist es Umfragen über die Effektivität von Kontrollen zu erstellen. Diese Informationen dienen dann dem IKS- Verantwortlichen beim Beurteilen der Konformität des Unternehmens. Die Behebung möglicher Risiken liegt jedoch beim Prozessverantwortlichen selbst. So kann es beispielsweise vorkommen, dass ein Risiko, welches nicht durch eine Kontrolle abgedeckt wird eine offene Schwachstelle darstellt, die bereinigt werden muss. Der von der Verantwortlichkeit her Niedrigste in der Hierarchie, ist der Kontrollverantwortliche. Seine Aufgabe ist es schlichtweg die Kontrollen durchzuführen. Dabei kann es sich sowohl um manuelle Kontrollen handeln, als auch um automatische. Hierbei handelt es sich dann um das Anstoßen der Kontrolldurchführung innerhalb eines IT-gestützten Tools (Chuprunov 2011, ). 32

45 6 Herausforderungen bei der Umsetzung eines IT-gestützen Prozesskontrollsystems Im vorigen Kapitel wurden die Grundlagen eines internen Kontrollsystems sowie die Eigenschaften von Kontrollen vorgestellt. Ziel dieser Arbeit ist es ein automatisches IT-gestütztes Prozesskontrollsystem zu implementieren. Doch zuvor ist es notwendig, sich mit den Herausforderungen bei der Umsetzung einer unternehmensweiten Prozesskontrolle an ein IT-System und dessen Ausgestaltung auseinander zusetzten. Dazu sollen zunächst die Anforderungen an ein IT-System basierend auf den Schwachstellen manueller Kontrollen herausgearbeitet und anschließend den Potentialen, die sich durch den Einsatz von IT ergeben, gegenübergestellt werden. 6.1 Schwachstellen manueller Kontrollen In Zeiten in denen die Unternehmen unter dem Druck der immer stärker zunehmenden Anforderungen stehen, ist es nicht mehr angebracht, dass das Compliance Personal flüchtige und oberflächliche Kontrollen in Teilprozessen durchführt (Turner/Di Florio 2003, 50). Diese Situation erfordert einen Wechsel hin zu regelmäßigen, kontinuierlichen Überprüfungen, die für eine nachhaltige Unternehmenstransparenz sorgen (Baldwin et al. 2005, 167). Kontinuierliche automatische Kontrollen sind für Unternehmen daher weitaus effektiver und wirtschaftlicher als manuelle Kontrollen. Diese sind fehlerbehaftet und können zudem nur langsam ausgeführt werden (Dalci/Tanış 2002, 48). Zu diesem Ergebnis kam auch das IT-Governance Institut, das argumentiert, dass es beispielsweise 1995 noch akzeptierbar gewesen sein mag, mehrere Wochen darauf zu warten, dass mit Hilfe manueller Kontrollen ein Fehler entdeckt wird. Dies ist jedoch heutzutage nicht mehr tragbar. Aufgrund der Tatsache, dass ein Fehler innerhalb von 5 Minuten oder weniger entdeckt werden muss, können manuelle Kontrollen, nicht mehr die Schlüsselrolle einnehmen (ITGI 2004, 25). In Folge dessen wird der Anspruch der Kosteneffizienz von Kontrollen immer größer. Während lang andauernde manuelle Kontrollen sehr teuer für ein Unternehmen werden können, sind automatische Kontrollen deutlich kosteneffizienter. Ferner können mit manuellen Kontrollen nicht alle relevanten Prozesse abgedeckt werden. Aufgrund dessen werden lediglich Stichproben erhoben und auf die Grundgesamtheit projiziert. Dennoch besteht hierbei das Risiko, dass Unregelmäßigkeiten nicht entdeckt werden können. Ein weiterer Nachteil von manuellen Kontrollen ist, dass dadurch häufig nur präventive Kontrollen durchgeführt werden können. Aufgrund der Komplexität mancher Prozesse ist es aber notwendig v.a. aufgrund der Datenmenge eine detektive Kontrolle durchzuführen. Gerade in Zeiten der Globalisierung ist zudem eine unternehmensweite Abdeckung von Kontrollen notwendig. Die dafür notwendige Synchronisation kann jedoch mit manuellen Kontrollen, die lediglich eine isolierte Betrachtung zulassen, nicht sichergestellt werden. Nicht außer Acht gelassen werden darf die zeitliche Abdeckung. Manuelle Kontrollen werden in der Regel auf definierte und limitierte Zeiträume angewendet. Dadurch kann es passieren, dass Fehler unerkannt bleiben, weil sie nicht innerhalb des gewählten Zeitraums auftreten. Der wichtigste bzw. schwerwiegendste Nachteil manueller Kontrollen wurde bereits genannt: Wirtschaftlichkeit. Traditionelle manuelle Kontrollaktivitäten verursachen hohe und v.a. auch wiederkehrende Kosten. Dies rührt u.a. daher, dass sie mehrfach getestet werden müssen, wohingegen automatische Kontrollen, wenn einmal getestet, beliebig oft wiederholt werden können (Brauer et al. 2009, 33ff.). Um diesen Nachteilen entgegen zu wirken, ist es also 33

46 notwendig manuelle Kontrollen durch automatische zu ersetzen. Dazu werden im Folgenden die dafür nötigen IT-Potentiale identifiziert. Vorher bleibt jedoch noch zu sagen, dass bestimmte Kontrollen manuell durchgeführt werden müssen. So können Kontrollen die eine persönliche Begutachtung, wie das Abzeichnen von Berichten, nicht automatisch durchgeführt werden. Ferner muss auch das das Testen der Kontrollen selbst in Bezug auf ihre Effektivität manuell erfolgen. 6.2 IT-Potentiale und deren Einfluss auf Kontrollen Automatische Kontrollen laufen IT-gestützt ab, welche im heutigen Zeitalter in Unternehmen nicht mehr wegzudenken sind. Es ist bewiesen, dass IT-Überwachungssysteme effektiver sind als z.b. die Systeme vor SOX, die noch nicht IT-gestützt abliefen (Masli et al. 2010, 29f.). Die Nutzung von IT bereitet Unternehmen sogar klare Wettbewerbsvorteile (Ranganathan/Brown 2006, 74; Vasile-Daniel 2010, 490) und auch wirtschaftliche Vorteile (Lim/Dehning/Richardson 2008) durch eine Kostenminimierung im Accounting Bereich (Dittmar 2007, 17). Zudem hat die Präsenz von IT spezifische Computerprogramme wie z.b. Kreditorenbuchhaltungs- oder Finanzberichterstattungssysteme (Teng/Calhoun 1996, 674) hervorgebracht. Um den zuvor genannten Nachteilen manueller Kontrollen entgegen zu wirken sollen nun Potentiale der IT identifiziert werden. Die IT ist zu einem fundamentalen Enabler in der heutigen Geschäftswelt geworden. Somit ist die Erschaffung und Erhaltung flexibler Netzwerke in der betrieblichen Praxis erst möglich geworden (Venkatraman 1994, 73). Als besonders interessant auf diesem Gebiet ist das Buch Process Innovation von Davenport (1993) zu bewerten. Process Innovation verfolgt den Ansatz, dass durch die Verschmelzung von Informationstechnologie und Personalentwicklungsmanagement, die Performance von Unternehmen verbessert werden kann. Dazu hat Davenport 7 Einflüsse von IT erkannt (Davenport 1993, 51): Auswirkung Automatisierung Informativ Sequentiell Tracking Analytisch Geographisch Integrativ Intellektuell Disintermediativ Tabelle 1: IT-Einflüsse nach Davenport Quelle: (Davenport 1993, 51) Erläuterung Die Beseitigung der menschlichen Arbeitskraft aus einem Prozess. Prozessinformationen erfassen zum Zwecke des Verstehens. Prozesssequenz ändern, oder Parallelismus ermöglichen. Genaue Überwachung des Prozessstatus und der Prozessobjekte Analyse von Informationen und Entscheidungsfindung verbessern. Prozesse über die Entfernung hinweg koordinieren Koordination zwischen Aufgaben und Prozessen. Erfassung und Verteilung von intellektuellem Vermögen. Die Beseitigung von Vermittlern innerhalb des Prozesses. 34

47 Wendet man diese Tabelle auf die Nachteile manueller Kontrolle an, so sind besonders die folgenden IT-Einflüsse interessant: Schwachstelle IT-Potential Verbesserung manuelle Kontrollen Automatisierung Dadurch können manuelle Kontrollen durch automatische Kontrollen ersetzt werden. Diese machen keine Fehler und können ein größeres Datenvolumen und damit das ganze Unternehmen abdecken. nur sehr langsame Durchführung, aufgrund von Beachtung der Prozessreihenfolge (ITGI 2004, 25) Sequentiell Prozesskontrollen müssen nicht immer mit der Reihenfolge des Prozesses übereinstimmen. Besonders vorteilhaft ist, das parallele Prüfen mehrerer Prozesse mit einem gleichzeitigen Abgleich untereinander. ab einem bestimmten Umfang: fehlende Aktualität keine Echtzeit Synchronisation möglich (Brauer et al. 2009, 52) manuelle Kontrollen sind fehlerbehaftet (Dalci/Tanış 2002, 48) Tracking Geographisch Disintermediativ Dies ermöglicht es, stets den Kontrollstatus abzufragen. Durch die Verteilung der IT ist es möglich Landesgrenzen zu überschritten und somit eine unternehmensweite Kontrollabdeckung und Synchronisation zu erreichen. Die Ergebnisse der automatisierten Kontrollen kommen direkt in das Überwachungssystem, wo sie adäquat für den Endnutzer aufbereitet werden können. Fehler bei der Übermittlung werden somit von Anfang an ausgeschlossen. Tabelle 2: Verbesserungspotentiale der IT Quelle: Eigene Darstellung 35

48 Zudem bestehen weitere Vorteile darin, die IT als Automatisierungsfaktor zu verwenden: Durch die notwendige Standardisierung der Prozesse, im Zuge der Abbildbarkeit im IT- System, kann erreicht werden, dass die Komplexität von Prozessen erheblich reduziert wird (Dameri 2009, 34). Nicht vernachlässigt werden darf der Einfluss des Internets, so kann damit ein unternehmensweiter Abgleich von Risikodaten über Landesgrenzen hinweg in Echtzeit erfolgen (Granlund 2009, 5). Dies ist besonders für international aufgestellte Konzerne von immenser Bedeutung. Bisher manuell getriebene Kontrollsysteme können also von den Potentialen, die die IT mich sich bringt, profitieren und automatisiert werden. Dies wird am Beispiel von Informationssystemen, wie Enterprise Resource Planing (ERP) Systemen klar, sie trennen Finanzdaten von Nicht-Finanzdaten und ermöglichen dadurch eine effektivere Finanzbuchhaltung (Dechow/Mouritsen 2005). In einer umfangreichen Literaturstudie wurde zudem die kritische Rolle von IT in modernen Unternehmen, besonders im Bereich der Accounting Systeme festgestellt (Efendi/Mulig/Smith 2006, 117) und auch der Einfluss der IT auf Management Kontrollsysteme ist bewiesen (Dechow/Granlund/Mouritsen 2007). Dennoch wurde diese Beziehung bisher nicht ausreichend erforscht. Es gibt bisher zwar viele Studien über die Relevanz und das Potential von IT, aber nicht über deren Einfluss auf die Accounting Literatur (Banker/Chang/Kao 2002; Granlund 2009; Sutton 2010) und umgekehrt (Anderson 2006; Bisbe/Otley 2004; Dechow/Granlund/Mouritsen 2007). Das Problem bei dieser Herangehensweise ist, dass IT und Accounting Systeme unabhängig voneinander betrachtet wurden. Als auffällig zu bewerten ist zudem die verschiedene Literatur, so lassen sich viele Fallstudien, Lösungen von Softwarehäusern und Regularien finden (Chapman/Kihn 2009; Butler/McGovern 2009; Bonazzi/Hussami/Pigneur 2010), die sich mit dem Thema auseinandersetzen. Yongmei geht sogar so weit, dass er sagt, dass kein direktes Verhältnis zwischen der Investitionen in die IT und der Firmen-Performance besteht (Yongmei/Honjian/Junhua 2008). Manche Journals bestätigen dies, indem sie die IT als einen uninteressanten Nachtrag zum Accounting ansehen (Granlund 2009, 6). Dies scheint sich dadurch zu bestätigen, dass in der Management Accounting Literatur kein einheitliches Verständnis von IT vorherrschen zu scheint. Dies ergab eine Studie in den Top Accounting Journals von Efendi/Muldig/Smith (2006) und Anderen (Dechow/Granlund/Mouritsen 2006; Woods 2009). Die Studie von E- fendi/muldig/smith über die vier bedeutendsten (US) Accounting Zeitschriften enthüllte, dass es keine Artikel gibt, die die moderne IT berücksichtigen. Der Autor dieser Arbeit schließt sich an dieser Stelle Granlund (2009), Lowe (2004) und Dechow/Mouritsen an die sagen, dass Kontrollen nicht fern von Technologie und deren Kontext studiert werden können, weil niemand jemals die darunterliegende Infrastruktur den Treffpunkt von vielen Technologien und vielen Typen von Kontrollen verstehen wird (Dechow/Mouritsen 2005, 691). Neu auf diesem Gebiet ist ein Forschungsergebnis von Xiah/Duh/Chow, die nachweisen konnten, dass sowohl Management Accounting Systeme, als auch die IT einen positiven Einfluss auf die Unternehmensperformanz haben. Die Autoren gingen sogar soweit, dass sie beweisen konnten, dass die IT teilweise als Vermittler tätig ist (Xiao/Duh/Chow 2011, 163), d.h. die Informationstechnologie beeinflusst Accounting Systeme soweit, dass eine markante Auswirkung auf die Unternehmensperformanz vorliegt. Abschließend bleibt zu sagen, dass Accounting Systeme und IT heutzutage untrennbar sind. Buchhalter nutzen anspruchsvolle Management Accounting Techniken, die ganz klar von 36

49 Existenz der IT abhängig sind. Um konkret sagen zu können, was die IT tatsächlich beiträgt und was nicht, hängt immer noch von der Entscheidung ab, wie stark die IT in das jeweilige System integriert wird (Alves 2010, 105). 37

50 7 Umsetzung eines IT-gestützten Prozesskontrollsystems am Beispiel von SAP GRC Process Control 10.0 Nachdem im vorherigen Kapitel, die Herausforderungen an ein IT-System dargestellt wurden, werden im Folgenden IKS-Kontrollen in einem IT-System implementiert. Dazu wurde SAP GRC Process Control 10.0 ausgewählt. 7.1 SAP GRC Process Control Kurzvorstellung Während SAP GRC Process Control in Gartner s Magic Quadrant GRC, das Anbieter nach definierten Kriterien innerhalb des Marktes positioniert, vergangenen Jahres noch als Visionär gelistet wurde, ist es 2011 in die Leader-Kategorie aufgestiegen (Caldwell/Scholtz/Hagerty 2011, 23). In diese Kategorie kommt demnach nur, wer neben Basisfunktionalitäten auch zusätzliche Dienste, wie Ad-Hoc Reporting oder Continuous Controls Monitoring anbietet (Caldwell/Scholtz/Hagerty 2011, 10). Die Unterstützung von CCM ist ein Grund mehr sich intensiver mit dieser Softwarelösung auseinanderzusetzen. SAP GRC Process Control 10.0 ist Teil der GRC Suite von SAP, die zusätzlich noch Risk Management, Access Control, Global Trade Services und Environment, Health und Safety Systeme enthält. SAP GRC Process Control (im Folgenden SAP PC) verfolgt einen risikobasierten Ansatz und ermöglicht eine unternehmensweite Übersicht über Kontrollen innerhalb von Geschäftsprozessen. Dabei können sowohl manuelle als auch automatische Kontrollen eingerichtet, beobachtet, getestet, bewertet und mit Hilfe von Gegensteuerungsmaßnahmen wieder in ein unkritisches Stadium überführt werden. Es können gesetzliche Vorgaben bereichsübergreifend erfüllt und zudem auch aussagekräftige Berichte erstellt werden. Compliance Rahmenwerke, wie SOX und FDA, sind bereits integriert und zudem flexibel skalierbar. SAP PC bietet vier Hauptfunktionen: Kontrolldokumentation, Kontrollevaluation, Kontrollzertifizierung und Kontrollreporting (SAP 2009). 7.2 Szenario: Automatische Überwachung von SAP ERP In den letzten 10 Jahren haben viele Unternehmen Enterprise Resource Planning (ERP) Systeme eingeführt. Die Motivation hinter diesen Investitionen ist es, die Effizienz, Effektivität und schließlich die Leistung des Unternehmens zu verbessern (Arnold 2006, 8). Dabei bilden ERP Systeme die in einem Unternehmen vorhandenen Ressourcen (Kapital, Betriebsmittel oder Personal) ab und optimieren die Steuerung von Geschäftsprozessen. Gängige ERP Systeme, wie beispielsweise SAP ERP, decken einen großen Bereich an Funktionen ab: Materialwirtschaft (Beschaffung, Lagerhaltung, Disposition, Bewertung), Produktion, Finanzund Rechnungswesen, Controlling, Personalwirtschaft, Forschung und Entwicklung, Verkauf und Marketing sowie die all-umfassende Stammdatenverwaltung (Poston/Grabski 2001; Hitt/Wu/Zhou 2002). Aufgrund spezifischer Anforderungen in der Praxis können ERP Systeme sehr komplex werden. Dem kann durch eine Anpassung der Systemeinstellungen (Customizing) entgegen gewirkt werden. Mit Hilfe des Customizings ist es bereits möglich Kontrollen in die Geschäftsabläufe zu integrieren. Beispielsweise kann die Protokollierung aller Stammdatenänderungen im Rechnungswesen automatisch vom System durchgeführt 38

51 werden. Ein weiteres Beispiel ist das Setzen eines Hakens in der Einstellung Auf Doppelte Rechnungen prüfen in den Einstellungen des Einkaufs-Customizing. Doch worin besteht das Besondere am Ansatz von SAP GRC Process Control? Kann doch ein Unternehmen einfach die Einstellung Auf doppelten Rechnungen prüfen pflegen oder die bezahlten Rechnungen und dazugehörigen Wareneingänge überprüfen und so mehrfach bezahlte Rechnungen ausfindig machen. Führt man sich jedoch die Größe und den Umfang heutiger ERP Systeme vor Augen, in denen es mehrere Tausend Rechnungen und Wareneingangsbelege zu prüfen gibt, erkennt man, dass die manuelle Durchführung auf Dauer ineffektiv und kostenaufwendig ist (siehe 6.1). Zumal eine weitreichende Abdeckung sehr zeitaufwändig ist und viele Mitarbeiter benötigt. Die Argumentation, man müsse doch nur einmal die Einstellung für die Überprüfung aktivieren ist auch nicht hinreichend. Denn was passiert wenn die Einstellung von einem Mitarbeiter bewusst oder unbewusst deaktiviert wird? Wer überprüft das auf einer kontinuierlichen Basis, damit stets gewährleistet ist, dass die Einstellung aktiv ist? Mit SAP Process Control ist es möglich, all diese Überprüfung automatisch durchführen zu lassen. Dazu kann SAP PC an ein bestehendes SAP ERP System angebunden werden und dieses automatisch überwachen. Für den Fall, dass eine wichtige Schwachstelle, die eine sofortige Bearbeitung erfordert, gefunden wird, kann im Rahmen eines Workflows sofort eine Nachricht an den betreffenden Bearbeiter geschickt werden. Dabei wird von folgender Grundüberlegung ausgegangen: Abbildung 14: Automatische Überwachung Quelle: Eigene Darstellung Die Darstellung suggeriert eine aggregierte Übersicht über den gesamten Kontrollstatus im Unternehmen. Dies ist für das Top-Management ein sehr wichtiges Instrument, um den Kontroll- und Risikostatus im Überblick zu behalten. Genau das wurde in der vorliegenden Arbeit umgesetzt. SAP GRC Process Control 10.0 wurde an ein SAP ERP System (Zielsystem) angebunden. Bei dem ERP System handelt es sich um das Demosystem der Firma SAP, die IDES AG (International Demonstration and Education System). Diese Modellfirma ist ein internationaler Konzern mit Tochtergesellschaften in verschiedenen Ländern. Das IDES System enthält beispielhafte Anwendungsdaten für unterschiedliche Geschäftssituationen. Die enthaltenen Geschäftsprozesse, sind wie in einem realen Unternehmen abgebildet und mit realistischen Merkmalen bestückt. Neben der Logistik, werden auch die Bereiche Finanzwesen und Personalwirtschaft abgedeckt. Die Besonderheit ist, dass das IDES System von der Firma SAP wie ein normales Unternehmen geführt wird und die darin enthaltenen Daten 39

52 (Stamm- und Bewegungsdaten) deshalb regelmäßig aktualisiert werden (SAP 2001, 7). Diese Tatsache ist eine wichtige Prämisse zur Durchführung dieser Arbeit, da sie den Generalisierbarkeits- und Echtheitscharakter steigert. Um gängigen Prozessen aus Logistik und Finanzbuchhaltung Rechnung zu tragen, werden mit SAP PC bereits vordefinierte Regeln für die Bereiche Financial-Close (Finanzabschluss), Procure-to-Pay (Einkaufsprozess), Order-to-Cash (Verkaufsprozess) und IT General (allgemeine Informationstechnologie) ausgeliefert. Diese können dann je nach Bedarf selbsterstellten Kontrollen zugewiesen werden und sind in der Lage folgende Kontrollkategorien abzudecken: Transaktionen, Konfigurationen und Stammdaten. In der vorliegenden Arbeit wurde der Einkaufsprozess zur Überwachung ausgewählt. Dazu werden die Regeln aus dem Bereich Procure-to-Pay selbst definierten Kontrollen zugewiesen. Die Entscheidung, den Einkaufsprozess zu überwachen, wurde maßgeblich dadurch beeinflusst, dass hierbei sowohl Finanzkontrollen, als auch Materialkontrollen ihre Anwendung finden und dadurch ein breites Spektrum an unterschiedlichen Kontrollen abgedeckt und anschließend auch evaluiert werden kann. Der Einkaufsprozess in SAP ERP gestaltet sich dabei folgendermaßen: Abbildung 15: SAP Einkaufsprozess Quelle: Eigene Darstellung in Anlehnung an die verwendete Einkaufsprozessbetrachtung Aufgrund eines Rückgangs des aktuellen Bestandes, ist es notwendig eine Materialbestellung auszulösen. Dazu erstellt der Mitarbeiter aus der entsprechenden Abteilung eine Bestellanforderung. Diese nimmt ein anderer Mitarbeiter aus dem Einkauf entgegen und wählt den Lieferanten aus, bei dem bestellt wird. Nach der Bestellung und der Benachrichtigung des Lieferanten über den Warenausgang wird die Ware versandt. Anschließend kann beim Eintreffen der Ware ein Wareneingang verbucht werden. Nach der Rechnungsprüfung wird in einem letzten Schritt die Zahlungsabwicklung eingeleitet. Um diesen Prozess zu überwachen, wurden die mitgelieferten Regeln aus dem Bereich Procure-to-pay selbstdefinierten Kontrollen zugewiesen. Insgesamt wurden 28 Kontrollen geschaffen, um den eben beschriebenen Einkaufsprozess zu überwachen. Zur Bewahrung eines Überblicks wurden die Kontrollen entsprechend ihrer Ausgestaltung in die Kategorien Kreditorenbuchhaltung, Materialwirtschaft und Einkauf eingeteilt. Die Vorstellung der Ausgestal- 40

53 tung dieser Kontrollen erfolgt im nachfolgenden Kapitel. Dort sollen diese Kontrollen klassifiziert werden. Eine Evaluierung im Rahmen eines Proof-of-Concept untermauert die aufgestellte Behauptung, dass es möglich ist, IKS-Kontrollen in ein IT-System zu überführen und dadurch eine kontinuierliche, automatische Überwachung eines Prozesses zu gewährleisten. Zum Testen dieser Behauptung wurden im Zielsystem innerhalb des Einkaufprozesses bewusst falsche Eingaben getätigt. Dies hatte zur Folge, dass von den 4 repräsentativ ausgewählten Kontrollen, allesamt ausgelöst haben. Die Behauptung wurde also bewiesen. An dieser Stelle sei erwähnt, dass nur die notwendigsten Einstellungen verwendet wurden, da das Ziel eines Proofof-Concept damit erreicht wurde. So wurde auch nur 1 User erstellt, der mit allen nötigen Rollen ausgestattet ist. In den nachfolgenden Kapiteln werden die Kontrollen zunächst klassifiziert, anschließend in SAP Process Control 10.0 zur Überwachung von SAP ERP eingepflegt und dann evaluiert. Der Implementierung und Evaluierung, liegt folgendes Grundprinzip zugrunde: Abbildung 16: Grundprinzip der Implementierung und Evaluierung Quelle: Eigene Darstellung Wie die Abbildung zeigt, kann in Skripten, die in Regeln enthalten sind, die logische Verbindung zum Zielsystem definiert werden. Die Regeln werden anschließend Kontrollen zugewiesen, welche zur automatischen Überwachung mit Hilfe des Überwachungseinplaners eingeplant werden. Dieser beinhaltet neben den zu überwachenden Kontrollen auch Angaben zum überwachenden Zeitraum und zusätzlich eine Angabe, wie oft die Kontrollen in diesem Zeitraum ausgeführt werden sollen. In dieser Arbeit wurde die kontinuierliche Ausführung eingestellt. Das Ergebnis dieser Überwachung, ist im Job Monitor einsehbar. In diesem wer- 41

54 den die die aktuellen Auswertungsdaten in nahezu Echtzeit gelistet. So ist schnell ersichtlich ob eine Schwachstelle (Error) existiert, die einen Eingriff erfordert. Zusätzlich dazu wird im Falle einer gefundenen Schwachstelle ein Workflow angestoßen, der eine Nachricht an einen zuständigen Mitarbeiter schickt. Diese beinhaltet die Schwachstelle, mit einer detaillierten Beschreibung. 7.3 Vorstellung und Klassifizierung der Kontrollen als Vorbereitung auf die Implementierung Bevor die Kontrollen in SAP PC eingepflegt werden, werden sie klassifiziert und kurz vorgestellt Auswahl einer geeigneten Klassifizierungstheorie Um die Kontrollen zu klassifizieren, muss zunächst eine geeignete Klassifizierungstheorie aus der Organizational Control Theory Literatur (Snell 1992; Ouchi 1977; Eisenhardt 1985) ausgewählt werden. Das dominanteste OCT-Model wurde von Ouchi und dessen Co-Autoren in einer Reihe von Publikationen entwickelt. Dabei haben Ouchi und McGuire angefangen, die Bedingungen zu untersuchen, nach denen das Management Ergebnis- oder Verhaltenskontrollen einsetzt (Ouchi/Maguire 1975). Dieses Modell hat Ouchi weiterentwickelt und 1979 in einer 2x2 Matrix präsentiert: Abbildung 17: Ouchi Framework Quelle: Eigene Darstellung in Anlehnung an (Ouchi 1979, 843) Ouchi s Modell teilt Kontrollen basierend der Ausprägung zweier Skalen ein: Zum einen das Wissen über den Prozess, der mit einer Kontrolle bestückt werden soll und zum andern die Fähigkeit das Ergebnis des Prozesses zu messen. Ist die Ausprägung beider Merkmale hoch, so handelt es sich um eine Ergebnis- oder Verhaltenskontrolle. In der Regel entscheidet man sich dann für die kostengünstigere Variante (Ouchi 1979, 843). Dabei versteht man unter einer Ergebniskontrolle eine Kontrolle, die die Ergebnisse eines Prozesses reglementiert. Eine Verhaltenskontrolle hingegen kontrolliert die Tätigkeiten eines Mitarbeiters während des Prozesses (Ouchi 1977, 98). Zusammengefasst gesagt beschreibt eine Ergebniskontrolle was kontrolliert wird und eine Verhaltenskontrolle, wie kontrolliert wird. Eine hohe Ausprägung von Wissen über den Prozess und eine niedrige von Fähigkeit das Ergebnis zu messen impliziert eine Verhaltenskontrolle. Ist das Gegenteil der Fall, so handelt es sich um eine Ergebniskontrolle. Sind beide Ausprägungen niedrig, so handelt es sich um eine Soziale Kontrolle (Clan Control). In Ouchis Publikation von 1977 hieß diese Kontrolle noch Ritual Control (Ouchi 1977), die von Snell (1992) in eine Input Kontrolle umbenannt wurde. In der 42

55 vorliegenden Arbeit trägt sie den Namen Soziale Kontrolle, da diese Bezeichnung exakt das Wesen der Kontrolle wiederspiegelt. So wählt man im Rahmen dieser Kontrolle gezielt diejenigen Mitarbeiter aus, die den Prozess durchführen dürfen. Damit wurde quasi eine Art präventive Kontrolle geschaffen, die bereits im Vorfeld durch die sorgfältige Auswahl qualifizierter Mitarbeiter einen risikoarmen Prozessablauf sicherstellen soll. Dennoch soll diese Kontrolle zunächst ausgeklammert werden, da es in dieser Arbeit darum geht, Kontrollen in einem IT-System abzubilden und eine soziale Kontrolle eine unmögliche Herausforderung darstellt. Da Ouchis [ ] Conceptual Framework for the Design of Organizational Control (Ouchi 1979) das meist zitierte Framework in Literaturrecherchen und perhaps the most well known among organizational control (Cardinal/Sitkin/Long 2004, 1) ist, wird es für diese Arbeit als Klassifizierungs-Theorie verwendet. Ein weiterer Grund ist, dass Ouchi ideal types von Kontrollen definiert, wo andere Theorien lediglich individuelle Elemente von Kontrollen untersuchen (Cardinal/Sitkin/Long 2002, 4). Ouchi gibt also Entscheidungsunterstützung beim Design von Kontrollen. Um Ouchi korrekt anwenden zu können, müssen zunächst die zugrundeliegenden Entscheidungskriterien (Fähigkeit das Ergebnis zu messen und Wissen über den Prozess) abgeleitet werden Skalenerstellung Um die theoretische Linse der OCT auf die Kontrollen anzuwenden, müssen zunächst die Dimensionen, Ability to measure Output (AtmO)- Fähigkeit das Ergebnis zu messen und Knowledge of the Transformation Process (KTP) - Wissen über den Prozess operationalisiert werden. Dazu wurde die Literatur nach Studien durchsucht, die das Ouchi Framework untersucht und angewendet haben. Tatsächlich haben im Laufe der Zeit zahlreiche Forscher im Rahmen von empirischen Studien Ouchi s Framework verwendet: Abbildung 18: Empirische Studien die Ouchi anwenden Quelle: Eigene Darstellung in Anlehnung an (Jaworski 1988; Snell 1992; Kirsch 1996; Kirsch/Ko/Haney 2010; Eisenhardt 1985; Kirsch et al. 2002; Ouchi 1979) Basierend auf diesen Studien wurden die in dieser Arbeit verwendeten Skalen erstellt. Dazu wurden geeignete Items übernommen, welche Fragebögen entstammen, die in den Studien dazu verwendet wurden um Projektleiter, Controller, Abteilungs- und Bereichsleiter nach dessen Einschätzung zu einem bestimmten Merkmal zu befragen. Die Items waren nicht immer eindeutig und mussten an manchen Stellen angepasst werden, weil in dieser Arbeit keine Fragebögen zur Bewertungsdurchführung verwendet wurden. Dies geschah stets im Hinblick auf das Ziel der vorliegenden Arbeit (Umsetzung von automatischen Prozesskontrollen) und 43

56 unter Berücksichtigung der Qualitätskriterien an eine Operationalisierung: Objektivität, Reliabilität und Validität (Herzwurm/Schockert/Weinberger 1997, 17). Unter diesen Voraussetzungen, konnten folgende Skalen geschaffen werden: Fähigkeit das Ergebnis zu messen (Ability to measure Output - AtmO): Diese Skala entstand unter Berücksichtigung diverser Studien: In einer Studie von Kirsch, wurden Controller im Hinblick auf die Erreichung des Projektziels befragt (Kirsch 1996, 18). In späteren Arbeiten wurden zudem Kunden und Anbieter von Informationssystemen (Kirsch et al. 2002, 497) und Projektmanager (Kirsch/Ko/Haney 2010, 487) in Bezug auf die Zielerreichung befragt. Snell hat mit seinen Fragebögen Führungskräfte in 102 Unternehmen befragt (Snell 1992, 326). Basierend auf diesen Daten, wurden für diese Arbeit drei passende Items abgeleitet: ITEM BESCHREIBUNG Ausprägung Objektivität Quantifizierbarkeit Zielbefriedigung Dieses Item misst die zur Verfügung stehenden objektiven Daten bezüglich der Zielerreichung. Die Ergebnisse des Prozesses sind hinsichtlich ihrer Anzahl messbar, d.h. quantifizierbar. Es besteht die Möglichkeit festzustellen, ob die Ziele im Sinne der Organisation zufriedenstellend erreicht wurden. 1 (es stehen objektive Daten zur Verfügung) 0 (es stehen keine objektiven Daten zur Verfügung) 1 (Ergebnisse sind quantifizierbar) 0 (Ergebnisse sind nicht quantifizierbar) 1 (Zielbefriedigung wurde erreicht) 0 (Zielbefriedigung wurde nicht erreicht) Tabelle 3: Skala - Fähigkeit das Ergebnis zu messen Quelle: Eigene Darstellung Das erste Item ist Objektivität und besagt, dass die Fähigkeit, das Ergebnis zu messen besser ausgeprägt ist, wenn objektive Daten bezüglich der Zielerreichung vorliegen. Dies ist beispielsweise der Fall, wenn Stammdaten von Mandanten hinsichtlich deren Eigenschaft ob sie Produktiv-Mandanten sind, untersucht werden müssen. Es reicht zu prüfen, ob der Status auf produktiv steht oder nicht. Das zweite Item ist die Quantifizierbarkeit der Ziele, d.h. in welchem Ausmaß die gesetzten Ziele erreicht werden. Das dritte Item ist die Zielbefriedigung und beschäftigt sich mit der Frage, ob der Prozess die Ziele einer Organisation befriedigt. 44

57 Wissen über den Prozess (Knowledge of the Transformation Process - KTP): Für diese Skala wurden dieselben Studien, wie für die Fähigkeit das Ergebnis zu messen zugrunde gelegt (Snell 1992, 326; Kirsch 1996, 18; Kirsch/Ko/Haney 2010, 486; Kirsch et al. 2002, 497): ITEM BESCHREIBUNG AUSPRÄGUNG Einfachheit Formulierung Einordbarkeit Es besteht ein grundlegendes Wissen über die Abläufe in der Organisation. Die Durchführung der Aufgaben in einem Prozess ist klar formuliert. Die vorhandene Expertise über den Prozess, ermöglicht eine klare Einordnung desselben. 1 (es besteht grundlegendes Wissen) 0 (es besteht kein Wissen) 1 (klare Formulierung) 0 (keine klare Formulierung) 1 (Prozess kann eingeordnet werden) 0 (Prozess kann nicht eingeordnet werden) Tabelle 4: Skala - Wissen über den Prozess Quelle: Eigene Darstellung Das erste Item ist Einfachheit und besagt, dass das Wissen über den Prozess groß sein muss, wenn der Prozess sehr einfach ist. Das zweite Item ist Formulierung und besagt, dass die Aufgaben in den Prozessen klar formuliert und dokumentiert sind. Das dritte Item beschreibt die Einordbarkeit des Prozesses in den Gesamtzusammenhang des Unternehmens. Beispielsweise ist der Prozess Bestellung durchführen notwendig um die Produktion mit Material zu versorgen. Nachdem nun die Skalen für die beiden Dimensionen des Ouchi-Frameworks feststehen, werden im Folgenden die Skalen für die Ergebnis- und Verhaltenskontrollen vorgestellt. Diese sind notwendig, um sagen zu können, ob die erste Messung bezüglich der Dimensionen korrekt ist, oder ob es Abweichungen gibt. Wie schon bei den Achsen des Kontrollframeworks von Ouchi, gibt es auch hier zahlreiche Studien, die Ouchi implementiert haben (Tiwana/Keil 2009, 40, 2007, 634; Tiwana 2010, 125, 2008, 780; Jaworski/MacInnis 1989, 416; Snell 1992, 326; Kirsch 1996, 18; Cardinal 2001, 32; Kirsch et al. 2002, 497). 45

58 Ergebniskontrolle: Es konnten drei Items ausgewählt werden, die bei der Fragestellung helfen, ob die Ausprägung für eine Ergebniskontrolle hoch oder niedrig ist: ITEM BESCHREIBUNG AUSPRÄGUNG Zielspezifikation Zielumfang Prozessende Ziele müssen klar gesetzt sein und kommuniziert werden. Das Ausmaß zu dem das Ziel erreicht werden kann, kann gemessen werden. Kontrolle wird am Ende des Prozesses ausgeführt. 1 (Ziel klar gesetzt) 0 (kein klares Ziel) 1 (Ausmaß der Zielerreichung feststellbar) 0 (Ausmaß der Zielerreichung nicht feststellbar) 1 (Ausführung am Ende) 0 (Prozess ist nach der Kontrolle nicht zu Ende) Tabelle 5: Skala - Ergebniskontrolle Quelle: Eigene Darstellung Das erste Item ist Zielspezifikation und besagt, dass wenn Ziele klar gesetzt (Cardinal 2001, 32; Kirsch et al. 2002, 497) und kommuniziert (Kirsch 1996, 18) werden, die Wahrscheinlichkeit hoch, dass es sich um eine Ergebniskontrolle handelt. Wenn zudem Ziele derart spezifisch sind, dass sogar das Ausmaß der Zielerreichung (Jaworski/MacInnis 1989, 416; Kirsch et al. 2002, 497) vorhergesagt werden kann, dann es ist umso wahrscheinlicher, dass es sich um eine Ergebniskontrolle handelt. Somit ist das zweite Item der Zielumfang. Das dritte Item ist Prozessende und beschäftigt sich damit, ob die Kontrolle am Ende eines Prozesses durchgeführt wird, was für eine Ergebniskontrolle sprechen würde, oder ob nach der Kontrolle noch eine zu bearbeitende Aufgabe folgt. Verhaltenskontrolle: ITEM BESCHREIBUNG AUSPRÄGUNG Zentralisierung Formulierung Gibt an ob die Entscheidungsfindung, bzw. Grundsätze und Richtlinien im Prozess delegiert wurden. Die Kontrollen sind in formalen Richtlinien beschrieben und beinhalten klare Schritte, die befolgt werden 1 (Entscheidungen wurden nicht delegiert) 0 (Entscheidungen wurden delegiert) 1 (zu befolgende Schritte vorhanden) 0 (zu befolgende Schritte 46

59 Kontrollhäufigkeit müssen. Häufigkeit mit der Kontrolle und Bewertung durchgeführt wird. nicht vorhanden) 1 (Kontrolle wird täglich durchgeführt) 0 (Kontrolle wird nicht täglich durchgeführt Tabelle 6: Skala - Verhaltenskontrolle Quelle: Eigene Darstellung Das erste Item ist Zentralisierung und gibt an, ob die Entscheidungsfindung bzw. Grundsätze und Richtlinien innerhalb einer Kontrolle an Mitarbeiter delegiert wurden. Wurden wenig bis gar keine Entscheidungen delegiert, so handelt es sich mit hoher Wahrscheinlichkeit um eine Verhaltenskontrolle (Snell 1992, 326; Cardinal 2001, 32). Das zweite Item ist Formulierung und besagt, dass Kontrollen, die in formalen Richtlinien beschrieben und deren Schritte klar zu befolgen sind, mit hoher Wahrscheinlichkeit Verhaltenskontrollen darstellen (Tiwana/Keil 2007, 634; Kirsch 1996, 18; Cardinal 2001, 32; Kirsch et al. 2002, 497). Das dritte Item ist die Kontrollhäufigkeit, die besagt, dass die Wahrscheinlichkeit für eine Verhaltenskontrolle groß ist, wenn Kontrollen häufig durchgeführt und bewertet werden (Snell 1992, 326; Cardinal 2001, 32). Da diese Arbeit Continuous Controls Monitoring zum Thema hat, ist jede Kontrolle, die nicht mindestens täglich (oder häufiger, sprich halbtäglich) durchgeführt wird mit null Punkten zu bewerten Vorgehen bei der Durchführung der Klassifizierung Nachdem die Skalen definiert sind, kann nun die Klassifizierung durchgeführt werden. Vorbild für die hier erstellten Kontrollen sind die mit SAP Process Control ausgelieferten Regeln und die von SAP bereitgestellte Dokumentation auf help.sap.com. Eine detaillierte Übersicht darüber befindet sich zudem im Anhang (Anhang B). Insgesamt werden 28 Kontrollen zur Überwachung des Einkaufsprozesses, die auch im System implementiert werden sollen, vorgestellt und klassifiziert. Dabei sind alle 28 vorgestellten Kontrollen detektive Kontrollen. Der Name der Kontrolle (Kontrolle_Nr) ist derselbe, unter dem die Kontrolle im System abgebildet wird. Der Klassifizierung liegt dabei folgende Überlegung zugrunde: 47

60 Abbildung 19: Grundüberlegung zur Klassifizierung Quelle: Eigene Darstellung Mit Hilfe der erstellten Skalen für Wissen über den Prozess und Fähigkeit das Ergebnis zu messen werden zunächst die Kontrollen klassifiziert. Dabei beziehen sich die beiden Dimensionen auf die Aufgaben, die den Kontrollen zugrunde liegen. Dies kann muss aber nicht das Risiko eines Prozesses sein. Vielmehr handelt es sich dabei um den gefährdeten Prozess, aufgrund dessen die Kontrolle eingerichtet wurde (1). Die Punktevergabe erfolgte dabei für jede Dimension separat, wie folgt: Wenn ein Item zutrifft, wird jeweils ein Punkt vergeben; wenn nicht null Punkte. Die Summe über alle drei Items entscheidet über die Einordnung in der Ergebnismatrix:. Abbildung 20: Bewertungsschema für Dimensionen Quelle: Eigene Darstellung 48

61 Nachdem alle Kontrollen anhand der Dimensionen klassifiziert worden sind, erfolgt ein erneuter Durchgang, mit dem Unterschied, dass hierbei die Skalen Verhaltenskontrolle und Ergebniskontrolle angewendet werden (2). Es wird getestet, ob es sich wirklich um die in Vorgang (1) erhaltene Kontrolle handelt. Das Framework wird also gegengeprüft, um zu sehen, ob Ouchi mit seiner Art, Kontrollen zu klassifizieren, Recht behält und damit das Framework als Entscheidungsgrundlage für das Design von Kontrollen beiträgt. Dabei ist zu beachten, dass (1) und (2) unabhängig voneinander durchgeführt werden müssen, um gegenseitige Beeinflussungen zu vermeiden Ergebnis der Klassifizierung und Vorstellung der Kontrollen Die Klassifizierung bezüglich der Kriterien, Fähigkeit das Ergebnis zu messen (AtmO) und Wissen über den Prozess (KTP) ist abgeschlossen. Die nachfolgende Tabelle zeigt das Ergebnis sowohl hinsichtlich der Einordnung der Kontrollen bezüglich der zwei Dimensionen als auch die Gegenprüfung, ob die theoretische Linse der Kontrolltheorie recht behält (Spalte OK? ). Dabei ist zu erwähnen, dass die Kontrollen im Hinblick auf die Dimensionen, entgegen der Darstellung in der Tabelle, unabhängig von der Betrachtung ob es sich tatsächlich um eine Ergebniskontrolle (OC) oder Verhaltenskontrolle (BC) handelt, klassifiziert wurden: NR Beschreibung AtmO/K Ergebnis OC/BC Ergebnis OK? TP 01 Lieferantenstammdaten Änderungen 3/2 OC BC 2/2 OC BC bedingt 02 Doppelte-Rechnung Parameter Änderung 3/2 OC BC 2/2 OC BC bedingt 03 Aufgeteilte Lieferantenrechnungen 2/1 OC 3/2 mehr OC bedingt 04 Zahlung ohne Wareneingangsbeleg 3/2 OC BC 3/3 OC BC bedingt 05 Zahlung ohne Wareneingangsbeleg (Buchungskreisebene) 3/2 OC BC 3/3 OC BC bedingt 06 Änderung an Rechnungs- 3/2 OC BC 2/2 OC BC bedingt Toleranzeinstellungen 07 Überbezahlte Rechnungen 3/2 OC BC 3/2 mehr OC bedingt 08 Überbezahlte Rechnungen (Buchungskreisebene) 3/2 OC BC 3/2 mehr OC bedingt 09 Zeigt doppelt gezahlte Rechnungen 3/2 OC BC 3/2 mehr OC bedingt 10 Materialpreisänderung 0/3 BC 3/3 OC BC bedingt 11 Inventurbeleg-Datum ungleich Systemdatum 1/3 BC 2/2 OC BC bedingt 12 Inventurbeleg-Datum ungleich Systemdatum 1/3 BC 2/2 OC BC bedingt (Buchungskreisebene) 13 Änderungen an Inventur- 1/3 BC 2/2 OC BC bedingt Toleranzeinstellungen auf Belegebene 14 Änderungen an Inventur- 1/3 BC 2/2 OC BC bedingt Toleranzeinstellungen 15 Änderungen an Inventurtoleranzgruppen 1/3 BC 2/2 OC BC beding 16 Standardpreisänderung 0/3 BC 3/3 OC BC bedingt 17 Änderung am gleitenden Durchschnitts- 0/3 BC 3/3 OC BC bedingt preis 18 Inventurtransaktionen die auf Belegebene die Toleranzgrenzen überschreiten 1/3 BC 3/2 mehr OC nein (bedingt) 49

62 19 Inventurtransaktionen die auf Positionsebene die Toleranzgrenzen überschreiten 1/3 BC 3/2 mehr OC nein (bedingt) 2/1 OC 2/2 OC BC bedingt 20 Änderungen am Orderbuch auf Werksebene 21 Änderungen am Orderbuch 2/1 OC 2/2 OC BC bedingt 22 Bestellungen ohne Wareneingang 2/1 OC 3/2 mehr OC bedingt 23 Inkorrekte Bestellfreigabe Prozeduren 2/1 OC 2/2 OC BC bedingt 24 Inkorrekte Bestellfreigabe Schritte 2/1 OC 2/2 OC BC bedingt 25 Belegartänderungen von Bestellungen 2/1 OC 2/2 OC BC bedingt 26 Bestellung aufgrund inkorrekter Freigabeprozedur 27 Bestellung aufgrund inkorrekter Freigabeprozedur auf Belegebene 28 Änderungen an Konfigurationseinstellungen für automatische Bestellungen Tabelle 7: Ergebnis der Klassifizierung Quelle: Eigene Darstellung 2/1 OC 3/2 mehr OC bedingt 2/1 OC 3/2 mehr OC bedingt 2/1 OC 3/2 mehr OC bedingt Die erste Prüfung bezüglich der Dimensionen (Fähigkeit das Ergebnis zu messen und Wissen über den Prozess) ergab 10 Ergebniskontrollen, 10 Verhaltenskontrollen und 8 Ergebnis- oder Verhaltenskontrollen. Dabei wurde stets der der Kontrolle zugrunde liegende und damit gefährdete Prozess untersucht: Abbildung 21: Ergebnis bezüglich der Dimensionen Quelle: Eigene Darstellung Die zweite Klassifizierung bezog sich schließlich auf die Kontrolle selbst. Diese hat ergeben, dass 10 Kontrollen eher eine Ergebniskontrolle als eine Verhaltenskontrolle darstellen. 18 Kontrollen hingegen können entweder eine Ergebnis- oder eine Verhaltenskontrolle darstellen: 50

63 Abbildung 22: Ergebnis der Klassifizierung bezüglich der Kontrollen selbst Quelle: Eigene Darstellung Laut Ouchi s Framework würde man im Falle gleicher Kontrollen die kostengünstigste auswählen. Da jedoch alle in einem IT-System abgebildet sind, sind die Kosten dieser Kontrollen als gleich anzusehen. Legt man die gefundenen Ergebnisse übereinander, so stellt sich ein ernüchterndes Ergebnis ein. Entgegen der Erwartung bietet Ouchi s Framework keine Entscheidungsunterstützung beim Design von Kontrollen. Zwei Kontrollen konnten durch die zweite Prüfung widerlegt werden, jedoch auch nur unter der Bedingung, dass für die OC/BC Prüfung die stärker klassifizierte Ergebniskontrolle verwendet wird. Bei den Kontrollen handelt es sich um Kontrolle_18 und Kontrolle_19. Diese erkennen Inventurtransaktionen, welche die Toleranzgrenzen auf Beleg- und Positionsebene überschreiten. Die Klassifizierung hat also ergeben, dass das Model nur bedingt Recht hat. Eine eindeutige Entscheidungsunterstützung für das Design von Kontrollen kann basierend auf diesen Ergebnissen nicht gegeben werden. 7.4 Einpflegen der Kontrollen in SAP Process Control 10.0 Dieses Kapitel gibt einen Überblick der Vorgehensweise, um automatische Kontrollen in Process Control zu erstellen. Was die technische Installation sowie die Anbindung von SAP PC an SAP ERP angeht, so wird an dieser Stelle auf den Anhang (Anhang A) verwiesen. Die dort aufgeführten Schritte dienen gleichzeitig als Dokumentation und Vorgangsprotokoll, das dieser Arbeit zugrunde liegt Kurzvorstellung der Arbeitsoberfläche Beim Starten von SAP GRC Process Control 10.0 öffnet sich folgende Übersicht im Browser: 51

64 Abbildung 23: Process Control Startseite Quelle: SAP GRC Process Control 10.0 Auf der Startseite befinden sich folgende Funktionen: Arbeitseingang (Liste der GRC- Workflow Aufgaben), Hilfe zur Anwendung, Ad-hoc-Aufgaben (ungeplante Aufgaben ausführen), Dokumentensuche (Im System hinterlegte Dokumente suchen), Meine Objekte (Bearbeiten von GRC-Objekten) und Meine Delegation (Einer anderen Person den eigenen Zugriff delegieren). Im Bereich der Stammdaten: Organisationen (Bearbeiten der Organisationsstruktur), Risiken und Maßnahmen (Bearbeiten des Risiko- und Maßnahmenkatalogs), Auflagen und Richtlinien (Bearbeiten von Richtlinien und Auflagen), Konten (Bearbeiten von Kontengruppen), Ziele (Bearbeiten von Kontrollzielen), Berichte (Berichte für Stammdaten anzeigen) und Aktivitäten und Prozesse (Bearbeiten der Geschäftsprozesse und indirekter Entitätsebenenkontrollen). Dies ist einer der wichtigsten Bereiche, hier werden die grundlegenden IKS-Objekte wie Geschäftsprozesse, Kontrollen, Risiken und Auflagen erstellt. Letzteren können in SAP PC die Auflagen FDA oder SOX zugewiesen werden. Zur Erstellung einer Auflage sei auf den Anhang verwiesen. Im Reiter Regeleinrichtung: Fortlaufende Überwachung (Automatisches Testen und automatische Überwachung der Kontrollen einrichten), Einplanung (Einplanen der fortlaufenden Überwachung bearbeiten und Jobfortschritt verfolgen), Automatische Überwachung der älteren Versionen (Regeln Kontrollen zuweisen, Regeln und Skripte erstellen, Überwachungen einplanen und beobachten) und Berichte (Berichte für Regeln der automatischen Überwachung). Dieser Bereich ist dafür dient der automatischen Kontrollüberwachung. Im Bereich Bewertungen: Umfragen (Für Bewertungen verwendete Fragen, Antworten und Umfragen definieren), Bewertungsplanung (Planauswertung und andere Bewertungen), Manuelle Testpläne (Testpläne anlegen um manuelle Kontrolle durchzuführen) und Berichte (Anzeigen von Berichten für Auswertungen). Im Reiter Zugriffsverwaltung können GRC-Rollenzuordnungen erfasst werden, die den Benutzerzugriff auf Anwendungsdaten und Funktionen kontrollieren. Im Bereich Berichte und Analysen: Konformität (Dashboards und Berichte für Konformitätsverwaltung anzeigen) und Zugriffsverwaltung (Dashboards und Berichte für Zugriffsverwaltung anzeigen). 52

65 7.4.2 Risiken im Einkaufsprozess Im Rahmen einer genaueren Betrachtung des Einkaufprozesses konnten 9 Risiken identifiziert werden. Diese sind, wie die Kontrollen, in die Bereiche Kreditorenbuchhaltung, Materialwirtschaft und Einkauf untergliedert worden: Kreditorenbuchhaltung: - Fehler bei Lieferantenzahlung: Wenn Änderungen an den Lieferantenstammdateien vorgenommen werden, kann es zum Überschreiten der Systemkonfiguration kommen, welche üblicherweise Fehler oder Unregelmäßigkeiten in der Lieferantenzahlung verhindern soll. - Mehrfache Rechnungen bezahlen: Versehentlich mehrfach bezahlte Rechnungen bleiben möglicherweise unerkannt oder werden erst in nachfolgenden Perioden gefunden. - Rechnungen überbezahlen: Rechnungsüberbezahlungen bleiben in nachfolgenden Perioden unter Umständen unentdeckt oder unerkannt. - Unautorisierte Beschaffung von Waren oder Dienstleistungen: Nicht eingehaltene Schwellenwerte für Bestellgenehmigungsgrenzen können zu Einkaufsvereinbarungen oder tatsächlichen Einkäufen führen, welche nicht den Absichten des Managements entsprechen. - Zahlung obwohl kein Wareneingang: Unter Umständen werden Zahlungen für Waren geleistet, die niemals eingegangen sind. Materialwirtschaft: - Umfangreiche Bestandsanpassungen: Die die Buchungstoleranzeinstellungen überschreitenden Bestandstransaktionen werden manipuliert und führen so zu umfangreichen Bestandsanpassungen. - Unregelmäßigkeiten und falsche Bilanz: Bestandstransaktionen werden in einer Periode verzeichnet, in der sie nicht erfolgt sind. Dies führt zu Unregelmäßigkeiten und Falschaussagen in der Bilanz. Einkauf: - Bestellungen bei unqualifizierten Lieferanten: Eine Bestellung bei unqualifizierten Lieferanten kann dazu führen, dass Produkte die Anforderungen nicht erfüllen, Lieferpläne nicht eingehalten werden sowie das Aufkommen von Prüfungsverstoßen. - Nicht managementkonformes Handeln: Ungültige, fehlerhafte oder nicht genehmigte Änderungen an den Konfigurationen, die das Anlegen einer Bestellung zum Zeitpunkt des Wareneingangs verhindern, können nicht managementkonforme Bestellungen zur Folge haben. 53

66 In SAP PC wird im Bereich der Stammdaten ein Risikokatalog bereitgestellt, in welchen die eben genannten Risiken eingepflegt wurden: Abbildung 24: Risiken im Einkaufsprozess Quelle: SAP GRC Process Control 10.0 Einem Risiko, muss im Gegensatz zu allen anderen IKS-Objekten keine Auflage zugewiesen werden. Dies hat den Grund, dass Risiken dadurch mehrfach verwendet werden können. So können IT-Risiken sowohl Bestandteil eines FDA als auch eines SOX Compliance- Rahmenwerks sein Organisationsstruktur, Geschäftsprozesse und Kontrollen Neben den Risiken gibt es noch weitere IKS-Objekte, die erstellt werden müssen, bevor die automatische Überwachung durchgeführt werden kann. Ein solches Objekt ist die Organisationseinheit. Der erste Schritt im System ist es eine Wurzelorganisation zu erstellen und anschließend Unterorganisationen anzulegen. Dies erfolgt nicht, wie zunächst gedacht, durch einen Initial-Upload der Organisationsstruktur aus dem Zielsystem sondern muss per Hand durchgeführt werden. Der Vorteil darin besteht, dass eine eigens dafür geschaffene Kontrollorganisationsstruktur eingerichtet werden kann. Dies ist besonders für IT-Kontrollen sinnvoll, da diese bereichsübergreifend eingesetzt werden und somit Redundanzen vermieden werden können. Beispielsweise kann es im Zielsystem den Bedarf geben die Passwortstärke der Mitarbeiter sowohl im Einkauf als auch im Vertrieb zu kontrollieren. Würde die Organisationsstruktur aus dem Zielsystem übernommen werden, würde man dort in Einkauf -> IT- Kontrollen -> Passwortstärke und Vertrieb -> IT-Kontrollen -> Passwortstärke unterscheiden. Die Kontrolle für die Passwortstärke wäre also redundant. Andererseits besteht die Möglichkeit die Hierarchie in mehrere Geschäftsgebiete, wie beispielsweise Länder, einzuteilen und damit unterschiedliche Regelungen abzubilden. So kann es zwar sein, dass die Anforderungen an IT-Kontrollen in jedem Land gleich sind, jedoch europäische Finanzbuchhaltungen der 8. EU-Richtlinie und US Amerikanische dem SOX unterliegen. Um das zu gewährleisten, kann bereits auf Organisationsebene eine Auflage zugeordnet werden. Wie bereits bei der Risikoerstellung geschehen, werden auch die Organisationseinheiten in IDES-Kreditorenbuchhaltung, IDES-Materialwirtschaft und IDES-Einkauf untergliedert: 54

67 Abbildung 25: Organisationshierarchie Quelle: SAP GRC Process Control 10.0 Diese Einteilung dient nicht nur der besseren Übersicht, sondern ist auch für Auswertungen vorteilhaft. So ist das Management in der Lage, sich je nach Bedarf beispielsweise nur die Risiken oder den Kontrollstatus der IDES-Materialwirtschaft anzeigen zu lassen. Zusätzlich muss jeder Organisationseinheit eine Auflage zugeordnet werden. Letztere muss jedem IKS- Objekt, außer einem Risiko, zugordnet werden und spielt daher eine wichtige Rolle, v.a. für Reporting-Zwecke. Dabei ist zu beachten, dass Organisation, Prozess, Teilprozess und Kontrolle derselben Auflage zugeordnet werden müssen, um eine gegenseitige Verknüpfung zu gewährleisten. Nach der Erstellung der Organisation, müssen die Geschäftsprozesse definiert werden. Diese dienen dazu die Kontrollen in die Geschäftsabläufe einzubinden. Wie schon beim Organisationsaufbau, erfolgt auch dies hierarchisch und unabhängig von der Prozessstruktur im ERP. Das wiederrum heißt nicht, dass die dortige Struktur nicht wiedergegeben werden kann, sondern nur, dass Kontrollprozesse aus der Sicht der Revision erstellt werden, die sich von der operativen Sicht unterscheiden können, aber nicht zwingend muss. In dieser Arbeit stellt sich die hierarchische Abfolge wie folgt dar: Abbildung 26: Geschäftsprozesse und Teilprozesse Quelle: SAP GRC Process Control 10.0 Bei der Erstellung wurde stets die Zuordnung Prozess - Teilprozess - Kontrolle verwendet, um einerseits einer genauen Dokumentation und andererseits spezifischen Reporting Anforderungen gerecht zu werden. Insgesamt wurden folgende drei Prozesse (mit den jeweils zugehö- 55

68 rigen Teilprozessen) abgebildet: Einkauf (Orderbuch pflegen, Beschaffung durchführen, Waren und Service empfangen), Kreditorenbuchhaltung (Lieferantenstammdaten pflegen, Konten analysieren und abgleichen, Rechnungsprüfung durchführen) und Materialwirtschaft (Bestand verwalten, Konten analysieren und abgleichen, Bestandsbewertung durchführen). Nach den Teilprozessen wurden, eine Ebene tiefer die Kontrollen angelegt. Eine genauere Beschreibung erfolgt später. Auch den Geschäftsprozessen (Prozess und Teilprozess) und den Kontrollen muss eine Auflage zugewiesen werden. Zusätzlich muss bzw. kann jeder Kontrolle ein Risiko zugeordnet werden. Dabei wurde bei der Risikozuordnung der direkte Ansatz gewählt: Jeder Kontrolle kann nur das Risiko zugewiesen werden, das für den darüber liegenden Teilprozess gültig ist. Aus betriebswirtschaftlicher Sicht wird damit Antwort auf die Frage gegeben: Welche Risiken sind durch Kontrollen abgedeckt? Auf der Ebene der Teilprozesse lautet eine mögliche Fragestellung: Welche Risiken sind relevant für diesen Prozess?. Dies ist besonders für das Management interessant, das so stets einen Überblick über die Risiken und die dazugehörige Kontrollabdeckung im Unternehmen hat. Ein Risiko, das nicht von einer Kontrolle abgedeckt wird fällt sofort auf, wie folgende Übersicht zeigt: Abbildung 27: Risikodeckung auf Teilprozessebene Quelle: SAP GRC Process Control

69 Ein anderer Ansatz, wäre die Zuordnung der Risiken über die Kontrollziele. Dabei wird ein Risiko einem Kontrollziel zugeordnet und dieses wiederum einer Kontrolle. In diesem Zusammenhang spricht man auch von einer indirekten Zuordnung. Da aber in der Regel ein Kontrollziel gerade das Gegenteil eines Risikos darstellt, wurde in dieser Arbeit die direkte Zuordnung gewählt, zumal diese dem risikobasierten Ansatz eines internen Kontrollsystems am nächsten kommt. Nachdem jeder Kontrolle das passende Risiko zugeordnet worden ist, müssen die Geschäftsprozesse der jeweiligen Organisationseinheit zugewiesen werden. Damit ergibt sich folgende Gesamtstruktur: Abbildung 28: Zuordnung auf Organisationsebene Quelle: SAP GRC Process Control Kontrollaufbau und -konzept Nachdem die grundlegenden IKS-Objekte - Organisationseinheiten, Prozesse, Teilprozesse, Kontrollen, Risiken und Auflagen erstellt und miteinander verknüpft worden sind, müssen die von SAP PC mit ausgelieferten Regeln, den Kontrollen zugewiesen werden. Dazu ist das Wissen über den Aufbau einer Kontrolle unerlässlich: 57

70 Abbildung 29: Aufbau Kontrolle_09 Quelle: SAP GRC Process Control 10.0 Die Vorstellung des Aufbaus erfolgt an Kontrolle_09. Dabei handelt es sich um eine Transaktionskontrolle, die basierend auf der Systemreferenznummer doppelt gezahlte Lieferantenrechnungen im Zielsystem ausfindig macht und auflistet. Bei dem Feld Kontrollautomatisierung, wurde Automatisch angegeben, da es das Ziel ist automatische Kontrollen zu erstellen. Der Zweck ist Aufdeckend, das heißt die Kontrolle erfolgt im Nachhinein (detektiv). Diese Auswahl ist logisch, Referenznummern können erst geprüft werden, wenn sie bereits referenziert wurden. Die dann folgenden Auswahlmöglichkeiten sind Filterkriterien für spätere Auswertungen. Für automatische Kontrollen ist es wichtig, dass definiert wird wann sie stattfinden. Dies geschieht durch Festlegen eines Datums als Auslöser. In dieser Arbeit wurde jede Kontrolle kontinuierlich geschaltet. Andere mögliche Optionen an dieser Stelle wären: Jährlich, Zweiwöchentlich, Kontinuierlich, Täglich, Monatlich, Vierteljährlich, Halbmonatlich oder Wöchentlich. Soll die Kontrolle getestet, also zur automatischen Überwachung eingeplant werden, so muss eine Testautomatisierung festgelegt werden. Das Testen dieser Kontrolle erfolgt Halbautomatisch, da sie manuell von einem dafür zuständigen Mitarbeiter eingeplant werden muss. Die Kontrolle als IKS-Objekt, definiert jedoch lediglich ihre Abhängigkeit von einem Teilprozess, eines Prozesses und einer Organisationseinheit. Zudem gibt sie Auskunft über die Eigenschaften der Kontrollen, doch beinhaltet sie keine ausführbaren Kriterien. Zum Durchführen der Intention einer Kontrolle, im Falle der Kontrolle_09, die die doppelten Systemreferenznummern im Zielsystem kontrolliert, muss die Kontrolle mit einer oder mehreren Regeln verknüpft werden. Die folgende Grafik soll die weiteren Ausführungen unterstützen: 58

71 Abbildung 30: Funktionsweise von Regeln Quelle: Eigene Darstellung Eine Regel wiederrum ist mit einem zugehörigem Regelskript verknüpft, das auf Tabellenebene die Kriterien auswertet. Dazu muss im jeweiligen Regelskript ein Verweis auf das zu überwachende System (Zielsystem), in diesem Fall SAP ERP, angegeben werden. Dies ist essentieller Bestandteil der Konfiguration, ohne die eine automatische Überwachung nicht möglich ist. Die Regel, die der Kontrolle_09 zugewiesen wurde, beinhaltet Kriterien die alle Rechnungen als doppelt bezahlt deklariert, deren Systemreferenznummer zweimal vorkommt. Anschließend werden alle Rechnungen auf die das zutrifft aufgelistet. Zusätzlich wurden die Verstöße in die Kategorien Hoch, Mittel und Niedrig untergliedert. Durch diese Unterteilung, wird bestimmt ab wann eine doppelte Rechnung, überhaupt als solche aufgelistet werden muss. So ist von einem hohen Verstoß erst dann die Rede, wenn doppelt vorkommende Rechnungen je einen Betrag von übersteigen. Diese Einteilung kann je nach Bedarf erfolgen und ist abhängig von der Konstitution eines Unternehmens. Ergebnis der Arbeit ist, dass allen Kontrollen die entsprechenden Regeln aus dem mitausgelieferten Set Procure-to-Pay zugewiesen wurden. Es wurden also insgesamt 28 Kontrollen zur kontinuierlichen automatischen Überwachung des SAP ERP Einkaufprozesses implementiert. 7.5 Proof-of-Concept aus strategischer Unternehmenssicht: Einplanen der automatischen Überwachung In diesem Kapitel wird das, in 7.4 implementierte Set an Kontrollen in SAP Process Control, evaluiert. Dazu werden ausgewählte Kontrollen zur Überwachung eingeplant. Anschließend sollen durch bewusst falsche Eingaben im Zielsystem die Kontrollen ausgelöst werden. 59

72 7.5.1 Zu erfüllende Anforderungen und Evaluationsbedingungen Bevor die Kontrollen eingeplant werden, müssen die zu erfüllenden Anforderungen herausgestellt werden. Die Prämisse ist, dass es möglich ist IKS-Kontrollen in einem IT-System zu implementieren. Dies kann aufgrund der Tatsache, dass Geschäftsabläufe mit Kontrollen erstellt werden konnten, bereits als erfüllt betrachtet werden. Der zweite Teil besteht darin, die automatische Überwachung in SAP Process Control zu aktiveren und mit einem erfolgreichen Ergebnis das Auslösen von ausgewählten Kontrollen und damit das Aufdecken von Schwachstellen und Verstößen abzuschließen. Zunächst muss aber definiert werden, was unter einem erfolgreichen Ergebnis aufgrund einer kontinuierlichen automatischen Überwachung verstanden wird. Handlungsanweisung geben Debreceny et al. (2005, 10), die die folgenden Anforderungen an ein erfolgreiches Continuous Controls Monitoring Tool stellen: 1. Eine Endnutzer freundliche Umgebung, die es dem Auditor erlaubt eine Reihe von Abfragen zu erstellen, die die Integritätsbedingungen von Transaktionen testen. Dies kann entweder durch vordefinierte Abfragen, durch Modifikation vordefinierter Abfragen oder durch die Schaffung von neuen Abfragen (indem einfache Skripte zusammengebaut werden) geschehen. 2. Ein Prozess um Abfragen einzubetten und einzuplanen. 3. Eine Methode, die es erlaubt diese Abfragen kontinuierlich oder zeitlich beschränkt auf Transaktionen anzuwenden um dadurch Verstöße aufzudecken. 4. Die Eigenschaft Verstöße im Rahmen einer elektronischen Berichterstattung zu melden (z.b. durch s). 5. Die Fähigkeit Transaktionsdetails von Verstößen auf einen Sekundärspeicher zu kopieren. Diese fünf Eigenschaften eines effektiven CCM Tools, sollen im Folgenden als Evaluationsgrundlage dienen. Allein aufgrund der Tatsache, dass in der vorliegenden Arbeit bereits vordefinierte Regeln Kontrollen zugewiesen werden konnten, kann die (1.) Anforderung als erfüllt betrachtet werden. Zudem besteht auch die Möglichkeit, bereits vordefinierte Regeln zu modifizieren und auch selbst Abfragen zu erstellen. Einer Endnutzer-freundlichen Umgebung ist dahingehend Rechnung getragen, dass der Frontend-Client von SAP Process Control mit einem gängigen Internetbrowser benutzt werden kann. Es wird angenommen, dass die Nutzung eines solchen in einem Unternehmen für jeden Mitarbeiter selbstverständlich ist Durchführen der Automatischen Überwachung In diesem Kapitel wird die (2.) Anforderung an ein CCM Tool bewiesen. SAP PC stellt einen Prozess bereit namens Überwachungseinplaner bereit, der es ermöglicht, Kontrollen/Abfragen einzubetten und einzuplanen. Dort können in SAP PC sogenannte Jobs erstellt werden. Ein Job bezieht sich auf einen festgelegten Zeitraum in dem er ausgeführt wird, beinhaltet eine Häufigkeit, also wie oft er in dieser Zeit ausgeführt werden soll und beinhaltet die 60

73 Kontrollen, die dabei ausgeführt werden. So ist es möglich einen Job zu definieren, der in einem Zeitraum von drei Jahren kontinuierlich prüft ob eine Rechnung doppelt bezahlt wurde. In der vorliegenden Arbeit beschränkt sich die Zahl der einzuplanenden Kontrollen auf 4. Dabei handelt es sich um folgende Kontrollen: - Kontrolle_09: Prüft ob doppelte Rechnungen bezahlt wurden und listet diese auf. - Kontrolle_13: Überwacht die Toleranzgrenzen auf Belegebene und erkennt so Inventurabweichungen. - Kontrolle_20: Überwacht das Orderbuch auf Werksebene und erkennt Bestellungen bei unqualifizierten Lieferanten. - Kontrolle_28: Überwacht Änderungen auf Konfigurationsebene, die eine ungewollte automatische Bestellung aufgrund eines Wareneingangs zur Folge haben und dadurch eine Zuwiderhandlung gegenüber dem Management darstellen. Es wurde darauf geachtet, dass es sich dabei um repräsentative Kontrollen handelt. So wurden Kontrollen ausgewählt, die die Finanzbuchhaltung betreffen (Kontrolle_09), die Compliance Anforderungen erfüllen (Kontrolle_13), die externe Schwachstellen beinhalten (Kontrolle_20) und die interne Forderungen umsetzen (Kontrolle_28). Die 4 Kontrollen stehen damit repräsentativ für die insgesamt 28 Kontrollen in dieser Arbeit. Somit ergibt sich folgende Ansicht im Überwachungseinplaner von SAP PC: Abbildung 31: Überwachungseinplaner Quelle: SAP GRC Process Control 10.0 Der Ablauf eines Jobs ist wie folgt: Nachdem der Job erstellt worden ist, wird er abhängig vom Beginn der eingestellten Testperiode gestartet. Die Kontrollen wurden dazu aufgrund der leichteren Durchführbarkeit auf einen Zeitraum von einem Tag eingeplant. Somit wird erreicht, dass sie nur einmal ausgeführt werden. Bei der Ausführung einer Kontrolle werden die einer Kontrolle zugewiesenen Regeln angestoßen, diese wiederrum bewirken, dass das zugrundliegende Skript die Verbindung zum Zielsystem (SAP ERP) herstellt und dort auf Tabellenebene die Regelkriterien umsetzt. Grundlage für das Finden von Schwachstellen und Verstößen ist das Vorhandensein solcher. Dazu wurden im SAP ERP bewusst falsche Eingaben gemacht. Anders gesagt, es wurde 61

74 Fraud begangen. So wurden beispielsweise doppelte Rechnungen erstellt, die je einen Betrag von / / übersteigen um Kontrolle_09 in hoher / mittlerer / niedriger Priorität auszulösen. Hinzu kam, dass bereits falsche Eingaben vorhanden waren, was aufgrund der Tatsache, dass das zugrundeliegende System (IDES AG) ein Testsystem ist, nicht überrascht. Das Vorgehen zum Erstellen von Schwachstellen für die anderen Kontrollen erfolgte analog. Um sich die im Rahmen eines Jobs gefundenen Schwachstellen anzeigen zu lassen, stellt SAP PC den Job-Monitor bereit: Abbildung 32: Job Monitor Quelle: SAP GRC Process Control 10.0 Insgesamt konnten 204 Ausnahmen, also 204 Schwachstellen gefunden werden. Die Spalte Jobstatus zeigt bei allen Kontrollen den Status Fertiggestellt. Es sind also alle Kontrollen erfolgreich durchgeführt worden. Die Spalte Testergebnis zeigt bei allen Kontrollen Nicht bestanden an, d.h. die Überprüfung hat ergeben, dass die Kontrollziele (das Eintreffen der Risiken zu verhindern) nicht erfüllt wurden. Der Schwachstellen-Status steht auf Abgesendet, d.h. es wurde im Rahmen einer automatischen Workflowabwicklung eine Mitteilung an einen zuständigen Mitarbeiter gesendet. Diese enthält die notwendigen Details einer Schwachstelle, sodass sie diese sofort behoben werden kann. Im Falle von Kontrolle_09 zeigt die Auswertung folgende Rechnungen als doppelt bezahlt an: 62

75 Abbildung 33: Job Monitor - Kontrolle_09 Quelle: SAP GRC Process Control 10.0 Der Mitarbeiter, der die Nachricht erhalten hat, kann also aufgrund der Referenznummer genau nachvollziehen, welche Rechnungen an welchen Empfänger doppelt bezahlt wurden, welches Beleg- und Rechnungsdatum vorliegt und wie hoch der Betrag der Rechnung ist. Zusätzlich wird angezeigt, welche Benutzerkennung die Rechnung abgewickelt hat. Dies ist eine wichtige Information um betreffende Person auf ihr Vergehen hinzuweisen oder im Falle von Fraud zur Rechenschaft zu ziehen. Damit ist sowohl die (3.) als auch die (4.) Anforderung bewiesen. Die Abfragen wurden in einen Prozess, der diese durchführt eingebettet und gestartet. Die Ausführung konnte Schwachstellen aufdecken, die zuvor verursacht wurden. Zusätzlich wurde ein Workflow angestoßen, der einem zuständigen Mitarbeiter elektronisch die Schwachstelle zur Bearbeitung aufgezeigt hat. Ferner besteht die Möglichkeit die Informationen zu den gefundenen Schwachstellen in Form einer Excel Datei zu exportieren und auszudrucken. Damit ist auch die (5.) Anforderung an ein erfolgreiches CCM Tool erfüllt. Erwähnenswert ist an dieser Stelle noch, dass ca Datensätze untersucht worden sind, was nicht mehr als drei Minuten in Anspruch genommen hat. Allein diese Tatsache rechtfertigt eine IT-gestützte Überwachung von Kontrollen. Eine manuelle Untersuchung von Datensätzen würde mehrere Mitarbeiter über einen langen Zeitraum an diese Aufgabe binden. Zumal dann immer noch die Gefahr besteht, dass etwas übersehen wird oder andere Unregelmäßigkeiten auftreten. 63

76 7.5.3 Ergebnis der Evaluation Die Evaluation ist erfolgreich verlaufen. Die von Debreceny et al. geforderten Anforderungen an ein erfolgreiches Continuous Controls Monitoring Tool wurden alle erfüllt: Anforderung an CCM-Tool Umsetzung in SAP Process Control 10.0 Endnutzer freundliche Umgebung, die es erlaubt vordefinierte, modifizierte und selbst kreierte Abfragen zu erstellen, die die Integritätsbedingungen von Transaktionen testen Prozess um Abfragen einzubetten und einzuplanen Abfragen kontinuierlich oder zeitlich beschränkt auf Transaktionen anwenden und Verstöße aufdecken Verstöße im Rahmen einer elektronischen Berichterstattung zu melden Fähigkeit Transaktionsdetails von Verstößen auf einen Sekundärspeicher zu kopieren Webbrowser als Frontend Client; es werden vordefinierte Regeln mitgeliefert, welche Kontrollen zugewiesen wurden; diese wiederrum testen die Integritätsbedingungen von Transaktionen; Überwachungseinplaner der es ermöglicht Jobs zu erstellen und einzuplanen; Ein Job beinhaltet Kontrollen und die Angabe eines Wirkungszeitraumes in dem die Kontrollen auf Transaktionen angewandt werden; Workflow, der eine gefundene Schwachstelle an einen zuständigen Mitarbeiter zur Behebung schickt; Möglichkeit des Exports von Berichten in Form einer Excel Tabelle; Tabelle 8: Ergebnis der Evaluation Quelle: Eigene Darstellung in Anlehnung an (Debreceny et al. 2005, 10) Diese Ergebnisse sind zudem in Übereinstimmung mit dem Guidance on Monitoring Internal Control Systems -Entwurf, den die COSO 2008 veröffentlich hat. Er besagt, dass eine effektive Überwachung das Herstellen einer effektiven Grundlage für eine Überwachung, das Entwerfen und Ausführen von risikobasierten Überwachungsverfahren, die Berichterstattung der Ergebnisse und die Einleitung von Korrekturmaßnahmen (wenn benötigt), beinhaltet (COSO 2008, 7). Da das COSO eine Rahmenwerksempfehlung zur Umsetzung eines internen Kontrollsystems für das Management eines Unternehmens darstellt, ist die Annahme, dass SAP PC das Top-Management eines Unternehmens unterstützt, erfüllt. Zusätzlich spielen neben der Einhaltung regulatorischer Anforderungen, u. a. aufgrund der unterzeichneten Verantwortung, für das Management andere Faktoren, wie beispielsweise Zeit und Kosten eine übergeordnete Rolle. Dazu stellt SAP PC mit Dashboards und Auswertungen eine schnelle und aufbereitete Übersicht bereit: 64

77 Abbildung 34: Dashboard - Automatische Überwachung Quelle: SAP GRC Process Control 10.0 Dieses Dashboard zeigt die Ergebnisse der automatisierten Überwachung, die im Rahmen des Proof-of-Concept durchgeführt wurde. Das linke Tortendiagramm, gibt Aufschluss über die Schwachstellen, die einem Mitarbeiter zur Bearbeitung zugeschickt wurden. Das rechte Diagramm zeigt die gefundenen Schwachstellen, sortiert nach deren Priorität. Es ist sofort ersichtlich, dass die meisten gefundenen Schwachstellen eine niedrige Priorität aufweisen. Dennoch haben 25% der aufgelisteten Mängel eine hohe Priorität. Basierend auf diesen Informationen kann das Management die Auswertungen der automatischen Überwachung einsehen und dort die notwendigen Details erfahren. Somit dienen Dashboards als ein erster Einstiegspunkt um die aktuelle Unternehmenssituation zu erfassen und verschaffen dem Top- Management durch ihre anschauliche Darstellung einen Mehrwert in Form von Zeitgewinnung, der sich auch auf eine Kostenminimierung niederschlägt. Zudem ist allein durch die Durchführung der automatischen Überwachung ein detaillierter Ablauf der Kontrollen dokumentiert. Dies kann neben dem Management noch weiteren Adressaten als Grundlage dienen: Zum einem dem internen Audit, das dadurch den Überblick über die implementierten Kontrollen und deren Effektivität behält und zum anderen dem externen Audit, die aufgrund der Protokollierung der Ergebnisse die Prüfung absegnen können. Damit kann also Continuous Controls Monitoring auch dazu beitragen: - dass das Unternehmen vor dem Wirtschaftsprüfer besteht, - dem Management in Echtzeit der aktuelle Status im Unternehmen aufzeigt wird, - dem internen Audit Auskunft über die Effektivität und Effizienz der Kontrollen gegeben - und Vertrauen gegenüber den Shareholdern geschaffen wird. 65

78 8 Diskussion In diesem Kapitel werden die Ergebnisse aus den Forschungsfragen kritisch hinterfragt, sowie Annahmen bezüglich markanter Auffälligkeiten getroffen. 8.1 IT als Parallelverschiebung von Ouchi s Dimensionen Die Klassifikation in hat ergeben, dass Ouchi s Framework keine oder lediglich eine bedingte Aussagekraft auf die Konstruktion von Kontrollen hat. Erwartet wurde, dass mit Hilfe des Frameworks eine Entscheidungsunterstützung für das Design von Kontrollen gegeben werden kann. Jedoch lassen sich nahezu alle Kontrollen im linken oberen Quadranten einordnen: Abbildung 35: Ouchi Framework Quelle: Eigene Darstellung in Anlehnung an (Ouchi 1979, 843) Da die hier untersuchten Kontrollen in einem IT-gestützten Tool zur kontinuierlichen Prozessüberwachung implementiert wurden, kann vorausgesetzt werden, dass die Kontrollen deshalb bereits IT-gestützt funktionieren. In Ouchi s Framework bedeutete eine Einordnung im linken oberen Quadranten bisher die Auswahl der kostengünstigsten Variante. Dieses Kriterium ist jedoch im Zeitalter der Informationstechnologie hinfällig geworden. Darauf basierend besteht der Grund zur Annahme, dass Kontrollen die IT-gestützt abgebildet sind, sowohl die Kriterien für eine Ergebnis- als auch für einer Verhaltenskontrolle vorweisen. Dazu soll zunächst eine Kontrolle aus dem klassifizierten Kontrollset (siehe 7.3.4) vorgestellt werden, auf die das zutrifft: 66

79 Kontrolle_09 Gefährdeter Prozess: Beschreibung: Erkennt doppelte Lieferantenrechnungen auf Basis der Systemreferenznummer (Transaktionskontrolle) Rechnung bezahlen Diese Kontrolle erkennt doppelte Lieferantenrechnungen auf Basis der Systemreferenznummer. Abhängig von der eingestellten Toleranz lassen sich hohe/mittlere/niedrige Verstöße auflisten. Bewertung KTP: Ergebnis: AtmO/ Rechnung muss bezahlt werden trivial in sich, daher hohe Objektivität; Der Erfolg des Rechnungsbezahlens hängt nur von den Faktoren Kreditor, Betrag und Erfüllungsdatum ab, daher hohe Quantifizierbarkeit; Rechnungen müssen - ganz im Sinne eines gültigen Kaufvertrages bezahlt werden, daher Zielbefriedigung erfüllt; / Der Prozess des Rechnungsbezahlens ist einfach, da lediglich Kreditor, Betrag und Erfüllungsdatum dafür notwendig ist; Die Formulierung ist zu allgemein, detailliertere Anweisungen fehlen; Die Einordbarkeit in den Gesamtprozess ist klar gegeben: Nachdem eine Bestellung aufgegeben wurde, muss sie bezahlt werden; 3/2 -> OC oder BC Bewertung OC/BC: Ergebnis: Ziele sind klar: keine doppelten Rechnungen zahlen; Ausmaß feststellbar aufgrund definierter Schwellenwerte in den Regelskripten; am Ende des Prozesses, da alle bis dato bezahlten Rechnungen verglichen werden; / nicht delegiert; klar beschrieben in Dokumentation inklusive der durchzuführenden Schritte im Regelskript; monatlich, also nicht häufig; 3/2 -> mehr OC als BC Tabelle 9: Kontrolle_09 - Verhaltens- sowie Ergebniskontrolle Quelle: Eigene Darstellung Bei dieser Kontrolle handelt es sich zudem um eine Transaktionskontrolle, d.h. es werden alle Transaktionen, die bis zu dem Zeitpunkt der Durchführung der Kontrolle erstellt wurden, überprüft. Dazu wird auf die zugehörige Datenbank, in der alle getätigten Lieferantenrechnungen hinterlegt sind zugegriffen. Anschließend wird überprüft, ob eine Systemreferenznummer doppelt vorkommt. Dabei wird die Tabelle Rechnungen nach dem doppelten Vorkommen der Systemreferenznummern durchsucht. Dies kann nur durchgeführt werden, wenn zum einen großes Wissen über den Prozess besteht, sodass der Kontrollprozess lückenlos und nach-verfolgbar im IT-System abgebildet werden kann und zum anderen das Ergebnis des Prozesses bekannt ist. In diesem Fall das Auffinden doppelter Lieferantenrechnungen. Um die Annahme endgültig zu bestätigen, soll der Ansatz eines Gegenbeweises erbracht werden. So sollen Kontrollen gefunden werden, die als Ergebniskontrollen und Kontrollen, die als Verhaltenskontrollen klassifiziert werden und nicht IT-gestützt abgebildet werden können. 67

80 Die soziale Kontrolle wird an dieser Stelle ausgeklammert, da es evident ist, dass das Auswählen von Personen auf deren Eignung für einen Prozess nicht IT-gestützt abgebildet werden kann. Nicht IT-gestützt abbildbare Kontrollen und Kontrollprozesse: - Medienbrüche: Eine Klassifizierung würde eine Verhaltenskontrolle ergeben. - Plausibilitätskontrollen: Ein IT-System kann keine Entscheidungen treffen, die nicht vorher einprogrammiert wurden. Dies verlangt menschliches Urteilsvermögen und ist daher nicht IT-gestützt abbildbar. Eine Klassifikation würde eine Ergebniskontrolle ergeben, da nur wenig Wissen über den Prozess vorhanden ist, jedoch viel über das Ergebnis. - Voice Trading: Viele vergangene Skandale im Bankenumfeld, so wird vermutet, sind auf Voice Trading zurückzuführen. Eine IT-gestützte Kontrolle, wird sich dafür nicht finden lassen. Eine Klassifikation würde zu einer Ergebniskontrolle führen. - mündliche Vereinbarungen leitender Angestellter: Eine Kontrolle, die diese Verhandlungen überprüft, würde als Ergebniskontrolle klassifiziert werden, weil das Gespräch nicht öffentlich und mit-verfolgbar stattfindet. Somit wurde ansatzweise aufgezeigt, dass es Kontrollen und Kontrollprozesse gibt, die nicht IT-gestützt ablaufen und die als Ergebniskontrolle oder Verhaltenskontrolle klassifiziert werden. Ob damit ein schlüssiger Gegenbeweis erbracht werden kann, muss in einer weiterführenden Arbeit geklärt werden. Zudem wird auf eine Anpassung der Dimension Wissen über den Prozess verwiesen. Diese muss im Falle einer IT-gestützten Kontrolle immer eine sehr hohe Ausprägung haben, weil sonst der Prozess nicht im System hinterlegt werden kann. Die Aussagekraft ist daher denkbar gering. Ein besseres Ergebnis wäre mit der Beobachtbarkeit eines Prozesses erlangt. Zudem sei an dieser Stelle auf ein Zitat von Dechow/Mouritsen (2005, 691) aus Kapitel 6.2 verwiesen, das besagt, dass Kontrollen nicht fern von Technologie und deren Kontext studiert werden können, weil niemand jemals die darunterliegende Infrastruktur den Treffpunkt von vielen Technologien und vielen Typen von Kontrollen verstehen wird. Aufgrund dessen wird auf eine weiterführende Arbeit verwiesen, die sich verstärkt mit dieser Infrastruktur auseinandersetzt und daraus geeignete Dimensionen ableitet. Nur so kann eine eindeutige Entscheidungsgrundlage für das Design von Kontrollen geschaffen werden. 8.2 Disparität zwischen Vorstellung und Realisierung von Kontrollen Während in dieser Arbeit ausschließlich vordefinierte Regeln mit selbsterstellen Kontrollen verknüpft wurden, kann es in der Praxis vorkommen, dass diese nicht mehr ausreichen und Regeln spezifisch erstellt werden müssen. Dann stellt sich die Frage, ob jede Regel einfach umgesetzt werden kann? Eine kritische Reflektion offenbart, dass dabei zwei Meinungen über das Design einer Kontrolle aufeinander treffen können: Die des Auftraggebers der Kontrollen (z.b. ein Wirtschaftsprüfer) und die des Auftragnehmers (z.b. ein IT-Mitarbeiter), der die Kontrolle im System umsetzt: 68

81 Abbildung 36: Disparität zwischen Kontrolle und Umsetzung Quelle: Eigene Darstellung Denkbar ist folgendes Szenario: Der Wirtschaftsprüfer gibt eine zu implementierende Kontrolle vor, die der Mitarbeiter aus der IT mit passenden Regeln und Kriterien umsetzten soll. Im vorliegenden System arbeiten die Skripte in den Regeln auf den jeweiligen Tabellen im Zielsystem. D.h. jede Kontrolle wird auf Tabellenebene umgesetzt. Der IT-Mitarbeiter erkennt, dass die Kontrolle, die der Wirtschaftsprüfer in Auftrag gegeben hat, nicht umsetzbar ist. Es herrscht also eine Disparität zwischen den IKS-Objekten, die beide Parteien definieren. Eine Kontrolle ist nur dann umsetzbar, wenn die Kontrolle basierend auf den Beschreibungen des Prüfers auch auf die Tabellen im System anwendbar ist. Das ist genau dann der Fall, wenn beide das Gleiche IKS-Objekt beschreiben. Wie vereint man nun diese unterschiedlichen Ansichten? Funktioniert das immer? Die Antwort lautet Nein. Während Transaktionskontrollen, wie sie u.a. in dieser Arbeit verwendet werden, sehr einfach umgesetzt werden können, sind Kontrollen die menschliches Eingreifen erfordern, in der Regel schwerer oder auch gar nicht umsetzbar. Ein Beispiel dafür wäre das Prüfen des Wareneingangs. Auch in dieser Arbeit wurde eine Kontrolle umgesetzt, die alle Wareneingangsbelege mit den bezahlten Rechnungen vergleicht, um auszuschließen, dass eine Rechnung doppelt bezahlt wurde. Doch nicht in allen Unternehmen wird der komplette Wareneingang elektronisch erfasst. So könnte eine Subkontroll-Anweisung lauten: Prüfen sie das Vorhandensein der Kürzel des Lageristen und des LKW-Fahrers auf dem Lieferschein. An dieser Stelle liegt ein eindeutiger Medienbruch vor, der die Umsetzung einer ITgestützten Kontrolle unmöglich macht. Sicherlich ist es möglich im Rahmen einer halbautomatischen Kontrolle Lieferscheine einzuscannen und elektronisch zu archivieren. Doch selbst dann kann diese Subkontrolle nicht automatisch und IT-gestützt durchgeführt werden, da die passende Tabelle im ERP System fehlt. Eine Möglichkeit wäre, bereits die Belege einzuscannen mit dem Vermerk, ob beide Kürzel auf dem Lieferschein vorhanden sind. Eine weitere Möglichkeit wären mobile Endgeräte am Wareneingang. Diese könnten einen direkten Sign- Off ermöglichen. Diese Disparität muss in Zukunft noch weiter erforscht werden. Nach Meinung des Autors ist ein Hauptumsetzungs-Problem die Fähigkeit zur Kontinuität. Die IKS-Objekte unterscheiden sich in ihrer Kontinuität von klar definierten Sachverhalten hin bis zu hoch komplexen Aufgaben, die sich umfangreich auf das menschliche Urteilsvermögen verlassen. Die Forderung nach hochkomplexen Kontrollen resultiert aus der Entwicklung der Kontrollsysteme. Während das Hauptziel traditionellen Audits lediglich darin bestand, die Genauigkeit der Finanzdaten zu versichern, ermöglicht modernes Audit mit Hilfe der IT, die feine und genaue 69

82 Sicherstellung der Genauigkeit von sowohl Finanz- als auch Nicht-Finanzdaten. Routine Aufgaben und klare Sachverhalte sind dabei gut in ein CCM übertragbar, da sie leicht in einen kontinuierlichen Ablauf eingebunden und automatisiert werden können. Komplexe Aufgaben hingegen stellen eine Herausforderung an die kontinuierliche und automatisierte Umsetzung dar. Die Frage ist, ob die Effektivität von CCM monoton mit steigender Kontinuität abnimmt: Abbildung 37: Steigende Kontinuität - Abnehmende Effektivität? Quelle: Eigene Darstellung Wenn dies tatsächlich der Fall ist, dann ist der Einfluss von CCM auf die Revision in seiner Fähigkeit, eine neue Kontrollumgebung zu erschaffen, vermindert. Denn dann erreicht CCM nicht mehr als eine bestehende Audit-Methode zu automatisieren, was zwar eine Arbeitserleichterung für das Audit-Personal darstellt, aber im Gesamtzusammenhang ist und bleibt dies nur ein Sekundärziel. Um dieses Problem zu adressieren schlagen Vasarhelyi, Alles und Kogan (Vasarhelyi/Alles/Kogan 2004, 5) die Unterscheidung in 4 Kontroll-Kontinuitätslevel vor: - Level 1: Überprüfen der atomaren Elemente von Transaktionen (z.b. Geld- und Informationstransaktionen auf Datenebene). - Level 2: Sicherstellen der Eignung der Messregeln, die in Transaktionsprozessen genutzt werden. - Level 3: Überprüfen der Angemessenheit der Schätzungen und deren Annahmen, sowie der Konsistenz von hochrangigen Messungen. - Level 4: Hochrangige Urteile und Fakten über die Organisation erfragen und kontrollieren. Auf jedes dieser Level soll der Einfluss von CCM geprüft werden. Nur dann kann ein weiteres Verständnis für die uneingeschränkte Umsetzbarkeit von Kontrollen geschaffen werden. Es besteht also die Forderung nach einem Handlungsleitfaden für das Design von Kontrollen. Dadurch soll sichergestellt werden, dass das vom Auftraggeber (z.b. Wirtschaftsprüfer) erschaffene IKS-Objekt mit dem vom Auftragnehmer (IT-Mitarbeiter) angebotenen IKS- Objekt eine Übereinstimmung findet. Doch auch innerhalb eines Unternehmens kann ein Handlungsleitfaden für klare Strukturen bei der Umsetzung von Kontrollen sorgen. Nur dann können effektive und effiziente Kontrollsysteme garantiert werden. Eine Studie, basierend auf 70

83 den Anforderungen seitens der Auftraggeber und nehmer, könnte in Einklang mit den vorgeschlagenen vier Leveln von Vasarhelyi, Alles und Kogan für mehr Verständnis sorgen. 8.3 Grundlegende Veränderung der Accounting-Profession Das in dieser Arbeit umgesetzte Continuous Controls Monitoring hat und wird die Accounting-Profession maßgeblich verändern. Dies soll an drei Beispielen dargestellt und erläutert werden: (1) Neue Qualifikationen erforderlich (Verschmelzung von IT und Accounting) (2) Veränderung der Prüfung (3) Überwachung der Überwachung (1) Es besteht fast kein Zweifel daran, dass die Informations- und Kommunikationstechnologie immens zum Ausmaß der Geschwindigkeit und der Beschleunigung des Wandels in der betrieblichen Praxis in den letzten 30 Jahren beigetragen hat (Hunton 2002, 56). In Kapitel 6 wurde auf die Potentiale, die die IT ermöglicht, eingegangen und anschließend auf die Probleme manueller Kontrollen angewandt. Dies legt die Vermutung nahe, dass sich die Profession des Audits im Wandel befindet. So wird zum Implementieren von Kontrollen einerseits das Wissen über Prozess und Kontrollen und andererseits Wissen über die verwendete Technik benötigt. Sicherlich gibt es auch dort noch Grenzen, dennoch sollte auf beiden Seiten das Verständnis für die jeweils andere Sichtweise vorhanden sein. Dies impliziert zum einen ein verändertes Profil des Mitarbeiters, der die Kontrollen erstellt und zum anderen wird es in der Zukunft verstärkt interdisziplinäre Teams geben, bestehend aus Informatikern, Wirtschaftsinformatikern, Juristen und Betriebswirten. (2) Eine weitere Folge der Entwicklung der IT ist die Prüfung an sich. Durch den Einsatz ITgestützter automatischer Prozesskontrollsysteme, wird nicht nur der Compliance-Status geprüft, er ist auch jederzeit abrufbar. Während Wirtschaftsprüfer vor Jahren noch nach Kontrollen und deren Effektivität im Unternehmen suchen mussten, genügt heute ein Systemzugang. Dazu gibt es spezielle Benutzerrollen, die den Wirtschaftsprüfern zugewiesen werden können. Aufgrund der Tatsache, dass automatische Prozesskontrollsysteme wie das in dieser Arbeit implementierte beispielsweise die gedeckten Risiken in einer Risiko- Kontrollmatrix anzeigt - kann der Prüfer sofort sehen, ob alle Risiken durch Kontrollen abgedeckt sind. Das mitprotokollieren aller Tätigkeiten innerhalb des IKS und das Speichern dessen, trägt zudem enorm zur Glaubwürdigkeit des Audits bei, die dadurch beweisen können, dass sie ihren Pflichten nachgekommen sind. Dadurch wird der gesamte Prozess transparent gemacht. Solch ein System hätte zwar Enron und Andersen nicht daran gehindert, das Einrichten einer Scheingesellschaft abzuzeichnen (Sign-Off), aber wenigstens wäre allen Beteiligten bewusst gewesen, dass ihre Fingerabdrücke auf den relevanten Entscheidungen sind (Alles/Kogan/Vasarhelyi 2004, 190). Der nicht von der Hand zu weisende Geschwindigkeitszuwachs im Prüfen ist natürlich auch für die Unternehmen selbst von Vorteil, da aufgrund des verminderten Zeitaufwands, Kosten was die Bezahlung der Wirtschaftsprüfer angeht - gespart werden können. Diese dargelegte Entwicklung macht es zudem schwierig zwischen internen und externen Auditoren zu unterscheiden, ganz besonders, weil die externen Prüfer 71

84 dazu gezwungen sind, verstärkt Fraud zu identifizieren. Dies impliziert ein tieferes Vordringen in das IKS (Vasarhelyi/Alles/Kogan 2004, 13), was die Frage aufwirft: Wo endet internes Audit und wo fängt externes an? (3) Im Zuge des CCM verschmelzen zunehmend die Grenzen zwischen Kontroll- und Prozesshierarchie. Es wird in Zukunft schwer werden eine klare Trennlinie, zwischen den verschiedenen Ebenen der Überwachung zu ziehen, weil sie immer mehr, an das allen Kontrollen gemeinsam zugrundeliegende ERP System, angeknüpft sind. Dazu wird die Verwendung von Continuous Auditing für die Ermöglichung einer Überwachung der Überwachung, sogenanntes Tertiary Black Box Monitoring diskutiert (Alles/Kogan/Vasarhelyi 2003, 37). Dadurch soll die Überwachung selbst überwacht werden. Im Zuge dessen, soll die Prüfung der Effektivität und Effizienz des internen Kontrollsystems verbessert werden. 8.4 Kritische Reflektion: Risikoaversion durch CCM? Wie viele Kontrollen sind duldsam? Können zu viele Kontrollen die Motivation der Mitarbeiter drücken und gar zu Fraud führen? Eine kritische Reflektion auf das kontinuierliche und automatische Überwachen von Kontrollen soll dies klären. Zunächst einmal konnte nachgewiesen werden, dass durch das Vorhandensein eines CCMs Manager weniger willkürliche Ausgaben tätigen, die als unangemessen und schwer begründbar angesehen sind. Jedoch wurde zudem festgestellt, dass Manager auf die Möglichkeit hin neue Investitionen zu tätigen risikoavers reagieren, da ihre Entscheidungen im Rahmen des CCMs unter ständiger Beobachtung stehen. Selbst wenn es wahrscheinlich ist, dass das Projekt zu einem langfristigem Erfolg führt, kann diese Haltung bei Managern beobachtet werden (Hunton/Mauldin/Wheeler 2008, 1551). Eine kontroverse Situation, da die Manager im Falle eines Erfolgs im Rahmen des durch die Principle-Agent-Theorie ausgehandelten Vergütungsvertrages besser bezahlt werden würden. In einer weiterführenden Studie hat man herausgefunden, dass das kontinuierliche Überwachen zu einer Erhöhung der wahrgenommenen Rechenschaftspflicht bei Managern führt. Diese manifestiert sich in der verstärkten Wahrnehmung, Entscheidungen rechtfertigen zu müssen. Ferner glauben Manager, dass die Erhaltung des Status-Quo die am einfachsten zu verteidigende Entscheidung darstellt. Diese Haltung, den Weg mit dem geringsten Widerstand zu gehen, reflektiert eindeutig eine risikoaverse Haltung (Hunton et al. 2010, 250) und dämpft jeden Risikoappetit. Hunton et al. schlagen deshalb vor, dass geeignete Mechanismen zeitlich mit CCM implementiert werden müssen, um eine angemessene Risikobereitschaft zu gewährleisten. Dies gilt ganz besonders für Situationen, die das Wachstum und die Entwicklung neuer Projekte betreffen. Damit wurde gezeigt, dass CCM nicht nur Vorteile bietet. Deshalb sei an dieser Stelle auf weitere Forschungen im Bereich der Risikoaversion im Zusammenhang mit CCM verwiesen. 8.5 Einschränkungen Diese Arbeit verfolgt im Rahmen einer Evaluation das Ziel einen Proof-of-Concept zu erreichen. Daher wurden sämtliche Konzepte der Rollenverteilung im System außer Acht gelassen. Kostenaspekte, sowohl was die Implementierung, als auch die Anschaffung der Systeme betrifft sind nicht Teil dieser Arbeit. In der Praxis muss dieser Faktor jedoch berücksichtig werden. Zumal viele Unternehmen aufgrund der hohen Kosten niemals ein IT-gestütztes Kon- 72

85 trollsystem implementieren würden, wenn es nicht vorgeschrieben wäre (Solomon/Cassell 2004). Deswegen müssen bei der Auswahl der idealen Kontrollumgebung Kosten, Nutzen und Notwendigkeit gegeneinander abgewägt werden. Ferner wurden in dieser Arbeit keine Aussagen über die Anzahl der zu implementierenden Kontrollen in Bezug auf die Größe eines Unternehmens getroffen. Zudem wurde keine Priorisierung von Kontrollen vorgenommen (Scoping). Zudem wurden lediglich vordefinierte Regeln Kontrollen zugewiesen In der Praxis können veränderte Bedingungen eine individuelle Anpassung erforderlich machen. 73

86 9 Showcase In der vorliegenden Arbeit wurde das Erstellen eines automatischen Prozesskontrollsystems wissenschaftlich untersucht. Im Zuge dessen wurde durch die Installation von SAP GRC Process Control 10.0 und dessen Anbindung an SAP ERP eine ideale Grundlage für weitere Forschungen im Bereich Continuous Controls Monitoring und Organizational Control geschaffen. So ist es möglich Kontrollen kontinuierlich und automatisch durchführen zu lassen sowie deren Status in nahezu Echtzeit einzusehen. Aufgrund der bereits von SAP mit ausgelieferten Kontrollen in den Bereichen Order-to-Cash, Procure-to-Pay, Financial-Close- Process und IT-General Controls ist es möglich aussagekräftige Kontrollen zu erstellen. In dieser Arbeit wurden Kontrollen erstellt, die den Einkaufsprozess eines Unternehmens überwachen. Basierend auf dieser Grundlage sind folgende Szenarien denkbar: Planspiele, in denen Studierende aus unterschiedlichen Fachbereichen (idealweiser Betriebswirtschaftslehre, Informatik und Wirtschaftsinformatik), in interdisziplinären Gruppen zusammenarbeiten. Vorstellbar wäre, dass im Rahmen des Planspiels Schwachstellen in Prozessen platziert werden und die Studenten diese durch automatische Kontrollen verhindern müssen. Sich monatlich verändernde Parameter können für zusätzliche Dynamik sorgen. Durch die Arbeit in interdisziplinären Teams, wird die Kreativität besonders gefordert und Ergebnisse, wie sie in Einzelarbeit vermutlich nicht erreicht werden können, können zum Vorschein kommen. Anschauungsmaterial für Vorlesungen in den Fachbereichen, Betriebswirtschaftslehre und Wirtschaftsinformatik. Professoren können das System nutzen und den Studenten die Vorteile der Automatisierten Kontrollüberwachung an einem repräsentativen Beispiel (eine der bereits implementierten Kontrollen, oder eine selbst erstellte) live zu präsentieren. Seminare, in denen die Studenten einen Teilbereich des Systems zunächst in einer einführenden Blockveranstaltung kennen lernen und anschließend im Rahmen einer Seminararbeit ihr erlerntes Wissen in einer Arbeit präsentieren. Klaus Tschira, Mitbegründer von SAP hat einmal gesagt: Nie wieder habe ich so viel in so kurzer Zeit gelernt, da zwanzig Teilnehmer Fehler für mich gemacht haben! Sie können so viele Fehler gar nicht allein machen. In diesem Sinne, ist die Arbeit der Studenten, mit dem in dieser Arbeit entwickelten Tool und auch die Fehler die sie dabei machen, ein wertvoller Gewinn und Ausgangspunkt für weitere Forschungen. Diese Szenarien sollen als ein erster Anreiz dienen, sich mit diesem Thema auseinander zusetzen. Nachdem der erste Schritt getan ist, können Vertiefungen im Bereich GRC angestrebt werden. Denkbar wäre eine umfassende Integration des Risikomanagements, was zu neuen Herausforderungen und spannenden Fragestellungen führen würde. Dazu bietet das vorliegende System die Möglichkeit zusätzliche SAP GRC Komponenten, wie SAP Riskmanagement und SAP Access Control ganz leicht anzubinden und zu integrieren. Besonders spannend, ist die Integration des Risikomanagements zu sehen, da dieses eine Wegbereiter- Funktion einnimmt und dadurch Process Control mit Risiken versorgen kann, die dann durch Kontrollen abgedeckt werden können. Diese Integration könnte zu neuen Ergebnissen im Bereich Continuous Controls Monitoring führen. 74

87 10 Fazit und Ausblick Automatische Prozesskontrollen dienen in der betrieblichen Praxis als Wegbereiter für eine nachhaltige Unternehmenstransparenz. Basierend auf den Potentialen der Informationstechnologie wurde in dieser Arbeit der Aufbau eines IT-gestützten internen Kontrollsystems zur kontinuierlichen, automatischen Überwachung interner und externer Anforderungen untersucht. Die erste Forschungsfrage behandelt die Herausforderungen bei der Umsetzung einer unternehmensweiten Prozesskontrolle an ein IT-System und dessen Ausgestaltung. Dazu wurden die Anforderungen an ein IT-System basierend auf den Schwachstellen manueller Kontrollen herausgearbeitet. Manuelle Kontrollen sind fehlerbehaftet, nur langsam durchführbar und decken lediglich eine Stichprobe ab. Eine Gegenüberstellung mit den Potentialen, die sich durch den Einsatz von IT ergeben, ergab, dass automatische Prozesskontrollen wesentlich effektiver und wirtschaftlicher durchgeführt werden können. Zur Implementierung eines IT-gestützten Prozesskontrollsystems, wurde SAP GRC Process Control 10.0 ausgewählt. Dieses wurde logisch mit einem SAP ERP System verbunden. Als Überwachungsgrundlage wurde der Einkaufsprozess ausgewählt. Anschließend wurden 28 Kontrollen, die die Bereiche Materialwirtschaft, Einkauf und Kreditorenbuchhaltung abdecken erstellt. Im Rahmen der zweiten Forschungsfrage wurden diese mithilfe der Organisationskontrolltheorie klassifiziert. Das Ergebnis entsprach nicht der Annahme, eine Entscheidungsgrundlage für die Konstruktion von Kontrollen zu erhalten. Vielmehr hat sich herausgestellt, dass das verwendete Framework von Ouchi keine eindeutige Entscheidungshilfe bieten kann. Es liegt die Vermutung nahe, dass die Dimensionen von Ouchi nicht geeignet sind, um IT-gestützte Kontrollen zu klassifizieren. Daher müssen in Zukunft geeignete Faktoren, wie die Beobachtbarkeit eines Prozesses, in die Gestaltung von Dimensionen miteinfließen. Zur Behandlung der dritten Forschungsfrage, wurden die Kontrollen in SAP GRC Process Control 10.0 implementiert und evaluiert. Im Rahmen eines Proof-of-Concept konnten vier ausgewählte Kontrollen, durch bewusst falsche Eingaben im SAP ERP ausgelöst werden. Somit dient SAP Process Control dem Management als Entscheidungsgrundlage und ermöglicht die Einhaltung regulatorischer Anforderungen. Dies hilft einerseits um vor dem Wirtschaftsprüfer zu bestehen und schafft andererseits eine Vertrauensgrundlage für externe Stakeholder. Um sowohl die Forschung als auch die Praxis auf dem Gebiet des Continuous Controls Monitoring weiter zu entwickeln, empfiehlt sich, in einem ersten Schritt die Integration des Risikomanagements. Dieses dient als Wegbereiter, indem es Risiken identifiziert, analysiert und anschließend der Compliance zur Verfügung stellt. Basierend auf diesen Risikodaten können Kontrollen in SAP Process Control erstellt werden. Da beide Systeme auf derselben Plattform basieren, ist der Mehraufwand durch die Installation von SAP Riskmanagement gering. Somit kann eine integrierte, ganzheitliche, kontinuierliche, automatische Überwachung von Prozessen und deren Risiken gewährleistet werden. Der nächste logische Schritt ist die Priorisierung von Kontrollen (Scoping), um mehr über deren Effektivität in Erfahrung zu bringen. Dazu werden diese mit einer Gewichtung versehen. Infolge dessen können wichtige Risiken stärker herausstellt werden, ohne weniger wichtige zu vernachlässigen. Dieser Vorgang ermöglicht es dem Management sich auf die für das Unternehmen wesentliche Risiken zu konzentrieren. Dies ist von entscheidender Bedeutung für eine effektive und effiziente Bewerkstelligung der immer stärker zunehmenden regulatorischen Anforderungen. 75

88 Literaturverzeichnis Accenture (2007): The Rise of the Multi-Polar World. Accenture. ACFE (2010): Report to the nations - on occupational fraud and abuse. Association of Certified Fraud Examiners. Akhalumeh, P.B.; Ohiokha, F.I.; Oseni, A.I. (2010): Business Process Reengineering. In: ACADEMIC SCHOLARSHIP JOURNAL, (2010), S Aktiengesetz/GmbHG (2007): Aktiengesetz - GmbH-Gesetz: mit Umwandlungsgesetz, Wertpapiererwerbs und Übernahmegesetz, Mitbestimmungsgesetzen Albrecht, W.S.; Williams, T.L.; Wernz, G.W. (1995): Fraud: Bringing light to the dark side of business, Irwin, New York Aldrich, H. (1999): Organizations evolving, Sage Publications Ltd Alles, M.A.; Kogan, A.; Vasarhelyi, M.A. (2003): Black box logging and tertiary monitoring of continuous assurance systems. In: Information Systems Control Journal, Vol. 1 (2003), S Alles, M.G.; Kogan, A.; Vasarhelyi, M.A. (2004): Restoring auditor credibility: tertiary monitoring and logging of continuous assurance systems. In: International Journal of Accounting Information Systems, Vol. 5 (2004), S Alles, M.G.; Kogan, A.; Vasarhelyi, M.A. (2008): Putting continuous auditing theory into practise: Lessons from two pilot implementations. In: Journal of Information Systems, Vol. 22 (2008) Nr. 2, S Alves, M.C.G. (2010): Information Technology roles in Accounting Tasks A Multiple-case Study. In: International Journal of Trade, Economics and Finance, Vol. 1 (2010) Nr. 1, S Anderson, S.W. (Hrsg.) (2006): Managing costs and cost structure throughout the value chain: Research on strategic cost management (Vol. 2). Elsevier, Oxford Anon, J.L.; Filowitz, H.; Kovatch, J.M. (2007): Integrating Sarbanes-Oxley controls into an investment firm governance framework. In: Journal of Investment Compliance, Vol. 8 (2007) Nr. 1, S Anthony, R.N. (1965): Planning and control systems: a framework for analysis, Harvard University Apreda, R. (2007): Compliance Risk And The Compliance Function Could Enhance Corporate Governance Not Only In Banks But In Other Kind Of Organizations As Well. In: Corporate Ownership & Control, Vol. 4 (2007) Nr. 3, S Arnold, V. (2006): Behavioral research opportunities: Understanding the impact of enterprise systems. In: International Journal of Accounting Information Systems, Vol. 7 (2006) Nr. 1, S Ashton, R.H. (1974): An experimental study of internal control judgements. In: Journal of Accounting Research, (1974), S

89 Baldwin, A.; Beres, Y.; Plaquin, D.; Shiu, S. (2005): Trust Record: High-Level Assurance and Compliance Trust Management. In: (Vol. 3477). Hrsg.: Herrmann, P.; Issarny, V.; Shiu, S. Springer Berlin / Heidelberg, 2005, S Banker, R.D.; Chang, H.; Kao, Y. (2002): Impact of information technology on public accounting firm productivity. In: Journal of Information Systems, Vol. 16 (2002) Nr. 2, S Beams, N. (2001): Enron: Das wahre Gesicht der "New Economy". zugegriffen am Berkau, C.; Hirschmann, P. (1996): Kostenorientiertes Geschäftsprozessmanagement, Vahlen, München Bernholz, P.; Faber, M.; Petersen, T. (2009): Kausalität in den Wirtschaftswissenschaften: Welche Ursachen hat die Finanzkrise? In: Universität Heidelberg, Wirtschaftswissenschaften (2009) Nr. 488, S Bisbe, J.; Otley, D. (2004): The effects of the interactive use of management control systems on product innovation. In: Accounting, organizations and society, Vol. 29 (2004) Nr. 8, S Bishop, R.; Rupprecht, D.; Shapiro, E. (2011): Drifting or Driving? - Finance effectiveness benchmark study In: Pricewaterhouse Coopers, (2011). Bodnar, G. (1975): Reliability modeling of internal control systems. In: The Accounting Review, Vol. 50 (1975) Nr. 4, S Bonazzi, R.; Hussami, L.; Pigneur, Y. (2010): Compliance management is becoming a major issue in IS design. In: Information Systems: People, Organizations, Institutions, and Technologies, (2010), S Brauer, M.H.; Steffen, K.D.; Biermann, S.; Schuler, A.H. (2009): Compliance Intelligence - Praxisorientierte Lösungsansätze für die risikobewusste Unternehmensführung, Schäffer-Poeschl Verlag, Stuttgart Brown, C.E.; Wong, J.A.; Baldwin, A.A. (2007): A Review and Analysis of the Existing Research Streams in Continuous Auditing. In: Journal of Emerging Technologies in Accounting, Vol. 4 (2007) Nr. 1, S Bungartz, O. (2009): Handbuch Interne Kontrollsysteme (IKS) - Steuerung und Überwachung von Unternehmen, Erich Schmidt Verlag, Berlin Butler, T.; McGovern, D. (2009): A conceptual model and IS framework for the design and adoption of environmental compliance management systems. In: Information Systems Frontiers, (2009), S Caldwell, F. (2010): Hype Cycle for Regulations and Related Standards, In: Gartner, Inc., (2010). Caldwell, F.; Scholtz, T.; Hagerty, J. (2011): Magic Quadrant for Enterprise Governance, Risk and Compliance Platforms. In: Gartner, Inc., (2011). Cardinal, L.B. (2001): Technological innovation in the pharmaceutical industry: The use of organizational control in managing research and development. In: Organization Science, Vol. 12 (2001) Nr. 1, S

90 Cardinal, L.B.; Sitkin, S.; Long, C.P. (2002): Creating control configurations during organizational founding. In: Academy of Management Journal, (2002). Cardinal, L.B.; Sitkin, S.B.; Long, C.P. (2004): Balancing and rebalancing in the creation and evolution of organizational control. In: Organization Science, Vol. 15 (2004) Nr. 4, S Chapman, C.S.; Kihn, L.A. (2009): Information system integration, enabling control and performance. In: Accounting, organizations and society, Vol. 34 (2009) Nr. 2, S Chatterjee, A.; Milam, D. (2008): Gaining Competitive Advantage from Compliance and Risk Management. In: From Strategy to Execution, (2008), S Chen, K.T.; Lee, R.M. (1992): Schematic evaluation of internal accounting control systems. In: EURIDIS Research Monograph, (1992). Child, J. (1973): Strategies of control and organizational behavior. In: Administrative Science Quarterly, (1973) Nr. March, S Chuprunov, M. (2011): Handbuch SAP-Revision, Galileo Press, Bonn Colbert, J.; Bowen, P. (1996): A Comparison of Internal Controls: COBIT, SAC, COSO and SAS 55/78. In: IS Audit & Control Journal, Vol. 4 (1996), S COSO (1992): Internal Control - Integrated Framework. Committee of Sponsoring Organizations of the Treadway Commission. COSO (2008): Guidance on Monitoring Internal Control Systems: Exposure Draft. In, (2008). Cressey, D.R. (1973): Other People's Money, Patterson Smith, Montclair Cushing, B.E. (1974): A mathematical approach to the analysis and design of internal control systems. In: The Accounting Review, Vol. 49 (1974) Nr. 1, S Cyert, R.M.; March, J.G. (1992): A behavioral theory of the firm, Wiley-Blackwell, New Jersey D Arcy, S.P.; Brogan, J.C. (2001): Enterprise risk management. In: Journal of Risk Management of Korea, Vol. 12 (2001) Nr. 1, S Dalci, İ.; Tanış, V.N. (2002): Benefits of Computerized Accounting Information Systems on the JIT Production Systems. In: Review of Social, Economic and Business Stuides, Vol. 2 (2002), S Dameri, R.P. (2009): Improving the Benefits of IT Compliance Using Enterprise Management Information Systems. In: Electronic Journal Information Systems Evaluation Volume, Vol. 12 (2009) Nr. 1, S Damianides, M. (2005): Sarbanes oxley and IT governance: New guidance on IT control and compliance. In: Information Systems Management, Vol. 22 (2005) Nr. 1, S Daniel, F.; Casati, F.; D'Andrea, V.; Mulo, E.; Zdun, U.; Dustdar, S.; Strauch, S.; Schumm, D.; Leymann, F.; Sebahi, S. (2009): Business compliance governance in service-oriented architectures. Vorgestellt auf der International Conference on 78

91 Advanced Information Networking and Applications, Washington, DC, USA, S Davenport, T.H. (1993): Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston Debreceny, R.S.; Gray, G.L.; Ng, J.J.J.; Lee, K.S.P.; Yau, W.F. (2005): Embedded audit modules in enterprise resource planning systems: implementation and functionality. In: Journal of Information Systems, Vol. 19 (2005) Nr. 2, S Dechow, N.; Granlund, M.; Mouritsen, J. (2006): Interactions between modern information technology and management control. In: Issues in management accounting, (2006), S. 45. Dechow, N.; Granlund, M.; Mouritsen, J. (Hrsg.) (2007): Management control of the complex organization: Relationships between management accounting and information technology (Vol. 2). Elsevier, Oxford Dechow, N.; Mouritsen, J. (2005): On Enterprise Wide Resource Planning Systems - The quest for integration and management control. In: Accounting, organizations and society, Vol. 30 (2005) Nr. 7-8, S DigitalSpirit (2011): digital spirit GmbH: Funktionierende Compliance-Einheiten machen Unternehmen wettbewerbsfähiger. zugegriffen am DIIR (2004): COSO: Unternehmensweites Risikomanagement - Übergreifendes Rahmenwerk. In: Deutsches Institut für Interne Revision e. V., (2004). Dittmar, L. (2007): Demystifying GRC. In: Business Trends Quarterly, Vol. 1 (2007) Nr. 4, S Doty, C.; Sen, A.; Wang, S. (1989): Effect of internal controls in data base design. In: Journal of Information Systems, (1989) Nr. 1, S Drösser, C. (2000): Vertraute Prüfung. zugegriffen am Dworkin, T.M. (2006): SOX and Whistleblowing. In: Michigan Law Review, Vol. 105 (2006), S Efendi, J.; Mulig, E.V.; Smith, L.M. (2006): Information technology and systems research published in major accounting academic and professional journals. In: Journal of Emerging Technologies in Accounting, Vol. 3 (2006) Nr. 1, S Egelhoff, W.G. (1984): Patterns of control in US, UK, and European multinational corporations. In: Journal of International Business Studies, (1984) Nr. Fall, S Eisenhardt, K.M. (1985): Control: Organizational and economic approaches. In: Management Science, (1985), S El Kharbili, M.; De Medeiros, A.K.A.; Stein, S.; van Der Aalst, W. (2008a): Business process compliance checking: Current state and future challenges. In: Modelling Business Information Systems, (2008a), S El Kharbili, M.; Stein, S.; Markovic, I.; Pulvermüller, E. (2008b): Towards a framework for semantic business process compliance management. Vorgestellt auf der Proceedings of GRCIS, S

92 Firozabadi, B.S.; Tan, Y.H.; Lee, R.M. (Hrsg.) (1999): Formal definitions of fraud. IOS Press, Amsterdam Gadatsch, A. (2003): Grundkurs Geschäftsprozess-Management - Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker, Vieweg, Wiesbaden Gericke, A.; Fill, H.G.; Karagiannis, D.; Winter, R. (2009): Situational method engineering for governance, risk and compliance information systems. Vorgestellt auf der 4th International Conference on Design Science Research in Information Systems and Technology, New York, S. 24. Gherai, D.S.; Balaciu, D.E. (2011): From Creative Accounting Practices And Enron Phenomenon To The Current Financial Crisis. In: Annales Universitatis Apulensis Series Oeconomica, Vol. 1 (2011) Nr. 13. Gill, S.; Purushottam, U. (2008): Integrated GRC - Is your Organization Ready to Move? In, Vol. 6 (2008) Nr. 3, S Gleißner, W. (2011): Grundlagen des Risikomanagements im Unternehmen, Vahlen, Franz Götz, B.; Köhntopp, F.; Mayer, B.; Wagner, G. (2008): Einsatz einer ganzheitlichen GRC- Softwarelösung. In: HMD Praxis der Wirtschaftsinformatik, Vol. 45 (2008) Nr. 5, S Granlund, M. (2009): On the interface between accounting and modern information technology, Turku School of Economics Groomer, S.M.; Murthy, U.S. (1989): Continuous auditing of database applications: An embedded audit module approach. In: Journal of Information Systems, Vol. 3 (1989) Nr. 2, S Hagerty, J.; Kraus, B. (2009): GRC in 2010: $29,8B in Spending Sparked by Risk, Visibility, and Efficiency. In: AMR Research, (2009). Hammer, M.; Champy, J. (1994): Reengineering the corporation: A Manifesto For Business Revolution, Harper Business, New York Hasenack, W. (1952): Betrieb und Kontrolle Zur Wesensproblematik der Betriebskontrolle. In: Betriebswirtschaftliche Forschung und Praxis, Vol. 4 (1952), S Hauschka, C.E. (2007): Coroporate Compliance. Handbuch der Haftungsvermeidung im Unternehmen, C.H. Beck, München Healy, P.M.; Palepu, K.G. (2003): The fall of Enron. In: The Journal of Economic Perspectives, Vol. 17 (2003) Nr. 2, S Herzwurm, G.; Schockert, S.; Weinberger, C. (Hrsg.) (1997): Kundenorientierte Evaluierung von Software-Tools zur Unterstützung von Quality Function Deployment (Vol. 12). Mellis, W., Herzwurm, Georg, Stelzer, D., Köln Hevner, A.R. (2007): A Three Cycle View of Design Science Research. In: Scandinavian Journal of Information Systems, Vol. 19 (2007) Nr. 2, S

93 Hevner, A.R.; March, S.T.; Park, J.; Ram, S. (2004): Design Science In Information Systems Research. In: MIS Quarterly, Vol. 28 (2004) Nr. 1, S Hillenbrand, T. (2002): "Das führende Unternehmen der Welt". zugegriffen am Hitt, L.M.; Wu, D.; Zhou, X. (2002): Investment in enterprise resource planning: Business impact and productivity measures. In: Journal of Management Information Systems, Vol. 19 (2002) Nr. 1, S Hollander, A.S.; Denna, E.L.; Cherrington, J.O. (2000): Accounting, information technology, and business solutions, McGraw-Hill Education Holtschke, B.; Heier, H.; Hummel, T. (2008): Quo vadis CIO?, Springer, Berlin/Heidelberg Hornik, S.; Ruf, B.M. (1997): Expert systems usage and knowledge acquisition: An empirical assessment of analogical reasoning in the evaluation of internal controls. In: Journal of Information Systems, Vol. 11 (1997) Nr. 2, S Huntington, I.; Davies, D. (1999): Wirtschaftskriminalität im Unternehmen: Betrug erkennen und bekämpfen, Campus Verlag, Frankfurt und New York Hunton, J.E. (2002): Blending Information and Communication Technology with Accounting Research. In: Accounting Horizons, Vol. 16 (2002). Hunton, J.E.; Libby, D.; Libby, J.; Mauldin, E.; Wheeler, P. (2010): Continuous monitoring and the status quo effect. In: International Journal of Accounting Information Systems, Vol. 11 (2010) Nr. 3, S Hunton, J.E.; Mauldin, E.G.; Wheeler, P.R. (2008): Potential functional and dysfunctional effects of continuous monitoring. In: The Accounting Review, Vol. 83 (2008) Nr. 6, S IDW (2006): PS 261: Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die beurteilten Fehlerrisiken. In: Prüfungsstandard, Institut der Wirtschaftsprüfer, Vol. 6 (2006). IDW (2009): PS 210: Zur Aufdeckung von Unregelmäßigkeiten im Rahmen der Abschlussprüfung. In: Prüfungsstandard, Institut der Wirtschaftsprüfer, (2009). IDW (2011): Entwurf einer Neufassung des IDW Prüfungsstandards: Feststellung und Beurteilung von Fehlerrisiken und Reaktionen des Abschlussprüfers auf die beurteilten Fehlerrisiken. In (IDW), I.d.W.i.D.e.V. (Ed.),(Vol. 261). Düsseldorf. ITGI (2004): IT Control Objectives for Sarbanes-Oxley Jaworski, B.J. (1988): Toward a theory of marketing control: environmental context, control types, and consequences. In: The Journal of Marketing, Vol. 52 (1988) Nr. 3, S Jaworski, B.J.; MacInnis, D.J. (1989): Marketing jobs and management controls: toward a framework. In: Journal of Marketing Research, Vol. 26 (1989) Nr. 4, S Jost, W.; Scheer, A.W. (1996): Geschäftsprozeßmodellierung innerhalb einer Unternehmensarchitektur. Vorgestellt auf der Geschäftsprozeßmodellierung und Workflow-Management, Modelle, Methoden, Werkzeuge, Bonn, S

94 Kimberly, J.R.; Bouchikhi, H. (1995): The dynamics of organizational development and change: how the past shapes the present and constrains the future. In: Organization Science, (1995), S Kirsch, L.J. (1996): The Management of Complex Tasks in Organizations: Controlling the Systems Development Process. In: Organization Science, Vol. 7 (1996) Nr. 1, S Kirsch, L.J.; Ko, D.G.; Haney, M.H. (2010): Investigating the antecedents of team-based clan control: Adding social capital as a predictor. In: Organization Science, Vol. 21 (2010) Nr. 2, S Kirsch, L.J.; Sambamurthy, V.; Ko, D.G.; Purvis, R.L. (2002): Controlling information systems development projects: The view from the client. In: Management Science, Vol. 48 (2002), S Kley, K.L. (2008): Controlling im Spannungsfeld von Governance und Vertrauen. In: Mehr Verantwortung für den Controller. Hrsg. Horváth, P., Stuttgart 2008, S Klotz, M.I. (2007): IT Comliance-Auf den Kern reduziert. In: IT-Governance, Vol. 1 (2007), S KPMG (2008): Erfolgsfaktoren bei der Implementierung eines internen Kontrollsystems. In: KPMG's AUDIT COMMITTEE INSTITUTE, (2008). KPMG (2011): Continuous Auditing & Continuous Monitoring - Der Umsetzungsgrad in der deutschen Wirtschaft In: KPMG, (2011). Krüger, A. (2008): Fragen und Antworten zur Immobilienkrise. tagesschau.de. In: zugegriffen am Küpper, H.U. (1987): Konzeption des Controlling aus betriebswirtschaftlicher Sicht. Vorgestellt auf der Rechnungswesen und EDV, Heidelberg, S Lainhart, J.W. (2001): An IT assurance framework for the future. In: Ohio CPA Journal, Vol. 60 (2001) Nr. 1, S Lim, J.-H.; Dehning, B.; Richardson, V.J. (2008): A meta-analysis of the effects of IT investments on firm performance. University of Waterloo. Loebbecke, J.K.; Eining, M.M.; Willingham, J.J. (1989): Auditors experience with material irregularities: Frequency, nature, and detectability. In: Auditing: A Journal of Practice and Theory, Vol. 9 (1989) Nr. 1, S Lowe, A. (2004): Postsocial relations: Toward a performative view of accounting knowledge. In: Accounting, Auditing & Accountability Journal, Vol. 17 (2004) Nr. 4, S Mallin, C.A. (2011): Handbook on International Corporate Governance: Country Analysis, Edward Elgar Publishing March, S.T.; Smith, G.F. (1995): Design and natural science research on information technology. In: Decision support systems, Vol. 15 (1995) Nr. 4, S Marekfia, W.; Nissen, N. (2009): Strategisches GRC-Management: Grundzüge eines konzeptionellen Bezugrahmens. Technische Universität Ilmenau, Fakultät für Wirtschaftswissenschaften, Institut für Wirtschaftsinformatik. 82

95 Masli, A.; Peters, G.F.; Richardson, V.J.; Sanchez, J.M. (2010): Examining the potential benefits of internal control monitoring technology. In: The Accounting Review, Vol. 85 (2010), S Matoussi, H.; Gharbi, I. (2011): BOARD INDEPENDENCE AND CORPORATE FRAUD: THE CASE OF TUNISIAN FIRMS. Working Paper Series (S. 1-24). Tunisia: Manouba University. Merchant, K.A. (1985): Control in business organizations, Pitman Publishing, Marshfield Mitchell, S.L.; Switzer, C.S. (2009): GRC capability model. Red Book 2.0., Open Compliance & Ethics Group, Phoenix Mossanen, K.; Amberg, M. (2008): IT-Outsourcing & Compliance. In: HMD Praxis der Wirtschaftsinformatik, Vol. 45 (2008), S Namiri, K.; Stojanovic, N. (2007): A formal approach for internal controls compliance in business processes. pdf, zugegriffen am Nelson, E.G.; Machin, J.L.J. (1976): Management Control: System Thinking applied to the Development of a Framework for Empirical Studies. In: The Journal of Management Studies, (1976) Nr. October, S o., A. (2006): Kritik an Pierer und ein Geständnis. zugegriffen am Odenthal, R. (2005): Kriminalität am Arbeitsplatz: Korruption und Unterschlagung durch Mitarbeiter erkennen und verhindern, Gabler Verlag, Wiesbaden OECD (2004): OECD principles of corporate governance, Organisation for Economic Co- Operation and Development Österle, H. (1995): Business Engineering. Prozeß-Und Systementwicklung (Vol. 1), Springer Verlag, Berlin Ouchi, W.G. (1977): The relationship between organizational structure and organizational control. In: Administrative Science Quarterly, (1977) Nr. March, S Ouchi, W.G. (1979): A conceptual framework for the design of organizational control mechanisms. In: Management Science, Vol. 25 (1979), S Ouchi, W.G.; Maguire, M.A. (1975): Organizational control: Two functions. In: Administrative Science Quarterly, (1975), S Ould, M.A. (1995): Business processes: modelling and analysis for re-engineering and improvement. (1. Auflage Aufl.), Wiley Pathak, J. (2003): Internal audit and e-commerce controls. In: Internal Auditing, Vol. 18 (2003) Nr. 2, S Perrow, C. (1970): Organizational analysis: A sociological view, Taylor & Francis, Wadsworth, Belmont, CA Pershkow, B.I. (2002): Sarbanes-Oxley: investment company compliance. In: Journal of Investment Compliance, Vol. 3 (2002) Nr. 4, S

96 Poston, R.; Grabski, S. (2001): Financial impacts of enterprise resource planning implementations. In: Information Systems, Vol. 2 (2001), S PricewaterhouseCoopers (2008): 8th Annual Global CEO Survey. PricewaterhouseCoopers (2011): The Path Forward for Data Analysis and Continuous Auditing. Racz, N.; Weippl, E.; Seufert, A. (2010): A Frame of Reference for Research of Integrated Governance, Risk and Compliance (GRC). Vorgestellt auf der Communications and Multimedia Security, Berlin/Heidelberg, S Ranganathan, C.; Brown, C.V. (2006): ERP investments and the market future of firms: toward an understanding of influeantial ERP project variables. In: Information Systems Research, Vol. 10 (2006) Nr. 1, S Ridley, G.; Young, J.; Carroll, P. (2004): COBIT and its Utilization: A framework from the literature. Vorgestellt auf der 37th Hawaii International Conference on System Sciences, Hawaii, S. 8 pp. Romeike, F. (2008): Rechtliche Grundlagen des Risikomanagements: Haftungs-und Strafvermeidung für Corporate Compliance, Erich Schmidt Verlag, Berlin Ruud, F.; Sommer, K. (2006): Das COSO-ERM-Framework: Entrprise Risk Management in der Praxis. In: Der Schweizer Treuhänder, (2006) Nr. 3, S SAP (2001): IDES - das SAP Modellunternehmen. SAP (2009): SAP Lösung im Detail - Internes Kontrollsystem. SAP. SAP (2011a): Installation Guide. SAP (2011b): Operations Guide. SAP (2011c): Security Guide. SAP (2011d): Users Guide. Sarbanes-Oxley Act (2002): Sarbanes-Oxley Act of Public Law , 116 Stat 745. Washington DC: Government Printing Office. Scott, W.R.; Davis, G.F. (2007): Organizations and organizing: rational, natural, and open systems perspectives, Pearson Prentice Hall, New Jersey Sidhu, K. (2009): Anti-Corruption Compliance Standards in the Aftermath of the Siemens Scandal. In: German Law Journal, Vol. 10 (2009) Nr. 8, S Simon, H.A. (1996): The sciences of the artificial, The MIT Press, Cambridge Singleton, T. (2007): IT Audit Basics: The COSO Model: How IT Auditors Can Use It to Evaluate the Effectiveness of Internal Controls. In: Information Systems Control Journal, Vol. 6 (2007), S. 13. Snell, S.A. (1992): Control theory in strategic human resource management: The mediating effect of administrative information. In: Academy of Management Journal, Vol. 35 (1992) Nr. 2, S

97 Solomon, D.; Cassell, B.-L. (2004): Companies Complian About Cost of Corporate- Governance Rules. In: THE WALL STREET JOURNAL, (2004). Stoneburner, G.; Goguen, A.; Feringa, A. (2002): Risk management guide for information technology systems. In: National Institute of Standards and Technology - Special publication, Vol. 800 (2002), S. 30. Sutton, S.G. (2010): The fundamental role of technology in accounting: Researching reality. In: Advances in Accounting Behavorial Research, Vol. 13 (2010) Nr. Ed, Arnold, V., S Syed Abdullah, N.; Sadiq, S.; Indulska, M. (2010): Emerging challenges in information systems research for regulatory compliance management. Vorgestellt auf der Proceedings of CAiSE, Tunisia, S Tarantino, A. (Hrsg.) (2008): Governance, Risk, and Compliance Handbook - Technology, Finance, Environmental, and International Guidance and Best Practices. John Wiley & Sons, Inc., Taylor, F. (1911): The Principles of Scientific Management Harper and Brothers, New York/London Teng, J.T.C.; Calhoun, K.J. (1996): Organizational Computing as a Facilitator of Operational and Managerial Decision Making: An Exploratory Study of Managers' Perceptions*. In: Decision Sciences, Vol. 27 (1996) Nr. 4, S Teubner, A.; Feller, T. (2008): Informationstechnologie, Governance und Compliance. In: Wirtschaftsinformatik, Vol. 50 (2008) Nr. 5, S Thompson, J.D. (1967): Organizations in action, McGraw-Hill, New York Tiwana, A. (2008): Does technological modularity substitute for control? A study of alliance performance in software outsourcing. In: Strategic Management Journal, Vol. 29 (2008) Nr. 7, S Tiwana, A. (2010): Systems Development Ambidexterity: Explaining the Complementary and Substitutive Roles of Formal and Informal Controls. In: Journal of Management Information Systems, Vol. 27 (2010) Nr. 2, S Tiwana, A.; Keil, M. (2007): Does peripheral knowledge complement control? An empirical test in technology outsourcing alliances. In: Strategic Management Journal, Vol. 28 (2007) Nr. 6, S Tiwana, A.; Keil, M. (2009): Control in Internal and Outsourced Software Projects. In: Journal of Management Information Systems, Vol. 26 (2009) Nr. 3, S Turki, S.; Bjekovic-Obradovic, M. (2010): Compliance in e-government Service Engineering: State-of-the-Art. In: Exploring Services Science, Vol. 53 (2010), S Turner, R.; Di Florio, C. (2003): Investment management compliance: The dawn of a new era? In: Journal of Investment Compliance, Vol. 4 (2003) Nr. 4, S Vasarhelyi, M.A.; Alles, M.G.; Kogan, A. (2004): Principles of analytic monitoring for continuous assurance. In: Journal of Emerging Technologies in Accounting, Vol. 1 (2004) Nr. 1, S

98 Vasile-Daniel, C. (2010): How Financial Auditors Use Caats And Perceive Erp Systems? University Cluj-Napoca, Faculty of Economics and Business Administration, Romania. Venkatraman, N. (1994): IT-Enabled Business Transformation: From Automation to Business Scope Redefinition. In: Sloan Management Review, Vol. 35 (1994) Nr. 2, S Viator, R.E.; Curtis, M.B. (1998): Computer auditor reliance on automated and nonautomated controls as a function of training and experience. In: Journal of Information Systems, Vol. 12 (1998) Nr. 1, S vom Brocke, J. (2008): Entscheidungsorientierte Wirtschaftsinformatik: Entwicklung einer konstruktionsbegleitenden Kalkulation zur wirtschaftlichen Nutzung neuer Technologien. Multikonferenz Wirtschaftsinformatik (MKWI 2008) (S ). Garching bei München. Wall, F. (1999): Planungs-und Kontrollsysteme, Gabler, Wiesbaden Webster, J.; Watson, R.T. (2002): Analyzing the past to prepare for the future: Writing a literature review. In: Management Information Systems Quarterly, Vol. 26 (2002) Nr. 2, S. 3. Weill, P.; Ross, J.W. (2006): IT governance on one page. In: MIT Sloan Management Review, (2006). Wiggert, M. (2009): Risikomanagement von Betreiber-und Konzessionsmodellen, Verlag der TU Graz, Graz Williamson, O.E. (1975): Markets and hierarchies: analysis and antitrust implications: a study in the economics of internal organization, Free Press New York Woods, M. (2009): A contingency theory perspective on the risk management control system within Birmingham City Council. In: Management Accounting Research, Vol. 20 (2009) Nr. 1, S Woodward, J.; Dawson, S.; Wedderburn, D. (1980): Industrial organization: Theory and practice. In, (1980). Xiao, J.Z.; Duh, R.R.; Chow, C.W. (2011): Exploring the direct and indirect performance effects of information/communication technology and management accounting and controls. In: Accounting and Business Research, Vol. 41 (2011) Nr. 2, S Yongmei, L.; Honjian, L.; Junhua, H. (2008): IT capability as moderator between IT investment and firm performance. In: Tsinghua Science & Technology, Vol. 13 (2008) Nr. 3, S Zhang, Y.; Zhou, J.; Zhou, N. (2007): Audit committee quality, auditor independence, and internal control weaknesses. In: Journal of Accounting and Public Policy, Vol. 26 (2007) Nr. 3, S

99 Anhang A SAP BusinessObjects GRC Process Control Installation and Configuration Preface This section is intended to be an installation and configuration guide for installing SAP BusinessObjects GRC Process Control Although the corresponding thesis is written in German, this part is written in English in order to reach a wider audience. In addition, the guides provided by SAP are English anyway. All illustrations and screenshots included in this manual were reconstructed or come from the system used in this thesis. In addition, it should be mentioned that the present work should meet the quality characteristics of a proof-of-concept. Therefore only mandatory components are installed and there is no claim for completeness. The following only describes an initial installation and configuration, not an upgrade. 1. Introduction 1.1 Overview and use case in this thesis SAP BusinessObjects Process Control 10.0 (PC) is part of the Governance, Risk and Compliance suite from SAP. SAP PC is an enterprise software solution for compliance and policy management. It enables organizations to manage and monitor its internal control environment. In this thesis SAP PC is connected to a SAP ERP System in order to achieve a continuous control monitoring (CCM). Therefore included rules are assigned to controls and then scheduled for monitoring in the Legacy Automated Monitoring section. 1.2 General Information The following guides give important information on installing SAP PC: - installation guide: detailed description of preparation and implementation of the technical installation and post-installation ( SAP BusinessObjects Portfolio SAP BusinessObjects Governance, Risk Compliance (GRC) Process Control Process Control 10.0) - operations guide: description of the ongoing support and typical administration activities ( SAP BusinessObjects Portfolio SAP BusinessObjects Governance, Risk Compliance (GRC) Process Control Process Control 10.0) - security guide: settings for security and suggestions for raising security levels ( SAP Library (users guide): collection of documentation for SAP PC ( Also refer to the latest SAP Notes on and SAP Release Notes on ( SAP BusinessObjects Governance, Risk, Compliance 87

100 (GRC) SAP BusinessObjects Process Control Release Note for SAP BusinessObjects Process Control 10.0). For further issues, also refer to SAP Developer Network: Please note that the guides stated above form the basis of the achievements described in the following (SAP 2011a, 2011b, 2011c, 2011d). Nevertheless experience from work with the tool is included too. 2. Technical Landscape and required components This installation pursues to monitor a connected SAP ERP system. Therefore the following system landscape is adopted: The first component as pointed out in the image above, is the Front End Client. It consists of SAP GUI to execute customizing tasks, Adobe Flash Player to view dashboards and a web browser which is mainly used to view the embedded NetWeaver Business Client. Another available option for the Front End Client, could have been the Portal, with the advantage of displaying extended Crystal Reports. Process Control is the main component and it is contained in the ABAP add-on GRCFND_A. In order to monitor the SAP ERP System, it is connected via RFC-Connection to the Process Control component. Plugins GRCPINW and 88

101 GRCPIERP are mandatory in this use case. Also it s highly recommended to install the latest Service Packs for all components. Important: Make sure that the Service Packs of GRCFND_A, GRCPINW and GRCPIERP have got the same release number. In this installation all components are on release SP Preparation and Installation Based on the system, which is currently used, the installation procedure is different. In order to keep this guide general, refer to the latest Installation Guide provided by SAP ( SAP BusinessObjects Portfolio SAP BusinessObjects Governance, Risk Compliance (GRC) Process Control Process Control 10.0). In the guide, focus on Preparing for the Installation and Installing the Components. 4. Post-Installation This section assumes that the required components mentioned above were installed successfully. 4.1 Activate Process Control in Client Precondition: Make sure that the client you re using is a customizing client. Therefore execute Transaction Code (TC) scc4 and make sure that Changes w/o automatic recording, no transports allowed is activated. Procedure: 1. Start PC via GUI 2. Open the SAP Reference IMG via TC spro 3. Then navigate to IMG Governance, Risk and Compliance General Settings Activate Applications in Client and excute 4. Choose New Entries button and select GRC-PC in the dropdown menu 5. To finally activate it, make sure that GRC-PC is indicated in the Active -column 6. Save and Exit 4.2 Check SAP Internet Communications Framework (ICF) Services Procedure: 1. Execute TC sicf 2. Make sure that Hierarchy Type is SERVICE and then hit the execute icon or press F8 3. Expand the node default_host sap public, then right click on public 89

102 and choose Activate Service for all sub-nodes (Yes-Button with indicated hierarchy) 4. Proceed likewise with the node default_host sap bc and activate all sub-nodes too 5. Go to default_host sap grc and activate it and the underlying components too 6. Save and Exit 5. Activate Business Configuration Sets (BC-Sets) BC-Sets are an official implementation toolset used to simplify the customization process. Procedure: 1. Go to SAP IMG with TC spro 2. Click SAP Reference IMG 3. Then click Existing BC-Sets in the top line and a second column Additional Information appears 4. Expand node Governance, Risk and Compliance and click on BC-Sets for Activity in the top line 5. Mark BC Set Exists in the Additional Information column and activate it by Goto Activation Transaction 6. Make sure to select Expert Mode in Select Activation Mode when activating a BC-Set 7. Proceed likewise for the remaining BC-Sets unitl each BC-Set Exists has changed into BC-Set Exists BC Set(s) Activated 90

103 Alternatively you can use TC scpr20 to activate BC-Sets, therefore please refer to the latest installation guide in order to activate all necessary BC-Sets for Process Control and Shared BC-Sets. In this installation, the activation of BC-Set GRPC-BP-ATTR-VALUE ended with warnings. So the underlying table had to be modified in order to grant a successful activation. 6. Create the initial user Since this thesis is to meet the characteristics of a proof-of-concept, only one user is created. Note that in order to follow up compliance regulations e.g. segregation of duties more than one user had to be created. Therefore refer to the latest security guide. Procedure: 1. Call TC su01 2. Switch to Roles 3. Assign SAP_GRC_FN_BASE to access GRC applications a. SAP_GRC_FN_ALL to provide customizing rights b. SAP_GRC_FN_BUSINESS_USER c. SAP_GRC_FN_DISPLAY d. SAP_GRC_SPC_SETUP e. Most important assign SAP_GRC_NWBC in order to actually display the NWBC in the front end 4. Make sure that the assigned roles are activated (TC pfcg) 5. Save and Exit 91

104 When starting the NetWeaver Business Client for the first time (use TC nwbc), you should see something like this: 7. Activate Common Workflow Procedure: 1. Call TC spro and click SAP Reference IMG 2. Go to Governance, Risk and Compliance General Settings Workflow 3. Execute Perform Automatic Workflow Customizing 4. Make sure that all tasks are marked green after the generation 5. Save and Exit (To the best of the author s knowledge it is sufficient when Maintain Runtime Environment is entirely marked green.) 8. Perform Task Specific Customizing Procedure: 1. Switch again to IMG Governance, Risk and Compliance General Settings Workflow 2. Execute Perform Task-Specific Customizing 3. Expand SAP and navigate to GRC and Expand SAP and navigate to GRC 4. click Assign Agents a. Assign Task as General Task via button Attributes... 92

105 b. Make sure that all tasks that are not assigned as Background task have been assigned as General Task c. Finish and go back to the hierarchy and click Activate event linking d. Click the Properties icon and set Linkage status to No errors, make sure that Event linkage activated is selected and Error feedback is set to Do not change linkage 93

106 e. Be sure to activate all WS_ 5. When finished go back and expand the node GRC (if the node GRC couldn t be expanded go to TC se38 and run RS_APPL_REFRESH to refresh the directory) 6. Navigate to GRC GRC-SPC and repeat steps 4 a. e. to activate the features from above for Process Control 7. Save and Exit 9. Activate Crystal Reports In order to view Crystal Reports in NWBC go to IMG using spro and clicking on SAP Reference IMG. Navigate SAP Customizing SAP NetWeaver Application Server SAP List Viewer (ALV) Maintain Web Dynpro ABAP-Specific Settings. Execute and select Allow Crystal Reports. Save and Exit. 10. Create connections between SAP PC and SAP ERP 10.1 Overview This implementation is focused on the continuous monitoring of the SAP ERP system. In SAP Process Control 10.0 are two ways to implement this use case: - Continuous Monitoring new : this is the new in GRC Suite 10.0 implemented monitoring; you can set up automated tests and monitoring of controls that have been assigned to organizations, including configuration of rules, definition of criteria for application systems and assignment of rules to controles - Legacy Automated Monitoring old : as the name says, it s a legacy version from older versions of Process Control like 2.5 or 3.0; the main difference to the new Continuous Monitoring is to be able to use pre-delivered rules and rule skripts (see here: dd/content.htm); these scripts origin from mainly versions 2.5 and 3.0 and can only be implemented within the Legacy Automated Monitoring section; details later when in section Control Rule Assignment 10.2 Set up RFC-Connections For both types the two system SAP Process Control and SAP ERP had to be connected with each other. The most important thing here is, that you ve to create a RFC connection pointing from SAP PC to SAP ERP AND the other way round: 94

107 To set up the Continuous Monitoring and the Legacy Automated Monitoring, RFC- Connections (source connection and target connector) had to be created first. RFC-Connection from SAP Process Control to SAP ERP (target connector): In this a RFC-connection to SAP ERP (in this implementation A01) with client 900 is created; to do so, first a rfc_grc User had to be created in the target system A01 (su01 create rfc_grc user); after that call TC sm59 (in Process Control system) and create a RFC connection: 95

108 RFC-Connection from SAP ERP to SAP Process Control (source connector): In this step we are going to create a RFC-connection to SAP Process Control (in this implementation P02) with client 000; to do so, first a rfc_erp User had to be created in the source system P02 (su01 create rfc_erp user); after that call TC sm59 (in ERP system) and create a RFC connection: Make sure that the connections work by executing Connection Test in each system. Save and Exit. The logical port shown in the image above implies that SAP Process Control is the source system and SAP ERP is the target system, which should be monitored Customize Continuous Monitoring For finally using Continuous Monitoring it had to be customized first. The former Real Time Agents are substituted by the Plug-Ins. So make sure, that the ERP Plug-Ins GRCPINW and GRCPIERP are installed. Without them, the following won t work! Procedure: 1. Switch into IMG and navigate to: IMG Governance, Risk and Compliance Common Component Settings Integration Framework 96

109 2. Create connectors: this is step is already done, by creating a RFC connection; 3. Execute Maintain Connectors and Connection Types 4. Make sure that SAP is listed as a connection type in Connection typ definition menu 5. Go to Define Connectors and create a new entry: - Target Connector: the system you want to monitor, in this case A01CLNT900; make sure you use the exact name of the corresponding RFC-connection! - Connection Type: type of the system you are monitoring, in this case SAP 97

110 - Source Connector: this is the RFC-connection that is pointing at the Process Control system (created from SAP ERP to SAP PC); it also applies here: make sure you use the exact name of the corresponding RFC-connection! (don t be surprised when SAP doesn t recognize the system you ve typed in or when can t choose a system like you can in target connector - it will work though) - Logical port: the logical port is the same as target connector; as said before, this is to indicate which system is monitored; (don t be surprised when SAP doesn t recognize the system you ve typed in or when can t choose a system like you can in target connector it will work though) - Max No. of BG WP: 3 6. Execute Maintain Connection Settings ; in opening window insert AM and click continue 7. Go to Subscenario definition and make sure the Sub Scenario CONFIG is listed in the list below: 8. Mark CONFIG and double click Scenario-Connection type Link in the left side bar and make a new entry, which looks like this: 9. Double click Scenario-Connector Link in the left side bar and make a new entry: - Target Connector: the system you re connecting to; in this case A01CLNT900 (SAP ERP) - Con. Type: type of system you re connecting to; in this case SAP 98

111 10. Save and exit 10.4 Customize Legacy Automated Monitoring To use the pre-delivered rules, you have to set up the connectors for Legacy Automated Monitoring Procedure: 1. Open IMG and navigate to IMG Governance, Risk and Compliance Process Control Legacy Automated Monitoring Automated Testing and Monitoring 2. Configure RFC Connectors is already done, by creating a RFC-Connection 3. Execute Maintain System Type and make sure that SAP is listed as a System Type, if note create a new entry, which looks like this: 99

112 4. Save, go back and execute Register Connectors and create a new entry, which looks like this: - System Type: type of system to connect to; in this case SAP; - Target Connector: system to connect to; in this case A01CLNT900; make sure you use the exact same name as the RFC-connection name; - Source Connector: the source system, in this case P02CLNT000 (don t be surprised when you ve to type in the Source Connector manually and the system don t recognize it it will work though) - Default Target Connector: indicate your default connector, if you ve only got one, like in this case, mark it; 5. Save and exit To make sure, that the pre-delivered rules and rule scripts work, you have to assign them to the just created target connector.therefore login into your Process Control by TC nwbc and switch to Rule Setup. Since Rules use the same connector the corresponding rule scripts do, per default, you only have to assign the target connectors in the rule scripts. A list of all predelivered rules can be accessed here: ent.htm Note: You can of course create your own rule scripts; in this work it isn t necessary due to the fact that only a proof-of-concept is required. 100

113 Procedure: 1. It s highly recommended to copy all the scripts you want to use. Therefore search the script you want to use and click Copy in the toolbar above. The name of the new script must have a Z_ as a prefix; Note: You can only use rule scripts with Script Type GRC Configurable ; 2. After copying; mark a rule you want to implement later and open it - Primary Target Connector: hit the icon next to the field and the target connector you ve set up before should appear; double click it; - The rest of the fields, are already pre-filled; so you re done; save and exit; 3. Proceed like in step 2 for all scripts you want to use; 11. Create root Organization The root organization can only be created in the backend. Once this is done you can of course create subsidiary organizations in the front end, too. Procedure: To create the root organization, execute TC GRFN_STR_CREATE in Backend 101

114 It s highly recommended to use a full year (01.01.) in terms of consistendy. Continue and save; Now you can set up subsidiary organizations in the NWBC Front End; To do so execute TC nwbc and switch to tab Master Data and then Organizations, mark you root organization you just created and hit button Add. 12. Set up Regulations The most important things in using Process Control are regulations. Nearly every object depends on regulations. To create one, open up the front end and switch to tab Master Data Regulations and Policies Regulations and open it. First you ve to create a Regulation Group, after that you can create the Regulation : - Name: Name of your regulation - Valid from: it s highly recommended to use entire years (valid from XX) - Assign Regulation Configuration: Attention! Process Control comes with 2 predefined regulations: SOX and FDA. These specific regulations can be assigned only once. So be careful and assign them wisely. After that you can assign the regulation to an organization by opening Organizations and switch to Tab Regulations ; there add the regulations you want to assign; Save and quit; 102

115 13. Create Risks In this system risks are assigned directly to controls and sub processes. Another possibility is the indirect assignment. In this case, risks are assigned to control objectives, which are assigned to controls. From a business perspective the direct assignment answers the question Which risks are covered by corresponding controls? As said before, to answer that question, a direct assignment is applied. Either way, you ve to set up the risks before the assignment to a control (in this case) or control objective. Procedure: 1. Switch to Master Data Risks and Responses Risk Catalog 2. First create a Risk Category 3. Then create a Risk Template ; as said several times before, mind the valid date! (full year!); Drivers and Impacts are excluded in this system; your Risk Template should look like this: 103

116 4. Save and create as many risks as you need and quit; 14. Create Business Processes and Controls In this section the following hierarchy should be achieved: 104

117 Procedure: 1. Go to Master Data Activities and Processes Business Processes 2. Create Process; mind the valid date! add description and save; 3. Create Subprocess; assign the corresponding risks (this is important, because you can only assign risks to controls, which are assigned to a subprocess first); also assign fitting regulation; 4. Create Control: In the following, only the fields important for this thesis are discussed: - Name: self-explanatory - Control or Process Step: Control - Control Automation: Automated (all controls set up in this work are automated) - Purpose: Detective (ex post control) - Valid from: as said before, full year! - Valid to: this is an important field; since you can t delete controls, you can limit their validity; this is because of the use case, that you might want to restore deleted controls some other time and therefore you only had to expand the valid date; - Trigger: Date; - Operation frequency: you can choose between monthly, weekly, daily, continuously, etc. - to be tested: yes - Test Automation: automated; The rest of the options are for representation purpose only; e.g. you can choose that you only want to display all controls base on a high risk; 5. Assign regulation; 6. Assign risks; 7. Save and quit; 105

118 15. Assign Rule to a Control In this section, the Control Rule Assignment in the Legacy Automated Monitoring is described. Therefore the following, scheme applies: As already described: A Primary Target Connector had to be assigned in the rule script; In this case A01CLNT900; Within the rules pre-delivered by sap, a rule script is already assigned to a rule; So the only step left is to assign a rule to a control. Before doing that, make sure that the rules you want to assign have the Rule Status Released. To Check this switch to Rule Setup Legacy Automated Monitoring Rule and search for the rule, you want to assign later and set the Rule Status from Work in Progress to Released : 106

119 Having checked the rule status, you can now start assigning rules to a control. Procedure: 1. Navigate to Rule Setup Legacy Automated Monitoring Control Rule Assignment and open it 2. Select the regulation, in which your controls are defined; and click search (if you ve created lots of controls, it is recommended to specify the search) 3. Select the control, and hit Assign Rules to selected Control ; 4. Search for the rule you want to assign, mark it and click Ok ; 5. Once assigned, you should get something like this: 107

120 As shown in the image above, Rule Z_FIMPRCH_05T1_01 has been assigned to control Kontrolle_10 ; The columns Monitoring and Compliance indicate that the rule can be set as a job at terms of any frequency. You can also assign several rules to a control; Save and quit, when finished; 16. Assign Business Processes to Organization After having assigned rules to controls, you have to assign the entire business processes with all their dependencies to an organization. 108

121 Procedure: 1. Switch to Master Data Organizations Organizations and tab Subprocesses. 2. Click Assign Subprocess in the opening window 3. It hast to be decided whether your subprocess supports to be a shared service or not; shared service means, you can assign it to several organizations und use it more than once; 4. There is also the possibility to allow local changes if it should be allowed to edit the subprocesses and controls on organization-level; leave it blank if you won t allow this due to compliance issues 5. In the 4 th step you can select your controls, you want to assign to the corresponding organization 6. Review and confirm the assignments, then save and quit; The Subprocess tab should then look like this: 7. Hit Save and quit; Assign the rest of your subprocesses and controls; 17. Schedule Controls into Monitoring Scheduler After having created all controls assigned rules and organizations, you can finally schedule your controls. Therefore, you have to create a new job. Procedure: 1. Switch to Rule Setup Legacy Automated Monitoring Monitoring Scheduler and open it 2. Enter a regulation and click Create Schedule to create a new schedule 109

122 - Job Name: Name - Frequency: Daily; you can choose between daily, weekly, monthly. - Selected Controls: here you can add the controls you want to apply 3. After adding all controls, which should be ran, click Schedule and exit; 18. View Control Status in Job Monitor The last step is to display exceptions and compliance issues. Therefore switch to Rule Setup Legacy Automated Monitoring Job Monitor Enter the regulation, you scheduled your job in and click search ; depending on your jobs, the following list, can look like this: The control displayed here, checks every client in the target system, whether it is a productive client or not; in case of not, an exception is thrown and as you can see in the column Total Exceptions, there is one; 110