Mit einem erfolgreichen Migrationsprojekt wird man nicht Projekt-Manager des Jahres. Migrationsprojekte sind unbeliebt, aber von großer Tragweite. Im Unterschied zum Wechsel einer Textverarbeitungs- oder einer Router-Software müssen rechtliche Anforderungen berücksichtigt werden, vorhandene Anwendungen müssen integriert werden und umfangreiche Datenbestände müssen bewegt und verändert werden. Wer hier bereits bei der Produktauswahl und Einrichtung einer DMS-Umgebung auf einige Punkte achtet, kann zum Zeitpunkt der Migration viel Aufwand sparen.

Im folgenden Artikel werden die Ursachen für eine DMS-Migration und deren besondere Projektmerkmale dargestellt. Es werden Hinweise für das Vorgehen in einem Projekt und Tipps zur Aufwandsreduzierung gegeben.

Ursachenforschung

Der Wechsel eines elektronischen Archivsystems ist keine überraschende Einmalaufgabe, die nur bei Firmenübernahmen oder Systemkonsolidierungen anfällt, sondern eine regelmäßige Aufgabe während des normalen IT-Betriebes. Speicherarchitekturen sollen gewechselt werden, man ist mit dem bisherigen Anbieter unzufrieden oder es fehlen wichtige Funktionalitäten. Bei einer Betrachtung der typischen Lebenszyklen von IT-Komponenten, wie Datenbanken, Betriebssysteme oder Hardware wird klar: Aufbewahrungsfristen führen dazu, dass Dokumente von einer Systemumgebung in die nächste übernommen werden müssen. Während beispielsweise Eingangsrechnungen nach HGB „nur“ 10 Jahre aufbewahrt werden müssen, können Anlagendokumentationen durchaus eine Lebensdauer von mehreren Jahrzehnten erreichen und Kundenakten im Lebensversicherungsbereich eine Aufbewahrung von 100 Jahren und mehr erfordern. Die Umstellung von DMS-Komponenten und Dokumentenbeständen ist somit typisches Merkmal des DMS-Betriebes.

Hierbei kommt dem Herstellerwechsel – sprich dem Austausch aller DMS-Komponenten – besondere Bedeutung zu, da hier im schlimmsten Fall alle bereits gespeicherten Dokumente kopiert und eventuell sogar konvertiert werden müssen.

Besondere Merkmale einer DMS-Umgebung

Eine Textverarbeitung kann in der Regel einfach gewechselt werden: Ab einem definierten Zeitpunkt wird einfach mit dem neuen System gearbeitet. Anzeigeprogramme oder Konverter ermöglichen das Öffnen von Dokumenten, die im „alten“ Format gespeichert wurden, oder diese Dokumente liegen sowieso in Papierform, als PDF-Datei und möglicherweise in einem DMS vor.

Beim Wechsel eines DMS ist das anders: Elektronische Archive müssen gesetzlichen Anforderungen genügen und ordnungsgemäß im Sinne dieser Gesetze betrieben werden. Hier spielen Begriffe, wie Unveränderbarkeit, Vollständigkeit und Ordnung eine Rolle. Die Anforderungen gelten für das Altsystem, das neue System und auch für den Migrationsprozess selbst. Auch wenn man selbst davon überzeugt ist, dass dies so sei, reicht das nicht aus. Wirtschafts- und Betriebsprüfer wollen überzeugt werden. Somit kommt der prüfergerechten Dokumentation dieser Systeme, der sog. Verfahrensdokumentation und der Dokumentation des Migrationsprozesses eine entsprechende Bedeutung zu.

Werden Speichersysteme eingesetzt, die keine offengelegten Standard-Schnittstellen unterstützten und man nur mit Hilfsmitteln des DMS- oder des Speichersystem-Herstellers auf diese Daten zugreifen kann, entsteht ggf. das nächste schwierige Thema im Rahmen einer Systemumstellung.

Typischerweise wird ein DMS nicht auf der grünen Wiese betrieben. Es bestehen viele technische Integrationen, bspw. zu Office-Produkten, zur E-Mail-Umgebung oder zu den sogenannten führenden Anwendungen, um aus diesen Anwendungen Dokumente zu archivieren und zu recherchieren. Die Anwender erwarten hier zu Recht, dass diese Funktionalitäten nach einer Umstellung weiterhin vorhanden sind. Werden auch noch Indexdaten in der führenden Anwendung gehalten, wie bspw. SAP mit ArchiveLink dies vorsieht, ist auch deren Anpassung im Rahmen einer Migration erforderlich.

