//SEIBERT/MEDIA entwickelt interaktive Anwendungen mit dem Google Web Toolkit (GWT). Dieses Open-Source-Framework möchten wir Ihnen hier einmal näher vorstellen.

Wie der Name schon sagt, ist GWT ein Framework von Google, das sich seit 2006 in der Entwicklung befindet und aktuell in der Version 2.0.4 am Markt ist. Die Reifeprüfung in Sachen Qualität, Stabilität und Performance hat GWT längst bestanden – die eindrucksvollste Referenz nutzen Sie jeden Tag: Google.

Einsatzgebiete

GWT ist bestens für die Entwicklung Desktop-ähnlicher Internet-Anwendungen mit einem hohen Maß an Interaktivität geeignet. Eine Internet-Anwendung, die in GWT realisiert ist, läuft im Web-Browser des Nutzers und erfordert keine Installation auf dessen Rechner. Ein Aufruf der entsprechenden Internet-Seite reicht aus, um die Anwendung zu starten.

Wie gesagt sind GWT-Applikationen Desktop-ähnliche, aber keine reinen Desktop-Anwendungen: Sie benötigen zum Ausführen eine Web-Verbindung und können auf die Ressourcen des Client-Rechners nur soweit zugreifen, wie der Browser es erlaubt. Der Vorteil gegenüber einer Desktop-Anwendung besteht indes vor allem darin, dass ein zentrales Pflegen der Anwendung möglich ist, ohne dass der Betreiber sich um Updates und unterschiedliche Software-Stände auf den Client-Rechnern kümmern muss.

Entscheidungskriterien für GWT als Framework für eine Web-Anwendung sind:

• Viele vom Benutzer abzufragende Daten, möglicherweise über mehrere Seiten
• Darstellung von Listen mit Interaktionen wie Sortieren, Einblenden von Optionen usw.
• Für den Nutzer indiviualisierte Darstellung von Inhaltsbereichen
• Notwendigkeit zum Austausch vieler kleiner Daten zwischen der dargestellten Internet-Seite und der auf dem Server laufenden Anwendung (z.B. ein Chat)
• Mehrsprachigkeit
• Zusammenhänge zwischen einzelnen Elementen auf der Seite

Entscheidet man sich für GWT als Framework, hat man die technologische Basis, um eine moderne, schnelle Web-2.0-Anwendung zu erstellen. AJAX gehört dabei zum Grundkonzept und kann im Projekt schnell und effizient eingebunden werden.

Argumente für den Einsatz von GWT im Projekt

Seine Effizienz zieht GWT aus der Vielzahl vorgefertigter Widgets, die in die Anwendung integriert werden können: Der Entwickler muss nicht mehr alle Elemente und Ereignisse selbst erstellen, die im Browser dargestellt werden bzw. stattfinden – Tabellen, dynamische Funktionen, Auf- und Zuklappen, usw. usf. –, sondern kann sich unter zahlreichen vorgefertigten Elementen bedienen, was viel Projektzeit einspart.

GWT nimmt den Entwicklern auch Grundlagenarbeit ab: Insbesondere im Hinblick auf die Browser-Kompatibilität ist GWT von Haus aus sehr stark, entsprechend weniger aufwändig sind Qualitätssicherung, Debugging und Anpassung. Zudem ist Sicherheit ein wichtiges Argument: Als Standard-Framework verfügt GWT über zahlreiche integrierte Mechanismen, um häufig auftretende Sicherheitsprobleme von Web-Anwendungen von vornherein auszuschließen und Sicherheitslücken zu stopfen.

Und nicht zuletzt haben mit GWT realisierte Web-Anwendungen grundsätzlich eine gute Performance, da die Last vom Server auf die Clients verlagert wird. GWT wandelt Java im Browser automatisch in JavaScript um – die Oberfläche wird also zum Großteil im Browser generiert. Deshalb muss der Server nicht ständig fertige Seiten, sondern im Grunde nur noch die Daten liefern, und zwar in schlanken Datenformaten wie z.B. JSON. Somit sparen GWT-Anwendungen Server-Last und Bandbreite und haben deutlich bessere Antwortzeiten als vergleichbare Applikationen, die Server-seitig erzeugt werden.

Vorraussetzungen und Einarbeitung

Sicherlich ist GWT nicht „ohne“ und benötigt auf Entwicklerseite zunächst eine gewisse Einarbeitungszeit: Programmierer müssen, sofern sie zum ersten Mal mit GWT arbeiten, viele Aspekte berücksichtigen und Denkweisen erlernen, die von der klassischen Web-Programmierung abweichen. Auch die notwendigen Qualifikationen zum Erstellen einer GWT-Anwendung unterscheiden sich von denen bisheriger Web-Anwendungen. Es gibt verschiedene Möglichkeiten, das Frontend teilweise auch in HTML zu beschreiben, Java-Kenntnisse sind jedoch auch hier unverzichtbar.

Um eine gute Basis zu schaffen, ist also eine entsprechende Setup-Zeit notwendig. Vor allem muss klar sein, dass GWT kein vollständiges Framework mit Frontend und Backend ist: Es ist nur für die Benutzeroberfläche zuständig und bietet die Möglichkeit, diese komplett in Java zu schreiben. Auch der Datenaustausch mit dem Backend ist vorgesehen. Was jedoch im Backend auf dem Web-Server läuft, schreibt GWT nicht vor. (Es ist aber auf jeden Fall sinnvoll, hier ebenfalls Java zu nutzen, damit das gesamte Projekt in einer einheitlichen Entwicklungsumgebung realisiert wird.)

Grundsätzlich ist der Aufwand für eine dynamische, Desktop-ähnliche Anwendung natürlich höher als für Internet-Software, die reines HTML ausliefert. Das ist dem komplexen Aufbau geschuldet: Die Anwendung läuft eben zum Teil im Browser, zum Teil auf dem Server. Hier nimmt GWT dem Entwickler-Team jedoch viel Arbeit ab und verkürzt – im Vergleich zur Programmierung mit Ajax ohne den Einsatz von GWT – die Entwicklungszeiten signifikant.

Von entscheidender Bedeutung ist der Projektumfang: Je größer ein Projekt ist, desto lohnenswerter ist der Einsatz von GWT. Um beispielsweise ein Kontaktformular umzusetzen, ist GWT wegen des Overheads sicherlich nicht geeignet. Wenn jedoch die Grundkomponenten erst einmal erstellt sind, kann man mit GWT Fahrt aufnehmen und schnell neue Features implementieren.

Fazit

Sind die Voraussetzungen für den Einsatz von GWT gegeben, entscheidet man sich mit dem Framework für eine moderne, ökonomische Lösung. Der User erhält Oberflächen, die direkt auf seine Eingaben reagieren, ohne dass die komplette Seite neu geladen werden muss. Das ist ein entscheidender Usability-Vorteil: GWT ermöglicht hervorragende Nutzererlebnisse. Ist das Team erst einmal in die neue Technologie eingearbeitet, erweist sich das Google Web Toolkit im Projekt als sehr effizient.

Beispiele

Aktuell realisiert //SEIBERT/MEDIA zwei aufwändige Projekte mit GWT und hat hier umfassende Erfahrungen gesammelt. Anhand unseres Projekts TwentyFeet, dem Auswertungs-Tool für professionelle Social-Media-Aktivitäten, können Sie sich einen kompakten Überblick verschaffen, was mit GWT möglich ist.

Dies sind einige weitere Beispiele für GWT-Applikationen:

• sendmehome.com
• beta.contactoffice.com
• riflethru.com
• anwaltmap.de
• onlinefeedreader.org
• web.workmeter.com
• bookingpad.com
• clarityaccounting.com
• aliveawake.com

Planen Sie ein Software-Projekt? Möchten Sie Ihre bestehende Applikation mit neuen Funktionen ausstatten oder optimieren? Die Entwickler von //SEIBERT/MEDIA/TECHNOLOGIES sind Experten in der Anwendungsentwicklung mit Java, GWT, Groovy & Grails und Perl und helfen Ihnen gerne weiter. Bitte sprechen Sie uns unverbindlich an!

Weiterführende Informationen

Der quelloffene GWT-Code
Beispiele für GWT-Projekte
Grails: Kurze Entwicklungszeiten und nahtlose Java-Integration (Vodcast)
Plattform zum sicheren Datenaustausch für BodeHewitt entwickelt
Das Google Web Toolkit

Beim Live-Schalten einer Website ist die Informationsarchitektur voll entwickelt, sämtliche Seiten sind vorbereitet und mit Content gefüllt. Ein Wiki dagegen hat zu Beginn in aller Regel nur wenige Seiten, dafür wächst es kontinuierlich. Sicherlich verändern sich auch Websites, beispielsweise werden Unterseiten zusammengelegt oder es kommen neue hinzu, vielleicht entsteht mit einer Sortimentserweiterung ein neuer Hauptmenüpunkt, etc. Diese Veränderungen sind aber nicht strukturell signifikant.

Bei einem Wiki ist es anders: Hier entwickelt sich ganz schnell und relativ unsystematisch viel Inhalt. Das ist in einem Firmenwiki auch völlig normal und erwünscht: Es ist ja gerade nicht das Ziel, Mitarbeitern vorzuschreiben, wann und welche Inhalte sie in welchem Kontext im Wiki ablegen.

Die Struktur eines Wikis ist somit innerhalb kurzer Zeit eine ganz andere und ihre Entwicklung lässt sich en detail nicht im Voraus planen. Es entstehen neue Portalseiten mit zahlreichen Unterseiten, neue Projekte erfordern häufig das Anlegen neuer, separater Wiki-Bereiche, es werden viele verschachtelte Strukturen entwickelt, die im Gegensatz zu einer Website keinen systematischen Strukturen folgen.

Wenn man ein Wiki-Projekt plant, muss also ein Verständnis dafür vorhanden sein, dass die Informationsarchitektur eines Wikis eben nicht der einer Website entspricht (und entsprechen soll) und dass auch die Entwicklung und Planung von Navigationselementen, der Suche oder der letzten Änderungen bei einem Wiki anderen Regeln folgt.

In diesem kompakten Video erläutern wir die Unterschiede zwischen einer Website- und einer Wiki-Struktur anschaulich:

Fazit: Sicherlich können und sollten Sie ein Wiki inhaltlich planen und vorbereiten (z. B. in Form eines Scheunenbau-Workshops) und Bereiche, Portalseiten etc. in eine Informationsarchitektur integrieren. Eine solche, vergleichsweise grobe Strukturierung reicht unserer Erfahrung nach aber vollkommen aus, denn die Tiefenstruktur entwickelt sich organisch und sicherlich nicht so, wie Sie es detailliert geplant haben. Und das ist auch gut so.

Planen Sie eine Wiki-Einführung? Benötigen Sie Unterstützung bei einem laufenden Wiki-Projekt? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne, bitte sprechen Sie uns an. Weitere ausführliche Informationen inkl. zahlreicher Videos zum Thema finden Sie auch auf unserer speziellen Seite über Firmenwikis.

Weiterführende Informationen:
Unsere spezielle Seite zum Thema Firmenwikis
Welche Informationen gehören ins Firmenwiki? Beispiele aus der Praxis
Firmenwikis: Im Wiki zählt Qualität vor Quantität – oder doch nicht?
Neue Wiki-Dokumente richtig anlegen: Wo und wie einsortieren?

Warum haben Mitarbeiter Bedenken, ihr Wissen zu teilen?

Grundsätzlich ist das Wissen eines Mitarbeiters sein wertvollstes Gut: Wegen seines Wissens hat das Unternehmen ihn eingestellt, das eigene Know-how bildet seine Daseinsberechtigung im Unternehmen. Nun wünscht der Arbeitgeber also, dass der Mitarbeiter sein Wissen allen zentral zur Verfügung stellt.

Die Projekterfahrung zeigt, dass viele Mitarbeiter hierdurch einen Machtverlust und einen Verlust an Wert für das Unternehmen befürchten. Ein Gedankengang wie der folgende wird im Zuge der Wiki-Einführung etlichen Mitarbeitern durch den Kopf gehen:

Warum soll ich mein Wissen allen zur Verfügung stellen? Ich werde dadurch ja weniger wichtig im Unternehmen, verbaue mir gegebenenfalls Aufstiegschancen und mache mich entbehrlich. Ich würde doch selbst daran mitwirken, meinen „Marktwert“ zu senken!

In dieser emotionalen Konstellation dürfte sich nahezu jeder Mitarbeiter befinden, wenn sein Arbeitgeber ihn auffordert, sein Wissen im Firmenwiki abzubilden. Hierin liegt eine Herausforderung, die auf dem Weg zu einem erfolgreichen, produktiv nutzbaren Firmenwiki gemeistert werden muss.

Missverständnis: Informationen vs. Wissensanwendung

Das grundsätzliche Missverständnis besteht darin, was die Mitarbeiter konkret eigentlich im Wiki teilen sollen. Stark vereinfacht müssen wir „Wissen“ nämlich in Daten, Informationen und Wissensanwendung unterteilen, also 1) pure Daten, Zahlen und Fakten, 2) die Daten in einem bestimmten Kontext (Informationen) und 3) die Anwendung von Informationen in einer bestimmten Situation.

Diese Fähigkeit, Wissen im Kontext richtig anzuwenden, ist der Grund, warum das Unternehmen einen Mitarbeiter eingestellt hat und beschäftigt, hierin besteht sein Wert für das Unternehmen. Und das kann man nicht in einem Wiki-Dokument festhalten. Mitarbeiter sollen also gar kein Wissen, sondern vielmehr Daten und Informationen im Wiki teilen.

Ein Beispiel: Ich kann die Daten einer Studie zum Thema Firmenwikis in einem Wiki-Dokument zusammenfassen. Ich kann diese Daten im Wiki auch interpretieren und in einen Zusammenhang mit der Herausforderung der Mitarbeiteraktivierung stellen. Ich kann allerdings nicht im Wiki abbilden, wie ich diese Daten und Informationen in einer bestimmten Projektsituation anwende, beispielsweise bei einer Frage in einem Wiki-Workshop. Ich kann auch nicht darstellen, wie ich mithilfe der verfügbaren Informationen eine individuelle Aktivierungsstrategie entwickle, die die spezifischen Anforderungen eines Kunden berücksichtigt. Und ich kann im Wiki auch nicht darlegen, wie ich einen runden, verständlichen Blog-Artikel über die Angst, Wissen zu teilen, erstelle. Das, was den „Marktwert“ eines Mitarbeiters im Unternehmen definiert, kann im Wiki gar nicht abgebildet werden.

Das Wiki-Dashboard gibt Mitarbeitern etwas zurück

Dennoch, so könnte ein Einwand lauten, würden Mitarbeiter ja die Exklusivität an bestimmten Informationen verlieren. Das ist zweifellos richtig. Doch ein Experte, der im Unternehmen nicht als solcher wahrgenommen wird, ist letztlich eher angreifbar als ein Kollege, der Informationen ins Wiki stellt und dessen Expertise im ganzen Unternehmen bekannt ist.

Hier spielen Dashboards eine wichtige Rolle, über die jedes professionelle Wiki-System verfügt: Wenn ein Mitarbeiter beispielsweise die Startseite des Confluence-Wikis aufruft, sieht er sofort, wer wann in welchen Dokumenten Änderungen vorgenommen hat:

Abb.: Das Dashboard unseres öffentlichen Wikis auf Basis von Confluence

Alle Mitarbeiter sehen: Dieser Kollege verfügt offensichtlich über Know-how, er kann zum Wiki etwas beitragen, er ist Wissensträger in einem bestimmten Bereich, auf diesen Kollegen kann man bei diesbezüglichen Problemen zugehen. Die Folge ist eine breite und wachsende Wertschätzung des Expertenwissens quer durch das Unternehmen. Tatsächlich steigen also die Reputation und die Attraktivität des Mitarbeiters für das Unternehmen.

Weniger interne Fachfragen führen zu mehr Produktivität

Damit nicht genug: Legt ein Mitarbeiter Exklusiv-Informationen im Wiki zentral ab, sinkt zwangsläufig das Aufkommen an Fachfragen per E-Mail oder gar per Besuch im Büro und somit auch der Zeitaufwand für die aufwändige Bearbeitung von fachlichen Problemen per E-Mail. Der Effekt ist klar: Der Mitarbeiter hat mehr Zeit für die produktive Arbeit und sein Engagement in Projekten. Aufgrund seiner Aktivitäten im Firmenwiki wird er produktiver und letztlich wertvoller als vorher.

Es tritt also genau das Gegenteil von dem ein, was viele Mitarbeiter zunächst befürchten: Durch die zentrale Abbildung von Teilen ihrer Expertise werden viele Nutzer nämlich noch wichtiger und können sich noch deutlicher als Fachleute profilieren. Die Angst, Wissen zu teilen, beruht auf einem Missverständnis: Sie ist unbegründet, weil der Gewinn an Reputation und Zeit für produktive Aufgaben deutlich höher einzuschätzen ist als der Verlust von Know-how-Exklusivität.

Diese Argumentation sollte Bestandteil jeder Einführungsstrategie sein. Bei der Entwicklung einer solchen Strategie unterstützt //SEIBERT/MEDIA Sie natürlich gerne: Bitte sprechen Sie uns an oder besuchen Sie unsere spezielle Seite zu den Themen Firmenwikis und Wiki-Einführung mit vielen weiterführenden Informationen und Videos .

Haben Sie die Live-Video-Session zu diesem Thema und weiteren interessanten Aspekten rund um die Einführung eines Enterprise Wikis verpasst? In unserem öffentlichen Wiki können Sie die ausführliche Agenda zur Sendung nachlesen oder sich gleich hier die komplette Aufzeichnung der ca. 45-minütigen Diskussion ansehen:

Weiterführende Informationen

Live-Video-Sessions von //SEIBERT/MEDIA jetzt regelmäßig
Erfolgsfaktoren für Wikis: Organisation ist der Schlüssel
Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?
Welche Informationen gehören ins Firmenwiki? Beispiele aus der Praxis
Wiki-Zusatzleistungen von //SEIBERT/MEDIA

So ist das auch bei einem Wiki und deshalb empfehlen wir, die Mitarbeiter „abzuholen“ und ihnen ein solides inhaltliches Grundgerüst zur Verfügung zu stellen. Um ein solches Gerüst effizient und systematisch zu errichten, bietet //SEIBERT/MEDIA Scheunenbau-Workshops an – und damit einen guten Start für die inhaltliche Befüllung Ihres Firmenwikis.

Umzusetzende Inhalte priorisieren

Für den Einstieg haben unsere Wiki-Experten sogenannte Themenkarten erarbeitet, die wir gemeinsam mit dem Kunden durchgehen. Auf diesen Karten sind verschiedene Inhalte beschrieben, die eigentlich in allen Firmenwikis Relevanz besitzen. Am Anfang des Workshops stellen wir diese etwa 30 Karten vor und priorisieren sie mithilfe eines sogenannten „Business Value Pokers“.

Viele Dokumente mithilfe von Vorlagen erstellen

Der eigentliche Scheunenbau beginnt dann mit dem Anlegen vieler leerer Seiten, die zunächst nur Seitentitel enthalten. Anschließend werden diese Dokumente hierarchisch sortiert und mit ersten Notizen befüllt. Hierfür bringt //SEIBERT/MEDIA zahlreiche nützliche Vorlagendokumente für fast alle erdenklichen Anwendungsfälle in den Workshop ein, die wir natürlich an spezifische Unternehmensbedürfnisse anpassen:

• Dokumente für das Projektmanagement wie Projektchecklisten, die Meeting-Vorbereitung, Projektauswertungen, PM-Handbücher, etc.
• Vorlagen für das Personalwesen wie Erste-Schritte-Dokumente, das Unternehmen von A bis Z, Event-Organisation, Teilnehmerlisten, Vorlagen für Zielvereinbarungen, Schwarzes Brett, Bücherbestellliste u.v.m.
• Dokumentenvorlagen für die IT-Abteilung, den Betriebsrat, das Qualitätsmanagement, usw. usf.

Nächste Schritte definieren

Den zunächst letzten Schritt im Workshop bildet die gemeinsame Definition der nächsten Aufgaben. Mit der Abarbeitung dieser (vor allem redaktionellen) Tasks entsteht der eigentliche Content für den Wiki-Piloten und den Roll-out an die Mitarbeiter.

Je mehr angefangene Seiten, desto besser!

Dieser Workshop ist genau dann erfolgreich, wenn das Maximum an neuen Inhalten eingebracht ist. Dabei kommt es nicht auf die Anzahl der hochgeladenen Dateien, komplette Dokumente und durchweg operationalisierte Inhalte an, sondern auf unstrukturierte und gerne auch unfertige Wiki-Seiten. Je mehr es davon gibt, desto besser. Es wird die Aufgabe aller Mitarbeiter im Tagesgeschäft sein, die im Rahmen des Workshops erstellten Rahmengerüste mit Inhalten zu füllen und regelmäßig zu aktualisieren.

Warum eigentlich Scheunenbau?

Ganz einfach: In diesem Workshop soll etwas Praktisches und Nützliches schnell aufgebaut werden, kein gemütliches Wohnhaus und schon gar keine Kathedrale, sondern eben eine Scheune, denn es geht hier um Funktionalität und auch um Kosteneffizienz, nicht jedoch um Schönheitspreise für durchgehend optimal und einheitlich formatierte Seiten bzw. um Idealvorstellungen von einem organisch gewachsenen Wiki.

Mit einem Scheunenbau-Workshop von //SEIBERT/MEDIA entsteht schnell ein stabiles inhaltliches Gerüst, mit dem die Mitarbeiter sofort weiterarbeiten können und das für viele unterschiedliche Informationsbedürfnisse bereits Antworten parat hat – ein guter Start, um Ihr Wiki zu einem „Inhaltsmagneten“ zu machen und das negative Muster des leeren Wikis zu vermeiden.

Interessieren Sie sich für individuelle Wiki-Schulungsleistungen? Wir stehen Ihnen gerne zur Verfügung, bitte sprechen Sie uns unverbindlich an. Einen Überblick über alle von //SEIBERT/MEDIA angebotenen Wiki-Schulungen, -Workshops und -Vorträge finden Sie auf einer umfangreichen Portalseite in unserem öffentlichen Wiki.

Weiterführende Informationen

Unsere spezielle Seite zum Thema Firmenwikis mit ausführlichen Infos und Videos
Wiki-Admin-Workshops: Was sie beinhalten und für wen sie sich lohnen
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Erfolgsfaktoren für Wikis: Organisation ist der Schlüssel

Eine Lösung: Mailchimp und der AutoResponder

Mailchimp ist eine Newsletter-Applikation, die mit ihrer AutoResponder-Funktion ein solches E-Mail-Marketing hervorragend unterstützt, ohne manuell E-Mails anlegen und verschicken zu müssen: Folgeinformationen nach Kundenkontakten lassen sich zeitgesteuert versenden. So können sich Unternehmen automatisierte E-Mail-Ketten (wohlgemerkt: nicht Ketten-E-Mails ) zunutze machen. Einige wichtige Eigenschaften des Tools:

• Zeitsteuerung: E-Mails werden einmalig angelegt und dann nach einem vordefinierten Versandrhythmus immer wieder an verschiedene Empfänger verschickt.
• Vollständige Personalisierung: Die E-Mails sind personalisierbar und kommen z.B. ohne unpersönliche Begrüßungsfloskeln aus.
• Integration in das Corporate Design: Die E-Mail-Templates sind vollständig anpassbar.
• Sehr gute Usability: Mailchimp ist einfach und schnell zu bedienen und kann – im Gegensatz zum deutlich komplexeren OpenEMM – auch von Kunden ohne großes Technik-Know-how selbst gehandhabt werden.
• Kein Versand vom eigenen Server: E-Mails werden nicht von einem eigenen Server verschickt.  Es besteht somit keine Gefahr, dass die eigenen E-Mail-Server auf Spam-Listen landen. Allerdings werden die Daten extern gespeichert.
• Hervorragende Auswertungsmöglichkeit mit Statistiken: Sie sehen, welcher Empfänger die E-Mail geöffnet hat, welche Links angeklickt wurden, etc.
• Weitere wichtige Features: Google-Analytics-Integration, Benchmarking innerhalb einer Branche, A/B-Testing, RSS to E-Mail, Inbox-Inspector, Twitter-Tracking, …
• Kostenlose Nutzung: Bis zu einem Kreis von 500 Empfängern und bis zu einem Aufkommen bis zu 3.000 E-Mails pro Monat ist Mailchimp kostenlos. Für viele kleinere und mittlere Unternehmen reicht das vollkommen aus.

Abb.: Das namensgebende Mailchimp-Maskottchen

//SEIBERT/MEDIA setzt Mailchimp seit einigen Monaten ein und wir sind überzeugt: Das Werkzeug macht einen runden, ausgereiften, professionellen Eindruck und kann bedenkenlos im Unternehmensumfeld eingesetzt werden.

Anwendungsfälle

Wie kann man sich eine solche E-Mail-Kette eigentlich vorstellen? Stellen wir das Potenzial dieses Kommunikationskanals anhand einiger Beispiele kurz dar:

Anwendungsfall 1: Interessenten zu Kunden machen
Sie betreiben eine Website und generieren täglich neue Anfragen. Diese Interessenten sollen von Ihrem Vertrieb zu Neukunden gemacht werden. Bei diesem Prozess unterstützen Sie Ihre Vertriebsmitarbeiter künftig, indem Sie nach einem Tag, drei Tagen, einer Woche und zwei Wochen jeweils eine E-Mail mit interessanten Hintergrundinformationen an Ihren Interessenten verschicken.

Anwendungsfall 2: Cross-Selling im Online-Shop
Jeder Kunde, der etwas kauft, erhält in unregelmäßigen Abständen nach seinem Kauf ein interessantes Angebot per E-Mail. Auf diese Weise betreiben Sie automatisiert ein Cross- und Up-Selling.

Anwendungsfall 3: Vorfreude steigern bei der Reise-Vorbereitung
Ihr Kunde hat ein Event oder eine Reise gebucht. Im Vorfeld und mit dem näherrückenden Termin erhöhen Sie die Vorfreude Ihres Kunden, indem Sie ihm hilfreiche Informationen und nützliche Tipps rund um seine Veranstaltung oder Reise zukommen lassen.

Die Vorteile

E-Mail-Kampagnen wie die eben beschriebenen sind exemplarisch und es ist eine Vielzahl von Anwendungsfällen denkbar. Fassen wir zusammen, was diese Kommunikationsketten unserer Erfahrung nach gemeinsam haben:

• Durch die vollständige Automatisierung ist der Betrieb kostengünstig.
• Mailchimp erlaubt sehr individuelle und hochwertige Kontakte, die auf die Situation des Kunden zugeschnitten sind.
• Durch die persönliche Ansprache funktionieren viele dieser E-Mails so gut wie individuell verschickte Nachrichten.
• Sehr hohe Öffnungsraten und Antwortquoten sind die Regel.
• Die Umsetzung ist schnell möglich.

Kommunikationsketten mit Mailchimp waren kürzlich auch Thema einer Live-Video-Session von //SEIBERT/MEDIA, die Sie sich hier als Aufzeichnung ansehen können. In dieser Sendung stellen Ihnen Gastgeber Martin Seibert und Sebastian Preuss die Software und ihre Potenziale vor, zeigen Ihnen Mailchimp von innen und erklären Ihnen, was //SEIBERT/MEDIA ggf. konkret für Sie tun kann:

Unser Leistungsangebot

//SEIBERT/MEDIA hilft Ihnen bei der Konzeption, der Umsetzung und dem Betrieb Ihrer E-Mail-Automation auf Basis von Mailchimp, und gerne zeigen wir Ihnen die Möglichkeiten und Vorteile eines automatisierten E-Mail-Marketings mithilfe von E-Mail-Ketten zunächst im Rahmen eines persönlichen Vor-Ort-Workshops oder einer Remote-Präsentation, denn: Die Umsetzung der E-Mail-Automation ist ein sehr individuelles Vorhaben, das unbedingt auf Ihre Bedürfnisse zugeschnitten sein sollte.

In unserem öffentlichen Wiki haben wir unsere Leistungen beschrieben und realistische Empfehlungen mit konkreten Preisangaben ausführlich für Sie aufbereitet.

Weiterführende Informationen

Bestätigungs-E-Mails: Potenziale und Realität, Versandzeitpunkt und Häufigkeit
E-Mail-Werbung: Missverständnisse und Fallstricke
Lohnen sich Spam-Filter in Unternehmen?
“viele gruesse aus der soehnleinstrasse” – Nachlässige E-Mail-Kommunikation ist unprofessionell

Dieser Artikel ist auch als englischsprachiger Gastbeitrag im Confluence-Blog von Atlassian erschienen.

111 Gründe für ein Firmenwiki

1. Ein Firmenwiki schafft mehr Transparenz über alle Abläufe im Unternehmen.
2. Ein Wiki ermöglicht es, das komplette Unternehmens-Know-how zentral abzubilden.
3. Firmenwikis gibt es seit 1998. Viele Lösungen am Markt sind anerkannt, sehr ausgereift und etabliert.
4. Wikis helfen Unternehmen, verstreute Informationen zu zentralisieren und zu systematisieren.
5. Das Wissen jedes einzelnen Mitarbeiters ist wertvoll. Ein Wiki hilft, dass alle davon profitieren.
6. Ein Wiki ermöglicht die Mitwirkung an der Firmenkommunikation und -information.
7. Ein Firmenwiki entlastet Mitarbeiter und führt zu mehr Produktivität im Unternehmen.
8. Durch mehr Effizienz und Produktivität haben Wikis einen hohen ROI.
9. Im Firmenwiki kann man eigene Ideen aktiv in das Unternehmen einbringen.
10. Ein Firmenwiki bietet ein vollständig personalisiertes Nutzungserlebnis.
11. Ein Firmenwiki eröffnet neue und effizientere Wege der Zusammenarbeit.
12. Mit der Wiki-Einführung sendet das Management das wichtige Signal, dass es Mitarbeitern vertraut.
13. Durch ein Wiki kann das E-Mail-Aufkommen im Unternehmen deutlich reduziert werden.
14. Durch die Zusammenarbeit im Firmenwiki wird der Teamgeist gestärkt.
15. Jeder macht Fehler. Im Wiki können Mitarbeiter fehlerhafte Inhalte anderer proaktiv selbst verbessern.
16. Jede Info, die man im Wiki findet, ohne einen Kollegen fragen zu müssen, führt zu mehr Produktivität.
17. Mit Beiträgen im Wiki erlangen Mitarbeiter eine Reputation als Wissensträger.
18. Ein Wiki bringt eine Kultur der Offenheit ins Unternehmen, die Mitarbeiter motiviert.
19. Ein Wiki steht für „Kommunikation auf Augenhöhe“. Ein wichtiger, identitätsstiftender Soft Fact.
20. Ein Firmenwiki ermöglicht die Vernetzung der Mitarbeiter des Unternehmens.
21. Ein Firmenwiki ermöglicht mehr eigene, proaktive Teilnahme am Unternehmensgeschehen.
22. Oft stößt ein Wiki in eine Lücke und kann sich ohne Überschneidungen als Referenzwerk etablieren.
23. Firmenwikis unterstützen Mitarbeiter erwiesenermaßen, sich selbst besser zu artikulieren.
24. Firmenwikis machen die Informationen im Unternehmen erwiesenermaßen glaubwürdiger.
25. Viele Iterationen führen zu hochwertigen Inhalten. Wiki-Dokumente durchlaufen sehr viele Iterationen.
26. Firmenwikis sind im Breitenmarkt angekommen. Wer kein Wiki einführt, hat einen Wettbewerbsnachteil.
27. Wiki-Nutzer sagen, dass sie durch das Teilen von Wissen mehr Respekt im Unternehmen erworben haben.
28. Wikis haben sich durchgesetzt und sind laut Gartner Hype Cycle auf der „Ebene der produktiven Nutzung“.
29. Ein Wiki ist das dynamische Gegenstück zum statischen Intranet mit dem One Administrator’s Syndrome.
30. Im Wiki wächst Unternehmenswissen organisch und rasch, da der Umweg über Administratoren entfällt.
31. Ausgereifte Wikis sind zukunftssicher, sie werden rasant mit hoher Update-Frequenz weiterentwickelt.
32. Im Wiki bleibt das wertvolle Wissen von Mitarbeitern erhalten, die das Unternehmen verlassen.
33. Im Wiki können Dokumente und ganze Bereiche für ständige Updates abonniert werden.
34. Mit einem Firmenwiki sind deutlich bessere Urlaubsvorbereitungen möglich.
35. Wiederholte Nachfragen werden durch Dokumentation des eigenen Wissens im Wiki vermieden.
36. Die Notwendigkeit, anderen eigenes Wissen beibringen zu müssen, wird durch ein Wiki stark reduziert.
37. Statt alleine kann man im Firmenwiki gemeinsam mit anderen zusammenarbeiten.
38. Zu eigenen Ideen und Konzepten kann man sich im Wiki schnellen Input der Kollegen holen.
39. Ein geschützter Bereich ermöglicht das Hinterlegen und Auffinden eigener Daten im Firmenwiki.
40. Theoretisch können in einem geschützten Bereich im Firmenwiki auch private Daten hinterlegt werden.
41. Der Nutzer entscheidet selbst darüber, wer seine Beiträge im Firmenwiki sehen und editieren darf.
42. Mit dem Wiki können Wissensträger des eigenen Fachbereichs schnell identifiziert werden.
43. Im Firmenwiki findet man Mitarbeiter, die eigene Wissensgebiete ergänzen können.
44. Im Wiki können Daten aus anderen Systemen automatisiert gesammelt und zentral ausgewertet werden.
45. Ein Wiki ermöglicht eine professionelle, zentrale Kapazitätsplanung ohne großes E-Mail-Aufkommen.
46. Mit dem Wiki können anschauliche Charts erstellt werden, es wird zur zentralen Auswertungsplattform.
47. Firmenwikis bieten Office-Export und -Import. Integration und Migration von Content sind einfach.
48. Neue Mitarbeiter können schneller produktiv sein, wenn sie alle Infos für den Einstieg im Wiki finden.
49. Tutorials und Anleitungen im Wiki verringern den Schulungs- und Supportaufwand im Unternehmen.
50. Ist ein Mitarbeiter krank, kann seine Vertretung sofort am aktuellen Stand weiterarbeiten.
51. Durch die Wiki-Dokumentation laufen Projektübergaben und Vertretungen reibungsärmer ab.
52. Stellenbeschreibungen, die im Wiki aktuell gehalten werden, sparen Zeit und Kosten beim Recruitment.
53. Wikis sind von jedem Internet-Rechner aus erreichbar. Das erleichtert die Arbeit in virtuellen Teams.
54. Im Wiki lassen sich Fachbibliothek, geliehene Arbeitsmittel usw. ohne Drittsystem effektiv verwalten.
55. Formulare für Urlaubsantrag, Dienstreise usw. im Wiki hinterlegt verringern den administrativen Aufwand.
56. Ein Wiki eignet sich bestens für interne Blogs, Newsletter etc., ohne Drittsysteme nutzen zu müssen.
57. Wiki-Formulare ermöglichen webbasierte Lösungen wie sonst mit MS Access oder Datenbanken umgesetzt.
58. Im Wiki können Wochenspeiseplan, Fußball-Tippgemeinschaft, Wäscheservice und andere sozialen Aktivitäten effizient organisiert werden.
59. Firmenwikis ermöglichen die zentrale Steuerung und Auswertung der Außenkommunikation.
60. Ein Wiki gibt auch dem Betriebsrat die Möglichkeit, eigene Infos zentral und aktuell zu kommunizieren.
61. Wikis sind betriebssystemunabhängig. Es genügen ein Browser und ein Web-Zugang.
62. Wikis sind sicher. Zugriffsrechte sind fein justierbar und bis auf Seitenebene spezifisch einstellbar.
63. Die Nutzung des Wikis ist ohne Installation zusätzlicher Software möglich.
64. Ein Wiki hat eine ausgereifte API und lässt sich perfekt an bestehende Systeme wie MS SharePoint anbinden.
65. Ein Wiki kann an das Corporate Design angepasst werden und wirkt nicht wie ein Fremdkörper.
66. Wikis lassen sich per LDAP und Single-Sign-on in die IT-Infrastruktur integrieren.
67. Wikis sind sehr skalierbar. Sie eignen sich für einzelne Projektteams ebenso wie für Tausende Nutzer.
68. Der Code ist bei vielen Wikis quelloffen und eigenständig an individuelle Bedürfnisse anpassbar.
69. Wiki-Templates können an alle Anforderungen angepasst werden, im Gegensatz zu vielen anderen Systemen.
70. Ausgereifte Firmenwikis sind stabil und auch bei sehr großen Datenmengen sehr performant.
71. Wikis lassen alle Optionen offen. Daten können später ggf. leicht in andere Systeme migriert werden.
72. Dank mächtiger Berechtigungskonzepte erfüllen Wikis die Einhaltung auch strenger Datenschutzauflagen.
73. Im Wiki können Beteiligte auf alle Projektinfos zugreifen und haben den Status sofort im Blick.
74. Dokumentieren Mitarbeiter Arbeitsschritte im Wiki, sind die Beteiligten stets auf dem aktuellen Stand.
75. Im Firmenwiki können Unterlagen und Projekte anderer Bereiche eingesehen werden.
76. Von Projektauswertungen bis dokumentierten „Lessons learned“ im Wiki profitieren künftige Projekte.
77. Kontaktdaten aller Beteiligten und Ansprechpartner im Wiki verbessern die Projektkommunikation.
78. Systematische Projekt-Checklisten im Wiki erleichtern das Projektmanagement signifikant.
79. Wikis bieten E-Mail-Import an: Der Mail-Austausch im Projekt wird zentral dokumentiert.
80. Ein Wiki kann als sicheres Extranet genutzt werden, das die Kundenbindung stärkt.
81. Ein Wiki als Extranet erlaubt die Kundenintegration und sorgt für effiziente Kommunikation im Projekt.
82. Pflichtenhefte im Extranet-Wiki schaffen Sicherheit und helfen, Missverständnisse schnell auszuräumen.
83. Ein Wiki zeichnet sich durch eine einfache und intuitive Bedienung aus.
84. Wikis funktionieren wie Word: Open, edit, save. Unterschied: Das Wiki-Dokument ist zentral verfügbar.
85. Wikis haben eine sehr gute Usability. Deshalb ist die Arbeit im Wiki effektiv und effizient.
86. Die gute Wiki-Usability führt zu kurzen Einarbeitungszeiten im Vergleich zu klassischen Intranets.
87. Im Firmenwiki muss man nicht wie bei Wikipedia im Wiki-Code arbeiten: Es gibt Rich-Text-Editoren.
88. Die gute Usability von Wikis erhöht die Nutzungsfreude. Mitarbeiter nutzen das Wiki gerne und oft.
89. Im Wiki ist jede Änderung nachvollziehbar. Mehr Transparenz bei der Zusammenarbeit geht nicht.
90. Im Firmenwiki kann man per RSS-Abo auf dem Laufenden bleiben, ohne ein Dokument aufzurufen.
91. An Wiki-Dokumente können Dateien angehängt werden, die dann zentral und aktuell verfügbar sind.
92. Per WebDAV lassen sich Office-Dokumente direkt aus dem Wiki heraus bearbeiten und sind stets aktuell.
93. Events lassen sich mit dem Wiki effizient planen, ohne mehr als eine einzige E-Mail zu versenden.
94. E-Mail-Vorlagen im Wiki helfen, die E-Mail-Kommunikation zu automatisieren und effizienter zu machen.
95. E-Mail-Anhänge liegen in verschiedenen Iterationsstufen in Postfächern. Wiki-Dokumente sind aktuell.
96. E-Mail-Anhänge lagern dezentral in Postfächern. Wiki-Inhalte sind zentral abrufbar.
97. Gemeinsam im Wiki erstellte Berichte sind hochwertig, aktuell und schneller entwickelt als per E-Mail.
98. Fehler in einem verschickten E-Mail-Anhang bleiben bestehen. Im Wiki sind Fehler per Klick behoben.
99. Zwei von drei E-Mails an Mitarbeiter haben interne Absender. Ein Wiki hilft, dieses Aufkommen zu reduzieren.
100. 46% der Mails via Verteiler und @all sind für den Empfänger belanglos. Wikis reduzieren interne E-Mails.
101. Mit einem Wiki müssen Service-Mitarbeiter immer gleiche Fragen nicht jedes Mal per E-Mail beantworten.
102. Im Wiki entwickelte Meeting-Agendas sind aktuell und allen zugänglich, ohne E-Mails auszutauschen.
103. Werden sie gemeinsam im Wiki vorbereitet, sind Meetings zielführend und aufs Wesentliche konzentriert.
104. Die Meeting-Vorbereitung im Wiki erspart frustrierende Themen- und Grundsatzdiskussionen im Meeting.
105. Wer ein Meeting verpasst, kann Input immer noch im Wiki als Notiz, als Frage, als Kommentar geben.
106. Wiki-Plugins wie TaskDock für Confluence ermöglichen ein dynamisches Task-Management ohne Drittsystem.
107. Mit Wiki-Plugins sind kleine BI-Lösungen möglich, die Ansprüche von Teams oder KMU oft schon erfüllen.
108. Mit Plugins wie dem Gliffy-Plugin für Confluence sind tolle Visio-Anwendungen im Wiki möglich.
109. Mit Wiki-Plugins können Datenbankinhalte ins Wiki integriert werden, inkl. dynamischer Aktualisierung.
110. Wissenschaftliche Studien haben den Nutzen von Firmenwikis längst nachgewiesen.
111. Ein Firmenwiki ist keine eierlegende Wollmilchsau. Aber ganz nah dran.

