Das "BlueSpice docu" Weihnachtspaket

Unsere Wiki-Handbuchlösung  BlueSpice docu macht die Erstellung von Firmenhandbüchern, Qualitätshandbüchern, Ablaufbeschreibungen und Team-Seiten einfacher, interaktiver und schneller als je zuvor. Mit den neuen Oracle- und Postgres-Anbindungen fügt sich die Software nahtlos in jede IT-Landschaft ein. Sie bietet darüber hinaus Enterprise Content und Search-Funktionen, die sonst nur mit teurer Spezialsoftware erhältlich sind.

Einige Neuerungen im Überblick:

• Noch einfachere Verwaltung des Systems
• Erweiterte Enterprise-Suche
• Individuelle Anpassungsmöglichkeiten
• Rationelleres Arbeiten durch bereichsspezifische Seitenvorlagen
• Bessere Zusammenarbeit im Autorenteam durch Interaktions- und Kommentarfunktionen direkt auf der Seite
• Neues, klares und noch übersichtlicheres Design

Wir gewähren  15% Jahresschluss-Rabatt, wenn Sie sich noch vor Ende des Jahres für den Erwerb von BlueSpice docu entscheiden!

Informieren Sie sich hier!

Ihr Kontakt:

Dr. Michael Scherm
+49 (0) 941 - 66080 -197

Ein Kernproblem, das im Zusammenhang mit Mehrkanalstrategien immer wieder auftaucht, ist „Channel Conflict“. Damit gemeint sind die Fälle, in denen verschiedene Vertriebs- und Marketingkanäle sich nicht gegenseitig nützen und unterstützen, sondern sich schaden und sich unter Umständen sogar vollständig blockieren.

„Multi Channel Integration“ und „Channel Conflict“ werden auch in zunehmendem Maße relevant, wenn man die internen Abläufe in Unternehmen betrachtet. Denn die Fragestellungen und Probleme, die im Zusammenhang mit der Multi Channel Integration in Marketing und Vertrieb diskutiert wurden, erinnern stark an diejenigen, die heute im Zusammenhang mit der Nutzbarmachung von Web 2.0-Technologien für Unternehmen auftauchen. Der Blick darauf, wie Multi Channel-Strategien in Vertrieb und Marketing umgesetzt werden, lohnt sich deshalb nicht nur für die einschlägigen Zielgruppen, sondern auch für den Wissens-, Prozess-, Produkt- und Qualitätsmanager.

Lesen Sie hier das Whitepaper zum Thema: HalloWelt_Multichannel

Heute verfügen wir auf breiter Fläche über Erfahrungen und Studien. McKinsey hat bereits Anfang des Jahres Ergebnisse einer Befragung von 3.249 Unternehmen veröffentlicht. Interessant sind hier die Aussagen zum internen Einsatz von Web 2.0. Unternehmenswelt.de fasst das Ergebnis zusammen:

Auch die interne Verwendung durch das Personal selbst, beispielsweise über Unternehmens-Wikis oder Blogs macht sich bemerkbar. Hier sehen 77 % der Web 2.0-nutzenden Unternehmen einen besseren Zugang zu Informationen, 60 % sinkende Kommunikationskosten und 52 % einen schnelleren Zugang zu Experten. 44 % berichten von sinkenden Reisekosten, 41 %  von einer größeren Mitarbeiterzufriedenheit. 29 % sehen ihre Produkte schneller an den Markt gebracht und 18 % bemerken einen steigenden Umsatz.

Eine Umsatzsteigerung kann über den internen Web 2.0-Tools erreicht werden, wenn zum Beispiel die Informationen über Produkte, Kampagnen und Kundenprojekte verbessert wird. Letztlich unterstützen diese Tools die Organisation von Unternehmen als Communities. Dazu reicht aber - ceterum censeo - nach unserer Erfahrung eine technische Umstellung alleine nicht aus. Auch eine freiere und lebendigere interne Kommunikation muss organisatorisch gut vorbereitet werden.

Effiziente technische Dokumentation ist eine zentrale Aufgabe in Industrie, Verwaltung und Versorgungswirtschaft. Hier revolutionieren Wikis (hawaiisch für „schnell“), und namentlich die Wikipedia-Software MediaWiki, Vorgehensweisen und Verfahren. „Wikis reduzieren den Zeit- und Arbeitsaufwand für Dokumentationen erheblich“, sagt Dr. Michael Scherm von der Hallo Welt! GmbH. „Die Daten werden nicht mehr in Textverarbeitungs- oder komplexen Dokumentenmanagementsystemen bereitgehalten, sondern in einem Wiki gemeinsam online erarbeitet und gepflegt. „Die Texte werden so einfach und arbeitsteilig erstellt, wie man es aus der Wikipedia kennt, aber die Qualitätskontrolle erfüllt höchste Ansprüche“, erklärt sein Kollege Radovan Kubani, Geschäftsführer.

Open Source aus Bayern

Auf der Hannover Messe präsentiert das Regensburger Unternehmen eine neuartige Lösung auf der Basis von MediaWiki: BlueCraft ist eine Komplettlösung, mit der Unternehmen schnell, effektiv und kostengünstig Handbücher erstellen und pflegen können. Die führende Wikisoftware MediaWiki wird intelligent mit den Anforderungen von Unternehmen verknüpft (einfache Bedienung, Revisionssicherheit, Berechtigungsmanagement, umfangreiche Such-, Export- und Automatisierungsfunktionen).

Eine Lösung die sich bereits vielfach bewährt hat

BlueCraft Screen

BlueCraft ist bereits erfolgreich bei Unternehmen im Einsatz und wird vor allem in Branchen nachgefragt, die sich durch ein hohes Maß an Dynamik und Technologisierung (Energie, Automotive, Mechatronik, Umwelttechnik, Maschinenbau, Luft- und Raumfahrt, Medizintechnik, Elektrotechnik) auszeichnen.

Typische Anwendungsfälle sind technische Dokumentationen, Prozessbeschreibungen, Verfahrensanweisungen und Vorlagen für Nachweise. Zertifizierungsverfahren (z.B. ISO 9001: 2008) werden mit der Onlineplattform genauso unterstützt wie interne Qualitätsaudits.

Auf der Hannover Messe gibt Hallo Welt! einen Ausblick auf die zweite – semantische – Generation des Handbuchs („Web 3.0“).

Hannover Messe
Halle 2, Stand A 54
(Bayern Innovativ)

Wiki wird zentrale Wissensplattform unserer Filialen

Das für die Neustrukturierung eingeführte Content Management System erwies sich bald als unpraktisch. Die BerlinApotheke etablierte schließlich auf Basis der Software MediaWiki eine allgemeine Wissensplattform. Mit dem Wiki ließen sich jetzt die Workflows dynamisch optimieren. Der offene Prozess der Wissenssammlung im Wiki machte die Unternehmensorganisation transparent und förderte die interne Kommunikation.

Die Idee, das Wiki auch als Qualitätsmanagementsystem einzusetzen und nach der DIN EN ISO 9001:2008 zertifizieren zu lassen, war nur ein konsequenter Schritt. Wesentliche Vorteile des Wikis wie z.B. die Verlinkung zu anderen Prozessen, Dokumenten und das Einfügen von Weblinks, konnten für das Qualitätsmanagement genutzt werden. Zudem konnte das Qualitätsmanagementsystem dezentralisiert werden. Sie erleichterten das Arbeiten und steigerten die Effizienz. Mit den alten Systemen war das so nicht möglich. Das vorher verwendete Intranet und das Dokumentationssystem wurden schließlich zugunsten eines Systems, nämlich des Wikis, aufgegeben.

Konzeptionelle und technisch unterstützte uns die Hallo Welt! - Medienwerkstatt bei diesem Projekt der Restrukturierung.

Vier Schritte zum QMS-Wiki

Für die Vorbereitung der Übersetzung des Qualitätsmanagements in das Wiki wurde viel Zeit eingeplant, um alle Eventualitäten mit einzubeziehen und durchzudenken. Damit konnte ein möglichst sicheres und optimales Ergebnis erzielt und die Zertifizierung gewährleistet werden.

In einem ersten Schritt wurden Anforderungen an die Funktionen des Systems gestellt. Richtungsgebende Fragen waren dabei:

