Zu Beginn betrachten Mitarbeiter Wikis aus 2 Blickwinkeln. Da gibt es zum einen die Nutzer oder besser die Nutznießer, die den Zugriff auf das für sie erforderliche Wissen haben wollen und dies so komfortabel wie möglich. Zum anderen gibt es die Wissensbereitsteller, deren Vorteil in der Effizienz der Bereitstellung, der erhofften Synergien in Form der gestärkten Zusammenarbeit und auch der erwarteten Anerkennung liegt.
Der Wiki-Einsatz wird natürlich erfolgreicher, je mehr es gelingt den Bedarf der Nutznießer zu befriedigen und diese als aktive Wissensbereitsteller zu mobilisieren.
Produktmanager
Der Produktmanager freut sich fast immer auf ein Wiki oder eine Enterprise 2.0-Lösungen. Er gewinnt in jedem Fall. Sei es, dass er nicht mehr jede Frage 10-mal beantworten muss, er mehr Kollegen aus seinem Umfeld in die Produktmanagementarbeit integrieren kann oder die Kunden-/Marktnähe größer wird. Ich habe selten Produktmanager gesehen, die nicht sofort die Vorteile erkannt haben. Einzige Bedenken sind, dass die Lösungen und die Fütterung mit Informationen ihre zeitlichen Kapazitäten überfordern kann und wie diese Herausforderung gelöst wird.
Technische Engineers/Projektmanager/Projekteure
Hier liegt der größte Hebel für den Erfolg eines Wiki-Projektes. Von Natur aus zählt diese Gruppe zu den wichtigsten Nutznießern und den wichtigsten Know-how-Trägern außerhalb des Produktmanagements. Die Mitarbeiter dieser Gruppe profitieren in dreifachem Sinne, denn sie können mit einem Wiki ihre Aufgabe besser erfüllen, gestalten die zukünftigen Produkte mit und erhalten die Chance ihre Leistungsfähigkeit in der Produktgestaltung zu zeigen. In der Regel leisten diese Kollegen gerne, insbesondere dann, wenn das Thema von ihren Chefs wohlwollend begleitet wird.
Vertriebsbeauftragte/Account Manager
Der Account Manager schätzt den Nutzen eines Vertriebs-Wikis, möchte allerdings auf seine persönlichen Ansprechpartner und den kurzen Draht zu den Know-how-Trägern nicht verzichten. Die Account Manager sind als Inputgeber eher zurückhaltend, da ihre Ausrichtung primär auf Geschäftszahlen fokussiert ist. Sie werden meist auch so gesteuert. Am besten funktioniert die Zusammenarbeit nach dem Prinzip Win-Win, einer regelmäßigen Motivation und der kundenorientierten Zusammenarbeit. Die Erwartungen an den Input sollten jedoch nicht zu hoch geschraubt werden.
Mitarbeiter in der Dokumentation
Der Mitarbeiter Typ 1 ist unzufrieden, wenn noch ein Verfahren bzw. noch ein Tool eingeführt wird. Er sieht die Mehrarbeit vor sich und glaubt nicht an die Zusammenarbeit mit den Kollegen. In diesem Fall gilt es die Vorteile in der Umsetzung zu belegen, aber auch einen aktiven Support z.B. durch additive Ressourcen zu bieten.
Der Mitarbeiter Typ 2 sieht die Vorteile gegenüber dem klassischen Dokumenten-Management-System und will die Chancen und Vorteile in Sinne des einfachen und effektiven Nebeneinander nutzen. Durch ihre Vorbildung können diese Kollegen ein Wiki häufig nach kurzer Einweisung virtuos bedienen und haben Spaß an der Nutzung.
Entwickler
Toll jetzt endlich – Wollte ich doch schon immer – Machen wir in der Entwicklung doch längst – Dann bekomme ich endlich mehr Input aus dem Vertrieb – Wir müssen besser dokumentieren, was wir warum gemacht haben, um später das Rad nicht wieder neu erfinden zu müssen. Das sind typische Reaktionen im Entwicklungsbereich. Hier ist die Toleranz hinsichtlich einer eventuell fehlenden Tool-Perfektion am größten. Die Zusammenarbeit im Bereich Pflichten- und Lastenheft funktioniert perfekt, solange die Zuarbeit auch verantwortungs- und funktionsgerecht erfolgt und der Entwickler seine kreativen Gestaltungsmöglichkeiten behält.
Service-Spezialisten
Auch die Service-Spezialisten schätzen und lieben Wikis / Enterprise 2.0-Lösungen. Sie benötigen das Wissen bezogen sowohl auf die eigenen Produkte und Lösungen (alt und neu) als auch auf Partnersysteme und die Kundenrealitäten. Das Wissen ist meist nur in den Köpfen weniger oder verteilt auf mehrere Kollegen und der Informationsaustausch mit den Kollegen ist eine elementare Voraussetzung für eine erfolgreiche Installationen sowie Betrieb von Lösungen. Wikis machen das Leben für den Service-Techniker lebenswerter und der Service-Spezialist liefert auch gerne zu.
In Summe gilt, dass die Vorteile von allen Beteiligten gesehen werden und immer eine ausreichende Zahl an Unterstützern bzw. Evangelisten für ein Wiki-Projekt bereit stehen. Zu beachten ist die Sorge um den temporären Mehraufwand zu Beginn eines Wiki-Projektes, für die es gilt, eine Lösung zu schaffen. Des Weiteren ist der Schlüssel eine professionelle Projektorganisation, die die unabdingbare Teamkultur fördert, rechtzeitig mögliche Klippen umschifft und die realistische Taktung gewährleistet.
1 Kommentar
Trackback URL Comments RSS Feed
Sites That Link to this Post