Im Rahmen des Seminarthemas beschäftigt sich diese Arbeit mit der Archivierung von Geschäftsdokumenten innerhalb des Enterprise Resource Planning Systems (= ERP)[1] SAP R/3 der Firma SAP AG[2].
Da das SAP R/3-System keine eigene Lösung für diesen Aufgabenbereich bereitstellt, werden hier die funktionalen und technischen Anforderungen an Archivsysteme untersucht, welche als externe Ablagesysteme in ein SAP R/3-System integriert werden können. Um die spezifischen Anforderungen an derartige Systeme festzustellen, müssen folgende Aspekte untersucht und daraufhin existierende Lösungen verschiedener Anbieter auf ihre Einsatztauglichkeit geprüft werden.
Zunächst werden im ersten Teil die erwarteten funktionalen Erweiterungen aus der Sicht des Nutzers eines SAP R/3-Systems erfasst, woraus ein erstes Anforderungsprofil für integrierbare Archivsysteme hervorgeht.
Dieses Anforderungsprofil wird im zweiten Teil bezüglich funktionaler und qualitativer Aspekte sowie deren technischer Umsetzung differenziert, um geeignete Systeme aus der Vielfalt existierender Lösungen herausfiltern zu können.
Der dritte Teil beschäftigt sich mit der softwaretechnischen Seite der Integrierbarkeit externer Archivsysteme in ein SAP R/3-System, die sich aus den architektonischen Prinzipien einer modernen Standardsoftware wie des SAP R/3-Systems ergeben.
Nachdem die funktionalen und die allgemeinen technischen Anforderungen besprochen worden sind, beschäftigt sich der vierte Teil mit der Frage, welche Technologie eine sinnvolle Zusammenarbeit zwischen einem SAP R/3-System und einem angebundenen Archivsystem unterstützt. Wesentlich ist dabei die Kooperation der systeminternen Datenverwaltungen beider Systeme und der daraus resultierende Archivierungsprozess. Weiterhin soll ein kurzer Überblick über Technologien zum Auslagern und zum Retrieval von Dokumenten gegeben werden.
I. Funktionalitätsanforderungen aus Anwendersicht
Bevor die Deklaration eines Anforderungsprofils für Archivsysteme als funktionale Erweiterung des SAP R/3 vorgenommen werden kann, sind folgende Aspekte ausführlicher zu betrachten.
A. Warum bietet SAP R/3 keine eigene Lösung?
Zunächst drängt sich die Frage auf, warum das SAP R/3-System keine eigene Archivierungslösung bietet, obwohl es als Marktführer im Bereich der betriebswirtschaftlichen Anwendungslösungen eine umfassende Unterstützung organisatorischen Informationsmanagements leisten möchte (Buck-Emden, S. 110 f).
Eine Antwort ergibt sich aus einer näheren Betrachtung der Zielsetzungen des SAP R/3: es soll eine „integrierte, vollständige Unterstützung von Geschäftsprozessen“ (Buck-Emden, S. 289) geleistet werden, die „ ... eine einheitliche Sicht auf alle Daten und Geschäftsprozesse im Unternehmen ermöglicht.“ (Buck-Emden, S. 110). Dazu werden Funktionalitätskomponenten für betriebswirtschaftliche Kernbereiche wie Rechnungswesen, Logistik und Personalwirtschaft sowie branchenspezifische Lösungen bereitgestellt, die je nach Anwenderbedarf kombinier- und konfigurierbar sind (Buck-Emden S. 292 ff).
Dabei wird deutlich, dass die Kernkompetenzen des SAP R/3 in der Abbildung betriebswirtschaftlicher Prozesse auf Softwaresysteme und der Bereitstellung DV-technischer Verarbeitungshilfen für die Anwendungsgebiete liegt. Allerdings beinhaltet es kein zentrales Dokumentenmanagement, welches eine sichere Ablage mit Archivierungs- und Recherchemöglichkeiten für die vielen ein- und ausgehenden Dokumente im organisatorischen Umfeld bietet. Genau das ist der Aufgabenbereich für ein zu integrierendes Archivsystem, welcher im Folgenden weiter differenziert werden soll.
B. Aspekte der funktionalen Erweiterung
Zwei wesentliche Anforderungen bestehen für eine funktionale Erweiterung durch Integration eines Archivsystems in SAP R/3: erstens eine zentrale Datenverwaltung und zweitens die Integration der Bedienbarkeit des Archivsystems in die Anwenderoberfläche.
B.1. zentrale Dokumentenverwaltung
Unter einer zentralen Dokumentenverwaltung wird verstanden, dass alle ein- und ausgehenden Dokumente in einem zentralen Ablagesystem gehalten werden (Gulbins, S. 11). Dabei stehen in dem hier zu untersuchenden Zusammenhang vier Aspekte im Vordergrund, die deutliche qualitative Verbesserungen für den Anwender darstellen und demnach funktionale Anforderungen an ein integrierbares Archivsystem darstellen.
Der erste Aspekt ist eine sicherere Lagerung der Dokumente, als dies durch eine lokale Ablage durch die Sachbearbeiter in ein SAP R/3-Systems erreicht werden kann. Außerdem vereinfacht eine zentrale Dokumentenverwaltung die Erstellung eines Archivs, da auf alle vorhandenen Dokumente zugegriffen werden kann.
Als zweiter Aspekt ist die Mehrfachnutzbarkeit zu nennen: hierunter wird verstanden, dass mehrere Benutzer gleichzeitig Dokumente ansehen oder bearbeiten können (Balzert, S. 306). So können notwendige Arbeitsschritte gleichzeitig durchgeführt und mittels einer Versionskontrolle (Balzert, S. 311) Änderungen und Zugriffe auf ein Dokument nachverfolgt werden.
Der dritte Aspekt ist die Möglichkeit zur Recherche nach Dokumenten, was als Grundfunktionalität von Archivsystemen gefordert wird. Diese Funktionalität stellt auf grund der großen Anzahl ein- und ausgehender Dokumente einen wesentlichen Beweggrund zum Einsatz von Archivsystemen im Bereich der betriebswirtschaftlichen Anwendungen dar (siehe Kapitel II).
Neben den drei allgemeinen Aspekten zur funktionalen Erweiterung besteht hier zusätzlich die Anforderung, SAP R/3-interne Dokumentenverwaltungen wie beispielsweise das Workflow-Management zu unterstützen (vgl. Buck-Emden, S. 282- 288).
B.2.Integration in die Anwenderoberfläche
Die Forderung nach der Integration der Bedienung des Archivsystems in die Arbeitsumgebung des SAP R/3 hat den Grund, dass Mitarbeiter keine zusätzlichen technisch-administrativen Aufgaben zur Bedienung des Archivsystems erlernen und durchführen müssen (IXOS-Archive inside, S. 25).
Dieser Aspekt erfordert von verwendbaren Lösungen eine Unterstützung der Technologien zur Datenpräsentation des SAP R/3, so dass die Benutzerschnittstelle des Archivsystems in die graphische Benutzeroberfläche des R/3 (= SAPGUI) integriert werden kann. Die technische Realisierung dieser Anforderung wird im Zusammenhang der softwaretechnischen Integrierbarkeit externer Systeme in ein SAP R/3-System detaillierter untersucht (siehe Kapitel III).
Aus den kurz skizzierten Anforderungen aus Anwendersicht für eine tatsächliche Funktionalitätserweiterung des SAP R/3-Systems ergibt sich folgendes erstes Anforderungsprofil:
Das Aufgabengebiet des Archivsystems besteht in der Ablage und Verwaltung aller ein- und ausgehender Dokumente einer Organisation. Dabei soll zum einen eine qualitative Erhöhung des organisationsinternen Dokumentenmanagements durch eine zentrale Dokumentenverwaltung erreicht werden, da diese sichere Lagerung, eine Zugangskontrolle sowie die Mehrfachnutzbarkeit der Dokumente gewährleistet. Zum anderen sollen DV-technische Funktionalitäten wie Recherchemöglichkeiten, Workflow-Unterstützung und Integration in die Benutzeroberfläche die Unterstützung der Abwicklung von Geschäftsprozessen durch das SAP R/3 ergänzen.
Dieser erste Anforderungskatalog soll in den folgenden Kapiteln differenziert und bezüglich der technischen Realisierung untersucht werden.
II. Anforderungsprofil an integrierbare Archivsysteme
Hier soll nun das Anforderungsprofil weiter spezifiziert werden. Dazu werden zunächst die Anforderungsaspekte genauer spezifiziert, um anschließend an Hand des Anforderungskataloges die Eignung einer Auswahl von existierenden Lösungen verschiedener Anbieter zu diskutieren.
A. Differenzierung des Anforderungsprofils
Zur Differenzierung des Profils werden die funktionalen und qualitativen Anforderungen für die Anbindung von Archivsystemen an ein SAP R/3-Systems an Hand von 5 Kriterien definiert[3]. Hierdurch soll ein detaillierterer Anforderungskatalog für Archivsysteme als funktionale Erweiterung eines SAP R/3-Systems entstehen, der außerdem als Abgrenzung gegenüber anderen elektronischen Archivsystemen dient.
A.1. Vielseitigkeit
Das Kriterium der Vielseitigkeit erfasst den nötigen Spezialisierungsgrad des Einsatzgebietes eines Archivsystems (vgl. Cook, S. 16). Im allgemeinen wird ein weit gefächertes Einsatzgebiet als Qualitätsindikator eines Archivsystems angesehen: in dem hier besprochenen Zusammenhang besteht allerdings nur ein sehr begrenztes Aufgabengebiet.
Denn die Hauptaufgabe ist hier die Bereitstellung eines sicheren Ablagesystems für Geschäftsdokumente, in dem recherchiert werden kann und welches sich sinnvoll in ein SAP R/3-System integriert lässt. Es werden also keine umfangreichen Verwaltungsfunktionen für Dokumente benötigt, da sonst eine Überlappung der Funktionalität mit dem SAP R/3-System entstünde. Damit unterscheiden sich die geeigneten Systeme in Ihrer Zielsetzung von den zahlreich existierenden Knowledge- und Document-Management-Systemen: während diese eher Konkurrenzprodukte zum SAP R/3-System darstellen, wird hier ein qualitativ hochwertiges Ablagesystem zum langfristigen Auslagern großer Informationsmengen benötigt (CE Archiv, S. 3).
A.2. Universalität
Unter dem Kriterium Universalität werden elektronische
Archivsysteme bezüglich des zu verarbeitenden Archivguts klassifiziert. Dabei
sind sowohl die Art Dokumente und als auch die zu unterstützten Datenformate zu
definieren(Cook, S. 17).
Die Art der hier zu verarbeitenden Dokumente unterteilt sich in
CI- und NCI-Daten, wobei für beider Datenarten die jeweiligen standardisierten
und quasi-standardisierten Datenformate sowie Komprimierungsverfahren zu
unterstützen sind.
Auf eine differenzierte Ausarbeitung dieses Bereiches wird
verzichtet (vgl. hierzu Gulbins, S. 167 – 180), da für die Klassifikation
geeigneter Archivsysteme lediglich wichtig ist, dass nur die Verarbeitung von
Standardformaten sowie einiger proprietärer Datenformate des SAP R/3-Systems
unterstützt werden muss. Weiterhin ist anzumerken, dass im Bereich der
betriebswirtschaftlichen Dokumentenverwaltung fast ausschließlich DIN-genormte
Papiergrößen in meist ausreichend guter Vorlagenqualität zur Verarbeitung
anfallen.
Somit beschränkt sich das zu verarbeitende Archivgut auf wenige
Arten, die allgemein anerkannten Standards unterliegen. Dies ist ein wichtiges
Abgrenzungskriterium gegen andere Einsatzbereiche von Archivsystemen, in denen
viele Sonderformate berücksichtigt werden müssen (z.B. schlechte
Vorlagenqualität im Bereich der historischen Archivierung): denn so kann sich
der Entwicklungsschwerpunkt verwendbarer Archivsysteme auf die Qualität der
Verarbeitungsmechanismen konzentrieren.
A.3. Langfristigkeit
Dieses Kriterium
beschäftigt sich mit dem Nutzungszeitraum eines Archivs, welcher im Bereich der
elektronischen Archivsysteme die einzusetzende Speichertechnologie determiniert
(Cook, S. 19-21). Die Wahl des Mediums sollte
bezüglich der Kapazität, der durchschnittlichen Lebensdauer des Mediums und
andererseits bzgl. der zukünftigen Verfügbarkeit geeigneter Abspielgeräte
getroffen werden[4].
Der Einsatz von Archivsystemen im Bereich der
betriebswirtschaftlichen Dokumentenverwaltung lässt sich in drei Kategorien
gliedern: erstens den betriebswirtschaftlichen Einsatz zur Unterstützung
aktueller Geschäfts-prozesse, zweitens die gesetzliche vorgeschriebene
Aufbewahrung und drittens die Archivierung zur internen Dokumentation.
Für den betriebswirtschaftlichen Einsatz sollten Speichermedien
eingesetzt werden, die - neben ausreichender Kapazität - im Archivsystem zwecks
Wiederzugriff verfügbar bleiben können. Hierzu eignen sich CD-R-, WORM- oder
Jukebox-Systeme[5].
Die gesetzliche Aufbewahrung fordert nach dem Handels- und
Steuergesetz lediglich eine „... ‚ordnungsgemäße, qualifizierte Ablage und
Aufbewahrung der Nachweise’.“[6]
Dabei können auf grund der relativ geringen Wiederzugriffsrate die Medien aus
dem Archivsystem entfernt werden, so dass sich hier vor allem CD-R-Systeme oder
Datenbänder anbieten.
Die interne Archivierung ist eigenmotiviert, so für die verwandte
Technologie dass keine Vorschriften einzuhalten sind. Hierbei spielt die
Verfügbarkeit geeigneter Abspielsysteme für das Speichermedium eine große
Rolle, wobei sich momentan die Verwendung von CD-R-Systemen empfiehlt: dieses
Medium kann gut gelagert werden und die langfristige Verfügbarkeit von
Abspielgeräten ist auf grund der Verbreitung von CD-R-System relativ
wahrscheinlich.
Dieses Klassifikationskriterium umfasst die sicherheitstechnischen Aspekte elektronischer Archivsysteme, welchen für den Einsatz von Softwaresystemen zur Verwaltung sensibler Daten eine besondere Beachtung zu schenken ist (vgl. Cook, S. 25-27). Dabei sind als drei wesentliche Aspekte die Stabilität, Datenschutz und Datensicherheit sowie die Verfügbarkeit des Systems zu nennen, welche hier kurz bezüglich der resultierenden Ansprüche an verwendbare Archivsysteme besprochen werden sollen.
Zur Sicherung der Stabilität sollte das System administrationsfähig sein, so dass nach einem Systemfehler ein konsistenter Zustand sowie eventuell verloren gegangene Daten mittels entsprechender Recovery-Mechanismen wieder hergestellt werden können (IXOS-Archive inside, S. 15-17).
Besonders wichtig ist der Bereich des Datenschutz und der Datensicherheit, um die Einsicht und Änderung von Dokumenten durch unbefugte Personen zu verhindern. Ziel ist dabei die „... Gewährleitung von Vertraulichkeit, die Integrität, Authentizität sowie die Verbindlichkeit gespeicherter Informationen ...“ (vgl. Balzert, S. 307). Gewöhnlich wird dieser Anspruch durch Vergabe von „... Nutzungsrechten mit Login und Passwort ...“ (vgl. Balzert, S. 308) realisiert: zur Integration in ein SAP R/3-System sollten die Zugangskontrollen in entsprechenden Berechtigungsprofile des R/3 integriert werden können (vgl. hierzu Will, S. 190 – 196).
Der Anspruch an professionelle Softwaresysteme einer Systemverfügbarkeit von 99,9 % kann allein von softwaretechnischer Seite nie garantiert werden (vgl. Balzert, S. 23), so dass hier eine hardwareseitige Sicherungsarchitektur bereitgestellt werden muss. Eine Möglichkeit ist eine 2-Server-Architektur: beim Ausfall des ersten Servers kann der zweite ohne zeitliche Verzögerung die Aufgaben übernehmen (vgl. IXOS-Archive inside, S: 10-11).
Diese Realisierung dieser Anforderungen erhöht zwar die Kosten eines geeigneten Systems, doch nur so kann die nötige sicherheitstechnische Qualität erreicht werden.
A.5. Beschreibungsqualität und Recherchemöglichkeit
Das Kriterium der Beschreibungsqualität behandelt Fragen der funktionalen Qualität von Archivsystemen. Darunter fallen die Katalogisierung der Archivs, die Indizierung und Attributvergabe für archivierte Dokumente sowie die Darstellungsqualität von NCI-Daten. Hier werden nur die Funktionalitäten besprochen, da deren Realisierungen später ausführlicher behandelt werden (siehe Kapitel IV).
A.5.1. Die Katalogisierung
Hierunter wird verstanden, dass die Struktur sowie die Benennung des Archivs und seiner Substruktur vom Anwender selber definiert werden kann und dass die Möglichkeit der Einsicht dieser Struktur in einer geeigneten Darstellungsform gegeben ist (vgl. Cook, S. 28).
Für das hier untersuchte Einsatzgebiet von elektronischen Archivsystemen sollte also die Strukturdefinition vor der Erstellung des Archivs durch den Nutzer möglich sein, da man so den Bedürfnissen des Anwenders am besten gerecht werden kann. Zur Einsicht bestehender Archive sollte ein entsprechender „Archiv-Explorer“ (IXOS-Archive inside, S. 27) bereitgestellt werden, mit dem durch die Archivstruktur navigiert werden kann.
A.5.2. Indizierung und Attributvergabe
Die Indizierung der zu archivierenden Dokumente ist die Grundlage der archivinternen Dokumentenverwaltung: der Index wird separat gespeichert und verweist auf die logische Lageradresse des entsprechenden Dokuments (vgl. Cook, S. 29). Die Attributvergabe enthält Angaben, die eine ausreichende Beschreibung zur inhaltlichen Zuordnung des Dokuments ermöglichen sollen. Diese Attribute stellen die Grundlage für die Recherchefunktionalität im Archiv dar: über eine Suchfunktion kann der Anwender sich Trefferlisten anzeigen lassen und auf diese Weise ein Dokument wiederfinden (vgl. Cook, S. 30-31).
Die technische Funktionsweise dieser Vorgänge werden später detaillierter erläutert (siehe Kapitel IV).
A.5.3.Darstellungsqualität von NCI-Daten
Dieser Aspekt beschäftigt sich mit der Frage, mit welcher Auflösung NCI-Daten im Archivsystem gehalten werden sollen und welche Komprimierungs-verfahren eingesetzt werden sollen (vgl. Cook, S. 32-33).
Hierbei wird für schwarz-weiß sowie für farbige Dokumente allgemein eine Auflösung von 300 dpi empfohlen, da hier das Verhältnis zwischen Qualität und Speicherbedarf am günstigsten ist. Außerdem können bei dieser Auflösung noch Techniken wie ORC zur Umwandlung von NCI- in CI-Daten angewandt werden (vgl. Gulbins, S. 143 – 152).
B. Vergleich existierender Lösungen
Die bisherigen Ausführungen zu funktionalen und qualitativen Anforderungen an verwendbare Archivsysteme zur Integration in ein SAP R/3-System zeigen ein sehr eng eingegrenztes Anforderungsprofil auf, wodurch die Auswahl an existierenden Lösungen stark eingeschränkt wird. Um einen strukturierten Überblick zu erhalten, werden die Ergebnisse des vorangehenden Teils noch einmal zusammengefasst. Daran anschließend werden diejenigen existierenden Systeme kurz vorstellt, die auf grund des Anforderungskataloges für eine Integration in Frage kommen.
B.1. Zusammenfassung des Anforderungsprofils
Die Ausführungen zur Vielseitigkeit definieren das genaue Einsatzgebiet des Archivsystems: es soll als Ablagesystem für Geschäftsdokumente mit einigen qualitativ hochwertigen Funktionalitäten dienen.
Die Anforderungen bezüglich der Universalität verlangen die Unterstützung von Standardformaten, was sich sowohl auf die Größe von Dokumenten als auch auf die entsprechenden Datenformate bezieht. Dabei werden an die Technologie besonders hohe Qualitätsanforderungen gestellt.
Um die unter dem Aspekt der Langfristigkeit genannten drei Kategorien der Archivierung zuzulassen, muss die Nutzbarkeit der entsprechenden optischen und magnetischen Speichermedien gewährleistet werden.
Aus dem Bereich der Sicherheit entstehen Forderungen nach einem Administrationswerkzeug für das Archivsystem, die Gewährleistung des Datenschutzes durch die Vergabe von Nutungsrechten sowie die Bereitstellung einer hardwareseitigen Lösung zur Sicherstellung der geforderten Systemverfügbarkeit.
Als letztes werden als eigentliche Archivierungsfunktionalitäten die eigenständige Definierbarkeit eines Archivs, eine geeignete Indizierung und Attributvergabe sowie die Unterstützung von Technologien zur Ablage von NCI-Daten gefordert.
B.2. Auswahl verwendbarer Archivsysteme
Auf grund des sehr eng spezifizierten Anforderungsprofils fallen viele existierende Lösungen für Archivsysteme aus der engeren Wahl für eine Integration in das SAP R/3-System heraus. Unter anderem wären hier sehr funktionstüchtige und weit verbreitete Knowledge- und Document-Management-Systeme wie „knowledge mission“ der Firma knowledgepark AG (knowledge mission) oder „LiveLink“ der Firma Open Text Corporation (Live Link) auf grund ihrer abweichenden Zielsetzungen zu nennen.
Bei der Suche nach verwendbaren Systemen bin ich auf drei Systeme gestoßen, die den Anforderungen entsprechen:
Es handelt sich erstens um das IXOS Archive der Firma IXOS Software AG (IXOS-Archive inside), zweitens um das CE-Archiv der Firma CE Computer Equipment AG (CE Archiv) und drittens um das System Easyware der Firma Easy Software AG (Easyware).
Diese drei Systeme stellen natürlich nur eine Auswahl der möglichen einsetzbaren Lösungen dar. Allerdings habe ich sie auch deswegen ausgewählt, da sie das Anforderungsprofil erfüllen und außerdem die nötigen softwaretechnischen Anforderungen (siehe Kapitel III) sowie die Schnittstelle SAPArchiveLink (siehe Kapitel IV) unterstützen.
Sie erfüllen somit alle Anforderungen für eine Integration und sollen deshalb repräsentativ für andere existierende Systeme zur Erläuterung der technischen Anforderungen herangezogen werden.
III. Integration aus softwaretechnischer Sicht
Nachdem das Anforderungsprofil aus nutzerbezogenen und funktional-qualitativen Gesichtspunkten erstellt sowie eine repräsentative Auswahl verwendbarer Systeme gefunden wurde, sollen in den nächsten beiden Kapiteln die weiterführenden technischen Anforderungen besprochen werden.
Zunächst werden in
diesem Kapitel jene softtechnischen Aspekte behandelt, die aus den gegebenen
Architekturprinzipien des SAP R/3 resultieren: es handelt sich um eine
betriebswirtschaftliche Standardsoftware (Buck-Emden, S. 14), aus dessen
architektonischer Konzeption sich grundlegende Konsequenzen für zu
integrierende Softwaresysteme ergeben.
Der Begriff Standardsoftware besagt, dass bei der
architektonischen Konzeption des R/3 – Systems international festgelegte
Standards berücksichtigt wurden. Ziel dieses Prinzips ist, dass ein SAP
R/3-System in vielen Umgebungen lauffähig ist und andere Systeme in das SAP R/3
integriert werden können, solange sie ebenfalls die entsprechenden Standards
unterstützen (vgl. Buck-Emden, S. 15-17). Um ein Archivsystem in das SAP R/3
integrieren zu können, muss dieses natürlich auch die entsprechenden
Konventionen unterstützen.
Die Standardisierung des SAP R/3 ist sehr differenziert und
komplex. Für das hier untersuchte Gebiet reicht eine kurze Betrachtung
folgender drei Aspekte aus, die eine direkte Auswirkung auf die Architektur
eines integrierbaren DMS mit sich bringen: erstens die Basistechnologien
computergestützter Datenverarbeitung, zweitens das Client- Server-Prinzip als
das grundlegende Konzept moderner Softwaretechnik und drittens das
Komponentenmodell, welches eine Anpassung des SAP R/3-Systems an die konkreten
Anforderungen eines Nutzers ermöglicht.
Unter Basistechnologien werden hier Betriebssysteme,
Netzwerktechnologien, Internettechnologien und Datenbankmanagementsysteme (=
DBMS) verstanden. Grundlegende Voraussetzung für ein Softwaresystem ist, dass
die einzelnen Funktionsbausteine die gleichen Technologien verwenden oder dass
geeignete Schnittstellen die Interaktionen unterstützen. (vgl. Balzert, S. 367
ff.).
Das SAP R/3-System unterstützt folgende Technologien, die auch in
den genannten Archivsysteme Verwendung finden (vgl. die jeweiligen White
Papers): im Bereich der Server-Betriebssysteme Windows NT / 2000 Server sowie
die größeren UNIX-Derivate mit deren Netzwerktechnologien, die grundlegenden
Internettechnologien (HTML und XML,
JAVA, HTTP und TCP / IP) sowie die verbreiteten relationalen DBMS Oracle, DB2,
Microsoft SQL Server und Informix (vgl. Buck-Emden, S. 121-123, S. 147-153).
Das Client-Server-Prinzip bedeutet allgemein gesprochen, dass ein
Server (Diener) eine Funktionalität anbietet, die vom Client (Klienten)
angefordert werden kann. Der Server führt die geforderte Funktionalität aus und
teilt dem Client die Ergebnisse mit (vgl. Balzert, S. 425). Dieses Konzept wird
unter anderem bei der Architektur von Softwaresystemen eingesetzt, wobei die
grundlegende Struktur eine
3-Schichten-Architektur ist, in der die Funktionalitäten nach
Präsentation, Fachkonzept und Datenhaltung getrennt werden und gegenseitig als
Server bzw. Client fungieren (vgl. Balzert, S. 426 ff.).
Dieses Konzept liegt – mit kleinen Detailunterschieden – bei den
genannten Systemen vor, vorbei die eigentlichen Archivfunktionalitäten als
Server fungieren und die Anwenderschnittstellen die Clientseite darstellen
(vgl. auch hier jeweiligen White Papers). Diese Architektur ist eine
Grundvoraussetzung für die Integrierbarkeit in die Client-Server-Struktur des
SAP R/3-Systems (Buck-Emden, S. 119-120): nur so kann eine Interaktion zwischen
den Systemen gewährleistet werden, wobei das Archivsystem hierbei die Rolle des
Servers übernimmt.
Unter dem Komponentenmodell des SAP R/3 wird verstanden, dass das die gesamte Funktionalität des System aus kleinen, eigenständigen Softwarekomponenten besteht, welche mit den anderen Komponenten kommunizieren und je nach Nutzerbedürfnissen kombiniert werden können. Die Kommunikation der Komponenten wird über eine Middleware ermöglicht, welche das technische Herzstück des Komponentenmodells darstellt. Dieses Architekturprinzip erlaubt eine beliebige Kombination der Komponenten eines SAP R/3-Systems und die Integration externer Systeme – allerdings müssen diese auch die entsprechende Technologie unterstützten ( vgl.Buck-Emden, S. 189 - 98).
Die Funktionsweise dieser Middleware beruht auf einer Erweiterung
des Client-Server-Prinzips durch eine standardisierte
Kommunikations-funktionalität: die
anfragende Komponente (Client) übersetzt die nötigen Informationen zunächst in
ein sprachen- und plattformunabhängiges Format. Diese Daten werden an die
befragte Komponente (Server) weitergeleitet, welche die angefragte Funktion
ausführt und die Ergebnisse in entsprechender Weise wieder an die anfragende
Komponente zurückleitet (vgl. Balzert, S. 473). Zur Realisierung dieser
Kommunikationsfunktionalität stehen drei Technologien zur Verfügung, welche
natürlich alle inkompatibel zueinander sind und jeweils andere architektonische
Konsequenzen hervorrufen: CORBA als offiziell verabschiedeter Standard der OMG[7],
COM als proprietärer, aber etablierter Industriestandard von Microsoft[8]
und JavaBeans der Firma SUN als Komponententechnologie für Java-Umgebungen[9].
Die Unterstützung dieser
Komponententechnologie erfordert eine aufwendige softwaretechnische
Entwicklung: bei den drei Archivsystemen ist die Anforderung implizit erfüllt,
da sie die Schnittstelle SAPArchiveLink unterstützen (siehe Kapitel IV).
In diesem Kapitel sollen nun die technischen Prozesse des Archivierens von Dokumenten aus dem SAP R/3-System besprochen werden. Dabei werden zunächst die Probleme der Auslagerung sowie die Konsequenzen besprochen, die sich aus der Unterstützung der Schnittstelle SAPArchiveLink ergeben. Anschließend sollen die verwandten Technologien zum Archivieren und zum Recherchieren von Dokumenten behandelt werden.
Anzumerken ist hierbei, dass die Funktionalitäten bei allen drei genannten Archivsystemen grundsätzlich gleich sind. Da die Intention dieser Arbeit in der Erläuterung der Prinzipien liegt, werden diese allgemein für alle Systeme beschrieben. Vernachlässigt werden dabei Detaildifferenzen, die bei einer Entscheidung für ein Archivsystem natürlich eine gewichtige Rolle spielen können.
A. Auslagerung von Dokumenten aus dem SAP R/3
A.1. Problematik bei der Auslagerung
Die Problematik des Archivierens von Daten und Dokumenten aus
einem SAP R/3-System in ein externes Ablagesystem besteht darin, dass bei einer
solchen Auslagerung die Dokumente aus der internen Verwaltung des SAP R/3
herausgelöst werden müssen. Da diese interne Dokumentenverwaltung des SAP R/3
die Grundlage für die qualitativ hochwertige Unterstützungsfunktionen der
Abwicklung von Geschäftsprozesse eines SAP R/3-Nutzers ist, muss die
Möglichkeit der Wiedereinbindung der Dokumente in diese interne
Dokumentenverwaltung für eine sinnvolle Archivierung gegeben sein (Buck-Emden,
S . 280-282).
Möglichkeiten zur Realisierung dieser Anforderung bestehen
entweder darin, eine Übernahme der relevanten Steuerungsdaten in das
Archivsystem zu ermöglichen[10],
oder in der Unterstützung der R/3-Schnittstelle SAPArchiveLink, wie sie von den
drei genannten Archivsystemen realisiert wird (vgl. die jeweiligen White
Papers).
Die Schnittstelle SAPArchiveLink dient einerseits als
Kommunikationsschnittstelle innerhalb des Komponentenmodells und fordert die
Unterstützung der entsprechenden Technologien (s.o.) auf der Server-Seite, also
vom Archivsystem. Andererseits stellt sie die benötigten Dienste für die oben
angesprochene Wiedereinbindung in die R/3–interne Dokumentenverwaltung zur Verfügung: dabei werden Steuerungsdaten
für das Dokument in einer Datenbank hinterlegt. Diese Datenbank befindet sich
auf der Seite des SAP R/3-Systems, so dass sich der administrative Teil des
Archivs sowie die Steuerungsdaten zur Wiedereingliederung der Dokumente
innerhalb des SAP R/3 befindet (Buck-Emden, S. 281).
Um Wiedereingliederung der Dokumente in das R/3-System zu
ermöglichen, werden fünf Arten von Steuerungsdaten hinterlegt (vgl. Buck-Emden,
S. 281-282).
Die ersten beiden Arten sind ein Dokumentenindex sowie die
zugehörige Archivstruktur, welche zur Administration des externen Archivs
benötigt werden. Als dritte Art werden die vergebenen Attribute des Dokumentes
hinterlegt, wodurch die oben erläuterte Beschreibung der Dokumente vorgenommen
wird (siehe Kapitel II). Die vierte Art von Steuerungsdaten ist das
Dokumentenformat, welche die Zuordnung zur entsprechenden Verarbeitungsapplikation
des SAP R/3 gewährleistet. Die fünfte Art von Steuerungsdaten speichert die
Objektidentität des SAP-Business-Objektes, wodurch das ausgelagerte Dokument
wieder in seine Anwendungsumgebung reintegriert werden kann[11].
Weiterhin übernimmt SAPArchiveLink die Wiedereingliederung der
Dokumente mittels der Steuerungsdaten 3 bis 5, so dass die Archivsysteme zur
Unterstützung dieser Schnittstelle lediglich die Nutzung der ersten und zweiten
Art von Steuerungsdaten gewährleistet werden muss (Buck-Emden, S. 282).
Zur Unterstützung der Schnittstelle SAPArchiveLink muss das
Archivsystem eine Schnittstelle definieren, welche die Nutzung der beiden Arten
von Steuerungsdaten ermöglicht. In den vorgestellten Archivsystemen tragen
diese Schnittstellen folgende Bezeichnungen: „IXOS Archive for R/3“ beim IXOS
Archive (IXOS inside, S. 5), „CE Archiv Link for R/3“ beim CE Archiv (CE
Archiv, S. 38) und „Easy for mySAP.com“ bei Easyware (Easyware, S. 12).
Da der generelle Ablauf des Archivierungsprozesses bei allen
Systemen gleich ist, soll er beispielhaft unter der Verwendung des IXOS Archiv
erläutert werden:
|
|
|||
|
Abb. 1:
Archivierungsprozess unter Verwendung des IXOS Archive |
Ein zu archivierendes Dokument wird an die Schnittstelle
SAPArchiveLink geleitet. Dort werden die oben beschriebenen Steuerungsdaten in
der Archiv-Datenbank innerhalb des SAP R/3 ablegt. Nun wird das Dokument durch
die Schnittstelle „IXOS Archive for R/3“ an die Document Pipeline des IXOS
Archive weitergeleitet: diese fungiert
lediglich als Verarbeitungspuffer, um die Konsistenz und die Stabilität
des IXOS Archive zu gewährleisten. Die eigentliche Verarbeitung des Dokumentes
wird im sogenannten Document Service-Modul geleistet: hier wird das Dokument
mit seinem zuvor definierten Index in das entsprechende Archiv übertragen,
dessen Struktur ebenfalls in der SAP-Archivdatenbank hinterlegt ist. Die
Speicherung erfolgt zunächst auf eine Festplatte, bevor die Daten auf die
gewählten Speichermedien übertragen werden. Als Speichertechnologie können je
nach Bedarf dabei CD-ROM, WORM-Systeme, Jukeboxen oder auch Datenbänder
verwendet werden. Die Verwaltung der Speichermedien erfolgt über STORM-Modul
(Storage Manager for Optical Media), welches über den Administrationsserver
gesteuert werden kann. Dazu stehen Log-Files über ein Monitoring-System zwecks
Kontrolle zur Verfügung und es kann in die entsprechenden Prozesse eingegriffen
werden (siehe Abb. 1).
Die Retrievalfunktionalität bietet dem Nutzer eine Suche nach
Dokumenten über die hinterlegten Attribute an. Zunächst wird eine Trefferliste
aus den angegebenen Suchparametern zusammengestellt. Wählt der Nutzer ein
Dokument aus, so wird die logische Adresse des Dokuments durch den
Dokumentenindex aus der Archivdatenbank ermittelt und vom Speichermedium in das
Document-Service-Modul geladen, so dass es einsehbar ist (siehe rote Pfeile,
Abb. 1). Soll das Dokument wieder in
das SAP R/3-System reintegriert werden, so werden die entsprechenden Funktionalitäten
der Schnittstelle SAPArchiveLink aktiviert
(vgl. IXOS-Archive inside, S. 14-18, und Buck-Emden, S.280-282).
Im hier besprochenen Anwendungsgebiet von Archivsystemen
existieren drei Archivierungsszenarien: für die Auslagerung einer großen Anzahl
von Dokumenten stehen dabei für CI-Daten ein COLD-Modul und für NCI-Daten ein
Scan-Modul zur Verfügung, während zur Archivierung von Einzeldokumenten
Verfahren bereitstehen, deren Nutzung in die jeweilige Anwenderoberfläche
integriert ist.
Da auch diese Funktionalitäten bei den drei Systemen gleichartig
sind, werden im Folgenden nur die allgemeinen Funktionsweisen erläutert.
B.1. COLD-Modul
Das COLD-Modul (Computer Output on Laser Disk) ermöglicht die
Auslagerung großer Bestände an CI-Daten. Dabei kann der Anwender vor der
Auslagerung die Archivstruktur sowie die Attribute zur Beschreibung der
Dokumente bestimmen (vgl. IXOS-Archive COLD). Es werden dabei zwei Varianten
angeboten: einmal die Archivierung sogenannter Drucklisten und zum anderen
Dokumentenlisten[12].
Eine Druckliste enthält mehrere Dokumente, die in einem
inhaltlichen Zusammenhang stehen (z.B. Dokumente eines SAP-Business-Objektes),
weshalb sie im Archiv als ein Dokument behandelt wird. Dieses Verfahren dient
zum Archivieren abgeschlossener Geschäftsprozesse (IXOS-Archive inside, S.18).
Dokumentenlisten enthalten mehrere Dokumente, die allerdings nicht in einem direkten inhaltlichen Zusammenhang stehen. Die Dokumente werden jeweils separat indiziert und dann in ein gemeinsames Archiv ausgelagert. Diese Technik dient zum Auslagern von Daten, die keinem SAP-Business-Objekt zugeordnet sind (IXOS-Archive inside, S.19).
B.2. Scan-Modul
Das Scan-Modul eines Archivsystems ist ein hochqualitativer
Scan-Client, der die Archivierung großer Bestände von NCI-Daten durch eine
zentrale Stelle ermöglicht. Mit geeigneter Hardware kann die geforderte
Darstellungsqualität gewährleistet werden und verschiedene Funktionalitäten
erlauben eine Nachbearbeitung der Dokumente (vgl. IXOS-Archive inside, S. 209).
Für die Archivierung werden drei Verfahren bezüglich der Reihenfolge der Auslagerung und der Erfassung im SAP R/3 unterschieden, aus denen je eine verschiedenartige organisationsinterne Dokumentenverwaltung resultiert[13].Beim frühen Archivieren wird das Dokument erst ausgelagert und dann erfasst, bei gleichzeitigen Archivieren geschieht dies gleichzeitig und beim späten Archivieren wird das Dokument erst erfasst und dann archiviert (IXOS-Archive inside, S.20).
B.3. Einzeldokument-Archivierung
Durch die Möglichkeit der Einzelarchivierung von Dokumenten soll der im Anforderungsprofil genannten Forderung nach einer zentralen Dokumentenverwaltung nachgekommen werden. Der Anwender soll erstellte Dokumente mit selbst definierten Attributen in das Archivsystem einpflegen können, statt diese lokal zu speichern; wesentlich dabei ist die Integration der Bedienbarkeit dieser Funktionalität in die Anwenderoberfläche, um dem Anwender zusätzliche technisch-administrative Aufgaben zu ersparen (vgl. Kapitel I).
Im hier betrachteten Untersuchungsumfeld sind dabei vier verschiedene Szenarien für die Archivierung von Einzeldokumenten zu unterscheiden: erstens aus dem SAP R/3-Umfeld, zweitens aus sogenannten Groupware-Applikationen, drittens aus Desktop-Applikationen und viertens über das Internet (IXOS-Archive inside, S. 21-24).
Im SAP R/3-Umfeld sollte dabei die Nutzung der Archivierungsfunktionalität in die Anwenderoberfläche des SAPOffice[14] integriert sein. Für Group-Applikationen und Desktop-Applikationen sollte die Integration ebenfalls in der Benutzeroberfläche stattfinden; diese Integration ergibt noch eine weitere funktionale Erweiterung des SAP R/3-Systems: denn werden Dokumente aus Group- oder Desktop-Applikationen in das Archiv eingespielt, können diese automatisch innerhalb des SAP R/3 erfasst werden. Für die Archivierung von Dokumenten über das Internet muss eine entsprechende Infrastruktur geschaffen werden, welche hier nicht weiter ausgeführt werden soll[15].
An dieser Stelle existiert ein wesentlicher Qualitätsunterschied zwischen den drei Systemen. Während alle entsprechende Schnittstellen für die Einzeldokument-Archivierung aus Group- und Desktop-Applikationen sowie aus dem Internet darstellen, bietet nur das IXOS-Archive diese Funktion aus dem SAP R/3-Umfeld an: dabei wird es auch dem Anspruch nicht völlig gerecht, da die Dokumente nur im TIFF-Format archiviert werden können (vgl. IXOS-Archive inside, S. 21).
Die Recherche im Archiv geschieht mittels einer Suchmaske, in der
ein Archiv (damit ist eine abgeschlossene Archivstruktur mit einer definierten
Bezeichnung gemeint) durchsucht werden kann, wobei die entsprechenden
Beschreibungsattribute als Suchparameter genutzt werden (vgl. Gulbins, S.
33-36).
Die Suchmasken sind in die jeweilige Arbeitsumgebung des
Archivnutzers integriert. Hiermit sind die gleichen Arbeitsumgebungen gemeint,
die bei der Einzeldokument-Archivierung unterschieden wurden: das SAP
R/3-Umfeld, Group- und Desktop-Applikationen sowie das Internet (vgl.
IXOS-Archive inside, S. 25-30).
Wichtiger als die Suchmasken sind die Werkzeuge zum Einsehen von
Dokumenten, da diese die unterschiedlichen Datenformate unterstützen müssen.
Dabei werden von den drei behandelten Archivsystemen Lösungen angeboten, die
unterschiedliche Funktionalitäten anbieten:
Das IXOS Archive beinhaltet den IXOS Viewer, der u. a. das
Einfügen von Kommentaren sowie ein ORC-Modul zur Wandlung con NCI- in CI-Daten
bietet (IXOS –Archive inside, S. 32-34). Der „Document Explorer“ des CE Archiv
ist eine Kombination aus Archiv-Katalog, Scan-Client und Dokumentenanzeige (CE
Archiv, S. 34), wobei die Funktionalität des „Mappenmanager“ von Easyware noch
weitreichender angelegt sind (Easyware, S. 6).
Als letzter Aspekt der Retrievalwerkzeuge beschäftigt sich mit der Wiedereingliederung von Dokumenten in da SAP R/3-System. Das technische Prinzip wurde bereits im Abschnitt über SAPArchiveLink erläutert, so dass nur noch die Frage nach der Platzierung der Bedienbarkeit dieser Funktion aus Anwendersicht bestehen bleibt: als eine weitere Gemeinsamkeit wird diese Funktion in allen drei Systemen in den oben beschriebenen Werkzeugen zur Dokumentenansicht angeboten (vgl. die jeweiligen White Papers).
Aus den Ausführungen wird deutlich, dass verwendbare Archivsysteme für eine funktionale Erweiterung des SAP R/3-Systems ein sehr eng eingegrenztes Anforderungsprofil erfüllen müssen und dass es auf grund dieser Tatsache nur relativ wenige einsetzbare Lösungen gibt.
Die wesentlichen Aspekte des Anforderungsprofils sind erstens das Aufgabengebiet, welches – im Gegensatz zu den Zielsetzungen vieler existierender Systeme – lediglich ein Ablagesystem mit hoher funktionaler Qualität qualitativen Anforderungen stellt. Zweitens ist sind auf der softwaretechnischen Seite vor allem die Unterstützung der nötigen Komponententechnologien für eine Integration in das SAP R/3 zu nennen, weshalb ein komplexes Architekturkonzept der Systeme erforderlich ist . Als dritter Aspekt, welcher die Auswahl an existierenden Systemen noch weiter einschränkt, ist die Unterstützung der Schnittstelle SAPArchiveLink zu nennen, wodurch eine sinnvolle funktionale Integration von Archivsystemen in ein SAP R/3 überhaupt ermöglicht wird.
Die drei repräsentativ ausgewählten Systeme zeigen jedoch, dass durchaus Lösungen existieren, die diese hohen Anforderungen erfüllen. Der Vergleich der Systeme zeigt, dass sie fast gleichwertige Funktionalitäten liefern. Für das IXOS Archive spricht, dass es erstens eine Einzeldokument-Archivierung aus dem SAP R/3-Umfeld erlaubt (welche allerdings auch nicht ganz den Anforderungen entspricht) und zweitens die Tatsache, dass die Schnittstelle SAPArchiveLink in einer Zusammenarbeit der Firmen SAP AG und IXOS Software AG entstanden ist (vgl. Buck-Emden, S.280). Denn man könnte annehmen, dass die IXOS Software AG ein speziell auf dieses Einsatzgebiet ausgerichtetes Archivsystem entworfen hat: allerdings zeigen die Untersuchungen, dass die beiden anderen Produkte mindestens gleichwertig sind, so dass bei einer Entscheidung für den Einsatz eines Archivsystems als funktionale Erweiterung des SAP R/3 letztendlich die schon angesprochenen Detailunterschiede sowie kostentechnische Gesichtpunkte ausschlaggebend sein werden.
|
Begriff |
Erläuterung |
|
CD-R |
Compact Disk Recordable: einmal / mehrmals beschreibbare Daten-CD Speicherkapazität : 650 – 800 MB |
|
CI |
Coded Information: DV-technisch erstellte Daten in einem Format, das Steuerungs-/Beschreibungsdaten enthält. Steuerungsdaten des Dokumentes sind dabei inkludiert. |
|
COLD-Modul |
Computer Output On Laser Disk: System zur Ablage von CI-Daten auf optischen Speichermedien mit Archivfunktionalität durch Indizierung und Attributvergabe. |
|
COM |
Common Object Model: Proprietäre Komponententechnologie von Microsoft, die sich auf grund ihrer Verbreitung als Quasi-Standard etabliert hat. |
|
CORBA |
Common Object Request Broker Architecture: Durch die OMG definierter Standard für die Komponententechnologie |
|
Datenband |
magnetische Speichertechnologie, die noch großflächig im Einsatz ist. Speicherkapazität: bis zu 1 GB pro Kassette. Als Weiterentwicklung existieren optische Bänder mit Kapazitäten bis zu 1 TB pro Band – diese Technologie ist allerdings bisher wenig verbreitet. |
|
DBMS |
Datenbank Management System: Verwaltungssystem für große Datenbestände, in dem die physikalische Datenhaltung und der Datenzugriff durch eine Schnittstelle getrennt werden. Im Einsatz befinden sich derzeit zum überwiegenden Teil relationale DBMS. |
|
ERP |
Enterprise Resource Planning System: Computergestützte Verwaltungssysteme für Unternehmen. Während die früherer nur zur administrativen Unterstützung prozessorientierter Bereiche wie Produktion eingesetzt wurden, soll heute das gesamte Informationsmanagement einer Organisation unterstützt werden. |
|
HTML |
Hyper Text Markup Language: Untersprache von SGML; Datenformat von Internetseiten. |
|
HTTP |
Hyper Text Transfer Protocol: Verbindungsprotokoll zum Aufrufen von Diensten auf Servern. |
|
JavaBeans |
Komponententechnologie für Java-Umgebungen: mit Beans werden die nötigen Schnittstellen und persistenten Objekte definiert. |
|
Jukebox |
System mit mehreren optisch-magnetischen Speichermedien, die durch einen automatischen Wechselmechanismus gleichzeitig im System bereitgehalten werden können. Speicherkapazität: bis zu 1000 GB |
|
NCI |
Non Coded Information: in einem Format vorliegende Daten / Dokumente, das keine Steuerungs-/Beschreibungsdaten enthält. Informationen über das Dokument müssen extern hinzugefügt werden. |
|
OCR |
Optical Character Recognition: Umwandlung von NCI-Daten in CI-Daten durch Texterkennung. Dabei erhält das neue CI-Dokument zusätzlich entsprechende Steuerungsdaten. |
|
OMG |
Object Management Group: Zusammenschluss von Unternehmen zur Verabschiedung von Standards in der Softwaretechnik, der mittlerweile über 100 Unternehmen angehören. |
|
SAP R/3 |
ERP- System der SAP AG: betriebswirtschaftliche Standardsoftware, welche die Marktführerschaft im Bereich der ERP-Systeme innehat. R3 steht für Real Time System, Version 3, aktuelles Release: 4.0 |
|
SAPGUI |
SAP Graphical User Interface: Benutzeroberfläche des SAP R/3-Systems, die dem Anwender eine einheitliche, individuell konfigurierbare Arbeitsumgebung bietet. Um eine Integration externer Systeme in diese Oberfläche zu ermöglichen, müssen die entsprechenden R/3-internern Technologien der Datenpräsentation unterstützt werden. |
|
TCP / IP |
Transmission Control Protocol / Internet
Protocol: Übertragungsprotokoll: TCP sichert die Korrektheit der Datenpakete, IP unterstützt die Weiterleitung. |
|
WORM |
Write Once Read Only Memory: einmal beschreibbarer optischer Speicher Speicherkapazität: unterschiedlich, größer als bei CD-R |
|
XML |
Extended Markup Language: Untersprache von SGML; Datenformat zur Definition logischer Dokumentenstruktur, welches zur Übertragung von Daten zwischen heterogenen Systemumgebungen eingesetzt wird. |
|
Balzert |
|
|
|
Balzert, Heide: Lehrbuch der Objektmodellierung. Analyse und Entwurf. Heidelberg: Spektrum Akademischer Verlag 1996. |
|
Buck-Emden |
|
|
|
Buck-Emden, Rüdiger: Die Technologie des SAP R/3-Systems.
Basis für betriebswirtschaftliche Anwendungen. 4. aktualisierte und erw. Aufl. Bonn: Addison Wesley Longman
Verlag 1999 (=Edition SAP). |
|
Cook |
|
|
|
Cook,
Michael: The Management of Information from Archives. Vermont (USA): Gower
Publishing Company 1986. |
|
Gulbins |
|
|
|
Gulbins, Jürgen; Seyfried, Manfred; Strack-Zimmermann, Hans: Elektronische Archivsysteme. Image-Management-Systeme, Dokumenten-Management-Systeme. Berlin, Heidelberg: Springer Verlag. |
|
Will |
|
|
|
Liane Will (Hrsg. SAP AG): SAP R/3 Systemadministration. Basiswissen für das SAP R/3-Systemmanagement. Bonn: Addison Wesley Longman 1998 (= SAP Expertenwissen). |
|
|
|
|
CE Archiv |
|
|
|
CE Computer Equipment AG : CE
Archiv-Leistungsbeschreibung. Bielefeld:
2000 (= White Paper). |
|
Easyware |
|
|
|
Easy
Software AG: Easyware. Version 2.1 . Mülheim a. d. Ruhr 2001 (= White Paper). |
|
IXOS-Archive
COLD |
|
|
|
IXOS Software: Integrating External Data in R/3. The COLD-Modul of IXOS-Archive. Version 1. Grasbrunn / München: IXOS Software AG 1999 (= White Paper). |
|
IXOS-Archive
inside |
|
|
|
IXOS Software: IXOS-Archive inside. Architecture and Technical Overview. Version 2.1 . Grasbrunn / München: IXOS Software AG 2000 (= White Paper). |
|
knowledge mission |
|
|
|
knowledgepark
AG: knowledge mission. Die Lösung für Wissensmanagement. Version 1.3. Neu-Isenburg: 2000 (= White
Paper). |
|
Live Link |
|
|
|
Douglas
Varley: Live Link Product Summary for Version 9. Open Text Corporation 2001
(= White Paper). |