Governance, Risk and Compliance in SAP-Systemen
Anforderungen an SAP-Systeme: Wie lassen sich IT-Governance, Risikomanagement und Kontrollen eingliedern, ohne dass die betroffenen Systeme an Effizienz und Dynamik verlieren?
Einen GRC-Hut über eine Unternehmens-IT zu stülpen, um so Proforma-Resultate zu erhalten, bringt soviel wie ein ISO-Ordner im Büchergestell
Von Dipl. Kfm. Jörg Altmeier*
(13.03.08) - Was steht eigentlich hinter der Abkürzung GRC? Welche Auswirkungen haben Anforderungen aus GRC für SAP-Systeme? Sind diese überhaupt bereit dazu? Und wie können die Anforderungen umgesetzt werden? Diese und weitere Fragen beantwortet der folgende Artikel.
Governance, Risk and Control
Peter Weill und Jeanne Ross vom Center for Information Systems Research (CISR) der MIT Sloan School of Management in Boston haben IT Governance definiert als eindeutigen Rahmen mit Entscheidungsrechten und Zuständigkeiten, die den unternehmensspezifisch "richtigen" Umgang mit der IT unterstützen. Risk Management bezeichnet das aktive Managen mit dem obersten Ziel der Reduzierung von Risiken. Damit diese Mitigation ermöglicht wird, sind in Unternehmen Controls zu implementieren und deren Einhaltung sicherzustellen (Compliance). In freier Interpretation der altbekannten Formel e = mc2 können wir es vereinfacht auszudrücken: Governance, Risk and Compliance kann gleich gesetzt werden mit Effizienz, Mitigation und Controls. Kontinuität (Continuity) sorgt dafür, dass Erreichtes kritisch hinterfragt wird und Qualitätszyklen angestoßen werden.
Was sind die Anforderungen an SAP-Systeme
SAP-Systeme werden für die Abbildung von geschäftskritischen Geschäftsabläufen verwendet. Die hochflexible Standard-Software kann durch ihre Konfiguration bestehenden Abläufen angepasst werden, ohne dass die bewährten Prozesse geändert werden müssen.
SAP-Systeme werden von einer Vielzahl von Personen bearbeitet: Entwickler, Basis-Verantwortliche, IT-Architekten, Berechtigungs-Koordinatoren, Business nahe IT-Mitarbeiter, System-Verantwortliche, externe Berater und schließlich die Endanwender. Alle haben ihre eigenen Betrachtungsweise auf das System. Entwickler sehen keine Risiken in Eigenentwicklungen – sie arbeiten ja gut; System-Verantwortliche durchschauen die Komplexität nicht mehr und sind auf die Beurteilung ihrer technisch versierten Spezialisten angewiesen; Berechtigungs-Koordinatoren sitzen zwischen Stuhl und Bank: Die Beteiligten fordern möglichst hohe Rechte und nicht nur diejenigen, die sie zum Ausführen ihrer Arbeit tatsächlich benötigen; das Business will möglichst alle Wünsche erfüllt haben mit dem Hinweis, dass sie ja das Budget vergeben; externe Partner wiederum haben ein nur eingeschränkte Sicht auf die Systeme haben. Es bestehen also Meinungsdifferenzen über das was notwendig ist und was nicht; nur in einem sind sich alle einig: GRC ist ein Reizwort, denn wer wird schon gerne überprüft und legt transparent sein Tätigkeitsgebiet dar?
Sind die Systeme bereit für ein GRC?
Wie lassen sich IT-Governance, Risikomanagement und Kontrollen eingliedern, ohne dass die betroffenen Systeme an Effizienz und Dynamik verlieren? Viele in der Schweiz implementierten SAP-Systeme laufen gut; sie funktionieren ohne große Einbussen in der Verfügbarkeit. Die meisten von Ihnen haben die ausgelieferten Standards individuell auf kundenspezifische Anforderungen customized. Dies bringt auf der einen Seite eine höhere Akzeptanz bei den Benutzern, auf der anderen Seite jedoch ein höheres Bedürfnis an Dokumentation und Transparenz in der Systemumgebung. Letztere durfte dem Kosten- und Zeitdruck zuliebe häufig unvollständig oder gar nicht ausgeführt werden.
Viele Unternehmen stehen daher vor der Situation, nicht mehr ganz genau zu wissen, wo welche Datenströme fließen, oder wie die System-Schnittstellen genau arbeiten. Diese schwere Altlast, gekoppelt mit einer schlechten Systemhygiene, lässt sich nicht ohne Aufwand beheben und so verzichten Unternehmen oft auf eine Bereinigung.
Die Auswirkungen dieser mangelnden Visibilität sind für Einführung von IT-Governance-Modellen eine große Herausforderung, die es zu meistern gilt. Das gleiche gilt auch für ein die Bereiche Risiko- und Compliance-Management.
Von der Black Box zu einem schlagkräftigen GRC
Wir haben es also mit einer Black Box oder besser mit vielen kleinen Black "Böxchen" zu tun, und die gilt es in einem ersten Schritt zu öffnen. Ohne diese Transparenz kann man GCR nicht sinnvoll implementieren. Die von SAP und anderen Herstellern angebotenen Tools erfüllen ihrerseits erst die dann die Anforderungen an die Governance, wenn sie einem bereinigten System aufgesetzt werden. Dies bedeutet zuerst Knochenarbeit, die – macht man alles auf einmal – selten zum Ziel führt. Erfolgversprechender ist die Vorgehensweise, Mitarbeitende und Systeme in kleinen Schritten von Teilerfolg zu Teilerfolg führen.
Betrachtet man den Sachverhalt aus Sicht der Qualitätsverantwortlichen, ergeben sich zwischen SAP-System und Assembly-Line augenfällige Gemeinsamkeiten. Wie hat die Automobilindustrie es fertig gebracht, dass die Autos fehlerfrei und sicher laufen und sich erst noch gewinnbringend verkaufen lassen?
1. Zuerst ist ein gemeinsames Ziel aufzustellen, dass da heißt: "Das SAP System bildet zuverlässig, effizient und sicher die für das Unternehmen notwendigen Prozesse ab". Die verarbeitenden Daten erreichen eine hohe Qualität und die Prozesse sind klar und übersichtlich dargestellt. Da in SAP-Systemen Menschen die zentrale Rolle spielen, müssen diese auch besonders beachtet werden. Die meisten Mängel in SAP-Systemen werden schließlich durch sie verursacht. Die Qualitäts-Verantwortlichen haben bereits vor über drei Jahrzehnten erkannt, dass jeder einzelne Mitarbeiter persönlich involviert werden muss und Verantwortung für seinen Teilbereich, sein Arbeitsergebnis zu tragen hat. In der Automobilbranche konnte durch eigenverantwortliche teilautonome Arbeitsgruppen die Qualität massiv erhöht werden.
2. Die angestrebte Qualität soll analysiert und Zielwerte der einzelnen Etappen definiert werden. In dieser Projektphase sind Personen der Informatik wie auch des Business vertreten und alle werden in die Erreichung der Qualitätsziele miteinbezogen, niemand darf unverhältnismäßige Anforderungen stellen.
3. Der Entscheid, wie was und wer überprüft und wie mit den Ergebnissen umgegangen wird, ist ein sehr sensibles Thema. Ganz wichtig für die Erarbeitung der internen Kontrollen ist die Transparenz, was passiert, wenn etwas nicht eingehalten wird. Wie alle zu erreichenden Ziele werden auch die Kontrollen in Etappen geplant.
4. Die Überprüfung der gesetzten Ziele soll wo immer möglich in einem Exception Reporting erfolgen. Das heißt, erst wenn die Werte nicht mit den Vorgaben übereinstimmen, wird agiert. Dies ist notwendig, da es in SAP-Systemen sehr viele zu überprüfende Werte gibt und das Monitoring immer mit Ressourcenproblemen konfrontiert ist.
5. Die richtige Kommunikation der Themen soll über Abteilungen hinweg gewährleistet werden. Dabei führen die Vergleichsmöglichkeiten die mit einer Visualisierung der IT erreicht wurde zu einer höheren Akzeptanz des "Kostenverursachers IT". Lob und Akzeptanz sollen diejenigen erhalten, die die Ziele zuerst besonders gut erreichen oder auch um besondere Einsätze zu honorieren.
6. Die Erreichung der gesteckten Ziele kann von einer Vielzahl von Werkzeugen und Regelwerken unterstützt werden. Dabei sollen jedoch immer die Vorgaben des IT-Governance beachtet werden
Fazit
Einen GRC-Hut über eine Unternehmens-IT zu stülpen, um so Proforma-Resultate zu erhalten, bringt soviel wie ein ISO-Ordner im Büchergestell. Der Qualitätsreifegrad eines SAP-Systems ist ausschlaggebend für eine erfolgreiche Implementierung. Es gilt, in kleinen Schritten komplexe SAP-Systeme mit GRC-Teilen auszustatten, damit vernünftige Resultate bereitgestellt werden können. Die Nachhaltigkeit dieser Vorgehensweise macht sich in jedem Fall bezahlt, denn es ist sicher motivierender, effizient und transparent zu arbeiten.
Was die Anerkennung der Leistungen schwierig macht, ist die Tatsache, dass viele Betreiber wie auch Anwender von SAP-Systemen (noch) nicht bereit sind, für eine höhere Qualität einzustehen. Was die Autos von heute, versehen mit den neusten Technologien, mit aktiven Sicherheitssystemen erreichen – ist Zukunftsmusik für die SAP-Systeme. Manager müssen endlich den Mut aufbringen, sich auch für Altlasten, die vor ihrer Zeit entstanden, geradezustehen und sich nicht hinter einer Projektflut zu verstecken. Nur so können sie einmal ruhig in ihrem Sessel sitzen und am Dashboard die Geschwindigkeit, Fehlerquote, Compliance-Verstöße, etc. online managen. (wikima4: ra)
*Dipl. Kfm. Jörg Altmeier, Dipl.- Kfm. (Universität Saarbrücken), CISA, ist Managementberater im Umfeld Knowledge, Processes, Information Systems & Security; Managing Director der wikima4 in Zug; Lehrbeauftragter an diversen Hochschulen und Autor zahlreicher Fachbeiträge.
|
|
