Autoren: Bernhard Zöller, Volker Halstenbach, Jürgen Rentergent

„Microsoft365“ (ehemals Office365) steht für eine Vielzahl von Komponenten und Lizenzmodellen und nicht nur einfach für die aktuelle Bezeichnung der MS Office Suite, deren Vorläufer es bereits seit 1990 gibt, als MS Word, Excel und PowerPoint in einem einzigen Installationspaket (und Preis) ausgeliefert wurden. Wenn ein Kunde heute in einem DMS-/ECM-Projekt die „Integration mit Microsoft365“ wünscht, muss man erstmal klären, was damit eigentlich gemeint ist.
Grob kann man funktional unterteilen:

• Ablage und Aufruf von Dokumenten aus den Microsoft Bearbeitungsprogrammen MS Word, Excel, PowerPoint. Hier muss man wieder unterscheiden, ob es die klassischen Rich Client-Anwendungen sind (nur hier funktionieren die typischen Integrationsszenarien zur automatischen Ablage in die E-Akte, Check-out und Check-in, Versionierung etc. Aber bereits die Variante für die Apple Macs funktioniert hier nicht oder kaum, ganz zu schweigen von den nativen Apps für Apple iPads bzw. Android Tablets und Smartphones). Diese Apps tragen nur den gleichen Namen (Word etc.), setzen aber auf unterschiedliche Basistechnologien. Nur die Dokumentformate sind identisch und die Funktionalität ist eine Untermenge der bekannten MS Office-Funktionen, aber die Client-Architektur ist eine komplett andere, wodurch keine der technischen Integrationskomponenten aus der klassischen Rich Client MS Office-Welt hier anwendbar ist. Außerdem fehlen einige generische UI-Elemente wie Drag&Drop, Kontextmenüs etc.Für weit verbreitete Windows Rich Client MS Office-Anwendungen liefern DMS-/ECM-Anbieter häufig Erweiterungen in Form von Add-ins, Makros (früher) oder andere technische Komponenten, die sich in die Oberfläche der MS-Anwendungen integrieren und dem Anwender erlauben, das DMS für bestimmte Funktionen direkt zu nutzen, aus dem Kontext der MS-Anwendung heraus. Typische Beispiele sind Ablage, Einchecken etc. Wichtig: Klären Sie mit dem Anbieter, ob mit dem Tag der Verfügbarkeit einer neuen MS Office-Version auch der Support der bisherigen technischen Schnittstelle sichergestellt ist oder ob die Schnittstelle ebenfalls ein Update benötigt und wann der offizielle Support dann wieder verfügbar ist. In diesem Zusammenhang muss man berücksichtigen, dass Patches und neue Releases jetzt häufiger und automatisch kommen. Zwar hat ein Unternehmen / haben Behörden die Möglichkeit, diese Updates zu steuern (z. B. via Gruppenrichtlinien), aber bereits wegen der Sicherheitsproblematik lassen sich Updates nicht beliebig auf die lange Bank schieben.Noch etwas komplexer wird die Aufgabe, wenn noch weitere Drittkomponenten wie eine Vorlagenverwaltung in die Gesamtlösung zu integrieren sind.
•  Ablage und Aufruf aus MS Outlook. Ergänzend zu den o. a. Anmerkungen sind hier noch E-Mail-Besonderheiten zu erwähnen, wie
  •  Attribut-basierte Dublettenprüfung. Hashwert-basierte Dublettenprüfung funktioniert bei E-Mail nicht, wenn die Mail an mehr als eine Person geschickt wird und alle Empfänger ablegen sollen, aber eine mehrfache Ablage vermieden werden soll
  • Das Containerproblem: E-Mail enthält manchmal einen oder mehrere Anhänge, die vielleicht in den gleichen fachlichen Kontext, manchmal aber mit anderen fachlichen Attributen (andere Dokumentart) und manchmal sogar in einen anderen Aktenkontext abgelegt werden sollen.
  • Volltextsuche in Attachments: Wird eine E-Mail mit Attachments als EML- oder MSG-Container abgelegt, sind nicht alle DMS-Lösungen in der Lage, bei der Volltextsuche auch in den eingebetteten Attachments zu suchen.
  • Die o. a. Hinweise auf die Frage zur Releasefähigkeit der technischen Schnittstelle gelten hier ebenso.