• Was ist an technischer Infrastruktur bereits vorhanden?
• Wo sind wesentliche Verbesserungen notwendig?
• Welche Funktionen müssen zusätzlich generiert werden? (vor allem in Bezug auf die Anforderungen nach der ISO 9001)
• Wer ist für den Aufbau zuständig?

Schritt  zwei des QMS-Projekts betraf die Strukturierung und Festlegung von Inhalten mit Hilfe eines Kernteams. Deshalb wurden für das QMS Projekt sowohl Mitarbeiter aus den Fachbereichen, als auch aus der IT herangezogen. Zudem nahmen wir einige sogenannte „Poweruser“ ins Team, die reell mit dem QMS nichts zu tun haben, jedoch über ihre eigenen Blickwinkel auf die Themen für das schnelle Ausarbeiten der Inhalte wichtig waren.

In Schritt drei wurden die Planungen umgesetzt, ein Redaktionsteam gebildet und das System intern beworben und vorgestellt.

Die Abnahme und Rezertifizierung durch den Auditor Ende 2009 stellte den letzten Schritt dar.
Um das Zertifikat zu erhalten, war es notwendig, entgegen dem Wiki-Prinzip bestimmte Prozesse zu schützen. Dazu wurde von der Hallo Welt! ein Freigabemechanismus entwickelt, der sicherstellte, dass der jeweilige Prozess vom Prozessinhaber überprüft wird.

„Es war ein Kraftakt, die Prozesse neu zu strukturieren und ins Wiki reinzustellen. Für viele Mitarbeiter, die bisher wenig im Wiki gearbeitet haben, war es nicht einfach, aber wir haben es geschafft. Der Auditor war ganz begeistert vom Wiki, und als ich gleich ein Foto von ihm machte und ihn ins Wiki reinstellte, war er hin und weg.“
(Mi-Young Miehler, Projektleiterin)

Es sei noch der Kommentar des Auditors erwähnt, der ein großes Lob aussprach, da das System nun zu einer bereichsübergreifende Kommunikationsplattform ausgebaut wurde, die weit über die Weitergabe und Dokumentation von  Prozesserfahrung hinaus geht.

Ergänzende Erfahrungen

Nachdem nun schon etwas Zeit vergangen ist, gibt es vor allem zwei Funktionen, die als Vorteile des Systems hervorstechen.

• Zum einen die Versionierung, über die nachvollziehbar wird, wer und wann welche Änderungen vorgenommen hat. Ideal für die Dokumentation.
• Zum anderen ist die sehr gute Suchfunktion, vor allem die Volltextsuche, wesentlich. Prozesse, von denen man den genauen Namen nicht mehr weiß, werden so wieder auffindbar. Zudem kann nun, wenn ein Mitarbeiter das Unternehmen verlässt, herausgefunden werden, in welchen Prozessen dieser Mitarbeiter involviert war. Die Sucheingabe des Namens im QMS Namespace liefert Ergebnisse über den Arbeitsbereich der Person, so können drohende Lücken aufgedeckt werden und schnell eine entsprechende Vertretung organisiert werden.

Herzlichen Dank an Frau Miehler für den Erfahrungsbericht

Zugegeben – so direkt vergleichen kann man die beiden eigentlich nicht: Der Microsoft SharePoint Server bietet „alles-in-einem“ für die Teamarbeit im Microsoft Office Umfeld, während MediaWiki besonders dafür gedacht ist, gemeinsam webbasierten Content zu erstellen.

Trotzdem lohnt es sich einmal über die Vor- und Nachteile beider nachzudenken. Dabei haben wir drei Punkte unter die Lupe genommen:

Benutzerfreundlichkeit

SharePoint bietet viele Möglichkeiten – keine Frage. Wie man diese voll ausschöpfen kann, steht allerdings auf einem anderen Blatt. Es dauert eine Weile, bis man  sich zurechtfindet, denn SharePoint ist trotz seiner an die Office Produkte angelehnten Benutzeroberfläche stellenweise kompliziert und unübersichtlich aufgebaut.

