Wie viel kostet die Migration von Daten und Dokumenten?

Die Überführung von Print-orientierten Dokumenten in ein Content-Management-System haben wir im letzten Blogbeitrag beleuchtet. Dabei war auch die Sprache davon, wie intensiv und fordernd diese Migration sein kann – wir nannten den Artikel darum auch „Feindliche Übernahme“. So verschieden das Ausgangsmaterial ist und so verschieden die Anforderungen an Zielformat und Zielqualität sind, so unterschiedlich ist auch der Weg, der bei einer Content-Migration eingeschlagen werden kann. Ganz praktisch stellen sich aber viele Unternehmen die Frage: Wie plane und kalkuliere ich denn so ein Migrationsprojekt?

Eine Universallösung gibt es hierfür nicht, aber ich möchte Ihnen ein paar grundsätzliche Vorgehensweisen zeigen und Tipps geben. Im Grunde müssen Sie aus zwei mögliche Vorgehensweisen wählen: die Bottom-Up- und die Top-Down-Methode. Wenn Sie sich nicht zwischen den beiden Varianten entscheiden können, habe ich noch eine weitere Lösung für Sie parat, aber dazu später mehr.

Bottom-Up: Ich bewerte Content, Prozesse und Systeme detailliert

Bei der Bottom-Up-Methode versucht man möglichst detailliert alle Informationen zu sammeln und diese zu spezifizieren. Im vorherigen Beitrag schon ausführlich aufgezeigt, an dieser Stelle noch einmal zusammengefasst:

  • Welcher Content muss migriert werden?
  • Wie viele Dokumententypen gibt es?
  • Und wie viele Dokumente von welchem Dokumententyp?
  • Wie groß ist der Umfang jeweils?
  • Wie hoch ist der Grad der gewünschten Strukturierung, wie hoch der Anteil wiederverwendbaren Contents?
  • Was ist mit Grafiken?

Durch diese Informationen bekommt man eine Vorstellung der Größenordnung des Contents und des anstehenden Migrations-Projektes.

Zusammen mit den nötigen Prozessen und Arbeitsschritten sowie Rahmenbedingungen nähert man sich einer Kalkulation an. Rahmenbedingungen können sein:

  • Was kann mein Content-Management-System leisten?
  • Wie viel muss ich händisch machen, was kann ich automatisieren?
  • Wie viele User können das System zeitgleich nutzen?

Und nicht zuletzt: Wie wird der Content im System weiter verwendet?

  • Generiere ich hauptsächlich Print-Dokumente?
  • Will ich Technische Daten und Produktbeschreibungen auf der Unternehmens-Website verwenden oder in einem Kundenportal bereit stellen?
  • Will ich meinen Content als mobile Dokumentations-App den Vertriebs- und Service-Mitarbeitern zur Verfügung stellen?

Das alles beeinflusst logischerweise den Strukturierungsgrad der Inhalte.

Nun begegnen mir in meinem Vertriebsalltag viele Redakteure oder Doku-Leiter, die sagen „So weit denken wir noch gar nicht. Hauptsache ich habe meine Daten im Redaktionssystem.“ Schon klar, man muss nicht gleich ein ganzheitliches Konzept aufziehen. Aber wenn ich schon weiß (und das ist in den meisten Fällen der Fall), dass ich den Content möglichst in verschiedenen Medien wiederverwenden will, dann sollte ich das von Anfang an berücksichtigen. Den Content, den ich heute in ein CMS migriere, in 2 oder 3 Jahren noch mal anzupacken, zu modellieren und zu strukturieren ist eine doppelte und unnötige Arbeit, die teuer werden kann und nur zu Frust führt – bei Redakteuren und Unternehmensleitung.

Sie ahnen es: Die Bottom-Up-Methode ist ein sehr aufwändiges Verfahren. Neben den ganzen gesammelten harten Fakten und reinen Zahlen spielen Expertenwissen und Erfahrungen in Migrationsprojekten eine große Rolle. Beispiel für dieses Vorgehen ist das Anfertigen eines Lastenheftes und des dazugehörigen Pflichtenheftes. Am Ende habe ich ein Vorgehen und eine Projektbeschreibung mit Leistungen und Aufwänden, die in eine Budgetgröße einfließen. Einfließen (und nicht automatisch ergeben) deshalb, weil ja unterschiedlich kalkuliert werden muss. Was setze ich intern um, was extern? Mit welchem Kostensatz kalkuliere ich intern, mit welchem extern? Oftmals ist es auch sinnvoll, externe Dienstleister hinzuzuziehen, die meine internen Mitarbeiter coachen, damit diese die Tätigkeiten selbst umsetzen können. Dieser Fall kommt in unseren Projekten bei doctima häufig vor.

Elementar für den Projektplan ist dann auch die zeitliche Planung, sprich wie lange ist die Gesamtlaufzeit des Projektes von Kick-Off bis Live-Gang. Das ergibt sich daraus, wer was liefern muss, was die Reaktionszeiten der jeweiligen Verantwortlichen sind, die Berücksichtigung von Arbeits-, Urlaubs-, Krankheitszeiten, etc. Da sind wir schon in der Projektplanung. Das soll hier erstmal keine Rolle spielen, ich betrachte eher die Leistungskalkulation.

