Das „E“ in ECM (Enterprise Content Management) wird häufig mit Großunternehmen assoziiert, dabei ist damit eher „unternehmensweit“ im Sinne von abteilungsübergreifend gemeint. Und hier ergeben sich nicht nur für Großunternehmen, sondern auch für viele mittelständische Unternehmen Anforderungen bzgl. Performance, Skalierbarkeit und Robustheit sowie Integration in andere Enterprise-Lösungen, wie z.B. ERP, CRM, Mail / Groupware und Benutzerverwaltung, die bei Lösungskonzeption und Plattformauswahl oft zu spät – wenn überhaupt – berücksichtigt werden.

Viele Unternehmen und Organisationen betreiben seit vielen Jahren eine DMS-Lösung. Meistens handelt es sich um abteilungsspezifische, selten um unternehmensweit betriebene Lösungen. Der weitere Ausbau zur unternehmensweiten ECM-Lösung erfolgt jedoch oft nicht. Obwohl dies eigentlich sowohl im Sinne der Anwender als auch der Hersteller und Systemintegratoren sein sollte. Die Gründe sind vielfältig. Zum einen spielen sicherlich organisatorische und innerbetriebliche Gründe eine Rolle, zum anderen jedoch auch Defizite bei den im Einsatz befindlichen Softwareprodukten, die einen weiteren Ausbau erschweren sowie die Verantwortlichen auf Anwenderseite demotivieren. Einige dieser „Showstopper“ werden im Folgenden exemplarisch erläutert.

Benutzerverwaltung

Da die Einführung einer DMS- oder ECM-Lösung immer auch ein organisatorisches Projekt ist und Arbeitsabläufe optimiert und hierfür die Unternehmensorganisation abgebildet werden soll, ist eine ausgereifte Benutzerverwaltung des Produktes wichtig. Natürlich haben alle (ernst zu nehmenden) Produkte eine Benutzerverwaltung. Aber wie funktional ist diese? Gibt es neben Benutzern und Gruppen auch echte Rollen zur optimalen Abbildung von Aufbau- und Ablauforganisation? Auch wenn ein fehlendes Rollenkonzept in einem Produkt nicht unbedingt ein K.o.-Kriterium darstellt, so kann es dem Administrator doch einige Mühen und Kopfschmerzen bereiten.

Selbstverständlich gehört in diesem Zusammenhang die Integration mit vorhandenen Benutzerverwaltungen – meistens LDAP oder Active Directory (AD) – zur Standardaufgabe bei der Systemeinführung. Über Single-Sign-On (SSO) und Benutzer- sowie Gruppensynchronisierung hinaus gibt es jedoch in fast allen größeren Projekten über den Standard hinausgehende Anforderungen, wie zum Beispiel mehrere parallele ADs, Fail-Over Mechanismen bei der Anmeldung über einen AD-Service, zu integrierende externe Identity Management Lösungen (z.B. als Authentifizierungsdienst einen Sun One Directory Server o.a.), zusätzliche Authentifizierung über Drittsysteme (z.B. SAP), unterschiedliche Benutzerverzeichnisse für a) interne Benutzer und b) externe Benutzer mit unterschiedlichen Anmeldeverfahren (a=SSO, b=Login-Dialog). Dies kann gar nicht alles im Standard eines einzigen ECM-Produktes umgesetzt sein. Wichtig ist jedoch, dass die AD/LDAP-Schnittstelle der ECM-Lösung eine Release-fähige und trotzdem offene Schnittstelle für projektspezifische Erweiterungen besitzt und beim Anbieter oder Integrator ausreichendes Know-how für eine Umsetzung vorhanden ist.

Mandantenfähigkeit

Bei der Bewertung von Lösungen sollte darauf geachtet werden, ob weitere Mandanten mehr oder weniger komplette zusätzliche Instanzen darstellen, oder ob auch mandantenübergreifende Einstellungen und Objekte unterstützt werden, so dass sich der Mehraufwand für Konfiguration, Administration und Systempflege bei weiteren Mandanten nicht dramatisch erhöht (unter der Annahme, dass die Verwendung mandantenübergreifender Strukturen auch zulässig und gewünscht ist).

