ECM-BLOG

Dienstag, 04 Mai 2010

Migration von DMS-Umgebungen

geschrieben von  Thorsten Brand
E-Mail
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-Produkte, 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:
 

Bereich

 

Migrationsobjekte

 

Typische Umstellungen

 

Dokumente

 

Alle Formate, alle Objekte

 

· Keine Übernahme der Dokumente, deren Aufbewahrungsfrist abgelaufen ist

 

· Löschen der Dokumente nach BDSG

 

· Konvertierung von Notiz-Informationen

 

Dokumente

 

Gescannten Dokumente

 

· Konvertierung Single-Page-TIFF in Multi-Page-TIFF und umgekehrt

 

· Konvertierung Bildformate in PDF oder PDF/A

 

Dokumente

 

Office-Dateien und E-Mails

 

· Konvertierung alter Office-Formate

 

· Konvertierung E-Mail-Formate

 

Dokumente

 

COLD-Dateien, Druckdaten

 

· Umstellung Layoutverwaltung für Hintergrund-Layouts

 

· Konvertierung COLD-Dokumente in PDF oder PDF/A

 

Dokumente

 

Sonstige Formate

 

· Konvertierung „exotischer“ Formate

 

Indexdaten

 

Indexfelder

 

· Aufteilung und Zusammenführung von Indexfeldern

 

· Überarbeitung Multi-Value-Listen

 

· Konsolidierung Auswahllisten, bspw. für Dokumentarten oder Schlagworte

 

Indexdaten

 

Aktenstrukturen

 

· Neuaufbau Aktenplan

 

· Mapping und Umstellung alter Aktenstrukturen

 

Indexdaten

 

Volltext

 

· Neuaufbau Volltext, meist keine Migration

 

Administration

 

Berechtigungen

 

· Neuaufbau, meist keine Migration

 

· Migration besonderer Dokumenten­berechtigungen (Bsp. bei Berechtigungen auf Einzeldokumenten)

 

Administration

 

Fristenverwaltung

 

· Konsolidierung der Aufbewahrungsregeln

 

· Neuaufbau, meist keine Migration

 
 
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:
 

Phase

 

Besonderheiten im Rahmen einer DMS-Migration

 

Ist-Bestandsaufnahme

 

- Ermittlung des Ist-Zustandes des Altsystems (Formate, Volumen, elektronische Prozesse, Anwendungsintegrationen, funktionale Besonderheiten), typischerweise mit Checklisten

 

- Systemprüfung auf Konsistenz

 

- Prüfung Ist-Zustand Neusystem, bezogen auf die erforderlichen Funktionalitäten

 

Konzeption

 

- Feinkonzept mit Zielhersteller und ggf. Migrationsdienstleister zu den folgenden Themen:

 

o Kennzahlen Ist-Zustand (Anzahl Dokumente, Anzahl Seiten, Speichervolumen insgesamt etc.)

 

o Festlegung der grundsätzlichen Migrationsvorgehensweise (Big Bang, begleitend)

 

o Abgrenzung und technische Identifizierung der relevanten Dokumente, der nicht mehr aufbewahrungspflichtigen Beständen und der zu löschenden Dokumenten (nach BDSG)

 

o Besondere Vorgehensweise für spezielle Dokumentarten (Bsp. Vorstandsprotokolle, Personaldokumente)

 

o Festlegungen von Details für die Daten- und Dokumenten-Migration (siehe auch Tabelle 1)

 

o Müssen Notizen migriert werden oder nicht?

 

o Überarbeitung von Berechtigungs- oder Aktenstrukturen

 

o Export-Strecke festlegen: Erfolgt der Export der Dokumente über Export-Möglichkeiten des DMS-Systems oder direkt über die Medien / das Speichersystemen?

 

o Vorgehensweise bei der Migration der Indexdaten: Werden diese pro Dokument oder wird der gesamte Datenbankbestand migriert?

 

o Festlegung Frozen Zone (keine Änderung mehr an migrierten Dokumenten ) oder Festlegung einer Vorgehensweise bei Dokumenten, die während der Migration im Altsystem verändert wurden

 

o Vorgehensweise bei inkonsistenten Dokumenten (Objekt ohne Indexsatz, Indexsatz ohne Objekt)

 

o Umfang der Protokollierung für Umfang Altsystem, Export, Aufbereitung, Import sowie Gesamtmigrationsprotokoll

 

o Zusätzliche Hard- und Software, eingesetzte Migrationswerkzeuge

 

o Migrations-Zeiten: Kann die Migration parallel zum Tagesbetrieb erfolgen oder müssen Nacht-Jobs eingeplant werden?

 

o Projekt- und Ressourcenplanung

 

o Aufgaben des Anbieters, des Kunden und Einsatz von Dienstleistern

 

o Fehlerbehandlung und Eskalationswege

 

Durchführung

 

- Installation und Einrichtung Zielsystem

 

- Aufbau der Migrationsumgebung

 

- Einrichtung der Export-, Konvertier- und Importprozesse

 

- Testmigration und Freigabe

 

- Start Migration inkl. Überwachung und Fehlermanagement

 

Abnahme / Freigabe

 

- Export Protokolle

 

- Protokollprüfung

 

- Erstellung Migrations-Dokumentation

 

- Abstimmung mit Revision oder Wirtschaftsprüfern

 
 
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 bsp. 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:
 

Abschnitt Dokumentenmigration

 

Umfang der Migration

 

Es ist definiert, welcher Umfang an Dokumenten migriert werden soll. Dies ist typischerweise zeitraum- oder archivbereich-, stammdaten- oder dokumentart-bezogen.

 

Les- und Verarbeitbarkeit der Dokumente

 

