//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?

Unter uns Usability-Experten ist die Auffassung weit verbreitet, dass die Leute, die eine Software entwickeln, keine repräsentativen Nutzer sind. Wenn wir nicht aufdecken, was unsere Nutzer von uns unterscheidet, endet es damit, dass wir komplexe und komplizierte Systeme entwickeln, mit denen ausschließlich wir selbst arbeiten können.

Meiner Meinung nach haben Joshua und diese Usability-Profis nur teilweise recht. Meistens trifft diese Aussage zu. Aber wie immer im Leben gibt es Ausnahmen. Und diese Ausnahmen sind heutzutage fast gar keine mehr.

Nehmen wir die Arbeitsmethoden bei 37signals. Sie stellen eine große Bandbreite an Produkten her: Basecamp ist ein sehr beliebtes Projektmanagement-Werkzeug. Campfire ist ein tolles Tool für Online-Diskussionen (das meine Produktivität und die meiner Kollegen dramatisch erhöht hat). Highrise ist ein wunderbares CRM-Tracking-System.

Jason Fried, Ryan Singer und das Team von 37signals vertreten eine klare Position: Sie entwickeln für sich selbst. Sie erstellen Applikationen, die sie selbst nutzen würden. Und sie sollen so funktionieren, wie das Team sie am liebsten anwenden würde.

Das dürfte so eigentlich nicht funktionieren. Wenn Joshua und andere richtig liegen, sollte 37signals keine erfolgreiche Produktpalette haben. Aber Millionen Kunden lieben diese Produkte und schwärmen ihren Freunden davon vor. Obwohl 37signals gewiss unzufriedene Kunden hat, die die Anwendungen zu kompliziert finden oder die wichtige Funktionen vermissen, haben sie immer noch ausreichend begeisterte Nutzer, die die Software profitabel machen. Wie geht das?

In seinem Artikel empfiehlt Joshua, die eigenen Nutzer mithilfe der Kerninstrumente der Usability-Forschung kennenzulernen: Interviews, Kontextbefragungen, Umfragen, Card-Sorting und User-Tests. Diese Werkzeuge ermöglichen tiefe Einblicke, mit ihrer Hilfe verstehen wir die Nutzer und erfahren, woher sie kommen und wie gut sie mit einer Anwendung umgehen können.

37signals unternimmt nichts dergleichen. Sie entwickeln aus ihrer eigenen Perspektive. Wenn sie eine neue Funktion umsetzen wollen, fragen sie sich selbst, wie sie aussehen soll. Sie brauchen keine Usability-Forschung.

Stattdessen nutzen sie unkonventionelle Methoden, um Nutzer-Feedback zu sammeln – unkonventionell jedenfalls aus Sicht eines Usability-Experten. Beispielsweise müssen alle Entwickler und Designer abwechselnd auch im Kunden-Support arbeiten. Wenn ein neues Feature ausgerollt wurde, müssen die Leute hinter dieser Funktion all die auftretenden Probleme und Fragen direkt und persönlich mit den Kunden besprechen. Das gibt ihnen ein unmittelbares Gespür dafür, wie es ist, ein User zu sein, vor allem dann, wenn das Produkt nicht so funktioniert wie diese Nutzer es gerne hätten.

Das Unternehmen betreibt zudem ein sehr aktives Diskussionsforum und einen Blog. Die 37signals-Kunden sind nicht schüchtern. Wenn sie nicht glücklich sind und sich eine Produktänderung wünschen, lassen sie es alle Welt wissen. Das Team liest dort eifrig mit und bezieht aus diesen Diskussionen Inspiration und Ideen für spätere Entwicklungen.

Mit den so zusammengetragenen Informationen und dazu ihren sehr kollaborativen Entwicklungsprozessen erstellen sie die Anwendungen, die sie so erfolgreich gemacht haben. Sie haben bewiesen, dass man tolle Ergebnisse auch hinbekommt, ohne auf die etablierten Forschungsmethoden zurückzugreifen. Tatsächlich kann man eine Software entwickeln, deren Nutzer man selbst ist, und diese dann mithilfe direkten Feedbacks weiter vorantreiben.

37signals nicht das einzige Unternehmen, das so vorgeht. Bei Apples iPhone-Strategie war es grundsätzlich genauso. Auch Apple hat keine traditionelle User-Forschung durchgeführt. Stattdessen haben sie das iPhone so entwickelt, wie sie selbst es nutzen wollten. Auch sie beobachten genau, welches Feedback über ihre Shops und Hotlines hereinkommt. Und sie lesen die Diskussionen, in denen Leute sich über Frust und fehlende Features beschweren. Aber letztlich entwickeln sie für sich selbst.

Wir nennen das Self-Design und dieses Self-Design ist eine von fünf Formen der Entscheidungsfindung bei der Anwendungsentwicklung, die wir identifiziert haben. Es ist eine wichtige Form und kann richtig angewendet sehr erfolgreich sein.

Vorteile und Nachteile des Self-Designs

Die großen Vorteile des Self-Designs sind die Faktoren Geschwindigkeit und Kosten. Die traditionelle Nutzerforschung ist zeitaufwändig und teuer, sie dauert Wochen und kostet Tausende Dollar, wenn man sie professionell durchführt. Nun, fragen Sie sich einfach selbst: „Wie würde ich es gerne nutzen?” ist sicherlich eine deutlich schnellere und günstigere Alternative.

Der größte Nachteil des Self-Designs besteht darin, dass es nur funktioniert, wenn Sie einen großen Kundenstamm haben, der wie Sie denkt. 37signals hat Millionen Kunden, die ähnlich ticken wie das Team selbst und die den Markt attraktiv machen. Die Apple-Leute haben genügend Smartphone-Nutzer gefunden, die wie sie selbst sind, um eine anständige Kerbe am Markt zu hinterlassen, obwohl ihre Marktanteile hier in den USA nach wie vor geringer als die von RIM und Nokia sind. Wenn Sie einen Markt finden, der groß genug ist, dass sich auf ihm viele Leute wie Sie selbst tummeln, wird Self-Design Sie glücklich machen. Wenn nicht, werden Sie Schiffbruch mit etwas erleiden, das nur eine handvoll Leute bedienen kann.

Ein weiterer Nachteil: Self-Design funktioniert nur, wenn die Entwickler und Designer das Produkt selbst andauernd nutzen. 37signals hat Basecamp produziert, um die eigenen Projekte zu verwalten. Ihre Software Campfire ist ihre wichtigste Kommunikationsplattform, denn sie haben Team-Mitglieder in aller Welt. Die Apple-Leute nutzen ihre Telefone jeden Tag, rund um die Uhr.

Wenn sich bei der täglichen Nutzung etwas als frustrierend herausstellt, kommt das sehr schnell an die Oberfläche. Das Team erfährt den Frust am eigenen Leib, und weil sie das Produkt kontrollieren, können sie sich sofort darauf konzentrieren, das Problem aus der Welt zu schaffen. Auch sporadisch auftretende Frustrationsquellen, die zum Beispiel auftreten können, wenn man etwas zum ersten Mal nutzt, kommen rasch zutage, weil das Team gut mit dem Support vernetzt ist, der – wenn man so will – ständig sehr günstige User-Tests durchführt, indem er den Nutzern durch die Applikation hilft.

Die Teams von Apple und 37signals wären mit Produkten, die sie nicht selbst tagein, tagaus nutzen würden, nicht so erfolgreich. Fingen sie auf einmal an, Software für die Intensivmedizin oder für Grundschullehrer zu entwickeln, ginge das wahrscheinlich schief. Da sie nicht selbst mit den Anwendungen arbeiten würden, müssten ihnen zwangsläufig auch die Frustrationsquellen entgehen. Der natürliche Flow oder die kontextuellen Nuancen wären ihnen unbekannt, ihre Anwendungen Einheitsbrei und klobig.

Selbst wenn sie die Produkte nutzten, täten sie dies auf andere Weise als die anderen User und würden möglicherweise fehlschlagen. Ein Entwickler zum Beispiel, der in der IT-Abteilung an der Erstellung von Intranet-Anwendungen beteiligt ist, wird mit Self-Design nur dann erfolgreich sein, wenn er sie für andere Entwickler in IT-Abteilungen erstellt. Wenn die Software sich an Leute im Vertrieb oder in der Produktion richten soll, wird der Ansatz wohl scheitern. Entwickler und Vertriebsmitarbeiter nutzen zwar das gleiche Tool, aber sie machen ganz unterschiedliche Sachen damit.

Self-Design funktioniert nur in den Fällen, in denen Sie der Nutzer sind und jede Menge anderer User auf genau die gleiche Art und Weise mit der Software arbeiten wie Sie. Wenn diese Konstellation auf Sie nicht zutrifft, müssen Sie sich wohl nach einer alternativen Methode der Entscheidungsfindung umsehen. Wenn sie zutrifft, sind Sie vielleicht tatsächlich Ihr eigener Nutzer, und das ist eine gute Sache.

Dieser Artikel wurde im Original am 22. Juli 2010 unter dem Titel Actually, You Might Be Your User von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

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

Neues Blind-Guardian-Album – neue Marketing-Strategie

Zunächst kurz zum Hintergrund: Anfang 2010 gab das Label Nuclear Blast den Veröffentlichungstermin des lange erwarteten und von der weltweiten Fan-Community heiß ersehnten neunten Studio-Albums der Krefelder Fantasy-Metaller Blind Guardian bekannt. Nahezu zeitgleich starteten Plattenfirma und Band eine intensive Marketing-Kampagne, doch nicht etwa in Form von Plakatierung, Anzeigen, Broadcasting in Radio und TV (wo Hardrock und Metal traditionell sowieso nicht stattfinden), sondern Content-intensiv mithilfe der angesagten Social-Media-Kanäle. Die offensichtliche Intention:

• die Zielgruppe und vor allem junge Metal-Fans auf ihren eigenen Kommunikationskanälen abholen
• früh Spannung aufbauen und hochhalten
• der treuen Fan-Gemeinde etwas zurückgeben

Quasi über Nacht sind Blind Guardian konsequent auf allen gängigen Plattformen vertreten und aktiv, aber nicht aufdringlich und PR-triefend, sondern informativ und mit einen Mehrwert für die Nutzer. Sehen wir uns an, wie die wichtigsten Social-Media-Kommunikationskanäle hier genutzt wurden und werden.

Twitter-Infos: Täglich, aktuell und relevant

Der Twitter-Account von Blind Guardian hat es innerhalb weniger Monate auf immerhin knapp 4.000 Follower gebracht, seit Beginn des Jahres wurden ca. 300 Tweets mit Links auf neue Interviews und Merchandising-Specials, mit Hinweisen auf Konzerte und Termine und mit regelmäßigen Statusinformationen rund um die Studio-Aktivitäten und den Veröffentlichungsprozess des neuen Albums gepostet.

Meiner Meinung nach ein Musterbeispiel: Ich muss gestehen, dass mich als bekennender Metal-Fan noch keine Band via Twitter so gut, breitgefächert und umfangreich über ihre Aktivitäten informiert hat wie Blind Guardian. Hier wurde und wird täglich redaktionelle Arbeit geleistet, Links z.B. auf gerade online gegangene Interviews in der Fachpresse werden in der Regel am gleichen Tag gezwitschert, die Inhalte sind hochwertig und relevant.

