On sunday I saw that Loic Le Meur and Robert Scoble had a debate on the quality on Robert’s advice for startups in general and his credibility to predict successful tech innovations. That discussion motivated me to tell this story about the product launch of TwentyFeet.com.

When we started programming the basis of what is now a social media egotracker back in summer 2009 we knew, that marketing and “social media juice” would be most critical for our success. My company is a web agency since 1996 with about 60 people and more than 30 programmers. We run a profitable business and are experienced in web technology. We knew we could create a neat application, that would be cool. We had a good team of usability professionals, screen designers, frontend and backend programmers and system administrators. Everything you need for a cool app, that can work and scale. But we wanted to create a social media analytics egotracker. A tool for social media experts.

That was much more of a problem. I had about 250 followers on twitter back then and followed 12 people. I never @replied anybody, I rarely retweeted others and definitely did not read the tweets of these people like Robert Scoble, that formed the milliscoble. Who has time for that? Did I mention, that our facebook fan page had about 30 fans back then? So our big challenge was:

How do you succeed in a social media world as a German nobody?

Gary Vaynerchuk would say: “You need to hustle.” So we tried. I started reading every TechCrunch and Mashable blog post. I learned who Robert Scoble is and read his tweets. I learned, that “.@scobleizer” is different to “@scobleizer” on twitter and why to use it. And if world domination is the goal, where do you head? A TechCrunch feature was our goal. We would literally sell the exclusive rights to publish about TwentyFeet to TechCrunch. What an idea! Everybody would love our app and Michael Arrington would be on the forefront. I read all his blog posts, so I thought I knew what he wanted: exclusive content. He should have it.

It turned out, that Michael Arrington did not give a damn about TwentyFeet. He wouldn’t answer my @replies nor would TechCrunch answer our oh so exclusive offer to market TwentyFeet for us. Mashable wouldn’t either. Although I read their instructions on how to pitch them correctly thoroughly and followed all of their hints. They wouldn’t even answer. It was frustrating. And I understood, what Gary meant: If you are a social media nobody you have to hustle harder.

Okay. So I would write a guest blog post for TechCrunch. I approached them once more and suggested to write something about Google Wave. Erick Schonfeld answered. Erick Schonfeld answered! The second guy next to Arrington. That alone made my day. So I created my Google Wave blog post and submitted it. I thought it was a pretty good one. Then I waited. Don’t bother him too much. I was jumping, when he simply wrote “posted http://bit.ly/8CW8Yr“. My guest blog post learned me what it meant to be loved on social media: 2250 ReTweets of the story, over 300 new followers for my twitter account which would almost double my followers back then, 250 comments, 330 facebook shares, more than 16.000 YouTube views, … (I analyzed these numbers in a German blog post here. [automatic english translation])

And this blog post offered one more thing, that was worth more than all the rest:

Robert Scoble retweeted my article and wrote one himself citing mine.

We got into contact. I learned, that you can call Robert. And that was a game changer. I called him and we talked about TwentyFeet for a short time. He promised to at least take a look, if we were ready. That was back in December 2009.

I also stayed in contact with Erick Schonfeld also but there was a big difference to the communication with Robert Scoble. Both are very busy. But Robert Scoble seems to have way more time to be responsive and to listen. I got answers and tweets, DMs and emails. Erick Schonfeld answered after 3 reminders. I don’t blame him, but still feel like an idiot trying to bother him again and again. That is not the hustle Gary Vaynerchuk is talking about.

The result for my goal for TwentyFeet was: no TechCrunch coverage, no Mashable coverage, but contact with Robert Scoble. He lend me his ear, skyped with me, scheduled an hour long presentation of our application that he sat through asking really clever questions and giving away advice for free, telling us what to focus on and what to omit. And at the end he also gave us, this monumental tweet: “I’ve been testing @TwentyFeet – fun service that aggregates your social network statistics. Video shows you it: http://j.mp/aMJbYC“ Whatever you might think of the grammar, it unleashed a flow of ReTweets, tweets, blog posts and social media love, that we social media nobodies from Germany did not dream to receive.

The effect cannot compete with the response to a TechCrunch blog post about Google Wave. But here is the point: TwentyFeet is not a Google product. We are not the center of a hype. No one dared to take time to speak to us. But Robert Scoble did care.

If you, Loic, really think, that Startups should stop addressing Robert Scoble I claim the opposite:

• Do not dream of a TechCrunch post you will not get.
• Do not try to bother Erick Schonfeld or Michael Arrington for your pitch.
• Try to talk to people who can open doors.
• Talk to Robert Scoble!

Think of motivation: Erick Schonfeld has to publish stories that gain the love of thousands or even millions of RSS readers. Will he take the risk of writing about a small German startup, that might not even go live ultimately? No! He wants stories that win and have little risk. I understand that now. You should not bother him until you play in the league of millions. And now look at Robert Scoble. The frontrunner of social media. Well respected. Well known. Heard. But still one single guy. Somebody who you can call. Somebody whose sole mission is to help startups. He is payed by a hosting provider (Rackspace rocks!) not solely to help rackspace hosted startups. He is payed to help all startups. Big and small. Doesn’t that sound like someone to address at first?

Isn’t it smart to get a sparrings partner first who will help you to cope with the TechCrunch’s and Mashable’s later. Do I think it is an either or? Not at all. But I think, that “Scoble first” is a good choice.

Here are my reasons:

• Robert Scoble takes valuable time for you. You can even call him on the phone.
• He listens. He is not arrogant at all although he would have plenty reasons to be. How refreshing!
• You should listen to him, when he gives advice.
• Do your homework and you might earn that tweet, that can open doors.

I am not saying, that only Robert Scoble can help you. But I think it’s worth a try. Be prepared. Have a cool story. Be short and plain. And then even social media nobodies from Germany can succeed.

Disclaimer: I was not asked nor influenced to write this blog post for Robert Scoble. I wrote it, because I simply needed to make sure, that people who underestimate what Robert Scoble does for people like me, remain silent. Erick: I love TechCrunch. And I still desperately want that blog post.

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

Affiliate-Netzwerke sind Internet-basierte Werbepartnerprogramme, bei denen die Werbepartner (Affiliates, Publisher) auf ihren Websites Werbemittel des werbenden Unternehmens (Advertiser, Merchant) platzieren. Die Vermittlung von Kunden auf das Online-Angebot des werbenden Unternehmens erfolgt in der Regel über Links, es können aber auch ganze Websites oder Shop-Module sein, die der Werbepartner in seine Website einbaut. Für jede erfolgreich vermittelte Transaktion – z.B. das Aufrufen eines Angebots, die Teilnahme an einem Gewinnspiel, die Registrierung in einem Portal, die Durchführung einer Bestellung – erhält der Werbepartner eine Provision. Die Werbepartnerprogramme werden heutzutage überwiegend von unabhängigen Anbietern angeboten, die die technische Administration und die finanzielle Abwicklung für die Affiliate-Partner einerseits und die werbenden Unternehmen andererseits übernehmen.