In einem MediaWiki geht die Einarbeitung gemäß seinem Namen (Wiki bedeutet auf Hawaiianisch „schnell“) recht zügig. Zum einen ist vielen der Grundaufbau aus der Wikipedia bekannt, zum anderen lässt es sich sehr intuitiv bedienen.

Dokumenten-Management

Das Zusammenspiel zwischen dem SharePoint Server und den verschiedenen MS Office Produkten wie Word und Excel könnte kaum besser sein. Nahtlos können diese in SharePoint integriert werden. Wird ein Dokument bearbeitet – egal ob über SharePoint oder direkt in der Datei – wird die Änderung überall sofort sichtbar.

Hier kann und will das MediaWiki nicht mithalten. Dateien können zwar ins Wiki hochgeladen werden, doch für eine Bearbeitung muss das Dokument wieder heruntergeladen und nach den Änderungen neu eingebunden werden. Werden vor allem Dokumente für die Wissens-Strukturierung genutzt, ist dieser Weg sehr umständlich. Dennoch organisiert die Wikipedia-Community ihr Bilderverzeichnis in einem zentralen Wiki, und organisieren dieses über das Kategoriensystem: Wikimedia Commons.

Knowledge-Management

Nicht alles, was an Wissen in einem Unternehmen vorhanden ist, ist in Office-Dokumenten untergebracht. SharePoint bietet für weiteren Inhalt Web 2.0-Lösungen, z.B. integrierte Wikis. Diese lassen sich jedoch eher als rudimentär einstufen. So fehlen Diskussionsseiten und auch die Versionierung ist nicht auf Anhieb zu finden.

Ganz anders ist das beim MediaWiki. Jede Artikelseite verfügt über eine eigene Diskussionsseite. Genauso findet man frühere Versionen der Seite und die Autorenliste mit einem Mausklick. Eine Wissenssammlung kann so schnell erstellt, diskutiert und verändert werden, ohne dass altes (möglicherweise in der aktuellen Version gelöschtes) Wissen verloren geht.

Qual der Wahl – die Entscheidung

Im Großen und Ganzen betrachtet eignet sich also der SharePoint Server ideal für das Dokumenten- Management, während MediaWiki als Knowledge-Management-Lösung die Nase vorne hat. Ob nun die Entscheidung auf SharePoint oder auf MediaWiki fällt, hängt folglich davon ab, ob eine Dokumentenstruktur oder das Wissen im Allgemeinen im Vordergrund steht.

Wobei … warum eine Entscheidung fällen? Warum nicht eine Brücke schlagen und die positiven Eigenschaften beider verbinden? Technisch ist die Verbindung von MediaWiki und SharePoint machbar. Die inhaltliche Kombination ist nicht zuletzt das Ergebnis einer guten Strategie für die Erneuerung des Wissens- und Dokumentenmanagements.

Siehe auch den Artikel:

Richard Heigl: Die Freiheit zu Lernen. SharePoint, Wikis, Knowledge Management. In: DOK magazin 1-09

… doch was tun, wenn man sich nicht durch eine schier unendliche Liste von Suchergebnissen durcharbeiten will? Oder wenn man noch nicht ganz genau weiß, was man sucht? – Dafür gibt es eine professionelle Lösung, die nun auch Hallo Welt! für MediaWikis anbietet: Die Facettensuche. Mit diesem Suchmechanismus engt man die Ergebnisse nach und nach ein.

Erweiterte Suche in blue note for MediaWiki. Neben den Ergebnissen der Titelsuche ist links die Facettensuche.

Facetten filtern Ergebnisse

Oft führt der Weg zur Facettensuche über die einfache bzw. die Direktsuche. Hier wird der Suchbegriff in ein Eingabefeld geschrieben. Gelangt man dann zur Facettensuche kann man das Suchergebnis eingrenzen indem man beispielsweise eine Kategorie und/oder einen Autor usw. wählt. Schon wird die Ergebnisliste kürzer und genauer. Per Klick nähert man sich also an das optimale Suchresultat an.

Interessant ist die Facettensuche sowohl für eine effektive schnelle Suche, als auch für das Bummeln durch die Resultate. Sie bringt das Suchergebnis einerseits schnell auf den Punkt, andererseits lädt sie aber auch zum stöbern ein, da sie verschiedene Kombinationen der einzelnen Facetten zulässt, die sich jederzeit verändern lassen.