Facebook: Das Mehr an Funktionalität genutzt

Ähnlich ist die Situation auf Facebook: Auch hier ist die Band präsent und versorgt Nutzer via Fanpage fleißig und täglich mit aktuellen News und Links, wobei die Autoren die im Vergleich zu Twitter erweiterte Funktionalität von Facebook in Form eingebundener Video-Previews und Bilder rege nutzen. Das Facebook-Konzept geht ganz offenbar ebenfalls auf: Fast 100.000 Fans innerhalb weniger Monate und Dutzende Kommentare zu jeder Statusmeldung sprechen für sich (wie übrigens auch 100.000 MySpace-Friends).

Dass sich Tweets und Facebook-Statusmeldungen häufig überschneiden, liegt in der Natur der Sache und ist unproblematisch: Praktisch und völlig legitim bedient man mehrere Kommunikationskanäle, muss aber jeweils nur ein Mal redaktionell tätig werden.

YouTube: Blicke hinter die Kulissen

In ihrem YouTube-Kanal schließlich lädt die Band hinter die Studiokulissen ein: Das Content-Herz des Channels bilden nach und nach veröffentlichte zwei- bis dreiminütige Clips mit Videoschnipseln, die während der CD-Produktion entstanden sind und die große Teile des Entstehungsprozesses vom Drum-Recording über die Aufnahme von Gitarren und Gesang bis hin zur Orchestrierung Revue passieren lassen.

Dabei wechseln sich authentische Backstage-Szenen mit Einblicken in die Studioarbeiten ab, die Band-Mitglieder treten ebenso auf wie verschiedene Gastmusiker und das Produktions-Team – Material, das Anhängern der Band wirklich einen Mehrwert bietet und Fans, die nach jeder noch so rudimentären neuen Tonfolge lechzen, eine Wonne ist … Ich weiß, wovon ich spreche! Ein Beispiel:

Diese Making-of-Videos haben auch tatsächlich den angestrebten viralen Verbreitungsweg genommen und sind in thematisch relevanten Foren und Blogs sowie via Facebook, MySpace, Twitter vielfach gepostet bzw. eingebunden (und auch auf YouTube selbst begeistert aufgenommen) worden.

Optimierungsmöglichkeiten: Layout-Anpassungen

Freilich gibt es aus Online-Marketing-Perspektive auch Kritikpunkte im Detail, denn gerade die Layout-Anpassungen sind recht lieblos umgesetzt – bspw. ist das Twitter-Hintergrundbild für hohe Auflösungen zu klein und sind im YouTube-Kanal kaum individuelle Modifikationen vorgenommen worden. Das Gros der Fan-Gemeinde wird sich indes sagen: Geschenkt, hier kommt es auf die Informationen an!

Es wäre allerdings unklug, auch als Unternehmen damit zu rechnen, dass Kunden ebenso über fehlende oder nicht professionell umgesetzte Corporate-Design-Anpassungen hinwegsehen. Promotion für eine Metal-Band und Web-weite Unternehmens-PR sind doch zwei Paar Schuhe. Dennoch können wir interessante Erkenntnisse aus diesem Beispiel ziehen.

Was bringt Social-Media-Marketing also?

Der Erfolg gibt Band und Label recht: Unmittelbar nach der Veröffentlichung in Deutschland rangiert At the Edge of Time auf Verkaufsrang 4 in der Amazon.de-Rubrik Musik und klettert in den deutschen Album-Charts sogar direkt auf den zweiten Platz.

Ob dies auch den beschriebenen Marketing-Maßnahmen zu verdanken ist? Diese Frage wird sich so kaum valide beantworten lassen, und meines Erachtens ist sie auch gar nicht so wichtig.

Interessanter ist vielmehr die Tatsache, dass man mit einem überschaubaren Budget die Zielgruppe perfekt bedienen und bei Laune halten kann: mit selbst produzierten Videos, hochwertigen Textinhalten und systematischer und aufeinander abgestimmter Kommunikation auf Social-Media-Plattformen. Das haben Blind Guardian in den letzten Monaten eindrucksvoll unter Beweis gestellt.

Und das Schönste daran: Mit diesen umfangreichen Aktivitäten wurde keine heiße Luft promotet, sondern tatsächlich ein herausragendes Album, auf dem sich Blind Guardian zwischen Power Metal und Klassik-Bombast auf großartige Weise einmal mehr neu erfunden haben. Hut ab also in zweierlei Hinsicht!

Unser Leitungsangebot

Suchen Sie Wege, um sich im Web weiter zu positionieren und auch neue Kommunikationswege effektiv und effizient zu nutzen? Haben Sie noch keinen Auftritt bei Facebook, Twitter und Co.? Wir beraten Sie gerne und haben in unserem öffentlichen Wiki unser Leistungsangebot zusammengefasst:

• Ihr individueller YouTube-Channel
• Ihre individuelle Facebook-Fanpage

Oder sprechen Sie uns einfach unverbindlich an.

Weiterführende Informationen

Twitter: Elf Erfolgsfaktoren für Unternehmens-Tweets
Social Media: Acht Tipps für einen erfolgreichen Auftritt
Facebook: Potenziale für Unternehmen und Aussichten
Online-Werbung trotz Krise auf Wachstumskurs, aber auch vor Herausforderungen

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

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

In der ersten Ausgabe drehte sich alles um die großartigen Werke von Hugh Dubberly, einem Vorreiter in Sachen digitales Design. Der Autor David Brown verfasste eine wunderbare Hommage an den Künstler und auf der Website wurden einige Beispielarbeiten ausgestellt.

Nun ging der Artikel über eine Bildschirmseite hinaus und die Macher der Gain-Website wollten natürlich, dass die Nutzer den gesamten Artikel lesen. Also brauchte der Beitrag einen Scroll-Balken. Die Betreiber einer so stylishen Seite ließen es sich nicht nehmen, dafür eine eigene Scroll-Leiste zu entwickeln und verzichteten auf das Standardinstrumentarium.

Abb.: Die Ersteller der Gain-Website fanden es sinnvoll, einen eigenen, stylishen Scroll-Balken zu implementieren.

Es stellte sich leider heraus, dass sie das mit der Interaktion nicht ganz hinbekommen hatten. Ein Klick auf einen der Pfeile oben oder unten bewegte den Text nur pixelweise, um eine komplette Zeile zu sehen, waren also mehrere Klicks nötig. Beim Ziehen des viereckigen „Fahrstuhl“-Elements wurde der Content nicht sanft gescrollt, wie wir es kennen, sondern sprang unvermittelt, weshalb es schwer war, die richtige Textstelle wiederzufinden. Und ein Klick auf den Bereich zwischen Pfeil und „Fahrstuhl“, der den Inhalt normalerweise um eine Seite weiterbewegt, hatte gar keinen Effekt.

Für die Leser war das ärgerlich. Nutzer, die mehr über die herausragenden Arbeiten Hugh Dubberlys erfahren wollten, wurden dauernd vom Content abgelenkt, weil sie sich auf den Scroll-Balken konzentrieren mussten. Kein guter Weg, um digitales Design anzupreisen.

Die Scroll-Leiste neu erfinden

Die Gain-Website war in Flash umgesetzt und die Gain-Macher waren weder die ersten noch die letzten die versucht haben, das Nutzerverhalten in Sachen Scroll-Leiste umzukrempeln. Andere Flash-Designs sind noch verrückter: Da werden Bewegungen umgekehrt, Elemente unsichtbar gemacht usw. Das ist nicht die Schuld von Flash, sondern der Mangel an Kenntnis darüber, dass Scroll-Balken komplizierte Gebilde sind.

Wenn man darüber nachdenkt, gibt es heute höchstens ein halbes Dutzend verbreitete Varianten von Scroll-Leisten, Varianten, die einst irgendwo eingebaut wurden und heute überall genutzt werden. Das heißt, dass höchstens eine Handvoll Leute auf dem Planeten wirklich weiß, wie eine Scroll-Leiste implementiert wird. Das ist keine einfache Sache. Scroll-Balken sind, wie gesagt, kompliziert.

Interaktionen sollen unsichtbar bleiben

Wir brauchen Elemente wie Scroll-Balken, um Seiten interaktiv zu machen. Wir wollen, dass diese Elemente so funktionieren, wie wir es gewohnt sind, damit wir uns auf die wichtigen Bestandteile der Seite konzentrieren können. Die Leute sollen sich am Artikel erfreuen und sich nicht darüber den Kopf zerbrechen müssen, wie sie nach unten scrollen. Unsere Manipulationen müssen unsichtbar bleiben. Wenn die richtige Bedienung im Mittelpunkt steht, hält das den Nutzer davon ab, das zu tun, wofür er auf die Seite gekommen ist.

Das Raster der interessanten Momente

Die Netflix-Website gehörte zu den Vorreitern in Sachen ausgeklügelte Interaktion und zu den ersten, die AJAX-Technologien in großem Stil nutzte. Die Netflix-Leute waren führend darin, „natürliche“ interaktive Elemente zu realisieren und tolle Nutzererlebnisse zu ermöglichen. Es fing ganz einfach mit ihrem Filmbewertungs-Tool an: Ein Klick auf ein Sternchen aktualisierte die Server-Datenbank und machte die Aktualisierung durch einen Farbwechsel kenntlich. Doch diese einfache Interaktion erforderte mehrere wichtige, zeitlich aufeinander abgestimmte Schritte, um korrekt zu funktionieren.

Vor einiger Zeit hat uns Bill Scott – ehemaliger Netflix-Mitarbeiter – eine Technik gezeigt, mit der all diese kleinen Interaktionen festgehalten werden können. Er nennt sie „Raster der interessanten Momente“. Dieses Raster zeichnet alles auf, was während und mit einer Interaktion passiert. „Die Entwickler fanden das wirklich toll“, sagte Bill uns, „denn sie mussten nur einen Blick darauf werfen und brauchten sich nicht zu fragen, ob die Konzeptionierer oder Designer etwas vergessen hatten“.

Das Raster ist eine große Matrix, die die Ereignisse, die an der Oberfläche auftreten, und die Design-Elemente, die damit zu tun haben, enthält. Sehen wir uns das am Beispiel eines Drag-and-Drop-Elements an. In diesem Fall sind scheinbar diese Ereignisse relevant: Seite laden, Mausbewegung, Maus über dem Objekt, Mausklick, Einleiten des Ziehens, festgehaltene Maus bewegt sich vom Objekt weg, Neueingabe des gezogenen Objekts. Die Design-Elemente – Bill Scott nennt sie Aktoren – sind diese: die Seite, das angeklickte Objekt, ein möglicher automatisierter Hinweis der Anwendung und der Cursor.

Tatsächlich aber hält Bill bei einem gängigen Drag-and-Drop 16 Ereignisse und sechs Aktoren fest. Auf das Raster übertragen haben wir volle 96 interessante Momente. Ein solcher Moment tritt zum Beispiel ein, wenn das Ziehen eines geeigneten Objekts beginnt und alle verfügbaren Ziele, in denen das Objekt abgelegt werden kann, hervorgehoben werden. In sein Raster würde Bill in der Zeile „Ziehen beginnt“ also dieses Ereignis eintragen. Zudem würde er in die gleiche Zeile schreiben, dass der Cursor die schemenhafte Gestalt des aufgenommenen Objekts annimmt.

