Xing-Blog als net.work.xing kurz vor dem Relaunch (Update)

networkxingscreen1net.work.xing heisst offensichtlich die neue Version des Corporate Blog von Xing (bisherige Version). Bin eben von der Testsite überraschenderweise gepingt worden. Es sieht frischer und übersichtlicher aus. Und ist viersprachig(!): englisch, spanisch, türkisch und chinesisch. Es gefällt mir. Aber warum nicht in der Sprache der meisten Mitglieder, in deutsch?

Update: So, vorhin war nun der Switch auf die neue Version!

Update2: Eine deutsche Version ist in Arbeit erklärt Thorsten VespermannDirector Corporate Communications XING AG.

Corporate Inhouse Social Software

Gestern hat mich Björn Ühss aus Wien für seine Diplomarbeit bei IBM interviewt. Sein Thema lautet „Nutzen von Social Software für Unternehmen anhand Best Practices verglichen mit IBM“. Dabei haben wir auch über die Zukunft von Social Software in (grossen) Unternehmen gesprochen, der klassischen Klientel von IBM. Björn meinte völlig zu recht, die Einführung von Wikis, Blogs und anderen Social Tools in diesen Unternehmen sei wegen der mangelnden Akzeptanz (im Management) sehr schwierig. Von Twitter ganz zu schweigen.

Dabei kam mir folgender Gedanke. Ich glaube, der Weg mit dem geringsten Widerstand die neuen Corporate Social Services, so nenne ich sie mal, einzuführen ist, sie auf den vorhandenen Messaging Servern aufzusetzen und diese um „soziale Funktionen“ aufzubohren. Was heisst das?

Man nehme einen Mail/Messaging Server von einem der beiden Marktführer, IBM Notes oder Microsoft Exchange, und bohre sie auf zu Inhouse Social Network Plattformen. Die Server enthalten ja schon mal alle Nutzerprofile des Unternehmens, Diese gilt es nun um relevante weitere userbezogene Daten zu erweitern. Die Grunddaten dazu gibt es überall im Unternehmen, insbesondere in den Organisations- oder Personalabteilungen. Je nach System und Ausprägung können diese erweiterten Profile im Active Directory (AD) und/oder im LDAP abgelegt und automatisch mit den Quellensystemen ständig synchronisiert werden. Diese „angereicherten Profile“ bilden die „Knoten“ des internen sozialen Netzes, dass es nun zu weben gilt.

Die „berufsbedingten sozialen Beziehungen“ zwischen diesen Knoten ist der „Social Graph“, den diese Mailsysteme noch nicht haben. Diesen Graph gilt es als Add-on den Servern hinzuzufügen. Relativ simpel am praktischten eben auch im AD oder LDAP. Und schon hätte man ein „Corporate Inhouse Social Software“ basierend auf den schon vorhandenen Messaging Servern. Warum ist das interessant?

Die Organisationsstrukturen von Grossunternehmen (10.000+ IT-Arbeitsplätze) werden flacher, verteilter und dadurch de facto vernetzter. Sie wandeln sich immer mehr von hierarchisch starren Strukturen hin zu flexiblen serviceorientierten Gebilden. Die Linien lösen dadurch natürlich nicht vollständig auf, aber sie werden komplexer. Es ist für den einzelnen Mitarbeiter nun viel wichtiger, aufgabenbezoge Beziehungen im  Unternehmen zu knüpfen und zu pflegen. Einfache Adressbücher, auch hierarchisch gegliederte interne „Gelbe Seiten“, reichen da nicht mehr aus, um den Anforderungen gerecht zu werden.

Unternehmen werden i.d.R. nicht ihre sensitiven personenbezogenen Daten in externe webbasierte Services wie LinkedIn, Xing o.ä. herausgeben. Webbasierte Services, die mittlerweile Alltag in der Web 2.0 Welt sind und die wir alle privat und viele auch berufsbedingt nutzen. Vorallem Freiberufler und Selbstständige. Aber die haben andere Anforderungen als (grosse) Unternehmen.

Im Gegenzug macht es auch keinen Sinn, sogenannte „White Label“ Lösungen dieser öffentlichen webbasierten Plattformen zu verwenden. Solche Lösungen bedeuten deutlich mehr Entwicklungs-, Wartungs- und Pflegeaufwand für die Softwarehersteller, dessen Geschäft es ja gerade ist, einen einheitlichen Dienst im Internet allen anzubieten. Jede Version für einen Kunden würde eine eigenständige Aufmerksamkeit (Entwickler) bedeuten. Das ist meist nicht wirtschaftlich für die Anbieter.

Eigenständige Inhouseprodukte wie beispielsweise das wikibasierte SocialText bringen uns in dieser Grössenordnung auch nicht weiter. Meist ist es so dass IT Abteilungen die Einführung zusätzlicher technologischer Plattformen, die schwer mit der restlichen Infrastruktur zu integrieren sind, scheuen wie der Teufel das Weihwasser. Zu recht. Denn das bedeutet Mehraufwände im Betrieb, Sicherheitsrisiken, Bedenken in der Kette der Verfügbarkeiten und mehr.

Deswegen finde ich meinen Ansatz eigentlich am attraktivsten. Man nimmt, was man schon hat und kennt, was sich bewährt hat und bohrt es nur auf. Und man muss nicht über so abstrakte Begriffe wie „Neues Web“, „Web 2.0“ oder „Cool“ argumentieren. Der Bedarf ist da. Ich bin schon mehrfach in grossen Intranetvorhaben nach solchen praktikablen Lösungen gefragt worden. So etwas kann man auch als Add-on Produkt entwickeln und vertreiben.