Een Salesforce center of excellence vanaf nul opbouwen

Kort antwoord: een Salesforce center of excellence is een klein team met echte beslisbevoegdheid over het platform, niet een commissie die maandelijks het werk van anderen doorneemt. In het middensegment bouwt u er een met vier deeltijdrollen en drie artefacten. Governance faalt zodra die is ontworpen om beslissingen te voorkomen in plaats van ze snel te nemen.

Wat is een Salesforce center of excellence eigenlijk?

Haal het ondernemingsjargon eraf en een CoE is drie dingen:

• Een benoemde eigenaar van het platform. Eén persoon die verantwoordelijk is of Salesforce het bedrijf dient, niet vijf die geraadpleegd worden.
• Een korte lijst beslissingen die alleen zij nemen. Datamodel, integraties, beveiligingsmodel, releaseproces.
• Een set herbruikbare bouwstenen zodat het volgende project op 60% begint in plaats van op nul.

Al het overige in een CoE-charter is een vergadering of een document, en geen van beide verandert wat er live gaat.

Heeft u er een nodig in het middensegment?

De meeste CoE-adviezen zijn geschreven voor orgs met duizenden gebruikers. U hebt de enterprise-versie niet nodig, maar wel iets zodra deze signalen verschijnen:

• Twee afdelingen hebben overlappende objecten gebouwd die vrijwel hetzelfde betekenen.
• Niemand kan zeggen wat een wijziging aan Account breekt.
• Elk project bouwt dezelfde integratie of hetzelfde goedkeuringspatroon opnieuw.
• Releases wachten op de agenda van één persoon.
• De backlog wordt bepaald door wie het hardst escaleert.

Twee of drie daarvan en u hebt al een governanceprobleem. U hebt het alleen nog geen naam gegeven.

Wie zitten er in de minimale CoE?

Vier rollen, en in het middensegment zijn de meeste onderdeel van iemands bestaande baan. Weersta de neiging een afdeling te bemensen.

• Platformeigenaar (20-40%). Meestal een product- of ops-leider. Eigenaar van de roadmap en degene die nee zegt. Deze rol kan niet gedeeld worden.
• Lead architect of senior beheerder (50%). Eigenaar van datamodel, beveiligingsmodel en technische standaarden. Beoordeelt wijzigingen die objectgrenzen overschrijden.
• Release-eigenaar (20%). Eigenaar van pipeline, omgevingen en releasekalender. Vaak in het begin dezelfde persoon als de architect, maar leg de verantwoordelijkheid apart vast.
• Businessvertegenwoordiger per hoofdfunctie (10% elk). Sales, service, finance. Zij brengen vraag in en nemen besluiten terug naar hun teams. Ze zijn er niet om technisch werk goed te keuren.

Vier mensen, samen ruwweg 1,2 fte. Dat is het geheel. Een CoE die zes nieuwe mensen nodig heeft voordat hij kan draaien, sneuvelt bij de volgende begrotingsronde.

Welke beslissingen bezit de CoE, en welke niet?

Dit deel wordt overgeslagen, en het bepaalt als enige of de CoE overleeft. Schrijf twee expliciete lijsten.

De CoE beslist: wijzigingen aan gedeelde objecten en het datamodel, nieuwe integraties en de bronsystemen erachter, het beveiligings- en deelmodel, het releaseproces en de gates, welke capaciteiten als herbruikbare componenten worden gebouwd, en wat op de roadmap komt.

De CoE beslist niet: indeling van rapporten en dashboards, page-layoutaanpassingen binnen de eigen objecten van één team, formuleringen van veldlabels, of welke van twee even geldige implementaties een ontwikkelaar kiest. Die horen bij de mensen die het werk doen.

De tweede lijst telt zwaarder dan de eerste. Een orgaan dat alles beoordeelt wordt een wachtrij, en om een wachtrij heen wordt gewerkt. Binnen een paar kwartalen bouwen mensen in hun eigen sandbox en vragen ze achteraf vergiffenis, precies de toestand die u met de CoE wilde beëindigen.

Waarom commissies falen en kleine teams niet

Een commissie optimaliseert op consensus, dus haar standaardantwoord is uitstel. Een team optimaliseert op doorstroom, dus het standaardantwoord is een besluit, soms een verkeerd besluit. Op een platform waar een verkeerd veld volgende sprint hernoemd kan worden maar een stilstaande roadmap een jaar kost, wint het team die ruil elke keer.

Drie regels houden het een team:

1. Besluiten hebben een deadline. Wat binnen een week niet besloten is, valt terug op het advies van de architect. Stilte is instemming.
2. Vergader wekelijks 45 minuten, niet maandelijks twee uur. Korte cadans betekent kleine besluiten, en die zijn omkeerbaar.
3. Publiceer besluiten, geen notulen. Eén regel per besluit, met reden en datum. Dat logboek wordt het standaardendocument waar niemand tijd voor had.

Wat levert het op in de eerste 90 dagen?

1. Dag 1-30: het bovenstaande document met beslisbevoegdheden, en een eerlijke inventarisatie van wat er is. Objecten, integraties, automatisering, technische schuld, wie wat bezit.
2. Dag 31-60: het releaseproces. Eén pipeline, één set omgevingen, approval gates per omgeving, en geen directe wijzigingen in productie.
3. Dag 61-90: de eerste twee herbruikbare componenten. Kies de patronen die u al twee keer hebt gebouwd, verpak ze netjes en gebruik ze in het volgende project.

Dat derde punt maakt van een CoE een bezit in plaats van overhead. Producten bouwen leerde ons dat op de harde manier: bij Tekunda werken we als Salesforce SI, ISV en PDO, en juist de packagingdiscipline uit de productkant laat een deliveryteam nieuw werk in weken in plaats van maanden live brengen. Een CoE die herbruikbare onderdelen oplevert betaalt zichzelf terug. Een CoE die beleidsstukken oplevert wordt geschrapt.

FAQ

Hoe groot moet een Salesforce CoE zijn?

In het middensegment vier rollen, samen ongeveer één tot anderhalf fte. Voeg pas mensen toe als een concreet besluit structureel op capaciteit wacht.

Hoort de CoE bij IT of bij de business?

Bij geen van beide exclusief. De platformeigenaar komt uit de business, de architect uit IT, met gezamenlijke rapportage. Een CoE volledig van IT dwaalt af van de vraag, een volledig van de business dwaalt af van de architectuur.

Wat is het verschil tussen een CoE en een governance board?

Een governance board beoordeelt besluiten die elders zijn genomen. Een CoE neemt ze en is verantwoordelijk voor de uitkomst. Beoordeelt uw CoE alleen, dan hebt u een board gebouwd.

Hoe weet u dat de CoE werkt?

De tijd van verzoek tot productie daalt, het aantal wijzigingen buiten het releaseproces nadert nul, en elk project hergebruikt meer dan het opnieuw bouwt.