Ronny

In unserem Projekt war von vornherein klar, dass wir ein Zweiklassen System zur Zeit haben und auch weiterhin haben werden. Die einen, die ihren Mailaccount haben um damit Mails zu bekommen die “an alle” versendet werden (Bekanntmachungen, Mitteilungen, …) und ansonsten vielleicht 5 eMails in der Woche schreiben. Die anderen, die eben den ganzen Tag mit dem Medium eMail zu tun haben und dem entsprechend viele Mails haben. Einfach gesagt: Standard User und Power User.

Für die Standard User wird Group-Office das Tor zu eMail und Company Collaboration sein. In unserem Fall haben die meisten Standard User auch keinen festen Platz, sondern müssen sich mal von da und mal von dort anmelden können. Dafür ist Webmail eh am einfachsten. Auf die Standard User möchte ich jetzt auch gar nicht weiter eingehen, da Group-Office in späteren Artikeln bestimmt noch behandelt werden wird.

Heute geht es um die Power User. Warum überhaupt zwei verschiedene Systeme anbieten? Naja, da gibt es Argumente wie die Möglichkeit zum Sortieren des Posteingangs (oder anderer Ordner). Möchte man beispielsweise einen Ordner nach den Absendern gruppieren, so wird das mit einem Webmail Client sehr schwierig da dafür die kompletten Daten des Ordners in die Berechnung der Anzeige einfließen müssten. Group-Office – und auch die meisten anderen – arbeitet als IMAP Client mit direktem Zugriff auf den Mailserver und kann dabei nicht viel an Cache nutzen.

Ein weiteres Beispiel ist die Anzeige (Liste) der Mails. Group-Office zeigt per Default 20 eMails in der Liste an. Man kann diesen Wert auf bis auf 50 erhöhen – dann ist Schluss. Das macht aus Sicht der Webmail Anwendung auch Sinn, um die Performance zu erhalten. Nun ist es allerdings so, dass manche Anwender ihren Ordner einfach mal so überfliegen möchten, weil sie “irgendeine eMail suchen die vor ein paar Tagen gekommen ist”. Man möchte die Liste einfach durch scrollen. Mir ist schon klar, dass man dafür auch Suchfunktionen innerhalb des Webmail Systems nutzen könnte Schlecht ist das auch bei Mitarbeitern die morgens so um die 70 eMails oder Montags sogar > 100 eMails haben. Sie müssten sich durch mehrere Seiten klicken um sich einen Überblick zu verschaffen – das ist auch aus meiner Sicht nachvollziehbar

Das sind nur ein paar Beispiele dafür, dass es notwendig ist einen FatClient anzubieten. Der wohl schwerwiegendste Grund dürfte allerdings die Gewohnheit sein. Die Mitarbeiter haben sich über viele Jahre an einen FatClient (in dem Fall Outlook) gewöhnt. Nun möchten wir das ganze System ändern. Eine große Aufgabe liegt darin, den Mitarbeitern das ganze schmackhaft zu machen – mit möglichst wenig Änderungen an Bedienung und Verfahrensweisen. Auch das ist ein Grund, warum man den FatClient nicht einfach “wegmigrieren” kann.

Die Qual der Wahl? Naja.

Nun, welchen eMail Client kann man nehmen? Gibt es viele Alternativen? Aus meiner Sicht nicht wirklich. Ein Client, der auf Windows als auch auf Linux läuft. Ein Client der recht bekannt ist und aktiv entwickelt wird. Ein Client der erweiterbar ist.

Wie aus der Überschrift zu entnehmen ist haben wir uns auf Thunderbird als FatClient festgelegt. Gibt es andere, wirkliche, Alternativen? Ich kenne keine und bin bisher auch mit Thunderbird ganz zufrieden. Es gab zwar so einige Stolperstellen, aber im Großen und Ganzen bin ich zufrieden – mittlerweile.

Ist Thunderbird “Ready for the Enterprise”?

Das ist mit die interessanteste Frage in dem Spiel. Kann Thunderbird im Unternehmen eingesetzt werden? Naja, generell spricht ja nichts dagegen – wieso auch. Welche Anforderungen hat ein Unternehmen denn?

Also prinzipiell benötigt ein Unternehmen an sich auch nicht viel mehr als der Privatmann zu Hause (ganz ganz grob ausgedrückt):

• eMail (IMAP, SSL)
• Kalender (Free & Busy, Shared)
• Adressbuch / -bücher (LDAP, Lokal)

Diese Anforderungen sind wirklich nur der Standard – es geht hier nicht um Firmen die mit dem Mailclient Workflow abbilden oder anderes. Aber stellen wir uns das mal vor… So wie jeder Thunderbird kennt würde dann auf jedem Arbeitsplatzrechner Thunderbird installiert, die Plugins heruntergeladen und installiert, alles manuell konfiguriert. Dieses Szenario x Anzahl Poweruser. Und die Updates nimmt man direkt aus dem Internet, oder? Klar.

Damit sind wir bei den Anforderungen der Unternehmen:

• zentrale Installation (komplettes Package incl. Plugins/Extensions)
• zentrale Steuerung von Updates
• zentrale Administration der Clients (Konfiguration, Konfigurationsupdates)

Aber kann Thunderbird das? Yes, he can. Allerdings war es echt schwierig an die nötigen Informationen zu kommen.

Weiter geht es im nächsten Artikel – bald auf dieser IP Adresse.