ACONO Insights
GRC-Software richtig konfigurieren: Standard oder Customizing?
Bei der Einführung einer GRC-Software stellt sich früh eine zentrale Designfrage:
Wie stark sollte die Plattform an die individuellen Anforderungen des Unternehmens angepasst werden?
Moderne GRC-Plattformen bieten umfangreiche Konfigurationsmöglichkeiten. Prozesse, Datenmodelle, Rollen und Berechtigungen, Workflows, Reports, Schnittstellen und ganze fachliche Lösungen lassen sich auf die Organisation zuschneiden.
Diese Flexibilität ist wichtig. Gleichzeitig erhöht jede Individualisierung die Komplexität der späteren Lösung.
Aus unserer Projekterfahrung bei der Konzeption, Implementierung und dem Betrieb von GRC-Lösungen haben sich deshalb drei Fragen als besonders relevant für Konfigurationsentscheidungen erwiesen.
1. Welchen Business Value erzeugt die Anpassung?
Individualisierung sollte einen nachvollziehbaren fachlichen Nutzen erzeugen.Das kann beispielsweise eine regulatorische Anforderung sein, eine notwendige Governance-Struktur, eine risikobasierte Freigabelogik oder eine Schnittstelle, durch die wiederkehrende manuelle Datenpflege entfällt.Bestehende Prozesse und Legacy-Lösungen sind dabei wichtige Informationsquellen. Sie sollten jedoch nicht ungeprüft zum Zielbild der neuen Plattform werden.Insbesondere bei historisch gewachsenen Excel- oder Altsystemlösungen lohnt sich die Frage, welche Strukturen tatsächlich weiterhin benötigt werden.
2. Wie weit entfernt sich die Lösung vom Standard?
Bei GRC-Plattformen wirken Konfigurationsentscheidungen häufig über den einzelnen Anwendungsfall hinaus.Prozesse stehen beispielsweise mit Risiken und Kontrollen in Verbindung. Anwendungen, Organisationseinheiten, Informationswerte und weitere Objekte werden häufig von mehreren GRC-Disziplinen gemeinsam genutzt. Zusätzliche Sonderfelder, individuelle Workflows, spezielle Rollenmodelle oder Reporting-Anforderungen können deshalb Auswirkungen auf Datenqualität, Berechtigungen, Integrationen und andere fachliche Lösungen haben. Wir prüfen Anforderungen daher zunächst gegen vorhandene Plattformmechanismen und bewährte Referenzmodelle.
Bei ACONO bündeln wir dafür Erfahrungen aus unterschiedlichen Projekten in unserer internen GRC Content Zone. Dazu gehören unter anderem Reference Configurations, Musterkonfigurationen, Best Practices, Templates und fachliche Knowledge Assets für Disziplinen wie Prozessmanagement, Risikomanagement, IKS, BCMS und ISMS.Dadurch müssen bekannte Fragestellungen nicht in jedem Projekt vollständig neu entwickelt werden. Gleichzeitig bleibt ausreichend Raum für Anforderungen, die sich tatsächlich aus dem jeweiligen Unternehmen ergeben.
3. Welche Kosten entstehen in Build und Run?
Die initiale Implementierung bildet nur einen Teil der Kosten einer GRC-Lösung ab. Zum Build gehören unter anderem Konzeption, Konfiguration, Integration, Testing und Dokumentation.Im Run entstehen Aufwände für Wartung, Support, Release-Tests, Schnittstellenbetrieb, Datenpflege und zukünftige Weiterentwicklungen.Eine Konfiguration kann während der Implementierung vergleichsweise einfach erscheinen und trotzdem über mehrere Jahre erhebliche Folgekosten verursachen. Diese Perspektive ist für uns besonders relevant, weil ACONO GRC-Landschaften nicht nur konzipiert und implementiert, sondern teilweise anschließend im Rahmen von Managed Services betreibt. Designentscheidungen aus einem Implementierungsprojekt begegnen uns damit später erneut im Service Desk, bei Releases, Änderungen und im Schnittstellenbetrieb.
Die Total Cost of Ownership (TCO) sollte deshalb bereits bei wesentlichen Design- und Konfigurationsentscheidungen berücksichtigt werden.