Inzwischen sind viele unserer Kunden auf speedikon C umgestiegen, oder dabei auf speedikon C umzusteigen. Neugewonnene Kunden haben direkt mit speedikon® C begonnen und sind somit von einem Umstieg nicht betroffen.
Vorweg muss man sagen, dass eine Migration nach speedikon® C kein Update o.ä. von speedikon FM darstellt. Auch eine 1:1 Datenübernahme hat sich als nicht sinnvoll erwiesen, denn dann würde man die Chance vergeben, sich das System nochmals von Grund auf anzusehen und zu eruieren, ob die bestehenden Prozesse noch aktuell sind bzw. ob sie mit neuen Methoden besser laufen könnten, als sie das heute vielleicht tun. Es sollte außerdem geprüft werden, ob alle vorhandenen Objekte und Merkmale gepflegt und relevant (und nicht redundant) sind bzw. ob es einen Pflegeprozess zu jedem Objekt bzw. Attribut gibt. Denn eine Übernahme der Daten nach C macht nur Sinn, wenn man sich auf die Daten verlassen kann. Selbstverständlich gibt es erprobte Tools, die diese Arbeit erleichtern aber eine richtige Migration ist ein guter Anlass alten Ballast zu entfernen und die neuen Möglichkeiten zu nutzen.
Ein speedikon® C Projekt muss nicht immer sofort in einem großen Migrationsprojekt münden, es ist auch möglich nur bestimmte Teile zu migrieren, um die neuen Möglichkeiten zu nutzen: Wenn jemand zum Beispiel Wert auf die Zeitschiene/Historie legt, können auch bestimmte Daten zyklisch nach speedikon® C geschrieben und upgedated werden, um sie dort auszuwerten; gleichzeitig bleibt aber die bestehende Datenpflege in speedikon FM erhalten.
Wie speedikon® C genutzt werden kann, um das Service Portal zu ersetzen, wenn zum Beispiel Java-Plugins nicht mehr verwendet werden dürfen, werden wir in einem nächsten Blogeintrag beleuchten.
Warum keine 1:1 Migration?
speedikon® C wurde komplett neu entwickelt, um die neuen technologischen Möglichkeiten richtig nutzen zu können. Sonst hätten wir ja nur eine neue Oberfläche über das vorhandene System ziehen müssen, was für uns als Hersteller mit Sicherheit schneller und preiswerter gewesen wäre. Aber dann hätten wir die gewünschte Flexibilität in den Datenstrukturen nicht erschaffen können und hätten mit denselben Nachteilen leben müssen wie bisher.
Zum Beispiel gibt es in speedikon FM immer Räume und Flächen. In 98% der bekannten Fälle war dies eine 1:1 Zuordnung, also hat jeder Kunde für die 2% der Fälle, in denen Abweichungen relevant waren, doppelte Daten halten müssen. Dieses Konzept haben wir eliminiert und nutzen nur Räume (einschließlich der Daten, die in speedikon FM an der Fläche stehen). Flächen werden dann angelegt, wenn es dafür einen triftigen Grund gibt, sie also zwingend anders behandelt werden müssen als Räume. Ein Beispiel wären Verkaufsflächen, mit denen ein Raum weiter unterteilt wird, um die Platzierung von Produktgruppen zu ermöglichen. Hiermit kann dann ausgewertet werden, was welche Fläche im Sortiment in Anspruch nimmt. Aber auch in diesem Fall haben nur ein geringer Teil der Räume Flächen, da für Verwaltungsgebäude dieses Konstrukt nicht gilt. Und jetzt liegt es natürlich an der Software, und deren Auswertungsmöglichkeiten, darauf Rücksicht zu nehmen und keine Flächen doppelt zu handhaben (das macht natürlich die Software und nicht der Nutzer).