Die Vertriebsaktivitäten des Unternehmens wachsen – und damit natürlich auch die Wahrscheinlichkeit von Rechtsverletzungen, die durch die Werbepartner begangen werden können. Kommt ein Werbepartner z.B. auf die Idee, Werbe-Links mit fremden Markennamen zu verknüpfen, urheberrechtlich geschützten Content in das Werbemittel einzubinden oder unlautere Werbebotschaften einzusetzen, liegt es nahe, die rechtliche Verantwortung beim werbenden Unternehmen direkt anzusiedeln, das schließlich am meisten von den wachsenden Vertriebsaktivitäten seiner Werbepartner profitiert. Doch ist das so einfach?

Grundsätzlich muss sich ein Unternehmen die Handlungen seiner Mitarbeiter und Beauftragten zurechnen lassen

In der Vergangenheit hatten sich viele Gerichte mit der Frage zu beschäftigen, ob das werbende Unternehmen für rechtswidrige Werbemethoden seiner Affiliate-Partner haftet. Der Gedanke, dass sich der Inhaber eines Unternehmens Verletzungshandlungen seiner Mitarbeiter oder Beauftragten zurechnen lassen muss, ist dem deutschen Recht keinesfalls fremd. Entsprechende Regelungen finden sich im Bürgerlichen Recht, im Wettbewerbsrecht, Markenrecht und Urheberrecht. Das noch zu schließende Glied in der Haftungskette war lediglich die Frage, in welchem Handlungsbereich der Affiliate Partner noch als „Beauftragter“ des Unternehmens im haftungsrechtlichen Sinne gilt und in welchem Bereich er außerhalb seiner Beauftragung sozusagen auf eigene Faust und dementsprechend auch in ausschließlich eigener Verantwortung tätig wird.

Der BGH gibt der Haftung für Affiliate-Partner klare Konturen

Der Bundesgerichtshof (BGH) hat die Reichweite der Haftung des werbenden Unternehmens durch seine jüngere Rechtsprechung klar definiert: Er hat eine Haftungszurechnung für das werbende Unternehmen grundsätzlich bejaht, andererseits die Haftung aber auf Handlungen des Werbepartners beschränkt, die das Unternehmen in zumutbarer Weise kontrollieren kann (BGH, Urteil vom 07.10.2009, Az. I ZR 109/06 – Partnerprogramm).

Im zu entscheidenden Fall hatte ein Werbepartner eines Fahrraddiscounters die Marke „Rose“ als Metatag im Quelltext sowie im sichtbaren Content seiner Website superschnelle-raeder.de verwendet und hierdurch eine Platzierung auf der ersten Seite der Trefferliste von Google erzielt. Von dieser Website aus gelangte man über einen Link auf das Internetangebot des werbenden Fahrraddiscounters. Hiergegen setzte sich der Inhaber der Marke „Rose“ zur Wehr, der seine Marke für Fahrräder, Fahrradeinzelteile und Zubehör registriert hat.

Die Besonderheit in diesem Fall lag darin begründet, dass der Werbepartner nicht mit dieser Website, sondern mit einer anderen, unter der Domain 0049-index.de registrierten Website als Werbepartner angemeldet war. Die Website superschnelle-raeder.de, auf der die Rechtsverletzung begangen wurde, war dem werbenden Unternehmen nicht bekannt.

Der BGH stellte zunächst fest, dass die Nutzung der Fahrradmarke „Rose“ in der Weise, dass sie das Ergebnis des Auswahlverfahrens in der Trefferliste einer Suchmaschine beeinflusst und den Nutzer zu dem Angebot eines konkurrierenden Fahrraddiscounters führt, eine Markenrechtsverletzung darstellt, solange das Markenwort in dem konkreten Kontext nicht ausnahmsweise eine andere Funktion erfüllt (z.B. als Beschreibung für roséfarbene Fahrräder).

Affiliate-Partner sind als Beauftragte des werbenden Unternehmens anzusehen

Der BGH stellte weiterhin fest, dass Werbepartner eines Affiliate-Programms als Beauftragte des werbenden Unternehmens anzusehen sind. Der Unternehmensinhaber soll sich bei seiner Haftung nicht hinter einem von ihm abhängigen Dritten verstecken können, zumal ihm die Erweiterung seines Geschäftsbetriebs durch unabhängige Partner zugute kommt und er den Risikobereich des Werbepartnernetzwerks in gewisser Weise beherrschen kann. Hierbei sei es unerheblich, ob die Werbepartner direkt vom werbenden Unternehmen oder von einem unabhängigen Netzwerkanbieter beauftragt werden. Unerheblich ist es nach Ansicht des BGH auch, wie das werbende Unternehmen und der Werbepartner ihre Rechtsbeziehungen ausgestaltet haben. Das Unternehmen kann sich seiner haftungsrechtlichen Verantwortung nicht einfach entziehen, indem es seinem Werbepartner die Nutzung markenrechtsverletzender Keywords vertraglich untersagt.

Es ist daher möglich, dass der Unternehmensinhaber auch für Rechtsverstöße der für ihn tätigen Werbepartner haftet, die ohne sein Wissen und gegen seinen Willen begangen werden.

Die Haftung des werbenden Unternehmens endet bei nicht angemeldeten Websites

Der BGH setzte der weitgehenden Haftung des werbenden Unternehmens aber wiederum eine Grenze: Das Unternehmen haftet ausschließlich für Rechtsverletzungen im Zusammenhang mit der zum Partnerprogramm angemeldeten Website, wenn nur über diese Website getätigte Links abgerechnet werden und das werbende Unternehmen nicht damit rechnen muss, dass der Werbepartner noch auf weiteren Websites für ihn tätig wird, die ihm unbekannt sind. Diesen Risikobereich beherrscht das Unternehmen nämlich nicht mehr, da die Seiten, auf denen die Rechtsverstöße begangen werden, nicht ohne weiteres ermittelbar sind.

Konsequenz für werbende Unternehmen

Die Entscheidung des BGH beinhaltet einen pragmatischen Kompromiss zwischen einer Freizeichnung des werbenden Unternehmens wegen fehlender Kenntnis der Rechtsverletzungen und einer uferlosen Haftung für sämtliche Fehltritte seiner Werbepartner.

