Q: U.S. Navy, Wikimedia Commons, Lizenz: CC

Plaudern wir ein wenig aus dem Web 2.0-Nähkästchen: Der Erfolg eines Projekts hängt nicht zuletzt vom “Pilot Team” ab, das, um im Bild zu bleiben, die Plattform “zum Fliegen” bringen soll.

Ein Wiki zum Beispiel. Geht man von einer typischen Wiki-Implementation innerhalb eines Unternehmens aus, so läuft diese in Phasen ab, d.h. die Unternehmensmitarbeiter werden zu bestimmten Projektabschnitten in Gruppen in das Wiki eingeführt, die man wie folgt benennen kann:

Innovators: Hierbei handelt es sich um die Projektinitiatoren, die mit der Untersuchung der Mitarbeiteranforderungen, mit der Auswahl der Software, mit der Beantragung und Freigabe des entsprechenden Budgets und der Projektplanung betraut sind. Abhängig von der Unternehmensgröße, der Reichweite des geplanten Wikis und der Methode des Projektmanagements sind fünf bis zehn Mitarbeiter mit den betriebswirtschaftlichen und organisatorischen Aufgaben des sogenannten Pre-Pilots für ca. ein halbes Jahr (mit unterschiedlicher Arbeitsbelastung) beschäftigt. Die „Haupt“-Verantwortlichen für den Betrieb des Wikis, also die Wissensmanager und ggfs. ihre Assistenten werden essentieller Teil des Pilot Teams.

Pilot Team: Ein repräsentativer Ausschnitt der künftigen Wiki-User, die kurz nach der Installation des Wikis seine Arbeit aufnimmt. Meistens dreht es sich um ein Team von 20 bis 30 Usern, also eine Gruppengröße, mit der man auch in voller Besetzung während eines Meetings oder einer Telefonkonferenz noch effektiv arbeiten kann. Selbst bei großen Unternehmen ist diese Anzahl valide, da der Umfang der Aufgaben einigermaßen gleich bleibt (s. u.)

Extended Pilot Team: Ist das Wiki funktional, inhaltlich und strukturell vorbereitet, kann die nächste Gruppe angeheuert werden. Das Extended Pilot Team testet das Wiki, das sich in einer Art Beta-Version befindet, anhand seiner größeren Useranzahl und bringt damit eventuell weitere Fehler der Software und Anforderungen des Unternehmens ans Tageslicht. Demnach sollte es sich um eine kritische Masse von ca. 50 bis 70 Nutzern drehen, die sehr informell vom Pilot Team an das Wiki herangeführt werden. Meistens handelt es sich um technikaffine, neugierige Kollegen, die indirekt bereits von der Wikieinführung erfahren haben und gerne einen kritischen Blick auf die neue Plattform werfen.

Post Kick-Off-Community: Wie der Name bereits andeutet, werden irgendwann mit einem gewissen Trommelwirbel, wie z. B. durch eine Einladung des CEOs, die Tore des Wikis für alle Mitarbeiter geöffnet. Das Pilot Team und das Extended Pilot Team sind jedoch eindeutig identifizierbar, da sie als „Vorreiter“ nach wie vor gerade in der ersten Zeit dieser Phase spezielle Aufgaben zu erfüllen haben. Mit der Zeit ändert sich die Zusammensetzung des Teams der Verantwortlichen jedoch: Mitglieder des ursprünglichen Pilot Teams scheiden aus und werden durch andere Community-Mitglieder ersetzt.

Nachzügler: Auch wenn die Einführung des Wikis noch so erfolgreich ist, eine von Anfang hundertprozentige Annahme des Wikis durch die Mitarbeiter wird aus verschiedensten Gründen nicht erreicht. Selbst wenn man die frisch eingestellten Mitarbeiter nicht mitrechnet, tröpfeln noch Monate nach der Einführung des Wikis immer wieder Neulinge in das System.

Die Vorgehensweise anhand eines Phasenmodells stellt unterschiedliche Anforderungen an die jeweiligen Gruppen. Doch besonders die Zusammensetzung und Organisation des Pilot Teams sollte wohl durchdacht sein, da davon ein gelungener Start des Wikis abhängt.

Aufgaben des Pilot Teams

Den Mitgliedern des Teams darf nicht verschwiegen werden, dass ihre Tätigkeit mit viel Arbeit und Engagement verbunden ist. Der Prefill eines Wikis kostet Zeit und Energie, was auch vom Arbeitgeber durch entsprechende Zugeständnissen anerkannt werden muss.
Ganz grob gesagt soll das Pilot Team möglichst viel an und mit der neuen Plattform arbeiten, denn nur wer selbst mit dem Wiki umgeht, kann auch abschätzen, wo die Potenziale und Schwierigkeiten des Projekts liegen, kann helfen die Software anzupassen und für sein Unternehmen nutzbar zu machen.

Konkret stehen folgende Aufgaben im Raum:

• Kontakt zwischen dem Wikiprojekt und dem eigenem Arbeitsbereich, wie z. B. der eigenen Abteilung
  • Inhalte zur Verfügung stellen
  • Anforderungen an die Usability formulieren
• Strukturierung des Contents
• Funktionales Testen des Systems
• Training und Support für andere User
• Marketing und PR im Kollegenkreis

Die Koordination des Pilot Teams sollte über wöchentliche Meetings erfolgen. Dabei hat es sich als sinnvoll erwiesen, dass sich jedes Mitglied ein bestimmtes Arbeitspensum zuteilt, das in der darauffolgenden Woche zu erfüllen ist.

Zusammensetzung des Teams und Profil des Pilot Users

Wie sieht die typische Zusammenstellung des Pilot Teams aus? Am besten setzt man auf eine in jeder Hinsicht, aber besonders in folgenden Punkten, heterogene Gruppe:

Technische Kompetenz: Vom Computerneuling bis hin zum Programmierer kann sich das gesamte Spektrum der Teammitglieder erstrecken, da alle Perspektiven für die optimale Anpassung des Systems an das Unternehmen und seine Mitarbeiter interessant sind. Schließlich ist die Gesamtheit der angestrebten Community ebenso verschieden.

Abteilungen: Da die einzelnen Pilot User jeweils ihren thematischen Arbeitsbereich repräsentieren, sollte auch möglichst viele, wenn nicht sogar alle Abteilungen im Team vertreten sein, damit nicht eine oder mehrere Sektionen des Unternehmens ausgegrenzt werden. Die fehlenden Abteilungen nachträglich zu integrieren ist immer mit höherem Aufwand verbunden.

Hierarchien: Die Mischung unterschiedlicher Hierarchiegrade bringt v. a. den Vorteil, dass von Anfang an auf allen Ebenen eine Akzeptanz für das Wiki geschaffen wird und die unterschiedlichen Autoritätsstufen im Wiki möglichst flach gehalten werden können.

Alter: Gerade inhaltlich tragen Mitarbeiter reiferen Dienstalters anders zum Unternehmenswissen bei als beispielsweise die Auszubildenden. Während Letztere in ihrem Lernprozess gerade prädestiniert dazu sind, Lücken im Firmenwissen aufzuspüren und dokumentieren, schleifen die Älteren eher über die gesammelten Informationen drüber und ergänzen die Angaben durch Details

Wirft man einen Blick auf die einzelnen Persönlichkeiten des Teams, so gibt es wünschenswerte Charakteristika, die (fast) nicht fehlen dürfen:

Toleranz bezüglich Team UND System: Das installierte Wiki in seiner Rohfassung ist leer, langweilig, meist noch fehlerbehaftet und wenig funktional. Demensprechend „leidensfähig“ sollte der Pilot User sein. Auch die Heterogenität des Teams selbst kann die Geduld und Toleranz des Einzelnen extrem strapazieren.

Kreativität: Das Wiki ist funktional und inhaltlich (fast) beliebig formbar. Diese Freiheit sollte in vernünftigem Maße genutzt werden um eine ansprechende Lösung für die gesamte Community zu basteln. Daher sind durchaus auch Querdenker erwünscht, die aus der technischen Einheitswikiinstanz eine lebende Individualsoftware machen

Mut: Das Engagement in einem Pilot Team wird von den Kollegen nicht immer wohlwollend aufgenommen. Unsicherheit und Unverständnis gegenüber der neuen Plattform führen häufig zu gehässigen Bemerkungen bis hin zu offenem Widerstand. Standfestigkeit ist hier gefragt!

Fleiß und Selbstdisziplin: Wie der obere Abschnitt schon deutlich machen sollte, darf nicht unterschätzt werden, wieviel Arbeit in einer Wiki-Implementation steckt. Vom eigenen Beschäftigung mit dem Systems über die Strukturierung der Inhalte bis hin zur Pflege einer ansehnlichen Community ist ein weiter Weg, der manchmal auch mit Rückschlägen gepflastert ist.

Idealismus: Oft heißt es, dass ein Wiki die Firmenkultur positiv verändert. Ganz so weit möchte ich gar nicht argumentieren. Es genügt daran zu glauben, dass das Wiki eigentlich keine bloße Software sondern ein Prinzip darstellt, das die Arbeitsweisen in einer Organisation stärker an die Bedürfnisse der Menschen anpassen kann. Diese Einsicht benötigt der Pilot User um den Prozess einer Wiki-Einführung von dem anderer Software-Projekte zu unterscheiden.

Fazit

Rein äußerlich scheint die Auswahl eines Pilot Teams keine aufwendige oder gar komplizierte Sache zu sein. Oft ist man dabei sogar auf die freiwillige Teilnahme der Mitarbeiter beschränkt und hat keinen direkten Einfluss auf die Zusammensetzung. Dennoch lohnt es sich, ein paar Gedanken in die Planung der Teamarbeit zu stecken, um eventuelle Fehlbesetzungen zu vermeiden.

Tenor der Beiträge war, dass die Einführung eines Wikis eine Managementaufgabe ist, für die Geld und Personal zur Verfügung stehen muss. Perspektivisch sehen wir von Hallo Welt! zwei Entwicklungen:

• der Schwerpunkt der künftigen Entwicklung wird auf der inhatlichen Arbeit und Prozessorientierung liegen
• Wissensmanagement wird noch mehr und radikaler  “bottom-up” organisiert  werden müssen

Das soll jedoch nicht heißen, dass technisch nicht mehr zu tun wäre. Doch die technische Anpassung und Integration folgt immer weniger der Faszination, die von den technischen Spielmöglichkeiten ausgeht, sondern von den Anforderungen des betrieblichen Alltags.

Die Folien gibt es online zum Download.

Handelsübliche Käsetheke. Q:Wikimedia Commons

In ihrem Supermarkt gibt es eine Fleisch- und Käsetheke oder ein Kühlregal. Ist Ihnen schon einmal aufgefallen, dass Sie zu diesen Orten, an denen verderbliche Ware verkauft werden, immer durch den ganzen Laden rennen müssen? Ja? Das ist natürlich Absicht. Im Wirtschaftsjargon nennt man das „Frequenzbringer“. Gemeint sind Waren im Sortiment, die besonders günstig sind (“Lockangebote”) oder täglich neu eingekauft werden müssen. Sie werden so platziert, dass man an allen Regalen vorbei muss, und dann auf den ganzen anderen Kram stößt, dessen Kauf eigentlich nicht beabsichtigt war. Ein Frequenzbringer kann aber auch ein Bereich sein, in dem es immer Sonderangebote gibt, denken Sie an die bekannten Discounter. Es wird in jedem Laden immer bestimmte Warengruppen geben – verderblich, billig oder beides, die täglich und immer wieder Kunden in den Laden spülen sollen. Städtebaulich können übrigens Cafés, Kaufhäuser oder kulturelle Einrichtungen als Frequenzbringer dienen.

Was hat des mit Web und Web 2.0 zu tun? Web 2.0-Anwendungen sind unter anderem attraktiv, weil man dort aktuelle Veränderungen beobachten kann. In Facebook sehe ich die neuesten Statusmeldungen und Kommentare meiner Freunde, bei Wikipedia die „Letzten Änderungen“, im Weblog den neusten Eintrag.

Wir von Hallo Welt! nennen diese Features auch „Frequenzbringer“, weil sie dazu ermuntern, mindestens einmal täglich auf eine Seite zu sehen. Im Unterschied zu den Frequenzbringern Ihres Supermarkts, sind die Frequenzbringer im Web normalerweise nicht irgendwo „hinten“, sondern “vorne”, beim Einstieg oder im Portal, angeordnet.

