Ein Salesforce Center of Excellence von Grund auf aufbauen

Kurze Antwort: Ein Salesforce Center of Excellence ist ein kleines Team mit echten Entscheidungsrechten über die Plattform, kein Gremium, das monatlich die Arbeit anderer durchsieht. Im Mittelstand genügen vier Teilzeitrollen und drei Artefakte. Governance scheitert, wenn sie darauf ausgelegt ist, Entscheidungen zu verhindern, statt sie schnell zu treffen.

Was ist ein Salesforce Center of Excellence wirklich?

Ohne Konzernvokabular bleiben drei Dinge:

• Ein benannter Eigentümer der Plattform. Eine Person, die dafür geradesteht, ob Salesforce dem Geschäft dient, nicht fünf, die konsultiert werden.
• Eine kurze Liste von Entscheidungen, die nur sie trifft. Datenmodell, Integrationen, Sicherheitsmodell, Release-Prozess.
• Ein Satz wiederverwendbarer Bausteine, damit das nächste Projekt bei 60% statt bei null startet.

Alles andere in einer CoE-Charta ist entweder ein Termin oder ein Dokument, und beides ändert nichts daran, was ausgeliefert wird.

Brauchen Sie eines im Mittelstand?

Die meisten CoE-Ratgeber zielen auf Orgs mit Tausenden Nutzern. Sie brauchen nicht die Konzernversion, aber etwas, sobald diese Signale auftreten:

• Zwei Abteilungen haben überlappende Objekte gebaut, die fast dasselbe bedeuten.
• Niemand kann sagen, was eine Änderung an Account kaputt macht.
• Jedes Projekt baut dieselbe Integration oder dasselbe Freigabemuster neu.
• Releases warten auf den Kalender einer Person.
• Das Backlog entscheidet, wer am lautesten eskaliert.

Zwei oder drei davon, und Sie haben bereits ein Governance-Problem. Sie haben es nur noch nicht benannt.

Wer sitzt im minimal tragfähigen CoE?

Vier Rollen, im Mittelstand meist Teil bestehender Jobs. Widerstehen Sie dem Reflex, eine Abteilung zu besetzen.

• Plattform-Eigentümer (20-40%). Meist eine Produkt- oder Ops-Führungskraft. Hält die Roadmap und sagt Nein. Diese Rolle lässt sich nicht teilen.
• Lead Architect oder Senior Admin (50%). Hält Datenmodell, Sicherheitsmodell und technische Standards. Prüft Änderungen über Objektgrenzen hinweg.
• Release-Verantwortlicher (20%). Hält Pipeline, Umgebungen und Release-Kalender. Anfangs oft dieselbe Person wie der Architekt, aber schreiben Sie die Verantwortung getrennt auf.
• Fachvertretung je Hauptfunktion (je 10%). Vertrieb, Service, Finanzen. Sie bringen Bedarf ein und tragen Entscheidungen zurück. Sie sind nicht da, um technische Arbeit freizugeben.

Vier Personen, rund 1,2 Vollzeitäquivalente. Mehr ist es nicht. Ein CoE, das sechs Neueinstellungen braucht, bevor es arbeitet, fällt der nächsten Budgetrunde zum Opfer.

Welche Entscheidungen gehören dem CoE, welche nicht?

Diesen Teil überspringen Teams, und er allein entscheidet über das Überleben. Schreiben Sie zwei ausdrückliche Listen.

Das CoE entscheidet: Änderungen an gemeinsamen Objekten und am Datenmodell, neue Integrationen und die führenden Systeme dahinter, das Sicherheits- und Sharing-Modell, den Release-Prozess und seine Gates, welche Fähigkeiten als wiederverwendbare Komponenten entstehen, und was auf die Roadmap kommt.