• Integration mit all den anderen MS Office-Anwendungen wie Visio, MS Project etc. Die Forderung nach einer „technischen“ Integration in diese Anwendungen kommt in unseren Projekten so gut wie nie vor. Natürlich möchte man diese Dateien auch im DMS ablegen, aber das funktioniert fast immer mit Drag&Drop aus dem Dateisystem oder per „Speichern unter…“ in einen überwachten Ordner. Was nicht immer funktioniert, ist die Versionierung und die damit verbundenen Check-out- und Check-in-Funktionen aus der Oberfläche der MS-Anwendung heraus. Diese sind bei manchen DMS-/ECM-Produkten an Word, Excel, PowerPoint gebunden und für andere Formate (Editoren) gar nicht oder nur mit einer komplett anderen Benutzerführung möglich.
• Integration mit den MS Office Webapps, die auf einem Windows PC oder einem Apple Mac in einem Browser laufen. Diese heißen zwar auch „Word“, „Excel“, „PowerPoint“, haben aber einen deutlich reduzierten Funktionsumfang und lassen sich mit den bisher verwendeten Technologien nicht mit einem DMS integrieren. Die gilt natürlich ebenso für die nativen Office Apps (also keine Browser-Anwendung) für iOS oder Android.
• Integration in SharePoint. Bereits kurz nach dem Markteintritt von SharePoint Ende 1999 wurde diskutiert, ob und wenn ja, wie, eine Integration einer SharePoint-Anwendung mit einem DMS funktionieren kann. Diese Diskussion hält bis heute an. Unter anderem werden zwei Konzepte immer wieder diskutiert:
  • Auslagerung von Dokumenten aus dem SharePoint in ein DMS. Das wird immer dann diskutiert, wenn man der Ansicht ist, man könne im SharePoint selbst nicht „revisionssicher“ ablegen. Das ist aber faktisch u. E. nicht ganz richtig, weil man auch mit SharePoint-Werkzeugen eine ordnungsgemäße Aufbewahrung herstellen kann, nur eben nicht im Standard, sondern durch weitere Komponenten und mit deutlich mehr Aufwand als in einer DMS-Lösung.
  • Die Nutzung einer SharePoint-Portalanwendung als Frontend mit einem DMS als Backend. Die Sinnhaftigkeit dieser Variante konnten wir nie verstehen, weil das „Backend“ die Funktionalität für Suche, Trefferliste, Versionierung, Akten und Aktenverlinkung etc. vorgibt. Das Frontend kann also eigentlich nur ein SharePoint-Lookalike sein, in dem die gleiche Funktionalität wie im Standard DMS-Client nachgebaut werden müsste. Das haben wir bei keinem einzigen DMS-Anbieter gesehen, von funktional dünnen Demos mal abgesehen.
