Redundanzfreie Integration

• Home
• Magazin
• Know How
• Content Management

Redundanzfreie Integration

Neben der Wahl der "richtigen" Integrationstechnologie stellt sich in jedem ECM-Projekt die Frage, wie viel ECM-Information die führende Anwendung verwalten soll: Denkbar ist, dass alle fachlichen Dokumenten-Metadaten, wie Lieferschein-Nummer, Versicherungsschein-Nummer etc. in der führenden Anwendung hinterlegt sind.

Aus anwendungstechnischer Sicht handelt es sich dann um eine saubere, redundanzfreie Integration. Dies erfordert in der Regel eine massive Erweiterung des Datenbank-Modells der führenden Anwendung, um die Zuordnung von Dokumenten zu unterschiedlichen Datensätzen, wie dem Kunden-Stammsatz, dem Schadendatensatz und dem Kündigungseintrag zu ermöglichen.

Das ECM wird hierbei auf reine Ablage- und Bereitstellungsfunktionen reduziert und kennt keinen fachlichen Bezug der Dokumente, lediglich technische Kennzeichen wie Dokumentenformat, Seiten- und Komponentenzahl (wie Anmerkungen etc.). Steht die führende Anwendung nicht zur Verfügung, gibt es auch keinen Dokumentenzugriff.

Der Zugriffsschutz ist in der führenden Anwendung hinterlegt und kann beliebig komplex gestaltet werden – in einer entkoppelten ECM-Lösung gestaltet sich hingegen gerade die Synchronisierung komplexer Zugriffsbeschränkungen schwierig.

Diese vollständige Integration in die führende Anwendungsumgebung hat in der Regel sehr hohe Einrichtungsaufwände zur Folge: Jedes Objekt, das im ECM gespeichert wird, muss in der führenden Anwendung bekannt gemacht werden, unabhängig davon, über welchen Weg es in das ECM gelangt ist. Übrigens entspricht dieser Ansatz der von SAP bereitgestellten Content Server Standard-Schnittstelle – dort fällt auf Kundenseite jedoch der geschilderte, hohe Integrationsaufwand nicht mehr an, da alle Abgleichmechanismen zwischen ECM und SAP bereits innerhalb der gelieferten Schnittstellen abgehandelt sind.

Autarke ECM-Umgebung – Freiheit kostet Redundanz

In vielen Projekten erhält das ECM jedoch ein Eigenleben: Um eine fachliche Recherche zum Beispiel mittels Kundennummer oder Buchungsnummer unmittelbar über die ECM-Infrastruktur zu ermöglichen, werden hierbei die notwendigen Recherchekriterien im ECM selbst gespeichert.

Hierdurch erhält das ECM Eigenständigkeit und muss nun diese fachlichen Daten möglichst effizient verwalten. Leider sind viele Content Management-Systeme nur mit einem eingeschränkten Datenbankmodell ausgestattet, selbst wenn für die Abbildung der Datenbank ein leistungsfähiges Datenbanksystem wie Oracle, DB/2 oder MS SQL-Server zur Verfügung steht.

Vielfach verlangt das ECM-Datenmodell, dass alle fachlichen Recherchekriterien nicht normalisiert und damit innerhalb des ECM redundant hinterlegt werden: Der Kundenname beispielsweise muss bei jedem kundenbezogenen Dokument gespeichert werden, möchte der Anwender über den Namen nach den zugeordneten Dokumenten recherchieren können. Ändert der Kunde seinen Namen, müssen alle alten Dokumente mit dem neuen Namen versorgt werden oder der Datenbestand im ECM weist einen anderen Namen auf als der Datenbestand in der führenden Fachanwendung (was aus historischer Sicht wiederum korrekt sein kann).

Das ECM kann in dieser Umgebung genutzt werden, auch wenn die führende Fachanwendung nicht zur Verfügung steht. Dies ist von Vorteil, wenn diese Fachanwendung aus technischen Gründen häufiger nicht zur Verfügung steht, die Mitarbeiter (zum Beispiel im Call-Center) dennoch ständig – zumindest beschränkt – zur Auskunft bereit sein müssen. Sporadische Nutzer brauchen überdies nicht in die führende Anwendung eingewiesen zu werden, um nach fachlichen Dokumenten zu recherchieren.

Wer mit den geschilderten Problemen der redundanten Datenhaltung leben kann, für den ist dieser Integrationsansatz immer dann interessant, wenn zusätzlich das Projektbudget eng begrenzt ist: Der Integrationsaufwand einer entkoppelten ECM-Lösung ist grundsätzlich eher gering – allerdings muss streng darauf geachtet werden, dass die auf der Basis des ECM entwickelte Lösung auf ihre Kernfunktionen beschränkt wird! Gerne wird seitens der Anwender versucht, Anwendungsfunktionen, die in der Fachanwendung fehlen, auf der Seite des ECM abbilden zu lassen, was unnötig hohe Entwicklungsaufwände zur Folge hat.

Doppelt gemoppelt hält besser

Wer ganz auf Nummer Sicher gehen will und gleichzeitig eine hoch integrierte Lösung bevorzugt, der hält die fachlichen Dokumentendaten sowohl in der führenden Anwendungsumgebung als auch im ECM: Für den Notfall und für Anwender ohne Zugriffsmöglichkeit auf die führende Anwendung stehen dann die Dokumente dennoch zur Verfügung.

