Microsoft Teams gegen den Rest: Deutungshoheit in der Office 365 ECM-Strategie

Das New Kid on the Block von Microsoft wird allgemein wohlwollend aufgenommen. Gestandene SharePoint-Architekten sitzen allerding zwischen den Stühlen bezüglich der ECM-Strategie: Wo findet Kollaboration denn jetzt statt? Wirft Teams die sorgsam über die Jahre aufgebauten Mechanismen für Dokumentenmanagement über den Haufen? Ist das bisherige Konstrukt der Team Sites mit all ihren Konfigurationen jetzt alt und ausgemustert? Wie biegt man bisher gelebte Vorgaben im Rahmen des Informationsmanagements in Teams rein und sollte man das überhaupt tun?

So schön die neue Teams-Welt auch ist: Wer lange Zeit teure SharePoint- und ECM-Consultants beschäftigt hat, um sein Informations- und Dokumentenmanagement mit den guten(?) alten Instrumenten von SharePoint zu implementieren, wird sich irgendwann mal beim Auseinandersetzen mit Teams und dessen Architektur fragend am Kopf kratzen. Teams bringt unter der Haube eine eigene SharePoint Site Collection pro Instanz mit, ohne dass man etwas explizit machen muss. Dieses integrierte Provisionieren der Dateiablage ist toll, aber wo stellt man sein bisher verwendetes Projektwebseiten-Template für die Generierung der Site Collections ein? Schließlich ist dort all das hart erarbeitete Customizing drin, was so eine SharePoint Site erst zu einer wirklichen Firmen-SharePoint Site macht.

Aber bis eben war das doch noch der Königsweg…

Die erste ernüchternde Antwort: Teams erstellt seine SharePoint Site Collection so, wie Teams das für richtig hält. Und wenn ein neues Team aus der Taufe gehoben wird, entsteht eben eine sehr rudimentäre Website, welche eigentlich nur für die Dateien-Registerkarte verwendet wird. Somit fehlen dann erst einmal Dinge wie

• Metadaten und Ansichten
• Content Types und Content Type Hub
• Informationsrichtlinien
• Workflows
• Vorlagen
• (Fast) alles andere Features, die prinzipiell im Rahmen von ECM mit Dokumentenbibliotheken in SharePoint möglich sind.

Flows werden seit kurzem direkt in Teams unterstützt (Artikel dazu folgt wahrscheinlich in nächster Zeit).

Microsoft stellt mit der Modern View auch auf SharePoint-Webseiten die Benutzeroberfläche so um, dass viel von dem Funktionsballast über Bord geworfen wird. Die Dateienanzeige in Teams schränkt das in ihrer Einfachheit allerdings sogar noch weiter ein. Und somit muss man konstatieren, dass die jahrelang praktizierten Vorgehensweisen im neuen Standard von Office 365 immer weniger Beachtung finden und auf den alten SharePoint-Hasen irgendwie irritierend „out“ wirken.

Ownership von teamorientier Arbeit

Teams wirkt so erfrischend neu und anders, weil es sich all dieses Ballasts entledigt. Im Standard – zumindest dem von Microsoft ausgelieferten – legt der Endbenutzer sich im Client selbst ein Team an, wenn er es benötigt. Das wird von Microsoft auch so explizit empfohlen. In entsprechend angepassten SharePoint-Systemen gibt es dagegen eine neue Projektwebseite meistens nur über einen definierten Prozess. Hier steht am Ende dann oft ein Template, in dem dann genau festgelegt wird, welche Verzeichnisstruktur in der Standardbibliothek vorliegt, wie das Archivsystem für Compliancedokumente angebunden ist und welche Features nicht gewünscht und hart deaktiviert sind. Alles schön nach dem Recht und der Ordnung, die während des Implementierungsprozesses definiert worden ist. Teams macht das Provisionieren hingegen beiläufig. Dokumentenmanagement ist nur noch ein Teilaspekt der kollaborativen Arbeit und es gestaltet sich mittlerweile ganz anders aus, wie das in den zuerst skizzierten Umgebungen gelebt wird.

Daraus ergibt sich eine ganz andere Charakteristik, wer in der Gemengelage Anforderer – Produktowner – Produkt denn überhaupt die Hosen an hat. Im klassischen SharePoint ECM wird durch Vorgaben und Richtlinien bisweilen recht fix vorgegeben, wie das Dokumentenmanagement vonstatten zu gehen hat. Wollte man das etwas bewertend färben, könnte man über die beamtentümelige Pomadigkeit eines vorgegebenen Korsetts lästern. Der Aussteller der Site Collections hat den Daumen drauf, was wie benutzt wird.

In Teams verschwimmen diese Vorgaben in der Art und Weise, dass sich hier wenig nach Vorgabe oder Einschränkung anfühlt. Benutzer in Teams verhalten sich oftmals eher intuitiv: Erste zarte Teilnahme an den Chats, die in den Kanälen stattfinden, hier mal eine Wortmeldung, da mal ein Dokument bearbeiten und – schwupps – ist man drin. Die Unsicherheit verschwindet recht schnell und die Schwelle der aktiven Mitarbeit wird durch die formlose Kommunikation deutlich gesenkt. Dadurch treten aber auch Regeln und Vorgaben in den Hintergrund, das Team organisiert sich soweit selbst. Erst in den Schnittstellen außerhalb des Teams greifen wieder die Mechanismen der Organisation.

Dieser Überbau lässt die Mitglieder gegenüber dem Tool mitunter eine viel selbstbewusstere Rolle einnehmen als das im klassischen Dokumentenmanagement auf SharePoint Websites. Nicht mehr das Regelwerk ist der Treiber der täglichen Arbeit, sondern die Kommunikation der Teammitglieder untereinander. Zugegeben, das ist jetzt etwas romantisiert angemalt, die bisherigen Erfahrungen in den Ausrollprozessen gehen aber tatsächlich in diese Richtung.

Je nach Umfeld ist letztere aber unverzichtbar und erfüllt auch einen entsprechenden Zweck, sei es Compliance oder schlicht und ergreifend die Unternehmensstrategie im Umgang mit dem Lebenszyklus von Dokumenten und ihrer Auffindbarkeit. Alt hergebracht ist also explizit nicht automatisch schlecht sondern steht wie so oft im Dienste der Anforderungen (oder halt diesen im Weg).

In einem anderen englischsprachigen Blog (ich finde es leider nicht mehr wieder) wurde diese unterschiedliche Herangehensweise einmal mit der ureigenen SharePoint-Funktion des Auscheckens illustriert. Während Benutzer in SharePoint explizit Dokumente im Rahmen der Zusammenarbeit auschecken, um möglichst exklusive Bearbeiten-Rechte zu erlangen, gibt Teams dafür noch nicht einmal die Möglichkeit im Client, das zu tun. Hier wird offensiv geteilt und jeder Benutzer aktiv eingeladen, sich im Zweifel auch gleichzeitig in den Dokumenten zu bewegen. Zugegeben, mittlerweile ist einiges mehr mit den Onlineclients und der gleichzeitigen Bearbeitung möglich. Dennoch: beides hat mit Kollaboration zu tun, allerdings jeweils mit ganz anderen grundlegenden Denkansätzen.

Welche ECM-Strategie hätten’s denn gern?

Zurück zum eigentlichen Thema. Was soll eine Organisation denn nun nutzen? Den eher akademischen Metadatenweg mit Implementierung des Lebenszyklus und Klassifizierung nach alter Schule oder das hippe Alles-egal? Wenn beides valide Optionen sind, stellen sich ein paar Fragen:

• Existiert bereits ein Dokumentenlebenszyklus in der Organisation, der analog oder digital bereits gelebt wird?
• Gibt es Compliance-Regeln, die den Einsatz von Teams für die Anwendungsfälle verbieten?
• Hat die Organisation bereits SharePoint im Einsatz und dort eine Arbeitsweise etabliert?
• Führt die Organisation Office 365 im Rahmen eines größeren Kulturwandels ein und fängt es auf der grünen Wiese an?
• Was sind überhaupt die anvisierten Nutzungsszenarien von Teams? Welche Use Cases sollen mit dem Client abgedeckt werden? (kleiner Tipp: Teams ist kein Intranet. Wirklich nicht.)
• Wie (stark) prägt die Unternehmenskultur Herangehensweisen an Software und die Implementierung von Lebenszyklen?
• Gibt es externe Faktoren/Systeme, die eine bestimmte Arbeitsweise einfordern?

