Dokumenten Management Systeme Marktübersicht 2013 · 2016-01-15 · III.1 Abgrenzung ECM und DMS Enterprise Content Management (ECM) hat sich seit vielen Jahren als Gattungsbegriff

Dokumenten Management SystemeMarktübersicht 2013

Hersteller und Produkte

Erstellt durch

Zöller & Partner GmbH www.zoeller.de

Impressum

Seite b September 2012 © Zöller & Partner GmbH

DMS-Marktübersicht 2013

Impressum

Autoren: Zöller & Partner GmbH, Otto-Volger-Str. 3c, 65843 Sulzbach/Taunus, www.zoeller.de

Copyright © Zöller & Partner GmbH, 2012

Herausgeber: Bitkom Research GmbH, Berlin, www.bitkom-research.de

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berech-tigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Waren-zeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Satzerstellung: CAP Studio, Erlangen, www.cap-studio.de Druck und Einband: Klever GmbH, Bergisch Gladbach, www.klever-digital.de

Alle Rechte sind vorbehalten. Ohne Genehmigung von Zöller & Partner ist es nicht gestattet, Inhalte dieser Marktübersicht zu vervielfältigen, unabhängig von der Art der Vervielfältigung (analog oder digital). Die elek-tronische Version dieser Marktübersicht darf zu Sicherungszwecken kopiert werden, dabei müssen aber die urheberrechtlichen Ansprüche gewahrt bleiben.


© Zöller & Partner GmbH September 2012 Seite c

Verzeichnisse

INHALTSVERZEICHNIS

I Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

II Grußwort des Herausgebers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

III Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

III.1 Abgrenzung ECM und DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2III.2 Warum Anwender in DMS-Lösungen investieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4III.3 Verwirrende Begriffs- und Angebotsvielfalt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5III.4 „Ich dachte, das ist Standard“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6III.5 Boom im Mittelstand: von den Großen vernachlässigt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6III.6 Vorbemerkungen zur DMS Marktübersicht 2013 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7III.7 Allgemeines zu den Anbietern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8III.8 Aufbau der Marktübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8III.9 Erläuterungen zu den Angaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

IV Erläuterungen zu den Abschnitten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

IV.1 DMS-Server-Plattform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10IV.2 Digitalisieren und Indexieren von Papierdokumenten (Capture-/Scan-Komponenten) . . . . . . 10IV.3 Capture OCR, Klassifikation, Index-, Datenextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14IV.4 Capture-Komponente für strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18IV.5 Capture-Komponente für zentralen Druckoutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20IV.6 Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21IV.7 DMS-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24IV.8 Aktenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26IV.9 E-Mail-Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28IV.10 Postkorb-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32IV.11 Workflow / Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33IV.12 Collaboration-Funktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34IV.13 Signatur-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36IV.14 Standards und Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37IV.15 Schnittstellen zu SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39IV.16 Schnittstellen zu weiteren führenden Anwendungen (z.B. ERP) . . . . . . . . . . . . . . . . . . . . . . . . . 40IV.17 SharePoint-Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42IV.18 Weitere Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

V Erläuterungen zu den Fragen in den einzelnen Abschnitten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

V.1 Stammhaus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45V.2 Allgemeine Angaben zum Anbieter in Deutschland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45V.3 Allgemeine Angaben zum Anbieter in Österreich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45V.4 Allgemeine Angaben zum Anbieter in der Schweiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45V.5 Mitarbeiteranzahl im Bereich DMS/ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46V.6 Umsätze im Bereich DMS/ECM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46V.7 Spezifische Einsatzfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46V.8 DMS-Server-Plattform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46V.9 Capture-/Scan-Funktionen im Anwender-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47V.10 Eigenständige Capture-/Scan-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47V.11 Capture OCR, Klassifikation, Index-, Datenextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48V.12 Capture-Komponente für strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50V.13 Capture-Komponente für zentralen Druckoutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50V.14 Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51V.15 DMS-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51V.16 Aktenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53V.17 Client-basierte E-Mail-Archivierung: MS Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53V.18 Client-basierte E-Mail-Archivierung: Lotus Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54V.19 Client-basierte E-Mail-Archivierung: Andere Mail-Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54V.20 System-getriebene E-Mail-Archivierung: MS Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54V.21 System-getriebene E-Mail-Archivierung: Lotus Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55V.22 System-getriebene E-Mail-Archivierung: Andere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Verzeichnisse

Seite d September 2012 © Zöller & Partner GmbH


V.23 Postkorb-Funktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56V.24 Workflow / Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57V.25 Collaboration-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57V.26 Signatur-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58V.27 Standards und Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58V.28 Schnittstellen zu SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59V.29 Schnittstellen zu weiteren führenden Anwendungen (z.B. ERP) . . . . . . . . . . . . . . . . . . . . . . . . . 59V.30 SharePoint Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60V.31 Weitere Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

VI Anbieterübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

VI.1 Ainea AG: Ainea-Pergamon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62VI.2 Akzentum GmbH: PROXESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76VI.3 Alfresco Software Ltd.: Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94VI.4 Allgeier IT Solutions: scanview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108VI.5 BDV Branchen-Daten-Verarbeitung GmbH: Uniarchiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128VI.6 Bernhard Starke GmbH: Starke-DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141VI.7 Beta Systems Software AG: Beta UX ContentMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160VI.8 Braintribe Holding GmbH: Content Service Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172VI.9 Canon Deutschland GmbH: Therefore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197VI.10 CC e-gov GmbH: CC DMS® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214VI.11 Ceyoniq Technology GmbH: nscale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231VI.12 COI GmbH: COI BusinessFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254VI.13 Comarch Swiss AG: COMARCH ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276VI.14 Consolidate Software GmbH & Co.KG: Consolidate C4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297VI.15 d.velop AG: d.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316VI.16 d.velop: ecspand. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339VI.17 Dieter Spielberg Document Management Systems GmbH: FileDirector. . . . . . . . . . . . . . . . . . 362VI.18 DM Dokumenten Management GmbH: lobo-dms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379VI.19 DMSFACTORY GmbH: TINCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397VI.20 DocuPortal: DocuPortal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409VI.21 DocuWare AG: DocuWare 5.1x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420VI.22 Dr.DOC GmbH: Dr.DOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440VI.23 Drivve: drivve/DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458VI.24 EASY SOFTWARE AG: EASY DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473VI.25 EASY SOFTWARE AG: EASY ENTERPRISE.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485VI.26 ELO Digital Office GmbH: ELOenterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505VI.27 ELO Digital Office GmbH: ELOoffice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528VI.28 ELO Digital Office GmbH: ELOprofessional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543VI.29 EMC Deutschland GmbH: Documentum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566VI.30 Fabasoft AG: Fabasoft Folio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586VI.31 Fasihi GmbH: Fasihi Enterprise Portal/feb2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608VI.32 forcont business technology GmbH: forcont factory FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620VI.33 Gräbert Software + Engineering GmbH: ArchivPlus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634VI.34 H&S Heilig und Schubert Software AG: PAM-STORAGE®. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655VI.35 HABEL GmbH & Co. KG: HABEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674VI.36 Hans Held GmbH Büroorganisation: REGISAFE public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692VI.37 Hyland Software, Inc.: OnBase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714VI.38 IBM: DB2 Content Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736VI.39 IBM: FileNet P8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759VI.40 INTENSIO GmbH: NOVIPLAN-DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783VI.41 IQDoQ GmbH: HyperDoc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798VI.42 IQUADRAT AG: PHOENIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820VI.43 Kendox AG: Kendox InfoShare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832VI.44 LIB-IT DMS GmbH: FILERO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854VI.45 Microsoft Deutschland GmbH: Microsoft SharePoint Server 2013 . . . . . . . . . . . . . . . . . . . . . 869VI.46 Multi-Support R&D A/S: Multi-Support Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882VI.47 Open Text: Open Text ECM Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904VI.48 Optimal Systems GmbH: OS|ECM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928


© Zöller & Partner GmbH September 2012 Seite e

Verzeichnisse

VI.49 OXSEED AG: OXSEED Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952VI.50 Perceptive Software: ImageNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969VI.51 proALPHA Software AG: proALPHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989VI.52 PROCAD: PRO.FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006VI.53 SAP Deutschland AG & Co. KG: SAP ECM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020VI.54 SAPERION AG: SAPERION ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038VI.55 SER Solutions Deutschland GmbH: DOXiS4 iECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056VI.56 SI Software Innovation GmbH: LDMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079VI.57 softgate GmbH: softgate-archiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094VI.58 Softwarebüro Krekeler: Office Manager Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112VI.59 T-Systems International GmbH: ECM Suite ImageMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127VI.60 UPTIME services AG: ARTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144VI.61 WeWebU Software AG: WeWebU OpenWorkdesk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161VI.62 windream GmbH: windream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175

Verzeichnisse

Seite f September 2012 © Zöller & Partner GmbH



© Zöller & Partner GmbH September 2012 Seite 1

Vorwort

I Vorwort

Der BITKOM hat Enterprise Content Management (ECM) in den Mittelpunkt seiner Agenda gerückt. ECM ist eines der wichtigsten Trend-Themen der IT-Branche und inklusive seiner Kernfunktionen DMS (Dokumenten Management Systeme) und Archivierung bei Unternehmen und Behörden häufig bereits unverzichtbarer Teil der IT-Landschaft geworden. Während in der Vergangenheit vor allem Großunternehmen in solche Lösungen investiert haben, hat sich mittlerweile ein sehr vielfäl-tiger Markt entwickelt, der die Vorteile solcher Lösungen auch für kleinere und mittlere Unter-nehmen sowie öffentliche Einrichtungen erschwinglich macht.

Diese Marktvielfalt kann aber auch hinderlich sein, weil sich der interessierte Anwender mit einer Fülle an neuen Themen auseinandersetzen muss, um dann in einem sehr dicht besetzten Wettbe-werb die für ihn geeignete Lösung zu finden.

Die vorliegende DMS-Marktübersicht hat das Ziel, diese Lernkurve zu verkürzen und die Recherche zu vereinfachen. Sie schafft einen neutralen Überblick über DMS-Kernfunktionen und das breit gefächerte Angebot auf dem deutschsprachigen Markt. Damit unterstützt sie ein Anliegen des BITKOM-Kompetenzbereichs ECM, der die Bedeutung der ECM-Themen im Markt und bei den Anwendern fördern möchte.

Die Teilnahme war unabhängig von der BITKOM-Mitgliedschaft und unentgeltlich, um sicherzu-stellen, dass der Leser einen möglichst umfassenden Überblick über das Angebot erhält. Wir freuen uns daher, dass über 60 Anbieter an der Erhebung teilgenommen haben.

Andreas NowottkaVorstandsvorsitzender im BITKOM-Kompetenzbereich ECM

II Grußwort des Herausgebers

Die vorliegende DMS-Marktübersicht beeindruckt mindestens in zweierlei Hinsicht. Dass es sich um ein Schwergewicht auf dem Markt für Marktstudien handelt, erschließt sich – zumal dem Bezieher der Druckausgabe – auf den ersten Blick bzw. beim ersten Anheben. Neben dem reinen Umfang besticht die Publikation durch ihre Qualität, die sich insbesondere in der systematischen und detaillierten Art der Hersteller- und Produktanalyse äußert.

Bitkom Research hat deshalb gern die Rolle des Herausgebers der Marktübersicht übernommen, die im Unterschied zur Vorgängerpublikation auch in elektronischer Fassung bezogen werden kann. Sie, sehr geehrte Leserinnen und Leser, haben damit die Wahl zwischen der gedruckten Ausgabe und der digitalen Datei. Wir sind gespannt, wie Sie sich entscheiden und werden dies bei zukünf-tigen Publikationen berücksichtigen.

Ob Sie die folgenden Seiten am Bildschirm oder auf Papier lesen, ich wünsche Ihnen eine erfolg-reiche Lektüre in dem Sinne, dass Sie exakt die Informationen finden, die Sie sich von der Markt-übersicht versprechen. Falls Ihr Analysebedarf über den DMS- bzw. ECM-Markt hinausgeht, lade ich Sie hiermit ein, einen Blick auf die Bitkom Research Homepage zu werfen. Dort finden Sie Informa-tionen zu weiteren Marktberichten und Dienstleistungen, die wir anbieten.

Dr. Axel PolsGeschäftsführer Bitkom Research GmbH

Einleitung

Seite 2 September 2012 © Zöller & Partner GmbH


III Einleitung

Seit mehr als inzwischen einem Vierteljahrhundert werden DMS-Lösungen in Behörden und Unter-nehmen eingesetzt und mit ihrer Hilfe werden vielfach Arbeitsprozesse deutlich effizienter abgewi-ckelt als vor deren Einsatz.

Trotz dieser für EDV-Anwendungen langen Historie erscheint der Markt für DMS-Lösungen intrans-parent. Bereits auf der Ebene grob formulierter Anforderungen finden sich überraschend viele Unterschiede zwischen den Produktangeboten, die weitgehend unbekannt sind. Umso deutlicher zeigen sich die Produktunterschiede bei genauerem Hinsehen. Für Anwender sind diese Produkt-unterschiede häufig von erheblich höherer Bedeutung als geahnt: Anstelle einer eigenentwickelten Lösung bei Fehlen der Funktion in Produkt A, könnte diese Funktion in Produkt B bereits im Stan-dard enthalten sein und durch einfaches Customizing bereitgestellt werden.

Die hiermit vorliegende DMS-Marktübersicht mit über 60 Produkten bietet dem Leser einen fundierten Einblick in die Vielfalt der im deutschsprachigen Raum angebotenen Lösungen. Dieser erste Eindruck kann zum Beispiel sehr gut genutzt werden, um im Rahmen einer Produktauswahl eine erste Sichtung vorzunehmen und sich im weiteren Auswahlverfahren auf die für die Lösung passenden Produkte zu konzentrieren. Für eine konkrete Produktauswahl ist allerdings die Darstel-lungstiefe auch dieser Marktübersicht nicht ausreichend, diesem Anspruch will und kann eine solche Übersicht aber auch gar nicht genügen bei der Komplexität und Funktionsvielfalt der Produkte.

III.1 Abgrenzung ECM und DMS

Enterprise Content Management (ECM) hat sich seit vielen Jahren als Gattungsbegriff für alle Arten von Systemen etabliert, deren Zweck es ist, Unterlagen und nicht bzw. gering strukturierte Informa-tionen aller Art zu verwalten, vorzuhalten und in unterschiedlichste Geschäftsprozesse zu inte-grieren. Im deutschsprachigen Markt gibt es mit solchen Anglizismen aber immer auch Abgren-zungsprobleme. Ein Problem entsteht durch die Schwierigkeit, Begriffe prägnant und sinnvoll zu übersetzen. Wie soll man den Begriff „Content“ inhaltlich korrekt übersetzen, der bei wörtlicher Übersetzung zu „Inhalt“ sinnentleert wird? Aber wenn jeder Anbieter unter Content etwas anderes versteht; was ist dann die semantisch korrekte Übersetzung? Gleiches Problem bei „Records Management“: „Aufzeichnungsverwaltung“? Natürlich nicht! „Arbeitsfluss“ für „Workflow“? Jeder kennt solche Beispiele. Einfachste Lösung: Wenn sich am Markt kein Konsens für eine Übersetzung durchsetzt, behält man die – aus unserer Sicht – besser zu verstehenden englischen Begriffe bei, weil sie schlichtweg – so zumindest unsere Meinung – zu weniger Missverständnissen führen als semantisch unverstandene oder gar unsinnige Übersetzungen. Mit anderen Worten: man belässt es bei „Records Management“, „Enterprise Content Management“, „Workflow“ genau wie bei „ERP“ und weiteren Begriffen mit all ihren Unschärfen, weil jeder Übersetzungsversuch das Problem noch vergrößern würde.

Ein weiteres Problem solcher Abkürzungen ist, dass sie auch schnell in die Hype-Schublade abge-legt werden. Gerade in der IT-Branche gibt es zahllose Beispiele von Technologie-Hypes, die man dann bald wieder vergessen konnte oder die als eigenständiges Thema heute nicht mehr sichtbar sind, weil sie in anderen Themen aufgegangen sind. Beispiele gefällig? ILM (Information Life Cycle Management), KM (Knowledge Management), IDMS (Integrated Document Management System), EAI (Enterprise Application Integration), BPR (Business Process Reengineering) u.v.a.

Diesbezüglich schätzen wir den Begriff Enterprise Content Management aber komplett anders ein. Er hat sich nach unserer Wahrnehmung seit Jahren sowohl im internationalen als auch im deutsch-sprachigen Markt verbreitet. Aber im deutschsprachigen Markt hat sich bereits viele Jahre vor der Verbreitung von „ECM“ der Begriff Dokumenten Management (Systeme, DMS) etabliert und wird auch heute noch weitgehend verwendet. Vor allem viele kleinere und mittlere Anwender assozi-ieren mit ihren Anforderungen nicht unbedingt eine „Enterprise“-Lösung. Es gibt außerdem eine gleichnamige Fachmesse (die jährlich stattfindende DMS Expo), die zur Etablierung des DMS-Begriffs beiträgt. Und wer im Internet nach „DMS“ recherchiert, wird sehr häufig auf Webseiten von Firmen stoßen, die sich sowohl als DMS-Anbieter im obigen Sinne verstehen, sich aber auch im Bereich ECM positionieren.



Einleitung

Für den Neueinsteiger ist es daher nicht immer erkennbar, ob es sich bei DMS und ECM nur um Synonyme oder unterschiedliche Marktsegmente mit Überlappungen handelt. Weil sie aus unserer Sicht keine echten Synonyme sind, möchten wir die beiden Begriffe anhand der folgenden Abbil-dung miteinander vergleichen und abgrenzen.

Abbildung 1: Abgrenzung DMS und ECM

Wichtige, implizite Aussagen in dieser Abbildung sind:

• Archivierung ist kein eigenständiger Markt (mehr). Archivierung im Sinne von „über die Dauer der Aufbewahrungsfrist gegen unzulässige Manipulation schützen und die Reproduktionsfä-higkeit sicherstellen“ kann jedes moderne DMS. Die Zeiten, als man dafür dedizierte Archiv-systeme kaufen musste, sind lange vorbei. Die Funktion Archivierung ist aber selbstverständ-lich nach wie vor in vielen DMS- und ECM-Projekten wichtig und häufig genug der Projektauslöser.

• Aktenverwaltung und Automatisierungen in Dokumenten-zentrischen Prozessen („Workflow“) sind keine exklusiven Eigenschaften einzelner Säulen des ECM-Marktes (also nur DMS, oder Archiv oder Collaboration), sondern Anforderungen, die viele Anwender in unterschiedlichen Bereichen an ihre Dokument-verwaltenden Systeme stellen.

• Die Abgrenzung zwischen Collaboration- und DMS-Lösungen fällt zunehmend schwer. Jede Collaboration-Lösung hat Dokumenten-verwaltende Funktionen und viele moderne DMS-Lösungen weisen teilweise auch Collaboration-Funktionen auf (mehr dazu im nachfolgenden Abschnitt zu Collaboration).

• Weitere Funktionen wie Web Content Management (WCM), Enterprise Search und Enterprise Portal, Product Life Cycle Management (PDM) / Engineering Document Management (EDM) gehören ebenso zum ECM-Markt, haben aber mit den klassischen DMS-Lösungen keine Gemeinsamkeiten. Eher findet man hier Überschneidungen zu Collaboration-Lösungen, die auch echte Web-Redaktionsfunktionen Enterprise Search- und Portalfunktionen aufweisen. Daher haben wir diese fließenden Grenzen in der Abbildung visualisiert.

• Ein sehr fragmentierter und heterogener Teilmarkt ist der gesamte Bereich Output Manage-ment, der durch die zunehmende Digitalisierung der Output-Strecken bis hin zum Empfänger in den letzten Jahren erheblich an Bedeutung und an Sichtbarkeit gewonnen hat.

• Bezogen auf die o.a. Abbildung fokussiert die vorliegende DMS-Marktübersicht 2013 auf den DMS-Begriff im weiteren Sinne inkl. wichtiger Collaboration-Funktionen.

Einleitung



III.1.1 Unterschiede im deutschen und englischen Sprachgebrauch

Im ECM-Whitepaper des BITKOM1 findet sich ein anschaulicher Vergleich zwischen deutschem und englischem Sprachgebrauch. Besonders häufige Ursache für Missverständnisse: Der englische Begriff „Document Management“ ist inhaltlich nicht mit dem deutschen „Dokumenten Manage-ment“ gleichzusetzen.

Abbildung 2: Unterschiede im deutschen und englischen Sprachgebrauch, Quelle: BITKOM ECM-Whitepaper, Februar 2012

III.2 Warum Anwender in DMS-Lösungen investieren

Nicht nur die Probleme mit Papier, sondern auch das wachsende Chaos der elektronischen Ablagen auf den Netzlaufwerken und E-Mail-Systemen und die verlorengegangene Auskunftsfähigkeit (Stichwort: unvollständige Akte) machen das Arbeiten mit Dokumenten – egal ob in analoger oder digitaler Form – zunehmend zum teuren Missstand, unabhängig von Größe und Branche des Unter-nehmens.

In einem Umfeld wachsender Sensibilisierung für mangelnde Ordnungsmäßigkeit, nicht vorhan-dener Dokumentations- und Auskunftsfähigkeit und der Einsicht, dass die konventionellen Ablagen auf Datei- und E-Mail-Systemen in die Sackgasse führen, werden die Vorteile moderner DMS- und ECM-Lösungen immer offensichtlicher.

Das papierlose Büro wurde zwar bis heute nicht erreicht, papierarme oder sogar papierlose Prozesse, elektronische Ablagen und Archive sind dagegen mittlerweile tausendfach erfolgreich in Betrieb. Elektronische Archivierung, Dokumenten Management und die Automation Dokumenten-basierter Prozesse stehen weit oben auf der Prioritätenliste vieler Unternehmen und Organisati-onen, unabhängig von Unternehmensgröße und Branchenzugehörigkeit.

1. Quelle: BITKOM ECM Whitepaper, Februar 2012. Download auf www.bitkom.org/ecm. Zöller & Partner Berater gehörten zum Autorenteam



Einleitung

Die wachsenden Probleme der Anwender mit analogen und digitalen Dokumenten sorgen seit Jahren für Wachstum im DMS-/ECM-Markt. Anwender haben eigentlich auch keine andere Hand-lungsoption als die Einführung einer DMS-Lösung, wenn sie Dokumenten-basierte Prozesse effizi-enter gestalten und gleichzeitig regelkonform Ordnung halten wollen in der Flut der analogen und digitalen Unterlagen, die sich heute häufig auf einer unkontrollierbaren Vielzahl von Systemen und Ablagen verteilt: auf den lokalen Ablagen der PCs, auf den File-Servern, den E-Mail-Systemen, den Ablagen der führenden Anwendungen und vielen weiteren Repositories (Aufbewahrungssystemen). Die „vollständige Akte“, also die einfache und belastbare Auskunftsfähigkeit und Ordnungsmäßig-keit ist schon lange verloren gegangen. Das gilt für archivierte Belege ebenso wie für lebende Doku-mente und für Unternehmen und Organisationen in allen Branchen und unabhängig von der Unter-nehmensgröße.

Häufige Triebfedern sind der wachsende Druck, Aufbewahrungspflichten und Dokumentations-pflichten für unterschiedlichste Dokumente und Abläufe – analoge oder elektronische – zu erfüllen sowie die betriebswirtschaftliche Notwendigkeit, Kosten in Dokumenten-basierten Prozessen zu reduzieren. Dokumenten Management Systeme bieten sich als ideale Basis für eine geordnete und revisionsfähige Verwaltung unterschiedlicher Dokument-Informationen an und helfen, der nach wie vor beträchtlichen Papierflut im Posteingang Herr zu werden. Gleichzeitig bieten sie das Potenzial, Arbeitsabläufe zu beschleunigen und in vorhandene IT-Anwendungen zu integrieren, wodurch sich erhebliche Nutzenpotenziale ausschöpfen lassen.

III.3 Verwirrende Begriffs- und Angebotsvielfalt

Der Markt erschlägt die Anwender mit Abkürzungen und Schlagworten (ECM, DMS, „Revisionssi-cherheit“, „Archiv“ „Workflow“, „Records Management“) und schafft hierdurch statt Transparenz eher bremsende Verwirrung, weil natürlich jeder Anbieter (und Berater) seine eigenen Definitionen verwenden möchte.

Bereits unter dem vermeintlich eindeutigen Begriff „Archivierung“ verstehen DMS-/ECM-Anbieter, Datenbank-Administratoren, Speicherhersteller, Landesarchivare und Wirtschaftsprüfer sehr unterschiedliche Dinge. Auch ist das Verständnis zu häufig verwendeten Begriffen wie „Doku-menten Management“ (oder „Enterprise Content Management“) sehr unterschiedlich. „Die Spanne reicht von der einfachen MS Office-Dateiverwaltung auf dem Server mit Volltextsuche bis hin zur Prozessunterstützung in Content-zentrischen Prozessen, die in eine heterogene Anwendungsland-schaft unter Einhaltung regulatorischer Anforderungen integriert werden können“2, wie es im BITKOM ECM-Whitepaper von 2012 dargestellt wird. Entsprechend vielfältig sind auch die verschie-denen Angebote der Hersteller.

Für den Neueinsteiger ebenfalls verwirrend ist die Unübersichtlichkeit der Angebote. Die angebo-tenen ECM-Systeme in den unterschiedlichen Produktkategorien – wie Archivierung, Dokumenten Management, Records Management, Collaboration etc. – verfügen zwar alle über „Dokumenten-verwaltende“ Funktionen im weiteren Sinne, sind aber häufig schwer miteinander vergleichbar, weil sie unterschiedliche Einsatzfelder adressieren.

Die vorliegende Marktübersicht erläutert daher in den einleitenden Kapiteln wesentliche Begriffe und berücksichtigt dabei den Marktkonsens. Die nachfolgenden Angaben der Anbieter in einem gleichartigen Raster sollen zur besseren Vergleichbarkeit der Produktangebote führen, unabhängig davon, welche Marketingetiketten der Anbieter seinen Produkten anheftet.

2. Quelle: BITKOM ECM-Whitepaper, Februar 2012.

Einleitung



III.4 „Ich dachte, das ist Standard“

Die Erfahrungen der Anwender von DMS-Lösungen sind überwiegend positiv. Die am häufigsten genannten produktabhängigen Probleme (es gibt natürlich ebenso häufig auch personelle oder organisatorische Ursachen für Erfolg oder Misserfolg) sind auf eine falsche Systemwahl zurückzu-führen – typische Auswirkungen sind dann mangelnde Skalierbarkeit, unterschätzter Aufwand bei Installation, Anpassung und Betrieb, unvorhergesehener Individualentwicklungsaufwand wegen übersehener funktionaler Anforderungen, mangelnde Performanz vor allem Browser-basierter Client-Umgebungen u.a. Trotzdem: Kein uns bekannter Anwender will wieder zurück zu Papier, Mikrofilm und manuellen Abläufen. Die Vorteile der DMS-Lösungen sind einleuchtend und dauer-haft, auch wenn sie in manchen Projekten erst nach einer Lernkurve und mit erhöhtem Aufwand zur Verfügung stehen.

Für den Anwender, der sich neu mit der Thematik beschäftigt, kann es aber sehr schwer sein, die verschiedenen Lösungen zu bewerten und deren Eignung zur Abdeckung der eigenen Anforde-rungen einzuschätzen. Daher werden die für ein erfolgreiches Projekt wichtigen Detailunter-schiede, vor allem in der Funktionalität und Benutzerfreundlichkeit, aber auch bei Verwaltungs-funktionen, Architektur und Skalierbarkeit und den Werkzeugen zur Anpassung an die individuellen Anforderungen erst sehr spät im Projektverlauf sichtbar, im schlimmsten Fall erst nach Vertragsab-schluss. Typisch ist eine komplett falsche Einschätzung der Dienstleistungsaufwendungen: Unter der Annahme, dass bestimmte Funktionen feststehende Bedeutungen haben („Akte“, „Arbeits-korb“, „Workflow“) und im Standard-Umfang aller Produkte bereits enthalten sind, werden die zum Erstellen der Lösungen notwendigen Dienstleistungen für Customizing und Anwendungsintegration nicht ausreichend ermittelt. Die Folge sind ungeplante und nicht selten erhebliche Zusatzkosten.

Die Marktübersicht soll zu den Produkten am Markt eine erste Einschätzung erlauben, was eine moderne DMS-Lösung an Funktionalität im Standard mitbringt, an welchen Stellen Partnerlö-sungen zu beschaffen oder Anpassungen zu erwarten sind.

Die vorliegende Marktübersicht fragt DMS-Funktionen ab, die nach unserer Einschätzung nicht exotisch sind, sondern die wir als typische Anforderungen in vielen Projekten kennengelernt haben. An einige DMS-Funktionen hat der Leser vielleicht noch gar nicht gedacht. Der Anwender sollte aber nur diejenigen Funktionen vom Anbieter einfordern, die er auch mittelfristig benötigt: Die berühmte eierlegende Wollmichsau kann kein Anbieter liefern. Der Anwender sollte sich bei Fachkonzeption und Systemauswahl auf diejenigen Anforderungen konzentrieren, die für ihn auch in absehbarer Zeit relevant sind. Erfreulicher Fakt ist aber auch, dass sehr viele Systeme am Markt mittlerweile bereits im Standard über eine Fülle an Funktionen verfügen und darüber hinaus Customizing Werk-zeuge mitbringen, die diese Funktionen an die spezifischen Anforderungen, auch kleinerer und mittlerer Anwender und innerhalb deren Budgets, anpassen lassen. Wer also Funktionsabfragen in der Marktübersicht findet, die konkret eigene Probleme lösen würden, der darf beruhigt davon ausgehen, dass es eine Reihe von Angeboten am Markt gibt, die diese Funktionen zur Verfügung stellen.

III.5 Boom im Mittelstand: von den Großen vernachlässigt

Eine Reihe mittelständischer Hersteller adressiert mit ihren Komplettlösungen, inkl. Aktenfunkti-onen, E-Mail- und MS Office-Archivierung bis hin zu integrierten Postkorb/Workflow-Komponenten erfolgreich den Markt für kleine und mittelständische Unternehmen (KMU). Für viele kleinere und mittelständische Anwender sind die Lösungen erst in den vergangenen Jahren bezahlbar geworden; umso größer ist dort der Nachholbedarf. Dieser Trend wird sich fortsetzen, weil Anwender zunehmend mit digitalen und digitalisierten Dokumenten arbeiten, um sie in den neuen standortübergreifenden elektronischen Prozessen einbinden zu können.

Dieses boomende Marktsegment wurde von den großen, internationalen Anbietern bis heute weder preislich noch architektonisch adressiert, was einer der Hauptgründe für die immer noch vorhan-dene Vielfalt an Angeboten auf dem Markt ist.



Einleitung

III.6 Vorbemerkungen zur DMS Marktübersicht 2013

Die DMS-Marktübersicht 2013 dient der schnellen Orientierung in einem Markt mit sehr vielen unterschiedlichen Angeboten. Typischerweise werden in Auswahlprojekten aufgrund architektoni-scher, funktionaler und wirtschaftlicher Rahmenbedingungen nur eine Untermenge der Hersteller betrachtet. Die Marktübersicht erleichtert eine Vorauswahl, sodass dann mit dem gesparten Aufwand die verbleibenden Anbieter und deren Systeme umso detaillierter unter die Lupe genommen werden können. Die Marktübersicht ist kein Ersatz für eine solche detaillierte Betrach-tung, aber eine gute Gliederung für die weitere, detaillierte Betrachtung, die der Anwender ergänzen und abschnittweise gewichten muss. Wer zum Beispiel kein SAP-System hat oder haben wird, für den ist der Abschnitt SAP-Integration irrelevant.

Was der Anwender ebenfalls nicht einer Marktübersicht überlassen darf, ist die Bewertung ergono-mischer Aspekte, wie beispielsweise:

• Ist die Oberfläche für alle Zielgruppen (Sachbearbeiter, Knowledge-Worker, Systemverwalter, Scan-Personal) akzeptabel?

• Wie viele Mausklicks und sonstige Eingaben sind notwendig, um eine Mail mit drei Attach-ments in einer Akte abzulegen?

• Ist die Aktensicht ein zumutbarer Ersatz für die bisherige Ablage im File- und E-Mail-System?

• Ist die beworbene Drag & Drop-Funktionalität ein Segen (weil einfach) oder Fluch, weil komplette File-Strukturen vom Grobmotoriker falsch „gedroppt“ wurden, jetzt aber auch noch unveränderbar?

• Wie werden 50 Schadensfotos einer Akte zugefügt? 50 Mal Einzelindexierung oder alle „in einem Rutsch“?

Die Liste dieser Detailanforderungen ist beliebig erweiterbar und kann praktisch nur im konkreten Projekt bestimmt, abgefragt und bewertet werden.

Im Folgenden listen wir beispielhafte Themen, die in ihrer notwendigen Detaillierung über die vorlie-gende Marktübersicht hinausgehen:

Aufsetzen, Einrichtung des Gesamtsystems, vor allem im Hinblick auf den späteren Ausbau. Wenn das „Fundament“ falsch geplant wurde, sind häufig später bei Skalierung auf weitere Abteilungen und deren Prozesse aufwändige Umbauarbeiten notwendig.

Implementierung der Ordnungsstrukturen für Dokumente und Akten. Dazu gehören typischerweise auch Einrichtung von Dokumentklassen, Teilbereichen, Zugriffsrechten, etc.

• Aufsetzen der Dokumentprozesse (Workflows) für Scan-Szenarien, Redaktions-Workflows, Freigabe-Genehmigungsworkflows und alle anderen Prozessautomatismen

• Mandantenfähigkeit: Abgrenzung der Daten- und Dokumentbestände, mandantenspezifische Verwaltungsberechtigungen und Abrechnungswerkzeuge

• Mehrsprachigkeit: welche Sprachen für GUI und Attribute, Dokumentation, Training etc. Gleichzeitige Mehrsprachigkeit, Umschaltbarkeit, Local Support?