An diesem Punkt haben wir mit unserer Sammlung von Gründen, die wir natürlich gemeinsam im Wiki zusammengetragen haben, aufgehört: Die Argumente sind nicht nur qualitativ, sondern auch quantitativ überwältigend. Deutlich soll werden, dass Unternehmen, die auf ein Wiki verzichten, sich ungeahnter Möglichkeiten berauben und sich selbst limitieren. Bei diesen ist es wirklich an der Zeit, gründlich über eine Wiki-Einführung nachzudenken. Dabei unterstützt //SEIBERT/MEDIA Sie natürlich gerne: Fragen Sie die Experten für Unternehmenskommunikation. Zahlreiche Informationen haben wir auch auf unserer speziellen Seite zum Thema Firmenwikis zusammengestellt.

Und falls Sie in Ihrem Unternehmen bereits ein Wiki einsetzen sind wir gespannt, welche Erfahrungen Sie gemacht haben und welche Anwendungsfälle für Sie besonders überzeugend sind. Würden Sie weitere Gründe anführen? Wir freuen uns auf Ihre Meinungen und Kommentare.

Weiterführende Informationen

Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?
Erfolgsfaktoren für Wikis 1: Technologie ist wichtig, wird aber überschätzt
Erfolgsfaktoren für Wikis 2: Organisation ist der Schlüssel
Hofläden, Supermärkte und Firmenwikis: Bitte klingeln und Herzlich willkommen
Strategische Wikis und Wikis im Tagesgeschäft: Eine wichtige Unterscheidung
Architektur eines Wiki-Projekts: Elemente, Vorgehen, Ablauf, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA

Ansatz: Es gibt eine Herausforderung? Es gibt auch eine Wiki-Lösung!

Im //SEIBERT/MEDIA-Use-Case-Workshop erarbeiten wir gemeinsam mit Ihnen Lösungsmöglichkeiten für konkrete Anwendungsfälle und Herausforderungen: Sie haben ein Problem und wir finden gemeinsam eine Lösung.

Dabei sind ganz unkomplizierte, schnelle Lösungen ebenso denkbar wie komplexe Ergebnisse wie vollautomatisierte Plugins mit Schnittstellen. Ein professionelles, ausgereiftes Wiki lässt da alle Wege offen. Dabei gehen wir in der Regel so vor:

• In einem gemeinsamen Gespräch erfassen wir den Status Quo und die Problemstellung.
• Wir entwickeln eine User-Story, die dem Idealzustand entspricht.
• Ein erstes Lösungsszenario wird entweder direkt im Wiki oder mithilfe von Scribbles oder Wireframes beschrieben und etabliert.
• Gemeinsam definieren wir Akzeptanztests für eine Lösung und anschließend das weitere Vorgehen.

Beispiel: Vom Problem zum Lösungsvorschlag

Beschreibung der Herausforderung
Was genau ist darunter nun zu verstehen? Wie ein Use-Case-Workshop ablaufen kann, zeigen wir am besten anhand eines Beispiels aus der Praxis:

Ein //SEIBERT/MEDIA-Kunde ist ein international agierendes Industrieunternehmen. Für den weltweiten Rollout neuer Produkte werden umfangreiche Marketingpläne erstellt und bislang als aufwändige Powerpoint-Präsentationen per E-Mail mit Anhang unternehmensweit kommuniziert. Außerdem werden Marketingplan-relevante Aufgaben und fast alle Meeting-Vorbereitungen in Word-Dokumenten abgebildet und ebenfalls per E-Mail verschickt. Ein denkbar ungünstiges Szenario, denn dieses Vorgehen geht zulasten von Produktivität und Effizienz:

• Marketingpläne werden dezentral in Form von Präsentationen abgebildet.
• Marketingpläne sind uneinheitlich aufbereitet.
• Es sind nicht alle Vorlagen für die Erstellung der Marketingpläne zentral verfügbar. Im Unternehmen sind teilweise unterschiedliche Versionen im Umlauf.
• Es sind nicht alle Iterationen der Marketingpläne zentral verfügbar.
• Aufgaben werden in Word-Dokumenten abgebildet und dezentral per E-Mail kommuniziert.
• Es gibt Herausforderungen bei der Transparenz, Kommunikation, Effektivität, Effizienz und insbesondere bei der Koordination der Aktivitäten.

Vorgehen: Welche Maßnahmen helfen?
Gemeinsam mit dem Kunden haben //SEIBERT/MEDIA-Berater eine User-Story erarbeitet, die ein optimales Vorgehen beschreibt:

• Es soll im bestehenden Confluence-Firmenwiki des Kunden ein Portal eingerichtet werden, um die Marketingpläne zentral abzubilden.
• Alle Informationen, die heute in Marketingplänen enthalten sind, sollen künftig in Form von Wiki-Dokumenten aufbereitet werden, die der Projektmanager per Klick aus vorbereiteten Vorlagen generieren kann und nur noch mit Inhalten befüllen muss.
• //SEIBERT/MEDIA erstellt diese Vorlagen für Confluence, an denen sich Projektmanager orientieren können.
• Um die Inhalte der Präsentationen adäquat abzubilden, sollen Confluence-Plugins genutzt und teilweise zusätzlich integriert werden, die aussagefähige Diagramme, Gantt-Charts und Tabellen ermöglichen.
• Da dem Kunden das Aufgabenmanagement-System JIRA zu mächtig ist, soll für die zentrale Aufgabenverwaltung im Zusammenhang mit Marketingplänen das Confluence-Plugin TaskDock zum Einsatz kommen, das ein Wiki-internes Aufgabenmanagement und die Erstellung von seitenspezifischen Aufgaben inklusive Statusüberwachung ermöglicht.

Konkrete Optimierung: Wie der Prozess künftig ablaufen soll
Welche Auswirkungen hat diese grundlegende prozessuale Veränderung nach der Realisierung? Außerordentliche:

• Per Klick kann ein Projektmanager einen Wiki-Space für einen Marketingplan anlegen und ebenfalls per Klick die einzelnen Dokumente aus Vorlagen erstellen, die nur noch mit spezifischen Inhalten gefüllt werden müssen.
• Die wichtigen Informationen sind einheitlich aufbereitet und jederzeit auf einen Blick verfügbar.
• Alle Informationen sind zentral abgebildet. Angefügte Powerpoint- und Word-Dateien werden versioniert und stehen in allen (auch früheren) Versionen zur Verfügung.
• Marketingpläne sind stets aktuell und können auch von mehreren Beteiligten einfach bearbeitet und weiterentwickelt werden.
• Aufgaben werden zentral abgebildet. Transparenz ist durch jederzeit verfügbare Statusinformationen gegeben.
• Zusätzlich ist es möglich, Präsentationen direkt anzeigen zu lassen und mithilfe des WebDav-Plugins direkt aus Confluence zu bearbeiten.

Sie sehen: Ein Firmenwiki unterstützt mehr als die bloße Zusammenarbeit und ist in vielerlei Hinsicht der Schlüssel zu konkreten, individuellen Prozessoptimierungen. Man sollte sich eben nur mit erfahrenen Wiki-Experten zusammensetzen.

Ein Use-Case-Workshop von //SEIBERT/MEDIA setzt sich zumeist aus mehreren aufeinanderfolgenden Sitzungen zusammen, in denen wir in Kleingruppen gerne auch mehrere Themen be- und Lösungen erarbeiten. Wichtig ist jedoch: Use-Case-Workshops sollten mit entscheidungsbefugten Personen durchgeführt werden, die die internen Abläufe kennen und auch beeinflussen können. Sonst verläuft eine solche Veranstaltung leider häufig im Sande, ist kaum effizient und mitunter sogar frustrierend.

Haben Sie Interesse an professionellen Wiki-Schulungen und -Workshops durch Experten für Unternehmenskommunikation? Bitte sprechen Sie uns an. Ausführliche Informationen über unsere Schulungsleistungen haben wir für Sie auch auf einer Portalseite in unserem neuen öffentlichen Wiki zusammengestellt.

Weiterführende Informationen

Wiki-Admin-Workshops: Was sie beinhalten und für wen sie sich lohnen
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Firmenwikis: Stärken von Confluence gegenüber Foswiki und MediaWiki
Welche Informationen gehören ins Firmenwiki? Beispiele aus der Praxis

Diese Erweiterung funktioniert ja so: Google „merkt“ sich, welche Suchphrasen reale Nutzer häufig eingeben, und ergänzt Sucheingaben automatisch um mehr oder weniger sinnvolle Begriffe. Insbesondere Fragen, die offenbar zahlreiche User bewegen, haben es in sich. Wir haben zehn besonders schöne bzw. schräge Suchphrasen-Vorschläge gefunden, die bisweilen tief in die Nutzerseele blicken lassen. Werfen wir also einen Blick hinein.

10. Senf oder Ketchup drauf?

Man soll nicht mit Scheuklappen durch die Weltgeschichte laufen. Gerade im kulinarischen Umfeld beweisen wir unseren Kosmopolitismus: Wir essen afrikanisches Foufou, Sushi aus Japan und russischen Borschtsch; wir haben todesmutig sogar typisch englische Küche in London genossen. Und nun muss hin und wieder einfach mal etwas ganz Neues auf den Tisch, finden offenbar manche Nutzer:

9. Hurra, 0,5-ter!

Halbfinale. Ein halbes Finale also. Ein Unterlegener, der oft nur halb so gut wie der Sieger ist. Und wer hier verliert, hat in der Regel nur ein halbwegs erfolgreiches Turnier gespielt, denn er ist quasi auf halbem Wege gescheitert. Somit können wir eine Frage, die so manchem Internet-Nutzer unter den Nägeln brennt, glasklar und fundiert beantworten: Die Verlierer des Halbfinales spielt um den 0,5-ten Platz.

8. Man wird ja wohl fragen dürfen

Ist die Zahl 14 glücklich? Ist es nachts kälter als draußen? Kommt Godot? Manche Fragen sind schlicht sinnlos. Das ist aber beileibe kein Grund, sie nicht zu googeln:

7. Geht im Internet alles? Bestimmt!

Wir shoppen online, treffen Freunde im Netz, sehen im Internet fern und schreiben Tagebuch, tauchen via Google Earth in Ozeane ab und flanieren via Street View durch Straßen in fernen Städten. Wir spielen im Web Poker und lesen unsere Tageszeitung. Wir werden früher oder später per Klick den Bundestag wählen. Im Internet ist alles möglich! Und mancher User fragt sich, ob es sich nicht auch heute schon vermeiden lässt, sich beim Ja-Wort gegenüberzustehen:

6. Kreuchende und fleuchende Flora?

Sicherlich könnte man den Unterschied zwischen Pflanzen- und Tierwelt neunmalklug mithilfe biologischer Fachtermini à la Zellbegrenzung, Plastiden, Vakuolen oder Plasmodesmen vs. Desmosomen herausarbeiten. Doch bei dieser Suggestion kann man sich eigentlich auf eine viel näherliegende Reaktion beschränken: den Facepalm.

5. Living in the Matrix

In was für einer Welt leben wir? Existieren Raum und Zeit tatsächlich? Wie steht es um die Beschaffenheit der Wirklichkeit? Vielleicht ist ja alles virtuell und die Welt eine Simulation, wie einzelne Modelle unseres Universums postulieren. Manchen Nutzern drängen sich in diesem Zusammenhang begründete existenzielle Fragen auf:

4. Das Web rückt die Welt enger zusammen

Das Internet macht die Welt zum globalen Dorf, wir kommunizieren binnen Sekunden mit Personen auf anderen Kontinenten, Grenzen verschwimmen. Das verunsichert selbst weltgewandte Nutzer und provoziert Fragen wie diese (die ihrerseits nunmehr einen Double Facepalm provozieren):

3. Was man sich sonst nicht zu fragen traut, fragt man Google

Es gibt keine dummen Fragen, sondern nur dumme Antworten, hieß es einmal so schön. Es ist faszinierend, wie Google so manch ehernen Grundsatz mir nichts, dir nichts über den Haufen wirft. Aber zur Antwort: ein klares Ja. In unseren Büroräumen halten wir beispielsweise seit längerer Zeit ein 0,3-Liter-Glas Wasser, das gerne über politische und weltwirtschaftliche Fragen nachdenkt, sich die Zeit mit Lesen vertreibt und mit seinem feinen, altersweisen Humor immer auch für einen klugen Scherz zu haben ist.

2. Halber Analphabetismus

Köche, die nichts schmecken, Maler, die farbenblind sind, wasserscheue Schwimmer, Veganer mit Soja-Allergie – all das mag es geben. Es geht aber immer noch einen Hauch grotesker, und zwar in Form von Google-Nutzern, die diese Suchphrase in die Suchmaske – wohlgemerkt – schreiben:

1. Aha, Sie waren das also!

Tja, man wähnt sich auf der sicheren Seite und dann geht alles ganz schnell: Ein unbedachter Klick, die Nachfrage des Systems nicht genau gelesen – und alle Lichter sind aus. Hach, sie war doch eigentlich ganz schön, die Zeit mit dem World Wide Web …

Google Suggest hilft, Zeit zu sparen, und erweist sich hier und da als wirklich nützlich, hat sich aber auch als richtiger Spaßvogel etabliert, wenn man genau hinsieht. Für ein paar unterhaltsame Minuten in der Mittagspause ist dank Auto-Complete jedenfalls gesorgt. Kennen Sie weitere kuriose Suchvorschläge? Wir freuen uns auf Ihre Kommentare!

Weitere Informationen und ähnliche Beiträge

Weitere skurrile Google-Suggest-Funde im Blog Google LOLz
Google Suggest: Ein Praxisbericht zum Vorgehen gegen diskreditierende Suchphrasen
Google Suggest: Manipulationsmöglichkeiten der Vorschlagslisten
Kuriose URLs: Elf unfreiwillig haarsträubende Domain-Namen von Unternehmen
Top-10: Zehn der schlechtesten kommerziellen Websites im Netz

Google Suggest im Visier der SEO-Agenturen

Google Suggest ist inzwischen zu einem beachtlichen Geschäftszweig von SEO-Agenturen geworden, die sich bemühen, Suchergebnisse zu manipulieren. Ein Stichwort heißt in diesem Zusammenhang „Reputation Management”: Es geht also um Einflussnahme darauf, dass ein Personen- oder Unternehmensname nicht zusammen mit negativen Begriffen vorgeschlagen wird – ein ganz seriöses und nachvollziehbares Interesse an der Image-Pflege also.

Auf der anderen Seite gibt es durch Marketingeffekte getriebene Ansätze. Manche Unternehmen haben großes Interesse daran, bei bestimmten Suchbegriffen – Fernreisen, Immobilien, Schuhe, Skifahren, Reifenwechsel oder was auch immer – mit ihren Marken aufzutauchen. Und es gibt Agenturen, die versuchen, genau das zu bewerkstelligen.

Abb.: Viele Unternehmen streben genau dies an: Mit ihrem Firmennamen bei allgemeinen Begriffen vorgeschlagen zu werden.

Manuelle Beeinflussung der Vorschlagslisten

Wie in unserem Praxisbericht erwähnt besteht die Möglichkeit, die Suchanfragen manuell zu beeinflussen: Theoretisch kann man einfach selbst die Suchkombination eingeben, die man in die Vorschlagsliste hieven möchte, und dies an mehreren Rechnern wiederholen. Google soll „denken“, dass viele verschiedene Nutzer die betreffende Suchphrase eingeben, und diese somit als relevant einstufen. Das ist natürlich nur auf einer sehr niedrigen Ebene praktikabel, da niemand Zugang zu Hunderten oder Tausenden Rechnern hat. Wirksam wäre ein solches Vorgehen aber mit Sicherheit.

Alternativ hierzu könnte man die eigenen Mitarbeiter involvieren und beispielsweise im Intranet oder im Firmenwiki einen Link zu einer Google-Suche anbieten, den die Mitarbeiter (am besten von verteilten Standorten oder von zu Hause aus) anklicken sollen. Auch hier wird die Konversionsrate aber kaum hoch genug sein, um prominente Suchphrasen aus der Vorschlagsliste zu verdrängen (die ja auf zehn Vorschläge begrenzt ist).

Manipulationen in der Grauzone

Die angesprochenen Agenturen gehen zwangsläufig anders vor und bemühen Maßnahmen, die in einem Graubereich liegen: Rechtswidrig sind sie nicht, entsprechen aber auch nicht den Google-Richtlinien. Eine häufig genutzte Möglichkeit bieten sog. iFrames: Auf einer Website wird neben den Design-Elementen und dem Content ein pixelgroßer, in der Regel unsichtbarer iFrame geladen, der die Google-Suche mit einer bestimmten Suchphrase beinhaltet. Jeder Nutzer, der die Website besucht, führt im Hintergrund also automatisch eine entsprechende Google-Anfrage durch.

Erstaunlicherweise funktioniert diese Manipulation zumindest bei wenig frequentierten Suchbegriffen tatsächlich. Obwohl Google eigentlich bemerken könnte und müsste, dass alle Anfragen von der gleichen Seite aus durchgeführt werden. Man kann zwar davon ausgehen, dass diese Maßnahme keine langfristige Wirkung hat, aber immerhin tritt der gewünschte Effekt offensichtlich erst einmal ein.

Eine zweite Möglichkeit besteht darin, mittels Spam viele Nutzer dazu zu bringen, eine Google-Suche auszuführen. Das ist natürlich dubios, aber wahrscheinlich dennoch wirksam und vor allem eine nachhaltige Lösung, weil Google sie nicht nachvollziehen kann.

Drittens können Agenturen reale Nutzer engagieren, die für ein geringes Entgelt im Internet surfen, wie es das Unternehmen wünscht, und das Marketing des Unternehmens damit positiv beeinflussen. Hier wird häufig auf Arbeitskräfte aus Niedriglohnländern zurückgegriffen. Auch diese Aktivitäten sind gewiss nicht seriös, die Effekte aber ebenfalls nachhaltig.

Spekulationen und vermeintliche Automatisierung

Darüber hinaus finden sich im Netz etliche Spekulationen über die Beeinflussbarkeit von Google Suggest. Eine Empfehlung lautet, Content zu schaffen, der die gewünschten Suchphrasen unterstützt. Ob und wie genau das funktionieren und wirken mag, ist allerdings nicht klar. Jedoch scheint es durchaus so zu sein, dass Content einen gewissen Einfluss hat: Im Internet wimmelt es in der Tat von Suchvorschlägen, von denen man sich nie und nimmer vorstellen kann, dass sie wirklich jemand eingegeben hat. Möglicherweise könnten solche Phrasen also aufgrund der Inhalte in die Vorschlagslisten übernommen worden sein.

Viele Vorschläge sind in Sachen Seriosität zweifelhaft oder driften ins Reich der Spekulation ab. Worauf ich hinaus will: Es gibt Agenturen, die behaupten, Google-Suggest-Manipulationen im Griff zu haben und automatisiert abbilden zu können. Im Rahmen unserer Beratung sind wirklich abenteuerliche Anbieter auf uns zugekommen, die den Eindruck erweckt haben, dass sie gewünschte Begriffskombinationen einfach selbst in die Datenbank eintragen könnten. Antworten auf konkrete Fragen und vor allem konkrete Ergebnisse ist man allerdings schuldig geblieben.

Man muss den Eindruck bekommen, dass vielfach versucht wird, mit dubiosen und vermutlich nicht wirklich ergebniswirksamen Aktivitäten Geld zu verdienen.

Weiterführende Informationen

Google Suggest: Ein Praxisbericht zum Vorgehen gegen diskreditierende Suchphrasen
Globales Suchmaschinen-Marketing darf nicht nur auf Google setzen
SEO und SEM: Suchphrasen werden länger
Kuriose Google Suggestions im Blog GoogleLOLz

Die Kehrseite: Namen mit unpassenden Begleitbegriffen

Zuweilen kommt es vor, dass Google Suggest für bestimmte Namen negativ besetzte Begriffen vorschlägt – eine nicht unproblematische Praxis, die ein schlechtes Licht auf Personen oder Unternehmen werfen und in Extremfällen sogar existenzbedrohende Folgen haben kann. Ein Problem, vor dem auch Google selbst nicht gefeit ist:

Vor einiger Zeit wandte sich ein Kunde wegen diskreditierender Suchvorschläge von Google Suggest an //SEIBERT/MEDIA: Bei der Eingabe seines Namens schlug Google u.a. Suchphrasen mit den Begriffen Betrug und Scientology vor. Nun ist der Kunde kein Mitglied dieser Organisation und freilich auch kein Betrüger. Entsprechend unangenehm waren ihm die verunglimpfenden Suchvorschläge. Eine gute Gelegenheit, sich eingehender mit Google Suggest und den Möglichkeiten zu beschäftigen, die Ergebnisse zu beeinflussen.

Analyse mittels XML-Anfrage

Es gibt grundsätzlich zwei Möglichkeiten, um auf Google Suggest-Vorschläge Einfluss zu nehmen bzw. bestimmte Vorschläge zu unterbinden. Einerseits steht der Rechtsweg offen: Natürlich kann man mit einem Rechtsanwalt vorgehen und Google eine Unterlassungserklärung oder einstweilige Verfügung mit der Aufforderung zukommen lassen, die Vorschläge zu entfernen bzw. zu ändern. Andererseits ist es möglich, die Suchvorschläge mit den Mitteln zu beeinflussen, die Google selbst nutzt, um seine Ergebnisse zu generieren.

Höchstwahrscheinlich beeinflusst die tatsächliche Anzahl der Suchanfragen die Berechnung der Vorschläge maßgeblich. In diesem Zusammenhang ist eine XML-Anfrage hilfreich: Aus ihr geht hervor, wie groß die Anzahl der verschiedenen Suchanfragen ist. Diese Werte stimmen vermutlich nicht genau mit den tatsächlichen Suchanfragen überein, aber es ist immerhin ersichtlich, welche Werte besonders hoch oder weniger hoch sind und welche Werte Google als relevant einstuft.

Darüber, wie die Zahlen zustande kommen, schweigt Google zwar, aber es gibt zumindest einige Anhaltspunkte, wie häufig Suchanfragen durchgeführt werden. Zudem fällt wohl auch die jeweilige Trefferanzahl, die eine Suchphrase generieren würde, ins Gewicht. Wo genau der Zusammenhang besteht, ist allerdings unklar.

Das weitere Vorgehen

In unserem Fall hat der Kunde seinen Willen bekommen und sein Name wird nicht mehr in Verbindung mit den negativ belegten Begriffen vorgeschlagen. Was hat dazu geführt?

Ursprünglich war der Plan, die Vorschlagsliste manuell mit neuen Begriffskombinationen zu füllen und so die diskreditierenden Suchphrasen zu verdrängen. Das hat bis zu einem gewissen Grad auch funktioniert: Tatsächlich konnten mehrere zusätzliche Suchphrasen eingeschleust werden. Hierfür musste allerdings ein recht hoher manueller Aufwand betrieben werden – dazu mehr in unserem folgenden Artikel Google Suggest: Manipulationsmöglichkeiten der Vorschlagslisten.

Eine zwischenzeitlich angestrebte Lösung auf offiziellem Wege ist indes nicht zustande gekommen. In Googles Webmaster-Forum blieb eine Reaktion auf unsere Beschwerde aus. Im Rahmen einer persönliche Kontaktaufnahme sind uns zwar Vorschläge unterbreitet worden, die jedoch nicht zu einer Lösung des Problems führten.

Am Ende des Tages hat eine durch einen Rechtsanwalt zugestellte einstweilige Verfügung mit anschließender Androhung eines Ordnungsgeldes Google dazu bewegt, die betreffenden Suchphrasen kommentarlos zu entfernen. Manchmal ist der direkte und vielleicht auch etwas banale Weg der zielführende.

In einem weiteren Artikel zum Thema beschäftigen wir uns ausführlich mit Manipulationsmöglichkeiten der Google-Vorschläge und (vermeintlich) automatisierten Vorgehensweisen.

Weiterführende Informationen

Google Suggest: Die Idee und die Tücken
Kuriose Google Suggestions im Blog GoogleLOLz
Globales Suchmaschinen-Marketing darf nicht nur auf Google setzen
SEO und SEM: Suchphrasen werden länger

Ihr Input ist uns wichtig. Deshalb rufen wir die Aktion „Gut kommentiert!“ ins Leben und prämieren hochwertige Kommentare und Anmerkungen von Lesern des //SEIBERT/MEDIA-Blogs! (Ja, wir haben die Idee ein bisschen im Design-Tagebuch bei Achim Schaffrina abgeguckt.)

Natürlich freuen wir uns, dass Kunden, Interessenten, Leser und Mitarbeiter auch jetzt schon immer wieder Artikel durch konstruktive Anmerkungen aufwerten. Das möchten wir weiter fördern und noch mehr Kommentare generieren, die wertvolle Ergänzungen zu unseren Fachbeiträgen bilden: Lassen Sie uns Ihre Meinung zu interessanten Entwicklungen, Trends und Technologien wissen, die wir an dieser Stelle drei Mal pro Woche thematisieren!

Und wir sind gerne bereit, einen kleinen Anreiz dafür zu schaffen: Ende September stellen wir nach einer qualitativen Vorauswahl die zehn unserer Meinung nach besten bis dahin neu eingegangenen Kommentare hier im Blog für Sie zusammen. Bei der Auswahl behalten wir uns vor, zwei Kommentare von unseren Kunden und einen Kommentar von einem //SEIBERT/MEDIA-Mitarbeiter zu nominieren.

Entscheiden, wer das iPad gewinnt, tun jedoch allein Sie. Wir geben Ihnen die Möglichkeit, diese Beiträge über eine Umfrage auf unserer Facebook-Fanpage zu bewerten. Wenn uns bis dahin nicht noch etwas besseres einfällt, wird das einfach eine Meldung auf der Fanpage sein. Als Stimmen zählen dann Ihre Kommentare. Jeder kann beliebig oft kommentieren, es wird aber nur die letzte Stimme gezählt.

Dem Gewinner mit den meisten Stimmen winkt ein nagelneues iPad von Apple!

Abb.: Der Lohn für Ihren guten Kommentar (Bild-Quelle: apple.de)

Warum wir ein Gewinnspiel veranstalten

Warum machen wir das eigentlich? Aus mehreren Gründen: Zunächst sind wir an Ihrem wichtigen Feedback interessiert. Der Blog ist einer unserer wichtigsten Kommunikationskanäle und ein bedeutendes Vertriebsinstrument, das wir ständig optimieren und inhaltlich weiter verbessern möchten. Dafür eignen sich, wie wir meinen, fachliche Diskussionen mit unseren interessierten Lesern, die oft selbst eine große Expertise auf dem Gebiet der Unternehmenskommunikation mitbringen, bestens.

Zweitens ist uns freilich auch daran gelegen, unsere Reichweite zu vergrößern und mit einem Anreiz weitere Interessenten, Leser und Abonnenten zu gewinnen. Drittens ist in unserem eigenen Unternehmen viel, viel Spezial-Know-how vorhanden. Also wollen wir auch unsere Mitarbeiter motivieren, sich an der Außenkommunikation zu beteiligen und sie somit qualitativ zu verbessern. Und nicht zuletzt, da sind wir ganz ehrlich, sehen wir rege diskutierte Artikel einfach lieber als Beiträge, die zwar von vielen Leuten gelesen werden, aber ohne Feedback bleiben.

Wir sind gespannt, wie die Aktion „Gut kommentiert!“ anläuft und wir freuen uns auf Ihre Anmerkungen und gerne auf weitere Aktionen dieser Art. Also:

Selbst kommentieren, Ende September den wertvollsten Kommentar wählen und mit Ihrer Meinung ein iPad gewinnen!

Weiterführende Informationen

Rückblick: Die Themen des Jahres im //SEIBERT/MEDIA-Blog
Presseecho: Wiesbadener Kurier greift //SEIBERT/MEDIA-Blog-Artikel auf
Auswirkungen eines Gast-Blog-Artikels bei TechCrunch
Blog-Artikel im Corporate Weblog: Von der Ideenfindung zur Veröffentlichung

Teilnahmebedingungen: Veranstalterin des Gewinnspiels ist die //SEIBERT/MEDIA GmbH, Söhnleinstraße 8, 65201 Wiesbaden, Deutschland. Die Teilnahme am Gewinnspiel ist kostenlos und unabhängig vom Erwerb von Dienstleistungen. Teilnahmeberechtigt sind nur Personen, die das 18. Lebensjahr vollendet haben. Ein eventueller Gewinn ist nicht übertragbar und kann nicht ausgezahlt, aufgeschoben oder eingetauscht werden. Der Rechtsweg ist ausgeschlossen.

Read this article in German.

Wikis for enterprise use, both those available commercially as well as those available in open-source contexts, have become quite sophisticated. This article introduces and evaluates possible requirements as well as decision-making criteria.

An absolute necessity for the evaluation of a wiki system is that you have a clear picture of the requirements for the system – this is the first and most important step as there are numerous criteria and factors to consider when choosing the correct system.

1. Open-Source-Software or a commercial wiki product?

In principle, it is necessary to differentiate between free open-source wikis and commercial systems. Does your company like using open-source-software? This is by no means an exception: Within the open-source domain, there are professional, sophisticated systems supported by large, engaged communities. Moreover, open-source is, well, “sexy”. Or would your company prefer to avoid open-source-software? That is also not out of the ordinary and completely legitimate. Many companies show a clear tendency towards one or the other of these two directions.

2. Price?

Is your company ready to pay licensing fees for a wiki? Which fees will be required for which system? Regarding commercial systems, you have to consider costs beyond the simple purchase price, such as the follow up costs for support as well as plug-ins, assuming that these will in some cases be necessary.

3. Are high quality plug-ins available?

The expansions are what make wikis into real enterprise wikis. Are processes that you wish to depict supported by suitable expansions? Are these plug-ins fully developed? These questions require the testing of the available expansions for stability and quality.

4. Does an active community already exist?

It’s important that enterprise wikis are consistently undergoing further development. Enterprise 2.0 is an extremely fast growing field within which new demands and possibilities are constantly arising. If there’s no development community latching onto new trends and understanding performance wishes, then the system is quickly out-of-date. Is free support through the community – which is normal for many wikis – guaranteed? How many different service providers are there and what is the quality and depth of knowledge of these service providers?

5. Is this particular Wiki a known quantity?

No company has a burning desire to be the first to discover that a seemingly innovative solution is actually no solution at all. Enterprise wikis have been around since 1998. We strongly advise taking a look at who is established and respected in this field. This is why references and experiences from other companies and service providers with wiki experience play such an invaluable role.

6. What kind of technologies?

Which programming languages are being used (e.g. Java, Perl, PHP)? Is the wiki based on a databank (e.g. mySQL) or on files? Should the wiki be integrated into a company-wide search system? What kind of demands will there be on performance and scalability? Here, of course, your IT department will often list certain requirements. Experience shows, however, that demands such as “Only Java!” or “In any case mySQL!” play no role at all in the day-to-day operations of the wiki or even the systems administration.

7. System functionalities?

The range of functions is a decisive criterion: The wiki needs to be able to depict business processes and must be able to fulfill the demands posed by day-to-day work. When evaluating functionality, you should invest a significant amount of time. Does the system offer a well-thought-out, flexible plan for granting permissions? Can you set up different wiki areas? Can the wiki display, for example, tables, charts, etc.? Does the system offer a native WYSIWIG editor? And so on.

8. Usability and Design?

Motivating employees and creating a critical mass of users are both critical factors for success when introducing a wiki. Ideally, workers should use (happily) the wiki every day and see it as a permanent, integrated component of the infrastructure. Does the software fulfill central usability standards? Is the GUI easy to use? Can the layout of the wiki be adapted to fit the corporate design of your company? How difficult is the administration?

9. Requirements for the project?

Should the enterprise wiki only be implemented in certain departments or across the board? Is it a test run based on the initiative of a department or a full-on rollout following a company decision? How many users are there likely to be? Scalability and the prerequisites for smooth integration into the existing IT-infrastructure play an important role during the introduction of the wiki.

10. Migratability of the data?

Many companies would like – or even need – to keep open the option to move their data at a later date and transfer it into other systems. So can the data be migrated into another system in the most automatic way possible? How difficult is this process?

11. Does the wiki offer simple system administration?

