DMS-Lösungen werden häufig mit papierlosen Prozessen assoziiert, als wäre das Hauptproblem der Anwender seit den 80er Jahren unverändert der Papiereingang. Für viele Unternehmen ist das sicher auch heute noch die Initialzündung für ein DMS-Projekt. Während aber das Papierproblem im Posteingang stagniert – wir kennen keine Kunden, die von steigenden Volumina im Posteingang berichten – wachsen die Probleme mit elektronisch geborenen Dateien und Unterlagen, sowohl im täglichen Posteingang (E-Mail) als auch bei den intern erzeugten Dateien. Die Folgen sind – dank sinkender Speicherpreise – wachsende Halden von Dokumenten und Unterlagen aller Art auf den File-Systemen und in den E-Mail-Ablagen. Das Problem ist häufig nicht der Speicherbedarf: Das ist wegen sinkender Preis eher selten ein Projektauslöser, wenn man von der Belastung der Infrastruktur durch verlängerten Backup- und Recovery-Zeiten und die Anbindung von Remote-Standorten mal absieht. Das größte Problem ist schlicht das baumstrukturierte Chaos in den Ablagen und die damit einhergehenden Nachteile:

• Keine verlässliche Ablage: Im File-System wird an einem Speicherort abgelegt („Rechnungswesen/Lieferanten/Schriftwechsel/Vertrag.pdf“). Der Pfad ist die Adresse und das ist die Ursache für viele Probleme. Kommt eine neue Version des Dokumentes hinzu oder wird das Dokument in einem anderen Ordner abgelegt, zeigen alle irgendwo gespeicherten Adressen auf die falsche Version. Der Ablageort ist nie eine gute Adresse. In einem DMS erhält das Dokument eine nicht-sprechende Content-ID, die mit Attributen verknüpft ist. Diese Content-ID wird in Fachsystemen hinterlegt und kann daher auch bei sich ändernden Attributen verlässlich wiedergefunden werden. Seltsamerweise haben manche ECM-Lösungen keine solche Content-ID zur Adressierung, sondern verwenden den fachlichen Ablagepfad wie in einem File-System. Architektonische Todsünde unserer Meinung nach; die besseren ECM-Lösungen nutzen selbstverständlich eindeutige Content-IDs.
• Da die File-Systeme häufig nach Abteilungsstrukturen verrechtet sind, werden Mehrfachkopien erzeugt, um die Dokumente auch in anderen Bereichen zur Verfügung zu stellen. Da der Ort und der Dateiname die Suchparameter darstellen, sind die Fehler vorprogrammiert. In einer ECM-Lösung können Dokumente n-fach in andere Ordnungsstrukturen (Akten, Vorgänge) verlinkt werden, die physische Ablage erfolgt nur einmal. Das Kopieren bei Mehrfachablage ist in solchen Systemen eine Option, kein Zwang.
• Keine fachlichen Attribute: Das File-System hat keine Datenbank, welche die Erstellung fachlicher Attribute erlaubt. Also behelfen sich Anwender damit, die Bezeichnung der Ordnerstrukturen als Ersatz für fachliche Attribute zu verwenden. Es gibt aber keine Möglichkeiten, Feldtypen zu definieren und man kann keine Relationen zwischen einem Dokumenten-Objekt und einem beliebig individualisierbaren Attribut-Set bilden, welches sich je nach Dokumentart unterscheidet. Mit anderen Worten: Vertragsunterlagen zu einem Lieferanten und dessen Rechnung im gleichen Ordner abzulegen, ist daher im File-System praktisch nicht möglich, wenn Rechnungen und Vertragsdokumente unterschiedliche fachliche Attribute benötigen.
• Keine attributbasierten Zugriffsrechte. In jedem besseren DMS kann man Lese- und Schreibrechte an Dokumentarten hängen und auch nach Schreiben, Lesen, Ändern differenzieren. Im File-System beziehen sich die Zugriffsrechte auf den Ort der Ablage und diese sind häufig bereichsspezifisch zugeordnet. In einer DMS-Lösung kann man unterschiedliche Rechte an die Dokumentarten hängen, sodass eine Akte mit unterschiedlichen Dokumentarten von unterschiedlichen Anwendergruppen mit unterschiedlichen Rechten genutzt werden kann.
• Keine systemgestützte Versionierung. Im File-System ist die Versionierung- wenn man das überhaupt so nennen kann – eine persönliche Versionierung mit Hilfe von Dateibezeichnungen (Vertrag_Final_Version03), was hochgradig fehlerbehaftet und für alle Mitarbeiter missverständlich und unzuverlässig ist. In einer DMS-Lösung kann die Versionsnummerierung durch das System erzwungen werden, wenn das gewünscht wird, der Dateiname spielt dafür keine Rolle mehr. Mit einem Versionssprung (zum Beispiel von Neben- auf eine neue Hauptversion) können auch Events verknüpft werden, wie beispielsweise die Archivierung aller Hauptversionen, aber nicht der Entwurfsversionen. Mit der Versionierung kommt dann auch die Möglichkeit, sich die Versionshistorie zu einem Dokument anzeigen zu lassen, sodass der Mitarbeiter nicht immer alle vorhandenen Versionen sieht, sondern nur die zum jeweiligen Zeitpunkt gültige.
• Keine Suche nach Attributen, keine Kombisuche: Suchen Sie mal im File-System nach Dokumentart „Rechnungen“ vom Lieferanten XYZ GmbH, jünger als 1.1.2014. Klar, solche Suchen gibt das Dateisystem nicht her. Erst recht nicht, wenn man diese Suche mit Volltext kombinieren will (alle Rechnungen vom Lieferanten XYZ jünger als 1.1.2014, in denen der Begriff „XYZ123“ vorkommt). Das ist Standard in jedem besseren DMS, inkl. der Möglichkeit solche Suchen zu speichern.
• Keine disziplinierbaren Aktenstrukturen: Dokumente werden in einem DMS in Ordnungsstrukturen (zum Beispiel einer E-Akte) abgelegt, die von den Mitarbeitern nicht einfach geändert werden können. DMS-Aktenstrukturen können sowohl statisch als auch dynamisch sein. In einem File-System sind sie eigentlich immer von Anwendern änderbar, eine Differenzierung nach statischen und dynamischen Elementen ist eigentlich praktisch nicht möglich. Eine moderne ECM-Lösung erlaubt beides: Akten können einen statischen Teil haben, der nur mit bestimmten Rechten oder gar nicht geändert werden kann. Und die Akte kann Strukturen enthalten, die situativ und nach Bedarf vom Endanwender angelegt werden können.
• Keine echten Akten. Das kann zwar nicht jedes DMS (was uns manchmal wundert), aber die besseren machen in der Modellierung der Ordnungsstrukturen eine Unterscheidung zwischen Akte und Dokument. Beide können eigene Attribute haben. Bei der Akte wären das beispielsweise Aktenzeichen, Entstehungsdatum, Status der Akte und beliebige weitere Attribute. Wird im Datenmodell des DMS unterschieden zwischen Dokumenten und Akten, können n:m-Relationen genutzt werden. Vereinfacht ausgedrückt: Dokumente können in mehrere Akten verlinkt sein, ohne sie kopieren zu müssen. Und das wiederum eröffnet neue Möglichkeiten bei der Aktennutzung: Das Bilden von Hand- oder Schwebeakten, das gleichzeitige Ablegen in Projekt-, Kunden- und Vertriebsakte ist so viel einfacher möglich und bei einer neuen Version muss man nicht zwangsläufig wissen, wo denn dieses Dokument noch abzulegen ist.