• Betriebssicherheit/Hochverfügbarkeit: welche Komponenten können mit welchen Konzepten hochverfügbar gestaltet werden?

• Backup/Recovery: Wie werden Daten und Dokumente gesichert? Welche Werkzeuge müssen/dürfen genutzt werden?

• Systemverwaltungswerkzeuge, Benutzerverwaltung, Zugriffsrechteverwaltung, Protokollie-rung der Transaktionen, Statistiken und Auswertungen, Fehlerhandling

• Entwicklungswerkzeuge zur Anpassung des DMS, Entwicklung und Pflege eigener Anwen-dungen und Integrationsverfahren

• Support: Support-Zeiten, Verfügbarkeit in der Region, Anzahl Mitarbeiter, Support-Konzept, Einbindung bei Drittkomponenten, Eskalationsprozeduren in Prio-1-Fällen etc.

• Schulung/Training: welche Sprache, an welchen Orten, für welche Benutzergruppen?

• Anwendervereinigung: in welchem Land, welche Mitglieder, welche Aktivitäten?

Einleitung



• Dem Projekt zugeordnete Mitarbeiter: Projekt- und Produkterfahrungen

• Export- und Importwerkzeuge für Individual- und Massenprozesse

III.7 Allgemeines zu den Anbietern

Teilnehmen konnten alle Hersteller/Anbieter, die ein Dokumenten Management System im Sinne der Marktübersicht herstellen und im deutschsprachigen Markt anbieten. Die Hersteller konnten auch Partner zur Teilnahme benennen, wenn sie keine eigene Repräsentanz in Deutschland, Öster-reich oder der Schweiz haben.

Nicht aufgenommen wurden Produkte, die auf einem DMS eines anderen Herstellers aufsetzen, aber am Markt als eigenständiges Produkt vermarktet werden oder die sogar „nur“ Ergänzungs-komponenten darstellen. Beides hätte zur Folge, dass mehrere Hundert Systemlösungen aufge-nommen werden müssten, weil viele Partner der DMS-Hersteller solche Ergänzungslösungen anbieten. Es stand den teilnehmenden DMS-Herstellern aber frei, solche ergänzenden Partnerlö-sungen in ihrem eigenen Katalog aufzunehmen. Dort finden sich in allen relevanten Frageab-schnitten Fragen zu Herkunft der Komponenten, sodass der Leser relativ einfach feststellen kann, ob es sich um eine Eigenentwicklung oder ein Drittprodukt handelt.

Die Teilnahme für die Anbieter war kostenlos und nicht abhängig von einer Mitgliedschaft im BITKOM.

III.8 Aufbau der Marktübersicht

Die Marktübersicht ist grob betrachtet in zwei ungleich große Bereiche aufgeteilt: Der Erläuterung der Übersicht und der Übersicht selbst.

Innerhalb der eigentlichen Übersicht (2. Teil) hat jeder teilnehmende Anbieter seine Angaben zu Fragestellungen gemacht, die für jeden Anbieter identisch formuliert wurden. Die Antworten der Teilnehmer können für einen ersten Vergleich somit quasi nebeneinander gestellt und verglichen werden. Dabei wurden die Fragestellungen in zwei Kapitel (1. Anbieter, 2. Produkt) aufgeteilt und innerhalb dieser Kapitel wurden Abschnitte für fachlich oder technisch zusammengehörende Bereiche, wie z.B. im Produktbereich bezüglich der SAP-Archivierung, gebildet.

Für jeden Hauptabschnitt des Fragenkataloges findet sich überdies nachfolgend Erläuterungska-pitel. In diesen werden die speziellen Herausforderungen der mit den Abschnitten einhergehenden Funktionsanforderungen hervorgehoben und erläutert, welche Fragestellungen und Antworten für welche fachlichen oder technischen Umfelder von Bedeutung sind.

Wir haben uns bemüht, die Fragestellungen möglichst selbst erklärend zu formulieren, um vergleichbare Antworten zu erhalten. Dort wo wir Missverständnisse befürchten mussten, haben wir Einzelfragen direkt im Fragenkatalog für den Anbieter erläutert. Diese Erläuterungen zu Einzel-fragen finden sich im nachfolgenden Kapitel „Erläuterungen zu den Fragen in den einzelnen Abschnitten“.

Auf eine Bewertung der gemachten Angaben oder gar der einzelnen Produkte wurde gänzlich verzichtet, da diese nach unserer Erfahrung immer nur vor dem Hintergrund einer konkreten Projektsituation erfolgen kann und weitere Aspekte wie zum Beispiel Preise und Referenzen berücksichtigen muss.

III.9 Erläuterungen zu den Angaben

Die Informationen zu Herstellern und Produkten wurden im Zeitraum Juni bis August 2012 von den befragten Anbietern in einer Web-Anwendung erfasst. Zöller & Partner hat die Angaben nach bestem Wissen verifiziert und bei Bedarf in Absprache mit den Anbietern angepasst, auch um eine Vergleichbarkeit durch eine gleichartige Bearbeitungsweise herzustellen. So haben wir eine Produktfunktionalität als gegeben eingestuft, wenn diese im Standard des Lösungsangebotes geliefert werden kann und nicht erst im Projekt als Individuallösung entsteht oder in einem konkreten Projekt entwickelt wurde. Es war jedoch nicht zwingend notwendig, dass diese Produkt-funktion vom Hersteller selbst entwickelt wurde. Auch wenn Fremdkomponenten (z. B. für die Formatkonvertierung, die Volltextdatenbank, den Multiformat-Viewer etc.) in das Lösungsangebot als Standardfunktion eingebettet wurden, haben wir dies als Standardfunktion der Lösung aner-kannt. Wir haben jedoch generell um die Angabe der Zulieferer solcher Komponenten gebeten.



Einleitung

Es war den Anbietern freigestellt, Angaben zu Mitarbeiterzahlen und Umsätzen zu machen. Solche Angaben sind aber aus verschiedenen Gründen nicht einfach vergleichbar. Das liegt einerseits daran, dass zahlreiche Anbieter nicht nur im DMS-/ECM-Markt, sondern auch in anderen IT-Segmenten anbieten und eine Trennung der Umsätze nach Herkunft häufig schwierig, wahrschein-lich sogar unmöglich ist (zu welchen Anteilen werden Server und Speicher dem DMS-Bereich zuge-ordnet?). Ein weiteres Problem sind die unterschiedlichen Vertriebsmodelle: einige Anbieter vertreiben direkt, andere über ein Partnernetzwerk oder eine Mischung aus beidem. Wer über ein umfangreiches Partnernetzwerk verfügt, erzeugt mit den Partnern an der Schnittstelle zu Kunden ggf. einen höheren Umsatz wie ein Anbieter, der „nur“ direkt vertreibt, aber die gleiche Anzahl Lösungen implementiert hat. Welche Zahl soll gelten? Der selbst erzielte Umsatz oder der Umsatz am Markt?

Außerdem haben einige Anbieter Minderheit- oder Mehrheitsbeteiligungen an ihren Vertriebspart-nern. Durch solche Aspekte taugen die veröffentlichten Umsatzzahlen (falls sie überhaupt veröf-fentlicht wurden) als Bewertungskriterium zur Unternehmenseignung nur sehr eingeschränkt, falls überhaupt. Mehr als eine ungefähre Vorstellung von der „Größenordnung“ wird man aus den veröf-fentlichten Zahlen nicht ableiten können. Ein Bewertung der Eignung der DMS-Plattform für die eigenen, nicht selten individuellen Anforderungen, regionale Supportverfügbarkeit, personelle Ressourcen zu spezifischen Integrationsanforderungen etc. (um nur einige wenige Beispiele zu nennen) sind u. E. wesentlich wichtiger bei der Eignungsbewertung als reine Umsatzzahlen, die sich aus den o.a. Gründen nicht vergleichen lassen.

Bewusst wurde davon Abstand genommen, Preisangaben in die Übersicht aufzunehmen. Um die Kosten einer DMS-Lösung unterschiedlicher Hersteller vergleichen zu können ist eine besonders genaue Spezifikation der funktionalen Anforderungen notwendig, die über das in der Übersicht enthaltene Maß deutlich hinausgeht. Vor allem die Dienstleistungskosten sind zu berücksichtigen, die häufig einen erheblichen Gesamtkostenanteil ausmachen und in besonderem Maße von den Detailanforderungen abhängig sind.

Erläuterungen zu den Abschnitten



IV Erläuterungen zu den Abschnitten

IV.1 DMS-Server-Plattform

In diesem Abschnitt geht es darum zu verstehen, welche technischen Plattformvoraussetzungen (Server-Plattform und Datenbank) auf der Anwenderseite zu erfüllen sind, um die Lösung betreiben zu können.

Einige der in diesem Abschnitt formulierten Fragestellungen wiederholen sich in denjenigen Kapi-teln, in denen Zusatzkomponenten beschrieben werden, welche häufig auf eigenständigen Server-systemen installiert werden (z.B. E-Mail-Archivlösung, SAP-Integration etc.). Die in dem Abschnitt „DMS-Server-Plattformen“ gemachten Angaben gelten zunächst systemweit. Bei nachfolgenden Abschnitten kann der Anbieter auf diese Plattform referenzieren (zum Beispiel, wenn für die Akten-verwaltung die bereits beschriebene DMS-Server-Plattform zum Einsatz kommt) oder ergänzende Plattformvoraussetzungen angeben, welche für die Fragen im Abschnitt ergänzend notwendig sind.

Zu „typischen“ Systemfragen, die sich abschnittweise (bzw. komponentenweise) wiederholen, gehört die Frage nach der Bezeichnung der Komponente, typischerweise dem Produktnamen. Da Komponenten häufig als Fremdprodukt (OEM) integriert werden, wird im Rahmen der Marktüber-sicht auch der (abweichende) Hersteller abgefragt.

Die Frage nach dem Datum der Produktbereitstellung dient einer ersten Einschätzung darüber, wie ausgereift das angebotene Produkt ist, da eine hohe Versionsnummer nicht zwangsläufig erkennen lässt, wie lange das Produkt bereits vermarktet wird. Als weiterer Indikator für den Reifegrad dient die Abfrage der Kundenanzahl. Durch die Beschränkung auf den deutschsprachigen Raum (Deutschland, Österreich, Schweiz) ist hier, insbesondere für Produkte aus dem angelsächsischen Gebiet, kein unmittelbarer Rückschluss auf den gesamten Markterfolg möglich. In der Marktüber-sicht wird dennoch bewusst dieses geografische Gebiet abgefragt, um zusätzlich eine grobe Einschätzung über die für dieses Gebiet zuständige Supportinfrastruktur vornehmen zu können.

Für den Betrieb im Rechenzentrum ist es wichtig zu verstehen, welche Plattformkombinationen aus System- und Datenbankbetrieb möglich sind. Die im konkreten Projektfall benötigte Systemumge-bung lässt sich aus dieser Darstellung jedoch noch nicht ausreichend detailliert ableiten und muss im Rahmen der tatsächlichen Produktauswahl ermittelt werden.

Im Falle der Systembereitstellung unter Linux sind die Anbieter aufgrund der Vielzahl der Linux-Distributionen aufgefordert, diejenigen Distributionen namentlich aufzuführen, für die das Produkt / die Komponente vom Hersteller freigegeben ist.

In „Andere Plattformen und Datenbanken“ können Anbieter weitere Informationen zu den Platt-formen geben, die sich aus den konkreten Fragestellungen nicht unmittelbar ableiten lassen.

IV.2 Digitalisieren und Indexieren von Papierdokumenten (Capture-/Scan-Komponenten)

Nach wie vor ist Papier in der heutigen Zeit mit einer der wichtigsten Informationsträger. Umso verwunderlicher ist die immer wieder in den Projekten gemachte Erfahrung, dass Scannen und Erfassen von Papierdokumenten einer der am häufigsten unterschätzten Projektschritte in DMS-Projekten ist. Diese Erfahrung bezieht sich leider nicht nur auf das sogenannte Scannen und Inde-xieren von Dokumenten, sondern oft auf den gesamten Erfassungsprozess, also von der Vorberei-tung der Papierdokumente für das Scannen bis hin zu einer möglichen Einlagerung (z.B. für Doku-mente mit einem hohen rechtlichen Stellenwert) oder sogar Vernichtung von Papieroriginalen. Der Papiererfassungsprozess wird übrigens häufig auch als „Capture“-Prozess bezeichnet.

Im Gegensatz zu den nutzbringenden Effekten eines Dokumenten Management Systems, wie die schnelle Dokumentenrecherche und -anzeige, entsteht bei der Wandlung des Papiers in digitale Dokumente (auch Images genannt) erfahrungsgemäß zusätzlicher Aufwand: Das Papier muss vorbereitet, also entklammert, geglättet, sortiert, dann auf den Scanner gelegt und digitalisiert werden. Anschließend wird das digitalisierte Abbild noch auf Lesbarkeit hin geprüft und indexiert, also mit Suchkriterien versehen. Letztendlich erfolgt erst dann die Speicherung des digitalen Doku-ments in ein DMS. Nicht zu vergessen ist, dass genau dieser Capture-Prozess die Grundlage einer digitalen Weiterverarbeitung von Informationen, z.B. innerhalb einer Postkorb-/Workflow-Anwen-dung, und daher ein sehr wichtiger und nicht zu unterschätzender Prozessschritt ist.




Je nachdem, wie die eigentlichen Geschäftsprozesse organisiert sind, kann ein Digitalisieren von Papier am Arbeitsplatz oder das Scannen von Papier in einer zentralen Organisationseinheit sinn-voll sein. In der Praxis ist häufig eine Mischform dieser beiden Papiererfassungsorganisationen anzutreffen. An einem Beispiel aus der Praxis wird dieses etwas anschaulicher.

Beispiel Kfz-Anmeldung: Hier werden mittlerweile in vielen Fällen die notwendigen Unterlagen eingescannt und elektronisch in einer DMS-Lösung archiviert. Unterlagen des Kunden müssen in diesem Prozess dem Kunden direkt nach der Sachbearbeitung zurückgegeben werden (z.B. der Personalausweis). Diese Art des Scannens wird „Scannen am Arbeitsplatz“ oder auch „Ad-hoc-Scannen“ genannt. Der o.g. Prozess macht die Rückgabe von Kundendokumenten erforderlich, daher kann hier eine zentrale Scan-Stelle nicht sinnvoll sein.

Das Ad-hoc-Scannen macht allerdings dann keinen Sinn, wenn z.B. ein hochvolumiger, täglicher Posteingang von den Mitarbeitern einer Firma, einer Behörde usw. selbst am Arbeitsplatz einscannt würde. Die Prozesskosten hierfür sind erfahrungsgemäß einfach zu hoch und es kann nicht die Aufgabe eines Fachspezialisten sein, Dokumente einzuscannen. Hier ist es sinnvoll, den Postein-gang zu bündeln und in einer zentralen Organisationseinheit einen Erfassungsprozess zu imple-mentieren, der eine effektive und qualitativ hochwertige Digitalisierung des hochvolumigen Papier-posteingangs und der Zuordnung zu den jeweiligen Geschäftsvorgängen im DMS ermöglicht.

Die beiden o.g. Beispiele machen deutlich, dass – abhängig von den organisatorischen Dokumen-tenerfassungsprozessen – unterschiedliche Erfassungstechnologien zum Einsatz kommen können. Diese sind zum einen relevant für das Arbeitsplatzscannen, also die sogenannten „Capture-/Scan-Funktionen im Anwender-Client“ und zum anderen für das Digitalisierungsmassen-geschäft, die sogenannten „Eigenständigen Capture-/Scan-Komponenten“.

Prinzipiell haben die oben angesprochenen organisatorischen Dokumentenerfassungsprozesse erhebliche Auswirkungen auf die Auswahl geeigneter Scan-Hardware und auch Scan- und Index-Software. Schon die Art und Weise, wie Papierdokumente für das Scannen vorbereitet werden, wirkt sich auf die eingesetzte Scan-Infrastruktur aus, denn Dokumente können beispielsweise auf der Vorder- und/oder Rückseite bedruckt, geheftet oder geöst sein, oder auch als Leporello Formular vorliegen. Diese Art von Papierdokumenten bekommt man i. d. Regel nicht ohne weiteres gescannt. Beim Auseinanderreißen von Dokumenten in Einzelseiten muss z. B. die logische Doku-mentenklammer erhalten bleiben, was häufig durch Separieren anhand von Barcode-/Patchcode-Blättern oder einer fest eingestellten Seitenzahl beim Scannen erfolgt. Spezielle Scanner vertragen während des Scannens auch einmal eine vergessene Büroklammer. Wird hier an hochwertigen „Werkzeugen“ gespart, dann macht sich dies dauerhaft an den Wartungs- und Personalkosten einer Erfassungslösung bemerkbar. Der Einsatz hochwertiger Scanner, sowohl für das Arbeitsplatz-scannen als auch für das Massenscannen, und einer optimalen Scan-Software ist somit notwendig und begründet. Auf den ersten Blick schrecken natürlich die Kosten für hochwertige Scanner ab, aber diese Kosten haben sich sehr schnell wieder amortisiert. Der Grund liegt hier in den Prozess-kosten. Langfristig sind die Kosten für ein nicht performantes Einscannen von Papierbelegen, das Umkopieren von kleinen Formaten auf große Formate (oder umgekehrt), ein wiederholtes Scannen aufgrund eines Doppeleinzugs oder Qualitätsmangels und ein häufig beschädigter Scanner wegen vergessener Büro- oder Tackerklammern höher, als die Anschaffungskosten guter Scanner.

An dieser Stelle muss angemerkt werden, dass in der vorliegenden Marktübersicht nur eine Teil-komponente einer gesamtheitlichen Dokumentenerfassung betrachtet wird: Die Scan- und Index-Software. Die Ausführungen zuvor haben aber verdeutlicht, dass für einen wirtschaftlichen Erfas-sungsprozess erheblich mehr organisatorische und auch technische Rahmenbedingungen berück-sichtigt werden müssen als in dieser Marktübersicht abgefragt werden. Ebenso werden in zwei getrennten Abschnitten die Capture-/Scan-Funktionalitäten zum einen für das Arbeitsplatzscannen (also die Scan-Anwendung innerhalb einer DMS-Client-Anwendung) und zum anderen für das Massen-Scannen mit einer speziellen Capture-/Scan-Anwendung abgefragt:

• „Capture-/Scan-Funktionen im Anwender-Client“

• „Eigenständige Capture-/Scan-Komponenten“

Bei der „Capture-/Scan-Funktion im Anwender-Client“ wird zusätzlich noch zwischen den Funkti-onen in einem Windows-Client und einem Web-Client unterschieden.

Da sich die Fragestellungen für beide Arten von Scan-Anwendungen in der DMS-Marktübersicht sehr ähneln, werden diese nachfolgend zusammengefasst erklärt.




Nun aber zu den Inhalten der Marktübersicht:

Grundsätzlich sollte der DMS-Anbieter angeben, welche Komponenten er für die Capture-/Scan-Funktionen im Anwender-Client und für die eigenständigen Capture-/Scan-Komponenten im Produktportfolio führt. Im Hinblick auf die eigenständigen Capture-/Scan-Komponenten gibt es aktuell DMS-Anbieter, die die hier abgefragte Scan-Software innerhalb ihres DMS-Portfolios selbst entwickelt haben und andere, die auf komplette Scan-Lösungen bzw. einzelne Scan-Komponenten von Drittanbietern zurückgreifen. Die Produkte spezialisierter Scan-Software-Hersteller werden auch häufig über bereits vorhandene Scan-Schnittstellen oder anhand eigener Projektlösungen oder als OEM-Produkte in die jeweiligen DMS-Umgebungen integriert. Aufgrund der vielfältigen Lösungsangebote sollte der DMS-Anbieter angeben, ob die hier beschriebene Scan-Komponente (im Nachfolgenden auch Capture-Anwendung genannt) ein herstellereigenes Produkt oder eine Fremdlösung ist. Als herstellereigenes Produkt gelten solche Lösungen, die im Kern vom Anbieter selbst stammen, also auch dann, wenn weitere Komponenten, wie z.B. Bildaufbereitungs-, Bildver-besserungs- oder Konvertierfunktionen als OEM-Komponenten fremder Hersteller standardmäßig in die Lösung integriert wurden. Erfahrungsgemäß kann die Einbindung von spezieller Kofax-Hard-ware und auch -Software notwendig sein, um bestimmte Scanner an einen Scan-PC anzubinden, oder um Spezialfunktionen, wie beispielsweise Barcodeerkennung und Bildverbesserungen, zu ermöglichen.

Die Marktverbreitung und auch die kontinuierliche Pflege der angegebenen Scan-Produkte werden über das Erscheinungsdatum des Softwareproduktes (seit wann auf dem Markt verfügbar), die Anzahl der Kunden und die Angabe des aktuellen Software Releases verdeutlicht.

Im Bereich der Dokumentenerfassung lassen sich heute zwei Philosophien voneinander unter-scheiden: Das Ad-hoc-Scannen und das Stapelscannen. Mit Ad-hoc-Scannen ist ein direktes Scannen von Einzelblättern gemeint, ohne gleich Scan-Profile zu erstellen oder einen Scan-Stapel zu bilden. Das Einscannen eines ganzen Dokumentstapels wird als Batch- oder auch Stapel-Scan-ning bezeichnet. Stapelscannen bedeutet, dass ein Dokumentstapel vollständig eingezogen, gescannt und mit ggf. einheitlichen Indexmerkmalen versehen wird.

Insbesondere beim Batch- oder Stapelscannen ist es erforderlich, den gesamten Papierstapel wieder in Einzeldokumente aufzutrennen. Die notwendige Dokumententrennung des Stapels wieder zurück in Einzeldokumente findet typischerweise über Barcode- oder auch Patchcode-Trennblätter statt, wobei wir damit die nächste Anforderung an eine stapelbasierte Dokumentener-fassung ansprechen: Welche Barcodes bzw. Patchcodes werden von der Capture-Lösung grund-sätzlich erkannt und können inhaltlich interpretiert werden. Die wohl verbreitetsten eindimensio-nalen Barcodes sind Codabar, Code-128, Code-39, 2/5 Interleaved und im zweidimensionalen Bereich die Codes PDF 417 und Data Matrix.

Eine gute Scanqualität ist unter anderem zur Erkennung der o. g. Barcodes sehr wichtig. Es ist schon verwunderlich, welche Scan-Qualitätsunterschiede es heute noch in den Capture-Produkten gibt, obwohl es sowohl hardware- als auch softwaretechnisch möglich ist, die Bildqualität mit Hilfs-mitteln einer Capture-Anwendung zu verbessern. Automatisches leserichtiges Ausrichten gescannter Dokumente („Auto rotate“), das Entfernen schwarzer bzw. weißer Ränder, das Ausfiltern von Schmutz („Noise“, „Despeckling“) und die automatische Erkennung leerer Rückseiten von Dokumenten über Schwellwert sind wohl die wichtigsten und am häufigsten genutzten Bildverbes-serungsmechanismen im Capture-Umfeld. Auf den ersten Blick scheinen die zuvor angespro-chenen Funktionen sehr nützlich zu sein, dennoch sollte ihr Einsatz mit Bedacht erfolgen. Es ist leicht möglich, über die Funktion „Despeckling“ alle Umlaute auf dem gescannten Bild zu elimi-nieren (alle Punkte/Pixel ab einer gewissen Größe werden ja herausgefiltert). Ebenso kann anhand eines falsch konfigurierten Schwellwerts über die „leere Rückseitenerkennung“ eine paraphierte Rückseite ungewollt entfernt werden.

In den nachfolgenden Fragestellungen wurde abgefragt, welche Dateiformate von den Scan-Lösungen unterstützt werden. Die wichtigsten Formate im DMS-Umfeld sind heute wohl PDF, PDF/a und auch noch TIFF. Im Zusammenhang mit dem Scannen von großformatigen, farbigen Doku-menten, wie z.B. Plänen und Konstruktionszeichnungen, sind hochkomprimierte Dateiformate inte-ressant. Diese beruhen auf Wavelet-Transformation und generieren sehr kleine Dateigrößen. Auch Angaben hierzu sind vom DMS-Anbieter möglich gewesen.




Im Hinblick auf die Bereitstellung gescannter Dokumente im PDF-Format wird abgefragt, welche verschiedenen PDF-Dateivarianten erstellt werden können. So können PDF-Dateien erzeugt werden, die reine Bildinformationen oder nur Textinformationen oder sogar beides enthalten. Die Textinformationen werden über OCR-Softwarekomponenten aus der generierten Bilddatei extra-hiert und entweder als Information mit dem ursprünglich gescannten Abbild in einer PDF-Datei zusammengefasst. Sind Textinformationen in der PDF-Datei enthalten, so können diese zur späteren Volltextrecherche innerhalb einer DMS-Lösung und in den Dokumenten selbst nutzbar gemacht werden – vorausgesetzt, die DMS-Lösung besitzt eine Volltextdatenbank. Sollte das nicht der Fall sein, ist die Volltextrecherche immer noch in jedem Standard-PDF-Viewer möglich, aber dann selbstverständlich nur noch in der gerade geladenen Datei.

Eine ganz wesentliche Komponente im Prozess der Dokumentenerfassung ist auch die Indexan-wendung. Es reicht nicht, die Papierdokumente nur zu scannen. Selbstverständlich müssen diese auch immer einem fachlichen Sachverhalt zugeordnet werden. Dies erfolgt über die „Indexierung“ anhand vorher definierter Dokumentattribute. Über diese Indexwerte können die in einem DMS gespeicherten Dokumente dann im Nachhinein recherchiert werden. Eine Standard-Indexierkom-ponente als integraler Bestandteil der Capture-Anwendung ist daher zwingend notwendig.

Nur der Vollständigkeit halber soll kurz auf die Scanner-Hardware eingegangen werden, denn diese spielt nach wie vor eine wesentliche Rolle im Zusammenspiel mit der abgefragten Scan-Software.

Erfahrungsgemäß kommen in DMS-Installationen Scan-Geräte aus unterschiedlichen Kategorien zum Einsatz:

Multifunktionsgeräte dienen als dezentral, durch den Endanwender nutzbare Digitalisierungsein-heiten, zumeist in Ergänzung zentral organisierter, professioneller Scanstellen. Häufig handelt es sich hier um Simplex-Scanner, das heißt, beim doppelseitigen Scannen muss das Papier zweimal eingezogen werden. Da die Multifunktionsgeräte meist über Funktionen verfügen, das Dokument in einem bestimmten Netzlaufwerk abzulegen oder dem Anwender per E-Mail zu senden, sind für diese Erfassungsszenarien keine spezifischen Capture-Komponenten erforderlich. Zur Optimierung dieses Erfassungsprozesses bieten jedoch einige DMS-Hersteller spezifische Produkterweite-rungen an, um Dokumenten-Metadaten über die Touch-Bildschirme der Multifunktionsgeräte erfassen zu können.

Einzelplatzscanner werden häufig in administrativen Bereichen wie Sekretariaten eingesetzt, um hin und wieder Dokumente in das DMS scannen zu können. Diese Geräte lassen sich häufig unmit-telbar über die DMS-Software nutzen, wobei die Geräte über einfache Treiber, vornehmlich TWAIN-Treiber, angesprochen werden. Wie oben beschrieben ist es für diese Anwendungsfälle sinnvoll, dass in der DMS-Anwendung eine Capture-/Scan-Funktion im Anwender-Client verfügbar ist. Die immer reichhaltigere mitgelieferte Software dieser Geräte insbesondere für die Volltexterkennung, kann beim Einsatz in DMS-Lösungen nur bedingt genutzt werden, da sie nicht unmittelbar über TWAIN angesprochen werden können.

Arbeitsgruppen- und Produktionsscanner sind auf Massenerfassungsprozesse ausgerichtet. Hier findet eine ständige Weiterentwicklung in den Bereichen des Papiereinzuges, der Geräterobustheit, der Wartungsfreundlichkeit, der Lampe (LED ist zwischenzeitlich etabliert, bietet gleichbleibende Lichtqualität bei Nutzbarkeit ohne Aufwärm-Wartezeit) und nicht zuletzt bei der Kamera, also bei der Abbildqualität statt. Diese Geräte sind heutzutage immer häufiger als Duplex-Scanner aufge-baut und bieten bereits in den kleineren Ausbaustufen sogenanntes „Multi“-Streaming, also das gleichzeitige Scannen in Schwarz/Weiß und Farbe. Die Einsatzmöglichkeit der häufig mitgelie-ferten, teilweise ziemlich leistungsfähigen gerätespezifischen Softwarekomponenten hängt vom gewählten DMS und Erfassungsszenario ab, in dessen Umfeld das Gerät zum Einsatz kommt. Nichts desto weniger ist für den sinnvollen und performanten Einsatz dieser Scanner eine eigen-ständige Capture- und Scan-Komponente das Mittel der Wahl. Insbesondere beim Einsatz von durchsatzstarken Scannern unterscheiden sich die Scan-Anwendungen hinsichtlich Performance und Skalierbarkeit spürbar.

Zusammenfassend können folgende typische Unterscheidungsmerkmale zwischen den heute am Markt verfügbaren Scannern festgestellt werden: Die Scan-Geschwindigkeit, die Technologie für Doppeleinzugserkennung sowie das Startverhalten beim Nachlegen während des Scannens und die Bedienung. Variieren kann auch die Robustheit der Geräte, die Geräuschentwicklung und die Wartbarkeit. Die Aufrüstbarkeit, Anforderungen an Scanner-PC und Hardware-Schnittstellen fallen ebenfalls unterschiedlich aus.




IV.3 Capture OCR, Klassifikation, Index-, Datenextraktion

Eine manuelle Indizierung von Dokumenten in einem DMS ist als Funktion immer vorhanden. Mit dem Ziel der Aufwandsminimierung bei der Erfassung werden oft zusätzliche Module angeboten, die eine automatische Erkennung, Indizierung und ggf. eine systemunterstützte Zuordnung von Dokumenten für die weitere Bearbeitung unterstützen. Durch eine automatische Analyse von Text, Layout und Strukturinformationen eines Dokumentes sollen Inhalte ermittelt werden, die für die weitere Verarbeitung in Geschäftsprozessen oder für die Ablage in einem DMS erforderlich sind.

Es gibt einen eigenständigen Markt für OCR- und Klassifikationssoftware mit eigenen Subsys-temen. Da nur einige DMS-Anbieter eigene Module entwickeln, werden oftmals Kooperationen mit Anbietern entsprechender Erkennungsprodukte eingegangen, was aus funktionaler Sicht oft aus-reichend ist. Unterschiedliche Hardware-Plattformen von DMS und Erkennungslösung, mehrere Benutzer- oder Administrations-Anwendungen oder separate Protokollierung können in einem solchen Lösungskonzept zu erhöhten Aufwänden bei Einführung und Betrieb führen. Die Kosten und Nutzen gegenüber einem manuellen Verfahren müssen hier immer gegenübergestellt werden. Geringe Belegmengen oder sehr heterogene Dokumentstrukturen sind Merkmale, bei denen sich eine entsprechende Automatisierung bei der Erfassung von Dokumenten oft nicht rechnet.

Die Anforderungen an eine Software-unterstützte Erkennung von Dokumentinhalten können aus Sicht eines DMS-Anwenders ganz unterschiedlich sein. Daher interessieren uns Lösungen in nach-folgend dargestellten Produktkategorien.

Die Lösungen zur automatisierten Beleglesung werden häufig, optimiert für bestimmte Branchen oder Anwendungsfälle, mit einer Massenverarbeitung angeboten. Es gibt z.B. vorkonfigurierte und vortrainierte Produktpakete für Eingangsrechnungsverarbeitung, Zahlungsverkehr, Krankenkas-sendokumente etc., die auf die zu erwartenden Dokumente und damit verbundene Besonderheiten eingerichtet sind. Nicht jede Software ist grundsätzlich für jeden Anwendungsfall optimal nutzbar. Kann ein Produkt sehr gut Formulare verarbeiten, bedeutet das nicht, dass es auch für eine Frei-formerkennung der gesamten Eingangspost gleichermaßen gut geeignet ist.

Ein häufiger Anwendungsfall für den Einsatz von Erkennungslösungen ist die Eingangsrechnungs-verarbeitung. Aufgrund von Ähnlichkeiten bei Rechnungen werden darauf optimierte Produktsuiten als sogenannte „Rechnungsleser“ angeboten. Der Anwender sollte neben den Fähigkeiten zur Erkennung von Papiereingangsrechnungen auch auf Möglichkeiten zur Verarbeitung von elektro-nisch ausgetauschten Rechnungsformaten achten.

Produktkategorie Typischer Funktionsumfang Einsatzmöglichkeiten und Anwendernutzen

OCR-Tipphilfe •Ad-hoc-Auslesen von markierten Dokumentinhalten

•Typischerweise Client-basiert

•Ersparen von „Tipparbeit“ und Vermei-dung von Eingabefehlern, vor allem bei komplexen Zeichenketten,(Bestell-nummer, Artikelnummer, Adressanga-ben, etc.)

•Nutzung bei der manuellen Indizie-rung von Dokumenten

Volltext-OCR •Volltext-Erkennung aller Dokumentin-halte

•Bereitstellung der Inhalte zur Volltext-indizierung und Volltextsuche

•Inhaltserschließung bei Verträgen, Presseartikeln, etc.

•Suche nach Dokumenten unabhängig von der Dokumentart über gemein-same Inhalte

Formularbasierte Beleg-lesung, Zonen-OCR

•Auslesen von strukturierten Doku-mentinhalten

•Verwaltung von Formulardefinitionen für das Auslesen von Feldern

•Datenextraktion bei Antrags-, Bestell-formularen, etc.

•Automatische Indexierung von Doku-menten bzw. Datenerfassung in Fach-anwendungen

Freiform-Beleglesung •Auslesen von unstrukturierten Doku-mentinhalten

•Verwaltung von Regelwerken für die Beleganalyse

•Funktionen zur Systemoptimierung („Training“)

•Datenextraktion bei Eingangsrech-nungen, E-Mails, Eingangspost, etc.

•Automatische Indexierung von Doku-menten

•Automatische Übernahme von Daten in Fachanwendung (z.B. ERP-System)




Unterschiede zeigen sich hier bei den Fähigkeiten zur Interpretation von Rechnungspositionen in komplexeren Tabellenstrukturen. Die Erkennungslösung wird typischerweise immer in Verbindung mit einer elektronischen Prüfung und Freigabe im Kontext eines ERP-Systems genutzt. Wichtig sind in diesem Zusammenhang konfigurierbare Schnittstellen sowohl für den Zugriff der Erkennung auf ERP-Stammdaten zur Validierung von Leseergebnissen als auch für die Übertragung von Rech-nungsdaten in das verwendete ERP-System als Grundlage für weitere Bearbeitungsschritte.

Für die Dokumentverarbeitung sind folgenden Schnittstellen und Verarbeitungsschritte typisch:

Abbildung 3: Schnittstellen und Verarbeitungsschritte einer Capture-Umgebung

Anwender haben oft unterschiedliche Eingangskanäle für Dokumente. Neben den klassischen Papierdokumenten und Fax wird auch zunehmend E-Mail-Kommunikation genutzt. Erfassungslö-sungen benötigen die Fähigkeit, auch unterschiedliche Dokumentquellen und Dokumentformate zu verarbeiten. Stolpersteine finden sich in der automatisierten Klassifizierung und Weiterverarbei-tung von E-Mails, da diese weniger strukturiert sind als die eingehende Geschäftspost in Papier-form und als Containerformat beliebig komplex (z.B. Mail in Mail) sein können.

Bei digitalisierten Papierdokumenten stören sog. „Schmutzpartikel“, eingerahmte Zeichen, in falscher Orientierung eingelegte Seiten etc. den Lesevorgang. Hier fragen wir nach Möglichkeiten der eingesetzten Erfassungssoftwarekomponenten, unabhängig von Möglichkeiten der einge-setzten Scanner, die teilweise eigene integrierte Bildoptimierungsfunktionen bieten.

Die inhaltliche Erschließung von Dokumentinhalten erfolgt oftmals auf Basis verschiedener Merk-male. Informationen können bspw. in Barcodes oder Zeichen in Maschinenschrift enthalten sein. Unterschiede bei den Produkten zeigen sich bei komplexeren Aufgabenstellungen wie Dokumente mit Blockhandschrift (z.B. handschriftlich ausgefüllte Anträge) oder die Auswertung von Tabellen-strukturen (z.B. bei einer Rechnungsverarbeitung).

Das Lesen von möglichst „richtigen“ Inhalten ist eine wichtige Voraussetzung für die Qualität der weiteren Verarbeitung. Die angebotenen Lösungen unterscheiden sich hier in den verwendeten Verfahren und Technologien:

• Regelbasierte Erschließung, so dass auf Basis eines definierten Regelwerkes (Wenn–dann) Inhalte ermittelt werden können. Der Anwender definiert die Regeln manuell, nach denen die Erkennung arbeiten soll. Vorteile liegen in der klaren Entscheidung

• Selbstlernende Verfahren besitzen zwar auch ein Regelwerk, aber dieses passt sich selbst-ständig und impliziert an, wenn ein Anwender bspw. die erkannten Inhalte bestätigt oder korri-giert.




• Statistische Verfahren erlauben auf Basis von Häufigkeiten, bspw. von verwendeten Begriffen, auf den Inhalt des Dokumentes zu schließen.

• Grafische Verfahren nutzen Layout- und Dokumentinformationen zur Identifizierung von Inhalte, bspw. kann von einem Logo auf den Kreditor geschlossen werden.

Diese Verfahren können auch in Kombination zueinander eingesetzt werden, um die Erkennungs-ergebnisse weiter zu verbessern. Auf Basis der Einzelergebnisse unterschiedlicher Erkennungs-Engines kann dann das wahrscheinlichste Gesamt-Erkennungsergebnis ausgewählt werden (Voting-Verfahren).

Trotz aller Technologie gibt es einige Probleme in der Praxis, die auch dann auftreten, wenn eine OCR zu 100% arbeitet. Dies fängt bereits bei der Trennung der einzelnen Dokumente im Scan-Stapel an. Gerade gemischtes Beleggut verlangt oftmals eine manuelle Zusortierung von Trennblät-tern oder Barcode-Trennung, da die Software-Regeln für die Erkennung von Dokumentgrenzen nicht richtig greifen. Schwierig wird es auch bei der Mehrfachklassifikation von Dokumenten, also der Identifikation mehrerer Geschäftsvorfälle in einem Dokument („anbei finden Sie die Abrech-nung und ich bitte um die Zusendung von Information zum Produkt “?). Hier lassen sich Dokumen-tenklassen nicht immer ausreichend genau unterscheiden. Nützlich sind aussagefähige Statistik-funktionen, um schnell einen Überblick über typische Problemfälle zu bekommen.

Apropos Erkennungsraten: Oft hört man die Aussagen: „Unsere Erkennungsrate liegt bei 99%“. Bei genauerer Betrachtung stellt man leicht fest, dass bei dieser Aussage immer die Bezugsgröße wichtig ist: Geht es um Dokumente, Seiten, Felder oder Zeichen?

Eine Modellrechnung mit 500 Belegen à 2 Seiten (insg. 1.000 Seiten) mit jeweils 3 Feldern pro Seite und insg. 24 Zeichen pro Seite zeigt, dass hierbei ein deutlicher Unterschied für den Aufwand zur Nachbearbeitung entstehen kann:

Im schlimmsten Fall ist fast die Hälfte der Belege zu korrigieren, was so in der Praxis zwar nicht vorkommt, jedoch zeigt, dass man bei solchen Aussagen immer in die Details gehen muss.

Den Anwender interessieren für die Betreuung und den laufenden Betrieb die Möglichkeiten und damit verbundenen Aufwände zur Einrichtung einer Regelbasis zur Erschließung von Dokumenten. Während die Vergabe von festen Systemparametern, eine Programmierung oder die Eingabe von Regeln in einer spezifischen Syntax eine stärkere Strukturierung der Erkennung forciert, setzen selbstlernende Ansätze mehr auf die interne Fähigkeit des Systems zur intelligenten Klassifizie-rung. Diese kann bei möglicherweise geringerem Einrichtungsaufwand, einen höheren Trai-ningsaufwand, bedingt durch eine höhere Anzahl von Beispieldokumenten im Vergleich zu festen Struktur- und Regelvorgaben, erfordern.

Der wesentliche Faktor für die Qualität der Daten ist die Möglichkeit zur systemseitigen Validierung der Leseergebnisse. Neben Syntax-Prüfungen von Feldern (Format, Länge etc.) hilft der Abgleich mit externen Datenquellen, wie zum Beispiel einem Lieferantenstamm im ERP-System, zur Über-prüfung einer gelesenen Kontoverbindung im Fußteil einer Rechnung. Ist eine „Dunkelverarbei-tung“, d.h. ohne manuellen Eingriff von Anwendern, von Rechnungen mit Bestellung geplant, betrifft dies auch den systematischen Abgleich von tabellarischen Rechnungspositionen mit Bestellpositionen inkl. Summenprüfung etc.

Bezug Erkennungsrate = 99% Beleg-NachbearbeitungBeleg Von 500 Belegen werden 5 nicht voll-

ständig korrekt verarbeitet5 Belege (1%)

Seite Von 1.000 Seiten werden 10 Seiten nicht erkannt

Worst case: 10 Belege (2%)

Feld Von 3.000 Feldern werden 30 Felder nicht erkannt


Zeichen Von 24.000 Zeichen werden 240 Zei-chen nicht erkannt





In der Praxis kann die Erkennungssoftware nicht alle Dokumente immer zu 100% lesen bzw. immer vollständig validieren, d.h. ein Anteil der verarbeiteten Dokumente muss Mitarbeitern in einer Anwendungsoberfläche zur manuellen Entscheidung vorgelegt werden. Neben einer intuitiven und ergonomischen Benutzerführung zur Eingabe, Korrektur und Vervollständigung von unklaren Daten, sollte der Anwender auch auf die Lernfähigkeit des Systems durch Speicherung der Korrek-turen in die Regelbasis achten.

Soll eine Weiterverarbeitung von Daten in einem ERP-System erfolgen, ist die Unterstützung systemspezifischer Schnittstellen von Vorteil. Ein wichtiges Kriterium ist die Umsetzung von Trans-aktionssicherheit und Vollständigkeit bei der Übergabe von Dokumenten und Daten.

Für die Überwachung und Optimierung des gesamten Erkennungsprozesses sind statistische Infor-mationen sehr wichtig. Wie viele Lieferanten wurden bei Rechnungen erkannt, wie hoch war der Anteil an Rechnungen mit Korrekturen? Wir fragen nach Möglichkeiten, um bspw. Erkennungsraten oder Verarbeitungs- und Korrekturzeiten zu überwachen und bei Bedarf auszuwerten.

Bei der Auswahl eines Produktes ist vor allem die Prüfung der Verarbeitung mit eigenen, repräsen-tativen Dokumenten und Dokument-Stapeln wichtig – möglichst mit den eigenen Scannern digita-lisiert. Der Anbieter sollte auch das Regelwerk für die Erkennung und Prüfung kennen und reprä-sentative Datensätze zur Verfügung gestellt bekommen, um sein System vortrainieren zu können.

Wesentliche Bewertungskriterien sind:

• Erkennungsraten bei Verarbeitung des eigenen Belegguts

– Test-Stapel zur Vorbereitung und im Rahmen eines Anbieter-Termins

– Qualität der Erkennung geht vor Geschwindigkeit

• Aufwände für Administration

– Definition, Training neuer Dokumentenarten

– Übersichtlichkeit und Funktionalität der Admin-Anwendung

• Ergonomie der Korrekturanwendung

– Customizing und Anpassung ohne Programmierung

– Komplette und einfache Bedienung über Tastatur

• Transaktionsschutz

– Mechanismen zur VollständigkeitskontrolleAnzahl gescannter Dokumente = Anzahl bearbeiteter Dokumente = Anzahl exportierter Dokumente

• Integration in führende Zielsysteme (Schnittstellen)

– DMS-Lösungen

– ERP-Systeme oder andere Systeme für Prüfdaten oder Weiterverarbeitung

• Wirtschaftlichkeit

– Lizenzkosten der Software

– Kosten für das Training und Optimierung der Dokumente

• Manchmal wichtig: Architektur / Skalierbarkeit bei Anforderungen mit hohem Volumen

Abschließend muss noch der Hinweis erlaubt sein, dass diese Technologie zwar bei der Kostenre-duzierung der Dokumentverarbeitung hilft, aber nicht den Königsweg darstellt. Erster Schritt sollte immer die Vermeidung des Medienbruchs von Papier zu elektronischen Informationen sein. Die direkte elektronische Verarbeitung bspw. über elektronische Formulare, über EDI oder FTP, ist immer effizienter, als der Einsatz von OCR-Technik. Das papierlose Büro wurde bereits vor vielen Jahren propagiert, ist aber noch lange nicht Realität.




IV.4 Capture-Komponente für strukturierte Daten

In vielen Bereichen der Kommunikation zwischen Unternehmen (Business-to-Business; B2B-Kommunikation) hat sich der Austausch strukturierter, elektronischer Nachrichten etabliert:

• SWIFT-Messages im Bankenbereich

• DALE-Messages im Unfallversicherungsbereich

• EDI-Nachrichten im allgemeinen

• u.v.a.

Da der Inhalt dieser Dokumente häufig archivierungspflichtig ist, besteht bei vielen DMS-Anwen-dern die Anforderung, diese Unterlagen in das DMS übernehmen und ordnungsgemäß aufbe-wahren (archivieren) zu können.

Wie im folgenden Beispiel ersichtlich, sind diese Dateien zwar in vielen Fällen lesbar, aber für den normalen Anwender nicht interpretierbar (Beispiel aus einem EDI-Bestelldatensatz):

UNA:+.? 'UNB+UNOC:3+Senderkennung+Empfaengerkennung+060620:0931+1++1234567'UNH+1+ORDERS:D:96A:UN'BGM+220+B10001'DTM+4:20060620:102'NAD+BY+++Bestellername+Strasse+Stadt++23436+xx'LIN+1++Produkt Schrauben:SA'QTY+1:1000'UNS+S'CNT+2:1'UNT+9+1'UNZ+1+1234567'

Daher besteht häufig die Anforderung, die Datei im Zuge der Erfassung nicht nur in das DMS zu importieren, sondern den Inhalt der Datei in ein „Augenlesbares“, d.h. von einem Menschen lesbares Dokument umzuwandeln und ebenfalls im DMS abzulegen.

Somit lassen sich die Kernanforderungen an die Erfassungskomponenten (Capture-Komponenten) für strukturierte Dateien in folgende Funktionen zusammenfassen:

• Massenimport

• Auslesen (Parsen) der Daten zur Verwendung als Metadaten

• Umwandlung / Konvertierung der Dateien

Neben den „echten“ elektronischen Datenaustauschformaten, werden die in diesem Kapitel abge-fragten Erfassungskomponenten häufig auch für den Massenimport unstrukturierter, elektroni-scher Dokumente (bspw. zentraler PDF-Druckoutput aus Fachanwendungen oder für die Über-nahme von Dokumenten, die von einem Dienstleister digitalisiert wurden) eingesetzt.

Ein weiteres Einsatzfeld für diese Komponenten, welches zukünftig eine große Bedeutung bekommen dürfte, ist die Verarbeitung einer Mischform: PDF-Dateien mit einem definierten Satz an so genannten „custom properties“, das sind vom Anwender definierte Dateieigenschaften, die in die PDF-Datei eingebettet sind. Ausgelöst durch die Änderung der Vorsteuerabzugsfähigkeit elek-tronischer Rechnungen, laufen Vereinheitlichungsbemühungen, um einen Satz an Metadaten zu definieren, die in PDF-Rechnungen zur Übermittlung der Rechnungsdaten verwendet werden sollen. Es ist schließlich absurd, eine elektronisch erzeugte PDF-Rechnung beim Empfänger über einen OCR-basierten Rechnungsleser laufen zu lassen, um die Rechnungsdaten mit entspre-chender Fehlerquote auszulesen.

Eine zentrale Frage in diesem Kapitel lautet: Welche Import-Szenarien werden unterstützt?




Das Ziel bei der Realisierung der Import-Szenarien ist immer, ein robustes Verfahren zu implemen-tieren, welches die Dokumente automatisiert, mit den erforderlichen Metadaten versieht und diese dann im DMS in einem Teilarchiv oder einer elektronischen Akte ablegt. Daher lautet der Kern der Frage: Wie teile ich der Erfassungskomponente mit, wie die Metadaten für das zu importierende Dokument lauten. Die Erfassungskomponente sollte daher unterschiedliche Varianten des Imports, die sich vor allem in der Metadaten-Erfassung unterscheiden, unterstützen.

• Dateinamen: Eines der einfachsten, funktional aber auch eingeschränktesten, Verfahren besteht darin, jedem Dokument bei der Erzeugung die Metadaten im Dateinamen mitzu-geben, so dass die Erfassungskomponente den Dateinamen nach festgelegten Regeln analy-siert, zerteilt und die Metadaten des Dokuments daraus extrahiert. Aufgrund der Längenbe-grenzung für Dateinamen ergeben sich offensichtlich Grenzen hinsichtlich der Metadaten, die über dieses Verfahren mitgegeben werden können.

• CSV-Datei: Um diese Grenze aufzuheben, hat sich lange Zeit das CSV-Format (Comma seprated Value) bewährt. In diesem Fall werden die eigentlichen, durch Kommata getrennten, Metadaten in einer Textdatei gespeichert. Der Metadatensatz enthält eine Verknüpfung zu der betreffenden Datei. Die Erfassungskomponente muss nun die abzulegende Datei erfassen und die zu dieser Datei gehörenden Metadaten aus der CSV-Datei auslesen, so dass die Ablage im DMS erfolgen kann.

• XML-Datei: Weitere Flexibilität lässt sich durch den Einsatz von XML-Dateien erreichen. Über die Auszeichnung ist es einfach möglich, in einer Importdatei unterschiedliche Metadaten-Definitionen unterzubringen, die von der Erfassungskomponente identifiziert und ausgelesen werden müssen. Der weitere Importprozess ähnelt dem CSV-Verfahren.

Wie bereits eingangs erwähnt, sind strukturierte Dateien für die meisten Anwender nur „schwer“ zu lesen. Daher besteht in vielen Fällen die Anforderung, dass im Zuge der Ablage dieser Dateien im DMS eine Konvertierung in ein einfach lesbares Format erfolgen soll. Aber auch beim Massenim-port von Image-Dateien kann eine Konvertierung gewünscht sein. Daher werden die Verfügbarkeit entsprechender Konvertierfunktionen und der möglichen Zielformate ebenfalls abgefragt.

Keine Regel ohne Ausnahmen. Diese Aussage gilt natürlich auch für automatisierte Prozesse. Daher sind vor allem die Funktionen im Fehlerfall, das Fehlerhandling der Anwendung, relevant. In diesem Punkt unterscheiden sich die Produkte signifikant. Teilweise werden so gut wie keine Routinen zur Fehlerbehandlung zur Verfügung gestellt. Das kann zum Beispiel bedeuten, dass im schlechtesten Fall bei einem Problem der Import fortgesetzt wird und die problemhafte Datei in den Untiefen des Systems „verschwindet“, oder der komplette Import bleibt stehen, bis dies jemandem auffällt und eine Problembeseitigung angegangen wird. In den besseren Produkten werden Fehler-Queues und Fehlerprotokolle geführt, so dass zum einen fehler- oder problemhafte Dateien aussor-tiert und die Fehlermeldung protokolliert werden und zum anderen der Importprozess mit den problemfreien, zum Import anstehenden, Dateien fortgeführt werden kann. Gerade wenn es darum geht, dass in nächtlichen Jobs große Mengen elektronischer Dateien importiert werden müssen, sollte den Routinen und dem Verhalten der Anwendung im Fehlerfall, im Auswahlprozess, eine entscheidende Rolle beigemessen werden.




IV.5 Capture-Komponente für zentralen Druckoutput

Bei mittleren und großen Unternehmen werden die Ausgangsdokumente typischerweise auf zentralen, hochskalierbaren Output Management Systemen erzeugt und gedruckt. Im Unterschied zum lokal gedruckten Word-Dokument werden hier typischerweise keine Einzeldateien, sondern komplette Druckstapel mit hunderten oder zigtausenden von Dokumenten in Beschreibungs- und Druckformaten wie IBM 1403, AFP oder PCL in verschiedenen Output-Komponenten zur Dokumen-tenerstellung, -optimierung, Sendungsoptimierung und Sendungsverteilung verarbeitet. In den in diesem Prozess entstehenden Druckspools befinden sich sowohl die eigentlichen Nutzdaten als auch Steuerinformationen (Seitenvorschub, Dokumentwechsel) und Anweisungen zur Visualisie-rung (Verwendung von Fonts, Vektorgrafiken, Einbetten von Grafiken etc.). Mit anderen Worten: Diese Dateien stellen weniger ein visualisiertes Dokument dar, als vielmehr eine Sequenz von Anweisungen, was das Output-System (Drucker, PDF-Konverter etc.) tun soll, um das Dokument darzustellen. Sollen auch solche Dokumente in einem DMS aufbewahrt werden, benötigt man eine Software, die folgende Anforderungen abdecken kann:

• Interpretationsfähigkeit der jeweiligen Druckspoolformate

• Konvertieren und Aufsplitten einer Druckspooldatei in die Einzeldokumente. Ein 1403-Druckspool, welcher 25.000 Ausgangsrechnungen enthält, soll in 25.000 einzelne PDFs konvertiert und mit den jeweils gültigen Indexinformationen indexiert und archiviert werden.

• Löschen der Druckspooldatei nach erfolgreicher Archivierung aller Archivobjekte.

• Fehlerbehandlung bei nicht erfolgreicher Konvertierung, Indexierung, Archivierung.

Manche DMS-Anbieter bieten für Teilfunktionen eigenentwickelte Komponenten, manche inte-grieren Drittprodukte in ihr Lösungsangebot. Neben der reinen Funktionalität ist es für den Anwender auch wichtig, die Bedienfunktionen dieser Produkte zu verstehen: Dauert es 30 Minuten oder 4 Stunden bis Dokumentarten eingepflegt sind? Solche Aspekte wie Bedienbarkeit der Einricht- und Verwaltungswerkzeuge sind zwar wichtig, lassen sich aber über solche statischen Abfragen wie in dieser Marktübersicht eigentlich gar nicht abfragen. Wie soll man abfragen, ob das Ändern eines AFP-Profils „ergonomisch“ ist? Hier bleibt dem Anwender nur die Detailsichtung der in Frage kommenden Systeme, wenn er mit Hilfe dieser Übersicht eine erste Sichtung der mögli-chen Lösungen vorgenommen hat.

Werden Druckformate in ihrem ursprünglichen Format auch abgelegt (im Unterschied zur Ablage in einem konvertierten Format wie PDF), ist die Frage wichtig, wie diese Dokumente angezeigt werden sollen. Es ist kaum davon auszugehen, dass die Anwender über native PCL-, AFP- oder 1403-Viewer verfügen. Daher soll der Anbieter angeben, ob die DMS-Lösung über einen Viewer verfügt, der diese Druckformate nativ auch anzeigen kann oder ob diese Formate vorher in PDF oder TIFF konvertiert werden (müssen), die dann wiederum recht einfach in den normalen DMS-Viewern angezeigt werden können.

Vor allem bei Ablage nativer AFP-Dateien ist es wichtig zu verstehen, wie das System mit den so genannten AFP-Ressourcen umgeht. Diese Ressourcen sind Objekte, auf die aus dem Druckstrom heraus referenziert werden und die deswegen nicht mehrfach gespeichert werden müssen, was AFP zu einem äußerst schlanken Format macht. Diese native Form der AFP-Aufbewahrung erfordert dann aber auch, dass diese referenzierten Ressourcen bei der Reproduktion am Bildschirm eben-falls noch zur Verfügung stehen, um sie anzeigen zu können. Das bedeutet wiederum, dass das System in irgendeiner Form mit Versionen von Ressourcen umgehen können muss, was die wenigsten Systeme am Markt tun.

Die am weitesten verbreitete Variante ist daher die Konvertierung in PDF oder TIFF vor der Archivie-rung, wodurch sich keine Notwendigkeit zur nachgelagerten Ressourcenverwaltung ergibt. Für sehr große Druckjobs entsteht aber ein Mengenproblem, wenn der Kunde die Grafik und andere spei-cherintensive Objekte nicht mehr nur einzeln verlinkt, sondern nun in jedem Dokument abgelegt haben möchte. Der Anwender muss daher die Vor- und Nachteile der nativen Ablage versus der PDF- bzw. TIFF-konvertierten Ablage abwägen. PDF/A als Zielformat findet sich bei hochvolumigem Output eher selten, weil der PDF/A-Standard das Einbetten der verwendeten Zeichensätze fordert. Das hätte zur Folge, dass bei einem Druckjob mit 200.000 Ausgangsrechnungen jede PDF-Datei den kompletten Zeichensatz beinhalten würde, was je nach gewähltem Zeichensatz, Umfang des eingebetteten Subsets und Anzahl der verwendeten Zeichensätze einen zusätzlichen Speicherbe-darf von bis zu mehreren Hundert Kilobyte (pro Dokumentdatei wohlgemerkt) bedeuten würde. Mit




anderen Worten: Bei einem Zeichensatzumfang von 50 KB würde im Falle von wöchentlichen Druckläufen mit jeweils 100.000 Ausgangsdokumenten pro Jahr über 250 GB an Speicher nur für die eingebetteten Zeichensätze verbraucht werden. Dazu kommen die Auswirkungen auf die Leitungsbelastung, wenn komplette Akten mit Dutzenden oder Hunderten von Dokumenten über-tragen werden sollen. Ohne Zeichensätze sind die Dokumente in der Regel nur einen Bruchteil so groß, weil zu den reinen Zeicheninformationen (ohne Zeichensatz) nur noch der Speicherbedarf für den eigentlich schlanken PDF-Container (5-10 KB) hinzukommt. Für Anwender mit Massendruck wäre daher PDF/A ohne Font-Embedding die beste Variante, was aber zur Folge hätte, dass ein PDF/A-Validierungswerkzeug einen Mangel an PDF/A-Kompatibilität erkennen würde. Trotzdem kann es bei solchen High-Volume-Anwendungen sinnvoll sein, aus diesem Grund auf die 100%-ige PDF/A-Konformität zu verzichten (die gesetzlich nicht gefordert ist) und ein „beinahe PDF/A-Format“ mit gleichwertiger, langfristiger Reproduktionsfähigkeit mit einem Bruchteil der Speicher- und Übertragungsanforderungen zu wählen. Der entsprechende Fragenabschnitt der Marktüber-sicht deckt beide Varianten ab.

Wenn ein Anbieter hier keine eigenen Einträge macht, heißt das nicht, dass man nicht mit Hilfe von Drittprodukten und auf Basis dieses DMS eine vernünftige Lösung implementieren kann. Auf dem D.A.CH-Markt (Deutschland, Österreich, Schweiz) gibt es eine Reihe für diese Aufgaben speziali-sierter Hersteller, die technisch als Empfänger der Druckspools und Konvertierer/Formatierer für das DMS dienen.

IV.6 Archivierung

„Archivierung“ bezeichnet einen der missverständlichsten Begriffe der ECM-/DMS-Branche. Im Markt finden sich vornehmlich die folgenden drei unterschiedlichen Definitionen:

• Definition I: Sicherstellung (und Dokumentation) der wirksamen Verhinderung unzulässiger Änderungen und Sicherstellung der Reproduktionsfähigkeit aufbewahrungspflichtiger Inhalte (bildlich oder inhaltlich) über die Dauer der Aufbewahrungsfrist inklusive der Protokollierung zulässiger Änderungen. Zielgruppe dieses Archivierungsverständnisses sind fast alle privaten und öffentlichen Unternehmen und Organisationen. Neben der eigentlichen Archivierung ist zudem die Dokumentation der Verfahren und eingesetzten Schutzfunktionen für sachverstän-dige Dritte von Bedeutung: Die Schutzfunktion kann nicht alleine durch eine Arbeitsanweisung beschränkt sein, weil der „sachverständige Dritte“ dann nicht prüfen könnte, ob nicht doch Manipulationen stattgefunden haben. Die Schutzeinrichtung muss insbesondere „prüfbar“ und somit technischer (nicht nur organisatorischer) Natur sein.

In den Gesetzestexten zum Beispiel des Handels- oder Steuerrechts wird der Begriff „Archivie-rung“ gar nicht verwendet3. Was die DMS-Branche sprachlich verkürzt „Archivierung“ nennt, wird in den genannten Gesetzen als „ordnungsgemäße Aufbewahrung“ bezeichnet.

Wenn in dieser Marktübersicht der Begriff Archivierung verwendet wird, ist diese Definition I gemeint.

• Definition II: Datenarchivierung. Typischer Anwendungsfall: Datenauslagerung aus Produktiv-systemen zu Zwecken der Systemverschlankung. Zielgruppe: IT-Systembetreiber. Hier muss häufig begrifflich zu Backup abgegrenzt werden, weil es ein häufiges Missverständnis zu Datenarchivierung und Datenbackup gibt. Ein Backup dient der Sicherstellung der Verfügbar-keit (via Rückholung/Recovery) im Notfall. Datenarchivierung bedeutet, dass Daten aus dem Produktivsystem ausgelagert werden, weil sie den Systembetrieb unverhältnismäßig belasten und zur Verbesserung der Systemleistung aus dem Systembetrieb herausgenommen und einem Datenarchiv zugeführt werden.

Solche Auslagerungskonzepte findet man sowohl in individuell entwickelten Anwendungen als auch in kommerziell verfügbaren Anwendungen, z.B. zur Entlastung von SAP- oder E-Mail-Systemen. Diese Archivlösungen dienen der Verschlankung durch Auslagerung von Daten ggf. mit Verknüpfung zu verbliebenen Restdaten. Diese Art der Archivierung hat einerseits mit dem in der ECM-Branche häufig verwendeten Begriff der Archivierung in Aktenzusammenhängen wenig zu tun, dennoch werden für Daten- und Massen-Mail-Archivierung häufig DMS-Produkte eingesetzt, die auch in der vorliegenden Marktübersicht dargestellt sind.

3. Allerdings wird der Begriff „Archivierung“ in Kommentaren und Erläuterungsdokumenten, wie z.B. den FAIT-Dokumenten des IDW, und hier insbesondere FAIT3 wieder aufgegriffen.




• Definition III: Dauerhafte Aufbewahrung von Gegenständen und Unterlagen aus kulturhistori-schen Gründen. Zielgruppe: öffentlicher Bereich. Nur in diesem Anwendungsbereich kommt der Begriff „Archivierung“ in Deutschland als gesetzliche Anforderung vor und bezieht sich in der Regel auf Unterlagen, über die die Landesarchivare der Bundesländer bzw. der Bundesar-chivar (für Deutschland: in Koblenz) Verfügungsrecht besitzen: Gemeinden, öffentlich-recht-liche Organisationen und andere öffentliche Einrichtungen sind verpflichtet, im Vorfeld einer geplanten Vernichtung die Unterlagen einer übergeordneten Archivdienststelle zur dauer-haften Archivierung anzubieten, da diese den Auftrag hat, kulturhistorisch wertvolle Informa-tionen und Unterlagen zu erhalten.

Diese Art der dauerhaften Aufbewahrung von Originalunterlagen wird in der Regel nicht durch solche Produkte organisiert oder unterstützt, die in der vorliegenden Übersicht dargestellt werden.

Unabhängig davon, ob die Aufbewahrung gesetzlich (wie bei der kaufmännischen Aufbewahrung) oder aus sonstigem, zumeist zivilrechtlichem, Eigeninteresse begründet ist und dann häufig mit sehr viel längeren Aufbewahrungsfristen erfolgt: Im Kern geht es bei der Archivierung meistens darum, Unterlagen über die Dauer einer bestimmten oder zunächst unbestimmten Frist gegen unzulässige Änderungen geschützt und reproduktionsfähig vorzuhalten4. Die wichtigsten Erläute-rungen und Interpretationen zu den für fast alle Anwender relevanten Anforderungen zur ordnungs-gemäßen Aufbewahrung nach deutschem Steuer- und Handelsrecht finden sich in den folgenden Dokumenten:

• GoBS5 von 1995

• Derzeit in Entstehung: GoBS-Nachfolger GoBIT6

• IDW RS FAIT 3 7

Der Gesetzgeber macht dem Anwender keine Vorschriften bezüglich der Speichertechnologie. Bereits im BMF-Schreiben zur GoBS 1995 findet sich die folgende Textpassage, die klarstellt, dass der Gesetzgeber den Anwendern die Wahlfreiheit lässt, mit welchen technologischen Mitteln sie die Anforderungen für die Schutzfunktionen gegen unzulässige Änderungen umsetzen:

Abbildung 4: Ausschnitt aus dem BMF-Schreiben zu den GoBS 1995: Wahl der Speichermedien

Durch das Fehlen konkreter technologischer Gestaltungsvorschriften, wie die Anforderungen zur „Archivierung“ zu erfüllen sind, bieten sich somit unterschiedliche technisch-organisatorische Möglichkeiten, den geforderten Schutz der Dokumente und ggf. auch der Metadaten gegen unzu-lässige Manipulationen über die Dauer der Aufbahrungsfrist sicherzustellen. Diese Schutzfunkti-onen können grundsätzlich auf Speicherebene, auf System- oder Anwendungsebene, z.T. auf orga-nisatorischer Ebene oder mit einer Kombination dieser Verfahren umgesetzt werden.

4. Brand/Geis/Groß/Lindgens/Zöller: Gabler-Verlag, Steuersicher archivieren, 1. Auflage 20115. GoBS = Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme, veröffentlicht mit BMF-Schreiben vom 7. November 1995, IV A 8 – S 0316 – 52/95- BStBl 1995 I S. 7386. Grundsätze ordnungsmäßiger Buchführung beim IT-Einsatz (GoBIT)7. Fachausschuss für Informationstechnologie des IDW, Stellungnahme zur Rechnungslegung: Grundsätze ordnungsmä-ßiger Buchführung beim Einsatz elektronischer Archivierungsverfahren (IDW RS FAIT 3), verabschiedet vom Fachausschuss für Informationstechnologie (FAIT) am 11.07.2006. Billigende Kenntnisnahme durch den HFA am 6.9.2006




Organisatorische Maßnahmen alleine könnten zwar theoretisch ebenfalls die geforderte Unver-sehrtheit herbeiführen, aber nur, wenn sich jede handelnde Person an die betreffenden Anwei-sungen hält. Bei rein organisatorischen Maßnahmen fehlt jedoch die „technische Zwangsläufig-keit“ der Schutzfunktion, was dazu führt, dass ein auf dem guten Willen oder der ungetrübten Aufmerksamkeit der Mitarbeiter basierendes Verfahren nicht prüfbar wäre. Solche Verfahren wären daher nicht „revisionssicher“, um ein weiteres beliebtes Adjektiv der DMS-Branche zu verwenden. In der Regel ist mit „revisionssicher“ gemeint, dass ein prüfbares Verfahren ange-wendet wird, welches dem Prüfer mit ausreichender Glaubwürdigkeit darstellt, dass die verwen-deten Systeme und Verfahren den regulatorischen Anforderungen entsprechen.

Aufgrund der vielfältigen zulässigen Interpretationen des Archivierungsbegriffs und der damit einhergehenden vielfältigen Umsetzungsmöglichkeiten zwängt der Fragenabschnitt „Archivierung“ dieser Marktübersicht die Anbieter nicht in eine bestimmte technologische Richtung, sondern fragt einerseits die am Markt typischen Schutzfunktionen ab und lässt überdies Raum für die Darstel-lung weiterer Lösungen.

