Best Practices: Doku IST ERP-Landschaft - Scoping Workshop

Hallo zusammen,

bei uns steht demnächst ein Scoping Workshop mit unserem Microsoft-Partner an, um die Migration auf Dynamics 365 Business Central vorzubereiten und den Projektumfang zu definieren.

Unsere aktuelle IST-Landschaft ist derzeit eine hybride Umgebung:

• Microsoft Dynamics NAV 2013 R2: Steuert aktuell hauptsächlich unsere Produktionsprozesse.

• Dynamics 365 Business Central: Nutzen wir bereits für Finanzbuchhaltung, Personalmanagement und Zeitwirtschaft.

Um unserem Partner für den Workshop eine optimale Grundlage zu liefern, erstelle ich derzeit eine umfassende Dokumentation unserer IST-Systemlandschaft.

Mein bisheriger Ansatz (Funktionale Anwendungslandschaft / Application Map):

1. ERP-Module & Customizing:

• In NAV: Genaue Unterscheidung zwischen NAV-Standard, der genutzten Branchenlösung unseres Partners sowie unseren Eigenentwicklungen (spezifische Module & Funktionen in der Produktion)

• In BC: Erfassung der aktuell genutzten In-System Add-Ons / Extensions.

2. Umsysteme & Schnittstellen:

• Erfassung aller relevanten Drittsysteme (z. B. Subsysteme, BDE/MDE, Maschinenanbindungen).

• Visuelle Verknüpfung: Darstellung der Interaktion mit NAV/BC über Verbindungspfeile (zunächst High-Level, ohne tiefere technische API-Spezifikation).

Meine Fragen an die Community & erfahrene Partner:

• Dokumentations-Ansatz & Vollständigkeit: Würdet ihr als Community bzw. Partner ebenfalls diesen funktionalen Ansatz für den Einstieg wählen, oder fehlen auf dieser Ebene noch wesentliche Informationen, die ich für den Scoping Workshop unbedingt ergänzen sollte?

• Schnittstellen-Erfassung: Reicht die funktionale Darstellung (Verbindungspfeile zwischen den Systemen) für die Erstbewertung durch den Dienstleister aus, wenn man sich technisch mit den genauen API-Technologien (wie OData, REST, SQL-Zugriffe) selbst nicht im Detail auskennt?

• Tipps & Vorlagen: Hat jemand Tipps, Erfahrungswerte oder erprobte Vorlagen für die Aufbereitung einer solchen IST-ERP-Landschaft, um dem Partner die beste Arbeitsgrundlage für das Migrationsprojekt zu liefern?

Ich freue mich sehr über euer Feedback und Ratschläge aus der Praxis.

Vielen Dank und beste Grüße,
Sulim Litaev

Hallo,

grundsätzlich sieht das schon gut aus.

Frage: Ist das euer bisheriger Partner oder ein neuer? Falls es euer bisheriger Partner ist, sollte der eigentlich schon wissen was zu tun ist, er hat ja Zugriff auf den Quellcode, und er sollte euch kennen.

Wenn man euren Quellcode mit dem einer Standardversion vergleicht, dann sieht man welche Änderungen eingebaut wurden. Man muss dann nur noch heraus finden warum sie gemacht wurden.

Die Anwender zu befragen ist da meistens wenig hilfreich, weil die Dinge oft als Standard voraussetzten, und dann vermeintlich unwichtige Dinge nicht erzählen. Außerdem wurden (sollte eigentlich heute auch noch der Fall sein) die Systeme häufig soweit angepasst, das die Anwender gar nicht mitbekommen was im Hintergrund alles passiert.

Dann solltet ihr noch herausfinden, was euch an der jetzigen Implementierung nervt, und versuchen es mit dem Update zu verbessern.

Wenn ihr dann wisst, was geändert wurde bzw. sollte, müsst ihr dann nur noch herausfinden, ob das noch möglich ist, ob es evtl. schon Standard ist, bzw. was es kostet es neu zu implementieren.

Gruß Fiddi

Hallo,

grundsätzlich sieht das schon gut aus.

Frage: Ist das euer bisheriger Partner oder ein neuer? Falls es euer bisheriger Partner ist, sollte der eigentlich schon wissen was zu tun ist, er hat ja Zugriff auf den Quellcode, und er sollte euch kennen.

Wenn man euren Quellcode mit dem einer Standardversion vergleicht, dann sieht man welche Änderungen eingebaut wurden. Man muss dann nur noch heraus finden warum sie gemacht wurden.

Die Anwender zu befragen ist da meistens wenig hilfreich, weil die Dinge oft als Standard voraussetzten, und dann vermeintlich unwichtige Dinge nicht erzählen. Außerdem wurden (sollte eigentlich heute auch noch der Fall sein) die Systeme häufig soweit angepasst, das die Anwender gar nicht mitbekommen was im Hintergrund alles passiert.

Dann solltet ihr noch herausfinden, was euch an der jetzigen Implementierung nervt, und versuchen es mit dem Update zu verbessern.

Wenn ihr dann wisst, was geändert wurde bzw. sollte, müsst ihr dann nur noch herausfinden, ob das noch möglich ist, ob es evtl. schon Standard ist, bzw. was es kostet es neu zu implementieren.

Gruß Fiddi

Hallo Fiddi,

Es handelt sich hierbei um unseren bisherigen Partner. Die SQL-Datenbankanalyse wurde schon vorgenommen, wir haben jedoch intern bereits entschieden, die alte Datenbank NICHT bis zum neuesten Stand hochzufahren. Sondern quasi einen Neustart mit Business Central in Kombination mit einem Reporting-Tool zu machen, natürlich mit Übernahme aller benötigter Stammdaten und Funktionen.

Daher habe ich auch nicht weiter viel Zeit investiert, die INDIV-Entwicklungen genauestens zu dokumentieren.

Intern hatten wir bereits die Diskussion, was noch besser werden könnte und was für uns aus der „alten Welt“ essenziell ist – wobei das noch in sauberer Form dokumentiert werden muss.

Die Frage, ob die NAV-Funktionen – egal ob INDIV oder Branchenlösung – in BC bereits im Standard drin sind, steht also noch als nächster Schritt gemeinsam mit unserem Partner an.

Gruß Sulim

Hallo,

Daher habe ich auch nicht weiter viel Zeit investiert, die INDIV-Entwicklungen genauestens zu dokumentieren.

Das halte ich persönlich für einen großen Fehler. Die Individual- Anpassungen hatten meist einen Grund: Aus einem grobschlächtigen 5Kg Hammer ein für euch passendes Werkzeug zu machen. Diese Anpassungen waren oft nötig um aus eben diesem groben ein brauchbares Werkzeug zu machen, das Dinge für den Anwender vereinfacht und weniger fehleranfällig ist.

Ich weiß das kostet Geld, aber jede Sekunde und Minute Arbeitszeit, die ihr durch die Anpassungen gespart habt, hat euch Geld gebracht, genauso wie es weniger Fehler auch getan haben.

Auch der Neustart wird immer wieder gerne empfohlen, weil auch eine Konvertierung Arbeit macht und Geld kostet. Das bedeutet aber, das deine Kollegen für eine ganze Zeit mit zwei System arbeiten müssen, um z.B. um Chargen zu verfolgen. Was dann aber wegen der unterschiedlichen Bedienkonzepte dazu führt, dass sie sich irgendwann die Finger brechen und Fehler machen.

Das Ganze erhöht zwar den Preis des Updates. Aber wenn Ihr Daten später doch haben müsst, oder Funktionen doch implementieren müsst, weil es sonst nicht funktioniert. Dann kostet das meist mehr, als wenn man es gleich gemacht hätte.

Und erspare mir bitte die Diskussion mit der Standard- Software. Es gibt keinen Standard (ISO oder DIN) für ERP-Software. Software ist immer individuell, und jedes Unternehmen definiert seinen eigenen Standard. Ich habe das in meiner langen Zeit schon so oft gehört: "Wir wollen den Standard einsetzten". Aber schon beim Beleglayout war es mit dem Standard dann vorbei. Mal ganz abgesehen Funktionen, die deren Business Case erforderte, die aber in keiner normalen Software vorhanden war und ist.

Gruß Fiddi
Gruß Fiddi