Von der Software Auswahl bis zur erfolgreichen Implementierung bei Ihren Kunden. Teil 3: Zusammenarbeit während der Implementierungsphase.

Wir haben die GRC advisor Webinar Reihe ins Leben gerufen, um die erfolgreiche bestehende Zusammenarbeit mit Beratungsunternehmen zu vertiefen und weiter auszubauen. Beide Seiten profitieren voneinander, verfügen sie doch über jeweils ergänzende Erfahrungsschätze, die äußerst hilfreich sein können. In diesem Blogbeitrag fassen wir die Inhalte des dritten Teils der GRC advisor Webinar Reihe kurz zusammen.

 

Verschiedene Modelle in der Zusammenarbeit

In der Zusammenarbeit zwischen Toolanbietern und Beratungsunternehmen gibt es verschiedene Herangehensweisen. Das eine ist die klassische Variante, in der zu einem bestimmten Zeitpunkt der Toolanbieter einsteigt und die Federführung für das Umsetzungsprojekt übernimmt. Die GRC advisor verbleiben in der fachlichen Beratung und agieren im Auftrag des Kunden hinsichtlich einzelner, ausgewählter Themen.

 

Ein zweites Modell, das sich in der Vergangenheit bewährt hat, ist, dass die GRC Berater die Federführung für das Umsetzungsprojekt übernehmen. Dieser Modus bedeutet, dass Sie auch die Verantwortung für die Projektleitung des Toolprojekts übernehmen, wobei gewisse punktuelle Unterstützungsleistungen immer bei avedos verbleiben werden. Das bezieht sich insbesondere auf die Tätigkeiten rund um das Reporting und Dashboarding sowie auf die Customizing-, d.h. die Individualentwicklung, die von unseren Experten durchgeführt werden muss. Es gibt bestimmte Voraussetzungen für diesen Modus, bspw. ist es für uns enorm wichtig, dass die Infrastruktur auch bei Ihnen aufgebaut wird, damit Sie dort eigenständig arbeiten können und es ist zwingend notwendig, dass Sie die Partnerausbildung, die wir anbieten, abschließen.

 

Dieses Partner-Onboarding Konzept haben wir speziell nach den ersten Zusammenarbeiten und Erfahrungen mit unseren Partnern entwickelt. Es sind im Grunde zehn Tage, die Sie investieren, in denen Sie in Allem ausgebildet werden, was Sie zur Implementierung bei Kunden brauchen. Es gibt dort eine gesunde Mischung aus Theorie und Praxis: man beginnt mit grundlegenden Dingen, wie dem Scorecard Konzept oder dem Pflichtenheft und arbeitet sich vor bis dahin, wie man die eigentliche Konfiguration im Produkt macht. Tag 6, bspw., widmet sich der Aktivitätsmatrix, wo es um Sichtbarkeitssteuerungen geht, bis hin zum Tag 10, wo sämtliche Lerninhalte nochmal gemeinsam reviewed werden.

 

Sobald dieses Onboarding abgeschlossen ist, schließt sich meist das erste Projekt an, bei dem unsere Partner in der Regel in der Federführung sind wobei wir besonders am Anfang mit Rat und Tat zur Seite stehen und auch bei Fragen jederzeit erreichbar sind.

 

Alternativen im Projektvorgehen

Nachdem geklärt ist, wer das Projekt in der Federführung übernimmt, schließt sich die Frage an, wie man das Projekt durchführt und hier ist das sog. agile Vorgehen zurzeit in aller Munde. Hierbei ist von besonderer Bedeutung, dass man die Erwartungen des Kunden an diesen agilen Ansatz anpasst. Das bedeutet bspw., dass im Wasserfallansatz die Projektziele klar definiert sind und stabil bleiben, wohingegen im agilen Vorgehen der Zeitrahmen und die Budgetvorgaben klar definiert sind, dafür ist man bei den Projektzielen etwas variabler. Aus unserer Sicht ist es besonders empfehlenswert, wenn man gemeinsam an dem Kundenprojekt arbeitet, diese Entscheidung auch gemeinsam zu treffen und sich auf eine bestimmte Arbeitsweise festlegt und dafür sorgt, dass alle Beteiligten hinter dieser Entscheidung stehen.

 

