Die Annahme, dass sich viele Dokumenten Management Systeme (DMS) am Markt nur marginal unterscheiden, hält sich hartnäckig. Dabei gibt es keinen Funktionsstandard, den man auf jeden Fall erwarten kann. Bereits bei den DMS-Kernfunktionen unterscheiden sich die Systeme mehr als erwartet. Was ist zu beachten bei der Auswahl der geeigneten DMS-Lösung?

Ich dachte, das ist Standard…

Das eine, beste System für alle Anwender gibt es nicht. Dazu sind u.a. die Anwender, Rahmenbedingungen und Anforderungen, aber nicht zuletzt natürlich auch die am Markt verfügbaren Lösungen viel zu unterschiedlich. Für ein DMS gibt es keinen allgemeingültigen Standardumfang. Bereits auf grobem Level unterscheiden sich die Lösungen erheblich voneinander, z.B.

• in ihrer Architektur (z.B. Technologien auf Client- und Serverseite, mehrstufige Systeme, Verfügbarkeit eines Transportwesens, Ausprägung der Mandantenfähigkeit, Virtualisierbarkeit oder Betriebssicherheit)
• in ihren Infrastrukturanforderungen (z.B. unterstützte Datenbanken, Anforderungen an Ausstattung und Anzahl der benötigten Server und das Netzwerk)
• in den Kernfunktionen, siehe Abbildung 1 (z.B. welche DMS-Kernfunktionen verfügbar sind, ob diese alle vom gleichen Hersteller oder auch von Drittanbietern kommen oder wie diese in die Anwendung integriert sind)
• ihrer Bedienbarkeit (Benutzerergonomie der Clients, den Client-Plattformen wie z.B. Rich-Client, Browser-Client, Mobile App, ggf. aber auch separate Akten-, Tablet- oder Offline-Clients)
• in ihrer Administrierbarkeit (z.B. erforderlicher Aufwand, Fähigkeit einer dezentralen Administration)
• in ihren Möglichkeiten zur Integration mit anderen Fachverfahren. Das können sowohl weit verbreitete Standardlösungen sein, die man ggf. mit standardisieren Schnittstellen bedient oder generische Werkzeuge zur Integration in Legacy-Applikationen oder solche ohne eigene Schnittstelle zum Andocken von Fremdsystemen.
• ihren Lizenzmodellen (z.B. Named vs. Concurrent User, Server- und Modul-Lizenzen oder Seitenpreise)

Abbildung 1: Mögliche Funktionsbereiche eines DMS

Allein am deutschen Markt sind die DMS-Produkte von über 60 Herstellern vertreten, wenn man die Betrachtung auf branchenübergreifende, unternehmenstaugliche Komplettlösungen einschränkt. Hinzu kommen zahlreiche Erweiterungen von Partnerunternehmen der Hersteller, internationale Lösungen, Speziallösungen (Nischenlösungen) oder Einzelplatzsysteme. Während auf der einen Seite eine Reihe an Lösungen nicht die architektonischen und administrativen Anforderungen für international agierende Unternehmen und Konzerne mit verteilten Standorten erfüllen, gibt es auf der anderen Seite Lösungen von großen, internationalen DMS-Anbietern, die sowohl preislich als auch aufgrund ihrer Anforderungen an die IT-Infrastruktur und den Administrationsaufwand meist nicht für mittelständische – und keinesfalls für kleine – Unternehmen betreibbar sind.

Kleine Unternehmen mit einer 1-Mann-IT sind nicht in der Lage, ein komplexes DMS technisch zu betreiben und den erforderlichen Support für die eigenen Anwender zu leisten. Für solche Unternehmen sind z.B. Cloud-basierte Lösungen interessant, oder Betriebsmodelle, bei denen bereits der First-Level-Support vom DMS-Hersteller oder einem Dienstleistungspartner geleistet wird. Demgegenüber stehen große Unternehmen, die eine DMS-Lösung im eigenen Haus betreiben und die Systeme selbst administrieren. Sie erwarten zum Teil von den Lösungen, dass diese in einem definierbaren Umfang dezentral und eigenständig von Bereichs- oder Fachadministratoren verwaltet und erweitert werden können und stellen daher entsprechende Anforderungen an die Dokumenten Management Systeme und deren Administrationswerkzeuge.

