Die Arbeit an Ausschreibungen für GRC-Tools und die dann folgenden Einführungsprojekte sind unser tägliches Geschäft. Die Fachbereiche der Unternehmen auf der anderen Seite müssen sich diesen Vorhaben in der Regel nur selten oder meistens einmalig annehmen. Mit diesem Beitrag wollen wir unsere Erfahrung hinsichtlich typischer Stolpersteine sowie dazugehörigen Handlungsempfehlungen teilen.

 

Das Vorgehen zur GRC-Tool-Auswahl und -Einführung lässt sich in folgende Phasen einteilen:

 

Plan

  • Analyse der Anforderungen
  • Ausschreibung
  • Bewertung und Auswahl
Build
  • Analyse- und Designphase
  • Umsetzung- und Testphase
Run
  • Roll-Out- und Betreuungsphase

 

Voraussetzungen für eine erfolgreiche Plan-Phase

In der Phase "Plan" gilt es zunächst, klare Verantwortlichkeiten zu schaffen. Wesentlich ist unter anderem die Frage, ob der Prozess durch den Fachbereich oder die IT getrieben wird. Es gilt zu klären, wer die Auswahl strukturiert, Hauptansprechpartner für die Anbieter ist und letztlich auch, wer die finale Entscheidungshoheit bei Unstimmigkeiten hat.

Ebenso sollte frühzeitig die Budgetverantwortung geklärt werden und im Weiteren nach welchen internen Mechanismen die Kosten auf Fachbereich und verbundene Gesellschaften umgeschlagen werden, z.B. über Verrechnungspreise o.ä.

Sobald die Analyse der Anforderungen startet und der Kriterienkatalog für die Auswahl erstellt wird, ist eine Abgrenzung wichtig, ob es um einen konkreten Anwendungsfall (z.B. rein auf ISMS fokussiert) geht oder ob die Software "erweiterbar" im Sinne von ganzheitlicher Integration verschiedener Themenstellungen sein soll. Durch diese Entscheidung kann es ggf. wichtig werden, den Kreis der in die Auswahl involvierten Personen zu erweitern. Weiterhin ist die Betrachtung der bestehenden IT-Landschaft/-Strategie von Bedeutung, um zentrale strategische Vorgaben zu beachten und diese in Einklang mit den fachlichen Anforderungen zu bringen.

Breit gefächerte Expertise im Auswahlteam ist ein wesentlicher Schlüssel: Fachliches Wissen zu GRC-Prozessen allgemein und den unternehmensspezifischen Gegebenheiten sowie ein starker IT-Hintergrund sind erforderlich, um die Prozessanforderungen in Software-Anforderungen zu übersetzen. Darüber hinaus sind aktuelle und tiefe Marktkenntnisse erforderlich, damit auch die relevanten und möglicherweise im Unternehmen noch nicht bekannten Anbieter in der Auswahl berücksichtigt werden.

Die Überleitung der Anforderungen in den Kriterienkatalog sowie die Definition von Bewertungsskalen und der Gewichtung muss präzise erfolgen, damit allen an der Auswahl Beteiligten die Entscheidungslogik und die gesetzten Schwerpunkte klar sind. Die Transparenz im Vorgehen ist nicht nur aus Sicht von Compliance essentiell, sondern auch, um internen Meinungsverschiedenheiten vorzubeugen.

Letztlich ist die Qualität der Ausschreibungsunterlagen oft ausschlaggebend: Die Anbieter müssen für ihre Angebotslegung und Vorstellung der Software inhaltlich ausreichend viel verstehen können, ohne mit sämtlichen unwesentlichen Details überfrachtet zu werden. Auch hier hilft es, wenn die Schwerpunkte für die Entscheidung transparent sind und klar dargestellt werden. Realistische Timelines helfen allen Beteiligten, damit die Angebote qualitativ hochwertig erstellt werden können.

Im Rahmen der Bewertung und Auswahl des Tools empfiehlt es sich, nach der Erstellung der Shortlist einen kleinen Proof-of-Concept (wie einen Ausschnitt aus dem Prozess) abbilden zu lassen, z.B. als Inhalt der Angebotspräsentation. So bekommt man einen echten Einblick in die Software und ein Gefühl, wie der eigene Prozess sich dort wiederfinden könnte.

Transparenz in den Bewertungskriterien der Angebotspräsentation ist auch hier wieder wichtig, damit die spätere Entscheidung klar nachvollziehbar und dokumentiert ist. Hier ist auch eine gute Gelegenheit, das fachliche Know-how der Anbieter zu hinterfragen. Für das gemeinsame Implementierungsprojekt wird neben den menschlichen Faktoren von entscheidender Bedeutung sein, dass der Anbieter ein Verständnis der zugrunde liegenden Geschäftsprozesse hat.

Next step: Build-Phase

Sobald das Projekt startet, muss mit dem Anbieter ein Setup gefunden und definiert werden und das Projekt von Anfang an als gemeinsames betrachtet werden. Hygienefaktoren wie Entscheidungs- und Eskalationspfade sollten nicht unterschätzt werden, besonders wenn verschiedene Fachbereiche involviert sind. Timelines sind im GRC-Umfeld nach compelling events oder zur Einhaltung anderer Fristen oft sehr knapp und sorgfältige getroffene Vereinbarungen und Rahmenbedingungen helfen der Arbeitsatmosphäre. Eine Trivialität, die sich dennoch oft als massives Problem erweist, ist das Thema der internen Ressourcen. Es ist eine große Herausforderung, genügend Kapazitäten für die Projektarbeit zur Verfügung zu stellen, da der "GRC-Alltag" üblicherweise regulär weiterläuft und Regelprozesse "nebenbei" zu betreiben sind.

In der eigentlichen Umsetzung gilt wie in jedem Projekt: Vorsicht mit den Anforderungen und Erweiterungen, denn der Appetit kommt auch hier beim Essen. Es ist empfehlenswerter, sich streng an den ursprünglichen Scope zu halten, Erweiterungen vorzusehen und insbesondere im technischen Konzept ermöglichen. Weiterhin ist es gute Praxis, Vertreter aus der erweiterten Community (key user) von Anfang an mit einzubinden, auch schon in frühen Phasen der Konzeptentwicklung. Bekanntermaßen sind die Verantwortlichen oft sogenannte "Splitterköpfe" und haben neben den GRC-Tätigkeiten etliche andere Aufgaben in ihren Gesellschaften. Einfaches Navigieren und intuitives Zurechtfinden muss daher maßgebliches Ziel sein und ist von deutlich größerer Bedeutung als in anderen Softwareprojekten. Daher sind auch Dashboards und Berichte von essentieller Bedeutung, damit diese "ihre" relevanten Informationen möglichst einfach finden können. Insbesondere sobald es an das fachliche Testing geht, ist in diesem Kontext mit wertvollem Feedback zu rechnen.

In Sachen Dokumentation gibt es hingegen wenig Besonderheiten. Da diese Disziplin in den meisten Projekten sträflich vernachlässigt wird, gilt lediglich der Appell, möglichst ausführlich und nachvollziehbar zu dokumentieren.

Von besonderer Bedeutung ist hingegen die projektbegleitende Kommunikation. Besonders im GRC-Umfeld ist dies wichtig, da das Projekt oft nur stichtagsbezogen oder mit den jeweils anstehenden Aktivitäten auf dem Radar der User erscheint. In der Kommunikation ist zu beachten, dass die Nutzergruppen oft sehr unterschiedlich mit der Software arbeiten hinsichtlich Aufgaben, Frequenz und Tiefe des eigenen fachlichen Wissens. So kann man z.B. bei nur jährlichen Zertifizierungen eine Art One-Pager zur Verfügung stellen, in dem beispielsweise der Zugang zum Tool, die 3-5 wesentlichen Klicks, und einfache Auswertungsmöglichkeiten erklärt werden. In Anbetracht der Vielfalt der Aufgaben muss die Kommunikation also besonders präzise sein und geeignet aufbereitet werden, um die Aufmerksamkeit von den anderen Aufgaben ggf. "wegzulenken".

Insgesamt gilt es, einen Schwerpunkt auf Schulungsaspekte zu legen und die Gelegenheit zu nutzen, von Anfang an auch fachliche Inhalte einzuarbeiten und aufzufrischen. Etwaige Defizite in der Community werden oft erst bei solchen Gelegenheiten transparent und können gleich in diesem Rahmen aufgearbeitet werden.

Der Übergang in die Run-Phase

