aus Netzwerk-Insider-Ausgabe Juni 2018
Die Einführung von UCC-Produkten ist keineswegs ein Selbstläufer. Dabei sind Cisco Spark (jetzt Webex Teams) und Microsoft Teams nur Stellvertreter für alle Produkte in diesem Bereich. Unify Circuit, Slack und andere sind davon nicht ausgenommen. Das Risiko eines Scheiterns von UCC-Projekten speziell im Sinne fehlender Akzeptanz seitens der Benutzer ist generell hoch.
Dies liegt an folgenden typischen Ursachen:
• Funktionale Fehlausrichtung
• Mängel der Produkte
• Schlechte Team- und Kanal-Strukturierung
• Organisatorische Einführung scheitert
Wir diskutieren die wichtigsten UCC-Produkte, ihre Schwächen und Stärken und die Projekt-Risiken auf unserer Sonderveranstaltung „Kriterien und Erfolgsszenarien für den Einsatz von UCC-Produkten: Cisco Spark/Webex Teams, Microsoft Teams und Unify Circuit in der Analyse“ vom 27. bis 28.6. in Düsseldorf im Detail (https://www.comconsult-akademie.de/einsatz-ucc-produkte/). An dieser Stelle deshalb nur ein grober Überblick über die typischen Probleme.
Funktionale Fehlausrichtung und
Mängel der Produkte
UCC steht für Communication AND Collaboration. Der größte Fehler bei der Einführung besteht dann auch darin, das Produkt als neue Form der Videokonferenz einzuführen und darauf zu reduzieren. Zum einen würde das eine totale Funktionsüberlappung mit der existierenden UC-Installation erzeugen, zum anderen wird dies dem Kollaborations-Ziel solcher Projekte in keiner Weise gerecht. Jeder der Funktionsbereiche eines UCC-Tools erfordert eine saubere Positionierung sowohl in sich selbst als auch gegenüber der bereits existierenden IT.
Generell unterteilen wir die Funktionsbereiche von UCC in mindestens folgende Bereiche:
• Meeting / Desktop-Videokonferenz
• Dokumenten-Kollaboration
• Messaging / Persistent Chat
• Kollaboration mit Externen
Die meisten der im Markt angebotenen Produkte, darunter speziell Cisco Spark/Webex Teams und Unify Circuit, stammen aus dem Meeting-Bereich. Sie sind dort absolut stark und Cisco und Unify bauen diesen Bereich immer weiter aus in Richtung der perfekten Meeting-Erfahrung und der Integration von White-Boards und sowohl Standard-Videokonferenz-Lösungen als auch Web-Meetings und Webinaren. Dies erklärt auch die Umbenennung von Spark zu Webex Teams und die Integration des Produkts in den privaten IP-Backbone von Cisco Webex. Cisco steht in diesem Meeting-Bereich unter einem starken Konkurrenzdruck im internationalen Markt. Anbieter wie Zoom können inzwischen signifikante Markterfolge verzeichnen. Dies ist auch einer der Gründe für die Neupositionierung von Spark als Webex Teams. Und zweifelsfrei ist Zoom als Konkurrent sehr ernst zu nehmen. Es ist funktional und qualitativ ein herausragendes Meeting-Produkt mit einer interessanten Lizenzstruktur. Wir benutzen in unseren Tests Zoom als qualitativen Maßstab für Bild- und Tonqualität.
Aber so toll und überzeugend Spark, Circuit und Co auch im Meeting-Bereich sind, darf das nicht davon ablenken, dass UCC einen klaren Kollaborations-Schwerpunkt hat. Und hier beginnen die Probleme und liegen mögliche Ursachen für das Scheitern dieser Projekte.
Dokumenten-Kollaboration ist ein Mega-Thema. Es sollte aus unserer Sicht die Bedeutung haben, die Email Anfang der 90er Jahre bei der Markteinführung hatte. Und wir sind überzeugt davon, dass hier ein großes Potenzial für Team-Effizienz und Ablauf-Verbesserungen liegt. Es würde komplett den Rahmen sprengen, dies hier im Detail zu erläutern, ich verweise deshalb auf die schon erwähnte Sonderveranstaltung Ende Juni in Düsseldorf. Aber aus vielen wichtigen Punkten, sollen einige Punkte stellvertretend angesprochen werden:
• Ein UCC-Tool darf nicht auf der Basis von Uploads oder Downloads arbeiten. Es geht bei Dokumenten-Kollaboration ja genau darum, dass Kopien von Dokumenten vermieden werden und alle am gleichen Dokument zur gleichen Zeit arbeiten können
• Auf Grund der Komplexität eines guten Dokument-Management- und Kollaborations-Produkts sollte nur genau eine derartige Lösung im Unternehmen etabliert werden. Wenn also das UCC-Produkt die Lösung für Dokumenten-Kollaboration sein soll, dann muss es die zentral eingesetzte Lösung für diesen Funktionsbereich sein. Und hier liegt die Messlatte hoch mit Versionskon-trolle, Historien-Log, Labeln, Metadata, Integration in lokale und bestehende Datei-Manager, umfassende Kollaborations- und Sharing-Möglichkeiten und vieles andere mehr
• Ein direktes Bearbeiten eines Dokuments aus dem Produkt muss möglich sein
• Es muss möglich sein, mit mehreren Personen zur gleichen Zeit am Dokument zu arbeiten
• Ein Dokument muss zeitgleich auf mehreren Geräten eines Benutzers offen sein können
Speziell Spark/Webex Teams und Unify Circuit sind hier weit von einer akzeptablen Lösung entfernt. Beide Anbieter haben funktionale Erweiterungen in dieser Richtung angekündigt, aber zumindest im Moment existieren diese nicht. Dies ist auch nicht so einfach umzusetzen. Dokumenten-Kollaboration und Bearbeitung ist komplex. Es ist nicht ausgeschlossen, dass hier statt einer Eigenentwicklung eine Kooperation mit einem anderen Anbieter gesucht wird.
Microsoft Teams ist im Bereich der Dokumenten-Kollaboration der König gegenüber seinen Konkurrenten. Dies ist eine der Stärken und leider auch eine der zentralen Schwächen des Produkts. Jedes Team erzeugt einen Team-Bereich in Office 365 SharePoint Online. Wer Teams macht, der macht auch SharePoint Online. Dies wird zwar auf den ersten Blick nicht sichtbar, ist aber wichtig. So muss es in solchen Lösungen zwingend möglich sein, auf Dokumente eines Teams auch mit einem normalen Datei-Manager zugreifen zu können. Es kann und darf nicht sein, dass Teams oder Spark zur alleinigen Datei-Verwaltungs-Oberfläche für die Dokumente eines Teams werden. Durch die Nutzung von SharePoint erfüllt Teams diesen Anspruch. Aber SharePoint ist ein absolutes Schwergewicht der Dokumenten-Kollaboration. Es unterstützt Metadata, Labeling und ein Life-Cycle-Management mit allen Formen der Compliance. Was sich nett und schön liest, kann in der Praxis zu einem Komplexitäts-Alptraum werden. Die Datei-Manager-Inte-
gration funktioniert je nach Plattform gut oder weniger gut. Die Performance im Betrieb ist sehr schwankend, abhängig von der Qualität der Netzwerk-Anbindung und deutlich hinter dem Standard zurück, den hier Google mit der G-Suite setzt. Allerdings kann die G-Suite auch nur einen Bruchteil der Funktionalität abdecken. Lange Rede kurzer Sinn: wer Teams einsetzen will, der muss auch bereit sein, SharePoint zu benutzen und mit Office Online zu arbeiten. Und ein wenig SharePoint wäre es unserer Sicht der falsche Ansatz. Hier gilt ganz oder gar nicht. Was bei Microsoft Teams sowieso generell für die Office 365 Umgebung gilt. Der Elefant im Raum heißt hier zudem Skype for Business. Microsoft hat eine neue Online-UC-Version in Kombination mit Teams angekündigt. Es darf zumindest bezweifelt werden, ob dies zusammen mit einer existierenden UC-Lösung eines anderen Herstellers harmoniert.
Damit kommen wir zu Persistent Chat. Persistent Chat Produkte gibt es seit langer Zeit und viele davon sind zusammen mit den entsprechenden Projekten gescheitert. Ihre Nutzung ist nicht trivial und Akzeptanz ist das zentrale Problem. Dies hat sich in den letzten drei Jahren geändert. Und der Grund dafür ist Slack. Slack hat Persistent Chat im Markt endlich erfolgreich etabliert und Großkonzerne wie IBM und Oracle setzen es Unternehmensübergreifend ein. Aber Chat ist eben kein Selbstläufer. Und es gibt eine ganze Reihe von Anforderungen, die wir in unserem Kriterien-Katalog erarbeitet haben, die man besser sehr ernst nimmt. Und bewertet man Cisco Spark/Webex Teams damit, dann sieht das Produkt nicht aus. Microsoft Teams ist besser, aber immer noch als problematisch einzustufen. Dagegen ist die Tab-/Menu-Struktur pro Kanal schlicht genial. Endlich können verschiedene Informations-Typen in einem Kanal sauber voneinander getrennt werden. Jeder Slack-Benutzer wird bestätigen, dass dies zu komplett unbenutzbaren und chaotischen Kanälen führen kann. Teams hat hier eine sehr elegante Lösung gefunden. Trotzdem hat Teams hier seine Schwächen im Detail. Es bleibt der Zweifel, ob das Produkt für große Teams mit vielen Kanälen skaliert. Von den UCC-Produkten kommt aus unserer Sicht am ehesten Unify Circuit den Anforderungen eines Chat-Tools nahe. Aber wie gesagt, das diskutieren wir ausführlich in unserer Sonderveranstaltung zu diesem Thema.
Schlechte Team- und
Kanal-Strukturierung
UCC-Produkte schaffen Transparenz im Team und im Unternehmen. Dieser sehr zentrale Punkt wird häufig übersehen. Eine Entscheidung für Transparenz muss bewusst getroffen werden, sie ist eine elementare Kultur-Frage. Der zu zahlende Preis dafür ist eine Flut von Informationen, die es in E-Mail-Lösungen so nicht gibt. Und gerade dieser Aspekt wird bei der Produktauswahl schnell unterschätzt. Die typische Beschwerde eines UCC-Benutzers ist: „habe gar nicht gesehen, dass du was gepostet hast“. Und dies ist nicht nur ein Problem der Benachrichtigungs-Funktion. Die Anzahl der Teams, die Anzahl der Kanäle und die potentielle Länge der Kanäle müssen ausgewogen sein. Und es muss klar sein, wo etwas gepostet wird und wo man etwas findet. Der Verweis auf die Suchfunktion ist hier nicht hilfreich. Ja, die muss es geben und die muss gut sein, ggf. sogar KI basiert. Aber trotzdem muss es möglich sein, auch ohne Suche einen direkten Überblick zu bewahren. Dies ist leider nicht so einfach zu erreichen. Wir haben dazu einen Erfahrungsbericht auf unserer Sonderveranstaltung. Dies ist auf den ersten Blick eine Anforderung an die Gestaltung und an die Konfiguration des UCC-Produkts. Bei näherer Betrachtung der Produkte gibt es aber auch Limitierungen in den Produkten. So gibt es Produkte, die von der Handhabung her eher bewusst auf kleine Teams und kleine Kanäle zugeschnitten sind. Dies kann passen, muss es aber nicht.
Organisatorische Einführung scheitert
Wie heißt es so schön in Zeugnissen: er bemühte sich sehr. Es reicht nicht aus, tolle Ziele zu haben. Sie müssen auch umgesetzt werden. UCC und speziell Kollaboration ist gleichzusetzen mit Änderung. Jede Änderung wichtiger Abläufe wird immer auf Wiederstände stoßen. Dies ist wie ein Naturgesetz. Und bei UCC gilt: Projekterfolg tritt nur dann ein, wenn alle Mitarbeiter das Produkt in gleicher Weise und intensiv nutzen. Und damit sind wir bei dem typischen Kardinalfehler solcher Projekte. Wer UCC als weiteres Tool unter vielen einführt und dann darauf wartet, dass alle begeistert darauf springen, der ist nicht sehr realistisch. Und so ist neben der Vermeidung anderer Fehler bei der Einführung eine zentrale Schlüsselentscheidung zu treffen: das UCC-Tool muss alle anderen parallelen Tools inklusive der Email ablösen. Anders formuliert: die Nutzung der Email für eine interne Kommunikation muss verboten werden! Änderungen erfolgen eben nicht freiwillig. Mitarbeiter sind träge und haben sich an „ihre“ Tools gewöhnt. Die Lösung liegt in der organisatorischen Erzwingung der Nutzung. Und dazu muss das Tool die dafür erforderlichen Anforderungen erfüllen. Wer versucht, ein dafür ungeeignetes Produkt zu erzwingen, der wird daran keine Freude haben. Die Auswahl des richtigen Produkts schafft das unverzichtbare Fundament für die Durchsetzung des Produkts. Nun ist niemand perfekt, auch kein UCC-Projektmanager. Ein begleitendes Change-Management sollte deshalb von Beginn an etabliert werden. Die Klagen der Nutzer, und diese werden kommen wie eine Lawine, müssen erst genommen werden. Anpassungen werden erforderlich sein, es muss zwingend ein Feintuning geben. Die Zeit und der Aufwand dafür inklusive der Schulung der Nutzer müssen auf der Kostenseite und in der Projektplanung berücksichtigt werden.
Ein spezieller Aspekt bei der Einführung von UCC ist die Erstellung einer Lösch- und Archivierungs-Strategie. Generell wird man anstreben, eher Kanäle aufzubauen, die klein sind und eine kurze Nutzungszeit haben. Fokussierung und thematische Eingrenzung ist hier das Ziel. Dies führt zwangsläufig zu einer hohen Zahl von Kanälen. Nach Abschluss eines Themas sollten solche Kanäle entweder archiviert oder gelöscht werden. Dies erfordert eine entsprechende Klassifizierung der Kanäle. Im Kern erinnert das stark an die Fähigkeiten eines Dokumenten-Management-Systems. Hier ist es unverzichtbar, um die Menge an sichtbaren Kanälen so gering wie möglich zu machen. Der Unterschied zwischen Archivierung und Löschung ist wichtig und erheblich. Archivierte Kanäle sind weiterhin durchsuchbar. An dieser Stelle hat Microsoft Teams eine seiner Schwächen. Es kann weder archivieren noch löschen. Man kann einen Kanal nur unsichtbar machen, dies kommt funktional einem Archivieren nahe, wenn man so will. Trotzdem führt dies auf Dauer in eine chaotische Situation. Wir vermuten, dass die Probleme dabei in der Nutzung von SharePoint liegen. Wenn man einen Kanal löscht, müsste auch der SharePoint mit allen Dokumenten gelöscht werden. Hinzu kommen Pro-bleme der Abgrenzung zwischen Kanal und Team. Dies ist aber ohne Frage ein spannendes Thema. Es kann ja durchaus sein, dass die Dokumente eine andere Lebensdauer haben sollen als der Chat-Bereich. Diese Problematik einer möglichen Trennung des Life-Cycles von Chat und Dokumenten betrifft aber im Kern alle Produkte.
Der Netzwerk Insider gehört mit seinen Produkt- und Markt-Bewertungen rund um IT-Infrastrukturen zu den führenden deutschen Technologie-Magazinen. Der Bezug des Netzwerk Insiders ist kostenlos.
ComConsult GmbH
Pascalstraße 27
DE-52076 Aachen
Telefon: 02408/951-0
Fax: 02408/951-200
E-Mail: info@comconsult.com