Quelle: Zöller & Partner ECM-Seminar

• Keine Rendition-Verwaltung. Wenn Vertragsdokumente sowohl im nativen Word-Format für die spätere Bearbeitung einer neueren Version, gleichzeitig aber auch als PDF abgelegt werden sollen (um das zu diesem Zeitpunkt geltende Layout einzufrieren und allen Mitarbeitern visuell unverändert zur Verfügung zu stellen), bieten moderne DMS-Lösungen sogenannte Rendition-Funktionen. Hierbei wird das Eingangsdokument in ein anderes Format konvertiert (Engl.: Rendering). Für 1 logisches Dokument (Vertrag 1.0) existieren jetzt zwei technische Ausprägungen (so genannte Renditions): die native Word-Datei und das konvertierte PDF. Der Endanwender muss das aber nicht wissen. Je nach Zugriffsrecht wird ihm nur das PDF oder, für berechtigte Autoren einer neuen Version, auch die native Version zur Verfügung gestellt. Die Rendition-Funktionen kommen häufig auch zum Einsatz, wenn bestimmte Dokumentarten ohne Mehrfachausführungen in PDF konvertiert werden sollen, also für Massenkonvertierungen. Für solche Zwecke genügt dann keine Client-seitige Konvertierung (wie man es manchmal bei einfachen TIFF- oder PDF-Druckern sieht), sondern skalierbare Serverdienste.
• Keine Multi-Format Viewer für gemischt-formatige Akten. Die Dokumente einer E-Akte bestehen häufig aus unterschiedlichen Formaten: PDF, JPEG, MS Office und Mail-Formate und so weiter. Das lässt sich auch nicht verhindern, da sich nicht alle Unterlagen in PDF konvertieren lassen, ohne dass Informationen oder Funktionen verloren gehen. Das gilt für Word-Funktionen ebenso wie für Excel-Formeln. MS Project-Dateien lassen sich gar nicht in PDF-konvertieren, hier werden nur funktionsreduzierte Druckansichten von Teilsichten der Gantt-Charts, Ressourcen- oder Kalenderansichten in PDF-konvertiert. PDF ist letzten Endes nur eine 2D-Druckansicht. Alles, was nicht problemlos in eine Druckansicht konvertiert werden kann, lässt sich nicht ohne Verluste in PDF konvertieren. Daher empfehlen wir unseren Kunden häufig die Ablage im nativen Format (wie im File-System). Beim Blättern in einer Akte wollen Anwender aber nicht bei jedem Formatwechsel eine andere native Anwendung laden. Daher gibt es Multi-Format-Viewer, die den Zwang zu Konvertierung in ein „Archivformat“ (was auch immer das angeblich sein soll) verhindern. Diese Viewer sind häufig in der Lage, nicht nur Bitmap-Formate wie TIFF oder JPEG, sondern auch andere Formate darzustellen. Die besseren unterstützen über 200 verschiedene Formate, einschließlich alter Formate wie Word Perfect oder AmiPro, sodass der Anwender diese alten Anwendungen auch nicht vorhalten muss, um die Dokumentinhalte noch anzeigen zu können.
• Keine Schutzfunktionen gegen unzulässige Manipulationen. Kernfunktion einer modernen DMS-Lösung ist das, was die Branche „revisionssichere Archivierung“ nennt. Im Prinzip geht es darum, jegliche unzulässige (versehentliche oder absichtliche) Manipulation während der gesetzlichen oder freiwillig auferlegten Schutzfrist (Aufbewahrungsfristen) so zu verhindern, dass ein sachverständiger Dritter die Wirksamkeit dieser Schutzfunktion prüfen kann. Im File-System ist das kaum machbar. Wenn ein Speicherbereich noch beschrieben werden kann (weil neue Rechnungen abgelegt werden sollen), kann er auch manipuliert werden. Wer schreiben kann, kann auch überschreiben (weil keine Versionierung) oder Löschen. In einem DMS ist das sehr einfach verhinderbar und war schon immer eine Kernfunktion. Rechnungen können abgelegt, aber nach Ablage nicht mehr gelöscht oder gar inhaltlich manipuliert werden.
• Keine Löschfristenverwaltung. Jedes bessere DMS hat nicht nur eine Schutzfunktion für bestimmte Dokumentarten, sondern kann diese Schutzfunktion mit absoluten oder relativen Zeitangaben verknüpfen. Eine E-Akte kann daher aus sehr unterschiedlichen Dokumentarten bestehen: Manche sind jederzeit löschbar, andere erst nach 10 Jahren und wieder andere erst nach „Beendigung des Vertragsverhältnisses + 10 Jahre“.