Dem werbenden Unternehmen verbleibt ein Haftungsrisiko, welches es zwar theoretisch durch dauernde Überwachung sämtlicher ihm gemeldeter Websites unter Kontrolle bringen kann, was aber in der Praxis die Grenzen der Wirtschaftlichkeit überstrapazieren würde. Ein gewisses Risiko muss daher in die werblichen Aktivitäten mit einkalkuliert werden.

Das Unternehmen kann dieses Risiko abmildern, indem es seine Werbepartner durch aufklärende Hinweise stärker für die Haftungsgefahren sensibilisiert und Rechtsverstöße sanktioniert, z.B. durch klare Regressregelungen, die Festlegung von entsprechenden Kündigungsrechten und die Vereinbarung von Vertragsstrafen.

Hinweis: //SEIBERT/MEDIA bietet keine Rechtsberatung an. Als Rechtsberatung von //SEIBERT/MEDIA ist auch dieser Artikel nicht zu verstehen. Wenn Sie Fragen haben oder Rechtsberatung in Anspruch nehmen möchten, wenden Sie sich bitte an die Anwaltskanzlei Karsten+Schubert.

Katja Schubert gehört der Rechtsanwaltskanzlei Karsten+Schubert für Wirtschafts- und Unternehmensrecht aus Berlin an. Die Website erreichen Sie unter http://www.karstenundschubert.de. Ausführliche Informationen über die Autorinnen und weitere Fachartikel von Stefanie Jehle und Katja Schubert finden Sie in unserem Special Internet-Recht.

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

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

10. Senf oder Ketchup drauf?

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

9. Hurra, 0,5-ter!

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

8. Man wird ja wohl fragen dürfen

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

7. Geht im Internet alles? Bestimmt!

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

6. Kreuchende und fleuchende Flora?

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

5. Living in the Matrix

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

4. Das Web rückt die Welt enger zusammen

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

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

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

2. Halber Analphabetismus

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

1. Aha, Sie waren das also!

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

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

Weitere Informationen und ähnliche Beiträge

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

Google Suggest im Visier der SEO-Agenturen

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

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

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

Manuelle Beeinflussung der Vorschlagslisten

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

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

Manipulationen in der Grauzone

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

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

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

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

Spekulationen und vermeintliche Automatisierung

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

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

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

Weiterführende Informationen

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

Die Kehrseite: Namen mit unpassenden Begleitbegriffen

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

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

Analyse mittels XML-Anfrage

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

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

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

Das weitere Vorgehen

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

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

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

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

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

Weiterführende Informationen

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

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!

Seit nunmehr zehn Jahren arbeitet //SEIBERT/MEDIA eng mit Atlas zusammen und hat zahlreiche Projekte für das Unternehmen verwirklicht, darunter auch die Corporate Website und ein Firmenwiki. Jamie Chesler, General Manager for Marketing and After Sales, war so freundlich, die Zusammenarbeit mit //SEIBERT/MEDIA aus Kundensicht zu beschreiben:

Jamie Chesler über die Dienstleistungen, die //SEIBERT/MEDIA für Atlas erbringt:

Hauptsächlich unterstützt //SEIBERT/MEDIA uns im Online-Bereich. //SEIBERT/MEDIA hat mehrere Unternehmens-Websites für uns erstellt, kümmert sich um unser Extranet und unterstützt uns bei unseren Online-Marketing-Aktivitäten.

Jamie Chesler über die Zufriedenheit mit //SEIBERT/MEDIA:

Wir sind sehr zufrieden, //SEIBERT /MEDIA leistet sehr gute Arbeit. Unsere Unternehmen sind praktisch gemeinsam gewachsen, die Zusammenarbeit ist daher sehr eng. Wir schätzen vor allem die Flexibilität. Wir sind ein internationales Unternehmen und es macht keinen Unterschied, dass wir in den USA arbeiten: Wir erhalten den Service, den wir erwarten würden, wenn wir in Deutschland ansässig wären. Diese Unterstützung ist für uns sehr wichtig und //SEIBERT/MEDIA bietet uns diesen guten Service zu jeder Zeit.

Wir danken Jamie Chesler für diese Kundenstimme und freuen uns auf eine weitere erfolgreiche und vertrauensvolle Zusammenarbeit mit Atlas!

Weiterführende Informationen
Weitere Stimmen von //SEIBERT/MEDIA-Kunden
//SEIBERT/MEDIA berät weltweit

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.

Das Internet ist seit seinen Anfängen mit einer gewissen „Kostenlos-Mentalität“ verknüpft: Nutzer sind es gewohnt, Inhalte kostenfrei zu erhalten und dafür allenfalls Banner oder ähnliche Werbemittel in Kauf zu nehmen. Davon können nicht nur redliche Anbieter kostenpflichtiger Leistungen ein Lied singen, die dadurch mit Absatzhemmnissen zu kämpfen haben.

Diese Kostenlos-Mentalität machen sich seit einigen Jahren zunehmend auch sog. Abofallen zunutze. Sie suggerieren durch ihre Aufmachung, dass die zu erhaltene Leistung kostenfrei sei. Nur wirklich aufmerksamen Nutzern fällt auf, dass das Gegenteil der Fall ist. Das versprochene Angebot ist vielfältig: Ahnenforschung, Routenplaner, Horoskope, Download von Software, Unterstützung bei Hausarbeiten oder in der Schule. Nicht selten sind es gerade die jüngeren Internet-Nutzer, auf die es die Anbieter abgesehen haben.

Die Hinweise auf die Kosten sind dann entweder in den Untiefen von kleingedruckten AGB bzw. versteckten Links oder Sternchen verschleiert oder es wird über die Kostenpflichtigkeit durch Begriffe wie „gratis“ oder „free“ schlicht getäuscht. Ganz harmlos soll man sich zuvor noch rasch mit Namen und Adresse anmelden, um dann das schöne Angebot kostenfrei nutzen zu dürfen. Die Überraschung ist dann umso größer, wenn die Rechnung über ein lang laufendes Abonnement oder einen teuren Online-Service ins Haus flattert.

Hat der Anbieter einen Anspruch auf Zahlung?

Ist man einem Abofallen-Anbieter auf den Leim gegangen, besteht kein Grund zur Panik. Werden die Kosten rechtswidrig verschleiert, hat der Anbieter regelmäßig keinen Zahlungsanspruch, denn entweder wurde ein Vertrag gar nicht rechtswirksam geschlossen oder der geschlossene Vertrag kann wegen arglistiger Täuschung angefochten werden.

Auch verbotene Klauseln in AGB sind rechtlich nicht bindend. Ein Beispiel hierfür ist eine in AGB enthaltene Zahlungspflicht, wenn zuvor der Eindruck erweckt wurde, das Angebot sei kostenfrei. Ebenso wurde eine Klausel, die im Zusammenhang mit der Nutzung von Datenbanken eine Vorauszahlungspflicht des Kunden festlegt, bereits als AGB-rechtlich unzulässig beurteilt.