Sehr häufig wird für diese Schutzfunktionen eine DMS-Server-Funktionalität benötigt. Entweder weil der Server spezifische, mit Schutzmechanismen ausgestattete Speichersysteme ansteuert oder weil der Anbieter selbst, innerhalb seiner Serversoftware, Schutzmechanismen zur Verfügung stellt. Manchmal bedient er sich der Hilfe von Dritten, die zum Beispiel eine Schnittstelle zwischen einem DMS und einem externen Archivspeicher implementiert. Der Anwender sollte in diesen Fällen sicherstellen, dass diese Drittlösungen auf Dauer verfügbar sind und nicht durch Release-wechsel der DMS-Software oder der Speicherlösung nicht mehr funktionieren oder mit hohem Indi-vidualaufwand auf neue Architekturen oder Programmierschnittstellen angepasst werden müssen.

In der Praxis muss der Anwender prüfen, ab welchem Zeitpunkt er die Unveränderbarkeit der Doku-mente sicherstellen möchte. Für eingehende Handelsbriefe beispielsweise stellt sich die Frage nicht. Hier muss zu einem frühestmöglichen Zeitpunkt die Schutzfunktion greifen. Aber für intern erstellte Dokumente, die noch einem längeren Redaktionsprozess unterliegen, muss der Anwender selbst entscheiden, ab wann die aktuelle Dokumentenversion nicht mehr einfach überschrieben werden, sondern unveränderbar abgelegt und mit einer neuen Version versehen werden soll. Gerade wenn Akten aus solchen „lebenden“ und teilweise „archivischen“ Dokumenten bestehen, muss im Detail mit dem Anbieter geklärt werden, wie solche gemischten Aktenstrukturen innerhalb einer einzigen Ablage implementiert werden können, ohne vom Endanwender zu verlangen, änder-bare und unveränderbare Dokumente in unterschiedlichen Systemen abzulegen.

Von zunehmendem Interesse für die Anwender ist die Möglichkeit, Dokumente nach unterschiedli-chen Regeln zu schützen und zu löschen. Die Produkte verfügen daher zunehmend über Regel-werke, die eine oder sogar mehrere Regeln mit einzelnen Dokumenten, Akten, Dokumentarten etc. verknüpfen können. So ist zum Beispiel sicherzustellen, dass Abmahnungen nach einer bestimmten Zeit aus der Personalakte sicher gelöscht werden, während die anderen Dokumente über einen zunächst unbestimmten Zeitraum dort verbleiben müssen.

Einige der Systeme am Markt verfügen über sehr umfassende Möglichkeiten, diese Regeln durch Eintritt von Ereignissen (Schließen der Akte, Bezug eines Wertes aus einer führenden Anwendung wie SAP o.a.) oder manuelle Attributsänderungen einzuleiten. Solche Systeme zur Verwaltung von Aufbewahrungs- und Löschregeln (häufig verwendeter Begriff dafür ist Records Management) werden immer wichtiger, weil eine zunehmende Vielfalt von Dokumenten und Unterlagen in einem DMS zu verwalten sind, dadurch die Komplexität steigt und eine manuelle Aufbewahrungsfristen-verwaltung immer aufwendiger und daher auch fehleranfälliger wird.

Wenn die Aufbewahrungsfrist zum Zeitpunkt der Archivierung bekannt ist, können Löschregeln hinterlegt werden, die ein Aussondern der löschbaren Objekte automatisieren. Daher enthält der Fragebogen auch hierzu einige Fragen. Wie bei vielen anderen Frageabschnitten kann die Marktü-bersicht aus Platzgründen nur einführende Fragen enthalten. Der Anwender sollte im konkreten Projektfall noch weitere Details mit dem Anbieter abklären, wie beispielsweise:

• Wie können Löschfristen nachträglich geändert, verlängert, verkürzt werden. Werden diese Maßnahmen protokolliert?

• Wenn Dokumente auf unveränderbaren Speichern abgelegt sind: Wie wird eine „echte“ Löschung (auf Kundenwunsch, beim Verkauf von Unternehmensteilen an andere mit entspre-chenden Vereinbarungen zur Löschung von Kundenunterlagen) umgesetzt?




• Wenn sich in einer Akte Dokumente mit unterschiedlichen Aufbewahrungsfristen befinden: Kann man die Löschfristen so einrichten, dass die Akte komplett bleibt, solange sich noch aufbewahrungspflichtige Unterlagen in der Akte befinden? Sonst genügt man zwar dem Gesetz, hat aber eine nicht mehr auskunftsfähige Akte, weil durch das teilweise Löschen von Einzelunterlagen der gewünschte Überblick über den Gesamtsachverhalt verloren geht.

• Wenn Löschregeln ausgeführt werden: Kann man einstellen, welche Daten protokolliert werden? Hinweis: Normalerweise besteht keine gesetzliche Verpflichtung, Löschvorgänge zu protokollieren. Wenn Unterlagen nicht mehr aufbewahrungspflichtig sind, besteht kein Grund, Auskunft zu dieser Unterlage zu geben, auch nicht darüber, dass sie gelöscht wurde. Es sind häufig selbst auferlegte Regeln oder Vereinbarungen mit Dritten, die hinter der Forderung nach der Protokollierung von Löschvorgängen stehen.

IV.7 DMS-Funktionen

Im Abschnitt DMS-Funktionen werden die Kernfunktionen zur Verwaltung von Dokumenten über den gesamten Lebenszyklus übersichtsartig abgefragt: Von der Erstellung und Ablage der Doku-mente unter Verwendung der Microsoft Office-Produkte, über Dokumentenveränderungen mittels Versionierung und Check-Out/Check-In, Freizeichnung/Freigabe, bis zur Ablage und möglichen Wandlung in alternative (Archiv)Dokumentenformate.

Die Anforderungen an unveränderbare Speicherung von Dokumenten, die häufig auch unter dem Begriff der „Revisionssicherheit“ zusammengefasst werden, und die in modernen Dokumenten Management Systemen bereitstehenden Funktionen zur Veränderung von Dokumenten stehen in einem scheinbaren Widerspruch zueinander. Tatsächlich besteht dieser Widerspruch nicht, solange mit Hilfe des DMS inhaltliche Änderungen nachvollziehbar sind. Die Nachvollziehbarkeit kann in der Regel über Versionierungsfunktionen sowie geordnete Check-Out-/Check-In-Funktionen hergestellt werden. Die „unveränderbare Speicherung“ bezieht sich in diesen Systemen nicht auf das gesamte Dokument, sondern (lediglich) auf einzelne Versionsstände des Dokuments. Die Revi-sionssicherheit der Dokumentenablage ist hierdurch nicht per se gefährdet und wird gewährleistet, wenn das System die unveränderte Aufbewahrung der relevanten Dokumentenversionen sicher-stellt.

Nicht alle an der Übersicht beteiligten Systeme sind bereits im Produktkern mit diesen Funktionen ausgestattet und bieten diese ggf. in Zusatzkomponenten an. Daher fragen wir innerhalb der Marktübersicht zunächst ab, ob die DMS-Funktionen dieses Abschnitts bereits in einer einheitli-chen Archiv-/DMS-Software oder als separate Komponente mit eigenständiger Serverumgebung angeboten werden. In einzelnen Fällen bieten Hersteller zwar getrennte Serverumgebungen einer-seits für Archiv- und andererseits für DMS-Funktionen an, ermöglichen jedoch die gemeinsame Nutzung innerhalb eines einheitlichen Clients. Zumindest aus Anwendersicht bieten diese Systeme dann möglicherweise einen einheitlichen Umgang zu den verwalteten Dokumenten.

Gerade in Unternehmen mit geografisch verteilten Unternehmens- und/oder Rechenzentrum-Standorten, ist häufig eine Kombination aus lokaler sowie zentraler System- und Datenbereitstel-lung zu implementieren. Hierbei sind bereits im Systemkern etablierte Replikationsfunktionen besonders hilfreich, einen konsistenten Datenbestand der einzelnen Systeminstanzen zu sichern. Zusätzlich zu den abgefragten Funktionseigenschaften sind für die Bewertung konkreter Produkt-angebote weitere Aspekte zu berücksichtigen, wie z.B. zeitliche Steuerung der Replikationsfunkti-onen sowie Protokollierungs- und Überwachungsmöglichkeiten.

Die Verbreitung mobiler Endgeräte nimmt stetig zu und damit die Notwendigkeit, ohne jegliche Datenverbindung, also Offline, mit den DMS-Datenbeständen arbeiten zu können. Die Nutzung eines DMS im Offline-Betrieb stellt erheblich höhere Anforderungen an die Systemsoftware sowie an den Systemaufbau als ein reiner Online-Betrieb. Die im Rahmen der Übersicht gestellten Fragen bieten hier einen ersten Einstieg für den Vergleich der unterschiedlichen Lösungsansätze der Produkte.

Der Anteil am Arbeitsplatz erstellter oder abgelegter Dokumente wächst nach unserer Beobachtung in modernen DMS-Lösungen ständig an. Diese Dokumente werden zumeist im Ursprungsformat abgelegt, vornehmlich als MS Office-Datei. Zwecks dauerhafter und universeller Verfügbarkeit bevorzugen viele Kunden die Möglichkeit zur Formatwandlung von Office-Dateien und E-Mails in etablierte Langzeitformate wie PDF, PDF/A oder TIFF.




Im Rahmen dieser zunächst banal klingenden Aufgabe – Wandlung von Format A nach B – sind im Praxiseinsatz zahlreiche Herausforderungen zu meistern, die im Rahmen der hiermit vorliegenden Übersicht großteils unberücksichtigt bleiben müssen: Bewusst erfragt die Übersicht lediglich die grundlegenden Möglichkeiten, die in den dargestellten Produkten enthalten sind.

Weitere in der Praxis relevante Aspekte wurden aus Platzgründen nicht aufgenommen und sollen hier – ohne Anspruch auf Vollständigkeit – kurz angerissen werden:

• Möglichkeiten zur Festlegung des Wandlungsumfangs: Dieser Aspekt spielt insbesondere bei Tabellenkalkulationsdateien eine bedeutende Rolle, denn es ist häufiger Wunsch, dass nicht die gesamte Datei, sondern lediglich einzelne Datenblätter gewandelt werden sollen; auch sind Einschränkungen innerhalb der Datenblätter, z.B. auf den Druckbereich häufig gewünscht. Die Eingriffsmöglichkeiten des Anwenders zur Bestimmung des Wandlungsum-fangs sind bei Server-basierten Lösungen in der Praxis häufig deutlich geringer als bei Client-basierten Lösungen.

• Sicherung des Dokumentenlayouts: Wie ist sichergestellt, dass das Layout des gewandelten Dokuments dem Layout des gedruckten Dokuments entspricht und vor allem Verweise auf Seitenzahlen ihre Gültigkeit erhalten?

• Einsatzumgebung: Sind Einschränkungen in der Produktfunktionalität oder im Produktsup-port beim Einsatz z.B. in Terminalserver-Umgebungen zu berücksichtigen?

• Wandlungsgeschwindigkeit / Ressourcenbedarf: Mit welcher Geschwindigkeit erfolgt die Formatwandlung – wie hoch ist der Hardwarebedarf, um innerhalb einer gesetzten Frist eine definierte Menge an Dateien wandeln zu können (zwecks Einhaltung von Service-Level-Verein-barungen).

• Verlässlichkeit / Administrationsaufwand: Wie stabil läuft die Wandlungsfunktion und welchen Betreuungsaufwand ruft sie hervor? Welche Automatismen in der Fehlerbehandlung sichern die weitere Produktionsfähigkeit auch im Störungsfall?

Nach der Darstellung grundlegender Systemfunktionen vertieft die Marktübersicht einzelne Aspekte der im Client zur Verfügung gestellten Anwendungsfunktionen, wobei dieser Teil des Frage-bogens doppelt ausgeführt ist: Einmal für den sog. Rich-Client und ein weiteres Mal für den sog. Browser-Client. In der Praxis sehen wir, dass weiterhin beide Client-Varianten nachgefragt werden und zusätzlich beobachten wir teilweise deutliche Unterschiede in den Funktionsangeboten. Einige Hersteller bieten zwischenzeitlich ausschließlich Browser-Clients für den Dokumentenzugriff an. War es vor einigen Jahren noch so, dass Browser-Clients generell funktional und ergonomisch den „fetten“ Rich Clients deutlich unterlegen waren, so ermöglichen aktuelle Web-Technologien wie bspw. Ajax RIA-Frameworks, (RIA = Rich Internet Application) und HTML5, Browser-Clients funkti-onal und ergonomisch ähnlich leistungsstark auszustatten wie Rich Clients. Es bleibt die Notwen-digkeit, seitens des Anwenders die Funktionalität und Bedienbarkeit der künftigen Lösung im Vorfeld detailliert zu untersuchen.

Da die Kategorisierung der Client-Umgebung in „Rich-“ und „Thin-“Client nicht genormt ist, wird in der Übersicht konkret nach den verwendeten Client-Technologien abgefragt. Auf diese Weise sollen Einordnungsprobleme sog. RIA-Clients, also Clients auf Basis von Java, Flash/Flex, AJAX etc. vermieden werden.

Die kurze kategorische Übersicht über die im Client enthaltenen Funktionen kann im Rahmen der Produktauswahl lediglich zu einer groben Weichenstellung dienen. Alle hier angesprochenen Funk-tionskategorien sind im Rahmen einer konkreten Auswahlsituation vertieft zu untersuchen, denn innerhalb jeder Funktionsgruppe ergeben sich häufig wesentliche Produktunterschiede. Die Funk-tionsgruppen „Aktenfunktionen“, „Postkorb-Funktionen“ und „Collaboration-Funktionen“ werden aufgrund ihrer besonderen Funktionsvielfalt in eigenen Unterkapiteln dieser Marktübersicht vertieft dargestellt.

Andere Funktionsgruppen werden bereits im aktuellen Kapitel DMS-Funktionen vertieft durch-leuchtet, wie z.B. Such- und Trefferlistenfunktionen sowie die Fragestellungen zur Dokumentenan-zeigefunktion (Viewer) und Versionierung.




In besonders komplexen DMS-Anwendungsbereichen ergeben sich immer wieder Anforderungen zur Bildung komplexer Dokumentenstrukturen mit Hilfe sog. Verbunddokumente. Auch hier vermit-telt die Marktübersicht einen ersten Eindruck, welche DMS-Produkte überhaupt das Konstrukt der Verbunddokumente unterstützen – weitere wesentliche Aspekte, insbesondere zur Usability, sind jedoch einer konkreten Produktsichtung vorbehalten.

Abgeschlossen werden die Client-Funktionsübersichten mit einigen typischen Prozessanforde-rungen an DMS-Lösungen: Freigabe und Änderungsbenachrichtigung.

Nach Betrachtung der Client-Funktionen folgen Fragestellungen zur MS Office- inkl. MS Outlook-Integration sowie zur Windows Explorer (Desktop und File-System) Integration. Gerade diese beiden Integrationsszenarios spielen in produktiven DMS-Anwendungen eine besonders wichtige Rolle, denn Anwender benötigen einen einfach und schnell bedienbaren Zugang zum DMS, insbesondere für die Ablage ihrer Dokumente.

Die Fragen nach den Administrationswerkzeugen für die Einrichtung und Verwaltung von Ablage-funktionen dienen einem ersten Einstieg in die Fragestellungen zur Betriebsführung der DMS-Lösung. Für die Umsetzbarkeit konkreter Betriebskonzepte muss hier ebenfalls tiefer untersucht werden. Beispielsweise kann die Notwendigkeit bestehen, die Administration des Systems für unterschiedliche Anwendungsbereiche mittels Berechtigungssteuerung an getrennte Personen oder Gruppen zu übertragen.

Die abschließende Frage über CAD-Integrationsfunktionen soll einen ersten Einstieg in die beson-ders komplexen Anforderungen an DMS-Lösungen zur Dokumentenverwaltung technischer Anlagen vermitteln. Systeme mit dem Funktionsschwerpunkt „Verwaltung technischer Dokumenta-tion“ sind deutlich seltener anzutreffen als DMS-Lösungen zur Verwaltung kaufmännischer Doku-mente; der Markt für sog. EDM-Lösungen (EDM = Engineering Document Management) füllt eine Nische, die im Rahmen der hiermit vorliegenden Übersicht nur sehr grob angesprochen wird. Weiterführende typische EDM-Fragestellungen, wie die Integration konkreter CAD-Produkte, spezi-elle Freigabeprozesse oder Automatisierung von ERP-Prozessen können aus Platzgründen inner-halb der Übersicht nicht vertieft untersucht werden.

IV.8 Aktenverwaltung

Was für viele Anwender eine Selbstverständlichkeit ist, war jahrelang in vielen DMS-Lösungen eine funktionale Lücke: eine anpassbare elektronische Aktenverwaltung, die die bisher genutzten Papieraktenstrukturen ohne funktionale und wenn möglich auch ohne ergonomische Einschrän-kungen abbilden kann. In den letzten Jahren haben sich die marktgängigen Dokumenten Manage-ment Systeme bezüglich der Aktenverwaltungsfunktionen deutlich verbessert: Während vor einigen Jahren die Aktenfunktionalität vieler Systeme kaum über einfache Ordnerstrukturen hinausging, gibt es heute immer mehr Produktangebote mit umfassenden Funktionalitäten, die auch komplexe Anforderungen abdecken können.

Was dem Anwender die Auswahl erschwert: Der Begriff „Aktenverwaltung“ wird nicht einheitlich verstanden und kann daher nicht alleine für die Einschätzung der Funktionalität eines DMS heran-gezogen werden. Vielmehr gilt es, eine Vielzahl von Funktionen und Objektverwaltungsmöglich-keiten zu untersuchen, die in ihrer Gesamtheit Aktenverwaltung ausmachen. Produkte unter-scheiden sich heute seltener darin, ob sie überhaupt Aktenfunktionen bereitstellen, sondern immer häufiger darin, welche Aktenfunktionen mit welchen Gestaltungsmöglichkeiten bereitgestellt werden.

Für die vorliegende Marktübersicht wurden aus der Vielzahl der von Anwendern in Umsetzungspro-jekten geforderten Aktenfunktionen diejenigen Anforderungen herausgegriffen, die nach unserer Kenntnis am häufigsten benötigt werden. Es ist jedoch darauf hinzuweisen, dass die einzelnen Funktionen in konkreten Umsetzungskonzepten und daher auch im Rahmen von Auswahlprojekten häufig erheblich detaillierter durchleuchtet werden müssen. Dies gilt insbesondere für Funktions-anforderungen an die Aktenmodellierung oder an die Berechtigungssteuerung.

Im Rahmen der Marktübersicht wird zunächst abgefragt, ob die Aktenfunktionalität bereits in einer genannten Komponente (typischerweise DMS-Server) enthalten ist oder ob sie mittels einer sepa-raten Komponente bereitgestellt wird.




Wie bei allen potentiell separaten Komponenten wird auch bezüglich der Aktenverwaltung abge-fragt, wer der Hersteller ist, seit wann die Komponente im Markt verfügbar ist und wie sie im Markt verbreitet ist.

Aus Anwendersicht ist die Aktenfunktionalität häufig integraler Bestandteil der DMS-Lösung; über die Fragestellungen zur „Integration mit DMS/ECM“ wird erkennbar, wie homogen oder inhomogen die Bedienweise der Aktenverwaltung mit den übrigen DMS-Funktionen erfolgt.

Zunehmend besteht der Bedarf nach einheitlicher Strukturierung der im DMS verwalteten Akten. Hier haben sich in Unternehmen und Behörden viele Begriffe etabliert, die ähnlich klingen und leider dennoch häufig etwas anderes umschreiben, wie z.B. Aktenmodell und Aktenplan.

Im Rahmen der Marktübersicht wird der Begriff des „Aktenmodells“ verwendet. Das Aktenmodell im Sinne der Marktübersicht besteht aus einer Meta-Beschreibung für den Aufbau konkreter Akten, einer Art Akten-Schablone. Die konkreten, im DMS gehaltenen, Akten werden bei ihrer Bildung aus dem Aktenmodell abgeleitet. Das Aktenmodell wirkt hierbei wie eine Vorlage. Prominente Vertreter von Aktenmodellen sind z.B. Personal-, Kunden-, Lieferanten-, Bestell-, Reklamations- und Projek-taktenmodelle. Das Aktenmodell „Personalakte“ enthält das Regelwerk und die grundsätzliche Aufbaubeschreibung aller Akten vom Typ „Personalakte“. Die Personalakte des Mitarbeiters „Max Mustermann“ ist dann eine aus dem Aktenmodell „Personalakte“ abgeleitete Instanz. Diese Perso-nalakte enthält die Dokumente, die zum Personalstamm „Max Mustermann“ gehören.

Systeme, die keine Aktenmodellierung erlauben, können dennoch mit Aktenfunktionen ausge-stattet sein. In diesen Systemen kann die Einheitlichkeit der Akten jedoch nur mit Hilfe strenger (überwachter) Organisationsanweisungen erzielt werden, die dem Anwender klar vorgeben, wie jede einzelne Akte zu strukturieren ist oder z.B. über individuell entwickelte Anwendungen, die Strukturfehler aufdeckt und ggf. auch korrigiert.

Alle Strukturierungsmöglichkeiten von Aktenmodellen gelten automatisch für die aus den Modellen generierten Akten. Dies gilt insbesondere bezüglich der Registerstrukturen (Anzahl, Tiefe) und der Akten-Metadaten: Aktenanwendungen zeichnen sich vielfach dadurch aus, dass sie eigene Meta-daten auf der Ebene von Akten und Registern zulassen, die über eine einfache Bezeichnung der Akte / des Registers hinausgehen. Typische Anwendungsfälle von Akten-Metadaten sind das Fest-legen der Aktenbezeichnung, des Aktenstatus, des Akten-Vernichtungsdatums etc. Diese Daten gelten vielfach unabhängig vom einzelnen Dokument und sind daher bei sauberer Strukturierung als Akten-Index anstelle als Dokumenten-Index zu führen.

Die Unabhängigkeit der Akten-Infrastruktur des DMS von der Dokumenten-Infrastruktur wird insbe-sondere im Anwendungsfall „leere Akte“ deutlich: Das System soll eine Akte inklusive der Beschrei-bungsdaten bereitstellen können, obwohl (noch) keine Dokumente zum Fall, Kunden etc. abgelegt sind.

Typische von Anwendern geforderte Aktenfunktionen umfassen die Möglichkeit der Aktenrecherche in Abgrenzung zur Dokumentenrecherche sowie weitergehende Anwendungsfunktionen, die teil-weise auf die Arbeitsorganisation (bspw. Wiedervorlage, Offline-Speicherung für Notebook, E-Mail-Ablage) und auf Zusammenarbeit im Team zielen (bspw. E-Mail-Weiterleitung).

Die Fragen nach den in Akten verwaltbaren Elementen verdeutlichen, dass immer mehr Anwender Aktenanwendungen als zentralen Informationspool verwenden, der durchaus auch DMS-„fremde“ Objekte verwalten oder Beziehungen zwischen Akten darstellen können soll.

Abschließend fragt die Marktübersicht nach einigen weiterführenden Aktenfunktionen, wie z.B. den Löschregeln für Akten und Verwendungsnachweisen für Dokumente (in welchen Akten befindet sich das aktuell angezeigte Dokument?). Diese sind hilfreich, wenn Anwender eine reine Dokumen-tensuche durchgeführt haben und vom Dokument in die zugehörige Akte geleitet werden wollen sowie zur Prüfung der Vollständigkeit, wenn Dokumente in mehrere Akten gehören.




IV.9 E-Mail-Archivierung

E-Mail ist die heute am häufigsten genutzte Kommunikationsform für den Austausch von geschäfts-relevanten Willenserklärungen und Dokumenten wie z.B. Angeboten, Bestellungen und zukünftig vermehrt auch Rechnungen. Daher ist es logisch, dass die E-Mail wie andere Dokumente auch ordnungsgemäß aufbewahrt („archiviert“) werden muss. Der Begriff E-Mail-Archivierung erzeugt aber bei Anwendern häufig Verwirrung, da der Begriff im Markt für drei sehr unterschiedliche Anwendungsszenarien steht:

• E-Mail-Archivierung I: Journalarchivierung: Alle ein- und ausgehenden E-Mails werden zum frühestmöglichen Zeitpunkt als Journal-Kopie in einem anderen System geschützt abgelegt. Hierbei werden die einzelnen E-Mails nach wie vor in die Zielpostfächer weitergeleitet, es findet keinerlei Entlastung des Mail-Systems statt. Journalarchivierung dient in der Regel dazu, Beweis führen zu können, dass man bestimmte E-Mails erhalten oder versendet hat oder sogar, dass dies belegbar NICHT der Fall war. Journalarchivierung wird nicht von jedem Unternehmen benötigt, sondern nur wenn entsprechende rechtliche Vorgaben erfüllt werden müssen.

• E-Mail-Archivierung II: Regelbasierte Archivierung: Hierbei geht es primär um die Entlastung der Mail-Systeme. E-Mail bzw. deren Attachments werden dabei nach bestimmten Regeln (älter als…, größer als…, etc.) aus dem Mail-System ausgelagert und ggf. durch Links ersetzt, wenn sie noch im Zugriff durch die Mitarbeiter verbleiben sollen. Diese Form der E-Mail-Archi-vierung wird nicht aus rechtlichen Gründen durchgeführt, sondern, um die Mail-Datenbanken oder die Speicher zu entlasten. Wenn es um die Auslagerung von Objekten aus den E-Mail-Datenbanken geht, sollten Anwender auch die Möglichkeiten moderner E-Mail-Systeme beachten, die zum Teil bereits eigene Auslagerungsfunktionen anbieten (z.B. persönliche Archivpostfächer in Exchange 2010).

• E-Mail-Archivierung III: Qualifizierte Ablage (z.B. in einem DMS): Hierbei wird das Problem adressiert, dass die geschäftliche E-Mail häufig im E-Mail-System aufbewahrt wird und nicht zusammen mit den anderen Dokumenten, die zum Prozess (z.B. Rechnung, Antrag) oder der Ordnungsstruktur (z.B. Kunde, Liegenschaft, Projekt) gehören. Dadurch entstehen lücken-hafte Akten, der Überblick auf den gesamten Sachverhalt geht verloren. Das kann bei aufbe-wahrungspflichtigen Dokumenten auch zum Compliance-Problem werden, weil aufbewah-rungspflichtige Unterlagen im E-Mail-System selbst nicht ausreichend sicher aufbewahrt werden können. Bei dieser Form der E-Mail Archivierung besteht daher die Möglichkeit, einzelne oder mehrere E-Mails in einem DMS abzulegen, typischerweise in einer Ordnungs-struktur, in die auch gescannte und andere Dokumente abgelegt werden.

Für die Varianten I und II hat sich ein eigener Markt mit rein auf die E-Mail-Archivierung ausgerich-teten Systemen entwickelt. Zum Teil bieten aber auch DMS-Hersteller solche Funktionen an.

Die vorliegende Marktübersicht fragt alle drei Varianten ab, aber immer aus der Perspektive einer DMS-Lösung. Die Fragen zum Themenkomplex E-Mail-Archivierung sind daher untergliedert in Client-basierte E-Mail-Archivierung (erlaubt die qualifizierte Ablage gem. Variante III) und die regel-basierte, systemgetriebene Archivierung

IV.9.1 Client-basierte E-Mail-Archivierung

In mittlerweile fast allen DMS-Projekten benötigt ein Sachbearbeiter die Möglichkeit, direkt aus dem Mail-Client eine; im Zusammenhang mit Geschäftsvorgängen aufbewahrungspflichtige bzw. aufbewahrungswürdige; E-Mail in eine elektronische Kunden-, Lieferanten-, Projektakte, abzulegen.

In der Marktübersicht wurden Anbieter nach den Möglichkeiten für eine Ablage vollständiger E-Mails oder nur einzelner Anhänge aus den am meisten verbreiteten Mail-Clients MS Outlook und IBM Lotus Notes sowie in einem eigenen Kapitel aus „anderen Mail-Clients“ gefragt.




Die angebotenen Integrationen zur Anwender-getriebenen Archivierung zeigen Unterschiede im Verfahren und dem Zeitpunkt der Archivierung. Eine häufige Variante ist die direkte Ablage aus dem Mail-Client in eine individuell ausgewählte DMS-Ordnungsstruktur. Hierbei erfolgt die Indizierung und Archivierung synchron. Mit der Ablage „in einer Akte“ ist damit die Indexierung ganz oder teil-weise bereits erfolgt. Fehlende Attribute, die sich nicht aus den Aktenattributen ergeben, kann der Anwender in einem Index-Dialog hinzufügen. Eine andere Variante ist, dass der Anwender seine zu archivierenden E-Mails manuell in vorbereitete, sogenannte Archivordner der E-Mail-Umgebung verschiebt. Bei diesem Verfahren werden die Mails typischerweise über einen Hintergrundprozess, zeitversetzt aus den Archivordnern ausgelesen und in vordefinierte Ablagestrukturen des DMS abgelegt. Bei diesem Prozess ist zu beachten, dass zum Zeitpunkt der asynchronen Übertragung keine fehlenden Indexwerte mehr zugeordnet werden, d.h. das Lösungskonzept muss Vorsorge treffen, dass alle für die Ablage benötigten Attribute zum Zeitpunkt des Verschiebens in den E-Mail-Archivordner vorhanden sind.

Um den manuellen Aufwand bei der Client-basierten Indexierung zu minimieren, bieten einige Anbieter eine automatisierte E-Mail-Klassifikation an. Daher haben wir hierzu Fragen im Fragenka-talog mit aufgenommen. In der Praxis sind solche Systeme aber weit von der Interpretationsfähig-keit der Mitarbeiter entfernt, da sich die Zuordnung zu bestimmten Geschäftsvorgängen oder Ordnungsstrukturen bei unstrukturierten E-Mails (diese machen den Löwenanteil aus) nur sehr schwer erreichen lässt. Wesentliche Ursachen sind: die Angaben zur korrekten Ablage sind in der E-Mail gar nicht enthalten (korrekte Kreditorennummer, Bauprojekt-Kennzeichen, Artikelnummern-serie) oder sie sind zwar enthalten, aber irgendwo zusammen mit vielen anderen Informationen und nicht eindeutig zuzuordnen. Ein Mensch hat hier definitiv Vorteile bei der inhaltlichen Erschlie-ßung, weil er im Zweifel situativ andere Systeme, Kollegen oder den Absender einbeziehen kann.

Unterschiede zeigen sich auch bei Funktionen zur automatisierten Ablage von ausgehenden, durch den Anwender erstellten E-Mails (z.B. Dokumentation von eigenen Korrespondenzen). Auch hier gelten die für eingehende E-Mails gemachten Anmerkungen zu den Unterschieden zwischen der manuellen und der (teil)-automatisieren Ablage.

E-Mails werden zwar in einem standardisierten Transportformat – RFC 2822-Format – zwischen E-Mail-Systemen ausgetauscht, dort aber in herstellerspezifischen Formaten verwaltet. Für die Speicherung und Anzeige der archivierten E-Mails setzen die DMS-Anbieter auf unterschiedliche Methoden und Verfahren, oft getrieben durch Philosophien eingesetzter Viewer-Technologien. Für die Anzeige einer im Mail-System-spezifischen Format archivierten E-Mail wird entweder der entsprechende E-Mail-Client oder ein herstellerspezifischer Viewer mit Formatinterpretation benö-tigt.

Einige Mail-Clients wie Lotus Notes oder Novell GroupWise bieten keine Speicherung der gesamten E-Mail inklusive aller Anhänge in einem Containerformat (alle Elemente einer Mail in einer Datei) als Standardfunktion an. Hier wählen Anbieter oftmals den Lösungsansatz mit Aufsplitten einer E-Mail in seine Bestandteile (Body und Anhänge) und deren Speicherung in getrennten Dateien. Wichtig bei diesem Verfahren ist die Wahrung des logischen Zusammenhangs der gesamten E-Mail (Briefzusammenhang), insbesondere wenn eine spätere Wiederherstellung erforderlich wird.

Neben der Möglichkeit zur DMS-Ablage von E-Mails im Originalformat wird in der vorliegenden Über-sicht auch nach Möglichkeiten einer Formatkonvertierung für EMail-Texte oder auch von Anhängen in ein Standardformat wie z.B. PDF gefragt, um eine Mailsystem-neutrale Anzeige im PDF- oder TIFF-Viewer zu ermöglichen. Hierbei ist zu beachten, dass nicht alle DMS-Lösungen eine solche Konver-tierungsmöglichkeit anbieten, und einige Produkte neben dem Originalformat auch eine konver-tierte Fassung dauerhaft bereitstellen. Stolpersteine bei Konvertierungen sind Dateiformate wie zum Beispiel MS Excel und MS Project, die mehrere Druckformatierungsmöglichkeiten besitzen und die Entscheidung für eine der Varianten immer zu einem Informationsverlust führt. Ebenso wenig lassen sich Video- oder Musikdateien in PDF oder TIFF konvertieren. Im Prinzip hilft der Grundsatz: einfach in TIFF oder PDF bzw. PDF/A lassen sich nur solche Dokumente konvertieren, deren Default-Druckansicht für die Aufbewahrungsanforderungen ausreichend ist und bei denen keine wichtigen Informationen verlorengehen (wie z.B. die Excel-Formel bei PDF-Konvertierung).




Nach der Archivierung einer E-Mail wünschen sich Anwender DMS-seitige Unterstützung mit folgenden Optionen:

• Die archivierte E-Mail wird automatisch im E-Mail-System gelöscht. Dies verhindert, dass nach Wochen oder Monaten eine E-Mail abermals archiviert wird, weil dem Anwender nicht ersicht-lich ist, ob die E-Mail bereits archiviert wurde.