Stillstandzeiten verkürzen

Die Eleganz dieses Interessante-Momente-Gitters kann am besten mit Bills Worten aufgezeigt werden. „Ursprünglich“, erklärt er uns, „habe ich mit unzähligen Statusdiagrammen versucht, einzelne Sachen wie eine Drag-and-Drop-Aktion abzubilden. Und all die Möglichkeiten und Eventualitäten bei der Umsetzung erschlagen einen schließlich. Nach jedem Meeting hatte ich mir vorgenommen, all die Möglichkeiten und Nuancen, die gerade Thema waren, zu dokumentieren. Doch es hat nicht lange gedauert, bis 20 oder 30 Seiten mit Notizen vor mir lagen. Und ich habe schnell gemerkt, dass das kein geeigneter Weg zu einer Lösung ist. Wir mussten eine andere Methode finden. Schließlich ist mir aufgefallen, dass eine Interaktion aus vielen kleinen Ereignissen besteht und dass immer diese Objekte und Elemente involviert sind. Indem ich diese in einem einfachen, übersichtlichen Raster abbildete, konnte ich alles wie durch ein Mikroskop betrachten, die Nuancen schnell erkennen und die Stillstandzeiten zwischen Iterationen tatsächlich verkürzen.“

Kommunikation und Nutzererlebnisse verbessern

Bill nutzt sein Raster, um Interaktionen zu verfeinern. Wenn die Entwickler die ersten Prototypen implementieren, probieren Bill und sein Konzeptions-Team sie aus. Wenn etwas nicht auf natürliche Weise funktioniert – also so, wie man es erwarten würde – muss im Raster nur eine einfache Änderung vorgenommen werden, das ist alles. Die Entwickler sehen die Änderung, implementieren die modifizierte Interaktion und liefern eine neue Iteration.

So wird das Gitter zu einem Instrument, das Konzeptionierer und Entwickler auf die gleiche Seite zieht und das auf einfache, elegante Weise die Kommunikation im Team und die Nutzererlebnisse verbessert.

Dieser Artikel wurde im Original am 6. Juli 2010 unter dem Titel „Capturing the Interesting Moments“ von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

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.

Content

Entscheidend für ein gutes Google-Ranking ist sogenannter „Unique Content“, also Inhalte, die einzigartig und ausschließlich auf der eigenen Website zu finden sind. Auch Bilder, Videos usw. werden nur über die dazugehörigen Texte gefunden und sollten daher immer auch mit einem guten, aussagekräftigen Text versehen sein. Die auf der Website verwendeten Inhalte sollten sich deutlich von denen anderer Anbieter unterscheiden. Verwenden mehrere Websites ähnliche oder gleiche Texte, z.B. bei Artikelbeschreibungen, zeigt die Suchmaschine die Link-stärksten Seiten zuerst an und andere, weniger Link-starke Seiten bleiben durch schlechtere Platzierungen unbemerkt. Natürlich sind professionelle, unikale Texte ein Kostenfaktor, doch diese Investition lohnt sich langfristig garantiert.

Keywords

Viele Keywords sind hart umkämpft und schwierig zu ranken. Eine Alternative sind Informationstexte mit ebenso aussagekräftigen, aber weniger umkämpften Keywords und Keyword-Kombinationen.

URL

Jeder Inhalt sollte grundsätzlich nur unter einer URL zu erreichen sein. Technisch besteht jedenfalls keine Notwendigkeit, einer Seite mehrere URLs zuzuweisen. Außerdem kann dieser häufig gemachte Fehler zu SEO-Problemen und im schlimmsten Fall sogar zum Ausschluss der Seite aus dem Google-Index führen.

Eine URL sollte nie verändert werden. Vor allem sind durch die Änderung einer URL Bookmarks und Verlinkungen hinfällig, der Seite geht somit Traffic verloren. Schon bei der Planung eines neuen Projektes ist also zu überlegen, wie die URL gestaltet wird, damit eine spätere Änderung nicht nötig wird. Sollte eine Änderung – aus welchem Grunde auch immer – dennoch unumgänglich sein, ist natürlich eine korrekte Weiterleitung Pflicht.

Damit nicht scheinbar mehrere URLs mit gleichem Inhalt entstehen, muss immer eine Standard-Domain definiert sein. Alle anderen Domain-Namen sollten auf die Standard-Domain weitergeleitet werden.

URLs sollten möglichst „sprechend“ gehalten werden und sich selbst erklären. Das erhöht die Klickraten und schafft zusätzliche Keyword-Relevanz. Ein Beispiel für eine sprechende, also ausdrucksstarke URL wäre: http://jeansshop.de/jeans/kaufen

Damit jede URL zu einem bestimmten Keyword gefunden wird, empfiehlt es sich, dass die URL das Keyword auch enthält. Unterseiten, beispielsweise in Online-Shops, sollten zu den konkreten Produkten ranken, die Hauptseite immer zum allgemeinen Produktangebot.

Für das Ranking ist es egal, ob für eine URL die Groß- oder Kleinschreibung gewählt wird. Wenn die Kleinschreibung festgelegt wird, muss die „falsche“ Variante mit Großschreibung aber auf diejenige mit Kleinschreibung weitergeleitet werden – und umgekehrt.

Erlaubt sind ausschließlich Klein- und Großbuchstaben. Umlaute, das Eszett, Sonderzeichen (außer „–“), Satzzeichen, Währungszeichen o.ä. sind dagegen nicht möglich und müssen jeweils ersetzt werden.

Um Keywords zu trennen, sollten nur Bindestriche oder Slashes verwendet werden. Den häufig verwendeten Unterstich „_“ interpretiert Google als Buchstaben, die einzelnen Keywords sind nicht mehr zu erkennen.

Eine URL sollte maximal zwischen 100 und 200 Zeichen enthalten. Zu lange URLS verstümmelt Google in den Snippets, sie werden unattraktiv bzw. verlieren an Aussagekraft.

Zudem haben Eye-Tracking-Studien ergeben, dass Nutzer beim Überfliegen der Ergebnislisten nur maximal die ersten beiden Wörter einer URL wahrnehmen. Es ist also empfehlenswert, den Inhalt einer Seite schon am Link-Anfang möglichst aussagefähig darzustellen.

Title-Tag

Der Title-Tag ist der wichtigste Keyword-Träger und sollte exakt mit den Keywords gefüllt werden, auf die die URL ranken soll. Dabei sind maximal 60 Zeichen zulässig, die aber auch möglichst ausgenutzt werden sollten.

Descriptions

Der Bereich der Meta-Description sollte nicht mit sinnlosen Aneinanderreihungen von Keywords gefüllt werden, sondern mit ausformulierten Beschreibungen der Seite.

Snippets

Die angezeigten Snippets der Suchmaschinen kann man selbst beeinflussen. In der ersten Zeile erscheint der Titel, den man selbst festlegen kann. Die Zeilen Zwei und Drei werden mit den Beschreibungen aus der Meta-Description gefüllt und sollten auch möglichst ausgenutzt werden, da so eine höhere Klickrate erreichbar ist. In der vierten Zeile folgt die URL, welche optimalerweise wie oben beschrieben aufgebaut sein sollte. Wichtig ist hierbei ein Beschneiden durch Google zu verhindern. Ein gutes Snippet hat einen enormen Einfluss auf die Klickrate.

Google-Index

Es ist immer von Vorteil, den gesamten Inhalt einer Website zu indizieren. Dies ist aber bei den wenigsten Seiten tatsächlich der Fall. Dabei haben gerade Themen oder Keywords auf Unterseiten oder auch älteren Datums gute Chancen auf ein gutes Ranking, weil sie vielleicht Nischenthemen abdecken. Voraussetzung ist aber eben eine vollständige Indizierung der Seiteninhalte.

Seitenstrukturen

Alle Inhalte, die von der Startseite aus mit vier bis fünf Klicks erreichbar sind, können auch von Google gecrawlt werden. Was sich tiefer in der Website verbirgt, wird ein Crawler vermutlich nicht finden.

Das Problem kann entweder in der Blätternavigation liegen, was dazu führt, dass zahlreich Klicks notwendig sind, um eine bestimmte Unterseite zu finden. Oder aber die Verlinkung fehlt, da ältere Seiten nicht archiviert werden. Beides führt dazu, dass ältere Unterseiten nach einer gewissen Zeit schlecht ranken und schließlich aus dem Google-Index entfernt werden.

Bei großen Websites unterstützen XML-Sitemaps die bessere Indizierung der vielen Unterseiten.

Interne Verlinkung

Wenn auf einer häufig aktualisierten Website ein Archiv eingerichtet wird, erhält jede Unterseite einen Link und bleibt damit im Google Index. Durch Verlinkung der Seiten untereinander ist ein noch besseres Ranking zu erreichen.

Bei Inhalten, die Bild und Text enthalten, ist es sinnvoll, immer sowohl das Bild als auch den Text zu verlinken, wobei Bilder und Grafiken möglichst immer einen Alt-Tag erhalten sollten.

Ladezeit

Seit kurzem zieht Google zur Einstufung einer Website auch die Ladezeit heran, die unmittelbar in die Ermittlung des Rankings einfließt. Nicht zuletzt ist also auch ein hochwertiges technologisches Fundament ein SEO-Faktor.

Haben Sie Fragen zum Thema SEO? Ist Ihnen bewusst, dass manche SEO-Maßnahmen durchaus gefährlich sein können, weil sie gegen die Richtlinien von Google & Co. verstoßen? Möchten Sie sicherstellen, dass Ihre Web-Inhalte dauerhaft gut ranken? Die SEO-Experten von //SEIBERT/MEDIA beraten Sie gerne und verhelfen Ihnen mit seriöser, gezielter, wirkungsvoller und nachhaltiger Suchmaschinenoptimierung zu mehr Erfolg im Web. Bitte sprechen Sie uns an.

Weiterführende Informationen

White Hat SEO: Seriöse Suchmaschinenoptimierung für dauerhaften Erfolg
Link-Popularität und Suchmaschinenerfolg: Was gute Inhalte und intensive Arbeit bewirken
Duplicate Content: Ein Problem für das Google-Ranking?

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

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

Im Zusammenhang mit nutzerbasierter Usability-Forschung stößt man immer wieder auch auf die Ergebnisse von Eye-Tracking-Studien, die zweifellos wichtige Erkenntnisse liefern. Was kann Eye-Tracking nun? Und was kann Eye-Tracking nicht? Und wie ist Eye-Tracking im konkreten Usability-Projekt anwendbar? Ein Überblick.

Ähnlicher Testaufbau wie beim User-Test

Im Hinblick auf den eigentlichen Testaufbau unterscheidet sich eine Eye-Tracking-Studie nicht grundsätzlich von einem User-Test: Wie bei einer nutzerbasierten Usability-Studie werden Probanden rekrutiert und eingeladen, es findet eine Eins-zu-eins-Situation zwischen Testteilnehmer und Versuchsleiter statt, der Nutzer erfüllt bestimmte, im Vorfeld definierte Aufgaben und wird bei seinen Aktivitäten beobachtet, es werden Daten aufgezeichnet und ausgewertet.