Auch ein vom Kunden zu bestätigender Button „Ich verzichte auf mein Widerrufsrecht“ verhilft den Anbietern nicht zum Erfolg. Soweit ein Widerrufsrecht besteht, ist dieses vom Gesetz zwingend vorgesehen und kann nicht ausgeschlossen werden.

Die verschiedenen Facetten des Vertragsrechts halten also eigentlich genügend Mechanismen bereit, um sich erfolgreich zur Wehr zu setzen. Vielen Opfern ist jedoch die für sie günstige Rechtslage nicht bekannt – obwohl das Thema Abofalle auch im Internet und im TV rege und ausführlich diskutiert wird. Hinzu kommt, dass die eintrudelnden Zahlungsaufforderungen – verhältnismäßig betrachtet – eine geringe Höhe haben. Nicht jeder ist bereit, sich deswegen auf nervende Korrespondenz einzulassen – zumal das Gehabe beim Eintreiben der Rechnungsbeträge auf juristische Laien einschüchternd wirkt.

Reaktion im Falle eines Falles

Wenn Sie glauben, Opfer einer Abofalle geworden zu sein, und die eingetroffene Rechnung nicht bezahlen wollen, müssen Sie sich darauf einstellen, massive Drohungen des Anbieters über einige Zeit hinweg über sich ergehen zu lassen: Mahnungen, Drohbriefe, Inkassoschreiben oder gar Telefonanrufe. In der Praxis hat sich aber gezeigt, dass trotz dieser Drohungen nur selten gerichtliche Schritte eingeleitet werden.

Auch das Bundesjustizministerium rät inzwischen offiziell und eindeutig: Nicht zahlen! Auf Rechnungen und Mahnungen muss man gar nicht reagieren. Möchte man dennoch etwas tun, kann man die Gegenseite darauf hinweisen, dass kein Vertrag zustande gekommen ist und vorsorglich die Anfechtung bzw. den Widerruf erklären. Die Verbraucherzentralen stellen Musterbriefe bereit, mit denen Opfer in geeigneter Weise reagieren können.

Trifft ein gerichtlicher Mahnbescheid ein, muss man unbedingt schnell reagieren und Widerspruch erheben. Dieser Widerspruch muss innerhalb einer Frist von zwei Wochen beim Mahngericht eingegangen sein. Haben Sie dies versäumt, ist unbedingt fristgerecht Einspruch gegen den dann folgenden Vollstreckungsbescheid einzulegen. Auch hierfür finden Sie Muster bei den Verbraucherzentralen.

Will man sich Stress und Nerven von vornherein ersparen, hilft nur eins: Die Internet-Angebote vollständig und aufmerksam lesen. Ein gesundes Misstrauen bei vermeintlich kostenlosen Angeboten ist durchaus angebracht.

Hinweis: //SEIBERT/MEDIA bietet keine Rechtsberatung an. Als Rechtsberatung von //SEIBERT/MEDIA ist auch dieser Artikel nicht zu verstehen. Wenn Sie Fragen haben oder Rechtsberatung in Anspruch nehmen möchten, wenden Sie sich bitte an die Anwaltskanzlei Karsten+Schubert.

Dr. iur. Stefanie Jehle gehört der Rechtsanwaltskanzlei Karsten+Schubert für Wirtschafts- und Unternehmensrecht aus Berlin an. Die Website erreichen Sie unter http://www.karstenundschubert.de. Ausführliche Informationen über die Autorinnen und weitere Fachartikel von Stefanie Jehle und Katja Schubert finden Sie in unserem Special Internet-Recht.

Die Link-Popularität bewertet sowohl die Anzahl der externen Seiten, die auf die eigene Seite verlinken, als auch die Qualität dieser Links. Dazu schätzt Google ein, wie wertvoll ein Link tatsächlich ist, und legt dafür die Suchmaschinenrelevanz und den PageRank der verlinkenden Seite zugrunde.

Link-Akquise

Es gibt verschiedene Möglichkeiten, Links für die eigene Website zu akquirieren. Allerdings: Nicht alles ist erlaubt und nicht alles ist risikolos, denn gerade für Off-Page-Maßnahmen haben Google & Co. klare Richtlinien aufgestellt

Um das Ranking der Seite zu verbessern, sind sowohl starke als auch schwache Links (diese sicher in größerer Anzahl) wichtig. Dabei sollte die Zahl der eingehenden Links langsam, aber kontinuierlich wachsen.

Möglich sind rein grafische Links oder Text-Links. Im besten Fall sollten die Links aber die entscheidenden Keywords enthalten. Sehr wichtig für ein gutes Ranking ist zudem, dass auch die Unterseiten selbst verlinkt werden.

Tauschen von Links

Die klassische Variante der Link-Akquise ist der Link-Tausch: Website-Betreiber, die zumeist thematisch ähnliche Angebote betreiben, verlinken sich gegenseitig. Allerdings wirkt der Link-Tausch nur in einem sehr überschaubaren Rahmen, sofern man nicht wirklich populäre Websites als Tauschpartner gewinnen kann. Um den eigenen PageRank signifikant zu steigern, sind in aller Regel sehr viele getauschte Links nötig, was mit erheblichem Aufwand verbunden und kaum gangbar ist.

Beim Link-Tausch müssen Betreiber besonders darauf achten, dass die eigene Seite durch Verlinken mit unseriösen Seiten nicht selbst als „böse“ eingestuft wird. Wer sich in schlechte Nachbarschaft (Bad Neighbourhood) begibt, bekommt mitunter rasch Probleme mit Google.

Link-Kauf

Link-Kauf bezeichnet das dauerhafte Anmieten von Back-Links. Diese Maßnahmen sind für viele Website-Betreiber kaum verzichtbar, insbesondere wenn sie in einem hart umkämpften Markt mit zahlreichen konkurrierenden Anbietern aktiv sind: Die Linkpopularität kann oft nur durch Link-Kauf gesteigert werden, um ein akzeptables Ranking zu erzielen.

Google verbietet den Link-Kauf allerdings und sanktioniert Verstöße gegen diese Richtlinie. Für Link-Verkäufer und Interessenten gibt es regelrechte Marktplätze. Wer dort agiert läuft  immer auch Gefahr, von Google abgestraft zu werden. Zudem besteht stets das Risiko, sein Geld in den Sand zu setzen, wenn mitunter teuer eingekaufte Links über Nacht wertlos geworden sind. Die Preise für Links schwanken zwischen Cent-Beträgen für sog. Russen-Links und nicht unerheblichen Summen für hochwerte Links bspw. von Hochschul-Websites.

