HinweisDieses Vorgehen habe ich gemeinsam mit Juliane Winterscheid erarbeitet, meiner Kooperationspartnerin für Change Management. Juliane ist Prosci-zertifiziert. LinkedIn-Profil (öffnet in einem neuen Tab)
02 · Change Management
Change Management, wenn kaum jemand Salesforce nutzt
Ein neues Salesforce-Release ist schnell ausgerollt. Ob Fachbereiche, Entwicklerteams und Partner danach anders arbeiten, ist eine andere Frage. Gemeinsam mit Juliane Winterscheid plane ich die Einführung neuer Prozesse und Standards nach Prosci und ADKAR, damit sie im Alltag ankommen und bleiben.
Termin vereinbaren (öffnet Microsoft Bookings in einem neuen Tab)
Change Management in einem Salesforce-Programm heißt, neue Prozesse, Standards und Releases so einzuführen, dass die Menschen, die damit arbeiten, sie auch nutzen. Das betrifft die Fachbereiche, die mit Salesforce ihren Alltag erledigen, genauso wie Entwicklerteams und Implementierungspartner, die nach gemeinsamen Regeln bauen sollen. Juliane Winterscheid und ich übernehmen diese Arbeit auf Kundenseite: Juliane begleitet die Menschen durch die Veränderung, ich sorge dafür, dass Architektur, Partnersteuerung und Releases dazu passen. Wenn auf dieser Seite „wir“ steht, sind wir beide gemeint. Unser Vorgehen orientiert sich an Prosci, warum, steht weiter unten.
Typische Ausgangslage
- Salesforce ist live, aber Teile der Fachbereiche arbeiten weiter mit Excel, E-Mail und eigenen Listen.
- Schulungen sind gelaufen, die Nutzung bleibt trotzdem niedrig, und niemand weiß genau, woran es hängt.
- Neue Standards für Entwicklung und Release sind beschlossen, aber jeder Partner und jedes Team legt sie anders aus.
- Releases werden kleiner und häufiger, und Fachbereiche erfahren von Änderungen erst, wenn sie schon in Produktion sind.
- Das Management erwartet Ergebnisse aus dem Programm, ist aber selten da, wenn Entscheidungen zur Einführung anstehen.
Was wir machen
- Für jede betroffene Gruppe schätzen wir nach dem ADKAR-Modell ein, an welcher der fünf Stufen die Einführung hängt.
- Neue Standards führen wir in Etappen ein und beginnen mit den häufigsten Fällen.
- Wir richten ein festes Format ein, in dem Fachbereiche, Teams und Partner anstehende Änderungen früh sehen und mitreden können.
- Wir messen die Nutzung in Salesforce und steuern dort nach, wo sie hängt.
Was Sie bekommen
- Festgelegte Erfolgskennzahlen aus Salesforce-Berichten, zum Beispiel zu angelegten und gepflegten Datensätzen
- Einen Einführungsplan je Release, der zeigt, welche Gruppen betroffen sind, was sich für sie ändert und wann sie davon erfahren
- Einen Sponsor-Plan, der festhält, was das Management wann sichtbar tut, damit neue Regeln verbindlich werden
- Einen festen Weg, auf dem Rückmeldungen aus dem Alltag in den Backlog kommen
- Interne Verantwortliche, die die Einführung nach der Übergabe weiterführen
Warum kommen neue Prozesse im Alltag nicht an?
Ein Release ist technisch in Minuten ausgerollt. Danach entscheidet sich, ob jemand anders arbeitet. Die Gründe, warum das nicht passiert, sind meist dieselben, und für jeden gibt es eine Antwort:
Was wir dagegen tun
- Ein Einführungsplan je Release legt fest, wer wann davon erfährt.
- Die erste Version deckt die häufigsten Fälle ab, Randfälle kommen später.
- Neue Regeln kommen vom Management, nicht nur vom Projektteam.
- Der alte Weg wird geschlossen, sobald der neue trägt.
Woran es scheitert
- Betroffene erfahren zu spät davon und suchen sich einen Weg drumherum.
- Alles soll auf einmal geregelt sein, die erste Version kommt spät und wird selten gelesen.
- Der Rückhalt im Management fehlt, neue Regeln bleiben eine Empfehlung.
- Der alte Weg bleibt offen, Excel-Listen und E-Mails funktionieren weiter.
Wie sieht ADKAR in einem Salesforce-Programm aus?
Das ADKAR-Modell (öffnet in einem neuen Tab) von Prosci beschreibt fünf Stufen, die jede Person bei einer Veränderung durchläuft. Hakt eine Einführung, fehlt meist eine davon. Häufig sehen wir Folgendes: Die Schulungen sind gelaufen, die Nutzung bleibt trotzdem niedrig. Statt eine weitere Schulung anzusetzen, fragen wir je betroffener Gruppe, an welcher Stufe es hängt:
- AAwarenessBewusstseinWarum ändert sich etwas?
- DDesireBereitschaftWill ich mitmachen?
- KKnowledgeWissenWie geht es?
- AAbilityFähigkeitKann ich es im Alltag?
- RReinforcementVerankerungBleibt es, oder falle ich zurück?
Es fehlt Awareness
Ein Vertriebsteam weiß nicht, wofür die gepflegten Opportunities gebraucht werden.
Das muss der zuständige Vertriebsleiter erklären, nicht der Trainer.
Es fehlt Reinforcement
Die Entwickler eines Partners kennen die Namenskonventionen, aber niemand prüft sie in der Pipeline.
Dann gehört eine automatische Prüfung in den Release-Prozess.
Salesforce hilft beim Messen. Ob ein neuer Prozess genutzt wird, zeigen Berichte über angelegte und gepflegte Datensätze zuverlässiger als eine Umfrage. Diese Zahlen legen wir in der ersten Phase fest und schauen in der zweiten regelmäßig darauf. Die einzelnen Themen, von Key Usern bis zur Messung der Nutzung, beschreibe ich in Salesforce Change Management: warum Einführungen scheitern. Kapitel für Kapitel entlang der fünf Stufen führt die Masterclass Change Management.
Gemeinsame Standards für fünf Partner in drei Monaten
30+
Entwickler in acht Streams
5
Implementierungspartner
3
Monate, bis die Standards gelebt wurden
80 %
der Fälle deckte die erste Version ab
Zu Beginn dieses Programms lagen die technischen Ansätze der Teams weit auseinander. Gemeinsame Standards für Namenskonventionen, Automatisierung je Objekt, Testabdeckung und eine Object Ownership Matrix haben wir deshalb in Etappen eingeführt.
Die erste Version deckte rund 80 Prozent der Fälle ab. Die Randfälle kamen Schritt für Schritt dazu, wenn sie im Projekt auftauchten. Später brachten wir im Programm neue Themen mit Vorlauf in regelmäßigen Center-of-Excellence-Calls auf den Tisch, bevor sie zum Problem wurden. Irgendwann kamen kaum noch neue Randfälle hinzu. Wie die Regeln für mehrere Partner aussehen, beschreibe ich unter Partnersteuerung.
Kleinere Releases brauchen einen festen Weg in die Fachbereiche
Mit einem sauberen Release-Prozess werden Releases kleiner und häufiger. Für Fachbereiche heißt das: öfter kleine Änderungen statt einmal im Quartal ein großes Paket. Damit das funktioniert, brauchen sie einen festen Weg, auf dem sie vorher erfahren, was sich ändert, und einen Rückweg, auf dem sie melden, was im Alltag nicht passt. Vor jedem Release kläre ich mit den Verantwortlichen im Fachbereich, welche Teams betroffen sind, was sich in ihren Abläufen ändert und wer sie informiert. Das steht im Release-Plan, bevor die Entwicklung fertig ist. Nach dem Release prüfe ich, ob die neuen Prozesse genutzt werden, und bringe Rückmeldungen aus dem Alltag in den Backlog.
Prosci stützt sich auf Forschung seit 1998
Prosci ist für mich der Goldstandard im Change Management. Der Grund ist die Forschung dahinter: Prosci befragt seit 1998 Projekte nach ihren Erfahrungen mit Veränderungen.
88 %
der Projekte mit sehr gutem Change Management erreichten ihre Ziele
13 %
waren es bei schlechtem Change Management
7×
so oft erfolgreich
In der 12. Ausgabe der Studie Best Practices in Change Management (öffnet in einem neuen Tab) mit 2.668 Teilnehmenden erreichten Projekte mit sehr gutem Change Management ihre Ziele siebenmal so oft wie Projekte mit schlechtem, 88 gegenüber 13 Prozent. Als wichtigsten Erfolgsfaktor nennen die Teilnehmenden aktives und sichtbares Sponsoring durch das Management. Das deckt sich mit dem, was ich in Salesforce-Programmen erlebe.
Zusammen mit Juliane Winterscheid, die Prosci-zertifiziert ist, habe ich zwei Bausteine von Prosci auf Salesforce-Programme übertragen: das ADKAR-Modell von oben und den Prosci 3-Phase Process (öffnet in einem neuen Tab). Der 3-Phase Process gibt der Einführung auf Ebene der Organisation einen Rahmen: Vorgehen vorbereiten (Prepare Approach), Veränderung steuern (Manage Change) und Ergebnisse sichern (Sustain Outcomes). Die Schritte unter „So läuft die Zusammenarbeit“ folgen diesen Phasen.
Prosci und ADKAR sind eingetragene Marken von Prosci, Inc. Die Prosci-Zertifizierung hat Juliane Winterscheid, nicht FK Solution Design, und FK Solution Design ist kein Partner von Prosci. Diese Seite beschreibt, wie wir Elemente des Vorgehens in Salesforce-Programmen anwenden.
So läuft die Zusammenarbeit
- 01
Vorgehen vorbereiten
Wir legen fest, woran Erfolg gemessen wird, welche Gruppen betroffen sind und was sich für jede im Alltag ändert. Dazu gehören die Risiken und wer im Management die Einführung trägt.
- 02
Veränderung steuern
Je Gruppe entsteht ein Plan entlang der ADKAR-Stufen, verknüpft mit dem Release-Plan. Die häufigsten Fälle kommen zuerst. Wir messen die Nutzung in Salesforce und steuern nach, wo sie hängt.
- 03
Ergebnisse sichern
Wir prüfen, wo Lücken bleiben, verankern neue Regeln in Pipeline, Berichten und Center-of-Excellence-Calls und übergeben die Verantwortung an interne Owner.
Häufig gestellte Fragen
Warum orientieren Sie sich an Prosci?
Weil Prosci für mich der Goldstandard im Change Management ist. Das Vorgehen beruht auf Befragungen seit 1998 mit über 10.000 Teilnehmenden und ist in der Branche weit verbreitet. Es gibt dem Teil eines Salesforce-Programms eine Struktur, der sonst oft dem Zufall überlassen bleibt: ob die Menschen anders arbeiten.
Was ist das ADKAR-Modell?
ADKAR ist ein Modell von Prosci mit fünf Stufen, die jede Person bei einer Veränderung durchläuft: Awareness (Bewusstsein), Desire (Bereitschaft), Knowledge (Wissen), Ability (Fähigkeit) und Reinforcement (Verankerung). Hakt eine Einführung, fehlt meist eine dieser Stufen. Das Modell zeigt, welche.
Wie lange dauert es, neue Standards in einem großen Programm einzuführen?
In meinem größten Programm mit über 30 Entwicklern und fünf Implementierungspartnern hat es etwa drei Monate gedauert. Die erste Version deckte rund 80 Prozent der Fälle ab, die Randfälle kamen nach und nach dazu.
Wer muss beim Change Management mitmachen?
Alle, die die Veränderung betrifft oder die sie tragen: Fachbereiche, Entwicklerteams, Partner und das Management. Ohne Rückhalt im Management fehlen Entscheidungen und Aufmerksamkeit, und neue Regeln werden zur Empfehlung, an die sich nicht jeder hält.
Was ändert sich durch kleinere, häufigere Releases?
Fachbereiche bekommen öfter kleine Änderungen statt selten große Pakete. Das senkt das Risiko einzelner Releases, verlangt aber einen festen Weg, auf dem Betroffene vorher erfahren, was kommt.
Wer dahintersteht
Zwei Spezialgebiete, ein gemeinsamer Plan
Ich verantworte die Salesforce-Architektur, Juliane Winterscheid die Veränderung bei den Menschen. In Ihrem Programm planen wir beides zusammen, damit Release-Plan und Change-Plan zueinander passen.
Fabian KramerArchitektur und Releases
Ich sorge dafür, dass Architektur, Release-Plan und Pipeline die Veränderung tragen, und messe die Nutzung direkt in Salesforce.
Über mich →
Juliane WinterscheidChange Management
Juliane begleitet Sponsoren, Führungskräfte und Key User durch die Veränderung. Sie ist Prosci-zertifiziert und lehrt an der Hochschule Fresenius.
Profil und Referenzen →- Gemeinsam
Ein Plan für Release und Veränderung
Key User, Schulung, Kommunikation und Messung planen wir entlang des Release-Plans. Wie das entlang der ADKAR-Stufen aussieht, zeigt die Masterclass.
Zur Masterclass →
Artikel zum Change Management
Grundlagen von Juliane Winterscheid
Juliane erklärt, was Change Management ist, welche Phasen und Modelle es gibt und wie Werkzeuge wie Stakeholder-Analyse und Kommunikationsplan funktionieren.
Praxis aus Salesforce-Programmen
Ich beschreibe, wie Key User, Schulung, Hypercare und Messung in einer Salesforce-Einführung zusammenspielen.