Machtfrage 'Teams oder SharePoint?': Wie Office 365 zukünftig die ECM-Strategie der Unternehmen verändert
Teams, das ‘New Kid on the Block’ von Microsoft stößt auf großes Interesse im Markt. Doch nicht alle brechen in Jubelstürme aus. So sitzen viele gestandene SharePoint-Architekten zwischen den Stühlen in Sachen ECM-Strategie: Wirft Teams die über die Jahre aufwändig mit SharePoint aufgebauten Mechanismen für Dokumentenmanagement über den Haufen? Wo findet zukünftig Kollaboration statt? Müssen die klassischen Team Sites mit all ihren Konfigurationen jetzt ausgemustert werden? Und wie bringt man bisher gelebte Vorgaben des Informationsmanagements in Teams rein – und sollte man das überhaupt tun?
Teams macht jetzt vieles automatisch…
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 pro Instanz eine eigene SharePoint Websitesammlung (Site Collection) mit, ohne dass man etwas einrichten muss. Ein solches automatisches Provisionieren der Dateiablage ist toll, aber wo stellt man dann sein bisher verwendetes Projektwebseiten-Template für die Generierung der Site Collections ein? Schließlich steckt dort all das hart erarbeitete Customizing drin, das so eine SharePoint Site erst zu einer wirklichen Firmen-SharePoint Site macht.
… aber viele SharePoint-Elemente fehlen
Die erste ernüchternde Antwort: Teams erzeugt seine SharePoint-Site-Collections 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. Damit fehlen eine Reihe von vertrauten Elementen 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.Metadaten und Ansichten
Mit der neuen Modern View-Oberfläche stellt Microsoft auch auf SharePoint-Webseiten die Benutzeroberfläche so um, dass viel von dem alten 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 SharePoint-Arbeitsweisen im neuen Office 365-Standard allmählich an Bedeutung verlieren und auf alte SharePoint-Hasen irritierend „out“ wirken.
Ownership von teamorientier Arbeit
Teams wirkt so erfrischend neu und anders, weil es sich all dieses Ballasts entledigt. Plötzlich können Endanwender Aufgaben übernehmen, für die früher Experten erforderlich waren. So legt sich im Office 365-Standard der Anwender selbst im Client ein Team an, wenn er es benötigt. Von Microsoft wird das auch explizit so empfohlen. Anders kennt man das von angepassten SharePoint-Systemen, wo eine neue Projektwebseite meistens nur über einen definierten Prozess angelegt werden konnte. Hier steht am Ende dann oft ein Template, in dem genau festgelegt wird,
- welche Verzeichnisstruktur in der Standardbibliothek vorliegt;
- wie das Archivsystem für Compliance-Dokumente angebunden;
- 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.
Wer hat die Hosen an – Anforderer oder Produkt-Owner?
Daraus ergibt sich eine ganz andere Charakteristik, wer in der Gemengelage Anforderer – Produkt-owner – 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.
Die Teams-Adoption verläuft intuitiv
In Teams verschwimmen solche klassischen Vorgaben, weil sich hier wenig nach Vorgabe oder Einschränkung anfühlt. Benutzer in Teams arbeiten eher intuitiv: Erste vorsichtige 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 gegenüber dem Neuen 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.
Nicht mehr ECM-Regelwerk ist der Treiber, sondern Teamkommunikation
Dieser Überbau lässt die Mitglieder gegenüber dem Tool eine viel selbstbewusstere Rolle einnehmen, als das im klassischen Dokumentenmanagement mit SharePoint-Websites üblich ist. 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.
Doch in vielen Organisationen sind Regelwerke weiterhin unverzichtbar und erfüllen ihren Zweck, ob das Compliance ist, 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 SharePoint: auschecken – in Teams: gemeinsam bearbeiten
In einem anderen englischsprachigen Blogbeitrag 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 zur Frage, wann Teams oder SharePoint die bessere Lösung für eine Organisation ist. Empfiehlt sich die eher akademische Methode mit Metadaten, Implementierung des Dokumenten-Lebenszyklus und der Klassifizierung nach alter Schule, oder gilt ab jetzt das hippe Alles-egal? Sofern beide Optionen denkbar sind, stellen sich folgende 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 durfte, 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. Dem Microsoft-Ansatz, einfach mal alle Schotten aufzureißen wird hier in Deutschland kaum ein Unternehmen folgen wollen. Sinnvoller sind da sicherlich die ersten zarten Knospen einer PowerShell-Unterstützung.
Vorne arbeiten mit Teams, hinten kontrollieren mit SharePoint?
Am Ende läuft es allerdings in beiden Fällen immer auf die Einrichtung einer SharePoint Websitesammlungen hinaus. 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 Management-Tools 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 oder Metalogix 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.
Fazit: Die grobe Richtung ist erkennbar, aber noch ist vieles im Fluss
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 Teams-Verfechter im Unternehmen recht wenig, wenn damit die Metadaten-Strategie des Unternehmens 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.
(Der Originalbeitrag ist auf Spmoshpit.de erschienen.)
Im echten Leben ist er in Bremen Enterprise Architect und Head of Development bei der deroso Solutions GmbH. Schwerpunkte seiner Arbeit sind sowohl Office 365 und Azure als auch seit 2005 alle on-premise-Iterationen des SharePoint Servers. Er ist weiterhin mehrfach MCSE, MSCA, MCPD und MCTS.