Navision 4 -> NAV 2016 / Step 2.3.3 Test Field Relations

Hallo Kollegen, Freunde, Besucher,

wir sind gerade in einem Projekt an dem Update von Navision 4 zu NAV 2016 dran. Konkret stehe ich gerade noch am Anfang und teste erst einmal die Datenbank gemäß Upgrade Manual von MS.
Bisher habe ich bei Updates die Feld Relationen über die Datenbank-Prüfung durchlaufen lassen, hatte ein paar kritische Fehler die dafür gesorgt haben das der Test abbricht (Bsp.: Table Relation von Code 20 Feld auf Code 10 Feld). Nach dem Abschluss der Prüfung haben wir ja eine ansehnliche Log Datei in der alle Warnungen aufgeführt sind, die während des Tests aufgefallen sind. Im Manual ist an dieser Stelle ja nur lapidar die Rede von:
"If any error messages appear during the test, note their content and number. You must then decide whether or not these errors will affect the upgrade."
Soweit so gut. Im Zuge des Updates werden ja bspw. Dimensionen angefasst, also sollte man, soweit ich es bisher gemacht habe, schon darauf achten, das man diesen Fehlern Aufmerksamkeit schenkt und sie vor dem Update bereinigt. Soviel zum Vorspiel. :)

Jetzt habe ich aber eine Datenbank vor mir, bei welcher die Log Datei mittlerweile fast 700 MB groß ist und knapp 2,2 Millionen Warnungen ausspuckt, die quer durch alle Objekte gehen. Jetzt bin ich am hin und her überlegen ob es eigentlich einen Punkt gibt am dem man sagen muss: "Ok, die Datenbank ist in der Form nicht mit vertretbaren Aufwand update-fähig und wir gehen für die Datenmigration einen anderen Weg." Als Beispiel könnte ich mir vorstellen eine nackte NAV 2016 DB zu nehmen, die Individualprogrammierungen die vorhanden sind zu übernehmen bzw. zu aktualisieren und anschließend die Daten zu übernehmen, die für den Betrieb nötig sind. Im Grunde statt eines Update-Projektes eine Neu-Implementierung mit Ablösung der alten ERP-Lösung Navision 4 zu NAV 2016. Allerdings habe ich keine konkrete Idee, ab welchen Punkt diese "kritische Masse" erreicht ist, wo ich sagen kann wir können/sollten nicht den "Standard Weg" gehen. Ich hoffe ich konnte meinen Gedankengang einigermaßen verständlich aufzeigen. :)

Beste Grüße und vielen Dank schon einmal für eure Gedanken dazu,
Udo.

Hallo,

der Datenbanktest ist schön und gut, aber an den meisten Stellen aber leider hoffnungslos aufgebläht und oft irrelevant.

Du solltet die Meldungen bewerten, und schauen ob dort wirklich relevante Probleme vorhanden sind. Ein Lookup von einem Code 10 auf ein Code 20 ist nicht wirklich ein Problem, wenn in der LookupTabelle max. 10 Zeichen drin sind.

Ich persönlich habe diesen Test höchst selten gefahren, weil er selten bis gar keine relevanten Infos bringt (das in der Druckerauswahl ein Drucker steht, der auf dem testenden Rechner nicht vorhanden ist, ist nicht wirklich wichtig, weil er beim Update zu keinen Problemen führt.)

Gruß Fiddi

Nach meinen Erfahrungen ist dieser Datenbanktest eigentlich nutzlos.
Ja im Upgrade tauchen Fehler auf, wenn es Dimensionen mal gab, welche dann gelöscht wurden. Aber wen interessiert es? Dimensionen anlegen und weiter. Trial and error.

Jetzt ist der Schritt von Version 4 auf 2016 natürlich ein riesen Sprung.
Aber niemand verliert gern Daten (bringt eine Neuimplementierung mit sich).

Nach meinen Erfahrungen ist dieser Datenbanktest eigentlich nutzlos.

So direkt wollte ich das nicht sagen

Gruß Fiddi

also fiddi & m_schneider haben es im Grunde schon auf den Punkt gebracht.
Ich führe den Test grundsätzlich nicht mehr aus...dauert ja auch ne Weile, bis der durchgelaufen ist :)
Ihr habt ja dann auch eine Testphase, in der die Herausforderungen sowieso hochkommen würden, sofern es wirklich welche sind.

Nach meinen Erfahrungen ist dieser Datenbanktest eigentlich nutzlos.

Ja, funktional gebe ich dir da vollkommen Recht. Aber es war für mich bisher immer ein schöner Indiz bzgl. der "Gesundheit" der Datenbank mit der man grob abschätzen kann, was einen später erwarten wird. Aber dieses mal ist es sehr ausufernd und dabei bin ich auf den Gedanken gekommen gleich von vornherein zu sagen ich gehe gleich einen anderen Weg. Und da fehlt mir aktuell die greifbare Möglichkeit dies auch irgendwie "professionell" auszudrücken.
Zu sagen ich habe dein sehr ungutes Bauchgefühl wird dem Kunden nicht ganz reichen - Auch wenn ich ein charmantes Kerlchen bin.

