Salesforce CRM für ein globales Softwareentwicklungsunternehmen

Lösung

Entdeckungsphase

Zum Projektteam gehörten ein Product Owner, der auch als Projektmanager und leitender Business Analyst fungierte, ein Tech Lead, der uns bei der Nutzung und Implementierung von Salesforce entsprechend unseren Bedürfnissen beriet, ein Business Analyst, der die Anforderungen beschrieb, und Entwickler. Während der Erkundungsphase ermittelte unser PO zusammen mit den wichtigsten Interessengruppen, d. h. der Abteilung für Geschäftsentwicklung und dem Support-Team, das das System verwaltet und Anfragen bearbeitet, die wichtigsten Anforderungen und Probleme, die im Rahmen des Releaseumfangs gelöst werden sollten.

Da mehrere unternehmensinterne Systeme in die Salesforce-Lösung integriert werden mussten, arbeitete unser PO auch mit Vertretern der BI-, internen Automatisierungs- und Support-Teams sowie mit SharePoint-Verantwortlichen zusammen.

Als Ergebnis formten wir den Funktionsumfang, bewerteten ihn, unterteilten ihn in vier geschäftskritische Phasen und stellten einen Entwicklungsplan auf:

1. Neubewertung und Optimierung unserer bestehenden Arbeitsabläufe unter Berücksichtigung unseres alten Datenmodells, um die Abwärtskompatibilität für eine problemlose Migration von MS Dynamics sicherzustellen.
2. Implementierung der Salesforce-Funktionalität zur Unterstützung aller wichtigen Arbeitsszenarien, Anpassung der Standardfunktionalität an unsere Bedürfnisse.
3. Integration von Salesforce mit unternehmensinternen Plattformen und Einrichtung des Datenaustauschs.
4. Daten von Microsoft Dynamics zu Salesforce migrieren und dabei minimale Ausfallzeiten der Lösung sicherstellen.

Bei dem Projekt praktizierten wir Scrum mit einwöchigen Sprints, um Änderungen auf der Grundlage von Gesprächen mit den Beteiligten zeitnah vorzunehmen. Wir verwendeten alle Standardzeremonien wie tägliche Standups, Sprint-Reviews, Planungen, Retrospektiven und Backlog-Reviews und führten alle zwei Wochen Demos für die Beteiligten durch.

Überarbeitung des Arbeitsablaufs der Projektleiter

Vormals gab es keine klare Unterscheidung zwischen den Entitäten Leads und Opportunities, so dass Leads manchmal kurz vor dem Vertragsabschluss in Opportunities umgewandelt wurden. Um das Kunden-Onboarding und die Berichterstattung transparenter zu gestalten, haben wir beschlossen, das gesamte Verfahren zu überarbeiten. Wir überarbeiteten den Prozess der Erstellung von Leads und deren Zuweisung an verantwortliche Personen, indem wir einen deutlichen Unterschied zwischen einem Lead und einer Opportunity einführten.

Nach dem neuen Paradigma fungieren Leads als wichtige Instanzen in der Frühphase, um mögliche bestehende Kontaktpunkte mit einem Kunden aufzudecken und die verantwortliche Person zu ermitteln. Gibt es keine, wird festgelegt, ob die Anfrage weiter bearbeitet werden soll. Für die Lead-Bearbeitung bedeutet dies, dass der Lead, sobald er eingegangen, geprüft und qualifiziert ist, in eine Opportunity umgewandelt und einem Vertriebsmitarbeiter zugewiesen werden sollte. Auf diese Weise wird die Lead-Lebensdauer auf die anfänglichen Lead-Qualifizierungsaktivitäten beschränkt, während die gesamte weitere Bearbeitung und Kommunikation in der Opportunity und den zugehörigen Entitäten stattfindet. Anfragen, die von bestehenden Kunden eingehen, werden als neue Opportunities registriert.

Um den Übergang zum neuen Workflow reibungsloser zu gestalten, baten wir alle Benutzer, die mit Leads arbeiten, einen Monat vor der Einführung der Salesforce-Lösung den neuen Prozess im alten CRM zu befolgen. Wir nahmen kleinere Anpassungen an den bestehenden Geschäftsregeln in MS Dynamics vor, die für den Übergang zum neuen Prozess unerlässlich waren. Dank der frühen Anpassungsphase konnten wir die Anzahl der Probleme nach der Umstellung minimieren.