Auf der einen Seite gibt es also die Lösungen kleinerer Anbieter, die eher den unteren KMU-Markt adressieren und nicht beliebig nach oben skalierbar sind, auf der anderen Seite lassen sich große Lösungen oft nicht nach unten skalieren. Dies ist aber keine feste Abhängigkeit: So gibt es z.B. unter den mittelständischen Herstellern auch solche, die sich durchaus für international aufgestellte, große Unternehmen eignen. Während sich früher vorrangig große Unternehmen mit dem Thema DMS beschäftigt haben und in den letzten Jahren immer mehr mittelständische Unternehmen und öffentliche Einrichtungen ein DMS implementiert haben, beschäftigen sich heute immer mehr Unternehmen aus dem unteren Mittelstandssegment (mit 50 Mitarbeitern oder weniger) mit einer möglichen DMS-Einführung. Und auch kleinere Unternehmen und Organisationen haben das Thema auf dem Radar.

Selbstverständlich unterscheiden sich die Lösungen aber auch in der Funktionalität und dies nicht nur – wie oben bereits dargestellt – in der Anzahl der verfügbaren Kernfunktionen, sondern auch in der Ausprägung, d.h. den Detailfunktionen einer jeden Funktionsgruppe, wie z.B.:

• Erfassung von Dokumenten, Dateien und sonstigen Unterlagen
• Dokumentenklassifikation, Index- und Datenextraktion
• Dokumentenverwaltung, u.a. mit Versionierung und Attribuierung
• Aktenfunktionen
• Dokumentenanzeige
• Speicherung und Archivierung
• Client-Funktionen z.B. in Rich-, Browser-, Tablet- oder Smartphone-Clients
• Suchfunktionen für Volltext- und Attributsuche
• Integration in Office- und E-Mail-Anwendungen
• Scan-, Indizierungs- und Validierungsfunktionen
• Workflow- und Postkorb für Szenarien wie Frühes Scannen aber auch zur Automation von Redaktions- und Bearbeitungsprozessen bis hin zur Integration in systemübergreifende Abläufe
• Massendruckarchivierung
• Integration in ERP- bzw. Fachanwendungen (inkl. verfügbare Standardintegrationen z.B. in SAP, SharePoint oder bestimmte FiBu-Anwendungen)
• Collaboration-Funktionen
• Individualisierbarkeit für Benutzer und Benutzergruppen
• Entwicklungsschnittstellen (API, Web Services, etc.)
• Integrationswerkzeuge oder Standard-Schnittstellen für Output- und Retrievalintegration in andere Fachanwendungen
• Verwaltungs-/Administrationswerkzeuge für die einzelnen Funktionen
• Mandanten- und Hosting-Fähigkeit

Die Anwender unterschätzen häufig die erheblichen Unterschiede im Detail bereits bei den Basisfunktionen eines DMS. Beispiel Versionierung: Gibt es einen linearen Versionspfad oder sind Verzweigungen (engl. branches) möglich? Unterstützt die Lösung eine ein- oder mehrstufige Versionierung? Werden Versionsnummern automatisch oder manuell vergeben? Zeit ein Link auf die damals verlinkte Version oder die aktuelle Version eines Dokumentes? Ist dies abhängig vom Prozess konfigurierbar? Können beim Erzeugen von Hauptversionen Ereignisse, z.B. wie das Erzeugen einer PDF-Rendition (eine zweite Anzeigeversion des Dokumentes) oder der Start eines Workflows, ausgelöst werden? Können die Nebenversionen der Hauptversionen – mit Ausnahme der aktuellsten Hauptversion – automatisch gelöscht und alle Hauptversionen automatisch revisionssicher (unveränderbar) in PDF konvertiert und archiviert werden? Beziehen sich Versionen auf einzelne Dateien oder auf logische Dokumente (z.B. den Vertrag in der Version 1.0 als Word zusammen mit einer entsprechenden PDF-Rendition)? Und dies ist nur eine von Hunderten von Einzelfunktionen die eine Gesamtlösung ausmachen.