Bei einem User-Test sind das der Bildschirm und die dort stattfindenden Aktivitäten und Eingaben. Der User selbst wird bei seiner Arbeit per Video aufgenommen, zusätzlich zeichnet ein Mikrofon alle Äußerungen des Teilnehmers auf, der animiert wird, die Methode lauten Denkens anzuwenden. Darin liegt das große Potenzial eines klassischen User-Tests: Die Probanden arbeiten nicht einfach mit der Anwendung, sondern kommentieren ihr Vorgehen, weisen auf Probleme hin, kommunizieren, was ihnen bei der Arbeit positiv und negativ auffällt, schlagen mitunter selbst Lösungsansätze vor etc.

Bei einer Eye-Tracking-Studie kommt nun eine weitere Datenquelle hinzu: Die Augenbewegungen und Blickverläufe des Testteilnehmers auf dem Bildschirm werden von einem Eye-Tracker registriert, man erhält also Informationen darüber, was der Nutzer fixiert und worauf sich seine Aufmerksamkeit fokussiert.

Stark verbesserte Hardware

Dazu ist eine sehr sensible Eye-Tracking-Hardware nötig, die aber in den letzten Jahren eine beachtliche Entwicklung genommen hat und deutlich besser geworden ist. Die Zeiten, in denen sich die Probanden wie Teilnehmer einer medizinischen Versuchsreihe fühlen und eine ziemlich bizarre Apparatur mit Helm und Brille tragen mussten, die eine normale Nutzung kaum erlaubt hat, sind jedenfalls vorbei.

Mit modernen Eye-Trackern haben Nutzer inzwischen vergleichsweise viel Bewegungsfreiheit, können sich problemlos um 20 oder 30 Zentimeter vor- oder zurückbeugen, das Tragen von Kontaktlinsen ist kein Problem mehr, die Kameras, die die Augenbewegungen erfassen, sind kaum als solche zu erkennen. Insofern haben sich die Testumgebungen stark verbessert und sich realen Nutzungssituationen deutlich angenähert.

Problem: Methode lauten Denkens nicht anwendbar

Modernes Eye-Tracking-Equipment bietet dem Probanden also einen gewissen Bewegungsspielraum, aber sicherlich keine uneingeschränkte Bewegungsfreiheit im Kopfbereich. So kommt man auch zum grundsätzlichen Problem: Die Kombination aller oben genannten Methoden im Rahmen einer Test-Session ist schwer möglich.

Wenn bei einem Eye-Tracking-Test die Methode lauten Denkens zum Einsatz kommen soll, verfälschen natürliche Kopfbewegungen beim Sprechen die Ergebnisse; wenn der Nutzer darüber nachdenkt, wie er etwas ausdrücken soll, und dabei den Bildschirm betrachtet, hat dies zweifellos Einfluss auf die Blickverläufe. Es ist kaum gangbar, den Probanden anzuweisen, eine konkrete Aufgabe zu erledigen und währenddessen ständig zu kommunizieren, was ihm durch den Kopf geht, und zudem noch seine Blickverläufe aufzuzeichnen. Sobald der Test-Teilnehmer zu reden beginnt, besteht nicht mehr die gewünschte klassische Nutzungs- und Laborsituation. Deshalb kann bei Eye-Tracking-Studien die Methode lauten Denkens praktisch nicht angewendet werden.

Das ist das Kernproblem und ein elementarer Unterschied zu einem klassischen User-Test. Die Testumgebung ist im Grunde die gleiche, doch mithilfe einer zusätzlichen Apparatur werden zusätzliche Daten gesammelt – diejenigen Daten, die für die Identifikation von Usability-Problemen ungleich wichtiger sind, können im Rahmen dieses Testaufbaus jedoch nicht erfasst werden.

Wann sind Eye-Tracking-Studien sinnvoll?

In der Regel laufen Eye-Tracking-Tests aus den gerade genannten Gründen so ab, dass Testteilnehmer keine fest definierten, spezifischen Workflows innerhalb einer Anwendung durchlaufen, sondern nur sehr allgemeine Aufgaben erfüllen sollen – beispielsweise wird der Nutzer gebeten, sich die Startseite einer Website anzusehen. Als Ergebnis erhält man zwar eine recht eindrucksvolle Heat-Map, aus der hervorgeht, was der Nutzer fixiert hat und wie intensiv, doch die Usability-Probleme der Anwendung werden so kaum aufgedeckt. Deshalb ist Eye-Tracking häufig auch nicht sehr effektiv.

Wann Eye-Tracking sinnvoll ist, entscheidet sich im Einzelfall. Stellen wir dennoch eine Zahl in der Raum: Ich bin davon überzeugt, dass in 90% aller Fälle ein klassischer User-Test für die Verbesserung der Usability einer Web- oder Intranet-Anwendung sinnvoller ist als eine Eye-Tracking-Studie.

Gewiss möchte niemand dem Eye-Tracking die Daseinsberechtigung absprechen, die Anwendungsfälle sind, wie erwähnt, aber sehr speziell. Sinnvoll eingesetzt können diese Tests wertvolle Erkenntnisse liefern. Einige beispielhafte Fragen, auf die sich mithilfe von Eye-Tracking-Analysen gute Antworten finden lassen, lauten:

• Wo muss ein Banner platziert werden, damit ihn möglichst viele Nutzer registrieren?
• Welche von vielen Elementen auf einer Seite werden überhaupt gesehen und welche gehen unter?
• Fixieren Nutzer Elemente in einer Reihenfolge, die für das Verständnis wichtig bzw. optimal ist?
• Wird in Design A ein wichtiges Element besser wahrgenommen als in Design B?

Grundsätzlich kann Eye-Tracking sicherlich sinnvoll und erkenntnisbringend eingesetzt werden, gerade in den Bereichen Pre-Testing und Marktforschung. Im Hinblick auf die Testergebnisse ist aber eine Differenzierung notwendig.

Differenzierung: Messung von Aufmerksamkeit, nicht von Wahrnehmung

Beim Eye-Tracking wird Aufmerksamkeit gemessen, nicht Wahrnehmung: Es wird zwar aufgezeichnet, wo Probanden hinsehen, jedoch nicht, ob Informationen verarbeitet werden. Dass der Nutzer einen Bereich betrachtet, bedeutet nicht, dass er auch Inhalte liest.

Als Indikator für die Wahrnehmung gilt unter Eye-Tracking-Befürwortern zwar die sog. Fixationsdauer: Hier setzt man voraus, dass die Dauer der Fixierung und die Verarbeitungstiefe in einem direkten Zusammenhang stehen.  Diesem Argument entgegnen Psychologen allerdings, eine längere Fixationsdauer ließe keine Rückschlüsse darauf zu, ob positive oder negative Emotionen beim Betrachter geweckt werden. Außerdem würden psychophysische Tests keine Erkenntnisse über die (gerade für die Werbung wichtige) Erinnerungsstärke liefern – Fixationsdauer hin oder her.

Fazit: User-Tests sind die beste Alternative, Eye-Tracking kann ergänzen

Im Rahmen der Usability-Forschung spielen Eye-Tracking-Studien unbestritten eine wichtige Rolle: Vor allem für das Forschungsfeld Mensch-Maschine-Interaktion sind Erkenntnisse beispielsweise über das F-Muster sehr interessant und wichtig.

In konkreten Projekten eignet sich Eye-Tracking zur Analyse spezifischer Anwendungen und Websites (die ja sehr komplex sind) aber selten und kann höchstens eine ergänzende Funktion einnehmen. Um die Usability-Probleme einer Software aufzudecken, ist der klassische User-Test in aller Regel die empfehlenswerte und beste Alternative. Ausführliche Informationen zum Thema finden Sie auf unserer speziellen Seite über User-Tests.

Weiterführende Informationen

Die Usability-Website von //SEIBERT/MEDIA
Der User-Test: Die Königsdisziplin der Usability-Forschung
Blickverläufe: Neue Eye-Tracking-Studien bestätigen F-Muster
Voodoo-Usability: User-Tests, die keine sind

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

Expertenanalyse im Vorfeld des User-Tests

Zunächst klickt sich der Versuchsleiter beim Pre-Test durch die Applikation, um grundsätzliche Fragen zu klären: Er lernt die Anwendung kennen, testet, wie lange die Erledigung von Aufgaben dauert, und beschätzt, wie viele Aufgaben in einer Test-Session sinnvollerweise untergebracht werden können bzw. sollten. Bietet es sich an, mehrere Aufgaben in einem Test von den Probanden erledigen zu lassen, weil einzelne Tasks nur wenig Zeit in Anspruch nehmen? Welche technischen Besonderheiten sind zu berücksichtigen? Muss vielleicht eine Datenbank nach jeder Test-Session zurückgesetzt werden? Etc.

Der wichtigste Bestandteil des Pre-Tests ist schließlich das systematische Identifizieren von möglichen Problemquellen. Hier wendet der Experte sein theoretisches und praktisches Wissen an und untersucht gezielt die einzelnen Abläufe, die später die Probanden durchlaufen sollen. Bei der Prüfung geht der Berater den korrekten Ablauf Schritt für Schritt durch und notiert alle Probleme, die der User bei der Erledigung der einzelnen Schritte haben könnte.

Ziel ist es, jeden möglichen Fehler, den der Nutzer beim Durchlaufen des Prozesses machen könnte, festzuhalten und zu beurteilen. Er stellt also Hypothesen darüber auf, welche Probleme im User-Test bei welchem Arbeitsschritt zu erwarten sind.

Die eigene Expertise auf den Prüfstand stellen und profitieren

Beim Aufstellen solcher Hypothesen handelt es sich also um eine expertenbasierte Usability-Analyse, die dem User-Test vorausgeht. Sie hat mehrere Vorteile.

Zunächst ist dieses Vorgehen methodisch sehr interessant: Der Experte erkennt bei der Vorbereitung die Probleme A, B und C. Beim User-Test stellt sich dann heraus, ob er damit überhaupt richtig liegt. Oder sind diese Probleme gar keine für die wirklichen User? Bzw. entpuppen sich im Test ganz andere Details als Hürden, die noch überhaupt nicht bedacht worden sind?

Das ist sehr hilfreich und erhellend für den Berater: Er hat die Möglichkeit, seine Expertise und auch theoretische Grundlagen unter Praxisbedingungen auf den Prüfstand zu stellen. Diese Erkenntnisse und Erfahrungen fließen in die künftigen expertenbasierten Tests des Beraters ein und verbessern die Qualität seiner Analysen.

Hat er mehrmals solche Hypothesen für User-Tests aufgestellt, die sich dann bestätigt haben, wird er in die Lage versetzt, auch in späteren Expertenanalysen noch mehr Probleme aufzudecken, die in der Praxis tatsächlich zu Fehlern führen.  Zudem erkennt er, welche theoretischen Usability-Richtlinien in der Nutzungspraxis womöglich gegenstandslos sind, da z.B. eine bestimmte, scheinbar problematische Positionierung eines Elements bei realen Nutzern gar keine Probleme verursacht.

Überraschungen während des User-Tests vorbeugen

Ein ausführlicher Pre-Test macht nicht zuletzt den User-Test einfacher. Man hat bereits eine Vorstellung davon, wo vermutlich Fehler vorkommen und wo das Programm Probleme bereiten wird, und kann sich auf das Wesentliche konzentrieren.