Einführung der Funktionalität

Itransition implementierte eine neue CRM-Lösung auf der Salesforce-Plattform und richtete alle erforderlichen Workflows ein. Dabei konnten wir unsere etablierten Vertriebsprozesse beibehalten, übertragen und bei Bedarf modifizieren und erweitern. Unseren Experten gelang es, die meisten Funktionen ausschließlich mit den in Salesforce integrierten Funktionen zu realisieren, so dass sich die Anzahl der Workarounds und individuellen Lösungen deutlich verringerte. Gelegentlich haben wir die Funktionalität mit Hilfe der Apex-Sprache und Add-ons an unsere Bedürfnisse angepasst.

Zu den wichtigsten Salesforce CRM-Modulen, die unser Team implementiert hat, gehören:

• Home - Zusammenfassung der wichtigsten Informationen, die die Aufmerksamkeit der Benutzer erfordern (Ereignisse, Aufgaben, aktuelle Datensätze, Chatter, überfällige Phasen)
• Konten - Verwaltung aller Kundeninformationen und zugehörigen Projekte
• Kontakte - Speichern von Kontaktinformationen
• Leads - Erstellen und Verwalten von Leads
• Chancen - Erstellen und Verwalten von Chancen
• Aufgaben - Erstellen von Aufgabenlisten in Bezug auf Konten, Kontakte und Verkaufschancen
• Kalender - Zugriff auf alle Ereignisse und Besprechungen, die in Salesforce registriert wurden
• Dashboards - Zugriff auf Analysen und Einblicke
• Berichte - Erstellung komplexer Berichte mit Salesforce CRM-Daten
• Dateien - Speicherung aller Dateien im Zusammenhang mit Leads und Opportunities, die Benutzer direkt in Salesforce hochgeladen haben, in Sharepoint als Hauptspeicher für Unternehmensdokumentation
• Chatter - Kommunikation mit anderen Benutzern von Itransition Salesforce CRM
• Marks - Teilnahme an der Bewertung zwischen Vertriebsexperten und Opportunity-Koordinatoren
• Beziehungsumfragen - Protokollierung und Speicherung der Ergebnisse von Umfragen zur Kundenzufriedenheit

Anpassung der Standardfunktionen an interne Prozesse

Auch wenn wir die Standardfunktionen von Salesforce so weit wie möglich genutzt haben, mussten einige von ihnen dennoch konfiguriert, angepasst und/oder auf unsere etablierten Prozesse abgestimmt werden. Wir haben uns auch damit beschäftigt, wie wir Standardentitäten von Salesforce auf unsere Prozesse anwenden können und welche benutzerdefinierten Entitäten hinzugefügt werden sollten.

Da unser Prozess beispielsweise aufgrund der sehr individuellen Angebote, die wir für unsere Kunden erstellen, keine Angebote, Produkte und andere zugehörige Entitäten enthielt, führten wir die Entität "Zusatzeinnahmen" ein. Sie ermöglichte es uns, Upselling im Zusammenhang mit einer Verkaufschance in einem bestimmten Projekt zu registrieren, ohne eine neue Verkaufschance zu erstellen, und die Upselling-Historie zu verfolgen.

Ein weiteres Beispiel für eine benutzerdefinierte Entität ist Marks - interne Fragebögen, die unsere Presales- und Sales-Manager verwenden, um die Qualität der erbrachten Dienstleistungen während der Opportunity-Bearbeitung zu bewerten. Zuvor war die Lead-Qualifizierung ein vollständig manueller Prozess, der von verschiedenen Personen durchgeführt wurde. Wir haben den Ablauf zur Bestimmung der Lead-Qualität auf der Grundlage definierter Regeln automatisiert und dabei die geschätzte Anzahl der Transaktionen, die Unternehmensgröße und die Kontaktinformationen berücksichtigt, um den Prozess transparenter zu machen und menschliche Fehler zu vermeiden.

Außerdem haben wir das Verfahren zur Bearbeitung von Dubletten im neuen System überarbeitet. Der überarbeitete Prozess wendet fortlaufend Deduplizierungsregeln auf alle wichtigen Systementitäten (Lead, Opportunity, Account, Kontakt) an, die potenziell ein Duplikat aufweisen könnten, was die Datentransparenz deutlich verbessert. Bei der Erstellung eines Leads zum Beispiel wird das System:

• Benutzer, die Zugriff auf den Lead haben, werden über ein Duplikat informiert (einschließlich der Account- und Kontakt-Entitäten) und es wird vorgeschlagen, eine Opportunity zu erstellen.
• Wenn ein Benutzer keinen Zugriff auf den doppelten Lead hat, zeigt das System ein Flag an, das vor einem Duplikat warnt und dem Benutzer nicht erlaubt, den Lead in eine Verkaufschance umzuwandeln. Dadurch wird der Benutzer gezwungen, zu dem Schritt überzugehen, bei dem der für die Lead-Verteilung zuständige Presales-Supervisor sicherstellt, dass es sich tatsächlich um einen neuen Lead handelt (falsch positiv) oder dass eine solche Verkaufschance/ein solches Konto bereits im System vorhanden ist.

Standardmäßig benachrichtigt Salesforce die Benutzer nicht über neue Chatter-Posts ohne direkte Erwähnung, aber unsere CRM-Endbenutzer sind es gewohnt, mit E-Mails zu arbeiten, und wollen auf dem Laufenden bleiben. Daher haben wir die Salesforce-Standardfunktionalität angepasst und die Erwähnung bestimmter Benutzer in Chatter-Beiträgen eingeführt, so dass diese Benutzer sofortige E-Mail-Benachrichtigungen mit den Details einer zugehörigen Verkaufschance (ID und Name der Verkaufschance, Kontoname und primär verantwortliche Person) erhalten können.

Wir hielten auch die mobile CRM-App für eine großartige Ergänzung, da sie den Zugriff auf die Informationen und Funktionen von unterwegs aus ermöglichen würde. Die Mitarbeiter, die für die Zuweisung von Vertriebsmanagern zu eingehenden Anfragen zuständig sind, sind oft nicht im Büro oder in Besprechungen, so dass es für sie viel bequemer wäre, eine mobile CRM-Version zu haben. Zu diesem Zweck hat unser Team die mobile App auf unsere Prozesse zugeschnitten.

Im Vergleich zur Webversion hat die mobile App nur begrenzte Möglichkeiten zur Lead-Konvertierung. Um den Benutzern die Möglichkeit zu geben, konvertierte Leads Vertriebsmitarbeitern zuzuweisen, auf Duplikate zu prüfen und zusätzliche Einstellungsoptionen für die Verkaufschance bereitzustellen, haben wir unseren benutzerdefinierten Konvertierungsalgorithmus von Lead zu Verkaufschance in die mobile Version integriert. Darüber hinaus haben wir benutzerdefinierte CRM-Bildschirme unter Verwendung von Salesforce-Komponenten-Blaupausen implementiert, so dass die Benutzeroberfläche auf dem Handy und im Web gleich aussieht und somit eine nahtlose Benutzererfahrung gewährleistet ist.

Außerdem setzten wir das native Salesforce to Outlook Addon ein, um E-Mails und Kalender direkt im CRM zu synchronisieren. Zu guter Letzt haben wir Zugriffsrechte und Verantwortungsbereiche bei der Bearbeitung einer Verkaufschance definiert, indem wir Profile eingerichtet und Benutzerrollen und Berechtigungen zugewiesen haben.

Integrationen

CRM ist ein Einstiegspunkt für die Customer Journey innerhalb von Itransition, daher musste es vollständig mit unserem IT-Ökosystem verbunden werden. Daher haben wir es mit den folgenden Plattformen integriert:

• SharePoint

• SharePoint-CRM-Materialien zur Erstellung strukturierter SharePoint-Ordner nach der Erstellung von Leads und Verkaufschancen und zur Verteilung von Zugriffsrechten
• SharePoint-Dateiübertragung und -anzeige zur Darstellung eines Dokumentenbaums mit SharePoint-Inhalten und zur Ermöglichung des automatischen Abrufs und der Übertragung von Dateien, die an Chatter-Beiträge angehängt sind, sowie von Anhängen aus E-Mails (über das Outlook-Addon) an SharePoint

• Jira

