Das Wiki nicht als Instrument zur Leistungsmessung missverstehen

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

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

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

Unbegründet: Angst vor Mitarbeiterüberwachung per Wiki

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

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

Eigene Inhalte kommunizieren und Unternehmenskultur positiv beeinflussen

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

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

Datenschutz sicherstellen

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

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

Verantwortung wahrnehmen: Wiki-Einführung als taktisches Mittel

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

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

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

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

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

Zusammenfassung

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

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

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

Weiterführende Informationen

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

1. Verstellen Sie sich nicht

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

2. Werden und bleiben Sie aktiv

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

3. Bieten Sie guten Inhalt an

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

4. Investieren Sie Ihre Zeit effizient

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

5. Konsistenz ist Trumpf

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

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

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

7. Netzwerken von Angesicht zu Angesicht

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

8. Danken Sie anderen

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

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

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

Weiterführende Informationen

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

Einheitliche Aufbereitung aller Dokumente ist unmöglich

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

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

Existenz von Inhalten ist wichtig, nicht Form

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

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

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

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

Weiterführende Informationen

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

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

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

Platz 10: Dinghyinsurance.com

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

Platz 9: Stexps.com

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

Platz 8: CWOL.com

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

Platz 7: 5safepoints.com

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

Platz 6: Videosoniclab.com

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

Platz 5: Webking.com

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

Platz 4: Lingscars.com

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

Platz 3: Yvettesbridalformal.com

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

Platz 2: Arngren.net

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

Platz 1: Havenworks.com

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

Kennen Sie weitere Beispiele?

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

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

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

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

Platz 11: Technik mit Nerv-Potenzial

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

Platz 10: Blockhütten und bloggende Friseure

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

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

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

Platz 8: Alles im … Eimer

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

Platz 7: Weg hier!

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

Platz 6: Wer wird denn gleich ungalant werden?

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

Platz 5: Wein statt Wasser

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

Platz 4: Wenn selbstkritisch, dann aber richtig!

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

Platz 3: Gelächter beim Schlächter

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

Platz 2: Sittenstrolche in die Therapie!

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

Platz 1: Das Land hinter dem Regenbogen …

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

Kennen Sie weitere kuriose Beispiele?

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

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

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

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

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

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

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

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

Vorteile von E-Mails

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

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

Vorteile eines Aufgaben-Management-Systems

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

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

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

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

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

Eine bestimmungsgemäße Technologieanwendung bringt Unternehmen voran

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

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

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

Weiterführende Informationen

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

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

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

Effizienzgewinn durch die Nutzung eines zentralen Systems

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

Das ist jedoch falsch. Ein ums andere Mal sehe ich bestätigt, dass die sach- und bestimmungsgerechte Anwendung von Technologie in aller Regel zu einem Effizienzgewinn führt. Software-Systeme für den Einsatz im Unternehmen sind heute so ausgereift, dass selbst Mitarbeiter ohne Technologie-Know-how mit ihnen produktiv und sinnvoll arbeiten können – das gilt natürlich auch für professionelle Enterprise-Wiki-Lösungen wie Confluence und Foswiki.

Ein Firmenwiki ist in diesem Zusammenhang die optimale Lösung: Die Vorteile, kein Referenzwissen per E-Mail zu verschicken, sondern Know-how in einem zentralen, digitalen, Web-basierten System zu speichern und für alle verfügbar zu machen, überwiegen die möglicherweise noch verbliebenen Nachteile deutlich.

Im erstrebenswerten Optimalfall ist eine E-Mail eine Nachricht, die sich mit dem Lesen durch den Empfänger erledigt hat.

Organische Inhalte statt „toter“ Anhänge

Deshalb plädiere ich dafür, Datei-Anhänge in einem zentralen System zu speichern, das allen Empfängern zugänglich ist; eine E-Mail sollte lediglich den Verweis auf das entsprechende Dokument beinhalten. Dafür gibt es überzeugende Argumente, die deutlich werden, wenn man diesen Prozess an einem konkreten Beispiel durchexerziert.

Verschicke ich beispielsweise einen Bericht per E-Mail an mehrere Empfänger, ist dieser Bericht ein „totes“ Dokument: Es verändert sich nicht, es kann nicht kommentiert werden, Leser können nicht mit ihm interagieren, es entwickelt sich nicht weiter und es ist nicht zentral verfügbar.

Bilde ich diesen Bericht in einem Wiki-System ab, „leben“ die Inhalte: Die Adressaten können das Dokument sinnvoll modifizieren und ggf. selbst Fehler beheben oder Unklarheiten ansprechen, Aufstellungen sind um aktuelle Daten erweiterbar, über die Kommentarfunktion können die Daten gemeinsam mit anderen Empfängern interpretiert und diskutiert werden – der Bericht wird besser, ohne dass eine einzige weitere E-Mail auszutauschen ist.

Auf diese Weise durchläuft das Dokument im Wiki mehrere Iterationen und werden Inhalte organisch weiterentwickelt und interpretiert, wobei der ursprüngliche Sender stets die Kontrolle über die Inhalte behält: Er kann das Topic z.B. via RSS abonnieren und wird über jede Modifikation benachrichtigt, über die Revisionskontrolle ist jede Änderung lückenlos nachvollziehbar.

Der Geschäftsführer oder der Abteilungsleiter, der sich das Dokument schließlich ansieht, findet einen ganz anderen, einen wesentlich hochwertigeren Bericht vor, als er per E-Mail erhalten hätte, während gleichzeitig das E-Mail-Aufkommen deutlich reduziert worden ist und dieses Wissen auch später jederzeit zur Verfügung steht.

Darüber hinaus löst sich das immer wieder auftretende Problem, etwa zunächst einen falschen Anhang zu versenden, in Luft auf: Der Initiator des Wiki-Dokuments kann in diesem jederzeit Korrekturen vornehmen, die Empfänger haben sofort Zugriff auf das korrekte Dokument. Streng vertrauliche Informationen liegen zudem nicht in individuellen Postfächern, sondern in einem zentralen, sicheren System. Das Dokument hinter dem Link kann natürlich nur aufrufen, wer dazu legitimiert ist.

Die Kommunikation über das Wiki und der Verzicht auf Dateianhänge in E-Mails wirken sich also auf mehreren Ebenen positiv aus:

• produktiverer Umgang mit den Informationen aus dem Dateianhang
• organische und interaktive Inhalte statt „toter“ Dateien
• verstärkte Sicherheit durch Zugriffsbeschränkung
• zentrale Dokumentation des Unternehmenswissens
• bessere Zusammenarbeit und Kollaboration, aktives Teilen

Intern keine Anhänge, in der Kundenkommunikation geht es selten anders

Beim Versand von Dateianhängen per E-Mail spielt immer die Sender-Empfänger-Struktur eine Rolle, weshalb hier Einschränkungen nötig sind. Für E-Mails unter Kollegen sollte die Regel, keine Anhänge zu verschicken, meiner Überzeugung nach immer gelten. Auch bei E-Mails an einen Kunden, mit dem man bereits im Projekt zusammenarbeitet, ist eine zentrale die optimale Lösung: In einem modernen Unternehmen sollte es ein System geben, in dem Informationen gemeinsam mit dem Kunden gesammelt und ausgetauscht werden können. Ein Extranet auf Wiki-Basis bildet dafür eine ausgezeichnete Plattform, deren Rechtestruktur es ermöglicht, den Zugriff auf das Projekt-Team und die Mitarbeiter beim Kunden zu beschränken.

Eine andere Frage ist die nach der Kommunikation mit Interessenten, zu denen noch keine Geschäftsbeziehung besteht. Eine pragmatische Möglichkeit, diese Empfänger wie beschrieben zu integrieren, besteht leider noch nicht. Kann bzw. darf man voraussetzen, dass der kaum bekannte Empfänger in einem Wiki-System kollaborieren kann bzw. überhaupt möchte? Sicherlich nicht. In Fällen wie diesen ist der Versand von Dokumenten per Anhang trotz einiger Bedenken die besser gangbare Lösung.

Ein weiteres Problem: Nicht alle Menschen sind immer und überall online. So ist es möglich, dass der Empfänger den Wiki-Link öffnen und die Informationen gerne abrufen möchte, es aber einfach nicht kann, weil er unterwegs keinen Internet-Zugang hat oder weil er seine E-Mails z.B. per Mobiltelefon abruft o.ä.

Der Absender muss also immer eigenverantwortlich entscheiden, in welcher Form er Dokumente kommuniziert. Die Probleme, die durch die E-Mail-Flut und durch die damit verbundene Ineffizienz entstehen, wiegen allerdings weitaus schwerer als die Frage, ob der Empfänger einen Link öffnen kann oder doch besser ein E-Mail-Anhang versendet werden sollte. Die allermeisten Mitarbeiter sind problemlos in der Lage, diese Entscheidung zu treffen.

Ich möchte also nicht einseitig argumentieren: In sehr vielen Fällen ist die Ablage von Dokumenten im Wiki zwar der empfehlenswerte und effizientere Weg, es gibt aber durchaus Szenarien, in denen es nach wie vor sinnvoller ist, Dateien per E-Mail zu versenden. Generell gilt:

Wir sind noch nicht soweit, ausschließlich von Schwarz und Weiß reden zu können. Allerdings sind wir auch längst über das Stadium hinaus, in dem es nur um Nuancen an zusätzlicher Produktivität geht.

Weiterführende Informationen

E-Mail-Missbrauch 3: Aufgaben gehören nicht in E-Mails
Kundenservice und Transparenz: Das Kunden-Extranet von //SEIBERT/MEDIA (Vodcast)
Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wikis sind der Kitt, der Intranets zusammenhält

Die E-Mail: Segen für Unternehmen

Die E-Mail hat die (geschäftliche) Kommunikation so stark verändert wie keine zweite Kommunikationsform in den letzten Jahrzehnten. Es ist völlig unbestritten, dass wir ihr eine dramatische Modernisierung und Beschleunigung, eine schnellere und unkompliziertere Kommunikation als je zuvor verdanken.

Versuchen wir kurz, uns vorzustellen, wie wir ohne E-Mails kommunizieren würden:

• Wir würden den Großteil des Tages telefonieren.
• Wir würden stundenlang mit persönlichen Gesprächen und in Meetings verbringen.
• Wir würden täglich Dutzende oder Hunderte Faxe lesen und schreiben.
• Dokumente würden sich in Briefumschlägen in der Ablage stapeln, die klassische Portokasse wäre ein Muss.

Natürlich telefonieren viele Menschen notgedrungen auch heute noch häufig geschäftlich und verbringen reichlich Zeit in Meetings. Doch um das Kommunikationspensum, das wir heute dank der E-Mail täglich leisten, mithilfe von Telefon, persönlichen Gesprächen, Fax und Briefen abzubilden, würde auch ein sehr langer Arbeitstag ganz sicher nicht ausreichen, von produktiver Arbeit ganz zu schweigen. (Es wäre vielleicht einen separaten und wohl ziemlich umfangreichen Artikel wert, um eine solche Situation einmal intensiver zu durchdenken.)

Die falsche Anwendung von E-Mails: Fluch für Unternehmen

Wir haben also zum Glück die E-Mail. Alles ist gut? Ganz und gar nicht, denn:

Der Siegeszug der E-Mail ist viel zu weit gegangen.

Wir sehen uns nämlich einer offenkundigen Diskrepanz gegenüber: Die E-Mail wird missbraucht, es wird versucht, Dinge mit ihr abzubilden, die auf andere Art und Weise (und mit anderen Technologien) viel besser und sinnvoller abgebildet werden können. Die Frage lautet also: Wofür ist die E-Mail gemacht und wofür wird sie genutzt?

Die Grundfunktion einer E-Mail besteht darin, Textinformationen zu versenden. Das funktioniert prima. E-Mails können Dateien hinzugefügt werden. Auch das ist mitunter sinnvoll – der Rechner des Empfängers muss diese natürlich verarbeiten können.

Doch schon die HTML-E-Mail ist meiner Auffassung nach eine Form des „Missbrauchs“: Nicht jeder Anwender kann sie problemlos ansehen, die HTML-Darstellung ist kein unmittelbarer Dienst eines Mail-Programms, zusätzlich sind Browser-Komponenten erforderlich. Dies aber nur am Rande – das HMTL-Format ist in erster Linie unter Marketing- und auch Usability-Aspekten zu betrachten. An dieser Stelle soll indes die Produktivität von Mitarbeitern im Mittelpunkt stehen.

Meiner Erfahrung nach gibt es zwei entscheidende Formen des E-Mail-Missbrauchs in der Unternehmenskommunikation, die sich auf mehreren Ebenen negativ auswirken, nämlich auf die Produktivität (auf die Qualität von Dokumenten und Arbeitsergebnissen) und auf die Transparenz im Unternehmen. Hier meine ich den Versand von statischem Wissen in E-Mails mit Anhängen und das Versenden von Aufgaben.

Diese Thesen werde ich in zwei Artikeln, die sich diesem Beitrag anschließen, ausführlich begründen. Zunächst aber zu den Auswirkungen des E-Mail-Missbrauchs, für den es ein untrügliches Indiz gibt: Manager, Bereichsleiter, Projektmanager und viele Mitarbeiter in großen und auch in kleinen Unternehmen ertrinken förmlich in E-Mails!

Die E-Mail-Flut und die Produktivität

Ich möchte das an einem Bild verdeutlichen: Stellen wir uns jemanden vor, der vor einem großen Berg Münzen sitzt und die Aufgabe hat, diese zu sortieren – abzuarbeiten also. Jede Münze muss er in die Hand nehmen, auf ihren Wert prüfen und in einer bestimmten Schale ablegen. Es wird dem Mitarbeiter indes nicht leicht gemacht, denn klimpernd fallen aus einem stets aufgedrehten Hahn immer wieder weitere Münzen auf dem Tisch.

Mit konzentrierter und konsequenter Arbeit gelingt es ihm, alle Münzen zu sortieren und dabei schneller zu sein als der nachfließende Münzstrom, er lehnt sich zufrieden zurück, der Tisch ist leer – für 30 Sekunden. Dann klimpert aus dem Hahn eine neue Münze, gleich darauf eine zweite und eine dritte. Innerhalb von Minuten hat sich wieder ein respektables Häuflein angesammelt, das schnell größer wird; die Freude ist verflogen, die Arbeit beginnt von vorn.

Gewiss: Bestünde ausschließlich darin das Tagwerk dieser Person, wäre das nicht weiter bemerkenswert. Auch die Müllbehälter im Wohngebiet sind stets aufs Neue randvoll, wenn das Trio von der Müllabfuhr das nächste Mal seine Runde dreht; auch der Busfahrer fährt seine Stammstrecke jeden Tag wieder ab; auch der Fußball-Weltmeister muss sich nach dem Triumph erneut durch die Qualifikation kämpfen, um beim nächsten Turnier dabei zu sein.

Was aber, wenn das Sortieren nur eine von vielen Aufgaben wäre, die zu erledigen sind, wenn das Sortieren nicht einmal die wichtigste Aufgabe ist? Wann widmet er sich den anderen Tätigkeiten?

Damit sind wir bei der Bearbeitung von E-Mails. Viele Leser dürften das Gefühl kennen, wenn nach einem „Kraftakt“ endlich einmal keine ungelesenen E-Mails mehr im Posteingang liegen: Ein Gefühl der Zufriedenheit stellt sich ein, während in diesem Moment zwei neue E-Mails eingehen. Bearbeitet man auch diese noch rasch, um den Posteingang „sauber“ zu halten? Bearbeitet man auch die vier weiteren E-Mails, die angekommen sind, während man eine etwas umfangreichere Antwort verfasst hat? Aber wann will man produktiv sein und die Aufgaben angehen, die vielleicht soeben aus den E-Mails extrahiert wurden?

Ich habe schon einmal das Szenario beschrieben, dass, wer wollte oder wer nicht aufpasst, den ganzen Tag damit zubringen könnte, E-Mails zu bearbeiten – der Nachschub ist ungebrochen. Ein entscheidendes Problem ist also, dass man angesichts der E-Mail-Flut mitunter nicht mehr in der Lage ist, die Arbeitszeit sinnvoll und produktiv zu nutzen, die sich aus den E-Mails ergebenden Aufgaben zu extrahieren, zu priorisieren und vor allem zu erledigen. (Ich habe Manager kennengelernt, die offen zugeben, E-Mail überhaupt nicht zu bearbeiten, weil sie sonst nichts anderes tun würden.)

Aus dem Missbrauch der E-Mail resultiert eine E-Mail-Flut, die die Produktivität jedes „Betroffenen“ reduziert und die den Nutzen deutlich einschränkt, den das Unternehmen aus der Leistung des (durch das immense E-Mail-Aufkommen zudem unzufriedeneren) Mitarbeiters ziehen möchte. In den folgenden Beiträgen Der E-Mail-Anhang ist oft die falsche Anwendung von Technologie und Aufgaben gehören nicht in E-Mails gehe ich darauf ein, wie sich dieses Problem meiner Meinung besser in den Griff bekommen lässt und wie sich mehrere Fliegen mit einer Klappe schlagen lassen.

Weiterführende Informationen

Nicht relevante E-Mails sind böse
Rezepte gegen die E-Mail-Flut: E-Mails effizient beantworten
Die E-Mail-Flut bringt Geschäftsleute um

Abb.: Der //SEIBERT/MEDIA-Artikel über Google Wave auf TechCrunch.com

Ein Posting im größten Tech-Blog der Welt zu einem der heißesten Themen des Jahres bilden eine vielversprechende Kombination und wir waren gespannt, was dabei herauskommen würde, zumal in den Beitrag eine Menge Arbeit investiert worden ist. Grund genug also, sich einmal genauer mit den Auswirkungen eines eigenen Artikels in einem der wichtigsten Weblogs zu befassen und ein paar Daten zu sammeln.

Fast meistbeachteter TechCrunch-Artikel im November 2009

Tatsächlich sprechen schon die mehr als 250 Kommentare zum Beitrag eine deutliche Sprache: Der Artikel hat große Aufmerksamkeit erhalten und ist sehr rege und kontrovers diskutiert worden, wobei sich Feedback von eingefleischten Google-Hassern und Diskussionsbeiträge von Leuten, die sich ernsthaft und aus einer neutralen Perspektive mit der Idee und der Anwendung auseinandersetzen, in etwa die Waage gehalten haben.

„Why Google Wave Sucks …“ einer der der erfolgreichsten TechCrunch-Beiträge im November 2009 und einer der meistbeachteten TechCrunch-Artikel überhaupt. Selbst wer recht gründlich sucht, findet nur eine Handvoll Beiträge, die auf ein ähnlich großes oder auf größeres Interesse gestoßen sind und die mehr Feedback generiert haben. Einige Zahlen im Überblick:

• mehr als 250 Kommentare im Artikel selbst
• mehr als 325 Sharings via Facebook
• Tausende Videozugriffe auf den eingebundenen YouTube-Film (bisher über 16.000)
• neue Abonnenten des //SEIBERT/MEDIA-YouTube-Channels
• Tausende Zugriffe auf die eingebundenen Flickr-Bilder (bisher über 4.200)
• mehr als 2.250 Retweets

Hochwertige Kontakte

Unter den Retweetern befinden sich einige wirklich profilierte Leute aus dem Tech-Umfeld sowie amerikanische und deutsche Größen der Blogosphäre. Besonders habe ich mich über den persönlichen Kontakt zu Robert Scoble gefreut, dem bekannten Blogger, Autoren und früheren Technologie-Botschafter in Diensten von Microsoft, der u. a. in einem eigenen Blog-Beitrag auf den TechCrunch-Artikel eingegangen ist. Weitere interessante Kontakte haben sich via XING und LinkedIn ergeben.

Große Resonanz im Twitter-Umfeld

Besonders interessante Auswirkungen zeigt „Why Google Wave Sucks …“ im Twitter-Umfeld: Immerhin hat es der Beitrag auf einen Platz in den Top-1000 der Tweet-basierten Suchmaschine Topsy gebracht (wobei ich mich frage, wie viel an einer Top-100-Platzierung gefehlt hat). Über die Retweets hinaus ist viel anerkennende Erwähnung (auch in Form einiger Direct Messages) über Twitter eingegangen, zudem erfreut sich auch mein eigener Twitter-Account eines deutlich gestiegenen Interesses, wie diese kleine Auswertung zeigt:

• Tag der Veröffentlichung: +77 Follower
• 2. Tag: +67 Follower
• 3. Tag: +21 Follower
• 4. Tag: +15 Follower
• 5. Tag: +14 Follower
• 6. Tag: +14 Follower
• 7. Tag: +28 Follower
• 8. Tag: +67 Follower

Nicht zuletzt hat mich erfreulich viel positives persönliches Feedback erreicht: Beispielsweise haben //SEIBERT/MEDIA-Mitarbeiter den Artikel in unserem internen Micro-Blog rege diskutiert und haben mich mehrere TechCrunch-Leser auch direkt per E-Mail angesprochen.

Hat sich der Aufwand nun gelohnt?

Die Entwicklung eines solchen Beitrags ist mit einem nicht unerheblichen Aufwand verbunden: Neben der gemeinsamen Sammlung von Argumenten in einer Wave habe ich ein ganzes Wochenende in die Erstellung des Artikels investiert, die anschließende Qualitätssicherung hat weitere Ressourcen gekostet.

Aber ja, der Aufwand hat sich gelohnt. Für //SEIBERT/MEDIA ist Twitter längst ein ernstzunehmendes Marketing-Instrument und bislang mehr als 300 neue Follower sind wirklich ein ausgezeichnetes Ergebnis; von der weiteren Aufmerksamkeit im Twitter-Umfeld ganz abgesehen. Auch die vielen neuen, hochkarätigen Kontakte sind Gold wert und werden sich auszahlen. Ich freue mich auf weitere //SEIBERT/MEDIA-Artikel auf TechCrunch.com

Weiterführende Informationen

Unsere spezielle Seite zum Thema Google-Wave-Beratung
Blog-Artikel im Corporate Weblog: Von der Ideenfindung zur Veröffentlichung
Google Wave: Ein Ausblick auf eine neue Stufe der Unternehmenskommunikation

Der Kunde

Die BodeHewitt AG bietet ihren nationalen und internationalen Mandanten Dienstleistungen in den Bereichen betriebliche Altersversorgung, Investment Consulting, Pension Administration sowie Human Resources aus einer Hand von der Strategieentwicklung über die Konzeption bis zur Administration. Das Unternehmen blickt auf jahrzehntelange Erfahrung zurück und stellt seinen Kunden über die Anbindung an das internationale Netzwerk von Hewitt Associates globale Kompetenz und lokale Experten in 35 Ländern in aller Welt zur Verfügung.

Die Anforderung: Sicherheit, Erreichbarkeit und Nutzungskomfort

//SEIBERT/MEDIA hat für BodeHewitt eine Plattform zum sicheren Datenaustausch erstellt, mit der der Datenaustausch zwischen dem Unternehmen und seinen Kunden im Internet sicher und komfortabel abgewickelt werden kann. Diese Plattform ist im Internet erreichbar, externen Zugang haben jedoch ausschließlich Kunden von BodeHewitt.

Abb. 1: Das Kundenportal

Zur Anwendung gehören separate Bereiche für Nutzer auf Kundenseite, Mitarbeiter von BodeHewitt und Administratoren, die Firmen und Benutzer verwalten. Der Hauptzweck des Portals besteht darin, dass Mitarbeiter den ihnen zugeordneten Unternehmenskunden Dateien zum sicheren Herunterladen anbieten können. Dieser Dateitransfer ist auch in die andere Richtung möglich.

Abb. 2: Die Dateiübersicht

Da die Cross-Browser-kompatible Anwendung webbasiert ist und komplett im Browser arbeitet, entsteht für den Kunden kein Mehraufwand bspw. durch eine lokale Installation. Dennoch muss er nicht auf Features wie das gleichzeitige Hochladen mehrerer Dateien (inkl. animierter Fortschrittsanzeige) verzichten. Um möglichst alle Kunden erreichen zu können, wird kein Flash verwendet, die Grundfunktionalitäten sind auch ohne Javascript verfügbar.

Stabilität und Agilität durch moderne Java-Technologien

Bei der Entwicklung der Anwendung hat //SEIBERT/MEDIA auf moderne Java-Technologien gesetzt. Im Frontend verwendet das System die auf der Java VM laufende Skriptsprache Groovy mit dem Web-Framework Grails. Grails bietet die Möglichkeit, Änderungen komfortabel und schnell umzusetzen und verfügt unter anderem über ein umfangreiches Template-System, mit vielen Wurzeln in Spring. (Spring ist das für Java entwickelte Framework, auf dem Grails basiert.)

Die Geschäftslogik im Hintergrund ist jedoch in Java programmiert: Diese Sprache ist etwas restriktiver und setzt weniger auf Komfort als vielmehr auf Stabilität. Der kombinierte Einsatz von Groovy/Grails und Java hat somit einen stabilen Anwendungskern geliefert, der vom agilen Frontend-Teil der Anwendung verwendet wird. Hier kommt das gute Zusammenspiel zwischen Java und Groovy eindrucksvoll zur Geltung.

Die Applikation ist dank der Verwendung des HTTPS-Protokolls durch aktuelle SSL-Verschlüsselungen abgesichert und mit einem Zertifikat eines namhaften Anbieters versehen. Zudem gibt es strenge Anforderungen an die Passwörter, darunter Mindestlänge, Zeichenvorgaben, Gültigkeitsdauer und Historie (so müssen sich die letzten Passwörter unterscheiden, was prinzipiell bei jeder aktuellen Anwendung, über die sensible Daten ausgetauscht werden, Standard sein sollte).

Das Design des Portals orientiert sich an den Vorgaben der bestehenden Corporate Identity von BodeHewitt. Das Portal ist durchgehend mehrsprachig und derzeit auf Deutsch und Englisch verfügbar.

//SEIBERT/MEDIA: Full-Service-Dienstleistungen aus einer Hand

//SEIBERT/MEDIA realisiert Full-Service-Projekte und vereint konzeptionelles und Design-Know-how, Technologiewissen und IT-Expertise unter einem Dach. Unsere Kunden profitieren von kurzen Wegen, enger Kommunikation und eingespielten Teams, so vermeiden wir Konflikte und ineffizient hohe Abstimmungsaufwände. Wir verbinden technologische Kompetenz mit langjähriger Erfahrung in der Umsetzung ganzheitlicher Projekte und sind in der Lage, attraktive Gesamtpakete anzubieten, die Mehrwert schaffen.

Benötigen Sie Unterstützung bei der Web- und Anwendungsentwicklung? Planen Sie ein Web-Projekt oder suchen Sie zusätzliche technologische Expertise bei einem laufenden Vorhaben? Auf unseren speziellen Seiten zu den Themen Web-Development mit Grails und Perl-Programmierung finden Sie ausführliche Informationen und direkte Kontaktmöglichkeiten.

Weiterführende Informationen

Grails: Kurze Entwicklungszeiten und nahtlose Java-Integration (Vodcast)
Die Programmiersprache Groovy
Die Website von //SEIBERT/MEDIA/TECHNOLOGIES

URL-Shortener: von tr.im zu bit.ly

Kurz-URL-Dienste sind aus dem Tagesgeschäft bei //SEIBERT/MEDIA nicht mehr wegzudenken. Aus der URL http://blog.seibert-media.net/2009/10/28/social-software-projekte-woran-die-einfuehrung-von-enterprise-20-tools-scheitern-kann-teil-1 mit ihren 133 Zeichen wird der handliche Link blog.seibert-m….

Die Erstellung dauert wenige Sekunden, Short-URLs werden in E-Mails, in Blog-Artikeln, in Twitter- und Facebook-Postings, in Beiträgen im internen Micro-Blog, in Präsentationen und selbst in Print-Publikationen wie unseren Marketing-Broschüren verwendet. Für die interne wie auch die Kundenkommunikation haben die Mitarbeiter im Consulting-Bereich von //SEIBERT/MEDIA zumeist den Dienst tr.im genutzt, der durch seine konkurrenzlos kurzen URLs und seine einfache Handhabung besticht.

Eine Nachricht hat unsere eifrigen tr.im-User jedoch im Sommer 2009 mit Sorge erfüllt: tr.im gibt auf, hieß es. Was würde das bedeuten? Sämtliche Short-URLs, die mit diesem Dienst generiert worden sind, würden von einem Tag auf den anderen ins Leere führen. Höchste Zeit, sich nach zukunftsfähigen Alternativen umzusehen.

Da kürzlich Twitter tinyurl.com durch bit.ly als URL-Shortener ersetzt hat, bietet sich dieser Dienst an: Die URLs sind einen Hauch länger als die mit tr.im erstellten, aber die Twitter-Integration und auch das praktikable Handling sind überzeugende Argumente. Also sollte fortan möglichst bit.ly genutzt werden, nicht zuletzt, um eine möglichst homogene Kommunikation nach innen wie nach außen sicherzustellen.

Das Problem mit bit.ly: zwei Buchstaben

Doch halt – .ly? Diese Domain-Endung steht für Libyen – und wir damit vor einem kleinen Problem. Wenn wir einen Moment darüber nachdenken, drängen sich nämlich Fragen auf: Kann man guten Gewissens die Nutzung eines Dienstes vertreten, von dem Libyen – in welcher Form auch immer – profitiert? Konkret: Ist dies mit unseren moralischen Vorstellungen vereinbar?

Weltpolitisch macht Libyen in den letzten Monaten seinem zweifelhaften Ruf als unberechenbarer Partner einmal mehr alle Ehre. Leidtragende ist derzeit die Schweiz, die sich einer grotesken Kampagne gegenübersieht, die inzwischen in eine handfeste diplomatische Krise ausgeufert ist. (Auslöser des Konflikts war die vorübergehende Festnahme des Gaddafi-Sohns Hannibal wegen einer Prügelei in einem Genfer Hotel.)

Noch ernstzunehmender und tragischer ist die innenpolitische Lage in Libyen: Die Verfolgung politisch Engagierter ist, wie Amnesty International feststellt, an der Tagesordnung, immer wieder wird einerseits von Schauprozessen gegen Oppositionelle und andererseits von langjährigen Inhaftierungen ganz ohne Anklage berichtet, in Gefängnissen wird gefoltert, für vergleichsweise geringfügige Delikte drohen archaische körperliche Strafen, die Bevölkerung ächzt unter dem Sicherheitsapparat mit seinem Netzwerk aus Spitzeln. Die Menschenrechtssituation in Libyen ist offensichtlich also nach wie vor sehr problematisch. (Weitere ausführliche Informationen stehen auf der Website von Amnesty International zur Verfügung.)

Libysche URLs salonfähig machen: moralisch vertretbar?

Nun ist bit.ly natürlich kein libyscher Dienst, und es geht auch nicht darum, dass Libyen sich eine goldene Nase verdienen würde: Das ist höchstwahrscheinlich nicht der Fall, denn es handelt sich ja lediglich um eine Domain, die in Libyen 75 US-Dollar kostet. Und gewiss eignet sich die Endung -ly ganz wunderbar für „sprechende“ URLs wie short.ly, simp.ly oder eben bit.ly.

Vielmehr steht das Problem im Raum, dass durch die millionenfache Nutzung libysche URLs „salonfähig“ gemacht werden. Ist das moralisch vertretbar? Kann man das zweifelhafte außenpolitische Gebaren und die vielen menschenrechtlich bedenklichen Vorfälle einfach missachten, nur um eine kurze URL zu erhalten? Sollte man diese Endungen nicht besser boykottieren, anstatt sie millionenfach zu publizieren?

Wie erwähnt hat gerade Twitter tinyurl.com durch bit.ly als Short-URL-Dienst ersetzt. Ist das unter moralischen Gesichtspunkten haltbar? Schließlich gibt es viele andere Anbieter, die ähnliches leisten. Wieso also ausgerechnet Libyen?

Neben den moralischen Bedenken besteht zudem eine Gefahr ganz praktischer Natur: Libyen hat nach wie vor die Hoheit über die Domain. Wenn Libyen es (aus welchem Grund auch immer) möchte, kann es dem Anbieter die URL bit.ly morgen wieder wegnehmen. Millionen toter Links wären die Folge. Wie ernstzunehmen ist diese Gefahr?

Aus zwei unscheinbaren Buchstaben ergeben sich also viele Fragen. Denken wir noch einen Schritt weiter: An welchem Punkt würden wir denn „Halt!“ sagen? Würden wir hypothetische Dienste namens ea.sy, one.mm oder fa.ir nutzen, um Links zu verkürzen? (Diese Domain-Endungen stehen für Syrien, Myanmar, das ehemalige Birma, und den Iran, drei waschechte „Schurkenstaaten“, wenn man so will.)

Kann man sich im Tagesgeschäft moralische Bedenken leisten?

Natürlich kann dieses Thema nicht ausführlich besprochen werden, ohne Gegenfragen zu stellen: Nimmt man im grenzenlosen Web auf Aspekte wie die eben beschriebenen keine Rücksicht? Ist es im Tagesgeschäft nicht unsere Aufgabe, Bewertungen auf politischer Ebene vorzunehmen? Ja, kämen wir, selbst wenn wir wollten, überhaupt um bit.ly herum, wenn alle Welt es nutzt?

Oder resultieren diese Bedenken womöglich aus einer übertriebenen politischen Korrektheit? Denn andererseits hat Libyen am 15. September 2009 turnusmäßig den Vorsitz der UNO-Generalversammlung für ein Jahr übernommen. In der Staatengemeinschaft nimmt der Gaddafi-Staat einen festen Platz ein und genießt offenbar zwar wenig Vertrauen, aber doch weitgehend uneingeschränkte Anerkennung.

Freunde von tr.im sind aus dieser Zwickmühle indes durch die Nachricht befreit worden, dass der Dienst von einer Community weitergeführt und auch über 2010 hinaus existieren wird, und das sogar als Open-Source-Anwendung. Und wer bit.ly als Domain doof findet, kann alle bit.ly-Links auch in j.mp-Links umwandeln. Diese deutlich kürzere Domain besitzt bit.ly auch. Doch die Fragen bleiben:

Zählen im grenzenlosen Web und insbesondere im Tagegeschäft allein praktische Erwägungen? Oder darf (bzw. muss?) man sich Überlegungen auch auf einer anderen Ebene leisten?

Wie sehen Sie das? Vielleicht gibt es noch weitere Aspekte, die hier berücksichtigt werden sollten? Bitte nutzen Sie gerne das Kommentarfeld unten für Ihre Anmerkungen.

Weiterführende Informationen

Kurz-URL-Dienste: nützlich und riskant
Warum nur? bit.ly erhält Zuspruch von Google und Co., formiert Allianz mit Yfrog
So funktioniert bit.ly: URLs kürzen, Klickstatistiken inklusive

In diesem Artikel sollen einige wichtige und wertvolle Zusatzleistungen vorgestellt werden, die gerade auf diese Aspekte abzielen und die //SEIBERT/MEDIA im Rahmen eines ganzheitlichen Wiki-Projekts oder auch unterstützend erbringen kann.

1. Analyse und Bericht über die Wiki-Akzeptanz (Wiki-Gardening, Wiki-Championship)

Die meisten Firmenwikis werden nicht intensiv genug genutzt. Es bleibt immer ein drängender Wunsch der Verantwortlichen, dass Nutzung und Akzeptanz des Wikis weiter steigen mögen. Und dies ist vollkommen unabhängig von der aktuellen Nutzungsintensität: Mehr geht immer und mehr ist auch immer besser, weil sich der Nutzen des Wikis mit steigender Beteiligung der Mitarbeiter auch dramatisch steigert. Daher sollten Sie darauf achten, dass alle funktionellen, organisatorischen und inhaltlichen Möglichkeiten des Wikis ausgenutzt werden.

Wir erstellen einmal pro Monat einen ausführlichen Bericht und machen eine Bestandsaufnahme. Sie erhalten einen Überblick darüber, was gut, schlecht oder gar nicht läuft. Wir zeigen Ihnen auf, wie Sie die Situation verändern können und was zu tun ist. Und häufig brauchen Sie für die Umsetzung nicht einmal weitere Unterstützung. Die „Sichtbarkeit“ der Verbesserung erhöht den Nutzen und Wert dieser Dienstleistung. Voraussetzung für diese Leistung: Wir benötigen einen Zugriff auf Ihre Wiki-Instanz aus unserem Büro.

2. Betreuungskontingent für Beratung zu Plugins und Konfiguration auf Abruf

Täglich wird an Ihrem Wiki gearbeitet. Je mehr Zeit Ihre Mitarbeiter mit dem Wiki verbringen, desto mehr Fragen entstehen. Je intensiver die Nutzung wird, desto höher wird auch der Support-Aufwand. Sie sollten dabei auf den professionellen Support eines erfahrenen Wiki-Spezialisten wie //SEIBERT/MEDIA zurückgreifen. Bei uns beauftragte Kontingente werden in der Menge rabattiert. Trotzdem verfallen sie nie und werden auch nur bei Abruf abgerechnet. Sie sind also flexibel und bestimmen ganz allein und risikolos, ob und in welchem Umfang Sie Support benötigen bzw. in Anspruch nehmen. (Zu Beginn empfehlen wir in der Regel zwei Stunden pro Monat.)

3. Workshop für Plugins und Wiki-Formulare

In professionellen Enterprise-Wiki-Systemen wie Confluence und Foswiki steckt viel mehr, als auf den ersten Blick ersichtlich ist. Warum sollten Sie warten, bis zufällig mal ein Mitarbeiter über eine neue Funktion stolpert und Sie damit überrascht? Warum sollten Sie warten, bis Sie eine bestimmte Funktion dringend benötigen und erst dann nach umfangreichen Recherchen und über Umwege herausfinden, dass der bessere Weg ganz einfach und schnell gewesen wäre? Mit der Unterstützung von //SEIBERT/MDIA nutzen Sie von Beginn an den vollen Funktionsumfang von Foswiki oder Confluence mit allen wichtigen Plugins.

In einem intensiven Workshop zeigen wir Ihnen alle relevanten Plugins, führen Sie in die Anwendung und Konfiguration ein und gehen mit Ihnen vor allem einige Beispiele für Wiki-Formulare durch. Mithilfe dieser Formulare können Sie auch mit geringen Kenntnissen webbasierte Lösungen erarbeiten, wie sie sonst häufig mit Microsoft Access oder mit Datenbanken etabliert werden. Sie eignen sich ausgezeichnet für die Verwaltung und Organisation von Anfragen, Vorfällen und Anwendungsbeispielen in vielen verschiedenen Bereichen.

4. Nutzungsbeispiele und Vorlagen für Mitarbeiter erstellen

Häufig wissen Mitarbeiter nicht so genau, was sie mit dem Wiki anfangen sollen, weil es vor allem an Beispielen und Vorlagen für sinnvolle Anwendungsfälle mangelt. //SEIBERT/MEDIA verfügt über einen Satz an Vorlagen, den wir Ihnen gerne zur Verfügung stellen, darunter Projektübersichten, Meeting-Protokolle, Aufgabenlisten, Organisationstabellen, Abwesenheitsübersichten, Richtlinien und andere nützliche Dokumente. Diese helfen Ihren Mitarbeitern dabei, besser zu verstehen, wie mit dem Wiki gearbeitet werden kann und soll. Sie erhalten auf Wunsch auch monatliche Updates. Diese werden in ein von uns eingerichtetes separates Web (Foswiki) bzw. in einen separaten Space (Confluence) automatisch eingespielt und aktualisiert.

5. Individuelle Nutzungsbeispiele (Use Cases) für Ihr Unternehmen

Jedes Unternehmen ist anders. Ihre Mitarbeiter sind es auch. Allgemeine Vorlagen für pauschale Anwendungsfälle sind nützlich, doch darüber hinaus ist es hilfreich und notwendig dafür zu sorgen, dass individuelle Vorschläge etabliert werden, die den Mitarbeitern aufzeigen, inwiefern und wie sie das Wiki nutzen sollen und können. Gerade diese passgenauen Vorlagen sorgen für eine aktive Nutzung. Dabei brauchen die Mitarbeiter nicht einmal selbst Transferleistungen zu erbringen, sondern können direkt in die Vorlagen hineinarbeiten, die wir entwickeln, bzw. diese wiederverwenden.

Viele Wikis beginnen dann zu „fliegen“, wenn interne Mitarbeiter diesen Job übernehmen. Wenn das in Ihrem Unternehmen funktioniert, ist das super! Wenn jedoch eigene Mitarbeiter keine Zeit zur Erstellung guter Use Cases haben, sollten Sie ernsthaft in Erwägung ziehen, von der Kreativität und vom Know-how eines Wiki-erfahrenen Dienstleisters zu profitieren.

6. Kugelschreiber und Notizblöcke mit der Aufschrift „Ich schreib’s noch ins Wiki!“

Ein Betrieb könnte an seine Mitarbeiter Kugelschreiber mit der Aufschrift „Ich schreib’s noch rein: www.wiki-name.de“ ausgeben. Die Kugelschreiber verteilen sich fast wie von selbst, diffundieren durch die Belegschaft und weisen immer wieder aktiv darauf hin, dass das geschriebene Wort nicht nur aufs Papier, sondern auch für alle Mitarbeiter zugänglich ins Wiki gehört. Dafür eignen sich natürlich auch Notizbücher und Abreißzettel-Blöcke.

7. Webinare beim Rollout und zur Integration weiterer Mitarbeiter

Das wichtigste und wirkungsvollste Instrument für die Einbindung und Integration neuer Mitarbeiter in das Wiki ist der persönliche Kontakt. Leider ist dieser Kontakt gleichzeitig auch die knappste und teuerste verfügbare Ressource. Wir bieten Ihnen die Möglichkeit, Einführungen sehr persönlich und trotzdem effizient zu gestalten: mit einem Webinar. Als Webinar bezeichnet man ein Seminar, das im Internet durchgeführt wird. Die Mitarbeiter brauchen Ihren Arbeitsplatz nicht zu verlassen, sondern können mithilfe einer Telefonkonferenz und einer Desktop-Sharing-Sitzung auf den Bildschirm des Seminarleiters schauen.

So ist die Möglichkeit gegeben, jederzeit zu unterbrechen und miteinander zu reden. Gleichzeitig sehen alle Teilnehmer den gleichen Bildschirm und können nachvollziehen, wie mit der Software gearbeitet wird. Zusätzlich kann das Webinar mitsamt Bild und Ton aufgezeichnet werden und steht allen Mitarbeitern auch später noch zur Verfügung.

Ein Webinar lohnt sich ab drei bis vier teilnehmenden Mitarbeitern und die Organisation ist denkbar unkompliziert: Alle interessierten Mitarbeiter tragen sich in eine Liste ein, sobald sich genügend Teilnehmer gefunden haben, beginnt ein Terminierungsprozess, schließlich wird das Webinar abgehalten. Auf diese Weise kann dauerhaft und persönlich geschult werden.

Wir können Ihnen einerseits dabei helfen, die Wiki-Einführungsschulungen selbst durchzuführen, andererseits führen wir Webinare auch komplett durch. Besonders interessant an Webinaren ist auch, dass nach etwa fünf Sitzungen der Aufwand fast ausschließlich aus der reinen Präsentationszeit besteht. Es gibt kaum noch Vorbereitungs- und Nachbereitungszeiten und vor allen Dingen keinen Reiseaufwand.

8. Erstellung eines Handbuchs für Mitarbeiter: Zehn Schritte für den Einstieg ins Wiki

Eine gedruckte Broschüre oder ein Wiki-Dokument mit einer Anleitung und Einführung kann die Wiki-Nutzung weiter unterstützen. Ein individuelles Dokument, das zum Beispiel die Wiki-Auszeichnungssprache erklärt und als „Cheat-Sheet“ herangezogen werden kann, ist hilfreich und sinnvoll. Darüber hinaus sollten die Grundfunktionen eines Wikis leicht verständlich und mit Bildern (am besten denen aus dem eigenen Wiki) erklärt werden. Auf diese Weise haben Mitarbeiter immer die Möglichkeit, sich etwa fehlende Grundlagen zu erarbeiten. Papier hat zudem noch eine besondere „Präsenz“ auf dem Schreibtisch der Mitarbeiter.

9. Telefon-Hotline für Wiki-Support

//SEIBERT/MEDIA bietet auf Wunsch eine Wiki-Support-Hotline für Ihre Mitarbeiter an. Dort können Anrufe abgesetzt und Fragen sofort beantwortet werden. Die Abrechnung erfolgt minutengenau. Es gibt keine Mindestkontingente oder Pauschalgebühren. Auf Wunsch richten wir Ihnen eine eigene 0800er-Rufnummer ein.

10. Train-the-Trainer-Seminar: Workshop zur Wiki-Motivation für die Führungskräfte

Nichts ist wichtiger als die Akzeptanz und Nutzung des Wikis. Führungskräfte definieren durch ihr eigenes Handeln und die Anleitung ihrer Mitarbeiter, wie erfolgreich das Wiki ist. Was muss man einfordern? Wo sollte Zwang herrschen? Was geht mit Zwang gar nicht? Was funktioniert wie von allein? Wo muss man den Mitarbeitern helfen? Wann ist etwas nicht mehr sinnvoll im Wiki abgebildet? Wie gehe ich mit E-Mails um? Was mache ich mit Wiki-Verweigerern? Wie reagiere ich auf „Totschlag-Argumente“ gegen das Wiki? Was sind häufige Muster? Wie verhalten sich Mitarbeiter in Wikis? Solche und ähnliche Fragen beantworten wir bzw. helfen Ihren Führungskräften dabei, diese selbst beantworten zu können.

//SEIBERT/MEDIA ist ein erfahrener Wiki-Dienstleister und kann sowohl Wiki-Projekte von A bis Z realisieren als auch punktuell unterstützen. Denken Sie über eine Wiki-Einführung nach oder benötigen Sie Unterstützung beim Rollout Ihres bestehenden Systems? Haben Sie Fragen zu einzelnen hier beschriebenen Leistungen? Bitte nutzen Sie das Kontaktformular auf unserer speziellen Seite zum Thema Firmenwikis für Ihre Anfrage.

Weiterführende Informationen

Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen von Kunden und Informationsquellen
Strategische Firmenwikis und Unternehmenswikis im Tagesgeschäft: Eine wichtige Unterscheidung
Hofläden Supermärkte und Firmenwikis: „Bitte klingeln und Herzlich willkommen“

Abb.: Zugriffsentwicklung im 12-Monats-Verlauf, Grafik realisiert mit Confluence-Charts

Schwerpunkt Film

Zunächst zu einem konzeptionellen Schwerpunkt. Wir haben 2009 auf bewährte Formate gesetzt und mehr als 40 neue Podcasts produziert, aber auch neue Konzepte integriert: Seit diesem Jahr bereichert mit nützlichen Tutorials und vielen Vodcasts das Format Bewegtbild unseren Blog.

• Alle Vodcasts von //SEIBERT/MEDIA

Schwerpunkt Unternehmenskommunikation

Kollaborative Tools gehören zu den Themen des Jahres und das Stichwort Enterprise 2.0 ist eines der meistgebrauchten Buzzwords, wenn es um Intranet-Technologien geht. Hinter diesem Hype steckt tatsächlich etwas, denn Unternehmen können von Social-Media-Konzepten und -Tools signifikant profitieren – eine geeignete Einführungsstrategie und eine entsprechende Unternehmenskultur vorausgesetzt.

2009 haben wir mehr als 30 Wiki-Artikel publiziert, die sich mit Potenzialen, Funktionen und Anwendungsfällen von Enterprise Wikis befassen, und Wissenswertes über Projektabläufe veröffentlicht. Darüber hinaus sind die Anwendung des Micro-Blogging-Konzepts im Unternehmen und das systematische Aufgabenmanagement mit professionellen Tools in mehreren ausführlichen Beiträgen thematisiert worden.

Und nicht zuletzt haben wir uns Google Wave gewidmet, dem Thema der Stunde weit über Unternehmensgrenzen hinaus. Unser vielbeachteter Beitrag blickt auf Google Wave voraus, stellt die zu erwartenden Features vor und wagt eine erste Prognose. Ein halbes Jahr später haben wir die Beta-Version von Google Wave testen können und eine ausführliche Bestandsaufnahme erarbeitet, die auch im TechCrunch-Blog erschienen ist und dort erhebliche Resonanz hervorgerufen hat. Unser Zwischenfazit:

Wenn man sich ansieht, wie die Waves in einer Geschwindigkeit, der kein Mensch folgen kann, aktualisiert werden, wird klar, warum vor allem wenig Technologie-affine Nutzer Google Wave als zu komplex empfinden werden. Für professionelle Zusammenarbeit empfehle ich nach wie vor Wikis. Wer jedoch tatsächlich an Echtzeit-Kollaboration interessiert ist, wird mittelfristig wohl kaum um Google Wave herum kommen. Allerdings sind sehr gute Web-Kenntnisse und Technologie-Know-how im Unternehmen unverzichtbar.

Die wichtigsten Artikel zum Thema Social Media:

• Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
• Google Wave: Ein Ausblick auf eine neue Stufe der Unternehmenskommunikation
• Warum Google Wave nichts taugt und warum es trotzdem alle nutzen werden
• Micro-Blogging im Unternehmen: Potenziale und Anwendung am Beispiel des //SEIBERT/MEDIA-Micro-Blogs
• Aufgabenmanagement: Argumente für JIRA

Schwerpunkt Web 2.0 und Internet-Nutzung

Nachdem sich der Hype um das Web 2.0 in den letzten Jahren etwas gelegt hat, beschreiben immer mehr seriöse Studien den tatsächlichen Stand der Dinge in Sachen Web-Nutzung sowie die Möglichkeiten und auch die Schwierigkeiten, mit denen das Web-2.0-Umfeld zu schaffen hat. Diese Entwicklung haben wir auch 2009 intensiv verfolgt und regelmäßig aktuelle Forschungsergebnisse aufgegriffen, kommentiert und interpretiert. Unser Zwischenbilanz:

Man wird im Zusammenhang mit dem Web 2.0 sozusagen von einer Zwei-Klassen-Gesellschaft sprechen dürfen: Einerseits bedienen Angebote wie die großen Portale und die privaten Netzwerke ein Mainstream-Publikum und haben es teilweise auf eine beeindruckende Durchdringung des Webs gebracht, andererseits stagnieren die Zahlen bei Angeboten, die „nur“ Partikularinteressen entgegenkommen und von den Zielgruppen auch intensiv genutzt werden, aber sich der Mehrheit der User verschließen. Tatsächlich kann man wohl auch davon ausgehen, dass hier die Nutzerpotenziale weitgehend ausgeschöpft sind.

Die wichtigsten Artikel zum Thema Web-Nutzung:

• Internet Nutzung: Nutzerzahlen auf höchstem Niveau, Web-Bindung immer enger
• Web 2.0 und der Stand der Dinge: Wer generiert die Inhalte?
• Web 2.0 und der Stand der Dinge: Wer nutzt das Web 2.0 eigentlich?

Schwerpunkt Usability

Wie wichtig Usability im Web ist, hat sich glücklicherweise herumgesprochen. Wir beobachten nun, dass immer mehr Unternehmen auch die Nutzerfreundlichkeit ihrer Intranet-Anwendungen verbessern möchten. Vor diesem Hintergrund haben wir in diesem Jahr neben Personas insbesondere User-Tests thematisiert und deren Bedeutung gerade im Zusammenhang mit der Optimierung von Intranet-Software hervorgehoben:

Vor einem User-Test wird häufig leidenschaftlich diskutiert, und die Beteiligten klammern sich an ihre Überzeugungen. Nach einem User-Test gibt es keine Diskussionen mehr, die Fakten sprechen eine klare Sprache. Entscheidern fällt es wie Schuppen von den Augen, wenn sie in den Highlight-Videos sehen, wie ein Proband nach dem anderen über ein Problem stolpert.

Die exklusiven deutschen Übersetzungen der Fachartikel des renommierten Usability-Experten Jared M. Spool, dessen Kompetenz Leser in aller Welt ebenso schätzen wie seine sprachliche Verve, runden unser Portfolio an Usability-Beiträgen ab.

Die wichtigsten Usability-Artikel:

• Die politische Komponente von User-Tests
• Mehr als nice-to-have: In welchen Projekten Personas unverzichtbar sind
• Warum Mailto-Links auf Websites vermieden werden sollten
• Der Moderator als multiple Persönlichkeit: Drei Rollen bei der Durchführung von User-Tests

Schwerpunkt Design

Auch die Design-Abteilung hat im Jahr 2009 einmal mehr Akzente im //SEIBERT/MEDIA-Blog gesetzt. Neben aktuellen Artikeln rund um interessante Projekte sind unsere Design-Fachleute in Form ausführlicher Experten-Interviews zu den Themen Logo-Entwicklung und Web-Design zu Wort gekommen. Die Schlagzeile des Jahres aber ist und bleibt:

//SEIBERT/MEDIA/DESIGN erhält den iF-Award!

Die wichtigsten Design-Artikel:

• Design-Auszeichnung: //SEIBERT/MEDIA erhält den iF-Award
• Experten-Interview: Logo-Analyse, geschichtenerzählende Logos und Logo-Trends
• Experten-Interview: Was machen Web-Designer eigentlich genau?
• Sichtweisen auf Tag-Clouds: Wortwolken unter Design-Aspekten

Schwerpunkt Online-Marketing

Der Bereich Online-Marketing spielt im //SEIBERT/MEDIA-Blog nach wie vor eine gewichtige Rolle. Im Mittelpunkt steht vor allem Google, dessen Dienste natürlich zentrale Instrumente in Sachen Werbung und Marketing sind – doch wir blicken auch über den Tellerrand hinaus. Und im Zusammenhang mit Google, SEO und SEM sind auch Landing-Pages eines der Themen der Stunde, dem wir uns intensiv widmen:

Wir beobachten den Trend, dass normale Unternehmens-Websites im Zuge eines viel bewussteren und zielstrebigeren Online-Marketings immer weniger Chancen gegenüber klar positionierten Landing-Pages haben. Viele Websites entstanden unter dem „Wir-müssen-im-Web-sein“-Ansatz und wiesen vor allem beschreibende Inhalte auf. Eine eigens auf die Leistung oder das Produkt ausgerichtete Landing-Page bietet dagegen das, wonach der User sucht, nämlich die wichtigsten Informationen zum Thema ohne Ablenkungen oder Alternativen und eine eindeutige, konkrete Aufforderung zu einer erfolgversprechenden Handlung.

Die wichtigsten Artikel zum Thema Online-Marketing:

• Landing-Pages und Corporate Websites: Goldgrube und Millionengrab?
• Google AdWord vs. Bannerwerbung: Ein Bericht aus der Online-Marketing-Praxis
• Globales Suchmaschinen-Marketing darf nicht nur auf Google setzen
• Online-Werbung trotz Krise auf Wachstumskurs, aber auch vor Herausforderungen

Schwerpunkt Technologie

2009 sind die Entwickler von //SEIBERT/MEDIA/TECHNOLOGIES leider etwas zu selten zu Wort gekommen – daran werden wir im anbrechenden Jahr arbeiten! Trotzdem haben wir auch in diesem Jahr über einige spannende Technologien berichtet und z.B. Micro-Blogging-Systeme auf Herz und Nieren geprüft, eine TYPO3-Bestandsaufnahme gemacht und das Framework Grails thematisiert. Dem Cloud Computing – laut Gartner Hype Cycle dem IT-Trend 2009 schlechthin – haben wir uns schon Anfang des Jahres ausführlich gewidmet:

Wie so viele neue Technologien birgt das Cloud-Computing nicht nur Potenziale, sondern stellt Unternehmen auch vor Herausforderungen. Ein kritischer Faktor ist die Sicherheit. Unternehmen sollten auch berücksichtigen, dass in den europäischen Ländern hohe Anforderungen an das Auslagern von Daten bestehen: So dürfen Kundendaten in der Regel nur im Unternehmen selbst gespeichert werden. Für einzelne Anwendungsgebiete wie beispielsweise die Ablage des E-Mail-Verkehrs ist die Auslagerung in die „Rechnerwolke“ allerdings auch für deutsche Unternehmen eine vielversprechende Option – ein schlüssiges Sicherheitskonzept vorausgesetzt.

Die wichtigsten Technologie-Artikel:

• Cloud-Computing: Chancen und Herausforderungen
• Grails: Kurze Entwicklungszeiten und nahtlose Java-Integration
• Experten-Interview: TYPO3, kritische Punkte und gute Aussichten
• Micro-Blogging: Laconica und Yammer im Intranet

An dieser Stelle möchten wir uns bei Ihnen für das Interesse und den Input bedanken – bleiben Sie weiter dabei! Allen Lesern einen guten Rutsch und einen tollen Start ins neue Jahr wünschen das //SEIBERT/MEDIA-Blog-Team und alle Mitarbeiter!

Read this article in German.

Google Wave is a hot topic at the moment. The ambitious group collaboration and micro-messaging platform started rolling out in beta via an initial batch of 100,000 invitations two months ago. Many people still want invitations. Among those who’ve tried it, some criticize it, some praise it. For now it has a lot of usability problems that are described below. Yes, you should look at Google Wave. But there is no need to desperately long for an invitation yet.

Nevertheless, this post outlines how you’ll probably use Google Wave in the future and also gives you advice on how to implement it in your company or your team of coworkers. It also reveals some big usability problems in the current version. Those issues aside, I would like to show you the advantages of the “wave” once again and describe some cool use cases that might make you love it at some point in the future.

Introduction to Google Wave

If you don’t know the wave yet, you might want to see this movie:

Advantages of Google Wave

Innovative interface
The user interface of Google Wave breaks new ground and yet is not unfamiliar as its layout resembles the inbox of your mail application. The timeline that lets you recap how the wave has evolved and changed since your last visit is something that even wikis don’t have today—a feature that will surely be copied extensively in the future due to its intuitive usability.

Waves activate participants to contribute
Furthermore, the user interface motivates further contributions to the wave. This is an excellent way to convince a lot of people to participate.

Real-time collaboration
It is a completely new experience to actually see your friends, colleagues and contacts type in and change content in real time. No other application apart from a few client-side chat tools currently offers such a service via a web interface. If you’re a tech geek, you’ll love that part of Google Wave. It is a powerful innovation when it comes to real-time communication and collaboration. It is competing with the well-known comforts of email, wikis and chat, but in a lot of use cases, I think Wave will win.

What is Google Wave good for?

Brainstorming, early concept creation and discussion is what I see Google Wave being used for extensively in the near future. It can also serve as a multi-user note-taking platform for meetings and sessions in your company or university. If you want to organize an event collaboratively, Google Wave will most likely replace wikis. That’s a punch in the gut for all creators of wiki software.  These are just the most obvious uses.  As more people use Google Wave and become comfortable with it, they will begin using it in entirely new ways.  The real-time communications it makes possible will override its weak points because of the greater efficiency it allows for any group trying to work together.  One day the wave is gonna rock! But that is not today.

Google Wave is overly complex (Steve Rubel)

Robert Scoble put it this way: “This service is way overhyped and as people start to use it they will realize it brings the worst of email and IM together: unproductivity.”

What he means is shown in this video I have put on YouTube:

If you look at the public waves being updated at a speed that none of us can follow, you will understand how especially non-tech-savvy users will find it overly complex. I hear them say: “I just don’t want to know all this stuff.”

Even if “all this stuff” is relevant content from your teammates, you’ll have to filter and sort it all out to make it manageable. I believe it’s possible, but Google Wave users will have to learn how to do it. That’s the interface after login with an open wave:

Disadvantages and usability problems

Missing revisions with rollbacks
There is no professional revisioning system in place yet. If somebody messes up your wave and you want to undo it, you’re in for an unpleasant surprise: You have to do it manually. So folks, please do not delete too much content on waves.

No permanent hiding of replies yet
At the same time, Google Wave does not offer a way to permanently hide replies. Result? The main text in the wave is disturbed by images, boxes, colors and text from all participants. This can become a real mess and might even prevent you from reading the important content. The Google Wave team should definitely address this.
(Look at the screenshot above and see how nice the small “+” sign fits in. That should be the default.)

Why can’t I invite everybody yet? Closed preview kills value
Right now Google Wave is not suitable for real usage as too few people have an account. If you can’t invite everybody, the value of a wave decreases dramatically.

Where are notifications for updates of the waves I follow?
There are no means of monitoring waves. This is Google Wave’s biggest weakness.  I don’t get an email, Gtalk alert, or any other notification in the communication systems I already use today when there is new activity in a wave.  As I am still heavily using RSS feeds, I’d love an RSS feed of the waves I want to keep an eye on. Unfortunately, this isn’t yet an option.

Too slow for a real chat
For a real chat, Google Wave is much too slow. The performance of live transmissions varies from good to very poor and back without any understandable pattern. Today, you’ll want to keep using Skype or Jabber clients for chatting. I expect this to change, once we see local implementations of Google Wave in companies. Most of the server power can then go to the companies’ employees, clients and partners.

Google Wave is unstable
If there are peeks, Google Wave seems to have trouble with the load of lots of users. Here is a screenshot that I see way to often.

Portability: no exporting of waves possible yet
There isn’t an export feature to my beloved wiki yet. I’d love to have the wave content “natively” (not as an embed) in my Confluence, Foswiki (TWiki) or MediaWiki whenever I want it. To Google and wiki vendors: please give us that kind of portability.

Google accounts should not be required
Why do I need a Google Account to participate in a wave? That is a big problem if you want to engage with clients and non-tech-savvy users.

Who is really online?
Google Wave tries to display who is online by showing a green dot on the profile picture, but it’s not reliable yet. In fact, I’ve even seen people writing content who were identified as being offline.

Remember: don’t share confidential information in waves
As soon as you invite somebody to a wave, he can access it forever. If the discussion reveals secrets you don’t want to share with all participants, you’re out of luck: there is no way to get anybody out of the wave. The only chance you have is to create a new wave from the existing one. If you don’t want to do that, you’d better keep confidential information out.

No markup editing like in wikis
There is no source code view in Google Wave that you would want to use as an experienced wiki user to control what appears and how.

Waves lack readable URLs
Waves already have permanent URLs. But how readable is this? “https://wave.google.com/wave/#minimized:nav,minimized:contact,minimized:search,restored:wave:googlewave.com!w%252Be-cg7PN0A.1?. The Google Wave team will have to come up with more readable versions that are short and self-explanatory. This one should instead read: “https://wave.google.com/wave/google-wave-learnings-advantages-usecases-and-usability-flaws/252Be-cg7PN0A/fullscreen/”

To-do’s for you to use Google Wave in your company

The following list to be a bit premature. As one cannot install Google Wave yet, this is just a checklist to help you prepare for it.

1. Technology

• Server infrastructure and a good sysadmin: You will clearly need a server and a skilled admin to set up a Google Wave server, if you want to use it in your company. If you want a lot of employees, partners and clients to use it, you should prepare to invest in good hardware to make the real-time experience a good one. Up until now no one has been allowed to install the preview version of Google Wave. This means that nobody knows how difficult or easy it will be to install it and how easy it will be to connect it with other public wave servers. Still, it should be helpful to have a sysadmin around who knows what he is doing.
• HTML5-compatible browsers: Google Wave is an HTML5 application. If your company still works on Internet Explorer 6 or below, you will not be able to use Google Wave flawlessly. Therefore, make sure all participants have access to up-to-date browsers.
• Fast web connection: A decent web connection for both servers and clients is highly recommended to have a good real-time communication experience.
• Firewall configuration: Your admin should know how to configure your firewall so that your Google Wave server can communicate with the world.

2. Organization

• Define the goal of the wave and make sure everybody understands the purpose and the content of your wave. If you don’t, a lot of “side-noise” will arise.
• Create wave guidelines: You should set up guidelines for your wave participants to make sure they understand what the wave is for.
• On-boarding: Make sure that everybody you want to work with has a Google Wave account. (I know, this is quite difficult today. And that’s why Google Wave isn’t that useful yet.)
• What application is to be used? Differentiate the systems in your company so that everybody understands when to use emails, wikis, chats, databases and when to use Google Wave. How to set them apart? I don’t know.  This will emerge organically.
• Give Google Wave a purpose: Make sure people understand how to use Google Wave. You don’t want them to turn it down before even testing it thoroughly. That is especially true for the non-geek users.
• Not too many wavers on one wave: You should beware of inviting too many people because you can’t kick them out afterwards.

3. Culture

• Do not delete content without permission: My brother had created a new wave to evaluate Google Wave. We were all filling in texts, comments and arguments. Within a very short period of time, a really cool document had evolved, and I thought: “you should make this a blog post.” So I started to restructure it, changed arguments and content into text, and deleted the comments afterwards. The bashing and flaming that triggered from people who were angry with me for killing their content was enormous.
• Make rules and copyright clear: After I had restructured our wave and taken all the bashing for deleting the obsolete comments, the first participants asked if they could use the content in their blogs. We became aware of the as-yet unanswered question: “Who owns a wave? Who may do what with it? Who is allowed to use its content?” Make sure to clarify this in advance with your coworkers.
• Be aware of the complexity: The basic use and advantage of Google Wave should be clear to your employees once you roll out Google Wave. If the purpose is not clear, its complexity will quickly drive away many of your colleagues. Good luck trying to convince them to come back.
• Get ready for live feedback stress: A special problem in a wave is that you get answers to what you write while you’re still writing it. Every other means of communication leaves room to formulate and write your message first. In Google Wave the stress of a personal meeting with live communication can occur. (See the video above if you don’t know what I mean.)
• For now, consider only inviting geeks: Today, nobody can really control documents in waves, and there’s no real revision yet. And waves change a lot. Therefore, it’s better to invite people who can give good feedback. The more wavers, the more complex a wave will become.

Overall evaluation and outlook

If you criticize Google Wave, you should keep in mind that it is a “preview” now. It’s not a beta, and it’s not a final release. The Google Wave team has set out to create “email as it should be in 2010”. And from what I see, they have a good chance of doing so, but 2010 is less than two months away. However, I am willing to bet that this piece of software will eventually overcome Robert Scoble’s criticism.

For professional collaboration, I still recommend the wikis mentioned above. But if you’re into real-time collaboration, Google Wave will eventually be your choice. Just make sure to bring advanced web skills.

Sources

A lot of the content for this blog post was created in a wave. As no one knows who owns the content in a wave, I would like to list all who participated: mseibert (That’s me!), jseibert, eicker, bfri, Silke, Sam, Gerrit, Ton, Paul.

Google Wave ist zurzeit ein mächtig heißes Thema. Die ehrgeizige Plattform für Micro-Messaging und für die Zusammenarbeit in Teams ist vor wenigen Monaten im Beta-Stadium angekommen, 100.000 Einladungen wurden verschickt, viele Leute warten noch darauf. Von denjenigen, die Google Wave bereits ausprobiert haben, hört man sowohl kritische als auch lobende Stimmen. Insbesondere hat Google Wave noch zahlreiche Usability-Probleme, auf die ich eingehen werde. Ja, Sie sollten Google Wave ausprobieren, aber es gibt keinen Grund für schlaflose Nächte, in denen man die Einladung herbeisehnt.

In diesem Beitrag erläutere ich, wie Sie Google Wave später wahrscheinlich nutzen werden und wie Sie es am besten in Ihrem Unternehmen oder in Ihrem Team implementieren. Ich spreche auch einige der größten Usability-Probleme an. Zunächst möchte ich aber die Vorteile der „Welle“ noch einmal beschreiben und Ihnen einige coole Anwendungsmöglichkeiten zeigen, die vielleicht künftig dazu führen, dass Sie einige Aspekte von Google Wave doch lieben werden.

Eine kurze Einführung

