Document Management System (kurz: DMS) ist ein sperriger Begriff. Gemeint ist hier ein Ablage- und Wiederfinde-System für Dateien (PDF, Word, Excel, Powerpoint, Graphiken etc.), das die Zusammenarbeit mehrerer Personen in einer Gruppe unterstützt. Wenn das Team über das Land oder die Welt verteilt ist, befindet sich das DMS vorzugsweise im Internet.

Der Berater kennt das Problem zur Genüge: Wie mit einem Kunden zusammenarbeiten, der seine Unterlagen sicher im Intranet kursieren läßt und ablegt? Auf das Intranet erhält man keinen Zugriff. Andererseits ist das Hin- und Herkopieren dicker Dokumente über Emails und mit USB-Sticks auch keine Lösung. Bei vielen Email-Systemen liegt die maximale Nachrichtengröße noch zwischen 10 und 20 Megabyte und viele externe Firewalls lassen nur PDF durch. Heutzutage sind Dokumente aber größer, und nur mit PDFs läßt es sich nicht gut zusammenarbeiten. Es ist auch erstaunlich, wie leichthin viele Menschen Dokumente mit Emails verschicken. "Das ZIP-Paßwort ist meine Mobilnummer." Schön. Aber wer es schafft, eine Email mit einem vertraulichen Anhang abzufangen, sollte auch in der Lage sein, die Mobilnummer des Absenders herauszubekommen. PGP wiederum ist auf Firmenrechnern fast nie installiert. Wie also sicher und zuverlässig Dokumente austauschen?

Wer einen eigenen Server betreibt, auf dem ein DMS installiert ist, welches über HTTPS (also verschlüsseltes Web-Protokoll) erreichbar ist, verfügt schon über die wichtigsten Voraussetzungen, um diese Probleme zu lösen. Dokumente beliebiger Größen können dort gelagert werden, der Zugriff funktioniert weltweit, jede Übertragung über das öffentliche Internet erfolgt verschlüsselt. Mindestanforderungen an ein kundenfähiges DMS sind (A): es muß

• clientseitig mindestens mit Firefox, Internet Explorer, Safari und Opera funktionieren,
• die eigene, schnelle Administration der Nutzer und Zugangsrechte erlauben,
• ein ausgefeiltes Rechtemanagement bieten, das Kundenbereiche vollständig voneinander separieren kann (Mandantenfähigkeit),
• das Check-out/Check-in und möglichst auch eine Versionierung von Dokumenten erlauben

Das Rechtemanagement muß immerhin so leistungsfähig sein, daß ein Kunde, der Zugang zu dem DMS hat, nicht einmal die Namen der Ordner sehen kann, auf die er keinen Zugriff hat. Sie wollen Ihre Kunden ja vielleicht nicht unbedingt wissen lassen, für wen Sie sonst noch so arbeiten.

Die Suche nach dem richtigen System

Wer BSCW und Livelink kennt, weiß, wie ein DMS funktionieren muß und was es leisten muß. Leider sind BSCW und Livelink nicht (mehr) frei verfügbar. Damit sind wir beim nächsten Punkt. Wer einen eigenen Server betreibt, hat keinen Grund, für ein DMS einen kostenpflichtigen Service zu nutzen, der zudem den Nachteil haben könnte, daß man das Backup der Daten nicht mehr selbst effizient bewerkstelligen kann. Das DMS sollte also (B)

• als Open Source verfügbar sein,
• sich in einen LAMP-Server (Linux, Apache, MySQL, PHP) integrieren,
• Dokumente als Dateien abspeicheren (also keinesfalls als Binärobjekte in einer Datenbank), sodaß sie auch ohne den Weg über das DMS archivierbar und direkt auf dem Server lesbar sind,
• möglichst ohne Java SDK, Tomcat und andere Erweiterungen funktionieren, sondern nur mit reinem PHP und (wenn es unbedingt sein muß) Javascript.

Die Anforderung, ohne Java, JSP und andere Erweiterungen zu funktionieren, ist nicht zwingend. Dies war meine persönlicher Wunsch, da für die üblichen Anwendungen PHP serverseitig und Javascript plus Flash clientseitig alle wichtigen Funktionen bereitstellen. Was darüber hinausgeht, ist meist nur hübsche Spielerei, bläht die Installationspakete auf 15 Megabyte und mehr auf und macht die Installation und Pflege zu einem zeitraubenden Unterfangen.

Die Suche nach dem richtigen System ist nicht leicht. Die üblichen tabellarischen Gegenüberstellungen nach Art von Heise c't und Computerwoche helfen nicht weiter. Die Redakteure haben den Mainstream im Auge und verwechseln leider auch manchmal Content Management Systeme mit DMS, wozu Hersteller dieser Systeme aber auch ihren Teil beitragen. Beliebt sind heutzutage auch die Systeme, wo alles drin ist und ohne die X-te Kalenderfunktion kommt offenbar kaum noch ein Produkt aus.

Ein DMS ist aber keine Groupware und eine Groupware braucht nicht unbedingt ein DMS. Groupware hat Nachrichten-, Kalender-, Projektplanungs- und weitere Funktionen, die Abläufe innerhalb eines Projektes (den Workflow) unterstützen. Dokumentenmanagement hat damit wenig zu tun. Eine richtige Integration von Workflow und Dokumentenmanagement schaffen nur große, oftmals teure Produkte, die innerhalb einer Organisation eingesetzt werden können. Das ist gerade das Gegenteil der Situation, wie ich sie eingangs geschildert habe. Groupware-Funktionen nutzt eine freier Berater gerade nicht gemeinsam mit seinen Kunden.

