Nutzung des BICC als Leuchtturmprojekt mittels Change Management

Dieser Fachartikel der Autoren Mag. Christian Gasperi und Markus Rotter, MA ist Teil der Artikelserie zum Thema "From Chaos to Organization: Einführung eines BICC in einem KMU”.

Die Erstellung von Konzepten kann bereits sehr herausfordernd sein. Die Implementierung ist definitiv noch schwieriger, da diese neben fachlichen Fähigkeiten auch ein entsprechendes Repertoire an Soft-Skills erfordern. Viele Firmen nutzen hierzu externe Hilfe, um den Erfolg dieser Unternehmung zu gewährleisten. Denn schlechtes (oder nicht vorhandenes) Veränderungsmanagement kann die besten Konzepte zum Scheitern bringen. Dieser Artikel beschreibt die Vorgangsweise der Autoren, um mittels eines Leuchtturmprojekts, das Business Intelligence Competency Center (BICC), ein Keyuserkonzept voranzutreiben.

Folgende Grafik stellt den Prozess schematisch dar:

Abbildung 1: Ablauf der Einführung eines Keyuserkonzepts am Beispiel eines BICC

Es ist von zentraler Bedeutung für dieses Konzept, dass jegliche Veränderung in der Organisation einen Mehrwert darstellt, also keine Veränderungen nur der Veränderung wegen angestrebt werden. Die Schritte lassen sich in einmalige Prozessschritte (blau) und kontinuierliche Verbesserungszyklen (grün) unterteilen.

Herangehensweise zur Einführung

Bedarf ermitteln

Der erste Schritt ist eine lückenlose Ermittlung des Bedarfs für das oben beschrieben Konzept in der Organisation. Wenn vorheriger Schritt durchgeführt wurde und Bedarf an einer Verbesserung besteht, muss jedoch kritisch hinterfragt werden, ob eine Änderung in dieser Größenordnung sinnvoll und notwendig ist. Für die Bedarfsermittlung verwenden die Autoren Workshops, da sich diese sehr gut zur Erarbeitung der aktuellen Lage eignen.

Prozesse und Umfeld analysieren

Nachdem der Bedarf für einen Change verifiziert wurde, muss eine sorgfältige Analyse durchgeführt werden. In dieser Überprüfung werden die aktuellen Prozesse durchleuchtet und Verbesserungspotenziale ermittelt. Wichtig dabei ist, dass eine Umfeldanalyse getätigt wird und dabei die Stakeholder identifiziert und in weiterer Folge ein adäquates Stakeholdermanagement implementiert wird. Eine vollständige Beschreibung würde den hier gespannten Rahmen sprengen. Die Autoren werden sich in naher Zukunft diesem Thema mit einer separaten Veröffentlichung widmen und den Artikel an dieser Stelle verlinken.

Lösungsansätze erarbeiten

In weiteren Workshops und Diskussionen mit den Stakeholdern und Fachbereichen werden nun Möglichkeiten erarbeitet, um das Konzept in der Organisation zu verankern. Zu beachten ist, dass zwar die Eckpunkte des Keyuserkonzepts einzuhalten sind, es jedoch kein starres, sondern ein generisches Modell zu Grunde liegt. Ziel ist es, der Organisation einen Nutzen zu bringen, daher müssen diese Lösungsansätze gemeinsam erarbeitet und erweitert, anstatt vorgegeben zu werden. Man sollte bereits in diesem Schritt die Chance nutzen das Big Picture gemeinsam zu definieren und ein gemeinsames „Warum machen wir das“ (siehe dazu eine Referenz zum „Golden Circle“ von Simon Sinek bzw. dem St. Gallener Management Modell) zu schaffen.

Planung des Projekts

Nachdem die Eckpunkte definiert wurden, sollte das Projektausmaß (Scope) bekannt sein, somit kann eine Detailplanung erfolgen. Dieser Entwurf sollte finanzielle, personelle sowie zeitliche Komponenten berücksichtigen und der Geschäftsführung eine realistische Zeitlinie bei einer transparenten Kostenstruktur bieten. Dabei ist zu beachten, dass die vorgestellte Handlungsweise in entscheidungsfähiger Form vorliegt, damit die Verpflichtung zur Umsetzung seitens der Geschäftsführung rasch erfolgen kann.

Präsentation an die Geschäftsführung

Der logische Schritt nach einer Planung ist eine angemessene Präsentation. Gemäß des bereits erwähnten Stakeholdermanagements sollten die gewünschten Kanäle und Form der Präsentation der Geschäftsführung bekannt sein. Ziel ist es eine Freigabe zum Projekt (oder Teilen davon) und vor allem die entsprechende Verpflichtung zur Umsetzung („Commitment“) zu erhalten. Das „gemeinsame Warum“ muss durch die Geschäftsführung gesichert und gegebenenfalls müssen Widerstände mit Hilfe der Geschäftsführung in weiterer Folge auch beseitigt werden.

Information Top/Down