• Co-Authoring erlaubt das Überarbeiten von Dokumenten durch mehrere Personen gleichzeitig. Alle Beteiligten sehen hierbei mehr oder weniger synchron, wer welche Änderungen vorgenommen hat. Diese Funktion gibt es eigentlich schon seit einigen Jahren und auch auf anderen Plattformen (z. B. Google Docs). Co-Authoring erfordert eine spezielle Ablageumgebung sowie kompatible Dokumentformate (wie die XML-basierten Dokumentformate in MS Office). In einem normalen Filesystem (oder einem normalen DMS) ist Co-Authoring nicht möglich. Diese Funktion gab es in der Microsoft-Welt bereits mit Office 2013, aber schnell und einfach wurde es mit den späteren MS Office-Versionen ab Office 2016 und der Ablage in OneDrive bzw. SharePoint. Wird diese Funktion benötigt und sollen die Dokumente trotzdem in einem DMS liegen (wofür es gute Gründe gibt, aber das ist ein anderes Thema), wird es tricky, weil folgende Aufgabe gelöst werden müssen: Das Dokument soll weiterhin mit seinen zugehörigen Attributen, Versionen, Aktenverlinkungen und Berechtigungen im DMS liegen. Gleichzeitig soll es aber für das Co-Authoring parallel in ein anderes System (MS Teams, OneDrive, SharePoint) ausgelagert werden mit anderen Berechtigungen und anderer Versionierungslogik. Was heute meistens angeboten wird, ist das einfache Auschecken nach SharePoint (oder OneDrive) und nach dem Bearbeiten das Zurückholen ins DMS, aber ohne Synchronisation von Berechtigungen oder Versionen. Das ist eine pragmatische Lösung, die man sogar zu Fuß machen kann: Dokument aus dem DMS nach OneDrive/SharePoint/Teams kopieren, dort per Co-Authoring bearbeiten und nach Fertigstellung als neue Version wieder im DMS ablegen. Es ist natürlich bequemer, das per Klick machen zu können, statt sich manuelle Wege merken zu müssen.Wie relevant ist Co-Authoring oder ist es nur ein Gadget, das in der Praxis aber niemand nutzt? Bei uns (Zöller & Partner) verwenden wir die Funktion bisher eigentlich nie. Wenn wir untereinander oder mit Kunden an Dokumenten arbeiten, nutzen wir meistens die Screen-Sharing-Funktionen der Konferenz-Plattform, egal ob Webex, Zoom, MS Teams oder andere. Eine Person schreibt, die anderen kommentieren verbal und bei Bedarf übernimmt eine andere Person das Steuer. Aber wir können natürlich nicht ausschließen, dass es praktische Anwendungsfälle für echtes Co-Authoring gibt. Ich persönlich würde nicht gerne in einem Dokument arbeiten wollen, dessen textliche Inhalte kontinuierlich durch andere Personen geändert werden.
• Integration in MS Teams-Ablage. Eine weitere, relativ neue Anforderung wird mit der raschen Verbreitung von MS Teams diskutiert. MS Teams ist nicht nur eine Videoconferencing-Plattform (als die wir sie alle kennen), sondern eigentlich eine Collaboration-Plattform, die unter anderem auch für jedes Team und die dortigen Unterstrukturen (Kanäle genannt), Dateiablagen und Dokumenten Versionierung zur Verfügung stellt. Eigentlich ist MS Teams bzgl. der Dokumentenverwaltung eine Art SharePoint-Anwendungserweiterung. Bei Erstellung eines Teambereichs wird automatisch eine SP-Site erstellt und die Dokumente in Teams “Dateien” sind natürlich Dokumente im SharePoint. Die Kernfrage der Teams-Integration ist daher eigentlich schon 20 Jahre alt, weil exakt diese Frage mit dem Markteintritt von SharePoint bereits gestellt wurde: Wie viele verschiedene Ablagesysteme mit unterschiedlichen Berechtigungsstrukturen, Benutzerführungen, Verwaltungswerkzeugen will sich ein Unternehmen oder eine Behörde leisten? Und die Frage bezieht sich nicht nur auf das Budget, sondern auch auf die Zumutbarkeit für End-User und die IT. Daher besteht manchmal der Wunsch, die beiden Welten DMS und SharePoint (bzw. MS Teams-Dateiablage) so zu integrieren, dass zumindest der Aspekt Konsolidierung der Benutzeroberflächen für die End-User berücksichtigt wird. Aber diese Forderung ist nicht einfach abdeckbar, falls überhaupt. Wenn man beispielsweise eine DMS-Akte in den MS Team Client als iFrame einbaut, hat man innerhalb dieser Komponente die DMS-Benutzerführung für Auschecken, Einchecken, Versionshistorie, Aktenstrukturen etc. Es ist eben NICHT die gleiche Benutzerführung wie in Teams (oder SharePoint), sondern eigentlich nur eine Art Absprungseite in die Funktionalität und Benutzerführung eines anderen Systems. Will man die modernen Collaborationen-Funktionen von MS Teams und gleichzeitig die Vorteile von DMS-Lösungen nutzen (Archivierung, Aktenstrukturen, ggf. sogar auf Basis Aktenplan, team-/projektübergreifende attributbasierte Berechtigungen, Rendition-Funktionen, unveränderbare Dok-IDs und Folder-IDs u. v. a.), dann kommt man um eine 2-Säulen-Strategie nicht herum: Man muss definieren, welche Dokumente bzw. Dokumentenprozesse in welcher Plattform (DMS oder SharePoint/Teams) verwaltet werden sollen und muss den Endanwendern die unterschiedlichen Benutzerführungen nahebringen.

Geht man diese Abgrenzung nicht an, droht wieder – wie in den alten Lotus Notes/Domino-Zeiten – eine nicht mehr beherrschbare Vielfalt an kleinteiligen, isolierten Ablagen, weil nun jeder Bereich und jede Projektgruppe nach bestem Wissen und Gewissen macht, was sie für richtig hält.

Was hier für MS Teams/SharePoint gesagt wurde, gilt natürlich genauso für andere alternative Ablage- und Team-Plattformen wie Box, Confluence und viele andere mehr. Wir haben die Microsoft-Plattformen hier beschrieben, weil sie in unseren Projekten am häufigsten vorkommen.