Was bedeutet Reinforcement im Change Management?

Reinforcement ist im ADKAR-Modell von Prosci die fünfte Stufe: Maßnahmen, die dafür sorgen, dass eine Veränderung bleibt und niemand in alte Gewohnheiten zurückfällt.

Warum halten sich Partner nicht an vereinbarte Standards?

Meist nicht aus Absicht. Neue Entwickler kennen die Standards nicht, unter Termindruck werden Ausnahmen gemacht, und wenn niemand prüft, wird aus der Ausnahme die Regel.

Wie lange dauert es, bis Standards bei mehreren Partnern gelebt werden?

In meinem größten Programm mit fünf Partnern etwa drei Monate. Danach kamen nur noch einzelne Randfälle dazu, die im Center-of-Excellence-Call besprochen wurden.

Gehören Standards in den Vertrag mit dem Partner?

Ja, als Verweis auf die geltende Fassung beim Kunden. So ist klar, dass eine Lieferung, die gegen die Standards verstößt, nicht abgenommen ist.

Reinforcement: Standards bei Partnern verankern

Reinforcement ist die letzte Stufe im ADKAR-Modell: dafür sorgen, dass eine Veränderung bleibt. Bei Salesforce-Partnern ist das die schwierigste Stufe, weil Standards nach einigen Monaten verwässern, wenn neue Entwickler dazukommen und der Termindruck steigt. Verankert werden sie an drei Stellen: in der Pipeline für alles, was sich automatisch prüfen lässt, im Pull-Request-Review für den Rest und in einem regelmäßigen Center-of-Excellence-Call, in dem neue Randfälle besprochen werden. Dauerhaft halten sie erst, wenn ein interner Verantwortlicher sie führt.

Warum verwässern Standards bei Partnern?

Die erste Einführung neuer Standards läuft meist gut. Die Teams sind aufmerksam, die Regeln sind neu, und jemand schaut genau hin. Nach einigen Monaten ändern sich drei Dinge:

Neue Entwickler kommen. Partner tauschen Personen aus, und wer neu ins Team kommt, kennt die Standards nur aus einem Dokument, wenn überhaupt.
Der Termindruck steigt. Vor einem wichtigen Release wird eine Ausnahme gemacht, „nur dieses Mal“. Wenn niemand prüft, wird aus der Ausnahme die Regel.
Die Aufmerksamkeit lässt nach. Wer anfangs jeden Pull Request geprüft hat, hat inzwischen andere Aufgaben.

Im ADKAR-Modell fehlt dann nicht das Wissen, sondern die Verankerung. Ein Beispiel: Wenn die Entwickler eines Partners die Namenskonventionen kennen, aber niemand sie in der Pipeline prüft, fehlt Reinforcement. Eine weitere Schulung ändert daran nichts. Dann gehört eine automatische Prüfung in den Release-Prozess.

Jeder Hebel verankert einen anderen Teil der Standards

Zusammen lassen die Hebel wenig Raum für stilles Verwässern:

Hebel	Was er verankert	Wer
Automatische Prüfung in der Pipeline	Namen, verbotene Muster, Testabdeckung, Validierung gegen die Ziel-Org	läuft bei jedem Pull Request
Pull-Request-Review	Design, Verantwortung für Objekte, Passung zur Architektur	Reviewer auf Kundenseite
Center-of-Excellence-Call	neue Randfälle, anstehende Änderungen mit Vorlauf	technische Leads der Streams
Einarbeitung neuer Entwickler	Kenntnis der geltenden Fassung	Partner, geprüft vom Kunden
Vertrag	Standards als Abnahmekriterium	Einkauf, Programmleitung
Übergabe an internen Verantwortlichen	Fortbestand nach dem Projekt	Kunde

Die Pipeline ist der günstigste Hebel, weil sie nie müde wird. Was dort geprüft wird, muss kein Reviewer mehr anmerken. Welche Regeln in die Standards gehören und was davon automatisch geht, beschreibe ich in Salesforce-Entwicklungsstandards für mehrere Partner.

Der Center-of-Excellence-Call klärt neue Randfälle