Nun werden das abgestimmte Konzept und der Plan zur Umsetzung Top/Down, also von oben durch die Hierarchieebenen, kommuniziert. Diese Kommunikationsform sollte nicht mit dem Top/Down-Veränderungsmodell verwechselt werden, denn das gemeinsame „Warum“ ist die oberste Prämisse und sollte nun auf den nächsten Hierarchieebenen getragen werden. Wichtig zur erwähnen ist, dass Informationen und Konzepte nicht in die Organisation gedrückt werden, sondern eher abgeholt werden (ähnlich den Push- und Pull-Prinzipien in der Logistik oder bei agilen Entwicklungsmethoden) da ansonsten der Change schon zu Beginn scheitern wird. In diese Phase ist mit größeren Widerständen zu rechnen, daher sind Transparenz und Vorteile für die Fachbereiche von zentraler Bedeutung. Nach Erfahrung der Autoren wird eine einzelne Präsentation nicht ausreichen, um sämtliche Bereiche zu überzeugen. Daher sollte für den Informationsfluss bzw. -austausch entsprechend viel Zeit eingeplant werden damit auf bestehende Widerstände eingegangen und diese durch gemeinsame Erarbeitung (im Folgeschritt) aufgelöst werden können. In dieser Phase des Changes steht das "Gemeinsam" im Vordergrund.

Feinkonzept ausarbeiten

Nun wird das Feinkonzept mit den entsprechenden Bereichen ausgearbeitet und es muss zwingend ein gemeinsamer Weg gefunden werden. Einerseits sollten die Eckpunkte des Konzepts berücksichtigt werden, aber anderseits auch Platz für eine Nutzenmaximierung der Fachbereiche vorhanden sein. Um den maximalen Mehrwert für die Organisation darzustellen, ist es notwendig gemeinsame Anpassungen an dem Konzept zu erlauben, anstatt die kompromisslose Integration in die Organisation. Vielmehr sollten die Hauptprobleme der Fachbereiche und leichte Adaptionen mit sichtbarem Nutzen („Low Hanging Fruits“) ermittelt werden.

Gemeinsam mit den Schritten „Prozesse und Umfeld analysieren“ und „Lösungsansätze erarbeiten“ sollte dieser Schritt im Rahmen einer kontinuierlichen Verbesserung mehrmals durchlaufen und überarbeitet werden.

Prototyp bereitstellen

Der Prototyp soll die Funktionalität und den generierten Mehrwert für die Organisation beweisen und dadurch den Bedarf wecken. Der Hauptzweck dieses „Leuchtturmprojekts“ ist es, kritisch eingestellte Stakeholder zu überzeugen. In unserem Beispiel wird dazu das bereits beschriebene BICC genutzt.

In einer Kick-Off-Veranstaltung wird der Prototyp in Dienst gestellt und die ersten Keyuser sollen die Möglichkeit haben ein Netzwerk zu bilden. Die bis dahin genossenen Schulungen stellen eine gute Basis für die Keyuser dar. Gemäß des „Keyuser-Lifecycles“ sollten bei dieser Gelegenheit auch weitere Schulungsbedarfe erhoben und langfristig gedeckt werden.

Regelbetrieb herstellen

Entsprechend des Ablaufplans werden nun die weiteren KeyuserInnen in den entsprechenden Domänen eingesetzt.

Schlussbetrachtung

Die Autoren haben gute Erfahrungen mit der hier beschriebenen Vorgehensweise zur Einführung eines Keyuserkonzepts gemacht. Die große Komplexität der Materie und eine Detailbetrachtung würde den Rahmen dieses Artikels sprengen. Die Relevanz für ein angemessenes „Change Management“ sollte dieser Artikel aber transportiert haben. Neben Fähigkeiten in diesem Bereich und einer stringenten Planung zur Umsetzung ist vor allem ein hohes Ausmaß an Beharrlichkeit und ein breites Repertoire an Soft-Skills vonnöten, wenn ein derartiges Projekt erfolgreich sein soll.

Das Wichtigste bei der Umsetzung ist es stets daran zu denken, dass das Keyuserkonzept kein Selbstzweck ist und der Nutzen der Organisation an oberster Stelle steht.

Über die Autoren

Mag. Christian Gasperi Markus Rotter, MA

Mag. Christian Gasperi ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit Business Itelligence, Datawarehousing, Geoinformatik, Datenbanken, IT-Architkur, Systemarchitektur, Projektmanagement und lateraler Mitarbeiterführung gemacht. Markus Rotter, MA ist seit den 2000ern in der IT tätig und hat in dieser Zeit Erfahrungen mit IT-Management, Business Intelligence, Datawarehousing, Datenbanken, Systemadministration, IT-Architekturen, Mitarbeiterführung und Projektmanagement gemacht.
Homepage Homepage
Xing Profil Xing Profil

 

Zurück

Übersicht der Artikel

Dieser Fachartikel verdeutlicht das Abbilden eines IT-Portfolios in einem Ticket-Issue-System.

Weiterlesen

Dieser Artikel behandelt die Grundlagen des agilen Arbeitens, im speziellen KANBAN und SCRUM.

Weiterlesen

Dieser Fachartikel beschreibt das Abbilden des Keyuserkonzepts in einem Ticket-Issue-System.

Weiterlesen

Dieser Artikel beschreibt eine Vorgangsweise, um mittels eines Leuchtturmprojekts ein Keyuserkonzept voranzutreiben.

Weiterlesen