Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann (Teil 1)

Die Effizienzsteigerung bei der internen und externen Zusammenarbeit, die durch den Einsatz  von Enterprise-2.0-Lösungen in Unternehmen erreicht werden kann, ist hier schon häufig thematisiert worden und – wie erste Studien am Beispiel der Wiki-Nutzung belegen – kaum bestreitbar.

Und trotzdem ist die Einführung eines kollaborativen Tools selten ein Selbstläufer (zumal mit dieser ein nicht unbeträchtlicher Wandel der Kommunikationskultur im Unternehmen verbunden ist). Woran und warum können Social-Software-Projekte also scheitern? In diesem und im folgenden Beitrag nennen wir 12 Gründe, die unter anderem auf den Überlegungen von Dion Hinchcliffe basieren.

1. Eine Lösung erfüllt nur die Bedürfnisse einer Abteilung

Häufig werden Lösungen „von unten“ und zunächst in einer einzelnen Abteilung implementiert. Für die Belange eben dieser Abteilung mag das entsprechende Tool auch gut geeignet sein. Wenn sich das System aber nicht an den Bedürfnissen des gesamten Unternehmens orientiert, wird die Ausweitung schwierig. Bereits in einer Abteilung vorhandene Lösungen sollten deshalb intensiv daraufhin geprüft werden, ob und inwieweit sie sich für einen flächendeckenden Rollout im Unternehmen eignen. Häufig ist das nämlich nicht oder nur bedingt der Fall.

2. Zuerst wird das Tool ausgewählt

Manche Unternehmen begehen den Fehler, das Pferd von hinten aufzuzäumen, und wählen ein Tool aus, ohne dass ein konkreter Bedarf für die Nutzung besteht. Anschließend wird viel Mühe darin investiert, Standardlösungen im Nachhinein an die tatsächlichen Anforderungen des Unternehmens anzupassen, was häufig nicht gelingt. Auch eine Studie von Jakob Nielsen bestätigt dies: Voraussetzung für die erfolgreiche Einführung eines Tools ist deren tatsächliche Notwendigkeit. Wenn das System dabei hilft, ein vorhandenes Problem zu lösen, lernen die Mitarbeiter auf „natürliche“ Weise, es zu nutzen. Löst es dagegen offensichtlich keine Probleme, wird es scheitern.

3. Das falsche Tool wählen und krampfhaft daran festhalten

Wenn Unternehmen sich sehr früh für ein bestimmtes System entscheiden, stellt sich während des Prozesses der Etablierung und Anpassung mitunter heraus, dass das Tool nicht uneingeschränkt geeignet ist und nicht alle bestehenden Anforderungen erfüllt. Obwohl hier eigentlich eine Kursänderung nötig wäre, sieht man davon ab und versucht stattdessen, das gewählte System dennoch auf Biegen und Brechen durchzusetzen.

Die Gründe hierfür sind vielfältig: Mal ist die Bedarfsermittlung nicht intensiv genug durchgeführt worden, mal wurden potenzielle Lösungen nicht gründlich evaluiert. Wenn sich herausstellt, dass eine Software ungeeignet ist, scheuen Unternehmen womöglich auch die Mehrkosten, die durch ein Umschwenken entstehen würden (und bedenken dabei nicht, dass ein gescheitertes Projekt das Unternehmen letztlich noch teurer zu stehen käme und die Probleme, die das Tool beheben soll, nach wie vor bestünden). Zudem spielen persönliche Vorlieben und Ressentiments von Führungskräften für oder gegen eine Software gerne eine unrühmliche Rolle, insbesondere dann, wenn diese an der Unternehmensrealität und den tatsächlichen Bedürfnissen vorbeigehen. In jedem Fall werden die Akzeptanz und die Nutzung des Tools leiden.

4. Keine Ressourcen für Einführung und Schulung

Zur erfolgreichen Einführung eines Enterprise-2.0-Tools gehört mehr als das Zur-Verfügung-Stellen einer geeigneten Plattform. Wenn Unternehmen es versäumen, den Mitarbeitern eine „Bedienungsanleitung“ an die Hand zu geben, werden daraus große Probleme im Hinblick auf die Akzeptanz resultieren: Auch die beste Usability bringt nicht viel, wenn die Mitarbeiter das Konzept nicht verstanden haben, für das ein Tool steht.

Die intensive Aufklärung der Mitarbeiter über die Funktionsweisen des Systems, über die notwendige Veränderung der Kommunikationskultur und über die Vorteile für jeden Einzelnen und für das ganze Unternehmen kann schon in der Anfangsphase viele Barrieren beseitigen. Eine Einführung nach dem Motto „Hier ist das System, nun fangen Sie mal an!“ gelingt in den seltensten Fällen.

5. Keine Unterstützung „von oben“

Immer wieder beruht die Einführung eines Kollaborations-Tools auf der Initiative der IT-Abteilung – und das Management interessiert sich nicht wirklich für das System. Die mangelnde Beteiligung der Geschäftsführung ist mit einem hohen Risiko verbunden. Nichts gegen das Graswurzelkonzept, aber ohne Unterstützung und Förderung „von oben“ wird sich ein Tool schwer auf breiter Ebene durchsetzen können.

6. Fehlende Beteiligung der IT-Abteilung

Das andere Extrem ist die fehlende oder mangelnde Integration der IT-Experten in das Projekt. Dabei spielen gerade die Planung und die Anpassung an die interne Infrastruktur eine wichtige Rolle für das Gelingen des Projekts. Treten hier Probleme und Verzögerungen auf, kommt es auch zu Problemen und Verzögerungen bei der Annahme des Systems und der Mitarbeiterbeteiligung.

Im zweiten Teil des Artikels werden sechs weitere Hindernisse beschrieben, die erfolgreichen Social-Software-Projekten im Weg stehen.

Weiterführende Informationen

Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Unsere spezielle Seite zum Thema Firmenwikis
Social Software: Der Wikipedia-Irrtum
Micro-Blogging: Argumente für das Twittern im Unternehmen
Micro-Blogging im Unternehmen: Potenziale und Anwendung am Beispiel des //SEIBERT/MEDIA-Micro-Blogs


Mehr über die Creative-Commons-Lizenz erfahren

Diese Schulung richtet sich an alle, die sicherer im Umgang mit den administrativen Funktionen im Confluence Backend werden und für Ihre Kolleg*innen als kompetente*r Ansprechpartner*in bereitstehen wollen.
ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar