Hallo Forum!

Wir überlegen von BAAN IV auf BAAN LN umzusteigen. Gibt es hier in diesem Forum User die so ein Projekt bereits hinter sich haben? Erfahrungsberichte oder Dokumentation die den Ablauf der Migration beschreiben? Uns interessieren sowohl technische und als auch inhaltliche Erfahrungen mit dem Umstieg.

Viele Grüsse
:)

Hallo!

Kann leider nicht mit Erfahrungen aufwarten, mich würde aber mal interessieren warum Ihr umsteigen wollt. Gibt es etwas in LN was entscheidend besser gelöst ist als in IV für Eure Bedürfnisse? Wenn ja, was genau ist es.

Gruss

Martin

Vielleicht ein paar Hinweise aus den Erfahrungen, die ich bislang in solchen Umstiegsprojekten sammeln konnte:

Es gibt zwei grundlegende Denkansätze: Der erste ist ein sehr technischer: Baan IV nehmen, Konvertierungstools von SSA anwerfen, Anpassungen portieren und in LN unter neuer Oberfläche im Grunde weitermachen wie bisher. Der zweite: SSA LN gründlich anschauen, überlegen, welche Funktionen man neu nutzen möchte, im Grunde fast eine Neuimplementierung aufsetzen, und sich am Ende über die Datenkonvertierung und eventuell benötigte neue Anpassungen Gedanken machen.

Die Unterschiede zwischen Baan IV und LN sind schon ziemlich groß, LN ist weitaus mächtiger. Gewinn aus der Umstellung (außer einer neuen Oberfläche) zieht man vor allem dann, wenn man diese neuen Funktionen und Prozesse nutzt, und nicht alte Baan-IV-Krücken 1:1 überträgt. Speziell die Abläufe in Versand und Lager, die Nutzung von kundenspezifischen/Standardartikeln sowie die Kostenarten/Kostenträgerrechnung würde ich mal einer gründlichen Prüfung unterziehen, falls es sich um eine Multisite-Installation handelt, wäre auch da genauer hinzusehen (LN unterstützt das deutlich besser).

Bei Anpassungen: Den Umstellungsaufwand nicht unterschätzen; alle Reports (externe wie Rechnungen etc., und interne Auswertungen) müssen komplett neu gemacht werden, aus Baan IV hier irgendwas zu migrieren ist so gut wie nicht machbar, weil sich die wichtigsten Tabellennamen (Artikelstamm, Handelspartnerstamm, Verkaufs- und Einkaufsdaten) geändert haben. Empfehlen würde ich auch, mit SSA eine Vereinbarung über die Verfügbarkeit aller Source-Codes zu treffen: Ohne die sind Anpassungen wesentlich schwerer durchzuführen, weil die meiste Funktionalität nicht mehr in der Session, sondern in einer Unmenge an DLLs steckt. Die Stelle, an der man ggf. anpassen und einen Sourcecode anfordern muss, findet man ohne *alle* Sourcecodes gar nicht erst.

Unschöne Neuerungen in LN sind ein überaus merkwürdiges Handling der Adressen (übermäßig kompliziert) und - je nach Größe des Anwenders - die Aufsplittung von Artikelstamm und Handelsparnterstamm in unterschiedliche Funktionseinheiten: Man sieht nicht mehr alles in einer Maske. Auf der anderen Seite gibt es eine Reihe neuer Maskentypen, die einem als Anwender das Leben sehr erleichtern. Nicht vergessen werden sollte im Projekt außerdem, dass Statistiken und Berichtswesen aus der Fibu so umgebaut sind, dass sie nur noch mit einem externen Berichtsgenerator sinnvoll nutzbar sind.

Wenn man das ganze nicht als reine IT-Geschichte sieht, alle Abteilungen einbezieht und sich die Zeit nimmt, die so ein Projekt halt braucht, lohnt sich die Umstellung in meinen Augen durchaus: Baan IV ist mittlerweile zehn Jahre alt, und den Unterschied merkt man.


Beste Grüße,
Hoffe, das hilft etwas
Ulrich Fuchs

Unschöne Neuerungen in LN sind ein überaus merkwürdiges Handling der Adressen (übermäßig kompliziert)
Ist es wahr das Adressen nicht mehr fest den Handelspartnern zugeordnet sind sind? Ich meine sowas mal gesehen zu haben...

Ja - jede Adresse im System (egal ob für einen Lieferanten, Mitarbeiter oder das eigene Lager) findet sich in einem globalen Adressstamm wieder, Handelspartnerstamm etc. verweisen dann nur auf diesen Adresscode.

Beste Grüße
Ulrich Fuchs

Meiner Meinung nach ein "tödliches" Feature - oder wie verhindere ich das eine falsche Adresse für einen Kundenauftrag verwendet wird?

Sollte es keinerlei Einschränkung in der Verwendung der Adressen geben, wäre das für uns ein klares und gewichtiges Argument gegen LN.

Gruss

Martin Jung

Die Adressen sind bei uns auch ein ganz heißes Thema. Zur Zeit haben wir ca. 200.000 (+/-) im System. Davon die Hälfte einmalige und täglich kommen zig. tausend hinzu. Gleichzeitig fliegen auch genausoviele wieder raus (die Aufträge sind erledigt und werden gelöscht). Dazu gibt es bei uns einen großen Unterschied zwischen Rechnungs (Post) und normalen Lieferadressen. Die Rechnungsadressen sind im Gegensatz zu den Lieferadressen überprüft und nicht jeder darf sie ändern... (einmalige Postadressen haben wir nicht).
Bisher konnte mir von SSA noch niemand sagen wie das in LN vernünftig gehen soll.

Gruß
Christof Seidel

Ich sehe im Moment zwei Ansätze für die Adressgeschichte: Der eine ist, nur in Handelspartnern zu denken und die Adressen quasi nur im Hintergrund mitlaufen zu lassen. LN unterstützt bswp. "Warenempfänger je Kunde", das löst das Problem, dass Herr Jung anspricht; Die Trennung des Handelspartnerstamms in Rechnungsempfänger und Warenempfänger andererseits löst das Problem von Herrn Seidel - wenn man die allgemeine Adressverwaltung nicht allen Benutzern freigibt und sie nur die Adresse des Rechnungsempfängers oder Warenempfängers direkt über den jeweiligen Stammsatz aufrufen können (es gibt da einen Punkt im Menü Zusatzoptionen respektive einen Button). Oder man macht Nummernkreise für die einzelnen Adresstypen, und schränkt die Bearbeitbarkeit dann über das Rechtemanagement im Tools-Bereich darüber ein. Ist für Herrn Seidel vielleicht der bessere Ansatz, ein Programm "nicht benutzte Adressen löschen" gibt es, ein "nicht benutzte Handelspartner löschen" nicht.

Der andere Ansatz, der allerdings bedeuted, auf die volle Länge der Handelspartnernummer zu verzichten, besteht darin, ein Codierungsschema für Adressen aufzubauen, dass aus Handelspartnernummer und Folgenummer besteht, allerdings gibt es dann keine Möglichkeit, über die Software irgendwelche Restriktionsprüfungen zu machen.

Exemplarisch zeigt das Beispiel aber nochmal meine Kernaussage: Von Baan IV nach LN6.1 ändert sich nicht nur die Versionsnummer und der Softwarename, sondern man muss sich wieder Gedanken über Prozesse und Stammdaten machen. Aber wenn man das tut, macht das Arbeiten mit LN viel Spaß, hier sollte man für die Jungs und Mädels von Baan/Invensys/SSA ein Lob loslassen: da ist, obwohl an der einen oder anderen Stelle vielleicht mal zu kurz gedacht wurde, ein feines Stück Software entstanden.

Ulrich Fuchs

Hallo!

Kann leider nicht mit Erfahrungen aufwarten, mich würde aber mal interessieren warum Ihr umsteigen wollt. Gibt es etwas in LN was entscheidend besser gelöst ist als in IV für Eure Bedürfnisse? Wenn ja, was genau ist es.

Gruss

Martin

Es geht uns im Prinzip "fast" um eine Neuimplementierung, da die Einführung von Baan IV vor ca. 7 Jahren recht unstrukturiert verlaufen ist. Deshalb möchten wir die Chance auf eine durchdachtere Struktur bei einem Umstieg auf LN nutzen.

Hallo Ulrich Fuchs,

vielen Dank für die ausführliche Antwort mit einigen Ratschlägen. Wir denken eher an die 2. Variante, die praktisch in Richtung einer Neuimplementierung geht.

Die notwendige Zeit für den Umstieg müssen wir uns einräumen, wir planen derzeit mit 6-9 Monaten, schaun mer mal....