Standards sind nie fertig. Neue Fälle tauchen auf, etwa ein Stream, der ein Feld auf einem fremden Objekt braucht. Ohne festen Ort werden diese Fälle zwischen zwei Entwicklern entschieden, und jeder Partner entscheidet anders. Ein regelmäßiger Call mit den technischen Leads aller Streams gibt ihnen einen Ort. Jede Entscheidung dort wird in die Standards übernommen.

Der Call hat einen zweiten Effekt, der für Reinforcement fast wichtiger ist: Die technischen Leads tragen die Entscheidungen in ihre Teams. Ein neuer Entwickler erfährt eine Regel dann von seinem eigenen Lead, nicht aus einem Dokument des Kunden. Format und Rhythmus beschreibe ich in Salesforce Center of Excellence: Format und Rhythmus.

Wie arbeiten Sie neue Entwickler eines Partners ein?

Jeder Personalwechsel beim Partner ist ein kleiner Neustart. Ich empfehle eine kurze, feste Einarbeitung, die der Partner verantwortet und der Kunde prüft: die geltenden Standards, die Object Ownership Matrix, der Weg eines Pull Requests durch die Pipeline und die wichtigsten Einträge aus dem Entscheidungslog. Der erste Pull Request eines neuen Entwicklers bekommt ein ausführlicheres Review als üblich, damit Missverständnisse früh auffallen. Das kostet einen halben Tag und spart Wochen an Korrekturen. Je öfter ein Partner Personen austauscht, desto mehr lohnt es sich, deshalb gehört die Einarbeitung als Pflicht in die Vereinbarung mit dem Partner.

Ausnahmen unter Termindruck brauchen eine Begründung und ein Ticket

Ausnahmen wird es geben. Entscheidend ist, dass sie sichtbar sind. Eine Ausnahme von den Standards braucht im Pull Request eine Begründung und ein Ticket, das die Korrektur im nächsten Release einplant. So bleibt die Ausnahme eine Ausnahme. Häufen sich Ausnahmen bei einer Regel, gehört die Regel in den nächsten Center-of-Excellence-Call: Entweder passt sie nicht, oder der Plan lässt zu wenig Zeit.

Was gehört in den Vertrag?

Ein Vertrag ersetzt kein Review, aber er macht klar, was gilt. Ich empfehle, im Vertrag mit jedem Partner auf die geltende Fassung der Standards beim Kunden zu verweisen, nicht auf eine Kopie im Anhang. Dann gilt jede Änderung aus dem Center-of-Excellence-Call ohne neue Verhandlung. Und eine Lieferung, die gegen die Standards verstößt, ist nicht abgenommen. Für KI-generierten Code gilt dasselbe, siehe Partner codet mit KI: Was in den Vertrag gehört.

Woran erkennen Sie, dass Standards verankert sind?

Drei Zeichen zeigen es. Reviewer merken seltener dieselben Punkte an, weil die Pipeline sie vorher findet. Neue Randfälle kommen im Center-of-Excellence-Call auf den Tisch, bevor sie gebaut sind, statt danach als Konflikt. Und neue Entwickler eines Partners halten die Regeln ein, ohne dass jemand sie einzeln erklärt. In meinem Programm fielen die Randfälle irgendwann ganz weg, weil Themen besprochen wurden, bevor sie zu Konflikten wurden.

Wiederkehrende Review-Anmerkungen zählen

Sehen Sie sich die Review-Kommentare der letzten zwei Monate an und zählen Sie, welche Anmerkungen sich wiederholen. Jede Anmerkung, die sich automatisch prüfen lässt, kommt in die Pipeline, mit einer klaren Fehlermeldung, die den Standard nennt. Typische Kandidaten sind Namenskonventionen, fest eingetragene IDs im Code und Felder ohne Beschreibung; der Salesforce Code Analyzer oder eine eigene Regel in der Pipeline findet sie, bevor ein Reviewer sie sieht. Für den Rest richten Sie einen festen Call mit den technischen Leads ein. Und planen Sie von Anfang an, wer auf Kundenseite die Standards übernimmt, wenn das Projekt endet. Wie ich das mit mehreren Partnern aufsetze, beschreibe ich unter Partnersteuerung.