Derartige Unterschiede lassen sich allein durch den Vergleich von zwei oder drei Vertriebspräsentationen nicht identifizieren. Die Vermutung, dass die teureren Produkte bzw. die Produkte der großen, internationalen Hersteller automatisch eine umfangreichere Funktionsvielfalt mit sich bringen, wird meistens sehr schnell enttäuscht. Zum Teil fehlen Funktionen, von denen der Anwender denkt, dass sie eigentlich nicht hinterfragt werden müssten (z.B. Drag & Drop von E-Mails aus Outlook in die Akte, Werkzeuge zur Aktenmodellierung, Ablage per „Speichern unter…“ aus beliebigen Anwendungen, der Export von Dokumentlisten in ein Tabellenformat und viele andere mehr). Und bei manchen Systemen lassen sich die Oberflächen nur sehr aufwendig – d.h. durch teure Professional Services Mitarbeiter – den Wünschen der Fachbereiche so anpassen, dass diese vernünftig damit arbeiten können, während manche mittelständischen Hersteller diese Anpassungen mit einfachen Customizing Werkzeugen durch den Anwender selbst ermöglichen. Auch dies sind nur wenige, willkürlich herausgepickte Beispiele aus einer Vielzahl von Einzelaspekten.

Um zu vermeiden, dass die gewählte Lösung nach der Vertragsunterzeichnung immer teurer wird,

• indem zusätzliche Lizenzkosten, z.B. für benötigte Zusatzmodule oder Komponenten von Dritt-Anbietern, entstehen,
• die Dienstleistungsaufwände, z.B. durch Change Requests oder vom Standard abweichende Individualprogrammierung, unvorhergesehen steigen
• oder die Anwender die Lösung ablehnen und die Nutzung ganz oder teilweise verweigern,

sollte man im Vorfeld der Beschaffung einer DMS-Lösung Zeit und Aufwand einplanen, um eine geeignete Lösung mit Hilfe einer strukturierten Vorgehensweise auszuwählen.

Ein DMS-Projekt ist zu mindestens 51% ein Orga-Projekt.

Ein DMS-Projekt ist vor allem auch eine organisatorische Aufgabe. Die Beschaffung von Technologie wird weder die Probleme beseitigen noch die Anwender dazu überreden, Verfahrensweisen zu ändern. Es ist daher wenig zielführend, wenn man im Auswahlverfahren eine generische Liste an potentiellen DMS-Funktionen für verschiedene Produkte vergleicht, bei der alle Anbieter aufgrund der fehlenden Konkretisierung gleich gut abschneiden. Der Mangel liegt an der fehlenden Detaillierung derjenigen Anforderungen, die für den Anwender kurz- und mittelfristig wichtig sind und wo sich die Systeme tatsächlich voneinander unterscheiden. Typische Beispiele sind:

• Technische Anforderungen: z.B. Konformität zur vorhandenen IT-Infrastruktur client- und serverseitig
• Fachlich-funktionale Anforderungen: Welche der oben genannten Funktionsbereiche werden benötigt?
• Organisatorische Anforderungen: Welche Prozesse müssen, z.B. durch eine frühe Erfassung von Rechnungen oder der gesamten Eingangspost, angepasst werden? Welche Zuständigkeiten verschieben sich gegebenenfalls? Wie ändert sich die Arbeitsweise?
• Regulatorische Anforderungen: Welche rechtlichen Vorgaben, aber auch unternehmensinternen Regelungen und Risikoabwägungen müssen beachtet werden, z.B. bzgl. der Aufbewahrungsfristen, dem Ersetzenden Scannen oder der Dokumentformate? Ist nur deutsches oder auch internationales Recht zu berücksichtigen?

Zu diesem Zweck sollten sowohl die IT als auch der/die betroffene/n Fachbereich/e im Projekt mitarbeiten, letztere werden häufig über die Orga-Abteilung vertreten. Es ist empfehlenswert, dass die Projektleitung durch eine duale Besetzung aus Vertretern dieser beiden Bereiche zusammengestellt wird. Die Fachbereiche allein sind nicht in der Lage die Anforderungen an eine den IT-Rahmenbedingungen konforme und später auch administrierbare Lösung zu beschreiben. Auf der anderen Seite kann die IT nicht allein die fachlich-funktionalen Anforderungen definieren, da diese sowohl von den Sollprozessen als auch der Arbeitsweise der Endanwender abhängig sind.

Was brauchen wir wirklich?

Ausgehend von den Herausforderungen und Problemen der Ist-Situation müssen die Anforderungen an eine Lösung beschrieben werden. Vorgefertigte, generische Funktionslisten aus dem Internet oder aus anderen DMS-Projekten sind meistens ungeeignet und sogar gefährlich. „Unterstützen Sie Workflow?“, „Haben Sie eine Outlook-Schnittstelle?“, „Gibt es eine SharePoint-Integration?“ sind Beispiele für Fragen, die man auf keinen Fall stellen sollte, weil kein Anbieter dazu „Nein“ sagen kann. Das Ergebnis einer Reihe solcher Fragen führt zwangsläufig zu einem Ergebnis welches aussagt, dass die verglichenen Produkte nahezu gleich sind. Das Gegenteil entspricht aber der Realität.