Darüber hinaus ist das ausführliche Pre-Testing eine Vorsichtsmaßnahme, gerade wenn es sich um eine komplexe Anwendung handelt. Ein Szenario wie dieses ist sicherlich kein angenehmes: Der Testteilnehmer klickt irgendein Element an und der Testleiter hat keinen Schimmer, wo sich der Nutzer hinmanövriert hat. Was genau hat der Nutzer jetzt gemacht? Eigentlich wäre es doch logisch gewesen, dass er ein anderes, sehr prominent positioniertes Element hätte anklicken müssen! Als Testleiter sollte man die Struktur der Anwendung und auch die Bereiche kennen, die für die zu erledigenden Aufgaben nicht relevant sind, um von Fehlern der Probanden nicht selbst überrascht zu werden.

Es lohnt sich, ein Budget für gute Vorbereitung einzuplanen

Aus diesen Gründen ist der Usability-Berater gut beraten, potenzielle Wege in der Anwendung im Vorfeld zu durchlaufen und vor dem User-Test eine intensive Expertenanalyse durchzuführen. Und auch aus Kundensicht ist es sinnvoll, im Rahmen eines User-Tests auch ein zusätzliches  (geringes) Budget für einen expertenbasierten Pre-Test einzuplanen.

Das ist gewiss etwas aufwändiger und kostet Zeit, doch dieses Vorgehen führt zu einer besseren Testsituation und damit zu besseren Testergebnissen. Der Versuchsleiter ist sicher, er antizipiert Fehler, er kann den User eventuell schneller auf den richtigen Pfad zurückbringen und sich auf die Beobachtung der Probanden und die Schwachstellen der Anwendung konzentrieren – gsnz im Sinne hochwertiger Resultate.

Haben Sie Fragen zu nutzerbasierten Usability-Analysen? Suchen Sie Möglichkeiten, Ihre Web- oder Intranet-Anwendung nutzerfreundlicher zu gestalten? Wir sind Experten für Usability und helfen Ihnen gerne. Ausführliche Informationen und ein Kontaktformular für Ihre unverbindliche Anfrage finden Sie auf unserer speziellen Seite zum Thema User-Tests.

Weiterführende Informationen

Der User-Test: Die Königsdisziplin der Usability-Forschung
Die politische Bedeutung von User-Tests
User-Tests: Whiteboards erleichtern die Systematisierung und erhöhen die Transparenz
User-Tests: Debriefings sind wichtig und haben sich durchgesetzt

Bei der Software-Entwicklung bieten sich zwei grundsätzliche Ansätze an: das klassische lineare Wasserfall-Modell und flexible agile Entwicklungsmethoden.

Das Wasserfall-Modell beschreibt eine lineare Vorgehensweise bei der Software-Entwicklung: Die sequenziellen Entwicklungsprozesse sind in (aufeinander aufbauende) Phasen mit fest definierten Zielsetzungen unterteilt, dem Abschluss einer Phase folgt die nächste, der gesamte Projektzyklus wird im Vorhinein festgelegt.

Das Wasserfall-Modell erfordert eine sehr konkrete Planung und kann insbesondere bei wenig komplexen Projekten eine effektive und einfache Arbeitsmethode sein. Es weist jedoch auch einige gravierende Nachteile auf: Da die Phasen hintereinander ablaufen müssen, ist das Wasserfallmodell unflexibel Veränderungen gegenüber, das Projekt und die Anforderungen an das Ergebnis müssen schon früh extrem detailliert geplant werden, was in der Praxis oft gar nicht umsetzbar ist.

Vor allem können Änderungen aufgrund neuer Anforderungen sehr kostenintensiv sein und werden, je später die Phase, immer schwieriger umzusetzen. Dies führt unter Umständen auch dazu, dass die entwickelte Software schon bei ihrer Fertigstellung nicht mehr aktuell ist.

Auf der anderen Seite: Agile Entwicklungsmethoden auf der Basis von Scrum oder XP. Der iterative Ansatz basiert auf wenigen klaren Regeln, die es erlauben, auf geänderte Anforderungen, die in Software-Projekten besonders häufig auftreten, kontrolliert aber flexibel zu reagieren. Insbesondere ändert sich das klassische Dreieck des Projektmanagements: Aus einem Kompromiss aus Kosten, Zeit und Qualität wird ein Kompromiss aus Kosten, Zeit und Funktionalität. Es gibt also keine Kompromisse hinsichtlich der Qualität, dafür werden nicht sämtliche Funktionen von vornherein festgelegt, sondern nach und nach im Rahmen mehrerer Iterationen definiert und umgesetzt.

Eine ausführliche Einführung zu iterativen Arbeits- und Vorgehensweisen geben Ihnen unsere Artikel über Scrum und Extreme Programming.

Studien zeigen: Wasserfall-Methode gefährdet Projekte

//SEIBERT/MEDIA möchte Kunden überzeugen, in Software- und Web-Projekten auf agile Entwicklungsmethoden zu setzen. Und das aus guten Gründen.

Im Rahmen einer britischen Studie wurden 1.027 IT-Projekte, von denen nur 13% nicht gescheitert waren, auf Misserfolgsfaktoren hin untersucht: In 82% dieser Projekte hat die Anwendung der Wasserfall-Methode maßgeblich zum Scheitern beigetragen, und zwar insbesondere durch die umfangreiche Anforderungsfestlegung im Vorfeld. (Thomas, M.: IT Projects Sink or Swim. British Computer Society Review, 2001)

In einer anderen Studie wurde anhand von 6.700 Projekten untersucht, welche Faktoren Software-Projekte gefährden: Vier von fünf der ermittelten Schlüsselfaktoren stehen im Zusammenhang mit der Wasserfall-Methode, darunter die Schwierigkeiten, Anforderungen nachträglich zu modifizieren und Probleme bei der späten Integration von Funktionen. (Jones, C.: Patterns of Software Failure and Success. International Thompson Press)

Aus einer Umfrage unter Unternehmen, die auf agile Entwicklungsmethoden setzen, gehen diese hochinteressanten Ergebnisse hervor:

• 88% der befragten Unternehmen geben an, die Produktivität habe sich verbessert.
• 84% sagen aus, die Qualität sei gestiegen.
• In 46% der Unternehmen sind die Projektkosten nach der Etablierung agiler Methoden gleich geblieben.
• In 49% der Unternehmen sind die Kosten danke agiler Entwicklung gesunken.
• 83% der Unternehmen geben an, es sei eine höhere Zufriedenheit der Kunden mit der neuen Software festzustellen.

(Corporate Report: Agile Methodologies Survey Results. Shine Technologies Pty Ltd., Victoria, Australia, 2003)

Eine vierte Studie, für die mehr als 8.000 Projekte ausgewertet wurden, hat bereits 1994 gezeigt, dass bei 37% aller IT-Vorhaben massive Probleme durch die frühe Festlegung auf bestimmte Anforderungen entstehen. (Jim Johnson et. al.: Chaos: Charting the Seas of Information Technology. Published Report, 1994)

Komplexe Projekte erfordern moderne, flexible Methoden

In komplexen Projekten, die naturgemäß vielen Änderungen unterworfen sind, ist die Anwendung iterativer Methoden unbedingt empfehlenswert. Mit dieser Empfehlung stehen wir natürlich nicht allein, prominente und renommierte Verfechter der iterativer Software-Entwicklung sind beispielsweise Harlan Mills, Frederick Brooks, Barry Boehm, James Martin, Tom DeMarco, Ed Yourdon und zahlreiche mehr. Stellvertretend für viele führende Software-Entwickler kommt Craig Larman angesichts der oben dargestellten und ähnlicher Forschungsergebnisse zu einem klaren Schluss:

Data shows that iterative and evolutionary development is correlated with lower risk, higher productivity and lower defect rates than waterfall methods. (Larman, C.: Agile & Iterative Development. Addison-Wesley, 2004)

Das Handwerkszeug für effektive, flexible Software-Entwicklung bei geringen Risiken und größtmöglicher Produktivität steht in Form von Methoden wie Scrum und XP längst zur Verfügung und wird von //SEIBERT/MEDIA bei der Zusammenarbeit mit langjährigen Kunden wie z.B. der Allsecur GmbH erfolgreich eingesetzt. Die Frage „What are the most exciting, promising software engineering ideas or techniques on the horizon?“ hat David L. Parnas, ein Vorreiter im Bereich der Software-Entwicklung, so beantwortet:

I don’t think that the most promising ideas are on the horizon. They are already here and have been for years, but are not being used properly.

Haben Sie Fragen zu agilen Entwicklungsmethoden? Planen Sie ein Software-Projekt oder benötigen Sie Unterstützung bei einem laufenden Vorhaben? Wir sind Experten für iterative Entwicklung und verfügen über jahrelange Erfahrung in der Anwendung von Scrum und XP. Bitte sprechen Sie uns an.

Weiterführende Informationen

Scrum: Agile Software-Entwicklung bei //SEIBERT/MEDIA
JIRA: Aufgabenmanagement, Scrum und agiles Projektmanagement für Entwickler und Manager
Grails: Kurze Entwicklungszeiten und nahtlose Java-Integration
Anatomie einer Iteration

Angesichts des Marktes, in dem Flickr sich bewegt – den Foto-Websites also –, ist diese Entwicklung einleuchtend. Bevor Flickr auf den Plan trat, ging es bei den Größen am Markt wie Photoworks und Ofoto (die bald von Kodak übernommen wurden) um das Drucken von Bildern und ähnliche Dienstleistungen: User konnten ihre digitalen Fotos hochladen und hochqualitative Ausdrucke beziehen. Sicherlich haben diese Anbieter schon damals Möglichkeiten zur Verfügung gestellt, Fotos mit Freunden und Familienangehörigen zu teilen. Ganz offensichtlich waren diese Funktionalitäten aber keine Bestandteile des Kernsystems, sondern ziemlich plump umgesetzt und dementsprechend frustrierend in der Handhabung.

Flickr hat alles verändert

Das Flickr-Team hat das Teilen in den Mittelpunkt des Konzeptions- und Entwicklungsprozesses gerückt. Jedem Aspekt wurde der Social-Media-Ansatz sozusagen eingebrannt.

Ein Beispiel: Das Teilen war ein Kernelement des Flickr-Geschäftsmodells. Hatte ein User einmal angebissen und hing am Haken, war er gerne bereit, gegen einen geringen Monatsbeitrag die Bandbreitenlimitierung aufzuheben, den Speicherplatz zu erhöhen, seine Bilder unbegrenzt lange auszustrahlen usw.

Der Fokus auf dem Teilen zeigte sich bis ins Detail und beispielsweise darin, dass hochgeladene Fotos per Voreinstellung den Status „Öffentlich“ hatten. Natürlich konnten und können User diese Einstellungen ändern, aber die Vorauswahl hat es ermöglicht, kürzlich eingestellte Bilder anderer User zu durchstöbern.

Schon früh konnten Nutzer andere Leute als Kontakte markieren, über deren Fotos sie auf dem Laufenden bleiben wollten. User, die www.flickr.com eintippten, sahen sofort, was es Neues gab und welche jüngsten Aktivitäten diese Leute entfaltet hatten.

