Wie viel UC braucht die TK?

1 Kommentar Drucken

Wir kommen jetzt in die entscheidende Marktphase, in der viele der alten TK-Anlagen nun nicht länger wirtschaftlich betrieben werden können. Entsprechend explodiert die Zahl der Projekte. Und es gibt ein zentrales Problem, um das sich nahezu jedes Projekt dreht. Dies ist die Frage: brauchen wir Unified Communications und wenn ja, wie viel davon?

Diese Frage mag überraschen, diskutieren wir doch seit Jahren, dass die Zukunft des Marktes in der UC liegt. Entsprechend sahen wir lange Zeit Hersteller, die wichtige UC-Positionen nicht abdecken können, mit einem sehr kritischen Blick. Nun haben die Hersteller natürlich dazu gelernt. Die typischen „alten“ TK-Produkte wurden um UC-Funktionen angereichert, selbst vor der Virtualisierung der Lösungen schreckte man nicht zurück. Es gibt kein besseres Beispiel für diese Entwicklung als die HiPath 4000. Gefördert wird diese Entwicklung durch einen Markt mit vielen TK-lastigen Kleinberatern, die UC nicht zwingend fördern und einem wenig flexiblen Vertrieb der großen TK-Anbieter. So hat sich der Markt noch weiter in seine Glaubens-Lager zerlegt. Auf der einen Seite das Lager der klaren UC-Befürworter, dem diametral gegenüber die TK-Traditionalisten gegenüber stehen und dazwischen jede Menge Schattierungen.

Im Endeffekt fällt der Kunde die Entscheidung. Und da können wir nicht verkennen, dass dieser nach wie vor mehrere ganz schwerwiegende Probleme mit UC hat:

  • Die Zahl der Arbeitsplätze, die UC-Funktionalität wirklich wirtschaftlich sinnvoll nutzen können, schwankt in den Unternehmen zwischen 10% und 90%. Vermutlich liegt der Mittelwert momentan deutlich unter 50%. Auch wenn sich das in Zukunft kontinuierlich in Richtung UC verschieben wird, existieren im jetzigen Zustand im Mittel noch viele reine TK-Arbeitsplätze.
  • Viele der angebotenen UC-Lösungen sind schlicht so komplex, dass das angestrebte Ziel einer neuen Form von Kommunikation weder auf der Seite der Betreiber noch auf der Seite der Anwender wirtschaftlich erreicht werden kann. Auf der Betreiberseite ist der Betrieb zu komplex, auf der Anwenderseite werden viele UC-Funktionen nicht genutzt, weil sie nicht intuitiv genug in der Bedienung sind.
  • Die Glaubwürdigkeit einiger Anbieter hat in den letzten Jahren deutlich gelitten. Zwar wird immer von UC und der Zukunft geredet, doch bleibt die tatsächliche Weiterentwicklung der Produkte hinter den Versprechungen zurück.
  • Mit Irritation sehen die Kunden, dass die Hersteller wichtige Standards, die eigentlich untrennbar mit UC verbunden sind, blockieren. Dies gilt vor allem für SVC auf der Videoseite. Die heute angebotenen Video-Lösungen skalieren schlichtweg nicht mit großen Teilnehmer-Zahlen. Nimmt man die Vision von UC aber ernst, dann müssen sie das. Wie glaubwürdig ist ein Hersteller, dem der Vertrieb seiner MCUs wichtiger ist als die Umsetzung einer skalierbaren UC-Plattform?
  • Die Cloud wirft neue und entscheidende Fragezeichen auf. Zwar war der externe Betrieb der TK-Lösung immer mal wieder ein Thema, aber er konnte sich nie wirklich durchsetzen. Die Cloud, was immer wir darunter verstehen wollen, schreibt die Spielregeln neu aus. Damit stellt sich automatisch die Frage, ob in Zukunft ein Teil der Anschlüsse (oder alle?) besser durch einen externen Betreiber erbracht werden sollten. In der Vergangenheit war das zum Beispiel aufgrund der engen Vermaschung mit internen Schnittstellen nicht sinnvoll. Das Argument verliert aber an Bedeutung in genau dem Maße, in dem diese Schnittstellen auch in der Cloud verfügbar sind. Ich verweise auf die ComConsult Analyse zu „Public und Private Clouds“.

In dieser Lage suchen die Kunden nach einer einfachen Lösung, bei der man nichts falsch machen kann. Die Lösung soll auf der einen Seite alle Türen offen halten, auf der anderen Seite aber keine Bindungen an eigentlich ungeeignete Produkte generieren.

