Der Markt für Content Management Systeme ist zerplittert. Das liegt einmal am Begriff „Content“ selbst, der sehr umfassend ist und kaum eine Informationsart ausgrenzt. Gleichzeitig ist der Markt zwar dicht bevölkert, dennoch unterscheiden sich die angebotenen Lösungen und Produkte erheblich voneinander.

Häufige Ursache für Missverständnisse: WCM ? ECM
Der größte begriffliche Graben verläuft zwischen dem klassischen Dokumenten Management und den Web Content Management Systemen (WCMS). Letzterer ist der der jüngere Markt mit über 200 Anbietern und einem starken Trend zur Konsolidierung. Der DMS-Markt ist im direkten Vergleich eher beschaulich, die große Anzahl Anbieter stagniert bis heute auf hohem Niveau, von vereinzelten Insolvenzen einmal abgesehen. Die häufig beschriebene Konsolidierung hat faktisch nicht stattgefunden. Selbst die jüngsten Zusammenschlüsse (siehe die folgenden Abbildungen) haben nicht zu einer Reduzierung der am Markt angebotenen Lösungen beigetragen. Dem Anwender bieten sich heute eher noch mehr DMS-Lösungen als vor 3 Jahren.  Die Zusammenschlüsse haben auch nicht dazu geführt, dass die Kleinen aussterben, wie man immer wieder lesen konnte. Mit Ausnahme von DocMan sind in jüngster Zeit keine DMS-Lösungen vom Markt verschwunden. Die kleineren Anbieter nehmen derzeit sogar den größeren Anbietern Marktanteile weg, weil die Großen der Branche (FileNET, IBM, OpenText/iXOS, EMC/Documentum) den boomenden Markt für kleine und mittlere Lösungen architektonisch und preislich nicht so gut (eigentlich gar nicht) adressieren wie die zahlreichen kleineren Anbieter in diesem Segment.

Konvergenz im High-End Bereich, keine Konsolidierung
Die beiden ehemals getrennten Märkte WCM und DMS wachsen „manchmal“ zusammen. Nicht jeder, der ein WCM benötigt, will sich damit auch auf eine ECM/DMS-Infrastruktur festlegen und umgekehrt. Trotzdem gibt es bei größeren Unternehmen zunehmend die Notwendigkeit, die verwalteten Inhalte ohne System- und Verfahrensbrüche auch auf Portalen und Websites verfügbar zu machen. Man möchte zum Beispiel die typischen Verfahren für Freizeichnung, Genehmigung und Publishing nicht mehrfach, sondern im Idealfall nur auf Basis einer einzigen Plattform implementieren. In solchen Projekten sind die Synergien zwischen DMS und WCM offensichtlich.

Documentum hat schon früh WCM-Funktionen in seine Systemumgebung integriert, andere Anbieter wie FileNET, iXOS oder IBM, die diese Aufgaben anfangs via Kooperationen abdeckten haben in der jüngsten Vergangenheit durch Übernahmen von WCM-Werkzeugen nachgezogen. Umgekehrt haben sich WCM-Anbieter wie Interwoven, Stellent oder Vignette um DMS-Funktionen ergänzt. Die folgenden Abbildungen geben einen Überblick über diese Entwicklungen.  Aber auch die kleineren Anbieter auf dem Markt können schon lange weit mehr als nur Papier scannen und archivieren. Ablage von MS-Office und Mailobjekten, Verwaltung von Aktenstrukturen und einfache Postkorbfunktionen für das typische Workflow-Szenario „Frühes Erfassen“ sind Standardfunktionen vieler DMS-Produkte im kleineren und mittleren Segment, selten jedoch anzutreffen bei den High-End-Produkten. Dort ist sogar häufig sehr viel mehr Entwicklungsaufwand notwendig.

Abb.1-1: Zusammenschlüsse/Fusionen/Übernahmen. FileNET. Anmerkung: Watermark wird nicht mehr vermarktet.

Abb.1-2: Zusammenschlüsse/Fusionen/Übernahmen. IBM

Abb.1-3: Zusammenschlüsse/Fusionen/Übernahmen. EMC/Documentum

Abb 1-4: Zusammenschlüsse/Fusionen/Übernahmen. OpenText/iXOS

Abb 1-5: Zusammenschlüsse/Fusionen/Übernahmen. Stellent, Interwoven, Vignette

Viele Unternehmen, die in der Vergangenheit eher abteilungsbezogen in Content Management investiert haben, sehen sich nun dem Problem gegenüber, dass sie eine Vielzahl unterschiedlicher Systeme betreiben, die sich voneinander durch eine Reihe wichtiger Merkmale unterscheiden:

• Unterschiedliche Funktionalität. Die folgende Abbildung gibt den Themenbogen für ECM-Projekte wieder. Natürlich benötigt nicht jeder Anwender jede Funktion. Auch adressieren die Systeme am Markt die einzelnen Teilfunktionen sehr unterschiedlich, manche Teilfunktion fehlt gänzlich im Portfolio. Die großen Anbieter komplettieren sich erst in jüngster Zeit mit Collaboration, Records Management oder anderen Content-Funktionen, die im Falle von Zukäufen erst noch integriert werden müssen, um dem Anwender auch administrative Vorteile und damit eine Reduzierung der Betriebskosten bringen zu können.

Abb.2 : ECM-Funktionen

• Unterschiedliche Architekturen. Von klassischen 2-tier Architekturen mit fetten Windows-Clients und schlanken Servern bis hin zu „echten“ 3-Schichten-Systemen. Vor allem die Unterschiede auf der Client- und der Application-Server-Seite sind gravierend. Da gerade bei den neueren Architekturen die Lernkurve von Anwendern und Anbietern noch nicht so ausgeprägt ist, entstehen hier die größten Ressourcenprobleme. Häufig unterschätzt: Integrationsaufwendungen der neuen Architekturen und die Mängel an Performanz und individueller Ergonomie bei Web-Clients.
• Notwendigkeit zur Beherrschung unterschiedlicher Entwicklungsumgebungen. Wenn ein Großunternehmen 5 verschiedene DMS-Lösungen in Betrieb hat, hat es wahrscheinlich auch 5 verschiedene Werkzeugkisten, um diese Lösungen zu programmieren, anzupassen und die anderen Systeme zu integrieren.
• Preisunterschiede. Der boomende Markt für kleine und mittlere Lösungen (das sind nicht nur KMUs, sondern auch Abteilungen von Großunternehmen, die mit einem kleinen Budget eine Lösung für ein Problem suchen) fordert Lösungen im unteren Preisbereich, die schnell zu installieren, einfach anzupassen und zu betreiben sind. Hier müssen die „Global Player“ häufig passen. Der „Massenmarkt“ wird nicht adressiert. Da weder Microsoft noch andere hierfür geeignete Produkte haben (der SPS in Version 2 hat deutlich weniger DMS-Funktionalität als die Version 1; das deutsche Dauerthema Archivierung wird von Microsoft überhaupt nicht adressiert) wird eine Lücke gelassen, in der sich viele kleinere Anbieter derzeit anscheinend sehr wohl fühlen. Die hohen Zuwachsraten dieser Anbieter sind ein Indiz dafür.
• Unterschiedliche Ansprechpartner und Support-Strukturen für die verschiedenen Content-Lösungen, die sich nicht nur im Hinblick auf zeitliche/geografische Verfügbarkeit und Know-how, sondern auch in Bezug auf die unterschiedlichen Support-Systeme erheblich unterscheiden.

Diesem sich abzeichnenden (oder bereits vorhandenen) Wildwuchs begegnen Unternehmen mit ECM-Strategien, die die Anzahl der Systeme und Plattformen und damit die Gesamtkosten reduzieren sollen. Wichtige Elemente dieser Strategien sollten sein:

• Analyse der geforderten Content-Funktionalität. Welche Content-Funktionen sind heute und zukünftig notwendig, welche dieser Anforderungen können mit einer zu minimierenden Zahl von Lösungen abgedeckt werden? Hierbei spielt auch eine Rolle, dass Firmen wie SAP oder Microsoft Content-Funktionen anbieten, die eine logische Ergänzung ihrer vorhandenen Infrastruktur beim Anwender sind. Kein Anwender würde den SAP Content Server einsetzen, wenn er nicht bereits SAP-Anwender wäre. Aber als SAP-Anwender verfügt das Unternehmen bereits über eine Fülle von Content-orientierten Funktionen, die es unter dem Gesichtspunkt der Betriebskosten sinnvoll erscheinen lassen, weniger Funktionalität zu akzeptieren, dafür aber die Einführung einer weiteren Anwendungsplattform vermeiden zu können. Diese Strategie hat ihre Grenzen, wo die vorhandene Plattform funktional nicht ausreicht, zum Beispiel bei der mangelnden Eignung des Microsoft SPS für hochvolumige, revisionssichere Dokumentenarchive mit Tausenden von Scans pro Tag. Klassisches Beispiel für Nischen, die häufig den Einsatz dedizierter Systeme erfordern, sind PDM-Projekte, deren Anforderungen von den klassischen DMS-Produkten nicht abgedeckt werden. PDM-Anbieter wie ProCAD, Eigner  und andere haben sich dadurch in dieser geschützten Nische festgesetzt, weitgehend unbehelligt von den DMS-/ECM-Anbietern und bei Nicht-SAP-Anwendern, die die PLM-Funktionen der SAP nicht nutzen können.
• Vorgabe von Standards für Plattformen, Middleware, Technologievorgaben für die Ebenen einer Mehrschichten-Architektur, Rechtesysteme, etc. 2 Grundregeln: 1. Keine K.-o.-Kriterien, die die Anzahl relevanter Anbieter bei ehrlicher Beantwortung auf Null reduziert! 2. Architektur nicht als Allheilmittel betrachten: Man kann architektonisch sauber aber unergonomisch oder unperformant Projekte wirksam killen.
• Analyse, welche Umgebungssysteme (kaufmännische Anwendungen, ERP-Systeme, Mailsysteme etc) Content erzeugen, die im ECM-System abgelegt werden. Das Problem ist hier weniger die Frage der Ablage selbst, sondern vielmehr die Frage, wie man an den Content herankommt, wie man ihn aus dem anderen System übernimmt, ob man ihn konvertiert oder im Originalformat belässt (oder beides) und wie und in welchem Format für welches System man ihn wieder zur Verfügung stellen kann. Beispiel ist die Ausgangspost aus Hostsystemen, die Mail aus Exchange, die Drucklisten aus SAP, die alle bestimmten Ordnern/Ablagen/Ordnungskriterien im ECM zugeordnet werden sollen.
• Analyse, für welche Zielsysteme (abfragende Systeme) Content aus dem ECM zur Verfügung gestellt werden muss, wenn der Content ursprünglich gar nicht aus dem abfragenden Anwendungssystem kommt. Die Kernfrage hier ist die der Verknüpfung zwischen dem Content und dem Anwendungssystem. Klassiches Beispiel sind Eingangsrechnungen, die mit SAP verknüpft sind. Was bei SAP-Basisanwendungen und ADP Paisy über Standard-DMS-Verknüpfungsszenarien einfach lösbar ist, wird bei vielen anderen Anwendungen zur Projektaufgabe, wenn der ECM-Hersteller selbst keine Integrationsschnittstelle zur Verfügung stellt.
• Welche Content-Lebenszyklen sind in dem ECM abzubilden. Konkret bedeutet dies die Beantwortung von Fragen wie:
  • Wie sollen Objekte übernommen werden? Manuell oder systemgesteuert. Synchron (Bsp: MS Office) oder asnychron (Bsp. Druckspool)?
  • Was soll mit dem Objekt im Quellsystem geschehen? Löschen, durch Restobjekt ersetzen?
  • Wie kommt das Quellsystem (Outlook, DB-Anwendung, Hostanwendung) wieder an das ausgelagerte Objekt? Konkret: Wie sollen die beiden Anwendungen (bzw. die Datenbanken) so miteinander verknüpft werden, dass ein späteres Retrieval aus der Quellanwendung (oder einer anderen anfragenden Anwendung) wieder möglich ist. Welche Datenbanken sollen mit welchen Indexwerten aktualisiert/synchronisiert werden? Ist sichergestellt, dass keine Indexlücke entsteht (wenn die Eingangspost auf dem Host und auf dem DMS indexiert wird: passiert das auch mit der zu archivierenden Mail oder wird diese nur im Mailsystem und dem DMS indexiert?)
  • Wie soll das Objekt abgelegt/archiviert werden? Im Originalformat, in einem konvertierten Format? Was soll man mit proprietären oder exotischen Formaten (1403 Drucklisten, AFP-Druckspools, Echange oder Domino-Objekte etc., Auslagerungsdateien aus Datenbankanwendungen) tun?
  • Welche Prozesse sind abzubilden? Typische Beispiele sind Entstehung, Versionierung, Genehmigung, Freizeichnung, Veröffentlichung in Original- oder Rendition-Format.
  • In welche Prozesse der Fachanwendungen sind die Content-Abläufe zu integrieren?
• Berücksichtigung rechtlicher Rahmenbedingungen.  Sobald es um die Verwaltung von Content geht, der handels-, steuer- oder zivilrechtlich relevant ist, muss geprüft werden, ob die gesetzlichen oder betrieblichen Vorgaben im System umgesetzt werden können. Mit der zunehmenden Sensibilisierung des Gesetzgebers für die Relevanz elektronischer Dokumente, erhält das Thema „Komformität“ der Systeme mit den geltenden regulatorischen Anforderungen schnell zunehmende Bedeutung und damit die Verfügbarkeit einer Verfahrensdokumentation für die eingesetzten Systeme und Verfahren.

Fazit: 
Für die Anwender mit umfangreichen heterogenen Anforderungen bieten sich zunehmend „echte“ ECM-Funktionsportfolien die die Basis für eine unternehmensweite ECM-Strategie bilden können. Dazu muss der Anwender aber analysieren, was er benötigt. ECM ist kein feststehender Begriff. Der Anwender muss ihn mit konkreten Anforderungen füllen und sich am Markt – ausgestattet mit genügend Kompromissfähigkeit – die für seine Probleme passende Lösung suchen. Dies sollte er mit einem Anforderungskatalog tun, der seinen konkreten, individuellen Anforderungen abdeckt und nicht einfach eine Zusammenstellung aller jemals gehörten oder gelesenen Features darstellt. Die Abfrage der für die eigenen Zwecke kritischen Funktionen und Merkmale ist wichtig: die Produkte unterscheiden sich fundamental in vielen Kriterien: Architektur, Funktionalität, Integrationsfähigkeit, Aufwand für Installation und Betrieb. Die Herausforderung für die Anbieter ist, die theoretisch funktionierenden Konzepte technisch umzusetzen, sonst gilt der alte Beraterwitz: Auf welcher Plattform läuft diese Lösung? Antwort: Auf PowerPoint!