Jene sozialen Features gaben den Ausschlag dafür, wie Flickr-Nutzer die Website wahrgenommen haben. Bereits „damals“ waren diese Funktionen eingebrannt und nicht aufgesetzt. Dank dieser integrierten Social-Media-Komponenten ist Flickr eine solche Erfolgsgeschichte geworden.

Pionierarbeit geleistet

Für die Flickr-Leute war es nicht einfach, diese sozialen Elemente zu integrieren. Es gab schlicht keine Paradebeispiele, keine andere Website verfügte über solche Funktionen, sie konnten nichts kopieren und sich an keinem Vorbild orientieren. Sie haben es wirklich neu erfunden, als sie sich damit beschäftigt haben.

Zum Glück hatten die Firmengründer ein außergewöhnlich cleveres und ambitioniertes Team um sich geschart. In einer unglaublichen Frequenz haben sie Prototypen und Entwürfe vorgelegt, oftmals mehrere am Tag, und versucht, die besten Methoden zum Lösen der großen Probleme heranzuzoomen.

Heute müssen Teams keine solche Pionierarbeit verrichten, zumindest nicht, wenn es um die Integration sozialer Elemente geht. Flickrs Erfolg hat anschließend viele Konzeptionierer, Designer und Entwickler inspiriert, die diese Konzepte aufgegriffen und wiederum optimiert und erweitert haben. Mittlerweile gibt es viele Beispiele, an denen man sich orientieren kann.

Beispiele identifizieren

Tatsächlich gibt es so viele Beispiele – gute wie schlechte –, dass es kaum möglich ist, den Überblick zu behalten. Deshalb waren wir sehr erfreut, als Christian Crumlish und Erin Malone ihr neues Buch „Designing Social Interfaces“ veröffentlicht haben. Mit ihrem Wälzer von über 400 Seiten haben sie eine beeindruckende Bibliothek mit Anwendungsfällen und aktuellen Trends rund um das Social Interface Design zusammengestellt. Meiner Meinung nach ist das Buch ein Standardwerk für alle, die sich mit Applikationen mit sozialen Komponenten beschäftigen – und das trifft heute eigentlich auf alle Applikationen zu.

Unermüdlich haben Christian und Erin Dutzende Websites mit Social-Media-Komponenten untersucht und alle Arten von Komponenten sorgfältig geordnet und katalogisiert. Sie eröffnen uns sehr interessante Einblicke in die verschiedenen Möglichkeiten, soziale Funktionen zu integrieren. Herausgekommen ist eine wunderbare Sammlung von Mustern, randvoll mit interessanten Beispielen, versehen mit netten Kommentaren über die zahlreichen Ansätze zur Lösung häufig auftretender Probleme.

Wie kann ein Team eine Quelle wie Designing Social Interfaces nun nutzen? Stellen wir uns vor, wir gehören diesem Team an: Wir entwickeln ein neues System, das den Mitarbeitern unseres Unternehmens dabei helfen soll, gesund und in Form zu bleiben. Wir wollen, dass die Angestellten und ihre Familien die Möglichkeiten wahrnehmen, die ihnen die Krankenversicherungen eröffnen, möchten ihnen gute Fachärzte vor Ort empfehlen und Ideen in Sachen Fitness und Gesundheit mit ihnen austauschen. (Nicht zuletzt, weil gesunde Mitarbeiter die Unternehmenskosten senken und die Produktivität erhöhen.)

Die Beispielbibliothek anwenden

Für dieses hypothetische Projekt könnten wir „Designing Social Interfaces“ nutzen und mithilfe dieses Buchs geeignete soziale Komponenten evaluieren. Beim Studium der einzelnen Kapitel kommen uns sicherlich tolle Ideen.

Neue Ideen generieren
Wir wissen zum Beispiel, dass wir Accounts brauchen. Also müssen wir herausfinden, welche Daten mit diesen Accounts verknüpft sein sollen. Wir möchten, dass Mitarbeiter ihre Familienangehörigen im System anlegen können. Wir möchten, dass Nutzer sich inhaltlich beteiligen, dass sie Ideen austauschen und lokale Experten empfehlen. Wir können uns auch vorstellen, dass die Nutzer verschiedene Dienstleitungen und Veranstaltungen bewerten und ihren Kollegen so Orientierungshilfen geben.

Spezifische Optionen evaluieren
Eine gute Beispielbibliothek ist wie ein Sprungbrett. Wenn wir das Buch von Christian und Erin durchblättern, finden wir schnell Stellen mit Anregungen für unser System. Wir können uns die spezifischen Features ansehen und uns fragen: „Würde dieses Feature uns helfen, unseren Usern ein schönes Nutzererlebnis zu bescheren?“

Zum Beispiel sehen wir die verschiedenen Beispiele für Sharing-Funktionen durch, sowohl die für privates als auch die für öffentliches Teilen. Wir entscheiden uns dann für privates Teilen, wenn wir meinen, dass es sich um Informationen handelt, die unsere Nutzer unter Kontrolle halten möchten (vielleicht Spezifika über Ärzte oder medizinische Tests). Auf der anderen Seite finden wir womöglich öffentliches Teilen sinnvoll, wenn es um Rezepte für gesundes Essen oder um Ideen für gutes Training geht. Unser Buch geht jeweils auf Pro und Contra ein und hilft uns bei der Entscheidungsfindung.

Interaktionen zwischen Elementen entdecken
Wie in allen guten Beispielbibliotheken werden auch im Buch von Christian und Erin stets verwandte Beispiele und mit einzelnen Features verbundene Bedingungen angeführt. Sie helfen uns herauszufinden, was wir über eine reine Funktion hinaus beachten müssen.

Wir wünschen uns nun zum Beispiel ein Diskussionsforum, in dem die User Fragen zu medizinischen Verfahren, Fitness und Gesundheit stellen und beantworten können. Dank der Tiefe der Beispielbibliothek finden wir rasch heraus, was mit der Implementierung eines Forums alles einhergeht, dass wir also Komponenten wie die Moderation zu berücksichtigen haben.

Die Feinheiten identifizieren
Wir fänden es toll, wenn unsere User uns sagen würden, wie sie die ganzen Dienstleistungen und Veranstaltungen einschätzen, die auf der Website dargestellt werden. Hierfür gibt es zahlreiche Möglichkeiten: Wir können uns für einen einfachen Daumen-hoch-oder-runter-Indikator entscheiden, wir können ein Sterne-System wählen, wie es bis vor kurzem auf YouTube verwendet wurde, wir können die Leute ausführliche Reviews schreiben lassen.

Christian und Erin haben hervorragende Arbeit geleistet, indem sie die subtilen Auswirkungen beschreiben, die auch mit dieser Auswahl verbunden sind. Wenn wir solche Nuancen gründlich zur Kenntnis nehmen, wählen wir auch die richtige Lösung, die unseren Bedürfnissen entspricht.

Die richtigen Social-Media-Komponenten einbrennen

Christian und Erin haben uns meiner Meinung nach mit ihrem Buch ein wunderbares Geschenk gemacht. Teams, die zu diesem Titel greifen, machen einen großen Schritt in die Richtung: die Social-Media-Komponenten in das System einzubrennen.

Solche Sammlungen helfen uns bei der richtigen Einschätzung von Details und somit dabei, die Erwartungen der User an diese Details zu erfüllen. Das beschleunigt den Entwicklungsprozess und ermöglicht es dem Team, sich auf die Jobs zu konzentrieren, bei denen Innovation sich auszahlt – nämlich bei der Arbeit an den Grundfunktionalitäten, die für die Nutzer den größten Wert haben.

Dieser Artikel wurde im Original am 28. April 2010 unter dem Titel „Baking Social Interfaces Into Your Design“ von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

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

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

Die Gleichung: Viele Backlinks auf die eigene Website mit passenden Link-Texten sorgen dafür, dass die Website von Suchmaschinen als thematisch relevant eingestuft und besser gelistet wird. Google stuft die Relevanz einer Seite also nicht nur auf Basis ihres Inhalts ein, sondern legt auch Link-Texte von Backlinks zugrunde, die auf sie verweisen.

Wenig umkämpfte Suchbegriffe mit Russen-Links erobern

Tatsächlich funktioniert dieses Prinzip prima und mitunter so gut, dass selbst Web-Seiten, die den spezifischen Suchbegriff gar nicht enthalten, in den Trefferlisten Top-Positionen einnehmen. Eindrucksvolle Beispiele sind die sog. Google-Bomben. So funktionieren auch die sogenannten Russen-Links, die man zum Vorteil der eigenen Website einsetzen kann.

Zunächst ist die Bezeichnung Russen-Links nicht abwertend zu verstehen: Vielmehr handelt es sich um einen in der SEO-Branche etablierten Begriff, der ein ganz bestimmtes Phänomen beschreibt: Oft verlinken ausländische Websites, auf denen häufig sogar fremdsprachige Zeichensätze verwendet werden – Russisch eben – auf die deutsche Seite. Eigentlich ist das absurd, da die allermeisten Besucher der verlinkenden Website des Deutschen wohl kaum mächtig sein dürften. Dennoch entfalten diese Links eine ausreichende Wirkung. Der Begriff hat sich aufgrund dieses plastischen Bildes unter Branchen-Insidern durchgesetzt.

Vor allem, wenn eine Website auf einen Suchbegriff optimiert werden soll, der relativ wenig begehrt ist und – als Richtwert – Google für den Suchbegriff weniger als 50.000 Treffer generiert, sind mit solchen Backlinks gute Erfolge zu erzielen. Russen-Links sind mitunter schon für Cent-Beträge zu haben, mit einer Investition zwischen 20 und 50 Euro pro Monat kann man Dutzende oder sogar Hunderte Links einkaufen und wenig umkämpfte Suchbegriffe erobern.

Begehrte Suchbegriffe: mit Links von Websites mit hohem PageRank optimieren

Wer nun aber seinen PageRank steigern oder für härter umkämpfte Suchbegriffe gut gelistet werden möchte, stößt mit diesen Russen-Links schnell an Grenzen: Es sind wirklich extrem viele solcher Backlinks nötig, um den eigenen PageRank zu pushen oder sich im Zusammenhang mit begehrten Suchbegriffen gut zu positionieren.

Gewiss kann ein Website-Betreiber Unmengen dieser günstigen Links einkaufen. Das Problem dabei: Ein solcher Link-Handel verstößt grundsätzlich gegen die Google-Richtlinien und Google sanktioniert unzulässige SEO-Maßnahmen rigoros. Wegen der sehr vielen Backlinks ist die Manipulation offensichtlich und Google kann ihr rasch auf die Schliche kommen. Dementsprechend groß ist die Gefahr, bestraft zu werden.

Als Alternative gibt es diese seriösere oder vielmehr „hochwertigere“ Variante: Es ist zu beobachten, dass viele deutsche Hochschulen Links von der Uni-Website verkaufen. Teilweise kann man eine dort positionierte Seite sogar mit eigenem Content füllen. Freilich gehen diese Aktivitäten von (möglicherweise studentischen?) Webmastern aus, die diese Geschäfte in aller Regel nicht mit der Hochschulleitung abgestimmt haben. Dementsprechend bestehen auch hier Risiken: Eine Garantie, dass diese Links dauerhaft sind, gibt es freilich nicht.