Vielmehr sollten nur solche Anforderungen gestellt werden, die für den Anwender bzw. Fachbereich auch relevant sind und die er auch bewerten kann. Diese sollten dann in geeigneter Weise so detailliert werden, dass anhand der Antworten entschieden werden kann, ob Art und Umfang der Funktionen die Anforderungen abdecken, z.B. dass mehrere Outlook-Mails per Drag & Drop in einem Zug in das DMS übernommen werden können und automatisch mit Hilfe der vorhandenen E-Mail-Metadaten attribuiert werden, oder dass eine Output- und Retrieval-Integration für konkret definierte Dokumente aus einer Fachanwendung konfigurierbar ist.

Neben den fachlich-funktionalen Anforderungen an sich muss aber auch entschieden werden, ob das System durch den Kunden selbst betrieben, oder durch einen Dienstleister gehostet werden soll. Es muss ermittelt werden, ob ein Dienstleister spätere Anpassungen am System, wie z.B. die Anpassung von Workflowabläufen oder das Einrichten neuer Anwendungsbereiche, vornehmen soll, oder ob die eigene IT in der Lage sein soll, dies eigenständig durchzuführen. Sofern die IT-Administratoren oder sogar Fach-Administratoren später Änderungen an der implementierten Lösung vornehmen sollen, müssen entsprechende Werkzeuge ebenfalls mit bewertet werden.

Soll eine zwei- oder mehrstufige Systemumgebung (z.B. Test- und Produktivsystem) aufgebaut werden, macht es z.B. einen Unterschied, ob und in welchem Umfang ein Transportsystem vorhanden ist, um die Einstellungen von einer Systemstufe auf die andere zu übertragen, ohne alles nachkonfigurieren zu müssen.

Benutzerergonomie

Es reicht jedoch nicht aus, nur die funktionalen und technischen Anforderungen zu überprüfen. Gerade die Benutzerfreundlichkeit – die Frage, ob eine Lösung durch die Mitarbeiter der anfordernden Bereiche bedienbar ist – kann einen direkten Einfluss auf den Projekterfolg haben. Eine technisch gute Lösung kann trotzdem scheitern, wenn die Anwender die Arbeit mit der Lösung verweigern.

Neben grundsätzlich verschiedenen Bedienkonzepten sind die Anwendungsfunktionen – sofern sie überhaupt im Standard verfügbar sind – sehr unterschiedlich implementiert und lassen sich dadurch nicht immer einfach nutzen: Ist für die Ablage einer E-Mail in eine Akte ein lokales Zwischenspeichern erforderlich oder das Anlegen eines Ad-hoc-Workflows zu kompliziert, dann ist damit zu rechnen, dass die Akzeptanz des Systems bei den Endanwendern sinkt.

Daher sollten diejenigen, die später tagtäglich mit der Lösung arbeiten sollen, auch in den Auswahlprozess einbezogen werden und die Systeme in der engeren Auswahl bzgl. der Bedienbarkeit bewerten, z.B. anhand vorbereiteter Detail-Präsentationen mit einer einheitlichen Agenda über zuvor ausgewählte Use-Cases.

Fazit

Sowohl die Anforderungen an ein DMS als auch die am Markt verfügbaren Lösungen unterscheiden sich sowohl in den abgedeckten Funktionsbereichen als auch in den Detailfunktionen – und das bereits bei DMS-Basisfunktionen. Um das beste System für die eigenen Anforderungen auszuwählen, muss bereits bei der Auswahl berücksichtigt werden, dass von einem DMS-Projekt sowohl die IT-Infrastruktur, Schnittstellen zu anderen Fachverfahren, fachliche Anforderungen und Arbeitsweisen der Endanwender und nicht zuletzt auch organisatorische Fragestellungen tangiert werden.

Die Auswahl des Systems und auch des Implementierungspartners hat einen erheblichen Einfluss auf den Projekterfolg und die dauerhafte Betriebsfähigkeit der betroffenen Einsatzfelder.

Um eine geeignete Lösungsplattform auszuwählen, die sowohl die aktuellen als auch mittelfristig zu erwartenden Anforderungen abdecken kann, ist eine gute Kenntnis des DMS-Marktes sehr hilfreich und ein strukturiertes Vorgehen mehr als nur empfehlenswert.