Migration von Daten- und Dokumenten ‒ ein Leitfaden [2]

Autoren
Dr. Joachim Hartmann, freier Consultant u.a. bei der PROJECT CONSULT Unternehmensberatung GmbH
Dr. Dietmar Weiß, Inhaber der DWB Dr. Dietmar Weiß Beratung

Bei der Planung von Migrationsvorhaben ist ein notwendiger erster Schritt die sorgfältige Analyse des Daten- und Dokumentenbestandes – dieses Fazit zog der erste Artikel zum Thema in der letzten Ausgabe des DOK.magazins. Teil 2 dieses Beitrags stellt nun die konkrete Durchführung von Migrationsvorhaben in den Mittelpunkt. Dabei geht es vor allem darum, die technische Umsetzung im Detail zu planen und durchzuführen. Dazu müssen vor allem zwei Fragestellungen Beachtung finden – und vor der konkreten Durchführung beantwortet werden:

  1. Was sind mindestens Bestandteile einer Dokumenten-Migration?
  2. Welche Vorgehensweisen gibt es und liefern diese nachvollziehbare und dokumentierbare Ergebnisse?

Grundsätzlich gilt: Für die langfristige elektronische Aufbewahrung von Dokumenten, ist es sinnvoll, geeignete Formate zu evaluieren und festzulegen. Gerade bei Aufbewahrungsfristen, die über mehrere Jahrzehnte gehen, steht zu Beginn der Archivierung bereits fest, dass das Speicherformat im Laufe der Zeit höchstwahrscheinlich in ein anderes migriert werden muss. Aus Kompatibilitäts- und Kostengründen sollte daher in den Formaten archiviert werden, die nach aktuellem technischem Kenntnisstand eine lange Verfügbarkeit haben werden.

Bestandteile der zu migrierenden Dokumente identifizieren

Dokumente in ECM-Lösungen bestehen aus einem identifizierenden Teil, wie der Dokumentennummer und den Metabegriffen (wie z. B. Rechnung, Rechnungsnummer, Kundennummer, Vertragsnummer, Kundenname) sowie der eigentlichen Nutzdatei (Bild 1 fasst die wesentlichen Merkmale zusammen). Es kann sich hierbei um eine editierbare Office-Datei oder eine gescannte tif- oder pdf-Datei handeln. Es sind aber auch andere Formate möglich.

Nutzdatei-Formate
Nutzdatei-Formate sind dabei ein wichtiges Stichwort, denn die Migration von Archivsystemen wird unterschiedliche Formate liefern, die es hinsichtlich ihrer weiteren Verwendbarkeit zu überprüfen gilt. Bei der Nutzdatei, dem eigentlichen Dokument, gibt es den grundsätzlichen Unterschied zwischen CI-Dateien, also Text-Dateien, Zeichnungen, Office-Dateien und gescannten Dokumenten wie Tif-Dateien, pdf-Dateien. Reports und Druckspooldateien sind dem Wesen nach ebenfalls den CI-Daten zuzuschlagen und können beim Import nach bestimmten Sequenzen abgesucht und aufgetrennt werden. Dennoch stellen sie eine besondere Form dar und werden von den „kürzeren“ und direkt bearbeitbaren Office-Dateien unterschieden. Außerdem gibt es für Reports und Spooldateien häufig besondere Anzeigefunktionen, die weiter zu untersuchen sind.

Zusätzlich enthalten Dokumente gelegentlich Annotationen auf den Seiten der Nutzdatei. Möglich sind auch „logische Dokumente“, bei denen beispielsweise ein Vertrag in einem ECM-System aus mehreren Dateien besteht (Vertragsdokument sowie fünf Dateien für je einen Anhang). In diesem Fall gibt es eine logische Klammer um mehrere Dateien. Beim Export verursachen sowohl Annotationen sowie logische Klammern erfahrungsgemäß Schwierigkeiten, so dass diese Informationen im Zielsystem gegebenenfalls nicht exakt wiederhergestellt werden können.

Gegenwärtig kann man aufgrund von Normierungen und internationalen Standards folgende Formate als langzeitstabil erachten:

  • RTF, ASCII – als Standard-Textformate
  • PDF/A – für gescannte oder gewandelte Dokumente
  • tif – für Dokumente in schwarz/weiß
  • JPG – für Fotos
  • MP3 – als Audioformat
  • CSV, XML für die Archivierung von Metadaten und Listenformaten
  • HTML für Web-Formate

Videoformate und andere Multimediaformate sowie Formate für die Web-Seitenarchivierung sollten bei Bedarf separat untersucht werden.

Für die genannten Speicherformate sind folgende Anmerkungen zu ergänzen:

  • Der Standard („A“ für Archivierung) ist seit 2005 als ISO 19005-normiert. Damit PDF/A als Langzeitformat einsetzbar ist, gelten einige Einschränkungen gegenüber den gebräuchlichen PDF-Formaten. So müssen z.B. alle Schriften fest eingebettet sein und verlinkte Elemente, Audio- und Video-Daten sind unzulässig. Seit 2012 gibt es die an die neueren Entwicklungen angepasste sowie PDF/A-3, die auch Anhänge beliebigen Typus einbetten kann. Die vorigen Varianten sind hierzu kompatibel.
  • Das tif-Format besitzt häufig herstellerspezifische Erweiterungen zum Standard. Besonders bei mehrseitigen tif-Dateien ist darauf zu achten, dass herstellerspezifische Varianten entsprechend dokumentiert sind. Problematisch sind insbesondere elektronische Haftnotizen (sog. „Annotationen“) und Overlays in den Dokumentenseiten. Dieses Format mit diesen Elementen kann daher nur eingeschränkt empfohlen werden. Zwar gibt es im Allgemeinen keine Probleme bei der tif-Anzeige, allerdings sind bei sehr alten tif-Dokumenten durchaus Darstellungsprobleme mit heutigen Viewern bekannt. Es sollten daher Anzeige und Drucktests durchgeführt werden.
  • Bei Office-Dateien gelten die bekannten Versionskompatibilitäten. Heute seltene Formate sind in aktuelle Formate ggf. zu konvertieren, durch Viewer anzeigbar zu machen oder über die kaufmännische Betrachtung der Aufbewahrungsfristen und fachliche Bewertung von der Migration auszuschließen.
  • In diesem Zusammenhang sei ein immer wieder anzutreffendes Format genannt: MO:DCA (mixed object document content architecture). Es handelt sich dabei um ein Format für Verbunddokumente mit Text, grafischem Inhalt, Schriften und Barcodes, welches in AFP-Strömen vorkommen kann. Gelegentlich findet man auch gescannte Dokumente in diesem Format abgelegt. Hier gilt ebenfalls, dass es zu wandeln ist, wenn keine Anzeige- oder Druckfunktionen nach der Migration zur Verfügung stehen.

Grundsätzlich gilt: Soll das Originalformat erhalten bleiben, z.B. weil es weiterverarbeitet werden soll, muss ein Dokument sowohl in der Originalversion als auch in einer langzeitstabilen gewandelten Form archiviert werden.

Bild 1: Charakteristik eines elektronischen Dokumentes
Bild 1: Charakteristik eines elektronischen Dokumentes

Indexdateien
Bei den identifizierenden Bestandteilen eines Dokuments, den Indexdateien, stellt sich die Untersuchung der Lesbarkeit einfacher dar: Üblich sind hier eher Prüfungen der Darstellung vom Umlauten und des Regelwerks für die Indexwertdarstellung beim Export und für den Import. Die Besonderheiten der Indexdateien liegen in den Inhalten:

  • Sind Trennzeichen für Indexspalten auch Bestandteil im Indexwert?
  • Sind die Indexwerte alle korrekt oder ist eine Überarbeitung notwendig?
  • Und nicht zuletzt stellt sich die Frage, ob mit dem Indexwert für exportierte Dateien auch eine Prüfziffer exportiert wird, damit ein Prüfverfahren für die Unversehrtheit der Datei verwendet werden kann.

Soweit Annotationen exportierbar sind, werden die Texte gegebenenfalls mit Koordinaten in die Indexdatei oder in zusätzlichen Indexdateien zur Verfügung gestellt. Steuerzeichen, Positionsangaben des Textes und Autorenverweise sollten für die Migration geprüft werden.

Zwei Migrationsverfahren stehen zur Wahl

Hat man die Dokumentenformate untersucht und Verarbeitungsregeln erstellt, steht einem ordentlichen Transfer nichts entgegen. Für das Migrationsverfahren selbst ergeben sich dann zwei grundsätzliche Vorgehensweisen:

„On-the-Fly“-Migration mit laufenden Systemen
Bei der „On-the-Fly“-Migration (siehe Bild 2) werden die Dokumente und Daten aus einem System gelesen und in das Zielsystem übertragen. Lesen und Schreiben erfolgt über Standardfunktionen via API-Aufrufe. Es gibt im Prinzip keine Zwischenspeicherung exportierter Daten, sondern einen direkten Transfer. Im Quellsystem oder im Migrationswerkzeug wird eine Statustabelle geführt, welche Dokumente bereits transferiert wurden.

Voraussetzung für dieses Vorgehen ist, dass ein Migrationstool die Quell- und Zielsysteme direkt bedienen kann und entsprechende Schnittstellen bzw. Funktionsaufrufe besitzt. Ebenso ist selbstverständlich, dass beide Systeme verfügbar und mit einem Migrationsprogramm verbunden werden können.

Bild 2: „On-the-Fly“-Migration ‒ Ablaufschema
Bild 2: „On-the-Fly“-Migration ‒ Ablaufschema

Bild 2: „On-the-Fly“-Migration ‒ Ablaufschema

Eine Variante dieses Verfahrens kann auch eine gemeinsame Archivschnittstelle (z. B. des ERP-Systems) sein, an die beide Archivsysteme angeschlossen sind. Eine Rechercheabfrage wird standardmäßig an das neue System geschickt. Kann diese nicht beantwortet werden, wird die Abfrage über die gleiche Anbindung an das „abzulösende“ System weitergegeben und in zweifacher Weise bedient: Die gefundenen Dokumente werden in das neue System kopiert und als „migriert“ gekennzeichnet. Die Client-Abfrage bzw. der Anwender bekommt die Dokumente dabei angezeigt.

Damit kann eine Migration im laufenden Betrieb mit nicht übermäßiger zusätzlicher Last durchgeführt werden und der nicht übertragene Rest wird in einer einmaligen abschließenden Aktion übertragen.

Klassisches Export-Import-Verfahren arbeitet mit Zwischenspeicher
Das am meisten angewandte Verfahren ist der Export des relevanten Dokumentenbestandes und dessen Speicherung in einem Zwischenspeicher (siehe Bild 3). Der Export erfolgt gerne als Dateipärchen, also Nutzdatei (Dokument) und entsprechende Indexdatei. Es wird dazu eine Obergrenze an Dateien je Verzeichnis festgelegt und je nach Bedarf werden mehrere Verzeichnisse angelegt. Die erstellten Verzeichnisse können dann direkt für den Import verwendet oder „verpackt“, verschlüsselt und transferiert werden.

Beim Import wird ein systemunterstütztes Massenimportverfahren angewendet. Sowohl der Export wie auch der Import werden protokolliert, beim Import sollte für 100-prozentige Gewissheit die Prüfsumme des Dokumentes neu berechnet und mit dem ursprünglichen Wert verglichen werden.

Bild 3: Klassisches Migrationsverfahren mit Export und Import
Bild 3: Klassisches Migrationsverfahren mit Export und Import

Beide Migrationsverfahren haben Vor- und Nachteile
Vergleicht man beide Verfahren stellt man fest, dass jedes seine Vorzüge besitzt (siehe Tabelle).

