Ein neues Translation-Management-System (TMS) einzuführen klingt für manche nach einem spannenden Neuanfang, für andere nach einem Albtraum mit offenem Ende. Damit letzteres nicht eintritt, gilt es, eine gute und bedachte Vorbereitung zu treffen. Dann kann der Umzug ohne böse Überraschungen oder unliebsame Verzögerungen gelingen, und gleichzeitig können Sie dabei einige alte Zöpfe loswerden.

Warum das TMS wechseln?

Die Gründe für einen Systemwechsel sind vielfältig, und nicht immer selbst gewählt.

• Das Altsystem wird eingestellt: Der Anbieter stellt den Support ein oder ändert das Lizenzmodell so grundlegend, dass Bleiben keine Option mehr ist.
• Das System ist nicht mehr zeitgemäß: mangelnde Cloud-Fähigkeit, eine UX aus einer vergangenen Ära, keine offenen oder fehlende Schnittstellen zu wichtigen neuen Systemen in Ihrer Infrastruktur.
• Neue Anforderungen entstehen: mehr Sprachen, veränderte Datenmengen, neue Dateiformate, komplexere Workflows, modernere Technologie-Anforderungen, die das Altsystem nicht mehr stemmen kann.
• Eine Konzernentscheidung kommt von oben, ohne dass die Sprachabteilung involviert wurde. Auch das ist Realität, und auch dann gilt: Die eigene Vorbereitung entscheidet darüber, wie der Wechsel gelingt.

Planung: Was vor dem ersten Klick geklärt sein solte

Der häufigste Fehler bei Systemwechseln passiert nicht beim Aufbau, er passiert davor. Wer ohne saubere Vorbereitung loslegt, zahlt für die Versäumnisse später teuer nach.

Bevor ein System ausgewählt wird, müssen alle Anforderungen auf dem Tisch liegen. Was sind Must-haves, was Nice-to-haves? Welche neuen Features des Zielsystems sollen aktiv genutzt werden, und ist die eigene Infrastruktur überhaupt bereit dafür? In dieser Phase sollen alle Stakeholder gehört werden, von der IT bis zu den direkt Nutzenden sowie auch die Vertretenden der angeschlossenen Systeme. Nach diesen Anforderungen wird das passende System identifiziert und ausgewählt. Wie Ihnen blc helfen kann, die passende Toollösung zu finden, lesen Sie hier.

Es geht dann weiter mit dem Platz in der Systemarchitektur. Wo sitzt das neue TMS in der bestehenden IT-Landschaft? Welche Schnittstellen braucht es zum CMS, zu Abrechnungssystemen, zu KI-Komponenten, zum Projektmanagementsystem? Wer baut und betreut diese Schnittstellen? Gibt es eine IT-Sicherheitsfreigabe? Diese Fragen sind technisch, müssen aber von denjenigen gefragt und vorangetrieben werden, die Lokalisierungsprozesse verantworten.

Ist die Infrastruktur geklärt, bedarf es einer stringenten Datenstrategie: Translation Memories sollten nicht einfach ins neue System übertragen werden. Veraltete oder zweifelhafte Daten machen ein neues System nicht besser, sie verschlechtern es sogar. Und wenn Sie die Datenbestände im Zuge des Systemwechsels kritisch betrachten, empfehlen wir immer eine Bereinigung im Zug der Migration, damit ein sauberer Neustart gelingt.
Die gleiche Sorgfalt brauchen Ihre Terminologiedatenbanken, diese von Anfang an mitdenken und mitnehmen.

Die Anforderungen an Sprachworkflows sollten aus der Systemauswahl bereits bekannt sein, nun aber geht es daran, sie zu dokumentieren und zu analysieren, um sie ins neue System übertragbar zu machen. Alle beteiligten Personen an Workflows brauchen eine klare Funktion im System, hier muss ein Rollenkonzept erstellt und abgestimmt sein.

Aufbau: Sorgfalt zahlt sich aus

Wenn die Planung sitzt, geht es ans Einrichten des neuen Systems, und hier zählt Sorgfalt mehr als Tempo.

Damit sich das neue Tool nahtlos in Ihre Textprozesse einfügt, braucht es die entsprechenden Schnittstellen, die aufgebaut und dann frühzeitig mit klaren Abnahmekriterien getestet werden sollten. Die benötigten Workflows sind im neuen System aufzusetzen und werden am besten direkt dokumentiert. Und an dieser Stelle wird das Berechtigungskonzept umgesetzt: Rollen erstellt, Zugriffsrechte erteilt, Sichtbarkeit auf TMs und Termdatenbanken festgelegt.

Die TM-Migration selbst ist ein kritischer Schritt: bereinigt migrieren, und danach zwingend testen. Wenn 100%-Matches nach der Migration teilweise keine mehr sind, wird es teuer, in Zeit und in Geld. Terminologiedatenbanken parallel migrieren und ebenfalls validieren. Beim Umgang und der Migration Ihrer Sprachdaten steht blc an Ihrer Seite.

Und schließlich: die Menschen kommen ins Spiel. Schulungen für alle Nutzergruppen, aber nicht alle brauchen dasselbe. Wichtiger als reine Theorie ist, Nutzerinnen und Nutzer frühzeitig auf das System zu lassen. Learning by doing, Feedback aktiv einholen und in die Konfiguration einfließen lassen.

Testen: Bitte nicht überspringen

Testen ist der Teil, der unter Zeitdruck als erstes gekürzt oder vernachlässigt wird. Das ist ein Fehler.

Bevor überhaupt pilotiert wird, muss das System unter realistischer Last laufen. Lasttests sind potenzielle Showstopper, sie können alles andere blockieren, also diese frühzeitig zusammen mit der IT einplanen. Böse Überraschungen können so an dieser frühen Stelle besser eingefangen werden als später im Livebetrieb.

Sobald eine grundlegende Konfiguration steht, soll der vollständige Prozess End-to-End durchgespielt werden, von der Ausgangsredaktion bis zur Verwertung der zielsprachlichen Texte. Es müssen vielleicht nicht alle Sprachen getestet, aber alle Beteiligten einbezogen werden. Erst wenn das rund läuft, ist das System bereit.

Sobald Konfiguration und Migration auf einem guten Niveau sind, ist es Zeit, Ernst zu machen. Hier bietet sich ein Pilotprojekt an. Dafür wählen Sie eine Auftragsart, die so komplex wie nötig und so einfach wie möglich ist. Mit echten Nutzern, echten Inhalten, echten Workflows, und realistischen KPIs. Und anschließend eine ehrliche Auswertung und Konfigurationsanpassung, damit das System bereit für den großen Roll-Out ist.

Das Testen endet übrigens auch im Livebetrieb nicht, denn die meisten Systeme updaten automatisch oder geben Releases heraus. Diese müssen stets kritisch gesichtet und vertestet werden, bevor sich unliebsame Nebeneffekte neuer Features im nächsten eiligen Projekt zeigen.