Dementsprechend lohnt es kaum, bei der Suche nach dem richtigen DMS die üblichen Verdächtigen unter den Open Source Groupware-Produkten abzuklappern, wie PHProjekt, OpenGroupware etc. Es gibt in diesen Produkten zwar meist die Zuordnung von Dokumenten zum Projekt, aber sie sind nicht mandantenfähig, da jedes Gruppenmitglied die Gesamtstruktur sehen kann.

And the winner is...

Ich bin bei meiner Recherche (Anfang 2008) schließlich auf zwei geeignete DMS gestoßen: Epiware und Owl - die Eule. Beide Systeme leisten das Geforderte nach den Listen (A) und (B). Beide Produkte ließen sich jeweils innerhalb einer Stunde vollständig installieren, die Anleitungen in den Readme-Dateien reichten aus, waren bei Epiware aber präziser.

Epiware kommt professionell daher, es steht eine richtige (kleine) Firma dahinter und es gibt das Produkt mit Premium Support für Firmen. Das Rechtemanagement leistet genau die geforderte Mandantenfähigkeit, aber nicht mit viel zusätzlichem Komfort. Neue Releases gibt es (zu) häufig: 4.8.5 im Januar 2008, 4.8.4 im November 2007, 4.8.2 im Oktober 2007. Wichtig ist: Die Firma dahinter läßt auf Zukunftssicherheit hoffen, und vielleicht bekommen sie auch noch heraus, was sie mit ihrem Produkt erreichen wollen. Das Produkt kann man sich auch als gehostete Lösung vorstellen. Der übliche Kalender und zusätzliche Schmankerln wie Gantt Charts, Aufgabenliste und Wiki sind dabei. Für eine Groupware aber noch weitaus zu wenig, das Dokumentenmanagement (bezeichnenderweise unter dem Menüpunkt "Library" und dort unter "Shared Drive" versteckt) dagegen wie gesagt ausreichend, aber doch spartanisch.

Deshalb habe ich mich schließlich für Owl entschieden. Owl strotzt vor Bescheidenheit und sieht überhaupt wie ein "typisches" Sourceforge-Projekt aus, man weiß nicht recht: Lebt es noch oder ist es schon entschlafen? Noch lebt es: Release 0.95 im Oktober 2007, 0.93 im September 2006 - sparsamer geht es wohl nicht. Dokumentation ist leider fast keine vorhanden, das Vorhandene verdient den namen Dokumentation nicht. Die vielen Optionen und Einstellmöglichkeiten lassen sich mit drei Stunden Probieren und etwas Phantasie erkunden. Also alles in allen wirklich ein typisches Sourceforge-Projekt.

Bei Owl mußte ich insgesamt 8 der installierten Dateien leicht modifizieren:

• bei zweien war dies im Rahmen der Installation vorgesehen,
• zwei PHP- und zwei CSS-Dateien mußte ich nur leicht anpassen, um Owl meinem eigenen Seitenlayout anzugleichen,
• zwei PHP-Dateien mußte ich korrigieren, damit Owl auch mit dem Internet Explorer funktioniert.

Es geht also leider nicht ganz ohne LAMP-Kenntnisse. Daß der Internet Explorer nicht funktionierte, war einigermaßen ernüchternd; die Entwicklermannschaft steht mit ihm offensichtlich auf Kriegsfuß. Auch ärgerlich ist, daß PHP viele Warnungen wegen nicht ganz sauberen Codes in die Logfiles schreibt. In der FAQ von Owl wird empfohlen, das Warnungsniveau von PHP heraufzusetzen - warum beseitigen die Burschen nicht einfach die Unsauberkeiten?

Zu den Stärken von Owl zählen:

• die weitreichende und ziemlich vollständige Funktionalität, wenn man es mit den Benchmarks BSCW und Livelink vergleicht,
• die Vielsprachigkeit,
• die zahlreichen Optionen und Einstellmöglichkeiten,
• die äußerst fein einstellbaren Rechte auf Ordner- und Dateiebene über Gruppen und individuell über detaillierte Access Control Lists (ACL),
• die Integration in eine vorhandene Nutzerverwaltung,
• die Fähigkeit, untergeschobene Dateien zu adoptieren.

Eine unerwartete freudige Überraschung war, daß Owl bereit ist, extern authentifizierte Nutzer zu bedienen. Da ich auf meinen Seiten bereits eine Nutzerverwaltung habe, kann ich die Authentifizierung selbst vornehmen und Owl im Sinne eines Single Sign-on (SSO) den Namen des autorisierten Benutzers übergeben. Die Verwaltung der Owl-spezifischen Zugriffsrechte erfolgt selbstverständlich innerhalb von Owl.

Erfreulich ist auch, daß man existierende Dateibäume in das Dokumentenverzeichnis von Owl direkt auf Linux-Ebene kopieren kann. Findet Owl solche neuen Dateien, werden diese automatisch mit voreingestellten Eigentümernamen und Zugriffsrechten katalogisiert.

Es mag noch weitere Systeme geben, die ebenso gut wie Owl die genannten Anforderungen erfüllen. Für Hinweise bin ich dankbar. Vielleicht hilft dieser Artikel aber einigen, ein ähnliches Problem, wie ich es hatte, schnell und ohne viel Sucherei zu lösen.