Link-Baiting

Nachhaltiger, seriöser und Richtlinien-konform ist das sog. Link-Baiting. Hierbei geht es darum, die eigene Website von anderen Seiten verlinken zu lassen, ohne dies wie bei den gerade beschriebenen Maßnahmen aktiv voranzutreiben. Voraussetzung dafür ist hochwertiger, interessanter Content, der andere Seitenbetreiber dazu bringt, die eigene Website (ohne Gegenleistung) zu verlinken.

Die Themenrelevanz spielt beim Link-Baiting noch keine so große Rolle. Es ist aber davon auszugehen, dass langfristig thematisch passende Links wertvoller als andere sein werden.

Fazit

Bei der Off-Page-Optimierung trennt sich auch die Spreu vom Weizen: Viele aggressive Suchmaschinenoptimierer konzentrieren sich fast ausschließlich auf die Off-Page-Optimierung. Mit ihr (und vor allem mit dem Link-Kauf) sind schnell beeindruckende Ergebnisse zu erzielen, sie zeigt häufig unmittelbar Wirkung. Die im vorangegangenen Artikel beschriebenen On-Page-Maßnahmen werden hingegen vernachlässigt.

Wie gezeigt ist dieser Ansatz gefährlich und Website-Betreiber, die auf aggressive SEO-Aktivitäten setzen, müssen wissen, dass sie Risiken eingehen und im Fall der Fälle gar ein Rauswurf aus dem Google-Index droht.

Wer eine dauerhafte Optimierung anstrebt ist gut beraten, auf Seriosität und Nachhaltigkeit zu setzen und vor allem in On-Page-Optimierungen, in ein sauberes technologisches Fundament und in gute Inhalte zu investieren. So werden die besten Voraussetzungen für ein stabil gutes Ranking geschaffen, das sich zwar nur allmählich verbessert, aber auch von Dauer ist.

Haben Sie Fragen zum Thema SEO? 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
Ranking: Google liebt Aktualität
Duplicate Content: Ein Problem für das Google-Ranking?

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).

Drei Sieger beim Sommerfest-Fußballturnier

Bestes Fußballwetter und insgesamt 18 Hobbykicker von //SEIBERT/MEDIA und Freunden – beste Voraussetzungen für den Einstieg in einen Tag ganz im Zeichen des Balls, der mit einem kleinen Turnier mit Sechser-Teams auf dem Kleinfeld begann: 20 Minuten Jeder gegen Jeden.

Alle Spiele endeten torreich, aber jeweils schiedlich friedlich unentschieden, so dass tatsächlich gleich alle Teams zum Turniersieger gekürt werden konnten. Anschließend gab’s ein Neun gegen Neun auf dem Halbfeld, sodass nach den Künstlern und Auf-engstem-Raum-Dribblern nun auch die Pferdelungen und Strategen ihre Fähigkeiten in die Waagschale werfen konnten.

Gute Stimmung bei einem tollen WM-Einstand

Schauplatz des zweiten Teils unseres Sommerfestes waren dann unsere Büros im Wiesbadener Rheingau Palais, wo sich auch Kollegen, Partner und Freunde einfanden, die mit dem aktiven Kicken weniger am Hut haben. Hier wartete bereits ein leckeres Buffet auf die hungrigen und durstigen Gäste, das natürlich auf Kosten des Hauses ging – wiederum ein perfekter Einstieg in den anschließenden WM-Abend, an dem die fröhliche Stimmung schließlich in Begeisterung gipfelte, als wir uns gemeinsam den überzeugenden WM-Auftakt Deutschlands gegen die Socceroos aus Australien im //SEIBERT/MEDIA-WM-Studio angesehen haben.

Unser Sommerfest im Zeichen des Balls war eine rundum gelungene Angelegenheit! An dieser Stelle möchten wir alle insbesondere unseren fleißigen Helfern im Hintergrund – Melanie und Timo – herzlich für die perfekte Organisation danken!

Wir sind im WM-Fieber und helfen auch Kunden, die Begeisterung hoch zu halten

Auch über das Sommerfest hinaus hat uns der Fußball natürlich in seinen Bann gezogen und die Begeisterung steigt täglich, nun da sich das Turnier mit großen Schritten der KO-Phase nähert und Deutschland im anstehenden Achtelfinalklassiker ein Wiedersehen mit dem alten Rivalen England erwartet: REWE-Bildchen haben den Status einer Währung, Aufkleber aus Duplo-Riegeln verschönern viele Arbeitsplätze, im großen und vollkommen beflaggten Aufenthaltsraum kommen Kollegen zusammen, um die deutschen Spiele gemeinsam zu schauen und zu feiern. Und auch beim täglichen Mittagessen gibt es natürlich kaum ein anderes Thema als die zurückliegenden und anstehenden Spiele.

Im //SEIBERT/MEDIA-WM-Tippspiel, an dem immerhin knapp 20 Kollegen teilnehmen, haben dagegen viele von uns Möchtegern-Experten arg an den teils schwindelerregenden Ergebnissen der Vorrundenspiele zu knabbern: Spaniens Niederlage gegen die Eidgenossen, die teils erschreckenden (oder alternativ: erheiternden) Auftritte Englands, Italiens und allen voran Frankreichs sowie natürlich die unglückliche deutsche Pleite gegen Serbien haben für einige Nullrunden gesorgt.

Übrigens: Für einen Kunden hat //SEIBERT/MEDIA ein internes WM-Tippspiel mit automatischer Auswertungsfunktion auf Basis einer oberflächenangepassten TYPO3-Extension realisiert. Auf das Tippspiel im Intranet haben alle Kollegen via LDAP Zugriff und nutzen dieses Feature erfreulicherweise sehr intensiv. //SEIBERT/MEDIA hilft also auch Kunden, die Weltmeisterschaft gebührend zu begehen.

Fußball überall – aber keine Sorge, bei allem Enthusiasmus kommen unsere Projekte natürlich nicht zu kurz und wir liefern wie gewohnt starke Ergebnisse. Hoffen wir auf weitere schöne WM-Wochen, spannende Tipprunden, viele komplettierte REWE-Alben und natürlich, dass unsere Elf zumindest das Achtelfinale erfolgreich überstehen wird. Trööööt.

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

1. Office Connector

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

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

2. WebDAV-Plugin

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

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

3. Widget Connector

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

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

4. SQL-Plugin

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

Foswiki bietet hierfür das Database-Plugin an.

5. Label-Management-Plugin

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

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

6. Metadata-Plugin

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

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

7. Gliffy-Plugin

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

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

8. Dynamic Task List

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

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

9. TaskDock

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

Foswiki kann solche Funktionalitäten nicht abbilden.

10. Gallery-Plugin

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

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

11. Chart-Plugins

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

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

Vergleich Äpfel mit Birnen? Nein!

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

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

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

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

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

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

Weiterführende Informationen

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

Informationen für Mitarbeiter

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

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

Informationen zu Prozessen

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

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

Informationen über das und vom Unternehmen

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

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

Produkt- und Leistungsinformationen

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

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

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

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

Weiterführende Informationen

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

Interessante Informationen nicht nur für Atlassian-Kunden

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

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

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

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

Nehmen Sie teil – ein Klick genügt

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

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

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

Weitere Informationen

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

Rückblick auf die erste Live-Session

In der ersten Session waren ca. 40 verschiedene Nutzer dabei, während der eigentlichen Präsentation 22 User über den gesamten Zeitraum hinweg. Nicht schlecht fürs erste Mal, zumal sich auch ein Austausch ergeben hat und wir Moderatoren Argumente der Teilnehmer integrieren und auf Fragen von Nutzern eingehen konnten.

Hier ist die Video-Aufzeichnung der ersten Session:

In dieser Sendung sind wir zu dem Schluss gekommen, dass das iPad dem Kindle um einiges voraus ist, dieses so schnell aber dennoch nicht aussterben wird. Einige unserer Notizen:

• Amazon wollte das Kindle eigentlich nie produzieren, war aber dazu gezwungen, um das Buchgeschäft anzukurbeln. So sieht das Gerät auch ein bisschen aus.
• Eigentlich ist das Kindle gar nicht auf den deutschen Markt ausgelegt: Es gibt so gut wie keine deutschen Produkte, das mitgelieferte Ladekabel hat lediglich einen amerikanischen Lade-Anschluss.
• Das Kindle ist kein Konkurrent, sondern eher ein kleiner Bruder des iPad. Es verträgt sich mit dem iPad dank Amazons Sync-Technologie nämlich sehr gut.
• Das Kindle ist keine praktische Alternative, um es mit auf Reisen zu nehmen. Da passt das iPhone einfach besser in die Tasche und mit der iPhone-Kindle-App ist es auch vollkommen ausreichend, um 30 Minuten zu lesen.
• Für den Einsatz zu Hause bietet das iPad natürlich deutlich mehr Möglichkeiten durch Farbe und die vielen anderen Anwendungen (insb. E-Mail). Deshalb ist es sehr wahrscheinlich, dass es zu Hause auch viel häufiger genutzt wird als das Kindle.

Aber:

• Amazon dürfte mittelfristig bessere Preise für Bücher machen können als Apple. Das ist natürlich etwas spekulativ, spricht aber eher für das Kindle als das iBook.
• Die Sync-Funktion des Kindle ist derzeit ein überzeugender Grund, um keine Bücher im iBook-Store kaufen zu wollen. Nur das iPad reicht zum Beispiel für die Nachbearbeitung von Sachbüchern nicht aus.
• Für Kindle gibt es etwa 250.000 Bücher, für iBook nur etwa 60.000. (Das war zumindest zum Launch-Termin in Amerika so.)
• Amazon hat gerade angekündigt, in der Software künftig auch eine Tweet-Funktion anbieten zu wollen. Auch ein Posten auf Facebook soll offenbar möglich werden. Das bedeutet wohl, dass Amazon sich weiter bewegen möchte.
• Das iPad macht auf jeden Fall mehr Spaß und ist dem Kindle insgesamt überlegen.
• Als basales, aber seriöses Gerät hat das Kindle sicherlich eine Daseinsberechtigung und ist als Ergänzung zum iPad völlig okay.

Einen sehr interessanten Überblick bietet auch dieses Video zum Thema:

Die gesammelten Erkenntnisse aus der Session haben wir in unserem öffentlichen Wiki für Sie aufbereitet. Dort finden Sie viele Links, weitere Videos und ausführliche Informationen zum Thema.

Live-Sessions ab jetzt im Wochenrhythmus

Nach diesem erfolgreichen Auftakt gehen die Live-Video-Sessions von //SEIBERT/MEDIA zu interessanten Themen rund um technologische Entwicklungen, Social Media und Unternehmenskommunikation in die nächsten Runden: Ab jetzt regelmäßig und im Wochenrhythmus.

Den Anfang macht am kommenden Freitag (18. Juni 2010) von 10:30 bis 11:15 Uhr die Session zum Thema „Ergebnisse des Atlassian Summit 2010: Welche Änderungen gab es? Was bedeuten sie?“

Diese Sendung richtet sich vor allem an Unternehmen, die Atlassian-Produkte wie Confluence oder JIRA bereits einsetzen oder die dabei sind, Firmenwikis oder Aufgabenmanagementsysteme zu evaluieren. Doch wir möchten auch Nutzer ansprechen, die einfach mal einen Einblick in die Politik und die Strategieentwicklung von Software-Herstellern erhalten möchten.

Dies sind die kommenden Themen und Termine im Überblick:

Und so einfach geht’s

Für die Live-Video-Übertragung nutzen wir die Plattform UStream.tv und für den Live-Chat eine webbasierte IRC-Oberfläche. Sie müssen keinerlei Vorbereitungen treffen, es genügen ein Rechner mit Web-Anschluss, Ton und Flash. Um an unseren Sessions teilzunehmen, klicken Sie sich auf http://seibert.biz/live einfach direkt rein. Toll wäre es, wenn Sie sich vorher in die Teilnehmerliste eintragen würden. Aber gerne können Sie auch spontan und ohne Voranmeldung reinschauen und mit uns diskutieren, wenn Sie mögen.

Was wir erreichen möchten

In erster Linie sehen wir dieses Angebot als Kundenservice von //SEIBERT/MEDIA an. Wir möchten mit diesen Sendungen eine interessante und neuartige Form der Interaktion schaffen, die tatsächlich auch live und damit mit erheblichem Zusatznutzen für den Kunden verbunden ist.

Als Interessent oder Kunde können Sie sich live beraten lassen, Sie können sich in Echtzeit einbringen, Fragen stellen und natürlich gerne Ihre Meinung kundtun. Wir bieten Ihnen kompetente und persönliche Beratung bei geringen Transaktionskosten für Sie, denn Sie bleiben anonym und gehen keinerlei Verpflichtungen ein. Wir wollen damit zeigen, wie Social Media unserer Meinung nach richtig genutzt werden kann und sollte, und den Kontakt zu Ihnen enger und vor allem interaktiver gestalten. Und nicht zuletzt möchten wir Ihnen die Gelegenheit bieten, uns besser kennenzulernen.

Gewiss: Am Anfang müssen wir noch kleine Kinderkrankheiten kurieren, denn dieses Format ist auch für uns neu. Aber wir sind sicher, dass wir die //SEIBERT/MEDIA-Live-Sessions weiter professionalisieren und Ihnen einen stetig steigenden Mehrwert bieten können.

Wir freuen uns auf Ihren Besuch. Schauen Sie mal rein – warum nicht schon am Freitag um 10.30 Uhr, wenn es um den Atlassian Summit geht? Hier geht’s direkt zur Live-Online-Beratung.

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

Um den renommierten Preis haben sich Unternehmen aus 26 Ländern beworben und insgesamt 1.687 Beiträge eingereicht, die von der hochkarätig besetzten, internationalen Jury in Sachen Zielgruppenansprache und Inhalt, Usability, Look and Feel und Einzigartigkeit/Originalität begutachtet wurden. Nun ist unser Design-Team für die Gestaltung des neuen Social-Media-Auswertungs-Tools TwentyFeet in der Kategorie Digital Media – Screendesign ausgezeichnet worden.

Eingereicht hat //SEIBERT/MEDIA/DESIGN unter anderem dieses Bewerbungsvideo:

Mit dem iF award sieht sich das ganze Team bestätigt, das fieberhaft an TwentyFeet arbeitet, denn von Anfang an haben wir großen Wert auf ein hochqualitatives, originelles, nutzerfreundliches Design gelegt. Und bis zur offiziellen Preisverleihung im September wird die Anwendung natürlich online sein. (Gerne können Sie sich auf der Website jetzt schon vorregistrieren, so bleiben Sie über alle Entwicklungen auf dem Laufenden.)

Anschließend wird der Beitrag von //SEIBERT/MEDIA/DESIGN in der iF online exhibition zu sehen sein und im weltweit vertriebenen iF-Jahrbuch ausführlich vorgestellt werden.

Herzlichen Glückwunsch //SEIBERT/MEDIA/DESIGN!

Weitere Informationen:
Die Website mit Vorab-Informationen zu TwentyFeet
Die Website von //SEIBERT/MEDIA/DESIGN
Design-Auszeichnung: //SEIBERT/MEDIA/DESIGN erhält den iF award
Video im Web: Neue Kommunikationsmöglichkeiten für Unternehmen
Die Website des International Forum Design

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

Wer mit der Google-Bildersuche nach einem Begriff sucht, bekommt eine Trefferliste in Form von Thumbnails angezeigt. Nach Anklicken eines dieser Miniaturbilder wird auf einer gesonderten Seite im oberen Bereich noch einmal der Thumbnail zusammen mit dem Hinweis „Das Bild ist möglicherweise urheberrechtlich geschützt. Im Folgenden finden Sie das Bild unter:“ nebst Link angezeigt. Darunter befindet sich die Originalseite, die mittels Framing-Technik eingebunden wird.

Nicht jeder, der ein Foto oder ein anderes Bild auf seiner Website präsentiert, ist allerdings damit einverstanden, dass sein Werk auch über diese Bildsuche gefunden wird. Es stellt sich daher die Frage, ob eine Suchmaschine auch ohne Zustimmung des Urhebers ein Werk in ihre Bildersuche aufnehmen darf.

LG Hamburg: Thumbnails verletzen Urheberrecht

Ein Inhaber von Urheberrechten an Comic-Zeichnungen entdeckte die auf seiner Webseite abgebildeten Zeichnungen als Thumbnails bei der Google-Bildersuche und ging gegen Google wegen der Verletzung seiner Urheberrechte vor. Einer Nutzung als Thumbnail hatte er nicht zugestimmt. Auf die Abmahnung hin reagierte Google jedoch nicht. Die Zeichnungen wurden weiterhin in den Ergebnislisten angezeigt. Mit seiner Klage vor dem LG Hamburg verlangte der Rechteinhaber Unterlassung der Verwendung der Zeichnungen in der Bildersuche, Auskunft über die Verwendung der Zeichnungen und Ersatz seiner Abmahnkosten.

Das LG Hamburg gab dem Kläger Recht. Es sah durch die Thumbnails die Urheberrechte an den geschützten Zeichnungen als verletzt an, da Google sie ohne Berechtigung durch die Bildersuche öffentlich zugänglich machte. Das Gericht sieht in den Thumbnails eine Verwendung der Originalwerke, auch wenn die Thumbnails stark verkleinert und in gröberer Auflösung angeboten werden. Die Thumbnails sind gerade keine fragmentarischen oder ausschnitthaften Vorschauen auf das Original, sondern nur verkleinerte. Diese Veränderungen sind daher nicht so weitgehend, dass der Urheber dies akzeptieren muss. Eine sogenannte freie Benutzung, bei der ein anderer das Werk quasi nur als Anregung nimmt, um ein eigenes Werk zu erstellen, liegt bei den Thumbnails nicht vor. Auch eine andere zulässige Benutzung, die das Urheberrechtsgesetz kennt (etwa das Zitatrecht), oder sonstige Einschränkung des Urheberrechts verneinten die Richter bei der Nutzung der Bilder als Thumbnails.

Zulässig ist hingegen die Anzeige der Originalseite mittels eines als solchen erkennbaren Framings, da in diesem Fall ausreichend deutlich auf das fremde Angebot hingewiesen wird. Ebenso ist die Darstellungsoption „Bild in Originalgröße zeigen“ zulässig, da in diesem Fall mittels Deep-Link auf die Ursprungs-Seite zurückgegriffen wird. Bereits seit einiger Zeit ist höchstrichterlich anerkannt, dass das Setzen eines Deep-Links keine Urheberrechtsverletzung darstellt.

Unter Hinweis auf die aktuelle Gesetzeslage sahen sich die Richter im Ergebnis ausdrücklich außerstande, branchenspezifische Urheberrechtsschranken zur Privilegierung von Suchmaschinen zu finden, auch wenn Suchmaschinen anerkannterweise zur sinnvollen Strukturierung und Suche im Internet beitragen (vgl. LG Hamburg, Teilurteil vom 26.09.2008, Az. 308 O 42/06).

Zu dem gleichen Ergebnis kam das LG Hamburg in einem anderen Fall vom selben Tag, in dem es um ein als Thumbnail abgebildetes Foto ging (vgl. LG Hamburg, Teilurteil vom 26.09.2008, Az. 308 O 248/07). In beiden Fällen wurde Berufung beim OLG Hamburg eingelegt.

Gesetzgeberische Klarheit gefordert

Das Urteil des LG Hamburg wurde in der juristischen Fachwelt überwiegend kritisiert: eine Kritik, die sich gegen eine die sinnvollen Möglichkeiten der Suchmaschinennutzung einschränkende Rechtsprechung wendet. Allerdings ist sich die Fachwelt relativ einig, dass hier gesetzgeberisches Handeln oder zumindest eine klare Richtlinie durch die Obergerichte erforderlich ist. Bis dahin wird die Nutzung der Thumbnails in der Bildersuche grundsätzlich urheberrechtswidrig bleiben.

Hintergrundinformation: Zugänglich-Machen im Sinne von § 19a Urheberrechtsgesetz

§ 19a Urheberrechtsgesetz wurde erst vor einigen Jahren angesichts der zunehmenden Verbreitung des Internets neu eingeführt. Das sogenannte Recht der „öffentlichen Zugänglichmachung“ bezieht sich im Wesentlichen auf die Nutzung von Werken im Internet. Mit der sprachlich etwas hölzern klingenden Formulierung der öffentlichen Zugänglichmachung ist das Bereitstellen von urheberrechtlich geschützten Werken zum interaktiven Aufruf gemeint. Das ist beispielsweise dann der Fall, wenn ein Webmaster ein Foto auf seiner Webseite öffentlich bereithält.

Das Recht der öffentlichen Zugänglichmachung steht dem Urheber sowie Personen zu, denen er dieses Recht eingeräumt hat. Einen Eingriff in sein Recht stellt es dar, wenn das urheberrechtlich geschützte Werk im Internet-Angebot des Verletzers ohne Zustimmung des Urhebers für die Öffentlichkeit bereitgehalten und damit zugänglich gemacht wurde.

Einziger Lichtblick derzeit: In einem aktuellen Beschluss entschied das LG Hamburg, dass gegen Urheberrechtsverletzungen durch die Bildersuche nicht mittels einstweiliger Verfügung vorgegangen werden kann. Bis zu einer höchstrichterlichen Klärung wäre es demnach unverhältnismäßig, Verbote, die das gesamte Geschäftsmodell der Bildersuche in Frage stellen, durch einstweilige Verfügungen zu erlassen (vgl. LG Hamburg, Urteil vom 21.10.2009, Az. 308 O 565/09).

Hinweis: //SEIBERT/MEDIA bietet keine Rechtsberatung an. Als Rechtsberatung von //SEIBERT/MEDIA ist auch dieser Artikel nicht zu verstehen. Wenn Sie Fragen haben oder Rechtsberatung in Anspruch nehmen möchten, wenden Sie sich bitte an die Anwaltskanzlei Karsten+Schubert.

Dr. iur. Stefanie Jehle gehört der Rechtsanwaltskanzlei Karsten+Schubert für Wirtschafts- und Unternehmensrecht aus Berlin an. Die Website erreichen Sie unter http://www.karstenundschubert.de. Ausführliche Informationen über die Autorinnen und weitere Fachartikel von Stefanie Jehle und Katja Schubert finden Sie in unserem Special Internet-Recht.

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

Am 13. Juni 2010 öffnet das Rheingau Palais seine Pforten: //SEIBERT/MEDIA lädt alle Mitarbeiter, Partner, Freunde und natürlich auch Kunden zum Sommerfest 2010 ein.

Das diesjährige Sommer-Einläuten steht (nicht ganz unerwartet) im Zeichen des größten Sportereignisses des Jahres, der Fußball-WM in Südafrika. Am Nachmittag dürfen auf dem Sportplatz in Schierstein zunächst die Hobbykicker von //SEIBERT/MEDIA und aus unserem Freundes- sowie Kundenkreis ran: Auf die Weltmeisterschaft stimmen wir uns dort ab 16:45 Uhr mit einem eigenen Fußballspiel ein, bei genügend Teilnehmern sogar mit einem kleinen Turnier. (Anschließend können die sanitären Anlagen am Sportplatz inkl. Duschen genutzt werden.)

//SEIBERT/MEDIA-Kicker in Aktion: Thorsten Brüggemann mit vorbildlicher Schusshaltung

Anschließend lassen wir die Profis zur Tat schreiten: Die WM ist dann schon seit zwei Tagen im Gange, doch erstmals tritt die deutsche Mannschaft auf den Plan und bestreitet um 20:30 ihr WM-Auftaktspiel gegen Australien. Nach unserer eigenen Turniereröffnung wollen wir uns die erste deutsche Glanztat nicht entgehen lassen und schauen uns das Spiel gemeinsam im großzügigen Aufenthaltsraum in unseren Räumlichkeiten im Rheingau Palais via Beamer an.

Für ein passendes Ambiente wird natürlich gesorgt sein: Ab ca. 19:30 können wir uns am Buffet stärken und mit kühlen Getränken auf die Partie einstimmen, kreative Köpfe mit Ideen für eine stilechte Deko haben wir reichlich. Aber natürlich müssen Fußball-Muffel nicht über ihren Schatten springen und finden sicher genügend Ecken, in denen WM-frei gefeiert und in Ruhe geplauscht werden kann.

Der Ablauf am 13. Juni:

Blick ins //SEIBERT/MEDIA-WM-Studio 2006

Nach dem Sommerfest ist mitten in der WM

Nach dem Sommerfest und der Eröffnungsparty ist aber längst nicht Schluss, denn unser Aufenthaltsraum wird dauerhaft zum //SEIBERT/MEDIA-WM-Studio 2010 umfunktioniert: Wir übertragen auch alle weiteren Spiele der deutschen Mannschaft per Beamer, als Nervennahrung stellen wir Snacks, Knabberzeug und Getränke bereit. Gemeinsam schaut sich’s nun mal am besten.

Das Team von Jogi Löw muss zwar ohne Kapitän Ballack auskommen, geht dafür aber mit einer Bayern-Achse fast wie weiland ‘74 in den Wettbewerb. Hoffen wir das beste! „Högschde Disziplin“ und reichlich Anwesenheit sind zu diesen Terminen gefordert:

• 13. Juni 20:30: Vorrundenspiel Deutschland vs. Australien
• 18. Juni 13:30: Vorrundenspiel Deutschland vs. Serbien
• 23. Juni 20:30: Vorrundenspiel Ghana vs. Deutschland
• 26. Juni 20:30 oder 27. Juni 16:00: Achtelfinale mit deutscher Beteiligung
• 2. Juli 20:30 oder 3. Juli 16:00: Viertelfinale mit deutscher Beteiligung
• 6. Juli 20:30 oder 7. Juli 20:30: Halbfinale mit deutscher Beteiligung
• 11. Juli 20:30: Finale mit deutscher Beteiligung
  

Andy Brehmes Elfmeterschuss ins Weltmeisterglück 1990

Gäste sind herzlich willkommen, ob beim Sommerfest am 13. Juni oder zu späteren WM-Spielen. Wir freuen uns auf den Einstieg in den Sommer, auf ein tolles Turnier und vor allem auf Sie und Euch!

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