Die Dokumente im Zielsystem sollten gemäß den relevanten gesetzlichen und fachlichen Anforderungen lesbar und ggf. verarbeitbar (z.B. Drucken, neue Prozess starten etc.) sein.

 

Formate der Dokumente

 

Für das Quellsystem und das Zielsystem sind die vorhandenen Formate für Dokumente beschrieben.

 

Konvertierung der Dokumente

 

Werden im Rahmen der Migration Dokumentenformate konvertiert, ist zu beschreiben, in welcher Art und Weise dies erfolgt und für wie viele Dokumente dies relevant ist.

 

Referenzierung zum Quellsystem

 

Für die Nachvollziehbarkeit der Migration ist eine Referenzierung zum Quellsystem sinnvoll, um eindeutig das Ursprungsobjekt identifizieren zu können.

 

Vollständigkeit der Migration

 

Für die im Quellsystem migrations-relevanten Dokumente muss der Nachweis der Vollständigkeit im Zielsystem vorhanden sein. Dies kann durch Anzahl Dokumente (auch pro logischem Bereich), Anzahl Seiten und/oder Doc-ID-Kreise erfolgen.

 

Nachweis der nicht übernommenen Dokumente

 

Werden Dokumente aus unterschiedlichen Gründen nicht übernommen (bspw. abgelaufene Aufbewahrungsfristen, nicht mehr relevante Dokumente), sollte ein entsprechender Nachweis über diese Dokumente vorhanden sein. Dieser sollte zumindest die Identifikation im Quellsystem und eine fachliche Identifikation enthalten (Bsp. Dokumentart und Stammdaten)

 

Löschungen aus Datenschutzgründen

 

Unterliegen Dokumente datenschutzrechtlichen Regelungen, dürfen diese im Rahmen einer Migration nicht übernommen werden. Die Medien des Quellsystems sind zu vernichten.

 

Vorgehen bei schützenswerten Dokumente

 

Darstellung der besonderen Vorgehensweise bei Dokumenten mit höherem Schutzbedarf.

 

Vorgehen bei mehreren Dokumentversionen

 

Sind im Quellsystem mehrere Dokumentversionen enthalten, muss festgelegt werden, ob alle Dokumentversionen übernommen werden sollen oder ob nach definierten Regeln nur eine teilweise Übernahme erfolgt. Auch sollte beschrieben sein, wie sich die versionierten Dokumente im Zielsystem darstellen (z.B. auch als versioniertes Dokument oder als mehrere Einzeldokumente).

 

Abbildung von Notizen und grafischen Annotationen

 

Da es sich bei Notizen und grafischen Annotationen oft um hersteller-bezogene Umsetzungen handelt, sollte festgelegt werden, wie hiermit im Rahmen der Migration umgegangen werden soll.

 

Aufbewahrung der Migrationsprotokolle der Dokumentenmigration

 

Die Protokolle der Dokumentenmigration sollten aufbewahrt und, wenn möglich, im Zielsystem elektronisch archiviert werden.

 

Abschnitt Indexdatenmigration

 

Mapping-Regeln

 

 

 

 

Für die Migration der Datenbestände muss das Mapping vom Quelldatenbanksystem zum Zielsystem dokumentiert sein. Ggf. erforderliche Änderungen, Aufteilungen oder Zusammenfassungen von Indexstrukturen sollten nachvollzogen werden können.

 

Vollständigkeit der Datenmigration

 

Für die Migration der Indexdaten muss der Nachweis der Vollständigkeit der Datensätze im Zielsystem erbracht werden. Ggf. nicht übernommene Indexdaten müssen ebenfalls ausgewiesen werden.

 

Index-Strukturen in anderen Systemen

 

Sind in anderen Systemen Indexstrukturen vorhanden (ggf. auch nicht nur die DOCID), müssen diese Werte im Rahmen der Migration ebenfalls geändert werden.

 

Volltext-Index

 

Ist es erforderlich, dass Volltext-Indexdaten migriert werden müssen, sollte auch hier ein Nachweis über die Übernahme oder ggf. den Neuaufbau der Indexstrukturen erfolgen.

 

Protokollierung des Dokumentenmigration

 

Alle Änderungen an Indexwerten müssen nachvollziehbar mit altem und neuem Wert protokolliert werden.

 

Abschnitt: Migration von Systemeinstellungen

 

Systemeinstellungen

 

 

 

 

Die Migration der Systemeinstellungen (Archiv-Bereiche, Dokumentenarten, Indexstrukturen etc.) sollte dokumentiert sein, damit klar ist, wie sich das Quellsystem im Zielsystem abbildet. Hierbei erfolgt häufig keine technische Migration sondern eine manuelle Neukonfiguration.

 

Berechtigungen

 

Die Umsetzung des Berechtigungskonzeptes vom Quellsystem zum Zielsystem muss aus der Migrationsdokumentation transparent werden. Hiermit wird sichergestellt, dass sich beide Berechtigungskonzepte entsprechen. Dies beinhaltet sowohl die funktionalen Berechtigungen in der Anwendung als auch die Sichtbarkeits- und Bearbeitungsrechte für Dokumente.
 
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ützungsleistung:
  • 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.

Ähnliche Beiträge

Seitenanfang

Anmeldung

Seminare & Events

Ob Workshop, Seminar oder Info-Veranstaltung - Zöller & Partner bietet ein breites Spektrum an Events, von denen auch Ihr Unternehmen profitieren wird.

Mehr Infos

Seminarbewertungen

Lesen Sie, was andere Teilnehmer zu unserem Seminar sagen!

Seminarbewertungen

ECM-Newsletter

Hier können Sie sich zu unserem ECM-Newsletter anmelden.

Anmeldung ECM-Newsletter