Autoren: Bernhard Zöller, Marc-Björn Seidel

So unterschiedlich die verschiedenen DMS-Anwendungen und Einsatzfelder auch sein mögen: Wir kennen kein Projekt, in dem nicht die Anforderung zur Integration der DMS-Anwendung in andere Anwendungssoftware wie beispielsweise ERP- oder Fachanwendungen besteht. Nur: Was bedeutet eigentlich „Integration“?
Wir empfehlen dringend und ernsthaft, die Begriffe „Integration“ und „Schnittstelle“ erstmal zu vermeiden, und zwar so lange, bis allen Beteiligten (dem Projektteam, dem Anbieter) klar ist, was sie darunter verstehen. Doch wenn man den Begriff – wenigstens für die Lesezeit dieses Artikels – vermeidet: Wie soll man dann beschreiben, um was es eigentlich geht?
Wenn ein Unternehmen eine DMS-Lösung einführt, ist es ausnahmslos so, dass Dokumente, die im DMS aufbewahrt werden sollen, in anderen IT-Anwendungen entweder erstellt oder bearbeitet werden (z. B. Erfassen von Rechnungs- oder Antragsdaten) oder dort zur Sachbearbeitung notwendig sind (z. B. Zugriff auf die Akte, um Auskunft zu einem Sachverhalt geben zu können).
Hierdurch können eine Reihe legitimer Anforderungen entstehen:

Dokumenten-Verknüpfungsverfahren, Eingangsdokumente
Dokumente sollen direkt aus der Fachanwendungsoberfläche aus dem DMS heraus aufgerufen werden können. Statt also die Rechnung oder den Bauantrag im DMS suchen zu müssen, nachdem man die Rechercheattribute (Rechnungsnummer, Antragsnummer) in der Fachanwendung ermittelt hat, ist es komfortabler, die Recherche direkt in der Fachanwendung auszulösen. Das funktioniert manchmal so transparent, dass die Anwender gar nicht merken, dass sie gerade eine zweite Anwendung (nämlich das DMS) aufgerufen haben. Für diese Art der nahtlosen Recherche benötigt man unterschiedliche Verknüpfungsverfahren für Eingangs- und Ausgangsdokumente zwischen dem DMS und der Fachanwendung.
Für Eingangs- und intern erstellte Dokumente sind theoretisch über ein halbes Dutzend Verknüpfungsverfahren (siehe nachfolgende Abbildung) möglich. In der Regel sind mehrere Verknüpfungsverfahren erforderlich, da sich die Erfassungsanforderungen (frühes oder spätes Scannen, arbeitsteilige oder nicht arbeitsteilige Erfassung, Erfassen aus E-Mail etc.) von Bereich zu Bereich und manchmal sogar innerhalb eines Bereiches unterscheiden können.

Abbildung: Denkbare Verknüpfungsverfahren zu Eingangsdokumenten und internen Dokumenten, Quelle: Zöller & Partner DMS-Seminar

Ablage Ausgangsdokumente
Häufig besteht der Wunsch, Individual- oder Massenausgangsdokumente, die in Fachanwendungen generiert werden, im DMS abzulegen. Für Individualdokumente kann das noch einfach sein, wenn man „Drucken an DMS“ oder vergleichbare Funktionen nutzt. Massendruck ist dagegen fast immer mit hohem Dienstleistungsaufwand verbunden. Hier sehen wir in der Praxis unterschiedliche Ansätze: Manchmal stellt der Fachsystemanbieter eine Übergabespezifikation zur Verfügung, die vom DMS-Hersteller genutzt werden muss. In anderen Fällen – wie den klassischen Druckspool-basierten Verfahren – werden bei der Output-Erzeugung einzelne PDFs erstellt, um sie dann per Stapelimport in das DMS zu exportieren. Die für das DMS notwendigen Attribute werden entweder in der PDF-Datei selbst eingebettet oder in einer Indexdatei (früher CSV, heute häufiger XML) mitgegeben. Auf der Seite des DMS sorgt dann eine Importsoftware dafür, dass die PDFs automatisch aus Verzeichnissen eingelesen und indexiert werden. Danach wird die erfolgreiche Ablage quittiert und die Übergabeordner geleert. Im Fehlerfall erhält der Admin entsprechende Hinweise, bei welchen Dokumenten Fehler aufgetreten sind und er hat entsprechende Werkzeuge, um diese isolierten Fehler zu korrigieren.
Was wir in der Praxis auch gesehen haben: mehr oder weniger projektspezifische Lösungen, wo der Anwender oder der DMS-Hersteller eine Art Konnektor zwischen den beiden Systemen implementiert, um Dokumente aus der Fachanwendung direkt dem DMS zu übergeben.

Datenabgleich
Manchmal nutzt das DMS Daten der Fachanwendung als Dokumenten- oder Aktenattribute. Je nach Anwendungsfall können diese nur zum Zeitpunkt der Ablage eines Dokuments oder der Erzeugung einer Akte oder laufend synchronisiert werden. Greift jemand auf eine Liegenschaftsakte zu, soll z. B. der Status angezeigt werden, obwohl sich diese Daten ursprünglich in der Anwendung zur Liegenschaftsverwaltung befinden und dort federführend gepflegt werden. Für derartige Anforderungen müssen unidirektionale, synchrone oder asynchrone Datenabgleichverfahren oder Direktzugriffsverfahren zur Verfügung stehen Das gilt übrigens auch für den Abgleich mit den zentralen Rechteverwaltungssystemen (z. B. AD oder LDAP), aus denen in der Regel die Gruppenzugehörigkeiten der Personen gezogen werden und aus denen dann im DMS die Berechtigungen der Nutzer zugeordnet werden müssen.