Das CoE entscheidet nicht: Layouts von Berichten und Dashboards, Page-Layout-Anpassungen innerhalb der eigenen Objekte eines Teams, Formulierungen von Feldbezeichnungen, oder welche von zwei gleich gültigen Umsetzungen ein Entwickler wählt. Das gehört denen, die die Arbeit machen.

Die zweite Liste wiegt schwerer als die erste. Ein Gremium, das alles prüft, wird zur Warteschlange, und Warteschlangen werden umgangen. Binnen zwei Quartalen bauen Leute in ihrer eigenen Sandbox und bitten hinterher um Verzeihung, also genau der Zustand, den das CoE beenden sollte.

Warum Gremien scheitern und kleine Teams nicht

Ein Gremium optimiert auf Konsens, seine Standardantwort ist also Vertagung. Ein Team optimiert auf Durchsatz, seine Standardantwort ist eine Entscheidung, manchmal eine falsche. Auf einer Plattform, wo ein falsches Feld im nächsten Sprint umbenannt wird, eine blockierte Roadmap aber ein Jahr kostet, gewinnt das Team diesen Tausch immer.

Drei Regeln halten es zum Team:

1. Entscheidungen haben eine Frist. Was in einer Woche nicht entschieden ist, fällt auf die Empfehlung des Architekten zurück. Schweigen ist Zustimmung.
2. Wöchentlich 45 Minuten, nicht monatlich zwei Stunden. Kurze Taktung bedeutet kleine Entscheidungen, und die sind umkehrbar.
3. Veröffentlichen Sie Entscheidungen, keine Protokolle. Eine Zeile je Entscheidung, mit Grund und Datum. Dieses Log wird das Standarddokument, für das nie Zeit war.

Was liefert es in den ersten 90 Tagen?

1. Tag 1-30: das Dokument zu Entscheidungsrechten und eine ehrliche Bestandsaufnahme. Objekte, Integrationen, Automatisierung, technische Schuld, wem was gehört.
2. Tag 31-60: der Release-Prozess. Eine Pipeline, ein Satz Umgebungen, Freigabe-Gates je Umgebung und keine direkten Änderungen in der Produktion.
3. Tag 61-90: die ersten zwei wiederverwendbaren Komponenten. Nehmen Sie die Muster, die Sie schon zweimal gebaut haben, paketieren Sie sie sauber und nutzen Sie sie im nächsten Projekt.

Der dritte Punkt macht aus dem CoE ein Aktivum statt eines Gemeinkostenblocks. Produkte zu bauen hat uns das auf die harte Tour beigebracht: Bei Tekunda arbeiten wir als Salesforce SI, ISV und PDO, und genau die Paketierungsdisziplin aus der Produktseite bringt ein Delivery-Team in Wochen statt Monaten live. Ein CoE, das wiederverwendbare Teile liefert, finanziert sich selbst. Ein CoE, das Richtlinienpapiere liefert, wird gestrichen.

FAQ

Wie groß sollte ein Salesforce CoE sein?

Im Mittelstand vier Rollen mit zusammen rund einem bis anderthalb Vollzeitäquivalenten. Personal erst aufstocken, wenn eine konkrete Entscheidung dauerhaft auf Kapazität wartet.

Gehört das CoE in die IT oder ins Business?

In keines allein. Der Plattform-Eigentümer kommt aus dem Business, der Architekt aus der IT, mit gemeinsamer Berichtslinie. Ein rein IT-getriebenes CoE entfernt sich vom Bedarf, ein rein fachliches von der Architektur.

Was unterscheidet ein CoE von einem Governance-Board?

Ein Governance-Board prüft Entscheidungen, die anderswo fallen. Ein CoE trifft sie und haftet für das Ergebnis. Prüft Ihr CoE nur, haben Sie ein Board gebaut.

Woran erkennen Sie, dass das CoE funktioniert?

Die Zeit von der Anforderung bis zur Produktion sinkt, Änderungen außerhalb des Release-Prozesses gehen gegen null, und jedes Projekt verwendet mehr wieder, als es neu baut.