In unserem Artikel Google Wave: Ein Ausblick auf eine neue Stufe der Unternehmenskommunikation haben wir wichtige Funktionen des Systems vorgestellt. Falls Sie Google Wave noch nicht kennen, sollten Sie sich auch diesen einführenden Film ansehen:

Vorteile von Google Wave

Innovative Oberfläche
In Sachen Oberfläche geht Google Wave neue Wege, ist aber dennoch nicht unvertraut, da das Interface dem Posteingang eines E-Mail-Accounts ähnelt. Die Zeitleiste, auf der man verfolgen kann, wie eine Welle entstanden ist und wie sie sich seit dem letzten Besuch entwickelt hat, ist ein Feature, das heute noch nicht einmal Wikis vorweisen können – ein Feature, das man aufgrund seiner intuitiven Usability in Zukunft gewiss immer wieder kopieren wird.

Waves aktivieren Teilnehmer
Darüber hinaus motiviert die Oberfläche die Leute, sich an der Wave zu beteiligen. Tatsächlich ist dies eine hervorragende Möglichkeit, viele Teilnehmer zu generieren.

Zusammenarbeit in Echtzeit
Es ist eine ganz neue Erfahrung, Kollegen, Freunden und Kontakten dabei zuzusehen, wie sie Inhalte eingeben und verändern. Keine andere Anwendung (von einigen Chat-Tools abgesehen) bietet derzeit eine solche Funktion über eine Web-Oberfläche an. Technologie-Freaks werden diesen Aspekt von Google Wave lieben. Das ist tatsächlich eine mächtige Innovation in Sachen Echtzeitkommunikation und -zusammenarbeit; hiermit tritt Google Wave in direkte Konkurrenz zu den bekannten Technologien E-Mail, Wikis und Chats und deckt all diese Anwendungsfälle ab. Ich gehe davon aus, dass Wave in diesem Punkt als Sieger vom Platz gehen wird.

Wofür ist Google Wave gut?

Meiner Meinung nach dürfte Google Wave in naher Zukunft intensiv für Brainstorming, für frühe Stadien der Konzepterstellung und für Diskussionen genutzt werden. Es wird sicherlich auch als „Multi-User-Note-Taking“-Plattform bei Meetings Anwendung finden. Bei der kooperativen Organisation von Events wird Google Wave höchstwahrscheinlich Wikis ersetzen, ein schwerer Schlag für alle Entwickler von Wiki-Software. Dies sind die naheliegenden Anwendungsfälle. Wenn viele Leute Google Wave nutzen und sich damit gut auskennen, werden sie es auch in ganz anderen Bereichen einsetzen. Die Möglichkeit der Echtzeit-Kommunikation und die damit verbundene enorme Effizienz der Kommunikation in der Gruppe werden die Schwächen jedenfalls übertünchen; eines Tages wird die Welle rocken! Aber noch nicht heute.

Google Wave ist übermäßig komplex (Steve Rubel)

Robert Scoble drückt es so aus: „Dieses System ist overhyped und wenn die Leute es nutzen, werden sie merken, dass in ihm das Schlechteste aus E-Mail und Instant Messaging kombiniert wird: Unproduktivität.“

Was damit gemeint ist, sieht man gut in diesem Video, das ich auch bei YouTube eingestellt habe:

Tatsächlich: Wenn man sich ansieht, wie die Waves in einer Geschwindigkeit, der kein Mensch folgen kann, aktualisiert werden, wird klar, warum vor allem wenig Technologie-affine Nutzer Google Wave als zu komplex empfinden werden. Ich höre es schon: „Das will ich alles gar nicht wissen.“

Auch wenn das alles wertvolle Beiträge des eigenen Teams sind, wird man sie filtern und sortieren müssen, um sie nutzbar zu machen. Ich bin sicher, dass das klappen kann, aber Google-Wave-User werden lernen müssen, wie es funktioniert. So sieht eine geöffnete Wave nämlich beispielsweise aus:

Nachteile und Usability-Probleme

Keine Revisionen mit „Rollback“
Bislang gibt es kein professionelles Revisionssystem. Wenn Ihnen jemand Ihre Wave „verhunzt“ und Sie dies rückgängig machen möchten, werden Sie staunen: Sie müssen es manuell und in Handarbeit erledigen! Also: Vorsicht vor dem spontanen Löschen von Inhalten!

Kein dauerhaftes Verbergen von Antworten
Zur Zeit gibt es noch keine Möglichkeit, Antworten dauerhaft zu verbergen. Das Resultat? Der Haupttext in der Wave wird durch Bilder, Kästen, Farben und Anmerkungen von sämtlichen Teilnehmern massiv gestört. Das kann wirklich für Verwirrung sorgen und sogar vom Lesen des eigentlichen Inhalts abhalten. Hierum sollte sich das Google-Wave-Team wirklich kümmern.  (Sehen Sie sich im Screenshot oben mal an, wie schön, das „+“ eingefügt ist. Das sollte Standard sein.)

Geschlossene Previews mindern den Nutzen
Haute kann man Google Wave nur eingeschränkt nutzen, da nur sehr wenige Leute einen Zugang haben. Nicht einladen zu können, wen man will, reduziert den Nutzen der Anwendung dramatisch.

Keine Update-Benachrichtigungen
Es gibt keine Information über Updates der Waves, und dies ist der größte Schwachpunkt der Software. Ich erhalte keine E-Mail, keinen Gtalk-Alarm, keine wie auch immer geartete Mitteilung über ein Drittsystem, wenn es neue Aktivitäten in einer Wave gibt. Da ich selbst RSS-Feeds intensiv nutze, fände ich es toll, Waves via RSS im Auge behalten zu können. Leider ist das bisher nicht angedacht.

Zu langsam für wirklichen Chat
Für einen richtigen Chat ist Google Wave viel zu langsam. Die Performance im Hinblick auf die Übertragungsgeschwindigkeit schwankt zwischen gut und wirklich mies, ohne dass ein Muster zu erkennen wäre. Für viele Leute sieht es momentan danach aus, als würden Jabber-Clients oder Skype auch weiterhin die besseren Alternativen bleiben. Ich rechne aber damit, dass sich das Performance-Problem von Google Wave mit der Etablierung von lokalen Installationen in Unternehmen erübrigen wird, da dann der Großteil der Server-Kapazitäten natürlich von Mitarbeitern, Kunden und Partnern genutzt werden kann.

Google Wave ist instabil
In Spitzenzeiten hat Google Wave offensichtlich Probleme, die Nutzerlast zu stemmen. Diesen Bildschirm sehe ich viel zu oft:

Kein Wiki-Export von Waves
Bis jetzt gibt es keine Wiki-Exportfunktion. Es wäre sehr hilfreich, Waves nativ (und nicht über embed) im Firmenwiki auf Basis von Confluence, Foswiki, MediaWiki etc. verfügbar machen zu können. Auch das sollten sowohl Google als auch die Wiki-Hersteller bzw. -Communities auf die Tagesordnung setzen.

Obligatorische Google-Accounts
Warum benötige ich ein Google-Account, um an einer Wave teilzunehmen? Dies ist ein großes Problem, wenn man mit Kunden und wenig Technologie-versierten Benutzern zusammenarbeiten möchte.

Wer ist wirklich online?
Google Wave versucht durch einen grünen Punkt neben dem Profil anzuzeigen, wer online ist, aber das funktioniert noch nicht zuverlässig. Tatsächlich habe ich Nutzer Beiträge schreiben sehen, die als offline angezeigt wurden.

Gefahr für vertrauliche Informationen in Waves
Wenn Sie jemanden einmal zu einer Wave eingeladen haben, kann er bis in alle Ewigkeit auf diese zugreifen. Werden in der Diskussion irgendwann vertrauliche Informationen thematisiert, die nicht für jedermanns Augen gedacht sind, haben Sie Pech: Es gibt keine Möglichkeit, jemanden aus der Wave auszuschließen. Die einzige Lösungsmöglichkeit besteht darin, eine neue Wave aus der bestehenden heraus zu eröffnen. Wem das nicht gangbar erscheint, sollte in Waves lieber auf vertrauliche Inhalte verzichten.

Kein Markup-Editor
Es gibt keine Quellcodeansicht in Google Wave. Gerade erfahrene Wiki-Nutzer wünschen sich einen solchen Modus, um die Aufbereitung und Struktur der Inhalte zu steuern.

Keine lesbaren URLs
Jede Wave hat einen Perma-Link. Aber lesbar ist eine solche URL nicht: https://wave.google.com/wave/#minimized:nav,minimized:contact,minimized:search,restored:wave:googlewave.com!w%252Be-cg7PN0A.1?.

Das Google Wave-Team wird URLs entwickeln müssen, die möglichst kurz und vor allem selbsterklärend sind. Der oben dargestellte Link sollte besser so lauten: https://wave.google.com/wave/google-wave-learnings-advantages-usecases-and-usability-flaws/252Be-cg7PN0A/fullscreen/.

To-dos, um Google Wave im Unternehmen zu nutzen

Die folgende Liste ist zwangsläufig natürlich unfertig: Bisher kann ja niemand Google Wave lokal implementieren. Als zu erweiternde Rohfassung einer Checkliste dürften diese Anmerkungen aber allemal ihre Berechtigung haben.

Technologie

• Server-Infrastruktur und ein guter Admin. Voraussetzungen sind natürlich eigene Server und ein guter Systemadministrator, um einen Google-Wave-Server aufzusetzen. Wer Google Wave gemeinsam mit zahlreichen Angestellten, Partnern und Kunden nutzen will, sollte auch in wirklich gute Hardware investieren – vor allem, damit die Echtzeitkomunikation auch eine solche ist. Da bis jetzt noch niemand die Preview-Version von Google Wave lokal installieren durfte, sind die Kenntnisse hinsichtlich der Installation und der Verbindung mit anderen Google-Wave-Servern sehr überschaubar. Es dürfte jedenfalls sinnvoll sein, einen Admin zu haben, der weiß, was er tut.
• HTML5-kompatible Browser. Google Wave ist eine HTML5-Applikation. In Unternehmen, die noch mit dem Internet Explorer 6 und abwärts arbeiten, wird das System nicht fehlerlos laufen. Alle Mitarbeiter (und die zu integrierenden Kunden!) brauchen aktuelle Browser.
• Schnelle Web-Verbindung. Eine ordentliche Web-Verbindung auf Server- und auf Client-Seite ist für eine funktionierende Echtzeitkommunikation unerlässlich.
• Firewall-Konfiguration. Die Admins im Unternehmen sollten wissen, wie die Firewall zu konfigurieren ist, damit der interne Google-Wave-Server auch mit der Welt kommunizieren kann.

Organisation

• Zieldefinition. Eine zentrale Bedeutung wird der Zieldefinition zukommen: Jede Wave muss einen fest definierten Gegenstand haben, jeder muss Zweck und Inhalt der Wave verstehen. Ist das nicht der Fall, entstehen garantiert viele Nebengeräusche.
• Richtlinien erstellen. Damit Google Wave im Unternehmen sinnvoll genutzt werden kann, müssen Regeln eingehalten werden und muss jeder Teilnehmer wissen, wozu Google Wave dient. Man wird nicht umhinkommen, einen ausführlichen Leitfaden zu erstellen.
• Onboarding. Es muss sichergestellt werden, dass alle einzubindenden Nutzer über einen Google-Account verfügen. (Gerade das ist derzeit ziemlich problematisch und gerade deshalb ist Google Wave auch momentan noch nicht sehr nützlich.)
• Communication Patterns. Welche Applikation soll wofür verwendet werden? Im Unternehmen muss unterschieden werden, welche Anwendungsfälle ein System jeweils am besten abbildet. Alle müssen wissen, wann sie E-Mails schreiben sollen und wann die Nutzung von Wiki, Chat, Datenbank oder eben Google Wave am sinnvollsten und effizientesten ist.
• Zweck definieren. Geben Sie Google Wave einen Zweck. Jedes neu einzuführende System braucht eine Daseinsberechtigung. Es muss also deutlich werden, was ein System besser, effektiver, effizienter abbilden kann als andere Anwendungen. (Was das im Falle von Google Wave tatsächlich ist, wird sich mittelfristig organisch entwickeln.) Zudem müssen Mitarbeiter verstehen, wie sie mit Google Wave arbeiten: Niemand will, dass Mitarbeiter ein System ablehnen, ohne es richtig ausprobiert zu haben. Hier wird man sich insbesondere Mitarbeitern widmen müssen, die nun nicht unbedingt Computerfreaks sind.
• Nicht zu viele Waver in einer Wave. Wie erwähnt: Bei der Einladung zahlreicher Nutzer zu einer Wave ist Bedacht geboten. Später kann niemand mehr ausgeschlossen werden.

Kultur

• Keine Inhalte ohne Erlaubnis löschen. Hier möchte ich ein Beispiel aus eigener Erfahrung einbringen: Mein Bruder hat eine neue Wave eingerichtet, um Google Wave zu evaluieren. Mehrere Kollegen haben diese nun mit Texten, Kommentaren und Argumenten gefüllt, gemeinsam ist schon nach kurzer Zeit ein ziemlich eindrucksvolles Dokument entstanden. Mein naheliegender Gedanke: „Das sollte ein Blog-Artikel werden.“ Also habe ich mich daran gemacht, die Wave umzustrukturieren, habe Argumente und Inhalte in Fließtextform gebracht und die so verarbeiteten Kommentare anschließend gelöscht. Das Gewitter, das seitens der Teilnehmer über mich hereingebrochen ist, war ziemlich heftig! Meine Kollegen waren schlicht verärgert, weil ich mich einfach an ihrem Input vergriffen habe.
• Regeln und Copyright klarstellen. Nachdem ich unsere Wave neu strukturiert und den Ärger der Leute über das Löschen veralteter Kommentare über mich ergehen lassen hatte, haben mich die ersten Teilnehmer gefragt, ob sie die Inhalte der Wave für ihre Blogs nutzen könnten. Hier ist uns bewusst geworden, dass es noch einige ungeklärte Fragen gibt: Wem „gehört“ eine Wave? Wer darf was damit machen? Wer darf die Inhalte weiterverwenden? Darauf müssen Antworten gefunden werden, wenn Google Wave im Unternehmen eingesetzt wird.
• Sich der Komplexität bewusst sein. Wenn Google Wave einmal im Unternehmen ausgerollt wird, sollten die Mitarbeiter wissen, wie sie das System grundsätzlich bedienen und seine Vorteile kennen. Wenn insbesondere nicht klar ist, welchen Sinn und Zweck Google Wave hat, werden viele Mitarbeiter ganz schnell wieder abspringen. Viel Spaß dabei, diese Leute später wieder zur Nutzung von Google Wave zu animieren!
• Auf Live-Feedback-Stress vorbereitet sein. Ein spezielles Problem in einer Wave ist, dass man bereits Antworten erhält, während man seine Nachricht noch formuliert. Jedes andere Kommunikationsmittel lässt dem Nutzer Zeit, seine Mitteilung in Ruhe zu formulieren und zu verfassen. Mit Google Wave kann durchaus der gleiche Stress entstehen wie mitunter in einem Gespräch von Angesicht zu Angesicht. (Sehen Sie sich das Video oben doch noch einmal an, dann wissen Sie, was ich meine.)
• Zunächst nur Waver mit Technik-Know-how einladen. Anfangs sollten nur Technologie-interessierte, erfahrene User eingeladen werden: Derzeit kann niemand Dokumente in einer Wave wirklich kontrollieren, zudem gibt es noch keine wirkliche Revisionskontrolle. Und Waves verändern sich andauernd. Bei der Evaluation von Google Wave dürfte es zunächst sinnvoll sein, Leute einzuladen, die ein ausgeprägtes Technologieverständnis haben und wirklich gutes Feedback geben können. Und: Je mehr Waver, desto komplexer wird eine Wave.

Zusammenfassung und Ausblick

Wer Google Wave in diesem Stadium kritisiert, sollte freilich bedenken, dass wir es mit einer Preview-Version und längst nicht mit einem amtlichen Release zu tun haben. Das Google-Wave-Team hat angekündigt, mit der Software die „E-Mail, wie sie 2010 sein sollte“ abzubilden. Und was ich bisher gesehen habe, lässt mich damit rechnen, dass dies den Google-Wave-Leuten auch gelingen wird. Allerdings ist 2010 inzwischen ziemlich nahe. Dennoch gehe ich davon aus, dass diese Software die Kritik von Robert Scoble überwinden wird.

Für professionelle Zusammenarbeit empfehle ich nach wie vor Wikis. Wer jedoch tatsächlich an Echtzeit-Kollaboration interessiert ist, wird mittelfristig wohl kaum um Google Wave herum kommen. Allerdings sind sehr gute Web-Kenntnisse und Technologie-Know-how im Unternehmen unverzichtbar.

Eine Großteil des Inhalts dieses Artikels entstammt einer Wave. Da niemand weiß, wem der Inhalt einer Wave gehört, möchte ich alle Teilnehmer aufzählen, die mit mir zusammen für diesen Beitrag verantwortlich sind: jseibert, eicker, bfri, Silke, Sam, Gerrit, Ton, Paul.

Abb.: Hype Cycle of Emerging Technologies, 2009 (Quelle: Presseerklärung Gartner)

Phasen des Hype Cycle

Der Hype Cycle ist in Tech-Kreisen zu einem weitgehend anerkannten (wenn auch nicht ganz unumstrittenen) Tool geworden. Dieses von Jackie Fenn entwickelte Prognosewerkzeug beschreibt die Reife von Technologien mithilfe von Phasen unterschiedlich großer öffentlicher Aufmerksamkeit, die Innovationen entgegengebracht wird, und unterschiedlicher Erwartungen, die an Technologien gestellt werden. Demnach durchlaufen Technologien und Trends fünf Phasen.

Impulsphase: Eine neue, innovative Technologie wird vorgestellt und findet in Fachkreisen große Aufmerksamkeit. Nachahmer treten auf den Plan, schnell sieht sich die „revolutionäre“ Technologie übertriebenen Erwartungen gegenüber.

Gipfel der überhöhten Erwartungen: Die Technologie befindet sich auf dem Höhepunkt des Hypes. Die Erwartungen an die Innovation sind ebenso extrem hoch wie die Aufmerksamkeit, die der Technologie gewidmet wird.

Tal der Ernüchterung: Es wird deutlich, dass die Technologie nicht sämtliche Erwartungen und Anforderungen erfüllen kann und einige Vorschusslorbeeren zu Unrecht erhalten hat. In der öffentlichen Wahrnehmung spielt die Technologie eine immer geringere Rolle. Hier entscheidet sich, ob eine Technologie innovativ genug ist, um sich durchzusetzen, und überhaupt einen Nutzwert hat.

Pfad der Erkenntnis: Nach der Ernüchterung setzt sich eine realistische Sicht auf die Technologie durch. Ein Verständnis für die Vorteile, für die praktische Anwendung und auch für die Nachteile entsteht. Der reale Nutzwert der Technologie wird erkannt, sie wird vom Ballast überzogener Erwartungen befreit. Darin besteht die Voraussetzung, dass sich die Technologie auf breiter Ebene durchsetzt und produktiv genutzt werden kann.

Plateau der Produktivität: Die Technologie hat ein Niveau der Akzeptanz auf breiter Ebene erreicht, ihre Vorteile sind bekannt und werden weithin akzeptiert. Sie ist ausgereift und wird ständig weiterentwickelt. Nun entscheidet sich, ob die Technologie den Massenmarkt erobert oder sich vielmehr in einem Nischenmarkt etabliert.

Technologien innerhalb des Hype Cycle

An dieser Stelle wollen wir einige Technologien und Trends näher betrachten, für die sich derzeit besonders viele Unternehmen interessieren und mit denen wir uns in Blog-Artikeln immer wieder beschäftigen. Trendsetter der Stunde ist ein IT-Konzept.

Cloud Computing: Auf dem Höhepunkt des Hypes befindet sich das Cloud-Computing, einer der tatsächlich prägenden IT-Trends des Jahres 2009. Gartner dazu:

„The levels of hype around cloud computing in the IT industry are deafening, with every vendor expounding its cloud strategy and variations, such as private cloud computing and hybrid approaches, compounding the hype.“ (Dieses und die weiteren Zitate sind der Presseerklärung zur Veröffentlichung des Hype Cycle 2009 entnommen.)

Social Software Suites: Social Software Suites – Enterprise-2.0-Arbeitsplätze bzw. integrierte „Pakete“ also, die Firmenwikis, Blogs und Micro-Blogs im Intranet sowie andere kollaborative Technologien umfassen – befinden sich den Gartner-Experten zufolge auf dem Weg ins Tal der Ernüchterung:

„Awareness of social technology is high because of the popularity of related consumer social software and Web 2.0 services. Within businesses, there is strong and rapidly growing evidence of experimentation and early production deployments. The movement from point tools to integrated suites has brought broader adoption but also high expectations. Disillusionment is beginning based on the realization that, even with a suite, much work must be done to build an effective social software deployment.“

Mit anderen Worten und um es an dieser Stelle einmal mehr zu betonen: Social Software läuft nicht von allein. Gartner geht also offenbar davon aus, dass viele Unternehmen relativ blauäugig auf den Social-Media-Zug aufspringen oder schlicht noch mit diesen Technologien experimentieren, ohne sich Gedanken über die tatsächliche Etablierung im Unternehmen zu machen – mit der Folge, dass die Erwartungen enttäuscht werden.

In zwei bis fünf Jahren, so Gartner, werden sich Social Software Suites indes endgültig in Unternehmen durchgesetzt haben. Ob es zwischenzeitlich wirklich zu einem Fall ins Tal der Ernüchterung kommen wird, bleibt abzuwarten.

Twitter: Gartner zufolge hat auch Micro-Blogging und damit insbesondere Twitter – 2008 noch auf dem Gipfel der überhöhten Erwartungen – den Zenit nun überschritten. Folglich sei mit einer Ernüchterung zu rechnen, Anzeichen hierfür wären laut Gartner bereits erkennbar:

„Microblogging, in general, and Twitter, in particular, have exploded in popularity during 2009 to the extent that the inevitable disillusionment around “channel pollution” is beginning.“

Mit dem zunehmenden Spam-Aufkommen will Gartner auch die Hauptursache für die Desillusionierung ausgemacht haben. Hier ist jedoch Skepsis angebracht: Immerhin steigen die Nutzerzahlen nach wie vor stark an, die mediale Aufmerksamkeit ist ungebrochen, immer mehr Unternehmen erkennen Twitter als zusätzlichen Kommunikationskanal – eigentlich Indizien dafür, dass der Twitter-Hype seinem Höhepunkt vielmehr noch entgegenstrebt.

Web 2.0: Das Web-2.0-Konzept durchquert dem Hype Cycle zufolge gerade das Tal der Ernüchterung. Insbesondere die Erkenntnisse, dass das Mitmach-Netz größtenteils der 90-9-1-Regel unterliegt, dass Web-2.0-Plattformen zwar von vielen Usern genutzt werden, sich aber nur ein geringer Prozentsatz aktiv beteiligt, und dass das Partizipieren wohl eine Domäne einer kleinen Gruppe von Nutzern bleiben wird, dürften den Hype in den letzten Jahren merklich haben abklingen lassen. Dennoch soll sich in den nächsten zwei Jahren eine realistische Sichtweise auf Stärken, Schwächen und Anwendbarkeit des Web-2.0-Konzepts durchsetzen.

Wikis: Auf dem Pfad der Erleuchtung befinden sich laut Hype Cycle Wikis. Damit hätten sie erst vor nicht allzu langer Zeit das Tal der Ernüchterung verlassen – allerdings war von dieser vermeintlichen „Krise“ wenig zu spüren. Die Gartner-Analysten schätzen, dass es noch zwei bis fünf Jahren dauern wird, bis sich Enterprise-Wikis auf breiter Ebene durchgesetzt haben und sie das Plateau der Produktivität erreichen werden.

Hier stellt sich die Frage, ob das Firmenwiki-Konzept nicht schon etablierter ist, als es der Hype Cycle aussagt: Tatsächlich geht beispielsweise die Society for Information Management’s Advanced Practices Council (APC) davon aus, dass bereits heute 50% aller Unternehmen Wikis einsetzen.

Corporate Blogs: Unternehmens-Blogs folgen ebenfalls dem Pfad der Erleuchtung. Der Corporate Blog etabliert sich demnach also zusehends als ernstzunehmender Kommunikationskanal mit einem tatsächlichen Nutzwert. Den Gartner-Analysten zufolge wird die Technologie allmählich wirklich verstanden und ihre Potenziale werden immer realistischer eingeschätzt. Innerhalb der nächsten zwei Jahre soll der Unternehmens-Blog das Plateau der Produktivität erreicht haben.

Soweit einige Aussagen des Hype Cycle 2009, der (wie dargestellt) in Teilen sicherlich diskussionswürdig ist. Vor allem bezieht sich die Gartner-Studie auf US-amerikanische Verhältnisse, die gewiss nicht ohne weiteres auf die hiesige Situation übertragbar sind. Wie sehen Sie das? Spiegelt der Hype Cycle die Realität wider? Oder beurteilen Sie die Entwicklung mancher Technologien und Konzepte ganz anders? Nutzen Sie gerne die Kommentarfunktion unter diesem Artikel für Ihre Anmerkungen.

Weiterführende Informationen

Der Hype-Cycle: Bedeutung und Kritik
Firmenwikis: Ihr Wiki-Projekt in guten Händen
Social Software: Woran die Einführung von Enterprise-2.0-Tools scheitern kann
Social Software: Der Wikipedia-Irrtum
Micro-Blogging im Unternehmen: Potenziale und Anwendung
Cloud Computing: Chancen und Herausforderungen

Unsicherheit der Nutzer

Oft ist es Mitarbeitern, die neue Dokumente anlegen wollen, nicht klar, wo der Inhalt im Wiki am besten untergebracht ist. Oder aber sie sind sich unsicher, ob sie ein neues Dokument anlegen oder ein bereits bestehendes Dokument ergänzen sollen. Leider wissen sie aber häufig nicht, wo bereits bestehende Dokumente zu finden sind.

Die Folge: Der Mitarbeiter fühlt sich hilflos und möchte nichts falsch machen. Dies führt im schlimmsten Fall dazu, dass er lieber ganz davon absieht, Inhalte einzustellen.

Probleme mit der Einordnung und Auffindbarkeit von Dokumenten

Hier kann man in drei Problembereiche aufteilen:

1. Dokumente existieren mehrfach in unterschiedlicher Ausführung und in verschiedenen Iterationsstufen, was den Nutzer verunsichert und in den meisten Fällen nicht dazu führt, dass er diesen Umstand beseitigt. So bleibt das Problem bestehen und wiederholt sich immer wieder.
2. Es gibt keine sinnvolle Möglichkeit, Inhalte zu finden. Es besteht nur die Suche und diese funktioniert womöglich nicht verlässlich. Dokumente und Inhalte werden deshalb nicht gefunden.
3. Inhalte sind unsortiert und können nicht themen- und kontextbasiert gefunden werden. Dazu bedarf es einer entsprechenden Hierarchie (Taxonomie) und der Verschlagwortung (Tagging); Funktionen, die in vielen Wikis kaum genutzt werden. Dadurch, dass Inhalte außerhalb des Kontextes stehen und somit praktisch unauffindbar sind, bleibt es dem Nutzer verwehrt, neue Inhalte zu entdecken, wodurch das Wiki für ihn an Wert verliert.

Die optimale Organisation des Wissens

Ein gut strukturiertes Wiki ermöglicht es den Mitarbeitern, einen Überblick über die Inhalte zu erlangen. Es verfügt sowohl über eine gute und präzise Suche als auch über Strukturierungs- und Filtermechanismen, die das Auffinden von gesuchten Informationen genauso einfach machen wie das Entdecken von neuen, interessanten Inhalten. Verwandte Themen sind über Links und Hinweise miteinander verbunden.

Wie kann das Wiki-Chaos vermieden werden?

Die folgenden Maßnahmen sollen eine bessere Strukturierung und Organisation des Firmenwikis unterstützen. Keinesfalls sollen sie die Wiki-Nutzung verkomplizieren, daher richten sich diese Hinweise vor allem an Nutzer, die von der Nützlichkeit eines Wikis überzeugt sind und bereits damit arbeiten.

• Vor dem Anlegen eines neuen Dokuments sollte sich der Nutzer einen umfassenden Überblick (am besten durch die Nutzung mehrerer offener Tabs im Browser) über bereits bestehende Dokumente zum Thema verschaffen. Dazu dient die Suchfunktion. Dieser Vorgang nimmt nur wenig Zeit in Anspruch.
• Bei der Entscheidung darüber, ob man ein neues Dokument anlegen oder besser ein bereits bestehendes Dokument ergänzen sollte, kann man einen Richtwert von zehn Zeilen heranziehen. Besteht der Inhalt aus weniger als zehn Zeilen, ist das Anlegen eines neuen Dokuments wahrscheinlich nicht sinnvoll.
• Das Anlegen eines neuen Dokuments sollte immer aus dem am besten passenden bestehenden Dokument heraus erfolgen. So wird es automatisch zum Tochterdokument und verwandte Inhalte können schneller gefunden werden. Eine spätere Zuordnung ist zwar auch noch möglich, aber umständlicher und zeitaufwändiger.
• Um das eigene Wissen bzw. den eigenen Inhalt sinnvoll einzufügen und zu vernetzen, können verwandte Themen, die bestenfalls in den Tabs noch geöffnet sind, mit Links zum neu geschaffenen Inhalt versehen werden. Dies führt auch zu einer Verbesserung der Qualität der bestehenden Dokumente.
• Inhalte sollten mit Schlagwörtern versehen werden (Tagging). So lassen sich Artikel auf verschiedenen inhaltlichen Ebenen miteinander verknüpfen. Diese Verschlagwortung kann auch der Leser jederzeit vornehmen. Grundsätzlich gilt: Je mehr passende Tags pro Wiki-Dokument vergeben werden, desto besser.
• Die Erstellung von Themenportalen fördert die Auffindbarkeit von Inhalten im Wiki. Ein solches Portal lohnt sich ab einer Anzahl von etwa 20 thematisch relevanten Wiki-Dokumenten. Hier ist die Integration eines Brotkrumenpfads sehr sinnvoll. Bei einer großen Anzahl von Themenportalen ist es üblich, ein übergeordnetes Portal anzulegen. Die Übersichtsseiten sollten stets auf der Wiki-Startseite verlinkt werden.
• Durch die Visualisierung des Wiki-Aufbaus in Form eines Strukturbaums wird dem Nutzer die Orientierung im Wiki erleichtert. Mithilfe des Strukturbaums lässt sich aber auch die mangelhafte Verortung einzelner Dokumenten aufdecken. Diesen Missstand sollte ein erfahrener Wiki-Nutzer dann rasch beheben.

Wichtig: Die richtige Software

Um Struktur und Ordnung in ein Firmenwiki zu bringen und aufrecht zu erhalten, muss die verwendete Wiki-Software die eben beschriebenen Maßnahmen unterstützen. Wir empfehlen aus eigener Erfahrung die Nutzung der vollständig anpassbaren Open-Source-Software Foswiki oder den Einsatz des kommerziellen Systems Confluence, das insbesondere durch seine ausgezeichnete Usability überzeugt.

Durch das Zusammenwirken der geeigneten Maßnahmen und den Einsatz einer wirklich ausgereiften Wiki-Lösung steigt der Wert des Wikis für jeden einzelnen Mitarbeiter (und damit für das gesamte Unternehmen) und es wird neuen Nutzern der Einstieg so leicht wie möglich gemacht.

Haben Sie Fragen zur Organisation Ihres Wikis oder benötigen Sie Unterstützung? Bitte nutzen Sie für Ihre Anfrage das Kontaktformular auf unserer speziellen Seite zum Thema Firmenwikis.

Weiterführende Informationen

Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen und Informationsquellen
Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann
Strategische Wikis und Unternehmenswikis im Tagesgeschäft: eine wichtige Unterscheidung

1. Strategische Wikis
2. Unternehmenswikis im Tagesgeschäft

Kurz zusammenfasst sind strategische Wikis wertvoll und politisch einfach bei der Geschäftsführung einzuführen. Tagesgeschäfts-Wikis sind dafür deutlich besser für eine hohe Mitarbeiterakzeptanz und Nutzungsintensität. Beide Ausprägungen befruchten sich gegenseitig, weshalb die meisten Unternehmen auch planen, beide Formen früher oder später zu nutzen.

Strategische Firmenwikis: Dokumentation und Wissen

Die Unternehmen, die Firmenwikis einsetzen, um strategischen Nutzen zu stiften, sind in der Mehrzahl. Vielen Unternehmen imponiert der Erfolg von Wikipedia und es entsteht der Bedarf, vorhandenes Unternehmenswissen und Informationen im Unternehmen systematisch und gemeinschaftlich zu erarbeiten, zu organisieren und zu dokumentieren. Es werden Werte geschaffen, die das Unternehmen voranbringen (Referenzmaterial, Anleitungen, Richtlinien und Prozessdokumentationen). Diese strategische Anwendung von Wikis im Unternehmen ergänzt oder ersetzt häufig bestehende oder andere geplante Wissensmanagement-Systeme.

Bewertung des strategischen Ansatzes

Vorteile:

• Hier entsteht das wirklich wertvolle Wissen für das Unternehmen.
• Die Arbeiten in diesem Bereich wirken lange nach und veraltren nicht so schnell.
• Diese Informationen sind in der Regel für sehr viele Mitarbeiter wichtig und relevant.
• Viele Unternehmen haben in diesem Bereich noch gar keine Lösung etabliert, die akzeptabel funktioniert. Auf diese Weise stößt ein Wiki in eine existierende Lücke und kann sich vollkommen und ohne Überschneidungspunkte als internes „Lexikon“ oder besser: Referenzwerk etablieren.
• Politisch ist die Einführung von einem solchen Wiki häufig vergleichbar einfach. Es gibt einfach keine Argumente dagegen – außer vielleicht ein bestehendes Wissensmanagement-System, das bisher nicht genutzt wird (häufig z.B. Microsoft Sharepoint).
• Ein solches Ziel kann vergleichsweise gut in ein Projekt gefasst und kontrolliert werden. Es wird daher häufig in Wiki-Piloten zum Einsatz gebracht.