Auch nach Inbetriebnahme und Abschluss der Roll-Out-Phase bleibt es sehr wichtig, die Communities kontinuierlich zu stärken. Besonders, weil GRC oft als wenig dankbare Aufgabe in den Köpfen verankert ist, muss die Community stark zusammengehalten werden und der Fokus mindestens zu den wichtigen Phasen wieder gezielt darauf gelenkt werden. Dies ist allerdings nicht nur ein Thema der Software, sondern vor allem für die Verankerung in der Kultur und im täglichen Denken. Dem Tool kommt dabei durchaus eine prominente Rolle zu, da es im Auftritt nach außen immer Visitenkarte und Aushängeschild des Fachbereichs in der gesamten Organisation ist.

Regelmäßige fachliche Runden zum Austausch sind empfehlenswert, wenn möglich face-to-face. Auch hier sollten Aspekte rund um das Tool regelmäßig eine Rolle spielen, z.B. können hier neue Funktionalitäten oder Berichte vorgestellt werden. Auch wenn diese intensive Betreuung Ressourcen im Fachbereich bindet, wird dieser dadurch langfristig auch wieder entlastet. Die User weltweit werden sich dann auch eher untereinander austauschen, das Wissen teilen und Fragen ggf. rasch und unkompliziert klären können.

Sobald es an die Weiterentwicklung des Tools geht, ist das Feedback der User enorm wichtig. Aus der Erfahrung sehen sie häufig andere Schwerpunkte als die Verantwortlichen im Headquarter. Hier ist es wichtig, den Zeitpunkt für einen etwaigen Releasewechsel sorgfältig zu prüfen und ggf. auch mit der Community zu spiegeln. Insbesondere in der Abwicklung der Regelprozesse ist Timing oft ausschlaggebend, um nicht unnötige Hindernisse zu schaffen. Vor allem größere Anpassungen müssen selbstverständlich auch rechtzeitig in die Budgetierung eingeplant werden und auch in der internen Ressourcensituation berücksichtigt werden (z.B. Zeiten für Tests). Eine sorgfältige Planung und Sicherung der langfristigen Budgets ist essentiell, denn es wird häufig eine Kostensenkung über die Jahre hinweg erwartet. In der Argumentation kann unter Umständen das Feedback der User nützlich sein, aus dem man beispielsweise eine langfristige Roadmap erarbeiten kann, die auch eine Integration anderer Bereiche oder fachlich verwandter Themen vorsieht.

Im Allgemeinen hat sich gezeigt, dass es empfehlenswert ist, mit Updates nicht zu lange warten. Es besteht hier die Gefahr, die unregelmäßigen User regelrecht zu "schocken", weil sie die Oberfläche möglicherweise kaum wiedererkennen. Eine kontinuierliche Weiterentwicklung entlang der gemeinsam definierten Roadmap ist der Akzeptanz sehr dienlich. Besonders wenn weitere GRC-Prozesse integriert werden, sollte unbedingt darauf geachtet werden, dass die bestehenden User nicht "zurückfallen" und deren Usability leidet.

Es lohnt sich außerdem regelmäßig kritisch zu hinterfragen, inwieweit die Software zur berühmten "Eierlegenden-Woll-Milch-Sau" geworden ist und welche Elemente ggf. schon wieder unnötig geworden sind. Für den langfristig problemlosen Betrieb des Tools ist es sehr wichtig, dass die Expertise aus dem Projektumfeld gesichert wird, besonders wenn das Team sich mit Übergang in den Regelbetrieb verändert hat oder es im Unternehmen üblich ist, sich regelmäßig intern weiterzuentwickeln. Auch im laufenden Betrieb braucht es dedizierte Betreuer aus der IT und dem Fachbereich und es ist nötig, das zeitliche Commitment sorgfältig abzustimmen und an die Community zu kommunizieren. Das übergeordnete Ziel muss es sein, die User gezielt und adressatengerecht zu betreuen und dabei die restlichen Abteilungsaufgaben nicht zu vernachlässigen.

Unser Ziel als Tool-Anbieter ist es, Sie auf diesem Weg zu begleiten und ebenso bestmöglich zu unterstützen. Zögern Sie nicht, mit Fragen auf uns zuzukommen und im Dialog noch mehr von unseren Erfahrungen zu profitieren.

 

Email an Claudia Howe