Hallo, wunderschönen guten Morgen alle zusammen. Ich freue mich, euch willkommen zu heißen zu unserem neuesten Crownpeak-Webinar über das Thema Multi-Site-Management am Beispiel Weidmüller. Ich bin Fabrizio Penella und bin bei Kühlhaus als Partner-Manager verantwortlich. Ich möchte gern Jörn von Comspace und Moritz von Weidmüller das Thema sofort mal übergeben und ihr dürft gerne anfangen. Ja, schön, dass ihr euch alle entschieden habt, unserem Webinar zu folgen. Wir haben eine kleine Agenda aufgeschrieben und zwar würden wir jetzt am Anfang einmal kurz uns vorstellen, also Weidmüller und Comspace. Und dann gehen wir auch schon direkt in das Thema rein. Wir sprechen einmal über die Automatisierung des Multi-Site-Managements im Projekt Weidmüller, den Workflow dahinter. Dann wird Moritz euch ein paar Dinge zur Übersetzung geben. Ich gehe dann noch einmal auf ein paar Punkte ein, wie wir das Thema SEO gerade auch bei der Vererbung von Inhalten berücksichtigen und geben dann noch einen kleinen Ausblick, wie das Ganze weitergehen kann und freuen uns dann auch zwischendurch und auch am Ende noch in den Diskussionen und Fragerunden mit euch einzusteigen. Wer sind wir? Wir, Comspace, sind ein seit 2002 gegründetes und immer noch inhabergeführtes Unternehmen mit plus minus 100 Mitarbeitenden, Work from Anywhere. Wir arbeiten dezentral, haben Leute quasi in ganz Deutschland sitzen. Wir sind eine Digitalagentur mit hoher technischer Expertise. Früher haben wir gesagt, wir machen bunte Bildchen, malen machen wir nicht. Aber auch das ist im Wandel, aber unsere technische Expertise liegt hier klein im Vordergrund. In Bielefeld betreiben wir auch Rechenzentren und unser Büro sitzt tatsächlich ganz inmitten im Herzen von Bielefeld. Da haben wir einen großen Tower. Genau. Und dann Moritz. Ja, genau. Ich bin heute hier von der Firma Weidmüller. Die Firma Weidmüller ist ein 1850 gegründetes Familienunternehmen, damals noch nicht in der Elektrotechnik tätig, hat seinen Hauptsitz in Detmold mit Vertretung aber und auch Produktionsstadtorten in 80 Ländern. Ja, wie gesagt, aktuell oder schon seit langer Zeit aber tätig in der Elektrotechnik, also Produkte für die Verbindungstechnik. Wir haben knapp 6000 Mitarbeiter weltweit und haben 2023 einen Umsatz von knapp 1,1 Milliarden erwirtschaftet. Genau, das so ein bisschen, dass ihr Weidmüller einordnen könnt, wo wir so herkommen, was wir so machen. Ganz grob. Genau. Dann wollen wir heute quasi über Effizienz des Multiside Management und eine Automatisierung zur Redaktionsunterstützung sprechen. Ganz kurz noch zum Weidmüller-Projekt. Wir haben das zusammen mit unserem Partner der HMH umgesetzt und arbeiten hier klar im Team auch mit der Weidmüller zusammen. Es ist ein Fast-Pirid-Projekt ausgerollt auf 30 Länder plus minus in 15 Sprachen und da halt der Großteil dieses Verhärbungsmechanismus ausgerollt über diesen Verhärbungsprozess, den wir euch heute vorstellen wollen. Und haben diverse Systeme, unter anderem einen Damm nahtlos in das Projekt integriert. Und das Ganze wird dann noch abgerundet mit dem eShop. Dieses Projekt ist tatsächlich noch in der Zukunft gelagert, dass eben eShop und Webseite nähere aneinander rücken. Aber hier setzen wir auch schon auf gleiche Basis im Frontend. Moritz? Genau. Warum Multiside Management? Für uns war es wichtig, einfach die große Komplexität und einfach die Menge an Inhalten und Webseiten, die wir haben, irgendwie handelbar zu machen. Wie Jörn schon erwähnte, wir haben 30 Webseiten. Tatsächlich, glaube ich, die Case-Folie. Mittlerweile haben wir nur noch 13 unterschiedliche Sprachen und Subsprachen, die wir bedienen. Aber das führt trotzdem dazu, dass wir weltweit ungefähr 120 Personen im System haben, die Editing-Rechte haben, also die dort irgendwie Inhalte verwalten und erstellen können. Im Jahr 2024, hatte ich das mal rausgesucht, haben wir über 1200 Seiten in jedes Projekt vererbt. Also nicht insgesamt, sondern wirklich pro Projekt gab es 1200 Seiten, die Updates erhalten haben oder neu hinzugekommen sind. Und wir hatten insgesamt 24 Content-Updates. Genau. Das heißt, man sieht daran ganz gut, wir machen nicht irgendwie alle paar Monate nur einen Content-Update, sondern fahren sehr, sehr regelmäßig Content-Updates und dafür benötigen wir das. Das ist eigentlich nur möglich, weil wir eine sehr effiziente Multiside -Management-Strategie auch haben. Genau. Geh wieder an Jörn. Genau. Die Flexibilität, da wollen wir einmal drauf eingehen. Die Vererbung sollte zentral über den Content-Creator gesteuert werden. Kurz zum Hintergrund. Wir sitzen hier tatsächlich auf den Standard-Vererbungsmechanismus Corporate Content von Crownpeak, Schrägstrich im Fast-Pirate-System. Die Verteilung geht tatsächlich normalerweise nur im Site-E-Tect. Wir kümmern uns darum, dass automatisch Paket-Versionen erzeugen. Und so eine regelmäßige Vererbung überhaupt ermöglichen. Und nach der Vererbung gehen wir noch auf Anforderungen der einzelnen Landesauftritte ein. Das heißt, abhängig von den Landesauftritten wird eben mit der Vererbung umgegangen und auch weitere Workflows angestoßen, wo wir gleich auch noch drauf eingehen werden. Das sind zum Beispiel eben, wie gehe ich mit Übersetzung um, was passiert, wenn Inhalte gelöscht werden, wann und sollen Änderungen publiziert werden. Und da kommen wir nach und nach heute noch drauf zu sprechen. Im Content-Creator haben wir dafür eine Datenquelle zur Verfügung gestellt. Diejenigen, die Fast-Pirate von euch schon nutzen, kennen diese Oberfläche. Aber ich habe sie trotzdem einmal mitgebracht. Hier haben wir eine Datenquelle, die es ermöglicht, Weidmüller oder insbesondere hier auch Moritz, eine Automatisierung zu konfigurieren. Nach Projekten in dieser Datenquelle kann ich definieren, ob und wann ein Projekt automatisiert publiziert werden soll und kann da auch sagen, ich möchte nur die Publizierung anhaben oder ich möchte nur die Content-Vererbung anhaben. Bei der Content-Vererbung kann ich auch festlegen, wann soll die passieren und in welchem Intervall. Die Intervalle sowohl für Publizierung als auch die Vererbung kann ich unterscheiden zwischen täglich einmal in der Woche oder alle zwei Wochen bis hin zu fünf Wochen. Warum habe ich die Möglichkeit, gerade auch bei der Publizierung und bei auch der Vererbung, solche Mechanismen, die die Verteilung aus dem Headquarter ansteht, erzeugen natürlich immer eine gewisse Last auf das System. Und so hat Weidmüller die Möglichkeit, die Last auf dem System nach Priorität und Wünschen zu verteilen, dass eben nicht alle Länder gleichzeitig aktualisiert werden, was natürlich auch im Zweifel mal gehen würde. Aber gerade auch eine Publizierung, eine Vollpublizierung, Vollgenerierung der Webseite bedarf einer gewissen Zeit und erzeugt natürlich auch Last auf dem System. Und da ist es immer gut, wenn wir die Möglichkeit haben, die Publizierung zu versetzen. Natürlich ist das nicht der einzige Weg, eben diese Vererbung durchzuführen. All diese Schritte können selbstverständlich auch von Power-Usern wie Boritz weiterhin manuell und eigenständig zusätzlich im Sighter-Intecting getriggert werden. Auch dann, wenn eben das manuell getriggert wird, folgt der weitere Verlauf der Publizierung oder der Vererbung nach dem hier heute gezeigten Muster, da die Automatisierung klar in der Content-Vererbung hängt. Nach einer Content-Vererbung schaffen wir für die Redaktion auch Transparenz durch automatische E-Mails, die im Anschluss einer Vererbung an eine Nutzergruppe versendet wird. Diese Nutzergruppe kann automatisch angepasst werden oder kann angepasst werden und die Vererbung berücksichtigt eben den neuen Empfängerkreis automatisch bei der nächsten Vererbung. In der E-Mail haben wir dann anschließend direkt die Informationen, welche Inhalte wurden geändert und haben auch die Möglichkeit, direkt in den Content-Creator zum veränderten Inhalt zu springen. Ich habe dadurch einen sofortigen Überblick über alle Änderungen inklusive Löschungen aus dem Headquarter. Ich habe auch ein Beispiel dieser E-Mail mitgebracht. Ich hoffe, es ist groß genug. Hier kann ich klar erkennen, wann ist die E-Mail gekommen. Das ist dann ja auch ungefähr gleichbedeutend mit, wann hat die Vererbung stattgefunden und bekomme einen Überblick über Updated Pages und New Pages und ob gelöscht oder nicht. Aber da wird Moritz im Anschluss auch noch zukommen. Jetzt ist die Frage Automatisierung versus manuelle Arbeit. Die Automatisierung erfolgt für ressourcenintensive Tätigkeiten, gerade so Tätigkeiten wie ein Projekt aufräumen etc. Das sind Tätigkeiten, die bei den Landesredakteuren viel Aufwand erzeugen und klar automatisiert werden können. Weitmalerleute hat mit die Möglichkeit, zeitnah und mit wenig Aufwand aktualisierte Inhalte in alle Auftritte zu bekommen. Insbesondere für kleine Redaktionsteams hilft dieser Prozess eben, das Projekt auf dem aktuellen Stand zu halten. Damit habe ich so den ersten Einstieg in die Automatisierung gegeben und ihr hättet jetzt schon kurz die Möglichkeit, einige Fragen zu dem bis jetzt Gezeigten zu stellen, wenn ihr möchtet. Nutzt dafür gerne Fragen und Antworten oder den Chat. Ich sehe da gerade auch eine. Werden die Folien im Nachgang zur Verfügung gestellt? Die ganze Aufzeichnung wird im Nachgang auch zur Verfügung gestellt. Die kann man dann downloaden bei uns auf der Homepage. Also für alle, die teilgenommen haben oder sich angemeldet hatten zum Beginn. Aber an euch beide, Jörn und Moritz, inhaltlich eine Frage. Warum gibt es überhaupt Projekte für Länder ohne eigene Redaktion? Könnten die nicht auf die internationale Seite geleitet werden? In Englisch zum Beispiel? Ja, kann ich kurz beantworten. Also wir haben tatsächlich ein paar Projekte, wo wir nur sehr wenig Ressourcen mit der lokalen Redaktion haben, die aber eine eigene Sprache haben. Und aus dem Grund haben wir uns dann auch entschieden, auch Länder, die vielleicht nicht so viel Kapazität haben, um eine ganze Webseite eigentlich zu betreiben, dort auch für die Kunden einen sprachlich angepassten Auftritt quasi zur Verfügung zu stellen. Genau, das Level einer Automatisierung und auch was wir jetzt noch gleich bei Übersetzung sehen werden, ermöglicht es uns halt auch mit in Ländern, wo wir nur ein kleines Länderteam vielleicht haben, die auch andere Prioritäten haben, eventuell trotzdem einen kompletten Webauftritt in Landessprache zur Verfügung zu stellen, der immer hochaktuell ist. Danke sehr. Genau, da sind wir auch, glaube ich, schon beim Thema Übersetzung, den ich euch gerne ein bisschen näher bringen möchte. Wie wir bei uns die Übersetzung handhaben, um einfach, wie ja eben schon gesagt, in den verschiedenen Ländern auch einen sprachlich angepassten Auftritt für unsere Kunden zur Verfügung zu stellen. Generell haben wir eigentlich bei Weidmüller zwei unterschiedliche Übersetzungsprozesse, die ich euch beide ein bisschen zeigen möchte. Der erste Prozess ist eigentlich der, den wir hier bei uns in Detmold, also im Headquarter quasi, machen. Und die Redakteure hier vor Ort, die die Fachseiten pflegen, benutzen. Dort wird nämlich von Deutsch nach Englisch übersetzt. Beide Sprachen sind in unserem Hauptprojekt vorhanden. Und in den Landesprojekten existiert immer eigentlich ein englischer Sprachkanal, der nur für den Empfang, sage ich mal, der Vererbung dient. Und dieser wird dann in weitere Sprachen in den Länderprojekten übersetzt. Das heißt, unser Hauptprojekt nochmal hat zwei Sprachen, Deutsch und Englisch. Die Landesprojekte haben dann immer Englisch auf jeden Fall. Und dann die jeweiligen Sprachen, in denen wir die Webseite zur Verfügung stellen. Der Übersetzungsprozess im Hauptprojekt sieht so aus, dass wir da auf dem sogenannten Imcom-Projekt, also das auch die weidmüller.com quasi bespielt, arbeiten. Die Pflege der Inhalte passiert auf Deutsch durch unsere Redakteure. Die Übersetzung erfolgt dann auf Englisch durch unsere Redakteure. Also hier noch nicht durch einen professionellen Übersetzungsdienst oder nur in Ausnahmefällen, ist aber durch KI-Funktionalitäten unterstützt, die unser Übersetzungsdienstleister Kern da zur Verfügung stellt. Nachdem dann übersetzt wurde, laufen die Seiten wieder zurück in das Hauptprojekt und werden in die Länder vererbt. Ich zeige euch mal, wie das so ein bisschen aussieht bei uns. Das ist jetzt einfach ein Blick direkt in das CMS. Hier hat der Redakteur vielleicht gerade diese Seite bearbeitet und hat die auf Deutsch da vielleicht einen neuen Text eingefügt oder einen neuen Absatz. Er hat dann die Möglichkeit, hier oben einen Workflow zu starten. Typischerweise nimmt er normalerweise dort dann diesen Translate this Page oder Translate this Page and Release. Die verhalten sich eigentlich gleich. Der End Release macht genau das, was da eigentlich auch steht. Der gibt dem Redakteur die Möglichkeit, dass die Seite nach dem Übersetzungsprozess direkt freigegeben wird, ohne dass er quasi nochmal ins CMS rein muss, um die Freigabe der Seite zu starten. Bietet sich vor allem dann an, wenn eigentlich jetzt nicht groß was am Layout sich geändert hat, sondern nur eine textliche Anpassung vorgenommen wurde, spart einem einfach da nochmal in das System reinzugehen. Auch sehr praktisch für uns, dass der Redakteur direkt sieht, wann wurde die Seite das letzte Mal übersetzt oder befindet sich sie sich vielleicht auch gerade schon in der Übersetzung durch vielleicht einen Kollegen oder so. Wenn er sich dann entscheidet, die Seite übersetzen zu wollen, also auf einen dieser Workflows klickt, kann er noch hier kurz auswählen, ob er extern oder intern übersetzen möchte. Intern heißt einfach, er trägt die Übersetzung selber ein. Extern nutzt man nur in Ausnahmefällen. Dann würde auch in diesem Falle quasi unser Übersetzungsdienstleister dort tätig werden. Genau. Nachdem er sie dann abgeschickt hat, gehen die ganzen Geschichten oder gehen die Seiten dann die Inhalte in unser Translation Memory System. Das ist von dem Übersetzungsdienstleister Kern, also nicht für Spirit. Das sieht dann hier so aus. Wenn eine Seite ankommt, habe ich das mal ein bisschen hier vergrößert. Einfach hier klaren Datum. Titel der Seite. Die Seite wird schon einmal analysiert. Also alles, was wir schon kennen an Übersetzungen, wird schon vorausgeführt. Die Seite hier ist schon jetzt als Beispiel schon zu 78 Prozent übersetzt. Es fehlen also noch ein paar Worte. 802 Worte hat die Seite insgesamt. 174 müssen noch übersetzt werden. Und hier sieht man eine Gruppenzuordnung. Das hat einfach den Vorteil, wir haben gerade im Firmensitz bei uns in Detmold sehr viele Redakteure, die arbeiten und auch regelmäßig Seiten in die Übersetzung schicken. Und wir haben es so konfiguriert, dass tatsächlich nur die Redakteure, die auch an diesen Seiten arbeiten, nachher die Übersetzung sehen. Das kann ich gleich im Firmensitz noch mal zeigen, wie das dann aussieht. Hier habe ich nochmal die gleiche Seite wie eben. In den Metadaten der Seite, also wirklich in den Firmensitz Metadaten, kann ich hier nämlich, sieht man es ganz gut, Kern Custom Feel, Kern ist unser Übersetzungsdienstleister, kann ich dort einen User oder eine Usergruppe eintragen. Die dann quasi im Kernportal diese Seite zugewiesen bekommen. Also wir haben hier wirklich eine sehr enge Verknüpfung zwischen diesen beiden Portalen. Und können das dann quasi direkt steuern, dass wirklich die Redakteure immer nur die für sie notwendigen Sachen sehen und bearbeiten müssen. Genau. Abgrenzend davon haben wir die Übersetzung in den Ländern. Die wird, wie Jan eben schon beschrieben hat, durch den Übersetzungs, durch die Vererbung sozusagen getriggert. Die Übersetzung in den Ländern erfolgt durch einen Übersetzungsdienstleister, wie gesagt, bei uns Kern. Und die Landesredakteure haben aber die Möglichkeit, im Translation Memory System, das Portal, was wir eben gesehen haben, einen Review durchzuführen. Das heißt, dort haben auch die Länderredakteure noch eine gewisse Kontrolle, welche Inhalte gehen nachher zurück in mein Projekt und haben einen bestimmten Zeitrahmen, in dem sie Reviews durchführen können. Denn nachdem, wenn das Review quasi abgeschlossen wurde, laufen die Seiten zurück über Translation Studio in unser CMS und dort erfolgt eine automatische Freigabe der Inhalte, zumindest für fast alle Projekte, die wir haben. Das bedeutet, der Landesredakteur guckt sich quasi die Inhalte eher im Translation Memory System an, wenn er das denn möchte überhaupt. Und ansonsten läuft der Prozess dann vollautomatisch ab. Das heißt, der Redakteur muss nicht alle 30 Seiten, die vielleicht im Update waren, händisch durchklicken und freigeben. Das Ganze ist jedoch, wie schon erwähnt, pro Projekt konfigurierbar. Es gibt tatsächlich ein, zwei Länder, die gerne die Freigabe selber noch durchführen, einfach um da noch mehr Kontrolle zu haben und nochmal eine Endabnahme über die Seite zu machen. Auch das ist bei uns ohne Probleme einstellbar. Wir haben auch einige Länder mit einer identischen Sprache wie das Hauptprojekt, sprich Länder, die auf Englisch publizieren oder auch auf Deutsch. Dort findet kein Übersetzungsprozess statt, weil die Sprachen ja schon vorlesen, sondern nur eine Synchronisierung. Das erstmal grob zum Ablauf, wie das genau im System ausschaut, zeige ich euch jetzt. Hier habe ich mal als Beispiel eine Seite aus unserem italienischen Projekt genommen. Das heißt, der Redakteur in Italien bekommt die Mail, die Jörn eben gezeigt hat, klickt dort vielleicht auf den Content Creator Link und gelangt dann hier zu dieser Ansicht. Ich habe mal die Historie ein bisschen größer gemacht, dass man das gut sehen kann. Am 27.02. haben wir hier einen Content Update durchgeführt um 11 Uhr. Über diese Schedule Task, die Jörn da auch eben gezeigt hat, haben wir das eingestellt. Hier sieht man ganz gut die ganzen einzelnen Elemente, die hinzugefügt wurden oder hier auch verändert wurden oder hier auch eines hinzugefügt wurde, dass wir dieses Jahr auf der Intersolar sind zum Beispiel. Und wenn man sich die Historie noch ein bisschen weiter unten anguckt, sieht man auch am 26.02., also am Tag vorher, sind Übersetzungen vom Translation Studio zurückgekommen und wurden dann auch hier oben automatisch vom Translation Studio freigegeben. Das, was ich eben sagte, wenn eine Übersetzung fertig bestellt wurde und zurückläuft, wird sie eigentlich auch in fast allen Ländern automatisch freigegeben. Das sorgt auch dafür, dass die Seite auf den aktuellen Bestand ist und dann für die nächste Vererbung quasi auch wieder bereit ist. Konfiguriert wird das tatsächlich noch, also diese Workflows und welche da ausgeführt werden im Site-Architekten. Wir können in den Metadaten des Inhaltsbereichs Workflows hinterlegen. In diesem Falle machen wir das immer auf der obersten Ebene, also alle Seiten, die vererbt werden, sollen diesen Workflow erhalten. Es wäre aber auch denkbar, für einen Unterabschnitt bestimmter Seiten, zum Beispiel einen abweichenden Workflow zu definieren. Die Workflows sehen so aus. Das ist, glaube ich, jetzt hier Schweiz mal als Beispiel, weil einfach ein paar mehr Sprachen zur Verfügung stehen. Ich kann als Admin hier vorher festlegen, welche Workflows gestartet werden nach einer Besetzung. In diesem Falle sieht man hier ganz gut Englisch als Ausgangssprache wird übersetzt ins Deutsche, ins Französische und ins Italienische und hier unten ist auch eingestellt, dass diese nach dem Import-Release also freigegeben werden. Wenn ich das nicht wollen würde, würde ich einfach hier diesen Workflow leer lassen oder ich könnte, also vorstellbar wäre auch zum Beispiel, dass eine Sprache in dem Land zum Beispiel intern übersetzt wird. Genau, wenn so ein Content-Update läuft oder gelaufen ist, sieht das für mich zumindest als Admin im Kernportal so aus. Ich kann das hier ganz gut, glaube ich, erkennen. Wie gesagt, 27.02. war ein Update. Hier habe ich die ganzen Länder. Im 20-Minuten-Takt laufen hier quasi die Content -Updates rein und üblicherweise hat so ein Update, was wir alle 14 Tage durchführen, zwischen 30 und 60 Seiten enthält das quasi. Also keine neuen Seiten, sondern jede Seite ein Update bekommen hat. Die Seiten, die nur sprachlich so eine Synchronisation erhalten, weil sie eigentlich in die Sprache schon vorliegt, dort haben wir ein Skript, was wir über die Projekt-Einstellung einstellen können. Das haben wir hier so Language Sync genannt. Auch hier, Entschuldigung, können wir einstellen, dass alle Inhalte direkt transferiert werden und auch ein automatischer Release stattfindet. Das heißt, hier muss nicht auf eine Übersetzung gewartet werden, sondern kurz nachdem die Übersetzung oder die Vererbung stattgefunden hat, sind die Seiten quasi im Zielprojekt aktuell und freigegeben. Zum Beispiel Deutschland aktualisieren wir sogar alle 24 Stunden, weil es eines unserer wichtigsten Märkte ist. Die deutsche Sprache liegt vor und daher ist die deutsche Seite eigentlich auch fast immer synchron zu der Hauptseite. Zum Übersetzungsworkflow gehört in gewisser Weise bei uns auch das Löschen von Seiten und Absetzen im Zielprojekt. Auch dies steuern wir über die Projekteinstellungen, können das individuell für jedes Projekt einstellen und notwendig ist dieser Prozess, das heißt, da im Corporate Content nicht gelöscht wird. Das heißt, ein Absatz, der im Hauptprojekt nicht mehr oder gelöscht wird, würde ohne diesen Prozess in den Kindsprojekten immer noch vorhanden sein, was natürlich auf lange Sicht dazu führt, dass Seiten veraltet sind, unübersichtlich oder groß auch einfach falsche Inhalte auf den Seiten sich noch befinden. Der Prozess sieht, ja, das wird in den Projektinstellungen eingestellt. Hier haben wir die Möglichkeit auch zu differenzieren, ob überhaupt gelöscht werden soll, ob nur die Sektionen, also die Absätze gelöscht werden sollen, ob Absätze und Seiten gelöscht werden sollen oder nur Seiten. Wir hatten diese Granularität anfangs mit eingeplant, weil sie auch gewünscht war. Jetzt seit einer längeren Projektlaufzeit hat sich eigentlich herauskristallisiert, dass wir direkt immer Seiten und Absätze in allen Zielprojekten löschen, weil sich einfach herausgestellt hat, dass das die sinnvollste Methode ist, um einfach alle Projekte aktuell zu halten. Diese Löschungen sind auch für die Redakteure transparent. Björn hat es anfangs schon erwähnt. In den E-Mails sehe ich zum Beispiel, wenn Absätze von einer Seite gelöscht worden sind oder aber auch in den Mails, da habe ich jetzt kein Beispiel hier, aber es gibt auch eine Rubrik, die heißt Deleted Pages. Das heißt, dort kann auch der Länderredakteur dann sehen, wenn eine Seite komplett gelöscht worden ist vom Headquarter aus. Genau. Die automatische Freigabe von Inhalten hatte ich eben schon kurz angesprochen. Nochmal kurz vielleicht zu den Gründen, warum machen wir das? Also erstmal haben wir gerade eine Flexibilität, ob das automatisch geschehen soll oder nicht. Manche Landesgesellschaften haben da gerne noch ein bisschen mehr Kontrolle und möchten das nicht. Dort können wir das dann immer individuell einstellen. Genau. Die Möglichkeiten haben wir dann gerade an die Projektanforderungen, auch an die Freigabeverfahren. Die Prozesse lassen uns da genügend Freiheit. Der große Vorteil dieser automatischen Freigaben ist einfach, dass wir eine Planbarkeit für das Kampagnenmanagement haben, sowohl in den Ländern als auch bei uns in der Zentrale, weil durch die automatische Freigabe in fast allen Ländern wir genau sagen können, zu welchem Zeitpunkt vererbte Inhalte wirklich auch in den Ländern online sind. und dort genutzt werden können. Nochmal zusammengefasst die Vorteile des gesamten Prozesses, den ich gerade vorgestellt habe. Die Redakteure werden erstmal entlastet bei der Erstellung des globalen Contents, dadurch, dass, wie gesagt, die Seiten dort ihnen speziell zugeordnet werden in unserem Translation Memory System, dass Seiten vorübersetzt werden, dass der Rest der Übersetzung KI-gestützt abläuft. Wir haben standardisierte Prozesse und einen zentralen Übersetzungsdienstleister. Das sorgt dafür, dass wir eine hohe Qualität auf allen Webseiten haben, was die Übersetzung angeht, was die Verwendung unserer Terminologie angeht, aber auch, was die Planbarkeit und den zeitlichen Ablauf angeht. Und die automatisierte Löschung und Freigabe in den Zielprojekten stellt, wie gesagt, die Aktualität des Contents sicher, auch wenn mal vielleicht in den Ländern krankheitsbedingt oder wie auch immer Kollegen ausfallen. Können wir das im Headquarter alles steuern, dass diese Seiten trotzdem online sind? Ja, Fragen oder Anmerkungen? In der Tat, da sind welche bei F&A. Ich lese mal vor, chronologisch. Verteilung Master in Länder inklusive Freigabe ausgeführt. Wie wird denn Reihenfolge sichergestellt? Lokaler Länderkontent sollte seine Position behalten. Wie habt ihr das gelöst? Die Länder haben auf den Produktseiten, die vererbt werden, relativ wenig lokalen Content. Die kontrollieren das dann tatsächlich, wenn sie den mitten im Content haben, müssten sie tatsächlich noch einmal kontrollieren, ob der noch an der richtigen Position ist. Gelöscht wird er, wie gesagt, nicht. Er bleibt da. Der häufigste Fall, den wir aber tatsächlich haben, ist, dass in unserem Download-Bereich, der sich praktischerweise immer eigentlich am Ende der Seite befindet, nochmal lokale Downloads hinzugefügt werden. Das ist eigentlich üblicherweise der lokale Content, den wir auf unseren Produktseiten haben. Ansonsten auch noch die Ansprechpartner. Die haben wir einfach auf eine ganz andere Methodik gepflegt. Da nutzen wir tatsächlich die Metadaten der Strukturelemente, um auch nochmal dort was zu pflegen. Die werden durch die Vererbung nicht beeinflusst, stehen aber auch ganz am Ende der Seite. Und dann hat zusätzlich jedes Land auch Bereiche, wo sie komplett lokal pflegen können. Das ist zum Beispiel die Startseite, der Karrierebereich oder natürlich einfach der Vertriebsbereich, also der Sales-Bereich. Dort können sie lokal aufbauen oder auch natürlich komplett lokale Seiten hinzufügen, die ja nicht Teil des Corporate Content Pakets sind und daher auch nicht verändert werden. Danke sehr. Eine Frage habe ich hier auch noch. Französisch für Frankreich und Französisch für die Schweiz. Werden diese separat und doppelt aus dem Englischen übersetzt und auch doppelmanuell korrigiert und angepasst? Ja, wir haben mehrere Beispiele. Wir haben zum Beispiel Französisch für die Schweiz, Französisch für Frankreich. Wir haben aber auch Portugiesisch für Brasilien, Portugiesisch für Portugal. Wir haben dort die als Subsprachen angelegt. Das heißt, wenn im Review der portugiesische Kollege tatsächlich was anpasst, dann wird diese Anpassung auch durchgespeichert. Es ist aber so, dass wir aktuell nur für die Hauptsprachen eine komplette Übersetzung durchführen und die wird dann quasi für die Subsprachen, also für gleiche Sprachen in anderen Ländern, quasi einmal kopiert. Dort fallen nicht die kompletten Kosten an, sondern nur so eine Handlingsfee, würde ich es mal nennen. Genau, also das heißt, die liegen als separate Sprache vor, werden aber quasi zeitgleich laufen die zurück. Das ist ein bisschen, ja, ich hoffe, dass es so einigermaßen verständlich erklärt. Bei einer Folie habe ich gesehen. Ja, klar ist ja ein. Bei einer Folie habe ich gesehen, dass gleiche Sprachen auch nur synchronisiert werden in einem Land, wenn die Übersetzungen komplett identisch sind. Bitte nochmal, das habe ich akustisch. Ich habe irgendwie Folie 20, war das so, da stand drin, dass manche Sprachen komplett synchronisiert werden, weil sie ja gleich sind, obwohl sie unterschiedlich wären. Genau. Die Synchronisation findet dann statt, wenn entweder Deutsch oder Englisch in das Zielprojekt quasi importiert wird. Und dann findet eine Synchronisation statt. Okay. Genau, nur dann. Also das Französische liegt ja in einem einen Landesprojekt vor und das andere Französisch liegt in einem separaten Landesprojekt vor. Da können wir keine Synchronisation durchführen. Wir führen quasi nur eine Synchronisation per Skript dann durch, wenn quasi die importierte, also die vererbte Sprache gleich der publizierten Sprache im Zielprojekt ist. Zur nächsten Frage. Basiert die Schnittstelle zum Übersetzungsdienstleister auf dem für Spirit nativen XML Export Import? Jein. Da gehe ich mal drauf ein. Wir verwenden bei Weidmüller tatsächlich das Modul Translation Studio, welches ja von ID.media ist. Und ich glaube, im Hintergrund ist das, ist eben das XML, was ID.media in dem Translation Studio verwendet, ist sehr nah dran an diesem XML Export Import, den wir von früher kennen. Also früher gab es ja auch tatsächlich dieses Rechtsklick Übersetzungs-XML runterladen und dann wieder hochladen. Also das ist relativ ähnlich dazu. Aber hier setzen wir auf einen Standard, der von ID.media im Translation Studio weiterentwickelt worden ist. Und tatsächlich gibt es für Translation Studio und Kern inzwischen einen standardisierten Connector, der in Zusammenarbeit mit Weidmüller durch ID.media und Kern entwickelt worden ist, sodass sowohl Translation Studio als auch Kern da tatsächlich wissen, wie das Format aussieht, wie das weiterverarbeitet werden soll. Genau. Also das ist ein klares Jein, weil das Translation Studio XML ist, glaube ich, nicht zu 100 Prozent dieser XML Export Import, aber sehr nah dran angelehnt. Wäre es denn möglich, alle Übersetzungen über Translation Studio zu steuern und nicht noch zusätzliche Prozesse dazu zu bauen, verknüpfen? Das wäre tatsächlich denkbar. Und ich glaube, wir haben diesen Language Sync-Prozess einfach schon länger quasi, als wir aktuell die Schnittstelle von Kern nutzen. mit der Automatisierung. Wir hatten vorher da einfach andere Prozesse, die nicht ganz so gut waren, wie das, was wir jetzt aktuell nutzen. Wenn wir das heute quasi nochmal von Grund auf neu bauen würden, würde ich vermutlich dazu tendieren, alles über das Translation Studio abzuwickeln und zu schicken und auch das Handling dann selbst von den gleichen Sprachen in unserem Translation Memory dort zu automatisieren. Genau. Damit man einfach einen gleichen Prozess über alles hat. Aber da der Prozess sehr stabil und sehr zuverlässig läuft, haben wir den jetzt für die Länder, die quasi die gleichen Sprachen haben, wie das Hauptprojekt, einfach so gelassen. Gut. Und bevor ich die nächste Frage vorlese aus der Audience, ich sehe, da hat jemand die Hand gehoben. Bitte stell doch deine Frage in die F&A-Box. Dann können wir die direkt beantworten und vorlesen. Zur nächsten Frage. In welchem Zeitraum sind Aktualisierungen bei den Ländern durchgeführt? Also wenn es jetzt zum Beispiel eine neue Kampagnenseite gibt, werden die Länder dann alle gleichzeitig aktualisiert? Also alle Länder, die die gleiche Sprache haben wie das Hauptprojekt, werden mindestens einmal in der Woche, wie das heißt, das Deutsche und ich glaube das Englische, also UK, werden sogar täglich aktualisiert, weil wir dort einfach keinen Übersetzungsprozess haben. Alle Länder, die eine Sprache abseits von Deutsch oder Englisch verwenden, werden alle zwei Wochen aktualisiert. Das hat einfach den Hintergrund, dass unser Besetzungsdienstleister ungefähr drei bis vier Werktage immer für die Besetzung benötigt und die Länder, die Redakteure in den Ländern auch die Möglichkeit haben sollen, ein Review durchzuführen, auch wenn es mal etwas mehr Content ist. Das heißt, die haben in den Ländern auch drei bis vier Werktage ungefähr zur Verfügung. Und da hat sich dann für uns herausgestellt, dass ein zweiwöchentlicher Update-Zyklus das Optimum eigentlich darstellt. Wir haben einen sogenannten Redaktionskalender, das heißt, allen Beteiligten bei Weidmüller ist transparent, wann die nächste Vererbung durchgeführt wird, wann die Übersetzungen in die Länder zurücklaufen und wann sie dann dort entweder nach Beendigung des Reviews oder wenn das Review nicht durchgeführt wird, schließen wir dann automatisch da das Review, sage ich mal, ab. Und genau, anhand dieses Kalenders, wie gerade das ganze Jahr schon festgelegt wird, weiß eigentlich jeder, wann die Seiten dort passieren und Kampagnen werden dann entsprechend auch einfach terminiert oder man arbeitet einfach zusammen und stimmt sich da ab. Gut, aus der Audience habe ich jetzt keine Frage, aber ich habe mir nochmal was aufgeschrieben zu den letzten Folien, die in deinem Beitrag jetzt da waren, zum Thema Löschung von Seiten. Wie wird denn das alles gehandhabt mit dem Thema SEO? Also eine Seite nicht mehr da, da muss man Redirect machen, sonst fliegt man ja irgendwie da auch wieder raus aus dem Kontext. Hip, top, Überleitung, Fauri. Willkommen jetzt zu den SEO-Optimierungen in unserem Vererbungsprozess, weil da gibt es ja mehrere Aspekte. Und zwar gibt es natürlich mehrsprachiger Content und SEO. Wir haben durch die strikte Vererbung von Content aus dem Headquarter natürlich die Gefahr, dass wir doppelt einen Inhalt für eben die Suchmaschinen wie Google erzeugen, weil wir haben es ja gerade gehört, wir haben auch schon Language-Sync teilweise, wo dann tatsächlich der Content auch noch nicht nur identisch aussieht, sondern auch noch identisch ist. Da bietet es sich an, tatsächlich eben um diese Kennzeichnung, um das kenntlich zu machen mit hrflangen Elementen in der Webseite, um eben den Suchmaschinen mitzuteilen, dass eben dieser Inhalt nicht doppelt ist, sondern als eigenständig betrachtet werden soll. Die Einführung von hrflangen Elementen bietet natürlich auch noch zusätzlich den Vorteil, dass wir die Suchmaschinen dabei unterstützen, länderrelevante Seiten eben zu finden und auch in den Ländern die korrekten sprachspezifischen Snippets in den Suchergebnissen anzuzeigen. Jetzt gibt es da tatsächlich eine Herausforderung und zwar bei Corporate Content gibt es keine Verknüpfung zwischen den Kindprojekten, nenne ich es jetzt mal. Der Content weiß tatsächlich, dass es aus dem Headquarter kommt und kann da auch die Verknüpfung herstellen. Wir wollen aber tatsächlich eine automatisierte Generierung dieser hrflangen Verknüpfung. Das heißt, die Kindprojekte müssen auch wissen, in welchem anderen Kindprojekt existiert denn dieser Content und mit welcher URL überhaupt. Und dafür haben wir einen gemeinsamen Nenner geschaffen über eine UUID, die im First Spirit automatisch gepflegt wird. Da habe ich mal zwei Screenshots einmal mitgebracht. Ich hoffe, die sind groß genug. Und zwar in der Seitenbearbeitung, dort wo ich auch einstellen kann, wie ist die Priorität, wie oft ändert sich der Inhalt und soll das indiziert werden oder nicht, gibt es ein Feld Global Page ID, nennen wir es. Da haben wir uns ein bisschen der Terminologie von For Spirit Interna bei Datensätzen bedient. Und hier ist tatsächlich ein Value Service hinterlegt. Die Redaktion im Headquarter muss sich nicht darum kümmern, da einmal mit dem Kopf über die Tastatur zu rollen. Und eine UUID zu generieren, sondern der Value Service, sobald ich eine Seite anlege, befüllt vollautomatisch diese Global Page ID mit einer UUID und einem Zusatz der eigentlichen Page ID aus For Spirit. Warum machen wir das? UUIDs sind unter Umständen nicht immer identisch. Also bisher sind sie das gewesen, aber die Statistik sagt, dass UUIDs auch ruhig mal doppeln können. Aber um dem vorzubeugen, hängen wir als Präfix. Das ist tatsächlich die, also fix die Page ID an. Und damit haben wir die Möglichkeit, zum Generierungszeitpunkt einmal durch die Projekte zu gehen und die Seiten zu identifizieren und uns die gespeicherten URLs zu nutzen zu machen und diese auszulösen und in jedem Projekt und auf jeder Seite entsprechend mit dem dazugehörigen Harre Flangen ISO Code in den Kopf der Seite zu schreiben. So hat jede Suchmaschine die Möglichkeit, eben den länderspezifischen Content zu identifizieren und wir haben auch die Möglichkeit eben klarzustellen, okay, die Int-Seite ist eben auch der X-Default und die Suchmaschinen haben die Möglichkeit, so den länderspezifischen Snippet und auch das länderspezifische Ergebnis anzuzeigen und die Seiten kannibalisieren sich in den Suchergebnissen. Das ist nicht, weil sie klar als eigenständiger Content betrachtet werden können. Löschung von Inhalten ist das zweite Thema. Wenn Seiten gelöscht werden, erzeugen wir theoretisch 404 Seiten, die möglicherweise Rankings kaputt machen, die für weit mehr von Vorteil gewesen sein können, weil es eine Seite gewesen ist, die vielleicht hoch gerankt ist, die man weiter benutzen möchte. Das heißt, das kann eben das Ranking in der Suchmaschine beeinflussen. Deswegen erzeugen wir automatisiert im Workflow, wenn wir die Inhalte löschen, ein 301 permanent redirect, der von der Suchmaschine erkannt wird und so quasi das Ranking genutzt wird, um auf eine andere Seite zu verschieben. Da gibt es einen Automatismus, der identifiziert, was angezeigt werden soll. Und wir nutzen hier tatsächlich nicht die SEO-URLs von FastPirit, die tatsächlich eine andere Seite unter der gleichen URL zur Verfügung stellen, sondern wir erzeugen hier aus FastPirit echte Rewrite-Regeln, die regelmäßig, ich glaube, Moritz korrigiere mich gleich, ich glaube, alle sechs Stunden oder alle vier Stunden vom Web-Server automatisch eingelesen werden. Und dann wirklich echte 301, also Moved Permanently Redirects für die Suchmaschine darstellen. Diese Datenquelle habe ich jetzt auch mal als Beispiel mitgebracht, weil diese Datenquelle, um Redirects zu erzeugen, kann die Redaktion auch nutzen, um eigene Redirects einzustellen. Und ich habe es erwähnt, wir haben einen gewissen Automatismus, um eben bei Löschungen Redirects zu erzeugen und so habe ich die Möglichkeit, ich sehe hier, da ist jetzt zum Beispiel die, ich muss es einmal da, die Wallbox-Seite gelöscht worden. Und ich habe mich hier automatisiert für eine Seite entschieden, wo der Redirect hinlaufen soll. Aber es kann ja sein, dass die Fachredaktion eine viel bessere Seite dafür kennt und kann dann manuell noch hergehen und den Redirect, wenn sie denn möchte, anpassen und auf eine andere Seite laufen lassen. Die Seite muss dann noch freigegeben, also die Änderung muss freigegeben werden, wird dann publiziert und automatisch vom Web-Server wieder eingelesen. Wir haben auch zusätzlich noch die Sitemap-XML, die mindestens alle 24 Stunden aktualisiert wird. Dort fallen dann die gelöschten Seiten auch automatisch aus dem Scope und werden nicht mehr zur Verfügung stehen. Und solange sie noch in der XML-Sitemap zu finden werden, würden ja jetzt die automatisch eingelesenen Redirects greifen, sodass es nicht so schlimm ist, dass sie noch in der Sitemap drinstehen. Aber dann weitergeleitet werden. Auch für diesen Abschnitt haben wir wieder Fragen- und Antwortenzeit. Gibt es auch welche in der Audience wieder? Ich lese mal vor von Ronny. Warum ist eine derartige Global-Page -ID nicht schon längst Standard im CMS? Ja, ich weiß nicht, ob du das Antworten schiebst oder nicht. Das sind Fragen über Fragen, ja. Nee, ich kann natürlich nehmen, ich nehme das Thema mit zum Produktmanagement. Ich schaue mal, ob das in der Roadmap schon drin ist. Stand heute ist anscheinend nicht drin, aber kann man ja schauen, ob das hoch priorisiert wird für das nächste Release. Also die Zeichen dafür stehen gut. Diese Global-ID an den Datensätzen gibt es auch noch nicht immer. Ist da damals eingeführt worden und ich gehe tatsächlich davon aus, dass das für Seiten auch zukünftig passieren wird. Aber da auch immer der Tipp, nutzt die User-Group und den Kontakt zu uns oder Fabri, um eben die Produkt-Roadmap mit zu beeinflussen. Die nächste Frage, ein bisschen länger. Also mit der Global-Page-ID kann man die zugehörigen Seiten ja aus den anderen Projekten finden. Aber dazu muss man dann auch zum Generierungszeitpunkt für jede Seite in allen anderen Projekten geschaut werden, um die passende HDF-Lang-URLs zu finden. Das als Frage. Das müsste ja massiv die Generierungszeit verschlechtern, oder? Müsste, tatsächlich. Das Gefühl hätte ich auch gehabt, als wir diese Implementierung gemacht haben, weil wir ja im Prinzip zum Generierungszeitpunkt eine Verbindung zu jedem für das Projekt einmal öffnen. Tatsächlich ist das aber nicht der Fall. Die Generierung hat sich nicht wesentlich verlängert dadurch. Ich schätze, wenn das jetzt ein Verspürrück Aufbau wäre, wo wir 50 bis 100 Projekte plus hätten, dann wäre das tatsächlich ein fragliches Vorgehen. Dann müsste man sich dafür eine zusätzliche Logik wahrscheinlich ausdenken. Aber bei Weidmüller haben wir keine schlechten Erfahrungen damit gemacht. Das System ist performant genug, um eben diese Informationen zurechtzuziehen. Ein großer Vorteil ist tatsächlich, dass wir die gespeicherten URLs nutzen können, weil wir nicht noch das Projekt anstrengen müssen, um über den Content Producer sich überhaupt zu überlegen, wie wäre denn eigentlich die URL. Weil wir können die gespeicherten URLs verwenden, die sind schon da. Das heißt, ich muss nur das Projekt einmal öffnen, die Seite abrufen und die URL zurückgeben. Also das geht tatsächlich recht schnell. Zur nächsten Frage. Werden die Redirects auch für andere Sprachen erstellt oder muss man diese dann auch noch manuell erstellen? Die Redirects werden tatsächlich für jede gespeicherte URL erstellt. Also das heißt, wenn diese, wenn für eine Seite zwei URLs gespeichert sind, also Deutsch und Englisch zum Beispiel, dann werden auch zwei Redirects erstellt. Ja, beziehungsweise ich glaube, die Frage ging auf die Landesprojekte. Also in den Landesprojekten dieses Erstellen der Zero Redirects ist mit dem Löschen-Workflow. Das heißt, wenn wir eine, wenn eine Seite im Landesprojekt gelöscht wird, dann wird auch automatisch ein Zero Redirect erstellt. Wenn, also der einzige, der, was das nicht automatisch passiert ist, wenn jetzt im Hauptprojekt sich ein Redakteur einen, nachträglich den Redirect ändert, was Jörn eben gezeigt hat, sagt hier, die Seite, die da automatisch ausgewählt wurde, ist nicht ideal. Es gibt noch eine bessere und sich dort an dem Datensatz da eine, eine neueren oder eine andere Seite auswählt. Das wird nicht automatisch in alle Kindsprojekte übertragen, weil jedes Projekt für sich diese SEO-Weiterleitungs-Datenquelle hat und die untereinander nicht synchronisiert werden. Zur nächsten Frage. Nutzweitmühler hierbei die Cloud oder die On-Prem-Lösung von Crownpick? Die On-Prem-Lösung. Aktuell die On-Prem-Lösung. Ich hatte auch noch eine Frage aufgeschrieben. Nach welcher Logik entscheidet das System, auf welches Ziel ein Redirect erfolgen soll? Der Workflow ist so konfiguriert, dass wir quasi die Elternkette des Objektes nach oben gehen und dann tatsächlich die nächste Startseite im Prinzip auswählen. Also wenn die Terminologie kennt, hat im Navigationsverlauf eben die Menüpunkte und dort sind ja Seiten als Startseiten gekennzeichnet und da wird der nächst oberliegende Punkt mit Startseitenkennzeichnung genommen. Das hat sich bisher so bewährt, weil das in der Regel immer eine Übersichtsseite zu eben genau dem Topic, wo die Seite vorher zugehörte ist und damit die Weiterleitung nicht auf eine komplett Themenfremdung. Seite passiert, sondern schon irgendwie immer noch. Also wir haben jetzt Wallbox, da war Elektrizität irgendwie die Zielseite. Das passte halt ganz gut. Das ist ja der Automatismus. Eine Ebene höher zur Übersichtsseite. Kann man den umgehen? Also ich habe dann wirklich eine andere Zielseite in der gleichen Ebene, weil ich die halt neu gemacht habe oder komplett geändert habe und würde das gehen? Kann man da manuell eingreifen in dem Prozess? Aktuell nicht. Tatsächlich haben wir da schon mal drüber gesprochen, dass man bei der Vererbung oder dass man über die Metadaten eine Zielseite mitgeben kann, was das Ersatz sein könnte. Aber Moritz, vielleicht für euch hat sich der Case nicht so herausgestellt, dass das notanglich ist. Wir hatten das mal überlegt, dass man beim Löschen einer Seite quasi schon direkt angeben kann, welche Seite soll denn dann, sage ich mal, der Ersatz sein oder wohin soll der Redirect zeigen. Es hat sich einfach, also wir löschen erstens nicht im Jahresverlauf, sage ich mal, nicht so viele Seiten und wenn wir sie dann löschen, ist in sehr vielen Fällen einfach die darüber liegende Seite die passende, sodass wir das dann tatsächlich jetzt erstmal noch nicht so hoch priorisiert haben. Wir haben gerade angedacht, haben wir das mal durchaus auch schon durchgeplant und so, das wäre möglich, hat sich aber bei uns von der Priorität bisher noch nicht so gezeigt, dass wir das umsetzen müssten. Ja, ich sehe keine weiteren Aufwandfragen. Danke für die Antworten. Dann gehen wir nochmal kurz weiter. Wir sind ja auch schon fast am Ende, aber wir wollen natürlich trotzdem einen kleinen Ausblick darauf geben, wie kann es jetzt eigentlich damit weitergehen? Wir haben jetzt einige Verbesserungen oder Optimierungen für die Weidmüller oder gemeinsam mit der Weidmüller implementiert. Der eine Punkt ist tatsächlich, der diskutiert wurde und tatsächlich, nachdem ich den Bullet auf die Folie geschrieben habe, haben wir das schon gemacht, weitere Inhaltspakete zu definieren, um Inhalte losgelöst vom aktuellen Update-Zyklus zu verteilen. Wir haben vorhin Kampagne gehört. Bei Weidmüller ist es tatsächlich dazu gekommen, dass eben solche Kampagnenseiten nochmal verteilt werden. Und dafür ist ein zusätzliches Corporate-Content-Paket entstanden, womit eben zusätzliche Inhaltsbäume verteilt werden können. Und da greift im Hintergrund trotzdem die gleiche Logik wie bei dem, ich nenne es jetzt mal großen, Verteilungspaket. Das bietet halt die Möglichkeit, auch kleinere Teile losgelöst von diesem Automatismus trotzdem auch über den optimierten Modus zu verteilen. Und da gibt es die Überlegung und die Bestrebung, noch zusätzliche Möglichkeiten zu schaffen oder vielleicht da auch den Weg zu vereinfachen, Weidmüller die Möglichkeit zu geben, selbst solche Pakete zu definieren. Und dann steht tatsächlich noch auf unserer Roadmap, im Moment haben wir ja Corporate-Content-Einsatz. Wer sich damit auskennt, ist es im für das Spirit-Kontext eher veraltete Technologie. Und da gibt es tatsächlich die Idee, das durch das neue Multisite-Management von Crown Peak abzulösen. Großer Vorteil ist hier tatsächlich, der Großteil der Logik, die wir hier implementiert haben, kann auch mit dem neuen Multisite-Management verwendet werden. Hier sind kleinere Anpassungen notwendig, weil eben der Informationsset von den Elementen, die verteilt worden sind, etwas anders strukturiert ist. Aber das stünde jetzt auf der Roadmap als nächstes anzugehen, dass man auf das neue Multisite-Management setzt und damit noch eine gewisse Mehrflexibilität bietet und den vorher genannten Punkt sogar noch flexibler zu machen. Moritz, was macht das Multisite-Management für Weidmüller erfolgreich? Genau. Einmal vielleicht noch so ein bisschen als Wrap-up, was wir hoffen, dass wir euch ein bisschen mitgeben konnten, was da so bei Weidmüller, der eigentlich die Key-Benefits, wie man so schön auf Deutsch sagt, sind. Die Redakteure in den Ländern können die Inhalte, die sie bekommen, beeinflussen, hauptsächlich eigentlich durch die Reviews, aber natürlich auch dadurch, dass sie lokale Seiten oder auch Absätze einfügen können. Das müssen sie aber nicht, denn der Großteil der Seite wird vererbt. Und die, selbst wenn sie nichts machen, haben sie eine sehr aktuelle, sehr gut aussehende und komplett übersetzte Seite. Die relevanten Prozesse oder eigentlich alle Prozesse sind von Weidmüller zentral zu steuern. Der Großteil davon auch über den Content-Creator, zumindest an die, die man regelmäßig drangehen muss. Die, und eigentlich der Punkt ist der, das ist für uns der größte Benefit, die Übersetzungs- und SEO-Prozesse sind integraler Bestandteil des Multisite-Managements. Ja, für die Übersetzung geht man nochmal in ein separates Portal, aber ich glaube, wir konnten so ein bisschen zeigen, die sind sehr eng miteinander verknüpft. Vieles läuft automatisiert, sodass man nicht nochmal für unnötige oder für so Routineschritte wieder zurück ins CMS zum Beispiel wechseln muss bei der automatischen Freigabe. Genau, das ist der letzte Punkt. Die wiederholenden Schritte wurden automatisiert. Und soweit es denn irgendwie ging und natürlich auch sinnvoll ist, ja, das führt einfach dazu, dass wir da von einem für uns sehr erfolgreichen Multisite-Management sprechen würden. Ja. Wir sind am Ende unserer Präsentation und noch ein bisschen Zeit für Diskussionen beziehungsweise noch Fragen, die vielleicht offen geblieben sind. Ja, ich habe hier noch eine aus der Audienz. Das ist eine sehr interessante Frage. Grob geschätzt, wie viele Manntage hat denn das ganze Ding gekostet, das Multisite-Management? Jetzt ist natürlich die Frage, wo grenzt man es ab? Nimmt man die Kernprozesse außerhalb Translationsstudio mit dazu? Nimmt man die nicht mit dazu? Ich glaube, das Aufwendigste ist am Anfang sicherlich die Konzeption der Prozesse. Wie soll es denn ablaufen, als das reinhacken und umsetzen dann? Aber könnt ihr da überhaupt eine Zahl nennen? Keine Ahnung, in Manntage? Ich würde jetzt mal, also die Entwicklung ist ein bisschen entstanden. Es gab so einen Running Gag im Projektverlauf, dass wir sagen, pro Refinement ein Skript. Und wenn ich das so überschlage, dann würde ich fast sagen, also es ist, wie lange machen wir, arbeiten wir daran schon, Moritz? Zwei Jahre? Nein, länger. Drei Jahre? Ich glaube, ja, fast fünf. Oder vier? Ja, zumindest. Also ich würde jetzt so aus dem Bauch heraus sagen, dass da bestimmt 100 Tage reingeflossen sind auf die Jahre gesehen. Okay, okay. Ja gut, das ist ja auch nichts Triviales, muss man ganz klar sagen. Wobei das halt, wie schon eben gesagt, schwer abzugrenzen ist. Das ist im Projektverlauf gewachsen. Wir hatten jetzt aktuell Nuss-Wingart-Kern und die Kernschnittstelle als Dienstleister und als Schnittstelle. Wir hatten zum Start des Projekts noch einen anderen Dienstleister erst mit einer anderen Schnittstelle, der einfach auch andere, also gar nicht so diese Menge an Automatisierung eigentlich ermöglicht hat. Ich glaube, allein der Rollout-Prozess, bis es in alle Länder eigentlich überhaupt das neue, das für Spirit quasi eingeführt war, hat in Summe, würde ich sagen, locker über ein Jahr gedauert. Also deswegen und auch dann kamen neue Länder hinzu mit neuen Ländern, kamen neue Anforderungen, die man vielleicht von Anfang an eigentlich so bedacht hat. Ja, wir haben auch gerade erst letztens komplett, sage ich mal, diesen ganzen Vererbungsprozess nochmal refactored, weil dort sich einfach historisch gesehen einfach eine Menge auch technischer Schulden irgendwo ein bisschen so angesammelt hatten. Und das Refactoring an sich, na gut, das muss ich jetzt auch mal, ich würde mal sagen, das waren dann eher so irgendwas zwischen 5 und 10 PT, würde ich sagen. Also das ist vielleicht so Größenordnung. Aber dann waren natürlich die, da mussten die Prozesse nicht neu geplant werden, sondern technisch einmal, sage ich mal, neu. Umgeschickt werden. Und ich weiß gar nicht, ob wir wirklich an allen Sachen vorbeigekommen sind. Aber das war dann, das ist so das, ja, warum es jetzt schwierig ist, das hat so und so viel gekostet. Wenn ich jetzt neu, also wenn ich mit dem Wissen, was ich jetzt habe, das nochmal neu machen würde, wäre es wahrscheinlich weniger. In Summe über die ganze Zeit hinweg ist es vielleicht dann wirklich näher an dem, was Jörn sagt. Ja, genau. Also wenn man die Anforderungen von Anfang an genauso gehabt hätte, dann wären wir wahrscheinlich irgendwas bei 30 bis 50 PT gelandet. Aber jetzt so in allem Drum und Dran und genau das Refactoring einmal mit dem Besen durchgehen und was man so vor drei, vier Jahren gemacht hat, nochmal ein bisschen besser aufzustellen und das gehört ja dann auch noch dazu. Genau. Ja, ich sehe jetzt in der Q&A-Box keine weiteren Fragen. Ich hätte persönlich da eine, weil mich das Thema immer wieder rumtreibt, hat etwas weniger mit Multisite Management zu tun, sondern eher mit der Generierung von Content. Ihr tut ja sehr oft Seiten aktualisieren und dann auch in den Ländern übersetzen, verteilen, also habe ich jetzt mitbekommen in der Präsentation. Wie generiert ihr denn Content? Sind das dann Online-Marketing oder Marketing-Redakteure, Redakteure denn, die den Text dann schreiben, erfinden und sich überlegen oder verwendet ihr da auch schon AI-Tools? Zur Erstellung des Contents direkt nicht und der Content wird auch nicht bei uns nur im Marketing erstellt, sondern gerade die Produktseiten sind sehr technisch, braucht man sehr viel technische Expektive und beziehungsweise auch unsere Kunden erwarten da auch einmal ein hohes Level an technischer Genauigkeit. Das heißt, die Seiten werden tatsächlich in den Fachbereichen zum größten Teil, zumindest die Produktseiten, erstellt. Was wir nutzen, ist tatsächlich verschiedenste Tools, zum Beispiel zur SEO-Optimierung, einfach um zu gucken, wie sieht die Keyword-Dichte aus, Keyword-Recherche. Bei solchen Dingen kommen dann natürlich auch Tools zum Einsatz, die heutzutage einfach auch fast alle irgendwie KI-gestützt sind. Genau. Und bei der Besetzung hatte ich es ja schon erwähnt, dass da die Sachen vorübersetzt werden, auch bei Machine Translation, was über unseren Übersetzungsdienstleister Kern angebunden ist. Das heißt, über Kern haben wir da die Möglichkeit, eine für uns trainierte Übersetzungs-KI zu verwenden, die auch unsere Terminologie kennt. Genau. Das sind so die unterstützenden Tools, die wir da so hauptsächlich nutzen eigentlich. Wunderbar. Ja, und es macht Sinn auch, dass die KI trainiert ist auf eure Sprache, auf eure technischen Details und alles dran und dran, weil ja, muss ja irgendwie alles konsistent sein und passen. Da kommt noch eine Frage rein. Könntet ihr nochmal bitte genauer beschreiben, Nutzung, Multisite-Management versus Corporate-Content? Wenn ich es richtig verstanden habe, nutzt ihr nicht die neue Komponente von First Spirit? Das ist richtig, genau. Also momentan ist es Corporate-Content, weil zum Projektbeginn gab es das neue Multisite-Management ja noch nicht. Da ist es ja tatsächlich, Corporate-Content ist relativ starr in seiner Paketierung. für den Inhalt, für die Inhaltsvererbung. Das neue Multisite-Management ist ja tatsächlich seit Ende letzten Jahres eine Ramp-up-Phase, beziehungsweise kann jetzt, glaube ich, über euch, das kannst du besser beantworten, Fabri, eingesetzt werden. Da ist tatsächlich, das neue Multisite-Management setzt im Hintergrund auf auch eine Technologie, die es schon länger gibt, Content Transport ein. Also Content Transport ist eigentlich für eben eine manuelle Vererbung gedacht. Da lädt man sich dann Zipfals runter, trägt die rüber und lädt sie wieder hoch. Und da ist tatsächlich, bei dem neuen Multisite-Management kann ich flexibler Inhaltspakete packen. Also da könnte ich hergehen und eben auch eben dieses große Paket definieren, aber ich könnte auch ad hoc hergehen als Redaktion mit. Ich habe jetzt eine Landingpage für dieses Webinar hier, kann mir alle Inhalte in meinem Headquarter -Projekt zusammenklauben und das Paket definieren. Also damit ist man auch für kurzfristige und auch nicht auf lange angedachte Contents auf der flexibleren Seite. Und technisch ist eben die Paketierung und die Informationen, die eben das neue Multisite-Management zur Verfügung stellt, was für Inhalt habe ich verteilt, etwas anders als mit Corporate Content. Daher müsste man jetzt unseren, das ist jetzt tatsächlich von der Begrifflichkeit ein bisschen schwer auseinanderzuhalten, Weidmüller Multisite-Management und neues Groundpeak Multisite-Management. Da muss man halt gucken, dass man sich eben die Informationen anders aus dieser Verteilung holt. Was hat sich denn eigentlich verändert? Und bei dem neuen Multisite-Management hat man noch andere Herausforderungen, die zu berücksichtigen sind. Und zum Beispiel ist das so, bei Corporate Content ist es ja so möglich, dass eben Seiten auch mit lokalem Content angereichert werden können. Also das heißt, Länderredaktoren können hergehen und zusätzliche Absätze in die Seite reinwerfen. Die würden auch bestehen bleiben. Und im neuen Multisite-Management würde dann aber da wiederum der lokale Absatz verloren gehen. Das heißt, da müsste der Webflow angepasst werden, dass ich mir eben den lokalen Content des Redakteurs auf dieser eigentlich Headquarter-Seite wieder zurückhole. Auch dafür haben wir schon Lösungsideen, wie man damit umgehen kann. Das sind so die Unterschiede. Also die technische Herangehensweise zwischen dem Corporate Content und dem neuen Multisite-Management. Multisite-Management ist der Unterbau ist ein ganz anderer. Aber die Lösung, die wir hier heute gezeigt haben, kann so ähnlich verwendet werden. Und noch kurz vor Schluss noch eine Frage. Multisite-Management ist ja nun im Content Creator für Redakteure nutzbar und nicht wie Corporate Content-Verteilung im Site-Architekt. Eigentlich nur um den Admin vorbehalten ist. Je nach Verrichtigungskonzept. Corporate Content ist nur für die Projekte-Admins. Genau. Und genau mit dem neuen Multisite-Management ist die Berechtigungsverteilung wesentlich einfacher und da kann man. Wenn ich als Redakteur das Recht habe, vom Headquarter auch im deutschen Projekt zu arbeiten, dann habe ich auch die Möglichkeit, den Inhalt vom Headquarter ins deutsche Projekt zu übertragen. Genau. Und bei Corporate Content ist es so, dass die Verteilung muss ja vordefiniert, vorkonfiguriert werden. Da kann ich mich nicht mal so eben entscheiden, noch Inhalte in ein anderes Projekt zu verteilen, wenn Corporate Content davon nicht Bescheid weiß, dass das geht. Und das neue Multisite-Management ermöglicht auch flexiblere Verteilung zwischen Kindsprojekten. Also es kann jetzt sein, dass eben Beispiel Brasilien, Portugal ähnliche lokale Contents gegebenenfalls hätten, die das Headquarter aber nicht brauchen. Und so könnte das neue Crownpeak Multisite-Management dann Inhalte auch da die Verteilung vereinfachen. Davon würde man im Corporate Content Fall abraten, weil wenn sich da Vererbungsabonnements schneiden, dann reicht man vielleicht lieber an Sybretical rein. Ja. Es kommt nochmal eine Frage. Wir beantworten die noch. Die letzte Frage. Gibt es demnächst, die Frage, ihr werdet ein Crumpy, kann ich vielleicht nicht schnell beantworten, aber gibt es demnächst auch eine Vorstellung mit neuen Multisite-Management? Das nehme ich auf jeden Fall mit. Für Thibaut in die Product Office Hour. Vielleicht nicht in die nächste, die ist ja in zwei Wochen, aber in die darauffolgende. Das nehme ich auf jeden Fall mit. So, dann möchte ich allen Zuhörern und Zuhörerinnen mich bedanken. Ich möchte mich auch bei dir bedanken, Jörn und Moritz, dass ihr diesen tollen Webinar quasi gehalten habt und uns da ein paar Informationen gegeben habt. Und freue mich auf das nächste Webinar. Ich wünsche euch allen noch einen schönen Tag. Tschüss. Danke, ebenso. Tschüss.