Herausforderungen:

• Die Mitarbeiter müssen oftmals Überstunden machen, um das strategische Wiki voranzutreiben. Da die Informationen im Tagesgeschäft zwar gebraucht werden, ihre Erstellung aber nicht in Tagesgeschäftsprozesse integriert ist, sind nahezu alle Arbeiten für ein strategisches Wiki „Extra-Leistungen“. Wenn Sie als Unternehmen also einen strategischen Ansatz verfolgen wollen, dann sollten Sie sich bewusst sein, dass Sie Ihren Mitarbeitern dafür ausreichende Kapazitäten/Ressourcen einräumen müssen und dass Sie wertvolle Arbeitszeit, die sonst vielleicht auf Kundenarbeiten verwendet worden wäre, investieren müssen.
• Vielen Unternehmen ist nicht klar, dass die Redaktionsinvestition nicht von selbst entsteht, nur weil Wikis sehr leicht und schnell zu bedienen sind.
• Es ist besonders schwierig, einen strategischen Ansatz zu verfolgen, wenn man nicht die Unterstützung der Geschäftsführung hat. In diesem Bereich ist „Strong Backing from the Top“ nahezu unerlässlich.
• Es ist schwierig, die Mitarbeiter, die über das meiste Wissen verfügen, aus ihren häufig wichtigen Tagesgeschäftsaufgaben herauszuholen, um für die Dokumentation und den Wissensschatz im Unternehmen zu arbeiten. Hier ist das Fingerspitzengefühl der Projektleiter gefragt.
• Die Mitarbeiter mit dem meisten Wissen im Unternehmen sind häufig auch am stärksten ausgelastet. Hier müssen sinnvolle Lösungen geschaffen werden (z.B. Interviews durch Redakteure, die dann die Inhalte erstellen).

Tagesgeschäftswikis: Produktivität steigern und Zeit sparen

Wikis, die im Tagesgeschäft eingesetzt werden, konzentrieren sich darauf, den Anwendern einen direkten Nutzen bei ihrer täglichen Arbeit zu ermöglichen. Die Probleme, die heute Zeit kosten, und Informationen, die heute im Projekt nicht sinnvoll geteilt werden, können mit einem solchen Wiki verfügbar gemacht werden. Solche Tagesgeschäftswikis haben es häufig deutlich leichter im Unternehmen Fuß zu fassen. Diese Systeme helfen dabei, die E-Mail-Flut im Unternehmen zu reduzieren, etablieren virtuelle Arbeitsbereiche für Teams für eine bessere Zusammenarbeit und ergänzen Projektmanagement-Systeme.

Bewertung von Wikis im operativen Tagesgeschäft

Vorteile:

• Tagesgeschäftswikis entfalten Ihren Nutzen nahezu sofort.
• Gerade die Mitarbeiter, die besonders stark belastet sind, erfahren durch operative Wikis den größten Nutzen. In Zahlen ausgedrückt: Mitarbeiter, die heute drei Stunden täglich mit E-Mails und deren Bearbeitung verbringen, können mit Wikis diesen Zeitraum auf zwei Stunden verkürzen und trotzdem erreichen, was sie sonst nur in dreieinhalb Stunden erreicht hätten. Das klingt möglicherweise für den einen oder anderen wie „Schaumschlägerei“, ist in der Realität aber das schlagende Argument für den Erfolg vieler Firmenwikis.
• Ein kurzes Beispiel zur Demonstration: Ein Projekt wird mit einem Firmenwiki organisiert. Der Projektleiter erstellt eine Aufgabenliste mit Verantwortlichen. Bisher hat er nun regelmäßig alle Verantwortlichen per E- Mail angeschrieben und nach dem Status gefragt. Heute erstellt er ein zentrales Dokument mit einer Aufgabenliste. Die Mitarbeiter berichten ihren Status im Wiki. Der Projektmanager spart dadurch sehr viel Zeit und viel Abstimmungsaufwand und alle haben ständig den aktuellen Projektstand im Blick.
• Der Aufwand, um Mitarbeiter davon zu überzeugen, dass ein Wiki bei der täglichen Arbeit Zeit einsparen kann, ist verhältnismäßig gering.
• Operative Wikis sind vergleichsweise leicht und schnell bei Mitarbeitern einzuführen.
• Ein intensiv genutztes Tagesgeschäftswiki fördert auch den strategischen Ansatz. Wenn Sie die zentralen Mitarbeiter über das Tagesgeschäft häufig ins Wiki ziehen können, werden diese auch viel häufiger als sonst wertvolles Wissen, Dokumentationen und strategische Informationen dort hinterlegen.
• Die Dynamik des Wikis nimmt deutlich zu. Die Informationen darin wachsen schneller und intensiver.

Herausforderungen:

• Gerade große Unternehmen haben bereits zahlreiche Prozesse und Abläufe etabliert, deren Einhaltung wichtig ist und gefördert werden soll. Ein Wiki bildet nun viele dieser Prozesse auf andere Weise ab. Es entstehen leicht Redundanzen.
• Die klare Regelung von Hierarchien und Abläufen in Projekten und Prozessen geht im Wiki leichter verloren, weil es keine festgeschriebenen Strukturen und Vorgaben gibt. Die Mitarbeiter können dadurch verunsichert werden, dass Prozesse flexibler und offener sind. Die Anforderungen an das Wissen und die Wiki-Erfahrung der „internen Antreiber“ im Wiki-Projekt (Wiki-Champions) sind deutlich höher. Viele Unternehmen, für die Firmenwikis heute ganz neu sind, verfügen zu Beginn nicht über ausreichende Erfahrungen, Grundlagenwissen und auch Vertrauen in die Wiki-Technologie, um bereit zu sein, alte Prozesse über Bord zu werfen und dafür das Wiki einzusetzen. Hier ist ein kontrolliertes und schrittweises Vorgehen sinnvoll.
• Die höhere Dynamik von operativen Wikis steigert aber auch das Chaos-Potenzial. Wenn jeder einfach seine Inhalte einstellt, ohne auf Struktur und Vorgaben zu achten, geraten unerfahrene und neue Wiki-Nutzer häufiger in Verwirrung und scheitern beim Versuch, sich einen Überblick über das Wiki zu verschaffen.

Und jetzt? Gut nachdenken und auf ein Ziel fokussieren!

Es gibt keinen eindeutigen Weg, der zu bevorzugen ist. Wichtig ist eine Übereinstimmung Ihres Vorgehensmodells mit den Zielen Ihres Unternehmens und den Bedürfnissen der Mitarbeiter. Wir empfehlen, dass Sie sich zu Beginn auf klare und wenige Prioritäten im Wiki konzentrieren und dafür gründliche und wirklich hochwertige Lösungen entwickeln. Dann haben Sie ein erstes, strahlendes Aushängeschild, das die Möglichkeiten eines Wikis eindrucksvoll demonstriert. Ob Sie mit den strategischen Dingen anfangen und entsprechende Ressourcen bereitstellen oder lieber erst auf die Aktivität der Mitarbeiter setzen und im Tagesgeschäft beginnen, ist egal.

Für das Einfach-Durchwursteln fehlt den meisten Unternehmen und Mitarbeitern die Wiki-Vorerfahrung. Deshalb muss beides gut durchdacht und vorbereitet werden. Gerne unterstützen wir Sie hierbei.

Quellen und weiterführende Informationen

In-the-Flow & Above-the-Flow: Two Types of Wikis at Work
Unsere spezielle Seite zum Thema Firmenwikis
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Architektur eines Wiki-Projekts: Häufige Fragen von Kunden und Informationsquellen
Social-Software-Projekte: Woran die Einführung scheitern kann

Wie steht es darüber hinaus um die Weiterentwicklung von Foswiki und TWiki und was ist von den jeweiligen Marketing-Aktivitäten zu halten?

Produktentwicklung

TWiki-Entwicklung
TWIKI.NET bündelt seine verbleibenden Kräfte auf den Marketing-Bereich. Darin ist TWIKI.NET tatsächlich gut: Es gibt eine neue, moderne Website, TWiki nimmt ziemlich erfolgreich an Competions teil und erfährt vergleichsweise große Aufmerksamkeit in Blogs, es werden professionelle Videos erstellt. Doch damit hat es sich. Worauf es allerdings ankommt, ist die Software. Und hier tritt TWiki auf der Stelle. Die Weiterentwicklung wird der Foswiki-Community überlassen.

Natürlich könnte TWiki um neue Plugins, die die Foswiki-Gemeinschaft erstellt hat, erweitert werden – Foswiki ist inklusive aller Extensions Open Source, die Systeme sind kompatibel. Aber es wird bewusst darauf verzichtet, TWiki aufzuwerten. Ignoranz?

Zwar ist auf der Website von neuen TWiki-Komponenten und -Features zu lesen, doch diese sind proprietär und kostenpflichtig. Man wird seine Zweifel haben dürfen, ob diese Praxis, den Nutzern „exklusive“ Features vorzuenthalten, GPL-Lizenz-konform ist, mit der sich TWiki ja nach wie vor schmückt.

Leider sind diese zusätzlichen Funktionalitäten auch nirgends zu sehen, niemand kann sie ausprobieren oder bewerten, ohne eine Testinstallation der kommerziellen TWiki-Variante vorzunehmen. Es existieren keine Marketing-Videos zu neuen Funktionen, nicht einmal Screenshots oder ausführliche Beschreibungen. Wenn jemand von tollen Sachen spricht, sich aber weigert, sie uns zu zeigen, ist das jedenfalls alles andere als vertrauenerweckend und ein gutes Zeichen.

Meines Wissens gibt es in TWiki derzeit kein Feature, das nicht schon in der ersten Foswiki-Version verfügbar gewesen wäre. Es ist offensichtlich, dass die Weiterentwicklung von TWiki seit fast einem Jahr stillsteht.

Abb.: Zusätzliche Funktionen und Support gibt es nur in der kommerziellen TWiki-Version. Welche Features das konkret sein sollen, erfahren wir nicht. (Stand 23.10.2009)

Foswiki-Entwicklung
Innerhalb dieses Zeitraums sind indes mehr als 5.000 Entwicklerzugriffe auf den Foswiki-Code gezählt worden. Nutzer profitieren von zahlreichen neuen Plugins, von denen ich nur diese drei erwähnen möchte:

• das TopicPermission-Plugin und das SectionPermission-Plugin für das Rechte-Management einzelner Seiten
• das Autosave-Plugin, das vor Datenverlust schützt, wenn der Browser abstürzt
• das InnovationManagement-Plugin, das Unternehmen die Möglichkeit gibt, Mitarbeiter über neue Geschäftsideen abstimmen zu lassen und das Stimmgewicht dabei je nach Position im Unternehmen spezifisch einzustellen

Dies sind nur drei von vielen wirklich tollen, neuen Plugins, die samt und sonders Open Source sind. Und nicht nur das: Die Foswiki-Community hat 400 Bugs und damit Probleme behoben, von denen die allermeisten in TWiki bis heute ungelöst sind.

Marketing

TWiki
Ich habe angesprochen, dass TWIKI.NET in Sachen Marketing sehr erfolgreich ist. Die Basis dieses Erfolgs und die Grundlage dieser starken Marke bildet indes eine hervorragende Software, die über zehn Jahre hinweg auch von Foswiki-Mitgliedern entwickelt worden ist.

Jeder Leser, der ein Verständnis für das Open-Source-Konzept und den dahinterstehenden Community-Gedanken hat, wird nachvollziehen können, dass es für viele Foswiki-Entwickler etwas schmerzlich ist, das Markenrecht für eine Software, die sie über Jahre hinweg begeistert und unentgeltlich bzw. auf eigene Kosten vorangetrieben haben, nun in den Händen eines Unternehmens zu wissen. Vom erfolgreichen Marketing, das für TWiki betrieben wird, profitiert jedoch auch Foswiki. Also bitteschön, weiter so!

Das TWiki-Marketing hat allerdings eine Kehrseite: Die Kommunikation ist nicht offen und ehrlich, weder der ehemaligen Community (gegen deren Mitglieder man Drohungen mit Rechtsfolgen ausgesprochen hat), noch den Unternehmen gegenüber, die TWiki einsetzen.

Nirgends im TWiki-Umfeld wird auf Foswiki hingewiesen. Tatsächlich äußert sich TWIKI.NET Kunden gegenüber völlig unbegründet sehr negativ über Foswiki. Das ist ebenso wenig stilvoll wie professionell, sondern erweckt vielmehr den Eindruck sturen Eingeschnappt-Seins. Von dieser negativen und bedauernswerten Seite des TWiki-Marketings sollte man dringend Abstand nehmen.

Foswiki
Die gute Seite des Foswiki-Marketings: Die Community verfolgt einen zweigleisigen oder besser: ausgewogenen Ansatz. Es gibt gewiss Mitglieder wie mich selbst, die sich auch einmal aufregen oder die (wie beschrieben), ziemlich sauer auf TWIKI.NET sind, andere gehen ruhig und sachlich mit der Situation um. Es gibt Mitglieder, die viele Artikel verfassen und auch die Foswiki-Website ständig aktualisieren, andere produzieren regelmäßig Videos und Tutorials, die einerseits Marketing-Wirkung erzielen, andererseits natürlich auch den Foswiki-Nutzern helfen sollen. Die Marketing-Aktivitäten ruhen auf mehreren Schultern.

Doch die Marke Foswiki ist längst nicht so stark wie TWiki. Das wird mittelfristig sicher auch so bleiben – Foswiki hat keine Vollzeitangestellten, die sich den ganzen Tag um PR-Aktivitäten kümmern können, und keine Budgets, die 5.000-Euro-Filme zulassen. Die Marketing-Kapazitäten sind also leider noch ziemlich begrenzt, doch die Community tut, was sie kann, und wird Woche für Woche besser. Priorität genießt die Software.

Was bedeutet all das für Sie?

Der Glanz einer guten Marke bringt Ihr Unternehmen nicht voran. Ein Unternehmen, das Open-Source-Software für den Einsatz im Intranet evaluiert, muss sich auf zwei Dinge konzentrieren: das Produkt und die Community, die hinter diesem steht. Ihre Mitarbeiter, die das Wiki nutzen werden, sollen das tolle Produkt lieben lernen und jeden Tag gerne mit ihm arbeiten. Für Marketing interessieren sie sich nicht, sondern ausschließlich für eine möglichst ausgereifte Software, die ihnen dabei hilft, ihre Arbeit besser und effizienter zu erledigen.

Foswiki ist ein Open-Source-Wiki, das es in sich hat. Meiner Meinung nach sollten Unternehmen, die auf Open Source setzen, sich für Foswiki entscheiden, und Kunden, die eine TWiki-Instanz betreiben, wirklich intensiv darüber nachdenken, auf Foswiki umzusteigen – und damit auf das ausgereiftere und mächtigere System, das deutlich bessere Perspektiven hat und bietet.

//SEIBERT/MEDIA unterstützt Sie gerne dabei: Bitte sprechen Sie uns an und besuchen Sie unsere Seiten zum Thema Foswiki als Enterprise Wiki und zum Umstieg von TWiki mit weiteren ausführlichen Informationen und Kontaktmöglichkeiten.

Hinweis: Diese Ausführungen bilden die Meinung von Martin Seibert als Privatperson ab. Sie sind nicht als offizielles Statement der Foswiki-Community oder der //SEIBERT/MEDIA GmbH zu verstehen. Da ich im letzten Jahr wie die anderen ehemaligen TWiki- und heutigen Foswiki-Community-Mitglieder aus der TWiki-Gemeinschaft geworfen wurde, ist es möglich, dass mir verschiedene TWiki-spezifische Aspekte entgangen sind. Es wäre toll, wenn Sie weitere und neue Informationen zum Thema beisteuern könnten. Bitte nutzen Sie hierfür die Kommentarfunktion unten.

Weiterführende Informationen

TWiki: Good Marketing, strong Brand, poor Product, no Community
TWiki-Fork: Community spaltet sich ab und entwickelt Foswiki
Foswiki 1.0 ist erschienen (Pressemeldung)
Unsere spezielle Seite zum Thema Foswiki: Foswiki als Enterprise Wiki – lizenzkostenfrei und vollständig anpassbar (inkl. Vodcast)
Unsere spezielle Seite zum Thema TWiki: Wie geht es weiter mit Ihrer TWiki-Instanz?

Dies vorweg: Ich bin, wie regelmäßige Leser des //SEIBERT/MEDIA-Blogs vielleicht wissen, selbst Mitglied der Foswiki-Gemeinschaft. Deshalb mag man mir eine gewisse Befangenheit vorwerfen, bitteschön: In der Tat bin ich ein großer Foswiki-Fan. Doch ich bin auch weit davon entfernt, die Software TWiki zu verdammen, im Gegenteil: //SEIBERT/MEDIA selbst hat vor dem Umstieg auf Foswiki TWiki erfolgreich eingesetzt, mit gutem Gewissen haben wir Unternehmen TWiki als Firmenwiki empfohlen und zahlreichen Kunden bei der Einführung geholfen.

Ich habe nicht die Intention, TWiki-Bashing zu betreiben, sondern die, einen aktuellen Vergleich zu ziehen. Wie Sie (sofern Sie über eine Wiki-Einführung nachdenken oder bereits ein Enterprise Wiki betreiben) bin auch ich in erster Linie am bestmöglichen Produkt interessiert. Und hier geht Foswiki als klarer Sieger vom Platz, wie ich in diesem und im folgenden Artikel begründen werde. Innerhalb eines Jahres hat sich nämlich viel getan.

Thesen: Deshalb ist Foswiki TWiki voraus

Dies sind meine Thesen, die ich anschließend en detail ausführe:

• TWIKI.NET betreibt ausgezeichnetes Marketing, TWiki ist Foswiki markentechnisch weit voraus. Die Begeisterung der Mitarbeiter für ein System kann man aber nicht kaufen. Tolles Marketing des amerikanischen Software-Vermarkters „verwandelt“ sich nicht in etwas, das Sie in Ihrem Unternehmen wirklich benötigen.
• TWiki hat fast keine Produktentwicklung und keine Community. Doch genau darauf kommt es an: Sie benötigen ein gutes Produkt, kein cooles Marketing. Sie brauchen Programmierer, die neue Lösungen und innovative Plugins entwickeln. Eine Open-Source-Software lebt von einer aktiven und ambitionierten Community und braucht diese, um sich weiterzuentwickeln.
• Foswiki hat eine starke Produktentwicklung und eine starke Community. Das ist für Sie als Unternehmen entscheidend. Von der Twiki-Gemeinschaft hingegen ist so gut wie nichts übriggeblieben, nahezu das gesamte Team ist heute im Foswiki-Projekt aktiv.

Community-Aktivitäten

TWiki
Eines wird gerne vergessen: Die Menschen, die hinter einem Produkt stehen, sind am wichtigsten für den langfristigen Erfolg. Im Open-Source-Bereich gibt es keine Produktentwicklung und keine Innovation ohne eine Community.

Im Oktober 2008 hat sich die Community aus dem TWiki-Projekt zurückgezogen und Foswiki ins Leben gerufen. Übrig sind TWIKI.NET-Chef Peter Thoeny und seine Angestellten. Das Resultat: Community-Aktivitäten finden heute offenbar so gut wie gar nicht mehr statt.

Ganz ehrlich: Das ist schade. Ich fände es prima, wenn stattdessen eine aktive TWiki-Community am Start wäre, die mit der Foswiki-Gemeinschaft um das bessere Produkt wetteifern würde – die Nutzer könnten davon nur profitieren. Leider ist das anders und wenn sich daran nicht zügig etwas ändert, wird TWiki „dank“ der Untätigkeit in Sachen Weiterentwicklung schließlich von der Bildfläche verschwinden.

Doch tatsächlich unternimmt TWIKI.NET erhebliche Anstrengungen, um eine neue Community zu verhindern. Ein Beispiel: Wenn Sie sich die Download-Seite des Open-Source-Produkts (!) TWiki einmal genauer ansehen, zählen Sie nicht weniger als elf Hinweise auf den „Rechteinhaber“ TWIKI.NET. Bevor Sie den Download starten konnten, mussten Sie bis vor kurzem ein umfangreiches Formular ausfüllen – inzwischen kann dieser Schritt übersprungen werden. Tun Sie dies nicht, gehen Ihre Daten an wen? Korrekt. Das Produkt und das Unternehmen TWIKI.NET sind inzwischen untrennbar miteinander verwoben.

Abb.: Die Download-Seite für das Open-Source-Produkt Twiki (Stand: 23.10.2009)

Dies ist kein Umfeld, in dem professionelle Berater oder Entwickler in einer Community aktiv werden möchten bzw. können. Und das geschieht meiner Interpretation nach auch genau aus diesem Grund: um nämlich sicherzustellen, dass sich keine selbstbewusste Gemeinschaft mit professionellen Strukturen entwickelt. TWIKI.NET hat in politischer Hinsicht mit einer solchen ja zuletzt keine sehr guten Erfahrungen gemacht.

Foswiki
Die Foswiki-Community ist stark – gerade eben ist ein unabhängiger Verein gegründet worden, die Foswiki Association. Die Foswiki-Gemeinschaft ist demokratisch und vollkommen unabhängig von kommerziellen Interessen. Und vor allem: Die Wiki-Entwicklung macht den Community-Mitgliedern wieder Spaß. Das ist es, was Projekte wie Foswiki vorwärtskommen lässt. Eine gute, aktive und lebendige Community ist die Basis jeden Open-Source-Projekts.

Im folgenden Artikel TWiki, Foswiki und der Stand der Dinge ein Jahr nach dem Fork: Produktentwicklung und Marketing gehe ich darauf ein, ob und wie die Systeme vorangetrieben werden und welche Marketing-Aktivitäten TWIKI.NET und die Foswiki-Community entfalten bzw. was davon zu halten ist.

Hinweis: Diese Ausführungen bilden die Meinung von Martin Seibert als Privatperson ab. Sie sind nicht als offizielles Statement der Foswiki-Community oder der //SEIBERT/MEDIA GmbH zu verstehen. Da ich im letzten Jahr wie die anderen ehemaligen TWiki- und heutigen Foswiki-Community-Mitglieder aus der TWiki-Gemeinschaft geworfen wurde, ist es möglich, dass mir verschiedene TWiki-spezifische Aspekte entgangen sind. Es wäre toll, wenn Sie weitere und neue Informationen zum Thema beisteuern könnten. Bitte nutzen Sie hierfür die Kommentarfunktion unten.

Weiterführende Informationen

TWiki: Good Marketing, strong Brand, poor Product, no Community
TWiki-Fork: Community spaltet sich ab und entwickelt Foswiki
Foswiki 1.0 ist erschienen (Pressemeldung)
Unsere spezielle Seite zum Thema Foswiki: Foswiki als Enterprise Wiki – lizenzkostenfrei und vollständig anpassbar (inkl. Vodcast)
Unsere spezielle Seite zum Thema TWiki: Wie geht es weiter mit Ihrer TWiki-Instanz?

Worauf basiert das Miteinander?

Die Entscheidung des Bauern, seine Waren vor die Tür zu stellen und eine Kasse des Vertrauens zu installieren, ist vergleichbar mit dem Wechsel von einem klassischen Intranet zu einem Unternehmenswiki. Dieser bedeutet nämlich, dass das Bitte-klingeln-Schild abmontiert und durch ein Herzlich-willkommen-Banner ersetzt, die Tür aufgesperrt und die Einladung zur Mitwirkung ausgesprochen wird.

In einem Wiki kann jeder Mitarbeiter mitarbeiten: Jedes Dokument, das ich angelegt habe, kann jeder Kollege, der Zugang zum entsprechenden Wiki-Bereich hat, verändern. Das Unternehmen, das ein Wiki einführt, gibt damit sowohl Mitarbeitern als auch Kunden (die z.B. über ein Extranet auf Wiki-Basis integriert sind) einen hohen Vertrauensvorschuss bzw. sehr viel Macht über die „Transaktion“, um beim Beispiel des Einkaufs beim Bauern oder im Supermarkt zu bleiben.

Wie der Hofladen mit der Kasse des Vertrauens verfolgt ein Wiki einen sehr offenen Ansatz. Letztlich gelangen wir damit auch zu der Frage, wie Menschen funktionieren, die sich auch unser Bauer stellt, der sein Geschäftskonzept durchdenkt: Basiert das Miteinander auf Solidarität und Ehrlichkeit oder auf Kontrolle und Misstrauen?

Sind wir in dieser Hinsicht pessimistisch, werden wir dem Bauern davon abraten, seine Äpfel und Kartoffeln vor die Tür zu stellen und abzuwarten, ob die Leute bezahlen. Wir gehen davon aus, dass er seine Waren ungewollt verschenkt, dass die Leute den Kofferraum füllen und sich aus dem Staub machen, ohne die Kasse des Vertrauens eines Blickes zu würdigen. Als Optimisten vertrauen wir hingegen darauf, dass die Kunden die Waren, die sie mitnehmen, auch bezahlen und das Vertrauen nicht missbrauchen werden.

Zugegeben: Im Falle des Bauern sind Sorgenfalten eher angebracht als bei einem Unternehmen, das mit einem Wiki eine Kultur der Offenheit schafft. Gerade habe ich bewusst Äpfel mit Birnen verglichen.

Im Firmenwiki stiehlt niemand Kartoffeln

Der erste entscheidende Unterschied besteht darin, dass nicht einfach ein Internet-Nutzer im Firmenwiki vorbeikommen und dort Schaden anrichten kann. Auf das Wiki haben ausschließlich autorisierte Mitarbeiter bzw. Kunden Zugriff. Der zweite Unterschied ergibt sich aus der Natur eines Wikis: Im Unternehmenswiki gibt es keine Anonymität.

Das System verzeichnet jede Aktivität, ein professionelles Wiki-System wie Confluence oder Foswiki hält fest, wann und an welchem Ort es welche Modifikation durch wen gegeben hat. Habe ich ein Thema abonniert, werde ich via RSS oder E-Mail automatisch über Änderungen informiert.

Fakt ist: Wenn jemand (im übertragenen Sinne) einen Kartoffelsack einfach mitnimmt, erfahre ich das. Insofern ist das Wiki der offene Verkaufsstand des Bauern mit Überwachungskameras. (Aus diesem Grund ist es beispielsweise sinnlos, als Unternehmen darüber nachzudenken, ein Wiki „abzusperren“ und etwa dem Gros der Nutzer keine Schreibrechte einzuräumen. Damit würde lediglich das klassische, weitgehend statische Intranet-Portal kopiert und das Wiki-Konzept käme nicht zur Entfaltung.)

Vertrauen und Offenheit zahlen sich aus

Der Wikipedia-Gründer Jimmy Wales wurde einmal gefragt, welche Entwicklung seine Idee hinter sich hätte. Konzeptionell, so Wales darauf, sei der Wikipedia-Vorläufer Nupedia mit einem ziemlich seltsamen Restaurant vergleichbar gewesen:

In einem Restaurant nutzen Gäste Messer, um ihre Speisen mundgerecht zu portionieren. Der Restaurant-Leitung indes ist dies nicht geheuer: Sie befürchtet, dass Gäste, die unbeaufsichtigt mit Messern hantieren, zwangsläufig aufeinander losgehen und sich verletzen; so sei der Mensch eben und es bedürfe drastischer Beschränkungen.

Folglich wird jeder Tisch auf „todsichere“ Weise von allen anderen abgeschirmt und mit Gittern gesichert: In ihren Käfigen können Gäste dann essen und Messer benutzen, ohne anderen Leuten gefährlich zu werden.

Die Auswirkungen lassen nicht allzu lange auf sich warten und trotz der hervorragenden Karte ist das Restaurant bald verwaist – Käfige sind unromantisch und sorgen auch in jeder anderen Hinsicht für Abschreckung.

So charakterisiert Jimmy Wales Nupedia und begründet anhand dieses gescheiterten Konzepts das radikale Umdenken, das Wikipedia schließlich so erfolgreich gemacht hat: Jeder kann mitmachen, alle sind willkommen. Im Gegensatz zum Vorläufer-Projekt basiert Wikipedia nicht auf Misstrauen, sondern auf Vertrauen in das Gute im Nutzer, und ist deshalb eine so beispiellose Erfolgsgeschichte.

Dies ist der Kern des Wiki-Konzepts. Und während der Bauer trotz allen Mutes und trotz aller Innovationskraft verständlicherweise einige Zweifel an der Kultur der Offenheit hegen mag und mit sich ringen muss, hat das Unternehmen, das über eine Wiki-Einführung nachdenkt, keine zwielichtigen Umtriebe zu befürchten: Es kann nur gewinnen und wird von den Vorteilen einer „lebenden“, aktuellen, organisch wachsenden Wissensbasis im Intranet profitieren, in der eine unglaubliche Vielzahl von Prozessen abgebildet werden kann.

Weiterführende Informationen

Wikis sind der Kitt, der Intranets zusammenhält
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?
Social-Software-Projekte: Woran die Einführung von Enterprise-2.0-Tools scheitern kann

Bei einer Autofahrt durch eine ländliche Gegend kam ich vor einiger Zeit an einem hübschen Bauernhof vorbei. Draußen standen die bekannten Tafeln mit Kreideaufschriften wie „Blumen“, „Kartoffeln“, „Süße Äpfel“, „Süßmost“, „Pflaumen“, „Zwiebeln“ und dergleichen. Die Aufschriften mit kräftigem Strich sahen neu und akkurat aus und hatten offenbar nicht bereits Wochen bei Wind und Wetter im Freien hinter sich, sondern waren erst kürzlich erneuert worden. Leider war das Tor zum Hof verschlossen, am Zaun stand ein Schild mit der Aufforderung, bitte zu klingeln.

Das ist ein großes Problem: Möchte ich etwas kaufen, muss ich eine Klingel betätigen, jemand wird öffnen und mich wahrscheinlich fragen, was ich gerne hätte, oder mich in einen kleinen Verkaufsraum im Haus führen. Was mich daran stört und mich davon abhält, hier zu klingeln, ist die sehr hohe Verbindlichkeit: Angenommen, der Korb Äpfel, den der Bauer mir zeigt, bietet einen recht ernüchternden Anblick und ich will ihn eigentlich gar nicht haben – gewissermaßen bin ich trotzdem „gezwungen, zu kaufen“.

Ich hätte angehalten, geläutet, meinen Wunsch vorgetragen und den Bauern dazu bewegt, mir seine Produkte zu zeigen, ohne zu wissen, ob die angebotenen Waren überhaupt meinen Vorstellungen entsprechen. Dadurch würde ich mich in der Pflicht fühlen und am Ende die Äpfel vermutlich trotz meiner Bedenken kaufen. Kurz: Die „Transaktionskosten“ sind mir zu hoch erschienen und ich bin weitergefahren.

Anders stellt sich die Situation im Supermarkt dar: Ich kann hineingehen, mir alle Waren in Ruhe anschauen und das Geschäft wieder verlassen, ohne etwas zu kaufen. Diese Handlung ist anonym, die Türen stehen mir in beide Richtungen offen. Das Geschäft mit dem Bauern indes wäre, wie beschrieben, alles andere als anonym und vor allem nicht gerade unkompliziert.

„Bitte klingeln“ heißt es auch in vielen Intranets.

Auch in vielen Intranets heißt es: „Bitte klingeln!“ Einem Mitarbeiter, der eine Änderung oder eine Aktualisierung vornehmen und sein Wissen zentral speichern möchte, gelingt dies leider selten sofort und auf effiziente Weise: Vielleicht muss er sich an die IT-Abteilung wenden, um Zugriffsrechte zu erhalten, vielleicht muss er seine Änderung zusammen mit der Bitte um Einstellung einem Redakteur per E-Mail schicken, vielleicht landet die Änderung auch erst einmal auf dem Stapel „Inhalte für das nächste Content-Update“ und fängt eine Weile Staub.

Zunächst ist die Tür also geschlossen. Ebenso wie der Bauer höchstwahrscheinlich nicht über zu hohen Kundenandrang klagen muss, aktualisiert und erweitert kaum jemand die Inhalte im Intranet. Während der Bauer Ersteres womöglich verkraften kann, da er – um die Geschichte weiterzudenken – seinen Umsatz vor allem durch Lieferungen an einen Großhändler generiert, ist ein Intranet, in dem Informationen veralten und das niemand nutzt, verschwendetes Geld. Wie kann man das ändern?

Was offene Türen und eine Kasse des Vertrauens bewirken

Nehmen wir nun an, der Hofumsatz ist dem Bauern plötzlich gar nicht mehr egal, denn sein großer Kunde hat sich für einen anderen Lieferanten von Bio-Produkten entschieden: Es ist also höchste Zeit, den Direktverkauf anzukurbeln.

Eine Möglichkeit bestünde darin, die Tür grundsätzlich zu öffnen und die Bitte-klingeln-Tafel durch ein Herzlich-willkommen-Schild zu ersetzen. Mit einem Schlag würden die Transaktionskosten für potenzielle Kunden sinken. Die Tür generell aufzusperren und allen Mitarbeitern Zugang zu gewähren, wäre auch im Intranet ein richtiger erster Schritt.

Der Bauer hätte noch eine zweite Möglichkeit, die auf den ersten Blick deutlich radikaler erscheint. Er könnte seine Äpfel, Kartoffeln, Zwiebeln, Sträuße und Mostflaschen auf einem Tisch vor der Tür aufbauen, Preisschilder danebenstellen und eine blecherne Kasse des Vertrauens an einen Zaunpfahl nageln.

Wie dramatisch sich die Situation für mich damit ändern würde! Ich könnte anhalten, mir die Waren ansehen, einen Sack Kartoffeln oder eben einen Korb Äpfel nehmen, den ausgezeichneten Betrag in die Box werfen und weiterfahren, ohne dem Bauern zu begegnen. Ebenso könnte ich aber auch wieder einsteigen und meine Fahrt fortsetzen, ohne etwas zu kaufen und ohne schlechtes Gewissen. Meine Transaktionskosten wären in diesem Fall sogar noch geringer als im Supermarkt, wo ich mir einen Einkaufswagen nehmen, mich an der Kasse anstellen, meine Waren auf das Band legen muss etc. Beim Bauern dagegen wäre die Transaktion allein mir als Kunden überlassen.

Die Vorteile überwiegen die Risiken

Damit sind wir jedoch bei Kehrseite der Medaille: Der Bauer befürchtet nämlich, wahrscheinlich nicht unbegründet, dass Leute sich Waren einladen und auf Nimmerwiedersehen verschwinden könnten, ohne dafür zu bezahlen. Vielleicht wird dieser Fall tatsächlich ab und zu eintreten und der Bauer höchstens einen Manschettenknopf (und keine Münzen) in seiner Kasse vorfinden.

Doch Gefahren dieser Art bestehen auch im Supermarkt, denken wir an Kreditkartenmissbrauch, denken wir an eine gestohlene EC-Karte und die Zahlung per Karte und Unterschrift oder schlichten Diebstahl. Auch hier bleibt der Supermarkt auf seiner Forderung sitzen, auch für den Supermarkt besteht das Risiko von Rücklastschriften.

Dennoch sollte der Bauer sich für diesen Schritt entscheiden: Denn trotz der Gefahr, hin und wieder übers Ohr gehauen zu werden, bin ich fest davon überzeugt, dass sein Umsatz deutlich steigen und sich seine Entscheidung langfristig lohnen wird.

Warum diese Entscheidung mit dem Wechsel von einem klassischen Intranet zu einem Firmenwiki vergleichbar ist, lesen Sie im zweiten Teil des Artikels Hofläden, Supermärkte und Firmenwikis: Misstrauen vs. Offenheit.

Weiterführende Informationen

Unsere spezielle Seite zum Thema Firmenwikis
Wikis sind der Kitt, der Intranets zusammenhält
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Wiki-Studie: Wer nutzt Wikis und warum?

Das EC-M Beratungszentrum Elektronischer Geschäftsverkehr Mittelhessen veranstaltet am 13.11.2009 von 9:30 bis 12:30 Uhr gemeinsam mit der ita – IT-Akademie Hessen und dem IHK-Verbund Mittelhessen eine Informationsveranstaltung zum Thema „Wikis in Unternehmen: Was macht Wikis für Unternehmen so wertvoll?“

Referent ist Wiki-Experte Martin Seibert, Geschäftsführer der //SEIBERT/MEDIA GmbH und Head of Marketing der Foswiki-Community.

Die Veranstaltung findet im IHK-Plenarsaal, IHK Gießen-Friedberg, Lonystraße 7, 35390 Gießen statt. Interessierte Hörer sind herzlich eingeladen. Aufgrund der begrenzten Kapazitäten ist eine kurze Online-Anmeldung bis zum 11.11.2009 nötig. Hier geht’s zum Formular.

Firmenwikis: Praxisrelevante Informationen für Unternehmen

Social Software in Unternehmen ist in, Begriffe wie Enterprise 2.0 fallen inzwischen inflationär und Buzzword-artig. Insbesondere Firmenwikis sind im Kommen und ihr Nutzen längst unbestritten: Laut einer Schätzung der Society for Information Management’s Advanced Practices Council (APC) setzen bereits 50% aller Unternehmen Wikis im Intranet ein.

Ein Firmenwiki verwaltet vorhandenes Wissen zum Vorteil aller Mitarbeiter und des gesamten Unternehmens und bildet einen Wissenspool, der ständig erweitert werden kann. Die Möglichkeit der gemeinsamen Bearbeitung von Dokumenten und Projekten im Wiki fördert die Teamarbeit und führt zur effektiven Einsparung von Arbeitszeit und Kosten. Dazu trägt auch die damit einhergehende Reduzierung des E-Mail-Aufkommens bei.

Unternehmen, die über Social Software und über eine Wiki-Einführung nachdenken, sind in erster Linie an konkreten, praxisrelevanten Informationen interessiert. Sie möchten wissen, wie sich der Wiki-Einsatz im Einzelfall auswirkt und welche Aspekte erfolgskritisch sind.

Die Veranstaltung soll Wiki-Interessierten eine ausführliche Einführung geben und Unternehmen Perspektiven aufzeigen. Neben den Vorteilen von Firmenwikis gegenüber klassischen (statischen) Intranets werden leistungsfähige Tools, Auswirkungen von Wikis auf Kosten und Ressourcen sowie Erfolgsfaktoren und auch Gefahren bei der Einführung dargestellt.

Thematische Schwerpunkte der dreistündigen Veranstaltung sind unter anderem:

• das Wiki-Konzept und Vorteile für Unternehmen durch Firmenwikis
• Open-Source- und kommerzielle Wiki-Software für den Einsatz im Unternehmen
• Evaluation von Foswiki, TWiki, MediaWiki, Confluence und anderen Systemen
• die Veränderung der internen Kommunikationskultur und ihre Vorteile
• der Wikipedia-Irrtum und das Missverständnis, im Intranet eine Online-Enzyklopädie abbilden zu wollen
• der Return on Investment von Wikis und aktuelle Forschungsergebnisse
• Einführungsstrategien und Maßnahmen zur Mitarbeiteraktivierung
• Design und Usability als erfolgskritische Faktoren
• Anwendungsfälle und Praxisbeispiele

Die Veranstalter und Martin Seibert freuen sich auf Ihren Besuch am 13.11.2009 im IHK-Plenarsaal in Gießen von 9:30 bis 12:30 Uhr.

Weiterführende Informationen

Anmeldung per Online-Formular
Pressemitteilung zur Veranstaltung
Unsere spezielle Seite zum Thema Firmenwikis
Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln

7. Zu frühes Einbinden aller denkbaren Abteilungen

Schnell kommt es zu bürokratiebedingtem Stillstand, wenn zu früh sämtliche Abteilungen im Unternehmen einbezogen werden und entscheidungsberechtigt sind. Vor allem in großen Unternehmen droht die Gefahr, dass sich unterschiedliche Interessengruppen gegenüberstehen, die der jeweiligen Profilierung mehr Gewicht beimessen als der Lösung von Problemen mithilfe eines Kollaborations-Tools. Die sich hauptsächlich damit beschäftigen, Regeln und Abläufe festzulegen, und sich dabei in Details verlieren.

8. Nicht auffindbares Wissen

Zentral verfügbares Unternehmenswissen ist eine Sache, eine unüberschaubare Datensammlung eine andere. Hieran entscheidet sich der Nutzwert, den ein Mitarbeiter aus einem System ziehen kann. Es genügt also nicht, dass Informationen eben vorhanden sind, sie sollen auch auffindbar sein. Einerseits liegt es am Unternehmen, dies bei der Wahl des Tools zu berücksichtigen (Gibt es eine Suchfunktion und wie gut sind die Ergebnisse? Wie ausgereift ist die Möglichkeit, Inhalte hierarchisch abzubilden? etc). Andererseits müssen die Nutzer des Systems verstehen, wie wichtig und sinnvoll es ist, Content in Hierarchien abzulegen, Dokumente mit aussagefähigen Titeln zu versehen, Tags zu vergeben usw.

9. Mangel an effektiven Teilnehmern

Wenn Mitarbeiter im Unternehmen das neue System als (fixe) Idee der Geschäftsführung ansehen und keine Identifikation mit dem Tool aufbauen, werden sie es nicht nutzen. Die Geschäftsführung muss den Mitarbeitern aktiv kommunizieren, dass ein Tool nicht etwa aufgrund eines persönlichen Spleens eingeführt wird, sondern dass es das Unternehmen und jeden einzelnen Kollegen grundsätzlich voranbringt und entlastet und warum das so ist. Die Entwicklung einer Strategie, potenzielle Teilnehmer zu aktivieren, ist ein fester Bestandteil eines professionellen Social-Software-Projekts und der wirklich kritische Faktor, mit dem das Projekt steht oder fällt.

10. Keine langfristige Haushaltsplanung

Unternehmen sollten sich dessen bewusst sein, dass immer wieder Bedarf an internen oder externen Ressourcen anfallen wird. Nur eine weitsichtige Planung und das Einkalkulieren zusätzlicher Investitionen sichern den langfristigen Erfolg eines Enterprise-2.0-Projekts. Jedes Tool benötigt Pflege, neue Plug-ins sind zu implementieren, gegebenenfalls müssen Mitarbeiter geschult werden, um neue, zusätzliche Funktionalitäten zu beherrschen usw.

11. Bisher Verantwortliche werden nicht integriert

In klassischen Intranets gibt es in der Regel einige wenige Mitarbeiter, die über das Firmenwissen „wachen“. Werden diese Kollegen nicht in die neue Informations- und Kommunikationskultur einbezogen und wird ihnen nicht deutlich, dass die Wissensteilung z.B. in einem Firmenwiki einen Gewinn und keinen Verlust darstellt, versuchen sie unter Umständen, die Etablierung des neuen Tools zu behindern. Die unbegründete Angst, Wissen zu teilen, kann mit konsequenter, geduldiger Kommunikation beseitigt werden.

12. Fehlende Geduld

Erfahrungsgemäß kann es lange dauern, bis ein Social-Software-Projekt zum durchschlagenden Erfolg wird, bis sich Gewohnheiten ändern und bis Mitarbeiter neue, innovative Arbeitsmethoden annehmen. Es ist so gut wie unmöglich, einen konkreten Zeitkorridor zu benennen, in dem sich beispielsweise ein Wiki durchsetzt.

Allein der unternehmenskulturelle Wandel braucht Zeit. Hier ist vorrangig das Management gefordert: Es muss den richtigen Weg zu finden, die Mitarbeiter für ein neues Tool zu begeistern und sie zur Nutzung zu motivieren. Wissen Mitarbeiter nicht, wozu ein System eigentlich konkret dient bzw. welche Prozesse es optimieren oder gar ersetzen und welche Probleme es lösen soll, gerät das Projekt unweigerlich in eine Sackgasse.

Kommen dann z.B. noch eine schlechte Usability oder eine halbherzige Integration (durch die das Tool wie ein Fremdkörper innerhalb des Intranets wirkt) hinzu, besteht die Gefahr, dass die meisten Mitarbeiter an den „bewährten“ Arbeitsmethoden wie der E-Mail als Hauptkommunikationsmittel im Unternehmen festhalten.

Der Identifikation und der konsequenten Behebung solcher Hindernisse kommt große Bedeutung zu. Auch ein System, das zunächst schleppend oder gar nicht in die Gänge kommt, kann zu einem Erfolg werden, wenn man erkannte Hemmschwellen nachträglich beseitigt.

//SEIBERT/MEDIA unterstützt und berät Sie gerne bei der Evaluation von Systemen, bei der Einführungsplanung sowie während der ersten aktiven Schritte mit Ihrem neuen System. Wenn Sie Fragen haben, nehmen Sie bitte Kontakt mit uns auf oder besuchen Sie unsere spezielle Seite zum Thema Firmenwikis.

Weiterführende Informationen

Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Social Software: Der Wikipedia-Irrtum
Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?
Micro-Blogging: Argumente für das Twittern im Unternehmen
Micro-Blogging im Unternehmen: Potenziale und Anwendung am Beispiel des //SEIBERT/MEDIA-Micro-Blogs

Und trotzdem ist die Einführung eines kollaborativen Tools selten ein Selbstläufer (zumal mit dieser ein nicht unbeträchtlicher Wandel der Kommunikationskultur im Unternehmen verbunden ist). Woran und warum können Social-Software-Projekte also scheitern? In diesem und im folgenden Beitrag nennen wir 12 Gründe, die unter anderem auf den Überlegungen von Dion Hinchcliffe basieren.

1. Eine Lösung erfüllt nur die Bedürfnisse einer Abteilung

Häufig werden Lösungen „von unten“ und zunächst in einer einzelnen Abteilung implementiert. Für die Belange eben dieser Abteilung mag das entsprechende Tool auch gut geeignet sein. Wenn sich das System aber nicht an den Bedürfnissen des gesamten Unternehmens orientiert, wird die Ausweitung schwierig. Bereits in einer Abteilung vorhandene Lösungen sollten deshalb intensiv daraufhin geprüft werden, ob und inwieweit sie sich für einen flächendeckenden Rollout im Unternehmen eignen. Häufig ist das nämlich nicht oder nur bedingt der Fall.

2. Zuerst wird das Tool ausgewählt

Manche Unternehmen begehen den Fehler, das Pferd von hinten aufzuzäumen, und wählen ein Tool aus, ohne dass ein konkreter Bedarf für die Nutzung besteht. Anschließend wird viel Mühe darin investiert, Standardlösungen im Nachhinein an die tatsächlichen Anforderungen des Unternehmens anzupassen, was häufig nicht gelingt. Auch eine Studie von Jakob Nielsen bestätigt dies: Voraussetzung für die erfolgreiche Einführung eines Tools ist deren tatsächliche Notwendigkeit. Wenn das System dabei hilft, ein vorhandenes Problem zu lösen, lernen die Mitarbeiter auf „natürliche“ Weise, es zu nutzen. Löst es dagegen offensichtlich keine Probleme, wird es scheitern.

3. Das falsche Tool wählen und krampfhaft daran festhalten

Wenn Unternehmen sich sehr früh für ein bestimmtes System entscheiden, stellt sich während des Prozesses der Etablierung und Anpassung mitunter heraus, dass das Tool nicht uneingeschränkt geeignet ist und nicht alle bestehenden Anforderungen erfüllt. Obwohl hier eigentlich eine Kursänderung nötig wäre, sieht man davon ab und versucht stattdessen, das gewählte System dennoch auf Biegen und Brechen durchzusetzen.

Die Gründe hierfür sind vielfältig: Mal ist die Bedarfsermittlung nicht intensiv genug durchgeführt worden, mal wurden potenzielle Lösungen nicht gründlich evaluiert. Wenn sich herausstellt, dass eine Software ungeeignet ist, scheuen Unternehmen womöglich auch die Mehrkosten, die durch ein Umschwenken entstehen würden (und bedenken dabei nicht, dass ein gescheitertes Projekt das Unternehmen letztlich noch teurer zu stehen käme und die Probleme, die das Tool beheben soll, nach wie vor bestünden). Zudem spielen persönliche Vorlieben und Ressentiments von Führungskräften für oder gegen eine Software gerne eine unrühmliche Rolle, insbesondere dann, wenn diese an der Unternehmensrealität und den tatsächlichen Bedürfnissen vorbeigehen. In jedem Fall werden die Akzeptanz und die Nutzung des Tools leiden.

4. Keine Ressourcen für Einführung und Schulung

Zur erfolgreichen Einführung eines Enterprise-2.0-Tools gehört mehr als das Zur-Verfügung-Stellen einer geeigneten Plattform. Wenn Unternehmen es versäumen, den Mitarbeitern eine „Bedienungsanleitung“ an die Hand zu geben, werden daraus große Probleme im Hinblick auf die Akzeptanz resultieren: Auch die beste Usability bringt nicht viel, wenn die Mitarbeiter das Konzept nicht verstanden haben, für das ein Tool steht.

Die intensive Aufklärung der Mitarbeiter über die Funktionsweisen des Systems, über die notwendige Veränderung der Kommunikationskultur und über die Vorteile für jeden Einzelnen und für das ganze Unternehmen kann schon in der Anfangsphase viele Barrieren beseitigen. Eine Einführung nach dem Motto „Hier ist das System, nun fangen Sie mal an!“ gelingt in den seltensten Fällen.

5. Keine Unterstützung „von oben“

Immer wieder beruht die Einführung eines Kollaborations-Tools auf der Initiative der IT-Abteilung – und das Management interessiert sich nicht wirklich für das System. Die mangelnde Beteiligung der Geschäftsführung ist mit einem hohen Risiko verbunden. Nichts gegen das Graswurzelkonzept, aber ohne Unterstützung und Förderung „von oben“ wird sich ein Tool schwer auf breiter Ebene durchsetzen können.

6. Fehlende Beteiligung der IT-Abteilung

Das andere Extrem ist die fehlende oder mangelnde Integration der IT-Experten in das Projekt. Dabei spielen gerade die Planung und die Anpassung an die interne Infrastruktur eine wichtige Rolle für das Gelingen des Projekts. Treten hier Probleme und Verzögerungen auf, kommt es auch zu Problemen und Verzögerungen bei der Annahme des Systems und der Mitarbeiterbeteiligung.

Im zweiten Teil des Artikels werden sechs weitere Hindernisse beschrieben, die erfolgreichen Social-Software-Projekten im Weg stehen.

Weiterführende Informationen

Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln
Unsere spezielle Seite zum Thema Firmenwikis
Social Software: Der Wikipedia-Irrtum
Micro-Blogging: Argumente für das Twittern im Unternehmen
Micro-Blogging im Unternehmen: Potenziale und Anwendung am Beispiel des //SEIBERT/MEDIA-Micro-Blogs

In der Cafeteria eines Unternehmens trinken die Mitarbeiter Kaffee und unterhalten sich. Auf den ersten Blick scheint dies ein unproduktives “Zeit-miteinander-Verbringen” zu sein. Bei näherer Betrachtung wird aber deutlich, dass es sich dabei um einen wichtigen Bestandteil der Arbeit handelt: Die Leute kommunizieren, ventilieren und analysieren Fragen aus Projekten, thematisieren ihre tägliche Arbeit und geben sich gegenseitig Tipps. Weitsichtige Unternehmen haben daher ein Interesse daran, dass es diese Kommunikation in der Cafeteria gibt und sehen in ihr einen großen Nutzen.

Nicht jedes Unternehmen kann freilich eine eigene Cafeteria anbieten, es gibt allerdings Möglichkeiten, ähnliche Kommunikationsformen digital abzubilden: Eine vielversprechende Lösung ist ein Micro-Blog. Hier werden, ganz ähnlich wie beim gemeinsamen Kaffeetrinken, Informationen, Nachrichten, Ideen oder Projektdetails ausgetauscht. Teilweise sind diese unmittelbar und zeitnah relevant, teilweise geht es darum, Gedanken einfach einmal mit anderen Leuten zu teilen und Input zu erhalten. Davon können Unternehmen profitieren.

Vorteil: Effektivere Kommunikation

Der große Vorteil des Micro-Bloggings ist die Vervielfachung des Vier-Augen-Prinzips und damit eine Qualitätssteigerung im Unternehmen. Im Idealfall verläuft die Kommunikation im internen Micro-Blog in etwa so: Mehrere Leute denken kurz über eine Idee nach und geben ihre kompakten Kommentare ab, ehe sie sich wieder ihren eigenen, individuellen Aufgaben widmen. Der Erfolgsfaktor ist die Effektivität der internen Kommunikation, die Möglichkeit, schnell breitgefächertes Feedback aus vielen Perspektiven zu generieren.

Der Micro-Blog von //SEIBERT/MEDIA ist seit einigen Monaten implementiert und basiert auf status.net (vormals Laconica). Inzwischen haben sich mehrere Anwendungsfälle für das Micro-Blogging im Unternehmen als sinnvoll erwiesen:

• Statusberichte über persönliche Verfügbarkeit („Bereichsleiter ist den ganzen Tag bei einem Kunden.“)
• Kommunikation von Ideen, die im Micro-Blog schnell gemeinsam weiterentwickelt werden können (Brainstorming-Elemente)
• Hinweise auf interessante (unternehmensrelevante) Links im Internet inkl. persönlichen Kommentaren
• Diskussion über bestimmte Funktionen und Elemente auf Websites („Schaut Euch mal diese Navigation an, innovativ ist das, aber auch praktisch sinnvoll?“)
• schneller Erfahrungsaustausch ähnlich eines Chats
• zentrale Archivierung von Diskussionen und Wiederauffindbarkeit über eine Suchmaschine

Der Micro-Blog von //SEIBERT/MEDIA auf Basis von status.net

Die Oberfläche des //SEIBERT/MEDIA-Micro-Blogs auf Basis von status.net, eines Open-Source-Systems für Kurznachrichten, erschließt sich rasch und intuitiv: Die Navigationselemente befinden sich rechts oben, der Content-Bereich links, zusätzliche (und individuell anpassbare) Funktionalitäten sind in der rechten Sidebar. Die visuelle Gestaltung im eigenen Corporate Design ist hier – wie bei allen internen Systemen – ein wichtiger Erfolgsfaktor:

Abb. 1: Die Navigationselemente im rechten oberen Bereich

Abb. 2: Der Nachrichtenbereich

Die Arbeit in status.net ist denkbar einfach: Man gibt die Nachricht in das Textfenster ein, fügt ggf. eine Datei als Anhang hinzu, sendet, fertig. (Dabei ist die von Twitter bekannte Beschränkung auf 140 Zeichen aufgehoben.) Nach dem Abschicken erscheint der Beitrag in der portalartigen öffentlichen Zeitleiste. Andere Nutzer können diesen nun nicht nur sofort sehen, sondern haben verschiedene Funktionen, wie etwa das Hinzufügen zu „Beliebte Nachrichten“ zur Verfügung.

Der status.net-Dienst ermöglicht es zudem, direkt mit anderen Teilnehmern zu kommunizieren und – ähnlich wie in einem Forum, in dem Postings hierarchisch geordnet sind – unmittelbar und unter Wahrung des Kontextes auf Beiträge zu reagieren. Antworten auf die entsprechende Nachricht sind dann mit „in context“ gekennzeichnet, der Diskussionsbaum öffnet sich per Klick.

Innerhalb des Micro-Blogs können sogenannte Gruppen angelegt werden, in denen bestimmte Themengebiete thematisiert werden. Gruppen im //SEIBERT/MEDIA-Micro-Blog sind beispielsweise Design, Blog, Tech, Innovation und natürlich Fun. Per Klick können Nutzer bestimmten Gruppen beitreten oder diese verlassen:

Abb. 3: Die Gruppenübersicht

In der rechten Sidebar einer jeden Gruppe sind die Mitglieder aufgelistet, die gruppenspezifischen Nachrichten sind nach dem Eintreten sofort sichtbar:

Abb. 4: Ein Gruppenbereich

Eine zusätzliche und hilfreiche Navigationsmöglichkeit bilden Tag-Clouds. Beim Klick auf „Aktuelle Tags“ erscheint eine Übersicht über die Themen, die in letzter Zeit besprochen wurden:

Abb. 5: Die Tag-Cloud

Potenziale von Micro-Blogging für Unternehmen

Unserer bisherigen Erfahrung nach hat das Micro-Blogging im Intranet das Potenzial, die unternehmensinterne Kommunikation durch Kanalisation und eine damit verbundene Effizienzsteigerung maßgeblich zu verbessern, sowie einerseits die individuelle Produktivität zu erhöhen und andererseits die schnelle und unkomplizierte Zusammenarbeit auch jenseits des Wikis zu fördern. An dieser Stelle noch einmal unsere Hauptargumente für das Twittern im Unternehmen:

• Steigerung der Transparenz durch eine „öffentliche“ Diskussion im Unternehmen
• Reduktion des E-Mail-Aufkommens (E-Mail-Diskussionen, die aus dem E-Mail-Postfach in den Micro-Blog verlagert werden, entlasten alle Mitarbeiter.)
• Synchronisation von Arbeiten in Projekten
• Austausch über ein schnelles, modernes und unkompliziertes Kommunikationsinstrument
• innovationsförderndes Kommunikationsinstrument
• Integration räumlich verteilter („virtueller“) Teams
• Verbesserung der Qualitätssicherung
• Zeitersparnis im Vergleich zur Arbeit in Wiki-Dokumenten
• Quelle für interessante, neue Ideen
• unaufdringliche Alternative zu E-Mails oder Telefonaten
• Team-Bildungseffekte durch bessere und schnellere Kommunikation

Die Arbeit mit dem Micro-Blog auf Basis von status.net im //SEIBERT/MEDIA-Intranet und die Möglichkeiten eines solchen Systems fasst dieses Tutorial zusammen:

Haben Sie weitere Fragen zu status.net und Micro-Blogging im Unternehmen?  Sprechen Sie uns an.

Weitere Informationen:

Micro-Blogging 1: Argumente für das Twittern im Unternehmen
Micro-Blogging 2: Laconica und Yammer im Intranet
Social Software: Der Wikipedia-Irrtum

In the article Architecture of a Wiki-Project: Elements, Process, Approach, Rules, the procedure for a typical adoption of a Wiki is portrayed in exquisite detail; the best thing to do would be for you to read that article first. This article completes our explanation with the kinds of questions that according to our experience many customers have, questions that require coherent, unambiguous answers.

So //SEIBERT/MEDIA is suggesting that we never require all of our employees to use the Wiki?

Correct. The Wiki should only be required in those areas in which successful and efficient processes have been established. If such processes are depicted in a Wiki, it is unacceptable to return to old, suboptimal processes such as the overuse of hard copies (paper documents) or the complete neglecting of documentation.

At the same time, a directive like “knowledge and documentation is to be saved in the Wiki from this day forward” does not typically succeed in most companies. Forcing employees to use Wikis does little to spark their interest; rather, in our experience it leads more often to frustration among your employees. Larger companies in particular must be careful not to cause (unintentionally) blockades or defensive reactions among their employees. These are barely “visible”, thus endangering even more your Wiki’s success.

How long does it take to execute a Wiki-project?

The duration of the project varies naturally from company to company. However, we assume – depending on their size and agility – that companies require between 3 and 18 months for this process, when the project is overseen and executed by professionals. Here is another juncture where, for example, the consultants of //SEIBERT/MEDIA can help you to advance more quickly and efficiently.

But we always plan our projects sequentially. Your project approach is complex? Can’t it be done differently?

Of course it can be done differently. However, we have always had excellent experiences with this procedure. Regarding the organization of Wiki-projects, there are really no proven findings for an optimal process. We make our methods and approaches transparent to give you insight into how we can proceed together. The exact structuring and procedures for your project will be custom designed for your needs and ideas.

Our Wiki-project is already underway. Is it still possible to work together with your company?

Of course. We advise companies from A to Z as well as in special areas. It is especially those times when the use of the Wiki doesn’t “turn on” that many companies begin to doubt and experience difficulties in recognizing and analyzing the causes. We can be a big help to you in this context as well as with many other activities.

What does your management cost after the piloting of the Wiki?

Our services are always calculated, budgeted and invoiced according to the work actually undertaken. We calculate various hourly rates, depending on which of our employees are working for you. Please contact us when you have further questions regarding this.

Where can I find further information?

Please simply take a look at one of our special Wiki-sites (german), if you haven’t done that already:

• http://firmenwikis.seibert-media.net (incl. Introductory videos)
• http://foswiki.seibert-media.net (incl. Video)
• http://confluence.seibert-media.net/ (incl. Video)

You’ll find our own english articles on the topic of Wikis here:

• http://blog.seibert-media.net/tag/english+wiki

Numerous german and english videos and tutorials on Wikis may be found here:

• http://www.youtube.com/user/seibertmedia
• http://www.youtube.com/user/martinseibert

Many companies are unsure of how a successful Wiki-project should be started and executed. This article will give you an overview of this topic and inform you of the basics. //SEIBERT/MEDIA/ offers transparent services. Ultimately, as the saying goes, we’re also just cooking with water, but we’ve also collected many experiences regarding the process for Wiki-projects, which we will happily explain here – regardless of whether or not you are currently executing a project with us, are planning a project with us, or simply wish to be more successful with your Wiki – without our help.

The process for a Wiki-project that we are implementing usually resembles the following:

1. Information- and orientation phase before starting

Before you begin your Wiki-project, i.e., during your planning and gathering of information regarding an optimal approach, many of the services of //SEIBERT/MEDIA are free of charge. We offer you a budget overview with an orientating project offer for Wikis, an overview of possible Wiki workshops, and compare for you the leading open-source Wiki-systems like Foswiki and commercial systems like Confluence.

Beyond this, we offer you study results regarding the adoption experiences of other companies, information about the motivation of employees as well as the meaning of an individual Wiki-design, and further informational materials – free of charge. In this phase, we would be happy to demonstrate the Wiki-software solutions and their differences. In addition, we can provide you with a free test version within the framework of a workshop, so that you can try out and test the systems.

2. Workshops and Planning and Preparation

Often we structure and plan – together with our customers in collaborative workshops – which services are necessary in Wiki-projects. These workshops can take place at our location in Wiesbaden as well as together with your project team on location at your company. Naturally, we also offer Webinars and training sessions on the Internet. For these, we would be on the telephone and simultaneously be watching a screen. However, the personal appointments at your company are in our experience the most effective.

3. Placing of an order with //SEIBERT/MEDIA

So, you have entrusted //SEIBERT/MEDIA/ with the management of your Wiki-project. This could be a comprehensive and complete project management, from strategy consulting to conception, design, implementation, and adaptive programming to operations and the operational security of your Wiki. However, we are also happy to provide individual services and to come on board as a complementary specialist.

4. Project Kickoff Meeting and Planning of the Wiki-piloting

The beginning of a Wiki-project is an important phase, as companies should here attempt to gain some speed and develop the Wiki more and more into a real magnet for information. To accomplish this, much work is required regarding content; therefore, significant participation and integration is required of our customers. Decisions regarding who will take part in a Wiki-pilot and which tasks are to be assigned to whom are – in addition to the structuring of the project’s procedure – important elements of the Kickoff Meeting.

5. The Wiki-Pilot Project

We call the first phase after the Kickoff meeting the “Wiki-pilot project”, during which the company’s employees – often in concert with a professional – undertake the structuring and establishing of the first contents. In this phase, you need a so-called “adder” (according to one study that identified this type of Wiki-user), who helps you to bring as many relevant contents as possible into the Wiki in a structured way, which should help it become interesting and attractive for all of the employees in your company. This is a basic prerequisite for a successful Wiki-pilot: It is first and foremost the content that gives your Wiki purpose.

6. First Best-practice Examples in your Company

The most important goal of the Wiki-pilot is not to create the complete mirror image of your company’s collected knowledge into the new digital information system. This is an oft-repeated misconception. It would be far too much work and, as a whole, of doubtful importance to have a few employees digitize all of the knowledge of every employee and prepare it for digital use. The goal of the Wiki-project is first and foremost to establish “successful examples for the use of the Wiki”.

The best-case scenario: Your employees and participants in the Wiki-project run around in the company, saying: “So we have this new Wiki-system. Now we’re doing this and that. Before, that was so difficult and led to so many problems. With the Wiki, it’s become really fast, transparent, and efficient. You should try it out in your department sometime.”

7. Organic Expansion of the Project

When the Wiki-pilot is successful, the above-described mouth-to-mouth propaganda takes hold. If this – contrary to expectations – does not occur, then you should consider restructuring, changing, or even completely restarting your Wiki-pilot. With the oral propaganda at your back, you could begin establishing small pilot-projects in individual company divisions. There too, the goal is that the best practices of the Wiki should be implemented at an individual department level, thus showing all participants how valuable a Wiki can be in day-to-day operations.

Please never underestimate this growth phase. It’s about much more than just “forcing” the Wiki into as many departments as possible; rather, it’s about ensuring that more and more people enthused by the idea of the Wiki find the right way to use the Wiki:

A successful Wiki changes patterns of behavior and established rituals. Therefore, forced participation isn’t helpful. But overwhelming success is.

And once again: If you can’t get it to the point that your Wiki spreads itself through your company, just go back to the pilot to check and revise it. Never annoy employees who are skeptical of the Wiki and the changes it implies by offering them suboptimal solutions and compromises. The blockades and defensive postures that may be caused by this are difficult to overcome at later phases. In this all-important phase of the project, far too many companies work alone, thus missing out on the valuable experiences of Wiki-advisors. Initiate contact with us when you are in this phase. We have many informational documents that can help activate your employees as well as practical examples for the establishment of best practices within your company.

8. The Rollout of the Wiki to More and More Employees

After the Wiki-pilot, you should be on the lookout for employees who are more open to the Wiki. You should help these employees to start their journey and to establish best practices for their own individual needs. If you are successful in establishing that the Wiki is helpful for the daily business processes, then you have good cards for the establishing of the Wiki as a successful knowledge management system.

9. Stop signs and Exclusions Zones for Old and Worn-out Paths

As soon as you have found innovative waves, for example, to replace e-mail and paper documents with a controlled and transparent Wiki-based process, it will annoy you when the old, worn-out paths are still used. If you have a better way using the Wiki, a way that you have tested and found successful, then you should begin to erect metaphorical stop signs and exclusion zones for the old and worn-out paths.

Yes, we would even recommend that your company forbid the further use of these suboptimal processes. Still, such directives require content-based information, reasoning, and argumentation. There are often practical and good reasons for holding on to the status quo. These must be examined, analyzed, and dispelled. To accomplish this, we recommend following Fredmund Malik’s example: Be very skeptical when changes in important processes are accepted within the company without any discussion. Whatever is not actively discussed is either unimportant or not correctly thought-out.

10. Internal Marketing Campaign for the Wiki

The more successes you can show in the company, the more use your Wiki will experience. You will feel an ever-increasing need to give all of your colleagues access to the Wiki and wish that everyone would use the system a great deal more. In principle, this is a never-ending process. But you can support it with an internal informational- and marketing campaign.

//SEIBERT/MEDIA/DESIGN can develop for your company posters, pens, and notepads that refer to the Wiki and the special advantages it has in your company. In this vein, one of our customers requested the production of pens and notepads on which were written: “I’ll put that in the Wiki: wiki.companyname.de.” This measure is intended to remind employees who, for example, are taking notes while out of the office that knowledge should be shared with others in the Wiki, that it must be transparent and available. And such an action need not be expensive at all:

• Cost for pens: €268.00 for the production (for example, 500 count, Senator “Challenger”, 1-color) and €240.00 for the professional design (rough estimate including services)
• Cost for notepads: €409.90 for the production (for example, 500 notepads, A5-size, 50-pages, 4/0 color) and €400.00 for the design (rough estimate including services)

In the following article, “Architecture of a Wiki-Project: Customers’ Frequently Asked Questions”, we answer questions that complete our explanation of these topics.

//SEIBERT/MEDIA/SYSTEMS bietet Hosting-Notfalldienstleistungen an und hat eine spezielle Service-Seite für Notfälle mit Informationen über unsere Leistungen in kritischen Situationen eingerichtet. Wenn Sie ein akutes Problem mit Ihrer Website haben oder mit Ihrem Hosting unzufrieden sind, finden Sie hier schnelle Hilfe und können direkt Kontakt mit unseren erfahrenen IT-Fachleuten aufnehmen.

Abb. 1: Die Seite zu Hosting-Notfalldienstleistungen von //SEIBERT/MEDIA/SYSTEMS

Studie: IT-Ausfälle sind keine Ausnahme, sondern die Regel

Nicht wenige Unternehmen begehen den Fehler und lassen sich davon blenden, dass Berichte über sicherheitsrelevante „Großereignisse“ nur alle paar Wochen durch Web und Presse geistern. Doch tatsächlich sind IT-Probleme, Security-Schwächen und mangelnde Verfügbarkeit nicht etwa die Ausnahme, sondern vielmehr die Regel. Kürzlich hat Symatec die Studie 2009 SMB Disaster Preparedness Survey veröffentlicht, für die 1.650 kleine und mittelständische Unternehmen aus aller Welt befragt wurden, und kommt zu besorgniserregenden Ergebnissen:

• Durchschnittlich drei Ausfälle der IT-Systeme durch Angriffe von Hackern, Viren, Stromausfälle oder Naturkatastrophen verzeichnete jedes der befragten KMU innerhalb der letzten 12 Monate.
• Bei 42% der befragten Unternehmen war der IT-Betrieb mindestens ein Mal innerhalb eines Jahres für acht Stunden und länger lahmgelegt.
• Der durch einen IT-Ausfall entstandene Schaden beläuft sich im Durchschnitt auf ca. 10.000 Euro.
• Jedes vierte von IT-Problemen betroffene Unternehmen hat durch einen Ausfall wichtige Daten verloren.
• Rund 50% aller kleinen und mittleren Unternehmen haben keinen sog. Disaster-Recovery-Plan und wissen nicht, wie sie im Notfall reagieren sollen.

Im Notfall: Kurzfristige und zielgerichtete Unterstützung

Bei Hosting-Problemen ist direkte und möglichst unbürokratische Hilfe nötig und insbesondere im Notfall sind professionelle, kurzfristige und zielgerichtete Aktivitäten erforderlich. Die erfahrenen Systemadministratoren von //SEIBERT/MEDIA/SYSTEMS bieten Ihnen diese direkte Hilfe via Hotline und Live-Chat an.

Abb 2.: Screenshot der Kontaktmöglichkeiten im Notfall

Wenn Sie Ziel eines Hacker-Angriffs geworden sind, stehen wir Ihnen bei Schadensbegrenzung, Beweissicherung und beim Schützen der betroffenen Systeme zur Seite. Aber auch wenn Ihre Anwendung nicht (mehr) die nötige Performance bietet oder es ständig zu Verfügbarkeitsproblemen kommt, können wir kurzfristig eine schnelle und zuverlässige Plattform bereitstellen, auf die wir Ihre Anwendung umziehen können, um diesen Herausforderungen zu begegnen. //SEIBERT/MEDIA/SYSTEMS betreibt selbst eine größere Server-Infrastruktur, unsere Experten kennen alle relevanten Aspekte, die beim Hosting von geschäftskritischen Diensten vom Mail-Server bis zum Netzwerk-Equipment von Bedeutung sind.

Was //SEIBERT/MEDIA/SYSTEMS konkret tun kann

Kein Unternehmen kann es sich leisten, sich beispielsweise erst durch das Callcenter seines Hosters zu navigieren, um einen Ansprechpartner zu finden, während die Website down ist oder Datenverlust droht. Wenn es im Fall der Fälle schnell gehen soll und andere sich durch Warteschleifen telefonieren, arbeiten wir bereits an der Lösung. Unsere IT-Profis stehen Ihnen bei Problemen sofort und persönlich zur Verfügung.

Unsere Leistungen bei Problemen mit Ihrer Website:

• Analyse und Abwehr von Angriffen auf ihre Server-Systeme, Netzwerkinfrastruktur oder Web-Anwendung
• Software-Updates sowie Umzüge und Umstellungen
• Sicherheitsoptimierungen der Server-Systeme und -Dienste („Hardening“)

Unsere Leistungen bei Problemen mit Ihrem Mail-Dienst:

• Optimierung von unzureichenden Spam- bzw. Virenfiltern
• temporäres Mail-Hosting oder Relaying bei Performance-Problemen, Umzügen oder Ausfällen

Darüber hinaus unterstützen wir Sie kurzfristig und kompetent bei der Installation und Konfiguration von Diensten oder Web-Anwendungen.

Weitere Informationen über unser gesamtes Leistungsspektrum und unser Team finden Sie auf der Website von //SEIBERT/MEDIA/SYSTEMS.

Den folgenden Vorgang dürften viele Internet-Nutzer kennen: Man surft auf einer Website und findet einen Link „Kontakt“. Man klickt den Link an und startet damit eine Irrfahrt durch die Tiefen seines Rechners. Denn der Link führt nicht etwa auf ein Kontaktformular, sondern dazu, dass die Festplatte brummt, der lokal installierte Mail-Client startet (oder eingerichtet werden will) und allerlei zusätzliche Fenster aufgehen. Während man gerade noch gemütlich durch das Web gesurft ist, muss man nun plötzlich Stromschnellen meistern und turmhohe Wellen abwehren.

Der Kontakt-Link ist in diesem Fall ein sogenannter Mailto-Link, der automatisch eine E-Mail-Software aufruft – selbst wenn der User diese nicht nutzt. Mailto-Links auf Websites sind in dreierlei Hinsicht problematisch: Sie führen zu Usability-Problemen, erschweren das Tracking und können ein Sicherheitsrisiko darstellen.

Usability-Probleme

Kein lokaler E-Mail-Client installiert
Viele Nutzer verwenden Web-Mail-Dienste und greifen über web.de, gmx.de und Co. auf ihre E-Mails zu. Der Mailto-Link kann jedoch nur sinnvoll genutzt werden, wenn Outlook, Thunderbird oder ein vergleichbares Programm eingerichtet und konfiguriert ist, also die entsprechenden POP3- und SMTP-Server-Adressen angegeben worden sind. Dieser Umstand ist natürlich nicht allen Nutzern bekannt, wenn sie auf einen Mailto-Link klicken. Der Link startet dann die nicht installierte (aber auf den meisten Rechnern vorhandene) Mail-Software, die ersteinmal eingerichtet werden will. Die Mehrzahl der User versteht diesen Vorgang nicht und ist verwirrt. Und selbst diejenigen, die wissen, was geschieht, sind verärgert.

Enttäuschte Nutzererwartungen
Die meisten User erwarten beim Klick auf einen Link, dass sich eine neue Seite im Browser öffnet. Die Nutzer bewegen sich im Web und das machen sie mit dem Internet Explorer, Firefox oder einem anderen Web-Browser. Wenn stattdessen eine lokal installierte Software gestartet wird, führt das häufig zu Verwirrung und Unmut. Das ist eine Reaktion, die man in User-Tests insb. bei Personen mit geringer Technik-Affinität immer wieder beobachten kann. Schon PDF-Dokumente, die sich im schlanken Acrobat Reader öffnen, rufen kritische Blicke und negative Kommentare hervor. Ein fetter Mail-Client kann zu tiefen Sorgenfalten und einem Gefühl absoluter Ohnmacht führen; “der Rechner macht eben mal wieder, was er will”. Eine der wichtigsten Usability-Heuristiken, die der Nutzerkontrolle, wird hier komplett missachtet.

Kritisch ist das auch, weil der User sich beim Klick auf einen Kontakt-Link an einem kritischen Punkt der Nutzung befindet. Er hat die Entscheidung getroffen, den Anbieter zu kontaktieren. Wenn es direkt darauf zu massiven Problemen und einem Gefühl des Unbehagens kommt, wird dieser Entschluss möglicherweise revidiert und der Kontaktversuch abgebrochen.

Lange Ladezeiten
Das Laden einer Mail-Anwendung kostet Rechner-Ressourcen und geschieht langsam. Unter Umständen klickt der User den Mailto-Link sogar mehrfach an, weil der Client bis zum Start ein bisschen Zeit benötigt – mit dem unerfreulichen Resultat, dass sich die Mail-Software ebenfalls mehrfach und in mehreren Fenstern öffnet. Bei alten Rechnern kann der Start des Programms im schlimmsten Fall sogar zum Absturz führen.

Mangelnde Erfolgskontrolle

Ein weiterer Problemkomplex im Zusammenhang mit Mailto-Links ist die Erfolgskontrolle, die sich mit Tracking-Tools wie Google Analytics sehr genau durchführen lässt. Jede Anfrage via Kontaktformular wird festgehalten und es lässt sich präzise ermitteln, wie viele Nutzer die Kontaktseite aufgerufen und wieviele ein Formular tatsächlich abgeschickt haben. Den Investitionen in Online-Marketing-Kampagnen kann die Zahl der Conversions gegenübergestellt werden, auch die Kosten pro Conversion lassen sich genau darstellen. Wenn man den Wert der Anfrage beziffern kann (in den meisten Fällen ist das leider nicht ohne weiteres möglich), lässt sich sogar eine Rendite berechnen. Die Verwendung eines Kontaktformulars ermöglicht also eine genaue Kosten-Nutzen-Analyse.

Diese Analyse ist deutlich schwieriger, wenn zusätzlich oder ausschließlich Mailto-Links angeboten werden. Zwar kann man messen, wie häufig der Mailto-Link angeklickt wurde, aber das Anklicken des Links führt nicht immer zum Abschicken einer Mail. Also müssten per E-Mail eingehende Anfragen und Tracking-Daten irgendwie zusammengeführt werden, was automatisiert kaum gelingen dürfte oder sehr aufwändig ist. Das exakte Bestimmen von Kosten pro Anfrage und Rendite der Kampagne jedenfalls ist nicht mehr möglich.

Zudem ist eine standardisierte und vor allem effiziente Weiterbearbeitung von E-Mail-Anfragen deutlich schwieriger. Ein Problem besteht beispielsweise darin, dass im (via Mailto geöffneten) Mail-Programm meist Empfänger und Betreff bereits vorgegeben sind. Wird nun etwa der Betreff vom Nutzer nach eigenem Ermessen vom User verändert, landet die E-Mail möglicherweise nicht beim gewünschten Adressaten und im korrekten Filter, wodurch die Kommunikation verzögert oder gar verhindert wird.

Sicherheitsprobleme

Skripte
Die wenigsten User wissen oder berücksichtigen, dass E-Mails Skripte enthalten können. Diese Skripte werden analysiert, wenn der Mail-Client versucht, die Nachricht zu lesen. Wenn die Client-Software Administrator-Privilegien hat (was bei den meisten Windows-Nutzern der Fall ist), kann sie Skripte ausführen, die das ganze System beeinflussen können. Dass dafür der User verantwortlich ist, der ja mit der Website interagieren muss, um den Client über den Mailto-Link zu öffnen, mag als Argument angeführt werden. Allerdings hat wohl jeder schon mal versehentlich einen Mailto-Link angeklickt.

Generell gilt natürlich, dass ein Skript ohne Lücke in der E-Mail-Software nicht auf das lokale System zugreifen kann. Insb. ältere Rechner oder nicht gepatchte Outlook-Versionen bergen aber nach wie vor Risiken.

Spam
Ein zweiter sicherheitsrelevanter Aspekt betrifft die Gegenseite, also den Website-Betreiber, der Mailto-Links auf seiner Seite einsetzt: Wenn gewisse Sicherheitsmaßnahmen nicht getroffen werden, erweisen sich Mailto-Links nämlich als Anziehungspunkt für Spam.

Spammer nutzen meist Programme, die automatisch nach Mailto-Einträgen auf Websites suchen: Spam-Bots durchforsten den Quelltext also gezielt nach der Zeichenkette „mailto“ und dem @-Zeichen. Auch deshalb sollten Betreiber darauf verzichten, E-Mail-Adressen als Link darzustellen.

Fazit

Mailto-Links werden von vielen Website-Betreibern wohl schlicht missverstanden: Was einst als komfortabel gegolten haben mag, stört und irritiert die meisten Nutzer heute und ist auch für den Betreiber gefährlich. Mailto-Links erschweren dem User die Kontaktaufnahme (zudem bieten moderne Browser die Möglichkeit, die Mailto-Funktion zu sperren) und können zu Abbrüchen führen, erschweren oder vereiteln die Erfolgskontrolle und sind unter Sicherheitsaspekten nicht unproblematisch.

Auf einer modernen Website hat die Mailto-Funktion nichts verloren. Gute Kontaktformulare sind wesentlich effektiver und können dank moderner Technologien noch dazu ein positives Nutzungserlebnis schaffen.

Weiterführende Informationen

Formulare: Usability-Probleme und ihre Vermeidung
Lohnen sich Spam-Filter in Unternehmen?
Der Bestellvorgang: Was häufig schiefgeht und was User frustriert?

Im Artikel Architektur eines Wiki-Projekts: Elemente, Ablauf, Vorgehen, Regeln ist der Ablauf einer typischen Wiki-Einführung ausführlich dargestellt worden; am besten lesen Sie zunächst diesen Beitrag. Hier sollen nun ergänzend Fragen beantwortet werden, die erfahrungsgemäß viele Kunden bewegen und die nach schlüssigen, unmissverständlichen Antworten verlangen.

//SEIBERT/MEDIA schlägt also vor, dass Unternehmen das Wiki nie als zwingendes Medium für alle Mitarbeiter ausrufen?

Richtig. Das Wiki sollte nur dort verbindlich sein, wo erfolgreiche und effiziente Prozesse etabliert worden sind. Wenn solche Prozesse im Wiki abgebildet werden, ist es inakzeptabel, wenn auf alte, suboptimale Prozesse wie z.B. die Zettelwirtschaft oder gar den Verzicht auf jegliche Dokumentation zurückgegriffen wird.

Gleichzeitig bringt eine Anweisung wie „Wissen und Dokumentation ist künftig im Wiki abzuspeichern“ so gut wie gar nichts im Unternehmen. Die Wiki-Nutzung per Dekret hilft bei der Mitarbeiteraktivierung wenig, sondern sorgt unserer Erfahrung nach vielmehr für Frustration bei den Mitarbeitern. Gerade in großen Unternehmen müssen Sie aufpassen, dass Sie nicht unbeabsichtigt Blockaden und Abwehrhaltungen fördern. Diese sind nämlich kaum „sichtbar“ und gefährden Ihren Wiki-Erfolg umso stärker.

Wie lange dauert es, ein Wiki-Projekt so durchzuführen?

Die Projektdauer ist natürlich von Unternehmen zu Unternehmen unterschiedlich. Wir gehen jedoch davon aus, dass Unternehmen je nach Größe und Agilität zwischen 3 und 18 Monaten für diesen Prozess benötigen, wenn er professionell betreut und durchgeführt wird. Auch hier können zum Beispiel die Berater von //SEIBERT/MEDIA helfen, schneller und effizienter voranzukommen.

Unsere Projekte planen wir aber immer sequentiell. Ihr Projektansatz ist komplex. Geht das nicht anders?

Natürlich geht es auch anders. Wir haben mit diesem Vorgehen bisher aber die besten Erfahrungen gemacht. Es gibt für die Organisation von Wiki-Projekten bisher keine wirklich gesicherten Erkenntnisse für ein optimales Vorgehen. Wir machen unsere Methoden und unsere Ansätze transparent, um Ihnen einen Einblick zu geben, wie wir gemeinsam vorgehen können. Wie Ihr Projekt genau strukturiert wird und abläuft, richtet sich nach Ihren Bedürfnissen und Vorstellungen.

Unser Wiki-Projekt läuft schon. Können wir trotzdem mit Ihnen zusammenarbeiten?

Selbstverständlich. Wir beraten Unternehmen sowohl von A bis Z als auch in Spezialbereichen. Gerade wenn die Wiki-Nutzung nicht „anspringt“, verzweifeln viele Unternehmen und haben Schwierigkeiten, die Ursachen zu erkennen und zu analysieren. In diesem Zusammenhang und bei vielen weiteren Maßnahmen können wir Ihnen eine große Hilfe sein.

Was kostet die Betreuung über den Wiki-Piloten hinaus?

Unsere Dienstleistungen werden nach dem entstehenden Aufwand kalkuliert, budgetiert und fakturiert. Je nachdem welche Mitarbeiter für Sie arbeiten, rechnen wir unterschiedliche Stundenpreise ab. Bitte sprechen Sie mit uns, wenn Sie hierzu weitere Fragen haben.

Wo finde ich weitere Informationen?

Sehen Sie sich bitte einfach einmal unsere Wiki-Spezialseiten an, falls Sie das noch nicht getan haben sollten:

• http://firmenwikis.seibert-media.net (inkl. Einführungsvideos)
• http://foswiki.seibert-media.net/ (inkl. Video)
• http://confluence.seibert-media.net/ (inkl. Video)

Unsere über 80 eigenen Fachartikel zum Thema Wikis (davon über 25 als PodCast für Ihren MP3-Spieler) finden sich hier:

• http://blog.seibert-media.net/tag/wiki/

Zahlreiche Videos und Tutorials über Wikis finden Sie hier:

• http://www.youtube.com/user/seibertmedia
• http://www.youtube.com/user/martinseibert

Unsere Dienstleistungen rund um Wikis haben wir hier beschrieben:

• http://blog.seibert-media.net/firmenwikis/
• http://consulting.seibert-media.net/consulting/technologie-beratung/intranets__wikis/index.shtml

Vielen Unternehmen ist nicht klar, wie ein erfolgreiches Wiki-Projekt gestartet und durchgeführt werden soll. Dieser Artikel will hierüber eine Übersicht geben und grundlegend informieren. //SEIBERT/MEDIA erbringt transparente Dienstleistungen. Letztendlich kochen wir auch nur mit Wasser, haben aber mit dem Ablauf von Wiki-Projekten schon viele Erfahrungen gesammelt, die wir hier gerne darstellen möchten – unabhängig davon, ob Sie gerade ein Projekt mit uns durchführen, eines mit uns planen oder ganz ohne uns mit Ihrem Wiki erfolgreich werden wollen.

Der Ablauf eines Wiki-Projekts sieht bei uns in der Regel wie folgt aus:

1. Informations- und Orientierungsphase vor dem Auftrag

Während Sie zu Beginn das Wiki-Projekt planen und sich bei uns über einen optimalen Ablauf informieren, sind viele Leistungen von //SEIBERT/MEDIA für Sie kostenfrei. Wir bieten Ihnen eine Budget-Übersicht mit einem Orientierungs-Projektangebot für Wikis, eine Übersicht über mögliche Wiki-Workshops, vergleichen mit Ihnen führende Open-Source-Wikisysteme wie Foswiki mit kommerziellen Systemen wie Confluence.

Darüber hinaus geben wir Ihnen Studienergebnisse über die Einführungserfahrungen anderer Unternehmen, Informationen zur Mitarbeiter-Aktivierung sowie zur Bedeutung eines individuellen Wiki-Designs und weitere kostenlose Informationsmaterialien an die Hand. Gerne demonstrieren wir Ihnen in dieser Phase die Wiki-Software-Lösungen und deren Unterschiede. Zudem können wir Ihnen in Rahmen von Workshops eine kostenlose Testinstanz zur Verfügung stellen, in der Sie die Systeme schon einmal ausprobieren und prüfen können.

Unsere Wiki-Beispiele, Referenzen und die vielen öffentlichen Informationen über Wiki-Projekte wie inzwischen über 80 Fachartikel zu Wikis (davon über 25 als PodCasts für Ihren MP3-Spieler) sowie zahlreiche Videos von //SEIBERT/MEDIA und Tutorials über Wikis sollen dabei helfen, uns als qualifizierten und attraktiven Dienstleister zu positionieren.

2. Workshops und Planung und Vorbereitung

Häufig strukturieren und planen wir gemeinsam mit unseren Kunden in gemeinsamen Workshops, welche Leistungen in Wiki-Projekten erforderlich sind. Diese Workshops können sowohl bei uns in Wiesbaden als auch gemeinsam mit Ihrem Projektteam vor Ort bei Ihnen stattfinden. Natürlich bieten wir auch Webinare und Schulungen über das Internet an. Dann telefonieren wir gemeinsam und schauen gleichzeitig auf einen Bildschirm. Mit Abstand am wirkungsvollsten sind aber die persönlichen Termine bei Ihnen.

3. Auftragserteilung an //SEIBERT/MEDIA

Sie beauftragen //SEIBERT/MEDIA mit der Betreuung Ihres Wiki-Projekts. Das kann eine umfangreiche und vollständige Projektbetreuung von der Strategie-Beratung über Konzeption, Design, Umsetzung und Anpassungsprogrammierung bis zum Betrieb und der Betriebssicherstellung des Wikis sein. Wir erbringen gerne aber auch nur Teilleistungen und treten als Spezialist zur Ergänzung auf.

4. Projekt-Kickoff-Meeting und Planung des Wiki-Piloten

Der Beginn eines Wiki-Projekts ist eine wichtige Phase, weil Unternehmen hier versuchen sollten, Fahrt aufzunehmen und das Wiki nach und nach zu einem wirklichen Informationsmagneten zu entwickeln. Dazu gehört viel inhaltliche Arbeit und damit auch eine signifikante Beteiligung und Integration unserer Kunden. Wer an dem Wiki-Piloten teilnimmt und welche Aufgaben an wen übertragen werden, sind neben der Strukturierung des Projektablaufs wichtige Elemente für den Kick-off-Workshop.

5. Das Wiki-Pilot-Projekt

Als Wiki-Pilot-Projekt bezeichnet man die erste Phase nach dem Kick-off-Meeting, in der die Mitarbeiter des Unternehmens häufig in Zusammenarbeit mit einem Profi die Strukturierung und Etablierung der ersten Inhalte übernehmen. In dieser Phase brauchen Sie sogenannte „Adder“ (gemäß einer Studie, die einen Wiki-Nutzertyp „Hinzufüger“ identifiziert hat), die Ihnen dabei helfen, möglichst viele relevante Inhalte strukturiert in das Wiki einzubringen, damit es interessant und attraktiv für alle Kollegen in Ihrem Unternehmen wird. Das ist eine Grundvoraussetzung für einen erfolgreichen Wiki-Piloten: Erst der Inhalt gibt dem Wiki Sinn.

6. Erste Best-Practice-Beispiele in Ihrem Unternehmen

Das wichtigste Ziel des Wiki-Piloten ist nicht, eine umfassende Abbildung des Unternehmenswissen in dem neuen digitalen Informationssystem zu schaffen. Das ist ein häufiges Missverständnis. Es wäre viel zu viel Arbeit und insgesamt auch ein zweifelhaftes Unterfangen, ein paar wenige Mitarbeiter das Wissen aller Mitarbeiter digitalisieren und aufbereiten lassen zu wollen. Das Ziel des Wiki-Piloten besteht insbesondere darin, „strahlende und erfolgreiche Beispiele für die Wiki-Nutzung“ zu etablieren.

Im besten Fall laufen Ihre Mitarbeiter und Teilnehmer des Wiki-Piloten im Unternehmen herum und erzählen: „Wir haben ja dieses neue Wiki-System. Da machen wir jetzt das und das. Früher war sowas aufwändig und fehleranfällig. Mit dem Wiki ist das wirklich schnell, transparent und effizient geworden. Das solltet Ihr bei Euch in der Abteilung auch mal ausprobieren.“

7. Organische Ausweitung des Projekts

Wenn der Wiki-Pilot erfolgreich ist, setzt die oben beschriebene Mund-zu-Mund-Propaganda ein. Sollte diese wider Erwarten nicht einsetzen, sollten Sie darüber nachdenken, den Wiki-Pilot neu zu strukturieren, zu verändern oder sogar neu aufzusetzen. Mit der Mundpropaganda im Rücken können Sie sich auf den Weg machen, weitere kleine Pilot-Projekte in den einzelnen Unternehmensbereichen zu etablieren. Auch dort ist wieder das Ziel, dass für den Bereich spezifische Best Practices mit dem Wiki umgesetzt werden, die allen Beteiligten zeigen, wie wertvoll ein Wiki im Tagesgeschäft sein kann.

Bitte unterschätzen Sie diese Phase des Wachstums nicht. Es geht hierbei nicht darum, das Wiki möglichst vielen Abteilungen „aufzudrücken“, sondern dafür zu sorgen, dass mehr und mehr Begeisterte von der Wiki-Idee den richtigen Weg in die Wiki-Nutzung finden:

Ein erfolgreiches Wiki ändert Verhaltensweisen und Rituale. Zwang ist da nicht hilfreich. Erdrückende Erfolge schon.

Und noch einmal: Wenn Sie es nicht schaffen, dass Ihr Wiki sich von selbst verbreitet, gehen Sie zurück zum Piloten und prüfen und revidieren Sie. Nerven Sie niemals Mitarbeiter, die dem Wiki und den damit einhergehenden Veränderungen skeptisch gegenüberstehen, mit suboptimalen Lösungen und Kompromissen. Die entstehenden Blockaden und Abwehrreaktionen lassen sich später nur sehr schwer überwinden. In dieser wichtigen Phase des Projekts arbeiten viel zu viele Unternehmen ganz allein und lassen sich die wertvollen Erfahrungen von Wiki-Beratern entgehen. Sprechen Sie uns an, wenn Sie in dieser Phase stehen. Wir haben viele Informationsunterlagen zur Aktivierung von Mitarbeitern und tolle Praxisbeispiele für die Etablierung von Best Practices im Unternehmen.

8. Der Roll-out des Wikis an mehr und mehr Mitarbeiter

Nach dem Wiki-Piloten sollten Sie nach Mitarbeitern Ausschau halten, die dem Wiki offen gegenüberstehen. Diesen sollten Sie helfen, die ersten Schritte zu gehen und Best Practices für die eigenen Bedürfnisse zu etablieren. Wenn Sie es schaffen, dass das Wiki sich als hilfreich für die Tagesgeschäftsprozesse etabliert, dann haben Sie auch gute Karten für ein Wiki als erfolgreiches Wissensmanagement-System.

9. Stoppschilder und Absperrungen auf obsolete und ausgetretene Pfade

Sobald Sie innovative Wege gefunden haben, um zum Beispiel E-Mail und Papier durch einen kontrollierten und transparenten Wiki-Prozess zu ersetzen, wird es Sie ärgern, wenn trotzdem noch die ausgetretenen Pfade genutzt werden. Wenn Sie einen besseren Weg im Wiki haben, der erprobt und erfolgreich ist, sollten Sie beginnen, Stoppschilder und Absperrungen auf diesen ausgetretenen Pfaden anzubringen.

Ja, wir empfehlen sogar, dass die Unternehmensspitze untersagt, diese suboptimalen Prozesse weiter anzuwenden. Zu diesen Anweisungen gehören aber inhaltliche Informationen, Begründungen und Diskurs. Häufig gibt es noch praktische und gute Gründe dafür, am Status Quo festzuhalten. Diese müssen erfragt, analysiert und ausgeräumt werden. Hier empfehlen wir, es wie Fredmund Malik zu halten: Seien Sie sehr skeptisch, wenn die Veränderung von wichtigen Prozessen im Unternehmen ohne Diskussion hingenommen wird. Was nicht heftig diskutiert wurde, ist häufig entweder nicht wichtig oder nicht richtig durchdacht.

10. Interne Marketing-Kampagnen für das Wiki

Je mehr Erfolge Sie im Unternehmen vorzuweisen haben, desto mehr Nutzung wird das Wiki erfahren. Sie werden mehr und mehr das Bedürfnis verspüren, all Ihren KollegInnen Zugriff auf das Wiki zu geben und sich wünschen, dass alle noch viel mehr mit dem System arbeiten. Grundsätzlich ist dies ein Prozess, der nie aufhört. Aber Sie können ihn durch interne Informations- und Marketing-Kampagnen unterstützen.

//SEIBERT/MEDIA/DESIGN entwickelt für Sie Plakate, Kugelschreiber und Notizblöcke, die auf das Wiki und die speziellen Vorteile im Unternehmen hinweisen. So hat beispielsweise einer unserer Kunden Kugelschreiber und Notizblöcke produzieren lassen, auf denen „Ich schreib’s noch ins Wiki: wiki.unternehmensname.de“ steht. Diese Maßnahme soll Mitarbeiter, die sich beispielsweise unterwegs Notizen machen, daran erinnern, dass Wissen mit anderen im Wiki geteilt werden soll, dass es transparent und verfügbar sein muss. Und eine solche Aktion muss gar nicht teuer sein:

• Aufwand für Kugelschreiber: 268,00 Euro für die Produktion (zum Beispiel 500 Stück, Senator “Challenger”, 1farbig) und 240,00 Euro für das professionelle Design plus Projektmanagement
• Aufwand für Notizblöcke: 409,90 Euro für die Produktion (zum Beispiel 500 Schreibblöcke, A5, 50 Blatt, 4/0 farbig) und 400,00 Euro für das Design plus Projektmanagement

Im Folge-Artikel Architektur eines Wiki-Projekts: Häufige Fragen von Kunden und Informationsquellen werden ergänzend Fragen zu Themen beantwortet, die für viele Kunden neu oder zumindest missverständlich gewesen sind.

Maik, jede Medaille hat zwei Seiten. Die TYPO3-Medaille nicht?

Doch. Ein Nachteil sind bislang noch die Usability-Probleme bei der Arbeit mit TYPO3. Das funktioniert nicht nach dem Motto: Hier haben Sie also Ihr System, dann legen Sie mal los. Man muss dem Kunden schon erklären, wie er seine Inhalte einpflegt, und ein gewisser Schulungsaufwand für die Redakteure ist auf jeden Fall nötig. Man muss die Leute also ein bisschen einarbeiten. Wenn man das System aber verstanden hat, läuft das.

Kommen wir zu den Themen Stabilität und Sicherheit.

Von Stabilitätsproblemen habe ich noch nichts gehört. Es gibt ja Tausende Referenzen und auch wirklich große Websites, die mit TYPO3 umgesetzt wurden und die einwandfrei laufen. TYPO3 verfügt standardmäßig über Caching via Datenbank. Die Seiten liegen also schon vorgeneriert in der Datenbank vor. Es gibt zudem auch die Möglichkeit des Static File Cachings. Bei diesem Verfahren werden die Seiten als statische Dateien exportiert und müssen nur noch vom Webserver ausgeliefert werden, was hinsichtlich der Performance natürlich enorme Vorteile hat. Da gibt es also keine Probleme.

Ich meine, ich hätte mal von Security-Lücken gelesen …

Richtig, über eine spezielle URL konnte man die Konfigurationsdatei aufrufen, in dem der Hash des TYPO3-Install-Tool-Passworts steht. Über weitere Schritte war es schließlich möglich, sich einen Admin-Zugang anzulegen. Hier wurde dann nachgebessert, das TYPO3 Install-Tool wird jetzt nach einer Stunde automatisch deaktiviert. Auch bieten Extensions Angriffspunkte.

Einmal entdeckte Lücken werden jedoch schnell behoben: Beispielsweise gibt es Ansätze wie den „Last Friday each month is Bug Day“, ständig werden Patches veröffentlicht – die muss man natürlich auch einspielen. Wir reden halt über Software. Keine Software ist perfekt. Ein Sicherheitsproblem hat TYPO3 aber nicht.

Welche Grenzen hat TYPO3 denn? Was kann TYPO3 nicht?

Für eine normale, größere Webseite ist TYPO3 optimal. Man kann Content einpflegen, Bilder hochladen usw. Wenn etwas nicht geht, sind wieder die Extensions der Schlüssel. Für spezielle Anwendungsfälle muss man das System gegebenenfalls halt erweitern. Gerade haben wir für einen Kunden eine Mediathek realisiert und dafür eine Extension geschrieben.

Das geht so ohne weiteres?

Sicher, TYPO3 ist Open-Source-Software. An einer Extension arbeitet man aber schon ein bisschen länger. Das liegt vor allem daran, dass das System ein paar Jahre auf dem Buckel hat. Es hat sich eben eine Menge angesammelt.

Und wann räumt die Community mal auf?

Die ist längst dabei. Das dauert noch eine Weile, aber mit TYPO3 5.0 fangen die komplett bei Null an. Ende 2009 soll es eigentlich ein Release geben. Was man jetzt schon davon sehen kann, sieht wirklich cool aus. Mit FLOW3 wird es ein eigenes Framework für TYPO3 geben, das momentan im Alpha-Stadium und fast feature-complete ist. Wenn das fertig ist, wird das CMS mit dem Framework sozusagen nochmal neu gebaut und aller Ballast über Bord geworfen. Vor allem die Entwicklung von Extensions dürfte dadurch viel einfacher werden.

Der Relaunch wird auch ordentlich vorangetrieben: Mit der TYPO3-Association gibt es eine Non-Profit-Organisation, die Mittel gesammelt hat bzw. zur Verfügung stellt, um einige Entwickler hauptamtlich zu beschäftigen. Neben der ehrenamtlichen Community arbeiten also (soweit ich weiß) auch zwei Vollzeit-Entwickler an TYPO3. Klar, das merkt man.

Bleiben wir mal bei der Perspektive des Entwicklers. Ist TYPO3 denn aus Programmierersicht gut zu handhaben? Wie ist das im Vergleich zu anderen CMS?

Man braucht sicher Einarbeitungszeit. TYPO3 ist auch aus Entwickler-Sicht kein System, das man anschaltet und dann loslegen kann. Da ist zum Beispiel TYPO-Script, eine eigene Skriptsprache, die schon relativ alt und in Sachen Syntax nicht gerade das Nonplusultra ist. Bis man also erstmal die Syntax und das ganze System richtig versteht, dauert das schon seine Zeit.

Wenn man aber an ein paar TYPO3-Projekten gearbeitet hat, hat man ziemlich schnell eine Art Bibliothek mit den häufigsten Anwendungsfällen beisammen: Menü oben, vertikales Menü, Menü unten usw. – eine Bibliothek mit Standards also, auf die ich im nächsten Projekt mit Copy & Paste zugreifen kann. Die Einarbeitungszeit lohnt sich auf jeden Fall. Dann flutscht das.

Maik, vielen Dank für die Einblicke und die Zeit.

Weitere Informationen:
Experten-Interview: TYPO3 und seine Stärken
Flexibles Content Management mit TYPO3
Individualität und Funktionenvielfalt dank mächtiger TYPO3-Extensions

Das Content-Management-System TYPO3 wird immer häufiger verwendet, gilt als das Open-Source-CMS für größere Websites schlechthin. Maik, was hat TYPO3 anderen CMS voraus?

Der erste Vorteil besteht darin, dass TYPO3 so oft eingesetzt wird. Dadurch gibt es eine entsprechend große Community, die TYPO3 weiterentwickelt und pflegt. TYPO3 ist sehr gut dokumentiert und es gibt etliche gute Bücher zum Thema, was auf die meisten anderen CMS nicht zutrifft.

Die weite Verbreitung spiegelt sich zudem in der Anzahl des Extensions wieder. Das ist der zweite große Vorteil: Es gibt eigentlich für jede Anforderung und für jedes Problem, das man sich ausmalen kann, eine Extension. Natürlich sind die nicht immer passgenau, aber man hat zumindest einen Ansatzpunkt: Hier habe ich eine Grundlage und kann das weiterentwickeln.

Was heißt das für mich als Kunden, wenn //SEIBERT/MEDIA bei einem Website-Projekt die Umsetzung mit TYPO3 wählt bzw. empfiehlt? Ist das gut für mich? Ist das gut für meine Redakteure, die die Web-Inhalte pflegen? Müssen die zum Beispiel HTML-Kenntnisse haben?

Wenn TYPO3 verwendet wird, ist das für den Kunden und seine Redakteure eine gute Nachricht. HTML müssen die jedenfalls nicht können. Für TYPO3 gibt es das Template-System TemplaVoilá: Damit kann ich für den Kunden sogenannte Flexible Content Elements bauen. Der Kunde muss die jeweilige Komponente nur auswählen und die Daten einfügen.

Ein Beispiel: Ein bestimmter Content-Bereich umfasst ein Bild mit einem Text-Link und rechts daneben den Text. Jetzt muss man nur das Bild angeben und den Text in den WYSIWYG-Editor einstellen. Das Flexible Content Element ist dabei immer im Hintergrund aktiv, Bilder werden zum Beispiel automatisch skaliert usw. Der Redakteur muss keine Angst haben, dass er durch eine Content-Aktualisierung das Layout sprengt.

Der Redakteur loggt sich ein und kann selbst seinen Content verändern, inklusive Bildern, Multimedia-Inhalten, News?

Richtig. Für News gibt es ebenfalls ein sehr komfortables Plugin. TYPO3 hat auch ein sehr gutes Rechtesystem, das ziemlich ausgereift ist. Man kann zum Beispiel Gruppen anlegen und die Rechtevergabe bis zur einzelnen Seite hinunter flexibel einstellen.

TYPO3 ist ein Open-Source-Tool. Haben denn kommerzielle Content-Management-Systeme am Markt überhaupt noch eine Chance?

Der CMS-Markt ist natürlich riesig und hat auch viele Nischen. Es gibt viele gute Systeme, sowohl kommerzielle als auch freie. Schlechte natürlich auch. Gerade kommerzielle CMS sind heute aber eher auf ganz spezielle Anwendungsfälle ausgelegt bzw. werden extra für solche entwickelt.

Aber es ist für ein Unternehmen nie ein Fehler auf TYPO3 zu setzen?

Meiner Erfahrung nach ist TYPO3 das ausgereifteste freie CMS. Bei einem Standard-Website-Projekt würde mir nicht viel einfallen, was gegen TYPO3 spricht und was andere Systeme TYPO3 voraushaben.

Im zweiten Teil des Interviews sprechen wir darüber, ob die Medaille auch eine andere Seite hat, und werfen einen Blick voraus.

Weitere Informationen:
Flexibles Content Management mit TYPO3
Individualität und Funktionenvielfalt dank mächtiger TYPO3-Extensions

Warum ist Jira ein wichtiges Instrument für Ihr Unternehmen?

JIRA bietet Unternehmen jederzeit Transparenz über den Fortschritt und die weitere Planung von Projekten. Dabei ist JIRA nicht nur für Projektmanager ein wertvolles Tool, sondern es hilft jedem einzelnen Projektmitglied, den Überblick über aktuelle eigene Aufgaben und deren Prioritäten zu behalten.

JIRA erlaubt es, Aufgaben kategorisiert nach Typen anzulegen. Die Aufgaben können nach der Erstellung an die einzelnen Projektmitglieder delegiert werden. Durch selbst anpassbare Workflows besteht die Möglichkeit, die Bearbeitung von Aufgaben optimal auf bereits existierende Prozesse in Ihrem Unternehmen abzubilden. Durch die durchdachte und einfach zu bedienende Web-Oberfläche können Projekt-Teams kollaborativ und effektiv auch an unterschiedlichen Orten arbeiten. Damit ermöglicht JIRA ein professionelles, systematisches und effektives Fehler-, Aufgaben- und Qualitätsmanagement und unterstützt die agile Software-Entwicklung. Das System richtet sich aber, im Gegensatz zu anderen Bug-Tracking-Anwendungen, an Programmierer und das Management gleichermaßen.

Projektplanung und Controlling mit Jira

JIRA bietet vor allem im Bereich der agilen Software-Entwicklung sehr hilfreiche Tools. Zusammen mit der Ergänzung Greenhopper lassen sich Aufgaben in verschiedenen Ansichten übersichtlich darstellen und direkt bearbeiten. Über die Ajax-Oberfläche ist eine schnelle und angenehme Arbeitsweise möglich. So lassen sich beispielsweise Aufgaben in der Planungsansicht per Drag-and-Drop in verschiedene Releases ziehen.

Auch das Projekt-Controlling ist mit JIRA effektiv. Es gibt zahlreiche Möglichkeiten, über Portlets direkt auf der Startseite oder bei Bedarf über direkt abrufbare Projektstatusberichte den aktuellen Fortschritt und den Zeitaufwand des Projektes im Auge zu behalten.

Die tägliche Arbeit mit Jira

Für alle Mitarbeiter bietet JIRA einen Überblick über sämtliche eigenen Aufgaben und auch über alle Aufgaben des Projekt-Teams. JIRA hilft über eine personalisierte Startseite mit auswählbaren Portlets, die wichtigsten Aufgaben und Informationen individuell im Blick zu behalten.

JIRA erfüllt also alle Erwartungen an eine effektive Aufgabenverwaltung. Zusätzlich kann JIRA sehr individuelle Anforderungen abbilden und ermöglicht effizientes Arbeiten durch einfache, intuitive Benutzeroberflächen.

Gründe für //SEIBERT/MEDIA

//SEIBERT/MEDIA verfügt über umfassende Erfahrungen mit JIRA. Wir verwenden das System in unseren eigenen Projekten sowie in Kundenprojekten. Außerdem unterstützen wir Unternehmen bei der JIRA-Einführung. Wir beraten Sie, richten das System ein und integrieren es in Ihre bestehende Infrastruktur. Wir passen die Software Ihren unternehmensspezifischen Prozessen an und kümmern uns um die Migration von bestehenden Aufgaben aus anderen Tools. Zudem führen wir Workshops und Schulungen durch.

Gerne setzen wir Ihnen kostenlos und unverbindlich eine JIRA-Testinstanz auf, damit Sie das System ausführlich kennenlernen können. Zudem ist //SEIBERT/MEDIA offizieller Partner des JIRA-Herstellers Atlassian und kann Ihnen einen attraktiven Rabatt auf die Lizenzkosten anbieten. Füllen Sie einfach das Kontakformular auf unserer speziellen Seite über JIRA aus.

Weiterführende Informationen

Aufgabenmanagement: Argumente für JIRA
JIRA-Workflows: Aufgaben in systematische und transparente Abläufe überführen
Scrum: Agile Software-Entwicklung bei //SEIBERT/MEDIA

Der Siegeszug des iPhones

Der Hersteller Apple hat durch die Einführung des iPhones nicht nur den Mobiltelefonmarkt umgekrempelt, er hat auch eine mächtige Distributionsplattform für Anwendungen, den App Store, geschaffen. Zusätzlich wurde nach dem Vorbild des iPhones die neueste iPod-Generation, der iPod touch, zum vollwertigen PDA aufgerüstet. Mit mehr als 30 Millionen Geräten weltweit stellen das iPhone und der iPod touch derzeit die beliebtesten und vielfältigsten mobilen Geräte dar.

Anwendungsfälle von Apps und Websites

Durch die vielfältigen Kommunikationsmöglichkeiten können individuell angepasste iPhone-Anwendungen und iPhone-Websites in Ihrem Unternehmen Prozesse und Abläufe verbessern und ergänzen. Von der einfachen mobilen Lagerverwaltung bis hin zu iPhone-Anwendungen, die mit im Unternehmen eingesetzten Software-Systemen kommunizieren, können hochwertige Lösungen erstellt werden. Dazu gehören das interne CRM- und ERP-System, die IT-Infrastruktur, die Überwachungs-Software und viele weitere Anwendungen und Systeme. Solche iPhone-Anwendungen werden entweder im App Store von Apple kommerziell angeboten oder nur im eigenen Unternehmen bereitgestellt.

iPhone für Werbung und Marketing

Die große Anziehungskraft der Marke Apple und das Kultobjekt iPod haben das iPhone binnen kürzester Zeit zu einem Statussymbol gemacht. Mehr und mehr Unternehmen nutzen die Werbewirkung des App Stores aus, um bestehende Inhalte und Angebote in Form einer oder mehrerer iPhone-Anwendungen oder -Spielen zu veröffentlichen. Diese sind teilweise sogar kostenlos. Die iPhone-Anwendungen und –Websites reichen von der einfachen elektronischen Zeitschrift über die Erweiterung von bekannten Web-Applikationen bis hin zu Spielen. Mit einer einfachen iPhone-Website können Sie gezielt diese 30 Millionen Nutzer ansprechen und Ihr bestehendes Website-Angebot ergänzen.

Mit iPhone-Applikationen und iPhone-Websites können Sie nicht nur handfeste Probleme im Unternehmen lösen, sondern Sie können durch die hohe Verbreitung des iPhones auch eine hervorragende Werbewirkung für Ihr Unternehmen erreichen. Darüber hinaus können Sie für die 30 Millionen Anwender, die ein iPhone oder einen iPod touch besitzen, im App Store ein kostenpflichtiges Programm einstellen, mit dem Sie margenträchtigen Umsatz generieren können.

Gründe für //SEIBERT/MEDIA

//SEIBERT/MEDIA betreut bereits mehrere Applikationen für Geschäftskunden. Unsere Entwickler und Mitarbeiter haben erfolgreiche Spiele und Anwendungen im App Store veröffentlicht. Wir konzipieren und entwickeln Spiele und Anwendungen und übernehmen die Vermarktung. Gerne erstellen wir auch iPhone-Websites für Ihre Zielgruppe. Wenn Sie daran interessiert sind, nutzen Sie bitte das Kontaktformular auf unserer speziellen Seite zum Thema iPhone-Applikationen und -Websites.

Was ist Grails?

Grails ist der junge Aufsteiger unter den Web-Entwicklungs-Frameworks. Es baut auf der dynamischen Programmiersprache Groovy auf und ist höchst kompatibel zur Java-Plattform. Grails ist Open Source und wird von einer ständig wachsenden Community weiterentwickelt. Inspiriert von Ruby on Rails arbeitet Grails nach dem Paradigma „Convention over Configuration“. Dadurch macht es die Entwicklung von web-basierten Applikationen deutlich schneller und effizienter.

Welche Vorteile bietet Grails?

Grails schlägt die Brücke zwischen stabiler Java-Programmierung und schneller Web-Entwicklung mit Skriptsprachen. Es ermöglicht die Entwicklung von Web-Anwendungen in Java ohne den typischen „Java-Wasserkopf“. Daraus ergeben sich kürzere Entwicklungszeiten. Grails integriert bewährte Java-Enterprise-Technologien wie Hibernate, Spring und SiteMesh und erlaubt darüber hinaus die Nutzung der Vielfalt und Stabilität aller vorhandenen Java-Frameworks und -Bibliotheken. Mit Grails entwickelte Systeme bieten deshalb die gleiche Systemstabilität, die auch Java auszeichnet. Zudem ist die Ajax-Unterstützung von Grails hervorragend.

Ist eine Integration von Java und Grails möglich?

Diese Frage ist eindeutig mit Ja zu beantworten. Grails integriert sich nahtlos in bestehende Java-Anwendungen und –Plattformen und kann mit all seinen Vorteilen ebenso als Stand-alone genutzt als auch in bestehende Java-Anwendungen integriert werden.

Fazit

Das Web-Entwicklungs-Framework Grails hat sich in den letzten Jahren zu einer enormen Reife entwickelt und ist voll kompatibel zu bestehenden Java-Anwendungen. Bei //SEIBERT/MEDIA haben wir umfangreiche Tests durchgeführt, um zu prüfen, ob Grails mit bestehenden Java-Anwendungen interagieren und funktionieren kann, und mehrere Grails-Projekte erfolgreich realisiert. Grails hat sich dabei bestens bewährt.

Gründe für //SEIBERT/MEDIA

Seit 1996 entwickelt //SEIBERT/MEDIA erfolgreich Web-Software. Mit über 25 Entwicklern erbringen wir jeden Monat mehr als 3.500 Entwicklungsstunden. Von Anfang an haben wir uns mit der Grails- und Groovy-Entwicklung beschäftigt und bereits zahlreiche Enterprise-Projekte umgesetzt.

Planen Sie eine Software in Groovy oder Grails? Haben Sie eine bestehende Java-Software, die Sie mit Groovy- oder Grails-Komponenten erweitern oder verändern möchten? Brauchen Sie Schnittstellen oder planen eine Migration? Wir sind der richtige Ansprechpartner für Ihr Groovy- oder Grails-Projekt. Füllen Sie einfach das Kontaktformular auf unserer speziellen Seite über Grails und Groovy aus.

Weiterführende Informationen

Die Programmiersprache Groovy
Programmiersprachen und Fachbuchabsatz: C# überholt Java, Perl gehört zu den Major Languages

Interessieren Sie sich für Atlassian-Produkte oder Erweiterungen für JIRA oder Confluence? Es gibt gute Gründe für den Kauf von Atlassian-Lizenzen bei //SEIBERT/MEDIA, denn damit sind handfeste Vorteile für Sie verbunden.

1. 10% Naturalrabatt auf die angegebenen Lizenzen

Wir gewähren Neukunden einen einmaligen Rabatt auf die Lizenzkosten für Atlassian-Software in Form von Dienstleistungen. Diese Dienstleistungen umfassen sowohl individuelle Beratung und Beantwortung von Fragen zur Bedienung und Konfiguration der Software als auch Anpassungsarbeiten und Erweiterungen der Anwendung selbst. Zudem können Schulungen und Trainings mit diesem Kontingent durchgeführt werden.

2. Uneingeschränkter Support von Atlassian

Auch wenn Sie Ihre Lizenzen bei //SEIBERT/MEDIA kaufen, erhalten Sie uneingeschränkten Support von Atlassian.

3. Zusätzlich deutscher Support von //SEIBERT/MEDIA

Unsere Spezialisten für Atlassian-Produkte stehen Ihnen und Ihren Kollegen persönlich, per E-Mail und per Telefon zur Verfügung und helfen Ihnen unkompliziert weiter.

4. Hands-on-Unterstützung statt Remote-Befragung

Der Atlassian-Support ist bekannt für schnelle und kompetente Hilfestellungen. Allerdings erfolgt die Unterstützung per E-Mail oder über eine öffentlich zugängliche JIRA-Instanz. Sie müssen Fehler also immer selbst beschreiben und reproduzieren, um Unterstützung zu erhalten. Der //SEIBERT/MEDIA-Support erfolgt dagegen direkt. In engen Kundenbeziehungen erhalten wir in der Regel einen Zugriff auf die entsprechenden Instanzen: Unsere Experten wählen sich im Problemfall gemeinsam mit Ihnen (z.B. in einer Desktop-Sharing-Sitzung) in Ihre Anwendung ein. So können wir mit Ihnen unmittelbar im System arbeiten und Problemquellen häufig direkt und ohne Umschweife identifizieren und Fehler beheben. Das nennen wir Hands-on-Support.

5. Individuelle Beratung und Hilfe im System

Die ersten Schritte in einem Atlassian-Produkt sind mitunter eine Herausforderung. Nur wenn man das System richtig konfiguriert, stellt sich auch der Erfolg ein und werden Ihre Mitarbeiter für die Nutzung aktiviert. Wir helfen Ihnen direkt vom Start weg.

6. Kostenlos: Individuelle Einrichtung und professioneller Start

Dank unserer Naturalrabattlösung erhalten Sie eine kostenlose Einführung und Hilfestellungen bei der Einrichtung der Software. Das umfasst strategische, inhaltliche, gestalterische, programmiertechnische und systemadministrative Aspekte.

7. Schnittstelle zum englischsprachigen Atlassian-Support

Spezielle Fragen, die wir selbst nicht beantworten können, reichen wir für Sie an den Atlassian-Support weiter. Dabei übernehmen wir für Sie die Vermittlung zwischen deutsch- und englischsprachigen Nutzern und kommunizieren mit Atlassian, bis es eine Lösung gibt.

8. Keine Abnahmepflicht von Dienstleistungen

Wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, erhalten Sie kostenfreie Dienstleistungen als Naturalrabatt. Sie müssen diese Leistungen allerdings nicht abnehmen und erst recht keine kostenpflichtigen Leistungen nachbestellen. Unser Angebot beinhaltet keine Abnahmepflichten.

9. Kostenfreie Atlassian-Video-Schulungen für Ihr Intranet

//SEIBERT/MEDIA nimmt in unregelmäßigen Abständen Video-Tutorials auf, die Sie verwenden können, um Ihre Mitarbeiter zu schulen und sie mit den Funktionen des Systems vertraut zu machen. Wir stellen Ihnen diese Anleitungen kostenfrei zur Verfügung.

10. Tipps, Tricks und Anwender-Know-how im Newsletter

Unsere Kunden erhalten von uns monatlich einen Newsletter mit 10 oder mehr Fachartikeln rund um Internet- und Intranet-Technologie, sie sich häufig auch mit Atlassian-Produkten befassen. Unser Tiefen-Know-how teilen wir regelmäßig und unaufgefordert mit Ihnen.

11. Kauf auf Rechnung bei deutschem Dienstleister

Bei uns müssen Sie nicht im Internet mit Kreditkarte bestellen, sondern erhalten eine Rechnung nach deutschen Steuervorgaben und können diese nach Erhalt und Prüfung der Lizenzen mit einer Zahlungsfrist von 14 Tagen über etablierte Beschaffungswege bezahlen und abwickeln.

Tatsächlich ist der Erwerb von Atlassian-Lizenzen bei //SEIBERT/MEDIA attraktiver als direkt bei Atlassian und hat für Sie ausschließlich Vorteile. Es gibt keine Haken und keine Ösen: Sie zahlen die gleichen Gebühren wie bei Atlassian und erhalten alle Rechte und Möglichkeiten wie bei einem Direktkauf. Wenn Sie die oben genannten Vorteile interessieren, ist eine Beauftragung von //SEIBERT/MEDIA mit Sicherheit die interessantere Alternative. Bitte sprechen Sie uns an oder füllen Sie einfach das entsprechende Kontaktformular auf unseren speziellen Seiten zu JIRA und Confluence aus.

Weiterführende Informationen

Confluence: Ausgereift, viele Funktionen, gute Usability (Vodcast)
Aufgabenmanagement: Argumente für JIRA
JIRA-Workflows: Aufgaben in systematische und transparente Abläufe überführen

Was ist Perl?

Perl ist die Essenz aus zahlreichen Programmiersprachen und Werkzeugen, deren Vorteile sie in sich vereint. Perl besitzt die Vorzüge einer Interpreter-Sprache und ist durch die Interpretation enorm flexibel und individuellen Bedürfnissen anpassbar. Bei der Perl-Programmierung können Entwickler gleiche Algorithmen-Darstellungen auf verschiedene Weise ausdrücken. Objektorientierte Module lassen automatisierte Unit-Tests zu, die für höchste Qualität sorgen. Mit der Nutzung von CPAN stehen mehr als 10.000 ausgereifte, etablierte und in der Praxis erprobte Module zur Verfügung. CPAN ist ein weltweit gespiegeltes Online-Repository für Perl-Module, Anwendungen und Dokumentationen.

Warum auf Perl setzen?

Erfahrene Perl-Entwickler wie die Programmierer von //SEIBERT/MEDIA/TECHNOLOGIES arbeiten mit professionellen Versions-Kontrollsystemen wie Subversion und Git. Lösungen mit Perl sorgen für höchste Verfügbarkeit und Performance. Wir legen Wert auf eine individuelle und plattformunabhängige Software-Entwicklung sowie auf skalierbare Software-Lösungen, die sich leicht warten lassen und individuell anpassbar sind. Dies ermöglicht die Perl-Programmierung. So lassen sich Internet-Anwendungen entwickeln, die auch im Nachhinein flexibel ausgebaut, verändert und erweitert werden können. Mit Perl kann rasch hochwertige und individuelle Software entstehen, denn die Perl-Programmierung stellt bei maximaler Freiheit für den Entwickler sehr schnelle Ergebnisse sicher. Das ist ein großer Vorteil für Ihre Software.

Gründe für //SEIBERT/MEDIA

In Sachen Perl kennt //SEIBERT/MEDIA sich so gut aus wie kaum ein anderes Unternehmen in Deutschland. Seit 1996 arbeiten wir mit dieser Programmiersprache im Internet. Über 25 Entwickler arbeiten in kleinen und teilweise auch größeren Projekten, in denen bis zu 40 Vollzeitangestellte achtstellige Budget-Volumina verantworten.

Haben Sie eine Applikation in Perl? Möchten Sie eine ergänzen, erweitern oder eine Schnittstelle schaffen? Möchten Sie von oder zu Perl migrieren? Dann sind wir der richtige Ansprechpartner. Füllen Sie einfach das Kontaktformular auf unserer speziellen Seite zum Thema Perl-Programmierung aus.

Weiterführende Informationen

Die Website von //SEIBERT/MEDIA/TECHNOLOGIES
Programmiersprachen und Fachbuchabsatz: C# überholt Java, Perl gehört zu den Major Languages

In Web-Communities wird gern gemahnt: „Don’t feed the troll.“ Die Annahme: Wenn User nicht auf Provokationen eingehen und Provokation somit ins Leere läuft, verliert der Troll rasch die Lust und sucht sich eine andere Spielwiese. Haben auch Enterprise-Wikis mit Trollen zu schaffen? Gibt es so etwas wie Wiki-Trolle, die im Firmenwiki ihr Unwesen treiben?

Zunächst ist es wichtig, konstruktive (und selbst unverblümte) Kritik von Trollerei zu unterscheiden. Ein Troll provoziert Leute, er verdreht Aussagen ins Negative, während sich Kritik auf ein konkretes Problem bezieht.

Jemand, der Kritik äußert und auf ein Problem hinweist, würde vielleicht sagen: „Doof, die PDF-Exportfunktion crasht, wenn das Dokument länger als zehn Seiten ist. Darum solltest Du Dich doch kümmern!“ Ein Troll dagegen würde schreiben: „Das ist alles Mist!“

Trollerei kommt in einem Unternehmens-Wiki – wenn überhaupt – sehr selten vor. Jede Änderung ist personalisiert und kann zurückverfolgt werden; jeder vernünftige Mitarbeiter wird sich hüten, gefährliche Dummheiten anzustellen. Der etwa aus Wikipedia bekannte Vandalismus spielt in einem Enterprise Wiki so gut wie keine Rolle.

Hat ein Wiki aber auch einen öffentlichen Bereich, in dem beispielsweise Dokumentationen zur Verfügung stehen oder Support angeboten wird, tritt auch schnell ein Troll auf den Plan. Hier empfehle ich, diesen zumindest vor die Hürde einer obligatorischen Registrierung zu stellen, die häufig abschreckend wirkt. Dies gefällt zwar auch einigen Nutzern mit lauteren Absichten nicht besonders, ist aber wohl ein notwendiger Kompromiss.

Was allerdings, wenn trollhaftes Verhalten nun doch im Enterprise-Wikis zu beobachten ist? Eine Möglichkeit ist die, dass diese Aktivitäten von einer Person ausgehen, die mit dem Wiki und mit dieser Form der Zusammenarbeit hadert. (Der Wiki-Troll ist jedoch nicht mit dem Wikiphobiker zu verwechseln. Während dieser das System rundweg ablehnt und sich gar nicht erst beteiligt, agiert der Wiki-Troll ja im Wiki; er „bekämpft“ es sozusagen von innen.) Diese Person ist normalerweise schnell identifiziert. Ebenso rasch ist sie zur Seite genommen und ihr unmissverständlich erklärt, dass ihr Verhalten dem Unternehmen Schaden zufügt.

Eine zweite – und die wahrscheinlichere – Möglichkeit ist die, dass der Troll nur ein vermeintlicher ist und schlicht das Wesen eines Unternehmens-Wikis und die damit verbundene Netiquette nicht verstanden hat. Diesem Mitarbeiter muss man sich intensiv widmen und sich bemühen, ihm das Wiki-Konzept nahezubringen und die Philosophie begreiflich zu machen, für die ein Wiki steht.

Es ist wichtig herauszufinden, warum ein Mitarbeiter im Wiki unangebrachtes Verhalten an den Tag legt. Hat man die Ursache identifiziert und die betreffende Person direkt angesprochen, ist die Trollerei alsbald Geschichte; das Wiki kann seinen Zweck erfüllen und die effiziente und effektive Zusammenarbeit unterstützen. In aller Regel ist Trollerei im Firmenwiki lediglich ein Missverständnis.

Dieser Beitrag basiert auf dem Artikel „Wiki Troll“ von Stewart Mader. Stewart Mader gehört zu den führenden und einflussreichen Wiki-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.ikiw.org. Weitere Artikel von Stewart Mader finden Sie in unserem Wiki-Special.

Woher weiß ich, ob die Inhalte im Wiki korrekt sind?
Die Inhalte im Wiki sind so korrekt wie Inhalte auf Papier, auf CD, in Word oder in E-Mails: Das Medium sagt in keinem Fall etwas über die Korrektheit des Inhalts aus. In einem Enterprise-Wiki wird kein Mitarbeiter absichtlich falsche Informationen veröffentlichen. Und ist einmal versehentlich ein Fehler aufgetreten, kann er mühelos behoben werden.

Wer kontrolliert die Inhalte auf Fehler?
Ein Wiki unterliegt nicht der Kontrolle einer einzelnen Person. Die eigentliche Kontrollinstanz ist die Gemeinschaft der User. Voraussetzung für den Erfolg eines Wikis ist das Leitbild: Jeder darf Fehler machen und jeder darf und soll auf Fehler hinweisen.

Wie gehe ich vor, wenn ich auf einen Satz stoße, der grammatikalisch völlig falsch und unverständlich ist?
Kleine Fehler sollte jeder Mitarbeiter beheben, wenn er sie sieht; das entspricht dem Community-Gedanken eines Wikis. Auf größere Unklarheiten kann jederzeit über die Kommentarfunktion aufmerksam gemacht werden. Der Autor des fehlerhaften Textes wird den Kommentar per automatischer Benachrichtigung (E-Mail oder RSS) oder beim nächsten Bearbeiten des Textes zur Kenntnis nehmen und Anregungen berücksichtigen.

Kann ich Inhalte, die für das Wiki vorgesehen sind, offline erstellen?
Ja, und gerade bei längeren Texten empfiehlt sich dieses Vorgehen schon wegen der Fehlerkorrektur in Textverarbeitungen.

Kann ich im Wiki Anhänge wie Bilder oder PDFs verwenden?
Ja. Die Möglichkeit, externe Dokumente und Dateien in Wiki-Seiten einzubinden, ist eine der wertvollsten Eigenschaften von Systemen wie Foswiki und Confluence.

Kann ich Wiki-Inhalte in DOC- oder PDF-Dateien transferieren?
Ja. Wiki-Dokumente bestehen fast immer aus reinem Text, der via Copy & Paste in Textverarbeitungen und andere Applikationen kopiert werden kann. Außerdem gibt es Plugins zur Konvertierung von Wiki-Seiten in PDF-Dokumente.

Haben Sie weitere Fragen? Antworten finden Sie auch in unseren anderen FAQ-Artikeln zu den ersten Schritten und zur Sicherheit im Wiki sowie auf unseren speziellen Seiten zu den Themen Firmenwikis, Foswiki und Confluence.

Download (1,1 MB): Unsere Wiki-Broschüre auf deutsch (PDF)
Download (1,1 MB): Our wiki brochure in English (PDF)

Können bestimmte sensible Inhalte, die nicht jeder Mitarbeiter sehen soll, besonders geschützt werden?
Ein professionelles Enterprise-Wiki-System wie Foswiki oder Confluence verfügt über eine leistungsfähige Funktion zur Vergabe von Rechten. Es ist problemlos möglich, spezielle Bereiche zu schützen und diese beispielsweise ausschließlich besonderen Team-Mitgliedern zugänglich zu machen. Allerdings sollten Restricted Areas mit Bedacht und nur nach gründlicher Überlegung eingerichtet werden, denn Mitarbeiter könnten sich fragen, warum das Unternehmen von ihnen die Weitergabe des eigenen Wissen erwartet und ihnen gleichzeitig Informationen vorenthält.

Soll ich das Wiki kontrollieren und alle Änderungen erst freigeben?
Es besteht ein feiner Unterschied zwischen Zugangs- und Inhaltskontrolle. Ein Wiki lebt von seinem organischen Wachstum und ist eine sich ständig erweiternde Wissensbasis, der zu viel Kontrolle eher schadet, denn Überwachung schreckt ab. Die Ausarbeitung und Etablierung von Richtlinien, die für alle User verbindlich sind, ist vielleicht der wirksamste Kontrollmechanismus.

Braucht ein Wiki nicht einen Moderator?
Wer diese Frage stellt, denkt an Vandalismus, Editier-Kriege und Wikipedia. Ein Enterprise-Wiki ist aber nicht Wikipedia. Solche Phänomene treten in einem Firmenwiki nicht auf, da jede Änderung sich problemlos auf den Urheber zurückführen lässt. Ein Wiki braucht einen Ansprechpartner bzw. Experten für technische und organisatorische Belange und keinen Überwacher.

Kann man Dokumente für Änderungen sperren?
Ein ausgereiftes Wiki-System verfügt über eine fein justierbare Rechtevergabe, und Dokumente können über eine solche für die Bearbeitung gesperrt werden. Das wäre allerdings nur sinnvoll, wenn Mitarbeiter sich tatsächlich ernsthaft über Inhalte streiten und sich einen Editier-Wettkampf liefern würden. Um es zu wiederholen: In einem Enterprise-Wiki ist ein solches Szenario praktisch ausgeschlossen.

Haben Sie weitere Fragen? Antworten finden Sie auch in unseren anderen FAQ-Artikeln zu den ersten Schritten und den Wiki-Inhalten und -Dokumenten sowie auf unseren speziellen Seiten zu den Themen Firmenwikis, Foswiki und Confluence.

Download (1,1 MB): Unsere Wiki-Broschüre auf deutsch (PDF)
Download (1,1 MB): Our wiki brochure in English (PDF)

Wie bekomme ich Mitarbeiter dazu, die E-Mail-Kommunikation zu reduzieren und stattdessen vermehrt das Wiki zu nutzen?
Das Wiki soll die E-Mail nicht ablösen, sondern dient der systematischen Abbildung von Know-how und von Abläufen. Zunächst empfiehlt es sich, dynamische und/oder für viele Mitarbeiter relevante Informationen, die bislang per E-Mail verbreitet wurden, im Wiki abzulegen und lediglich den Link per E-Mail zu versenden. Über kurz oder lang wird die Akzeptanz des neuen Systems zunehmen und Mitarbeiter werden früher oder später ohne E-Mail-Hinweise ins Wiki gehen.

Ersetzt ein Wiki Meetings und mündliche Diskussionen?
Nein. Mit einem Wiki lassen sich Meetings jedoch deutlich effizienter vorbereiten. Zudem gibt es Kollegen, denen es leichter fällt, sich schriftlich und nicht im persönlichen Gespräch auszudrücken. Vom zusätzlich kommunizierten Know-how profitieren alle.

Womit fange ich an?
An ein neues System muss man sich herantasten. Eine bewährte Methode besteht darin, sich zunächst in der Sandbox des Wikis zu versuchen und die ersten Möglichkeiten der Applikation kennenzulernen. Auch das Anlegen einer persönlichen Seite eignet sich dazu, Funktionen zu testen. Ein Wiki lebt zudem von der Community, die neuen Usern stets einen erfahrenen Ansprechpartner zur Verfügung stellt.