„On-the-Fly“-Verfahren Klassisches Verfahren
Beide Systeme müssen in Betrieb sein. Das Migrationstool muss beide Systeme erreichen können. Das Verfahren kann bei entfernten Systemen in getrennten Netzen und unter getrennter Betriebsverantwortung eingesetzt werden.
Der Transfer benötigt sehr wenig Zwischenspeicher. Das Verfahren kann bei unterschiedlichen Systemverfügbarkeiten eingesetzt werden.
Das langsamere System bremst das schnellere System aus. Systembesonderheiten können ausgereizt werden, z. B. Parallelisierung des Imports.
Transformationen sind eher unerwünscht und erfordern einen Eingriff im Migrationstool. Transformationsschritte können durch zwischengeschaltete Verfahren eingebaut werden.
Das Verfahren benötigt mindestens den Platzbedarf des exportierten Gesamtvolumens, erfahrungsgemäß jedoch das Drei- oder Vierfache.

Migrationsverfahren ‒ Vergleich

Aus dem Vergleich beider Verfahren geht hervor, dass bei einer Inhouse-Migration mit bekannter API und unkritischer Netz-und Performance-Infrastruktur das „On-the-Fly“-Verfahren sehr attraktiv ist. Das klassische Verfahren dagegen stellt relativ geringe Anforderungen bezüglich einer gleichzeitigen Systemverfügbarkeit. Es benötigt lediglich Zwischenspeicher und kann sonst in nahezu allen Umgebungen und Anwendungsszenarien eingesetzt werden.

Anwendungsszenarien konkretisieren Konzepte zum Datenaustausch

Grundsätzlich schließen sich zwei grundsätzliche Anwendungsszenarien an die geschilderten Vor- und Nachteile der beschriebenen Migrationsverfahren an: zum einen eine hausinterne Migration, wenn alle relevanten Systeme in einem Unternehmen oder gegebenenfalls in einem Mandanten eines Rechenzentrums verfügbar sind. Zum anderen eine Systemmigration zwischen selbständigen Organisationen bzw. Unternehmen. Letztere laufen i. d. R. nach dem klassischen Verfahren ab, da eine Öffnung der IT für eine API-gesteuerte Migration zumeist nicht möglich oder nicht gewünscht ist. Selbst wenn beide Unternehmen Leistungsbezieher desselben Rechenzentrums oder innerhalb eines Konzerns sind wird erfahrungsgemäß das klassische Verfahren bevorzugt.

Das grundsätzliche Procedere ist bei beiden Verfahren vergleichbar. Da bei einer hausinternen Migration die formalen Anforderungen an Liefer- und Empfangsnachweise jedoch geringer sind können sie daher gegebenenfalls auch entfallen. Um welche Nachweise es sich hier konkret handelt, wird im Folgenden beschrieben.

Für das eigentliche Migrationsverfahren wird in einem Konzept festgelegt (siehe Bild 4), welche Daten in welchen Mengen (Paketen) und Formaten geliefert werden. Für eine Systemmigration zwischen selbständigen Organisationen bzw. Unternehmen werden darin auch Umfang und Stichprobenmenge der Testmenge sowie auch Termine für die Test- und Produktionslieferungen vereinbart. Technisch sollte ein einheitliches Transportverfahren vereinbart werden. Neben der Versendung von verschlüsselten Festplatten mit Kurierdiensten können Austauschserver, welche mit leistungsstarken Leitungen verbunden sind, genutzt werden.

Spezifiziert werden die Menge an Dateien in Verzeichnissen oder in komprimierten Datenpaketen, Kennwörter sowie der Aufbau des Lieferscheins für die jeweilige Lieferung und idealerweise die „Packzettel“ bzw. Inventarlisten, die den Lieferungen beigelegt werden. Die abgebende Organisation benennt im Lieferschein Gegenstand und Liefermenge (z. B. 12.500 Dateien gescannte Buchungsbelege). In der Inventarliste sind dann alle Dateinamen mit Prüfziffer aufgelistet, damit der Empfänger über eine „Soll-Liste“ an zu importierenden Dateien verfügt.

