UniElektro · Ablösung
Erst verstehen, dann entscheiden, dann umsetzen — in dieser Reihenfolge
Ein Elektrogroßhändler mit Filialstruktur löst sein Altsystem im Vertrieb ab. Der Fall ist deshalb interessant, weil an ihm nachlesbar ist, womit ein solches Vorhaben anfängt: nicht mit einer Konfiguration, sondern mit einer Bestandsaufnahme, die ein eigenes Arbeitspaket ist.
- Ausgangslage
- Ablösung
- Branche
- Handel
- Zeitraum
- September 2023 bis laufend
- Dauer
- über 2 Jahre
- Modell
- Projekt, danach Monatsbudget
- Umfang
- 108 Vorhaben, davon 23 Monatstöpfe
Ein Altsystem raus, Dynamics an seine Stelle
Eingesetzt
Womit gearbeitet wurde.
- Dynamics 365 Sales
- Customer Insights
- Power Platform
Der Fall, an dem unsere Reihenfolge nachlesbar ist: erst die Systemsituation erfassen und dokumentieren, dann ein Soll-Bild mit Schätzung und Zeitschiene, erst danach Umsetzung in numerierten Paketen. Das Gewicht lag nicht auf Konfiguration, sondern auf Frontend- und Backend-Logiken und der Übernahme der Altdaten. Nach dem Projekt ist die Zusammenarbeit in ein monatliches Budget übergegangen.
Der Verlauf
Was in welcher Reihenfolge passiert ist.
Nicht die Kurzfassung für die Website, sondern der Ablauf, wie er in den Arbeitspaketen steht.
Es begann mit Verstehen: Die aktuelle Systemsituation wurde erfasst und dokumentiert, als eigenes Arbeitspaket vor jeder Umsetzung. Danach folgte Entscheiden, ein Soll-Bild mit der nötigen Transformation und eine Schätzung mit möglicher Zeitschiene. Erst dann begann Umsetzen, in numerierten Paketen von Anforderungsmanagement über Datenmodell und Rechte bis zu Schnittstellen und Migration.
Das größte Paket waren Frontend- und Backend-Logiken: JavaScript-Funktionen aus Geschäftsregeln, Webresources, eigene Plugins und Flows. Dazu Flussdiagramme für die Funktionen auf der Firmen-Entität, damit nachvollziehbar bleibt, was das System tut.
Beim Übergang lag das Gewicht auf der Datenübernahme. Ein bestehender Datenbestand musste mit, samt Verknüpfungen, mit eigenen Migrationsdiensten und mehreren Testläufen, erst in die Testumgebung, dann nach Review und Rework final in die Produktion.
Bei den Schnittstellen haben wir das Mapping konzipiert und die Umsetzung des Partners fachlich gesteuert. Ein eigener Strang war Marketing: neue Newslettertemplates, Anpassungen am System, dazu Customer Insights und ein Eskalationsprozess für Leads.
Ein Detail, das den Unterschied macht: Wir haben ausgewertet, welche Felder tatsächlich benutzt werden, und gegen den Standard abgeglichen, bevor neue Felder entstanden. Die fachlichen Workshops fanden vor Ort statt. Dass die Zusammenarbeit nach dem Projekt in ein Monatsbudget übergegangen ist, ist der eigentliche Beleg.
Nachprüfbar
Woran das festzumachen ist.
Jede Zeile entspricht einem abgerechneten Arbeitspaket. Ohne Stundenzahlen und Teamgrößen — Zahlen dieser Art sind schwer zu erheben und noch schwerer zu belegen.
- IST-Situation erfasst und dokumentiert, als eigenes Paket vor jeder Umsetzung
- SOLL-Bild mit nötiger Transformation, dann Schätzung mit Zeitschiene
- Umsetzung in numerierten Paketen, dazu Projektmanagement als eigenes Paket
- Frontend- und Backend-Logiken als größtes Paket: JavaScript, Webresources, Plugins, Flows
- Altdatenübernahme samt Verknüpfungen, eigene Migrationsdienste, mehrere Testläufe
- Schnittstellen-Mapping konzipiert, Umsetzung des Partners fachlich gesteuert
- Marketing: Newslettertemplates, Customer Insights, Eskalationsstufen im Leadprozess
- Feldnutzung ausgewertet und gegen den Standard abgeglichen
- Nach dem Projekt in ein allgemeines monatliches Budget übergegangen
Klingt das nach Ihrer Lage?
Der Einstieg ist in beiden Fällen derselbe: erst ein Befund, dann eine Entscheidung. Nicht umgekehrt.
Stand · Verantwortlich: Pascal Peters, Senior Dynamics 365 CE Architect & Inhaber
Alle Angaben dieser Seite werden aus dem konsolidierten Referenz-Datensatz gerendert, nicht frei geschrieben. Zuletzt geprüft: Laufzeit, Umfang und die genannten Arbeitspakete.