Beispiele für mandantenübergreifende Einstellungen und Objekte sind konzernweite Vorgaben bzgl. Dokumentklassen, Aufbewahrungsfristen, Indexkriterien und genereller Ablagestrukturen, standardisierte Branchenkataloge sowie ERP-, LDAP- oder Portal-Anbindungen.

Auch sind Anwendungsfälle bekannt, bei denen entgegen der eigentlichen Mandantendefinition eine Zusammenarbeit über Mandantengrenzen hinweg erforderlich ist, was wiederum spezielle Anforderungen an die Umsetzung der Lösung stellt.

Selbst beim Scanbetrieb kann Mandantenfähigkeit eine Anforderung sein. Neben einer dedizierten Berechtigungssteuerung ist bei einer zentralen Scanverarbeitung (evtl. zzgl. Klassifizierung und Vorerfassung) für unterschiedliche Unternehmensbereiche ggf. eine Mandantentrennung organisatorisch abzubilden.

Mehrsprachigkeit und Locale Support

Beim unternehmensweiten Einsatz spielt Mehrsprachigkeit eine große Rolle. Bei ECM-Lösungen sind neben der Verfügbarkeit der Benutzeroberfläche in den entsprechenden Sprachen insbesondere der Multi-Language-Support bei Masken, Indexwerten, Strukturen sowie der Suche von Bedeutung.

Zum Thema „Locale Support“ gehören Anforderungen nach korrekter Sortierfolge basierend auf dem lokalen Zeichensatz (z.B. ISO-8859-1 / Latin 1 in Westeuropa, Latin 2 in Mittel- und Osteuropa oder Latin 5 in der Türkei bis ISO-8859-16 / Latin 10 oder Unicode) sowie landesspezifische Nummern-, Währungs- und Datumsformatierung bei Anzeige und Eingabe.

Transportsystem

Ein umfassendes und komfortables Transportsystem ist des Weiteren von großer Bedeutung: Typischerweise hat man in größeren Organisationen mehrere Systemumgebungen. Somit ist es wichtig, dass die Konfiguration von Entwicklungs- zu Test-, Produktiv- und Schulungssystem transportiert werden kann, inkl. Masken, Optionen und Einstellungen, Strukturen, Abläufen / Workflows, Customizing, Skripten, Berechtigungen und Benutzer- bzw. Gruppenzuordnungen. Nacharbeiten im Zielsystem sollten nicht oder zumindest nur sehr begrenzt erforderlich sein.

Auch im Mehrmandantenbetrieb wird ein Transportsystem sehr hilfreich sein und sogar eventuelle Schwächen bei der Mandantenfähigkeit des eingesetzten Systems (siehe Kriterien oben) abmildern.

Schnittstellen & Entwicklungswerkzeuge

Neben den Standardschnittstellen zu weit verbreiteten Systemen wie SAP, Exchange oder Notes/Domino, existieren bei allen relevanten Lösungen weitere Möglichkeiten, externe Applikationen zu integrieren oder Daten auszutauschen, zum Beispiel über dateibasierte Schnittstellen (basierend z.B. auf XML oder CSV). Wichtig für die projektspezifische Integration in andere Applikationen ist eine Programmierschnittstelle, idealerweise als Webservice für eine plattform- und programmiersprachenunabhängige Implementierung. Wenn ein Anbieter darstellt, dass er Schnittstellen als Webservices zur Verfügung stellt, muss man prüfen, welche Funktionsaufrufe zur Verfügung stehen, weil diese häufig noch nicht umfänglich sind. Nutzen evtl. Komponenten oder Module des Herstellers auch diese Programmierschnittstelle? Dann kann man eher davon ausgehen, dass sie nicht nur umfangreich, sondern auch entsprechend stabil sein wird und gut für projektspezifische Entwicklungen mit hohen Anforderungen bzgl. Qualität, Zuverlässigkeit und Wartbarkeit verwendet werden kann. Wobei sicherlich auch die Webservices eines Herstellers, der intern aus Performancegründen eine Low-Level-API verwendet, stabil und umfassend sein können.