Quelle: Zöller & Partner ECM-Seminar

• Weitere Defizite im Vergleich zu einem DMS: Neben diesen Basisfunktionen hat ein DMS natürlich noch eine Reihe weiterer Funktionen auf Anwendungsebene, die im File-System gar nicht vorhanden sind, wie beispielsweise:
  • Keine Freigabe-/Genehmigungsprozesse für geregelte Dokumente.
  • Keine Verknüpfungsschnittstellen zur Integration mit externen Fachanwendungen mit dauerhaft stabilen Dok- und Akten-IDs
  • Keine Massenimport- und Export-Werkzeuge für Dokumente und Attribute
  • Kein Scan- und Indexieranwendung, die mit den Dokumenttypen der zentralen DMS-DB verbunden ist.
  • Keine Offline-Client-Funktionalität mit bidirektionaler Synchronisation
  • Keine Tablet-Funktionalität für iOS Tablets

Quelle: Zöller & Partner ECM-Seminar

Es macht wenig Sinn, ALLE Dokumente in ein DMS umzuziehen, weil damit Hürden verbunden sind: die Anwender müssen neue Bedienfunktionen lernen, absolute Links funktionieren bei den meisten DMS’en nicht mehr, das System ist aufwendiger zu administrieren und die Software kostet mehr als der File-System-Speicher. Aber für viele Dokumente und Dateien im geschäftlichen Alltag ist ein DMS sehr viel besser geeignet als das baumstrukturierte Chaos im XYZ-Laufwerk. Selbst wenn ein DMS nur einen Ersatz für einfache Ablagefunktionen zur Verfügung stellt, sind die oben aufgeführten Unterschiede starke Argumente. Wenn aber – was in den allermeisten Projekten der Fall ist – noch Integrations- und Workflow-Anforderungen hinzukommen, kommt man an einer DMS-/ECM-Lösung eigentlich nicht mehr vorbei.