Top-Down: Ich geben einen Leistungsrahmen vor und fülle diesen

Top-Down geht den umgekehrten Weg. Man definiert einen Leistungsrahmen und plant dann innerhalb dieses Rahmens. Hier stimmt man also ab, welcher Anteil des Contents überhaupt migriert wird, wie hoch die Zielqualität sein soll bzw. wie diese reduziert werden kann, damit sie in den Rahmen passt.

Bei diesem Ansatz werden ähnlich viele Daten erfasst wie bei der Bottom-Up-Methode, nur dass der Schwerpunkt hier darauf liegt, meinen Rahmen einzuhalten. Und wenn ich bei der Bewertung an den Punkt komme, dass ich innerhalb des gesetzten Leistungsrahmens nicht alle Dokumente und nur zu einer bestimmten Zielqualität und einer bestimmten Granularität an Strukturiererung migrieren kann, dann werden Abstriche gemacht und nur den relevanten Anteil bewertet. Das kann – muss aber nicht – weniger aufwändig in der Betrachtung der Kalkulation sein.

Oben habe ich noch von zwei Möglichkeiten gesprochen, aber eigentlich gibt es in der Praxis auch Ansatz Nr. 3, eine agile Migration, sozusagen eine Mixtur der beiden genannten Ansätze.

Agile Migration hilft bei der schrittweisen Bewertung und Umsetzung

In Software-Projekten sind heutzutage agile Vorgehen sehr gern gesehen. Markus Nickl hat schon vor ein paar Jahren in unserem Blog angerissen, wie Agile Entwicklung und Scrum-Konzepte funktionieren. Grundsätzlich geht es darum, kein ganzheitliches Konzept wie bei einem Lasten- und Pflichtenheft zu erstellen, das dann 1:1 so umgesetzt wird. Bei der agilen Methode gebe ich einen gewissen groben Rahmen für die Projektziele vor und bewege mich innerhalb des Projektes flexibel und iterativ, um diese Ziele zu erreichen.

Der Hintergrund dieses Vorgehens ist ganz einfach: Gebe ich zu Beginn schon das kleinste Projektziel vor und definiere alle Projektpunkte durch, bin ich im eigentlichen Projekt zu festgefahren. In jedem (wirklich in jedem!) Projekt kommen früher oder später Wünsche durch den Kunden, sei es durch neue Ideen oder durch Usability-Erkenntnisse im Testing etc. Oft ist für diese guten Ideen laut Projektkalkulation kein Platz.

Diese sogenannten Change Requests (Änderungsanforderungen) können aber bei der Bottom-Up-Methode nicht berücksichtigt werden und auch bei der Top-Down-Methode ist es nicht viel anders. In der Praxis versucht man also, diese Änderungsanforderungen mit ins Projekt reinzuschummeln. Logischerweise ist das nicht ideal, vor allem wenn die Anzahl der Change Requests täglich steigt.

Wie läuft so eine Agile Migration ganz praktisch ab? Ein Beispiel: Wir haben einen Kunden mit dem Wunsch, seine bisherige Word-Dokumentation in ein Content-Management-System zu migrieren. Was ich sehr gut beziffern kann, ist das Aufsetzen und Implementieren des CMS – eine Standardleistung von uns.

Dann bewerte ich die Word-Dokumente und picke mir ein Dokument raus, dessen Typ und Inhalt repräsentativ für den Gesamt-Content ist. Das wird mein Muster-Dokument. Hier kann ich sehr schnell abschätzen, wie ich den Inhalt strukturieren muss, was ich dafür im CMS vorbereiten muss und wie lange ein Input dauert. Das heißt, die Kalkulation dafür steht quick and dirty. Dann folgt die Umsetzung: Bearbeitung des Contents, Migration ins Redaktionssystem, Bewertung des Ergebnisses. Nach Change Requests und Freigabe weiß ich nun, wie die angestrebte Endqualität in etwa aussieht und wie aufwändig der Weg dahin ist. Einen Erfahrungswert an Change Requests gewinne ich so auch. Diese Erkenntnisse kann ich jetzt viel besser auf den restlichen zu migrierenden Content übertragen.

Und was bedeutet das jetzt für Ihr Datenmigrationsprojekt?

Wie uns der Projektalltag zeigt, sind Migrationsprojekte oftmals sehr schwer vorab zu kalkulieren. Der Content, die Prozesse und die Wünsche an das Ergebnis sind doch immer wieder von Unternehmen zu Unternehmen unterschiedlich.

Was aber gleich bleibt ist das Know-How über

  • die Systeme,
  • die sinnvolle Strukturierung von Content
  • und vor allem das Einfließen von Erfahrungen aus ähnlichen Datenmigrationsprojekten.

Scheuen Sie sich also nicht davor, einen Tipp bei einem Experten einzuholen, wenn Sie vor solch einer Herkulesaufgabe stehen. Eine Hilfestellung von außen kann nur von Vorteil sein.

Wie sind Ihre Erfahrungen bei der Einführung eines Content-Mangement-Systems und der Datenmigration? Hat sich die ein oder andere Methode besonders bewährt? Wir freuen uns auf den Erfahrungsaustausch mit Ihnen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.