Einführung von Dynamics 365 Customer Engagement (CRM) mit dem Fokus auf Vertriebsprozesse und einheitlichem Rollout

Die meisten Projekte starten mit einer Neueinführung von Systemen, was einen großen Teil unseres Berufs ausmacht. Dabei hilft es uns von Anfang an dabei involviert zu sein um die beteiligten Personen, ihre Bedürfnisse und natürlich auch notwendige Prozesse direkt kennenzulernen. Durch diese Verbindung und das damit einhergehende Verständnis an entsprechende Anforderungen, kann man sich in die Herausforderung besser hineinversetzen um das bestmögliche Ergebnis zu erzielen. Viele dieser Projekte sind aus der Vergangenheit entstanden und wir sehen von der namentlichen Spezifizierung in diesem Fall ab.

Das besondere bei dieser Einführung, war der Gedanke eines Blueprint für den Rollout in andere Landesgesellschaften. So wurde mit verschiedenen Landesgesellschaften gesprochen, um die Anforderungen übereinander legen zu können. Aus Sicht des IT-Projektes sollte ebenso eine Toolunterstützung von Anfang an mit bedacht werden, weshalb mittels Azure DevOps der integrierte Ansatz der Softwareentwicklung genutzt wurde. In der Praxis bedeutet dies Application Lifecycle Management (kurz: ALM), welches die Ansätze der agilen und DevOps Entwicklung unterstützt und für eine Zusammenarbeit der verschiedenen Disziplinen sorgt. Der sogenannte Spruch 'Die Warheit steht im DevOps' konnte etabliert und die Transparenz im Projekt dadurch gewährleisten werden.

Zentraler Vertriebshub mit 360° Blick auf den Kunden

Die Anforderungen für den Vertriebshub wurden zentral gesammelt, besprochen und priorisiert. Dies war die Basis für den Blueprint, welcher durch die Integration mit dem ERP-System, der Nutzung von Outlook mit eingerichtetet Synchronisation sowie BI Daten angereichert wurde um Dynamics 365 Customer Engagement mit dem Ziel des 360° Blicks zu nutzen.

über 1000 Projekttage

Konstante Weiterentwicklung

Übernahme von Schlüsselrollen

Solution Architekt & Projektmanager

Agile Herangehensweise

langfristige Nutzung und Adaptierung des Scrum Frameworks

Langfristige Zusammenarbeit

Konstanz im Kernteam, wenig Wissenstransfer

Nennenswerte Themen

Microsoft Power Platform

Microsoft Power Platform

Die Power Platform wurde über die Jahre immer stärker, welches sich ebenfalls auf das Projekt auswirkte. Sei es Canvas Apps für verschiedene Zwecke, Flows zu Steuerung von Daten und interaktion mit anderen Systemen oder einfach nur das weitere Customizing von Dynamics 365 Customer Engagement.

Application Lifecycle Management

Application Lifecycle Management (ALM)

Früher gab es viele verschiedene, oftmals voneinander getrennte, Disziplinen in der Softwareentwicklung. ALM schafft eine Sichtbarkeit aller Teams die an der Softwareentwicklung beteiligt sind transparent zusammenzubringen und ein das Gemeinschaftsgefüge zu stärken.

Project Management

Zusammenarbeit & Kommunikation

Je größer ein Entwicklungsteam ist, desto mehr Struktur und Regeln werden benötigt. Die Zusammenarbeit muss einen zentralen Stellenwert haben um auch die Effektivität des Teams nicht zu beeinflussen. Der Schlüsselfaktor lautet: Kommunikation!

Was haben wir mitgenommen?

Kurz gesagt: Viel. Vor allem Erfahrung. Denn in einem Projekt dieser Größenordnung, bleibt es nicht aus neue Dinge zu lernen und bestehendes Wissen zu erweitern und Konzepte neu zu überdenken. Gerade die zusammenarbeit mit der Power Platform wurde stark erweitern, da sich diese selbst in ständiger Weiterentwicklung durch Microsoft befindet. Gerade das Konzept der Rollouts auf Basis eines einheitlichen Blueprints ist ein nicht zu missender Erfahrungsschatz. Rollouts und Blueprints sind keine neue Erfindung, dennoch war die Herausforderung hier besonders.

Jedes Projekt besitzt Routinen. Routinen werden zu Beginn eines Projektes eingeführt und verändert. Neue Routinen werden hinzugefügt, andere gegebenfalls nicht regelmäßig genutzt oder fallen oft aus. Eine Routine sticht dabei besonders heraus: Die Retrospektive. Unabhängig der gewählten Projektmethode empfiehlt es sich für jedes Projektteam eine regelmäßige Betrachtung des Projektes vorzunehmen, positives als auch negatives herauszustellen, auzuschreiben und zu besprechen. Damit lassen sich Maßnahmen treffen, welche die Effizienz des Projektteams fördert und eine stetige Weiterentwicklung des Projektteams gewährleistet.

Unsere Rolle(n)

Roy Carlitscheck

Roy als Solution Architekt

In der Rolle des Solution Architekt übernahm Roy die Verantwortung über die technische Landschaft und war maßgeblich an der Erweiterung des Systems beteiligt. Spezifierungen und Diskussion neuer Anforderungen, eigenständige Umsetzung aber auch Unterstützung der Teamkollegen mit seiner Erfahrung gehörten ebenfalls zu seinem Aufgabengebiet.

Des Weiteren wurde seine Stärke dafür genutzt, die Qualtität im Projekt zu überwachen. Code Reviews der Erweitertungen, Refactoring bestehender Lösungen und weitergabe von Wissen rundeten Sein Profil mit der Rolle des Solution Architekt ab.

Nico Krieger

Nico als Projektmanager

Projekte dieser Größenordnung bedarf es einer guten Steuerung im Hinblick auf die Meilensteine und Erwartungshaltung des Projektes. Die Planung, Leitung und Durchführung gepaart mit Budgetanforderungen sind ein dauerhafter Posten bei der Einführung von Systemen. So musste dafür gesorgt werden, das ein entsprechender Status zum Sprint, eine Aussage zum Budget oder der Verfügbarkeit der einzelnen Personen stets gewährleistet und transparent kommuniziert wurde.

Durch seine Erfahrung, war es ebenfalls möglich in die Rolle des Consultants zu wechseln und das Projektteam zu unterstützung. So wurde vor allem in der Qualtitätssicherung geholfen, Konfigurationen und kleinere Umsetzung mit angepackt und nicht zuletzt in der Diskussion bei neuen Anforderungen mitgewirkt.

Ergebnis

Mit der Einführung eines Systems dieser Größe bleibt ein Change für ein Unternehmen nicht aus. Viele Abläufe ändern sich, sobald das System das erste mal Live geht und die lang gelebten Prozesse für Mitarbeiter ändern sich von einem Tag auf den anderen. Durch das Sammeln der Anforderungen an zentraler stelle und der genutzten Methodik des Rollouts, waren die Rollouts in weitere Landesgesellschaft einfacher zu steuern und in kürzerer Zeit umzusetzen. Der Erfolg und Bedarf an weiteren Erweiterungen des Systems war gegeben, weshalb Erweiterungen im Customer Service Bereichen (ebenfalls mit Rollout-Gedanke) besprochen und angegangen wurden.