Was stelle ich ins Wiki?
Das hängt davon ab, welche Funktionen das System erfüllen soll. Als organisches Wissens-Management-System ist ein Wiki vor allem ein Organisations-System und ein Pool für Informationen, die von relativ dauerhafter Relevanz sind. Dabei kann es sich um Vorlagen, wiederkehrende Abläufe, interne Hinweise usw. usf. handeln. Generell gehört alles, was für ein Team interessant und für ein Projekt oder einen Ablauf wichtig ist, auch ins Wiki.

Können andere ändern, was ich geschrieben habe?
Ja. Die wesentliche Funktion eines Wikis besteht darin, dass alle Beteiligten ihr Wissen beitragen. Wer Zugang und Nutzungsrechte zu den gleichen Wiki-Bereichen hat, kann auch Änderungen vornehmen, Inhalte ergänzen und Know-how beitragen. Gerade deshalb sind Wikis so mächtig.

Wie sehe ich, was in einem Dokument geändert wurde?
Jede Änderung wird in der Seitenhistorie gespeichert. Über die Revisions-Funktion sind alle Modifikationen jederzeit nachvollziehbar.

Teilt das Wiki mir Modifikationen mit?
Ja. Über Änderungen in einzelnen, mehreren oder allen Dokumenten eines Wiki-Webs kann man sich per RSS-Feed oder via E-Mail-Benachrichtigung automatisch informieren lassen.

Kann ich Inhalte einfach löschen, wenn mir nicht gefällt, was ein Kollege geschrieben hat?
Im Grunde ja. Aber das ist nicht der Sinn eines Wikis, sondern widerspricht dem Wiki-Konzept der Transparenz und der Kollaboration. Besser ist es, Inhalte nicht zu löschen, sondern zu ändern oder zu diskutieren. Dafür gibt es eine Kommentar-Funktion, die in jedes Dokument eingebunden werden kann.

Haben Sie weitere Fragen? Antworten finden Sie auch in unseren anderen FAQ-Artikeln zu Wiki-Inhalten und -Dokumenten und zur Sicherheit im Wiki sowie auf unseren speziellen Seiten zu den Themen Firmenwikis, Foswiki und Confluence.

Download (1,1 MB): Unsere Wiki-Broschüre auf deutsch (PDF)
Download (1,1 MB): Our wiki brochure in English (PDF)

Was ist Confluence?

Confluence ist das etablierte und populäre kommerzielle Enterprise-Wiki-System des australischen Software-Unternehmens Atlassian. Im Hinblick auf Funktionsumfang, Usability, Ausgereiftheit und Support ist Confluence jeder anderen Wiki-Software überlegen. Über 6.000 Unternehmensinstallationen in aller Welt sprechen eine deutliche Sprache: Confluence ist Marktführer unter den lizenzpflichtigen Wiki-Systemen. Zu den Unternehmen und Organisationen, die Confluence erfolgreich einsetzen, gehören z.B. Cisco, IBM, Sun, die Deutsche Nationalbibliothek, BBC, CERN und die Vereinten Nationen, um nur einige Namen zu nennen.

Was zeichnet Confluence aus?

Confluence ist ohne Zweifel das mächtigste Enterprise-Wiki am Markt und verfügt über zahlreiche überlegene Plugins, die auf die Bedürfnisse von Unternehmen zugeschnitten sind. Ein großer Vorzug von Confluence ist die ausgezeichnete Usability: Der WYSIWYG-Editor ist intuitiv bedienbar, das Konzept zur Verwaltung von Spaces ist ausgereift. Auch hat Confluence eine hervorragende Suchmaschine – ein Schwachpunkt vieler anderer Wikis. Ein weiterer Vorteil ist der sehr nutzerfreundliche Administrationsbereich. Das Layout des Systems lässt sich schnell und einfach modifizieren und gut an das Corporate Design Ihres Unternehmens anpassen – ein nicht zu vernachlässigender Faktor für die erfolgreiche Etablierung eines Wikis. Zudem verfügt Confluence über einen MS-SharePoint-Connector und eine leistungsfähige Office-Schnittstelle. Dadurch können Sie das Wiki zum Beispiel auch aus MS Word befüllen.

Was kostet Confluence?

Der Confluence-Hersteller Atlassian verfolgt eine transparente und überschaubare Preispolitik: Die Lizenzkosten für eine Confluence-Installation liegen zwischen ca. 800 und maximal 6.000 Euro. Die Höhe der Lizenzkosten ist dabei nur am Anfang von der Anzahl der Mitarbeiter abhängig, die mit und in dem System arbeiten – selbst bei Tausenden oder Hunderttausenden Nutzern sind die Gebühren ab dem Maximalbetrag gedeckelt. Confluence ist damit eine günstige Alternative für große und sehr große Unternehmen sowie auch ein preiswerter Einstieg für Kunden mit weniger Mitarbeitern.

Viele unternehmensspezifische Funktionen, Erweiterbarkeit und Kompatibilität zu anderen Systemen, eine sehr gute Usability und eine nachvollziehbare Lizenzpolitik – all diese Fakten sprechen für Confluence.

Warum ist //SEIBERT/MEDIA der richtige Partner für Ihr Confluence-Projekt?

Als Spezialist für Firmenwikis verfügt //SEIBERT/MEDIA über umfassende Erfahrungen mit Confluence. Wir haben zahlreiche Enterprise-Wiki-Projekte von der Konzeption über das Design und die Programmierung bis hin zu Schulungs- und Einführungsprogrammen erfolgreich realisiert. Gerne setzen wir Ihnen eine kostenlose Confluence-Testinstanz auf, damit Sie das System unverbindlich kennenlernen können. //SEIBERT/MEDIA ist offizieller Atlassian-Partner und kann Ihnen einen attraktiven Rabatt auf die Lizenzkosten anbieten. Füllen Sie für Ihre Anfrage einfach das Kontaktformular auf unserer speziellen Seite zum Thema Confluence aus.

Weitere Informationen

Confluence 3.0: Das führende kommerzielle Enterprise-Wiki geht in die nächste Runde
Wikis brauchen ein individuelles Design
Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?

Download (1,1 MB): Unsere Wiki-Broschüre auf deutsch (PDF)
Download (1,1 MB): Our wiki brochure in English (PDF)

Die Idee dahinter ist ebenso naheliegend wie überzeugend: Die Leute finden deutlich mehr Gefallen an etwas Neuem, wenn sie selbst herausfinden, dass sie es aktiv und sinnvoll nutzen können und dass es sie weiterbringt. Das ist etwas völlig anderes als eine Verordnung von oben, als die Anweisung, ein neues System von nun an verbindlich nutzen zu müssen. Gerade so ein Vorgehen ist gefährlich, weil es den Erfolg der Wiki-Einführung gefährden kann.

Wenn Mitarbeiter ein Tool nur deshalb nutzen, weil sie es nutzen müssen, es ihnen das Leben und die Arbeit aber nicht erleichtert oder es schwer zu erlernen und sehr restriktiv ist, werden sie es, sobald ihnen niemand kontrollierenderweise über die Schulter schaut, einfach sein lassen. Die Leute müssen das Konzept begreifen, das Wesen eines Wikis verstehen, um seinen Nutzen zu erkennen. Dabei handelt es sich um einen (sehr individuellen) Prozess, der nicht per Dekret angeordnet und ausgelöst werden kann.

Ein Wiki ist ein Tool, das die Leute begeistert, wenn sie erst einmal herausgefunden haben, wie sie damit arbeiten können und dass es ihnen die tägliche Arbeit tatsächlich erleichtern kann. Diese Mitarbeiter werden ihren Kollegen von ganz allein davon erzählen, sie werden beim Kaffee berichten, wie dieses neue System sich auf ihre Arbeitsweise auswirkt. Das ist die Voraussetzung für eine Art von Wachstum, die nachhaltig ist, und diese Prozesse gilt es zu unterstützen.

Meine Empfehlung: Wenn Sie in Ihrem Unternehmen ein Wiki etablieren wollen, zwingen sie niemanden dazu, es zu nutzen. Sorgen Sie vielmehr dafür, dass es verfügbar ist, lassen Sie die Leute allmählich und von ganz allein herausfinden, wie sie es optimal nutzen können und worin sein eminenter Nutzen besteht. (Hier sind Ihre beispielhaften Aktivitäten im Wiki ebenso wichtig wie Geduld und ein gewisses Maß an Zurückhaltung.)

Nach und nach werden Ihre Mitarbeiter neue Möglichkeiten entdecken, Sachen zu erledigen, und typische Arbeitsabläufe und Prozesse im Unternehmen neu erfinden. Nehmen Sie – auch das gehört zum Graswurzelkonzept – diese Vorschläge unvoreingenommen an, es kann sich um unglaublich wertvolle Ideen und Verbesserungen handeln.

Dieser Artikel wurde im Original als Vodcast unter dem Titel „Grassroots is Best“ von Stewart Mader veröffentlicht. Stewart Mader gehört zu den führenden und einflussreichen Wiki-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.ikiw.org. Weitere Artikel von Stewart Mader finden Sie in unserem Wiki-Special.

Was ist Foswiki?

Foswiki ist eine webbasierte Wiki-Software für den Einsatz in Unternehmen, mit der Nutzer Web-Seiten in einem gewöhnlichen Browser bearbeiten können. Foswiki wird in Unternehmen als Team-Portal, Wissens-Pool, Projektmanagement-Tool, Planungs-Tool und Diskussionsplattform genutzt. Die Möglichkeiten, Fowsiki im Unternehmen einzusetzen, sind nahezu unbegrenzt.

Foswiki ist Open-Source-Software und damit vollständig kostenlos. Es entstehen Ihnen weder Lizenzkosten für das System selbst noch für die weit über 100 verfügbaren Erweiterungen. Zudem steht hinter Foswiki eine sehr aktive und ambitionierte Community, die die Software ständig weiterentwickelt und vorantreibt. //SEIBERT/MEDIA beteiligt sich auch an dieser Weiterentwicklung.

Was bietet Foswiki?

Eine der wichtigsten Funktionen von Foswiki ist die Versionskontrolle: Jede Änderung an den Inhalten wird festgehalten und ist zurückverfolgbar; das Thema Vandalismus erübrigt sich dadurch. Foswiki bietet eine fein justierbare Rechtevergabe für einzelne Nutzer und Nutzergruppen. Sie können also ganz genau festlegen, wer Inhalte anschauen oder ändern darf.

Um Nutzern die Veränderung von Inhalten so einfach wie möglich zu machen, kommt bei Foswiki ein auf TinyMCE basierender WYSIWYG-Editor zum Einsatz. Sie brauchen also keine Kenntnisse in einer bestimmten Auszeichnungssprache, um Änderungen durchführen zu können, sondern arbeiten fast wie in einem Textverarbeitungsprogramm.

Foswiki bietet über 100 Erweiterungen und sorgt so für zusätzliche Funktionalität. Sie können Foswiki dadurch genau Ihren Bedürfnissen anpassen: Legen Sie z.B. To-do-Listen mit dem ActionTracker-Plugin an, erstellen Sie Präsentationen mit dem SlideShow-Plugin direkt in Foswiki oder implementieren Sie eine kleine Business-Intelligence-Lösung mit dem Chart-Plugin.

Dank der anpassbaren Oberfläche ist es möglich, Foswiki an das Corporate Design Ihres Unternehmens anzugleichen. Das schafft Identifikation mit dem System und sorgt so dafür, dass Ihre Kollegen Foswiki auch gerne nutzen.

Wodurch unterscheidet sich Foswiki von anderen Systemen?

Ein interessanter Unterschied zu anderen Systemen ist die einfache Programmierung von Anwendungen mithilfe von sogenannten Metadaten: Sie können in Foswiki-Seiten Variablen sowie Formulare aus dem Quelltext der Seite erzeugen und verarbeiten und so ohne tiefergehende Programmierkenntnisse formularbasierte Anwendungen und Online-Datenbanken (beispielsweise für Vertriebsinformationen) entwickeln.

Foswiki eignet sich optimal für den Einsatz als Unternehmens-Wiki. Mit seinen zahlreichen Erweiterungen können Sie Foswiki genau auf Ihre Bedürfnisse abstimmen. Die einfache Bedienung ermöglicht es jedem Mitarbeiter, Foswiki im Geschäftsalltag zu nutzen, um z.B. interne Abläufe, wichtige Informationen oder Projektstände zu dokumentieren und auf Dauer abzubilden.

Gründe für //SEIBERT/MEDIA

//SEIBERT/MEDIA ist Spezialist für Foswiki. Mit unseren vier Kompetenzbereichen Consulting, Design, Technologies und Systems sind wir genau der richtige Partner, um Sie bei der Einführung von Foswiki zu unterstützen. Wir helfen Ihnen bei der Einführung des Systems, der individuellen Gestaltung der Oberfläche und beim dauerhaften Betrieb. Gerne setzen wir kostenlos und unverbindlich eine Testinstanz von Foswiki für Sie auf, damit Sie die Software kennenlernen können. Füllen Sie für Ihre Anfrage einfach das Formular auf unserer speziellen Seite zum Thema Foswiki aus.

Weitere Informationen

TWiki ist jetzt Foswiki: Unternehmen steigen um
Foswiki-Update: Version 1.0.4 ist erschienen
Foswiki-Tutorial: Dokumente erstellen und gemeinsam bearbeiten
Wikis brauchen ein individuelles Design
Wiki-Studie: Was bringen Wikis konkret und welche Probleme treten auf?

Download (1,1 MB): Unsere Wiki-Broschüre auf deutsch (PDF)
Download (1,1 MB): Our wiki brochure in English (PDF)

Entwickelt wurde das Tool von den Brüdern Lars und Jens Rasmussen, die schon an Google Maps maßgeblich beteiligt waren. Im Laufe des Jahres soll Wave als Open-Source-Anwendung (!) frei zugänglich gemacht werden.

Das Konzept

Steht nun so etwas wie eine Revolution der (Unternehmens-)Kommunikation ins Haus? Google Wave (das auf HTML 5 basiert und also komplett im Browser arbeitet) ist in GWT (Google Web Toolkit) programmiert. (Dieses Framework wird auch //SEIBERT/MEDIA in Kürze im Projekteinsatz verwenden.) Wave wartet in der Tat mit einem völlig neuen Konzept auf und soll die Online-Kommunikation und -Zusammenarbeit gehörig verändern. Das Ziel ist kein geringeres, als die heute etablierten Kommunikations- und Kollaborations-Tools in einem System zu vereinen.

„Zwei der erfolgreichsten Wege der digitalen Kommunikation, E-Mail und Instant Messaging, wurden bereits in den 60er Jahren entwickelt. Seitdem sind so viele verschiedene neue Wege eingeschlagen worden – Blogs, Wikis, kollaborative Dokumente etc. –, Computer und Netzwerke haben sich enorm verbessert. Mit Google Wave schlagen wir eine neue Art der Kommunikation und Online-Zusammenarbeit vor, die diese Fortschritte zum Ausgangspunkt hat.“
Lars Rasmussen

Auf einer Web-Oberfläche (die einen sehr guten Eindruck macht, soweit das derzeit zu beurteilen ist; über die Usability lassen sich indes freilich noch keine Aussagen treffen, zumal Google zuletzt auch unbefriedigende Ergebnisse geliefert hat) werden alle Elemente einer Konversation (E-Mail-Nachrichten, Chats, Videos oder Dokumente) in einer sogenannten Wave zusammengefasst. Diese können nach dem Wiki-Prinzip mehrere Nutzer gleichzeitig einsehen, modifizieren und ergänzen und so miteinander kommunizieren und zusammenarbeiten.

Die Wave wird von einem User gestartet, der andere Nutzer einlädt, an der Kommunikation teilzunehmen. Diese können nun sämtliche Inhalte der Wave selbst bearbeiten oder ergänzen. Alle Veränderungen werden in Echtzeit aktualisiert und dabei protokolliert. Dank einer Replay-Funktion ist der Verlauf der Wave bis zum Anfang zurückverfolgbar.

Lars Rasmussen weiter:

„Eine Wave ist gleichzeitig Unterhaltung und Dokument. In der Wave kann man sich unterhalten (und dabei Bilder, Videos, Maps und mehr einbinden) und vor allem auch gemeinsam arbeiten.”

Soweit das Grundkonzept. Was soll Google Wave nun tatsächlich können?

Die wichtigen Features

Live Transmission: Alle Inhalte einer Wave werden in Echtzeit und für alle Teilnehmer der Wave aktualisiert. Wartezeiten sollen so verkürzt und die Konversation deutlich schneller als per E-Mail oder Chat werden. (Die Funktion Live-Aktualisierung wird optional für jede Wave deaktivierbar sein.)

Conversation History: Personen, die später an einer Wave mitarbeiten, können den kompletten Verlauf einsehen, da dieser vollständig protokolliert wird.

Private Reply: Innerhalb einer Wave sind jederzeit geschützte, private Konversationen möglich, die nur für die teilnehmenden Personen einsehbar ist.

Attachements: Anhänge können einfach per Drag-and-Drop in eine Wave integriert werden. Bilder, die in eine Wave gezogen werden, erscheinen sofort bei den anderen Teilnehmern.

Neue Waves: Jede bestehende Wave kann zu einer neuen Wave konvertiert und als neue Wave ohne Historie nach Belieben weiterbearbeitet werden.

Live-Übersetzung (Rosy): Diese Erweiterung soll in Echtzeit zwischen 40 Sprachen übersetzen und die Kommunikation mit anderssprachigen Personen erleichtern. (Auf die Qualität darf man gespannt sein.)

Rechtschreibprüfung (Spelly): Spelly ist die in Google Wave integrierte Rechtschreibprüfung, die Eingaben schon während des Schreibens analysiert und korrigiert bzw. gegebenenfalls Korrekturangebote macht. Per Spell Checker werden Tippfehler korrigiert.

Suche (Searchy): Searchy ist  eine sehr schnelle Suchfunktion, die live aktualisiert wird, sobald neuer, passender Inhalt vorhanden ist.

Blog-/Kommentarfunktionen (Bloggy): Blogger können eine Wave in den eigenen Blog einbinden, Kommentare im Blog werden als Wave verwaltet. Sämtliche Konversationen in mehreren Blogs sollen über die Google-Wave-Oberfläche administriert werden können.

Links (Linky): Linky wandelt URLs automatisch in Links um. Zudem können andere Waves verlinkt werden. Verlinkte YouTube-Filme bettet die Erweiterung direkt als Videos ein.

Twitter (Tweety): Die Integration des Micro-Blogging-Dienstes Twitter ermöglicht die Tweety-Erweiterung.

Google Maps (Mappy): Die Erweiterung erlaubt die einfache Einbindung von Google-Maps in Waves.

External APIs: Als Open-Source-Software soll Google Wave eine Programmierschnittstelle beinhalten, über die eigene Erweiterungen entwickelt werden können.

Einen eindrucksvollen Überblick über die Features von Google Wave gibt dieses Video, ein kompakter Zusammenschnitt der Präsentation auf der I/O-Konferenz:

Die Aussichten

Ohne in voreilige Begeisterungsstürme ausbrechen zu wollen: Wenn nicht alle ersten Eindrücke täuschen und sich Google Wave nach dem Release schnell verbreitet (und natürlich fehlerlos funktioniert), dürfte Google Wave die (Unternehmens-)Kommunikation gehörig umkrempeln.

Beeindruckend ist die schiere Funktionenvielfalt. Nicht, dass jede Funktionalität für sich revolutionär wäre – ihre Bündelung in einem System ist es mit Sicherheit. Google Wave ist tatsächlich ein „Angriff“ auf E-Mail und Chat, auf Micro-Blogging- und Instant-Messaging-Dienste und selbst auf die sozialen Netzwerke wie Facebook: Diese Funktionen in Verbindung mit wichtigen Wiki-Features soll Google Wave nahezu lückenlos abbilden und sogar um weitere Funktionalitäten wie die Chat-Übersetzung in Echtzeit ergänzen: Bereits in der Demo-Version von Wave ist beispielsweise die vollständige Integration von Twitter zu sehen. Über kurz oder lang wird Google Wave insbesondere Instant-Messaging- und Micro-Blogging-Tools möglicherweise schlicht überflüssig machen.

In der Unternehmenskommunikation könnte Google Wave zunächst partiell einbezogen werden: Insbesondere für Gruppen, die gemeinsam an einem Projekt arbeiten, dürfte Wave eine ausgezeichnete Kommunikations- und Kollaborationsplattform sein. Fraglich ist allerdings, inwiefern Wave mit dem gewohnten E-Mail-Verkehr konkurrieren kann: Momentan kann nicht zwischen dringlichen und weniger wichtigen Nachrichten unterscheiden werden, die nicht sofort stören sollen – ein ernstzunehmender Schwachpunkt.

Voraussetzung dafür ist für viele Unternehmen freilich die Datensicherheit. Wie zumeist, wenn der Name Google im Spiel ist, schlagen auch jetzt die ersten Datenschützer Alarm und fällt das Schlagwort vom „gläsernen Nutzer“. Aus Unternehmenssicht kann hier wohl zunächst Entwarnung gegeben werden: Google Wave wird nicht nur Open Source (und damit an spezifische Bedürfnisse anpassbar) sein, sondern auch als Server-Version zur Verfügung stehen.

Wir sind sehr gespannt, ob es sich bei Wave um die vielbeschriebene „perfekte Welle“ und damit um den nächsten wirklich großen Wurf von Google handeln wird. Vielversprechend ist Google Waves allemal, macht schon jetzt einen sehr ausgereiften Eindruck und fußt auf einem innovativen Konzept. Um ein Strohfeuer handelt es sich aller Voraussicht nach zumindest nicht.

Weitere Informationen:

Die Google-Wave-Website
Die Google-Wave-Website für Entwickler
Google Wave: Die nächste Web-Revolution steht an
Wie Google Wave die Online-Kommunikation verändert
Google Wave: La Ola für Web-Sitzenbleiber

Mitarbeiter der Universität Tampere haben die 50 größten finnischen Unternehmen in Sachen Wiki-Nutzung befragt und ihre ebenso aufschlussreichen wie wichtigen Erkenntnisse in der Studie Experiences of Wiki Use in Finnish Companies zusammengefasst. Im ersten Artikel Wer nutzt Wikis und warum? sind die Verbreitung von Wikis in großen Unternehmen und Argumente für Wikis thematisiert worden. Im Mittelpunkt dieses Beitrags stehen neben dem tatsächlichen Nutzen von Wikis auch Probleme im Zusammenhang mit der Etablierung.

Welche Herausforderungen werden nun mithilfe von Wikis gemeistert und welche Prozesse verbessert? Welchen konkreten Nutzen haben Wikis also in der Unternehmenspraxis? Die teilnehmenden Unternehmen, die bereits mit Wikis arbeiten, sollten Aussagen über die Auswirkungen der Wiki-Nutzung durch die Vergabe von Noten zwischen 1 (trifft überhaupt nicht zu) bis 5 (trifft voll und ganz zu) jeweils konkretisieren. Die Ergebnisse sind eindrucksvoll:

• Wikis haben die Informationstransparenz gesteigert. (4,47 von 5)
• Wikis haben dafür gesorgt, dass wir immer aktuelle Informationen haben. (4,25 von 5)
• Wikis haben uns neue Methoden der Zusammenarbeit ermöglicht. (4,00 von 5)
• Wikis haben die Effizienz unserer Arbeit verbessert. (3,75 von 5)
• Wikis sorgen dafür, dass die Zusammenarbeit im Unternehmen besser wird. (3,73 von 5)
• Wikis helfen unseren Mitarbeitern, sich selbst besser zur artikulieren. (3,53 von 5)
• Wikis haben die Informationen in unserem Unternehmen glaubwürdiger gemacht. (3,47 von 5)

Durchschnittlich wurde für alle Fragen ein Wert von 3,89 von 5 vergeben, was deutlich für den hohen Nutzen von Wikis spricht.

Problemquellen bei der Etablierung

Es ist indes kein Geheimnis, dass ein Wiki im Intranet kein Selbstläufer ist und der Erfolg von vielen Faktoren abhängt. Welche Probleme stehen der wirklich effektiven und effizienten Wiki-Nutzung im Wege und welche Faktoren verhindern, dass das Potenzial eines Wikis voll ausgeschöpft werden kann? Auch hier sollten Wiki-erfahrene Unternehmen die Relevanz bestimmter Aussagen bewerten:

• Zu wenige Mitarbeiter stellen aktiv und häufig Informationen in das Wiki ein. (4 von 5)
• Den Teilnehmern wird der Nutzen des Wikis nicht schnell genug klar. (3,6 von 5)
• Es ist schwierig, Teilnehmer für das Wiki zu motivieren. (3,5 von 5)
• Die Zeit für die Wiki-Nutzung reicht nicht aus. (3,4 von 5)
• Wiki-Teilnehmer nutzen lieber alte Tools und steigen nicht auf das Wiki um. (3,2 von 5)
• Es ist schwer, die Informationen aktuell zu halten. (3,2 von 5)
• Die Arbeitsteilung und Nutzungsregeln für das Wiki sind unklar. (3,2 von 5)

Durchschnittlich wurde für alle Fragen ein Wert von 2,8 von 5 vergeben, was ebenfalls für den hohen Nutzen von Wikis spricht. (Die Mitte liegt bei 3,0.) Deutlich wird aber auch, dass die Wiki-Einführung mit der technischen Integration längst nicht beendet ist (sondern vielmehr erst richtig anfängt) und dass professionelle Konzepte, wie beispielsweise Wiki-Piloten, die konsequente Umsetzung der Graswurzelstrategie und natürlich Überzeugungsarbeit nötig sind, um insbesondere die Mitarbeiteraktivierung zu unterstützen.

Learned Lessons

Dementsprechend hätten einige der befragten Unternehmen mitunter andere Herangehensweisen verfolgt bzw. sich noch stärker auf bestimmte, erfolgskritische Faktoren konzentriert, wenn sie über das Erfahrungswissen verfügt hätten. Was würden die Unternehmen heute anders machen? Einige Aussagen:

• „Der Zweck der Nutzung und die Tagesgeschäftsabläufe im Wiki sollten von Anfang an gut definiert werden.“
• „Das Wiki sollte früher breit ausgerollt und genutzt werden.“ (Das halten wir nicht für sinnvoll: Gerade ein Wiki-Pilot mit einer begrenzten Anzahl von Mitarbeitern, die einen Querschnitt des Unternehmens abbilden, ist unserer Meinung nach ein wichtiger und notwendiger Schritt im Rahmen der Wiki-Einführung.)
• „Es sollte zu Beginn nicht nur Schulungen zur technischen Nutzung des Systems geben, sondern auch zu den Konventionen und Nutzungsregeln.“
• „Wir hätten das Intranet direkt abschalten sollen, statt es parallel weiterlaufen zu lassen.“ (Auch das halten wir nicht für sinnvoll: Sämtliche Funktionen eines Intranets wird ein Wiki nicht abbilden können; so erfüllt etwa ein CMS im Intranet grundsätzlich ganz andere Aufgaben. In erster Linie schließt ein Wiki funktionelle Lücken und leistet einen signifikanten Beitrag dazu, dass bestehende Systeme wieder ihrer eigentlichen Bestimmung zugeführt werden.)
• „Mehr Training und Anleitungen für Nutzer sind wichtig und hilfreich.“
• „Die Anwendung des Wikis im täglichen Geschäft sollte den Nutzern besser erklärt werden.“

Fazit: Wiki-Nutzen entfaltet sich langfristig, Wikis haben einen hohen ROI

Nicht zuletzt geht aus der Studie hervor, dass ein Wiki seine Wirkung ganz offensichtlich langfristig entfaltet und eine Investition in ein solches System sich auf Dauer rentiert. Einige zusammenfassende Erkenntnisse:

• Je länger ein Unternehmen ein Wiki einsetzt, desto höher schätzt es den Nutzen des Wikis ein.
• Unternehmen, die das Wiki zunächst sinnvoll in einer Pilotgruppe real testen und kontrolliert einführen, sind häufig erfolgreicher damit.
• Die Anwendung von Wikis für die Generierung von Ideen und zu Dokumentationszwecken steigt mit zunehmender Nutzung des Wikis.

Die Studie macht also anhand konkreter Zahlen deutlich, dass Unternehmen Wikis einen außerordentlich hohen Stellenwert beimessen und dass Wikis einen beachtlichen Return on Investment aufweisen, was sich mit unseren eigenen intensiven Erfahrungen deckt. Es dürfte schwerlich zu bestreiten sein, dass Unternehmen, die auf ein Wiki im Intranet verzichten, im Hinblick auf die Effektivität und die Effizienz der internen Kommunikation inzwischen einen nicht unrelevanten Wettbewerbsnachteil in Kauf nehmen.

Damit ein Wiki jedoch zu einer umfangreichen und organisch wachsenden Wissensbasis wird, gilt es, Strategien zu entwickeln und gezielt anzuwenden, um die Nutzung des Systems zu fördern und Probleme aus dem Wege zu räumen – dies sind unserer Meinung nach sogar die Hauptaufgaben und die wesentlichen Herausforderungen bei der Wiki-Etablierung.

Weiterführende Informationen

Unsere spezielle Seite zum Thema Firmenwikis
Confluence 3.0: Das führende kommerzielle Enterprise-Wiki geht in die nächste Runde
Sieben Maßnahmen für erfolgreiche Corporate Wikis

Download (1,1 MB): Unsere Wiki-Broschüre auf deutsch (PDF)
Download (1,1 MB): Our wiki brochure in English (PDF)

Der Boom von Enterprise-Wikis ist ein junges Phänomen und Untersuchungen zur Nutzung von Firmenwikis sowie zur Wiki-Praxis in Unternehmen sind rar. Umso erfreulicher ist es, dass sich Mitarbeiter der Universität Tampere die Mühe gemacht haben, die 50 größten finnischen Unternehmen eingehend zu deren Wiki-Nutzung zu befragen. Die interessanten Ergebnisse liegen nun in Form der Studie Experiences of Wiki Use in Finnish Companies vor.

Im Zentrum der Untersuchung standen insbesondere folgende Fragen: Nutzen die größten 50 finnischen Unternehmen überhaupt Wikis und wenn ja, warum? Und welche Anwendungsfälle gibt es in der Unternehmenspraxis?

Wie verbreitet sind Wikis in großen Unternehmen?

Zunächst zur Bestandsaufnahme. 80% der finnischen Top-50-Unternehmen haben sich an der Studie beteiligt:

• 26% nutzen Wikis.
• 15% haben Wikis im Testeinsatz.
• 18% denken derzeit über die Einführung eines Wikis nach.
• 38% haben sich noch nicht eingehender mit dem Thema Wikis beschäftigt.
• 3% haben sich bewusst gegen ein Wiki entschieden.

Insgesamt stehen also etwa 59% der befragten Unternehmen dem Einsatz von Wikis grundsätzlich positiv oder offen gegenüber. Und diese Zahlen belegen in der Tat, dass Enterprise-Wikis auf dem Vormarsch sind, es bis zu einer vollständigen Marktdurchdringung wohl aber noch ein langer Weg ist. Indes hat kein Unternehmen, das ein Wiki eingeführt hat, dieses wieder abgeschaltet.

Gründe für die Wiki-Einführung und Motivation für die weitere Nutzung

Im //SEIBERT/MEDIA-Weblog und auf anderen Kommunikationskanälen haben wir zahlreiche Argumente für eine Wiki-Einführung vorgebracht, die zum Großteil auf eigenen Erfahrungen beruhen, und sehen uns bestätigt: Die tatsächlichen Beweggründe der befragten Unternehmen decken sich vollkommen mit diesen Argumenten. Die wichtigsten Gründe für die Einführung und die weitere Nutzung eines Wikis sind der Studie zufolge diese:

• Optimierung der Informationstransparenz
• Verbesserung der Effizienz im Unternehmen
• einfache Bedienung von Wikis (Usability)
• Verfügbarkeit von aktuellen Informationen
• Nutzung von neuen kollaborativen Arbeitsmodellen
• einfache Einführung von Wiki-Software
• Erweiterung und Verbesserung der Zusammenarbeit im Unternehmen
• motivierte Mitarbeiter, die das Wiki nutzen
• gute Verfügbarkeit der Wiki-Software-Lösung
• Korrektheit der Informationen im Unternehmen verbessern
• Glaubwürdigkeit der Informationen verbessern
• Verfügbarkeit von ausgereiften Open-Source-Wiki-Systemen
• Möglichkeit, auf andere proprietäre Dokumentenformate zu verzichten

Besonders hervorzuheben ist hier, dass, wie die Studie betont, der Stellenwert der Usability mit der Dauer der Wiki-Nutzung offenbar an Gewicht gewinnt. Die befragten Unternehmen schätzen anfangs insbesondere die Bedienung von Wikis als komplizierter ein, als sie tatsächlich ist, und rechnen mit einem entsprechend höheren Aufwand für Einarbeitung und Schulung. Die gute Usability ausgereifter Wiki-Systeme trägt also maßgeblich zu einer möglichst reibungslosen und unkomplizierten Etablierung als Wissensmanagement-System bei.

Ein weiterer interessanter Aspekt: Die Gründe für den Einsatz eines Wikis verändern sich während und nach der Implementierung kaum, die Argumente für die Weiterführung und den Ausbau eines Systems unterscheiden sich so gut wie gar nicht von denen für eine Wiki-Einführung. Ein Wiki, so die naheliegende Interpretation, leistet also dauerhaft „Arbeit“, der Nutzen eines Wikis ist nicht mit seiner Einführung erschöpft, sondern nimmt stetig zu. Die Gründe für die Einführung sind häufig auch nach dieser noch aktuell und valide und ein Wiki somit tatsächlich in der Lage, die ursprünglichen Ziele zu erreichen.

Der zweite Teil der Auswertung geht auf die unmittelbare Wiki-Praxis ein: Wofür nutzen Unternehmen Wikis konkret? Welche Vorteile sind Unternehmen durch den Wiki-Einsatz entstanden? Welche Probleme haben sich herauskristallisiert? Was würden Unternehmen, die Wikis nutzen, im Nachhinein anders machen?

Weiterführende Informationen