• Die archivierte E-Mail wird durch einen DMS-Link ersetzt. Der Vorteil besteht hier in der Redu-zierung des Speicherbedarfs in der E-Mail-Datenbank. Sollen diese E-Mails noch offline zur Verwendung, bereitstehen, sollte der Anwender auf entsprechende Offline-Zugriffsmöglich-keiten achten. Solche Offline-Funktionen erhöhen aber die Komplexität der Lösung, weil geklärt werden muss, ob der Anwender offline E-Mails ändern (Attribute) oder sogar löschen können soll. Wenn ja, dann muss eine saubere Replikation mit dem DMS verfügbar sein, wenn er wieder am System angeschlossen ist. Da es sich dann aber nicht mehr um persönliche Ordner, sondern um Abteilungsablagen handelt, muss sichergestellt werden, dass bei konkur-rierenden Schreibzugriffen keine Fehler auftreten, weil nun der Datenbestand inkonsistent geworden ist. Mit anderen Worten: Offline-Replikation mit Änderungsmöglichkeiten ist ein sehr komplexes Thema mit erheblichen Risiken, das vom Anwender nur gefordert werde sollte, wenn er sich über die Tragweite (funktional und technisch) im Klaren geworden ist.

• Die archivierte E-Mail verbleibt im E-Mail-System und muss ggf. manuell gelöscht werden. Die Vorteile sind hier die Möglichkeit einer direkten Bearbeitung und Weiterleitung, insbesondere an externe Partner aus dem E-Mail-System.

Weiter werden in diesem Kapitel die Möglichkeiten zur Recherche nach archivierten E-Mails abge-fragt. Neben der Suche und Anzeige im DMS-Client können in Mail-zentrischen Anwendungsszena-rien auch Recherchemöglichkeiten im ursprünglichen E-Mail-Client sinnvoll sein.

Typischerweise wird von Anwendern neben der Suche über Metadaten auch eine inhaltliche Suche (über den Volltext von Mail-Bodies und Anhängen) gewünscht. Hilfreich bei einer Volltextsuche ist eine optische Unterstützung durch Markieren der gesuchten Begriffe innerhalb der gefundenen Ergebnisse.

IV.9.2 System-getriebene Mail-Archivierung

Die System-getriebene Mail-Archivierung unterscheidet sich deutlich von der Anwender-getrie-benen Mail-Archivierung: Im Gegensatz zu einer Anwender-getriebenen E-Mail-Archivierung, bei der ein Anwender aus dem Mail-Client heraus aktiv die Archivierung auslöst, zeichnet sich der System-getriebene Lösungsansatz durch eine zentral ablaufende Funktion aus, die E-Mails nach defi-nierten und im System hinterlegten Regeln aus einem E-Mail-System archiviert. Die Durchführung der E-Mail-Archivierung erfolgt automatisiert, teilweise zeitversetzt, im Hintergrund und erfordert keine Benutzeraktivitäten. Das Regelwerk kann zeitgesteuert, ereignisgesteuert oder auch kombi-niert mit mehreren Faktoren ausgeprägt sein.

Eine typische Triebfeder für den Einsatz einer System-getriebenen E-Mail-Archivierung sind für ein Backup immer größer werdende Mail-Datenbanken. Hier soll eine Reduzierung der Größe durch die Auslagerung von E-Mails in das DMS erreicht werden. Ein weiterer Anwendungsbereich ist die Erfül-lung regulatorischer Anforderungen oder Minimierung von Geschäftsrisiken durch vollständige Archivierung des ein- und ausgehenden E-Mail-Verkehrs. Hierbei steht mehr der Gedanke der voll-ständigen Online-Sicherung der gesamten E-Mail-Kommunikation aus Gründen der Nachvollzieh-barkeit, und weniger die Optimierung der Mail-Systeme, im Vordergrund.

Wie bei anderen Server-Funktionen wird im Rahmen der Marktübersicht auch bezüglich der E-Mail-Archivierungskomponente zunächst abgefragt, für welche Serverplattformen das E-Mail-Archiv-system freigegeben ist. Der Anwender kann hieraus ableiten, welche Systemumgebung für den Betrieb der E-Mail-Archivierung bereitzustellen ist.

Im nächsten Abschnitt wird nach den im Produkt konfigurierbaren Regeln für die Archivierung von E-Mails gefragt. Im Rahmen dieser Marktübersicht wurden aus Platzgründen lediglich die grund-sätzlichen Varianten berücksichtigt (Journalarchivierung, Definition von Gruppen mit gemeinsamen Archivierungsregeln etc.) und weitere Einstellmöglichkeiten ausgelassen, die in der Praxis dennoch von Bedeutung sind.




Einige E-Mail-Systeme wie bspw. Novell GroupWise bieten im Gegensatz zu MS Exchange oder Lotus Domino im Standard keine eigene Journalfunktion. Um in einer solchen Umgebung eine voll-umfängliche Archivierung aller extern und intern kommunizierten E-Mails umzusetzen, muss sich das E-Mail-Archiv wie ein Gateway verhalten, welches den ein- und ausgehenden E-Mail-Verkehr getrennt vom E-Mail-System über das SMTP-Protokoll abgreift. In diesen Fällen ist das Verfahren zur Archivierung von Mail-System-intern ausgetauschten Nachrichten zu klären, die das Mail-System erst gar nicht verlassen.

Eine „Single Instance Storage“-Archivierung (SIS) vermeidet Mehrfachspeicherung von EMail-Objekten (insbesondere Dateianhängen) durch eine interne Prüfung auf Duplikate. Dies kann gerade bei umfangreichen Empfängerlisten einzelner E-Mails zu einer enormen Platzersparnis führen. Allerdings bieten auch verschiedene Archivspeichersysteme eigene SIS-Mechanismen an, die quasi konkurrierend zur SIS-Speicherung der E-Mail-Archivlösung nutzbar sind. Der Anwender sollte in solchen Konstellationen aufgrund individueller Kriterien wie Performance bei der Speiche-rung, Migrationsanforderungen, etc. entscheiden, auf welcher Ebene „Single Instance Storage“ angesiedelt sein sollte.

Das Regelwerk der Archivierung kann Objekt- und Zeitmerkmale berücksichtigen, die in den folgenden zwei Fragegruppen dargestellt werden. Objektmerkmale können einerseits die einzelne Mail betreffen und die Archivierung auslösen, wenn die Mail z.B. von definierten Absendern stammt, eine bestimmte Größe überschreitet oder definierte Betreff-Informationen enthält. Ande-rerseits können Objektmerkmale bspw. das Postfach des Empfängers betreffen und die Archivie-rung auslösen, wenn das Postfach eine bestimmte Größe überschreitet.

Bei den Zeitmerkmalen sind im Markt ebenfalls vielfältige Varianten anzutreffen. So fragen Anwender nach Archivierungsmöglichkeiten bspw. in Abhängigkeit vom Alter der Mail, vom letzten Zugriff auf die Mail sowie nach regelmäßigen Archivläufen gemäß Zeitplan.

Informationen zu Kombinationsmöglichkeiten, stufenweisen Verfahren, Differenzierungen und Ausnahmebehandlungen, die in der Praxis von Bedeutung sind, konnten aus Platzgründen leider nicht in die Übersicht aufgenommen werden.

Wie bei der Client-basierten E-Mail-Archivierung interessiert auch bei der System-getriebenen E-Mail-Archivierung das Speicherformat der E-Mail und seiner Anhänge im Archiv. Die Übersicht hat neben der Speicherung im Originalformat auch nach alternativen Möglichkeiten einer Formatkon-vertierung für E-Mail-Texte oder Anhänge gefragt. Hier sind grundsätzlich dieselben Konvertierungs-herausforderungen zu meistern, die bereits bei der Client-basierten E-Mail-Archivierung beschrieben wurden, allerdings kombiniert mit einer voraussichtlich höheren Datenmenge – bei der Planung einer automatischen Konvertierung im Rahmen der System-getriebenen E-Mail-Archi-vierung ist eine Abschätzung der benötigten Rechnerressourcen wichtig, da durch hohen Rechner-einsatz spürbare Betriebskosten entstehen können.

Hinzu kommen Performance-Herausforderungen, wenn die Anzahl der zu archivierenden E-Mails und Anhänge an Umfang zunehmen, was bei der System-getriebenen E-Mail-Archivierung erheblich häufiger anzutreffen ist als bei der Anwender-getriebenen E-Mail-Archivierung. Insofern sind noch strengere Betriebsanforderungen an die hier abgefragte Archivierungslösung zu stellen und viele Kunden entscheiden sich in diesem Umfeld aus nachvollziehbaren Gründen gegen eine Formatkon-vertierung, um die befürchteten Betriebsprobleme der Konvertierfunktion zu umgehen.

Gerade bei der regelbasierten Archivierung von E-Mails kann der Zustand eintreten, dass lediglich einige aber insbesondere nicht alle E-Mails von der Archivierung berücksichtigt werden und es stellt sich die Frage, wie der Anwender im Nachgang auf die archivierten E-Mails zugreifen kann. Von Anwendern werden häufig folgende Optionen als sinnvoll erachtet:

• Die archivierte E-Mail wird automatisch im E-Mail-System gelöscht und durch einen DMS-Link ersetzt, mit dem Vorteil einer Reduzierung des Speicherbedarfs in der E-Mail-Datenbank. Falls ein solcher Link aus dem E-Mail-System gelöscht wird, sollte eine Mail-System-unabhängige Recherchemöglichkeit vorhanden sein.

• Die archivierte E-Mail verbleibt im E-Mail-System und muss ggf. manuell oder automatisiert gelöscht werden, mit dem Vorteil einer direkten Bearbeitung und Weiterleitung insbesondere an externe Partner aus dem E-Mail-System.




Weiter wurde auch in diesem Kapitel nach den Zugriffsmöglichkeiten auf archivierte E-Mails gefragt. Je nach Anwendungsszenario kann eine langfristige Aufbewahrung von E-Mails notwendig und damit ein möglichst E-Mail-System-unabhängiger Zugriff auf archivierte E-Mails wichtig sein. Der Anbieter sollte zusätzlich angeben, ob eine Suche und Anzeige aus dem ursprünglichen E-Mail-Client oder, unabhängig davon, mit der genannten ECM-Komponente möglich ist. Auch die Suche über Metadaten und eine inhaltliche Suche (über den Volltext von Mail-Bodies und Anhängen) kann hier relevant sein.

Über die in diesem Kapitel abgefragten Funktionen hinaus gibt es oft weitere Anforderungen der Anwender, die in einer Lösung für E-Mail-Archivierung berücksichtigt werden müssen. Dazu gehören beispielsweise die Unterstützung von mobilen Anwendern im Offline-Modus, die typischer-weise den Inhalt ihrer persönlichen Postfächer regelmäßig auf das Mobilgerät replizieren. Bei einer Archivierung von E-Mails stehen mit Links versehene replizierte E-Mails oder Anhänge ohne Netz-werkverbindung dann plötzlich nicht mehr zur Verfügung.

Weitere relevante Anforderungen umfassen zusätzlich beispielsweise die Fähigkeiten zur Über-nahme bereits bestehender „persönlicher Mail-Archive“, Umsetzungsmöglichkeiten für Aufbewah-rungsfristen und Vernichtungszyklen etc.

Im Rahmen der Marktübersicht werden die Funktionalitäten der untersuchten DMS-Lösungen für die im Markt am weitesten verbreiteten Plattformen MS Exchange und IBM Lotus Domino jeweils separat und zusammenfassend für alle weiteren Systeme in dem Abschnitt „Sonstige E-Mail-Systeme“ dargestellt.

IV.10 Postkorb-Funktionen

Bei einer Vielzahl an Workflow-Projekten im DMS-Umfeld handelt es sich um die Umsetzung Doku-menten-zentrischer Prozesse mittels Software-Unterstützung. In Analogie zum traditionellen, Papier-basierten Sachbearbeitungsprozess, bei dem der Sachbearbeiter seine Vorgänge in Papier-form in seinem „Posteingangskorb“ erhält, wird diese Art der Projekte „Postkorb-Projekte“ genannt.

Das bedeutet, typischer Dreh- und Angelpunkt des Vorgangs sind Dokumente oder Dokument-ähnliche Arbeitsaufträge, die beispielsweise durch „frühes Scannen“ (= Scannen vor der Sachbe-arbeitung) entstehen und dem Sachbearbeiter oder einer Gruppe in einer Arbeitsliste (Synonyme sind beispielsweise Postkorb, Arbeitskorb, Arbeitsliste etc.) zur Abarbeitung zugestellt werden.

Die Zielszenarien solcher Postkorb-Anwendungen sind die hochrepetitiven Sachbearbeitungspro-zesse, bspw. die Antragsbearbeitung im Finanzdienstleistungssektor oder die Eingangsrechnungs-bearbeitung. Daher beziehen sich die in diesem Abschnitt abgefragten Informationen auf die für den Sachbearbeiter zur Verfügung stehenden Funktionen in seinem Postkorb-Client. Das ausschließliche Weiterleiten gescannter Dokumente zum Indexier-Arbeitsplatz innerhalb des Doku-menten-Capture-Prozesses ist hier nicht gemeint.

Die zentrale Frage zur Positionierung der Postkorb-Anwendungen lautet: Wie werden die Vorgänge im System gebildet? In der Praxis lässt sich die Vorgangsbildung typischerweise in drei Varianten unterscheiden:

Ein Dokument bildet immer einen Vorgang: Dies ist die einfachste Variante der Vorgangsbildung. Durch das Scannen oder den Import von Dokumenten wird zu jedem Dokument ein Vorgang im DMS erzeugt und verteilt.

Mehrere Dokumente können einen Vorgang bilden: In vielen Fällen besteht ein Vorgang aber aus mehreren Dokumenten (Kontoeröffnungsantrag + PostIdent-Formular etc.). Für diese Fälle ist es erforderlich, dass das System mehrere Dokumente zu einem Vorgang zusammenfassen und verteilen kann.

Vorgänge können OHNE Dokument erstellt werden: Häufig entstehen Arbeitsaufträge aus Hinter-grundsystemen, z.B. aus der zentralen Terminverwaltung einer führenden Anwendung. In diesen Fällen muss es im Postkorbsystem möglich sein, Vorgänge OHNE Dokumente anlegen zu können, um den Sachbearbeitern den im Hintergrund erzeugten Arbeitsauftrag zuleiten zu können.

Je weniger der Prozess an ein oder mehrere Dokumente gebunden ist, desto flexibler sind die Gestaltungsmöglichkeiten der Postkorb-Lösung.




Im folgenden Abschnitt zu diesem Funktionsblock sollten die Anbieter angeben, welche Postkorb-Basisfunktionen im System zur Verfügung stehen. An dieser Stelle muss explizit darauf hinge-wiesen werden, dass eine Anbieterauswahl oder eine funktionale Reihenfolge der Anbieter anhand dieser Angaben nicht vorgenommen werden kann. Um die Produkte objektiv bewerten zu können, müssen deutlich mehr funktionale Details aus den umzusetzenden Geschäftsprozessen abgefragt werden. Die hier gemachten Angaben sind aber als erste Vorsortierung der Anbieter und Produkte gut geeignet. So ist ersichtlich, welche Funktionsgruppen ein Anbieter mit seinem Produkt unter-stützt und welche nicht. Grundsätzlich kann sich ein potentieller Anwender somit die Anbieter heraussuchen, die jene Funktionsgruppen unterstützen, die er benötigt. Für die weitere Systemaus-wahl ist dann die eingangs beschriebene Detaillierung der Anforderungen erforderlich.

Einen weiteren wichtigen Fragenblock, der in der Praxis in den Projekten häufig unterschätzt wird, stellen die Fragen nach Funktionen und Werkzeugen zur Einrichtung der Verteilregeln dar.

Beim Customizing der Workflow-Systeme sind im Allgemeinen folgende Teilaufgaben zu erledigen:

• Erstellen des Prozesstemplates

• Einrichtung der Verteilungslogik

• Einrichtung der Client-Funktionen

• Realisierung der Integrationen in Hintergrundsysteme

Der Anwender sollte sich auf alle Fälle davor hüten, Demos mit grafisch gestalteten Oberflächen als Beweis dafür zu sehen, dass komplexe Workflows und Integrationsanforderungen alleine mit grafi-schen Modellierungswerkzeugen umgesetzt werden können. In der Praxis der Workflow-Projekte zeigt sich immer wieder, dass nur der geringere Anteil der Einrichtungsarbeiten mit den grafischen Editoren realisiert werden kann, der überwiegende Anteil sind Skript- und/oder Programmierar-beiten.

Das bedeutet aber auch, dass auch bei Verfügbarkeit grafischer Editoren die Einrichtung und Anpassung der Workflows weiterhin komplexe Aufgaben sind, für deren Bearbeitung der Überblick über den Gesamtprozess und die technischen Auswirkungen von Änderungen erforderlich ist. Somit sind diese Aufgaben typischerweise in der IT-Abteilung, oder bei Mitarbeitern mit IT-Ausbil-dung (bspw. IT-Koordinatoren in den Fachbereichen) angesiedelt.

In vielen Unternehmen besteht die Notwendigkeit schnell und unkompliziert auf Änderungen in den Organisationsstrukturen oder den Sachbearbeitungsprozessen zu reagieren. Beispielsweise tritt bei Sach-Versicherungen häufig am Jahresende eine massive Arbeitsspitze auf, da in dieser Zeit die Kündigungsfristen anstehen und die Versicherten ihre Versicherungsverträge ändern (Kündigung, Neuabschluss, Anpassung etc.). In dieser Phase benötigen die zuständigen Abteilungen in den Versicherungen deutlich mehr Personal, um die Lastspitzen abarbeiten zu können. Häufig wird hierbei auf Mitarbeiter aus anderen Abteilungen zurückgegriffen. Beim Einsatz einer elektroni-schen Postkorb-Anwendung besteht nun die Anforderung, dass für einen definierten Zeitraum andere Verteilungsregeln greifen müssen. Um diese einzurichten, darf aber kein mittelgroßes IT-Projekt erforderlich sein. Daher besteht in solchen Fällen die Anforderung, dass Mitarbeiter mit einfach zu bedienenden Werkzeugen die Verteilungsregeln schnell und unkompliziert anpassen können.

Aus diesen Gründen wird im Fragenkatalog nach den Werkzeugen zur Einrichtung und Anpassung der Prozesse und der Verteilregeln gefragt. Die gegebenen Antworten können auch hier nur eine erste Orientierung geben, ob die Werkzeuge den Anforderungen des jeweiligen Unternehmens genügen, muss im Einzelfall überprüft werden.

IV.11 Workflow / Business Process Management

Der Fokus dieser Marktübersicht liegt auf dem Thema Dokumenten Management. Es geht somit primär um Funktionen zur Verwaltung von Dokumenten und die Automation Dokumenten-zentri-scher Prozesse. Einige DMS-Lösungen am Markt bieten jedoch über die in anderen Abschnitten abgefragten Dokumenten-Automatismen und Postkorb-Funktionalitäten hinausgehende Workflow-Funktionen an.




Bei Workflow-Anwendungen mit Business Process Management (BPM)-Orientierung handelt es sich nach allgemeinem Marktverständnis um Anwendungen zur Modellierung und Automatisierung KOMPLETTER Geschäftsprozesse unter Einbeziehung anderer IT-Systeme und -Anwendungen. Das einen Geschäftsprozess (Workflow) auslösende Ereignis kann unabhängig von der Entstehung bzw. vom Eingang eines Dokumentes auftreten und z.B. durch eine Anwenderaktion in einem externen System definiert sein. Es ist eben nicht „nur“ die elektronische Verteilung eines Dokumentes zum zuständigen Sachbearbeiter, der dann aufgrund seiner Sachbearbeiter-Kompetenz die erforderli-chen Fachsysteme und, fallabhängig, die zur Sachbearbeitung erforderlichen Transaktionen aufruft.

Das hier besprochene Kapitel ist für diese Art von Workflow-Anwendungen vorgesehen. Da für BPM-orientierte Workflow-Anwendungen Dokumente nicht im Zentrum der Prozesse stehen, liegen die entscheidenden Funktionen und Eigenschaften der Systeme außerhalb des DMS-Fokus. Daher werden in dieser Marktübersicht grundlegende Fragen zu einer Workflowanwendung, die als BPM-Lösung positioniert wird, gestellt. Diese Informationen dienen zur Beantwortung einiger grundle-gender Fragen:

• Welche DMS verfügen über Workflow-Komponenten, die als BPM-Lösungen positioniert werden

• Unter welchen Systemvoraussetzungen sind diese Workflow-Anwendungen lauffähig

• Welche Möglichkeiten stehen zur Prozessmodellierung zur Verfügung

• Welche Beschreibungssprachen / Standards werden für den Austausch von Prozessdefiniti-onen unterstützt

Zum Thema unterstützte Beschreibungssprachen und Im- und Export von Prozessdefinitionen ist in der Praxis jedoch zu beachten, dass auch bei einer Unterstützung von XPDL, BPEL oder BPMN der „fertige“ Workflow nicht einfach in das Workflow-System importiert und dann der Produktionsbe-trieb gestartet werden kann. Durch den Import einer Prozessdefinition kann der Customizing- und Programmieraufwand im Workflow-System reduziert werden, es wird aber immer notwendig sein, die systemspezifischen Konfigurationen im System, entweder durch Customizing oder durch Programmierung, vorzunehmen.

Steht bei einer Produktauswahl das Thema BPM im Fokus, ist der Detaillierungsgrad dieses Kapi-tels nicht ausreichend. In einem solchen Fall müssen die BPM-spezifischen Anforderungen detail-liert aufgearbeitet und anhand dessen eine Produktvorauswahl vorgenommen werden.

IV.12 Collaboration-Funktionen

Unter dem Begriff Collaboration – bekannte Synonyme wären Teamarbeit oder (früher) Groupware – werden sehr unterschiedliche Funktionen subsummiert, die nicht immer etwas mit Dokumenten zu tun haben. Da aber bei zahlreichen dieser Funktionen Dokumente oder Dokument-basierte Prozesse eine Rolle spielen, enthalten viele Collaboration-Plattformen Funktionen, die man auch in einem klassischen DMS findet.

Im Rahmen dieser Marktuntersuchung sollen diejenigen Collaboration-Plattformen berücksichtigt werden, die umfassende Dokumentenverwaltungsfunktionen aufweisen. Plattformen, die keine solchen Dokument-bezogenen Funktionen aufweisen, wurden bei dieser Marktübersicht nicht berücksichtigt. Wer also eine Collaboration-Plattform mit DMS- und Online-Conferencing anbietet, konnte an der Marktübersicht teilnehmen und die Funktion Online-Conferencing auch entspre-chend darstellen. Anbieter, die beispielsweise NUR Online-Conferencing anbieten, aber keine Doku-mentenfunktionen, sind in der Marktübersicht nicht enthalten.

Mit anderen Worten: Collaboration-Lösungen im Sinne der vorliegenden Übersicht sollen Arbeits-gruppen bei der Dokumenten-zentrierten Zusammenarbeit helfen, die vor allem für Projektarbeit typisch ist.

Collaboration-Funktionen haben erst innerhalb der letzten Jahre Einzug in ECM-Lösungen gefunden – viele ECM-Lösungen besitzen auch heute noch keine Collaboration-Funktionalität, wie der Über-sicht zu entnehmen ist.




Da auch „Collaboration“ potenziell über Drittprodukte in das Lösungsportfolio einzelner Anbieter integriert sein kann, wird zunächst abgefragt, ob die dargestellte Funktionalität über eine eigen-ständige und ggf. fremde Komponente bereitgestellt wird oder ob sie in einer der bereits darge-stellten Komponenten enthalten ist.

Anschließend wird der Funktionsumfang der Collaboration-Lösung abgefragt:

• Virtuelle Projekträume bilden den fachlichen Rahmen und dienen der Abgrenzung unter-schiedlicher Collaboration-Umgebungen (z. B. Projekte); sie könnten als charakteristisch für Collaboration-Lösungen angesehen werden. Dennoch haben wir auch solche Lösungen unter der Überschrift „Collaboration“ zugelassen, die keine virtuellen Projekträume bieten, wenn wenigstens mehrere der nachfolgend abgefragten Anwendungsfunktionen im Produkt enthalten sind.

• Team-Kalender sind Gruppenkalender des Projektraums und fassen die aufgabenbezogenen Termine der Arbeitsgruppe und seiner Mitglieder zusammen bzw. stellen diese gemeinsam dar.

• Anzeige des Anwesenheit-Status erlaubt den Beteiligten, unmittelbar während der Arbeitssit-zung den direkten Kontakt, z.B. über Telefon oder Instant Messaging, mit dem Mitarbeiter aufzunehmen.

• Terminüberwachung dient – ähnlich einer Wiedervorlage – der Einhaltung von Terminen und der aktiven Benachrichtigung aus dem System, wenn Ergebnisse, die zu einem Termin vorliegen sollten, noch nicht eingetroffen sind.

• Kontaktverwaltung ermöglicht in der Regel die Pflege von Kontaktdaten der Personen, die für die Projektarbeit von Relevanz sind, ähnlich einem Adressbuch der Mail-Umgebung.

• White-Boards erlauben das gemeinsame, parallele Erstellen und Zusammentragen von Text auf einer einfachen, tafelähnlichen Umgebung. Aus Platzgründen konnten wir hier nicht tiefer gehend fragen – nach unserer Beobachtung bieten jedoch einige Systeme zusätzlich Frei-hand-Zeichenmöglichkeiten und vordefinierte grafische Objekte (z. B. Pfeile, Rechtecke, Kreise, etc.).

• Newsgroups/Diskussionen erlauben den fachbezogenen und geordneten Austausch von Informationen und Abstimmungen innerhalb der Projektgruppe an einer vordefinierten Stelle im System. Auch hier gibt es im Detail Unterschiede, die nicht mit in die Übersicht aufge-nommen werden konnten, wie zum Beispiel in der Darstellung von Diskussionsverläufen als flache oder geschachtelte Darstellung.

• Projektplanungswerkzeuge beinhalten z. B. Ressourcenverwaltung und -zuordnung, Defini-tion von Meilensteinen, kritische Pfad-Analyse oder Gantt-Diagramm-Darstellungen. Hersteller, die diese Funktion angekreuzt haben, mussten wenigstens eine der genannten Detailfunktionen unterstützen.

• Dokumentenablagen bilden das typische Bindeglied zwischen Collaboration-Lösungen und „klassischen“ DMS-Lösungen. Weiterführende Details konnten wir nicht abfragen, allerdings interessieren in vielen Kundenumgebungen Versionierungsmöglichkeiten, Abstimmungs- und Freizeichnungsabläufe sowie eine möglichst freie Gestaltung der Verschlagwortungsmöglich-keiten.

• Wiki-Anwendungen bieten die Möglichkeit, weitestgehend ungeführt ein Projekt-, Abteilungs-, Unternehmens- oder ein sonstiges Glossar aufzubauen; die weltweit erfolgreichste Wiki-Anwendung ist derzeit die in der Wikipedia zusammengefasste, freie Online-Enzyklopädie.

• Blog-Anwendungen erlauben das Erstellen und Verwalten sog. Web-Logs (Online-Tagebü-cher), in denen Autoren Onlineberichte verfassen können, die von Lesern typischerweise kommentiert und teilweise auch bewertet werden können.

Dokumente stehen in vielfältiger Beziehung zu den obigen Collaboration-Funktionen. Deshalb fragten wir im darauf folgenden Block nach den Möglichkeiten, Dokumente an die genannten Colla-boration-Objekttypen anzuhängen. So könnten zum Beispiel an einem Termineintrag im Team-Kalender die Einladung, die Agenda und auch das Ergebnisprotokoll jeweils als eigenständige Dokumente einer Projektbesprechung angehängt sein.




Ausgehend von den in der Übersicht gemachten Angaben sollten Anwender bei der Auswahl einer Collaboration-Lösung prüfen, wie gut und geordnet abgelegte Dokumente wieder aufgefunden werden können und ob insbesondere ein Mehrfachzugang zu den Dokumenten möglich ist (z. B. sowohl über die Dokumentenablage als auch über den Termin sowie über die Teilnehmer des Termins und den Autor).

Allein die Auflistung der für Collaboration-Lösungen typischen Funktionsbereiche verdeutlicht die möglichen Überschneidungen von Collaboration- und E-Mail-Lösungen. Um die Notwendigkeit zur mehrfachen Pflege von Kontaktdaten oder Terminen zu vermeiden, fragen Anwender immer häufiger nach Synchronisierungsfunktionen; Diese Fragestellung haben wir in die Marktübersicht für die „gängigen“ Mail-Systeme MS Exchange und Lotus Notes aufgenommen. Für eine detaillierte Darstellung der Synchronisierungsfunktionen, etwa dem Umgang mit Synchronisierungskonflikten, bietet die Übersicht leider nicht ausreichend Platz. Diese Fragestellungen sind daher im konkreten Auswahlprozess zu klären.

Gerade im Rahmen der Projektarbeit ist es ein häufig geäußerter Anwenderwunsch, vom System aktiv auf Veränderungen der Projektdokumentation hingewiesen zu werden. Hierdurch lässt sich bereits durch die Bereitstellung einer veränderten Dokumentenversion die Aufforderung zur Prüfung, Freigabe etc. formulieren, ohne hierfür eine zusätzliche Kommunikation, z.B. per E-Mail aufnehmen zu müssen. Zugleich bedient diese Funktion den Wunsch der Projektmitarbeiter, schnell und einfach auf „alles Neue“ im Projekt hingewiesen zu werden.

IV.13 Signatur-Funktionen

Signaturfunktionen bieten Möglichkeiten, elektronische Unterschriften verschiedener Art und Qualität in einer DMS-Umgebung nutzen zu können. Eine elektronische Unterschrift kann hierbei technisch unterschiedlich ausgeprägt sein. Ein grafisches Bild einer gescannten Unterschrift kann für den Anwender ebenso eine Unterschrift darstellen wie für andere ein Login mit Passwort oder die Unterzeichnung auf einem Unterschriftenpad. Diese so genannten einfachen elektronischen Signaturen stehen jedoch nicht im Fokus der Marktübersicht. Abgefragt werden hier die Möglich-keiten, Dokumente mit kryptografisch erzeugten Signaturen zu erzeugen oder zu verifizieren, weil dies in manchen Branchen für bestimmte Dokumentarten und Geschäftsprozesse vorgeschrieben ist.

In Deutschland ist im Bürgerlichen Gesetzbuch, im Signaturgesetz und in der Signaturverordnung geregelt, welche Arten von Unterschriften nicht nur einfach eine Authentifizierungsbehauptung darstellen („Mit freundlichen Grüßen: Micky Maus“), sondern auch absichern, dass sie der eigen-händigen Unterschrift gleichkommen und damit bei jenen Vorgängen, in denen die so genannte Schriftform gefordert ist, die eigenhändige Unterschrift ersetzen können. In Deutschland ist dies nur mit der sogenannten qualifizierten elektronischen Signatur (QES) gemäß Signaturgesetz möglich. Alle anderen elektronischen Varianten der Authentifizierung können in einer DMS-Umge-bung aber ebenfalls von Interesse sein, beispielsweise zum Benutzernachweis im Rahmen von elektronischen Freigabeprozessen. Hier muss nicht immer mit der qualifizierten elektronischen Signatur gearbeitet werden. In der Praxis kommt diesem „normalen“ Authentifizierungsprozess sogar eine weitaus größere Bedeutung zu. Die Authentifizierung (der Benutzer ist tatsächlich derje-nige, der er behauptet zu sein) mit Benutzername und Passwort in jeder ERP-Anwendung ist gang und gäbe und offensichtlich ausreichend vertrauenswürdig für Buchungs-, Freigabe- und Genehmi-gungsverfahren aller Art.

Es gibt aber Anwendungsbereiche, in denen eine qualifizierte elektronische Signatur (QES) vorge-schrieben ist. So gibt es eine gesetzliche Regelung für Unternehmen, die dem Sozialversicherungs-recht unterliegen, dass bei der Papiererfassung die Rechnungswesen-relevanten Dokumente mit der qualifizierten elektronischen Signatur zu versehen sind, wenn die Originaldokumente vernichtet werden sollen. Hier wird der eigentlich sinnvolle Ansatz einer elektronischen Unterschrift für den Scan-Prozess zweckentfremdet. Es unterschreibt hier nicht etwas der Ersteller der Dokumente, sondern Mitarbeiter der Erfassungs-Stelle. Veränderungen an diesen Dokumenten können zwar nachgewiesen werden, aber ohne geeignete Systemumgebung ist ein Löschen von signierten Doku-menten trotzdem möglich.

Für elektronische Rechnungen wurden mit dem Steueränderungsgesetz 2010 neben der qualifi-zierten elektronischen Signatur auch beliebige andere elektronische Formate zugelassen, so dass hier die QES nur noch eine von mehreren Handlungsoptionen ist.




Für DMS-Systeme gibt es somit an unterschiedlichen Stellen Ansatzpunkte für die Nutzung elektro-nischer Signaturfunktionen. Unterstützt werden sollen möglichst viele Varianten, in jedem Fall aber auch die qualifizierte elektronische Signatur gemäß dem Signaturgesetz. Ist diese nicht erforder-lich, sind auch einfachere Unterschiften, die nach der gesetzlichen Definition als einfache oder fort-geschrittene Signatur bezeichnet werden, zulässig. Ein Zeitstempel ist hierbei keine elektronische Willensäußerung einer Person, aber ein technischer Mechanismus, um Tag und Uhrzeit fest mit einem elektronischen Objekt zu verbinden. Die Schutzmechanismen des Verfahrens zur elektroni-schen Signatur kommen hierbei ebenfalls zum Einsatz, so dass Änderungen bei Dokumenten, die mit einem Zeitstempel versehen sind, nachvollziehbar sind. Je nach Anforderung muss es also in DMS-Umgebungen möglich sein, unterschiedliche Signaturverfahren auch in Kombination mitein-ander einsetzen zu können.