Fernsteuerung
Ebenfalls nicht selten: Aus der Fachanwendung heraus werden komplexere Funktionen (nicht nur Belegrecherche) des DMS aufgerufen. Beispiel: Wenn in der Fachanwendung ein neuer Kunde angelegt wird, entsteht im DMS automatisch die zugehörige Kundenakte mit Aktenattributen und mit oder ohne Start-Dokumente. Ggf. wird auch ein Workflow im DMS gestartet und ein Vorgang Personen zur Abarbeitung zugewiesen. Hier genügt es nicht, den DMS-Anbieter zu fragen, ob bestimmte Funktionen für die Steuerung durch eine externe Anwendung zur Verfügung stehen, sondern auch in welcher Technologie der Funktionsaufruf zur Verfügung gestellt wird.
Und ab jetzt verwende ich die Begriffe „Schnittstelle“ und „Integration“ wieder. Bei allen den oben genannten Integrationsvarianten ist wichtig:

• Welche der relevanten Schnittstellenprodukte ist bei wie vielen Kunden bereits produktiv im Einsatz? Wenn es nämlich nur sehr wenige Kunden sind: Wer bezahlt dann für die Pflege dieser Schnittstelle? Im kommunalen Umfeld ist das eine besonders wichtige Frage, weil hier Dutzende von Fachverfahren kleinerer Softwarehersteller zum Einsatz kommen, die außerhalb der öffentlichen Verwaltung und außerhalb Deutschlands praktisch gar nicht relevant sind. Wie viel Aufwand soll also ein DMS-Hersteller für die Pflege einer Schnittstellenkomponente aufbringen, wenn nur eine Handvoll Kunden diese Schnittstelle einsetzen?
• Wie sieht der Support der Schnittstelle aus? Wie viele Personen im Support des DMS-Anbieters haben Fachwissen von den für die Integration notwendigen Komponenten der Fachanwendung? Wie sieht die vorausschauende Release-Pflege aus? Wenn der Hersteller der externen Fachanwendung eine neue Version herausbringt: Funktioniert dann die Schnittstelle noch? Weiß der DMS-Hersteller von den Änderungen „unter der Haube“ der Fachanwendung und kann er seine Schnittstelle rechtzeitig anpassen? Diese Frage gilt manchmal auch, wenn der DMS-Hersteller selbst eine neue Version seiner Software veröffentlicht: Funktioniert dann seine eigene Schnittstelle zur Fremdanwendung noch?
• Wie hoch ist der Einrichtungsaufwand und kann der Kunde die Schnittstelle z. B. per dokumentierter Parameter selbst pflegen? Benötigt er dafür Programmierkenntnisse oder kann die Schnittstelle über Customizing-Werkzeuge konfiguriert werden? Wenn also neue Druckjobs mit anderen Dokumentarten und Attributen hinzukommen: Kann der Kunde die Änderungen selbst einpflegen oder benötigt er die Dienstleistungen des DMS-Anbieters? Letzteres ist legitim, aber man möchte natürlich die anfallenden externen Kosten kennen, bevor die Verträge unterschrieben werden.

Gibt es denn keinen Integrationsstandard? Was ist mit CMIS?
Das Thema DMS/ECM und Integrationsstandards ist über 20 Jahre alt und die Antwort ist: eigentlich nicht.

Im Dezember 2000 wurde die DMA-Spezifikation (Document Management Alliance) arbeitsfähig vorgestellt und gleich danach beerdigt. In den frühen 2000er Jahren wurde mit JSR 170 eine Java-basierte Middleware verabschiedet, die sich ebenfalls nicht durchsetzte.

IBM, EMC und Microsoft waren dann die Gründer eines neuen, bei der OASIS beheimateten Versuchs, später unterstützt von Alfresco, OpenText, Oracle, und SAP. Im Mai 2010 wurde die erste Version der so genannten Content Management Interoperability Services (CMIS) veröffentlicht. Der Anspruch war, eine Art SQL für Content Management Systeme zur Verfügung zu stellen: Fremdaufruf von ECM-Systemfunktionen, ohne die Innereien der ECM-Lösung kennen zu müssen. Faktisch gibt es bisher eine Reihe von ECM-Herstellern, die CMIS unterstützen und bei Zöller & Partner sind wir davon überzeugt, dass genau so eine Schnittstelle notwendig wäre, um die Aufwendungen zur Integration in Fachverfahren zu reduzieren. Vor allem für die vielen kleinen und mittleren Anbieter von Fachverfahren wäre es eine exzellente Möglichkeit, sich in unterschiedlichste DMS-/Archiv-Lösungen zu integrieren, ohne die verschiedenen APIs verstehen und pflegen zu müssen.
Leider hat die OASIS am 09. Mai 2017 die CMIS-Arbeitsgruppe aufgelöst, sodass mit CMIS zwar eine funktionsfähige Spezifikation zur Verfügung steht (und in einigen Projekten zum Einsatz kommt), deren Zukunft aber ungewiss ist.

Was tun?
Ich glaube, wir haben im D.A.CH-Markt sehr viele DMS-Hersteller, die selbst oder über ihr Partnernetzwerk seit vielen Jahren ihre Lösungen in unterschiedlichste Fremdanwendungen integrieren. Wir empfehlen, die oben erläuterten Details bei den Anbietern zu hinterfragen, damit Sie schneller eine belastbare Einschätzung treffen können, ob Sie eine technisch programmierte Schnittstelle erhalten, die über die Nutzungsdauer der miteinander integrierten Systeme mit vertretbarem Aufwand lauffähig gehalten werden kann.