Ein anderer Aspekt bei der Bewertung und Auswahl des richtigen Integrationswerkzeugs ist die komponentenübergreifende Durchgängigkeit. Gibt es ein durchgängiges Entwicklungs-, Integrations- und Automatisierungsframework? Oder sind für verschiedene Komponenten und Anforderungen unterschiedliche Werkzeuge zu verwenden? Neben erhöhtem Know-how- oder Ausbildungsbedarf sowie Pflegeaufwand und Stabilitätsnachteilen kann es in diesem Fall vorkommen, dass Businesslogik mehrfach entwickelt werden muss, mit allen sich daraus ergebenden Nachteilen.

Ein einfaches Beispiel ist die Ablage eines Dokumentes im DMS. Dies kann gegebenenfalls abhängig von Use Case oder Anwender per Webbrowser, Voll-Client oder Drag&Drop über Webdav-Folder geschehen. In allen Fällen sollen die gleichen Pflichtfelder ausgewählt und Werte vererbt werden, automatisch Aktionen gestartet sowie die gleiche Berechtigungsprüfung erfolgen. Ob dies über eine einzelne gekapselte Businesslogik abzubilden ist oder mehrfach umgesetzt werden muss, zeigt deutlich die Reife des eingesetzten Integrationsframeworks. Dem Anwender sollte es lieber sein wenn es nur einmal gemacht werden muss, dafür aber richtig und stabil.

Verfügbarkeit, Skalierbarkeit und Virtualisierung

Ein besonderes Augenmerk ist auf Enterprise-Anforderungen wie Hochverfügbarkeit, Skalierbarkeit und Virtualisierung in geschäftskritischen Einsatzfeldern zu richten. Zur Erfüllung dieser Kriterien sollten Server-Dienste idealerweise Multi-CPU-, Multi-Core- und Multithreading-fähig sein. Die Zuordnung weiterer Ressourcen (physikalisch wie virtuell) hat zu einer signifikanten Durchsatzsteigerung zu führen. Integrierte Loadbalancing-Konzepte (zumindest für Systeme, die nicht komplett in einer Java Application Server-Umgebung laufen) sollten vorhanden sein, so dass zum einen die Skalierung und zum anderen auch die Verfügbarkeit durch System-eigene Komponenten unterstützt werden.

Des Weiteren sollte der Trend weg von dedizierter Betriebsumgebung und Nutzung bereits vorhandener Infrastruktur, wie Server, Storage, Datenbanken, Application Server etc. unterstützt werden, Restriktionen hierbei muss der Anbieter aufzeigen, um eine Bewertung der Betriebsfähigkeit in der eigenen IT-Architektur zu ermöglichen.

Betrieb

Ist ein System erst mal in Betrieb ergeben sich ganz neue Anforderungen, zum Beispiel an Administrierbarkeit, Verfügbarkeit und Monitoring. Und umso umfangreicher eine Implementierung ist, desto mehr Unterstützung benötigt der Administrator in seiner täglichen Arbeit. So ist es zum Beispiel wichtig, dass die Administration arbeitsplatzunabhängig (idealerweise über eine Webkonsole) erfolgen kann, so dass  auch beim standortübergreifenden Einsatz Reaktionsfähigkeit und Effizienz von Operatoren sichergestellt sind. Generell sollte eine zentrale Administration („Single-Point-of-Administration“) möglich sein (ohne Erfordernis von direktem Zugriff auf Datenbanktabellen, Registry, Konfigurationsdateien, etc.), auch über Mandantengrenzen hinweg, bei gleichzeitiger Möglichkeit der verteilten Administration durch Fachadministratoren. Auch eine organisatorische Aufteilung der Administration in zum Beispiel Benutzeradministration und „Content“-Administration kann erforderlich sein, wenn der allgemeine Administrator keine Dokumenteninhalte sehen darf, wie beispielsweise in HR-Umgebungen vorkommend. Dies geht hin bis zu Organisationen, die eine Administrationsfunktion nach dem Vier-Augen-Prinzip fordern, also eine zweistufige Administration.

Je mehr Anwender mit einem System arbeiten und umso mehr Geschäftsprozesse abgebildet sind oder maßgeblich unterstützt werden, umso höher sind die Anforderungen an die Verfügbarkeit des Systems (Stichwort 24×7 Betrieb). Somit sollte das System Wartungsarbeiten ohne spürbaren Neustart bzw. ohne Betriebsunterbrechung ermöglichen.

Monitoring

Zu den Betriebsanforderungen gehören auch: Es sollten klar strukturierte, übersichtliche und durchgängige Reports bzw. Logausgaben die Arbeit der Operatoren erleichtern und nicht unnötig erschweren. Idealerweise lässt sich die Lösung in Monitoring-Tools wie Tivoli, OpenView, Nagios oder RHQ integrieren, evtl. existieren hierfür bereits fertige Plugins oder zumindest verfügbare Musterkonfigurationen.

Terminalserver

Da Terminalserverumgebungen weit verbreitet sind, sollte die Unterstützung dieser selbstverständlich sein, möglichst ohne Einschränkungen (z.B. variabel konfigurierbare Pfade und Dateinamen). Zu beachten sind Besonderheiten bei der Aufteilung von Anwendungen auf verschiedene Citrix Serverfarmen (z.B. DMS auf anderem System als Microsoft Office oder ERP), da hier Client-basierte Integrationen problematisch sein können.

Unternehmensweiter Ausbau

Wie oben erwähnt, fand bisher oftmals kein weiterer Ausbau in Richtung unternehmensweiter Nutzung statt. Dies kann viele Ursachen haben. Neben schlechten Erfahrungen während der Umsetzung des ersten Projektes, fehlender Management-Unterstützung  oder nicht entsprechend gesetzter Prioritäten, können auch Unzulänglichkeiten der eingesetzten Produkte eine Rolle spielen. Konnten bisher architektonische oder qualitative Mängel durch ein mehr an Einsatz von Integratoren, Projektleitern oder Administratoren ausgeglichen werden, wird dies nun betriebswirtschaftlich nicht mehr tragbar.

Ein gutes, weil einfaches Beispiel hierfür ist der Client-Rollout. Konnte für die ursprünglich relativ geringe Anzahl an Benutzern das Konglomerat aus Skripten, VB-Programmen, Masken und DLLs noch irgendwie verteilt werden, ist dies unternehmensweit nicht mehr semi-manuell machbar. Bei eher volatilen Projektlösungen kommt hinzu dass häufig Updates durchgeführt werden müssen, verbunden mit entsprechendem Aufwand in der IT und teilweise erheblichen Zeitverzögerungen. Auch kann sich jetzt die Frage stellen, ob die ursprünglich gewählte Lösung der Client-basierten Integration nicht besser in einem Webservice aufgehoben wäre.

Neben den für das Initialprojekt wichtigen Kriterien kommen beim weiteren Ausbau evtl.  weitere Anforderungen hinzu (z.B. höhere Verfügbarkeitsanforderungen, weitere Sicherheitsaspekte, kritische Compliance Anforderungen, hausinterne Standards und Regelungen, Datenschutzbestimmungen, …), die womöglich mit vertretbarem Aufwand nicht abbildbar sind. Auch ist eine Kommunikation über verteilte Standorte komplexer, im Rechenzentrumsbetrieb könnte es Restriktionen beim RFC-Einsatz geben, hohe Verarbeitungsmengen stellen neue Herausforderungen, ein Output Management System (OMS) ist zu integrieren wie auch ein Verfahren zur Datenübertragung ins Rechenzentrum inkl. Message-Queueing. Hier sollte der Anwender prüfen, ob das notwendige Know-how bei den beteiligten Parteien vorhanden ist.