Da Unterlagen auf verschiedenen Wegen in ein DMS gelangen, muss geprüft werden, an welchen Stellen und in welchem Prozess eine Signaturfunktion gefordert ist. Die Scan-Anwendung sollte Signaturen im Rahmen der Papiererfassung erzeugen können. Wenn intern elektronische Willens-erklärungen erstellt, verschickt und archiviert werden sollen (Bsp. E-Mail), kann auch hier die Nutzung einer elektronischen Unterschrift sinnvoll sein. Im Rahmen von Freigabe- oder Workflow-Prozessen soll die elektronische Unterschrift als Nachweis (Wann und durch wen?) genutzt werden können. Aber auch der Archivserver, der für die Langzeitarchivierung der Dokumente zuständig ist, könnte dabei auf Teilfunktionen von Signaturkomponenten zurückgreifen, im Wesentlichen die Integritätsschutzfunktionen durch Berechnung von Inhaltswerten (sogenannte Hashwerte). Darüber hinaus kommen natürlich Dokumente von Dritten hinzu, die bereits eine Signatur besitzen und in einer DMS-Umgebung verwaltet werden sollen. Signatur¬informationen sollten im DMS-Client angezeigt und die Signatur selbst verifiziert werden können. Dies kann je nach Anforderung manuell oder automatisch erfolgen. Die Ergebnisse dieser Prüfung sollen in Prüfprotokollen doku-mentiert werden.

Die qualifizierte elektronische Signatur kann ein eigenständiges technisches Objekt sein, sie kann aber auch in Formate eingebettet werden, wenn diese so etwas zulassen (Bsp. PDF oder XML). Wenn eigenständige Objekte für die Signatur archiviert werden müssen, ist vom DMS-System sicherzustellen, dass die Verknüpfung zum signierten Objekt dauerhaft ist.

Qualifizierte elektronische Signaturen nach dem Signaturgesetz kann man nicht selbst erstellen, man benötigt hierfür eine im Gesetz definierte Stelle, das sogenannte Trust-Center, welches für die Erstellung der notwendigen Schlüssel und zeitlich begrenzt gültigen Zertifikate zuständig ist. Trust-Center stellen dem Anwender Chipkarten mit entsprechenden eingebetteten Schlüsseln und Zerti-fikaten zur Verfügung und geben in öffentlichen Verzeichnissen aktuelle Auskunft darüber, dass man eine Unterschrift besitzt.

Diese Information ist dann für die Prüfung einer Signatur erforderlich, um die Information zu erhalten, ob die Unterschrift der Person entspricht, die elektronisch unterschrieben hat und ob diese Unterschrift auch noch gültig ist. Das sogenannte Zertifikat, welches diese Informationen enthält, kann auch innerhalb der DMS-Anwendung gespeichert werden, so dass nicht bei jeder Einzelprüfung ein Zugriff auf das öffentliche Verzeichnis erforderlich ist. Auch erstellen Trust-Center sogenannte Sperrlisten (revocation list) für nicht mehr gültige elektronische Unterschriften, die ebenfalls redundant in einer DMS-Umgebung gehalten werden können.

Für die Sicherstellung der Langzeitgültigkeit von qualifizierten Signaturen sieht die Deutsche Signa-turverordnung das sogenannte Nachsignieren vor, bei dem alle signierten Objekte, die im Laufe der Zeit als technisch unsicher gelten, mit einer neuen technisch sichereren Unterschrift versehen werden müssen. Diese technischen Nachsignier-Funktionen sind bei einem DMS-System typischer-weise beim DMS-Server oder einem nachgelagerten Signaturserver angesiedelt. Damit nicht Milli-onen von Objekten einzeln neu unterschrieben werden müssen, hat ein vom Bund gefördertes Projekt ein technisches Verfahren definiert (sog. Signieren von Hash-Bäumen nach ArchiSig), mit dem die Anzahl an erforderlichen Nachsignaturen reduziert werden kann. Auch hierbei handelt es sich um eine serverbasierte Funktionalität.

IV.14 Standards und Zertifikate

Im DMS- und Archivmarkt gab und gibt es seit vielen Jahren den Wunsch nach Standardisierung auf unterschiedlichen technischen und funktionalen Ebenen in der Hoffnung, hierdurch mehr Anbiete-runabhängigkeit, Vergleichbarkeit und Verlässlichkeit bei der Konformität mit regulatorischen




Anforderungen zu erreichen. Historisch haben sich aber nur sehr wenige ECM-Standards durchge-setzt, viele Spezifikationen sind gescheitert und haben außer Aufwand nichts gebracht. Internatio-nale Negativbeispiele sind DMA, ODMA, Moreq (alle drei Versionen), WfMC und viele mehr. Aber auch auf nationaler Ebene wurden immer mal wieder Spezifikationen veröffentlicht, die dann nur ein Nischendasein fristeten, wenn sie denn überhaupt überlebten, wie z.B. DOMEA in Deutschland.

Die Ursachen für das Scheitern lagen häufig am mangelnden Interesse der Anbieter und Anwender, diese Spezifikation in die Produkte einzubauen (Anbieter) oder nachzufragen (Anwender). Mangelnde Nachfrage ist nach unserer Meinung auch ein sicheres Indiz dafür, dass viele dieser Spezifikationen keine betriebswirtschaftlich sinnvolle Problemlösung für eine ausreichend große Anwenderzahl dargestellt haben; mit anderen Worten: Die Aufwendungen für die Implementierung und Pflege des Standards auf Anwenderseite stehen nicht in einem attraktiven Verhältnis zum Nutzen.

Trotz dieser kritischen Betrachtung zu so genannten ECM-Standards gibt es einige Spezifikationen bzgl. Integration und Interoperabilität, die man im Projekteinzelfall in Betracht ziehen sollte. Diese Spezifikationen haben wir im Fragenkatalog abgefragt. Damit ist aber nicht gesagt, dass diese Spezifikationen immer für alle Anwender nützlich sind. Dementsprechend sollten die Anwender die Relevanz dieser Spezifikationen für die eigene Umgebung selbst einschätzen und einen Anbieter nicht wegen der mangelnden Unterstützung eines ECM-Standards abwählen, der für den Anwender aber gar keine praktische Bedeutung hat.

• CMIS steht für Content-Management-Interoperability-Services und ist ein im Mai 2010 veröf-fentlichter OASIS-Standard für die Integration von proprietären Content Management Systemen. CMIS erlaubt die Entwicklung von Anwendungen, die mit unterschiedlichen (CMIS-kompatiblen) Content Management Systemen zusammenarbeiten können. Lösungen, die vorhandene CMIS-kompatible Content Management Lösungen ergänzen, können mit relativ wenig Aufwand auch für andere CMIS-Lösungen adaptiert werden. Darüber hinaus können Client-Anwendungen entwickelt werden, die eine konsolidierte Front-End Sicht auf mehrere Content Management Systeme verschiedener Anbieter implementieren (Federation). Derzeit (Stand: August 2012) wird CMIS zwar von über 50 Anbietern formal unterstützt, ist aber derzeit noch in relativ wenigen Projekten praktisch umgesetzt. Dies kann sich ändern, da CMIS im Unterschied zu anderen derartigen Interoperabilitätsstandards wie DMA, ODMA oder aus JSR (siehe unten) plattformneutral ist und keine spezifische Implementierungstechnologie voraus-setzt.

• JSR-283 (JCR 2.0) spezifiziert eine Standard-API für den Zugriff auf Java Plattform EE (ehemals J2EE) Repositories – unabhängig von der Implementierung. Ziel ist die Ablösung der proprietären Repository-APIs verschiedener Hersteller. Dadurch soll insbesondere in großen Unternehmen mit unterschiedlichen Content Repositories langfristig eine vereinfachte Content-Integration ermöglicht werden. Die Java Content Repository-API soll auf unterschied-liche Content-Systeme zugreifen können, ohne die jeweiligen, herstellerspezifischen Funkti-onsaufrufe kennen zu müssen. Mit den Vorläuferversionen JSR 170 (veröffentlich im Juni 2005) ist diese Idee mittlerweile über 7 Jahre alt und hat nur begrenzte Verbreitung gefunden. Für Java-affine Anwender stellt JSR 283 aber ein mächtiges Funktionsset zur Integration unterschiedlicher Repositories zur Verfügung. Der Anwender sollte dann aber sicherstellen, dass der DMS-Hersteller diese Schnittstelle auch in zukünftigen Versionen seiner Lösung unterstützt.

• WebDAV steht für „Web Distributed Authoring und Versioning“. Es ermöglicht einem Web-Client das Schreiben von Dateien auf einen Web-Server über das normale http-Protokoll, das zu diesem Zweck erweitert wurde. Für den Endanwender stellt sich WebDAV als gewohnt hier-archisches Dateisystem dar, in das man einfach per „Drag & Drop“ oder „Speichern unter…“ Dateien ablegen kann. So einfach und attraktiv dies klingt, hat es aber auch erhebliche Nach-teile. Beispielsweise werden bei der Dokumentenablage Pflichtattribute nicht abgefragt, weil die Dateien unter Umgehung der Datenbank-Anwendung abgelegt werden können. In vielen Projekten empfehlen wir daher explizit nicht die Nutzung der WebDAV-Ablagen, so intuitiv dies für den Endanwender auch sein mag.




• CIFS – Der Begriff Common Internet File System (kurz CIFS) wurde 1996 von Microsoft einge-führt und beschreibt eine erweiterte Version von SMB (Server Message Block), eines Kommu-nikationsprotokolls u.a. für LAN-basierte Druck- und Dateiablagedienste. ECM-/DMS-Lösungen, die eine CIFS-Schnittstelle für die Übergabe unterstützen, bieten – vergleichbar mit o.a. WebDAV – eine generische Schreibmöglichkeit auf das Repository. Aber wie bei WebDAV auch muss man hier beachten, dass hierbei keine nicht-hierarchische Attribuierung möglich ist. Ist dies aber notwendig (zum Beispiel weil Dokumente mit unterschiedlichen Attributen versehen werden müssen und nicht einfach nur in einem „Baum“ abgelegt werden können), genügt CIFS als Schreibweg alleine nicht.

Neben diesen technischen Spezifikationen gibt es in jedem Land eine Reihe von Regularien, die beim Einsatz einer DMS-/Archivlösung zu berücksichtigen sind. Diese können branchenunab-hängig sein, wie die Vorschriften zur ordnungsgemäßen Aufbewahrung nach deutschem Steuer- und Handelsrecht oder branchenspezifisch, wie die spezifischen Regelungen zum ersetzenden Scannen im Sozialversicherungsrecht. Neben solchen regulatorischen Anforderungen gibt es eine Reihe von vertikalen Anforderungen in den unterschiedlichen Branchen, wie z.B. die in der Pharma-Branche u.U. relevanten Anforderungen nach FDA 21 CFR Part 11. Alle diese Anforderungen haben wir nicht systematisch in die Übersicht aufgenommen. Die Anbieter konnten aber die Konformität ihrer Produkte zu solchen branchenspezifischen Anforderungen in diesem Fragenabschnitt darstellen. Für den Anwender ist wichtig zu erkennen, dass viele dieser Konformitätsaussagen lediglich „behauptete“ Konformitätserklärungen sind, weil häufig eine neutrale dritte Prüfinstanz und messbare Prüfkriterien fehlen. Es gibt keine „Ordnungsmäßigkeits-Hauptuntersuchung“, die unabhängig davon, ob DEKRA oder TÜV die Messung vornehmen, zum gleichen Ergebnis kommt. Es fehlen die technisch-messbaren Kriterien bei Aspekten wie Sorgfalt, Ordnungsmäßigkeit, „Handeln nach besten kaufmännischen Grundsätzen“, die eine einfache, nachvollziehbare Bewer-tung erlauben. Daher beauftragen manche Anwender und Hersteller – legitimerweise – sachver-ständige Dritte (Wirtschaftsprüfer, Berater, Steuerberater etc.) mit der Aufgabe, das System oder die Anwendungsverfahren zu prüfen. Eine Garantie für die Ordnungsmäßigkeit stellt dies aber nicht dar, da diese in der täglichen praktischen Anwendung entsteht und nicht statisch zum Zeitpunkt der Inbetriebnahme für alle Zukunft.

Es gilt daher in der konkreten Produktauswahlsituation zu klären, welche Spezifikationen oder Standards im Rahmen einer ECM-Einführung im jeweiligen Einzelfall wirklich erforderlich sind und welche davon zu konkreten Anforderungen an die Funktionalität des einzusetzenden ECM-Produkts führen. Nur diese Standards sollten dann bei einer Produktauswahl berücksichtigt werden.

IV.15 Schnittstellen zu SAP

Im Gegensatz zu vielen anderen ERP-Anwendungen stellt SAP zur Anbindung von DMS-Lösungen standardisierte und zertifizierbare Schnittstellen zur Verfügung. Als „zertifiziert“ gelten für alle in diesem Kapitel abgefragten Schnittstellen lediglich solche Lösungen, für die die SAP AG ein entsprechendes Zertifikat ausgestellt hat.

Die für SAP-Anwender wichtigste und am häufigsten genutzte Integration von Dokumenten in die SAP NetWeaver-Plattform ist die SAP ArchiveLink-Schnittstelle mit vordefinierten Erfassungsszena-rien. Darüber können nicht nur in SAP erzeugte ausgehende Dokumente wie Bestellungen, Rech-nungen etc., sondern auch Dokumente aus externen Quellen mit SAP-Objekten verknüpft werden. Über die generischen Objektdienste (GOS) kann der Anwender die Anzeige dieser Dokumente direkt aus der entsprechenden SAP-Transaktion aufrufen.

Die ArchiveLink-Schnittstelle wurde bereits in unterschiedlichen Versionen zur Zertifizierung ange-boten. Anwender interessiert typischerweise die Unterstützung von DMS-Lösungen für die aktu-ellste Schnittstellenversion BC-AL 6.20. Darüber hinaus sollte man auf eine dauerhafte Pflege und ggf. Nachzertifizierung der Integration durch den Anbieter gemäß SAP-Vorgaben achten.

Wie bei anderen Server-Funktionen wird auch im Rahmen dieses Kapitels abgefragt, für welche Serverplattformen die Archivierungskomponente für die ArchiveLink-Schnittstelle freigegeben ist. Der Anwender kann hieraus den Bedarf an notwendiger Hard- und Software für die Umsetzung einer ArchiveLink-Integration erkennen.




SAP-Anwender mit einem sehr hohen Dokumentvolumen bei der Archivierung wünschen sich Sicherheit, dass eine DMS-Lösung für die zu erwartenden Belastungen geeignet ist. SAP bietet in diesem Zusammenhang für DMS-Anbieter eine zusätzliche, freiwillige sog. „Performance-Zertifizie-rung“ (AL-LOAD) der ArchiveLink-Integration an.

Die durchgeführten Messungen und Ergebnisse liefern nach unserer Beobachtung aber nur ein eingeschränktes Bild von den Möglichkeiten und Grenzen der getesteten Produktangebote. Die Testergebnisse können als erste Orientierung verwendet werden, sollten aber nicht als alleinige Auswahlentscheidung für ein DMS dienen.

Im Rahmen seines ILM-Konzepts (Information Lifecycle Management) ermöglicht SAP seinen Kunden alternativ zur Datenarchivierung über ADK (Archive Development Kit), die Anwendungs-daten in einem XML-Format über die BC-ILM 3.0-Schnittstelle (WebDAV-Protokoll) in einem externen Speichersystem zu archivieren. Auf diese Daten kann später sowohl aus SAP als auch unabhängig von SAP zugegriffen werden. Für die Archivierung von Dokumenten wird weiterhin die ArchiveLink-Schnittstelle verwendet. Neben DMS-Herstellern haben sich auch einige Hersteller von Archivspei-chern für diese Schnittstelle zertifizieren lassen.

Viele SAP-Anwender benötigen alternativ oder als Ergänzung zum SAP-Standard einen Zugriff auf Dokumente auch für Nicht-SAP-Anwender. Ein Zugriff auf SAP-verknüpfte Dokumente außerhalb von SAP-Anwendungen ist im ArchiveLink-Konzept aber nicht vorgesehen. Aus Platzgründen haben wir die DMS-Anbieter nur nach der grundsätzlichen Verfügbarkeit von Standard-Komponenten gefragt, welche diese Funktion zur Verfügung stellen. Wichtige Detailfunktionen der Produkte, wie bspw. Konfigurierbarkeit des Datenaustauschs, Vollständigkeitskontrolle und Fehlerbehandlung bei der Übertragung etc., sollten bei der Auswahl untersucht werden.

Im SAP-Standard werden ArchiveLink-verknüpfte Dokumente nur als Trefferliste von sogenannten „Anlagen zum Objekt“ über die generischen Objektdienste zur Recherche und Anzeige zur Verfü-gung gestellt. Eine Aktensicht auf Dokumente, ist nicht vorgesehen.

In vielen Anwendungsszenarien ist es jedoch sinnvoll und gewünscht, dass die Sachbearbeiter einen direkten Zugriff beispielweise auf eine elektronische Personalakte oder Vertragsakte, aus der SAP-Anwendung verfügbar haben.

Daher konnten die Anbieter hier zu verfügbaren Template-Lösungen Angaben machen. Die Unter-schiede zeigen sich vor allem in der für die Umsetzung der Akten verwendeten Technologie und damit verbundenen Integrationstiefe. Der Anwender sollte bei einer solchen Integration immer darauf achten, dass sich die in SAP vergebenen Berechtigungen synchron zu den DMS-Berechti-gungen verhalten, um unberechtigte Zugriffe auf Dokumente außerhalb von SAP zu vermeiden.

Unternehmen mit Anforderungen an die Integration eines DMS in SAP, sollten nicht ausschließlich nach zertifizierten Schnittstellen entscheiden. Trotz Zertifikaten für gleichartige Funktionen ergeben sich deutliche architektonische und administrative Unterschiede der angebotenen Lösungen. Darüber hinaus empfiehlt es sich potentielle Produkte auch im Hinblick auf funktionale Anforderungen zur Nutzung außerhalb der SAP-Welt zu prüfen.

IV.16 Schnittstellen zu weiteren führenden Anwendungen (z.B. ERP)

Was in vielen Ausschreibungen leider viel zu oberflächlich als „Integration“ mit anderen Fach-wendungen abgefragt wird, bedeutet in fast allen DMS-Projekten die Verknüpfung von einer oder mehreren Fachapplikationen mit den Erfassungs-, Recherche- und Verwaltungsfunktionen einer DMS-Lösung. Verknüpfung heißt konkret:

• Ein der Fachanwendung eigentlich fremdes Objekt (ein gescanntes Dokument, eine an den Kunden verschickte E-Mail) soll allen beteiligten Systemen so bekannt gemacht werden, dass dieses Objekt aus dem Kontext der Fachanwendung recherchiert werden kann.

• Dokumente, die in der Fachanwendung erzeugt werden, sollen nicht in der Fachanwendung selbst, sondern in einem DMS, mit den dort verfügbaren Funktionen zur Archivierung und Fris-tenverwaltung, aufbewahrt werden. Auch auf diese Unterlagen soll aus den Fachanwen-dungen oder aus anderen Anwendungen zugegriffen werden können.

Was trivial klingt, kann in der Praxis zu erheblichen Problemen führen, aufgrund der Vielfalt der involvierten Anwendungen, komplizierter Berechtigungsregeln und den beschränkten technischen Möglichkeiten, eine solche Integration zu implementieren.




Generell kann man folgende Varianten unterscheiden:

• Der Hersteller der Fachanwendung stellt selbst eine dauerhaft gepflegte, über die verschie-denen Major und Minor Releases stabile Verknüpfungsschnittstelle zur Verfügung, die in der Regel so konzipiert ist, dass sie kein bestimmtes DMS voraussetzt, sondern grundsätzlich von allen DMS-Herstellern mit ihren Werkzeugen bedient werden kann, sofern diese den Aufwand und den Wettbewerb nicht scheuen. Gegenüber einem DMS sieht die Aufruffunktion daher immer gleich aus. Das bekannteste Beispiel für eine solche vereinheitlichte DMS-System-unabhängige Integrationsschnittstelle ist zweifellos SAPs ArchiveLink. Sehr häufig ist die Funk-tionalität durch Werkzeuge auf Seiten der Fach- aber auch der DMS-Anwendung noch erwei-terbar.

• Der Hersteller der DMS-Software oder ein Integrator stellt eine solche Verknüpfungsschnitt-stelle für externe Fachanwendungen zur Verfügung. Das wird der DMS-Hersteller bzw. Inte-grator aber nur für relativ weit verbreitete Fachanwendungen tun, die ihm einen ausreichend großen Absatz versprechen, um in Entwicklung und vor allem dauerhafte Pflege der Schnitt-stelle investieren zu können. Daher ist der Anwender hier gefordert, beim Schnittstellenher-steller nachzuhaken, wie erfolgreich diese Schnittstelle vermarktet ist. Es hilft ja nicht, wenn der DMS-Hersteller eine solche Schnittstelle für die Finanzbuchhaltung XYZ entwickelt hat, dann aber der Vertriebserfolg dieser Schnittstelle ausbleibt, sodass sich eine ständige Pflege nicht rentiert und der Anwender irgendwann eine nicht mehr Release-fähige Alt-Implementie-rung betreibt, die mit der neuen Version seiner Finanzbuchhaltung nicht mehr zusammenar-beitet. Auch bei dieser Variante der Schnittstelle sollte man auf die Erweiterbarkeit der Schnitt-stelle für zukünftige Anwendungszwecke achten, ohne die Release-Fähigkeit der Implementierung zu beeinträchtigen.

• Häufig findet man auch individuelle Projektlösungen. Diese können – im Unterschied zu manchen Standardlösungen – auch sehr individuelle Probleme des Anwenders lösen. Man sollte aber gerade hier auf die dauerhafte Release-Fähigkeit achten, also fragen, wie verhin-dert werden kann, dass nach Minor- und Major-Release-Upgrades der Fachanwendung und/oder der DMS-Anwendung ein hoher Aufwand zur Anpassung oder gar Neuentwicklung der Integrationsschnittstelle entsteht. Wie bei den Standard-Integrationsschnittstellen gilt auch für eine Individualentwicklung, dass die Rahmenbedingungen nicht statisch sind: Dokument-arten, Prozessvarianten etc. können sich ändern und können daher die Ausgestaltung der Schnitt-stelle ändern. Daher sollte auch hier der Anwender dringend darauf achten, dass nicht nur seine Anforderungen zum Zeitpunkt der Einführung abgedeckt werden, sondern auch auf die Werkzeuge zum Anpassen der Implementierung an zukünftige Änderungen zur Verfügung stehen.

Der Fragenabschnitt in der Marktübersicht enthält Fragen, die man mindestens an den Anbieter stellen sollte. Diese Fragen betreffen die typischen Verknüpfungsszenarien:

• Verknüpfungsschnittstelle für eingehende Papierdokumente. Die DMS-Hersteller bieten für unterschiedliche marktgängige Fachanwendungen Verknüpfungsschnittstellen an, die je nach Implementierung, für die typischen Szenarien „vor“, „während“ oder „nach der Sachbearbei-tung“ zur Verfügung gestellt werden. Werden Dokumente – wie zum Beispiel eingehende Papierdokumente – vor der Sachbearbeitung gescannt, müssen sie entweder in einen DMS-Postkorb oder sogar in einen Postkorb der führenden Anwendung – falls vorhanden – weiter-geleitet werden. Verknüpfungen nach der Sachbearbeitung werden häufig mit Hilfe von Barcodes oder anderen temporär Papier-behafteten Kennzeichnungen implementiert. Hierbei ist neben der eigentlichen Verknüpfung auch wichtig festzulegen, wie Fehlersituationen verwaltet werden (zum Beispiel, wenn Dokumente, die im führenden System bereits vorge-merkt sind, nicht eingescannt werden, weil sie auf dem Weg zum Scanner verloren gehen oder den falschen Dokumenten zugeordnet werden).

• Verknüpfungsschnittstelle für ein- und ausgehende E-Mails, sofern diese einen Bezug zu einer Fachanwendung haben: Hierbei spielen mindestens drei Systeme eine Rolle: die E-Mail, die Fachanwendung und das DMS. Die E-Mail muss aus dem E-Mail-System dem DMS übergeben werden und der Link zum DMS der Fachanwendung (und ggf. auch dem E-Mail System) über-geben werden, damit aus der Fachanwendung ein Zugriff auf die vorgangsrelevanten Unter-lagen erfolgen kann.




• Verknüpfungsschnittstelle für PC-Dateien, wenn in diesen Unterlagen mit Bezug zu Fachan-wendungen erstellt werden. Auch hier sind eigentlich drei „Systeme“ involviert. Die Doku-menten-Erstellungswerkzeuge auf dem PC (also z.B. MS Office, Open Office, AutoCAD etc.), die Fachanwendung und das DMS. Die Grundsätze sind die gleichen wie bei der E-Mail-Integra-tion: System 1 (Bsp.: MS Word) erzeugt das Dokumente, das DMS nimmt entgegen, erzeugt eine Content-ID, diese wird dem (oder den) Fachanwendung(en) übergeben, zusammen mit Attributen, die den fachlichen Kontext definieren, um später einfach auf das Dokument zugreifen zu können.

Der Anbieter konnte hier für einige am Markt verbreitete Anwendungen (oder unter „weitere …“) entsprechende Angaben machen. Die entsprechenden Angaben in dieser Übersicht können für den Anwender nur ein erstes Indiz darstellen, dass der Hersteller für die jeweiligen benannten Fachan-wendungen überhaupt Integrationskomponenten entwickelt hat. Welche Funktionalität diese im Detail aufweisen, ob die Schnittstellen die eingesetzten Produktversionen unterstützen und wie diese den individuellen Anforderungen entsprechend erweitert und angepasst werden können, muss bei Bedarf im Projekt individuell geklärt werden.

Mit dem Begriff Integration ist aber nicht immer nur die Verknüpfung für ein- und ausgehende Doku-mente gemeint. Häufig müssen auch die Aspekte wie Single-System-Login, Integration der Zugriffs-rechtesysteme, Transaktionssicherheit bei synchroner oder asynchroner Übertragung zwischen zwei oder mehreren beteiligten System geklärt werden. Ebenso ausgelassen wurden Fragen zur Zugriffstechnologie auf das DMS (Bsp.: Rich-Client API oder Webservices?), Integration von Scan- und Postkorb-Anwendungen, programmierte Steuerung von Anlegen oder Löschen von Objekten. Diese Detailfragen sind im Projektfall zu klären, nachdem man sich mit der Marktübersicht einen ersten Überblick über einen engeren Kandidatenkreis und deren Kernfunktionen verschafft hat.

IV.17 SharePoint-Integration

Anwender, die sowohl Collaboration-Anforderungen als auch DMS-/Archiv-Anforderungen abde-cken müssen, stehen vor dem Problem, dass einerseits Collaboration-Lösungen (das gilt auch für den Microsoft SharePoint Server) i.d.R. nicht alle notwendigen Funktionen einer DMS-/Archivan-wendung zur Verfügung stellen, umgekehrt aber die allermeisten DMS-/Archivlösungen wichtige Collaboration-Anforderungen gar nicht oder nur unzureichend abdecken. Daher entwickeln viele Anwender eine 2-Säulen ECM-Strategie, um beide Einsatzbereiche abdecken zu können. Hierbei ist der Microsoft SharePoint in vielen Fällen im Architekturzielbild für die Collaboration-Säule strate-gisch gesetzt.

Wir möchten an dieser Stelle erwähnen, dass es eine Reihe funktional vergleichbarer wettbewerbs-fähiger Lösungen im Bereich Collaboration gibt. Aus zwei Gründen haben wir aber entschieden, nur die Integrationsfragen in Bezug auf den Microsoft SharePoint in die Marktübersicht aufzunehmen. Zum einen aufgrund der großen Verbreitung des SharePoint sowohl bei mittelständischen als auch bei großen Unternehmen. Zum anderen gibt es seitens der DMS-Anbieter kaum Integrationsschnitt-stellen zu anderen Collaboration-Lösungen, außer natürlich zu denen aus dem eigenen Hause, wie zum Beispiel bei Open Text mit dem klassischen LiveLink oder EMC mit eRoom. Daher erübrigt sich ein Abfragen nach solchen weiteren Collaboration-Integrationsschnittstellen.

Wer sich als Anwender aber entschieden hat, eine der anderen Collaboration-Plattformen in Ergän-zung zu seiner DMS-/Archiv-Plattform einzusetzen, für den sind die Integrationsfragen natürlich trotzdem nützlich, da sich die Fragen z.B. nach Rechercheintegration oder Content-Auslagerung eigentlich immer stellen lassen, wenn zwei ECM-Plattformen in der oben beschriebenen Form ergänzend parallel betrieben werden sollen.

Der SharePoint-Server besitzt seit der ersten Version von 1999 eigene Dokumentenverwaltungs-funktionen, die im Laufe der mittlerweile fünf Major Versionen (mit dem Erscheinen dieser Marktü-bersicht ist auch die 5. Version des SharePoint offiziell verfügbar) weiterentwickelt wurden. Dennoch wird er bisher in vielen Unternehmen – wie oben beschrieben – zusätzlich zu „klassi-schen“ DMS-/Archivlösungen eingesetzt. Der Grund ist meist, dass diese in der Regel noch leis-tungsfähiger die typisch geforderten Akten-, Ablagefunktionen sowie Integrationsanforderungen (z.B. Verknüpfungsverfahren mit SAP) unterstützen. Daher hat das Thema DMS-SharePoint-Integra-tion in den letzten Jahren eine hohe Bedeutung bei DMS-Anwendern erlangt. Mittlerweile bieten fast alle DMS-Anbieter Integrationsmöglichkeiten an, die sich aber hinsichtlich ihrer Funktionalität erheblich voneinander unterscheiden.




Die gängigen Integrationsszenarien unterscheiden sich prinzipiell:

• Szenario: Auslagerung von Dokumenten in ein externes DMS

Oft wird der SharePoint wegen der Standard-Integration in Microsoft Office in der Erstellungs- und Bearbeitungsphase von Dokumenten eingesetzt. Nach der Freigabe der Dokumente sollen diese in ein „revisionssicheres“ Archiv ausgelagert werden. Dabei sollen diese Doku-mente dem SharePoint-Anwender in seiner vertrauten SharePoint-Anwendung weiterhin zur Verfügung stehen. Solche Migrationsschnittstellen bieten eine Reihe von DMS-Herstellern. Im Prinzip benötigt man für diese reine Archivmigration aber kein vollständiges DMS. Zur Siche-rung der unveränderten Speicherung würde ausreichen, die Objekte aus dem SharePoint in ein reines Archiv-Repository (Archivspeicher) auszulagern und per Verknüpfung aus Share-Point zugreifbar zu machen. Solche reinen Middleware-Angebote (ohne DMS) werden am Markt auch angeboten, sind aber in der vorliegenden Marktübersicht der DMS-Komplettange-bote nicht enthalten.

Dabei lässt sich die Unveränderbarkeit der Dokumente auch mit SharePoint-Bordmitteln allein und ohne Einsatz eines Archivspeichers bewerkstelligen, wenn die regulatorischen Anforde-rungen über eine technisch/organisatorische Lösung für die unveränderbare Ablage ausrei-chend bedient sind. Ob solche Maßnahmen genügen, muss im Zweifelsfall von Revision, Prüfer etc. bestimmt werden. Sollten die SharePoint-Bordwerkzeuge als nicht ausreichend bewertet werden, kommen die Auslagerungslösungen in Betracht.

• Szenario: SharePoint als Integrationsplattform für ein externes DMS

In diesem Integrationskonzept fungiert SharePoint als Portal und Entwicklungsplattform. Es adressiert die Anwender, die über das SharePoint-Portal mit einer einheitlichen Benutzerober-fläche auf wichtigen Unternehmensinformationen – also auch auf ein evtl. vorhandenes DMS – zugreifen möchten.

Man macht sich zunutze, dass die SharePoint-Portaloberfläche durch sogenannte Webparts erweiterbar ist. DMS-Anbieter haben für ihr Produkt oft ein oder mehrere SharePoint-Webparts entwickelt, um z.B. Dokumente zu suchen, Trefferlisten anzuzeigen oder in den Abla-gestrukturen des externen DMS zu navigieren. In diesen Fällen kommen jedoch keine DMS-Funktionen des SharePoint wie z.B. Versionierung oder Check-In/-Out zum Einsatz. Vielmehr werden diese DMS-Funktionen als spezifische Erweiterung vom jeweiligen DMS-Anbieter gelie-fert. Die Dokumentenablage im DMS funktioniert ebenfalls nicht in jedem Fall wie in der SharePoint-Umgebung gewohnt, sondern nur so, wie sie vom DMS-Anbieter in Bezug auf sein Produkt implementiert wurde.

Häufige Kritik der Anwender bei diesem Konzept ist, dass sie es mit zwei Dokumentenablagen mit unterschiedlicher Bedienung zu tun haben und die Integration nur oberflächlich ist. Deshalb bezeichnen wir den SharePoint in diesem Szenario auch nicht als einen einheitlichen DMS-Client, sondern vielmehr als einen Portal-Client, der zusätzlich DMS-Funktionen eines Drittanbieters bein-haltet.

Weitere, vielfältige Integrationskonzepte kommen laufend neu auf den Markt, da die ECM-Anbieter den SharePoint zunehmend als Applikationsplattform begreifen. Bei jedem der Szenarien interes-siert, wie die Konsistenz zwischen der SharePoint-Ablage und dem DMS hergestellt wird, damit nicht nur die Dokumente, sondern auch deren Ablageinformationen und Strukturinformationen, wie Akten und Ordner, gegebenenfalls in beiden Systemen einheitlich vorliegen.

Weiter stellt sich für Anwender die Herausforderung, über die SharePoint-Oberfläche weitere DMS-Funktionen, wie z.B. den elektronischen Postkorb nutzbar zu machen. Die Marktübersicht muss sich hier aus Platzgründen auf eine grundlegende Funktionsbetrachtung beschränken. Details zu den Integrationsszenarien, die bei der Lösungseinrichtung, Pflege oder Bedienung von zusätzlicher Bedeutung sind, konnten aus diesem Grund ebenfalls nicht berücksichtigt werden.

Darüber hinaus gibt es auch Lösungen von DMS-Herstellern (und anderen Anbietern), die komplette DMS-/ECM-Lösungen auf Basis des SharePoint entwickelt haben, ohne ein vorhandenes DMS als Basis darunter zu legen. Es handelt eigentlich um eine 100%ige SharePoint-Architektur, bei der der SharePoint als eine Entwicklungsplattform genutzt wird, wobei große Teile der Anwen-dungslösung nicht von Microsoft, sondern von einem Microsoft-Partner kommen.