Zuletzt gilt das, was aber auch für andere Produktumstellungen gilt: Der Hersteller, von dem man weggeht, unterstützt einen im Rahmen der Migration nur leidlich bis gar nicht. Plötzlich ändern sich Preise und neue Export-Module tauchen auf, zu denen man im schlechtesten Fall nicht einmal „Nein“ sagen kann.

Und natürlich besitzt ein Migrationsprojekt die Merkmale, die auch oft in einem anderen Projekt nicht fehlen:

• Datenbestände sind inkonsistent
• Relevante Datenbestände müssen definiert und im System identifiziert werden
• Hohe Datenvolumen müssen verarbeitet werden
• Architektur von Quell- und Zielsystem sind unterschiedlich
• Es wird zusätzliche Hardware für den Migrationsprozess benötigt
• Funktionale Besonderheiten des Altsystems werden erst im Laufe des Projektes identifiziert
• Der Tagesbetrieb darf durch die Umstellung nicht beeinflusst werden
• Ressourcen-Engpässe und fehlende fachliche Qualifikation der Projekt-Mitarbeiter
• Es gibt andere Projekte und Termindruck

All diese Punkte erklären leicht, warum eine DMS-Migration ein Projekt ist, und man im Rahmen einer Produktauswahl einen gezielten Blick auf die Export-Möglichkeiten, die Protokoll-Funktionen und das Datenbankmodell der zur Auswahl stehenden DMS-Produkte werfen sollte.

Migrationsobjekte – worum geht es?

Eine DMS-Migration besteht aus einer Software-Migration und einer Daten- und Dokumenten-migration. Themen der Software-Migration sind typischerweise:

• Integration in Fachanwendungen, Office- und E-Mail-Umgebungen
• Integration in Betriebssysteme, Verzeichnisdienste, Applikations-Server, Datenbanken, Monitoring- Backup-und Reporting-Umgebungen
• Unterstützung von Server- und Client-Hardware
• Unterstützung von Scannern und Speichersystemen

Hier liegen natürlich auch Stolpersteine, die aber auch im Rahmen einer DMS-Neueinführung anfallen und daher an dieser Stelle nicht detailliert werden.

Für die Daten- und Dokumenten-Migration liegt oft das einfache Verständnis vor: Hier raus, da rein. So einfach ist es aber leider nicht. Die DMS-Produkte sind oft grundlegend unterschiedlich und es gibt nicht zu allen Bereichen Standards, auf die man zurückgreifen kann.

Sowohl Dokumenten- als auch Datenbestände und Systemeinstellungen müssen im Rahmen der Migration angefasst werden – teilweise aus technischen Gründen, weil ein Zielsystem bspw. grafische Annotationen oder Hintergrundlayouts anders verwaltet. Teilweise aber auch aus eigenem Wunsch, um alte Dokumentenformate zu konvertieren oder nicht mehr relevante Dokumente zu löschen.

Einige typische Umstellungen sind in der folgenden Tabelle aufgeführt:

Tabelle 1: Typische Daten- und Dokument-Migrationen

Vorgehensweise bei einer DMS-Migration

Steht das Migrationsprojekt an, sind die Projektschritte im Groben und die technische Vorgehensweise im Detail festzulegen. Bei der Grobplanung geht es um die Vorgehensweise insgesamt. Diese wird oft durch die folgende Frage bestimmt: Muss die Überführung der Datenbestände vollständig abgeschlossen sein, bevor das Zielsystem in Betrieb genommen werden kann oder kann das Zielsystem sofort in Betrieb genommen werden und die Migration erfolgt begleitend im Hintergrund?

Die Vorteile der letzteren Vorgehensweise liegen auf der Hand: Das neue System kann sofort genutzt werden, neue Dokumente landen nur im neuen System. Allerdings muss der Zugriff auf das Altsystem bis zum Ende der Umstellung erfolgen, bspw. durch Integration in das neue System oder die parallele Suche in zwei Systemen. Bei SAP hat man hier den Vorteil, dass SAP die Möglichkeit bietet, mehrere Content-Server unterschiedlicher DMS-Hersteller zu verwalten, so dass man hier eine laufende Migration leicht einrichten kann.

