Dokumenten Management Systeme

Transcription

Dokumenten Management Systeme
Marktübersicht 2013
Hersteller und Produkte
Erstellt durch
Zöller & Partner GmbH
www.zoeller.de
Impressum
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 berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- 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 elektronische Version dieser Marktübersicht darf zu Sicherungszwecken kopiert werden, dabei müssen aber die
urheberrechtlichen Ansprüche gewahrt bleiben.
Seite b
September 2012
© Zöller & Partner GmbH
Verzeichnisse
INHALTSVERZEICHNIS
I
Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
II
Grußwort des Herausgebers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
III Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
III.1
III.2
III.3
III.4
III.5
III.6
III.7
III.8
III.9
Abgrenzung ECM und DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Warum Anwender in DMS-Lösungen investieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Verwirrende Begriffs- und Angebotsvielfalt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
„Ich dachte, das ist Standard“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Boom im Mittelstand: von den Großen vernachlässigt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Vorbemerkungen zur DMS Marktübersicht 2013 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Allgemeines zu den Anbietern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Aufbau der Marktübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Erläuterungen zu den Angaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
IV Erläuterungen zu den Abschnitten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
IV.1
IV.2
IV.3
IV.4
IV.5
IV.6
IV.7
IV.8
IV.9
IV.10
IV.11
IV.12
IV.13
IV.14
IV.15
IV.16
IV.17
IV.18
V
DMS-Server-Plattform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Digitalisieren und Indexieren von Papierdokumenten (Capture-/Scan-Komponenten) . . . . . . 10
Capture OCR, Klassifikation, Index-, Datenextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Capture-Komponente für strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Capture-Komponente für zentralen Druckoutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
DMS-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Aktenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
E-Mail-Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Postkorb-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Workflow / Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Collaboration-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Signatur-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Standards und Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Schnittstellen zu SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Schnittstellen zu weiteren führenden Anwendungen (z.B. ERP) . . . . . . . . . . . . . . . . . . . . . . . . . 40
SharePoint-Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Weitere Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Erläuterungen zu den Fragen in den einzelnen Abschnitten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
V.1
V.2
V.3
V.4
V.5
V.6
V.7
V.8
V.9
V.10
V.11
V.12
V.13
V.14
V.15
V.16
V.17
V.18
V.19
V.20
V.21
V.22
Stammhaus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Allgemeine Angaben zum Anbieter in Deutschland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Allgemeine Angaben zum Anbieter in Österreich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Allgemeine Angaben zum Anbieter in der Schweiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Mitarbeiteranzahl im Bereich DMS/ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Umsätze im Bereich DMS/ECM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Spezifische Einsatzfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
DMS-Server-Plattform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Capture-/Scan-Funktionen im Anwender-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Eigenständige Capture-/Scan-Komponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Capture OCR, Klassifikation, Index-, Datenextraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Capture-Komponente für strukturierte Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Capture-Komponente für zentralen Druckoutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Archivierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
DMS-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Aktenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Client-basierte E-Mail-Archivierung: MS Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Client-basierte E-Mail-Archivierung: Lotus Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Client-basierte E-Mail-Archivierung: Andere Mail-Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
System-getriebene E-Mail-Archivierung: MS Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
System-getriebene E-Mail-Archivierung: Lotus Domino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
System-getriebene E-Mail-Archivierung: Andere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
September 2012
Seite c
Verzeichnisse
V.23
V.24
V.25
V.26
V.27
V.28
V.29
V.30
V.31
Postkorb-Funktionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workflow / Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collaboration-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signatur-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standards und Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schnittstellen zu SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schnittstellen zu weiteren führenden Anwendungen (z.B. ERP) . . . . . . . . . . . . . . . . . . . . . . . . .
SharePoint Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
57
57
58
58
59
59
60
61
VI Anbieterübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
VI.1
VI.2
VI.3
VI.4
VI.5
VI.6
VI.7
VI.8
VI.9
VI.10
VI.11
VI.12
VI.13
VI.14
VI.15
VI.16
VI.17
VI.18
VI.19
VI.20
VI.21
VI.22
VI.23
VI.24
VI.25
VI.26
VI.27
VI.28
VI.29
VI.30
VI.31
VI.32
VI.33
VI.34
VI.35
VI.36
VI.37
VI.38
VI.39
VI.40
VI.41
VI.42
VI.43
VI.44
VI.45
VI.46
VI.47
VI.48
Seite d
Ainea AG: Ainea-Pergamon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Akzentum GmbH: PROXESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Alfresco Software Ltd.: Alfresco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Allgeier IT Solutions: scanview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
BDV Branchen-Daten-Verarbeitung GmbH: Uniarchiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Bernhard Starke GmbH: Starke-DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Beta Systems Software AG: Beta UX ContentMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Braintribe Holding GmbH: Content Service Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Canon Deutschland GmbH: Therefore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
CC e-gov GmbH: CC DMS® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Ceyoniq Technology GmbH: nscale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
COI GmbH: COI BusinessFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Comarch Swiss AG: COMARCH ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Consolidate Software GmbH & Co.KG: Consolidate C4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
d.velop AG: d.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
d.velop: ecspand. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Dieter Spielberg Document Management Systems GmbH: FileDirector. . . . . . . . . . . . . . . . . . 362
DM Dokumenten Management GmbH: lobo-dms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
DMSFACTORY GmbH: TINCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
DocuPortal: DocuPortal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
DocuWare AG: DocuWare 5.1x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Dr.DOC GmbH: Dr.DOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Drivve: drivve/DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
EASY SOFTWARE AG: EASY DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
EASY SOFTWARE AG: EASY ENTERPRISE.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
ELO Digital Office GmbH: ELOenterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
ELO Digital Office GmbH: ELOoffice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
ELO Digital Office GmbH: ELOprofessional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
EMC Deutschland GmbH: Documentum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
Fabasoft AG: Fabasoft Folio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Fasihi GmbH: Fasihi Enterprise Portal/feb2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
forcont business technology GmbH: forcont factory FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Gräbert Software + Engineering GmbH: ArchivPlus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
H&S Heilig und Schubert Software AG: PAM-STORAGE®. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
HABEL GmbH & Co. KG: HABEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Hans Held GmbH Büroorganisation: REGISAFE public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Hyland Software, Inc.: OnBase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
IBM: DB2 Content Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
IBM: FileNet P8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
INTENSIO GmbH: NOVIPLAN-DMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
IQDoQ GmbH: HyperDoc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798
IQUADRAT AG: PHOENIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820
Kendox AG: Kendox InfoShare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 832
LIB-IT DMS GmbH: FILERO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854
Microsoft Deutschland GmbH: Microsoft SharePoint Server 2013 . . . . . . . . . . . . . . . . . . . . . 869
Multi-Support R&D A/S: Multi-Support Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882
Open Text: Open Text ECM Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Optimal Systems GmbH: OS|ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928
September 2012
VI.49
VI.50
VI.51
VI.52
VI.53
VI.54
VI.55
VI.56
VI.57
VI.58
VI.59
VI.60
VI.61
VI.62
Verzeichnisse
OXSEED AG: OXSEED Plattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952
Perceptive Software: ImageNow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969
proALPHA Software AG: proALPHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989
PROCAD: PRO.FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006
SAP Deutschland AG & Co. KG: SAP ECM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1020
SAPERION AG: SAPERION ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1038
SER Solutions Deutschland GmbH: DOXiS4 iECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
SI Software Innovation GmbH: LDMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079
softgate GmbH: softgate-archiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094
Softwarebüro Krekeler: Office Manager Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112
T-Systems International GmbH: ECM Suite ImageMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1127
UPTIME services AG: ARTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144
WeWebU Software AG: WeWebU OpenWorkdesk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1161
windream GmbH: windream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175
September 2012
Seite e
Verzeichnisse
Seite f
September 2012
I
Vorwort
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ältiger Markt entwickelt, der die Vorteile solcher Lösungen auch für kleinere und mittlere Unternehmen 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 Wettbewerb 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 sicherzustellen, 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 Nowottka
Vorstandsvorsitzender 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ünftigen Publikationen berücksichtigen.
Ob Sie die folgenden Seiten am Bildschirm oder auf Papier lesen, ich wünsche Ihnen eine erfolgreiche 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 Informationen zu weiteren Marktberichten und Dienstleistungen, die wir anbieten.
Dr. Axel Pols
Geschäftsführer Bitkom Research GmbH
September 2012
Seite 1
Einleitung
III
Einleitung
Seit mehr als inzwischen einem Vierteljahrhundert werden DMS-Lösungen in Behörden und Unternehmen eingesetzt und mit ihrer Hilfe werden vielfach Arbeitsprozesse deutlich effizienter abgewickelt als vor deren Einsatz.
Trotz dieser für EDV-Anwendungen langen Historie erscheint der Markt für DMS-Lösungen intransparent. 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 Produktunterschiede 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 Standard 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 Darstellungstiefe 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 Informationen aller Art zu verwalten, vorzuhalten und in unterschiedlichste Geschäftsprozesse zu integrieren. Im deutschsprachigen Markt gibt es mit solchen Anglizismen aber immer auch Abgrenzungsprobleme. 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 abgelegt 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 deutschsprachigen 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 assoziieren 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 DMSBegriffs 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.
Seite 2
September 2012
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 Abbildung 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 Archivsysteme kaufen musste, sind lange vorbei. Die Funktion Archivierung ist aber selbstverständlich 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 DMSLö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 Management, 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.
September 2012
Seite 3
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 Management“ 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 Unternehmens.
In einem Umfeld wachsender Sensibilisierung für mangelnde Ordnungsmäßigkeit, nicht vorhandener 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 Dokumentenbasierter Prozesse stehen weit oben auf der Prioritätenliste vieler Unternehmen und Organisationen, 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
Seite 4
September 2012
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 Handlungsoption als die Einführung einer DMS-Lösung, wenn sie Dokumenten-basierte Prozesse effizienter 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äßigkeit ist schon lange verloren gegangen. Das gilt für archivierte Belege ebenso wie für lebende Dokumente und für Unternehmen und Organisationen in allen Branchen und unabhängig von der Unternehmensgröße.
Häufige Triebfedern sind der wachsende Druck, Aufbewahrungspflichten und Dokumentationspflichten 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, „Revisionssicherheit“, „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 „Dokumenten 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 Anwendungslandschaft 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 verschiedenen Angebote der Hersteller.
Für den Neueinsteiger ebenfalls verwirrend ist die Unübersichtlichkeit der Angebote. Die angebotenen ECM-Systeme in den unterschiedlichen Produktkategorien – wie Archivierung, Dokumenten
Management, Records Management, Collaboration etc. – verfügen zwar alle über „Dokumentenverwaltende“ 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.
September 2012
Seite 5
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ückzufü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 dauerhaft, 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 Anforderungen einzuschätzen. Daher werden die für ein erfolgreiches Projekt wichtigen Detailunterschiede, vor allem in der Funktionalität und Benutzerfreundlichkeit, aber auch bei Verwaltungsfunktionen, Architektur und Skalierbarkeit und den Werkzeugen zur Anpassung an die individuellen
Anforderungen erst sehr spät im Projektverlauf sichtbar, im schlimmsten Fall erst nach Vertragsabschluss. Typisch ist eine komplett falsche Einschätzung der Dienstleistungsaufwendungen: Unter
der Annahme, dass bestimmte Funktionen feststehende Bedeutungen haben („Akte“, „Arbeitskorb“, „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 Werkzeuge 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. Aktenfunktionen, 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 vorhandene Vielfalt an Angeboten auf dem Markt ist.
Seite 6
September 2012
III.6
Einleitung
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 architektonischer, 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 Betrachtung, 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 ergonomischer 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 Attachments 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 vorliegende 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, Protokollierung der Transaktionen, Statistiken und Auswertungen, Fehlerhandling
•
Entwicklungswerkzeuge zur Anpassung des DMS, Entwicklung und Pflege eigener Anwendungen 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?
September 2012
Seite 7
Einleitung
III.7
•
Dem Projekt zugeordnete Mitarbeiter: Projekt- und Produkterfahrungen
•
Export- und Importwerkzeuge für Individual- und Massenprozesse
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, Österreich 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änzungskomponenten darstellen. Beides hätte zur Folge, dass mehrere Hundert Systemlösungen aufgenommen 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 Frageabschnitten 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äuterungskapitel. 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 Einzelfragen 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 Produktfunktion 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 anerkannt. Wir haben jedoch generell um die Angabe der Zulieferer solcher Komponenten gebeten.
Seite 8
September 2012
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 ITSegmenten anbieten und eine Trennung der Umsätze nach Herkunft häufig schwierig, wahrscheinlich sogar unmöglich ist (zu welchen Anteilen werden Server und Speicher dem DMS-Bereich zugeordnet?). 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 Vertriebspartnern. Durch solche Aspekte taugen die veröffentlichten Umsatzzahlen (falls sie überhaupt veröffentlicht 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öffentlichten 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.
September 2012
Seite 9
Erläuterungen zu den Abschnitten
IV
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 Kapiteln, in denen Zusatzkomponenten beschrieben werden, welche häufig auf eigenständigen Serversystemen 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 Aktenverwaltung 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übersicht 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übersicht 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 Systemumgebung 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 LinuxDistributionen 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 Plattformen 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 DMSProjekten ist. Diese Erfahrung bezieht sich leider nicht nur auf das sogenannte Scannen und Indexieren von Dokumenten, sondern oft auf den gesamten Erfassungsprozess, also von der Vorbereitung der Papierdokumente für das Scannen bis hin zu einer möglichen Einlagerung (z.B. für Dokumente 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 Dokuments 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-Anwendung, und daher ein sehr wichtiger und nicht zu unterschätzender Prozessschritt ist.
Seite 10
September 2012
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 sinnvoll 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-hocScannen“ 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 Posteingang zu bündeln und in einer zentralen Organisationseinheit einen Erfassungsprozess zu implementieren, der eine effektive und qualitativ hochwertige Digitalisierung des hochvolumigen Papierposteingangs 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 Dokumentenerfassungsprozessen – 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 Digitalisierungsmassengeschä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 IndexSoftware. 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 Dokumentenklammer erhalten bleiben, was häufig durch Separieren anhand von Barcode-/PatchcodeBlä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 Arbeitsplatzscannen 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 Prozesskosten. 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 Teilkomponente einer gesamtheitlichen Dokumentenerfassung betrachtet wird: Die Scan- und IndexSoftware. Die Ausführungen zuvor haben aber verdeutlicht, dass für einen wirtschaftlichen Erfassungsprozess erheblich mehr organisatorische und auch technische Rahmenbedingungen berücksichtigt 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 Funktionen 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.
September 2012
Seite 11
Nun aber zu den Inhalten der Marktübersicht:
Grundsätzlich sollte der DMS-Anbieter angeben, welche Komponenten er für die Capture-/ScanFunktionen 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-, Bildverbesserungs- oder Konvertierfunktionen als OEM-Komponenten fremder Hersteller standardmäßig
in die Lösung integriert wurden. Erfahrungsgemäß kann die Einbindung von spezieller Kofax-Hardware 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 unterscheiden: 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-Scanning 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 PatchcodeTrennblätter statt, wobei wir damit die nächste Anforderung an eine stapelbasierte Dokumentenerfassung ansprechen: Welche Barcodes bzw. Patchcodes werden von der Capture-Lösung grundsätzlich erkannt und können inhaltlich interpretiert werden. Die wohl verbreitetsten eindimensionalen 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 Hilfsmitteln 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 Bildverbesserungsmechanismen im Capture-Umfeld. Auf den ersten Blick scheinen die zuvor angesprochenen 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 eliminieren (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 ScanLö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 Dokumenten, wie z.B. Plänen und Konstruktionszeichnungen, sind hochkomprimierte Dateiformate interessant. Diese beruhen auf Wavelet-Transformation und generieren sehr kleine Dateigrößen. Auch
Angaben hierzu sind vom DMS-Anbieter möglich gewesen.
Seite 12
September 2012
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 extrahiert 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 Indexanwendung. 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-Indexierkomponente 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 Digitalisierungseinheiten, 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 Produkterweiterungen 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 unmittelbar über die DMS-Software nutzen, wobei die Geräte über einfache Treiber, vornehmlich TWAINTreiber, 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 aufgebaut 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 mitgelieferten, 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 eigenstä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.
September 2012
Seite 13
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 Subsystemen. Da nur einige DMS-Anbieter eigene Module entwickeln, werden oftmals Kooperationen mit
Anbietern entsprechender Erkennungsprodukte eingegangen, was aus funktionaler Sicht oft ausreichend 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 nachfolgend dargestellten Produktkategorien.
Produktkategorie
Typischer Funktionsumfang
Einsatzmöglichkeiten und
Anwendernutzen
OCR-Tipphilfe
• Ad-hoc-Auslesen von markierten
• Ersparen von „Tipparbeit“ und VermeiDokumentinhalten
dung von Eingabefehlern, vor allem
bei komplexen Zeichenketten,(Bestell• Typischerweise Client-basiert
nummer, Artikelnummer, Adressangaben, etc.)
• Nutzung bei der manuellen Indizierung von Dokumenten
Volltext-OCR
• Volltext-Erkennung aller Dokumentin- • Inhaltserschließung bei Verträgen,
halte
Presseartikeln, etc.
• Bereitstellung der Inhalte zur Volltext- • Suche nach Dokumenten unabhängig
indizierung und Volltextsuche
von der Dokumentart über gemeinsame Inhalte
Formularbasierte Beleg- • Auslesen von strukturierten Doku• Datenextraktion bei Antrags-, Bestelllesung, Zonen-OCR
mentinhalten
formularen, etc.
• Verwaltung von Formulardefinitionen • Automatische Indexierung von Dokufür das Auslesen von Feldern
menten bzw. Datenerfassung in Fachanwendungen
Freiform-Beleglesung
• Auslesen von unstrukturierten Doku- • Datenextraktion bei Eingangsrechmentinhalten
nungen, E-Mails, Eingangspost, etc.
• Verwaltung von Regelwerken für die
• Automatische Indexierung von DokuBeleganalyse
menten
• Funktionen zur Systemoptimierung
• Automatische Übernahme von Daten
(„Training“)
in Fachanwendung (z.B. ERP-System)
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, Krankenkassendokumente 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 Freiformerkennung der gesamten Eingangspost gleichermaßen gut geeignet ist.
Ein häufiger Anwendungsfall für den Einsatz von Erkennungslösungen ist die Eingangsrechnungsverarbeitung. 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 elektronisch ausgetauschten Rechnungsformaten achten.
Seite 14
September 2012
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 Rechnungsdaten 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 Weiterverarbeitung von E-Mails, da diese weniger strukturiert sind als die eingehende Geschäftspost in Papierform 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 eingesetzten Scanner, die teilweise eigene integrierte Bildoptimierungsfunktionen bieten.
Die inhaltliche Erschließung von Dokumentinhalten erfolgt oftmals auf Basis verschiedener Merkmale. 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 Tabellenstrukturen (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 selbstständig und impliziert an, wenn ein Anwender bspw. die erkannten Inhalte bestätigt oder korrigiert.
September 2012
Seite 15
•
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 Erkennungsergebnisse weiter zu verbessern. Auf Basis der Einzelergebnisse unterschiedlicher ErkennungsEngines 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 ScanStapel an. Gerade gemischtes Beleggut verlangt oftmals eine manuelle Zusortierung von Trennblättern 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 Abrechnung und ich bitte um die Zusendung von Information zum Produkt “?). Hier lassen sich Dokumentenklassen nicht immer ausreichend genau unterscheiden. Nützlich sind aussagefähige Statistikfunktionen, 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:
Bezug
Beleg
Seite
Feld
Zeichen
Erkennungsrate = 99%
Von 500 Belegen werden 5 nicht vollständig korrekt verarbeitet
Von 1.000 Seiten werden 10 Seiten
nicht erkannt
Von 3.000 Feldern werden 30 Felder
nicht erkannt
Von 24.000 Zeichen werden 240 Zeichen nicht erkannt
Beleg-Nachbearbeitung
5 Belege (1%)
Worst case: 10 Belege (2%)
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 Klassifizierung. Diese kann bei möglicherweise geringerem Einrichtungsaufwand, einen höheren Trainingsaufwand, 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 Überprüfung einer gelesenen Kontoverbindung im Fußteil einer Rechnung. Ist eine „Dunkelverarbeitung“, 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.
Seite 16
September 2012
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 Korrekturen 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 Transaktionssicherheit und Vollständigkeit bei der Übergabe von Dokumenten und Daten.
Für die Überwachung und Optimierung des gesamten Erkennungsprozesses sind statistische Informationen 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äsentativen Dokumenten und Dokument-Stapeln wichtig – möglichst mit den eigenen Scannern digitalisiert. 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ändigkeitskontrolle
Anzahl 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 Kostenreduzierung 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.
September 2012
Seite 17
IV.4
Capture-Komponente für strukturierte Daten
In vielen Bereichen der Kommunikation zwischen Unternehmen (Business-to-Business; B2BKommunikation) 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-Anwendern die Anforderung, diese Unterlagen in das DMS übernehmen und ordnungsgemäß aufbewahren (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 abgefragten Erfassungskomponenten häufig auch für den Massenimport unstrukturierter, elektronischer Dokumente (bspw. zentraler PDF-Druckoutput aus Fachanwendungen oder für die Übernahme 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 elektronischer 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 entsprechender Fehlerquote auszulesen.
Eine zentrale Frage in diesem Kapitel lautet: Welche Import-Szenarien werden unterstützt?
Seite 18
September 2012
Das Ziel bei der Realisierung der Import-Szenarien ist immer, ein robustes Verfahren zu implementieren, 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 mitzugeben, so dass die Erfassungskomponente den Dateinamen nach festgelegten Regeln analysiert, zerteilt und die Metadaten des Dokuments daraus extrahiert. Aufgrund der Längenbegrenzung 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 MetadatenDefinitionen 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 Massenimport 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 FehlerQueues und Fehlerprotokolle geführt, so dass zum einen fehler- oder problemhafte Dateien aussortiert 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.
September 2012
Seite 19
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 Dokumentenerstellung, -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 Visualisierung (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 1403Druckspool, 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 integrieren 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öglichen 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 ebenfalls 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 Archivierung, 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 speicherintensive 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 Speicherbedarf von bis zu mehreren Hundert Kilobyte (pro Dokumentdatei wohlgemerkt) bedeuten würde. Mit
Seite 20
September 2012
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 übertragen 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/AFormat“ mit gleichwertiger, langfristiger Reproduktionsfähigkeit mit einem Bruchteil der Speicherund Übertragungsanforderungen zu wählen. Der entsprechende Fragenabschnitt der Marktübersicht 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 spezialisierter 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ändige 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 „Archivierung“ 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 Produktivsystemen 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ügbarkeit (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-MailSystemen. 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.
September 2012
Seite 21
•
Definition III: Dauerhafte Aufbewahrung von Gegenständen und Unterlagen aus kulturhistorischen 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 Bundesarchivar (für Deutschland: in Koblenz) Verfügungsrecht besitzen: Gemeinden, öffentlich-rechtliche Organisationen und andere öffentliche Einrichtungen sind verpflichtet, im Vorfeld einer
geplanten Vernichtung die Unterlagen einer übergeordneten Archivdienststelle zur dauerhaften Archivierung anzubieten, da diese den Auftrag hat, kulturhistorisch wertvolle Informationen 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äuterungen und Interpretationen zu den für fast alle Anwender relevanten Anforderungen zur ordnungsgemäß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 unzulässige Manipulationen über die Dauer der Aufbahrungsfrist sicherzustellen. Diese Schutzfunktionen können grundsätzlich auf Speicherebene, auf System- oder Anwendungsebene, z.T. auf organisatorischer Ebene oder mit einer Kombination dieser Verfahren umgesetzt werden.
4. Brand/Geis/Groß/Lindgens/Zöller: Gabler-Verlag, Steuersicher archivieren, 1. Auflage 2011
5. 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. 738
6. 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
Seite 22
September 2012
Organisatorische Maßnahmen alleine könnten zwar theoretisch ebenfalls die geforderte Unversehrtheit herbeiführen, aber nur, wenn sich jede handelnde Person an die betreffenden Anweisungen hält. Bei rein organisatorischen Maßnahmen fehlt jedoch die „technische Zwangsläufigkeit“ 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 angewendet wird, welches dem Prüfer mit ausreichender Glaubwürdigkeit darstellt, dass die verwendeten 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 Darstellung 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 Releasewechsel der DMS-Software oder der Speicherlösung nicht mehr funktionieren oder mit hohem Individualaufwand 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 Dokumente 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, änderbare und unveränderbare Dokumente in unterschiedlichen Systemen abzulegen.
Von zunehmendem Interesse für die Anwender ist die Möglichkeit, Dokumente nach unterschiedlichen Regeln zu schützen und zu löschen. Die Produkte verfügen daher zunehmend über Regelwerke, 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 Aufbewahrungsfristenverwaltung 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 entsprechenden Vereinbarungen zur Löschung von Kundenunterlagen) umgesetzt?
September 2012
Seite 23
IV.7
•
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.
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 Dokumente 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 Revisionssicherheit der Dokumentenablage ist hierdurch nicht per se gefährdet und wird gewährleistet,
wenn das System die unveränderte Aufbewahrung der relevanten Dokumentenversionen sicherstellt.
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 einheitlichen Archiv-/DMS-Software oder als separate Komponente mit eigenständiger Serverumgebung
angeboten werden. In einzelnen Fällen bieten Hersteller zwar getrennte Serverumgebungen einerseits 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 RechenzentrumStandorten, ist häufig eine Kombination aus lokaler sowie zentraler System- und Datenbereitstellung 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 Produktangebote weitere Aspekte zu berücksichtigen, wie z.B. zeitliche Steuerung der Replikationsfunktionen 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.
Seite 24
September 2012
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 Wandlungsumfangs sind bei Server-basierten Lösungen in der Praxis häufig deutlich geringer als bei Clientbasierten 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 Produktsupport 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-Vereinbarungen).
•
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 Fragebogens 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 funktional und ergonomisch ähnlich leistungsstark auszustatten wie Rich Clients. Es bleibt die Notwendigkeit, 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 Funktionskategorien sind im Rahmen einer konkreten Auswahlsituation vertieft zu untersuchen, denn
innerhalb jeder Funktionsgruppe ergeben sich häufig wesentliche Produktunterschiede. Die Funktionsgruppen „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 durchleuchtet, wie z.B. Such- und Trefferlistenfunktionen sowie die Fragestellungen zur Dokumentenanzeigefunktion (Viewer) und Versionierung.
September 2012
Seite 25
In besonders komplexen DMS-Anwendungsbereichen ergeben sich immer wieder Anforderungen
zur Bildung komplexer Dokumentenstrukturen mit Hilfe sog. Verbunddokumente. Auch hier vermittelt 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 Prozessanforderungen an DMS-Lösungen: Freigabe und Änderungsbenachrichtigung.
Nach Betrachtung der Client-Funktionen folgen Fragestellungen zur MS Office- inkl. MS OutlookIntegration 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 Ablagefunktionen dienen einem ersten Einstieg in die Fragestellungen zur Betriebsführung der DMSLö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 besonders komplexen Anforderungen an DMS-Lösungen zur Dokumentenverwaltung technischer
Anlagen vermitteln. Systeme mit dem Funktionsschwerpunkt „Verwaltung technischer Dokumentation“ sind deutlich seltener anzutreffen als DMS-Lösungen zur Verwaltung kaufmännischer Dokumente; 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, spezielle Freigabeprozesse oder Automatisierung von ERP-Prozessen können aus Platzgründen innerhalb 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änkungen abbilden kann. In den letzten Jahren haben sich die marktgängigen Dokumenten Management 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 herangezogen werden. Vielmehr gilt es, eine Vielzahl von Funktionen und Objektverwaltungsmöglichkeiten zu untersuchen, die in ihrer Gesamtheit Aktenverwaltung ausmachen. Produkte unterscheiden 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 Umsetzungsprojekten 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 Funktionsanforderungen 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 separaten Komponente bereitgestellt wird.
Seite 26
September 2012
Wie bei allen potentiell separaten Komponenten wird auch bezüglich der Aktenverwaltung abgefragt, 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 Projektaktenmodelle. 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 Personalakte enthält die Dokumente, die zum Personalstamm „Max Mustermann“ gehören.
Systeme, die keine Aktenmodellierung erlauben, können dennoch mit Aktenfunktionen ausgestattet 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 Metadaten 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 Festlegen 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 insbesondere im Anwendungsfall „leere Akte“ deutlich: Das System soll eine Akte inklusive der Beschreibungsdaten 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 teilweise auf die Arbeitsorganisation (bspw. Wiedervorlage, Offline-Speicherung für Notebook, E-MailAblage) 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 Dokumentensuche 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.
September 2012
Seite 27
IV.9
E-Mail-Archivierung
E-Mail ist die heute am häufigsten genutzte Kommunikationsform für den Austausch von geschäftsrelevanten 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-Archivierung 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-MailDatenbanken 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ückenhafte Akten, der Überblick auf den gesamten Sachverhalt geht verloren. Das kann bei aufbewahrungspflichtigen Dokumenten auch zum Compliance-Problem werden, weil aufbewahrungspflichtige 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 Ordnungsstruktur, 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 ausgerichteten 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 regelbasierte, 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.
Seite 28
September 2012
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 teilweise 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-MailArchivordner 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 Fragenkatalog mit aufgenommen. In der Praxis sind solche Systeme aber weit von der Interpretationsfähigkeit 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, Artikelnummernserie) 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 Übersicht 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 TIFFViewer zu ermöglichen. Hierbei ist zu beachten, dass nicht alle DMS-Lösungen eine solche Konvertierungsmöglichkeit anbieten, und einige Produkte neben dem Originalformat auch eine konvertierte 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).
September 2012
Seite 29
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 ersichtlich ist, ob die E-Mail bereits archiviert wurde.
•
Die archivierte E-Mail wird durch einen DMS-Link ersetzt. Der Vorteil besteht hier in der Reduzierung des Speicherbedarfs in der E-Mail-Datenbank. Sollen diese E-Mails noch offline zur
Verwendung, bereitstehen, sollte der Anwender auf entsprechende Offline-Zugriffsmöglichkeiten 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 konkurrierenden 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 abgefragt. Neben der Suche und Anzeige im DMS-Client können in Mail-zentrischen Anwendungsszenarien 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-getriebenen 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 Systemgetriebene Lösungsansatz durch eine zentral ablaufende Funktion aus, die E-Mails nach definierten 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 kombiniert 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üllung regulatorischer Anforderungen oder Minimierung von Geschäftsrisiken durch vollständige
Archivierung des ein- und ausgehenden E-Mail-Verkehrs. Hierbei steht mehr der Gedanke der vollständigen Online-Sicherung der gesamten E-Mail-Kommunikation aus Gründen der Nachvollziehbarkeit, 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-MailArchivierungskomponente zunächst abgefragt, für welche Serverplattformen das E-Mail-Archivsystem 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 grundsä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.
Seite 30
September 2012
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 vollumfä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 MailSystem erst gar nicht verlassen.
Eine „Single Instance Storage“-Archivierung (SIS) vermeidet Mehrfachspeicherung von EMailObjekten (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 Speicherung, 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. Andererseits können Objektmerkmale bspw. das Postfach des Empfängers betreffen und die Archivierung 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 Formatkonvertierung für E-Mail-Texte oder Anhänge gefragt. Hier sind grundsätzlich dieselben Konvertierungsherausforderungen 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-Archivierung ist eine Abschätzung der benötigten Rechnerressourcen wichtig, da durch hohen Rechnereinsatz 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 Formatkonvertierung, 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.
September 2012
Seite 31
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-MailClient 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 typischerweise 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 Netzwerkverbindung dann plötzlich nicht mehr zur Verfügung.
Weitere relevante Anforderungen umfassen zusätzlich beispielsweise die Fähigkeiten zur Übernahme bereits bestehender „persönlicher Mail-Archive“, Umsetzungsmöglichkeiten für Aufbewahrungsfristen 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-MailSysteme“ dargestellt.
IV.10
Postkorb-Funktionen
Bei einer Vielzahl an Workflow-Projekten im DMS-Umfeld handelt es sich um die Umsetzung Dokumenten-zentrischer Prozesse mittels Software-Unterstützung. In Analogie zum traditionellen,
Papier-basierten Sachbearbeitungsprozess, bei dem der Sachbearbeiter seine Vorgänge in Papierform 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 Sachbearbeitung) 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 Sachbearbeitungsprozesse, bspw. die Antragsbearbeitung im Finanzdienstleistungssektor oder die Eingangsrechnungsbearbeitung. 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 Dokumenten-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 Hintergrundsystemen, 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.
Seite 32
September 2012
Im folgenden Abschnitt zu diesem Funktionsblock sollten die Anbieter angeben, welche PostkorbBasisfunktionen im System zur Verfügung stehen. An dieser Stelle muss explizit darauf hingewiesen 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 unterstü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 Systemauswahl 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 grafischen 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 Programmierarbeiten.
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-Ausbildung (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 elektronischen 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 ITProjekt 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-zentrischer Prozesse. Einige DMS-Lösungen am Markt bieten jedoch über die in anderen Abschnitten
abgefragten Dokumenten-Automatismen und Postkorb-Funktionalitäten hinausgehende WorkflowFunktionen an.
September 2012
Seite 33
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 erforderlichen 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 BPMorientierte 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 BPMLösung positioniert wird, gestellt. Diese Informationen dienen zur Beantwortung einiger grundlegender 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 Prozessdefinitionen 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 Produktionsbetrieb 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 Kapitels nicht ausreichend. In einem solchen Fall müssen die BPM-spezifischen Anforderungen detailliert 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 entsprechend darstellen. Anbieter, die beispielsweise NUR Online-Conferencing anbieten, aber keine Dokumentenfunktionen, sind in der Marktübersicht nicht enthalten.
Mit anderen Worten: Collaboration-Lösungen im Sinne der vorliegenden Übersicht sollen Arbeitsgruppen 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 Übersicht zu entnehmen ist.
Seite 34
September 2012
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 eigenständige und ggf. fremde Komponente bereitgestellt wird oder ob sie in einer der bereits dargestellten Komponenten enthalten ist.
Anschließend wird der Funktionsumfang der Collaboration-Lösung abgefragt:
•
Virtuelle Projekträume bilden den fachlichen Rahmen und dienen der Abgrenzung unterschiedlicher 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 Arbeitssitzung 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 Freihand-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 aufgenommen werden konnten, wie zum Beispiel in der Darstellung von Diskussionsverläufen als
flache oder geschachtelte Darstellung.
•
Projektplanungswerkzeuge beinhalten z. B. Ressourcenverwaltung und -zuordnung, Definition 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öglichkeiten.
•
Wiki-Anwendungen bieten die Möglichkeit, weitestgehend ungeführt ein Projekt-, Abteilungs-,
Unternehmens- oder ein sonstiges Glossar aufzubauen; die weltweit erfolgreichste WikiAnwendung 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 Collaboration-Objekttypen anzuhängen. So könnten zum Beispiel an einem Termineintrag im TeamKalender die Einladung, die Agenda und auch das Ergebnisprotokoll jeweils als eigenständige
Dokumente einer Projektbesprechung angehängt sein.
September 2012
Seite 35
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öglichkeiten, 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 eigenhä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-Umgebung 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 derjenige, 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 Genehmigungsverfahren aller Art.
Es gibt aber Anwendungsbereiche, in denen eine qualifizierte elektronische Signatur (QES) vorgeschrieben ist. So gibt es eine gesetzliche Regelung für Unternehmen, die dem Sozialversicherungsrecht 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 Dokumenten trotzdem möglich.
Für elektronische Rechnungen wurden mit dem Steueränderungsgesetz 2010 neben der qualifizierten elektronischen Signatur auch beliebige andere elektronische Formate zugelassen, so dass
hier die QES nur noch eine von mehreren Handlungsoptionen ist.
Seite 36
September 2012
Für DMS-Systeme gibt es somit an unterschiedlichen Stellen Ansatzpunkte für die Nutzung elektronischer Signaturfunktionen. Unterstützt werden sollen möglichst viele Varianten, in jedem Fall aber
auch die qualifizierte elektronische Signatur gemäß dem Signaturgesetz. Ist diese nicht erforderlich, sind auch einfachere Unterschiften, die nach der gesetzlichen Definition als einfache oder fortgeschrittene 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 elektronischen 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 miteinander 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 Willenserklä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 WorkflowProzessen 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 DMSClient 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 dokumentiert 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. TrustCenter stellen dem Anwender Chipkarten mit entsprechenden eingebetteten Schlüsseln und Zertifikaten 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 Signaturverordnung 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 typischerweise beim DMS-Server oder einem nachgelagerten Signaturserver angesiedelt. Damit nicht Millionen 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 Anbieterunabhängigkeit, Vergleichbarkeit und Verlässlichkeit bei der Konformität mit regulatorischen
September 2012
Seite 37
Anforderungen zu erreichen. Historisch haben sich aber nur sehr wenige ECM-Standards durchgesetzt, viele Spezifikationen sind gescheitert und haben außer Aufwand nichts gebracht. Internationale 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.
Seite 38
•
CMIS steht für Content-Management-Interoperability-Services und ist ein im Mai 2010 veröffentlichter OASIS-Standard für die Integration von proprietären Content Management
Systemen. CMIS erlaubt die Entwicklung von Anwendungen, die mit unterschiedlichen (CMISkompatiblen) 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 voraussetzt.
•
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 unterschiedliche Content-Systeme zugreifen können, ohne die jeweiligen, herstellerspezifischen Funktionsaufrufe 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 WebClient 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 hierarchisches 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 Nachteile. 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.
September 2012
•
CIFS – Der Begriff Common Internet File System (kurz CIFS) wurde 1996 von Microsoft eingeführt und beschreibt eine erweiterte Version von SMB (Server Message Block), eines Kommunikationsprotokolls u.a. für LAN-basierte Druck- und Dateiablagedienste. ECM-/DMSLö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 branchenunabhängig sein, wie die Vorschriften zur ordnungsgemäßen Aufbewahrung nach deutschem Steuerund 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 PharmaBranche 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 Bewertung erlauben. Daher beauftragen manche Anwender und Hersteller – legitimerweise – sachverstä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 Erfassungsszenarien. Darüber können nicht nur in SAP erzeugte ausgehende Dokumente wie Bestellungen, Rechnungen 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 angeboten. Anwender interessiert typischerweise die Unterstützung von DMS-Lösungen für die aktuellste 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.
September 2012
Seite 39
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-Zertifizierung“ (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 Anwendungsdaten 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 ArchiveLinkSchnittstelle verwendet. Neben DMS-Herstellern haben sich auch einige Hersteller von Archivspeichern 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 Unterschiede 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-Berechtigungen 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 Fachwendungen 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 Fristenverwaltung, aufbewahrt werden. Auch auf diese Unterlagen soll aus den Fachanwendungen 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.
Seite 40
September 2012
Generell kann man folgende Varianten unterscheiden:
•
Der Hersteller der Fachanwendung stellt selbst eine dauerhaft gepflegte, über die verschiedenen 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-Systemunabhängige Integrationsschnittstelle ist zweifellos SAPs ArchiveLink. Sehr häufig ist die Funktionalität durch Werkzeuge auf Seiten der Fach- aber auch der DMS-Anwendung noch erweiterbar.
•
Der Hersteller der DMS-Software oder ein Integrator stellt eine solche Verknüpfungsschnittstelle für externe Fachanwendungen zur Verfügung. Das wird der DMS-Hersteller bzw. Integrator 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 Schnittstelle investieren zu können. Daher ist der Anwender hier gefordert, beim Schnittstellenhersteller 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-Implementierung betreibt, die mit der neuen Version seiner Finanzbuchhaltung nicht mehr zusammenarbeitet. Auch bei dieser Variante der Schnittstelle sollte man auf die Erweiterbarkeit der Schnittstelle 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 verhindert 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: Dokumentarten, 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 Sachbearbeitung“ zur Verfügung gestellt werden. Werden Dokumente – wie zum Beispiel eingehende
Papierdokumente – vor der Sachbearbeitung gescannt, müssen sie entweder in einen DMSPostkorb oder sogar in einen Postkorb der führenden Anwendung – falls vorhanden – weitergeleitet 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 vorgemerkt 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) übergeben werden, damit aus der Fachanwendung ein Zugriff auf die vorgangsrelevanten Unterlagen erfolgen kann.
September 2012
Seite 41
•
Verknüpfungsschnittstelle für PC-Dateien, wenn in diesen Unterlagen mit Bezug zu Fachanwendungen erstellt werden. Auch hier sind eigentlich drei „Systeme“ involviert. Die Dokumenten-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-Integration: 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 Fachanwendungen ü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 Dokumente gemeint. Häufig müssen auch die Aspekte wie Single-System-Login, Integration der Zugriffsrechtesysteme, 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 Scanund 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 abdecken 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-/Archivanwendung 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 strategisch gesetzt.
Wir möchten an dieser Stelle erwähnen, dass es eine Reihe funktional vergleichbarer wettbewerbsfä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 Integrationsschnittstellen 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änzung 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 Dokumentenverwaltungsfunktionen, 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 „klassischen“ DMS-/Archivlösungen eingesetzt. Der Grund ist meist, dass diese in der Regel noch leistungsfähiger die typisch geforderten Akten-, Ablagefunktionen sowie Integrationsanforderungen
(z.B. Verknüpfungsverfahren mit SAP) unterstützen. Daher hat das Thema DMS-SharePoint-Integration 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.
Seite 42
September 2012
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 Erstellungsund Bearbeitungsphase von Dokumenten eingesetzt. Nach der Freigabe der Dokumente
sollen diese in ein „revisionssicheres“ Archiv ausgelagert werden. Dabei sollen diese Dokumente 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 Sicherung der unveränderten Speicherung würde ausreichen, die Objekte aus dem SharePoint in
ein reines Archiv-Repository (Archivspeicher) auszulagern und per Verknüpfung aus SharePoint zugreifbar zu machen. Solche reinen Middleware-Angebote (ohne DMS) werden am
Markt auch angeboten, sind aber in der vorliegenden Marktübersicht der DMS-Komplettangebote 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 Anforderungen über eine technisch/organisatorische Lösung für die unveränderbare Ablage ausreichend 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 Benutzeroberflä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 SharePointWebparts entwickelt, um z.B. Dokumente zu suchen, Trefferlisten anzuzeigen oder in den Ablagestrukturen des externen DMS zu navigieren. In diesen Fällen kommen jedoch keine DMSFunktionen des SharePoint wie z.B. Versionierung oder Check-In/-Out zum Einsatz. Vielmehr
werden diese DMS-Funktionen als spezifische Erweiterung vom jeweiligen DMS-Anbieter geliefert. 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 beinhaltet.
Weitere, vielfältige Integrationskonzepte kommen laufend neu auf den Markt, da die ECM-Anbieter
den SharePoint zunehmend als Applikationsplattform begreifen. Bei jedem der Szenarien interessiert, 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 DMSFunktionen, 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 Anwendungslösung nicht von Microsoft, sondern von einem Microsoft-Partner kommen.
September 2012
Seite 43
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 Produktkomponenten 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 Integrationspartnern, weswegen in der Übersicht der Hersteller der Komponenten anzugeben war.
Die funktionale Beschreibung dieser zusätzlichen Komponenten muss sich auf eine kurze ProsaBeschreibung ü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 Auswahlsituationen 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 Scanverarbeitung 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 unterschiedliche 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-Plattformen sind. Gerade bei DMS-Herstellern mit umfangreichem Partnernetzwerk ist es sogar wahrscheinlich, 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.
Seite 44
September 2012
0.1
Musterfirma
Musterprodukt
Musterfirma: Musterprodukt
Stammhaus
Firma
Adresse
Homepage
Gründungsjahr
Eigentumsverhältnisse
Allgemeine Angaben zum Anbieter in Deutschland
Firma
Adresse
Homepage
Gründungsjahr
Allgemeine Angaben zum Anbieter in Österreich
Firma
Adresse
Homepage
Gründungsjahr
Allgemeine Angaben zum Anbieter in der Schweiz
Firma
Adresse
Homepage
Gründungsjahr
Mitarbeiteranzahl im Bereich DMS/ECM
In D.A.CH.
In EU inkl. D.A.CH.
Weltweit inkl. EU
Anmerkungen des Anbieters
Umsätze im Bereich DMS/ECM
Geschäftsjahr
In D.A.CH. (in Mio. €)
In EU inkl. D.A.CH. (in Mio. €)
Weltweit inkl. EU (in Mio. €)
Spezifische Einsatzfelder
Fokussierung auf ERP-Umgebungen
bzw. Fachanwendungen
Fokussierung auf andere Einsatzfelder
DMS-Server-Plattform
Name der Komponente
Hersteller
Auf dem Markt seit (Datum)
Anzahl Kunden in D.A.CH.
Aktuelle Version
Freigegeben für Microsoft Windows
 MS SQL Server
Server und folgende Datenbanken auf  Oracle
dieser Server-Plattform
 Andere DB:
Freigegeben für IBM AIX und folgenden  IBM DB2
Datenbanken
 Oracle
 Andere:
Freigegeben für SUN Solaris und fol Informix
gende Datenbanken
 Oracle
 Andere:
September 2012
Seite 1
Musterfirma
Musterprodukt
Freigegeben für HP-UX und folgende
Datenbanken
Freigegeben für Linux und folgende
Datenbanken
 Informix
 Oracle
 Andere:
Linux Distributionen:
 Oracle
 MySQL
 Andere:
Andere Plattformen und Datenbanken
Capture-/Scan-Funktionen im Anwender-Client
Welche Scan-und Indexierkomponenten  Eine Scan-und Indexierkomponente ist im Standard Windows-Client (Richsind vorhanden?
Client) enthalten
 Eine Scan-und Indexierkomponente ist im Standard Web-Client enthalten
 Die Scan-und Indexierkomponente ist für die o. g. Standard Anwendungsclients kostenpflichtig. Ausnahmen:
Name bzw. Bezeichnung der Scan-und Für die Scan-und Indexierkomponente im Standard Windows-Client (Rich-CliIndexierkomponente.
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-Client):
Für die Scan-und Indexierkomponente im Standard Windows-Client (Rich-Client):
Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Client):
Aktuelle Version
Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Client):
Für die Nutzung der Scan-und Indexier-  Immer notwendig
komponente ist die Einbindung von spe-  Optional notwendig für:
zieller Hardware oder Software notwen-  Nicht vorgesehen
dig?
Ist ein Ad-hoc-Scannen von Einzelblät-  Für die Scan-und Indexierkomponente im Standard DMS-Client (Rich-Clitern möglich?
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-Client)
 Für die Scan- und Indexierkomponente im Standard Web-Client
Es steht ein Administrationswerkzeug
 Ja, für die Scan- und Indexierkomponente im Standard DMS-Client (Richfür die Definition von Scan-Profilen inkl. Client)
Stapelbearbeitung zur Verfügung?
 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 Automatisches leserichtiges Ausrichten gescannter Dokumente ("Auto
rungsfunktionalitäten werden in der
rotate")
Scan-und Indexierkomponente im DMS-  Entfernen schwarzer bzw. weißer Ränder
Client im Standard durchgeführt?
 Ausfiltern von Schmutz ("Noise", "Despeckling")
 Automatische Erkennung leerer Rückseiten von Dokumenten über
Schwellwert
 folgende Zusatzmodule sind notwendig:
Die Scan-Komponente im Standard
Formate für mehrseitige Schwarz/Weiß Dokumente:
DMS-Client erzeugt Dokumente in folFormate für einseitige Farbdokumente:
genden Formaten:
Formate für mehrseitige Farbdokumente:
PDF Volltext
 Die angebotene Scan-und Indexierkomponente verfügt über eine OCRund Volltextfunktion
 Die OCR-Funktion läuft automatisch während bzw. nach dem Scannen
Seite 2
September 2012
Musterfirma
Musterprodukt
Standard Indexierkomponente?
 Ja, integraler Bestandteil der o. g. Capture-Komponente
 Ja, Bestandteil der Capture-Komponente, muss jedoch zusätzlich lizenziert werden
 Nein, Indexanwendung muss separat entwickelt werden
Eigenständige Capture-/Scan-Komponente
Welches eigenständige Produkt zum
 Eine Capture Scan-Komponente ist als eigenständiges Produkt/KompoScannen und Indexieren steht zur Verfü- nente verfügbar
gung?
Auf dem Markt seit:
Anzahl Kunden:
Für die Nutzung der Scan-Software ist  Nicht vorgesehen
die Einbindung von spezieller Hardware  Optional notwendig (für Spezialfunktionen)
oder Software notwendig?
 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 ScanStapels
 Umsortieren einzelner Seiten zwischen Dokumenten eines Scan-Stapels
 Umsortieren einzelner Seiten zwischen mehreren Scan-Stapeln
Unterstützte Barcode-/Patchcodety Code-39
pen?
 2/5 Interleaved
 Code-128
 PDF 417
 Data Matrix
Welche der folgenden Bildverbesse Automatisches leserichtiges Ausrichten gescannter Dokumente ("Auto
rungsfunktionalitäten werden in der
rotate")
eigenständigen Scan-Komponente im
 Entfernen schwarzer bzw. weißer Ränder
Standard durchgeführt?
 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- Dateiformate für mehrseitige Schwarz/Weiß Dokumente:
ponente erzeugt Dokumente in folgen- Dateiformate für einseitige Farbdokumente:
den Formaten:
Dateiformate für mehrseitige Farbdokumente:
PDF Volltext
 Die eigenständige Scan-und Indexierkomponente verfügt über eine OCRund Volltextfunktion
 Die OCR-Funktion läuft automatisch während bzw. nach dem Scannen
 Die Konvertierung der gescannten und OCR'ten Dokumente in ein recherchierbares PDF-Dokument erfordert folgende Drittkomponenten:
Eine Standard Indexierkomponente ist  Ja, integraler Bestandteil der o. g. Capture-Komponente
integraler Bestandteil der eigenständi-  Ja, Bestandteil der Capture-Komponente, muss jedoch zusätzlich lizengen Capture-Anwendung?
ziert werden
 Nein, Indexanwendung muss separat entwickelt werden
Funktionalitäten der Dokumenteninde-  Eine Vorindexierung des Stapels oder einzelner Dokumente ist bereits
xierung
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 ScanArbeitsplatz durchgeführt werden
 Die Indexierfunktion/-prozess kann auf mehreren unabhängigen PCArbeitsplätzen gleichzeitig durchgeführt werden
Capture OCR, Klassifikation, Index-, Datenextraktion
Name der Komponente
September 2012
Seite 3
Musterfirma
Musterprodukt
Hersteller
Aktuelle Version
Plattform für OCR / Beleglesung
Die Verarbeitung erfolgt
Funktionsumfang OCR / Beleglesung
Die folgenden Eingangsformate können
verarbeitet werden:
Die folgenden Funktionen stehen in der
Software (unabhängig von ScannerFunktionen) für die Bildaufbereitung
von gescannten Dokumenten zur Verfügung:
Welche Dokumenteninhalte können verarbeitet werden?
Für welche Sprachen stehen entsprechende Erkennungs-Engines zur Verfügung?
Für die Dokumentenklassifikation
stehen die folgenden Funktionen zur
Verfügung
Wie können die Klassifikationsregeln
eingerichtet werden?
Die folgenden Funktionen stehen für die
Prüfung und Optimierung der Leseergebnisse zur Verfügung:
Seite 4
 Client-basiert
 Server-basiert
 auf dem im Abschnitt DMS-Server-Plattform genannten Server (identisch
mit OCR –Server)
 auf dediziertem Server. Folgende Plattformen und DB werden unterstützt:
 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
 TIFF-Format
 JPG-Format
 PDF (mit eingebetteten Rasterformaten)
 Office-Formate:
 E-Mail-Formate:
 Andere:
 Leerseitenerkennung
 Kontrastoptimierung
 Elektronisches Zuschneiden und Ausrichten
 In Leserichtung drehen
 Geraderücken
 Eliminierung ungewollter Linien
 Herausfiltern kleiner Punkte
 Herausfiltern Hintergrund/ Rückseite
 Blindfarben-Erkennung/-Filterung
 Barcodes
 Zeichen
 OMR-Kennzeichen (Bsp. Ankreuz-Felder)
 Tabellenstrukturen
 Weitere (Handblockschrift, etc.):
 Deutsch
 Englisch
 Französisch
 Weitere europäische Sprachen:
 Weitere internationale Sprachen:
 Inhaltliche Erschließung
 Regelbasierte Erschließung
 Statistische Verfahren
 Grafische Verfahren (Bsp. Layout, Logos)
 Dokumentgrößen
 Voting
 Selbstlernende Verfahren
 Weitere:
 Manuelles Definieren von Dokumentarten
 Automatisches Trainieren mit Beispieldokumenten
 Andere:
 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
September 2012
Musterfirma
Musterprodukt
Die Weitergabe der Verarbeitungsergeb-  Export der erkannten Daten als Datei
nisse ist über die folgenden Wege mög-  Export der erkannten Daten in eine Datenbank
lich:
 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
 Entwicklung der Erkennungsraten
ausgewertet werden:
 Verarbeitungszeiten (automatisch)
 Korrekturzeiten (manuell)
 Weitere Statistiken:
Für welche Anwendungsfälle oder Bran-  Eingangsrechnungsverarbeitung
chen stehen besondere Produktsuiten  Zahlungsverkehr
zur Verfügung?
 Versicherungsbranche
 Krankenkassen
 Allgemeine Eingangspost (Papier)
 Allgemeine E-Mails
 Weitere Produktsuiten:
Für Eingangsrechnungsverarbeitung:
Name der Komponente
Hersteller
Aktuelle Version
 Eingangsrechnungen
Verarbeitbare Belegarten
 Gutschriften
 Storno-Belege
 Belastungsanzeigen
 Sammelrechnungen
 Lieferscheine
 andere:
Für Eingangrechnungsverarbeitung:
 Papier (gescannte Dokumente)
Verarbeitbare Formate
 Dokumente im PDF-Format
 E-Mails (Bodies)
 EDI
 XML-Dateien
 andere:
 SAP ERP
Schnittstellen zu Buchhaltungssyste Microsoft Dynamics NAV
men
 Microsoft Dynamics AX
 Oracle Financials
 Andere:
Capture-Komponente für strukturierte Daten
Name der Komponente
Hersteller
Aktuelle Version
Die Funktion zur Übernahme struktu Server-Funktion
rierter Daten basiert auf:
 Client-Funktion
Folgende grundlegenden Importszena-  Import elektronischer Dateien, Indexextraktion erfolgt jeweils aus dem
rien stehen im Standard zur Verfügung 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:
September 2012
Seite 5
Musterfirma
Musterprodukt
Im Zuge des Imports stehen im Standard Funktionen zur Konvertierung der
importierten Daten und Dokumente in
"menschenlesbare", langzeitstabile Formate zur Verfügung.
 Strukturierte Daten können unter Zuhilfenahme einer Layoutdatei im
Zuge des Imports in PDF konvertiert werden.
Zuge des Imports in PDF/A konvertiert UND auf PDF/A-Konformität validiert
werden.
Zuge des Imports in TIFF konvertiert werden.
 Ergänzende Anmerkungen:
Fehlerhandling - Im Fehlerfall reagiert
 Jobabbruch bei Fehlerfall
das System mit folgendem Verhalten
 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 Es wird ein Ergebnisprotokoll geschrieben, welches für jedes erfolgreich
dard Protokollfunktionen zur Verfügung. importierte Dokument einen Eintrag enthält
 Für die Protokollierung fehlerhafter Verarbeitung wird ein separates Fehlerprotokoll geschrieben
Für die Einrichtung und Konfiguration
 Ja, alle den Import betreffenden Einstellungen werden in einem GUI-orider Importkomponente steht ein GUIentierten Werkzeug vorgenommen
basiertes Werkzeug zur Verfügung.
 Ja, die Basis-Einstellungen des Imports werden in einem GUI-orientierten
Werkzeug vorgenommen, weitere Einstellungen werden per Skript/Programmierung vorgenommen
 Nein, die Import-Einstellungen werden per Skript/Programmierung vorgenommen
Capture-Komponente für zentralen Druckoutput
Name der Komponente
Hersteller
Aktuelle Version
Plattform für COLD/Drucklistenarchivie-  Der im Abschnitt DMS-Server Plattform genannte Server ist identisch mit
rung
dem COLD-Server
 Dedizierter Server: alle im Abschnitt DMS-Server Plattform genannten
Plattformen werden unterstützt
 Dedizierter Server: folgende Plattformen und Datenbanken werden unterstützt:
Import und Indexierung nativer 1403
 Archivierung nativer 1403-Druckspoolformate, ohne FormatkonvertieDruckdaten
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-  Anzeige nativer 1403-Formate in dediziertem 1403-Viewer
ten
 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 Nettodaten angezeigt.
 Konvertierung vor der Anzeige in folgendes Viewing-Format:
Import und Indexierung nativer AFP Archivierung nativer AFP-Daten ohne Formatkonvertierung
Druckdaten
 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-  Anzeige nativer AFP-Daten in dediziertem AFP-Viewer
ten
 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
Seite 6
September 2012
Musterfirma
Musterprodukt
Die Einrichtung zur Entnahme von
 Nutzung einer grafischen Oberfläche (mit Dokumentendarstellung)
Indexdaten aus dem Datenstrom erfolgt  Editieren von Konfigurationsdateien
mit folgenden Mitteln
 Eingabe von Parametern in Eingabemasken
 Anders/Weitere:
Archivierung
Die Archiv-Funktionalität wird von einer  Ja, Angabe Komponente und Version:
bereits genannten Server-Komponente  Nein, eigenständige Komponente. Angabe Komponente und Version:
mit abgedeckt.
Wenn eigenständige Komponente:
welche Server- und Datenbankplattformen sind Voraussetzung dieser Komponente?
Hersteller
Der Schutz gegen unzulässige Änderun-  Dokumente und andere Objekte
gen (revisionssichere Aufbewahrung) ist  Metadaten zu den Dokumenten und Unterlagen
wirksam für
 Weitere:
Der Schutz gegen unzulässige Änderun-  Optische WORM-Speicher (Angabe, welche):
gen (revisionssichere Aufbewahrung)
 Magnetplatten-basierte WORM-Speicher (weitere Angaben siehe nächste
wird erreicht durch
Frage)
 Standard-Magnetplattensystem (SAN, NAS etc.) kombiniert mit SoftwareSchutz (Angabe, wie):
Die revisionssichere Speicherung auf
 EMC Centera
Magnetplattensystemen unterstützt fol-  NetApp SnapLock
gende spezielle WORM-Speichersys IBM Information Archive
teme
 Andere:
Die revisionssichere Speicherung auf
normalen überschreibbaren Medien
(NAS-/SAN) wird ermöglicht durch (bitte
Angabe der Verfahren)
Das Archivsystem erlaubt das Anlegen  Anlegen von Löschfristen
und Ausführen 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-  Funktionen des DMS/Archivs, die unabhängig vom verwendeten Speicher
benen Verwaltungsfunktionen von
arbeiten
Löschfristen sind …
 Funktionen des Speichersystems (folgende Speicher bieten diese Funktionen):
DMS-Funktionen
Die DMS-Funktionalität wird von einer  Ja, Komponente und Version:
bereits genannten Server-Komponente  Nein, eigenständige Komponente. Angabe Komponente und Version:
mit abgedeckt. Angabe der Komponente
Wenn eigenständige Komponente:
welche Server- und Datenbankplattformen sind Betriebsvoraussetzung dieser
Komponente?
Hersteller
Replikation von Systeminhalten zwi Replikation für Dokumente
schen mehreren Systeminstanzen
 Replikation für Beschreibungsdaten
 Replikation für Check-Out- / -In-Status
 Replikation Zugriffsschutz
 Replikation Benutzer / Benutzergruppen / Rollen
 Weitere:
September 2012
Seite 7
Musterfirma
Musterprodukt
Es steht ein Offline-Client mit folgenden  Mitnahme von Dokumenten zur Offline-Ansicht
Funktionen zur Verfügung
 Offline-Änderung von Dokumenteninhalten mit anschließender Synchronisierung
 Offline-Änderung von Dokumentenattributen mit anschließender Synchronisierung
 Offline-Erstellung von neuen Dokumenten mit anschließender Synchronisierung
 Offline-Suche nach Dokumenten (im Offline verfügbaren Dokumentenbestand) unter Nutzung der zugehörigen Dokumenten-Metadaten
 Die beschriebene Offline-Funktionalität ist im Standard-DMS-Client enthalten (gegebenenfalls als Lizenzoption)
 Die o.a. Offline-Funktionen stehen für folgende Client-Plattformen zur Verfügung:
 Weitere Offline-Funktionen:
Für den Zugriff auf die DMS-Funktionen  Ja, DMS-Client und Archiv-Client sind unterschiedliche Client-Anwendunwird eine andere Client-Anwendung
gen
bereitgestellt als für den Zugriff auf die  Nein, Zugang zu DMS und Archivierung über gleichen Client
Archiv-Funktionen
Rendition-Funktionen (Formatkonvertie-  Die Rendition-Funktion läuft auf einem Serversystem
rung)
 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-Client
Name und Version des Rich-Client Produktes
Technologie des Rich-Clients
 Native Windows-Anwendung (benötigt keine zusätzliche Laufzeitkomponente)
 .NET-Anwendung (benötigt .NET-Laufzeitumgebung)
 Java-Anwendung (benötigt Java-Laufzeitumgebung)
 Andere:
Der Rich-Client ist für den Einsatz mit
 WTS
Terminalservern freigegeben
 Citrix
 Nein
Die folgenden DMS-Funktionen sind im  Dokumentenablage / Dokumentenimport
Rich-Client enthalten
 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 "CollaborationFunktionen")
 Andere (bitte nur Stichworte):
Der Rich-Client enthält folgende Such-  Suche nach Textinhalten (Volltext)
und Trefferlistenfunktionen
 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
Seite 8
September 2012
Musterfirma
Musterprodukt
Der Multi-Format-Viewer im Rich-Client
(Variante: ohne Laden nicht mitgelieferter Plug-Ins) stellt folgende Dateiformate dar
 PDF
 TIFF
 JPEG
 MS Outlook (.msg)
 folgende MS-Office Formate:
 folgende CAD-Anwendungsformate:
 Andere:
Die Dokumentenanzeigefunktion im
 in einem Multi-Format-Viewer dar; die Anzeige der Dokumente erfolgt
Rich-Client stellt Dokumente
ohne Laden zusätzlicher, nicht mitgelieferter PlugIns
 in einem Multi-Format-Viewer dar; für die Anzeige der folgenden Dokumentenformate ist die Installation zusätzlicher nicht mitgelieferter PlugIns
notwendig:
 in den jeweiligen (auf dem Arbeitsplatz bereitzustellenden und zu ladenden) Editoren dar
 Thumbnailanzeige ist für alle in der Anzeigefunktionen darstellbaren
Rich-Client enthält eine ThumbnailanDokumentformate verfügbar
zeige für folgende Dokumentformate
 Thumbnailanzeige ist für folgende Dokumentformate verfügbar:
 TIFF
Rich-Client enthält Annotationsfunktio-  PDF
nen für folgende Dateiformate
 Redlining- / Annotationsfunktionen für folgende CAD-Anwendungsformate:
 Andere:
Versionierungsfunktionen im Rich Dokumenten-Inhalte
Client werden für folgende Objekttypen  Dokumenten-Attribute
bereitgestellt
 Ordner / Akten - Inhalte
 Ordner / Akten - Attribute
 Weitere:
Verbunddokumentfunktionen im Rich-  Bildung zusammengehöriger Dokumente aus Einzeldokumenten (ParentClient
Child-Beziehung; Compound Document)
 Verzweigung vom Parent-Dokument zum Child-Dokument und umgekehrt
 Versionierung von Dokumenteninhalten von Parent- und Child-Dokumenten (inkl. Check-In / Check-Out Funktionen)
 Versionierung der Dokumentenmetadaten von Parent- und Child-Dokumenten
Der Rich-Client enthält folgende Freiga-  Versand von Dokumenten innerhalb des DMS-Clients zwecks Erteilung
befunktionen
einer Freigabe
 Verwaltung des Freigabestatus
 Protokollierung des Freigabeprozesses
Der Standard Rich-Client enthält fol Benachrichtigung bei Änderungen an abonnierten Dokumenten
gende Benachrichtigungsfunktionen
 Benachrichtigung wenn neue Dokumente zu einer gespeicherten Suchabfrage entstehen
 Benachrichtigung, wenn neue Dokumente in abonnierten Akten entstehen oder geändert werden
 Sonstige (bitte nur Stichworte):
Browser Client / RIA Client
Name der Komponente
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
 WTS
mit Terminalservern freigegeben
 Citrix
 Nein
September 2012
Seite 9
Musterfirma
Musterprodukt
Die folgenden Funktionen sind im Brow-  Dokumentenablage / Dokumentenimport
ser Client enthalten
 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 "CollaborationFunktionen")
 Andere (bitte nur Stichworte):
Der Browser Client enthält folgende
 Suche nach Textinhalten (Volltext)
Such- und Trefferlistenfunktionen
 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
 in einem Multi-Format-Viewer dar ohne Laden Format-spezifischer PlugBrowser Clients stellt Dokumente
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
 PDF
Clients (Variante: ohne Laden weiterer  TIFF
Plug-Ins) stellt folgende Dateiformate
 JPEG
dar
 MS Outlook (.msg)
 folgende MS-Office Formate:
 folgende CAD-Anwendungsformate:
 Andere:
 alle in der vorherigen Frage angekreuzten Dokumentformate
Browser Client enthält eine Thumbnail-  folgende Dokumentformate:
anzeige für
Die Dokumentenanzeigefunktion des
 TIFF
Browser Clients beinhaltet Annotations-  PDF
funktionen für folgende Dateiformate
 Redlining / Annotationsfunktionen für folgende CAD-Anwendungsformate:
 Andere:
Versionierungsfunktionen im Browser
 Dokumenten-Inhalte
Client werden für folgende Objekttypen  Dokumenten-Attribute
 Ordner / Akten - Inhalte
bereitgestellt
 Ordner / Akten - Attribute
 Weitere:
Verbunddokumentfunktionen im Brow-  Bildung zusammengehöriger Dokumente aus Einzeldokumenten (Parentser Client
Child-Beziehung; Compound Document)
 Verzweigung vom Parent-Dokument zum Child-Dokument und umgekehrt
 Versionierung von Dokumenteninhalten von Parent- und Child-Dokumenten (inkl. Check-In / Check-Out Funktionen)
 Versionierung der Dokumentenmetadaten von Parent- und Child-Dokumenten
Im Browser Client stehen folgende Frei-  Versand von Dokumenten innerhalb des DMS-Clients zwecks Erteilung
gabefunktionen zur Verfügung
einer Freigabe
 Verwaltung des Freigabestatus
 Protokollierung des Freigabeprozesses
Seite 10
September 2012
Musterfirma
Musterprodukt
Im Browser Client stehen folgende
 Benachrichtigung bei Änderungen an abonnierten Dokumenten
Benachrichtigungsfunktionen zur Verfü-  Benachrichtigung wenn neue Dokumente zu einer gespeicherten Suchabgung
frage entstehen
 Benachrichtigung, wenn neue Dokumente in abonnierten Akten entstehen oder geändert werden
 Sonstige (bitte nur Stichworte):
Sonstige Client-Anwendungen
Folgende DMS-Integrationsfunktionen  Automatische Übernahme von Metadaten aus dem DMS in das geöffnete
für MS Office stehen zur Verfügung
Office-Dokument (Office-Feldfunktion)
 Übernahme von Office-Dokumenteigenschaften in das DMS als Indexdaten
 Verwendung markierter Textelemente für Volltextsuche im DMS ohne Verlassen 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 Bei jeder Zwischenspeicherung erstellt das DMS automatisch eine neue
tion
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-  Grafisches Werkzeug zum Anlegen von Ordnungsstrukturen (Indexfelder)
turen
 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 Metadaten im DMS aus folgenden CAD-Formaten:
 Check-Out / Check-In & Versionieren von CAD-Dokumenten ohne Verlassen der CAD-Anwendung für folgende CAD-Anwendungen:
Aktenverwaltung
Die Akten-Funktionalität wird von einer  Ja, Komponente (Bezeichnung) und Version:
bereits genannten Server-Komponente  Nein, andere Komponente (Bezeichnung) und Version:
mit abgedeckt. Bitte Angabe der Kom-  Wenn andere Komponente: Aktenfunktionalität erfordert folgende Serverponente und Version.
plattformen und Datenbanken:
Hersteller
Integration mit DMS/ECM
 Die Akten-Client Funktionalität ist Bestandteil des Standard-DMS-Rich-Clients
 Die Akten-Client Funktionalität ist Bestandteil des Standard-Browser-Clients
 Akten-Client ist separate Rich-Client-Anwendung
 Akten-Client ist separate Browser-Client-Anwendung
 Anders:
September 2012
Seite 11
Musterfirma
Musterprodukt
Aktenmodellierung, Aktenstrukturen
 Erstellung und Verwaltung mehrerer, voneinander unabhängiger Aktenmodelle:
 Aktenmodelle dienen als Template ("Kundenakte") und werden instanziiert ("Kundenakte XY")
 Aktenmodelle (Vorlagen, Templates) haben vordefinierte Registerstrukturen
 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 Zeitraum keine Dokumente)
Im Standard des Clients enthaltene
 Akten(!) können über den Volltext der enthaltenen Dokumente gefunden
Aktenfunktionen
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 Endgeräten (z.B. Notebooks) heruntergeladen und offline unter Verwendung des
Akten-Clients gesichtet werden
 Dokumente aus MS Office können direkt in ein Aktenregister (Unterregister 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
 Beliebige Inhaltselemente (Dokumente, Dateien, CAD, Video/AudioElemente verwaltet werden
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 verschlagwortet werden
 Zu Dokumenten lässt sich ein Verwendungsnachweis anzeigen: in welchen Akten befindet sich dieses Dokument?
 Akten können auch dynamische Strukturen / Pseudo-Register beinhalten
(z.B. Trefferlisten, die durch in die Akte eingebundene Suchabfragen ermittelt werden)
 Änderungshinweise: Die Aktenanwendung markiert eigenständig diejenigen Elemente, die seit dem letzten Öffnen der Akte geändert oder hinzugefügt wurden
 Änderungshinweise: Die Anwendung führt eine für den Anwender einsehbare Historie (z.B. RSS-Feed) über alle Veränderungen innerhalb einer Akte
Client-basierte E-Mail-Archivierung: MS Outlook
Name der Komponente
Hersteller
Verfügbar für
MS Outlook Client-Versionen:
Folgende Möglichkeiten der E-Mail Ausgewählte E-Mails und Anhänge können unmittelbar durch den EndbeArchivierung sind im Standard enthalten 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:
Seite 12
September 2012
Musterfirma
Musterprodukt
Die gesamte E-Mail (inkl. Anhänge) wird  MSG-Format
in folgendem Format abgelegt
 RFC 2822
 Speicherung einer E-Mail (Bodytext, Attachments) als jeweils eigenständige Objekte
 Andere:
Die Mailbodies werden in folgendem
 Original E-Mail-Format
Format abgelegt
 Konvertiert in PDF
 Andere:
Die Attachments werden in folgendem  Originalformat
Format abgelegt
 Andere:
Zustand des Mail-Systems nach der
 Archivierte E-Mail wird im Mail-System automatisch gelöscht
Archivierung von E-Mails
 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 Notes
Name der Komponente
Hersteller
Verfügbar für
Lotus Notes Client-Versionen:
Folgende Möglichkeiten der E-Mail Ausgewählte E-Mails und Anhänge können unmittelbar durch den EndbeArchivierung sind im Standard enthalten nutzer aus dem E-Mail-Postkorb in individuelle DMS-Ablagestrukturen, die
auch für andere Dokumente verwendet werden, abgelegt werden.
 Andere:
Die gesamte E-Mail (inkl. Anhänge) wird  NSF-Format
 DXL-Format
 RFC 2822
 Andere:
Format abgelegt
 Andere:
Format abgelegt
 Andere:
 Anders:
Suche nach E-Mails
 Aus dem Lotus Notes-Client
Anzeige von E-Mails
 Im DMS-Viewer
 Im Lotus Notes-Client
 Andere:
September 2012
Seite 13
Musterfirma
Musterprodukt
Client-basierte E-Mail-Archivierung: Andere Mail-Clients
Name der Komponente
Hersteller
Verfügbar für
 Novell Groupwise Client-Versionen:
 Andere Mail-Clients:
Folgende Möglichkeiten der E-Mail Ausgewählte E-Mails und Anhänge können unmittelbar durch den EndbeArchivierung sind im Standard enthalten nutzer aus dem E-Mail-Postkorb in individuelle DMS-Ablagestrukturen abgelegt werden.
 Andere:
Die gesamte E-Mail (inkl. Anhänge) wird  RFC 2822
 Andere:
Format abgelegt
 Andere:
Format abgelegt
 Andere:
 Anders:
Suche nach E-Mails
 Aus dem E-Mail-Client
Anzeige von E-Mails
 Im DMS-Viewer
 Im E-Mail-Client
 Andere:
System-getriebene E-Mail-Archivierung: MS Exchange
Name der Komponente
Hersteller
Aktuelle Version
Verfügbar für
MS Exchange-Versionen:
Plattform für E-Mail-Archivierungspro Mailserver
zesse
 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-ServerPlattform" genannten Plattformen werden unterstützt:
Folgende Archivregeln können definiert  Archivierung außerhalb des MS Exchange-Servers über SMTP-Schnittwerden
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  Absenderadresse(n)
kann nach bestimmten Kriterien durch-  Größe des Postfachs
geführt werden. Folgende Kriterien
 Größe eines Mail-Objektes
können als Auslöser definiert werden
 Betreff-Informationen
 Andere:
Seite 14
September 2012
Musterfirma
Musterprodukt
Die Server-basierte E-Mail-Archivierung
kann zeitgesteuert ausgelöst werden.
Folgende Zeitpunkte können als Auslöser definiert werden
Ablageformat für E-Mail (inkl. Anhänge)
 Zeitraum seit letztem Zugriff
 Sendedatum
 Zeitplan, z.B. festgelegter Tag und Uhrzeit
 Andere:
 MSG-Format
 RFC 2822
 Andere:
Format abgelegt
 Andere:
Format abgelegt
 Andere:
 Mehrstufiges Vorgehen ist möglich. Die unter Antwort 1-3 genannten Vorgehensweisen können zeitlich hintereinander ablaufen.
 Anders:
Suche nach E-Mails
 Aus dem MS Outlook-Client
Anzeige von E-Mails
 Im MS Outlook Mail-Client
 Im DMS-Viewer
 Andere:
System-getriebene E-Mail-Archivierung: Lotus Domino
Name der Komponente
Hersteller
Aktuelle Version
Verfügbar für
Lotus Domino Server-Versionen:
zesse
Folgende Archivregeln können definiert  Archivierung außerhalb des Lotus Notes-Servers über SMTP-Schnittstelle
werden
 Andere:
Die Server-basierte E-Mail-Archivierung  Zeitraum seit letztem Zugriff
 Sendedatum
Folgende Zeitpunkte können als Auslö-  Zeitplan, z.B. festgelegter Tag und Uhrzeit
ser definiert werden
 Andere:
Ablageformat für E-Mail (inkl. Anhänge)  NSF-Format
 DXL-Format
 RFC 2822
 Andere:
Format abgelegt
 Andere:
September 2012
Seite 15
Musterfirma
Musterprodukt
Die Attachments werden in folgendem
Format abgelegt
 Originalformat
 Andere:
 Anders:
Suche nach E-Mails
 Aus dem Lotus Notes-Client
Anzeige von E-Mails
 Im Lotus Notes Mail-Client
 Im DMS-Viewer
 Andere:
System-getriebene E-Mail-Archivierung: Andere
Name der Komponente
Hersteller
Aktuelle Version
Verfügbar für
Novell Groupwise-Versionen:
Andere Mail-Server:
zesse
Folgende Archivregeln können definiert  Archivierung außerhalb des Mail-Servers über SMTP-Schnittstelle
werden
 Andere:
Die Server-basierte E-Mail-Archivierung  Zeitraum seit letztem Zugriff
 Sendedatum
Folgende Zeitpunkte können als Auslö-  Zeitplan, z.B. festgelegter Tag und Uhrzeit
ser definiert werden
 Andere:
Ablageformat für E-Mail (inkl. Anhänge)  RFC 2822
 Andere:
Format abgelegt
 Andere:
Format abgelegt
 Andere:
 Anders:
Seite 16
September 2012
Suche nach E-Mails
Anzeige von E-Mails
Musterfirma
Musterprodukt
 Aus dem E-Mail-Client
 Im Mail-Client
 Im DMS-Viewer
 Andere:
Postkorb-Funktionen
Name der Postkorb-Komponente
Hersteller
Aktuelle Version
Die Postkorb-Funktionalität wird von
einer bereits genannten Server-Komponente mit abgedeckt. Bitte Angabe der
Komponente und Version
Vorgangsbildung
 Ja, Bestandteil der Standard DMS-Komponenten und Version:
 Trotz Bestandteil der Standard DMS-Komponenten ist die Postkorbfunktionalität kostenpflichtig
 Andere Komponente und Version:
 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 Es können Einzelpostkörbe eingerichtet werden
nen für Postkörbe
 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 Postkorboberfläche dar
 Zum Vorgang (nicht am Dokument!) können Notizen angebracht werden
 Das System speichert die Vorgangshistorie
Die Zustellung und Weiterleitung von
 das eigene System
Vorgängen nutzt zur Verteilung
 das Mail-System
 andere Dienste:
Die Verteilung der Postkorbvorgänge
 Der Anwender kann den Zielpostkorb aus einer Liste der verfügbaren
kann folgendermaßen definiert werden: 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 Prozessmodellierungselementen (Verzweigungen, kausale Prüfungen, Zusammenführungen) definiert werden
Für die Pflege und Anpassung der Ver-  Für die Fachadministration steht ein GUI mit Tabelleneditor zur Pflege
teilregeln stehen folgende Werkzeuge
tabellarischer Regelwerke zur Verfügung
zur Verfügung:
 Für die Fachadministration steht ein GUI mit einem grafischen WorkflowEditor zur Verfügung
 Die Verteilregeln werden in einem Werkzeug für die technische Administration per Skript od. Programmierung angepasst
Folgende Wiedervorlagefunktionen sind  Wiedervorlage im Postkorb
im Standard enthalten
 Wiedervorlage im Mail-Client
 Vorgänge können vor dem Ablauf der Wiedervorlagefrist in den Postkorb
zurückgeholt werden
Folgende Eskalationsmechanismen
 Erhöhung der Priorität des Vorgangs
stehen im Standard zur Verfügung
 Mail an konfigurierten Anwender
 Weiterleitung an konfigurierten Anwender
 Andere:
Workflow / Business Process Management
Name der Komponente
September 2012
Seite 17
Musterfirma
Musterprodukt
Hersteller
Aktuelle Version
Die Workflow/BPM-Funktionalität wird
von einer bereits genannten ServerKomponente mit abgedeckt. Bitte
Angabe der Komponente und Version
Positionierung
 Ja, Angabe Komponente und Version:
 Andere Komponente und Version:
 Folgende Plattformen und Datenbanken für diese Komponente:
 Automation Dokumentenlebenszyklus: Erstellung, Versionierung, Genehmigung, Freigabe, Publishing
 Postkorbanwendung: Bearbeitung elektronisch erfasster Dokumente
 BPM-Werkzeug zur Analyse, Implementierung und Überwachung beliebiger Geschäftsprozesse in beliebigen Hintergrundumgebungen, Dokumenten-zentrische Prozesse
 BPM-Werkzeug zur Analyse, Implementierung und Überwachung beliebiger 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 folgendem Abschnitt genannt wurden:
Die Software bietet folgende Werkzeuge  Grafischer Editor
zur Abbildung/Modellierung von Abläu-  Grafischer Editor + Skripting
fen/Prozessen
 Skripting
 Programmierung
 Andere:
Prozessdefinitionen können importiert  XPDL
werden, es werden folgende Beschrei-  BPEL
bungssprachen / Notationen unter EPK (Ereignisgesteuerte Prozessketten)
stützt:
 BPMN Ablaufmodelle in folgenden Quelldateiformaten:
 Andere:
Prozessdefinitionen können exportiert  XPDL
werden, es werden folgende Beschrei-  BPEL
bungssprachen unterstützt:
 EPK (Ereignisgesteuerte Prozessketten)
 BPMN Ablaufmodelle in folgenden Dateiformaten:
 Andere:
Welche Möglichkeiten bestehen, die
 Die Aufbauhierarchie muss in der Workflow-Anwendung gepflegt werden
Aufbauhierarchie des Unternehmens in  Es stehen Standard-Schnittstellen zur Verfügung, um die Aufbauhierarden Prozessen zu berücksichtigen?
chie aus den Verzeichnissen externer Anwendungen auslesen zu können.
Standard-Schnittstellen zu folgenden Anwendungen sind vorhanden:
Folgende, weitere Funktionen sind in
 Zeitüberwachung
der in diesem Abschnitt genannten
 Protokollierung und Logging
Komponente im Standard enthalten
 Eskalationsmechanismen, Event-getriggert
 Simulationstool zum Testen der Prozess-Definitionen
Collaboration-Funktionen
Name der Komponente
Hersteller
Aktuelle Version
Die Collaboration-Funktionalität wird
 Ja, Komponente und Version:
von einer bereits genannten Server Andere Komponente und Version:
Komponente mit abgedeckt.
Seite 18
September 2012
Musterfirma
Musterprodukt
Folgende Funktionen sind in der Kompo-  Virtuelle Projekträume
nente ''Collaboration'' im Standard ent-  Team-Kalender
halten
 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-  Virtuelle Projekträume
ten an, an die Dokumente angeheftet
 Team-Kalender
werden können
 Kontakte
 Terminüberwachung
 White-Board
 Newsgroups / Diskussionen
 Projektplanungswerkzeuge
 Dokumentenablage
 Wiki
 Blog
 Weitere:
Die Synchronisierungsfunktion mit MS-  Kalendereinträge
Outlook steht für folgende in der Colla-  Kontakteinträge
boration-Umgebung verwalteten
 Andere:
Objekte zur Verfügung
Die Synchronisierungsfunktion mit
 Kalendereinträge
Notes steht für folgende der Collabora-  Kontakteinträge
tion-Objekte zur Verfügung
 Andere:
Das System weist den Anwender auf
 Kennzeichnung der geänderten Objekte
geänderte Inhalte aktiv hin
 Mail-Versand mit Hinweis auf geänderte Objekte
 Abonnement-Funktion (z.B. RSS-Feed)
 Anders:
Signatur-Funktionen
Die Softwarekomponenten zum Signie-  eigene Produkte für:
ren von Dokumenten sind:
 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
 Zeitstempel
können standardmäßig verwaltet
 Qualifizierte Zeitstempel
werden
 fortgeschrittene Signatur
 qualifizierte elektr. Signatur (QeS)
Die Signatur-Lösung kann standardmä-  Scan-Anwendung
ßig in folgende DMS-Erfassungskompo-  Office-Integration
nenten integriert werden
 Archiv-Server
 Postkorb-System
 Andere:
Art der Speicherung für eine digitale Sig-  Begleitende Signatur (in der DMS-DB oder als eigenes Objekt)
natur
 Integrierte Signatur (im Objekt/Dokument)
 Content-Signatur (nur die relevanten Teile eines Dokumentes werden signiert)
Es können unterschiedliche Signatur Standard
Typen (unterschiedliche Root-Zertifi Customizing
kate) in der Anwendung verwaltet wer-  programmierbar
den.
 Nein, folgende Einschränkungen:
September 2012
Seite 19
Musterfirma
Musterprodukt
Verwaltung der Verknüpfungen zwischen Archivobjekt und elektronischer
Signatur im DMS-Server
Verfahren zur Überprüfung der Gültigkeit genutzter Zertifikate (Bsp. OnlinePrüfung gegen einen Verzeichnisdienst)
Aufbewahrung von Prüfprotokolle
Die Ergebnisse der Prüfungen der elektronischen Signaturen werden in Prüfprotokollen festgehalten
Funktionen zur Prüfung von Signaturen
 Eingebettete Signatur im Archivobjekt
 Speicherung im gleichen Verzeichnis, wie das Archivobjekt
 Verwaltung der Zusammengehörigkeit über Datenbanktabellen
 Andere:
 Online-Prüfung
 Dynamisches Laden der Sperrlisten vom Trust-Center
 Zyklisches Einlesen der Sperrlisten
 Ablage als eigenes Objekt im elektronischen Archiv
 Speicherung in der Datenbank
 Andere:
 Standard
 Customizing
 programmierbar
 Nein
 Für ein Dokument wird im DMS-Standard-Viewer angezeigt, ob eine Signatur 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
 Standard
 Customizing
 programmierbar
 Nein
Die Prüfung beinhaltet in einem Schritt
sowohl die Prüfung der objektbezogenen Signatur als auch der Nachsignaturen und fasst alle Ergebnisse in einer
einheitlichen Darstellung zusammen
Standards und Zertifikate
CMIS-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  im Archiv-Client als Standardfunktion enthalten
Repositories
 im Collaboration-Client als Standardfunktion enthalten
 im DMS-Client als Standardfunktion enthalten
JSR-283 (JCR 2.0) kompatibles Reposi-  in Archiv-Komponente als Standardfunktion enthalten
tory (Server)
Integrierter Zugriff auf JSR-283 (JCR
 im Archiv-Client als Standardfunktion enthalten
2.0) kompatible Repositories
WebDAV-kompatibles Repository (Ser in Archiv-Komponente als Standardfunktion enthalten
ver)
Integrierter Zugriff auf WebDAV-kompa-  im Archiv-Client als Standardfunktion enthalten
tible Repositories
SMB/CIFS-kompatibles Repository
 in Archiv-Komponente als Standardfunktion enthalten
Weitere DMS-relevante Zertifikate
Schnittstellen zu SAP
Zertifizierte Standardschnittstelle für
 Zertifizierung durch SAP ist erfolgt
ArchiveLink-Schnittstellenversion BC-AL
6.20
Plattform für die ArchiveLink-Schnitt Der im Abschnitt ''DMS-Server-Plattform'' genannte Server ist identisch
stelle
mit dem ArchiveLink-Schnittstellen-Server
Name der Komponente
Hersteller
Zertifizierter SAP ArchiveLink Load-Test  Ja, wurde für folgende im Abschnitt ''DMS-Server-Plattform'' genannten
Server-Plattformen durchgeführt:
Seite 20
September 2012
Musterfirma
Musterprodukt
Zertifizierte Standardschnittstelle für
 Zertifizierung durch SAP ist erfolgt
SAP ILM - WebDAV Storage Interface 3.0
(BC-ILM 3.0)
Plattformen für die SAP ILM WebDAV
 Der im Abschnitt ''DMS-Server-Plattform'' genannte Server ist identisch
Storage-Schnittstelle
mit dem SAP ILM WebDAV Storage-Schnittstellen-Server
 Dedizierter Server: Folgende Plattformen und Datenbanken werden unterstützt:
Name der Komponente
Hersteller
Schnittstelle zur Übertragung von SAP-  Standardkomponente vorhanden
Belegdaten in das DMS
Hersteller
Aktensichten auf Dokumente
 Standardkomponente vorhanden
Technologie der Aktensicht auf Doku Verknüpfung von DMS-basierten Akten über die ArchiveLink-Schnittstelle
mente
anstelle einzelner Dokumente
 Anzeige und Interpretation von im DMS verwalteten Akten mit SAP-Technologie
 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.CH
Schnittstellen zu weiteren führenden Anwendungen (z.B. ERP)
Standardschnittstelle für Microsoft ERP Name der Komponente:
Lösung Dynamics NAV
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 Name der Komponente:
Lösung Dynamics AX
Für die Microsoft Dynamics AX-Version(en):
Standardschnittstelle für ADP / Paisy
Name der Komponente:
Für die ADP Paisy-Version(en):
Standardschnittstelle für Oracle Finan- Name der Komponente:
cials
Für die Oracle Financials-Version(en):
Standardschnittstelle für Infor
Name der Komponente:
Für die Infor-Version(en):
September 2012
Seite 21
Musterfirma
Musterprodukt
Angaben zu Standard-Schnittstellen zu
weiteren Anwendungssystemen
SharePoint Integration
Schnittstellen-Funktionalität wird von
einer bereits genannten Komponente
mit abgedeckt
Name der Komponente
Aktuelle Version
Hersteller
Unterstützte SharePoint-Version
Unterstützte Komponente(n)
SharePoint-Schnittstelle unterstützt
Single-Sign-on
Dokumente aus SharePoint-Bibliotheken 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öglicht.
Die in der SharePoint-Dokumentenbibliothek angelegten Ordnerstrukturen
werden mit den Ordnerstrukturen des
DMS automatisch abgeglichen
Im DMS abgelegte Dokumente (OfficeFormate und PDF) können über die
Schnittstellenkomponente in den Volltextindex von SharePoint aufgenommen
werden. (DMS als Inhaltsquelle in
SharePoint)
Metadaten, von im DMS abgelegten
Dokumenten, können über die Schnittstellenkomponente in den Volltextindex
von SharePoint aufgenommen werden.
Über SharePoint-Volltextsuche gefundene Dokumente im DMS werden
gemeinsam mit Content aus anderen
Inhaltsquellen in der SharePoint-Trefferliste angezeigt
Über SharePoint-Oberflächen kann
direkt in Ordnern / Akten des DMS navigiert 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 angezeigt und bearbeitet werden
Benachrichtigung im persönlichen
SharePoint-Bereich (My Site) bei neuen
Postkorbeinträgen im DMS
Weitere Komponenten
Name der Komponente
Hersteller
Seite 22
 Ja, Komponentenname und Version:
 Microsoft Office SharePoint Server 2007
 Microsoft SharePoint Server 2010
Komponentenname und Version:
 Als Standardfunktion enthalten
 SharePoint -> DMS
 DMS -> SharePoint
September 2012

Dokumenten Management Systeme

Transcription

Documents pareils

TrashMail.com bietet jetzt vollständige

IT-Trainer - Veritas AG

revisionssichere E-Mail-Archivierung mit iMARC

Vorteile eines ERMS gegenü ber einer konventionellen E

fCoder Universal Document Converter Datenblatt

Arbeiten Sie nun mit CAD- und Symbolbibliotheken aus RxHighlight

Kostenloser Artikel-Download - Shop Digital Production Shop Digital

Archivierung von Dokumenten

IntelliArchive Infobroschüre