Hinweis: Der aktuelle Abschnitt beschreibt lediglich, wie der Microsoft SharePoint-Server mit der jeweils dargestellten DMS-Lösung integriert werden kann. Da der Microsoft SharePoint-Server 2013 auch als eigenständige Collaboration- und DMS-Lösung zu betrachten ist, wurde die Beschreibung des Produktes selbst ebenfalls in diese Marktübersicht aufgenommen.

IV.18 Weitere Komponenten

Am Ende der Fragenabschnitte konnten die DMS-Hersteller bis zu drei weitere Produktkompo-nenten benennen und kurz beschreiben, die zwar Bestandteil ihres DMS-Angebotsportfolios sind, in den anderen Abschnitten der Übersicht aber nicht abgefragt wurden. Typische Beispiele sind horizontale Lösungen wie Bildverwaltungssysteme, Rechnungsprüfung, Vertragsmanagement, Personalakten-Anwendungen oder vertikale, d.h. branchenspezifische Lösungen, aber auch Komponenten für Querschnittsfunktionen wie zum Beispiel die Vorlagenverwaltungen für MS Office etc.

Diese ergänzenden Lösungen stammen häufig nicht vom DMS-Hersteller selbst, sondern von Inte-grationspartnern, weswegen in der Übersicht der Hersteller der Komponenten anzugeben war.

Die funktionale Beschreibung dieser zusätzlichen Komponenten muss sich auf eine kurze Prosa-Beschreibung über die Kernfunktionen der jeweiligen Komponente beschränken: Es würde den Rahmen der vorliegenden Marktübersicht sprengen, wenn alle denkbaren Arten von Ergänzungslö-sungen mit dem gleichen Detaillierungsgrad abgefragt würde, der in der Darstellung der übrigen Fragenabschnitte angesetzt wurde. Daher bieten diese abschließenden Fragenabschnitte den Herstellern die Möglichkeit, ansonsten unberücksichtigte Komponenten ihres Produktangebots darzustellen.

In Auswahlprojekten können diese zusätzlichen Produktkomponenten ein hohes Gewicht bei der Bewertung der angebotenen DMS-Produkte einnehmen. Daher sollten in solchen Auswahlsituati-onen einerseits die konkreten funktionalen Ausgestaltungen der Zusatzkomponenten vertieft untersucht werden, ohne hierbei den Blick auf die „übrige“ Funktionalität und Ausgestaltung des DMS zu verlieren. Es besteht sonst die Gefahr, dass ein Produkt beschafft wird, das für die erste konkrete Projekt-Aufgabenstellung besonders geeignet erscheint, für weitere Ausbauten allerdings unbrauchbar oder nur kostenintensiv einsetzbar ist.

Gerade bei Anwendungs- und Lösungskomponenten sollte man nicht nur die Produktfunktionen bewerten, sondern die Prozesseignung dieser Komponenten, insbesondere für die Scanverarbei-tung der Papierdokumente. Hier sollte die Prozessverträglichkeit mit den übrigen DMS-Verfahren geprüft werden, um zu vermeiden, dass für verschiedene DMS-Anwendungen gänzlich unterschied-liche Prozesse z.B. in der Papiervorbereitung und -zusendung an die Scanstelle notwendig sind.

Insbesondere dann, wenn die Zusatzkomponente von einem abweichenden Hersteller stammt, sollte die Produktpflege und die Release-Verträglichkeit der Komponente mit dem DMS-Produkt zusätzlich bewertet werden. Falls mehrere Zusatzkomponenten infrage kommen, sollte überdies die Verträglichkeit der Komponenten untereinander gesichert sein, um zu vermeiden, dass z.B. in der Rechnungseingangsbearbeitung das Formularerkennungsprodukt des Herstellers A und in der Personalaktenanwendung das Formularerkennungsprodukt des Herstellers B integriert ist und somit zwei ähnlich geartete Produkte parallel betrieben und gepflegt werden müssen.

Der Leser kann aus den gesamten in dieser Marktübersicht gemachten Angaben über die „Weiteren Komponenten“ ableiten, wie vielfältig die Funktionsmöglichkeiten moderner DMS-Platt-formen sind. Gerade bei DMS-Herstellern mit umfangreichem Partnernetzwerk ist es sogar wahr-scheinlich, dass nicht alle am Markt angebotenen Ergänzungslösungen in dieser Marktübersicht erwähnt werden können. Hier hilft nur eine detaillierte Recherche bei denjenigen Anbietern, die – möglicherweise unter Zuhilfenahme dieser Marktübersicht – in den engeren Kreis der betrachteten Produkte gekommen sind.



MusterfirmaMusterprodukt

0.1 Musterfirma: Musterprodukt

StammhausFirmaAdresseHomepageGründungsjahrEigentumsverhältnisseAllgemeine Angaben zum Anbieter in DeutschlandFirmaAdresseHomepageGründungsjahrEigentumsverhältnisseAllgemeine Angaben zum Anbieter in ÖsterreichFirmaAdresseHomepageGründungsjahrEigentumsverhältnisseAllgemeine Angaben zum Anbieter in der SchweizFirmaAdresseHomepageGründungsjahrEigentumsverhältnisseMitarbeiteranzahl im Bereich DMS/ECMIn D.A.CH.In EU inkl. D.A.CH.Weltweit inkl. EUAnmerkungen des AnbietersUmsätze im Bereich DMS/ECMGeschäftsjahrIn D.A.CH. (in Mio. €)In EU inkl. D.A.CH. (in Mio. €)Weltweit inkl. EU (in Mio. €)Spezifische EinsatzfelderFokussierung auf ERP-Umgebungen bzw. FachanwendungenFokussierung auf andere EinsatzfelderDMS-Server-PlattformName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionFreigegeben für Microsoft Windows Server und folgende Datenbanken auf dieser Server-Plattform

MS SQL Server Oracle Andere DB:

Freigegeben für IBM AIX und folgenden Datenbanken

IBM DB2 Oracle Andere:

Freigegeben für SUN Solaris und fol-gende Datenbanken

Informix Oracle Andere:




Freigegeben für HP-UX und folgende Datenbanken

Informix Oracle Andere:

Freigegeben für Linux und folgende Datenbanken

Linux Distributionen: Oracle MySQL Andere:

Andere Plattformen und DatenbankenCapture-/Scan-Funktionen im Anwender-ClientWelche Scan-und Indexierkomponenten sind vorhanden?

Eine Scan-und Indexierkomponente ist im Standard Windows-Client (Rich-Client) enthalten Eine Scan-und Indexierkomponente ist im Standard Web-Client enthalten Die Scan-und Indexierkomponente ist für die o. g. Standard Anwendungs-clients kostenpflichtig. Ausnahmen:

Name bzw. Bezeichnung der Scan-und Indexierkomponente.

Für die Scan-und Indexierkomponente im Standard Windows-Client (Rich-Cli-ent):Für die Scan-und Indexierkomponente im Standard Web-Client:

Hersteller der Komponente? Für die Scan-und Indexierkomponente im Standard Windows-Client (Rich-Cli-ent):Für die Scan-und Indexierkomponente im Standard Web-Client:

Auf dem Markt seit (Datum) Für die Scan-und Indexierkomponente im Standard Windows-Client (Rich-Cli-ent):Für die Scan-und Indexierkomponente im Standard Web-Client:

Anzahl Kunden in D.A.CH. Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Client):Für die Scan-und Indexierkomponente im Standard Web-Client:

Aktuelle Version Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Client):Für die Scan-und Indexierkomponente im Standard Web-Client:

Für die Nutzung der Scan-und Indexier-komponente ist die Einbindung von spe-zieller Hardware oder Software notwen-dig?

Immer notwendig Optional notwendig für: Nicht vorgesehen

Ist ein Ad-hoc-Scannen von Einzelblät-tern möglich?

Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Cli-ent) Für die Scan-und Indexierkomponente im Standard Web-Client

Ist ein Stapelscannen möglich? Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Cli-ent) Für die Scan- und Indexierkomponente im Standard Web-Client

Es steht ein Administrationswerkzeug für die Definition von Scan-Profilen inkl. Stapelbearbeitung zur Verfügung?

Ja, für die Scan- und Indexierkomponente im Standard DMS-Client (Rich-Client) Ja, für die Scan- und Indexierkomponente im Standard Web-Client

Barcodeerkennung 2/5 Interleaved Code-39 Code-128 PDF 417 Data Matrix Gültig für Rich- und Web-Client bzw. Ausnahme:

Welche der folgenden Bildverbesse-rungsfunktionalitäten werden in der Scan-und Indexierkomponente im DMS-Client im Standard durchgeführt?

Automatisches leserichtiges Ausrichten gescannter Dokumente ("Auto rotate") Entfernen schwarzer bzw. weißer Ränder Ausfiltern von Schmutz ("Noise", "Despeckling") Automatische Erkennung leerer Rückseiten von Dokumenten über Schwellwert folgende Zusatzmodule sind notwendig: Gültig für Rich- und Web-Client bzw. Ausnahme:

Die Scan-Komponente im Standard DMS-Client erzeugt Dokumente in fol-genden Formaten:

Formate für mehrseitige Schwarz/Weiß Dokumente:Formate für einseitige Farbdokumente:Formate für mehrseitige Farbdokumente:

PDF Volltext Die angebotene Scan-und Indexierkomponente verfügt über eine OCR- und Volltextfunktion Die OCR-Funktion läuft automatisch während bzw. nach dem Scannen Gültig für Rich- und Web-Client bzw. Ausnahme:




Standard Indexierkomponente? Ja, integraler Bestandteil der o. g. Capture-Komponente Ja, Bestandteil der Capture-Komponente, muss jedoch zusätzlich lizen-ziert werden Nein, Indexanwendung muss separat entwickelt werden

Eigenständige Capture-/Scan-KomponenteWelches eigenständige Produkt zum Scannen und Indexieren steht zur Verfü-gung?

Eine Capture Scan-Komponente ist als eigenständiges Produkt/Kompo-nente verfügbar

Auf dem Markt seit (Datum) Auf dem Markt seit:Anzahl Kunden in D.A.CH. Anzahl Kunden:Für die Nutzung der Scan-Software ist die Einbindung von spezieller Hardware oder Software notwendig?

Nicht vorgesehen Optional notwendig (für Spezialfunktionen) Immer notwendig

Scanprozess Ad-hoc-Scannen möglich Stapel (Batch) Scannen möglich Es steht ein Administrationswerkzeug für die Definition von Scan-Profilen inkl. Stapelbearbeitung zur Verfügung

Stapel-/Batchorganisation Ändern der Priorität des Scan-Stapels Löschen kompletter Scan-Stapel Löschen einzelner Dokumente aus einem Scan-Stapel Ändern der Dokumententrennung innerhalb eines Scan-Stapels Umsortieren einzelner Seiten in einem Dokument innerhalb eines Scan-Stapels Umsortieren einzelner Seiten zwischen Dokumenten eines Scan-Stapels Umsortieren einzelner Seiten zwischen mehreren Scan-Stapeln

Unterstützte Barcode-/Patchcodety-pen?

Code-39 2/5 Interleaved Code-128 PDF 417 Data Matrix

Welche der folgenden Bildverbesse-rungsfunktionalitäten werden in der eigenständigen Scan-Komponente im Standard durchgeführt?

Automatisches leserichtiges Ausrichten gescannter Dokumente ("Auto rotate") Entfernen schwarzer bzw. weißer Ränder Ausfiltern von Schmutz ("Noise", "Despeckling") Automatische Erkennung leerer Rückseiten von Dokumenten über Schwellwert Korrektur von Helligkeit und Kontrast nach dem Scannen

Die eigenständige Standard Scan-Kom-ponente erzeugt Dokumente in folgen-den Formaten:

Dateiformate für mehrseitige Schwarz/Weiß Dokumente:Dateiformate für einseitige Farbdokumente:Dateiformate für mehrseitige Farbdokumente:

PDF Volltext Die eigenständige Scan-und Indexierkomponente verfügt über eine OCR- und Volltextfunktion Die OCR-Funktion läuft automatisch während bzw. nach dem Scannen Die Konvertierung der gescannten und OCR'ten Dokumente in ein recher-chierbares PDF-Dokument erfordert folgende Drittkomponenten:

Eine Standard Indexierkomponente ist integraler Bestandteil der eigenständi-gen Capture-Anwendung?

Ja, integraler Bestandteil der o. g. Capture-Komponente Ja, Bestandteil der Capture-Komponente, muss jedoch zusätzlich lizen-ziert werden Nein, Indexanwendung muss separat entwickelt werden

Funktionalitäten der Dokumenteninde-xierung

Eine Vorindexierung des Stapels oder einzelner Dokumente ist bereits beim Scannen möglich, Indexwerte können vorab fest eingestellt werden Die Indexierung von Dokumenten kann innerhalb eines Scanstapels abgebrochen und später an gleicher Stelle wieder aufgenommen werden Innerhalb eines Scanstapels können einzelne Dokumente während der Indexierung übersprungen werden Im Rahmen der Indexierung können Wertelisten verwendet werden Einzelne Dokumente innerhalb eines Scanstapels können während des Indexierens zum Re-Scan zurückgewiesen werden Die Indexierfunktion kann auf einem anderen Arbeitsplatz als dem Scan-Arbeitsplatz durchgeführt werden Die Indexierfunktion/-prozess kann auf mehreren unabhängigen PC-Arbeitsplätzen gleichzeitig durchgeführt werden

Capture OCR, Klassifikation, Index-, DatenextraktionName der Komponente




HerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionPlattform für OCR / Beleglesung Client-basiert

Server-basiertDie Verarbeitung erfolgt auf dem im Abschnitt DMS-Server-Plattform genannten Server (identisch

mit OCR –Server) auf dediziertem Server. Folgende Plattformen und DB werden unterstützt:

Funktionsumfang OCR / Beleglesung Bildaufbereitung für die Verbesserung der Leseergebnisse OCR für die Zeichenerkennung/Volltexterstellung Ad-hoc-OCR für die Übernahme von Einzelwerten (Zonen-OCR) Definition von Formularen für die strukturierte Beleglesung Automatische Klassifikation unstrukturierter Dokumente Definition einer Regelbasis für die unstrukturierte Beleglesung Trainierbares System für die unstrukturierte Beleglesung

Die folgenden Eingangsformate können verarbeitet werden:

TIFF-Format JPG-Format PDF (mit eingebetteten Rasterformaten) Office-Formate: E-Mail-Formate: Andere:

Die folgenden Funktionen stehen in der Software (unabhängig von Scanner-Funktionen) für die Bildaufbereitung von gescannten Dokumenten zur Verfü-gung:

Leerseitenerkennung Kontrastoptimierung Elektronisches Zuschneiden und Ausrichten In Leserichtung drehen Geraderücken Eliminierung ungewollter Linien Herausfiltern kleiner Punkte Herausfiltern Hintergrund/ Rückseite Blindfarben-Erkennung/-Filterung

Welche Dokumenteninhalte können ver-arbeitet werden?

Barcodes Zeichen OMR-Kennzeichen (Bsp. Ankreuz-Felder) Tabellenstrukturen Weitere (Handblockschrift, etc.):

Für welche Sprachen stehen entspre-chende Erkennungs-Engines zur Verfü-gung?

Deutsch Englisch Französisch Weitere europäische Sprachen: Weitere internationale Sprachen:

Für die Dokumentenklassifikation stehen die folgenden Funktionen zur Verfügung

Inhaltliche Erschließung Regelbasierte Erschließung Statistische Verfahren Grafische Verfahren (Bsp. Layout, Logos) Dokumentgrößen Voting Selbstlernende Verfahren Weitere:

Wie können die Klassifikationsregeln eingerichtet werden?

Manuelles Definieren von Dokumentarten Automatisches Trainieren mit Beispieldokumenten Andere:

Die folgenden Funktionen stehen für die Prüfung und Optimierung der Lese-ergebnisse zur Verfügung:

Syntax-Prüfung von Feldern (Format, Länge etc.) Abgleich mit externen Datenquellen (Bsp. Datenbanken) Abgleich mit einem Wörterbuch Logik-Prüfungen (Bsp. Summen, Pos. x Preis) Lernen von korrigierten Inhalten Manuelle Korrektur in einem Korrektur-Client




Die Weitergabe der Verarbeitungsergeb-nisse ist über die folgenden Wege mög-lich:

Export der erkannten Daten als Datei Export der erkannten Daten in eine Datenbank Bereitstellung der Volltextinformationen für eine Volltext-Datenbank Bereitstellung der um den Volltext ergänzten Dokumente im PDF-Format Erzeugung eines Layout-ähnlichen Word-Dokumentes mit den erkannten Texten Andere:

Die folgenden Informationen können ausgewertet werden:

Entwicklung der Erkennungsraten Verarbeitungszeiten (automatisch) Korrekturzeiten (manuell) Weitere Statistiken:

Für welche Anwendungsfälle oder Bran-chen stehen besondere Produktsuiten zur Verfügung?

Eingangsrechnungsverarbeitung Zahlungsverkehr Versicherungsbranche Krankenkassen Allgemeine Eingangspost (Papier) Allgemeine E-Mails Weitere Produktsuiten:

Für Eingangsrechnungsverarbeitung: Name der KomponenteFür Eingangsrechnungsverarbeitung: HerstellerFür Eingangsrechnungsverarbeitung: Aktuelle VersionFür Eingangsrechnungsverarbeitung: Verarbeitbare Belegarten

Eingangsrechnungen Gutschriften Storno-Belege Belastungsanzeigen Sammelrechnungen Lieferscheine andere:

Für Eingangrechnungsverarbeitung: Verarbeitbare Formate

Papier (gescannte Dokumente) Dokumente im PDF-Format E-Mails (Bodies) EDI XML-Dateien andere:

Für Eingangsrechnungsverarbeitung: Schnittstellen zu Buchhaltungssyste-men

SAP ERP Microsoft Dynamics NAV Microsoft Dynamics AX Oracle Financials Andere:

Capture-Komponente für strukturierte DatenName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionDie Funktion zur Übernahme struktu-rierter Daten basiert auf:

Server-Funktion Client-Funktion

Folgende grundlegenden Importszena-rien stehen im Standard zur Verfügung

Import elektronischer Dateien, Indexextraktion erfolgt jeweils aus dem Dateinamen Import einer Vielzahl elektronischer Dateien, Indexextraktion erfolgt aus einer zugehörigen Indexdatendatei im CSV-Format Import einer Vielzahl elektronischer Dateien, Indexextraktion erfolgt aus einer zugehörigen Indexdatendatei im XML-Format Import strukturierter Dateien, Indexextraktion erfolgt aus dem Auslesen definierter Auszeichner Anders:




Im Zuge des Imports stehen im Stan-dard Funktionen zur Konvertierung der importierten Daten und Dokumente in "menschenlesbare", langzeitstabile For-mate zur Verfügung.

Strukturierte Daten können unter Zuhilfenahme einer Layoutdatei im Zuge des Imports in PDF konvertiert werden. Strukturierte Daten können unter Zuhilfenahme einer Layoutdatei im Zuge des Imports in PDF/A konvertiert UND auf PDF/A-Konformität validiert werden. Strukturierte Daten können unter Zuhilfenahme einer Layoutdatei im Zuge des Imports in TIFF konvertiert werden. Ergänzende Anmerkungen:

Fehlerhandling - Im Fehlerfall reagiert das System mit folgendem Verhalten

Jobabbruch bei Fehlerfall Dokument wird bei Fehler übersprungen, kein Fehlerprotokolleintrag Dokument wird bei Fehler übersprungen, Fehlerprotokolleintrag Dokument wird verarbeitet, Fehlerprotokolleintrag Dokument wird verarbeitet, kein Fehlerprotokolleintrag Ergänzende Anmerkungen:

Die Importkomponente stellt im Stan-dard Protokollfunktionen zur Verfügung.

Es wird ein Ergebnisprotokoll geschrieben, welches für jedes erfolgreich importierte Dokument einen Eintrag enthält Für die Protokollierung fehlerhafter Verarbeitung wird ein separates Feh-lerprotokoll geschrieben

Für die Einrichtung und Konfiguration der Importkomponente steht ein GUI-basiertes Werkzeug zur Verfügung.

Ja, alle den Import betreffenden Einstellungen werden in einem GUI-ori-entierten Werkzeug vorgenommen Ja, die Basis-Einstellungen des Imports werden in einem GUI-orientierten Werkzeug vorgenommen, weitere Einstellungen werden per Skript/Program-mierung vorgenommen Nein, die Import-Einstellungen werden per Skript/Programmierung vorge-nommen

Capture-Komponente für zentralen DruckoutputName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionPlattform für COLD/Drucklistenarchivie-rung

Der im Abschnitt DMS-Server Plattform genannte Server ist identisch mit dem COLD-Server Dedizierter Server: alle im Abschnitt DMS-Server Plattform genannten Plattformen werden unterstützt Dedizierter Server: folgende Plattformen und Datenbanken werden unter-stützt:

Import und Indexierung nativer 1403 Druckdaten

Archivierung nativer 1403-Druckspoolformate, ohne Formatkonvertie-rung Archivierung nach Konvertierung in PDF Archivierung nach Konvertierung in PDF/A inkl. PDF/A-Validierung Archivierung nach Konvertierung in TIFF Archivierung nach Konvertierung in andere Formate:

Bei Speicherung nativer 1403-Druckda-ten

Anzeige nativer 1403-Formate in dediziertem 1403-Viewer Anzeige nativer 1403-Formate im Standard DMS-Viewer Die zum Zeitpunkt der Archivierung gültigen Hintergrundformulare werden automatisch aus dem DMS geladen und per Overlay mit den Netto-daten angezeigt. Konvertierung vor der Anzeige in folgendes Viewing-Format:

Import und Indexierung nativer AFP-Druckdaten

Archivierung nativer AFP-Daten ohne Formatkonvertierung Archivierung nach Konvertierung in PDF Archivierung nach Konvertierung in PDF/A inkl. PDF/A-Validierung Archivierung nach Konvertierung in TIFF Archivierung nach Konvertierung in andere Formate:

Bei Speicherung nativer AFP-Druckda-ten

Anzeige nativer AFP-Daten in dediziertem AFP-Viewer Anzeige nativer AFP-Daten im Standard DMS-Viewer Die zum Zeitpunkt der Archivierung gültigen AFP-Ressourcen stehen bei der Anzeige zur Verfügung Konvertierung vor der Anzeige in folgendes Viewing-Format:

Andere unterstützte Druckdatenformate




Die Einrichtung zur Entnahme von Indexdaten aus dem Datenstrom erfolgt mit folgenden Mitteln

Nutzung einer grafischen Oberfläche (mit Dokumentendarstellung) Editieren von Konfigurationsdateien Eingabe von Parametern in Eingabemasken Anders/Weitere:

ArchivierungDie Archiv-Funktionalität wird von einer bereits genannten Server-Komponente mit abgedeckt.

Ja, Angabe Komponente und Version: Nein, eigenständige Komponente. Angabe Komponente und Version:

Wenn eigenständige Komponente: welche Server- und Datenbankplattfor-men sind Voraussetzung dieser Kompo-nente?HerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Der Schutz gegen unzulässige Änderun-gen (revisionssichere Aufbewahrung) ist wirksam für

Dokumente und andere Objekte Metadaten zu den Dokumenten und Unterlagen Weitere:

Der Schutz gegen unzulässige Änderun-gen (revisionssichere Aufbewahrung) wird erreicht durch

Optische WORM-Speicher (Angabe, welche): Magnetplatten-basierte WORM-Speicher (weitere Angaben siehe nächste Frage) Standard-Magnetplattensystem (SAN, NAS etc.) kombiniert mit Software-Schutz (Angabe, wie):

Die revisionssichere Speicherung auf Magnetplattensystemen unterstützt fol-gende spezielle WORM-Speichersys-teme

EMC Centera NetApp SnapLock IBM Information Archive Andere:

Die revisionssichere Speicherung auf normalen überschreibbaren Medien (NAS-/SAN) wird ermöglicht durch (bitte Angabe der Verfahren)Das Archivsystem erlaubt das Anlegen und Ausführen von Löschfristen

Anlegen von Löschfristen Löschfristen können relativ zum Eintrittsdatum von Ereignissen definiert werden Ausführen von Löschfristen: Dokumente werden gelöscht Ausführen von Löschfristen: Index wird gelöscht Fristen können nachträglich verlängert werden durch (bitte Angabe, wie..): Fristen können unterbrochen werden (bitte Angabe, wie ..):

Die in der vorgenannten Frage angege-benen Verwaltungsfunktionen von Löschfristen sind …

Funktionen des DMS/Archivs, die unabhängig vom verwendeten Speicher arbeiten Funktionen des Speichersystems (folgende Speicher bieten diese Funkti-onen):

DMS-FunktionenDie DMS-Funktionalität wird von einer bereits genannten Server-Komponente mit abgedeckt. Angabe der Kompo-nente

Ja, Komponente und Version: Nein, eigenständige Komponente. Angabe Komponente und Version:

Wenn eigenständige Komponente: welche Server- und Datenbankplattfor-men sind Betriebsvoraussetzung dieser Komponente?HerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Replikation von Systeminhalten zwi-schen mehreren Systeminstanzen

Replikation für Dokumente Replikation für Beschreibungsdaten Replikation für Check-Out- / -In-Status Replikation Zugriffsschutz Replikation Benutzer / Benutzergruppen / Rollen Weitere:




Es steht ein Offline-Client mit folgenden Funktionen zur Verfügung

Mitnahme von Dokumenten zur Offline-Ansicht Offline-Änderung von Dokumenteninhalten mit anschließender Synchro-nisierung Offline-Änderung von Dokumentenattributen mit anschließender Synchro-nisierung Offline-Erstellung von neuen Dokumenten mit anschließender Synchroni-sierung Offline-Suche nach Dokumenten (im Offline verfügbaren Dokumentenbe-stand) unter Nutzung der zugehörigen Dokumenten-Metadaten Die beschriebene Offline-Funktionalität ist im Standard-DMS-Client ent-halten (gegebenenfalls als Lizenzoption) Die o.a. Offline-Funktionen stehen für folgende Client-Plattformen zur Ver-fügung: Weitere Offline-Funktionen:

Für den Zugriff auf die DMS-Funktionen wird eine andere Client-Anwendung bereitgestellt als für den Zugriff auf die Archiv-Funktionen

Ja, DMS-Client und Archiv-Client sind unterschiedliche Client-Anwendun-gen Nein, Zugang zu DMS und Archivierung über gleichen Client

Rendition-Funktionen (Formatkonvertie-rung)

Die Rendition-Funktion läuft auf einem Serversystem Die Rendition-Funktion läuft auf dem Arbeitsplatz des Endbenutzers

Quellformate für Rendition-Funktion Word - Versionen: Excel - Versionen: Powerpoint - Versionen: Outlook-Mail - Versionen: Notes-Mail - Versionen: Andere:

Zielformate für Rendition-Funktion PDF gemäß ISO 32000 PDF/A gemäß ISO 19005 Multi-Page TIFF Andere:

Rich-ClientName und Version des Rich-Client Pro-duktesAuf dem Markt seit (Datum)Technologie des Rich-Clients Native Windows-Anwendung (benötigt keine zusätzliche Laufzeitkompo-

nente) .NET-Anwendung (benötigt .NET-Laufzeitumgebung) Java-Anwendung (benötigt Java-Laufzeitumgebung) Andere:

Der Rich-Client ist für den Einsatz mit Terminalservern freigegeben

WTS Citrix Nein

Die folgenden DMS-Funktionen sind im Rich-Client enthalten

Dokumentenablage / Dokumentenimport Dokumentenanzeige (mitgelieferte Funktion bzw. Anwendung) Check-Out von Dokumenten, diese sind dann für den Zugriff durch Dritte gesperrt Check-In von Dokumenten: gibt Dokumente für Dritte zur Bearbeitung frei Genehmigungs- und -Freigabefunktionen Abonnieren von Änderungen an Dokumenten Aktenfunktionen (Beschreibung siehe Kapitel "Aktenverwaltung") Postkorb-Funktionen (Beschreibung siehe Kapitel "Postkorb-Funktionen") Collaboration-Funktionen (Beschreibung siehe Kapitel "Collaboration-Funktionen") Andere (bitte nur Stichworte):

Der Rich-Client enthält folgende Such- und Trefferlistenfunktionen

Suche nach Textinhalten (Volltext) Speichern und Wiederverwenden von Suchabfragen (Suchbedingungen) Speichern und Exportieren von Trefferlisten (CSV-, Excel oder anderes strukt. Format) Thumbnail-Vorschau aller Seiten eines Dokumentes in der Trefferliste Thumbnail-Vorschau der ersten Seite der gefundenen Dokumente in der Trefferliste Weiterleiten des Dokumentes als E-Mail-Anhang direkt aus der Trefferliste Weiterleiten des Dokumentenlinks per E-Mail direkt aus der Trefferliste Gruppieren von Trefferlisteneinträgen mit gleichen Metadaten




Der Multi-Format-Viewer im Rich-Client (Variante: ohne Laden nicht mitgeliefer-ter Plug-Ins) stellt folgende Dateifor-mate dar

PDF TIFF JPEG MS Outlook (.msg) folgende MS-Office Formate: folgende CAD-Anwendungsformate: Andere:

Die Dokumentenanzeigefunktion im Rich-Client stellt Dokumente

in einem Multi-Format-Viewer dar; die Anzeige der Dokumente erfolgt ohne Laden zusätzlicher, nicht mitgelieferter PlugIns in einem Multi-Format-Viewer dar; für die Anzeige der folgenden Doku-mentenformate ist die Installation zusätzlicher nicht mitgelieferter PlugIns notwendig: in den jeweiligen (auf dem Arbeitsplatz bereitzustellenden und zu laden-den) Editoren dar

Die Dokumentenanzeigefunktion im Rich-Client enthält eine Thumbnailan-zeige für folgende Dokumentformate

Thumbnailanzeige ist für alle in der Anzeigefunktionen darstellbaren Dokumentformate verfügbar Thumbnailanzeige ist für folgende Dokumentformate verfügbar:

Die Dokumentenanzeigefunktion im Rich-Client enthält Annotationsfunktio-nen für folgende Dateiformate

TIFF PDF Word - Versionen: Excel - Versionen: Powerpoint - Versionen: Redlining- / Annotationsfunktionen für folgende CAD-Anwendungsfor-mate: Andere:

Versionierungsfunktionen im Rich-Client werden für folgende Objekttypen bereitgestellt

Dokumenten-Inhalte Dokumenten-Attribute Ordner / Akten - Inhalte Ordner / Akten - Attribute Weitere:

Verbunddokumentfunktionen im Rich-Client

Bildung zusammengehöriger Dokumente aus Einzeldokumenten (Parent-Child-Beziehung; Compound Document) Verzweigung vom Parent-Dokument zum Child-Dokument und umgekehrt Versionierung von Dokumenteninhalten von Parent- und Child-Dokumen-ten (inkl. Check-In / Check-Out Funktionen) Versionierung der Dokumentenmetadaten von Parent- und Child-Doku-menten

Der Rich-Client enthält folgende Freiga-befunktionen

Versand von Dokumenten innerhalb des DMS-Clients zwecks Erteilung einer Freigabe Verwaltung des Freigabestatus Protokollierung des Freigabeprozesses

Der Standard Rich-Client enthält fol-gende Benachrichtigungsfunktionen

Benachrichtigung bei Änderungen an abonnierten Dokumenten Benachrichtigung wenn neue Dokumente zu einer gespeicherten Suchab-frage entstehen Benachrichtigung, wenn neue Dokumente in abonnierten Akten entste-hen oder geändert werden Sonstige (bitte nur Stichworte):

Browser Client / RIA ClientName der KomponenteAuf dem Markt seit (Datum)Technologie des Browser Clients HTML / XHTML

HTML5 Java-Script AJAX ActiveX .NET JavaApplets Silverlight Flash / Flex Andere:

Der Browser Client ist für den Einsatz mit Terminalservern freigegeben

WTS Citrix Nein




Die folgenden Funktionen sind im Brow-ser Client enthalten

Dokumentenablage / Dokumentenimport Dokumentenanzeigefunktion Check-Out von Dokumenten, diese sind dann für den Zugriff durch Dritte gesperrt Check-In von Dokumenten: gibt Dokumente für Dritte zur Bearbeitung frei Systemgestützte (nicht nur manuelle) Versionierung von Dokumenten Genehmigungs- und -Freigabefunktionen Abonnieren von Änderungen an Dokumenten Aktenfunktionen (Beschreibung siehe Kapitel "Aktenverwaltung") Postkorb-Funktionen (Beschreibung siehe Kapitel "Postkorb-Funktionen") Collaboration-Funktionen (Beschreibung siehe Kapitel "Collaboration-Funktionen") Andere (bitte nur Stichworte):

Der Browser Client enthält folgende Such- und Trefferlistenfunktionen

Suche nach Textinhalten (Volltext) Suchabfragen lassen sich speichern Thumbnail-Vorschau aller Seiten eines Dokumentes in der Trefferliste Thumbnail-Vorschau der ersten Seite der gefundenen Dokumente in der Trefferliste Weiterleiten des Dokumentes als E-Mail-Anhang direkt aus der Trefferliste Weiterleiten des Dokumentenlinks per E-Mail direkt aus der Trefferliste Speichern und Wiederverwenden von Suchen Gruppieren von Trefferlisteneinträgen mit gleichen Metadaten Markierung geänderter und neuer Dokumente

Die Dokumentenanzeigefunktion des Browser Clients stellt Dokumente

in einem Multi-Format-Viewer dar ohne Laden Format-spezifischer Plug-Ins in einem Multi-Format-Viewer dar mit Laden weiterer Format-spezifischer Plug-Ins in den jeweiligen (zu ladenden) Editoren dar

Der Multi-Format-Viewer des Browser Clients (Variante: ohne Laden weiterer Plug-Ins) stellt folgende Dateiformate dar

