Business Central – Das NAV Upgrade Dilemma

Obwohl es keine gesicherten Zahlen gibt, ist es evident, dass die Mehrzahl der Navision / Dynamics NAV Versionen sich auf einem Versionsstand irgendwo zwischen 2009 und 2015 bewegt.

Upgrade Dilemma

Das NAV Upgrade Dilemma

Obwohl es keine gesicherten Zahlen gibt, ist es evident, dass sich die Mehrzahl der Navision / Dynamics NAV Versionen auf einem Versionsstand irgendwo zwischen 2009 und 2015 bewegt. Dies ist auch nicht weiter verwunderlich, da ein Upgrade von Versionen vor Business Central gewöhnlich extrem aufwendig war (und ist), da jede einzelne Anpassung, egal ob individuell oder über ein Modul eines ISVs, manuell auf die nächsthöhere Version nachgezogen werden musste. Für die Nicht-Techniker unter Ihnen habe ich hier eine kleine Grafik gemacht, die dieses Problem stark vereinfacht zeigt.

NAV Upgrades


Mit der Einführung von Business Central gibt es eine vollkommen neue Systematik, die solche Probleme in der Zukunft gar nicht erst entstehen lässt. Auch hierzu eine stark vereinfachte Grafik.

BC Upgrade

Seit der Version 15 von Business Central kann der Original Code (die “Basis”) nicht mehr verändert werden und alle Anpassungen müssen in separate Programmteile, so genannte “Extensions”, ausgelagert werden. Über in der Basis vorhandene Events wird dann eine solche Extension angesprochen und liefert z. B. ein berechnetes Ergebnis für ein originales oder ein neu erstelltes Feld zurück. Bei einem Upgrade kann somit die Upgrade Routine davon ausgehen, dass der Originalcode so geblieben ist wie er war und kann daher alles das machen, was im Labor vorherbestimmt war. Die Events sind nach wie vor vorhanden und somit wird auch die “alte” Extension in der neuen Version wieder ausgeführt.

Sollte sich wider Erwarten eine Extension doch einmal mit einem Upgrade beißen, so kann diese sehr einfach deinstalliert, geändert und wieder neu installiert werden. Dafür hat Microsoft in den SaaS Versionen die Sandboxen und eine Zeitschiene für Upgrades geschaffen – Sie haben grundsätzlich 60 Tage Zeit, eine neue Version in einer Sandbox zu testen und ggf. Extensions zu ändern.

Aber auch wenn jetzt alles schön und neu und anders ist, stellt das natürlich alle Unternehmen mit den oben erwähnten Versionen (bis Business Central 14) nach wie vor vor ein Riesenproblem, für das es prinzipiell 4 Lösungswege gibt – alle haben Vor- und Nachteile und alle kosten Geld. Die Frage, die Sie beantworten müssen, lautet: Was ist das Beste für mich? Und genau dazu wollen wir Ihnen eine kleine Hilfestellung geben.

Weg 1 – Nichtstun

Oder mit anderen Worten: Aussitzen. Das ist weniger lächerlich als es klingt, wenn man sich die vielen AS400 Lösungen ansieht, die heute noch im Einsatz sind. Es wird immer Anbieter geben, die genau diese Nische bedienen und so ein Funktionieren für zumindest weitere 10 bis 15 Jahre garantieren können. Und nachdem Microsoft auch bis dato sehr schleppend mit NAV Updates reagiert hat, ist ein Wegfall derselben durchaus verschmerzbar.

Größere Sicherheitslücken sind nicht zu befürchten, da es sich bei diesen Lösungen ausschließlich um “On Premises” Versionen handelt und daher eine Öffnung nach außen ohnehin nur über abgesicherte Firmennetzwerke möglich ist. Auch massive gesetzliche Änderungen wird es vermutlich kaum geben und wenn doch, dann ist NAV gerade wegen der bekannten Flexibilität weit besser aufgestellt als viele andere Lösungen am Markt.

Der Nachteil bei diesem Weg ist, dass natürlich Dienstleistungen im Laufe der Jahre immer teurer werden, da die Anzahl der Fachkräfte abnimmt und die Dienstleister wissen, dass Ihre Kunden keine Wahl haben. Oder salopp auf Englisch: “They have your balls in a vice”.

Weg 2 – Traditionelles Upgrade

Ein traditionelles Update bedeutet, dass Sie alle Anpassungen, alle Einstellungen und alle historischen Daten in die aktuelle Version von Business Central mitnehmen.

Leider heißt das aber auch, dass alle diese Anpassungen von “in line” (also im Code integriert wie oben gezeigt) in Extensions umgesetzt / neu programmiert werden müssen – wenn das überhaupt möglich ist. Auch sämtliche Datenstrukturen müssen angepasst werden, da ja Datenerweiterungen (neue Felder) nicht mehr in den Ursprungstabellen, sondern in neuen, verbundenen Tabellen abgelegt werden.

Als wenn das noch nicht genug wäre – bei sehr alten NAV Versionen (< 2013) müssen sogar 3 Updates durchgeführt werden – von Ihrer Version auf 2013, von 2013 auf 2018 bzw. BC 14 und erst dann auf die aktuelle Version von Business Central. Lesen Sie sich dazu bitte diesen und diesen Artikel direkt bei Microsoft durch (nur in Englisch verfügbar).
Dass das unter Umständen extrem teuer werden kann, versteht sich glaube ich von selbst. Nichtsdestotrotz hier noch eine kurze Liste an Voraussetzungen bzw. von Vor- und Nachteilen dieser Lösung:

Gute Voraussetzungen, wenn:
  • Ihre Lösung jünger als 2013 ist
  • Sie keine oder nur wenige Anpassungen haben
  • Sie Ihren Daten vertrauen
  • Sie mit der aktuellen Abwicklung bzw. der Abbildung Ihrer Prozesse in NAV sehr zufrieden sind
  • (Bei einem Umstieg auf SaaS) die Datenmengen nicht zu groß sind (obwohl sich das mit dem 1.7.2021 zum Vorteil verändern wird)

Pros:

  • Sie haben Ihre gesamte Historie weiterhin direkt in der Applikation zur Verfügung.
  • Es ist nur wenig Beratungsaufwand notwendig, die Hauptlast liegt bei der Entwicklung und in der Datenmigration.
  • Funktionen und Einstellungen bleiben so wie sie waren, der Umgewöhnungsaufwand für die Benutzer hält sich in Grenzen, wenn man von der, nun verpflichtenden, Weboberfläche absieht.

Cons:

  • Zeitaufwendig und daher (extrem) teuer (abhängig von den Anpassungen)
  • Kein oder kaum Gewinn durch neue Technologien oder Funktionen
  • Parallele oder störende Funktionen durch mittlerweile hinzugekommene Features
  • Wegen möglicherweise fehlender Events oder anderer technischer Gegebenheiten kann es sein, dass nicht alle Anpassungen 1:1 in der neuen Entwicklungsumgebung umgesetzt werden können
  • Längere Antwortzeiten durch große Datenbestände

Weg 3 – Bedingter Neustart

In Ermangelung eines guten Begriffs nenne ich diesen Weg “bedingten Neustart”, weil Sie hier alle Anpassungen vorerst einmal “wegwerfen” aber Daten und Einrichtungen behalten. Dies bedeutet wesentlich weniger Entwicklungsaufwand aber dafür mehr Investition in Beratung und Migration.

Aus meiner Sicht ist eine solche hybride Lösung nur in ganz speziellen Fällen angebracht und auch nur dann, wenn es wenige Anpassungen, speziell in den Datenstrukturen, gibt. Microsoft und andere Provider bieten eine ganze Reihe von Lösungen an, um aktuelle Daten mit historischen ohne Bruchstellen zu verbinden und so weiterhin Vergleiche und Auswertungen zu ermöglichen.

Der Beratungsaufwand wird sicherlich größer sein als bei einem traditionellen Upgrade, da ja hier der Wegfall der Anpassungen im Standard durch (teilweise) neue Anpassungen oder Work-Arounds mit Standardfunktionen kompensiert werden muss.

Gute Voraussetzungen, wenn:
  • Ihre Lösung jünger als 2013 ist
  • Sie keine oder nur wenige Anpassungen haben
  • Sie Ihren Daten vertrauen
  • Sie mit der aktuellen Abwicklung bzw. der Abbildung Ihrer Prozesse in NAV zufrieden sind

Pros:

  • Ihre Einstellungen müssen nicht neu überdacht und gemacht werden
  • Sämtliche historischen Daten bleiben im System vorhanden
  • Der Entwicklungsaufwand ist weit geringer als bei einem traditionellen Update

Cons:

  • Ein großer Datenbestand führt unter Umständen zu verzögerten Antwortzeiten
  • Der Ersatz von historischen Anpassungen durch neue Funktionen im Standard muss geprüft, erklärt und geschult werden
  • Einige Funktionen werden durch den Wegfall der Anpassungen nicht mehr zur Verfügung stehen
  • Bedingt durch geänderte Prozesse und eine neue Oberfläche ist der Schulungsaufwand für Benutzer höher als bei einem traditionellen Upgrade

