Mit dem CMIS-Standard („Content Management Interoperability Services“) wurde bereits 2010 von Branchengiganten wie Microsoft, IBM und Oracle ein Standard vorangetrieben, um den Zugriff auf ECM-Systeme zu vereinheitlichen. Inzwischen sind knapp vier Jahre und eine weitere Version von CMIS ins Land gezogen und es stellt sich die Frage: wie wichtig ist dieser mit großen Vorschlusslorbeeren bedachte Standard im Jahre 2014, vor allem für kleine und mittelständische Unternehmen, die eventuell sogar gerade das für sie passende ECM-System aussuchen?

Was macht CMIS überhaupt?

Einfach ausgedrückt beschreibt der CMIS 1.1 Standard auf seinen ca. 330 Seiten, wie man ein beliebiges ECM-System „verwenden“ kann, ohne dabei irgendwelche Besonderheiten des Produkts zu kennen oder gar die Oberfläche des Programms zu benutzen. Wer sollte das aber tun wollen? Sicherlich nicht die normalen Anwender bei der täglichen Arbeit (schließlich haben sich die Verantwortlichen ja bewusst für ein ECM-System mit seinen besonderen Eigenschaften und dem Aussehen der Bedienoberfläche entschieden).

Stattdessen ist dieses Feature natürlich vor allem interessant, um anderen Programmen in der Systemlandschaft (z.B. dem Auftragsmanagement oder dem ERP-System) den Zugriff auf den Inhalt des ECMs zu ermöglichen bzw. eine Möglichkeit anzubieten, Daten in das ECM einzuspeisen. Da nur die „allgemeinen“ Operationen und Eigenschaften benutzt werden, die CMIS anbietet, kann man damit Anbindungen entwickeln, ohne hierfür die Besonderheiten eines bestimmten Systems zu kennen.

Ein paar technische Details für Interessierte

Im Rahmen des CMIS-Standards wird eher selten von ECM-Systemen gesprochen. Stattdessen wird hierfür der allgemeinere Begriff „Repository“ verwendet. CMIS standardisiert also den Zugriff auf Repositories, die als Inhalt sogenannte „Objekte“ der folgenden Typen haben:

• Dokumente (die eigentlich zu verwaltenden Informationen im ECM, z.B. eine Rechnung)
• Ordner (in diesen liegen die Dokumente, wodurch sich eine hierarchische Ordnung ergibt)
• Beziehungen (setzen zwei Dokumente zueinander in Bezug, z.B. Kundenstammdaten mit Rechnung)
• Rechte (Wer darf welche Objekte lesen/schreiben/löschen?)
• Item (Dokumente, die nicht versioniert werden müssen, z.B. Konfigurationseinstellungen)

Darüber hinaus kann jedes Repository noch eigene spezialisierte Typen für Objekte definieren, z.B. ein besonderes „Rechnungsdokument“, welches dann eigene Eigenschaften wie „Rechnungsbetrag“ oder „Rechnungsnummer“ aufweisen kann. Zudem definiert CMIS noch diverse Dienste, mit denen man auf diesen Objekten operieren kann. Eine der wichtigsten Operationen besteht dabei sicherlich darin, über eine standardisierte Abfragesprache bestimmte Mengen von Dokumenten aus dem Repository auszulesen. Es werden aber auch Operationen zum Anlegen und Löschen von Dokumenten sowie zum Navigieren innerhalb der Ordnerstrukturen angeboten.

(Zu) Vieles ist optional

Beschäftigt man sich etwas näher mit CMIS, wird schnell deutlich, dass der Standard zwar viele schöne Dienstleistungen und Konzepte beschreibt, diese aber häufig als „optional“ gekennzeichnet sind. Damit bleibt es letztlich dem Hersteller des jeweiligen ECM-Systems überlassen, ob er sich die Mühe macht, die entsprechenden Teile des Standards überhaupt zu unterstützen. Ein Beispiel hierzu: die Objekttypen „Dokument“ und „Ordner“ müssen zwingend von einem Repository unterstützt werden, um dem Standard zu entsprechen. Beziehungen, Rechte und auch Items sind jedoch „optional“. Ein ECM muss diese Konzepte gar nicht kennen oder unterstützen und darf sich trotzdem als CMIS-kompatibel bezeichnen. Sogar die essentiell wichtige Abfragesprache muss nicht unterstützt werden, um das Gütesiegel „CMIS-kompatibel“ zu erhalten.

Wie wichtig ist CMIS also für mich?