Bei der Big-Bang-Umstellung wird erst einmal migriert, ohne dass der Anwender hiervon etwas merkt. Die laufende Archivierung erfolgt hier weiterhin im Altsystem oder parallel. Hat man sich an die Dokumente der letzten Tage oder Wochen „heran migriert“, kommt meist an einem Wochenende der Cut-over: Restmigration und Produktivsetzung der neuen Umgebung. Diese Vorgehensweise führt leicht zu einem Zeitraum von mehreren Monaten, bis das neue System produktiv gesetzt werden kann.

Die Vorgehensweise in einem DMS-Migrationsprojekt orientiert sich grundsätzlich an den Projektphasen eines normalen IT-Projektes:

Tabelle 2: Projektphasen eines Migrationsprojektes

Sicherstellung der Ordnungsmäßigkeit einer Migration

Ist man am Ende einer Migration davon überzeugt, dass die Umstellung erfolgreich war, muss man dies bei Bedarf auch Dritten darstellen können. Die Ordnungsmäßigkeit der Archivierung muss gewahrt bleiben. Das bedeutet nicht die bitgenaue Umstellung von Dateien, was technisch auch nicht immer möglich ist. Eine bildliche und inhaltliche Gleichheit wird in den gesetzlichen Grundlagen gefordert. Somit ist bspw. die Konvertierung von TIFF in PDF zulässig. Auch dürfen bessere Kompressionsverfahren bspw. für Farbdokumente eingesetzt werden, solange hierdurch nicht die Lesbarkeit beeinflusst wird. Entsprechend dokumentierte Tests sichern hier die gewählte Vorgehensweise ab. Bei Dokumenten mit elektronischer Signatur führt eine Konvertierung allerdings zum Bruch der Signatur, so dass hier die Migrationsobjekte unverändert bleiben müssen, soll die Signatur erhalten bleiben.

Auch dürfen Indexbestände optimiert werden, solange eine Ordnung beim Zugriff vorhanden ist. Eine Verknüpfung von Buchung zu Beleg muss ebenfalls erhalten bleiben.

Zur Darstellung der Ordnungsmäßigkeit wird daher für das Migrationsprojekt eine entsprechende Projektdokumentation erstellt, die umfangreiche Protokolle in der Anlage besitzt, aber in der Zusammenfassung typischerweise auf die folgenden Punkte eingeht:

Tabelle 3: Inhalte einer Migrationsdokumentation

Empfehlungen zur Aufwandsminimierung

Die folgenden Hinweise sollen dabei helfen, den Aufwand für ein Migrationsprojekt zu reduzieren. Relevant sind einige dieser Punkte bereits bei der DMS-Produktauswahl, aber auch beim Customizing und dem täglichen Betrieb. Falls man sich erst zum Zeitpunkt der Migration mit den Themen beschäftigt, kann man hier auch manchmal eine Überraschung erleben.

• Fragen Sie bereits bei der Produktauswahl nach Massen-Export-  und Protokoll-Funktionen. Hiermit ist nicht „Speichern-unter“ im Viewer gemeint, sondern eher eine Maske, in der Doc-ID-Bereiche eingegeben werden können.
• Wählen Sie das Speichermedium unter Berücksichtigung möglicher Migrationen. Klären Sie, ob das System den gleichzeitigen Betrieb mehrerer Speichersysteme unterschiedlichen Typs unterstützt.
• Verstehen Sie die Art der Dokumentenspeicherung: Die Spanne geht hier von einer Einzeldateispeicherung im Quellformat in Verzeichnisstrukturen bis hin zur Speicherung vieler Dokumente, hier herstellerspezifischer Container-Objekte.
• Fragen Sie nach Migrationswerkzeugen auch für Metadaten (z. B. Indexdaten, Berechtigungsdefinitionen, Annotationen etc.).
• Verstehen Sie das Datenmodell für die Ablage der Dokumente und lassen sich dieses dokumentieren. Exportwerkzeuge sind bei den Datenbankprodukten Standard, doch diese nützen nur etwas, wenn man das Datenmodell auch versteht.
• Halten Sie die Anzahl unterschiedlicher Formate gering.
• Prüfen Sie, ob Datenbestände aufgrund der Fristenverwaltung im System identifiziert werden können.
• Löschen und Ändern: Wie wirken sich Löschungen  oder Änderungen  von bzw. an Dokumenten auf den Export dieser Dokumente aus?
• Prüfen Sie, wie unterschiedliche Versionen zu einem Dokument identifiziert werden können.
• Verwenden Sie möglichst keine grafischen Annotationen.
• Stellen Sie sicher, dass das System durch Job-Priorisierung das Kopieren von Beständen im laufenden Betrieb ermöglicht.
• Setzen Sie möglichst aktuelle Produktversionen ein. So vermeidet man, dass das Migrationsprojekt mit einem größeren System-Update kombiniert werden muss.
• Auch eine Verfahrensdokumentation kann die Migrationssicherheit erhöhen. Ein Hauptabschnitt jeder Verfahrensdokumentation sollte sich diesem Thema widmen. Dieser Abschnitt sollte vom Anbieter kommen.