Very important factors for simple system administration include fast backups, updates that can be easily installed, the possibility of reacting quickly to exploits, etc. Also, you shouldn’t forget during the evaluation to make sure that you can run the wiki on various operating systems.
In our experience, technology is not the most important factor for a wiki project (organizational measures are much more critical for its success), but you shouldn’t ignore it entirely, either. It’s important to analyze your company’s requirements very early on in the process and to find which system will most optimally support the processes that should be depicted. //SEIBERT/MEDIA can help you do this.

Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us. Further information on this topic can be found on our special page on enterprise wikis.

Further information

Architecture of a Wiki-Project: Elements, Process, Approach, Rules
Architecture of a Wiki-Project: Customers’ Frequently Asked Questions
Factors for the Success of Wikis 1: Technology is important, but not King
Factors for the Success of Wikis 2: Organization is the Key
Factors for the Success of Wikis 3: Overcoming Resistance from the Company Culture

In unserer letzten Live-Video-Session zum Thema Aufgabenverwaltung am 8. Juli 2010 haben wir uns mit der Frage beschäftigt, ob ein systematisches, unternehmensweites Aufgabenmanagement eine Utopie oder doch längst realistisch und umsetzbar ist.

Ausgehend vom Status Quo in vielen Unternehmen, dem Aufgabenmanagement per E-Mail, hat Martin Seibert die Fragen diskutiert, was eine professionelle Aufgabenverwaltung können muss, was die Etablierung eines ausgereiften Software-Systems für das Aufgabenmanagement anderen Vorgehensweisen voraus hat und warum //SEIBERT/MEDIA Unternehmen die Software JIRA empfiehlt.

Die Sendung kommt zu dem Schluss:

Nein, ein unternehmensweites, zentrales Aufgabenmanagement ist keine Utopie, sondern dank einer Software wie JIRA in immer mehr Unternehmen längst Realität.

Keine Zeit gehabt? Hier nachträglich ansehen!

Haben Sie die Sendung verpasst? Kein Problem: Die ausführliche Agenda zur Session haben wir zum Nachlesen in unserem öffentlichen Wiki zur Verfügung gestellt. Und hier können Sie sich die Aufzeichnung der ca. 45-minütigen Sendung anschauen:

Nicht verpassen: Unsere Folgesendung über die JIRA-Oberfläche

Übrigens: In der nächsten Live-Session zum Thema Aufgabenmanagement am 5. August 2010 dreht sich alles um die Oberfläche der Software JIRA. Wir stellen Ihnen das System in der Praxis vor, zeigen Ihnen, wie man mit wenigen Klicks Aufgaben anlegt, priorisiert, beschätzt, zuweist und aktualisiert und vermitteln Ihnen Tipps und Tricks zum Einsatz von JIRA im agilen Projektmanagement. Wie immer können Sie sich unter http://seibert.biz/live ganz einfach in die Session klicken und via Chat auch gerne mit uns interagieren.

Also: Wenn Sie sich für ein professionelles Aufgabenmanagement im Unternehmen interessieren und JIRA näher kennenlernen möchten, schalten Sie am 5. August um 11.15 Uhr ein. Und um den Termin nicht zu verpassen, können Sie sich hier schnell, einfach und natürlich kostenlos anmelden.

Weitere Informationen

Unser Video-Session-Portal mit allen Terminen
Live-Video-Sessions von //SEIBERT/MEDIA jetzt regelmäßig
Unsere spezielle Seite mit vielen Informationen über professionelles Aufgabenmanagement und JIRA
Atlassian-Lizenzen: Warum ein Kauf bei //SEIBERT/MEDIA eine gute Wahl ist
E-Mail-Missbrauch: Aufgaben gehören nicht in E-Mails

Wir haben die Erfahrung gemacht, dass auch in Unternehmen, die ein Wiki schon länger in Betrieb haben, nicht alle mächtigen Funktionalitäten, wichtigen Plugins, Konfigurationsmöglichkeiten usw. genutzt werden bzw. überhaupt bekannt sind. Deshalb kann das Wiki von den Mitarbeitern auch nach Jahren häufig nicht so effizient und produktiv eingesetzt werden, wie es eigentlich möglich wäre und sein sollte. Eine Administratorenschulung lohnt sich also oft auch für Unternehmen, die das Wiki schon vor einiger Zeit ausgerollt haben.

Flexibilität durch individuell zusammengestellte Schulungsinhalte

Jedes Unternehmen hat andere Bedürfnisse und in jedem Unternehmen ist es um das bestehende Wiki-Know-how der Beteiligten anders bestellt. Deshalb sind die Patentrezepte für einen gewinnbringenden Admin-Workshop Wiki-Kompetenz und Flexibilität. Wir halten es für sinnvoll, unsere Administratorenschulungen nicht nach starren Vorgaben durchzuführen, sondern Kunden in die Planung und Gestaltung des Workshops einzubinden: Sind Sie eher an einem grundsätzlichen Überblick über die Administration des Wikis interessiert? Oder sehen Sie spezielle Wissensdefizite in Ihrem Unternehmen, die punktuell behoben werden sollen? Stehen vielleicht Sicherheitsfragen in Ihrem Wiki besonders im Fokus?

Wir haben mögliche Schulungsinhalte in kompakte Blöcke aufgeteilt, die zwischen fünf und 45 Minuten Zeit in Anspruch nehmen und aus denen Sie gerne Ihre individuelle Agenda zusammenstellen können. Workshop-Inhalte sind beispielsweise:

Hintergrundwissen: In welcher Programmiersprache wurde das Wiki entwickelt, welche Frameworks nutzt es? Unter welchen Voraussetzungen läuft es (Betriebssystem, Datenbank, Hardware, sonstige Anforderungen)?

Admin-Bereich – Konfiguration: Allgemeine Konfiguration, Plugins (Installation, Deinstallation, Aktivierung, Einstellungen), Attachment-Speicherung, WebDAV-Konfiguration, Office-Connector-Einstellungen, etc.

Admin-Bereich – Administration: Sicherung, Import, Indizierung und E-Mail-Warteschlangen, Cache-Statistiken, Lizenzinformationen, Systeminformationen, Thread-Dump, Protokoll- und Profilerstellung, vertrauenswürdige Anwendungen, etc.

Admin-Bereich – Sicherheit: Globale Berechtigungen, Verwaltung von Benutzern und Gruppen.

Bereichs- und Seitenverwaltung: Sicherheit (Bereiche und Seiten), E-Mail (Konten, Import), Export (PDF, XML, HTML), erweiterte Seitenverwaltung.

Verzeichnisdienstintegration: LDAP-Anbindung, Strategie, Hinweise und Schritte zur Anbindung an OpenLDAP, Active Directory, eDirectory und weitere.

Auf unserer Seite über Wiki-Admin-Schulungen in unserem neuen öffentlichen Wiki finden Sie eine detaillierte Aufstellung der möglichen Inhalte mit zusätzlichen Erläuterungen und Angaben zur Dauer der einzelnen Elemente in einer übersichtlichen Tabelle.

Zielgruppen der Administratorenschulungen von //SEIBERT/MEDIA

IT-Mitarbeiter, die das Wiki administrativ betreuen und die für die Sicherheit des Systems verantwortlich sind, bilden sicherlich den Personenkreis, an den sich unsere Admin-Workshops in erster Linie richten. Wir vermitteln zahlreiche praxisrelevante Tipps und erklären Ihnen, wie das Wiki in die bestehende IT-Infrastruktur eingebunden wird, wie Nutzer optimal via Single-Sign-on und LDAP integriert werden, wie man Patches und Updates einspielt und updatet, usw.

Manager und Mitarbeiter, die der Ansicht sind, dass ein Wiki mehr als ein reines Kollaborations-Tool sein kann, und die das System effizienter und produktiver nutzen möchten, gehören ebenfalls zur Zielgruppe. Wir zeigen Ihnen den Umgang mit Bereichskonzepten, Wiki-Formularen, Auswertungen, Versionierungen, Macros und Plugins, etc.

Wiki Gardener kümmern sich um die Content-Pflege des Wikis und bilden die dritte Personengruppe, die von unserem Schulungsangebot profitieren kann. Wir erklären Ihnen, wie man effizient mit Dokumenten und Bereichen umgeht, User anlegt und Gruppen administriert, mit Revisionen arbeitet, Teile eines Dokuments in andere einbindet, E-Mail-Abos einstellt, usw.

Mitglieder des Betriebsrats, die ein legitimes Interesse daran haben, dass keine Datenschutzrichtlinien verletzt werden und dass das Firmenwiki ein nützliches Werkzeug, nicht jedoch ein Mittel zur Überwachung der Mitarbeiter ist, möchten wir mit unserer Leistung ebenfalls ansprechen. Wir zeigen Ihnen, wie Berechtigungen und Auswertungsmodule den Datenschutzauflagen entsprechend konfiguriert werden und helfen, in allen Unternehmensteilen Vertrauen in das Wiki als ebenso tolles wie unbedenkliches Arbeitsmittel aufzubauen und zu etablieren.

Mehrwert durch Praxisnähe und Erfahrung

Es ist unser Ziel, Sie und Ihre Mitarbeiter systematisch und praxisnah zu schulen: Unsere Wiki-Workshops werden von kompetenten Wiki-Beratern durchgeführt, die die Systeme Confluence und Foswiki bzw. TWiki durch jahrelange tägliche Arbeit ausgezeichnet kennen und die sich ggf. Verstärkung durch einen IT-Experten von //SEIBERT/MEDIA/SYSTEMS holen. In kleinen Gruppen vermitteln wir Ihnen eine fundierte theoretische Basis und haben gleichzeitig immer Ihre individuelle Unternehmensrealität und Ihre spezifischen Anwendungsfälle im Blickfeld. So schaffen wir Mehrwert.

Interessieren Sie sich für individuelle Wiki-Schulungsleistungen? Wir stehen Ihnen gerne zur Verfügung, bitte sprechen Sie uns unverbindlich an. Einen Überblick über alle von //SEIBERT/MEDIA angebotenen Wiki-Schulungen, -Workshops und -Vorträge finden Sie auf einer umfangreichen Portalseite in unserem öffentlichen Wiki.

Weiterführende Informationen

Unsere spezielle Seite zum Thema Firmenwikis mit ausführlichen Infos und Videos
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Firmenwikis aus Sicht des Betriebsrats: Tipps, Tricks und Fehleinschätzungen
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Erfolgsfaktoren für Wikis: Organisation ist der Schlüssel

Zu Beginn eines Sprints arbeiten Projektmanager und Kunde gemeinsam Vorschläge aus, welche Tickets realisiert werden sollen. Nach dieser Abstimmung mit dem Kunden entscheidet das Team anhand einer möglichst exakten Aufwandsschätzung, was im nächsten Sprint tatsächlich umsetzbar ist. Im Mittelpunkt: Klebezettel.

Ein kleiner Praxisbericht mit Beispielen

Das Team ordnet und bespricht die Prioritäten der anstehenden Aufgaben, die in Karteikartenform visualisiert werden:

Was muss abgearbeitet werden, bis eine Aufgabe abgeschlossen ist? Die Arbeitsschritte werden auf Karten festgehalten, die einen konkreten Überblick vor allem über die Komplexität einer Aufgabe bieten:

Die präzise Aufwandsschätzung ist ein grundlegender Teil von Scrum, denn nur durch realistische Schätzungen und exakt definierte Kapazitäten lassen sich Sprints gut planen. Deshalb steht am Anfang jedes Sprints der Aufwandspoker, bei dem das Entwickler-Team mithilfe spielerischer Elemente die Aufwände für einzelne Tasks definiert.

Vereinfacht dargestellt: Alle Team-Mitglieder beschätzen den Aufwand für ein Feature mithilfe von Karten, denen bestimmte Werte zugeordnet sind. Die Mitglieder mit der niedrigsten und höchsten Schätzung erläutern den anderen ihre Entscheidungen. Anschließend wird dieser Vorgang wiederholt, bis es zu einem Konsens kommt und eine realistische, fundierte Aufwandsschätzung vorliegt. Hier werden die Karten für den Aufwandspoker vorbereitet:

Nach dem Aufwandspoker kann das Team festlegen, welche Tasks im Rahmen der anstehenden Iteration bearbeitet werden. Ein Planning-Board gibt einen zentralen Überblick über die Aktivitäten im Sprint:

Mit JIRA und Greenhopper das Scrum-Vorgehen elektronisch abbilden

Bei //SEIBERT/MEDIA werden alle Tasks und Teilaufgaben natürlich auch in unserem professionellen Aufgabenmanagementsystem JIRA abgebildet, das im Zusammenspiel mit dem Plugin Greenhopper eine optimale Grundlage für ein Vorgehen nach Scrum bildet.

Auf dem Planning Board lassen sich Aufgaben, die in Karteikartenform dargestellt sind (Virtual Index Cards), per Drag & Drop den jeweiligen Releases (Iterationen) zuordnen. So kann die Zeitplanung mit wenigen Klicks durchgeführt und angepasst werden.

Diese Oberfläche des Task Boards gibt einen Überblick über alle Vorgänge innerhalb eines Releases oder über die einem Mitarbeiter zugewiesenen Aufgaben. Auch hier werden alle Aufgaben als Karteikarten dargestellt, die konfigurierbar sind. Statusanpassungen werden per Drag & Drop vorgenommen.

Das Chart Board schließlich ist das zentrale Auswertungsinstrument von Greenhopper: Komfortable Burn-down-Charts bieten einen Überblick über den Status eines jeden Projektabschnitts und geben dem Projektmanager die Möglichkeit, auf alle Entwicklungen kurzfristig proaktiv zu reagieren.

Scrum hat sich bei //SEIBERT/MEDIA als ein überraschend dynamischer und interaktiver Prozess dank Karten etabliert. Haben Sie Fragen zur agilen Anwendungsentwicklung? Suchen Sie Möglichkeiten, um Budget- und Terminüberschreitungen bei der Software-Erstellung zu vermeiden und gleichzeitig optimale Qualität sicherzustellen? Wir sind Spezialisten für agile Software-Entwicklung und Scrum und beraten Sie gerne: Sprechen Sie uns einfach an und wir stellen Ihnen unverbindlich ein Informationspaket zusammen, mit dessen Hilfe Sie herausfinden können, ob „agile“ auch etwas für Ihre Entwicklungsabteilung ist.

Weiterführende Informationen

Unsere spezielle Seite zum Thema JIRA mit Kontaktmöglichkeiten und Video-Einführung
JIRA: Aufgabenmanagement, Scrum und agiles Projektmanagement für Entwickler und Manager (Vodcast)
Agile Software-Entwicklung vs. Wasserfall-Modell: Was die Forschung sagt
Scrum: Agile Software-Entwicklung bei //SEIBERT/MEDIA

Unser Microblog

In unserem Microblog finden Sie täglich mehrere Nachrichten rund um unsere Arbeit und die Internet-Branche. Damit wollen wir Ihnen eine Art Filter für all das anbieten, was im Netz passiert: Entwicklungen und Tipps zu den Themen Unternehmenskommunikation und Social Media, technologische Neuerungen, Design-Trends und mehr.

Da wir diese Nachrichten automatisiert an unsere Twitter-Accounts, unsere Facebook-Fanpage und viele weitere Stellen syndizieren, überschreitet keine Nachricht die 140-Zeichen-Marke – Informationen aufs Wesentliche konzentriert also.

Möchten Sie diese Kurznachrichten abonnieren? Das geht über RSS-Feeds auf unserem Microblog-Portal, via Twitter und Facebook oder ganz einfach per E-Mail. Bleiben Sie auf dem Laufenden.

Der //SEIBERT/MEDIA-Weblog

Neben den Kurznachrichten produziert unser kompetentes Redaktions-Team drei Mal pro Woche hochwertige Fachartikel für unseren Corporate Weblog. Montags, mittwochs und freitags jeweils gegen 10.00 Uhr erscheint ein interessanter Beitrag von etwa zwei Seiten Umfang – immer kompetent und auf sachliche Information ausgerichtet.

Dieser Weblog ist unser Flagschiff für hochwertige Information und für Interessenten und unseren Kunden eine beliebte Möglichkeit, sich über neue Themen fundiert zu informieren. Übrigens können Sie ca. 100 Blog-Artikel auch als professionell umgesetzte Podcasts direkt anhören oder für Ihren MP3-Player kostenlos herunterladen. Wenn Sie den Weblog und unsere Podcasts abonnieren möchten, bieten wir Ihnen in der Toolbar unten Abos für unseren RSS-Feed und den monatlichen Newsletter an.

Unser öffentliches Wiki

Unser neues öffentliches Wiki unter http://infos.seibert-media.net auf Basis von Confluence ist die Quelle für Detailinformationen und spezifische Beratungsergebnisse. Natürlich ist unser Wiki längst kein Wikipedia. Aber wir arbeiten täglich an der Erweiterung und bilden u. a. viele Erkenntnisse aus unserem internen Firmenwiki öffentlich für Sie ab. Wenn Sie spezielle Informationen benötigen, können Sie jederzeit eine unkomplizierte Wiki-Suche durchführen und zudem bestimmte Stichwörter abonnieren.

Unsere klassischen Websites

Natürlich betreiben wir auch ganz klassische und konventionelle Corporate Websites wie unsere Portalseite unter www.seibert-media.net, die allgemeine Informationen über //SEIBERT/MEDIA sowie unsere Referenzdatenbank und aktuelle Job-Angebote bereithält. Auf unseren Minisites für die Bereiche Consulting, Design, Technologies und Systems können Sie sich über unser Leistungsportfolio informieren.

Integration via Web-Toolbar

Für alle //SEIBERT/MEDIA-Websites bieten wir Ihnen eine Werkzeugleiste am unteren Rand des Browser-Fensters an, die Ihnen eine Suche über alle Informationen in allen Auftritten ermöglicht. Hier können Sie komfortabel und Website-übergreifend in unseren Tweets, Blog-Artikeln, Wiki-Informationen und Website-Inhalten suchen, unseren Kommunikationskanälen folgen und sie abonnieren sowie mit //SEIBERT/MEDIA in Kontakt treten bzw. in Kontakt bleiben.

Der //SEIBERT/MEDIA-YouTube-Channel

Seit längerer Zeit bietet //SEIBERT/MEDIA in einem eigenen YouTube-Channel auch Videos an. Unser rasch wachsender Fundus an Bewegtbild setzt sich aus praktischen Screencasts und Tutorials mit Tipps und Tricks zu vielen Anwendungen, die für Unternehmen relevant sind, aus Video-Mitschnitten von Vorträgen und Workshops und aus professionell umgesetzten Vodcasts zu spannenden Themen zusammen. Schauen Sie mal rein unter www.youtube.com/seibertmedia.

Beim passiven Ansehen muss es aber nicht bleiben: Gerne können Sie im Rahmen unserer wöchentlich stattfindenden Live-Video-Sessions mit uns interagieren und ins Gespräch kommen. Infos zu diesen Beratungssendungen finden Sie in unserem öffentlichen Wiki.

Landing-Pages zu Spezialthemen

Der erste Kontakt zu Interessenten kommt in aller Regel aber über eine unserer vielen Landing-Pages zustande, die mit kompakten Informationen jeweils ein spezifisches Interesse bedienen. Auf diesen Seiten können Sie per Kontaktformular ganz unverbindlich und mit geringen „Transaktionskosten“ Kontakt mit uns aufnehmen und ohne Verpflichtungen anfragen. Und in aller Regel können wir Ihnen kurzfristig erste Links zu unseren Berichten, Informationen, Video-Tutorials und spezifischen Referenzen per E-Mail zuschicken. Das bringt Sie in Ihrer Projektplanung selbst dann voran, wenn Sie später bei der Umsetzung gar nicht mit uns arbeiten sollten.

Hier geht’s zu unseren speziellen Landing-Pages:

• Firmenwikis
• JIRA
• Google Wave
• Corporate Design
• Logo-Entwicklung
• User-Tests
• Expertenbasierte Usability-Analysen
• Google AdWords
• Landing-Pages
• iPhone-Programmierung
• Anwendungsentwicklung mit Groovy und Grails sowie mit Perl

Wir beraten Sie gerne, stellen Sie einfach Ihre unverbindliche Anfrage!

Besteht in Ihrem Unternehmen ein Interesse an einem speziellen Thema rund um die Bereiche Unternehmenskommunikation? Planen Sie neue Internet-Aktivitäten? Dann stellen doch auch Sie eine kurze, unverbindliche Anfrage: Schicken Sie einfach eine E-Mail an beratung@seibert-media.net oder füllen Sie rasch unser Online-Formular aus. Wir freuen uns darauf, Sie kostenlos informieren zu dürfen.

Und schauen Sie sich doch mal eingehender bei uns um, Möglichkeiten gibt’s reichlich!

Wie ist es in Ihrem Unternehmen? Benötigen viele Kunden immer wieder an den gleichen Stellen Unterstützung? Stellen Interessenten oft die gleichen Fragen? Möchten Sie Interessenten die Möglichkeit geben, Sie und Ihr Produkt- oder Leistungsspektrum auf interaktive Weise genau kennenzulernen, ohne zu viele Vorleistungen in Form von persönlicher Beratung oder Vertriebsaktivitäten erbringen zu müssen? Wollen Sie schon online vor allem das zeigen, was für Ihre Kunden wirklich wichtig und relevant ist?

Dann sollten Sie darüber nachdenken, interaktive Checklisten in Ihre Beratung zu integrieren: Checklisten auf Basis von Hunch bieten Ihnen die Möglichkeit, sich schon im Web als kompetenter Berater zu profilieren, und unterstützen den Vertrieb online. Sie helfen Kunden bei der Entscheidungsvorbereitung und der Auswahl von Alternativen und sie liefern Interessenten präzise Antworten im Hinblick auf Ihr Produkt- oder Leistungsspektrum, bevor eine persönliche Beratung nötig wird.

Probieren Sie’s mal aus

Auch //SEIBERT/MEDIA nutzt Hunch-Checklisten, denn Transparenz ist uns sehr wichtig. Wir versuchen nicht, Kunden einzuwickeln. Wir möchten immer lupenreine Qualität bieten. Dazu gehört auch, dass man klar macht, wo man stark ist und wo die eigenen Schwerpunkte liegen.

Um das Konzept kennenzulernen, schauen Sie doch einfach mal zwei unserer Checklisten an. So einfach geht’s:

1. Klicken Sie auf den Screenshot und Sie werden zur Checkliste weitergeleitet.
2. Beantworten Sie oben links einfach, schnell und anonym die angezeigten Fragen.
3. Auf der rechten Seite erscheinen die besten Ergebnisse, das relevanteste steht ganz oben.
4. Für Ergebnisse, die Ihnen gefallen, können Sie uns gerne eine unverbindliche Anfrage schicken. Wir freuen uns darauf.

Checkliste: Welche //SEIBERT/MEDIA-Dienstleistungen sind für Sie interessant?

Checkliste: Ist eine Wiki-Einführung für Sie interessant?

Wenn Sie nun zu der Ansicht gekommen sind, dass weitere Informationen zu einem Thema für Sie interessant sein könnten, fragen Sie uns einfach: Wir haben zu vielen Themen umfangreiche und hilfreiche Infos für Ihre Projektplanung, die wir gerne kostenlos und unverbindlich mit Ihnen teilen.

Vorteile von interaktiven Checklisten

Sie sehen: Mit interaktiven Checklisten haben Sie die Möglichkeit, Interessenten schon online punktgenaue Empfehlungen geben zu können. Darin steckt ein enormes Potenzial für Ihre Produkt- und Dienstleistungsberatung. Die folgenden Argumente sind unserer Meinung nach sehr überzeugend.

Aus Nutzersicht:

• Die Hunch-Checklisten sind einfach bedienbar.
• Der Nutzer bleibt anonym und kann sich ohne hohe „Transaktionskosten“ intensiv mit Ihrem Unternehmen beschäftigen.
• Der Service ist Web-basiert und schnell.
• Interaktive Checklisten sind von Anfang an relevant und auf den User zugeschnitten.
• Das System lernt und wird in der Beratung immer besser.
• Der User kann schnell und unkompliziert unter verschiedenen komplexen Alternativen auswählen.
• Die richtigen Fragen und Argumente helfen, Entscheidungen fundiert zu treffen.

Für Sie und Ihr Unternehmen:

• Die Nutzung der Software ist kostenfrei.
• Das Tool lernt selbständig und optimiert zum Beispiel die Reihenfolge ohne Ihr Zutun.
• Es ist sehr einfach, das System mit Fragen und Ergebnissen zu füllen. Dafür sind weder Programmierkenntnisse noch Technik-Know-how erforderlich.
• Sie können ohne viel Vorlauf loslegen und kurzfristig online gehen.
• Die Checklisten sind einfach und schnell zu erweitern.

Wir helfen Ihnen gerne dabei, eine eigene interaktive Checkliste aufzusetzen oder eine automatisierte Online-Beratung zu etablieren. Bitte fragen Sie uns unverbindlich.

Ich gebe zu: Als ich dieses Tool zum ersten Mal gesehen habe, war ich ziemlich begeistert und beeindruckt und bin es immer noch. Die Wibiya-Toolbar ist eine tolle Sache für Websites und Blogs: Sie lässt sich leicht einbinden, ist – auch in Sachen Design – sehr gut anpassbar und bietet zahlreiche kostenlose Apps. Sie vereint viele wichtige (und weniger wichtige) Social-Media-Anbindungen in einer schlanken Lösung, ohne dass jeweils eigene Widgets und Teaser für Twitter, Facebook, YouTube etc. nötig sind. Nutzer können twittern und Inhalte auf der Facebook-Fanseite teilen, ohne die Website zu verlassen. Der Seiteninhalt kann durch große 3D-Galerien, Spiele, Live-Chats und andere interessante Anwendungen aufgewertet werden. Ein richtiges Allround-Talent!

Betrachten wir anhand der //SEIBERT/MEDIA-Websites, wie die Wibiya-Toolbar sich im Unternehmensumfeld macht und was sie bringt.

Funktionen und Anwendung

Die Installation der Wibiya-Toolbar ist denkbar einfach: Sie lässt sich mit einem ganz kurzen Snippet integrieren, das Layout ist vollständig anpassbar. Sowohl Farben als auch sämtliche Buttons können ausgetauscht und spezifiziert werden, alle Online-Portale und Inhalte, die //SEIBERT/MEDIA betreibt, lassen sich einbinden. Diese Elemente sind in unsere angepasste Toolbar integriert:

• universelle Suche über alle öffentlichen Sites mithilfe von Google Custom Search (derzeit mehrere tausend Seiten)
• Direktansicht der letzten Microblog-Nachrichten als Ausklappliste
• Direktansicht der letzten Weblog-Fachbeiträge als Ausklappliste
• Direktansicht der letzten Änderungen im neuen öffentlichen Wiki von //SEIBERT/MEDIA als Ausklappliste
• die Möglichkeit, jede Seite, auf der die Toolbar implementiert ist, bei Facebook mit „Gefällt mir“ zu bewerten
• eine einfache und schnelle Möglichkeit, die Inhalte via AddThis zu teilen
• ein Live-Chat via IRC über den Channel #seibertmedia
• eine Möglichkeit, die RSS-Feeds von //SEIBERT/MEDIA für Weblog, Microblog, Podcasts und öffentliches Wiki zu abonnieren
• eine Inline-Ansicht der Facebook-Fanpage von //SEIBERT/MEDIA mit der Möglichkeit, direkt Fan zu werden
• eine Inline-Ansicht des //SEIBERT/MEDIA-Twitter-Accounts und die Möglichkeit, ihm zu folgen
• ein kleiner Layer mit einer einstellbaren Nachricht, die darauf hinweist, dass eine Anfrage gestellt werden kann

Die Wibiya-Toolbar ist kostenlos, sofern man ein kleines Icon „Powered by wibiya“ akzeptiert. Für eine nicht gebrandete Version, wie wir sie verwenden, ist ein Premium-Account nötig.

Vorteile

Grundsätzlich ist die Wibiya-Web-Toolbar eine solide und ziemlich coole Sache, wie wir finden. Aus unserer Sicht sind diese Vorteile überzeugend:

• einfache Einbindung in beliebige Websites
• Integration aller //SEIBERT/MEDIA-Websites inkl. Landing-Pages
• endlich eine einheitliche Suche über alle Seiten und Inhalte (inkl. Anhänge)
• ein richtiges Überraschungsei mit mehr als einem Dutzend Funktionen in einer Leiste, die sich vollständig an vorhandene Design-Anforderungen anpassen lässt
• eine dezente, aber recht beeindruckende Demonstration unseres erfolgreichen Ansatzes, interessanten, hochwertigen Content zu produzieren und sich mehrere Kommunikationskanäle zunutze zu machen
• Promotion der RSS-Feeds und des Newsletters
• mehr Follower und Fans auf Twitter und Facebook
• mehr Interaktion mit den //SEIBERT/MEDIA-Kunden über einen sehr einfach zu bedienenden Live-Chat mit Web-Oberfläche
• geringe Kosten für eine ausgereifte Lösung

Nachteile

Freilich ist leider keine Software die eierlegende Wollmilchsau und es hat jede Anwendung auch die eine oder andere Schwachstelle. Diese Nachteile könnten mit der Integration der Wibiya-Toolbar einhergehen:

• Die Toolbar kann zu Usability-Problemen führen, wenn Nutzer nicht zwischen Navigation und Toolbar unterscheiden können.
• mögliche Ablenkung von den eigentlichen Inhalten der Seite
• Kosten in Höhe von immerhin 9,90 US-Dollar pro Monat für eine nicht gebrandete Version
• Ggf. sind die Icons zu aktiv und aufgesetzt.
• Mit vollem Funktionsumfang ist die Toolbar ziemlich überladen und wird aus Design-Perspektive zu einem Problem.
• Ein Element von einer fremden Website stellt immer ein gewisses Sicherheitsrisiko dar.
• Die Toolbar kann unter Umständen die Ladezeiten der Website negativ beeinflussen.
• Ohne Anpassung verfälscht die Toolbar einige Messungen von Google Analytics massiv (Absprungrate und Seitenzugriffe pro Besuch). Hier ist ein Fix nötig.

Fazit

Unserer Ansicht nach überwiegen die Vorzüge die Probleme. Die  Wibiya-Toolbar ist eine professionelle, ausgereifte, schlanke und vollständig anpassbare Lösung, die relativ wenig Aufwand und geringe Kosten verursacht – vor allem angesichts der Alternative, die oben aufgezählten Funktionen auf die klassische Weise mithilfe einzelner Teaser und Widgets abzubilden, die ja erstens alle gestaltet und implementiert werden müssen und zweitens eine Seite schnell überfrachten.

Sicherlich sind aber vor allem gewisse Usability-Risiken nicht zu unterschätzen, die das Mehr an Funktionalität mit sich bringen kann. Wir werden die Nutzung unserer Websites und die Reaktionen unserer User jedenfalls im Auge behalten.

Wie steht es mit Ihnen: Sehen Sie diese Toolbar hier zum ersten Mal? Oder haben Sie im //SEIBERT/MEDIA-Blog oder anderswo schon mit ihr interagiert und erste Erfahrungen gesammelt? Wir würden uns sehr über Ihr Feedback freuen, nutzen Sie doch einfach die Kommentarfunktion unten.

Read this article in German.

From dozens of enterprise Wiki projects, we know that the successful introduction of a Wiki into a company typically depends on three factors: technology; organization; and culture. In the first of these three articles we focused on the requirements of technology. The second of these articles focused on organizational factors. This report will now focus on the implications of company culture and how these relate to the introduction of a Wiki.

Introduction of the Wiki: The company culture must shift

The establishing of a Wiki is necessarily accompanied by a change in the communicative practices within a company. In comparison to technological and organizational aspects, the component of “company culture” typically plays a somewhat lesser role during the introduction of a Wiki, yet certain kinds of resistance can hinder the success of the project within this context as well.

1. Changing of the approach to communication within a company

The establishing of a Wiki changes the approach to communication within a company. At a basic level, you often encounter within companies the so-called “top-down” approach: The management defines topics and communicates these consciously and intentionally to the employees. A Wiki causes this to change, as employees can themselves produce topics by putting new documents into the Wiki, thereby drawing attention to those topics, and they can also independently push new topics into the spotlight.

Many leaders in many companies fear this and are skeptical that the normal top-down method can be replaced – if not by a “bottom-up” approach still perhaps by a “communications loop”. It is often necessary to convince the management to relinquish some of their control over the communication within the company.

From the employees’ perspective, it can be a critical problem when employees hesitate to share their knowledge – their most valuable possession. Our project experience shows that in this regard some employees fear a loss of power or even a loss of their value to the company.

Over the course of the Wiki introduction, such people need to be convinced that this will in no case occur. In fact, sometimes the opposite of the fears of these employees occurs: Through the depiction in the Wiki of parts of their expertise, many users become even more important, can position themselves more strongly through their active participation, and profile themselves even more clearly as specialists. This is the case in nearly one-third of the participants, as shown by Majchrzak, Wagner and Yates in their study Corporate wiki users: results of a survey (Odense 2006): 29% of the surveyed Wiki users reported that they had achieved more respect within the company through the sharing of their knowledge, while 28% reported that their reputation within the company had risen.

2. Building of acceptance at decisive levels

In many Wiki projects, especially those in larger companies, you can witness the following phenomenon: Those people who make the decisions about the introduction of the Wiki are not the same people who will later use the tool. There are even decision makers who disparage the introduction of a Wiki, people who say: “I’m not going to work with it, so for that reason I don’t need it.”

Therefore, the decision about a company Wiki is also a challenge to the company culture, because those people with decision-making authority need to be shown conclusively that it is important for them to create an environment within which the employees can work productively, and that it is not their job to ensure only the introduction of those tools that help themselves. Instead, the task of a high-level manager is to provide those employees who are lower in the hierarchy with the tools that will help them increase their value to the company.

3. Responding to those who are skeptical of innovation

Regarding the cultural component, it is also important to evaluate whether you are dealing with a company that tends to quickly adopt innovations and new technologies – or not. In more conservative company cultures, newer technologies – even when they have been proven to lead to the optimization of processes – are often met with initial skepticism, or even in some cases with sweeping criticism.

If this is the case, meaning that there is a critical, conservative company culture within the company into which a Wiki is going to be introduced, then this must be met with extensive organizational measures, more Wiki marketing, and the stronger regimentation of Wiki use cases and other like-minded measures in order to implement the Wiki concept in spite of the opposition.

Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us. Further information on this topic can be found on our special page on enterprise wikis (German).

Read this article in German.

From dozens of enterprise Wiki projects, we know that the successful introduction of a Wiki into a company typically depends on three factors: technology; organization; and culture. In the first of these three articles we focused on the requirements of technology. This report will now focus on the organizational factors for a promising Wiki project.

Organization: The critical factor during the introduction of the Wiki

In our experience the organizational component is up to 50% responsible for the success of a Wiki introduction. It is not typically the technological components that create difficulties. Companies that use Wikis encounter almost exclusively organizational problems, problems that hinder the establishing of the Wiki, as is argued convincingly by Henriksson, Mikkonen and Vadén in their study “Experiences of Wiki use in Finnish companies” (Tampere 2008).

According to such experiences, companies often complain that too few employees upload information to the Wiki actively or often, that the Wiki participants do not grasp the using of the Wiki quickly enough, and that it is difficult to motivate participants to use the Wiki. The organizational measures that your company takes within the context of the Wiki introduction must therefore be complete as well as with an eye on the long-term.

1. Task definition

The first element of the organizational components is the posing of the question regarding which tasks should be accomplished by the Wiki, in other words, the question about the goals of the Wiki: Why is a Wiki being introduced? Which tasks are there that the employees should perform using the Wiki?

Here, certain use cases as well as the concrete use of the Wiki in these use cases must be defined well in advance. From the very beginning, you need to choose a relatively narrow definition for the orientation of the Wiki regarding the use cases. At the same time, it would be ideal to maintain the overall perspective. “Think Big, Start Small, Act Now” is the sensible recommendation, heard quite often due to the influence of Phyllis Piotrow (Piotrow, Phyllis: Keynote Conversation “Strategic Partnerships“, Entertainment-Education Conference, USA 2000).

2. Strong backing from the top

A second element among the organizational components is the so-called “strong backing from the top”: Missing participation from the management level is connected to a high risk, as without the support “from the top”, it will be difficult for a software tool to achieve wider acceptance. Again and again, Wikis become successful within individual departments, yet without the support of the management, it is very unlikely that a company-wide rollout is possible.

It is important that the introduction of the Wiki has the complete support of the management and that the management makes available the necessary resources and financial means.

3. Responsibility for the Wiki

The third element includes the responsibility for the Wiki and the necessary time resources to work with the Wiki. On the one hand, it is important that someone takes over the responsibility for the Wiki and actively pushes its introduction. The small team around this person occupies itself with content integration, fulfills the classic functions known as Wiki-gardening, installs new plugins, solves especially intransigent use cases, provides support, etc. Wiki specialists speak here of a so-called Wiki Evangelist; the team is known as Wiki Champions. These provide, especially in the instruction phase, valuable support: In the framework of the Wiki pilot project (typical during the introduction), this team supervises a larger group of employees who are working with the Wiki and later assumes more responsibility.