Wir haben im Grunde ja eigentlich immer 2 Möglichkeiten: Es gibt ein NAV System und wir machen ein Update. Wir haben irgendein anderes ERP-System oder Excel und müssen dort auch Daten rein bringen. Und ich überlege aktuell, nur allein aufgrund des Bauchgefühls, gleich zu sagen die Datenbank ist ein "wirtschaftlicher Totalschaden" und wir fangen mit etwas anderem neu an was eben zufällig auch NAV heißt. Aber dafür fehlt mir eine quantifizierbare Größe um das auch ausdrücken zu können.

Ich danke euch erst mal für eure Gedanken hierzu. :)

du musst dir die Frage stellen, wie hoch der Mergeaufwand ist...von 4 auf 9.

nun solltest du prüfen, wie lange Ihr ca. für die Nachprogrammierung der Funktionalitäten, sowie der anschl. Datenübernahme braucht...
wenn dann dabei rauskommt, das der Merge viel teuerer als die Nachprogrammierung/DÜ ist, dann würde ich direkt sauber anfangen - da kommt dann deine Argumentation auch gut, wenn du sagst, die DB ist techn. nicht gesund.

Hallo,

die erste Frage, die man sich stellen muss, wie wichtig sind dem Kunden sein historischen Daten, wie groß ist die Datenbank, was hast du für Daten vor dir, sind dort Daten, die nicht gelöscht werden dürfen (Garantie-, Gesundheisdaten,..)?

Wenn dem Kunden seine historischen Daten wichtig sind, weil er z.B. eine Absatzplanung oder Umsatz Entwicklung sehen will. Er die Daten für eine Seriennummernverfolgung benötigt,... da kommst du um ein Update kaum herum. Egal welche Größe die DB hat.
Ist die DB groß, weil pro Jahr mal eben ein paar Mio. Posten generiert werden, hast du mit Rim auch schlechte Karten (Excel wird das Datenvolumen wohl nicht schaffen). Und die Arbeit herauszufinden, welche Daten du übernehmen müsstest hast du auch noch.

Daher wäre mein Versuch immer, die DB egal wie alt, mit einem Update zu versehen. (Hab das Problem gerade bei einem Kunden mit einer 4er-DB mit Webshop- Anbindung)

Gruß Fiddi

Naja, NAV ist ja in erster Instanz erstmal ein ERP-Produkt und kein BI Tool oder Archivsystem. Von daher erschließt sich mir immer nicht so ganz, warum alle immer alle historischen Daten sehen wollen.

Ich denke, ein Neustart ist immer auch ein guter Anlass, um über etablierte und teilweise veraltete Prozesse nachzudenken. Von 4 auf 2016 hat sich soviel getan, dass es durchaus Sinn machen würde alles nochmal zu hinterfragen. Dabei kommt oftmals heraus, dass viele Individualisierungen auch per Standard oder Standard-nah dargestellt werden können. Das reduziert sowohl Wartung und Support als auch die Kosten beim nächsten Update. Also durchaus Argumente, die für viele Kunden interessant sein dürften.

Hallo,

Naja, NAV ist ja in erster Instanz erstmal ein ERP-Produkt und kein BI Tool oder Archivsystem. Von daher erschließt sich mir immer nicht so ganz, warum alle immer alle historischen Daten sehen wollen.

Das sehe ich ein bisschen anders. Nav ist schon ein Archivsystem, und wenn nur fürs Finanzamt, die gerne per GDPDU Ihre Daten aus den letzten Jahren aus der Fibu hätten.
Wenn du das in zwei oder mehr Systemen haben wird das nur sehr schwer unter einen Hut zu bringen sein. (zu mal man nicht weiß ob man auf das alte System noch zugreifen kann (Betriebsystem)).

Natürlich ist NAV kein BI-Tool, aber ein BI- Tool muss irgendwo her seine Daten bekommen, damit es funktionieren kann.

Gruß Fiddi

NAV 4 ist mehr als 10 Jahre alt. Die alte Datenbank soll ja nicht gelöscht, sondern mit lesendem Zugriff weiter betrieben werden. GDPDU funktioniert dort dann auch noch immer.

Mit Archivsystem meinte ich eher, dass behördliche Vorgaben an die Archivierung von NAV überhaupt nicht erfüllt werden. Von daher kann man NAV nicht wirklich als Archivsystem verwenden. Dass immer ein gewisser Bedarf besteht historische Daten zu sehen, steht ja außer Frage. Aber warum das immer in einer Datenbank sein muss, erscheint mir zumindest fragwürdig.

Aber warum das immer in einer Datenbank sein muss, erscheint mir zumindest fragwürdig.

Nimm mal den Hersteller von Medizinprodukten, der anhand seiner Serien und Chargennummern in den Artikelposten genau nachvollziehen kann, wann er was wohin geliefert bzw. produziert hat.

Wo willst du denn die NAv4- DB lassen, willst du dafür extra eine VM erstellen, damit du da eine Welt schaffen kannst, wo man NAV 4 betreiben kann. (ein normaler NAV4- Client kann auf einem Win7- Rechner schon nicht mehr ausgeführt werden). Wie lange die Hersteller vom Virtualisierungslösungen alte System supporten kannst du auch nicht vorhersagen. Daher ist das Update in den meisten Fällen der am wenigsten aufwändige Weg, weiter auf die alten Daten zugreifen zu können.

Außerdem ist die einzige wesentlich Änderung seit NAV4, im Standard die Umstellung der Dimensionen, und die hättest du auch in NAV2009 durchführen müssen.
Das einige Funktionen aus Branchenlösungen jetzt evtl. schon im Standard enthalten Sind, ist ein Problem der entsprechenden NAV- Partner, die dafür aber eh eine Lösung brauchen.
Das neue Möglichkeiten für den Zugriff auf das NAV- System vorhanden sind (Webclient, Phoneapp, Webservices,...) ist auch schön, hat aber auch nicht wirklich einen Einfluss auf das Update.

Gruß Fiddi

Nimm mal den Hersteller von Medizinprodukten, der anhand seiner Serien und Chargennummern in den Artikelposten genau nachvollziehen kann, wann er was wohin geliefert bzw. produziert hat.

Wo willst du denn die NAv4- DB lassen, willst du dafür extra eine VM erstellen, damit du da eine Welt schaffen kannst, wo man NAV 4 betreiben kann. (ein normaler NAV4- Client kann auf einem Win7- Rechner schon nicht mehr ausgeführt werden). Wie lange die Hersteller vom Virtualisierungslösungen alte System supporten kannst du auch nicht vorhersagen. Daher ist das Update in den meisten Fällen der am wenigsten aufwändige Weg, weiter auf die alten Daten zugreifen zu können.

Und das kann er dann nicht in seinem Altsystem sehen, was er wann produziert und wo hingeliefert hat? Der Betrieb dessen ist doch ein völlig anderes Problem. Wofür es im übrigen auch unterschiedlichste Lösungen gibt (z.B. technisches Update auf 2009 CC). Guck mal alleine, wieviele Firmen heute noch AS400 einsetzen. Sind das jetzt alles Hochrisiko-Firmen, weil die virtualisieren oder irgendwoher alte Hardware beziehen müssen? Weil alte Motoren nicht mit den hohen Oktanzahlen zurechtkommen, wirft man ja auch nicht die Oldtimer weg, sondern überlegt sich Lösungen.

Außerdem ist die einzige wesentlich Änderung seit NAV4, im Standard die Umstellung der Dimensionen, und die hättest du auch in NAV2009 durchführen müssen.
Das einige Funktionen aus Branchenlösungen jetzt evtl. schon im Standard enthalten Sind, ist ein Problem der entsprechenden NAV- Partner, die dafür aber eh eine Lösung brauchen.
Das neue Möglichkeiten für den Zugriff auf das NAV- System vorhanden sind (Webclient, Phoneapp, Webservices,...) ist auch schön, hat aber auch nicht wirklich einen Einfluss auf das Update.

Ich weiß nicht. Das ist mir etwas zu vereinfacht dargestellt. Der ganze Bereich Service wurde z.B. umgebaut. Die vielen Verbesserungen in einzelnen Funktionen (auch um Bugs zu beheben z.B. bei der Lagerwertberechnung). Und so weiter... das kann man ja nicht einfach ignorieren. Das sind Dinge, die wurden früher oft im Implementierungsprojekt per individueller Anpassung gelöst. Dementsprechend sollten sie beim Update neu bewertet werden, damit man gucken kann, was man überhaupt noch braucht. Ein stumpfes Hochziehen von jetzt nicht mehr benötigten Anpassungen macht nur die Taschen der Partner voll, hilft dem Kunden aber nur bedingt. Dann brauchen wir uns auch nicht zu wundern, warum ein so schlechtes Bild von uns herrscht.

Wofür es im übrigen auch unterschiedlichste Lösungen gibt (z.B. technisches Update auf 2009 CC)

Selbst NAV 2015 zickt unter Win 10 rum, wenn es kein aktuelles Build ist. Deshalb meine Meinung: Keiner weiß was in 5 oder 10 Jahren ist, deshalb aktuell halten.

Ein stumpfes Hochziehen von jetzt nicht mehr benötigten Anpassungen macht nur die Taschen der Partner voll, hilft dem Kunden aber nur bedingt. Dann brauchen wir uns auch nicht zu wundern, warum ein so schlechtes Bild von uns herrscht.

Da gebe ich dir Vollkommen recht.

Die erste Aktion bei einem Update sollte sein,. Aufräumen, Aufräumen,....

Teilweise hat sich über die Jahre dermaßen viel Schrott in den NAV- DBs angesammelt (Felder, Objekte, Funktionen,..) von denen heute kaum noch einer weiß woher und warum sie im NAV drin sind.

Gruß Fiddi