PDF TIFF JPEG MS Outlook (.msg) folgende MS-Office Formate: folgende CAD-Anwendungsformate: Andere:

Die Dokumentenanzeigefunktion im Browser Client enthält eine Thumbnail-anzeige für

alle in der vorherigen Frage angekreuzten Dokumentformate folgende Dokumentformate:

Die Dokumentenanzeigefunktion des Browser Clients beinhaltet Annotations-funktionen für folgende Dateiformate

TIFF PDF Word - Versionen: Excel - Versionen: Powerpoint - Versionen: Redlining / Annotationsfunktionen für folgende CAD-Anwendungsfor-mate: Andere:

Versionierungsfunktionen im Browser Client werden für folgende Objekttypen bereitgestellt

Dokumenten-Inhalte Dokumenten-Attribute Ordner / Akten - Inhalte Ordner / Akten - Attribute Weitere:

Verbunddokumentfunktionen im Brow-ser Client

Bildung zusammengehöriger Dokumente aus Einzeldokumenten (Parent-Child-Beziehung; Compound Document) Verzweigung vom Parent-Dokument zum Child-Dokument und umgekehrt Versionierung von Dokumenteninhalten von Parent- und Child-Dokumen-ten (inkl. Check-In / Check-Out Funktionen) Versionierung der Dokumentenmetadaten von Parent- und Child-Doku-menten

Im Browser Client stehen folgende Frei-gabefunktionen zur Verfügung

Versand von Dokumenten innerhalb des DMS-Clients zwecks Erteilung einer Freigabe Verwaltung des Freigabestatus Protokollierung des Freigabeprozesses




Im Browser Client stehen folgende Benachrichtigungsfunktionen zur Verfü-gung

Benachrichtigung bei Änderungen an abonnierten Dokumenten Benachrichtigung wenn neue Dokumente zu einer gespeicherten Suchab-frage entstehen Benachrichtigung, wenn neue Dokumente in abonnierten Akten entste-hen oder geändert werden Sonstige (bitte nur Stichworte):

Sonstige Client-AnwendungenFolgende DMS-Integrationsfunktionen für MS Office stehen zur Verfügung

Automatische Übernahme von Metadaten aus dem DMS in das geöffnete Office-Dokument (Office-Feldfunktion) Übernahme von Office-Dokumenteigenschaften in das DMS als Indexda-ten Verwendung markierter Textelemente für Volltextsuche im DMS ohne Ver-lassen von MS Office Check-Out / Check-In & Versionieren von Dokumenten ohne Verlassen von MS Office

MS Outlook-Integration Suche inkl. Trefferliste Check-Out / -In & Versionierung Ablage von Dokumenten Ändern von DMS-Metadaten DMS-Postkorb-Funktionen Start / Teilnahme an DMS-Freigabeprozessen

Integration in Windows Explorer "Senden an…" das DMS "Suchen..." im DMS DMS als "Laufwerk" Drag & Drop in den DMS-Rich-Client Drag & Drop in den Browser-basierten DMS-Client Anders, Weitere:

Fragen zur Windows Explorer-Integra-tion

Bei jeder Zwischenspeicherung erstellt das DMS automatisch eine neue Dokumenten(zwischen)version Der Anwender erhält bei jeder Zwischenspeicherung eine Rückfrage und entscheidet, ob der vorherige Dokumenteninhalt überschrieben wird oder ob eine neue Dokumentenversion erstellt wird Anders:

Anlegen und Verwalten von Ablagestruk-turen

Grafisches Werkzeug zum Anlegen von Ordnungsstrukturen (Indexfelder) Grafisches Werkzeug zum Gestalten von Recherche-/Suchmasken Grafisches Werkzeug zum Gestalten der Trefferlisten Standard Datenbankwerkzeuge zum Anlegen der Datenbanktabellen (keine dedizierten DMS-Werkzeuge) Suchmasken werden automatisch generiert und können angepasst werden

CAD-Integrationsfunktionen Automatische Übernahme der Kopfdaten aus der CAD-Datei als Metada-ten im DMS aus folgenden CAD-Formaten: Check-Out / Check-In & Versionieren von CAD-Dokumenten ohne Verlas-sen der CAD-Anwendung für folgende CAD-Anwendungen:

AktenverwaltungDie Akten-Funktionalität wird von einer bereits genannten Server-Komponente mit abgedeckt. Bitte Angabe der Kom-ponente und Version.

Ja, Komponente (Bezeichnung) und Version: Nein, andere Komponente (Bezeichnung) und Version: Wenn andere Komponente: Aktenfunktionalität erfordert folgende Server-plattformen und Datenbanken:

HerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Integration mit DMS/ECM Die Akten-Client Funktionalität ist Bestandteil des Standard-DMS-Rich-Cli-

ents Die Akten-Client Funktionalität ist Bestandteil des Standard-Browser-Cli-ents Akten-Client ist separate Rich-Client-Anwendung Akten-Client ist separate Browser-Client-Anwendung Anders:




Aktenmodellierung, Aktenstrukturen Erstellung und Verwaltung mehrerer, voneinander unabhängiger Akten-modelle: Aktenmodelle dienen als Template ("Kundenakte") und werden instanzi-iert ("Kundenakte XY") Aktenmodelle (Vorlagen, Templates) haben vordefinierte Registerstruktu-ren Verschachtelungstiefe der Akte ist begrenzt auf Ebenenzahl: Akten können in andere Akten verlinkt werden Akten besitzen eigene, von den Dokumenten unabhängige Metadaten Verwaltung "leerer" Akten (Akten enthalten für einen bestimmten Zeit-raum keine Dokumente)

Im Standard des Clients enthaltene Aktenfunktionen

Akten(!) können über den Volltext der enthaltenen Dokumente gefunden werden (Trefferliste enthält alle Akten, in denen mindestens ein Dokument die gesuchte Textpassage enthält) Die Volltextsuche nach Dokumenten lässt sich auf eine bestimmte Akte eingrenzen Links auf Akten (nicht auf Dokumente!) können per E-Mail weitergeleitet werden Setzen und Abrufen von Akten-Wiedervorlageterminen Akten inklusive der Aktenstrukturen und Dokumente können auf Endge-räten (z.B. Notebooks) heruntergeladen und offline unter Verwendung des Akten-Clients gesichtet werden Dokumente aus MS Office können direkt in ein Aktenregister (Unterregis-ter einer Akte) abgelegt werden E-Mails können direkt in ein Aktenregister abgelegt werden für folgende Mail-Clients: Es können gleichzeitig mehrere Akten geöffnet sein Die zuletzt verwendeten Akten werden in einer Verlaufsliste dargestellt; Anzahl:

Innerhalb einer Akte können folgende Elemente verwaltet werden

Beliebige Inhaltselemente (Dokumente, Dateien, CAD, Video/Audio-Dateien) URLs auf beliebige interne oder externe Quellen Verweise auf Papierakten (Fundstellenverzeichnis) Links auf andere Akten im DMS Links auf gespeicherte/programmierte Suchen im DMS Weitere:

Weitere Aktenfunktionen Löschregeln können auf komplette Akten angewendet werden Akten können (unabhängig von Dokumenten) mit eigenen Indexdaten ver-schlagwortet werden Zu Dokumenten lässt sich ein Verwendungsnachweis anzeigen: in wel-chen Akten befindet sich dieses Dokument? Akten können auch dynamische Strukturen / Pseudo-Register beinhalten (z.B. Trefferlisten, die durch in die Akte eingebundene Suchabfragen ermit-telt werden) Änderungshinweise: Die Aktenanwendung markiert eigenständig diejeni-gen Elemente, die seit dem letzten Öffnen der Akte geändert oder hinzuge-fügt wurden Änderungshinweise: Die Anwendung führt eine für den Anwender einseh-bare Historie (z.B. RSS-Feed) über alle Veränderungen innerhalb einer Akte

Client-basierte E-Mail-Archivierung: MS OutlookName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Verfügbar für MS Outlook Client-Versionen:Folgende Möglichkeiten der E-Mail-Archivierung sind im Standard enthalten

Ausgewählte E-Mails und Anhänge können unmittelbar durch den Endbe-nutzer aus dem E-Mail-Postfach in individuelle DMS-Ablagestrukturen, die auch für andere Dokumente verwendet werden, abgelegt werden. Ausgewählte E-Mails können vom Anwender in einen dedizierten Ordner des E-Mail-Systems verschoben werden; alle E-Mails in diesem Ordner werden zeitversetzt und vollautomatisch archiviert. Beim Versand einer E-Mail kann der Benutzer gefragt werden, ob die erstellte E-Mail im DMS abgelegt werden soll. Andere:




Die gesamte E-Mail (inkl. Anhänge) wird in folgendem Format abgelegt

MSG-Format RFC 2822 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenstän-dige Objekte Andere:

Die Mailbodies werden in folgendem Format abgelegt

Original E-Mail-Format Konvertiert in PDF Andere:

Die Attachments werden in folgendem Format abgelegt

Originalformat Konvertiert in PDF Andere:

Zustand des Mail-Systems nach der Archivierung von E-Mails

Archivierte E-Mail wird im Mail-System automatisch gelöscht Archivierte E-Mail wird durch Mail mit Link oder Stub ersetzt Archivierte E-Mail verbleibt weiter im Mail-System Anders:

Suche nach E-Mails Aus dem MS Outlook-Client Aus dem DMS-Client Volltextsuche im DMS für Mailbody Volltextsuche im DMS für Anhänge Wenn Volltextsuche in Anhängen: Welche Formate sind durchsuchbar?

Anzeige von E-Mails Im DMS-Viewer Im MS Outlook-Client Andere:

Client-basierte E-Mail-Archivierung: Lotus NotesName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Verfügbar für Lotus Notes Client-Versionen:Folgende Möglichkeiten der E-Mail-Archivierung sind im Standard enthalten

Ausgewählte E-Mails und Anhänge können unmittelbar durch den Endbe-nutzer aus dem E-Mail-Postkorb in individuelle DMS-Ablagestrukturen, die auch für andere Dokumente verwendet werden, abgelegt werden. Ausgewählte E-Mails können vom Anwender in einen dedizierten Ordner des E-Mail-Systems verschoben werden; alle E-Mails in diesem Ordner werden zeitversetzt und vollautomatisch archiviert. Beim Versand einer E-Mail kann der Benutzer gefragt werden, ob die erstellte E-Mail im DMS abgelegt werden soll. Andere:


NSF-Format DXL-Format RFC 2822 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenstän-dige Objekte Andere:







Suche nach E-Mails Aus dem Lotus Notes-Client Aus dem DMS-Client Volltextsuche im DMS für Mailbody Volltextsuche im DMS für Anhänge Wenn Volltextsuche in Anhängen: Welche Formate sind durchsuchbar?

Anzeige von E-Mails Im DMS-Viewer Im Lotus Notes-Client Andere:




Client-basierte E-Mail-Archivierung: Andere Mail-ClientsName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Verfügbar für Novell Groupwise Client-Versionen:

Andere Mail-Clients:Folgende Möglichkeiten der E-Mail-Archivierung sind im Standard enthalten

Ausgewählte E-Mails und Anhänge können unmittelbar durch den Endbe-nutzer aus dem E-Mail-Postkorb in individuelle DMS-Ablagestrukturen abge-legt werden. Ausgewählte E-Mails können vom Anwender in einen dedizierten Ordner des E-Mail-Systems verschoben werden; alle E-Mails in diesem Ordner werden zeitversetzt und vollautomatisch archiviert. Beim Versand einer E-Mail kann der Benutzer gefragt werden, ob die erstellte E-Mail im DMS abgelegt werden soll. Andere:


RFC 2822 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenstän-dige Objekte Andere:







Suche nach E-Mails Aus dem E-Mail-Client Aus dem DMS-Client Volltextsuche im DMS für Mailbody Volltextsuche im DMS für Anhänge Wenn Volltextsuche in Anhängen: Welche Formate sind durchsuchbar?

Anzeige von E-Mails Im DMS-Viewer Im E-Mail-Client Andere:

System-getriebene E-Mail-Archivierung: MS ExchangeName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionVerfügbar für MS Exchange-Versionen:Plattform für E-Mail-Archivierungspro-zesse

Mailserver Die im Abschnitt ''DMS-Server-Plattform'' genannten Server sind identisch mit der Plattform für Mail-Archivierungsprozesse (Gateway-/Import-Server) Dedizierter Gateway-/Import-Server: Folgende im Abschnitt "DMS-Server-Plattform" genannten Plattformen werden unterstützt:

Folgende Archivregeln können definiert werden

Archivierung außerhalb des MS Exchange-Servers über SMTP-Schnitt-stelle Journaling-Archivierung (inkl. Mailsystem-interner Kommunikation) Archivierung definierter Benutzer- oder Benutzergruppenpostfächer Single Instance Storage für individuelle Mail-Objekte

Die Server-basierte E-Mail-Archivierung kann nach bestimmten Kriterien durch-geführt werden. Folgende Kriterien können als Auslöser definiert werden

Absenderadresse(n) Größe des Postfachs Größe eines Mail-Objektes Betreff-Informationen Andere:




Die Server-basierte E-Mail-Archivierung kann zeitgesteuert ausgelöst werden. Folgende Zeitpunkte können als Auslö-ser definiert werden

Zeitraum seit letztem Zugriff Sendedatum Zeitplan, z.B. festgelegter Tag und Uhrzeit Andere:

Ablageformat für E-Mail (inkl. Anhänge) MSG-Format RFC 2822 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenstän-dige Objekte Andere:






Archivierte E-Mail verbleibt weiter im Mail-System Archivierte E-Mail wird durch Mail mit Link oder Stub ersetzt Archivierte E-Mail wird im Mail-System automatisch gelöscht Mehrstufiges Vorgehen ist möglich. Die unter Antwort 1-3 genannten Vor-gehensweisen können zeitlich hintereinander ablaufen. Anders:

Suche nach E-Mails Aus dem MS Outlook-Client Aus dem DMS-Client Volltextsuche im DMS für Mailbody Volltextsuche im DMS für Anhänge Wenn Volltextsuche in Anhängen: Welche Formate sind durchsuchbar?

Anzeige von E-Mails Im MS Outlook Mail-Client Im DMS-Viewer Andere:

System-getriebene E-Mail-Archivierung: Lotus DominoName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionVerfügbar für Lotus Domino Server-Versionen:Plattform für E-Mail-Archivierungspro-zesse



Archivierung außerhalb des Lotus Notes-Servers über SMTP-Schnittstelle Journaling-Archivierung (inkl. Mailsystem-interner Kommunikation) Archivierung definierter Benutzer- oder Benutzergruppenpostfächer Single Instance Storage für individuelle Mail-Objekte





Ablageformat für E-Mail (inkl. Anhänge) NSF-Format DXL-Format RFC 2822 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenstän-dige Objekte Andere:










Suche nach E-Mails Aus dem Lotus Notes-Client Aus dem DMS-Client Volltextsuche im DMS für Mailbody Volltextsuche im DMS für Anhänge Wenn Volltextsuche in Anhängen: Welche Formate sind durchsuchbar?

Anzeige von E-Mails Im Lotus Notes Mail-Client Im DMS-Viewer Andere:

System-getriebene E-Mail-Archivierung: AndereName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionVerfügbar für Novell Groupwise-Versionen:

Andere Mail-Server:Plattform für E-Mail-Archivierungspro-zesse



Archivierung außerhalb des Mail-Servers über SMTP-Schnittstelle Journaling-Archivierung (inkl. Mailsystem-interner Kommunikation) Archivierung definierter Benutzer- oder Benutzergruppenpostfächer Single Instance Storage für individuelle Mail-Objekte





Ablageformat für E-Mail (inkl. Anhänge) RFC 2822 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenstän-dige Objekte Andere:










Suche nach E-Mails Aus dem E-Mail-Client Aus dem DMS-Client Volltextsuche im DMS für Mailbody Volltextsuche im DMS für Anhänge Wenn Volltextsuche in Anhängen: Welche Formate sind durchsuchbar?

Anzeige von E-Mails Im Mail-Client Im DMS-Viewer Andere:

Postkorb-FunktionenName der Postkorb-KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionDie Postkorb-Funktionalität wird von einer bereits genannten Server-Kompo-nente mit abgedeckt. Bitte Angabe der Komponente und Version

Ja, Bestandteil der Standard DMS-Komponenten und Version: Trotz Bestandteil der Standard DMS-Komponenten ist die Postkorbfunkti-onalität kostenpflichtig Andere Komponente und Version:

Vorgangsbildung Vorgänge können ohne Dokumente erzeugt werden Dokumentenbasiert, d.h. Dokumente bilden immer den Vorgang Zu einem Vorgang können n Dokumente gehören Vorgangsmetadaten sind unabhängig von Dokumenten-Metadaten

Die im Standard enthaltenen Funktio-nen für Postkörbe

Es können Einzelpostkörbe eingerichtet werden Es können Gruppenpostkörbe eingerichtet werden Mitarbeiter kann Arbeit aus anderen Postkörben übernehmen Vorgänge können in andere Postkörbe weitergeleitet werden Im Gruppenpostkorb ist für die Gruppe sichtbar, wer welchem Vorgang zugeordnet ist Postkorboberfläche ist vom Endbenutzer anpass- und speicherbar Postkorb erlaubt Archivrecherche und stellt die Trefferliste integriert in der Postkorboberfläche dar Postkorb erlaubt Aktenrecherche und stellt die Akte integriert in der Post-korboberfläche dar Zum Vorgang (nicht am Dokument!) können Notizen angebracht werden Das System speichert die Vorgangshistorie

Die Zustellung und Weiterleitung von Vorgängen nutzt zur Verteilung

das eigene System das Mail-System andere Dienste:

Die Verteilung der Postkorbvorgänge kann folgendermaßen definiert werden:

Der Anwender kann den Zielpostkorb aus einer Liste der verfügbaren Postkörbe auswählen Die Verteilung kann in einem tabellarischen Regelwerk (bspw. Zuordnung von Namensbereichen zu Postkörben) definiert werden Der Anwender kann ad hoc einen individuellen Workflow zur Verteilung eines Vorgangs definieren Die Verteilung kann in einem Workflow-Editor unter Nutzung von Prozess-modellierungselementen (Verzweigungen, kausale Prüfungen, Zusammen-führungen) definiert werden

Für die Pflege und Anpassung der Ver-teilregeln stehen folgende Werkzeuge zur Verfügung:

Für die Fachadministration steht ein GUI mit Tabelleneditor zur Pflege tabellarischer Regelwerke zur Verfügung Für die Fachadministration steht ein GUI mit einem grafischen Workflow-Editor zur Verfügung Die Verteilregeln werden in einem Werkzeug für die technische Administ-ration per Skript od. Programmierung angepasst

Folgende Wiedervorlagefunktionen sind im Standard enthalten

Wiedervorlage im Postkorb Wiedervorlage im Mail-Client Vorgänge können vor dem Ablauf der Wiedervorlagefrist in den Postkorb zurückgeholt werden

Folgende Eskalationsmechanismen stehen im Standard zur Verfügung

Erhöhung der Priorität des Vorgangs Mail an konfigurierten Anwender Weiterleitung an konfigurierten Anwender Andere:

Workflow / Business Process ManagementName der Komponente




HerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionDie Workflow/BPM-Funktionalität wird von einer bereits genannten Server-Komponente mit abgedeckt. Bitte Angabe der Komponente und Version

Ja, Angabe Komponente und Version: Andere Komponente und Version: Folgende Plattformen und Datenbanken für diese Komponente:

Positionierung Automation Dokumentenlebenszyklus: Erstellung, Versionierung, Geneh-migung, Freigabe, Publishing Postkorbanwendung: Bearbeitung elektronisch erfasster Dokumente BPM-Werkzeug zur Analyse, Implementierung und Überwachung beliebi-ger Geschäftsprozesse in beliebigen Hintergrundumgebungen, Dokumen-ten-zentrische Prozesse BPM-Werkzeug zur Analyse, Implementierung und Überwachung beliebi-ger Geschäftsprozesse in beliebigen Hintergrundumgebungen, Prozesse sind unabhängig von Dokumenten

Plattform für BPM/Workflow Der BPM-/Workflow-Server ist identisch mit dem Server, der in folgendem Abschnitt genannt wurde: Dedizierter Server: es werden alle Plattformen unterstützt, die in folgen-dem Abschnitt genannt wurden: Dedizierter Server: folgende Plattformen und Datenbanken werden unter-stützt:

Die Software bietet folgende Werkzeuge zur Abbildung/Modellierung von Abläu-fen/Prozessen

Grafischer Editor Grafischer Editor + Skripting Skripting Programmierung Andere:

Prozessdefinitionen können importiert werden, es werden folgende Beschrei-bungssprachen / Notationen unter-stützt:

XPDL BPEL EPK (Ereignisgesteuerte Prozessketten) BPMN Ablaufmodelle in folgenden Quelldateiformaten: Andere:

Prozessdefinitionen können exportiert werden, es werden folgende Beschrei-bungssprachen unterstützt:

XPDL BPEL EPK (Ereignisgesteuerte Prozessketten) BPMN Ablaufmodelle in folgenden Dateiformaten: Andere:

Welche Möglichkeiten bestehen, die Aufbauhierarchie des Unternehmens in den Prozessen zu berücksichtigen?

Die Aufbauhierarchie muss in der Workflow-Anwendung gepflegt werden Es stehen Standard-Schnittstellen zur Verfügung, um die Aufbauhierar-chie aus den Verzeichnissen externer Anwendungen auslesen zu können. Standard-Schnittstellen zu folgenden Anwendungen sind vorhanden:

Folgende, weitere Funktionen sind in der in diesem Abschnitt genannten Komponente im Standard enthalten

Zeitüberwachung Protokollierung und Logging Eskalationsmechanismen, Event-getriggert Simulationstool zum Testen der Prozess-Definitionen

Collaboration-FunktionenName der KomponenteHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Aktuelle VersionDie Collaboration-Funktionalität wird von einer bereits genannten Server-Komponente mit abgedeckt.

Ja, Komponente und Version: Andere Komponente und Version:




Folgende Funktionen sind in der Kompo-nente ''Collaboration'' im Standard ent-halten

Virtuelle Projekträume Team-Kalender Anwesenheit/Online-Status eines Anwenders kann angezeigt werden Terminüberwachung Kontaktverwaltung White-Board Newsgroups / Diskussionsforen Projektplanungswerkzeuge Dokumentenablage Wiki Blog Weitere:

Bitte geben Sie diejenigen Komponen-ten an, an die Dokumente angeheftet werden können

Virtuelle Projekträume Team-Kalender Kontakte Terminüberwachung White-Board Newsgroups / Diskussionen Projektplanungswerkzeuge Dokumentenablage Wiki Blog Weitere:

Die Synchronisierungsfunktion mit MS-Outlook steht für folgende in der Colla-boration-Umgebung verwalteten Objekte zur Verfügung

Kalendereinträge Kontakteinträge Andere:

Die Synchronisierungsfunktion mit Notes steht für folgende der Collabora-tion-Objekte zur Verfügung

Kalendereinträge Kontakteinträge Andere:

Das System weist den Anwender auf geänderte Inhalte aktiv hin

Kennzeichnung der geänderten Objekte Mail-Versand mit Hinweis auf geänderte Objekte Abonnement-Funktion (z.B. RSS-Feed) Anders:

Signatur-FunktionenDie Softwarekomponenten zum Signie-ren von Dokumenten sind:

eigene Produkte für: Drittprodukte für:

Name der Komponenten Erstellung Einzelsignatur:Erstellung Massensignatur:Verwaltung Signaturen:Signaturprüfung, automatisch:Signaturprüfung, manuell:Nachsignatur:Weitere:

Die folgenden Arten von Signaturen können standardmäßig verwaltet werden

Zeitstempel Qualifizierte Zeitstempel fortgeschrittene Signatur qualifizierte elektr. Signatur (QeS)

Die Signatur-Lösung kann standardmä-ßig in folgende DMS-Erfassungskompo-nenten integriert werden

Scan-Anwendung Office-Integration Archiv-Server Postkorb-System Andere:

Art der Speicherung für eine digitale Sig-natur

Begleitende Signatur (in der DMS-DB oder als eigenes Objekt) Integrierte Signatur (im Objekt/Dokument) Content-Signatur (nur die relevanten Teile eines Dokumentes werden sig-niert)

Es können unterschiedliche Signatur-Typen (unterschiedliche Root-Zertifi-kate) in der Anwendung verwaltet wer-den.

Standard Customizing programmierbar Nein, folgende Einschränkungen:




Verwaltung der Verknüpfungen zwi-schen Archivobjekt und elektronischer Signatur im DMS-Server

Eingebettete Signatur im Archivobjekt Speicherung im gleichen Verzeichnis, wie das Archivobjekt Verwaltung der Zusammengehörigkeit über Datenbanktabellen Andere:

Verfahren zur Überprüfung der Gültig-keit genutzter Zertifikate (Bsp. Online-Prüfung gegen einen Verzeichnisdienst)

Online-Prüfung Dynamisches Laden der Sperrlisten vom Trust-Center Zyklisches Einlesen der Sperrlisten

Aufbewahrung von Prüfprotokolle Ablage als eigenes Objekt im elektronischen Archiv Speicherung in der Datenbank Andere:

Die Ergebnisse der Prüfungen der elek-tronischen Signaturen werden in Prüf-protokollen festgehalten

Standard Customizing programmierbar Nein

Funktionen zur Prüfung von Signaturen Für ein Dokument wird im DMS-Standard-Viewer angezeigt, ob eine Signa-tur vorhanden ist Die Signatur kann im DMS-Standard-Viewer manuell geprüft werden Beim Anzeigen im DMS-Standard-Viewer findet automatisch eine Prüfung der Signatur statt Einsatz eines speziellen Viewers bei Objekten mit qualifizierter Signatur

Die Prüfung beinhaltet in einem Schritt sowohl die Prüfung der objektbezoge-nen Signatur als auch der Nachsignatu-ren und fasst alle Ergebnisse in einer einheitlichen Darstellung zusammen

Standard Customizing programmierbar Nein

Standards und ZertifikateCMIS-kompatibles Repository (Server) in Archiv-Komponente als Standardfunktion enthalten

in Collaboration-Komponente als Standardfunktion enthalten in DMS-Komponente als Standardfunktion enthalten

Integrierter Zugriff auf CMIS-kompatible Repositories

im Archiv-Client als Standardfunktion enthalten im Collaboration-Client als Standardfunktion enthalten im DMS-Client als Standardfunktion enthalten

JSR-283 (JCR 2.0) kompatibles Reposi-tory (Server)

in Archiv-Komponente als Standardfunktion enthalten in Collaboration-Komponente als Standardfunktion enthalten in DMS-Komponente als Standardfunktion enthalten

Integrierter Zugriff auf JSR-283 (JCR 2.0) kompatible Repositories


WebDAV-kompatibles Repository (Ser-ver)

in Archiv-Komponente als Standardfunktion enthalten in Collaboration-Komponente als Standardfunktion enthalten in DMS-Komponente als Standardfunktion enthalten

Integrierter Zugriff auf WebDAV-kompa-tible Repositories


SMB/CIFS-kompatibles Repository in Archiv-Komponente als Standardfunktion enthalten in Collaboration-Komponente als Standardfunktion enthalten in DMS-Komponente als Standardfunktion enthalten

Weitere DMS-relevante ZertifikateSchnittstellen zu SAPZertifizierte Standardschnittstelle für ArchiveLink-Schnittstellenversion BC-AL 6.20

Zertifizierung durch SAP ist erfolgt

Plattform für die ArchiveLink-Schnitt-stelle

Der im Abschnitt ''DMS-Server-Plattform'' genannte Server ist identisch mit dem ArchiveLink-Schnittstellen-Server Dedizierter Server: folgende Plattformen und Datenbanken werden unter-stützt:

Name der KomponenteHerstellerAnzahl Kunden in D.A.CH.Zertifizierter SAP ArchiveLink Load-Test Ja, wurde für folgende im Abschnitt ''DMS-Server-Plattform'' genannten

Server-Plattformen durchgeführt:




Zertifizierte Standardschnittstelle für SAP ILM - WebDAV Storage Interface 3.0 (BC-ILM 3.0)

Zertifizierung durch SAP ist erfolgt

Plattformen für die SAP ILM WebDAV Storage-Schnittstelle

Der im Abschnitt ''DMS-Server-Plattform'' genannte Server ist identisch mit dem SAP ILM WebDAV Storage-Schnittstellen-Server Dedizierter Server: Folgende Plattformen und Datenbanken werden unter-stützt:

Name der KomponenteHerstellerAnzahl Kunden in D.A.CH.Schnittstelle zur Übertragung von SAP-Belegdaten in das DMS

Standardkomponente vorhanden

HerstellerAnzahl Kunden in D.A.CH.Aktensichten auf Dokumente Standardkomponente vorhandenTechnologie der Aktensicht auf Doku-mente

Verknüpfung von DMS-basierten Akten über die ArchiveLink-Schnittstelle anstelle einzelner Dokumente Anzeige und Interpretation von im DMS verwalteten Akten mit SAP-Tech-nologie SAP-Anwendung mit Verwaltung und Darstellung von Aktenstrukturen in der SAP-Datenbank

Template-Aktensichten für SAP Vorlage für Kundenakte Vorlage für Lieferantenakte Vorlage für Personalakte Vorlage für Vertragsakte

Anzahl Kunden in D.A.CHSchnittstellen zu weiteren führenden Anwendungen (z.B. ERP)Standardschnittstelle für Microsoft ERP Lösung Dynamics NAV

Name der Komponente:Für die Microsoft Dynamics NAV-Version(en): Verknüpfung für eingehende Papierdokumente Verknüpfung für eingehende und ausgehende E-Mails. Bitte machen Sie Angaben, welche E-Mail-Systeme hierbei unterstützt werden.: Verknüpfungsschnittstelle für andere PC-Dateien Verknüpfung für in der Anwendung erstellte Ausgangsdokumente

Standardschnittstelle für Microsoft ERP Lösung Dynamics AX

Name der Komponente:Für die Microsoft Dynamics AX-Version(en): Verknüpfung für eingehende Papierdokumente Verknüpfung für eingehende und ausgehende E-Mails. Bitte machen Sie Angaben, welche E-Mail-Systeme hierbei unterstützt werden.: Verknüpfungsschnittstelle für andere PC-Dateien Verknüpfung für in der Anwendung erstellte Ausgangsdokumente

Standardschnittstelle für ADP / Paisy Name der Komponente:Für die ADP Paisy-Version(en): Verknüpfung für eingehende Papierdokumente Verknüpfung für eingehende und ausgehende E-Mails. Bitte machen Sie Angaben, welche E-Mail-Systeme hierbei unterstützt werden.: Verknüpfungsschnittstelle für andere PC-Dateien Verknüpfung für in der Anwendung erstellte Ausgangsdokumente

Standardschnittstelle für Oracle Finan-cials

Name der Komponente:Für die Oracle Financials-Version(en): Verknüpfung für eingehende Papierdokumente Verknüpfung für eingehende und ausgehende E-Mails. Bitte machen Sie Angaben, welche E-Mail-Systeme hierbei unterstützt werden.: Verknüpfungsschnittstelle für andere PC-Dateien Verknüpfung für in der Anwendung erstellte Ausgangsdokumente

Standardschnittstelle für Infor Name der Komponente:Für die Infor-Version(en): Verknüpfung für eingehende Papierdokumente Verknüpfung für eingehende und ausgehende E-Mails. Bitte machen Sie Angaben, welche E-Mail-Systeme hierbei unterstützt werden.: Verknüpfungsschnittstelle für andere PC-Dateien Verknüpfung für in der Anwendung erstellte Ausgangsdokumente




Angaben zu Standard-Schnittstellen zu weiteren AnwendungssystemenSharePoint IntegrationSchnittstellen-Funktionalität wird von einer bereits genannten Komponente mit abgedeckt

Ja, Komponentenname und Version:

Name der KomponenteAktuelle VersionHerstellerAuf dem Markt seit (Datum)Anzahl Kunden in D.A.CH.Unterstützte SharePoint-Version Microsoft Office SharePoint Server 2007

Microsoft SharePoint Server 2010Unterstützte Komponente(n) Komponentenname und Version:SharePoint-Schnittstelle unterstützt Single-Sign-on

Als Standardfunktion enthalten

Dokumente aus SharePoint-Bibliothe-ken werden automatisch in das DMS überführt und mit den unter SharePoint bekannten Metadaten abgelegt.


Dem Administrator steht ein Werkzeug zur Verfügung, das eine Zuordnung von SharePoint-Dokumenten-Metadaten zu DMS-Dokumenten-Metadaten ermög-licht.


Die in der SharePoint-Dokumentenbibli-othek angelegten Ordnerstrukturen werden mit den Ordnerstrukturen des DMS automatisch abgeglichen

SharePoint -> DMS DMS -> SharePoint

Im DMS abgelegte Dokumente (Office-Formate und PDF) können über die Schnittstellenkomponente in den Voll-textindex von SharePoint aufgenommen werden. (DMS als Inhaltsquelle in SharePoint)


Metadaten, von im DMS abgelegten Dokumenten, können über die Schnitt-stellenkomponente in den Volltextindex von SharePoint aufgenommen werden.


Über SharePoint-Volltextsuche gefun-dene Dokumente im DMS werden gemeinsam mit Content aus anderen Inhaltsquellen in der SharePoint-Treffer-liste angezeigt


Über SharePoint-Oberflächen kann direkt in Ordnern / Akten des DMS navi-giert und angezeigt werden


Über SharePoint-Oberflächen können Ordner / Akten des DMS geändert werden


Über SharePoint-Oberflächen können elektronische Postkörbe des DMS ange-zeigt und bearbeitet werden


Benachrichtigung im persönlichen SharePoint-Bereich (My Site) bei neuen Postkorbeinträgen im DMS


Weitere KomponentenName der KomponenteHersteller

Documents

Dokumenten Management Systeme Marktübersicht 2013 · 2016-01-15 · III.1 Abgrenzung ECM und DMS Enterprise Content Management (ECM) hat sich seit vielen Jahren als Gattungsbegriff