E-Mail-Missbrauch 2: Der E-Mail-Anhang ist oft die falsche Anwendung von Technologie | //SEIBERT/MEDIA Weblog

Dieser //SEIBERT/MEDIA-Artikel ist am 6. Januar 2010 auch im Online-Magazin Dr. Web erschienen.

Anzeige

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

Unternehmenskommunikation: E-Mail vs. Wiki

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.

Der 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 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, weil er seine E-Mails 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

Sehr eingängig geschrieben. Ich bin ebenfalls genau dieser Ansicht. Wobei für mich der Unsinn, Dokumente als Anhang zu bekommen, nur noch durch Anhänge auf Wiki-Seiten platzieren, übertroffen wird.

Posted via web from slamprecht’s posterous

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert