P&I hat seit geraumer Zeit das neue Produkt Loga-all-in auf den Markt gebracht. Damit geht P&I den Weg, den aktuell alle Software-Hersteller einschlagen. Den Weg in die Cloud. Allerdings ist es keine gemischte Cloud – also eine Wolke, in der mehrere Kunden auf einer Plattform sind – sondern eine private Cloud. Jeder Kunde ist insofern autonom.
Zu dem Produkt Loga-all-in wird es einen separaten Blogeintrag geben. In diesem Artikel fokussieren wir uns auf die Migration zu Loga-all-in.
Eine Softwaremigration zu Loga-all-in kann aus 3 Richtungen kommen:
- Kunde migriert von Loga on prem zu Loga-all-in
- Kunde migriert von Fremdsystem on-prem-Lösung zu Loga-all-in
- Kunde migriert von Loga oder Fremdsystem Cloud zu Loga-all-in.
Das Wort „on-prem-Lösung“ bedeutet, dass die Software eine eigene Installation ist, die auf dem eigenen Unternehmens-Servern läuft – also nicht im Outsourcing in einem Rechenzentrum. Der Unterschied von On-Prem-Lösungen zu Rechenzentrums-Lösungen ist u.a., dass man bei der on-prem-Lösung Zugriff auf die eigene Datenbank hat. Die gehört einem selber und da sind nur Daten des eigenen Unternehmens drauf. Bei der Rechenzentrums-Lösung teilt man sich die Plattform und hat keinen Zugriff auf die Datenbank bzw. auf den Server.
Nun verspricht P&I den Kunden eine super leichte Migration mit wenig Aufwand mit einer neuen „Technologie“. Die alte Migrationsstrategie, dass man mühsam Daten aus dem alten System ziehen und mithilfe Mapping Tabellen in das neue System einspielen muss, sei vorbei. P&I würde die Migration auf der Datenbankebene durchführen. Damit muss der Kunde keine „Templates“ mehr füllen und die Migration erfolgt komplett über den Dienstleister.
Stimmt das wirklich?
Betrachten wir das Szenario 1: Kunde migriert von Loga on prem zu Loga-All-in.
Tatsächlich erfolgt hier die Migration quasi von Datenbank zu Datenbank. Ein Befüllen von Templates bzw. ein Abziehen von Daten aus Kundensicht ist nicht notwendig.
Szenario 2: Kunde migriert von Fremdsystem on-prem zu Loga-all-in.
Hier wird es schon schwieriger. Ist das HR-System in einem ERP System integriert, wird es kaum klappen, da man ungern sein ERP System einfach P&I übergeben möchte. Neben dem, dass man dann über ein Datenvolumen sprechen würde, das mehrere Tage benötigt, um von A zu B portiert zu werden. Egal ob es ein SAP, ein IFS, Navision etc. wäre – hier müssten weiterhin Templates befüllt werden.
Ist das alte HR-System allerdings ein eigenständiges System wie Sage, Datev, Hansalog etc. dann kann die Datenbank übermittelt werden und ein Migrationsversuche von Datenbank zu Datenbank kann avisiert werden.
Szenario 3: Kunde migriert von Loga oder Fremdsystem aus der Cloud (Rechenzentrum) zu Loga-all-in
Da die „alte“ Anwendung im Rechenzentrum beim Dienstleister gehostet wird, ist es unmöglich an die Datenbank zu kommen – dies würde kein Dienstleister zulassen. In diesem Fall bleibt es beim Befüllen der Templates.
Fazit: Die neu gepriesene P&I Migrationsphilosophie klingt toll, ist allerdings nur für Kunden nutzbar, die von Loga on-prem oder einem alternativ selbst gehosteten HR-Abrechnungssystem aus kommen, das kein ERP System ist.
Die globale Cloud Strategie bringt zwar weniger Aufwand im Eigenbetrieb bei Hosting und Wartung, führt allerdings bei einer erneuten Migration zu Datenverlust und zu höherem Aufwand.
Ihr HR|next Team
Möchten Sie unsere Neuigkeiten nicht verpassen? Dann registrieren Sie sich für unseren Newsletter.