• Automatische Erstellung von Tickets für neue Leads/Opportunities, Hinzufügen von Benutzern und Verteilen von Zugriffsrechten
• Worklog-Funktionalität, um die Kosten für die Bearbeitung von Leads/Chancen zu verfolgen und das Budget entsprechend zuzuweisen
• Kontakt- und Chat-Formulare auf der Website für die automatische Erstellung von Leads
• Empfehlungsformulare für die automatische Erstellung von Leads, die von Itransition-Mitarbeitern eingereicht werden, die keinen Zugriff auf CRM oder Leads innerhalb von CRM haben
• BI-System zum Senden von CRM-Daten an unser internes BI-Tool, um wertvolle Erkenntnisse zu gewinnen
• OpenAI zum Abrufen allgemeiner Unternehmensdaten auf der Grundlage der ersten Anfrage und zum Auffüllen von Lead-Informationen mit ChatGPT
• Wechselkurse API zum Abrufen und Speichern aktueller Wechselkurse, wobei die Kurse in allen Opportunities einmal täglich auf der Grundlage der tatsächlichen Werte neu berechnet werden
• HubSpot (ein CRM-System unserer Tochtergesellschaft) für das Management von Erwartungen, die Bewertung der Effizienz und die Generierung analytischer Erkenntnisse für eine Gruppe von Unternehmen

SharePoint Online als Dokumentenbibliothek für Salesforce

Das Speichern, Verwalten und Freigeben von Dokumenten in verschiedenen Formaten war für unsere Vertriebsabläufe unerlässlich. Zuvor verfügte MS Dynamics über einen lokalen Dokumentenspeicher (SharePoint-Bibliotheken), der zwar begrenzte Möglichkeiten der Zusammenarbeit bot, aber unbequem war. Wir beschlossen, diese Lösung abzuschaffen und unsere SharePoint- und Dokumentenmanagementprozesse in die Cloud zu verlagern. Wir entwarfen und implementierten die Salesforce-SharePoint-Integration unter Verwendung der SharePoint Online-Funktionen und erhielten die folgenden Funktionen:

• Erstellung einer notwendigen Ordnerstruktur für operative Vertriebsaktivitäten und langfristige Speicherung der zugehörigen Dokumente für jeden Lead und jede Opportunity
• Übertragung von Zugriffsberechtigungen von einem bestimmten Vorgang in CRM auf den entsprechenden Ordner in SharePoint Online entsprechend der Rolle des Benutzers
• Weitergabe von Dokumenten an andere Akteure (KMUs, Vorgesetzte, Kunden usw.), die an der Bearbeitung von Anfragen beteiligt sind, ohne dass diese Zugriff auf CRM erhalten
• Gleichzeitige Online-Bearbeitung, Kommentierung und Überprüfung desselben Dokuments durch mehrere Autoren gleichzeitig

Wir haben auch die nahtlose Navigation vom CRM zum Dokumentenspeicher beibehalten, indem wir das integrierte SSO mit dem Active Directory des Unternehmens verwendet haben. Wir mussten diese Funktionalität beibehalten und beschlossen, die automatische Synchronisierung von Anhängen von CRM zu SharePoint zu aktivieren. Auf diese Weise wären alle fallbezogenen Dokumente durchgängig am selben Ort verfügbar, und die Endbenutzer müssten nicht zu einem anderen System wechseln, um nach projektspezifischen Unterlagen zu suchen, sondern könnten Dateien hochladen und im CRM gemeinsam an Dokumenten arbeiten.

Die CRM-Lösung von Salesforce verfügt über ein integriertes Modul für das Dokumentenmanagement und kann in ECM/DMS von Drittanbietern integriert werden. Die Standardfunktionen des Systems unterstützten jedoch nicht alle möglichen Szenarien für die Dokumentenverwaltung, wie z. B. eine ganz bestimmte Struktur von Dokumenten, die wir einhalten mussten. Wir benötigten außerdem eine gleichzeitige Online-Kollaborationsbearbeitung derselben fallbezogenen Dokumente und wollten in der Lage sein, eine beliebige Anzahl von Teilnehmern innerhalb und außerhalb des Unternehmens einzubeziehen, ohne dabei auf eine fein abgestufte Zugriffskontrolle verzichten zu müssen. Schließlich mussten wir die vorhandene Dokumentenbibliothek unserer alten CRM-Lösung beibehalten.