Wenn ich eins als Dienstleister über die Jahre lernen durfe, dann ist das die Tatsache, dass gerade Unternehmen bisweilen fürchterlich unterschiedlich sind, was die Bewertung und Ordnung der genannten Punkte angeht. Was dem einen sein No-Go-Kriterium ist, stößt beim anderen auf beiläufiges Achselzucken und überhaupt keine Probleme. Den Ansatz von Microsoft, einfach mal alle Schotten aufzureissen wird zumindest hier in Deutschland kaum ein Unternehmen folgen wollen. Sinnvoller sind da sicherlich die ersten zarten Knospen einer PowerShell-Unterstützung.

Der Hybrid

Letztlich ist es allerdings so, dass in beiden Fällen jeweils SharePoint Websitesammlungen entstehen. Und wo ein SharePoint ist, ist bekanntlich auch meistens ein Weg. Auch wenn er aus Scherben und Dornen besteht und aussieht wie die verunglückte M.C.Escher-Hommage eines Dreijährigen. Warum also nicht die Vorzüge von Teams nutzen und im Hintergrund mit bekannten und üblichen Governancetools und Skripten für die richtige Governance sorgen? SharePoint strotzt vor APIs und Möglichkeiten, Strukturen und Inhalte zu steuern, und diverse Tool Hersteller wie AvePoint bieten umfassende Werkzeuge, die jahrelang erprobt sind.

Letztlich spricht nichts dagegen, auch die Websites von Teams so unter die Fuchtel zu nehmen, wie das vielleicht schon mit anderen SharePoint Websites passiert. Nur dadurch, dass der Lebenszyklus aus dem Teamsclient heraus gesteuert werden kann, gibt es einige Besonderheiten, die man dabei berücksichtigen sollte. Löscht ein Besitzer eines Teams selbiges, wird bekanntermaßen auch die dazugehörige Website direkt mit ins Nirvana gerissen. Das kann auch das beste Governancetool erst einmal nur mit einem „Nun denn.“ zur Kenntnis nehmen.

Trotzdem besitzt diese Zwitterstrategie einen gewissen Charme insbesondere dann, wenn man bereits Mittel und Wege im Einsatz hat, die Governance der existierenden Websites sicherzustellen. In diesem Fall fügt sich die Dateiablage der Teams grundsätzlich nahtlos ein.

Wie gehts von hier aus weiter?

Durch mehrere Einführungen von Teams im letzten Jahr hat sich in meinem Arbeitsumfeld das Für und Wider an vielen Stellen herausgeprägt. Um das in gesicherte Allgemeinplätze zu quetschen, ist es aber noch zu früh. Der Client ändert sich teilweise noch recht stark im Moment, weiterhin ist die Heterogenität dieser Einführung kaum geeignet, ein allgemeines Entscheidungsflowchart daraus zu basteln.

Bleibt (mal wieder) nur die Einzelbetrachtung. Die oben genannten Fragen bzw. deren Beantwortung geben eine grobe Indikation, in welche Richtung die eigene Organisation dabei steuern kann. Letztlich hilft ein glühender Verfechter für Teams im Kollegenkreis recht wenig, wenn dafür die Metadatenstrategie des Unternehmens damit begraben wird. Auf der anderen Seite ist es eine gute Gelegenheit, sich noch einmal Gedanken darüber zu machen, wo eigentlich was wann hin gehört. Wenn all das Dokumentenmanagement-Zeugs jahrelang wie ein Klotz mitgeschleppt wird und alle Kollegen aufgrund der Restriktionen nervt, dabei aber überhaupt keinen Mehrwert liefert bzw. nicht weiter benutzt wird, könnte man mal ins Grübeln kommen, ob nicht beispielsweise ein hybrider Ansatz etwas Dynamik in die Arbeitslandschaft bringen kann.

Das Thema ist spannend und verdient es, gerade mit den jüngsten Entwicklungen im Client weiter betrachtet zu werden. Gerne auch in den Kommentaren oder auf Twitter.