Diese Links entfalten eine beachtliche Wirkung, selbst wenige solcher hochwertigen Backlinks führen zu beeindruckenden positiven Entwicklungen in den Trefferlisten. Dafür muss man allerdings auch etwas tiefer in die Tasche greifen: Mit Beträgen zwischen ca. 50 und ca. 1.500 Euro monatlich ist man im Geschäft.

Allerdings verstößt auch diese Backlink-Beschaffungsmaßnahme gegen die Google-Richtlinien, doch ist es für Google hier sehr schwer, mithilfe von standardisierten Prozessen unerlaubte Maßnahmen zu erkennen. Jedenfalls schätzen Verkäufer von Hochschul-Backlinks die Gefahr einer Google-Abstrafung als eher gering ein.

Aggressive SEO: nicht illegal, aber von Google verboten

Um Missverständnissen vorzubeugen: Natürlich sind Verstöße gegen die Google-Richtlinien nicht illegal, man begibt sich keinesfalls in eine rechtliche Grauzone o. ä. Empfehlenswert sind aggressive SEO-Maßnahmen wie der Einkauf von Russen-Links und anderen Backlinks zum Zweck der Google-Optimierung dennoch nicht.

In der Übersicht:

Vorteile und Rechtfertigung für aggressive SEO

• Google macht keine Gesetze sondern nur Richtlinien. Es ist also keineswegs illegal, derartige Maßnahmen durchzuführen.
• Die Maßnahmen wirken schnell und beeindruckend, frei nach dem Motto „Wir können Google manipulieren!“
• Die Maßnahmen sind sehr kostengünstig (einmalig anfallende Dienstleistungskosten und darüber hinaus nur geringe monatliche Kosten).
• Im Vergleich zur Google-Klickkostenwerbung AdWords ist der Link-Kauf „spottbillig“.
• Durch aggressive SEO werden mehr und interessantere Besucher generiert (bis zu 75% statt 5% aus den Suchenden).
• Die Eintrittsbarrieren sind niedrig, es braucht „lediglich“ SEO-Know-how.

Nachteile und Herausforderungen

• Es besteht die Gefahr, dass Google die Optimierungsseiten aus dem Index entfernt oder – noch schlimmer – die „Handbremse“ zieht.
• Zudem besteht die – wenn auch geringere – Gefahr, dass die verbundenen Seiten ebenfalls entfernt werden.
• Die Wirkung kann durch Algorithmus-Änderungen im Nu verpuffen.
• Die Maßnahmen sind „böse“.
• Es gibt es keinen Anspruch auf eine erneute Listung, wenn man einmal aus dem Google-Index verbannt worden ist.

Also: Mit aggressiver SEO sind wirklich beachtliche, kurzfristige Erfolge zu erzielen. Doch Google arbeitet hart daran, Manipulationen zu erkennen, und ahndet Richtlinienverstöße streng. Im Extremfall heißt es also: Das war’s mit der Auffindbarkeit im Netz. Dieser Gefahr müssen sich Unternehmen, die aggressive SEO-Methoden anwenden, bewusst sein.

Haben Sie Fragen zur Suchmaschinenoptimierung? Fragen Sie sich, ob Ihre Website auch nächste Woche noch gut positioniert oder überhaupt auffindbar sein wird? Möchten Sie Ihr Standing bei Google & Co. durch nachhaltige SEO-Maßnahmen und hochwertigen Content systematisch verbessern? Bitte sprechen Sie uns an. Und auch im öffentlichen //SEIBERT/MEDIA-Wiki finden Sie Informationen zum Thema, die wir ständig aktualisieren und erweitern.

Weiterführende Informationen

White Hat SEO: Seriöse Suchmaschinenoptimierung für dauerhaften Erfolg
Darum lohnt sich Suchmaschinen-Marketing auch für kleiner Unternehmen
Link-Popularität und Suchmaschinenerfolg: Was gute Inhalte und intensive Arbeit bewirken
Ranking: Google liebt Aktualität
Duplicate Content: Ein Problem für das Google-Ranking?

J. und seine Mitarbeiter verteilten Dutzende Eier auf den Seiten von CoffeeCup.com. Kaum hatten sie den Wettbewerb angekündigt, durchforsteten die Besucher die Seite eifrig nach den Preisen.

Abb. 1: Auf CoffeeCup.com wurden Dutzende Ostereier versteckt, um zur Erforschung der Website anzuregen.

J. berichtet, dass diese Promotion-Aktion ein voller Erfolg war: „Abgesehen davon, dass der Traffic und die Verkaufszahlen in die Höhe gegangen sind, haben uns die Leute auch gesagt, dass sie beim Durchstöbern unserer Website eine Menge über uns gelernt hätten. Sie wussten zum Beispiel vorher nicht, dass die Produkte X und Y von uns sind, dass es uns bereits seit 15 Jahren gibt, dass wir einen umfangreichen Support anbieten oder dass wir so eine große Community haben.“

Geek-Punkte sammeln

Auch ThinkGeek.com, eine E-Commerce-Website für allerlei lustige Produkte und Scherzartikel, hat sich eine besondere Werbeaktion für treue Kunden ausgedacht: Die bei früheren Einkäufen gesammelten „Geek Points“ können gegen einige besonders ungewöhnliche Artikel eingelöst werden, beispielsweise den goldenen japanischen Glücks-Hundehaufen für 325 Punkte („Jeder weiß, dass Kacke Glück bringt, erst recht, wenn sie golden ist!“) oder das lustige Gewürz für Leute, die es mögen, wenn sämtliche Speisen nach Frühstücksspeck schmecken, für 400 Punkte.

Abb. 2: ThinkGeek.com schickt E-Mails über den Punktestatus und schlägt kuriose Artikel zum Einlösen vor.

Das Sammeln von Punkten oder Meilen ist seit 30 Jahren Treueprogramm-Standard. Heute können mit wenigen Klicks Punkte ganz einfach gegen Produkte oder Leistungen eingetauscht werden. Doch ThinkGeek ist dieser Service nicht genug, sie nutzen die Gelegenheit auch gleich, um die Aufmerksamkeit auf ein paar ihrer weniger bekannten Artikel zu lenken.

Es ist kein Zufall, dass CoffeeCup und ThinkGeek Schlüsselelemente aufgreifen, die in vielen Games vorkommen: Es ist spannend und es macht Spaß, versteckte Gegenstände zu finden und Punkte zu sammeln, Feedback zum Fortschritt sorgt für die Aufrechterhaltung der Spannung und der Herausforderung.

Indem sie solche Elemente in ihre Websites integrieren, erzielen die Leute von CoffeeCup und ThinkGeek ähnliche Erfolge wie Spiele: Die Nutzer fühlen sich herausgefordert und ihr Interesse an den Angeboten wird gestärkt. Und gleichzeitig tragen diese Features dazu bei, dass mit den Websites die Unternehmensziele erreicht werden.

Psychologische Prinzipien berücksichtigen

Unser Interesse an spielerischen Elementen kommt nicht von irgendwoher, sondern ist ein fester Bestandteil unserer Natur als Menschen. Wir sind eine neugierige Spezies, die sich gerne und oft einer guten Herausforderung stellt und sie genießt. Konzeptionierer, Designer und Entwickler können unsere Wesenszüge und Bedürfnisse in ihre Arbeit einfließen lassen, um unser Nutzerverhalten zu steuern.

Seit einigen Jahren katalogisiert Stephen Anderson die psychologischen Prinzipien, die hinter unserem offenkundigen Verhalten stecken, und konzentriert sich vor allem darauf, wie diese Erkenntnisse bei der Anwendungsentwicklung genutzt werden können. CoffeeCup beispielsweise macht sich Stephen zufolge die Prinzipien der Herausforderung und der Neugierde zunutze, um die User zu veranlassen, die Website zu erforschen. Der Schwierigkeitsgrad wird dadurch erhöht, dass die Eier wirklich gut versteckt sind, und zwar vor allem auf solchen Seiten, bis zu denen die meisten Nutzer normalerweise gar nicht vordringen. So wecken die CoffeeCup-Leute die natürliche Neugierde und lenken das Interesse der User auf das umfangreiche Angebot und auf die Funktionsvielfalt der Website.

ThinkGeek wiederum setzt auf sofortiges Feedback, Humor und Statusinformationen. Sofortige Informationen über den soeben erreichten Punktestand regen den Käufer dazu an, noch mehr Punkte zu sammeln. Witzige Produkte behält der Nutzer eher in (angenehmer) Erinnerung als weniger originelle. Und dank der stets aktuellen Statusanzeige kann der Kunde mit seinem prall gefüllten Punktekonto unter seinesgleichen prahlen, etwa in der Community.

Stephen unterstreicht, dass nicht die Eier oder die Geek Points ausschlaggebend für das große Engagement der Nutzer sind, sondern vielmehr die psychologischen Prinzipien, die diesen Game-Elementen zugrunde liegen. Bei der Entwicklung von Web-Anwendungen müssen wir also verstehen, wie wir diese Prinzipien für uns nutzen können.

Wie LinkedIn zum Ausfüllen der Profile ermutigt

LinkedIn behauptet, dass in den USA die Aussichten auf neue Stellenangebote um das Vierzigfache steigen würden, wenn User ihr LinkedIn-Profil vollständig ausgefüllt haben – im Vergleich zu den Nutzern, deren Profile nur rudimentäre Informationen enthalten.

Die Leute nutzen LinkedIn hauptsächlich, um ihre Karriere voranzutreiben. Das Unternehmen wiederum verdient gutes Geld damit, Recruitern Zugang zu den erweiterten Funktionen und ausführlichen Nutzerinformationen zu geben. Also legt LinkedIn natürlich viel Wert darauf, die User zum Ausfüllen ihres Profils zu ermuntern. Stephen weist hier auf die Profil-Vollständigkeitsanzeige hin, die dieses Anliegen unterstützt: Diese kleinen Fortschrittsbalken auf der Profilseite zeigen an, welche Informationen noch fehlen, bis das Profil vollständig ausgefüllt ist (und damit erst so richtig wertvoll für die interessierten Recruiter und LinkedIn wird).

Abb. 3: LinkedIn motiviert Nutzer, ihr Profil zu 100% auszufüllen.

Kaum hatten die LinkedIn-Leute dieses Feature integriert, konnten sie förmlich dabei zusehen, wie sich die Nutzer immer mehr Zeit nahmen, um ihr Profil zu ergänzen. Bei jedem Schritt wird dem User gesagt, was fehlt, um ein „Level“ abzuschließen. Diese Elemente funktionieren nach den Prinzipien des stufenweisen Aufstiegs, der Herausforderung und des uns innewohnenden Hangs zur Vollständigkeit. Wieder dirigiert die Psychologie die Interaktion.

Einzug in die Sabre Town

Stephen hat uns auch noch die Geschichte von Sabre Holdings erzählt. Wie alle großen Unternehmen wollten sie ihre Mitarbeiter ermutigen, sich an der Erweiterung des internen Wissensmanagement-Systems zu beteiligen. Solche Systeme sind indes bekannt dafür, dass die Mitarbeiteraktivierung zunächst oft schwierig ist. Sabre war hier keine Ausnahme.

Das Team implementierte nun ein neues System namens Sabre Town: Sie integrierten Game-Elemente wie Punkte und Levels und schalteten Funktionalitäten wie die Übersicht über die tägliche Nutzung frei.