So entwickelte unser Team eine Lösung, die es uns ohne zusätzliche Lizenzkosten ermöglichen würde, unseren CRM-Dokumentenfluss vollständig zu unterstützen, ohne die Standardfunktionalität der Plattform zu beeinträchtigen. Die Files Connect-Funktion erleichtert die Integration mit SharePoint und den Zugriff auf Dokumente auf einer Zielsite/Sitesammlung oder -bibliothek. Sie beginnt jedoch immer mit einem Stammordner, was bedeutet, dass:

1. Selbst bei einer geringen Anzahl von Fällen wird die Bibliothek wahrscheinlich schwer zu navigieren sein
2. Jeder Akteur eines Falles hat Zugriff auf die Ordner anderer Fälle, es sei denn, für jeden Ordner werden individuelle Berechtigungen auf Fallbasis festgelegt
3. Die Weitergabe von Ordnerberechtigungen von Salesforce an SharePoint wird bisher nicht unterstützt

Da wir Tausende von Ordnern haben, sahen wir die Unmöglichkeit, die Ansicht auf einen fallbezogenen Ordner einzugrenzen, als entscheidenden Mangel an. Auf der Grundlage der Lückenanalyse entschieden wir, dass wir die gewünschten Dokumentenverwaltungsfunktionen durch die Reintegration unserer bestehenden Lösung in Salesforce ohne kostspielige Drittanbieterkomponenten von AppExchange erhalten könnten. Da sich die bestehende Struktur und das Verhalten der Dokumentenbibliothek bereits bewährt haben und nicht geändert werden mussten, entschieden wir uns, sie so zu belassen, wie sie ist, und eine neue Funktion zur Synchronisierung von Anhängen in beide Richtungen hinzuzufügen.

Wir haben die folgenden Schritte durchgeführt:

• Anpassen der bestehenden Integration zur Unterstützung von Rückrufen aus Salesforce für neue Leads, Opportunities und Änderungen an Teammitgliedern
• Anpassen der Standardfunktionalität von Files Connect mit einer benutzerdefinierten Komponente zur Anzeige der Ordnerstruktur für einen bestimmten Lead oder eine bestimmte Opportunity
• Einführung eines benutzerdefinierten Endpunkts zum Hochladen von Dateien aus Salesforce in den SharePoint Online-Zielordner
• Automatisiertes Hochladen von Salesforce-E-Mails und Chatter-Anhängen in SharePoint mithilfe eines neuen Endpunkts

Auf diese Weise ist es uns gelungen, unsere Dokumentenbibliothek mit minimalen Codeänderungen und ohne Datenänderungen aus dem bestehenden CRM in Salesforce zu übertragen. Als Ergebnis der SharePoint-Salesforce-Integration gelang es uns:

• Verbesserung der Schnittstelle für das Dokumentenmanagement innerhalb von Salesforce mit getrennter Sichtbarkeit und einer geordneten Anzeige von Assets, die sich auf einen bestimmten Fall (Lead oder Opportunity) beziehen
• Nutzen Sie die erweiterte Zugriffskontrolle, die Online-Zusammenarbeit und die Dokumentfreigabefunktionen von SharePoint
• Wiederverwendung der etablierten Bibliotheksstruktur und Arbeitsprozesse in einem neuen CRM
• Automatische Synchronisierung von Salesforce-Anhängen mit der Dokumentenbibliothek
• Nahtlose Navigation zwischen Salesforce und SharePoint mit SSO gegen das Active Directory des Unternehmens ermöglichen

Durch die Nutzung des Outlook-Addons konnten wir außerdem sicherstellen, dass Dateien, die an E-Mails aus Outlook angehängt wurden, direkt in SharePoint erscheinen. Nicht zuletzt sind dank SharePoint die Dokumente nun auch außerhalb des CRM verfügbar, was nach unserer Einschätzung die Anzahl der benötigten Salesforce-Lizenzen um die Hälfte reduziert.

Kontakt- und Empfehlungsformulare

