Vorgehensmodell DMS-Integration

Datenabgleichverfahren

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 keinen Integrationsstandard?

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 sollte man also 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.

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

www.zoeller.de