• Das Unternehmen sollte schrittweise vorgehen und sich nicht zu viel vornehmen, sondern zunächst einmal nach Quick Wins streben und zwar anhand von ein bis zwei Fragestellungen hoher Priorität, also zum Beispiel das Messen der Lieferantenperformance anhand einheitlicher Metriken oder das zentrale Nachverfolgen von Feststellungen. Stellen sich hier schnell Erfolgserlebnisse ein, ist der Projektsponsor auch eher geneigt, weitere Budgets freizugeben. Startet das Projekt mit einer zu hohen Komplexität, droht sich das Team schnell zu verzetteln, der Fortgang des Projekts kann gefährdet sein.
  • Es ist wichtig, von Beginn an abzuwägen, wie viele Abteilungen direkt involviert sind. Die Integration von zu vielen Abteilungen bedeutet eine entsprechende Multiplikation von Individualanforderungen, die unter Umständen schwer miteinander zu harmonisieren sind, insbesondere, wenn die Gesamthoheit über die fachliche Projektsteuerung nicht geklärt und in der Organisation verankert wurde.
  • Von hoher Bedeutung ist die Vorbereitung der prozessualen Seite: Wie sieht der Implementierungsprozess aus? Wer ist verantwortlich? Welche Vorarbeiten muss das Unternehmen leisten, z. B. mit der Definition branchenrelevanter Use Cases.
  • Zentral sind personelle Fragen, die das Unternehmen kritisch und ehrlich beantworten sollte: Wer ist der Lösungseigentümer, eine einzelne Person, eine Abteilung oder Gruppe und müsste diese ggf. organisatorisch eingebettet werden, um über die notwendige Weisungsbefugnis zu verfügen? Wie geht es nach der Implementierung weiter, sind wir intern in der Lage, den Support zu leisten? Verfügen wir heute und zukünftig über die technische Expertise, um die Lösung gemäß unseren Anforderungen weiterzuentwickeln? Der oder die Lösungseigentümer sollten in ausreichendem Maße einen Teil ihrer Arbeitszeit der Pflege und Weiterentwicklung der GRC Softwarelösung widmen können und ein Mindestmaß an „Tool-Affinität“ aufweisen. Dies beinhaltet auch weniger fachliche Aufgaben wie die Einrichtung von User-Accounts über Rollen- und Berechtigungsvergaben bis hin zur Prüfung der Berichtsqualität und gegebenenfalls 1st Level Support für Endbenutzeranfragen und Troubleshooting.
  • Wer dieses Personal nicht im Hause hat, oder organisatorisch nicht sicherstellen kann, dass das Wissen und die Kompetenz rund um die GRC-Lösung nachhaltig gesichert werden können, sollte dies bereits bei der Wahl des Implementierungspartners berücksichtigen und darauf achten, dass diese Funktionen nach Bedarf an den Partner ausgelagert werden können. Sich allein auf den Helpdesk des Herstellers zu verlassen, ist riskant. Oft mangelt es diesen Support-Abteilungen an fachlichem Verständnis für die teilweise stark angepassten Kundenlösungen (nicht zu sprechen von erheblichen sprachlichen Barrieren internationaler Support-Organisationen), was zu erheblichem Aufwand bei der Fehlersuche und -beseitigung führt.
  • Sind mehrere Abteilungen involviert, ist es wichtig, sich methodisch auf eine gemeinsame Taxonomie zu einigen, um Sprachverwirrung zu vermeiden. Ist beispielsweise das „Issue“ aus dem internen Kontrollsystem gleich der „Feststellung“ der internen Revision? Abzustimmen sind bei der Integration mehrerer Abteilungen auch die methodischen Herangehensweisen an bestimmte Aufgaben oder der jeweils erforderliche Detailgrad an Informationen im Berichtswesen.