Einsatz von Dienstleistern

Beim Einsatz eines Archivierungs-Dienstleisters geht man davon aus, dass dieser die obigen Fragestellungen beherrscht – schon aus Eigeninteresse. Dies kann man prüfen, mindestens sollte man aber einige Punkte auch vertraglich regeln. Beispiel:

Bei Beendigung dieses Vertrages wird der Provider dem Auftraggeber bei der Migration der archivierten Dokumente unterstützen. Insbesondere betrifft dies folgende Unterstützungsleistungen:

• Bereitstellung aller Dokumente, bei denen die Aufbewahrungsfrist noch nicht beendet ist.
• Die Objektdaten sind im Quellformat der Archivierung zu liefern.
• Bereitstellung aller Indizierungsinformationen im Textformat mit einer eindeutigen Referenzierung zu den dazugehörigen Objektdateien.
• Das Anlieferungsformat für Objekte und Indexdaten wird im Detail vor Vertragsende gemeinsam abgestimmt.
• Die Lieferung der Dokumente erfolgt maximal einen Monat nach Vertragsende.
• Die Lieferung erfolgt auf Datenträgern, die der Auftraggeber verarbeiten kann. Hierüber wird sich rechtzeitig vor Vertragsende abgestimmt.
• Die Kosten für die Bereitstellung der Dokumente sind über die Kosten dieses Vertrages abgedeckt. Es fallen keine gesonderten Aufwände an.

Trotzdem bleibt die Migration einer DMS-Umgebung ein Projekt, welches geplant und überwacht werden muss. Ist man nicht selbst willens dies zu tun, kann auch hierfür ein Dienstleister beauftragt werden. Es gibt einen kleinen Markt von Anbietern, die sich mit einem oder mehreren DMS-Produkten, der Strukturen und Export-Möglichkeiten gut auskennen. Oft empfehlen die DMS-Hersteller auch entsprechende Partner. Dies kann eine Alternative sein, allerdings lassen sich diese Partner ihr Know-how zu Recht bezahlen, denn beide Parteien wissen: Die Nicht-Migration oder der dauerhafte Betrieb des Altsystems sind keine wirkliche Alternative. Je selbstständiger ein Anwender agieren kann, desto einfacher und günstiger wird das Migrationsprojekt.

Fazit

Wie immer im Leben gilt: Hat man keine Ahnung, muss man dafür bezahlen. Dies gilt auch für Migrationsprojekte. Durch einige einfache Fragestellungen und Dokumentationen kann die Abhängigkeit zum Anbieter reduziert werden. Ziel muss sein, eine Systemumstellung auch ohne den Anbieter durchführen zu können – nicht zu müssen.

Die obigen Hinweise sollen dabei helfen, diese Abhängigkeit zu reduzieren und dies bereits im Rahmen der Produktauswahl. Allerdings gilt auch: Ein DMS-Produkt mit Top-Migrationsfunktionen und mangelhafter sonstiger Produktfunktionalität kommt sicher nicht zum Einsatz. Allerdings kann die Diskussion mit dem Anbieter über einige Migrationsaspekte, insbesondere im Rahmen der Produktauswahl, hier schnell Klarheit über Abhängigkeiten bringen. Der Anbieter wird hier deutlich mehr Aufklärungsarbeit leisten, als zu dem Zeitpunkt, an dem er abgelöst werden soll.

Da die DMS-Migration eine regelmäßige Aufgabe im Rahmen des Systembetriebes ist, sollte die grobe Vorgehensweise bereits bei der Auswahl und Einrichtung konzipiert werden – wenn auch vielleicht nur für die Schublade. Aber nur so kann sichergestellt werden, dass bei einer Gesamtkostenrechnung einer DMS-Einführung der vorher kalkulierte Nutzen nicht durch ein aufwändiges Migrationsprojekt in Frage gestellt wird.