Frequenzbringer können ganz unterschiedlich sein.

Für passives Medienverhalten gibt es die Neuesten Seiten, Neuesten Dateien und Bilder, häufig wechselnde Artikel,  die neuesten Nutzer, Veränderungen in Profilen, E-Mailbenachrichtigungen wie „Franz X. hat eben Ihren Kommentar gelöscht“, (Video-)Blogeinträge, RSS-Feeds oder ein Microblog à la Twitter.

Im aktiven Medienverhalten können Foren und Kommentarfunktionen, aber auch Spiele eine Frequenzbringer-Funktion erfüllen. Frequenzbringer müssen in jedem Fall schnell konsumierbar sein oder dürfen nur einem geringen Arbeitsaufwand nach sich ziehen: bestimmte Votings wären ein weiteres Beispiel.

Keine Frequenzbringer sind natürlich Navigationselemente wie Tagclouds oder Rubriken mit statischem Inhalt.

Soll nun eine Startseite eine größere Aufmerksamkeit erhalten, muss sie ein bestimmtes Maß interessanter oder relevanter Neuigkeiten bereithalten. Und bei erfolgreichen Webprojekten werden diese mit einem erfahrenen journalistischen Blick für Layout und Design zusammengestellt.

Doch Vorsicht: Nicht immer ist der Einsatz von Frequenzbringern sinnvoll. Im Unternehmensumfeld, kann ein relativ statisches Betriebshandbuch eigentlich darauf verzichten. Ein Intranet-Startportal dagegen benötigt relevante News, die dann auch gepflegt werden müssen. Offizielle wie inoffizielle Online-Redakteure übernehmen  hier streckenweise die Funktion von Publishern.  Schon aus Gründen der Zeitersparnis kommen dann oft Dienste zum Einsatz, die Beiträge verschiedener Autoren automatisiert bereitstellen.

Ganz generell sollte man Frequenzbringer unbedingt sparsam und mit Blick auf die gesamte Softwarelandschaft einsetzen, um die eh schon steigenden Informationsflut und Reizüberflutung einzudämmen. Machen Sie es wie ihr Supermarkt: Lassen Sie sich ggf. fachkundig beraten.

Ok, das klingt für den Außenstehenden vielleicht etwas trocken, ist aber super spannend, weil dahinter Zukunftsfragen stehen: Wie sieht heute die Arbeitswelt von Leuten aus und wie wird sie in zehn Jahren aussehen?

Zu beobachten ist, dass Prozesse, Kommunikation und Dokumentation in den Unternehmen zunehmend dezentral organisiert werden: über mehrere Standorte verteilt, im engerem Zusammenspiel von Organisationseinheiten etc. Dazu braucht man Systeme und Verfahren, die diesen dezentralen Strukturen gerecht werden.

Aus diesem Grund ist  “Enterprise 2.0″ auch kein Hype, sondern kennzeichnet einen mittelfristigen Wandel der Kommunikationspolitik auch in den Unternehmen. Es geht ja nicht darum, ein Wiki oder ein Weblog einzurichten. Gefragt ist vielmehr ein neues Denken – Entwicklung “bottom-up”, wirkliche Einbeziehung von Mitarbeitern, Schaffung kommunkativer Freiräume. Die Web 2.0-Technologien regen diese Debatte lediglich an und ermöglichen den Strukturwandel.

Wer diesen Weg gehen will, braucht eine Strategie, das nötige Know-how, Manpower und Unterstützung. Unser Ansatz Beratung und Softwareprogrammierung zu kombinieren, hat sich daher als inhaltlich völlig richtig erwiesen.

Und die Leute aus der Unteren Bachgasse machen weiter und gehen die nächsten Schritte. Auf der Oberfläche wird dies durch ein Redesign deutlich, das bis Anfang 2010 umgesetzt wird. Auch dieses Blog ist Teil einer umfassenden Neuausrichtung:  Wir möchten diese Entwicklungen noch aktiver mitgestalten und noch enger mit Ihnen -  Kunden, Kollegen, Freunde, Neugierige, Innovatoren etc. – ins Gespräch kommen. Ideen teilen? Machen wir.