Wesentliche Merkmale der Projektvorgehen

 

 

Neben der Budgetfrage und wie man mit diesen variableren Zielgestaltungen umgeht ist aus unserer Sicht besonders wichtig, dass dem Kunden bewusst ist, dass er sich zwar weniger intensiv, dafür durchgehender in die agilen Projekte einbringen muss.

Neben dem Wasserfallansatz und dem agilen Vorgehen gibt es auch Mischformen bzw. hybride Ansätze, die durchaus sinnvoll sind und individuell vereinbart werden können.

 

Besonderheiten aus der Analyse- und Designphase

Dokumentation: Hier ist es besonders wichtig, dass wir nach der Sales-Phase und der internen Übergabe, die wir selbstverständlich durchführen, alles sauber dokumentieren, insbesondere wenn sich die Anforderungen dann nochmal geändert haben. Das Thema Dokumentation ist unserer Erfahrung nach insbesondere dann wichtig, wenn die Federführung nicht bei uns liegt, vor allem wenn wir an nachgelagerte Projektphasen denken wie Support und Betreuung.

 

Verfügbarkeit der Kundenansprechpartner: Die Ansprechpartner sind gerade auch im Zusammenspiel mit Ihnen sehr wichtig, ebenso für die Workshops. Insbesondere die wichtigen Entscheidungsträger auf Kundenseite gilt es an Bord zu holen, damit die Entscheidungen, die noch anstehen, rasch und verlässlich getroffen werden können.

 

Projektbegleitende Kommunikation: Ein drittes Thema ist das Stichwort projektbegleitende Kommunikation, mit der man unserer Erfahrung nach nie früh genug starten kann. Für uns bedeutet das, die gesamte Organisation frühzeitig zu informieren, dass es dieses Projekt gibt und anteasert, was das für die Organisation bedeutet. Und wir haben gute Erfahrungen damit gemacht, ausgewählte End User früh einzubinden. User, die z.B. auch die lokale Sicht gegenspiegeln können, das erleichtert das spätere Projekt, v.a. wenn wir an das Thema Roll-Out denken.

 

Zur Webinar Aufzeichnung

 

risk2value library

Die risk2value library ist eine Sammlung aus GRC-Bausteinen zur Verwendung in Implementierungsprojekten. Der Hintergrund, warum wir dieses neue Produkt ins Leben gerufen haben, lässt sich in drei Teile teilen:

 

Wir wollen besser werden in unseren Implementierungsprojekten, eine noch größere Standardisierung erreichen und schneller und agiler erste Ergebnisse beim Kunden erreichen können. Vor allem die Anforderungen, in kurzer Zeit zu einem ersten Prototypen zu kommen, begegnete uns immer häufiger und war ein starker Antreiber.

 

Ein weiterer wichtiger Punkt ist die Möglichkeit, dass unsere Kunden nach der gemeinsamen Entwicklung des ersten Systems, dieses eigenständig weiterentwickeln können. Zum einen das eigene System, zB ein ERM System noch verfeinern oder zu einer qualitativen Bewertung eine Quantitative ergänzen, zum Anderen aber auch verwandte GRC-Prozesse oder ganz neue Anwendungsfälle zu sehen.

 

Und schließlich sehen wir die library auch als Plattform, um den Wissenstransfer zwischen unseren Kunden und zwischen unseren Partner und zwischen Kunden und Partnern anzuregen. Das langfristige Ziel ist nämlich, neben den technischen Bausteinen auch fachliche Komponenten miteinzubringen.

 

Wenn Sie gerne nähere Informationen zur risk2value library hätten wenden Sie sich bitte an Claudia Howe.