Damit sind wir wieder an einer Stelle, an der wir vor ein paar Jahren schon einmal gestanden haben. Man nehme die traditionelle TK-Lösung und ergänze sie um eine angeflanschte UC-Lösung. Da ist es sehr praktisch, dass sich die alten TK-Lösungen in den letzten Jahren ja auch weiter entwickelt haben und als reine Software-Lösungen nun deutlich besser in den Rahmen eines gemeinschaftlichen Betriebs passen.

Damit ist aber auch klar: der Gewinner ist Microsoft. Lync-Server passt in dieses Muster wie die Faust aufs Auge. Da damit auch weitreichende Office- und Kollaborations-Anforderungen abgedeckt werden, hat man alle Türen für die Zukunft offen. Und als Krönung des Ganzen gibt es jetzt noch Office 365 mit der Option eines Cloud-Services mit dem identischen Funktionsumfang plus der Möglichkeit eines hybriden Betriebs (auch die anderen Hersteller gehen stark in diese Richtung, aber keiner belegt die Rolle des Ergänzungsprodukts so intensiv wie Microsoft).

Die Frage nach der Rolle des Lync-Servers in unserem aktuellen TK und UC-Markt war noch nie so drängend wie jetzt.

Finde ich das gut? Natürlich nicht. Nicht weil ich etwas grundsätzliches gegen den Lync-Server hätte (im Gegenteil, das User Interface setzt Maßstäbe für die ganze Branche). Aber die Strategie der offenen Türen, so dass man nichts falsch machen kann und jederzeit so viel UC hat wie man braucht, ist schlichtweg sehr riskant. Nehmen wir einmal an, die Prognose, dass UC die Zukunft gehört, ist richtig. Was bedeutet das dann für diesen Ergänzungsbetrieb? Ganz einfach: der Kunde hat sich startend mit vielleicht 10% der Arbeitsplätze im Prinzip dazu bekannt, auf Dauer Lync-Server an alle Arbeitsplätze zu bringen. Ganz klar formuliert: die Entscheidung für einen Lync-Ergänzungsbetrieb ist eine langfristige Entscheidung für Microsoft. Das Problem ist nur, dass der Kunde das gar nicht weiß und so ggf. auch nicht will. Aber wo soll die Entwicklung des stufenweisen Ausbaus des UC-Bereichs denn anders enden?

Hinzu kommt, dass der parallele Betrieb zweier Produkte weder die Betriebskosten senkt noch die Nutzung für den Endanwender vereinfacht. Auf welcher Seite liegt denn zum Beispiel die Integration mobiler Endgeräte? Wie werden Rufweiterschaltungen umgesetzt, wenn Anwender in beiden Welten arbeiten? Und wie sieht die Video-Lösung auf Dauer aus?

Das Problem in dieser Situation ist, dass wir in keiner heilen Welt leben. Auf der einen Seite die Vielzahl der UC-Produkte, die auch nach Jahren der Entwicklung dem UC-Anspruch immer noch nicht gerecht wird. Auf der anderen Seite der Wunsch nach einem Risiko-armen Einstieg. Da gibt es keine klaren Gewinner.

Es ist an der Zeit, noch einmal die Strategien der wesentlichen Marktteilnehmer zu analysieren. Die Kunden, die jetzt aus ihrer alten TK-Anlage aussteigen wollen, brauchen klare und Risiko-freie Perspektiven.

zugeordnete Kategorien: LAN, UC
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Ein Kommentar zu "Wie viel UC braucht die TK?":

  1. iavarone schreibt:

    Das Problem ist doch , dass die hersteller den Kunden in ihre Produktwelt binden wollen. Ein Ausbruch muss man mit weiteren hohen Investitionen in Hardware und Traversal Lizenzen bezahlen. Die jeweiligen Hersteller empfehlen dann auch mal ganz schnell ein homogenes Systemumfeld zu schaffen, bei der man sich von den Produkten des Konkurrenten schleunigst entledigen sollte. Dieses Platzhirschgerangel der Big Player im Videokonferenz – Highendbereich hat vor allem den Kunden und seine Bedürfnisse links liegen gelassen. Dieses Kunden- Melkkuh– Phänomen kannen wir noch aus den Anfangszeiten der PC Revolution, wo man ür einen Apple Würfel schon locker mal 25.000 DM und mehr hingeblättert hat. Vollmundige Versprechungen mancher Accountmanager stellen sich schnell als Farce heraus, wenn man sich in der Welt eines bestimmten Herstellers gefangen sieht. Dann werden schnell Zusatzinvestitionen für mehrere Gatekeeper und Traversallizenzen fällig. Dabei wird auch grundsätzlich verschwiegen, dass bei einem Call mit einem externen Partner gleich mehrere Traversal lizenzen verbraten werden können,

Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.