Die klassische erweiterte Suche spezifiziert die Anfrage

Die Facettensuche schließt aber andere Suchtypen keineswegs aus. In manchen Fällen ist es eine erweiterte Suche die der Facettensuche vorangestellt. Die erweiterte Suche ist die klassische Form, um die Fülle von Suchergebnissen zu reduzieren. In der erweiterten Suche gibt es Eingabefelder und Drop-Down-Menüs, die die Ermittlung auf bestimmte Rubriken, Orte, Branchen, etc. beschränkt. Gerade für eine detailreiche Suche ergänzen sich diese beiden Suchvarianten optimal.

Natürlich gibt es noch weitere Suchmechanismen, die sich mehr oder weniger gut mit der Facettensuche verbinden lassen. Ein Beispiel dafür ist die Powersuche, wie sie das Netzwerk Xing anbietet. Hier ist eine Facettensuche überflüssig, weil sich die Powersuche gezielt auf ein bestimmtes, vordefiniertes Detail bezieht, welches zumeist in einem direkten Zusammenhang mit dem Benutzer steht, wie „Mitglieder, die Sie kennen könnten“.

Eine Powersuche liefert Ergebnisse für vordefinierte Anfragen. Hier das Beispiel bei Xing

Für das MediaWiki ist die Facettensuche die ideale Ergänzung. Wie im Wiki selber ist der Benutzer nun auch bei der Suche aktiv beteiligt und kann an der Anordnung der Suchergebnisse genauso einfach mitwirken wie an der Gestaltung von Artikeln.

Insgesamt kann man sagen, dass die Facettensuche ein tolles Feature ist, mit dem sich die Suchergebnisse aus den verschiedensten Blickwinkeln beleuchten lassen. Wer damit auf der Suche ist, wird gewiss fündig.

Forschung und Entwicklung. Q.: Schaeffler Gruppe

Wie machen sich Wikis in Unternehmen? Bewähren sie sich? Paul Seren, Leiter des Wissensmanagements der Schaeffler Gruppe hat schon vor Jahren ein Unternehmenswiki eingeführt. Es ist heute eines seiner Erfolgsprojekte. Hallo Welt! sprach mit ihm über seine Erfahrungen.

Herr Seren, das Unternehmenswiki von Schaeffler ist bereits seit 2007 aktiv, hat ca. 1000 angemeldete Nutzer und ca. 2000  Einträge. Sind Sie wunschlos glücklich?

Prinzipiell ja: Ein Wiki im Unternehmen scheint immer mehr dem Informationsbereitstellungsbedürfnis der Mitarbeiter zu entsprechen. Der Bekanntheitsgrad und die Akzeptanz im persönlichen Internet-Einsatz von Wikipedia, sowie die sich verändernde Kommunikation um Internet sind hierzu sicher eine riesige Hilfestellung. Dennoch treffen im Unternehmensgebrauch konventionelle Gedanken-Welten der „gesicherten Ablagen“ mit dieser gemeinsamen Aufbereitung zusammen – hier ist eine intensiver Informations-/Einweisungsbedarf zur Kultur-Anpassung notwendig.

Sie haben den Impuls für das Schaeffler Wiki gegeben. Welche Idee steckt dahinter?

Die Grundidee entstammt aus der „Dokumentation“ des Wissen von Mitarbeitern, welche das Unternehmen aufgrund der Erreichung des Rentenalters verlassen (Methode Expert Debriefing): Einerseits sind gerade langjährige Mitarbeiter sehr stark vernetzt: Die eigene Arbeit hat eine Menge an Relationen zu anderen Wissen-und Arbeitsgebieten. Hier bieten Wikis mit seiner einfachen Vernetzungsmöglichkeit (interne und externe Links, Interwikilinks, Kategorisierung) gegenüber allen anderen Dokumentationssystem wesentliche Vorteile und vielfältige Möglichkeiten.