Das funktioniert zum Beispiel so: Durch die Beantwortung von Fragen bekommen Mitarbeiter Punkte; noch mehr Punkte gibt es, wenn die Antwort von Kollegen als besonders wertvoll bewertet wird. Auch durch das Anklicken von Profilen anderer Mitarbeiter wandern Punkte auf das eigene Konto. Der Anreiz: Je mehr Punkte ein Angestellter sammelt, desto größer der Funktionsumfang, auf den er zugreifen kann. Beispielsweise kann er ab einer bestimmten Punktezahl mehr Fotos in sein Profil hochladen. Ab einem bestimmten Level werden die Profilbilder automatisch mit  Ehrenabzeichen versehen, die den Nutzer als wichtigen „Heavy User“ kennzeichnen. Und so weiter.

Abb. 4: In der Sabre Town können Mitarbeiter Punkte sammeln und höhere Levels erreichen.

Stephen berichtete von einer Erfolgsgeschichte: Innerhalb kurzer Zeit stieg die Nutzungshäufigkeit des Sabre-Systems dramatisch an, die meisten Mitarbeiterfragen wurden von Kollegen innerhalb von 24 Stunden beantwortet, 60% davon sogar innerhalb einer Stunde, jede Frage erhielt im Schnitt neun Antworten. Sabre hat den Return on Investment in einer ersten Berechnung auf 150.000 Dollar in Form direkter, unmittelbarer Einsparungen innerhalb des Unternehmens beziffert und erwartet einen dauerhaften, kaum schätzbaren Nutzen. Am interessantesten: 65% aller Sabre-Mitarbeiter wurden innerhalb der ersten drei Monate nach Einführung aktive Sabre-Town-Mitglieder. Heute sind es sogar über 90%.

Mit Game-Elementen Anreize schaffen

Game-Elemente wie Punkte, Levels und Herausforderungen sind sehr wirksam bei der Anwendungsentwicklung. Aber, wie Stephen Anderson ganz richtig unterstreicht, sind es nicht die Spielelemente an sich, sondern die dahinter stehenden Prinzipien. Wenn wir diese Prinzipien verstehen und zu nutzen wissen, werden wir mit unseren Anwendungen ähnlich eindrucksvolle Erfolge erzielen, wie wir sie bei LinkedIn, Sabre Town, ThinkGeek und CoffeeCup gesehen haben.

Dieser Artikel wurde im Original am 31. März 2010 unter dem Titel „Designing with Elements of Play“ von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

Eine Studie der School of Journalism and Telecommunications an der University of Kentucky, die sich vorrangig mit den interaktiven Features von Online-Zeitungen beschäftigt, wollte diese Lücke schließen und hat die folgenden drei Forschungsfragen aufgeworfen:

• Welche Arten von interaktiven Features bieten Online-Zeitungen an?
• Wie werden diese interaktiven Features genutzt und bewertet?
• Wer nutzt welche interaktiven Features?

Vorab: Es handelt sich um eine Untersuchung, die auf einer Umfrage unter Nutzern von Online-Zeitungen basiert, eines sicherlich sehr spezifischen Web-Umfelds also. Tendenziell lassen sich die Ergebnisse aber wohl dennoch auch auf andere Websites übertragen: Es geht ja um das grundsätzliche Interesse von Usern an verschiedenen Funktionen.

Kategorien interaktiver Features

Im Ergebnis der Studie wurde erstmals eine Kategorisierung von interaktiven Features vorgenommen. Eine solche Kategorisierung hatte es bis dahin nicht gegeben:

Interaktiver Content
Die erste Kategorie umfasst interaktiven Content wie Video- und Audiodateien. Diese Features sind nicht unmittelbar für jeden verfügbar, sondern können aktiv ein- und ausgeblendet werden, der User kann den Content also verändern und anpassen.

Individueller Content
Der Inhalt der Seite kann individuell dem Interesse des Nutzers angepasst werden. Ein Beispiel hierfür ist die individuelle Wetteranzeige für eine Stadt oder ein Reiseziel.

Aktive Beteiligung durch Content-Veränderung
Durch das Hochladen von eigenen Bildern, Videos und Texten wird der Inhalt einer Seite aktiv durch den Nutzer bearbeitet und verändert.

Sozialer Austausch und Dialog
Via Forum und Chat können sich die Nutzer aktiv äußern und austauschen. So entsteht soziale Interaktion auf der Seite. Es wird nicht mehr nur einseitig Content zur Verfügung gestellt.

Nutzung der Features

Wie werden diese Features nun genutzt und beurteilt? Welche Faktoren begünstigen die Nutzung welcher Funktionen? Die Studie trifft hier klare Aussagen: Je mehr Aktivität seitens der User ein Feature erfordert, desto weniger wird es genutzt. Die erkannte Abstufung ist eindeutig:

• Die Möglichkeit, Audio- und Videodateien aufzurufen, nutzen sehr viele User. Diese Entwicklung ist unaufhaltsam: Vor allem Video-Nutzung ist der Trend der Stunde, eine Sättigung ist nicht abzusehen.
• Die zweite Kategorie, also die Anpassung der Inhalte auf dem Bildschirm, wird ebenfalls von vielen Nutzern als interessant und wichtig eingeschätzt. Im Vergleich zu Audio-Video-Features nutzen diese Möglichkeiten allerdings schon deutlich weniger User.
• Das Hochladen eigener Inhalte bewerten nur noch einige Nutzer als gut bzw. interessant.
• Chat und Forum für Dialog und Austausch werden kaum genutzt. Das Nutzerinteresse an dieser Kategorie ist am geringsten.

Eigenschaften der Nutzer interaktiver Features

Die Studie trifft darüber hinaus Aussagen über die Eigenschaften von Usern, die interaktive Features nutzen oder eben nicht.

• Ein Indikator ist das Geschlecht: Männer nutzen interaktive Features häufiger als Frauen. Bei der Entwicklung und Auswahl der geeigneten Features für eine Website kann dies eine Rolle spielen und sollte deshalb berücksichtigt werden.
• Auch das Alter spielt eine Rolle: Jüngere Nutzer interagieren grundsätzlich eher und intensiver mit Web-Anwendungen als ältere. Dieser Faktor ist aber deutlich weniger einflussreich.
• Wirklich erstaunlich ist, dass der Studie zufolge die Online-Erfahrung keinen Einfluss auf die Nutzung interaktiver Features hat.

Welche Funktionen sind nun sinnvoll?

Es stellt sich also die Frage, welche interaktiven Funktionen Unternehmen auf ihrer Corporate Website anbieten sollten. Ist es für ein Unternehmen wichtig und sinnvoll, ein Forum oder einen Chat zu integrieren? Tatsächlich liegen gerade solche Features nicht wenigen Unternehmen besonders am Herzen.

Die Antwort ist ein klares Nein, denn die Studie bestätigt die Erfahrung: Weder sind Forum und Chat wichtig, noch werden sie intensiv genutzt. Selbst auf Seiten mit viel Traffic, die wichtige Inhalte von allgemeinem Interesse thematisieren – eben Online-Zeitungen –, werden Forum, Chat und vergleichbare Plattformen nur sehr wenig genutzt und von den Usern als unwichtig eingestuft.

Gewiss: Auf Spiegel online oder auf FAZ.net diskutieren Nutzer das Tagesgeschehen tatsächlich in Foren. Nun können wir freilich nur mutmaßen, welche Traffic-Zahlen diese Websites verzeichnen. Allerdings muss man wohl kein Hellseher sein um zu schätzen, dass sich der Anteil der Besucher, die sich im Forum austauschen, im Promillebereich bewegt und dass die vermeintlich zahlreichen Teilnehmer nur einen Bruchteil der gesamten Nutzerschaft darstellen.

Wie viele Nutzer werden das auf einer Unternehmens-Website sein, die nicht Millionen Besucher pro Monat aufweist? In vielen Fällen dürfte sich die Investition in ein am Ende verwaistes Forum oder in einen leeren Chat kaum auszahlen.

Im Einzelfall wiederum stehen die Vorzeichen womöglich anders, etwa wenn ein Unternehmen darüber nachdenkt, ein Forum für die Beantwortung spezieller Kundenfragen oder für den Produkt-Support zu nutzen. Hier kann sich die Implementierung als lohnenswert erweisen.

Doch bei diesen Spezialfällen geht es nicht um den Austausch der Nutzer untereinander, sondern eher um B2C-Kommunikation. Wirklich sinnvoll ist es in aller Regel, Multimedia-Inhalte zu integrieren sowie den Nutzern die Möglichkeit zur Verfügung zu stellen, Inhalte zu personalisieren und sie so zur aktiven Nutzung zu motivieren.

Zielgruppe kennen und Kontext beachten

Grundsätzlich sollte ein Unternehmen die User der Corporate Website genau kennen und in Abhängigkeit davon beurteilen, ob es interaktive Features einsetzt oder nicht. Übrigens wirken sich der Studie zufolge auch Glaubwürdigkeit und Authentizität des eigenen Angebots deutlich auf die Nutzung interaktiver Angebote aus.

Interaktivität ist somit immer im Gesamtkontext zu sehen. Werden Features, die in Anbetracht der eigenen Nutzer sinnvoll sind, auch tatsächlich homogen in den professionellen Web-Auftritt integriert, hält man die Zielgruppe bei Laune und schafft Mehrwert. Andererseits werden sich aufgesetzte, von den Nutzern nicht angenommene Funktionen als kontraproduktiv erweisen.

Haben Sie Fragen zum Thema? Interessieren Sie sich für Nutzerforschung, um Ihre User besser kennenzulernen und um Ihr Online-Angebot besser an die Bedürfnisse Ihrer Zielgruppen anzupassen? Oder benötigen Sie eine Expertise bei der Realisierung neuer Features? //SEIBERT/MEDIA ist Full-Service-Dienstleister und berät Sie im Hinblick auf Konzeption, Usability, Design und Technologie. Bitte sprechen Sie uns an.

Weiterführende Informationen

Web-Design-Trends: Was ist typisch für aktuelle Websites?
Nutzererlebnisse: Was schlecht ist, sieht man, was gut ist, fühlt man
Internet-Nutzung: Nutzerzahlen auf höchstem Niveau, Web-Bindung immer enger

Schlanke und übersichtliche Seiten durch ausgeblendete Inhalte

Zunächst einmal sind Akkordeon-Effekte eine tolle Möglichkeit, viel Inhalt auf wenig Raum darzustellen. Es geht dabei um die effektive Nutzung des sog. Screen Real Estate. Akkordeon-Effekte eignen sich bestens, um auf einer Seite detaillierte Inhalte zu unterschiedlichen Themen abzubilden. Häufig haben Informationen für sich genommen einen zu geringen Umfang, um eine eigene Seite zu füllen. Würde man die Informationen jedoch alle auf einer Seite darstellen, wäre die Seite viel zu lang und unübersichtlich. Genau für diesen Anwendungsfall sind Akkordeon-Effekte wie gemacht.

Die vielen voneinander unabhängigen Detailinformationen werden einfach by default ausgeblendet und über ein Akkordeon verfügbar gemacht. Die Seite bleibt so schlank und übersichtlich. Eine praktische Lösung, wie einige von //SEIBERT/MEDIA umgesetzte Beispiele zeigen: