Dynamics Views
Einblicke, Meinungen und News rund um Microsoft Dynamics 365 Finance und Supply Chain Management sowie Dynamics AX
Kostentreiber in der Microsoft-Dynamics-365-Implementierung
Klappern gehört zum Handwerk, aber beim Autokauf hört man selbiges nur bei einer Probefahrt.
In diesem Blogbeitrag gebe ich einen kurzen Abriss über die Kostentreiber in einem Dynamics-365-Projekt. Eine genaue Bezifferung lässt sich ohne das Wissen der Branche und des Produktportfolios des Kunden leider nicht geben. Allein die Anforderung „Einfache Angebotserstellung über CRM“ kann von „Zwei-Zeiler mit Preisindikation“ bis hin zu komplexen Ausschreibungsunterlagen in einer behördlichen oder einem konzernähnlichen Ausschreibungsverfahren gehen. Das macht auch in der Basic-Phase einen signifikanten Unterschied. Die aus meiner Erfahrung heraus existierenden Variablen für eine Preisindikation lauten wie folgt:
Wenn wir davon ausgehen, dass der Kunde/Interessent in der Lage ist, die Prozesse seines Vertriebs oder seines sonstigen Geschäftsbetriebs zu Einhundertprozent auf die in Microsoft Dynamics 365 existierenden Felder und Prozesse zu definieren, dann bleibt die eigentliche Einrichtung mit Stammdaten, existierenden Bewegungsdaten wie Angeboten, Leads und Aufträgen, ggf. historischen Daten wie Historie der Besuchsberichte, Sachkontenbuchungen oder historischen Verkaufsaufträgen und Einkaufsbestellungen sowie Produktionsaufträgen. Das hängt wiederum vom Umfang der Altdaten ab, ist aber insbesondere bei offenen Entitäten sowie aktiven Personenkonten essenziell, um ein erfolgreiches Dynamics 365 hinzustellen und auch einen positiven Nutzen zu generieren. Manueller Upload insistiert einen Export zu Excel und ggf. eine Transformation der Daten, damit diese GOBD-konform abgelegt werden. Alternativ nutzt man das Common Data Model und die Common Data Services (heute besser bekannt als Felxdata) der Power Platform.
Variablen für die Preisindikation:
- Anzahl zu migrierende Datenentitäten
- Anzahl Datensätze pro Datenentität
- Anzahl Schnittstellen zu Legacy-System
- Komplexität der Datentransformation
- Nutzung Power Platform
Zum Rollout selbst gehört das Training. Erfahrungsgemäß sind Vertriebsmitarbeiter und Mitarbeiter in Konzernen nicht im HQ, sondern verteilt, ggf. sogar über die Kontinente. Daher haben wir mit Dynamics 365 Finance ein Rollout- und Trainingskonzept entwickelt, nennt sich SMIT GetFitKit und basiert auf Self-Service-Learning und theoretischen wie praktischen Examen, die integriert in Dynamics 365 durchgeführt und rollenbasiert geplant werden. Zertifikate sind in diesem Fall für die Rollen definiert und können mittels Lernvideos und klickbaren Inhalten in Dynamics 365 geübt werden. Webcasts zum Kickoff und zum Nachhalten der Erfolge der Trainees runden den Rollout- und Trainingsprozess ab.
Variablen für die Preisindikation:
- Anzahl Rollen
- Anzahl Zertifikate
- Anzahl praktische Prüfungen
- Anzahl theoretische Prüfungen
- Anzahl Rolloutwochen
Vor dem Rollout steht allerdings das Testing. Hier sind wir ebenfalls bereits gut aufgestellt für Dynamics 365, nutzen Azure DevOps, den integrierten SMIT TestCaseHub und unsere Testfälle aus dem SMIT TestKit for Microsoft Dynamics. 2.000 Standardtestfälle für Dynamics 365 Finance und Supply Chain Management, noch keine für Dynamics 365 Sales. Kunden ohne SMIT TestKit können zumindest die Struktur und Systematik des Testmanagements nutzen. Bei allen verfügbaren Prozessen schätze ich die Notwendigkeit von ca. 1.500-2.000 Testfällen mit im Mittel 2-3 Iterationen. Am Ende jedes Sprints eine Runde Funktionstests, also 200-600 manuelle Testausführungen. Vorteil: Die Prozesse sind getestet und die User haben bereits etwas gelernt. Die Testfälle dienen als Grundlage für die SMIT-GetFitKit-Zertifikate und -Trainingsvideos. Am Ende sogar für die Testautomatisierung und die Regressionstests. Diese sind erforderlich, da Microsoft eine One-Version-Strategie fährt und jeden Monat neue Releases rausbringt. Regressionstests dienen dem Verifizieren, dass Prozesse, die einmal liefen, auch heute noch fehlerfrei funktionieren.
Variablen für die Preisindikation:
- Anzahl Testfälle für die definierten Prozesse
- Anzahl Iterationen der Testfälle auf Basis von Äquivalenzklassenanalyse und Grenzwertanalysen
- Anzahl Regressionstests
Um das alles koordinieren zu können, nutzen wir Azure DevOps. Dieser muss eingerichtet und vorbereitet werden und dient im Laufe des Projektes oder der Sprints den Sprint Reviews, Retros und Refinements. Ist also der SPOT – Single Point of Truth. Hier ist der Gesamtumfang des Projektes entscheidend und die oben genannten Variablen zahlen alle auf den SPOT-Aufwand ein. Für ein schnellen Start liefern wir mit dem SMIT RapidKit Init ein buchungsfähiges Dynamics 365 Finance und Supply Chain Management mit SKR 03, SKR 04, SKR 51 oder dem ÖKR für Österreich innerhalb von unter drei Stunden. Dazu gibt es einen vorkonfigurierten und mit Finance-User-Stories bestückten Azure DevOps inklusive einer Trialversion des SMIT TestCaseHub mit den Finance-Testfällen für 30 Tage. Reicht, um einen Schnellstart und die ersten zwei Sprints hinzulegen und Kernprozesse zu etablieren.
Aus meiner Erfahrung ist es schier unmöglich, einen vernünftigen Preis für eine Dynamics-365-Implementierung zu nennen, wenn man nur Überschriften der Prozesse und nicht das Businessmodell mit einer groben Abschätzung der Personen und Datenvolumina kennt.
Aber dafür gibt es ja Probefahrten.
Schreiben Sie einen Kommentar
Kommentar...