Die Integrationsaufwände dieses Lösungsansatzes sind nur geringfügig höher als in der reinen Datenhaltung innerhalb der führenden Fachanwendung. Eine Reihe von SAP-Kunden verwenden zum Beispiel Produkt-Erweiterungen von ECM-Herstellern, die per "Index-Extraktion" fachliche Recherchekriterien aus SAP in das ECM übertragen und dort dem Content zusteuern.

Solche Lösungen sind selbst auf Projektbasis mit relativ geringem Aufwand umsetzbar. Allerdings ist hierbei zu beachten, dass ein ECM selten in der Lage ist, einen komplexen Zugriffsschutz, ggf. rollenbasiert und für einzelne Dokumente unterschiedlich ausgeprägt, im Systemstandard zu implementieren. Ist der in der führenden Anwendung fachlich verwaltete Dokumentenbestand inhaltlich kritisch und schutzwürdig, so steht die doppelte Indexverwaltung – in der Fachanwendung und im ECM – nur mit entsprechend hohem Aufwand in der Einrichtung eines Zugriffsschutzmodells innerhalb des ECM zur Verfügung.

Kein Industrie-Standard in Sicht – was nun?

Abgesehen von den erwähnten Hersteller-Standards von SAP und ADP sind keine weiteren Standards erkennbar, die eine ähnliche Funktionstiefe enthalten.

Kunden, die das ECM als integrierten Bestandteil ihrer führenden Fachanwendung verwenden möchten sind gut beraten, die Nutzbarkeit der von SAP definierten Schnittstelle genau zu untersuchen: Einige Anwender haben die SAP spezifischen ECM-Funktionsaufrufe in ihre führenden Anwendungen implementiert und können über diese Schnittstelle einheitlich auf jedes von SAP zertifierte Ablagesystem zugreifen.

Bei der Wahl der "richtigen" Integration spielen das Projekt-Budget und die strategische Einbettung des ECM in die betrieblichen Abläufe eine wesentliche Regel. Tiefe Integrationen dienen keinem architektonischem Selbstzweck sondern sollen helfen, die fallbezogenen Bearbeitungskosten zu reduzieren. Der ROI jeder Integration liegt typischerweise um so höher, je mehr Anwender das System nutzen, je mehr Dokumente im System gespeichert werden und je mehr Dokumentenzugriffe stattfinden.

Die Frage der "richtigen" Integrationstechnologie ist ebenfalls von den strategischen Richtlinien des Unternehmens deutlich beeinflusst. Unternehmen mit einer klaren Middleware-Ausrichtung werden versuchen, diesen Integrationsansatz auch im ECM-Projekt umzusetzen, müssen hierbei jedoch eine dedizierte Produktauswahl durchführen, da viele ECM-Hersteller Middleware-Konzepte noch nicht oder unzulänglich unterstützen. Sobald der Middleware-Ansatz nicht realisiert werden kann, müssen plattformspezifische Client- und Server-Integrationstechniken eingesetzt werden – vornehmlich ausgerichtet an den IT-strategischen Vorgaben, der vorhandenen IT-Infrastruktur, dem vorhandenen Know-how, den vom ECM bereitgestellten Möglichkeiten und dem Projekt-Budget.

Bereits bei der Produktauswahl sollten Anwender daher kritisch Plattformen und Funktionstiefe der vom ECM-Hersteller bereitgestellten API untersuchen. Wenn die Integrationsanforderungen bereits im Vorfeld exakt untersucht und spezifiziert wurden, können vom Integrator konkrete Lösungsansätze und bindende Aufwandschätzungen eingefordert werden. Die nachfolgende Checkliste zur Bewertung der Integrationsmöglichkeit eines ECM-Systems ist dabei sehr hilfreich:

Checkliste zur Bewertung der Integrationsmöglichkeit eines ECM-Systems:

• Besitzt das ECM eine standardisierte und zertifizierte Schnittstelle zu dem führenden Anwendungssystem (nur SAP und ADP Paisy)?
• Besitzt der ECM-Hersteller bereits eine fertige Lösung zur Content Integration mit der entsprechenden führenden Anwendung? Welcher Ansatz wurde gewählt – welche Funktionstiefe ist implementiert?
• Gibt es für das ECM bereits entsprechende Referenzlösungen mit gleichen Integrationsanforderungen?
• Gibt es Programmierobjekte (Java, COM usw.) und Tools zur Content Integration vom ausgewählten ECM und von der führenden Anwendung?
• Ist beim Projektpartner entsprechendes Know-how insbesondere für das bestehende führende Anwendungssystem vorhanden?
• Wie ist auf Releasewechsel der führenden Anwendung bzw. des ECM zu reagieren?
• In welchem System findet die Indexverwaltung statt?
• Lassen sich die Replikations-, Backup- und Restore-Funktionalitäten des ECM in den Backupszenarien der führenden Anwendung integrieren?
• Sind Integrationsalternativen konzeptionell ausgearbeitet und verbindlich angeboten worden?

Kommentare

Bitte beachten Sie unsere Informationen zum Datenschutz.

Weitere Artikel zum Thema