Weitere Anforderungen

Eine komplette Liste der technischen Anforderungen an „Enterprise“-fähige ECM-Plattformen würde den Rahmen dieses Artikels sprengen. Deswegen sollen hier nur einige wenige weitere, aber wichtige Aspekte adressiert werden:

• Rechenzentrumsbetrieb: Bei Auslagerung des Betriebs muss weiterhin die Möglichkeit der lokalen Administration durch den Fachadministrator bestehen. Außerdem werden Abrechnungsverfahren und weitere Statistiken benötigt, nutzungsabhängig und ressourcenverbrauchsabhängig.
• Repository-übergreifende Suche: Aufgrund von hohem Datenvolumen sowie vielfältigen Anwendungsszenarien werden manchmal Daten auf mehrere Repositories verteilt. Eine übergreifende Suche sollte möglich sein.
• Restriktionen und Limitierungen: Idealerweise sollte eine Lösung keine (praxisrelevanten) Restriktionen oder Limitierungen aufweisen (z.B. Anzahl Masken, Indexfelder insgesamt sowie je Objekt, Berechtigungseinstellungen je Objekt).
• Endanwenderoberfläche: Die zentrale Verwaltung von Benutzereinstellungen (inklusive persönlicher Oberflächeneinstellungen und Favoritenverwaltung) sollte möglich sein. Des Weiteren die Anpassbarkeit der Clients bis hin zu CI-Standards und dies möglichst „Release-fest“.
• Storage: Unterstützung unterschiedlicher Konzepte und Produkte. Idealerweise integrierte einfache hierarchische Speicherverwaltung, inkl. Caching mit intelligentem Purging (nicht nur nach Alter der Dokumente, sondern z.B. nach Zugriffshäufigkeit, Dokumentart, Platzverbrauch).
• Berechtigungskonzept inklusiver temporärer und dynamischer Erweiterung von Rechten im Rahmen der Vorgangsbearbeitung, ohne Unterbrechung der definierten Vererbungsregeln.
• Unterstützung mobiler Anwender.

Hinzu kommen weitere nicht-technische Anforderungen, die es zu berücksichtigen gibt, wie zum Beispiel ein Ausbildungskonzept für tausende Anwender, die man nicht alle zum Hersteller schicken kann. Neben den Konzepten sollte Praxiserfahrung vorliegen – idealerweise nachgewiesen durch zufriedene Referenzen.

Fazit

Die Anforderungen an die Enterprise-Fähigkeit von ECM-Lösungen sind vielfältig und wachsen mit der Größe der Organisation, der Anzahl Benutzer sowie der Anzahl unterstützter Geschäftsprozesse. Kein Produkt kann alle Anforderungen vollständig abdecken, so dass die Systemauswahl auch immer eine Kompromissentscheidung ist. Wichtig ist dabei dass man den alten Projektleitsatz „Start Small – Think Big“ verinnerlicht und bereits zu einem frühen Zeitpunkt an die zukünftigen Anforderungen denkt. Aber auch, dass man einen Anbieter wählt, der in der Lage ist, schnell zu reagieren und evtl. fehlende Funktionen relativ schnell und unbürokratisch umsetzen kann.

Vortrag auf DMS Expo im Oktober

Auf der DMS Expo (23.-25. Oktober 2012 in Stuttgart) wird der Autor im BITKOM ECM-Forum am 24.10. um 10:30 Uhr einen Vortrag zu diesem Thema halten. Im Anschluss besteht die Möglichkeit des Gesprächs und Erfahrungsaustauschs. Während der gesamten DMS Expo ist der Autor darüber hinaus im BITKOM ECM Solutions Park anzutreffen.