Die Inventarliste entspricht im Wesentlichen dem Exportprotokoll und kann im Prinzip beim Lieferanten einfach erstellt werden. Der Empfänger quittiert den Empfang mit der Bestätigung des Lieferscheins (z. B. durch Eintragen des Abholdatums vom Datenaustauschserver) und schickt diesen als Bestätigung an den Versender zurück. Beim Auspacken der Dateien erfolgt einer Überprüfung der Prüfziffern und bei Abweichungen zu den gelieferten Werte in der Inventarliste kann die fehlerhafte Datei genau benannt und eine neue Lieferung angefordert werden.

Bild 4: Sicheres Datenaustauschszenario mit Prüfziffern und Lieferscheinen
Bild 4: Sicheres Datenaustauschszenario mit Prüfziffern und Lieferscheinen

Das Verfahren ist hinreichend sicher und nachvollziehbar und reduziert den Prüf- und Dokumentationsaufwand erheblich, da unabhängig von der weiteren Verarbeitungsstrecke nach dem Verarbeitungsserver die Prüfziffer im Zielsystem belegt, dass der weitere Transport ohne Veränderung einherging, vorausgesetzt es finden keine Transformationen der Nutzdateien statt. Dieses Verfahren kann auch beim Datentransport via Festplatte angewendet werden. Anstelle der Paketverschlüsselung kann die Festplatte verschlüsselt sein, Lieferschein und Inventarliste werden wie oben beschrieben verwendet.

Bei einer organisationsinternen Migration spricht nichts dagegen, das Exportprotokoll mit Prüfziffern als „Soll-Liste“ für einen Abgleich mit dem Importverfahren zu verwenden, die formellen Schritte wie Lieferscheinquittierung oder Listenaufbereitung können natürlich entfallen. Weitere Details hängen erfahrungsgemäß von den konkreten Rahmenbedingungen der Migration ab und können allgemein formuliert an dieser Stelle nicht weiter ausgeführt werden.

Migrationswerkzeuge unterstützen Projektmanagement

Für den Abschluss des Beitrages soll noch ein kurzer Blick auf die Werkzeuge für das Projektmanagement-Team geworfen werden. Dabei kann man zwischen den eigentlichen Migrationstools und den Projektmanagement-Werkzeugen unterscheiden.

Migrationstools
Bei den unmittelbaren Migrationswerkzeugen handelt es sich in erster Linie um Export- und Importverfahren oder entsprechende Tools von Drittanbietern, die den Dokumentenbestand exportieren, mit Prüfziffern versehen und gegebenenfalls paketieren. Beim Import verhält sich die Betrachtung ebenso: Importverfahren oder Importtools übernehmen den Massenimport der angelieferten Daten und Dokumente. Der Abgleich der Inventar- oder Exportprotokolle mit den verarbeiteten Dokumenten ist systemspezifisch und erfordert eine projektspezifische Lösung. Ebenso sind Tools für die Erstellung von Lieferscheinen und Inventarlisten zu erstellen. Hier kann ein prozesssteuerndes Werkzeug eine wertvolle Hilfe sein.

Je nach Menge und Varianten bei der Verarbeitung empfiehlt sich eine datenbankgestützte Ablage der Lieferprotokolle und Inventarlisten, damit die Prüfungen performant bearbeitet und zu Dokumentationszwecken zusammengefasst und geprüft werden können. Wird nur ein System migriert, handelt es sich dabei zumeist um eine Datenbank des Migrationswerkzeuges. Werden mehrere Systeme mit mehreren unterschiedlichen Verfahren migriert, wird eine „Migrations-Datenbank“, die alle Protokollinformationen je Verfahren aufnimmt, die beste Lösung sein.