Andererseits: Das Wissen entwickelt sich weiter, Zusammenhänge verschieben sich, auch andere Mitarbeiter wissen etwas zu dem Thema, das Wissen ist eben kein „Snapshot“. Und hier greift der Wiki-Ansatz in einem  besonderen Maße:  Die Inhalte lassen sich ständig aktualisieren und sie werden auch aktualisiert.  Der Wissensschatz eines Experten kann die Initial-Zündung sein, aber sie wird in einem Wiki niemals so verstauben wie z.B. eine eventuell mit dem gleichen Inhalt erstellte Powerpoint-Datei.

Auch Wikis altern. Wo sehen Sie die größte Herausforderung mit „reifen“ Wissensportalen?

Die Herausforderung liegt in der aktiven Mitarbeit der bei uns als „Wiki-Gärtner“ bezeichneten Wiki-Verantwortlichen aus den Fachbereichen, welche sich um die größeren Themen-Cluster kümmern. Anpassung und Flexibilität sind nötig und letzten Endes auch gemeinsame Initiativen („Aufräumaktionen“) , damit das Unkraut nicht den sinnvollen Inhaltskern überdeckt.

Mir scheint, dass bereits etablierte Wiki-Systeme irgendwann vor dem Problem stehen, dass es einen neuen Anfang geben muss, weil neue Mitarbeiter das Wiki inhaltlich anders - „für sich“ -  gestalten wollen oder weil mit der ständigen Veränderung in dynamischen Wissensgebieten der Pflegeaufwand so groß wird, dass es einfacher scheint, alles einfach neu schreiben zu dürfen. Liege ich da richtig oder tritt das Problem bei Schaeffler erst gar nicht auf?

Ich denke, wir sind noch nicht an diesen Punkt angekommen. Aber: In einem Wiki mit der Verteilung der Pflegeverantwortlichkeit auf viele Schultern ist es wesentlich einfacher, Anpassungen durchzuführen als in klassischen eher hierarchischen Ablagesystemen.  Es geht ja grundsätzlich nichts verloren, es entstehen eher neue „Blickwinkel“ auf die Wissensinhalte. Natürlich muss immer wieder bewusst gemacht  werden, dass nichts abgeschlossen ist. Je abgeschlossener ein Bereich und dann noch mit einer geringen Zahl an mitwirkenden Mitarbeitern, um so mehr wächst die Gefahr, dass unveränderbare Monolithe entstehen, welche schwerfällig für Veränderungen sind.

Dokumentieren sie eigentlich bestimmte Zwischenstände des Wikis? Oder gibt es eine Routine für die Archivierung älterer Artikel?

Nein!

Nun ist ein international aufgestelltes Unternehmen wie Schaeffler ist zwingend mehrsprachig. Wie gehen Sie mit dem Problem im Wiki um? Welchen Lösung haben Sie dafür gefunden?

Wir unterstützen das Unterrnehmens-Wiki auf Deutsch und Englisch. Sollte es zu einer deutschsprachigen Wiki-Seite eine vergleichbare Seite im englischen Wiki geben, wird mit Interwiki-Links der Querverweis mit eingebracht. Es gibt nur in den wenigsten Fällen eine 1:1 Übersetzung – welche auch dann nur für den Zeitpunkt der Erstellung so gesehen werden kann. Grundsätzlich sind es eben zwei unabhängige Seiten in zwei unterschiedlichen Wikis – damit ist unser Vorgehen mit der Internet-Wikipedia-Welt vergleichbar.

Sie arbeiten für die inhaltliche Organisation des Wikis mit sehr visuellen Hilfsmitteln wie Wissenslandkarten. Hat sich das bewährt? Brauchen wir für Enterprise 2.0-Projekte noch einen eigenen Methodenapparat oder sind aus ihrer Sicht die etablierten Methoden der Gruppenarbeit ausreichend?

Die Wissenslandkarte ist generell nur ein Gedankenmodell – diese verändert sich ständig und ist auch daher nicht eine „verbindliches“ Dokument. Die Wissenslandkarte im Moment ist daher eher nur „sichtbar“ in der Auswertung der Kategorien-Zuordnung/Hierarchisierung der Wiki-Seiten. Bewährt hat sich bisher schon der Gedankengang, dass eine Information einer Wiki-Seite nicht zwangsläufig nur in einem Teil-Ast einer Wissenslandkarte steckt, sondern durch die Kategorien mehreren „Sichten“ zugeordnet sein kann. Von daher  reichen die Methoden aus – sie finden in Wiki aber eine anfassbare Umsetzungsmöglichkeit.

