Warum auf BC 14 upgraden?

Dieser Artikel ist eine sehr freie Übersetzung dieses Beitrages: Seven Reasons You Need to Upgrade Business Central to 14

Version BC14 Umstieg

Warum auf BC 14 upgraden?

Dieser Artikel ist eine sehr freie Übersetzung dieses Beitrages

Eine der besten Eigenschaften von Microsoft Dynamics NAV ist und war die (relativ) leichte Anpassbarkeit exakt auf die Anforderungen Ihres Unternehmens. Zusätzlich gibt es Add-on-Produkte in Hülle und Fülle, was zu Effizienzgewinnen und Wettbewerbsvorteilen führt.

Dies ändert sich auch mit Business Central nicht. Was sich jedoch geändert hat, ist die Art und Weise, wie diese Anpassungen und Add-ons mit dem Basiscode des Produkts interagieren. Vorbei sind die Zeiten, in denen die Objekte direkt im Code geändert wurden (und damit Upgrades de facto zu einer Neuinstallation gemacht haben), jetzt gibt es mit AL ein modernes Open Source Werkzeug mit dem über Visual Studio Code (de)installierbare Anwendungen erstellt werden können.

Warum wird jedoch von vielen ein Umstieg auf BC 14 statt auf die neueste Version empfohlen?

Im letzten Jahr gab es einen Ansturm auf den Umstieg auf Business Central 14 (BC 14), was zum Teil auf Microsofts N-2-Politik zurückzuführen war. Diese erlaubte den Erwerb von Lizenzen nur für zwei Versionen vor der aktuellen Version. Mit dem Erscheinen von BC 17 im Herbst 2020 wäre somit BC 14 nicht mehr als Upgrademöglichkeit zur Verfügung gestanden.

Microsoft ist jedoch kürzlich von dieser Politik abgewichen, als sie ankündigten, dass NAV-Kunden mit aufrechtem Wartungsvertrag bis zur Herbstversion 2021 (=BC 19) auf BC 14 umsteigen können.

Aber die Frage bleibt natürlich: Wenn Sie schon upgraden wollen, warum sollten Sie dann nicht gleich auf BC 17 bzw. die dann gerade neueste Version gehen? Warum stattdessen ein „Downgrade“ zu höheren Kosten durchführen? Hier sind fünf mögliche Gründe.

Grund Nr. 1: Zwei Oberflächen

BC14 ist die letzte Version, die sowohl den bekannten Role Tailored Client als auch den neuen Modern Client unterstützt. Ab BC 15 ist nur mehr zweiterer verfügbar. Diese Oberfläche ist modern, mit vereinfachten, App-ähnlichen Bildschirmen aber eine dramatische Umgewöhnung für Benutzer. Über die parallele Verwendung beider Oberflächen können Benutzer Schritt für Schritt ‚umgewöhnt‘ werden ohne gleich ins kalte Wasser geworfen zu werden.

Grund Nr. 2: Längere Unterstützung für BC 14

Microsofts Fahrplan besagt, dass BC 14 bis 2023 unterstützt werden wird. Dies ist wesentlich länger als die Standard N-2-Politik, die nur die aktuelle Version und die letzten beiden veröffentlichten Versionen umfasst. Bei einem Veröffentlichungszyklus von 6 Monaten haben Sie somit nur ein 18-Monatsfenster in dem Ihre Version vom Hersteller unterstützt wird. Ihr Partner kann diese Zeit selbstverständlich ausdehnen.

Grund Nr. 3: Der Umtausch von Benutzern 1:3

Sie können bei einem Umstieg auf BC 14 Ihre concurrent Benutzer im Verhältnis 1:3 auf named Benutzer umtauschen (zumindest jene die Sie vor dem 1.10.2018 gekauft haben).

Grund Nr. 4: Anpassungen

Wenn Sie über eine sehr stark angepasste Version von NAV verfügen, dann haben Sie vermutlich noch nie ein Upgrade auf eine höhere Version durchgeführt. Der Grund dahinter liegt in dem enormen Aufwand der notwendig ist, um jede einzelne Erweiterung in den Code der höheren Version zu integrieren.

Bei einem Umstieg von NAV auf Business Central müssen alle Erweiterungen in die neue Programmiersprache AL umgesetzt werden. Neben den unvermeidbaren Kosten birgt dies zusätzlich die Gefahr von Programmierfehlern und Verständnisproblemen.

Daher ist es vernünftiger (weil der Zwang ja da ist) zuerst eine problemlose weil bekannte Integration in den neuen „alten“ Code durchzuführen und dann Stück für Stück in die neue Programmiersprache umzusetzen. BC14 ist die einzige Version wo dies so durchgeführt werden kann. Zusätzlich können Sie Aufwand und Kosten über eine längere Zeitspanne verteilen.

Bei allen höheren Versionen müssen Sie auf einen Schlag alle Erweiterungen sofort auf AL umsetzen (allerdings ohne vorherige Integration) und Sie gefährden damit den reibungslosen Betrieb Ihrer Applikation.

Hinweis: Dieser Punkt kann zweifach interpretiert werden. Ja, es ist einfacher und risikoloser es so zu machen wie oben beschrieben aber es ist auch zumindest ein Drittel teurer als der ‚all in‘ Ansatz. Wie immer muss in diesem Fall das Kosten-Risiko Verhältnis genau analysiert werden.

Grund Nr. 5: ISV (Independent Software Vendor)-Add-Ons

Wenn sie Zusatzpakete unabhängiger Hersteller einsetzen, dann müssen sie mit einem Upgrade auf Versionen nach BC 14 warten, bis also der Hersteller sein Produkt im neuen Code fertiggestellt hat. Dies ist für viele Hersteller ein großes Problem dessen Lösung entsprechend lange dauern wird. Mit einem Umstieg auf BC 14 Uhr haben Sie die Möglichkeit, das Zusatzprodukt weiter im alten Code einzusetzen und Sie können somit quasi auf den Hersteller warten.

Ich persönlich halte einen Umstieg auf BC 14 Uhr nur dann für sinnvoll, wenn es sich wirklich um eine große Lösung mit vielen Anpassungen handelt. Hier ist das Risiko von Problemen die bei der Umsetzung von altem auf neuen Code entstehen doch ein sehr großes und zusätzlich wird Zeit benötigt, um Prozesse zu überdenken und gegebenenfalls zu straffen. Auch das kann natürlich großflächige Änderungen in den Anpassungen zur Folge haben.

Bei kleineren Applikationen mit wenigen oder nicht weitreichenden Anpassungen überwiegt der Vorteil der neueren Versionen (BC 14 ist bestenfalls suboptimal). Zusätzlich ist natürlich auch noch der Kostenfaktor zu bedenken weil man im oben geschilderten Fall die Anpassungen auf jeden Fall zweimal angreifen muss.

Mehr zu diesem Thema siehe auch hier