Prinzipiell spricht natürlich nichts dagegen, dass ein ECM-System den CMIS-Standard unterstützt: Die Software kostet deshalb keinen Cent mehr und sie besitzt dadurch in jedem Fall eine weitere Möglichkeit, die Daten auch wieder aus dem System heraus zu bekommen. Darüber hinaus bietet aber ohnehin jedes ernsthafte ECM native Möglichkeiten, über spezifische Schnittstellen und Exportfunktionen auf den gespeicherten Inhalt zuzugreifen bzw. den Content im System zu manipulieren. Diese sind eben nur nicht „für alle ECMs“ gleich, dafür aber häufig mächtiger, schneller und einfacher zu verstehen als die CMIS-Pendants.

Allgemein sollte man die Erwartungshaltung nicht zu hoch ansetzen und hoffen, dass mit CMIS der Datenaustausch wie von Zauberhand von alleine erfolgt. Für einfache Szenarien, wie beispielsweise dem Erstellen von Berichten, entfällt zwar der Programmieraufwand, da die entsprechenden Reporting-Tools oft von Haus aus CMIS beherrschen. Trotzdem muss die Zuordnung der darzustellenden Informationen immer noch von Hand durchgeführt werden. Dass so etwas durchaus kompliziert sein kann, können sich Interessierte gerne in folgendem Video ansehen, welches die Anbindung der Reporting-Software „JasperReports“ an ein ECM über CMIS zeigt. Ob man sich das wirklich selbst und ohne Hilfe durch einen fachkundigen Berater zutraut, bleibt natürlich jedem selbst überlassen.

Sollen die Daten nicht nur aus dem ECM ausgelesen sondern neue Daten hinzugefügt werden, ist es auch mit CMIS in den meisten Fällen nach wie vor erforderlich, kleine Programme (häufig als „Connector“ bezeichnet) entwickeln zu lassen, welche die Daten beispielsweise aus der Buchhaltungssoftware oder dem Email-Server auslesen und diese in das ECM einspeisen. Der Vorteil gegenüber der Verwendung proprietärer Schnittstellen kommt in diesem Fall erst dann wirklich zum Tragen, wenn eines Tages das vorhandene System durch ein neues (vielleicht auch von einem anderen Hersteller) ersetzt werden soll. In der Theorie muss dann nur das neue ECM eingerichtet werden und alle Anbindungen an die restliche Systemlandschaft funktionieren nahtlos weiter. Dies klappt aber auch nur dann, wenn das neue System mindestens genauso „CMIS-kompatibel“ ist, wie das alte. Fehlen dem neuen System wichtige, als optional markierte Funktionen des Standards, muss man schließlich doch wieder Geld in die Hand nehmen, um die entsprechenden Hilfsprogramme anpassen zu lassen.

Gerade für kleine und mittelständische Unternehmen ist diese Art von „Investitionssicherheit“ aber ohnehin nur bedingt wichtig: Die Einführung eines ECM-Systems stellt eine nicht zu unterschätzende Investition in finanzieller und zeitlicher Hinsicht dar, weshalb in der Realität solche Systeme nicht ständig „wie die Socken“ gewechselt werden. Wird das ECM dann doch eines Tages durch ein neues abgelöst, ist der Aufwand um kleinere Individualprojekte auf den neuen Stand zu bringen wahrscheinlich vernachlässigbar gegenüber den Kosten, die ohnehin anfallen, nämlich für Beratungsleistung, Migration der bestehenden Daten sowie die Schulung der Benutzer. Zudem ist die Wahrscheinlichkeit hoch, dass die Individuallösungen über einen Zeitraum von mehreren Jahren ohnehin immer wieder angepasst werden müssen, sei es z.B. aufgrund einer neuen Version der Buchhaltungssoftware oder einer Veränderung bestimmter organisatorischer oder rechtlicher Rahmenbedingungen (wie z.B. bei der Einführung des SEPA-Systems).

Das Fazit

CMIS ist eine schöne Idee, welche bei großen Systemlandschaften mit mehreren ECM-Systemen und dem häufigen Einsatz von Reporting-Werkzeugen durchaus Sinn machen kann. Aber selbst dort wird der Eindruck dadurch getrübt, dass die Unterstützung für viele wichtige Eigenschaften optional ist, es also dem Hersteller überlassen wird, ob er sie überhaupt anbietet. Für kleine und mittelständische Unternehmen bringt CMIS aus meiner Sicht deshalb wenig bis keinen echten Mehrwert. Unterstützt das angedachte ECM also den CMIS-Standard nicht, sollte das die Kaufentscheidung nicht negativ beeinflussen, so fern es auch andere Möglichkeiten gibt, das System von außen vernünftig anzusprechen.

Dirk Weber