Früher lösten alle Anfragen, die über das Kontaktformular auf unseren Websites gesendet wurden, die Erstellung einer E-Mail aus, die dann von der zuständigen Person aus der Geschäftsentwicklungsabteilung geprüft und an eine spezielle E-Mail eines zugewiesenen Vertriebsleiters weitergeleitet wurde. Diese Aktion löste die automatische Erstellung eines Leads in MS Dynamics mit der Zuweisung dieses bestimmten Vertriebsleiters zur Lead-Bearbeitung aus. Nach dem überarbeiteten Prozess wird alles direkt an das CRM übermittelt und dann verarbeitet, d. h. Lead-Qualifizierung, -Überprüfung, -Deduplizierung, -Zuordnung und so weiter. Da das Revisionsverfahren und die gesamte Verarbeitung im CRM stattfinden, gehen weniger Informationen verloren, da E-Mails manchmal übersehen oder vergessen werden könnten. Die Original-E-Mails werden außerdem automatisch in SharePoint gespeichert. Unser Team hat viel Arbeit in die Anpassung der Kontakt-, Empfehlungs- und Chatformulare auf unseren Websites gesteckt, um die Arbeit mit der neuen Lösung reibungslos zu gestalten. Dazu haben wir Power Automate eingesetzt, um Info-E-Mails mit eingehenden Anfragen auszusortieren und die Daten in das erforderliche Format zu bringen, um sie dann an das CRM zu übermitteln.

Abgesehen von der manuellen Umwandlung eines Leads in eine Verkaufschance haben wir diesen Prozess automatisiert, wenn der Lead über unser benutzerdefiniertes Empfehlungsformular übermittelt wurde. Das System überprüft den Lead auf Duplikate und stellt fest, wer diesen Lead eingereicht hat:

• Wenn dieser Mitarbeiter Zugriff auf das CRM hat, wird der Lead automatisch in eine Verkaufschance umgewandelt, während diese Person dieser Verkaufschance zugewiesen wird und Eigentümer aller zugehörigen Entitäten wird
• Wenn die Person keinen Zugriff auf das CRM hat, muss dieser Lead vom Vorgesetzten überprüft werden

Migration

Bei der Planung des Migrationsablaufs haben wir beschlossen, während der Übergangsphase nicht zwei Systeme gleichzeitig zu unterstützen, da dies die Benutzer verwirren und den Migrationsprozess verkomplizieren und verlängern würde, was ihn kostspieliger machen würde. Außerdem wirken sich alle Konversions-KPIs auf die internen Prognosen und Verkaufsstatistiken des Unternehmens aus, was ein weiterer Grund war, warum wir das Release nicht in mehrere Teile aufteilen wollten. Stattdessen führten wir vor der Migration eine einmonatige Übergangszeit ein, damit die Mitarbeiter MS Dynamics nach dem neuen überarbeiteten Paradigma nutzen und sich daran gewöhnen konnten. Auf diese Weise konnten wir die Migration zu einem einmaligen Ereignis machen.

Wir haben in der Entwurfsphase Migrationsregeln ausgearbeitet, um die Konsistenz zu wahren und sicherzustellen, dass das neue Datenmodell mit dem alten Modell kompatibel bleibt, um die Migration nicht zu erschweren. Vor der Migration in die Produktionsumgebung führten wir eine Testmigration der neuesten Daten in die UAT-Umgebung durch und ließen die Testgruppe die Qualität der migrierten Daten als zusätzlichen Sanity-Check bewerten. Wir setzten das Pentaho Data Integration Tool ein, ein Open-Source-ETL-Tool, das die Datenextraktion aus dem alten System, die Transformationen zur Abbildung der Daten auf ein neues System und das Laden der Daten in das neue System automatisiert.

Einen Monat vor der Umstellung auf das neue CRM richteten wir die Produktionsumgebung ein und testeten alle Integrationen mit externen Systemen. Am Tag der Migration schalteten wir MS Dynamics für eine begrenzte Zeit als Backup in den Nur-Lese-Modus, das neue CRM begann, neue Leads zu empfangen, und der Migrationsprozess wurde eingeleitet.

So haben wir die Datenmigration Schritt für Schritt durchgeführt:

1. Analyse aller zu migrierenden Entitäten (Leads, Accounts, Kontakte, Opportunities usw.) auf Datenqualität und Identifizierung kritischer Probleme, die gelöst werden mussten
2. Die Datenbereinigung wurde durchgeführt. Neben der manuellen Datenbereinigung haben wir Datentransformationsskripte ausgearbeitet und Regeln zur Lösung von Datenproblemen definiert (z. B. fehlten einige Informationen und mussten aus anderen Feldern geparst werden), um eine zusätzliche Datenbereinigung während der Migration zu gewährleisten.
3. Erstellung von Mappings für alle migrierten Entitäten
4. Initiierung des Migrationsprozesses. Die Reihenfolge der Migration der CRM-Entitäten wurde entsprechend den Abhängigkeiten zwischen den Entitäten festgelegt:
   • Die Konten und Kontakte wurden zuerst in das System migriert, gefolgt von den Verkaufschancen und den miteinander verknüpften Leads. Es wurden Deduplizierungsregeln angewendet.
   • Andere verknüpfte Entitäten wie Opportunity-Teammitglieder, zusätzliche Einnahmen, Marken usw. wurden migriert
5. Benutzern wurde Zugriff auf das neue System gewährt

Insgesamt dauerte die Migration aller Daten weniger als 12 Stunden und verursachte nur minimale Unterbrechungen für die Endbenutzer. Wir haben rund 30.000 Leads, 10.000 Opportunities und jeweils 7.000 Konten und Kontakte migriert.

Test & Feedback

Wir gaben das System schrittweise für die UAT-Umgebung frei, in der Regel am Ende eines Sprints oder nach Fertigstellung eines funktionierenden Moduls. Nach der Hälfte der Entwicklungsphase gewährten wir einer Testgruppe Zugang zum System, damit sie sich mit dem System vertraut machen und frühzeitig Feedback geben konnte. Außerdem testeten wir einen Monat lang den Empfang von Produktionsleads in der UAT-Umgebung. Die Testgruppe bestand aus häufigen Nutzern wie Supervisoren, Vertriebsleitern, Presales-Koordinatoren und Produktionsvertretern. Alle Fragen, Antworten, Vorschläge und Kommentare wurden gesammelt und in einem speziellen MS-Teams-Kanal behandelt.

Wir lieferten das System einen Monat vor dem Veröffentlichungstermin, und zwar auf einmal. Es war voll funktionsfähig und für den Empfang von Leads aus der Produktionsumgebung konfiguriert. Wir hatten eine Testphase, um die automatische Erstellung neuer Leads zu prüfen und sicherzustellen, dass das System der unterschiedlichen Belastung standhält. Wir führten auch Leistungstests der Integrationen gemäß OWASP durch.

Nach der Freigabe des CRM für die Produktionsumgebung sammelten wir Feedback von allen CRM-Benutzern und gaben ihnen Zugang zu einem speziellen Jira-Board, wo sie Tickets einreichen konnten. Alternativ konnten sie auch Anfragen an unseren Service Desk erstellen, eine L1-Supportabteilung, die grundlegende Anfragen bearbeitet und Anfragen von Benutzern sammelt. Gemeinsam mit den Stakeholdern priorisiert unser PO alle Anfragen in hoch, mittel und niedrig und legt so den Funktionsumfang für die nächsten Versionen fest.

Benutzerakzeptanz und Schulung

Um eine reibungslose Einführung des neuen Systems zu gewährleisten, haben wir mehrere Demositzungen für alle häufigen CRM-Nutzer durchgeführt. In diesen Sitzungen hob unser PO die Hauptunterschiede zwischen dem alten und dem neuen CRM hervor, beschrieb die wichtigsten Arbeitsabläufe im Detail und konzentrierte sich dabei auf die neu eingeführten Regeln, wies auf Änderungen hin und ging auf alle möglichen Unklarheiten ein.

Außerdem haben wir separate Fragerunden mit den Endbenutzern durchgeführt, um ihnen zu verdeutlichen, was sie von dem neuen System erwarten können. Außerdem haben wir eine spezielle FAQ-Seite eingerichtet und dort Links zu Videos mit Übersichten über die wichtigsten Funktionen aufgeführt. Schließlich erstellten wir ein umfangreiches CRM-Benutzerhandbuch und holten Feedback von CRM-Endbenutzern ein, um sicherzustellen, dass der Inhalt klar und verständlich ist. Das Handbuch behandelt unter anderem folgende Themen:

• Schnelle Antworten auf wichtige Fragen
• Salesforce CRM-Grundlagen und Lifehacks
• Übersicht über die Funktionen
• Leads und Opportunities - Einreichen und Bearbeiten neuer Anfragen
• Effiziente Anzeige von Daten
• Erstellen und Verwalten von Berichten
• CRM-Personalisierung