Many companies underestimate the incidental resources and necessarily high level of time expenditure that is required for the performing of these tasks. The difference between the Wiki Champion and the regular member of a project team is as follows: The Wiki Champion invests considerably more time in the Wiki and expends considerably more time in performing tasks within the Wiki as well as in offering first-level support.

4. The correct composition of the Wiki pilot project

The Wiki pilot project is the term for the phase during which a number of company employees (often in concert with an experienced Wiki specialist) begin the structuring and establishing of the initial content. The most important aspect of this phase is to inject as much relevant content as possible into the Wiki to make it interesting and attractive for employees.

Regarding this phase Stewart Mader argues that not only the so-called “early adopters” (employees known for their openness to new work methods and technologies) should be included; rather, users with less affinity for technology and who are generally more skeptical should also be included so that the employees working in the Wiki pilot project build an accurate, representative microcosm of the company.

“What’s critically important to the usefulness of the pilot is how you structure the pilot participants. If you only involve hard-core early adopters, then of course it won’t be representative of the organization as a whole. However, if you construct a pilot that involves people from several key areas of the organization [...] and those people understand going into the pilot that they’re getting a chance to set up their uses before everyone else in exchange for their help and patience in finding and fixing technical problems, you’ll get a group that will solidly support the project once it’s opened up for large-scale use.”

The most important goal for the Wiki pilot should not be thought of as the complete translation of the company knowledge base into this new digital information system. For one thing, this would take far too much time and effort. In addition, tasking a few employees to digitize and prepare the knowledge of all the employees is a task that would be nearly impossible to execute. The goal of the Wiki pilot project should instead be about establishing exemplary and successful examples for using the Wiki.

5. Organizational expansion

If the Wiki pilot is successful, this will be passed on via word of mouth: The examples of best practices that were developed will be talked about throughout the company, during which time the participants in the Wiki pilot will play important roles as go-betweens and communicators.

This word of mouth “propaganda” lays the cornerstone for the establishing of additional, albeit smaller, pilot projects within individual company departments or areas. But here, too, the goal is still the implementation of best practices specific to the individual areas; these will show all involved just how valuable a Wiki can be for their daily work. In this regard, it should not be about forcing the system onto all possible departments with the greatest possible speed; rather, it is about ensuring that more and more employees become enthusiastic about the idea of the Wiki, thus finding the right path to using the Wiki.

6. The rollout to more and more employees, and Wiki marketing

In order to increase employee activity during the rollout phase, it is absolutely necessary to make the Wiki known, to communicate throughout the company that there is a Wiki and that it should be utilized for certain use cases. Our experience with projects has shown that companies cannot afford to believe that this alone is enough: It is also usually necessary to repeat such messages and to remind employees repeatedly about this new tool.

This is a job for Wiki marketing. In the realm of Wiki marketing there are various instruments that have proven themselves effective, for example, pens bearing inscriptions such as “I’ll put it in the Wiki: www.wiki-name.com“, various office supplies and displays with information about the Wiki, a feature on the Wiki in internal newsletters, especially active Wiki participation on the part of management or other company leaders in order to demonstrate the importance of the system, and many more.

It is not important, however, how many measures you take, but rather much more important that the Wiki marketing is both unceasing and ongoing; it should be  implemented over a longer period of time in order to sensitize the employees to the Wiki as well as to the value placed on it by the company.

During this phase the company should also identify those employees who are most obviously open to the Wiki and then help them establish best practices for their individual needs. If the Wiki shows itself to be useful in the context of their daily business processes, the chances of establishing it as a successful knowledge management system are significantly higher.

7. Training

To activate its employees, the company leadership is set the task of offering them both training sessions and information on how the Wiki should be used: The employees need to become familiar with the user interface as well as with the individual functions of the Wiki.

To accomplish this, the company has several options. Several have shown themselves to be useful in practice. For example, the company could post (semi-) permanent information to the Wiki, which requires the employees to locate and retrieve such information on their own; such information could include operating manuals, screencasts, and videos in the Wiki or on the Internet that demonstrate the using of the Wiki. Another excellent set of options is that of training sessions offered by third parties or the in-house Wiki evangelist, during which employees are acquainted in a “hands-on” manner to certain functions.

The fundamental goal is that the employees can work with the Wiki just as naturally and assuredly as they do with, for example, e-mail. The users’ individual abilities and expectations naturally play an important role: In our experience, there are employees who quickly acquaint themselves with and teach themselves how to use the Wiki, learn the software by using it, and already after a short period of time have the feeling that they can work with the software. Some employees, on the other hand, need personal contact with experienced Wiki users and quite possibly a permanent contact person who offers first level support (in other words, first aid on the telephone and through conversations).

It is always important to ensure that every employee has various measures available and can take up those offers that will best help him or her to become familiar with and learn how to use the Wiki.

8. Separating the Wiki from other systems

When the Wiki is being rolled out to increasing numbers of employees, numerous use cases have proven themselves valuable in practice, as they considerably improve the work as well as positively affect the organizational structure and company development. We recommend that as soon as innovative ways are found to, for example, replace e-mail and paper documents with a controlled and transparent Wiki process, that obsolete, suboptimal working methods should be increasingly removed from the daily business. If such cases are identified, then they should be formulated into directives that require the use of the Wiki in those use cases. These binding directives should be accompanied as well by content information, reasons, and discourse. In fact, there are often practical and good reasons for the retaining of certain current practices, for holding on to the status quo. These must be examined, analyzed, and dealt with.

A further good idea in this context is the development of binding communications examples within the company, in other words of use cases, in which it needs to be clearly defined which information should be put in the Wiki and which processes should be depicted using other communications tools: When do you use the Wiki? When do you send an e-mail? When do you work with a document management system? Especially for critical cases that could be depicted not only in the Wiki but also with the help of other already extant systems, clear rules need to be defined regarding when which system should be used, taking into account the framework of the organizational considerations.

9. The meaning of professional layout

From an organizational perspective, it is just as important that the Wiki has a professional layout and is not implemented using the standard, “out of the box” version. The company demands from its employees that they store their most valuable capital – their knowledge – in the Wiki as well as make this knowledge centrally available to other employees. With this in mind, it is of great importance that a corresponding environment in the form of a qualitatively valuable solution be created, an environment within which the employees are happy to act. Employees are much more likely to identify with such a system, one that seems trustworthy and integrated, than one that seems to irritate the company Intranet like a foreign substance.

In addition to this, the Wiki layout is an important organizational component, because a high-value solution is politically symbolic within the company: The company leadership is underlining the meaning of the Wiki by investing in a layout incorporating its corporate design, thus signaling that the leadership believes in the system and views it as a central, and centrally important, platform.

Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us. Further information on this topic can be found on our special page on enterprise wikis (German).

Read this article in German.

An enterprise Wiki is not only a new technology for many employees (at least within the company environment); it also requires a change in the normal communication- and collaboration patterns throughout the entire company. Through our experiences with dozens of company Wiki projects, we know that the successful introduction of a Wiki usually depends upon three factors: technology; organization; and culture. This article – the first of three articles on this topic – is dedicated to the challenges of technology.

Technological aspects are often overestimated

Generally speaking, many companies overestimate the influence of the technology during the introduction phase of the Wiki. This overestimation is primarily due to the fact that many companies wrestle intensively and almost exclusively with the question of technology. In our experience, however, these technology factors are only about one-third of the equation for a successful Wiki introduction. Nevertheless, in regards to technology, companies must still implement a few very important prerequisites.

1. Choosing the correct Wiki software

The choosing and implementing of the software is a cornerstone of any Wiki project. Companies need to correctly implement the technological components before cultural or organizational aspects can be fully considered. The evaluation process requires the answering of a number of central questions: Which fully mature Wiki systems for enterprise use are available and which one is the best one for the depicting of your company’s business processes? Should your company rely on open source technologies such as Foswiki or should you choose a fully developed commercial solution like Confluence? Which weaknesses and strengths are implicit in these solutions regarding their adaptability (i.e. plugins)? Which interfaces are available for connecting to other systems? Is an LDAP connection – and thus a single sign-on solution – possible?

The focus of the evaluation is on the company’s requirements as well as on the question of which tasks the employees should be able to perform using the Wiki. The features of a particular technology should in some way be needed if a technology is to be successful within a company. Admittedly, our project experience has shown that some companies choose software even without just such a concrete need for that particular software; in such a situation, much energy must be invested after the fact to adapt standard solutions to the actual requirements of the company – often unsuccessfully. One study by Jakob Nielsen confirms that the prerequisite for the successful introduction of a software tool is the actual existing need for that tool:

A uniform finding across all of our case studies is that organizations are successful with social media and collaboration technologies only when the tools are designed to solve an identified business need. Different companies have different priorities and use different forms of internal communication; not every company needs every tool. Although picking the tool to support the need sounds obvious, it runs contrary to the technology fetishism that characterizes much talk about the latest Internet fads.

An intensive evaluation, for example in the form of strategy workshops with an experienced Wiki service provider, is the best way to evaluate Wiki software regarding the above factors.

2. System operation

Operating on a computer
There are three options for the operation of Wiki software. The simplest solution is having the system run locally on a PC at the company. This is sometimes a very sensible option, especially for a test phase with very few users during an initial evaluation. If, however, the classic functions such as collaboration are required, then this alternative is naturally not going to lead to the desired results, as the Wiki is only in operation when the corresponding computer is up and running; in addition, it is unlikely to be accessible from PCs outside of the work environment.

Third-party hosting
One established course of action is to enlist a third-party hosting service. These are typically service providers that support your company during the Wiki project and also provide hosting services. The disadvantage of this choice is that the Wiki is being managed outside of your internal systems; in other words, it is externally accessible, which is especially problematic from a political perspective: Many customers prefer to operate systems within their company, the primary purpose of this being to keep their data within the company. Still, many companies are reconsidering this concern in light of the current trend towards cloud computing, and over the next few years more and more companies will try to outsource their hosting activities.

Internal operation
Nonetheless, for most companies it goes without saying that they will operate a Wiki within their own company infrastructure. This third possibility is, however, the most difficult as well as the most expensive, since the company needs the corresponding know-how (i.e. a systems administrator and security plan) as well as the proper infrastructure (i.e. hardware or a virtual system on which the Wiki can run). Still, this alternative remains in many ways the most popular.

3. Technology infrastructure in the company

The technological component also touches on a company’s overall technology infrastructure. Some companies already have a problem when it comes to the choice of browser, as Internet Explorer 6 is still used in many companies. However, Internet Explorer 6 does not allow many of the functionalities offered by a Wiki software package.

In most smaller companies, the users are, admittedly, often already using more modern browsers such as Internet Explorer 7 or 8 or Firefox, but at many companies where employees do not have the chance to influence what software they use, thousands of users still work with outdated browsers. This is indeed a dilemma, because in this case the incomplete infrastructure can often be correlated with not only a lack of flexibility but also the missing willpower necessary to change the situation.

For the medium-term this problem will surely prove irrelevant, but at present this component is still extremely relevant, and many companies are being confronted with the fact that their state-of-the-art Wiki system cannot be completely utilized due to technical bottlenecks.

4. Integration and single sign-on

Also important for the acceptance of the Wiki is its integration within an existing sign-on server; the best-case scenario for this would be a single sign-on solution without any additional sign-on requirement. Employees find it very distracting when a system requires separate access procedures, which can greatly complicate the introduction of the Wiki. The Wiki should be imbedded into the existing infrastructure in order to raise the chances of its being accepted, especially in those cases when there are multiple existing systems for which a unified login or even a single sign-on solution has already been established

5. The position of the Wiki software in relationship to other systems

There are two interesting aspects to consider regarding the position of the Wiki software in relation to other systems:

a) Should there be gateways for the exchanging of data between the Wiki and already existing systems? For example, should it be possible to transfer data from a business intelligence system into the Wiki? To depict it in the Wiki? Should it be possible to transfer data from the Wiki into other systems?

b) Is there an existing portal solution into which the Wiki should be integrated, or will the Wiki be available separately using a URL? If the first is the case, then other questions must be raised; for example, does this influence in any way the layout, since the Wiki might then have to be adjusted to fit the existing portal solution due to the layout template.

These questions need to be answered, and technical solutions need to be found.

6. Evaluation of Plugins

There are a multitude of plugins and expansions for the performing of specific tasks within modern Wiki systems. During the Wiki introduction phase companies need to evaluate these plugins as well as consider the extensions needed to run the Wiki software correctly and utilize it to the fullest extent.

More than anything else, expansions such as a WebDAV plugin are powerful solutions. Such plugins make it possible to use a Wiki server like a local computer system in the company network or to use the Wiki just like other distributed networked drives – in other words, to create a framework that allows employees to save their work directly to the Wiki instead of on one of those distributed networked drives; the Wiki is then – just like any other drive – available, for example, when using Windows Explorer. The difference is that it is also available using browsing software.

Functionality like this has extremely high potential, but it also requires a high level of client-side configuration. The necessary know-how as well as the corresponding capabilities must be organized. Such functions are unusable without a systems administrator and corresponding configuration rights.

Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us. Further information on this topic can be found on our special page on enterprise wikis (German).

Fakt ist: Plugins machen Wikis erst zu richtigen Firmenwikis. Und die verfügbaren Erweiterungen für eine Wiki-Software müssen auf Ausgereiftheit, Stabilität und Qualität geprüft werden. Sehen wir uns elf wichtige Plugins für das kommerzielle Firmenwiki Confluence an und stellen diesen gegenüber, wie das Open-Source-System Foswiki diese Herausforderungen angeht.

1. Office Connector

• Der Office Connector ermöglicht das Importieren, Einbinden und Bearbeiten von Word-Dokumenten, Excel-Tabellen, PowerPoint-Präsentationen und Open-Office-Dokumenten in Confluence.
• Confluence-Seiten sind aus MS Office oder Open Office heraus editierbar.
• Große Dokumente können in viele Confluence-Dokumente aufgeteilt werden.

Das vermag Foswiki in dieser Form nicht abzubilden. Inhalte aus MS Office und Open Office können nur über Umwege in Foswiki eingebracht werden, z.B. über das Word2Wiki-Makro. Allerdings findet sich auf Foswiki.org ein Topic zum Thema Office Connector, woraus zu schließen ist, dass eine mittelfristige Lösung angedacht ist.

2. WebDAV-Plugin

• Das Plugin ermöglicht den direkten Zugriff auf Dateien auf dem lokalen System aus Confluence heraus.
• Anhänge in Confluence können bearbeitet und direkt in Confluence gespeichert werden.
• Anhänge sind per Drag & Drop integrierbar.

Es ist durchaus möglich, Foswiki als Netzlaufwerk freizugeben. Allerdings wäre dies eher ein Workaround. Dateien einfach innerhalb des Wikis zu nutzen, funktioniert jedenfalls nicht.

3. Widget Connector

• Inhalte von Websites können in Confluence-Pages eingebunden werden.
• Videos oder Foto-Slideshows aus entsprechenden Portalen sind auf Confluence-Seiten direkt abspielbar.
• Es ist möglich, Feeds aus Twitter und Co. einzubinden.

Diese Funktionalitäten kann Foswiki in der Form derzeit nicht vollständig abbilden. Immerhin: Mit dem Media-Plugin können angehängte Flash- oder Quicktime-Filme eingebunden werden. Weiterhin ermöglicht es ein JavaScript Code Snippet, bspw. YouTube-Filme einzubinden.

4. SQL-Plugin

• Inhalte können aus einer Datenbank ausgelesen werden (u.a. Oracle).
• Eine Verbindung mit dem Chart-Plugin ist möglich.
• Die Aktualisierung funktioniert dynamisch.

Foswiki bietet hierfür das Database-Plugin an.

5. Label-Management-Plugin

• Es wird eine Übersicht der Seiten eines Spaces und deren Labels (also: Tags) generiert.
• Mit einem Klick können einer Seite und den Tochterseiten Labels hinzugefügt werden.
• Labels können einen unterschiedlichen Status erhalten und Tochterseiten z.B. automatisch die Labels der Elternseite zugewiesen bekommen.

Hier muss Foswiki derzeit weitgehend passen. Einen Anfang macht immerhin das TagMe-Plugin, das aber längst nicht den Funktionsumfang der entsprechenden Confluence-Erweiterung hat.

6. Metadata-Plugin

• Mit diesem Plugin können Spaces Metadaten hinzugefügt werden. Das umfasst z.B. Metadaten für Nutzer, Anhänge etc.
• Zudem sind Spaces hierarchisch strukturierbar.
• Es ist möglich, entsprechende Reports in unterschiedlichen Darstellungen zu generieren

Diese Funktionalitäten können in Foswiki über die Meta-Daten ebenfalls ordentlich abgebildet werden.

7. Gliffy-Plugin

• Das Flash-basierte Web-Tool Gliffy erlaubt das Erstellen von Diagrammen wie Flowcharts, Wireframes, UML-Diagrammen, Netzwerk-Diagrammen etc.
• Das kommerzielle Plugin ermöglicht die vollständige Integration von Gliffy-Diagrammen in Confluence-Seiten.
• Diagramme können aus Confluence heraus bearbeitet werden.

Die Abbildung von Diagrammen ist in Foswiki nur in rudimentärer Form mit dem Flowchart-Plugin und dem DirectedGraph-Plugin möglich.

8. Dynamic Task List

• In Confluence-Seiten sind mit wenigen Klicks To-do-Listen integrierbar.
• Die Übersichtsliste mit Fortschrittsanzeige wird dynamisch aktualisiert.
• Es wird aufgezeichnet, wer eine Aufgabe abgeschlossen hat

Eine ähnliche Funktionalität bietet Foswiki mit dem ActionTracker-Plugin.

9. TaskDock

• Das kommerzielle Plugin TaskDock ermöglicht in Confluence ein Aufgabenmanagement im Kleinen (Planung und Zuweisung von Aufgaben, Statusinformationen, Überwachung, Aktivitätsstrom, nachträgliche Modifikation etc.).
• Aufgaben sind als allgemein oder seitenspezifisch (Seite kommentieren, Seite erweitern, Anhang hinzufügen) definierbar.
• Aufgabenspezifische Aktionen durch einen Bearbeiter werden automatisch erkannt (Fertigstellungs-Abfrage).
• TaskDock bietet verschiedene Auswertungsfunktionen.
• Eine JIRA-Integration ist geplant.

Foswiki kann solche Funktionalitäten nicht abbilden.

10. Gallery-Plugin

• Angehängte Bilder werden im Wiki-Dokument als Thumbnails dargestellt und per Klick vergrößert.
• Es sind Slideshows der angehängten Bilder integrierbar.

Für Foswiki steht das Gallery-Plugin zur Verfügung, das ähnliche Features bietet.

11. Chart-Plugins

• Das Plugin ermöglicht die Erstellung von Kreis-, Linien-, Balken- und Flächendiagrammen in Confluence-Dokumenten.
• Mit einem zusätzlichen Plugin ist die Integration von Gantt-Charts möglich (Gantt-Chart-Plugin).
• Via Chart-from-Table-Plugin können zudem Charts aus Tabellen oder anderen externen Quellen generiert werden.

Auch für Foswiki gibt es ein Chart-Plugin mit ähnlichen Möglichkeiten. Im Vergleich zu Confluence ist das Anlegen von Charts jedoch komplizierter und die Darstellung optisch weniger ansprechend.

Vergleich Äpfel mit Birnen? Nein!

Unternehmen, die noch vor der Entscheidung über die Einführung einer Wiki-Software stehen, empfehlen wir, keine Abstriche zu machen und sich gründlich und intensiv mit den Erweiterungen der zu evaluierenden Systeme zu beschäftigen: Ihre Ausgereiftheit und Qualität sind mitentscheidend dafür, ob das Wiki sich als dauerhafte Lösung erfolgreich etablieren kann.

Ob dies ein Vergleich zwischen Äpfeln und Birnen ist? Foswiki und die zugehörigen Plugins sind ja Open Source und werden von einer sehr engagierten Community ehrenamtlich weiterentwickelt. Und zweifellos ist Foswiki auch eine sehr ausgereifte, mächtige Wiki-Software. Confluence hingegen ist ein kommerzielles Sytem mit ganz anderen Voraussetzungen.

Dennoch ist die Antwort: Nein. Für Unternehmen zählt nämlich nur die Frage:

Kann eine Software meine Bedürfnisse erfüllen und bildet sie meine Anforderungen an ein Firmenwiki ab?

An diesen Ansprüchen müssen sich alle verfügbaren, ausgereiften Systeme nun einmal messen lassen, ob kommerziell oder frei.

Haben Sie Fragen zu Firmenwikis? Planen Sie eine Wiki-Einführung oder benötigen Sie Unterstützung bei einem laufenden Projekt? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne, bitte sprechen Sie uns an. Weitere ausführliche Informationen zum Thema finden Sie auch auf unserer speziellen Seite über Firmenwikis.

Weiterführende Informationen

Firmenwikis: Stärken von Confluence im Vergleich zu MediaWiki und Foswiki
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen und Informationsquellen
Strategische Wikis und Unternehmenswikis im Tagesgeschäft: eine wichtige Unterscheidung
Wiki-Zusatzleistungen von //SEIBERT/MEDIA

Informationen für Mitarbeiter

Das Wiki soll Mitarbeiter entlasten und zu mehr Effizienz und Produktivität führen. Jede Information, die ein Mitarbeiter benötigt und die er zentral findet, ohne sich an einen Kollegen wenden zu müssen, leistet ihren Beitrag dazu:

• Mitarbeiterverzeichnis (Standort, Abteilung, Kontaktdaten, Telefonliste, Position, Aufgaben, Stellenbeschreibung, Zuständigkeiten …)
• administrative Formulare (Urlaubsantrag, Dienstreise, Spesenerstattung, Hinweise bei technischen Problemen am Arbeitsplatz …)
• grundsätzliche Informationen zur Belegschaft wie Organigramme, Organisationsstrukturen …
• Unternehmens-News (GL-News, Unternehmenserfolge, Umsatzzahlen, Marktentwicklungen, Ziele, Neuigkeiten, Veranstaltungen …)
• Anwesenheitslisten, Urlaubspläne, Krankmeldungen, Erreichbarkeit bei Abwesenheit …
• Betriebsvereinbarungen, Betriebsrats- und Gewerkschaftsinformationen, Tarifinformationen …
• Mitarbeiterzeitung, interner Newsletter …
• Regelungen für Überstunden, Resturlaub, Zeiterfassung, Urlaubsvertretungen,
• Informationen zu Aus- und Weiterbildung
• Shop-Angebote für Mitarbeiter, Sonderangebote, Personalkauf-News …
• Dokumentation von Personalveränderungen, Infos für neue Kollegen, Geburtstage …
• Bedienungsanleitungen für Telefonanlage etc., Notfallnummern
• Gesetzestexte, Rechtshilfe
• Beschaffungsanträge
• Schulungspräsentationen
• Schwarzes Brett

Informationen zu Prozessen

Ein funktionierendes, organisches Firmenwiki hat nicht nur das Potenzial, Mitarbeiter bei der täglichen Arbeit zu entlasten. Es hilft insbesondere auch dabei, Prozesse zu optimieren, Projekte schlanker und effizienter zu machen und die Kommunikation mit Kunden und Interessenten (wo angebracht und sinnvoll) zu automatisieren. Beispiele für Prozessinformationen im Wiki:

• allgemeine Bestimmungen zur Arbeitssicherheit, Sicherheitsmanagement, Notfallmanagement, Brandschutz, Richtlinien, Gesetze …
• allgemeine Prozessinformationen
• Projekt-Checklisten, Kapazitätsplanung, Projektauswertungen, Teams …
• Pflichtenhefte
• Kundeninformationen
• Lizenzen
• Vorgabedokumente
• Betriebsanweisungsdatenbank
• E-Mail-Vorlagen zur Beantwortung häufiger Kundenanfragen, Problemklärung, …
• Meeting-Organisation, Agendas, Meeting-Protokolle, Formulare …

Informationen über das und vom Unternehmen

Mithilfe des Firmenwikis haben Beteiligte jederzeit einen Überblick über Marketing-Aktivitäten, die Außenwahrnehmung des Unternehmens, die Struktur des eigenen Unternehmens oder Konzerns usw. Das Wiki ermöglicht einerseits die zentrale Steuerung und Auswertung der Außenkommunikation, andererseits sorgen Unternehmensinformationen im Wiki für Transparenz. Mögliche Wiki-Inhalte sind:

• Presseberichte, Pressespiegel
• Werbeaktivitäten, Außendarstellung, Kommunikationskanäle …
• Bilder, Logos, Corporate Design, Corporate Identity …
• Unternehmenspolitik (Ausrichtung, Ziele, Strategien, Mission, Richtlinien, Unternehmenspräsentationen …)
• Kontakte und Angebote im Hinblick auf Partnerunternehmen, Kooperationen
• Abteilungsinformationen
• Informationen über die Geschäftsführung

Produkt- und Leistungsinformationen

Durch die Dokumentation der eigenen Produkte und Leistungen im Wiki sind Mitarbeiter und Unternehmensführung immer auf dem aktuellen Stand über Neuentwicklungen, das eigene Portfolio und die im Unternehmen vorhandenen (und fehlenden) Fähigkeiten. Diese Inhalte sind nicht zuletzt auch wichtig für die Kundenkommunikation sowie die Entwicklung von Marketing-Strategien und können zudem effizient für die Befüllung von Kommunikationskanälen wie dem Corporate Weblog oder Twitter genutzt werden:

• Produktinformationen (Neuigkeiten, Beschreibungen, Inhaltsstoffe, Preise, Sortimentslisten …)
• Informationen über Dienstleistungen
• Markt- und Konkurrenzanalysen
• auszubauendes Unternehmens-Know-how, möglicher Ausbau des Leistungsportfolios bzw. Produktspektrums …

Diese Listen mit möglichen Inhalten lassen sich natürlich fortführen und die angeführten Beispiele sind natürlich exemplarisch. Grundsätzlich empfiehlt es sich, alle weiterführende Informationen, Dokumentationen, Konzepte und Wissen, das dauerhaft relevant ist, ausnahmslos im Wiki abzubilden. So wird eine organisch wachsende Wissensbasis geschaffen, die Mitarbeiter entlastet, Prozesse vereinfacht und beschleunigt und für mehr Effizienz und Produktivität im Unternehmen sorgt.

Haben Sie Fragen zu Firmenwikis? Planen Sie eine Wiki-Einführung oder benötigen Sie Unterstützung bei einem laufenden Projekt? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne, bitte sprechen Sie uns an. Weitere ausführliche Informationen zum Thema finden Sie auch auf unserer speziellen Seite über Firmenwikis.

Weiterführende Informationen

Firmenwikis: Im Wiki zählt Qualität vor Quantität – oder doch nicht?
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen und Informationsquellen
Strategische Wikis und Unternehmenswikis im Tagesgeschäft: eine wichtige Unterscheidung
Neue Wiki-Dokumente richtig anlegen: Wo und wie einsortieren?
Wiki-Zusatzleistungen von //SEIBERT/MEDIA

Interessante Informationen nicht nur für Atlassian-Kunden

Diese zweite Sitzung (einen Rückblick auf die erste Sendung finden Sie hier) richtet sich vor allem an Unternehmen, die Atlassian-Produkte wie Confluence oder JIRA bereits einsetzen oder die dabei sind, Firmenwikis oder Aufgabenmanagementsysteme zu evaluieren. Doch wir möchten auch Nutzer ansprechen, die einfach mal einen Einblick in die Politik und die Strategieentwicklung von Software-Herstellern erhalten möchten.

//SEIBERT/MEDIA ist offizieller deutscher Vertriebspartner von Atlassian. Dadurch haben wir intensiven Kontakt zu den Entwickler-Teams von Confluence und JIRA und können Ihnen aus erster Hand berichten. Unsere möglichen Präsentations- und Diskussionsthemen:

• Wo stehen die Atlassian-Produkte derzeit am Markt?
• Welche Strategie verfolgt Atlassian künftig?
• Welche Schwerpunkte setzt man bei der Weiterentwicklung von Confluence und JIRA?
• Welche Erkenntnisse und Herausforderungen haben sich aus Workshops ergeben?
• Was bedeuten Veränderungen und Erkenntnisse für Unternehmen, die Atlassian-Software einsetzen oder dies planen?
• Was sagen und wünschen Atlassian-Kunden?

Als Atlassian-Partner können wir Ihnen hier sicherlich Informationen geben, die über Presseerklärungen hinausgehen. Um Missverständnissen vorzubeugen: Diese Video-Session soll keine Marketing-Veranstaltung für Atlassian sein, sondern wir wollen Entwicklungen ggf. kritisch würdigen, Ihre Fragen diskutieren und beantworten und Ihnen einfach guten Kundenservice bieten. Und natürlich leiten wir Ihre Anmerkungen auch gerne an unsere Ansprechpartner bei Atlassian weiter. Also: Wenn Sie Atlassian-spezifische Fragen haben, über Atlassians Unternehmenspolitik auf dem Laufenden bleiben wollen oder Ihnen etwas unter den Nägeln brennt, sollten Sie um 10.30 Uhr dabei sein und sich einbringen.

Nehmen Sie teil – ein Klick genügt

Sie können ganz spontan sowie ohne Voranmeldung, ohne Verpflichtungen und ohne Kosten an dieser zweiten Video-Sitzung von //SEIBERT/MEDIA teilnehmen. Unter http://seibert.biz/live finden Sie dieses Fenster:

Mit einem Klick auf den Connect-Button sind Sie live dabei – Sie an Ihrem Schreibtisch, wir in Bild und Ton und im Echtzeit-Chat. Was Sie dafür brauchen? Einen Rechner mit Browser, Ton und Flash sowie 45 Minuten Zeit für ein in Sachen Unternehmenskommunikation hochinteressantes und relevantes Thema. Weiter nichts.

Klicken Sie sich also rein, wir sehen, hören und lesen uns ab 10.30 Uhr. Und wenn Sie selbst keine Zeit haben, haben wir natürlich nichts dagegen, wenn Sie Ihren Kollegen unsere Sendung empfehlen oder sich das Video zur Sitzung später in unserem öffentlichen Wiki anschauen.

Weitere Informationen

//SEIBERT/MEDIA bietet Live-Video-Sessions
Live-Video-Sessions von //SEIBERT/MEDIA jetzt regelmäßig (mit Zusammenfassung der ersten Sitzung und weiteren Terminen)

Zusammenarbeit per E-Mail

Von: Texter
An: Ansprechpartner 1 beim Kunden, Ansprechpartner 2 beim Kunden
CC: Projektmanager

Hallo, hiermit sende ich Ihnen die Texte für die Website, die wir erstellt haben, zur fachlichen Freigabe. Es handelt sich um die restlichen Inhalte für den Menüpunkt 2 und die Unterseiten. Ich freue mich auf Ihr Feedback!

Von: Ansprechpartner 1 beim Kunden
An: Texter, Ansprechpartner 2 beim Kunden

Hallo, ich habe alle Texte für die Menüpunkte 2.x.x fachlich geprüft, ergänzt und gebe sie hiermit frei zum Einpflegen.

Von: Texter
An: Projektmanager

Hi, prima: Der Kunde hat die Texte inhaltlich so freigegeben (siehe Anhänge).

Von: Projektmanager
An: Texter, Programmierer

Hi, super, dann sind wir ja soweit durch. @ Programmierer: Die gesammelten Werke sind im Anhang, Du kannst sie jetzt einpflegen. PS: Warum werde ich nie in CC gesetzt? ^^

Von: Ansprechpartner 2 beim Kunden
An: Texter, Ansprechpartner 1 beim Kunden

Hallo, leider bin ich erst jetzt dazu gekommen, noch kleine Ergänzungen in die Dokumente einzuarbeiten (Texte für die Seiten 2.1.2 und 2.3.1, siehe Anhang). So können wir die Texte nun veröffentlichen. Es fehlt aber der Text für den Punkt 2.3.3. Was ist damit?

Von: Texter
An: Ansprechpartner 2 beim Kunden, Ansprechpartner 1 beim Kunden
CC: Projektmanager

Hallo, der angesprochene Text für 2.3.3 wurde von uns schon ganz am Anfang als Probe-Artikel erstellt und mit Ihrer Kollegin abgestimmt. Er war eigentlich auch von Ihrer Kollegin freigegeben. Ich leite Ihnen diese E-Mail hier noch einmal weiter.

Von: Ansprechpartner 2 beim Kunden
An: Texter, Ansprechpartner 1 beim Kunden

Hallo, vielen Dank für die Info und die Weiterleitung. Ich habe auch hier in den Text für 2.3.3 noch zwei Details direkt eingearbeitet. Nun ist alles okay.

Von: Texter
An: Projektmanager

Hi, Du bist mal wieder nicht in CC gesetzt worden. In den Texten 2.x.x. und auch in dem Probetext 2.3.3 hat es noch Änderungen vom Kunden gegeben (siehe weitergeleitete E-Mail). Welchen Stand hast Du jetzt? Ich leite am besten den ganzen Schwung weiter …

An: Projektmanager
An: Texter, Programmierer

Hi, okay, danke. Nur haben wir jetzt hier eine freigegebene Überarbeitung von Herrn X und eine von Frau Y … Ich rufe am besten noch mal eben dort an.

Von: Programmierer
An: Projektmanager
CC: Texter

Hi, ich pflege gerade die Website-Inhalte für den Menüpunkt 2.x.x in Typo3 ein. Mir fehlt aber hier noch der Text für den Punkt 2.3.3.

Von: Projektmanager
An: Programmierer
CC: Texter

Hi, oh, den hast Du nicht? Der neu überarbeitete Text 2.3.3 war in einer separaten E-Mail. Ich leite sie Dir hier noch mal weiter.

Von: Texter
An: Programmierer
CC: Projektmanager

Hi, ich hatte das ganze aktualisierte und freigegebene Paket eigentlich dem PM geschickt. Ich leite Dir die E-Mail mit dem Text 2.3.3 nochmal weiter.

Von: Programmierer
An: Projektmanager, Texter

Hi, danke. Aber ich habe jetzt zwei 2.3.3-Dokumente, die inhaltlich nicht ganz übereinstimmen.

Von: Texter
An: Programmierer, Projektmanager

Ah, sorry, ich habe die falsche Version weitergeleitet. Im Anhang ist das richtige Dokument. Die müssten übereinstimmen …

Was sich fast wie der Ablauf einer Szene aus einer Screwball-Komödie liest, ist häufig Projektalltag und mitnichten witzig – es sei denn, man findet Ineffizienz und die damit einhergehende ausbaufähige Produktivität in Projekten erheiternd. Leider ist dieses Beispiel nicht erdacht, sondern so ähnlich ist in einem Web-Projekt die inhaltliche Abstimmung mit dem Kunden abgelaufen: Es werden Zeit und Ressourcen vergeudet (und damit Kosten verursacht), weil Kommunikation und Zusammenarbeit dezentral stattfinden.

Stellen wir uns nun vor, für diese Koordinations- und Abstimmungsprozesse wäre ein Extranet auf Wiki-Basis verwendet worden, wie es auch //SEIBERT/MEDIA seinen Kunden anbietet.

Zusammenarbeit auf Wiki-Basis

Von: Texter
An: Ansprechpartner 1 beim Kunden, Ansprechpartner 2 beim Kunden
CC: Projektmanager

Hallo, alle nun erstellen Textvorschläge für die Seiten 2.x.x habe ich im Extranet-Bereich auf Wiki-Basis hinterlegt: <Wiki-Link>. Ich bitte Sie und Ihre Kollegen, Ergänzungen direkt dort vorzunehmen: Klicken  Sie einfach auf „Bearbeiten“ und nach Ihren Eingaben auf „Speichern“. Ihre Extranet-Zugangsdaten haben Sie ja separat erhalten. Wir freuen uns sehr auf Ihre Mitwirkung!

Von: Ansprechpartner 1 beim Kunden
An: Texter, Ansprechpartner 2 beim Kunden

Hallo, ich habe alle Texte für die Menüpunkte 2.x.x fachlich geprüft, im Extranet-Wiki ergänzt und gebe sie hiermit frei zum Einpflegen.

Von: Texter
An: Projektmanager

Hi, prima: Der Kunde hat die Texte inhaltlich so freigegeben: <Wiki-Link>.

Von: Projektmanager
An: Texter, Programmierer

Hi, ich habe auch schon per RSS-Benachrichtigung mitbekommen, dass der Kunde im Extranet aktiv war. Super, dann sind wir ja soweit durch. @ Programmierer: Die gesammelten Werke sind hier: <Wiki-Link>. Du kannst sie jetzt einpflegen.

Von: Ansprechpartner 2 beim Kunden
An: Texter, Ansprechpartner 1 beim Kunden

Hallo, leider bin ich erst jetzt dazu gekommen, noch kleine Ergänzungen in die Dokumente einzuarbeiten (Texte für die Seiten 2.1.2, 2.3.1 und 2.3.3, siehe <Wiki-Link>). So können wir die Texte nun veröffentlichen.

Von: Texter
An: Projektmanager

Hi, Du bist mal wieder nicht in CC gesetzt worden. Es hat noch Änderungen bei den Texten gegeben: <Wiki-Link>. Damit dürfte nun alles amtlich sein.