Herr Seren, vielleicht noch zum Schluss, wo sehen Sie den größten Bedarf  in der Weiterentwicklung des Wissensmanagements mit Wikis?

Es ist die Organisation und die Kultur im Unternehmen, welche den Umgang mit dieser Art der gemeinsamen Erstellung  von Inhalten als „selbstverständlich“  zu akzeptieren lernen muss. Dies erfordert Umdenken und das Loslösen von gewohnten Strukturen. Aber es ist auch die große Chance für Unternehmen, welche sich einer dem Idealbild einer „lernenden Organisation“ bewusst nähern wollen!

Herr Seren, wir danken Ihnen für das Gespräch!

Das Interview führte Richard Heigl.

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.

Anders sieht es in den Unternehmen selbst aus.  So wissen wir aus Fallstudien aber auch aus eigenen Erfahrungen, dass Weblogs im Intranet eine wichtige kommunikative Funktion erfüllen. Beispielsweise werden dort Erfahrungen einzelner Unternehmenbereiche ausgetauscht.

Der Vorteil liegt auf der Hand: Wie Wikis und andere Web 2.0 Anwendungen bewegen sich Blogs an der Grenze zwischen implizitem und explizitem Wissen. Hier werden neue Ideen formuliert, Probleme besprochen und Lösungsvorschläge eingebracht.  Firmeninterne Trends werden erkennbar.Es bilden sich nicht zuletzt virtuelle Fach-Communities, die hier einen  Weg haben, Wissen erarbeiten und zielgenau verbreiten zu können. Kurz gesagt: Die Blogs in den Unternehmen finden ihre Leser und ihre Schreiber.

Dabei schreiben nicht alle und nicht auch die Intensität der Beteiligung ist unterschiedlich. Eine Fallstudie bei Siemens zeigt, dass etwa ein Drittel der Mitarbeiter, die ein persönliches Weblog angelegt haben, gar keinen Beitrag schreiben. Ein Drittel der Mitarbeiter arbeitet sehr intensiv mit dem Blog. Ein weiteres Drittel der Blogs wird als Gruppenblog mit mehreren, verteilten Autoren genutzt. Auch spannend: bei Siemens sind etwa 2/3 der Beiträge Kommentare. So findet jeder seinen Weg, das Medium zu nutzen und das ist in der Gesamtsicht auch die effizienteste Nutzung des Mediums.

Zentral bleibt hier die Freiwilligkeit. Zwar kann sich eine Arbeitsgruppe oder eine Abteilung darauf einigen, dass ein Blog als zentrales Medium genutzt wird. Denkbar sind auch Zielvereinbarungen. Starre Direktiven laufen jedoch der Grundidee des Bloggens völlig zuwider.

Im Unterschied zu Siemens verpflichtete ein anderes Unternehmen seine Mitarbeiter dazu, dass jeder Mitarbeiter einmal die Woche bloggen muss, aber nicht mehr als zehn Zeilen schreiben darf. Das Ganze begründet sich dann mit der Steigerung der Effizienz und de  Effektivität der Weblog-Kommunkation. Leider bleibt unklar, welche Gründe und welche Ziele zu diesem Zwangsblogging führen. Zwang zur Reflexion? Zwang zum Berichten? Das kann im jeweiligen Kontext sinnvoll sein. Klar ist aber auch, dass auf diese Weise auch viel überflüssige Information produziert wird. Die Überlegung, ob mir ein Thema wirklich so wichtig ist, dass ich einen Beitrag schreibe, hat auch eine sehr angenehme Filterfunktion.

Die Chance von Corporate Blogs liegt in den gewonnenen Freiräumen. Diese gilt es zu nutzen.

Lit.: Dominik Fröhlin: Corporate Blogs bei der Siemens AG, in: Koch/Richter (Hg.): Enterprise 2.0, Planung, Einführung und erfolgreicher Einsatz von Social Software in Unternehmen, 2009, 97ff.