Workflow-Funktionen für die prozessgesteuerte Bearbeitung der Anlieferungen und Bestätigung von Eingängen sind sehr hilfreich, wenn auch nicht zwingend notwendig. Groupware-Lösungen mit Setzen von Statusinformationen aus Auswahllisten sind auch geeignet. Ebenso ist die Datenaustausch-Landschaft (vgl. Bild 4) aufzusetzen und zu implementieren. Automatische Verfahren und Namenskonventionen sind zu prüfen und im Vorfeld eingehend zu testen. Dabei sollte das entwickelte Verfahren nicht vom Standardfall funktionierender Lieferungen ausgehen, sondern auch Teillieferungen, Wiederholungslieferungen oder Stornierungen von Lieferungen berücksichtigen.

Projektmanagement-Werkzeuge
Für das Projektmanagement werden Projektplanungswerkzeuge (z. B. MS Project) und die übliche Office-Palette für die Erstellung von Dokumenten und Tabellen etc. benötigt. Gerade bei verteilten Projektgruppen und der zeitweisen Mitarbeit von Spezialisten sind Gruppentools zur Koordination und Mitteilung einheitlicher Informationsstände sehr hilfreich. Dazu gehören natürlich Telefonkonferenz-Möglichkeiten, aber vor allem eine für alle zugängliche Dokumentenablage, in der Dokumentationen, Status-Dokumente etc. abgelegt und eingesehen werden können.

Insbesondere für die Bearbeitung von Testfällen und die Beantwortung von damit verbundenen Fragen ist eine Testfallumgebung sehr hilfreich. Diese kann nicht nur in speziell dafür vorgesehenen Programmen, sondern auch in Gruppenplattformen wie Lotus Notes oder SharePoint eingerichtet und zur Verfügung gestellt werden. Das Projektmanagement sieht den Fortschritt der Testfallbearbeitung, erfasste Fragen und Fehler können von den entsprechenden Spezialisten eingesehen und beantwortet werden. Der Gesamtstatus kann also jederzeit ohne zu hohen manuellen Pflegeaufwand kontrolliert und letztendlich einfach dokumentiert werden – nicht zuletzt auch als Verwendungsmöglichkeit in einer Verfahrensbeschreibung.

Eine solche Plattform kann darüber hinaus grundsätzlich auch als Datenaustauschzentrale verwendet werden. Die Eignung hängt dabei aber vom festgelegten Transportverfahren ab.

Fazit

Eine Migration von Daten und Dokumenten von operativen Anwendungen oder von ECM-Lösungen ist ein vielschichtiges Thema, welches rechtliche, kaufmännische und technische Aspekte berücksichtigen muss. Vor allem ist aber Sorgfalt bei allen Teilaufgaben und Untersuchungen angebracht. Dies betrifft nicht zuletzt auch das Projektmanagement und die verwendeten Verfahren, die zur Migration eingesetzt oder entwickelt werden.

Der Beitrag hat die verschiedenen Themen angesprochen und system- und branchenunabhängig aufgezeigt. Unsere Erfahrungen zeigen, dass es sich lohnt, gewissenhaft und systematisch vorzugehen und entsprechende Experten für jede Projektphase einzubinden.

www.project-consult.com
Dr. Joachim Hartmann ist freier Consultant unter anderem bei der PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH. Mit IT-Migrationsprojekten befasst er sich erfolgreich seit ca. 25 Jahren. Weitere
Schwerpunkte seiner Beratertätigkeit sind ECM-Themen, insbesondere elektronische Aktenlösungen, ECM-Change Management und Trouble Shooting in IT-Projekten. Branchenschwerpunkte sind Banken, Versicherungen und Industrie.

www.dr-weiss.com
Dr. Dietmar Weiß, DWB Dr. Dietmar Weiß Beratung, unterstützt Unternehmen bei der Konzeption, Einführung und Migration von Eingangsrechnungssystemen sowie Erstellung von Fachkonzepten, Einführung, Migration und Auswahl von Dokumenten Management- und Archivsystemen. Er hat in über 14 Ländern Lösungen bereits eingeführt oder migriert.