Construire un centre d'excellence Salesforce en partant de zéro

Réponse courte : un centre d'excellence Salesforce est une petite équipe dotée d'un vrai pouvoir de décision sur la plateforme, pas un comité qui se réunit chaque mois pour relire le travail des autres. Dans une entreprise de taille moyenne, quatre rôles à temps partiel et trois artefacts suffisent. La gouvernance échoue quand elle est conçue pour empêcher les décisions plutôt que pour les prendre vite.

Qu'est-ce qu'un centre d'excellence Salesforce, concrètement ?

Retirez le vocabulaire d'entreprise et il ne reste que trois choses :

• Un propriétaire nommé de la plateforme. Une personne responsable du fait que Salesforce serve l'entreprise, pas cinq personnes consultées.
• Une courte liste de décisions qu'elle seule prend. Modèle de données, intégrations, modèle de sécurité, processus de release.
• Un ensemble d'actifs réutilisables pour que le projet suivant démarre à 60% plutôt qu'à zéro.

Tout le reste d'une charte de CoE est soit une réunion, soit un document, et ni l'un ni l'autre ne change ce qui est livré.

En avez-vous besoin à taille moyenne ?

La plupart des conseils sur les CoE visent des orgs de plusieurs milliers d'utilisateurs. Vous n'avez pas besoin de la version grand compte, mais il vous faut quelque chose dès que ces signaux apparaissent :

• Deux départements ont créé des objets qui veulent dire presque la même chose.
• Personne ne sait ce qu'un changement sur Account va casser.
• Chaque projet reconstruit la même intégration ou le même schéma d'approbation.
• Les releases attendent l'agenda d'une seule personne.
• Le backlog est arbitré par celui qui escalade le plus fort.

Deux ou trois de ces signes et vous avez déjà un problème de gouvernance. Vous ne l'avez simplement pas encore nommé.

Qui compose le CoE minimum viable ?

Quatre rôles, et à taille moyenne la plupart s'ajoutent à un poste existant. Résistez à l'envie de créer un département.

• Propriétaire de la plateforme (20-40%). Souvent un responsable produit ou opérations. Il détient la roadmap et sait dire non. Ce rôle ne se partage pas.
• Architecte principal ou admin senior (50%). Détient le modèle de données, le modèle de sécurité et les standards techniques. Relit les changements qui traversent les objets.
• Responsable des releases (20%). Détient le pipeline, les environnements et le calendrier. Souvent la même personne que l'architecte au début, mais écrivez la responsabilité séparément.
• Représentant métier par grande fonction (10% chacun). Ventes, service, finance. Ils apportent la demande et rapportent les décisions à leurs équipes. Ils ne sont pas là pour approuver le travail technique.

Quatre personnes, environ 1,2 équivalent temps plein. C'est tout. Un CoE qui exige six recrutements avant de fonctionner sautera au prochain arbitrage budgétaire.

Quelles décisions le CoE possède-t-il, et lesquelles non ?

C'est la partie que les équipes sautent, et la seule qui détermine la survie du CoE. Écrivez deux listes explicites.

Le CoE décide : les changements sur les objets partagés et le modèle de données, les nouvelles intégrations et les systèmes de référence derrière, le modèle de sécurité et de partage, le processus de release et ses portes, quelles capacités deviennent des composants réutilisables, et le contenu de la roadmap.

Le CoE ne décide pas : la mise en page des rapports et tableaux de bord, les ajustements de page layout sur les objets propres d'une équipe, la formulation des libellés, ou laquelle de deux implémentations également valables un développeur choisit. Cela revient à ceux qui font le travail.

La seconde liste compte plus que la première. Un organe qui relit tout devient une file d'attente, et une file d'attente se contourne. En deux trimestres, les gens construiront dans leur propre sandbox et demanderont pardon ensuite, c'est-à-dire exactement l'état que le CoE devait faire cesser.

Pourquoi les comités échouent et les petites équipes non

Un comité optimise le consensus, donc sa réponse par défaut est le report. Une équipe optimise le débit, donc sa réponse par défaut est une décision, parfois mauvaise. Sur une plateforme où un mauvais champ se renomme au sprint suivant mais où une roadmap bloquée coûte un an, l'équipe gagne cet arbitrage à chaque fois.

Trois règles maintiennent l'équipe :

1. Les décisions ont une échéance. Ce qui n'est pas tranché en une semaine bascule sur la recommandation de l'architecte. Le silence vaut accord.
2. Réunion hebdomadaire de 45 minutes, pas mensuelle de deux heures. Une cadence courte produit de petites décisions, celles qui sont réversibles.
3. Publiez des décisions, pas des comptes rendus. Une ligne par décision, avec la raison et la date. Ce journal devient le document de standards que personne n'avait le temps d'écrire.

Que doit-il produire en 90 jours ?

1. Jours 1-30 : le document de droits de décision ci-dessus, et un inventaire honnête de l'existant. Objets, intégrations, automatisation, dette technique, qui possède quoi.
2. Jours 31-60 : le processus de release. Un pipeline, un jeu d'environnements, des portes d'approbation par environnement, et aucun changement direct en production.
3. Jours 61-90 : les deux premiers composants réutilisables. Prenez les schémas que vous avez déjà construits deux fois, packagez-les proprement et servez-vous-en au projet suivant.

Ce troisième point transforme le CoE d'un coût en un actif. Construire des produits nous l'a appris à la dure : chez Tekunda, nous travaillons comme SI, ISV et PDO Salesforce, et c'est précisément la rigueur de packaging venue du produit qui permet à une équipe de livraison de mettre en production en semaines plutôt qu'en mois. Un CoE qui produit des pièces réutilisables se finance lui-même. Un CoE qui produit des documents de politique se fait couper.

FAQ

Quelle taille pour un CoE Salesforce ?

À taille moyenne, quatre rôles totalisant environ un à un et demi équivalent temps plein. N'ajoutez des personnes que si une décision précise attend en permanence faute de capacité.

Le CoE doit-il être rattaché à l'IT ou au métier ?

Ni exclusivement l'un ni l'autre. Le propriétaire de la plateforme vient du métier, l'architecte de l'IT, avec un rattachement conjoint. Un CoE entièrement IT s'éloigne de la demande, un CoE entièrement métier s'éloigne de l'architecture.

Quelle différence entre un CoE et un comité de gouvernance ?

Un comité de gouvernance relit des décisions prises ailleurs. Un CoE les prend et répond du résultat. Si votre CoE ne fait que relire, vous avez construit un comité.

Comment savoir si le CoE fonctionne ?

Le délai entre la demande et la production baisse, le nombre de changements hors processus de release tend vers zéro, et chaque projet réutilise plus qu'il ne reconstruit.