Von: Projektmanager
An: Programmierer
CC: Texter

Hi, es hat im Extranet-Wiki noch Aktualisierungen seitens des Kunden gegeben (2.1.2, 2.3.1 und 2.3.3). Kannst Du die bitte noch berücksichtigen?

Von: Programmierer
An: Projektmanager
CC: Texter

Hi, klar, kein Problem.

Wir sehen: Durch die Kollaboration im Wiki nimmt das E-Mail-Aufkommen rapide ab, Abstimmungsschwierigkeiten werden minimiert, Dokumente im Wiki sind auf dem aktuellen Stand und einfach zentral abrufbar.

Was ein Extranet auf Wiki-Basis leisten kann

Ein ausgereiftes Firmenwiki hat eine sehr fein justierbare Rechtevergabe: Für jeden Kunden kann ein eigener Wiki-Bereich angelegt werden, den auch nur dieser Kunde sieht und auf den nur der Kunde und die projektbeteiligten Mitarbeiter zugreifen können.

Der grundsätzliche Vorteil eines Wikis ist ja, dass mehrere Personen unabhängig voneinander, aber gemeinsam an Dokumenten arbeiten können: Inhalte werden direkt im Wiki kommentiert und weiter ausgearbeitet, sie stehen zentral und in der aktuellen Fassung zur Verfügung. Das geschieht, ohne in vielen Schritten ineffizient per E-Mail Dateien hin- und herschicken zu müssen und ohne dass Dokumente in verschiedenen Iterationsstufen verstreut in Postfächern auflaufen.

Und die gemeinsame Ausarbeitung und Qualitätssicherung von Inhalten ist nur ein Anwendungsfall von vielen: In einem Extranet auf Wiki-Basis kann unkompliziert eine Vielzahl von Informationen bereitgestellt werden: aktuelle Berichte über den Projektstatus, Rechnungen und Leistungsnachweise, Übersichten zum Budget-Status, Verlaufsgrafiken für den Budget-Verbrauch und Rechnungshöhen usw. So sind Kunden nicht nur über den Projektstand jederzeit im Bilde, sondern haben auch Budgets und Zeitpläne stets im Blick.

Der Extranet-Service ist für //SEIBERT/MEDIA Kundenservice, wir bieten Kunden die Zusammenarbeit im Extranet-Wiki kostenlos an. Schauen Sie als Kunde doch mal wieder in Ihren persönlichen Extranet-Bereich rein.

Und natürlich helfen wir Ihrem Unternehmen auch dabei, selbst ein Firmenwiki im Intranet und/oder ein Extranet-Wiki aufzubauen und zu etablieren – im Sinne von mehr Effizienz in der Projektarbeit, höherer Produktivität und mehr Transparenz. Bitte sprechen Sie uns an.

Weiterführende Informationen

Kundenservice und Transparenz: Das Kunden-Extranet von //SEIBERT/MEDIA (Vodcast)
E-Mail-Missbrauch: Der E-Mail-Anhang ist oft die falsche Anwendung von Technologie
Unsere spezielle Internet-Seite mit ausführlichen Informationen über Firmenwikis

Aus Dutzenden Firmenwiki-Projekten wissen wir, dass eine erfolgreiche Wiki-Einführung im Unternehmen erfahrungsgemäß von drei Faktoren abhängt: der technologischen, der organisatorischen und der kulturellen Komponente. Nachdem im ersten Beitrag zum Thema auf die technologischen Anforderungen und im zweiten Artikel auf den Erfolgsfaktor Organisation eingegangen worden ist, stehen nun unternehmenskulturelle Aspekte bei der Wiki-Einführung im Blickpunkt.

Wiki-Einführung: Unternehmenskultur muss sich wandeln

Mit der Etablierung eines Wikis geht zwangsläufig ein Wandel der kommunikativen Gewohnheiten im Unternehmen einher. Im Vergleich zu technologischen und organisatorischen Aspekten spielt die unternehmenskulturelle Komponente bei der Wiki-Einführung zwar meist eine eher geringere Rolle, doch bestimmte Widerstände können den Projekterfolg auch in diesem Zusammenhang beeinträchtigen.

1. Wandel des Kommunikationsansatzes im Unternehmen

Mit der Etablierung eines Wikis wandelt sich der Kommunikationsansatz innerhalb eines Unternehmens. Grundsätzlich stößt man in Unternehmen auf den sogenannten Top-down-Ansatz: Das Management definiert Themen und kommuniziert diese ganz bewusst an die Mitarbeiter. Mit einem Wiki ändert sich dies, denn Mitarbeiter können selbst Themen produzieren, indem sie neue Dokumente im Wiki anlegen und dadurch Aufmerksamkeit schaffen sowie bestimmte Themen auch eigenständig vorantreiben.

Dies fürchten viele Unternehmensführungsmitglieder und sind skeptisch, dass der gewohnte Top-down-Ansatz zwar nicht durch einen Bottom-up-„Approach“, aber doch durch einen kommunikativen Kreislauf abgelöst werden könnte. Es ist oft nötig, das Management wirklich davon zu überzeugen, die Steuerung der Kommunikation ein Stück weit aus der Hand zu geben.

Aus Mitarbeitersicht kann wiederum kritisch sein, dass Mitarbeiter sich scheuen, ihr Wissen und damit ihr wertvollstes Gut zu teilen. Die Projekterfahrung zeigt, dass manche Mitarbeiter in diesem Zusammenhang einen Verlust von Macht oder auch einen Verlust an Wert für das Unternehmen befürchten.

Im Zuge der Wiki-Einführung müssen solche Personen davon überzeugt werden, dass dies keineswegs der Fall ist. Tatsächlich tritt teilweise sogar genau das Gegenteil von dem ein, was viele Mitarbeiter zunächst befürchten: Durch die Abbildung von Teilen ihrer Expertise werden viele Nutzer nämlich noch wichtiger, können sich durch die aktive Teilnahme stärker positionieren und sich noch deutlicher als Fachleute profilieren. Dies trifft auf immerhin fast ein Drittel der Teilnehmer zu, wie Majchrzak, Wagner und Yates in ihrer Studie Corporate wiki users: results of a survey (Odense 2006) festgestellt haben: 29% der befragten Wiki-Nutzer geben an, durch das Teilen von Wissen mehr Respekt im Unternehmen erworben zu haben, 28% geben an, ihre Reputation im Unternehmen wäre gestiegen.

2. Bildung von Akzeptanz auf Entscheider-Ebene

In vielen Wiki-Projekten, gerade in größeren Unternehmen, ist das Phänomen zu beobachten, dass diejenigen Personen, die über eine Wiki-Einführung entscheiden, nicht diejenigen sind, die das Werkzeug später nutzen. Es gibt Entscheider, die dem Vorschlag einer Wiki-Einführung entgegnen: „Ich werde nicht damit arbeiten und deswegen brauche ich es auch nicht.“

Somit ist die Entscheidung über ein Firmenwiki auch eine kulturelle Herausforderung, denn den entscheidungsbefugten Personen muss deutlich gemacht werden, dass es wichtig ist, dass sie eine Umgebung schaffen, in der die Mitarbeiter produktiv arbeiten können, und dass es nicht ihre Aufgabe ist, für die Einführung von Tools zu sorgen, die ihnen persönlich helfen. Die Aufgabe eines High-Level-Managers besteht vielmehr grundsätzlich darin, den hierarchisch untergeordneten Mitarbeitern Werkzeuge zur Verfügung stellen, mit der diese selbst ihre Wertschätzung im Unternehmen steigern können.

3. Gegensteuern gegen Innovationsskepsis

Im Rahmen der kulturellen Komponente ist es darüber hinaus wichtig zu evaluieren, ob es sich um ein Unternehmen handelt, das Innovationen und neue Technologien schnell aufnimmt oder nicht. In konservativen Unternehmenskulturen wird neuen Technologien – selbst wenn sie erwiesenermaßen zu Prozessoptimierungen führen – zunächst Skepsis und nicht selten Pauschalkritik entgegengebracht.

Ist dies der Fall und herrscht in dem Unternehmen, in dem ein Wiki eingeführt werden soll, eine kritische, konservative Unternehmenskultur vor, müssen auch umfassendere organisatorische Maßnahmen ergriffen, mehr Wiki-Marketing betrieben, Wiki-Use-Cases stärker reglementiert werden usw., um das Wiki-Konzept trotz der Ablehnungshaltung durchzusetzen.

Haben Sie Fragen zur Wiki-Einführung? Oder benötigen Sie Unterstützung bei einem laufenden Projekt? Weitere Informationen zu Enterprise Wikis und ein Kontaktformular für Ihre Anfrage finden Sie auf unserer speziellen Seite zum Thema Firmenwikis.

Weiterführende Informationen

Strategische Firmenwikis und Unternehmenswikis im Tagesgeschäft: Eine wichtige Unterscheidung
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Hofläden, Supermärkte und Firmenwikis: „Bitte klingeln“ und „Herzlich willkommen“
Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann

Aus Dutzenden Firmenwiki-Projekten wissen wir, dass eine erfolgreiche Wiki-Einführung im Unternehmen erfahrungsgemäß von drei Faktoren abhängt: der technologischen, der organisatorischen und der kulturellen Komponente. Im ersten Beitrag zum Thema sind wir auf technologische Anforderungen eingegangen. In diesem Artikel stehen nun organisatorische Aspekte im Mittelpunkt, die die größte Herausforderung im Rahmen eines professionellen und erfolgversprechenden Wiki-Projekts bilden.

Organisation: Der kritische Faktor bei der Wiki-Einführung

Die organisatorische Komponente trägt unserer Erfahrung nach zu etwa 50% zum Erfolg einer Wiki-Einführung bei. Es sind nicht etwa technologische Aspekte, die Schwierigkeiten bereiten. Unternehmen, die Wikis nutzen, führen fast ausschließlich organisatorische Probleme an, die die Etablierung behindern, wie Henriksson, Mikkonen und Vadén in ihrer Studie „Experiences of Wiki use in Finnish companies“ (Tampere 2008) feststellen. (Die Ergebnisse haben wir in unserem Blog-Artikel Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf? zusammengefasst.)

Demnach beklagen Firmen in erster Linie, dass zu wenige Mitarbeiter aktiv und häufig Informationen ins Wiki stellen, dass den Teilnehmern der Nutzen des Wikis nicht schnell genug klar wird, und dass es schwierig sei, Teilnehmer für das Wiki zu motivieren. Dementsprechend umfassend und nachhaltig müssen die organisatorischen Maßnahmen im Rahmen der Wiki-Einführung sein.

1. Aufgabendefinition

Das erste Element der organisatorischen Komponente ist die Frage, welche Aufgaben mit dem Wiki erledigt werden sollen, die Frage also nach der Zielsetzung des Wikis: Warum wird ein Wiki eingeführt? Welche Aufgaben gibt es, die die Mitarbeiter mit dem Wiki erledigen sollen?

Hier müssen schon von vornherein bestimmte Anwendungsfälle und die konkrete Nutzung des Wikis in diesen Use Cases definiert werden. Für die Use Cases, oder Anwendungsfälle, sollte man zu Beginn eine relativ enge Definition für die Ausrichtung des Wikis wählen, gleichzeitig und idealerweise aber auch eine umfangreiche Perspektive offen lassen. „Think Big, Start Small, Act Now“ heißt hier häufig eine sinnvolle Empfehlung, die Phyllis Piotrow geprägt hat (Piotrow, Phyllis: Keynote Conversation „Strategic Partnerships“, Entertainment-Education Conference, USA 2000). 

2. Strong Backing from the Top

Ein zweites Element innerhalb der organisatorischen Komponente ist das sogenannten „Strong Backing from the Top“: Die mangelnde Beteiligung der Geschäftsführung ist mit einem hohen Risiko verbunden, denn ohne die Unterstützung „von oben“ wird sich ein Software-Werkzeug schwer auf breiter Ebene durchsetzen können. Immer wieder setzen sich Wikis zwar in einzelnen Abteilungen durch, doch ohne Förderung seitens des Managements wird ein unternehmensweiter Roll-out kaum möglich sein.

Es ist wichtig, dass die Einführung eines Wikis von der Unternehmensleitung uneingeschränkt unterstützt wird und das Management auch die nötigen Ressourcen und finanziellen Mittel zur Verfügung stellt.

3. Verantwortung für das Wiki

Das dritte Element umfasst die Verantwortung für das Wiki und die zeitlichen Ressourcen, um mit dem Wiki arbeiten zu können. Denn es ist enorm wichtig, dass jemand die Verantwortung für das Wiki übernimmt und die Einführung aktiv vorantreibt. Das kleine Team um diese Person befasst sich mit Content-Integration, erfüllt klassische, sogenannte Wiki-Gardening-Funktionen, installiert also neue Plugins, löst spezielle Anwendungsfälle, stellt Ansprechpartner etc. Wiki-Fachleute sprechen hier von einem sogenannten Wiki-Evangelist und einem Team aus Wiki-Champions, die gerade in der Einführungsphase wertvolle Unterstützung bieten: Im Rahmen des (bei der Einführung üblichen) Wiki-Pilot-Projekts betreut dieses Team eine größere Gruppe von Mitarbeitern, die mit dem Wiki arbeiten, und übernimmt auch später Verantwortung.

Viele Unternehmen unterschätzen hier die anfallenden Ressourcen und den nötigen, erheblichen Zeitaufwand, der bei der Erledigung dieser Aufgaben anfällt. Der Unterschied zwischen dem Wiki-Champion und dem regulären Projektteam-Mitglied besteht darin, dass der Wiki-Champion eben deutlich mehr Zeit in das Wiki investiert und deutlich mehr Zeit aufbringt, um Aufgaben im Wiki zu erledigen und First-Level-Support anzubieten.

4. Richtige Zusammensetzung des Wiki-Pilot-Projekts

Als Wiki-Pilot-Projekt bezeichnet man die Phase, in der einige Mitarbeiter des Unternehmens (häufig in Zusammenarbeit mit einem erfahrenen Wiki-Fachmann) die Strukturierung und Etablierung der ersten Inhalte übernehmen. In dieser Phase geht es darum, möglichst viele relevante Inhalte strukturiert in das Wiki einzubringen, damit es interessant und attraktiv für alle Mitarbeiter wird.

Stewart Mader spricht sich in diesem Zusammenhang dafür aus, nicht ausschließlich sogenannte Early Adopters einzubinden, also Mitarbeiter, die bekanntermaßen neuen Arbeitsweisen und Technologien sehr offen gegenüber stehen, sondern auch weniger Technologie-affine und eher skeptische Nutzer einzubeziehen, damit die Teilnehmer am Wiki-Pilot-Projekt einen möglichst repräsentativen Querschnitt des Unternehmens abbilden:

What’s critically important to the usefulness of the pilot is how you structure the pilot participants. If you only involve hard-core early adopters, then of course it won’t be representative of the organization as a whole. However, if you construct a pilot that involves people from several key areas of the organization [...] and those people understand going into the pilot that they’re getting a chance to set up their uses before everyone else in exchange for their help and patience in finding and fixing technical problems, you’ll get a group that will solidly support the project once it’s opened up for large-scale use.

Das wichtigste Ziel des Wiki-Piloten ist dabei nicht eine umfassende Abbildung des Unternehmenswissens in dem neuen digitalen Informationssystem. Zum einen wäre diese viel zu aufwändig, zum anderen wäre es ein kaum zu realisierendes Unterfangen, einige wenige Mitarbeiter das Wissen aller Mitarbeiter digitalisieren und aufbereiten lassen zu wollen. Das Ziel des Wiki-Piloten besteht vielmehr darin, strahlende und erfolgreiche Beispiele für die Wiki-Nutzung zu etablieren.

5. Organisatorische Ausweitung

Wenn der Wiki-Pilot erfolgreich ist, setzt eine wichtige Mund-zu-Mund-Propaganda ein: Die entwickelten Best-Practice-Beispiele sprechen sich im Unternehmen herum, wobei Teilnehmern am Wiki-Piloten eine zentrale Rolle als Vermittler und Kommunikator zukommt.

Diese Mund-zu-Mund-Propaganda bildet die Grundlage für die Etablierung weiterer kleiner Pilot-Projekte in den einzelnen Unternehmensbereichen. Auch dort ist es wieder das Ziel, für den Bereich spezifische Best Practices mit dem Wiki umzusetzen, die allen Beteiligten zeigen, wie wertvoll ein Wiki im Tagesgeschäft sein kann. Dabei geht es indes nicht darum, das System möglichst schnell möglichst vielen Abteilungen aufzuzwingen, sondern darum, dafür zu sorgen, dass sich mehr und mehr Mitarbeiter für die Wiki-Idee begeistern und den richtigen Weg in die Wiki-Nutzung finden.

6. Roll-out an mehr und mehr Mitarbeiter und Wiki-Marketing

In der Phase des Roll-outs ist für die Mitarbeiteraktivierung in erster Linie bedeutsam, das Wiki bekannt zu machen und im Unternehmen zu kommunizieren, dass es ein Wiki gibt und dass es für bestimmte Anwendungsfälle genutzt werden soll. Die Projekterfahrung zeigt, dass Unternehmen es jedoch nicht bei der einmaligen Bekanntgabe belassen dürfen: Zumeist ist es nötig, sie ständig zu wiederholen und den Mitarbeitern das neue Werkzeug immer wieder ins Bewusstsein zu rufen.

Das ist die Aufgabe des Wiki-Marketings. Im Rahmen des Wiki-Marketings gibt es verschiedene Instrumente, die sich bewährt haben. Möglichkeiten sind Kugelschreiber mit einer Aufschrift wie „Ich schreib’s noch ins Wiki: www.wiki-name.de“, Aufsteller und Displays mit Informationen über das Wiki, eine Erwähnung im internen Newsletter, eine besondere Partizipation des Managements oder von Führungskräften im Wiki, um die Bedeutung des Systems zu demonstrieren, und weitere mehr.

Dabei ist nicht wichtig, wie viele Maßnahmen man ergreift, sondern dass das Wiki-Marketing vielmehr kontinuierlich und über einen längeren Zeitraum hinweg betrieben wird, um die Mitarbeiter für das Wiki und seinen Wert für das Unternehmen zu sensibilisieren.

In dieser Phase sollte das Unternehmen zudem diejenigen Mitarbeiter identifizieren, die dem Wiki bereits offen gegenüberstehen, und ihnen dabei helfen, Best Practices für die eigenen Bedürfnisse zu etablieren. Wenn sich das Wiki im Rahmen der Tagesgeschäftsprozesse als hilfreich erweist, steigen die Chancen auf eine Etablierung als erfolgreiches Wissensmanagement-System signifikant.

7. Schulung

Um Mitarbeiter zu aktivieren hat die Unternehmensführung die Aufgabe, ihnen Schulungen anzubieten und Informationen darüber an die Hand zu geben, wie das Wiki zu nutzen ist: Die Mitarbeiter müssen mit der Oberfläche und den einzelnen Funktionen des Wikis vertraut werden.

Hier hat das Unternehmen verschiedene Möglichkeiten. Als praxistauglich hat sich erwiesen, dauerhafte Informationen zur Verfügung zu stellen, die sich Mitarbeiter jedoch aktiv selbst beschaffen müssen, beispielsweise in Form von Anleitungen, Screencasts und Videos im Wiki oder im Internet, die die Bedienung des Wikis demonstrieren. Schulungen, die von Dritten oder dem Wiki-Evangelisten angeboten werden und in denen Mitarbeiter „hands-on“ mit bestimmten Funktionen vertraut gemacht werden, sind ebenfalls sinnvolle Maßnahmen.

Das grundsätzliche Ziel ist, dass die Mitarbeiter so selbstverständlich, natürlich und sicher mit dem Wiki umgehen können wie zum Beispiel mit E-Mails. Individuelle Fähigkeiten und Erwartungen der Nutzer spielen dabei freilich eine tragende Rolle: Erfahrungsgemäß gibt es Mitarbeiter, die sich rasch autodidaktisch mit dem Wiki vertraut machen, das System über die Nutzung kennenlernen und schon nach kurzer Zeit das Gefühl haben, mit der Software arbeiten zu können. Andere Mitarbeiter brauchen dagegen den persönlichen Kontakt zu erfahrenen Wiki-Nutzern und möglicherweise auch einen ständigen Ansprechpartner, der First-Level-Support (sozusagen erste Hilfe per Telefon und im Gespräch) anbietet.

Wichtig ist immer dafür zu sorgen, dass jeder Mitarbeiter verschiedene Maßnahmen zur Verfügung hat und diejenigen Angebote wahrnehmen kann, die ihm dabei helfen, das Wiki kennen und anwenden zu lernen.

8. Abgrenzung des Wikis gegenüber anderen Systemen

Wenn das Wiki an mehr und mehr Mitarbeiter ausgerollt wird, bewähren sich immer mehr Anwendungsfälle in der Praxis, da sie die Arbeit erheblich verbessern und sich positiv auf die Organisationsstruktur und die Unternehmensentwicklung auswirken. Sobald innovative Wege gefunden sind, um beispielsweise E-Mail und Papier durch einen kontrollierten und transparenten Wiki-Prozess zu ersetzen, empfehlen wir, obsolete, suboptimale Arbeitsmethoden nach und nach aus dem Tagesgeschäft zu verbannen. Sind solche Use Cases identifiziert, sollte in Vorgaben formuliert werden, dass die Nutzung des Wikis in diesen Anwendungsfällen zukünftig verbindlich ist. Zu diesen verbindlichen Anweisungen gehören allerdings inhaltliche Informationen, Begründungen und Diskurs. Tatsächlich gibt es häufig noch praktische und gute Gründe dafür, am Status Quo festzuhalten. Diese müssen erfragt, analysiert und ausgeräumt werden.

Sinnvoll ist in diesem Zusammenhang die Entwicklung verbindlicher Kommunikationsmuster im Unternehmen, von Anwendungsfällen also, in denen klar definiert wird, welche Informationen ins Wiki gestellt und welche Prozesse mithilfe anderer Kommunikationswerkzeuge abgebildet werden sollen: Wann nutzt man das Wiki? Wann versendet man eine E-Mail? Wann arbeitet man mit einem Dokumenten-Management-System? Insbesondere für kritische Fälle, die sowohl im Wiki als auch mithilfe anderer, bestehender Systeme abgebildet werden können, müssen im Rahmen der organisatorischen Überlegungen klare Regeln im Hinblick darauf definiert werden, wann welches System zu nutzen ist.

9. Die Bedeutung eines professionellen Layouts

Unter organisatorischen Gesichtspunkten ist ebenfalls wichtig, dass das Wiki ein professionelles Layout hat und nicht in der Standardversion „out of the box“ implementiert wird. Das Unternehmen verlangt von den Mitarbeitern, dass diese ihr wertvollstes Kapital, ihr Wissen, im Wiki deponieren und anderen Mitarbeitern zentral zugänglich machen. Vor diesem Hintergrund ist es von großer Bedeutung, dass in Form einer qualitativ hochwertigen Lösung eine entsprechende Umgebung geschaffen wird, in der die Mitarbeiter gerne und mit Freude agieren. Mit einem System, das vertraut wirkt und integriert ist, identifizieren Mitarbeiter sich eher als mit einem Werkzeug, das als Fremdkörper im Intranet wahrgenommen wird.

Das Wiki-Layout ist darüber hinaus eine wichtige organisatorische Komponente, weil eine hochwertige Lösung ein unternehmenspolitisches Zeichen setzt: Die Unternehmensführung unterstreicht durch die Investition in ein Layout im Corporate Design die Bedeutung des Wikis und signalisiert, dass sie an das System glaubt und es als zentrale und wichtige Plattform ansieht.

Haben Sie Fragen zur Wiki-Einführung? Oder benötigen Sie Unterstützung bei einem laufenden Projekt? Weitere Informationen zu Enterprise Wikis und ein Kontaktformular für Ihre Anfrage finden Sie auf unserer speziellen Seite zum Thema Firmenwikis.

Weiterführende Informationen

Strategische Firmenwikis und Unternehmenswikis im Tagesgeschäft: Eine wichtige Unterscheidung
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Hofläden, Supermärkte und Firmenwikis: „Bitte klingeln“ und „Herzlich willkommen“
Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann

Damit die Einführung von JIRA im Unternehmen gelingt und sich die produktive Nutzung des Systems unternehmensweit durchsetzt, gilt es, einige Regeln im Umgang mit dem System zu befolgen und bestimmte Voraussetzungen zu schaffen bzw. zu etablieren.

Umgang der Mitarbeiter mit JIRA

JIRA-Fitness nur über intensive Nutzung: Jeder Mitarbeiter muss die Grundfunktionalitäten von JIRA kennen und so gut mit dem System umgehen können, dass er sich sicher fühlt. Wer nicht weiß, wie man einen Eintrag findet, wie man Aufgaben filtert, wie man ein E-Mail-Abonnement einstellt oder wer noch nie von Greenhopper gehört hat, muss sich intensiver mit den Grundfunktionen auseinandersetzen. Das geht nur über die tägliche, intensive Nutzung und nur, indem jeder Mitarbeiter JIRA anwendet und seine geplanten, aktiven und abgeschlossenen Aufgaben im System dokumentiert.

No Ticket, no Task: Eine essenzielle Grundlage für eine erfolgreiche JIRA-Einführung lässt sich so auf den Punkt bringen: No JIRA-Ticket, no Task. Die erste Frage auf eine persönlich oder telefonisch kommunizierte Aufgabe sollte lauten: „Wo ist das JIRA-Ticket dafür?“ Wer bei der schriftlichen Delegation einer Aufgabe kein JIRA-Ticket bekommt, fragt entweder danach oder legt sich bei gebotener Eile eben selbst ein Ticket an. Dazu reicht eine kurze E-Mail an die JIRA-E-Mail-Adresse des eigenen Bereichs.

Aktuelle Arbeiten dokumentieren: Jeder Mitarbeiter markiert, welche Aufgaben er gerade bearbeitet, welche warten und welche inaktiv sind. Wichtig ist vor allem, dass Dritte wie z.B. Projektmanager möglichst zu jedem Zeitpunkt erkennen können, woran der Kollege gerade arbeitet. Stichwörter sind Transparenz und Auswertbarkeit.

Umgang der Projektmanager mit JIRA

Umfangreiches JIRA-Know-how ist Pflicht: Für einen Projektmanager reicht es nicht aus, die JIRA-Grundfunktionen zu kennen. Wer als Projektmanager den Administrationsbereich von JIRA noch nicht gesehen hat und ihn nicht bedienen kann, sollte sich dringend einarbeiten. Wer nicht weiß, wie man einen Workflow konfiguriert oder mit Greenhopper einen Burn-Down-Chart für das eigene Projekt darstellt, sollte sich das von einem Kollegen zeigen lassen.

Tägliche und intensive Arbeit: Projektmanager arbeiten täglich und sehr intensiv mit dem System. Sie kontrollieren und dokumentieren Arbeitsstände, priorisieren neu eingetragene Elemente in ihren Projekten und sorgen dafür, dass keine überfälligen Vorgänge „explodieren“.

Mit gutem Beispiel vorangehen: Für die Akzeptanz und schnelle Etablierung von JIRA ist es wichtig, dass Projektmanager anderen Mitarbeitern vorleben, wie man mit JIRA arbeitet: So sollten Tickets bereits angelegt sein, wenn die anstehenden Aufgaben im Meeting besprochen werden. Für Projektmanager muss es die Ausnahme und nicht die Regel sein, dass Mitarbeiter sich in JIRA selbst organisieren müssen.

Vollständig, granular, beschätzt, paketiert, sortiert: Ein gut geplantes Projekt in JIRA besteht aus einem umfangreichen und (nach bestem Wissen des Projektmanagers) vollständigen Satz an Vorgängen. Es gibt granulare Unteraufgaben, alle Elemente sind beschätzt, die Elemente sind in Releases paketiert, um die Abarbeitung zu vereinfachen und zeitlich zu planen. Inhaltlich sind Komponenten definiert worden, die die Arbeiten sinnvoll unterteilen.

Regelmäßige Kontrolle und Aktualisierung: Gute Projektmanager führen regelmäßige Kontrollen und „Follow-ups“ durch. Sie prüfen, ob alle Projektbeteiligten den Arbeitsstand dokumentiert haben, nehmen ihre Burn-Down-Diagramme zur Kenntnis und reagieren proaktiv auf diese.

Sind diese Voraussetzungen geschaffen und diese Arbeitsweisen etabliert, entfaltet das System sein Potenzial: JIRA bietet allen Mitarbeitern und Projektmanagern einen Überblick über sämtliche eigene Aufgaben und auch über alle Aufgaben des Projekt-Teams. Unserer Erfahrung und den Erkenntnissen aus vielen JIRA-Projekten nach erfüllt JIRA alle Erwartungen an eine effektive Aufgabenverwaltung, kann darüber hinaus sehr individuelle Anforderungen abbilden und ermöglicht effizientes Arbeiten durch einfache, intuitive Benutzeroberflächen.

Haben Sie Fragen zu JIRA? Suchen Sie eine Lösung für ein professionelles, systematisches Aufgabenmanagement? //SEIBERT/MEDIA ist offizieller Atlassian-Partner und setzt JIRA selbst erfolgreich im eigenen Intranet ein. Wir beraten Sie und stellen Ihnen gerne kostenlos und unverbindlich eine Testinstallation zur Verfügung, damit Sie JIRA mit vollem Funktionsumfang kennenlernen können. Bitte nutzen Sie das Kontaktformular auf unserer speziellen Seite mit ausführlichen Informationen über JIRA für Ihre Anfrage.

Weitere Informationen

JIRA: Aufgabenmanagement, Scrum und agiles Projektmanagement für Entwickler und Manager (Vodcast)
Atlassian-Lizenzen: Warum ein Kauf bei //SEIBERT/MEDIA eine gute Wahl ist
E-Mail-Missbrauch: Aufgaben gehören nicht in E-Mails
JIRA-Workflows: Aufgaben in systematische und transparente Abläufe überführen

Ein Firmenwiki ist für viele Mitarbeiter nicht nur eine neue Technologie (zumindest im Unternehmensumfeld), sondern setzt im gesamten Unternehmen einen Wandel der Kommunikations- und Zusammenarbeitsgewohnheiten voraus. Aus Dutzenden Firmenwiki-Projekten wissen wir, dass eine erfolgreiche Wiki-Einführung erfahrungsgemäß von drei Faktoren abhängt: der technologischen, der organisatorischen und der kulturellen Komponente. Dieser erste von drei Beiträgen zum Thema widmet sich den technologischen Herausforderungen.

Technologische Aspekte werden häufig überschätzt

Der Einfluss der technischen Komponente bei der Wiki-Einführung wird von vielen Unternehmen grundsätzlich überschätzt, was vor allem daran liegt, dass viele Unternehmen sich fast ausschließlich mit Technologiefragen intensiv auseinandersetzen. Unserer Erfahrung nach tragen diese Aspekte jedoch nur zu etwa einem Drittel zum Erfolg einer Wiki-Einführung bei. Dennoch müssen Unternehmen natürlich auch in diesem Zusammenhang einige wichtige Voraussetzungen schaffen.

1. Auswahl der richtigen Wiki-Software

Die Auswahl und Einführung der Software ist ein Grundpfeiler eines Wiki-Projekts. Bevor kulturelle oder organisatorische Aspekte ins Spiel kommen, muss zunächst die technische Komponente erfüllt sein. Bei der Evaluation müssen verschiedene zentrale Fragen beantwortet werden: Welche ausgereiften Wiki-Systeme für den Einsatz im Unternehmen gibt es und welches ist das richtige, um die eigenen Unternehmensprozesse abzubilden? Setzt man als Unternehmen auf Open-Source-Technologien wie beispielsweise Foswiki oder wählt man eine ausgereifte kommerzielle Lösung wie etwa Confluence? Welche Schwächen und Stärken haben die Lösungen, inwieweit sind sie (ggf. über Plugins) anpassbar? Welche Schnittstellen zu anderen Systemen gibt es? Ist eine LDAP-Anbindung und somit eine Single-Sign-on-Lösung möglich?

Im Mittelpunkt der Evaluation stehen also die Anforderungen des Unternehmens und die Frage, welche Aufgaben die Mitarbeiter mithilfe des Wikis erfüllen sollen. Damit sich eine Technologie intern durchsetzt, muss natürlich ein Bedarf für die Nutzung ihrer Features bestehen. Allerdings zeigt die Projekterfahrung, dass manche Unternehmen eine Software auswählen, ohne dass ein solcher konkreter Nutzungsbedarf für diese spezielle Software besteht, und diese Unternehmen anschließend viel Mühe darin investieren müssen, Standardlösungen im Nachhinein an die wirklichen Anforderungen des Unternehmens anzupassen, was häufig nicht gelingt. Eine Studie von Jakob Nielsen bestätigt, dass die Voraussetzung für die erfolgreiche Einführung eines Software-Werkzeugs deren tatsächliche Notwendigkeit ist:

A uniform finding across all of our case studies is that organizations are successful with social media and collaboration technologies only when the tools are designed to solve an identified business need. Different companies have different priorities and use different forms of internal communication; not every company needs every tool. Although picking the tool to support the need sounds obvious, it runs contrary to the technology fetishism that characterizes much talk about the latest Internet fads.

Eine intensive Evaluation beispielsweise in Form von Strategie-Workshops mit einem erfahrenen Wiki-Dienstleister ist eine bewährte Methode, um Wiki-Software unter diesen Gesichtspunkten zu prüfen.

2. Betrieb des Systems

Betrieb auf einem Rechner
Für den Betrieb der Wiki-Software bestehen drei Möglichkeiten. Die einfachste Lösung ist die, dass das System lokal auf einem PC läuft. Für eine Testphase mit sehr wenigen Personen und eine erste Evaluation kann das durchaus sinnvoll sein. Wenn allerdings die klassischen Funktionen wie Zusammenarbeit zum Einsatz kommen sollen, ist diese Alternative natürlich nicht zielführend, zumal das Wiki nur läuft, wenn der entsprechende Rechner in Betrieb ist. Zudem ist kein Zugriff von fremden PCs aus möglich.

Hosting bei einem Drittanbieter
Ein gängiges Vorgehen ist das Hosting bei einem Drittanbieter. Dieser ist in der Regel der Dienstleister, der das Unternehmen beim Wiki-Projekt unterstützt und auch die Hosting-Leistungen übernimmt. Der Nachteil hierbei besteht darin, dass das Wiki außerhalb des internen Systems läuft, also von außen zugänglich ist, was gerade aus politischer Perspektive  problematisch sein kann: Viele Kunden wollen interne Systeme eben intern betreiben, um die Daten schlicht im eigenen Unternehmen zu haben. Allerdings zeichnet sich insbesondere im Zuge des Cloud-Computing-Trends ein Umdenken ab und immer mehr Unternehmen werden in den nächsten Jahren anstreben, Hosting-Leistungen auszulagern.

Interner Betrieb
Trotzdem ist es heute gerade in Deutschland für die meisten Unternehmen noch selbstverständlich, dass sie den Betrieb eines Wikis in der eigenen Infrastruktur durchführen. Diese dritte Möglichkeit ist allerdings die aufwändigste und kostspieligste, denn das Unternehmen benötigt entsprechendes Know-how (Systemadministrator, Sicherheitskonzept) und eine geeignete Infrastruktur (Hardware oder ein virtuelles System, in dem das Wiki läuft). Dennoch ist diese Alternative derzeit die bevorzugte.

3. Technische Infrastruktur im Unternehmen

Die technologische Komponente umfasst auch die generelle technische Ausstattung. Einige Unternehmen stehen schon bei der Frage nach dem Browser vor einem Problem, denn in vielen Firmen kommt heute noch der Internet Explorer 6 zum Einsatz, der zahlreiche Funktionen, die eine Wiki-Software bietet, nicht abbilden kann.

In den meisten kleineren Unternehmen nutzen die Anwender zwar bereits moderne Browser wie den Internet Explorer 7 oder 8 oder Firefox, doch in vielen Konzernen, in denen Mitarbeiter keine Möglichkeit haben, auf ihre Rechner Einfluss zu nehmen, arbeiten mitunter Tausende Nutzer mit einem veralteten Browser. Dies ist in der Tat ein Dilemma, denn hier korreliert die mangelhafte Ausstattung häufig mit Unflexibilität und dem fehlenden Willen, die Situation zu verändern.

Mittelfristig wird dieses Problem sicherlich gegenstandslos werden, doch derzeit hat diese Komponente durchaus noch eine hohe Relevanz und manche Unternehmen stehen vor der Tatsache, dass ihr ausgereiftes Wiki-System nicht vollumfänglich genutzt werden kann.

4. Integration und Single-Sign-on

Wichtig für die Akzeptanz des Wikis ist die Integration in einen bestehenden Anmelde-Server, am besten sogar eine Single-Sign-on-Lösung ohne zusätzliches Login-Erfordernis. Mitarbeiter empfinden es als sehr störend, wenn ein System separate Zugangsdaten erfordert, was die Einführung des Wikis wiederum erheblich erschwert. Gerade wenn es bereits mehrere bestehende Systeme gibt, für die ein einheitlicher Login oder sogar eine Single-Sign-on-Lösung etabliert ist, sollte das Wiki in diese Infrastruktur integriert werden, um die Akzeptanzchancen zu erhöhen.

5. Stellung der Wiki-Software gegenüber anderen Systemen

Im Zusammenhang mit der Stellung der Wiki-Software gegenüber anderen Systemen gibt es zwei interessante Aspekte:

a) Soll es Schnittstellen zwischen dem Wiki und bereits bestehenden Systemen geben, über die ein Datenaustausch stattfindet? Sollen also Daten z.B. aus einem Business-Intelligence-System an das Wiki übertragen und in diesem abgebildet werden bzw. sollen Daten vom Wiki in andere Systeme übermittelt werden können?

b) Gibt es eine Portallösung, in die das Wiki integriert werden soll, oder wird es separat über eine URL aufgerufen? Ist ersteres der Fall, hat dies beispielsweise auch Auswirkungen auf das Layout, da das Wiki dann eventuell im Hinblick auf das Rahmen-Template an die bestehende Portallösung angepasst werden muss.

Diese Fragen müssen geklärt und technische Lösungen gefunden werden.

6. Evaluation von Plugins

Für ausgereifte Wiki-Systeme gibt es eine Vielzahl von Plugins und Erweiterungen, die spezifische Aufgaben erfüllen. Diese Plugins müssen Unternehmen im Zuge der Wiki-Einführung evaluieren und sich Gedanken über Extensions machen, die notwendig sind, um die Wiki-Software richtig betreiben und vollumfänglich nutzen zu können.

Vor allem Erweiterungen wie ein WebDAV-Plugin sind mächtige Lösungen. Solche Plugins ermöglichen es, einen Wiki-Server wie einen lokalen Rechner im eigenen Netzwerk zu nutzen und das Wiki wie andere verteilte Netzlaufwerke zu verwenden – also die Voraussetzungen dafür zu schaffen, dass Mitarbeiter ihre Dateien nicht mehr auf einem der verteilten Netzlaufwerke speichern, sondern direkt im Wiki ablegen, das wie jedes andere Laufwerk, z.B. über die Windows Explorer, aber eben auch über die Web-Oberfläche zugänglich ist.

Funktionalitäten wie diese haben ein sehr großes Potenzial, erfordern aber eine sehr Client-seitige Konfiguration, für die Know-how benötigt wird und für die entsprechende Kapazitäten eingeplant werden müssen. Ohne einen Systemadministrator und entsprechende Konfigurationsrechte können solche Funktionen nicht genutzt werden.

Haben Sie Fragen zur Wiki-Einführung? Oder benötigen Sie Unterstützung bei einem laufenden Projekt? Weitere Informationen zu Enterprise Wikis und ein Kontaktformular für Ihre Anfrage finden Sie auf unserer speziellen Seite zum Thema Firmenwikis.

Weiterführende Informationen

Strategische Firmenwikis und Unternehmenswikis im Tagesgeschäft: Eine wichtige Unterscheidung
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Hofläden, Supermärkte und Firmenwikis: „Bitte klingeln“ und „Herzlich willkommen“
Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann

1. Funktionale Erweiterungen

• Confluence verfügt über einen hochwertigen und ausgereiften nativen WYSIWYG-Editor, der dem Rich-Text-Editor von Foswiki voraus ist. MediaWiki bietet nativ gar keinen WYSIWYG-Editor.
• In Foswiki und MediaWiki kann man HTML-Quellcode einfügen. Das ist für Angriffe von innen leider ein Sicherheitsproblem und könnte bei hohen Compliance-Anforderungen und hohen Sicherheitsbedürfnissen ein Ausschlusskriterium sein. In Confluence lässt sich kein HTML-Code einschleusen. Ein Widget-Plugin ermöglicht trotzdem die einfache und schnelle Einbindung von externen Inhalten wie YouTube-Filmen und Slideshare-Präsentationen.
• Die Integration von MS Office und Open Office in Confluence ist nahtlos.
• Das Gliffy-Plugin transportiert Visio-Anwendungen in das Firmenwiki: Prozessmodellierung, Planung, Zeichnungen, Diagramme. Das ist gerade für Dokumentationen, Handbücher usw. sehr interessant.
• Confluence bietet bessere Suchfunktionalitäten ohne zusätzliches Plugin (parametrisierbar).
• Confluence verfügt über den bequemen und praktischen Makro-Browser, der ermöglicht, dass auch Gelegenheitsnutzer die erweiterten Funktionen des Wikis sukzessive kennenlernen und selbstständig nutzen.
• Es gibt in Confluence ein sehr ausgereiftes Workflow-Plugin, das Freigabe- und Veröffentlichungsprozesse unterstützt. Auch dank dieses Features bietet Confluence beste Voraussetzungen dafür, Inhalte in einem Extranet für Kunden und Partner zu verwalten und zusätzlich zu den programmierten Routinen zu veröffentlichen. Aber auch Qualitäts-Management-Prozesse können eine ISO-zertifizierungskonforme Freigabe erhalten.
• Confluence hat einen mächtigen Dokumentenimport für bestehende Word-Dokumente.
• Confluence hat einen sicheren E-Mail-Import, mit dessen Hilfe die E-Mail-Kommunikation in Projekten auch im Wiki dokumentiert werden kann.
• Besonders interessant für Programmierer ist die bessere Erweiterbarkeit dank einer vielschichtigen Plugin-API.
• Aus Sicht von Administratoren und Nicht-Technikern ist die einfache Installation und Konfiguration von Hunderten Plugins direkt über die Web-Oberfläche des Administrationsbereichs sehr interessant, die ohne Unterstützung durch Systemadministratoren und Programmierer möglich ist, sofern eine Ermächtigung durch den Wiki-Manager im Unternehmen vorliegt.
• Die Confluence-Community ist größer und mit Entwicklern aus großen und sehr großen Unternehmen bestückt, die wiederum viele weitere Programmierer anlocken.
• Layout-Änderungen sind in Confluence durch Upload als Plugin möglich.
• Confluence verfügt über eine professionelle WebDAV-Anbindung, die das Wiki direkt in das Datei-System einbindet.
• Die Integration von und das Zusammenspiel mit anderen Atlassian-Produkten wie beispielsweise JIRA ist perfekt.
• Das ausgereifte SQL-Plugin ermöglicht eine bessere Anbindung von Datenbanken. Das ist insbesondere im Hinblick auf Reporting und Auswertungen interessant.

2. Usability-Verbesserungen

• Confluence verfügt über eine deutlich intuitivere und ausgereiftere Oberfläche als seine beiden Open-Source-Kontrahenten und löst die Aufgaben Suche und Navigation besser. Dies führt zu einer höheren Akzeptanz seitens der Mitarbeiter und verkürzt die Lernkurve. Auf diese Weise werden Schulungsmaßnahmen eingespart und langfristig eine stärkere Nutzung des Wikis erreicht.
• Das Bereichskonzept in Confluence ist sehr granular. In diesem Punkt ist Confluence insbesondere MediaWiki, das ein Bereichskonzept nativ gar nicht anbietet, haushoch überlegen!
• Die Rechtekonfiguration ist einfacher und transparenter für die Nutzer. MediaWiki dagegen hat überhaupt keine native Rechteverwaltung.
• Der Administrationsbereich von Confluence ist deutlich einfacher zu verstehen und zu bedienen als die entsprechenden Bereiche in Foswiki und MediaWiki.
• Die Möglichkeit der direkten In-Line-Anzeige von externen Dokumenten auf Confluence-Wiki-Seiten beschleunigt die Erfassung von Inhalten aus Datei-Anhängen und stellt die Content-Aufnahme in einer einheitlichen Web-Oberfläche sicher.
• Für Confluence gibt es ein Plugin zum Einkopieren von Dateien per Drag & Drop.
• Die Wiki-Struktur in Form von Eltern-Kind-Beziehungen zwischen Wiki-Dokumenten lässt sich in Confluence einfach und unkompliziert ebenfalls per Drag & Drop anpassen.
• Bestehende Wiki-Dokumente können in Confluence vollkommen problemlos nach Belieben geändert und vor allem umbenannt zu werden.
• Ein kleines, sehr einfach zu implementierendes Aufgaben-Plugin ermöglicht in Confluence schon nativ eine zumindest rudimentäre Aufgabenverwaltung.
• Das Betreiben von Mitarbeiter-Blogs in Confluence ist einfach und basiert auf einem ausgereiften Konzept.
• Die RSS-Feed-Implementierung ist ansprechender und übersichtlicher gelöst als in Foswiki und MediaWiki.

3. Politische Vorteile von Confluence

• Confluence erfreut sich einer höheren Nutzerakzeptanz und führt zu einer breiteren Wiki-Nutzung im Unternehmen.
• Das System ist eines der wenigen Microsoft-zertifizierten Wikis am Markt. Es bietet Schnittstellen zu Sharepoint und MS Office und integriert sich per WebDAV nahtlos in Shared Drives im Unternehmen. Das ist für IT-Fachleute häufig ein wichtiges Argument.
• Confluence ist mit Abstand das populärste und erfolgreichste kommerzielle System am Markt.

Evaluieren Sie gerade Wiki-Software? Benötigen Sie Unterstützung bei der Anforderungsbestimmung und beim Treffen einer fundierten Entscheidung? Wir sind Experten für Unternehmenskommunikation. Gerne beraten wir Sie ausführlich und präsentieren Ihnen sowohl Confluence als auch Foswiki und MediaWiki online: Bitte sprechen Sie uns an. Weitere Informationen zum Thema sowie ein komfortables Kontaktformular für Ihre Anfrage finden Sie auch auf unserer speziellen Seite über Firmenwikis.

Weiterführende Informationen

Unsere Seite mit Informationen und Videos über Confluence
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Social-Software-Projekte: Woran die Einführung scheitern kann
Atlassian-Lizenzen: Warum ein Kauf bei //SEIBERT/MEDIA eine gute Wahl ist
Wikis brauchen ein individuelles Design

Entscheidend bei der Evaluation von Wiki-Systemen ist, dass man sich über die Anforderungen an das System klar wird – dies ist der erste und wichtigste Schritt. Bei der Auswahl des richtigen Systems sind nämlich zahlreiche Kriterien und Faktoren zu berücksichtigen.

1. Open-Source-Software oder kommerzielles Firmenwiki?

Grundsätzlich sollte zwischen quelloffenen, kostenfreien Open-Source-Wikis und kommerziellen Systemen unterschieden werden. Setzt das Unternehmen gerne auf Open-Source-Software? Das ist beileibe keine Ausnahme: Im Open-Source-Bereich gibt es professionelle, ausgereifte Systeme, hinter denen große, engagierte Communities stehen. Und Open Source ist eben „sexy“. Oder ist Open-Source-Software generell zu vermeiden? Auch das ist keine Seltenheit und absolut legitim. In vielen Unternehmen gibt es jedenfalls eine klare Tendenz in diese oder jene Richtung.

2. Preis?

Ist das Unternehmen bereit, Lizenzgebühren für ein Wiki zu entrichten? Welche Gebühren fallen für welches System an? Bei kommerziellen Systemen sollte man nicht nur die Kosten der Software selbst, sondern auch die Folgekosten für den Support sowie für kostenpflichtige Plug-ins berücksichtigen, sofern man diese benötigt.

3. Sind hochwertige Plugins verfügbar?

Die Erweiterungen machen Wikis erst zu richtigen Firmenwikis. Werden abzubildende Prozesse von geeigneten Erweiterungen unterstützt? Sind diese Plugins ausgereift? Hier müssen die verfügbaren Erweiterungen auf Stabilität und Qualität geprüft werden.

4. Existiert eine aktive Community?

Es ist wichtig, dass Firmenwiki-Software weiterentwickelt wird. Enterprise 2.0 ist ein rasant wachsendes Feld, in dem sich immer neue Anforderungen und Möglichkeiten auftun. Wenn es keine Entwicklungsgemeinde gibt, die Trends aufgreift und Leistungswünsche nachvollzieht, ist ein System schnell veraltet. Ist ein kostenloser Support durch die Community – wie bei vielen Wikis üblich – gewährleistet? Wie viele verschiedene Dienstleister gibt es und wie ist die Qualität und Wissenstiefe dieser Dienstleister?

5. Handelt es sich bei dem Wiki um eine anerkannte Lösung?

Kein Unternehmen möchte unbedingt das erste sein, das herausfindet, dass eine scheinbar innovative neue Lösung gar keine ist. Firmenwikis gibt es seit 1998. Es ist wirklich ratsam zu schauen, wer im Markt etabliert und angesehen ist. Hier spielen Referenzen und Erfahrungen von anderen Unternehmen und Dienstleistern mit Wiki-Expertise eine große Rolle.

6. Verwendete Technologie?

Welche Programmiersprache kommt zum Einsatz (z.B. Java, Perl, PHP)? Arbeitet das Wiki auf Basis einer Datenbank (z.B. mySQL etc.) oder mit Dateien? Soll das Wiki in eine universelle Unternehmenssuche integriert werden? Welche Ansprüche an Performanz und Skalierbarkeit bestehen? Hier stellt nicht selten die IT bestimmte Bedingungen. Die Praxis zeigt allerdings, dass Anforderungen wie „Nur Java!“ oder „Auf jeden Fall mySQL!“ im Wiki-Tagesgeschäft und auch für die Systemadministration später keine Rolle spielen.

7. Funktionalitäten des Systems?

Der Funktionsumfang ist ein entscheidendes Kriterium: Das Wiki soll Unternehmensprozesse abbilden und muss die Anforderungen erfüllen können, die sich aus der täglichen Arbeit ergeben. In die Evaluation von Funktionalitäten sollte man nicht zu wenig Zeit investieren. Verfügt das System über ein durchdachtes, flexibles Berechtigungskonzept? Können Wiki-Bereiche angelegt werden? Kann das Wiki beispielsweise Tabellen, Charts usw. abbilden? Verfügt das System über einen nativen WYSIWYG-Editor? etc.

8. Usability und Design?

Die Mitarbeiteraktivierung und die Generierung einer kritischen Masse von Nutzern sind Erfolgsfaktoren bei der Wiki-Einführung. Mitarbeiter sollen tagtäglich (und gerne) mit dem Wiki arbeiten und es als festen, integrierten Bestandteil der Infrastruktur wahrnehmen. Erfüllt die Software also zentrale Usability-Standards? Ist die Oberfläche einfach bedienbar? Ist das Layout des Wikis an das Corporate Design des Unternehmens anpassbar? Wie aufwändig ist die Administration?

9. Anspruch an das Projekt?

Soll das Firmenwiki nur abteilungsintern oder flächendeckend eingesetzt werden? Handelt es sich um einen „Testballon“ auf Initiative eines Bereichs oder um einen Unternehmensbeschluss zum großflächigen Rollout? Wie hoch ist die voraussichtliche Anzahl der User? Skalierbarkeit und die Voraussetzungen für eine reibungslose Integration in die bestehende IT-Infrastruktur spielen eine wesentliche Rolle bei der Wiki-Einführung.

10. Migrierbarkeit der Daten?

Viele Unternehmen möchten bzw. müssen sich die Option offen halten, ihre Daten später umzuziehen und in andere Systeme zu übertragen. Können die Daten also möglichst automatisiert in ein anderes System migriert werden? Wie aufwändig ist der Umzug?

11. Bietet das Wiki eine einfache Systemadministration?

Entscheidend für eine einfache Systemadministration sind schnelle Backups, unkompliziert einzuspielende Updates, kurzfristige Reaktionsmöglichkeiten auf Exploits usw. Auch die Lauffähigkeit unter verschiedenen Betriebssystemen muss bei der Evaluation geprüft werden.

Erfahrungsgemäß spielt der Faktor Technologie nicht die wichtigste Rolle bei einem Wiki-Projekt (erfolgskritisch sind vielmehr die organisatorischen Maßnahmen), zu vernachlässigen ist er aber keinesfalls. Es ist wichtig, im Vorfeld einer Wiki-Einführung die eigenen Anforderungen genau zu analysieren und herauszufinden, welches System die abzubildenden Prozesse optimal unterstützt. Dabei kann //SEIBERT/MEDIA Ihnen helfen.

Denken Sie über eine Wiki-Einführung nach? Evaluieren Sie vielversprechende Software? Benötigen Sie Unterstützung bei einem laufenden Wiki-Projekt? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne, bitte sprechen Sie uns.  Weitere Informationen zum Thema finden Sie auch auf unserer speziellen Seite über Firmenwikis.

Weiterführende Informationen

Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Social-Software-Projekte: Woran die Einführung scheitern kann
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Software-Updates in Unternehmen: Wann sind sie sinnvoll?
Wikis brauchen ein individuelles Design

Sowohl Wikis und Micro-Blogs als auch Aufgaben-Management-Systeme wie Jira sind Möglichkeiten, die E-Mail-Flut nachhaltig zu verringern und mehr Produktivität in den Arbeitsalltag zu bringen. Diese Systeme müssen aber auch konsequent zum Einsatz kommen. Einige Fehlerquellen und Beispiele für die falsche Nutzung von Kommunikationskanälen haben wir in diesem Artikel für Sie zusammengestellt.

E-Mails an Verteiler und „An alle“

Mitarbeiter erhalten ständig interne Informationen, die für ihre eigentliche Arbeit nutzlos sind und die ihre Produktivität ausbremsen. Dabei handelt es sich vor allem um überflüssige Informationen, die an Verteiler oder „An alle“ verschickt werden, obwohl sie nur für wenige Kollegen gerade jetzt von Belang sind.

Natürlich sollen sich neue Mitarbeiter allen vorstellen und gewiss sind etwa Informationen zur aktuellen Entwicklung des Unternehmens für sämtliche Kollegen interessant und wichtig. Doch solche Inhalte sind erfahrungsgemäß die Ausnahme. Ich bin der Überzeugung, dass 90% aller An-alle-E-Mails nicht „alle“ interessieren, schon gar nicht, wenn es um unaufgeräumte Kühlschränke in der Büroküche geht. Solche Informationen sollten in entsprechenden Gruppen im Micro-Blog abgebildet werden. Auch E-Mails an einen Verteiler sind häufig besser in der entsprechenden Micro-Blog-Gruppe aufgehoben.

Abstimmungs- und Änderungsrunden per E-Mail

Häufig dokumentieren Mitarbeiter Projektstände und erledigte Arbeitsschritte detailliert per E-Mail und finden umfangreiche Abstimmungen per E-Mail statt mit dem Resultat, dass das E-Mail-Aufkommen erhöht und die Technologie E-Mail nicht bestimmungsgemäß genutzt wird.

Grundsätzlich gehören E-Mail-Inhalte mit reinem Informationscharakter entweder ins Wiki (sofern sie strukturiert dokumentiert sein sollen) oder in den Micro-Blog (wenn sie schnell dokumentiert und kommuniziert werden sollen).

Projekt-Teams können abgearbeitete Teilschritte im Wiki dokumentieren, ohne E-Mails über Verteiler auch an Kollegen zu schicken, die (wenn überhaupt) nur am Rande mit dem Projekt zu tun haben. Das gilt ebenso für die Organisation von Meetings, die Planung von internen Veranstaltungen, das Management der Bestellliste für Fachbücher usw. usf.

Auch E-Mail-Abstimmungen mit mehreren Empfängern sind ineffizient und sollten nach Möglichkeit vermieden werden. Diese Diskussionen sind im Micro-Blog besser aufgehoben und sollten dorthin ausgelagert werden.

E-Mail-Anhänge

E-Mails mit Anhängen sollten insbesondere in der internen Unternehmenskommunikation die absolute Ausnahme sein. Die Argumente gegen Dateianhänge in E-Mails liegen auf der Hand: Wichtige Dokumente sind dezentral in Postfächern verstreut, der aktuelle Stand der Dinge ist aufgrund unterschiedlicher Iterationsstufen nicht ersichtlich, im schlimmsten Fall durchlaufen Office-Dokumente auch noch ineffektive Änderungsrunden per E-Mail.

Es ist viel sinnvoller, Datei-Anhänge in einem zentralen System, dem Wiki, zu speichern, das allen Empfängern zugänglich ist, eine E-Mail sollte lediglich den Verweis auf das entsprechende Dokument beinhalten. Ein Beispiel aus der Praxis macht die Intention dieser Forderung deutlich:

Verschickt man zum Beispiel einen Bericht per E-Mail an mehrere Empfänger, ist dieser Bericht ein „totes“ Dokument: Es verändert sich nicht, es kann nicht kommentiert werden, Leser können nicht mit ihm interagieren, es entwickelt sich nicht weiter und es ist nicht zentral verfügbar. Bilden wir diesen Bericht in einem Wiki-System ab, sind die Inhalte dagegen lebendig: Die Adressaten können das Dokument sinnvoll modifizieren und ggf. selbst Fehler beheben oder Unklarheiten ansprechen, aktuelle Daten sind integrierbar, mittels Kommentarfunktion können die Inhalte gemeinsam mit anderen Empfängern interpretiert und diskutiert werden – der Bericht wird besser, ohne dass eine einzige weitere E-Mail auszutauschen ist.

Aufgaben in E-Mails

Aufgaben sollten in einem zentralen und professionellen Aufgaben-Management-System wie Jira abgebildet werden. In die E-Mail selbst gehören nur der Hinweis auf das Vorhandensein einer Aufgabe und die Bitte um Erledigung.

Sicherlich ist das Aufgaben-Management per E-Mail der klassische, schnelle und opportune Weg, doch mit der spontanen Hülle – eine E-Mail ist schnell geschrieben und kommuniziert – sind die Vorteile auch schon erschöpft.

Mit einer ausgereiften Aufgaben-Management-Software wie Jira dagegen ist die Abbildung kompletter Entwicklungslebenszyklen von der Ideensammlung und dem Anforderungs-Management über die Abarbeitung bis zur Qualitätssicherung möglich – ohne E-Mail-Verkehr, der über die Initiations-E-Mail mit dem Link auf die Aufgabe hinausgeht.

Ein solches System bietet die Möglichkeit, sich zentral einen aktuellen Überblick über sämtliche Fortschritte in einem Projekt zu verschaffen. An diesen Eigenschaften muss sich das Aufgaben-Management per E-Mail messen lassen und kann hier natürlich nicht gewinnen. Dabei definiert sich nicht über die Größe des Projekt-Teams, ob es sinnvoll ist, eine Aufgabe per E-Mail zu verschicken oder nicht – selbst kleine Teams mit sehr wenigen Mitarbeitern profitieren von einer systematischen Aufgabenverwaltung.

Firmenwikis, Micro-Blogs und professionelle Aufgaben-Management-Systeme sind zusätzliche Kommunikationskanäle, bestimmungsgemäß genutzt verschlanken sie die Unternehmenskommunikation dramatisch und führen zu mehr Effizienz und Produktivität im Unternehmen. Haben Sie Fragen zum Einsatz oder zur Einführung von Wikis, Micro-Blogging oder Jira? Benötigen Sie Unterstützung bei laufenden Projekten? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne, bitte sprechen Sie uns an.

Weiterführende Informationen

JIRA: Aufgabenmanagement, Scrum und agiles Projektmanagement für Entwickler und Manager
Aufgabenmanagement: Argumente für Jira
Confluence: Ausgereift, viele Funktionen, gute Usability (Vodcast)
Hype Cycle 2009: Wo stehen Cloud Computing, Social Media und Unternehmens-Blogs?
Micro-Blogging im Unternehmen: Potenziale und Anwendung
Social-Software-Projekte: Woran die Einführung scheitern kann

Mittlerweile zeichnet sich die Kommunikationslandschaft bei vielen Unternehmen durch eine Vielzahl von möglichen Kommunikationswegen aus, mit deren Hilfe Kommunikation kanalisiert und ihre Effizienz erhöht werden soll und kann.

Neben der persönlichen Absprache vor Ort im Büro und per Telefon sowie der ebenfalls klassischen (und häufig missbrauchten) Kommunikation per E-Mail haben sich weitere Kanäle in vielen Unternehmen längst durchgesetzt: Instant Messaging, interne Micro-Blogs, Wikis und Weblogs.

Die Herausforderung besteht darin, auch tatsächlich eine Effizienzsteigerung der internen Kommunikation zu erreichen. Fragen wir also nach der Relevanz und der sinnvollen Nutzung der internen Kommunikationsmöglichkeiten. Es hat sich bewährt, hierbei grundsätzlich die Faktoren Dringlichkeit und Dauer der Relevanz von Informationen zu berücksichtigen:

Sinnvolle Fragen

Um eine sinnvolle, effiziente Nutzung dieser Kanäle zu erreichen, sollte sich also jeder Mitarbeiter, der Kollegen Inhalte kommunizieren möchte, zunächst immer einige Fragen stellen:

• Welche Antwort sollte ich wo posten?
• Muss bzw. darf ich meinen Kommunikationspartner jetzt wirklich stören?
• Wie dringend ist meine Nachricht eigentlich tatsächlich für die anderen?
• Wer sind die Adressaten? Wer muss, wer darf sie lesen?
• Ist es eine Information mit kurzer Lebensdauer oder ist sie längerfristig relevant?
• Mit welchem Tool kann ich arbeiten, um welchen Kanal zu nutzen?

Effiziente Nutzung von Kommunikationskanälen

Telefon
Wenn eine Angelegenheit oder eine Anfrage höchste Priorität hat, sehr dringlich und eine persönliche Klärung unbedingt notwendig ist, sollte man zum Telefon greifen. Bei einem Telefonat wird der Adressat direkt angesprochen. Diese Form der Kommunikation hat für das Wissensmanagement keinen langfristigen Wert, da sie nicht dokumentiert wird.

Instant Messaging
Ähnlich wie beim Telefonanruf spricht man beim Instant Messaging jemanden direkt an bzw. stört ihn unmittelbar. Für das Instant Messaging sollte man sich bei Nachrichten entscheiden, die dringend und langfristig eher irrelevant sind und kurz und knapp gehalten werden können.

• „Schau Dir mal bitte dieses Ticket an: <Link>. Das Zwischenergebnis sollen wir morgen kommunizieren. Wie steht es damit?“
• „Im heute veröffentlichten Blog-Artikel wird die Grafik nicht dargestellt. Kannst Du das bitte rasch beheben?“

Tools, die sich in Unternehmen etabliert haben, sind Jabber-Clients (z.B. Psi oder Adium, iChat) oder Skype.

E-Mail
Auch bei der E-Mail-Nutzung sprechen wir den oder die Adressaten direkt an, die E-Mail ist ein Push-Medium. Nachrichten, die per E-Mail übermittelt werden, haben eine geringere Dringlichkeit als solche, für die ein Telefonanruf oder Instant Messaging angebracht ist. Der Sender erwartet in der Regel eine Antwort innerhalb eines Zeitkorridors von zwei Stunden bis maximal zwei Tagen.

E-Mails eignen sich für Informationen, die für einen beschränkten Nutzerkreis oder eine Einzelperson relevant sind, für Inhalte, die zwingend alle Mitarbeiter zur Kenntnis nehmen sollen, und auch für flüchtige Infos, die nur in diesem Augenblick relevant sind. Exemplarische Beispiele sind:

• „Ich habe ein Problem mit meinem Rechner, das (bei Gelegenheit) gelöst werden soll.“
• „Im Projekt müssen unbedingt ab sofort alle Einbuchungen wie hier im Wiki beschrieben aussehen: <Wiki-Link>“
• „Eine wichtige Information zur Unternehmensstrategie 2010 findet Ihr im Wiki unter …“
• „Da ist ein Päckchen für Dich angekommen.“
• „Anbei finden Sie das besprochene Angebot …“

Bei E-Mails, die ein konkretes Projekt betreffen, besteht immer das Problem, dass Beteiligten, die erst später dazu stoßen, vorherige E-Mails und die darin enthaltenen Informationen nicht zur Verfügung stehen. Auch im Hinblick auf die Archivierung von Inhalten ist die E-Mail-Kommunikation problematisch – letztlich ist jeder selbst dafür verantwortlich, was er mit der E-Mail macht. Gängige E-Mail-Tools sind Outlook, Exchange, Lotus Notes, Mail, Thunderbird und Zimbra.

Jira
Jira ist das mächtige Aufgaben-Management-System für Unternehmen. Grundsätzlich gehören Aufgaben nicht in E-Mails: Stattdessen sollte immer ein Jira-Ticket angelegt werden. Optional kann dann zusätzlich aus Jira heraus noch der Vorgang per E-Mail an den Bearbeiter mit der Bitte um Erledigung verschickt werden. Jira ist ein Pull-Medium, sofern die E-Mail-Benachrichtigungen über neue Aufgaben standardmäßig deaktiviert werden. Die E-Mail-Kommunikation im Zusammenhang mit Jira sieht im Optimalfall beispielsweise so aus:

• „Kannst Du bitte folgende Aufgabe für mich erledigen? Das Ticket ist hier …“
• „Die neuen Infos zur Aufgabe habe ich direkt im Jira-Vorgang hinterlegt, siehe …“

Micro-Blog
Ein Micro-Blog (beispielsweise auf Basis von StatusNet, Communote oder Yammer) eignet sich einerseits für Nachrichten mit einem gewissen Informationsgehalt, der auch noch in der Zukunft gegeben ist. So empfiehlt sich die Nutzung des internen Micro-Blogs

• für Nachrichten, die nicht unbedingt von allen Empfängern sofort gelesen werden müssen,
• zur Erfassung von Informationen, die längerfristig relevant sind und die schnell und unkompliziert veröffentlicht werden sollen,
• für Informationen, die öffentlich sind.

Andererseits ist der Micro-Blog auch die optimale Plattform für die bekannten (und für die meisten Empfänger irrelevanten und lästigen) An-alle-Informationen, die nach wie vor häufig per E-Mail kommuniziert werden und die nicht unmaßgeblich zur E-Mail-Flut in Unternehmen beitragen:

• „XY ist krank und isst heute nicht mit. Eine Portion Lasagne wartet auf einen Nachzügler.“
• „In der Küche ist eine Pizza angekohlt. Ich habe den Ofen jetzt ausgemacht.“
• “Zur Erinnerung: Nächste Woche bin ich im Urlaub und hier sind die Vertretungsregelungen samt Statusberichten.”

Ein Vorzug von internen Micro-Blogs besteht darin, dass Nachrichten archiviert werden und durchsuchbar sind. Durch die Verwendung von Gruppen werden zudem wichtige Nachrichten von weniger wichtigen getrennt und an spezifische Empfängerkreise kommuniziert. Auch im Pull-Medium Micro-Blog besteht eine Holschuld, der Abruf kann aber z.B. via RSS-Feed oder E-Mail-Digests automatisiert werden. Diese Informationen sind charakteristisch für die Abbildung im internen Micro-Blog:

• Zwischenstände in Projekten mit Links
• Persönliche Nachrichten mit wenig Relevanz bzw. geringer Wichtigkeit („Lecker, heute gibt’s Klöße zum Mittagessen!“, „Alles Gute zum Geburtstag, lass Dich schön feiern!“)
• Innovationen im Internet: Websites, Technik, Funktionen, Hardware
• Vertriebserfolge („Kunde XY hat beauftragt!“)
• IT-Logbuch
• Projektlogbücher

Generell müssen Projekte im Wiki dokumentiert werden. Projektbezogene Kurzinformationen, die aktuell relevant sind – wie z.B. Notizen aus Telefonaten, Bugs etc. – werden allerdings via Micro-Blogging erfasst und im Wiki durch Integration der Micro-Blog-Gruppe angezeigt.

Wiki
Weiterführende Informationen, Dokumentationen, Konzepte und Know-how, das von dauerhafter Relevanz ist, gehören ausnahmslos ins Pull-Medium Wiki. Diese Inhalte können sicherlich über andere Kanäle wie E-Mail oder Micro-Blog angekündigt werden – zentrales Wissens-Management-System ist jedoch das Wiki. Wiki-Systeme, die bei //SEIBERT/MEDIA zum Einsatz kommen, sind Foswiki und Confluence.

Blog
Im Blog werden Erfahrungs- und Projektberichte veröffentlicht, Unternehmens-Know-how geteilt und interessante Trends thematisiert, die mit dem Leistungsportfolio von //SEIBERT/MEDIA zu tun haben. Bei //SEIBERT/MEDIA dient der Corporate Blog als wichtigster externer Kommunikationskanal, den jedoch auch alle Mitarbeiter regelmäßig lesen und gelegentlich auch kommentieren sollen. Blog-Nachrichten müssen ebenfalls akiv gelesen werden, es empfiehlt sich das Monitoring via RSS-Reader.

Im zweiten Artikel zum Thema widmen wir uns Fehlern und Problemen, die die effiziente Nutzung der internen Kommunikationskanäle behindern.

Haben Sie Fragen zu einzelnen Systemen? Benötigen Sie Unterstützung bei der Einführung zusätzlicher Kommunikationsmöglichkeiten? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne, bitte sprechen Sie uns an.

Weiterführende Informationen

JIRA: Aufgabenmanagement, Scrum und agiles Projektmanagement für Entwickler und Manager
Aufgabenmanagement: Argumente für Jira
Confluence: Ausgereift, viele Funktionen, gute Usability (Vodcast)
Hype Cycle 2009: Wo stehen Cloud Computing, Social Media und Unternehmens-Blogs?
Micro-Blogging im Unternehmen: Potenziale und Anwendung
Social-Software-Projekte: Woran die Einführung scheitern kann

Bewegtbild ist aus dem Netz nicht mehr wegzudenken. 62% aller deutschen Nutzer sehen sich zumindest ab und zu Videos im Internet an, 52% aller User greifen regelmäßig auf Video-Portale mit nutzergenerierten Inhalten zu, in den jüngeren Nutzergruppen ist die Durchdringung sogar nahezu vollständig (siehe ARD-ZDF-Online-Studie 2009). Videoportale, Web-TV und Videobanner sind voll im Trend und im Grunde Pflichtprogramm für diejenigen, die ihre Zielgruppe bei Laune halten wollen und sie emotional in die Inhalte involvieren möchten.

Heute nutzen Internet-User das Web sowohl als Informationsquelle als auch zur Unterhaltung. Der Einsatz von Online-Videos, die nicht nur unterhalten, sondern vor allem überraschen, kann deshalb eine sinnvolle Ergänzung zum bisherigen Informationsangebot sein.

Eigentlich ist Bewegtbild im Web nichts Neues: Schon seit langer Zeit ist es möglich, digitale Videos in Websites einzubinden. Die große Welle ist aber erst vor ca. drei Jahren mit YouTube und Co. ins Rollen gekommen. Seitdem werden jährlich neue Rekorde in Sachen Nutzerzahlen vermeldet, IPTV, das Fernsehen im Netz, verzeichnet sensationelle Zuwachsraten im dreistelligen Prozentbereich.

Infrastruktur und verändertes Nutzerverhalten begünstigen Bewegtbild

Zu diesem Erfolg haben einerseits die immer bessere technologische Infrastruktur und andererseits das veränderte Nutzungsverhalten geführt: In mehr als 70% aller deutschen Haushalte ist ein Breitbandanschluss vorhanden, über 20% verfügen bereits über einen VDSL-Anschluss mit Übertragungsraten bis zu 50 Megabit. Und dank Plattformen wie YouTube haben Nutzer gelernt, im Internet aktiv nach Videomaterial zu suchen.

Neben Web-TV und nutzergenerierten Clips auf YouTube & Co. gewinnt Bewegtbild seit einigen Jahren nun auch auf Websites an Präsenz und Bedeutung. In diesem Zusammenhang fällt immer häufiger der Begriff “Web-Special”. Damit sind Websites gemeint, die unter massivem Einsatz von Flash und Videos Produkte auf unterhaltsame Weise vorstellen und die Interaktivität großschreiben. Portale wie zum Beispiel Mercedes-Benz.tv gehen noch einen Schritt weiter und eröffnen gleich einen eigenen Online-Sender mit zielgruppenspezifischen Inhalten.

Videos bieten neue Kommunikationsmöglichkeiten

Videos bieten neue Möglichkeiten der Kommunikation. Das Mercedes-Beispiel macht es deutlich: Ein Auto ist ein Fortbewegungsmittel und das tolle Fahrerlebnis lässt sich mithilfe bewegter Bilder besser und intensiver transportieren. Videos vermitteln Botschaften auf eingängige Weise, Videos sind intuitiv. Der Nutzer muss nicht wie sonst Texte lesen und einzelne Bilder betrachten, sondern befindet sich sofort direkt in der Handlung.

Zudem macht sich die Zielgruppe aktiv auf die Suche nach Inhalten. Theoretisch und praktisch kann sich im Web jeder Nutzer sein individuelles, abendfüllendes Programm selbst zusammenstellen: Der Trend geht weg vom Massenprogramm und hin zu individuellem Content, den der User selbst ausfindig macht. Über ein Videoportal kann das werbende Unternehmen mit dem Kunden also direkt in Kontakt treten (was TV-Werbung nicht leistet) und pflegt gleichzeitig sein Image als modern und up-to-date.

Bewegtbild im Netz braucht Web-Fachwissen und Film-Know-how

Die Argumente für den Einsatz von Videos im Internet sind überzeugend. Doch der Aufwand für ihre Produktion und die Einstiegshürden sind nicht zu unterschätzen, denn für ein gut funktionierendes, professionelles Videoportal ist Web-Fachwissen ebenso gefragt wie Know-how in Sachen Film oder TV. Sämtliche Komponenten müssen eine sinnvolle Einheit bilden, darüber hinaus müssen Interaktionsmöglichkeiten für den User integriert werden – keine einfache Aufgabe.

Gerade die „Notlösung“, dass die Agentur selbst die Videoproduktion übernimmt, kann schnell nach hinten losgehen. Das notwendige Equipment – professionelle Kamera, Beleuchtungstechnik, Postproduktions-Software etc. – kann man zwar recht günstig leihen oder kaufen, doch auch die beste Software kann schlecht gedrehtes Material nicht retten. Vor allem werden die nur scheinbar einfachen Dinge wie Beleuchtung und Ton gerne unterschätzt und aus Notlösungen hervorgegangene Ergebnisse genügen oft weder den Ansprüchen der Kunden noch denen der Agentur selbst. Die nötige Erfahrung bringt in der Regel eben nur ein Profi aus dem jeweiligen Bereich mit.

Ein gutes Zusammenspiel von Agentur und Produktionsfirmen bzw. Freelancern aus dem Film- und Animationsbereich ist essenziell für den Erfolg. //SEIBERT/MEDIA ist Spezialist im Bereich Web und kooperiert bei Projekten dieser Art mit erfahrenen Produktionsfirmen und Freelancern aus dem Filmbereich.

Ein aktuelles Beispiel ist ein Produktvideo für unseren Kunden StepStone, das //SEIBERT/MEDIA in Zusammenarbeit mit einem 3D-Artist und einem professionellen Sprecher produziert hat. Ein weiteres Projekt, bei dem mit Bewegtbild gearbeitet worden ist, ist der Online-Adventskalender für die Fink & Fuchs Public Relations AG. Professionelle Videos kommen zudem auch auf i-wie-ida.de zum Einsatz, der von //SEIBERT/MEDIA realisierten und mit dem iF Award ausgezeichneten Website.

Weiterführende Informationen

Die Website von //SEIBERT/MEDIA/DESIGN
Video-Podcasts von //SEIBERT/MEDIA
Video im Web: Kennen Sie die Trends?

Innovationsfreundlichkeit nach dem Crossing-the-Chasm-Modell

Zunächst zieht die Studie das Crossing-the-Chasm-Modell heran, das Geoffrey Moore entwickelt hat: eine Kategorisierung dahingehend, wann und unter welcher Prämisse Unternehmen innovative Technologien und Konzepte adaptieren. Demnach sind grundsätzlich fünf Unternehmenstypen zu unterscheiden:

Innovators: Vorreiter bei der Einführung neuer Technologien
Hierbei handelt es sich um Unternehmen, die frühzeitig innovative Technologien einsetzen, ohne dass diese durch relevante Referenzierungen anderer Unternehmen als praxistauglich bekannt wären, und damit relativ hohe Risiken eingehen. Die Technologie-Affinität im Unternehmen und in der Unternehmensführung ist so groß wie die Offenheit gegenüber neuen Arbeitstechniken.

Early Adopters: Frühzeitig Wettbewerbsvorteile verschaffen
Darunter sind Unternehmen zu verstehen, die intensiv Werkzeuge evaluieren, durch die ihnen Wettbewerbsvorteile entstehen. Ziel ist es, aussichtsreiche Technologien zu erkennen und anzuwenden, bevor sie zum Massenphänomen werden und sich auf einem breiten Markt durchsetzen, um so Alleinstellungsmerkmale zu erlangen.

Early Majority: Zeitige Investition in Problemlösungen
Diese „frühe Mehrheit“ denkt und handelt pragmatisch. Unternehmen dieser Kategorie gehören nicht zu denjenigen, die ein neues Tool sofort einführen, allerdings sondieren sie mit offenen Augen technologische Entwicklungen und den Markt und nehmen Erfolgsgeschichten zur Kenntnis. Sofern sich durch die Etablierung einer Technologie im Unternehmen ein Nutzen, eine Prozessoptimierung oder eine Problemlösung abzeichnet, investieren diese Unternehmen vergleichsweise früh in die Technologie.

Late Majority: Investition weitgehend ohne Risiko
Zur Late Majority gehören kulturell konservativ geprägte Unternehmen: Bevor ein Tool eingeführt wird, muss es sich nachweislich als nützlich erwiesen haben, in Sachen Return on Investment sollen die Risiken minimal sein. Diese Unternehmen setzen charakteristischerweise nicht nur deshalb auf Social Media, weil das Management vollends von den Konzepten überzeugt ist, sondern weil es ausschließen will, den Anschluss an die Wettbewerber zu verschlafen.

Laggards: Technologie-Einführung als Schadensbegrenzung
Diese Unternehmen sind die Nachzügler, die dann reagieren, wenn es zu spät ist, weil keine Wettbewerbsvorteile mehr zu erlangen sind, sondern höchstens der Abstand zur innovationsfreundlicheren Konkurrenz in Grenzen gehalten werden kann. Typischerweise herrscht in solchen Unternehmen eine Kultur, die von massiver Skepsis gegenüber innovativen Technologien geprägt ist: In einer so konservativen Unternehmenskultur wird neuen Technologien – selbst wenn sie nachweislich zu Prozessoptimierungen führen – nicht selten Pauschalkritik entgegengebracht, mitunter selbst dann noch, wenn eine Einführung erwiesenermaßen keine oder nur sehr geringe Risiken hätte. Der Status Quo wird so lange aufrechterhalten, bis der Kostendruck ein Einlenken unumgänglich macht.

Das Crossing-the-Chasm-Modell zieht eine Trennlinie zwischen Innovators und Early Adopters auf der einen, sowie der Early Majority, der Late Majority und den Laggards auf der anderen Seite und unterscheidet zwischen frühem Markt und Breitenmarkt:

Social Media ist in der Early Majority angekommen

So weit, so gut. Wirklich spannend ist nun allerdings, dass eine aktuelle Studie eine Beziehung zwischen dem Einsatz von Social Media in der internen Unternehmenskommunikation und Unternehmenskategorien nach dem Crossing-the-Chasm-Modell herstellt.

Im Rahmen ihrer Studie Enterprise 2.0 – Zehn Einblicke in den Stand der Einführung hat die centrestage GmbH Fallbeispiele von 72 sog. Enterprise-2.0-Unternehmen aus Deutschland, Österreich und der Schweiz untersucht. All diese Unternehmen haben interne Social-Media-Projekte erfolgreich durchgeführt. Hochinteressant ist die Frage, wo diese Unternehmen einzuordnen sind. Die Antwort:

• Innovators: 23%
• Early Adopters: 42%
• Early Majority: 31%
• Late Majority: 4%
• Laggards: 0%

Immerhin 35% und damit mehr als ein Drittel der Unternehmen im deutschsprachigen Raum, die innovative Kommunikations- und Kollaborations-Tools etabliert haben, gehören also nicht zu denjenigen, die sich als Innovationsvorreiter in Sachen Unternehmenskommunikation sehen bzw. so handeln. Vielmehr agieren sie in dieser Hinsicht mit Bedacht oder sind gar unternehmenskulturell sehr konservativ geprägt.

Es ist Zeit, auf Social Media zu setzen

Was bedeutet das? Der Einsatz von Social Media in Unternehmen hat sich bewährt. Unternehmen mit den unterschiedlichsten Philosophien befassen sich intensiv mit Enterprise 2.0 und haben die Potenziale des Konzepts erkannt, insbesondere den Return on Investment in Form von mehr Produktivität und Transparenz. Social Media in der internen Unternehmenskommunikation ist kein Phänomen mehr, das nur in visionären, sehr Technologie-affinen Unternehmen eine Rolle spielt. Vielmehr ist Enterprise 2.0 inzwischen ein Thema auf dem Breitenmarkt.

Für Unternehmen, die bislang nicht auf Social Media setzen, ist es an der Zeit, sich mit den Möglichkeiten des Enterprise-2.0-Konzepts zu beschäftigen. Und das hat nichts damit zu tun, auf einen Zug aufzuspringen oder einem Trend hinterherzuhecheln, sondern es geht schlicht darum, sich durch eine zukunftsfähige Unternehmenskommunikation Wettbewerbsvorteile zu verschaffen.

Haben Sie Fragen zum Einsatz von Social Media im Unternehmen? Möchten Sie wissen, wie Sie von neuen Kommunikationsformen profitieren können oder benötigen Sie Unterstützung bei einem laufenden Projekt? Wir sind Experten für Unternehmenskommunikation, bitte sprechen Sie uns an.

Weiterführende Informationen

Unsere spezielle Seite mit Informationen rund um Firmenwikis
Hype Cycle 2009: Wo stehen Cloud Computing, Social Media und Unternehmens-Blogs?
Social Software: Der Wikipedia-Irrtum
Micro-Blogging im Unternehmen: Potenziale und Anwendung
Social-Software-Projekte: Woran die Einführung scheitern kann

Einführungsstrategie: Von unten, von oben oder zweigleisig?

Drei grundsätzliche Einführungsstrategien werden in der Studie benannt: der Bottom-Up-Ansatz, die Top-Down-Strategie und der parallele Up-Down-Weg. Diese Bezeichnungen beziehen sich darauf, von wo im Unternehmen Impulse ausgehen und welche Instanzen im Unternehmen die Nutzung von Social Software vorantreiben; konkret: die Mitarbeiter bzw. einzelne Abteilungen oder die Unternehmensführung.

Die Bedeutung des Bottom-Up-Ansatzes – auch Graswurzelkonzept – hebt beispielsweise Wiki-Experte Stewart Mader im Zusammenhang mit Firmenwikis ein ums andere Mal hervor:

Meine Empfehlung: Wenn Sie in Ihrem Unternehmen ein Wiki etablieren wollen, zwingen sie niemanden dazu, es zu nutzen. Sorgen Sie vielmehr dafür, dass es verfügbar ist, lassen Sie die Leute allmählich und von ganz allein herausfinden, wie sie es optimal nutzen können und worin sein eminenter Nutzen besteht.

Prinzipiell ist das ein guter Rat. Tatsächlich hat sich gezeigt, dass Zwang und Druck von oben sich kontraproduktiv auswirken und die Etablierung von Social Software im Unternehmen ernsthaft gefährden können. Dieses Graswurzelkonzept im Sinne von „frei von Zwang“ beschreibt allerdings einen anderen Prozess als den Bottom-Up-Approach bei der Einführung eines Tools, von dem in der Studie die Rede ist.

Bei diesem handelt es sich nämlich um eine Strategie, die darauf basiert, dass sich ein Tool im Unternehmen durchsetzt, weil Mitarbeiter auf hierarchischen Ebenen unterhalb der Unternehmensführung dessen Potenziale und Qualitäten erkennen und seine Nutzung vorantreiben, indem sie einfach damit arbeiten und es aktiv im Unternehmen promoten, ohne dass das Management diesen Prozess fördert.

Ein Beispiel: Eine einzelne Abteilung nutzt ein Wiki und bewirbt es aktiv, immer mehr Mitarbeiter erkennen den Nutzen des Werkzeugs bei der täglichen Arbeit, am Ende hat es sich im Unternehmen etabliert. Die Einführung bzw. Durchsetzung des Tools erfolgt also ohne Unterstützung durch Entscheidungsträger.

Unternehmen machen Social-Media-Projekte zur Chefsache

Lediglich in 17% der Unternehmen, die Social Media einsetzen und im Rahmen der Studie untersucht wurden, ist die Einführung einer Software auf Initiative „von unten“ erfolgt. Daraus lässt sich ableiten, dass die Bottom-Up-Strategie alleine nicht zielführend ist. Darauf zu setzen, dass Enterprise-2.0-Tools sich von allein durchsetzen, entspricht offensichtlich in den seltensten Fällen der Unternehmensrealität.

Der Großteil der Unternehmen ist vielmehr der Ansicht, dass ein sog. Strong Backing from the Top erforderlich ist, um Social-Media-Projekte erfolgreich zu realisieren. 36% haben bei der Einführung einen zweigleisigen Weg verfolgt, den parallelen Up-Down-Ansatz. In diesen Fällen ist die Unternehmensführung auf die Initiative von Mitarbeitern oder eines Bereichs eingegangen und hat diese zur Chefsache gemacht. In 47% der untersuchten Unternehmen sind die Initiativen für Enterprise-2.0-Vorhaben direkt von der Unternehmensführung ausgegangen.

Unternehmensführung ist treibende Kraft für Enterprise 2.0

Es wird deutlich: Die treibende Kraft bei der Einführung von Social Media ist das Management. Die Studie kommt ganz klar zu dem Schluss, dass der Top-Down-Approach ein erfolgskritischer Faktor ist. Auf dem Weg zur Etablierung von Social Media gibt es genügend Hürden zu überwinden – ohne Unterstützung von oben, ohne Strategie und ohne die notwendigen Ressourcen ist sie fast zum Scheitern verurteilt.

Interessant ist übrigens der Zusammenhang zwischen strategischem Ansatz und Unternehmensgröße: Der Top-Down-Approach wird vor allem von kleinen und mittleren Unternehmen mit bis zu 500 Mitarbeitern verfolgt. In größeren Unternehmen und Konzernen gehen die Impulse dagegen eher von einzelnen Mitarbeitern oder Abteilungen aus und werden später vom Management aufgegriffen.

Fazit

Für den Erfolg von Social-Software-Projekten ist die Integration der Unternehmensführung mit ausschlaggebend, die Studie erklärt den Punkt „Führungskräfte überzeugen“ zum ersten und essenziellen strategischen Schritt. Wie an dieser Stelle oft beschrieben und wie die Projekterfahrung zeigt, ist das Strong Backing from the Top ein erfolgskritischer Faktor vor allem hinsichtlich der Mitarbeiteraktivierung.

Nur wenn die Mitarbeiter das Gefühl haben, dass die Unternehmensführung hinter einem Tool steht, dass das Werkzeug ganz offenbar ernstgenommen und als strategisch wertvoll angesehen wird (weil das Management z.B. entsprechende Kapazitäten und Ressourcen zur Verfügung stellt), werden sie es ihrerseits ernstnehmen.

Haben Sie Fragen zum Einsatz von Social Media im Unternehmen? Möchten Sie wissen, wie Sie von neuen Kommunikationsformen profitieren können oder benötigen Sie Unterstützung bei einem laufenden Projekt? Wir sind Experten für Unternehmenskommunikation, bitte sprechen Sie uns an.

Weiterführende Informationen

Unsere spezielle Seite mit Informationen rund um Firmenwikis
Hype Cycle 2009: Wo stehen Cloud Computing, Social Media und Unternehmens-Blogs?
Social Software: Der Wikipedia-Irrtum
Micro-Blogging im Unternehmen: Potenziale und Anwendung
Social-Software-Projekte: Woran die Einführung scheitern kann

Das Team hat Fallbeispiele von 72 Unternehmen aus Deutschland, Österreich und der Schweiz recherchiert und untersucht, die Social-Media-Projekte realisiert haben. Die interessantesten Erkenntnisse:

• Das Konzept Enterprise 2.0 ist reif für den Breitenmarkt. Unternehmen aller Größen und aus allen Branchen nutzen Social Software in der internen Unternehmenskommunikation.
• Unternehmen, die auf Enterprise 2.0 setzen, können nicht nur die interne Vernetzung verbessern und ihre Flexibilität erhöhen, sondern sie erlangen auch handfeste Wettbewerbsvorteile.
• Oft behindern etablierte (IT-)Strukturen die Einführung neuer Tools. Es ist erfolgskritisch, diese Strukturen zu modifizieren.
• Eine erfolgreiche Einführung hängt weniger vom Tool an sich, als vielmehr von organisatorischen und unternehmenskulturellen Aspekten sowie den Anwendungsfällen ab.
• Die Mitarbeiteraktivierung und die Generierung einer kritischen Masse von Teilnehmern bilden den Schlüssel für einen großflächigen Rollout im Unternehmen.
• Das Vertrauen auf die sog. Graswurzelstrategie allein ist bei der Einführung selten zielführend. Vielmehr ist die Förderung durch die Unternehmensführung ein entscheidender Erfolgsfaktor.

Bevor diese Erkenntnisse ausführlich analysiert werden, geben wir die Antworten auf wichtige Fragen wieder, die im Rahmen der Studie gestellt worden sind.

Wofür nutzen Unternehmen Enterprise-2.0-Konzepte?

• Wissensmanagement: 65%
• Unternehmensinterne Kommunikation: 35%
• Marketing und PR: 33%
• Ideen- und Innovationsmanagement: 19%
• Projektmanagement: 17%
• Kunden- und Partnermanagement: 11%

In der ersten Welle von Social Media in Unternehmen haben sich die meisten Firmen auf den Aspekt Wissensmanagement und darauf konzentriert, Strukturen zu schaffen, innerhalb derer das Unternehmens-Know-how strukturiert abgebildet werden kann. Nach wie vor fallen im Zusammenhang mit Enterprise 2.0 also zuerst die Stichwörter Zusammenarbeit und Teilen von Informationen.

Künftig werden sich Firmen, so die Studie, jedoch verstärkt auch für den Einsatz von Social Media für das Ideen- und Innovationsmanagement, das Projektmanagement sowie das Kunden- und Partnermanagement interessieren. Hier sehen die Unternehmen noch erhebliche Potenziale.

Welche Ziele verfolgen Unternehmen heute mit Social Media?

• Informationsmanagement mit dem Ziel, Know-how zentral abzubilden und verfügbar zu machen.
• Kommunikationsmanagement mit dem Ziel einer effektiven und effizienten internen Kommunikation.
• Kollaborationsmanagement mit dem Ziel, die Zusammenarbeit zu verbessern und zu fördern.
• Identitäts- und Netzwerkmanagement mit dem Ziel, Transparenz und ein Bewusstsein für die Aktivitäten der Kollegen zu schaffen.

Unternehmen erwarten einen konkreten Return on Investment in Form zielgerichteter, effektiver Prozesse. In erster Linie soll wertvolles Mitarbeiterwissen zentral zugänglich sein und nicht verlorengehen. Vorrangiges Ziel ist es zudem, für jede kommunikative Tätigkeit bzw. jede Information einen möglichst effizienten Kommunikationskanal zu schaffen, dadurch sowohl Produktivität als auch Transparenz im Unternehmen zu erhöhen und so Marktvorteile zu erlangen.

Welche Social-Media-Tools bzw. -Konzepte setzen Unternehmen ein?

• Wikis 69%
• Blogs 61%
• Networking Communities 44%
• Micro-Blogging 35%
• Social-Evaluation-Tools 32%
• Podcasting 32%
• Videosharing 32%

Insbesondere Firmenwikis und Blogs haben sich inzwischen auf breiter Ebene durchgesetzt und mittlerweile (auch hinsichtlich der technologischen Ausgereiftheit professioneller Software) ein Stadium erreicht, in dem sie tatsächlich produktiv genutzt werden können. Zudem haben sich auch im Web angesagte mediale Ausprägungen wie Social Bookmarking, Micro-Blogging, Bewegtbild oder Podcasts zumindest in Form von Insellösungen in vielen Enterprise-2.0-Unternehmen etabliert.

In den folgenden Artikeln interpretieren wir wichtige Erkenntnisse und widmen uns einigen besonders interessanten Themen rund um Enterprise 2.0, die auch in der Studie aufgegriffen wurden, beispielsweise Einführungsstrategien und der Marktreife von Social Software.

Haben Sie Fragen zum Einsatz von Social Media im Unternehmen? Möchten Sie wissen, wie Sie von neuen Kommunikationsformen profitieren können oder benötigen Sie Unterstützung bei einem laufenden Projekt? Wir sind Experten für Unternehmenskommunikation, bitte sprechen Sie uns an.

Weiterführende Informationen

Unsere spezielle Seite mit Informationen rund um Firmenwikis
Hype Cycle 2009: Wo stehen Cloud Computing, Social Media und Unternehmens-Blogs?
Social Software: Der Wikipedia-Irrtum
Micro-Blogging im Unternehmen: Potenziale und Anwendung
Social-Software-Projekte: Woran die Einführung scheitern kann

Grundlegendes: Trennung von HTML, CSS und JavaScript

Leider sieht man heute immer noch Seiten, die dem Betrachter des Quelltexts einen kalten Schauer über den Rücken jagen. Bunt gemischt stehen hier HTML, Style-Anweisungen (CSS) und JavaScript-Blöcke. Dies beeinflusst die Ladezeit erheblich. Deshalb an dieser Stelle: HTML, CSS und JavaScript müssen getrennt voneinander in eigenen Dateien stehen.

Dies sollte die grundlegende Herangehensweise eines Web-Entwicklers sein. Zum besseren Verständnis ein Vergleich: Ein Auto muss vier Räder und ein Lenkrad haben, um nicht in der ersten Kurve liegen zu bleiben. Es geht also um Grundvoraussetzungen. Nun zum, sagen wir: Sport-Tuning.

Zauberwort HTTP-Requests

Im Mittelpunkt der Optimierungsversuche sollten zunächst einmal die HTTP-Requests stehen, also die Anzahl der Anfragen, die der Browser an den Server stellt. Der Aufbau dieser Kommunikation dauert mitunter länger als die tatsächliche Übertragung der Daten. Ziel muss es also sein, die Anzahl dieser Requests auf ein Minimum zu reduzieren. Wie erreichen wir das? Betrachten wir drei Methoden, mit denen Sie der Ladezeit Ihrer Website einen Kick verpassen können.

CSS-Sprites
Eine Technik zum Einsparen von Requests sind sog. CSS-Sprites. In das Layout einer Website werden viele Grafiken und Bilder eingebunden, um die gewünschte Darstellung zu erreichen. Diese Grafiken werden zumeist einzeln geladen und benötigen so jeweils eine eigene Server-Anfrage.

Mithilfe der Sprite-Technik werden diese Grafiken nun in eine einzige Grafik integriert. Diese Grafik wird durch CSS dann jeweils an der richtigen Stelle positioniert. Das kann man sich wie eine Maske vorstellen, hinter der diese Grafik verschoben wird, sodass immer nur der gewünschte Teil sichtbar ist. Die Anzahl der HTTP-Requests lässt sich mit dieser Technik deutlich verringern.

Zu beachten ist, dass sich CSS-Sprites hervorragend für kleine Grafiken wie etwa Pfeile, Listenpunkte, Rahmen, Hintergründe oder Schattierungen eignen. Hochauflösende Fotografien oder andere größere Grafiken in ein Sprite zu stecken, ist aufgrund der enormen Dateigrößen wiederum nicht ratsam.

Mehrere Server
Der Browser, oder genauer das HTTP-Protokoll, baut nur eine begrenzte Anzahl an Verbindungen zu einem Server auf und arbeitet diese ab. Mit mehreren Servern kann es allerdings parallel kommunizieren. Deshalb ist es sinnvoll, gerade statische Dateien wie Grafiken oder CSS-Stylesheets auf einen eigenen Server auszulagern, der unter einer eigenen (Sub-)Domain zu erreichen ist (etwa img.ihre-domain.de), um auf diese Weise Ladezeiten einzusparen. Die verfügbare Bandbreite wird so optimal ausgenutzt.

JavaScript
Gerade in Zeiten von Mashups, Ajax und RIAs erfreut sich JavaScript großer Beliebtheit. Dies führt oft zu einer Vielzahl an Scripten aus verschiedenen Quellen. Oftmals ist entscheidend, an welcher Stelle JavaScripte eingebunden und in welcher Reihenfolge diese ausgeführt werden.

Prinzipiell empfiehlt es sich, Java-Scripte möglichst vor dem schließenden Body-Tag einzubinden. Auf diese Weise verringert sich die gefühlte Ladezeit für den Nutzer. Gerade beim Einbinden externer Scripte wie etwa Google Analytics sollte man dies berücksichtigen. Für Stylesheets gilt übrigens das genaue Gegenteil: CSS-Dateien werden optimalerweise möglichst im HTML-Head eingebunden, um das Rendern der Seite frühestmöglich zu gewährleisten.

Fazit

Diese Grundregeln gehören heute zum Handwerkszeug von Web-Entwicklern – oder sollten es zumindest. Wer sie befolgt, tut dies natürlich nicht zum Selbstzweck, sondern verschafft Usern durch eine technologisch einwandfreie Website angenehme Nutzererlebnisse und senkt die Gefahr von Nutzungsabbrüchen aufgrund schlechter Performance. Gleichzeitig sorgt eine sauber organisierte Code-Basis für Übersichtlichkeit und senkt dadurch die Kosten bei späteren Anpassungen. Und nicht zuletzt: Gerade hat Google darüber informiert, dass nunmehr auch die Ladezeit zur Einstufung einer Website herangezogen wird und unmittelbar in die Ermittlung des Rankings einfließt. Insofern ist ein hochwertiges technologisches Fundament auch ein SEO-Faktor.

Haben Sie Fragen? Suchen Sie Wege, um die Performance Ihrer Website zu optimieren, und benötigen dafür technologisches Know-how? Die Experten von //SEIBERT/MEDIA/TECHNOLOGIES helfen Ihnen gerne, bitte sprechen Sie uns an.

Weiterführende Informationen

Expectional Performance im Developer Network von Yahoo!
Tipps und Tricks für schnellere Websites
Die Website von //SEIBERT/MEDIA/TECHNOLOGIES

Funktionalitäten: Was bringt das Update?

Am Anfang steht die Evaluation, welche neuen Funktionalitäten das Update bietet. Werden Software-Fehler behoben, die im Unternehmen bekannt sind und die Mitarbeiter bereits angesprochen haben? Schafft es neue Funktionalitäten, die als nutzenbringend einzuschätzen sind? Oder handelt es sich vielmehr um ein Update, das nicht direkt zu einer konkreten Nutzenerweiterung führt, sondern das eher indirekt sinnvoll ist, zum Beispiel in Hinblick auf Sicherheit, Stabilität oder Performance?

Freilich gibt es Systeme, bei denen die Verbesserung gerade dieser Aspekte einen besonderen Nutzen für den Kunden darstellt, etwa weil das System besonders instabil ist oder weil das Unternehmen ein besonders großes Sicherheitsbedürfnis hat. In einem solchen Fall wäre natürlich die Ankündigung, dass das System fortan beispielsweise um zehn Prozent schneller sein wird, sehr interessant und sicherlich ein überzeugender Update-Grund. Eine pauschale Aussage ist hier aber kaum möglich.

Nachdem geklärt ist, welche Änderungen Bestandteile des Software-Updates sind und welchen individuellen Nutzen das Unternehmen davon hat, sollte nun geprüft werden, ob es sich um ein Major- oder Minor-Update oder vielleicht „lediglich“ um ein Patch handelt. Hier ist die Analyse der Versionsnummer sinnvoll.

Große Releases: Auf den ersten Patch warten?

Ein Major-Update geht in der Regel mit einem Sprung in der Versionsnummer einher. Selten werden für Major-Updates auch kleine Versionsnummern-Sprünge definiert, gängig sind Updates bspw. von Confluence 2.9. auf 3.0 oder von 3.0 auf 3.1. oder von Jira 3.1. auf Jira 4.0.

Nun gibt es allerdings eine ungeschriebene IT-Regel: Warte den ersten Patch ab, bevor das Update vorgenommen wird. Das ist nicht unbegründet: Ein Major-Update führt zu großen und möglicherweise sogar umwälzenden Änderungen. Dabei entstehen häufig auch Fehler und Probleme, die anschließend behoben werden müssen.

Nach jedem Major-Update gibt es deshalb nach relativ kurzer Zeit ein sogenanntes Patch Release, das die kritischsten Fehler behebt. Viele IT-Verantwortliche wollen daher zumindest den ersten Patch nach einem Major-Update abwarten.

Auch stellen sich hier wieder Fragen nach den zu erwartenden Vorteilen: Welcher zusätzliche Nutzen entsteht? Sind wir bereit, für diesen Nutzen ein paar Fehler in Kauf zu nehmen oder möchten wir auf keinen Fall Fehler im System haben? Das ist eine individuelle und sehr unternehmensspezifische Entscheidung.

Deshalb kann man auch nicht grundsätzlich sagen, dass es nicht sinnvoll ist, ein Major-Update sofort zu installieren, und dass man zunächst auf den ersten Patch warten muss. In der Praxis wird es aber häufig genau so gehandhabt.

Aufwand: Wie hoch sind die technischen Anforderungen?

Darüber hinaus müssen Informationen darüber eingeholt werden, welche technischen Anforderungen ein Software-Update stellt – nicht einfach für Unternehmen, die ein System erst kürzlich implementiert haben. Hier lohnt es sich, Beratung durch einen Dienstleister in Anspruch zu nehmen, der sich mit Unternehmenskommunikation und den wichtigen Systemen gut auskennt.

Anders liegt der Fall, wenn schon Updates vorgenommen wurden. Auf Basis dieser Erfahrung lässt sich der Aufwand in der Regel zumindest grob abschätzen: Wenn der Hersteller nicht explizit darauf hinweist, dass bspw. neue Datenbanken oder technische Umstellungen erforderlich sind, kann man davon ausgehen, dass der Zeitaufwand auch beim aktuellen Update nicht größer sein wird als beim letzten.

Da mit einem Software-Update aber gerade in großen Unternehmen und Konzernen mitunter sehr komplexe Prozesse einhergehen, kann freilich auch der Zeitaufwand unter Umständen relativ hoch sein.

Kosten: Rechtfertigt der Nutzen sie?

Nun muss sich der zu erwartende Nutzen an den entstehenden Kosten messen lassen. Dazu gehört in erster Linie die Entscheidung, ob das Software-Update intern oder extern durchgeführt werden soll und ob die dafür jeweils benötigten Ressourcen vorhanden sind. Der Aufwand, der für die Änderung betrieben werden muss, muss konkret eingeschätzt werden: Können wir die neue Version einfach einspielen? Ist ein Testsystem vorhanden? Sind noch eigene Tests an diesem Testsystem nötig? Und: Wie viele Mitarbeiter nutzen das System eigentlich?

Das sind Informationen, die in die Kostenbetrachtung einfließen müssen. Hier empfiehlt es sich, einen Schätzwert zu ermitteln und eine Kosten-Nutzen-Analyse vorzunehmen. Ein signifikanter Mehrwert sollte durch ein Update natürlich schon entstehen.

Bei Atlassian-Systemen wie Confluence und Jira ist in besonderer Weise zu berücksichtigen, dass Update-berechtigt nur Unternehmen sind, die auch einen laufenden Wartungsvertrag mit Atlassian haben. Das heißt: Nach dem Kauf der Software-Lizenz kann der Kunde zwölf Monate lang Updates vornehmen, dann ist zunächst Schluss. Der Update-willige Kunde muss seine Lizenz um weitere zwölf Monate verlängern. Die Kosten belaufen sich im Fall von Atlassian auf die Hälfte der Erstlizenz (siehe Preise für Confluence und Jira). Ähnliche Lizenzmodelle verfolgen auch viele andere Hersteller von kommerzieller Unternehmens-Software.

Auch dieser Aspekt muss also in die Kostenschätzung einfließen: Vielleicht ist das Wartungsfenster inzwischen geschlossen und erst eine neue Wartungslizenz fällig, um das Update durchführen zu können?

Übrigens: //SEIBERT/MEDIA gewährt Ihnen zehn Prozent Natural-Rabatt, wenn Sie Atlassian-Lizenzen über uns abschließen. Das gilt auch für die Verlängerung von Wartungsverträgen.

Updates: Option oder Pflicht?

Bei allen berechtigten betriebswirtschaftlichen Abwägungen für oder wider ein Software-Update, gibt es aber auch gewisse Pflichten: Es ist nicht empfehlenswert und im Sinne eines funktionierenden Systems auch nicht gangbar, etwa drei Mal in Folge auf ein Update zu verzichten, weil der Nutzenanstieg im Vergleich zum vorangehenden Update angesichts entstehender Kosten zu gering erscheint.

Früher oder später entstehen dann nämlich tatsächlich signifikante Betriebsrisiken, die eben jene Faktoren Sicherheit, Stabilität und Performance betreffen. Bei jedem Update muss die Entscheidung ggf. also unter Berücksichtigung der (ausgelassenen!) Vorgängerversion und ihrer Features, die nicht mitgenommen wurden, getroffen werden.

Faustregel: Spätestens nach drei Auslassungen nachziehen

Jedes Unternehmen hat spezifische Anforderungen und Voraussetzungen. Grundsätzlich  gelten aber diese Faustregeln:

• Als Unternehmen kann man ein einzelnes Update gewiss überspringen, und man muss sicherlich nicht jeden einzelnen Patch dritten Grades (3.1.x oder 4.2.x) mitnehmen.
• Nach der zweiten, spätestens aber nach der dritten ausgelassenen Version empfiehlt es sich allerdings dringend, nachzuziehen und sein System auf den aktuellen Stand zu bringen.
• Je kleiner Updates sind, desto eher können sie ausgelassen werden. Bei Major Releases dagegen ist es in der Regel so, dass die funktionalen Erweiterungen so interessant sind, dass spätestens nach Verfügbarkeit des Patches auch ein Update interessant ist.

Haben Sie Fragen zu Social Media, Wikis oder Aufgabenmanagement-Systemen im Unternehmen? Möchten Sie Social Software einführen oder benötigen Sie Unterstützung bei einem laufenden Projekt? Fragen Sie Experten für Unternehmenskommunikation, bitte sprechen Sie uns an.

Weiterführende Informationen

Wiki-Zusatzleistungen von //SEIBERT/MEDIA
Social-Software-Projekte: Woran die Einführung scheitern kann
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Aufgabenmanagement: Argumente für Jira

Das Wiki nicht als Instrument zur Leistungsmessung missverstehen

Eine von vielen Betriebsräten vorgebrachte Befürchtung ist die, dass das Wiki als Instrument der Leistungsmessung missbraucht werden könnte. In diesem Zusammenhang besteht der zunächst verständliche Wunsch, dass Mitarbeiter anonym im Wiki arbeiten und auch anonym auf die Inhalte zurückgreifen können sollen.

Dies ist natürlich auch möglich – aber es steht der wichtigen Mitarbeiteraktivierung entgegen. Die Erfahrung aus zahlreichen Wiki-Projekten zeigt, dass Mitarbeiter nur dann gewillt sind, sich in das Wiki einzubringen, wenn sie auch einen eigenen Benutzer haben. Die Aktivität im Wiki nimmt signifikant zu, wenn die Aktivitäten konkreten Personen zugeordnet werden können. Und das ist auch logisch: Natürlich möchte ein Mitarbeiter für seinen hochwertigen Input auch die verdiente Anerkennung ernten. Das ist aber nur möglich, wenn Inhalte personalisiert sind.

Um die Befürchtung der Leistungsmessung zu zerstreuen, hat das Unternehmen die Möglichkeit, das Wiki so zu konfigurieren, dass keine statistische Auswertung auf personalisierter Ebene möglich ist, die das Management für Leistungsvergleiche heranziehen könnte, dass also nicht ausgewertet werden kann, wer wieviele Wiki-Inhalte beigesteuert hat.

Unbegründet: Angst vor Mitarbeiterüberwachung per Wiki

Häufig wird eine Gefahr darin gesehen, dass sämtliche Änderungen im Wiki nachvollzogen werden können. Diese Befürchtung ist jedoch gegenstandslos. Wikis sind so aufgebaut, dass ersichtlich ist, wer wann was an welchem Dokument bearbeitet hat – die Betonung liegt auf Dokument. In der Praxis lässt sich gar nicht feststellen, wer wann welche Änderungen im Wiki, sondern nur wer welche Änderungen in einem konkreten Dokument vorgenommen hat. Wiki-weite Änderungen auf Personenebene lassen sich nicht systematisch nachvollziehen.

Die dokumentenspezifische Revisionshistorie wird geführt, um nachvollziehen zu können, ob eine Modifikation inhaltlich sinnvoll ist. In der Theorie kann dies kritisiert werden, in der Realität ist eine Leistungsüberwachung allerdings nicht möglich und die Befürchtung, dass sämtliche Schritte der Mitarbeiter überwacht werden, unbegründet.

Eigene Inhalte kommunizieren und Unternehmenskultur positiv beeinflussen

Das Wiki bietet dem Betriebsrat eine ausgezeichnete Möglichkeit, die eigenen Informationen im Unternehmen zentral und aktuell zugänglich zu machen und zu kommunizieren. Tatsächlich nutzen Betriebsratsmitglieder das Wiki erfahrungsgemäß sehr intensiv.

Und darüber hinaus erhalten Mitarbeiter durch das Wiki deutlich mehr Einfluss und können Prozesse aktiv mitgestalten. Der in vielen Unternehmen etablierte sog. Top-down-Ansatz wird durch einen Bottom-up-„Approach“ zwar nicht abgelöst, aber doch durch einen kommunikativen Kreislauf ersetzt. Gerade deshalb sollte der Betriebsrat sich für eine frühe Einbindung in ein Wiki-Projekt engagieren, um so auf die Weiterentwicklung der internen Kommunikation Einfluss zu nehmen.

Datenschutz sicherstellen

Sicherlich birgt ein Wiki auch Gefahren für die Rechte der Arbeitnehmer. Oft wird ein Wiki für Business-Intelligence-Zwecke eingesetzt, personalrelevante Daten und Statistiken werden also im Wiki erfasst und abgelegt und über eine Rechtestruktur geschützt.

Die Rechte müssen korrekt eingestellt sein, damit gewährleistet ist, dass keine Unbefugten Daten über andere Mitarbeiter einsehen können. Hierbei kann ein erfahrener Wiki-Dienstleister wie //SEIBERT/MEDIA wertvolle Unterstützung bieten und helfen, die Einhaltung strenger Datenschutzauflagen sicherzustellen.

Verantwortung wahrnehmen: Wiki-Einführung als taktisches Mittel

Normalerweise hat das Management ein großes Interesse daran, ein Wiki voranzutreiben – sonst würde es keines einführen. Anderen Wikis wiederum fehlt es am sogenannten „Strong Backing from the Top”, etwa wenn eine einzelne Abteilung ein Wiki eingeführt hat und einen größerflächigen Rollout anregt, dessen Nutzen vom Management bezweifelt wird.

Wenn der erste Fall Realität ist, ist der Betriebsrat (wie bei jedem anderen EDV-System auch) in der Position, Forderungen zu stellen und die Zertifizierung und Unterstützung mit in die Verhandlungswaagschale zu werfen. Hierbei muss der Betriebsrat allerdings sehr vorsichtig sein: Sind die systemischen Vorteile evident? Doch er hat grundsätzlich die Möglichkeit, die Einführung des Systems genauer unter die Lupe zu nehmen, das Wiki z.B. im Rahmen von Tarifverhandlungen eingehend zu prüfen und es quasi in „Sippenhaft“ zu nehmen.

Im zweiten Fall – wenn das Management also nicht davon überzeugt ist, dass es sich bei einem Wiki um das richtige Instrument für das Unternehmen handelt – sollte der Betriebsrat die ihm obliegende Verantwortung kennen. Stellt man sich quer, schnürt man dem System, dem es ohnehin schon an Unterstützung mangelt, nicht nur zusätzlich die Luft ab, sondern agiert auch kaum im Sinne der Kollegen, die das Wiki bereits als tolles Werkzeug schätzen gelernt haben: Der Betriebsrat würde sich gewissermaßen selbst ins Bein schießen und sich zudem der beschriebenen Vorteile berauben. Wenn sich der Betriebsrat hier widersetzt, wird es höchstwahrscheinlich gar kein Wiki geben.

Für die Ermächtigung der Mitarbeiter ist ein Wiki allerdings sehr hilfreich und daher im ureigenen Interesse der Mitarbeitervertretung.

Die Wiki-Einführung hat also durchaus eine politische Dimension und kann als taktisches Mittel eingesetzt werden. Dieser Verantwortung sollte der Betriebsrat sich bewusst sein und ebenso maßvoll wie weitsichtig agieren.

Zusammenfassung

Zusammenfassend sind aus Sicht des Betriebsrats diese Maßnahmen und Aktivitäten bei der Wiki-Einführung sinnvoll:

• Proaktives Engagement für ein Firmenwiki
• Einrichtung eines eigenen Wiki-Bereichs, in dem eigene Informationen zur Verfügung gestellt werden
• Die Berücksichtigung von Nutzernamen ist im Sinne einer selbstbewussten Belegschaft
• Weitsichtiger Einsatz der Wiki-Einführung als taktisches Mittel
• Unterstützung des Wikis aus rein systemischer Sicht, da es die Ermächtigung der Mitarbeiter unterstützt

Haben Sie Fragen zur Wiki-Einführung oder benötigen Sie organisatorische Unterstützung bei einem laufenden Projekt? Gehören Sie zum Betriebsrat? Sind Sie Mitglied der Unternehmensführung? Wir sind Experten für Unternehmenskommunikation sowie Firmenwikis und helfen Ihnen gerne, bitte sprechen Sie uns an.

Weiterführende Informationen

Unsere spezielle Seite zum Thema Firmenwikis
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen und Informationsquellen
Strategische Wikis und Unternehmenswikis im Tagesgeschäft: eine wichtige Unterscheidung

1. Verstellen Sie sich nicht

Authentizität ist ein wichtiges Prinzip in sozialen Netzwerken. Einerseits honoriert Ihre Zielgruppe einen authentischen Auftritt, andererseits erkennt sie Aufgesetztheit sehr schnell und straft Sie mit entsprechender Nichtbeachtung Ihrer Person bzw. Marke.

2. Werden und bleiben Sie aktiv

Dieser Rat spielt weniger darauf an, eine Zeit X auf einem Portal Y zu verbringen. Vielmehr ist wichtig, die richtigen Dienste zu nutzen und kontinuierlich am Ball zu bleiben. Die vier wichtigsten Namen sind Facebook, Twitter, LinkedIn und Xing. Sollten Sie nicht mindestens diese vier Dienste nutzen, müssen Sie um die Effektivität Ihrer Aktivitäten fürchten. Ihr Zielpublikum bewegt sich im Web auch auf anderen Wegen? Dann müssen Sie auch dort sein, um mit ihm in Kontakt treten zu können.

3. Bieten Sie guten Inhalt an

Sein Sie ehrlich zu sich selbst. Wenn Sie Ihr eigener Kunde wären – würden Ihre Inhalt Sie selbst ansprechen? Die Beantwortung dieser Frage ist nicht einfach und wird einige Zeit in Anspruch nehmen. Sie sollten diese Investition allerdings tätigen, denn was nicht interessiert, wird nicht wahrgenommen und auch nicht weiterverbreitet.

4. Investieren Sie Ihre Zeit effizient

Social Media birgt eine Menge Potenzial für Ihr Unternehmen. Einen positiven Effekt erzielt aber nur, wer sich auch intensiv mit der Materie beschäftigt. Vor allem ist ein effizientes Vorgehen entscheidend, denn Ihre limitierende Variable ist Ihre Zeit. Gehen Sie unstrukturiert vor, wird soziales Netzwerken mehr Zeit beanspruchen, als Sie eigentlich zur Verfügung haben. Das können Sie vermeiden, indem Sie ein konsequentes Monitoring durchführen und Ihre Aktivitäten bündeln. Mögliche Dienste hierfür sind beispielsweise ping.fm oder tubemogul.com.

5. Konsistenz ist Trumpf

Fokussieren Sie sich auf den Kern Ihrer Persönlichkeit bzw. Ihrer Marke und vermeiden Sie einen zu universellen Ansatz Ihrer Aktivitäten. Wenn Sich sich heute als Spezialist für Gesundheitsfragen profilieren und morgen durch eine Tweet-Serie mit Steuertipps glänzen wollen, wird man Ihnen mit verständlicher Skepsis begegnen. Etablieren Sie sich online so konsistent und seriös, wie Sie es auch offline tun.

6. Reden ist Silber, über andere reden ist Gold

Sie haben guten Content? Dann reden Sie darüber! Sprechen Sie aber auch über den guten Content anderer Leute, sofern es sich nicht gerade um Ihre größten Konkurrenten handelt. Wer nur über sich selbst redet, macht sich schon im normalen Leben auf Dauer wenig Freunde – warum sollte es dann im Netz anders sein? Wenn Sie guten eigenen Content vorzuweisen haben und parallel dazu auch über die guten Inhalte anderer berichten, bekommen Sie nicht nur mehr Aufmerksamkeit, sondern sind zudem glaubwürdig.

7. Netzwerken von Angesicht zu Angesicht

Für eine langfristige Wertschöpfung sollten Sie Ihre Kontakte nicht ausschließlich als digitales Portfolio verwalten. Nutzen Sie die Möglichkeit, fachspezifische Konferenzen oder Tagungen zu besuchen und Ihre Kontakte zu treffen. Social Media hilft Ihnen, Ihre Zeit durch vorherige Terminabstimmung sinnvoll zu planen und Entscheidungen durch gezielte Kommunikation vorzubereiten. Letztendlich ist in vielen Fällen aber immer noch der persönliche Kontakt ausschlaggebend für den Erfolg Ihrer Online-Tätigkeiten.

8. Danken Sie anderen

In den meisten Fällen werden Sie auf Ihrem Weg zum Social-Media-Olymp Helfer haben. Nutzen Sie jede Möglichkeit, um diesen Personen für Support und Inspiration zu danken. Auch dies wird sich positiv auf Ihre weiteren Aktivitäten auswirken.

Wenn Sie diese Tipps beherzigen, werden Sie früher oder später die Früchte Ihrer Arbeit ernten. Um unsererseits konsistent zu bleiben, möchten wir in diesem Zusammenhang noch einmal Lewis Howes für den wertvollen Input danken.

Haben Sie Fragen zum Einsatz von Social Media in der externen oder internen Kommunikation? Wir sind Experten für Unternehmenskommunikation und beraten Sie gerne. Bitte sprechen Sie uns an.

Weiterführende Informationen

Facebook: Potenziale für Unternehmen und Aussichten
Hype Cycle 2009: Wo stehen Cloud Computing, Social Media und Unternehmens-Blogs
Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann

Einheitliche Aufbereitung aller Dokumente ist unmöglich

Häufig werde ich von Kunden gefragt, ob man nicht irgendwie sicherstellen kann, dass alle im Wiki befindlichen Dokumente richtig eingeordnet, kategorisiert und verschlagwortet werden. Dies ist in Wikis nämlich häufig nicht der Fall und eigentlich sollte man dieses Thema daher intensiv verfolgen. Meine Antwort auf diese Frage lautet dennoch: Nein!

Tagging, Verschlagwortung oder Kategorisierung sind zusätzliche Möglichkeiten, um die Auffindbarkeit von einzelnen Dokumenten zu verbessern. Es ist meines Erachtens aber nicht möglich, eine einheitliche Qualität von Inhalten in einem internen System wie dem Wikis zu erreichen: Immer wird es hochqualitativen Content auf der einen und grobe, unfertige Entwürfe auf der anderen Seite geben. Der Versuch, sämtliche Dokumente auf ein einheitliches Niveau zu heben – und sei es nur durch Kategorisierung, Verschlagwortung oder die Formatierung der Überschrift – ist in der Realität zum Scheitern verurteilt.

Existenz von Inhalten ist wichtig, nicht Form

In einem Wiki zählt vielmehr, dass die bisher nicht digital und zentral erfassten Informationen überhaupt verfügbar sind und von allen Beteiligten eingesehen werden können. Die meisten Unternehmen sind froh, wenn Inhalte und Konzepte einfach zentral und für alle transparent dokumentiert werden. Es ist aus meiner Sicht ein sinnvolles Opfer, zunächst auf die Kategorisierung und die Verschlagwortung von Dokumenten zu verzichten. Befindet sich der Content erst einmal im Wiki, kann die Pflege der Informationen nachgeholt werden, dafür gibt es beispielsweise sog. Wiki-Gärtner im Unternehmen.

Das eingangs angesprochene Prinzip muss im Zusammenhang mit Wikis also teilweise revidiert werden. Zu Beginn eines Wiki-Projektes ist die digitale, zentrale Existenz von Informationen deutlich wichtiger als formale Qualität. Um diese kann und sollte man sich erst später kümmern.

Das heißt natürlich nicht, dass es nicht weiterhin sehr wichtig ist, dass die im Wiki existenten Inhalte hochwertig sind. Es geht hier um die formale Aufbereitung, nicht um die inhaltliche Güte.

Wie sind Ihre Erfahrungen mit den Anforderungen Inhaltsmenge, hohe Qualität und korrekte formale Aufbereitung?

Weiterführende Informationen

Unsere spezielle Seite zum Thema Firmenwikis
Neue Wiki-Dokumente richtig anlegen: Wo und wie einsortieren?
Strukturieren von Inhalten: Facettenklassifikation und Tagging
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen und Informationsquellen
Strategische Wikis und Unternehmenswikis im Tagesgeschäft: eine wichtige Unterscheidung

An zahllosen Stellen im Web und auch in diesem Blog ist immer wieder die Rede von der Bedeutung von Usability und der Notwendigkeit eines professionellen Designs für Unternehmen, die im Internet erfolgreich sein und Umsatz generieren wollen. Und man möchte meinen, inzwischen hätten alle Unternehmen zumindest schon einmal davon gehört, dass Nutzerfreundlichkeit und Design Erfolgsfaktoren sind.

Doch weit gefehlt, denn nach wie vor gibt es zahlreiche wahrlich unerschrockene Firmen, die (unfreiwillig) auf Schocktherapie setzen. Wir haben uns einmal umgesehen und stellen Ihnen zehn kommerzielle Websites vor, die es in sich haben – ein Kuriositätenkabinett mit Augenzwinkern. (Um die Websites aufzurufen, klicken Sie die Screenshots an, die Links öffnen im neuen Tab.)

Platz 10: Dinghyinsurance.com

Konservative Zurückhaltung in Sachen Layout ist auf der Website der W. H. Insurance Consultants Trumpf. Den Unterschied macht jedoch das revolutionäre Navigationskonzept: Ein Alleinstellungsmerkmal wird nämlich dadurch geschaffen, dass unterstrichene Wörter hier einmal keine Links sind. (Sie müssen schon auf die gelb-schwarzen Buttons klicken.) Allein deshalb hat dinghyinsurance.com einen Platz in dieser Liste redlich verdient.

Platz 9: Stexps.com

„Back to the Roots“ heißt es auch auf der Website des Sarasota-Tampa-Express stexps.com. Doch nicht der (fast) konsequent durchgezogene Retro-Stil, nicht die Inverted-L-Navigation mit den gleichen Links im vertikalen und im horizontalen Menü, nicht der animierte Cursor, der eine wogende Schlange roter Buchstaben in einer anderen Schriftart hinter sich herzieht, nicht die in spacigen Regenbogenfarben blinkenden NEW-Elemente haben uns überzeugt, sondern das unübertrefflich hektische FlightView-Widget rechts, das Sie sich gerne auch als Bildschirmschoner herunterladen können.

Platz 8: CWOL.com

Wenn Websites aussehen wie das Faltblatt des 1-Euro-Marktes am Ende der Fußgängerzone, das man im Briefkasten findet, schlagen Designer-Herzen naturgemäß höher. Zudem sorgt der Web-Auftritt der Technikfachleute von CWOL dafür, dass nicht nur die Preise den Nutzer in erhöhte Alarmbereitschaft versetzen, sondern auch das Farbkonzept.

Platz 7: 5safepoints.com

Zwar pfeifen die Leute der 5 Points Driving School unter anderem auf ein homogenes Bild- und Typografiekonzept, dafür berücksichtigen sie zwei andere interessante Usability- und Design-Erkenntnisse: 1) Heute haben User kein Problem mehr damit, nach unten zu scrollen. 2) Weißraum sorgt für Ruhe. Das nimmt man sich auf 5safepoints.com zu Herzen und verbindet dieses Wissen kongenial – lassen Sie sich überraschen! (Und wenn Ihnen das zu ruhig ist, können Sie Ihren Geist auf dieser Unterseite wieder in Schwung bringen.)

Platz 6: Videosoniclab.com

Eine Zeitreise in die Gründerzeit des Internets erwartet den Nutzer auf der Website von Videosonic, wobei gemütlichem Schwarz tatsächlich eine zentrale Bedeutung zukommt. Auch interessant: Die Buttons im linken Bereich sind zwar nicht anklickbar, sorgen aber beim genaueren Betrachten für Kopfschmerzen. Einen Blick wert ist zudem der Online-Shop.

Platz 5: Webking.com

Zum Dienstleistungsumfang der Web King Internet Services LLC gehören nicht nur Online-Marketing, E-Commerce-Expertise und Hosting, sondern auch Web-Design. Hier muss die eigene Website natürlich als Referenz herhalten. Ein Klick auf den entsprechenden Menüpunkt hat den schönen Nebeneffekt, dass man seinen künftigen Dienstleister gleich einmal persönlich kennenlernt – eine wichtige vertrauensbildende Maßnahme und Grundlage für eine enge, fruchtbare Zusammenarbeit.

Platz 4: Lingscars.com

An Ideen mangelt es nicht: Zunächst klettert uns Autohändlerin Ling vom Header entgegen. Und was es nicht noch alles zu entdecken gibt! Live-Chat, Twitter-Integration, Office-TV, ein Quiz, ein ominöses Game namens „Hang Me“, es blinkt und flackert an allen Ecken und Enden … man könnte sich wahrscheinlich stundenlang auf dieser Website amüsieren. Das ist alles so cool und offensichtlich gutgemeint, dass wir lingscars.com nur sehr schweren Herzens in diese Liste aufnehmen und das leise Gefühl haben, dieser ambitionierten Dame unrecht zu tun.

Platz 3: Yvettesbridalformal.com

Man muss sich schon etwas Zeit nehmen, um herauszufinden, was Yvette nun genau verkauft. Nach einigen (von zentralasiatischen Klängen begleiteten) Klicks findet man immerhin heraus, dass Yvette nicht nur einen Shop betreibt, sondern offenbar auch Plätzchen liebt: Irgendwo gibt es eine Seite mit Rezepten (die leider nach fünfminütiger Suche nicht wiederzufinden ist und deshalb hier nicht verlinkt werden kann). Ohne diese Anleitungen eingehender studiert zu haben, drängt sich angesichts der Website der Verdacht auf, dass sich unter den Zutaten für die Kekse auch die eine oder andere … sagen wir bewusstseinserweiternde Substanz befindet. Wie dem auch sei: Unser dritter Platz geht an yvettesformalbridal.com.

Platz 2: Arngren.net

Nur haarscharf am ersten Platz schrammt arngren.net vorbei. Beim Aufrufen der Seite stellt sich nur eine einzige Frage: Meinen die das ernst oder ist das ein Scherz? Ja, die meinen das ernst.

Platz 1: Havenworks.com

Sicherlich ist Content nach wie vor King. Doch wie teasert man das gesamte politische Wissen der Welt auf einer einzigen Web-Page an? Diese Frage beantwortet unser Sieger havenworks.com. Nehmen Sie sich gefühlte fünf Minuten Zeit für den Ladeprozess – auch Ihnen werden anschließend wahrscheinlich die Worte fehlen

Kennen Sie weitere Beispiele?

Dies sind zehn eindrucksvolle Beispiele dafür, wie blauäugig auch heute noch manche Unternehmen im Web zugange sind und wie man Potenziale und Geld mit vollen Händen zum Fenster hinauswerfen kann. Wir wollen gewiss nicht hämisch sein oder hochnäsig wirken – manchmal verschlägt es einem aber eben schier die Sprache, wenn man durchs Web surft …

Oder sind manche dieser Seiten vielleicht sogar schon wieder so strange, dass sie innovativ sind? Kennen Sie andere kuriose Beispiele, die unter Mottos wie „… hat sich bemüht …“ oder auch „… ist dieser Zeit voraus …“ stehen? Wir freuen uns auf Ihre inspirierenden Hinweise, bitte nutzen Sie die Kommentarfunktion unten.

Gerade der Domain-Name ist ein Aushängeschild für Unternehmen und Organisationen im Web. Mit der eigenen Website wird allerorten geworben, sie wird in E-Mail-Signaturen, in Broschüren und auf Kugelschreibern erwähnt (dazu später mehr). Umso erstaunlicher ist es, unter welch unfreiwillig haarsträubenden URLs einige vollkommen seriöse Firmen und Institutionen im Netz vertreten sind: Insbesondere fehlende Bindestriche und unbedacht gewählte Abkürzungen sorgen sowohl für Erheiterung als auch für Kopfschütteln.

Wir haben einige kuriose, bizarre und auch wirklich peinliche Beispiele aus aller Welt dafür gefunden, wie Unternehmen sich mit der eigenen URL in die Nesseln setzen können. Damit möchten wir sicherlich niemandem zu nahe treten. Doch es lohnt sich nach wie vor, eine gute, alte Faustregel zu beherzigen: Erst nachdenken, dann registrieren.

Platz 11: Technik mit Nerv-Potenzial

Die Firma Diener Veranstaltungstechnik sorgt nicht nur für ordentlich Power unterm Disco-Dach, sondern hat sich auch eine griffige Abkürzung für das zweite Wort im Unternehmensnamen ausgedacht. Bleibt zu hoffen, dass man es insbesondere in Sachen Lautstärke nicht übertreibt und die Gäste dadurch in die Flucht schlägt, wie die URL der Website impliziert: http://www.dienervt.de.

Platz 10: Blockhütten und bloggende Friseure

Englische Wortgruppen, in denen Apostrophe vorkommen, und URLs sind natürliche Feinde, wie die Internet-Präsenz des Kleinunternehmens Old Man’s Haven charmant belegt, das ebenso gemütliche wie komfortable Blockhütten in den urwüchsigen Hocking Hills vermietet. Liest man nämlich die URL, könnte man ebenso meinen, ein tüchtiger Barbier betriebe einen Blog, in dem sich alles um seinen rüstigen Stammkunden dreht, den rasierten alten Mann: http://www.oldmanshaven.com.

Platz 9: Ausfällig, na und? Hauptsache einprägsam!

Den Beratern der eidgenössischen ARS Computer Consulting AG spielt die Top-Level-Domain leider einen kleinen Streich. Vorteil: die wirklich gute Merkbarkeit! Zu erreichen ist die Website unter http://www.ars.ch.

Platz 8: Alles im … Eimer

Bleiben wir gleich beim Thema. Man suche sich einen englischen Unternehmensnamen, unterlasse es aber, die Abkürzung für Athletic Sport Sponsoring einmal zusammenhängend auf Englisch auszusprechen – und schon fahren unzählige deutsche Spitzensportler in Autos herum, die sie als Mitglieder einer (vermeintlich) ziemlich dürftigen Truppe ausweisen, die unter http://www.ass-team.net erreichbar ist. Ähnliche Missverständnisse kommen auch bei den Booking-Profis der A.S.S. Concert & Promotion Agentur auf: Zumindest des Englischen mächtige User werden reiflich überlegen, ob sie wirklich wissen möchten, was sich hinter der Unternehmens-URL verbirgt … nach Mit-allen-Sinnen-Genießen klingt http://www.ass-concerts.de jedenfalls nicht.

Platz 7: Weg hier!

Sind wir ein wenig mit dem englischen Slang vertraut, stutzen wir, wenn wir die URL lesen, unter der das Unternehmen Effective Office Environments im Web agiert. Gerne würden wir uns die tollen Büromöbel-Lösungen in Ruhe ansehen, aber die Aufforderung ist dank der sehr durchdachten Abkürzung eigentlich unmissverständlich: Wir sollen gefälligst verschwinden, aber zügig! Fehlt nur ein Ausrufezeichen hinter http://www.effoff.com.

Platz 6: Wer wird denn gleich ungalant werden?

Der Chip-Hersteller Swissbit zeichnet sich offenbar auch durch seine Heimatverbundenheit aus – und öffnet der Verwirrung Tür und Tor. Vielleicht hätte das Unternehmen darüber nachdenken sollen, sich anstelle der Schweizer Landeskennung eine internationale Top-Level-Domain wie COM oder NET zu sichern. Das ist indes nicht geschehen, und so kann man sich des Eindrucks nicht erwehren, hier wäre jemand auf eine eidgenössische Dame nicht sehr gut zu sprechen: http://www.swissbit.ch.

Platz 5: Wein statt Wasser

Wer mit der Sprachverwendung in Chats und Foren einigermaßen vertraut ist, dem sind einschlägige Abkürzungen wie etwa 4U, CU, ME2, 2L8, die erst über die lautliche Aussprache ihre Bedeutung offenbaren, bekannt. Flüstert man nun die URL des Weinhändlers Ingleside Vineyards auf diese und jene Weise vor sich hin, stellt man verlegen fest, dass man soeben geäußert hat, Wein statt Wasser abzuschlagen, diplomatisch ausgedrückt. Bleibt zu hoffen, dass der Domain-Name keine Rückschlüsse auf die Qualität der guten Tropfen zulässt – ansonsten gute N8: http://www.ipwine.com.

Platz 4: Wenn selbstkritisch, dann aber richtig!

Ein schöner Mist! Auch der IT-Dienstleister IT Asset Management and Asset Recycling Service tritt ins Bindestrich-Fettnäpfchen. IT Scrap (Elektronikschrott) ist gemeint, doch was muss (nicht nur) der (böswillige) Nutzer beim Eintippen der URL lesen? Dass die Website, die man gerade aufrufen will, offenbar so richtig … sagen wir bescheiden ist: http://www.itscrap.com.

Platz 3: Gelächter beim Schlächter

Und noch einmal stiftet das Apostroph-Problem Unheil. Kinderlachen ist etwas Herrliches, und ehrenvolle Ziele hat sich die Children’s Laughter Foundation ja auf die Fahnen geschrieben, wie die kompakte, kleine Infoseite zeigt. Aber ach, die Zusammenschreibung! Das Lachen kann angesichts der URL nicht nur Kindern im Halse stecken bleiben: http://www.childrenslaughter.com.

Platz 2: Sittenstrolche in die Therapie!

Warum muss es auch immer Leute geben, die in jeder Kleinigkeit böse Doppeldeutigkeiten erkennen? Diese URL führt zu einem Portal, auf dem Patienten Psychotherapeuten in ihrer Nähe suchen können. Die Suche ist kostenlos, in Sachen Domain-Name aber guter Rat teuer: http://www.therapists.com. Und hier ist nicht einmal ein fehlender Bindestrich das Problem – ein solcher zwischen „the“ und „rapists“ würde alles nur noch schlimmer machen.

Platz 1: Das Land hinter dem Regenbogen …

Kugelschreiber sind aus dem Alltag nicht wegzudenken, sie sind klassische und nach wie vor wichtige Werbemittel und in der goldenen Ausführung gar Statussymbole. Prima, dass sich ein Unternehmen wie Pen Island auf hochwertige Schreibgeräte spezialisiert hat und Kunden erstklassige, individuelle Produkte anbietet. Für den Internet-Auftritt besorgt man sich nun eine schöne NET-Endung … Doch dann geschieht das Unglück! Was machen die ambitionierten Pen-Island-Leute nämlich? Genau, sie verzichten auf einen hier doch ziemlich wichtigen Bindestrich und sichern sich den peinlichen ersten Platz in unserer Liste. Hereinspaziert: http://www.penisland.net.

Kennen Sie weitere kuriose Beispiele?

Was lernen wir daraus? Zumindest dies: Es ist immer empfehlenswert, mögliche URLs für den Unternehmensauftritt genau unter die Lupe zu nehmen und dabei auch um die Ecke zu denken. Gut und schön, wenn man davon ausgeht, die eigene Zielgruppe sei vor „Hintergedanken“ gefeit. Wenn aber ein Kunde den neuen Werbe-Kugelschreiber mit einer URL wie www.expertsexchange.com, www.powergenitalia.com oder www.hollandshitfestival.nl anschaut und meint: „Tut mir leid, den kann ich wirklich nicht annehmen. Was soll meine Frau denken, wenn sie den sieht?“, kann man schon von einem Problem sprechen. Und wenn die halbe Kundschaft beim Domain-Namen der Website grinsen muss sowieso.

Auch die drei gerade genannten URLs sind keine Phantasieprodukte: Unter diesen Domain-Namen waren bis vor wenigen Jahren tatsächlich ein Beratungsportal, der italienische Energieerzeuger Powergen und die Website eines niederländischen Konzertveranstalters erreichbar! Offenbar gilt Murphys Gesetz auch bei vermeintlichen Kleinigkeiten wie der Wahl der richtigen URL Kennen Sie weitere kuriose Beispiele? Wir sind gespannt, bitte nutzen Sie die Kommentarfunktion unten!

Neben der Kommunikation von statischem Wissen per Anhang ist der Versand von Aufgaben per E-Mail eine Missbrauchsform dieser Technologie, die Unternehmen hemmt und zu dramatischen Verlusten an Effizienz und Arbeitseffektivität führt. In diesem dritten und abschließenden Beitrag zum E-Mail-Missbrauch widme ich mich also Formen des Aufgaben-Managements.

Aufgaben gehören in ein zentrales System, nicht in E-Mails

Sicherlich kann diese These zunächst für Stirnrunzeln sorgen, doch die meisten Leute halten es nur deshalb für zweifelhaft, wenn jemand die Auffassung vertritt, man dürfe keine Aufgaben per E-Mail verschicken, weil sie keine konkrete Vorstellung davon haben, welche anderen, weitaus besseren Möglichkeiten es gibt.

Aufgaben sollten in einem zentralen und professionellen Aufgaben-Management-System wie JIRA abgebildet werden. In die E-Mail gehören nur der Hinweis auf das Vorhandensein einer Aufgabe und die Bitte um Erledigung. Dies ist die bestimmungsgemäße Anwendung der jeweiligen Technologie.

Dabei definiert sich nicht über die Größe des Projekt-Teams, ob es sinnvoll ist, eine Aufgabe per E-Mail zu verschicken oder nicht – selbst Kleinst-Teams aus vier, drei oder zwei Mitarbeitern profitieren von einem systematischen Aufgaben-Management.

Ich räume ein, dass es immer Mitarbeiter geben wird, die ihr Aufgaben-Management weiterhin in der spontanen E-Mail-Hülle betreiben werden. Das sei diesen Leuten ungenommen. In vielen Aspekten schlägt ein zentrales, professionelles Aufgaben-Management die Verwaltung per E-Mail allerdings um Längen. Stellen wir die Vorteile beider Arbeitsweisen einander gegenüber.

Vorteile von E-Mails

• E-Mails sind einfach und schnell erstellt, Aufgaben rasch kommuniziert.
• Die spontane Hülle funktioniert.
• Es ist keine Einarbeitung nötig, jeder Mitarbeiter kann eine E-Mail schreiben.
• Das Aufgaben-Management per E-Mail ist opportun („Ich mache das, was alle machen.“). Selbst in Unternehmen, die ein zentrales System betreiben, werden auch (noch) Aufgaben per E-Mail verschickt.

Damit wären die Vorteile jedoch bereits dargestellt – oder können Sie weitere ins Feld führen? Das stärkste Argument ist in diesem Zusammenhang wahrscheinlich die Lobbyfähigkeit der E-Mail, und lobbyfähig wird sie wohl auch bleiben – geeigneter macht sie das indes nicht.

Vorteile eines Aufgaben-Management-Systems

• Dokumentation: Es ist immer nachvollziehbar, wer wem welche Aufgabe zugeteilt hat.
• Vollständigkeit und Zentralisierung: Alle Aufgaben sind erfasst und zentral verfügbar. Keine Aufgaben gehen in E-Mail-Postfächern (bzw. gar in der Zettelwirtschaft) unter oder geraten in Vergessenheit.
• Planbarkeit: Der Aufwand für die Erledigung einzelner Aufgaben wird im Vorfeld beschätzt, eine verlässliche Kapazitätsplanung ist möglich. Es ist ersichtlich, wie viele Aufgaben einem Mitarbeiter zugeteilt sind und wie lange er benötigen wird, um diese zu bearbeiten.
• Transparenz: Anhand der Statusinformationen ist erkennbar, ob mit der Erledigung einer Aufgabe schon begonnen wurde und wie der aktuelle Stand der Bearbeitung ist.
• Kontrolle: Die Erledigung und die Einhaltung von Terminen kann nachverfolgt werden. Ein professionelles Aufgaben-Management-System bietet zudem mächtige automatisierte Auswertungsmöglichkeiten.
• Kundeneinbindung: Dank der Rechtestruktur ist es möglich, Kunden in die Planung einzubeziehen und so die Transparenz bei der Zusammenarbeit zwischen Projekt-Team und Kunden zu erhöhen.
• Minimales Briefing: Projekte können in jeder Phase einem anderen Projekt-Manager übergeben, neue Mitarbeiter jederzeit problemlos integriert werden. Alle Aufgabenbeschreibungen sind inklusive aktueller Statusinformationen zentral verfügbar.
• Integration: Ein System wie JIRA verfügt über eine API, über die die Software an andere Applikationen wie das Projektmanagement-System, die Zeiterfassung usw. angebunden werden kann. Die Software ist nahtlos in die bestehende IT-Landschaft integrierbar und in hohem Maße anpassbar.

Mit einer ausgereiften Aufgaben-Management-Software ist die Abbildung kompletter Entwicklungslebenszyklen von der Ideensammlung und dem Anforderungs-Management über die Abarbeitung bis zur Qualitätssicherung möglich. Ein solches System bietet die Möglichkeit, sich zentral einen aktuellen Überblick über sämtliche Fortschritte in einem Projekt zu verschaffen. An diesen Eigenschaften muss sich das Aufgaben-Management per E-Mail messen lassen und kann hier natürlich nicht gewinnen.

Hindernisse für die Etablierung eines Aufgaben-Management-Systems

Freilich ist eine Aufgaben-Management-Software wie JIRA komplex, sie erfordert Einarbeitung und die Etablierung ist (ähnlich wie die Wiki-Einführung) kein Selbstläufer: Maßnahmen zur Mitarbeiteraktivierung müssen getroffen werden, Schulungsaufwände sind in der Regel unverzichtbar, auch fallen für JIRA Lizenzkosten an (wobei die Lizenzpolitik des Herstellers Atlassian allerdings sehr transparent und fair ist).

Doch die Vorteile überwiegen die Nachteile, die durch einige zu überwindende Hürden entstehen, ganz klar; der Effizienz-, Transparenz- und Arbeitseffektivitätsgewinn, den ein Unternehmen aus einem professionellen Aufgaben-Management-System ziehen kann, ist unschätzbar.

Eine bestimmungsgemäße Technologieanwendung bringt Unternehmen voran

Stellt man also die spontane E-Mail-Hülle und ein professionelles Aufgaben-Management einander gegenüber, wird deutlich, dass der sinnvollste Umgang mit der E-Mail ihr sachgemäßer Gebrauch ist. Es geht nicht darum, dass der Mitarbeiter keine E-Mail erhalten soll, in der er über eine Aufgabe informiert wird; das ist sinnvoll. Allerdings soll es dabei bleiben. Und es ist gewiss möglich, dass sich aus einer E-Mail eine Aufgabe extrahieren lässt, dass aus dem Inhalt heraus also eine Aufgabe entsteht. Der Inhalt sollte aber nie die Beschreibung der Aufgabe sein – ein feiner, aber bedeutsamer Unterschied.

Wenn Aufgaben nicht per E-Mail kommuniziert und zumindest intern und innerhalb bestehender Geschäftsbeziehungen keine Anhänge per E-Mail ausgetauscht werden, nähern wir uns der bestimmungsgemäßen Nutzung von Technologie ein gehöriges Stück. Unternehmen können davon nur profitieren, denn sie ziehen signifikante Vorteile aus dieser Arbeitsweise:

• E-Mails, die mit dem Lesen erledigt sind
• Reduzierung des E-Mail-Aufkommens
• Effizienzsteigerung
• Effektivitätsgewinn
• produktivere Zusammenarbeit
• mehr Transparenz
• systematische Projektabläufe
• hochwertigere Ergebnisse

Weiterführende Informationen

Aufgaben-Management: Argumente für JIRA
JIRA: Aufgaben-Management, Scrum und agiles Projekt-Management für Entwickler und Manager (Vodcast)
JIRA-Workflows: Aufgaben in systematische und transparente Abläufe überführen
Atlassian-Lizenzen: Warum ein Kauf bei //SEIBERT/MEDIA eine gute Wahl ist

Im Artikel Warum der Siegeszug der E-Mail zu weit gegangen ist habe ich zwei Missbrauchsformen der E-Mail kurz angerissen, die ich für gefährlich halte und die schwerwiegende Folgen für Unternehmen haben. Eine Form dieses Missbrauchs, die einen maßgeblichen Anteil an der E-Mail-Flut hat, ist der E-Mail-Versand von statischem Wissen, die Kommunikation von Referenzmaterial, Unternehmens-Know-how und Nachschlageinformationen per E-Mail-Anhang. Meine Kern-These lautet:

Wenn E-Mails Dateianhänge enthalten, ist dies in den meisten Fällen die falsche Anwendung von Technologie.

Effizienzgewinn durch die Nutzung eines zentralen Systems

Damit vertrete ich eine Auffassung, die viele Leute nicht nachvollziehen können. Und das ist oft durchaus verständlich: Viele Personen, die hier skeptisch sind, wissen nur nicht, wie Wissensmanagement anders funktionieren kann. Und manche Gesprächspartner, die Alternativen (zumindest vom Hörensagen) kennen, sind der Meinung, dieses „Anders-Machen“ sei zu kompliziert und praktisch nicht gangbar – insbesondere höre ich nicht selten, dass die Usability und die Integration von Wiki-Lösungen angeblich so schlecht wären, dass die Anwender einfach nicht mit diesen arbeiten würden und dass Alternativen deshalb im Unternehmensalltag nicht praktikabel sein könnten.

Das ist jedoch falsch. Ein ums andere Mal sehe ich bestätigt, dass die sach- und bestimmungsgerechte Anwendung von Technologie in aller Regel zu einem