Weg 4 – Neustart

Bei einem Neustart (das negativ besetzte Wort lautet “Re-Implementierung”) behandeln Sie Ihre aktuelle NAV Version wie irgendeine beliebige ERP Installation und setzen ein neues Implementierungsprojekt auf. Dass die neue Software zufälligerweise ein direkter Nachkomme Ihrer bisherigen ist, müssen sie gedanklich vernachlässigen.

Allerdings ist ein Neustart mit Business Central natürlich wesentlich weniger aufwendig als mit jeder anderen ERP Software. Nicht nur dass die grundsätzlichen Funktionen gleich sind (wenn auch möglicherweise stark erweitert), auch die Datenstrukturen können über weite Strecken eins zu eins übernommen werden. Das Berechtigungsschema, die von mir so geliebten Buch.-Blätter, die Lagerorte, die gesteuerte Einlagerung, alles bleibt im Prinzip so wie es ist und der Einarbeitungsaufwand für Benutzer ist (mit Ausnahme jener für die Weboberfläche) minimal.

Natürlich ergibt sich ein gewisser Beratungsaufwand, wie bereits oben erwähnt müssen ja weggefallene Anpassungen entweder durch Standardfunktionen kompensiert werden oder es müssen eben Extensions konzipiert und umgesetzt werden. Man darf allerdings nicht vergessen, dass seit der Ersteinführung Ihrer Software möglicherweise 10 oder sogar 15 Jahre vergangen sind und daher viele Dinge, die damals wichtig waren, heute nicht mehr benutzt werden und das andere Prozesse und Prioritäten in den Vordergrund getreten sind.

Gute Voraussetzungen, wenn:
  • Sie eine (sehr) alte NAV Version haben oder der Wunsch nach einem Neustart vorhanden ist
  • Sie viele oder komplexe Anpassungen haben
  • Sie nicht genutzte Anpassungen haben
  • Es signifikante Änderungen des Umfelds (andere Produkte, zusätzliche Business Units, geografische Änderungen, neuer Besitzer etc.) gibt oder gab
  • Eine Datenbereinigung notwendig ist

Pros:

  • Nervige oder umständliche Prozesse können effizienter gestaltet werden
  • Teure Zusatzprodukte fallen weg
  • Datenfriedhof wird bereinigt
  • Kontenplan, Buchungsgruppen, Bewertungsmethoden etc. können den neuen Bedürfnissen angepasst werden

Cons:

  • Ein neues Projekt mit alten Namen ist intern schwer verkäuflich
  • Der externe Beratungsaufwand und die interne Beteiligung sind sicher höher als bei den anderen, oben angesprochenen Lösungen
  • Bei jedem SW Implementierungsprojekt gibt es Risken, nicht umsonst sagt man “Never change a running Software…”

Conclusio

Leider kann man bei keinem dieser vorgeschlagenen Wege eine eindeutige Aussage dafür oder dagegen treffen, ohne die konkrete Kundensituation zu kennen. Es empfiehlt sich daher, bereits für Machbarkeitsstudie und Planung ein entsprechendes Budget bereitzustellen, der dafür verwendete Betrag kann auf jeden Fall im eigentlichen Projekt eingespart werden.

Und wie so oft gibt es auch hier nicht nur schwarz oder weiß, sondern auch alle Grautöne dazwischen. Es ist also durchaus vorstellbar, dass Sie einen Teil ihrer Applikation durch ein anderes Produkt ablösen und den Rest dann Schritt für Schritt modernisieren.

Selbstverständlich können Sie anstelle eines Upgrades auch den Umstieg auf eine Lösung eines anderen Anbieters ins Auge fassen. Hierbei verlieren Sie zwar die gewohnte Arbeitsumgebung sowie die begriffliche Welt komplett, gewinnen aber möglicherweise Funktionalität und Bedienungsfreundlichkeit. Allerdings ist davon auszugehen, dass der Beratungsaufwand wesentlich höher ist als bei einem Neustart / Re-Implementierung.

Nachsatz: Herzlichen Dank an Ryan Pollyniak der dieses komplexe Thema sehr verständlich und vor allem entwaffnend ehrlich aufbereitet hat. https://www.youtube.com/watch?v=q0cDfE-FKRM&t=455s ab 1:50


Disclaimer: Wir wissen viel aber nicht alles und Fehler können passieren. Wenn Sie daher einen solchen finden – schreiben Sie uns bitte.