Guide des bonnes pratiques du consultant Salesforce en situation de découverte d’une nouvelle organisation

Avant de nous lancer dans un concours de bullet points, il est évident de mettre en exergue certains points :

1 - Chaque situation de projet est unique et nécessite que vous pesiez le pour et le contre de la mise en place des pratiques qui vont être énoncées.

2 - Les conseils de ces prochaines lignes prennent en compte les deux cas de figures : la reprise d’une organisation déjà existante dont vous récupérez la charge et la création d’une nouvelle organisation.

3 - Les points qui vont être abordés sont le fruit de l’expérience de l’auteur de cet article mais sont également issus de conversations avec ses pairs et de lectures de forums d’utilisateurs. Cet article n’a pas vocation à vous fournir une feuille de route mais vous munir des bons réflexes pour faciliter vos futures missions.

4 - Ces informations sont strictement subjectives, il va de soi qu’il y à forcément des meilleures pratiques à vos yeux que celles qui vont suivre, c’est pourquoi l’espace commentaire de notre article Linkedin vous aidera à nous partager vos meilleures pratiques.

Rentrons dans le vif du sujet :

‍

1/ Posez les bonnes fondations de votre futur terrain de travail

Vous venez de vous connecter à votre nouvelle organisation Salesforce, félicitations c’est le moment de vous retrousser les manches !

La première chose sur laquelle vous devez vous penchez est la constitution de votre structure de livraison. Personne n’aime travailler directement en environnement de production à moins d’être sous contrainte (temporelle/budgétaire/utilisateur oppressant derrière votre bureau).

Ce faisant, un de vos premiers réflexes sera de créer, si ce n’est pas déjà fait, des sandboxes qui vous permettront de tester vos futures configurations / développements sans intervenir dans l’espace quasi-sacré que représente l’environnement de production.

Idéalement, il vous faudra vous créer 3 sandboxes afin d’avoir une vision ainsi qu’un processus de livraison cohérent et clair.

1. Sandox développement : cette instance est votre terrain de jeu, et uniquement le vôtre ! Elle vous sert pour tester vos configurations/développements. À l’instar d’une salle du temps, c’est à cet endroit que vous pouvez construire les futures fonctionnalités demandées par vos utilisateurs.
2. Sandbox UAT ( User Acceptance Tests) : Cette instance est le terrain de jeux de vos testeurs, car oui, vous vous devez d’avoir sous la main une ou plusieurs personnes qui auront le loisir de vérifier que vous avez fait un excellent travail ! Cet espace permettra en plus d’avoir des tests réalisés par une personne qui ne connaît pas la magie dont vous avez fait preuve pour faire fonctionner votre réalisation, afin d’effectuer ce travail de recette avec un profil qui est différent de celui d’administrateur système (on se connaît !).
3. Sandbox Pré-prod : L’intérêt de cette dernière instance avant la production est double. Double, car dans la logique, il faudra doter cette instance d’un peu de données clients, afin de pouvoir être sûrs que nos efforts déployés soient d’équerres avec les données de votre production. Si vous disposez de sandboxes full ou partielles, c’est le moment opportun de les utiliser pour profiter des stockages adaptés.
   De plus, bien souvent votre organisation Salesforce va interagir avec des instances externes (ERP/CMS), eux mêmes (très) généralement dotés d’environnements Pré-prod. Votre sandbox de pré-prod sera sans doute légitime pour effectuer des tests d’interfaces entre toutes les instances avant une vraie connexion en production.

Si ces instances sont déjà crées, je vous conseille de les mettre au propre les unes par rapport aux autres le plus régulièrement dans la mesure du possible. Ceci permettra d’éviter les incohérences dans vos futurs développements/configurations/test.

2/ Gardez vos environnements propres et avec le moins de dettes techniques

Par environnement propres, j’entends ici le respect du processus de livraison que vous mettrez en place, et surtout sur le caractère miroir dont vos organisations doivent êtres revêties.

Nous le savons, certaines configurations peuvent êtres difficiles à déployer (coucou CPQ, Conga et autres modules/outils externes ou packagés), et cette difficulté peut dans certains contextes vous forcer à faire des choix.

Si pour gagner du temps et de l’efficacité sur vos livraisons, il vous viendrait l’idée saugrenue de faire vos configurations en UAT (parce qu’il est évident que vous ne ferez JAMAIS de développement directement en production), un écart entre vos différents environnements se creusera irrémédiablement avec le temps. Et c’est la qu’est la faille !

Des environnements avec des différences de configuration vont entrainer à terme de nombreux problèmes chronophages et vous altérer votre vélocité de production. Parmi ces problèmes, nous pouvons d’emblée citer la difficulté de maintenabilité desdits environnements.

En effet, des différences de configurations trop importantes risques d’altérer le bon fonctionnement de vos futurs travaux. Pour l’image, c’est comme si vous aviez deux maisons identiques mais avec des fondations différentes, en y réalisant exactement les mêmes travaux, des résultats seront différents car vos modifications impacteront différemment les fondations de vos maisons, l’une s’écroulera, l’autre tiendra debout !

Bon c’est une métaphore très poussée mais vous avez l’idée. Il en est de même pour la dette technique. A force de configurations, vos travaux souffriront forcément à un moment ou un autre d’un manque d’optimisation. Une règle de validation imprécise, des champs non utilisés et parasites, un flow sans conditions de déclenchement vont à terme entrainer des soucis de maintenabilité de votre organisations.

Le problème étant que les bugs vont s’accumuler et il faudra que vous dégagiez du temps pour réduire cette dette technique, et ce temps vous allez le perdre sur le développement ou la configuration de nouvelles fonctionnalités !

Si vous devez garder une phrase, c’est la suivante : dettes technique importante = problèmes de performances latents.

Essayez donc au maximum d’inclure du temps pour réduire cette dette technique dans vos plannings, plus vous la remettre à loin, plus cette dernière sera difficile à nettoyer. Cela vous évitera bon nombre de déconvenues que vous ne voyez peut-être pas aujourd’hui mais que vous ressentirez demain (et évidemment au plus mauvais moment).

‍“Si vous ne le faites pas, cela sera le problème du prochain consultant dans 2/3 ans”

3/ Mettez en place un processus de tickets pour les demandes utilisateurs

Les demandes vont affluer à partir du moment où votre premier utilisateur va se connecter à votre environnement de production. C’est inévitable car même si vous avez construit une instance en béton, vous n’en êtes pas le principal utilisateur.

Mettre en place un circuit interne de tickets va vous permettre plusieurs choses :

- Dans un premier temps, vous aller pouvoir temporiser vos travaux : trois demandes arrivent en même temps ? Aucun souci, c’est à vous de les prioriser en fonction de leur criticité versus leurs valeurs ajoutées à votre instance. Vous aurez ainsi une vision précise sur les attentes de vos utilisateurs ainsi que sur votre charge de travail à date !

- Dans un second temps, cette bonne habitude va vous permettre de mieux utiliser la structure de livraison évoquée par le point ci-dessus. Fini les déploiements au jour le jour, avec quelques fonctionnalités triées sur le volet, ou encore pire : les développements en prod ! Mettre en place un processus de tickets vous permettra de déployer plus facilement plusieurs fonctionnalités en paquets. Cela vous fera non seulement gagner un temps certain, mais en plus vous permettra de donner plus de lisibilité/visibilité à vos développements (si vous communiquez sur votre travail, ce que vous faites déjà excellemment de toutes façons). Cette bonne pratique induit un concept que je vais m’empresser de présenter et qu’il convient de mettre en avant :

4/ Vous n’êtes pas un héros !

Cette bonne pratique n’en est pas vraiment une, mais se le répéter plusieurs fois peut vous faire du bien !

Alors quand je dis que vous n’êtes pas un héros, je ne remets pas en cause vos aptitudes personnelles en dehors de Salesforce. Ici n’est pas la question, mais dans ce cas, il est préférable d’être conscient (et de le faire savoir) qu’il est illusoire de pouvoir traiter toutes les demandes dans l’immédiat.

Ce conseil est plus général et n'est pas spécifiquement lié à Salesforce, mais je le rappelle parce que vous allez être le seul administrateur : ne jouez pas les héros.

"Le service des ventes dépend de ce flux de travail !"

"Mais le flux doit être rédigé avant la fin de la semaine... sinon !"

"Nous avons appris que la date limite est la semaine prochaine et nous n'avons pas de temps à perdre"

"Ce projet de clôture d'opportunité va changer la donne pour {!Entreprise} pour toujours !"

‍Lorsque vous entendez cela, votre première tendance peut être d'abandonner tout ce que vous faites et d'être le héros. Ce n’est pas qu’on doute du fait que Jean-Gaston ait grand besoin d’avoir un rapport pré-construit sur ses objectifs de vente ou que Jeanne-Gastonne veuille disposer d’un nouveau champ sur sa vue de liste qu’il est nécessaire de le faire dès la demande (et ce, même s'ils sont au demeurant très sympas et qu’ils vous font cette demande en vous apportant un café de demandes passif/agressif )!

C'est une bonne chose à court terme, mais c'est douloureux pour vous et pour l'entreprise à long terme.

Les crises vous paraîtront normales et vous vous retrouverez à sauter d'un feu à l'autre, sans avoir le temps de réfléchir à ce qui est le mieux pour l'instance Salesforce de votre entreprise. Vous dépensez vos capacités mentales en "mode survie".

N’oubliez pas qu’un environnement Salesforce se construit pas à pas au gré des retours de vos utilisateurs. Lever la tête du guidon une paire d’heures par semaine pour se rendre compte du chantier que l’on à devant soi. Cela vous permettra de vous fixer des objectifs clairs et précis.

5/ Impliquez vos utilisateurs

Ce sont eux les utilisateurs finaux, même si ce fait est souvent oublié lors de vos travaux.

Il convient au maximum d’informer vos futurs collègues/clients sur ce qu’il se passe, dans un spectre aussi large que possible.

Vous pouvez par exemple impliquer trois personnes qui s’occuperont de tester vos travaux - une seconde lecture de test avec un œil nouveau est toujours plus perspicace que vous testant votre configuration/développement - sur l’environnement d’UAT (cela tombe bien, c’est son but).

Non seulement, vos retours de tests seront plus précis mais ces utilisateurs pourront remonter d’autres informations/besoins qui amélioreront l’efficacité de vos travaux à venir. De plus, ils pourront parler de ce qu’ils ont vu en avant-première avec leurs collègues et ainsi devenir ambassadeurs de vos travaux.

Il est également de bon ton de communiquer avec l’ensemble des parties prenantes de l’évolution de vos livraisons à venir. En effet, vous pouvez mettre en place la fonctionnalité la plus aboutie jamais réalisée, si personne ne l’utilise car personne ne sait qu’elle existe, c’est quand même un peu bête. Un mail ou même un message sur l’organisation reprenant les évolutions apportées vous permettra de donner une réelle impression de vie à votre organisation. Ainsi, impliquez plus vos collaborateurs qui auront le sentiment que la plateforme évolue avec eux.

6/ Et concrètement ?

Je sais ce que vous vous dites : “ je continue de lire mais ce bougre ne m’a donné encore aucune information réellement pratique, je ressens de la frustration”.

‍Je comprends votre point, c’était le but initial de cet article mais la dérive est rapide vu l’importance du sujet, mais je m’en vais vous contenter avec ces quelques conseils à la volée :

1. Restreignez au maximum les profils administrateurs !
2. Utilisez au maximum les champs/objets/flux/architectures standards pour construire les processus d'entreprise. Le code/ paramétrage custom est toujours plus compliqué à maintenir sur le long terme et rarement réplicable sur d'autres processus.
3. Historisez au maximum les requêtes, changements et autres interventions qui impactent votre organisation !
4. Lorsque vous créez des champs, remplissez les champs texte d'aide/description pour permettre au prochain administrateur de savoir ce que vous avez fait et pourquoi vous l'avez fait. Il vous en sera éternellement redevable.
5. Le schéma Builder détient la vérité !
6. Testez, testez, testez, et retestez ! Et surtout tester en tant qu’utilisateur !
7. Dans la meilleure des mesures, prévoyez pour la croissance de l’outil, et surtout pour une mise à l’échelle.
8. Ne jamais injecter des données de tests en production.
9. D’ailleurs j’en profite pour un rappel de la règle d’or : jamais oh grand jamais de mise en prod le vendredi !

‍

7/ DO-CU-MEN-TEZ

Pour être un bon consultant Salesforce, il ne suffit pas de connaître tous les détails techniques de la plateforme. Il s'agit d'être capable de comprendre le fonctionnement de votre client et de traduire ses flux et ses charges de travail dans l'outil. Salesforce est un terrain de jeu immense et il vous faut avancez par étapes ! Et comme tout bon voyage, il est important d’en faire le récit et de coucher sur le clavier vos travaux, à savoir en priorité :

• Les spécifications fonctionnelles de chaque fonctionnalités, le Graal étant de couvrir l’ensemble de votre organisation
• Les spécification techniques de chaque fonctionnalités : Graal similaire
• Les retours de discussions avec vos clients qui arbitrent les décisions importantes.

Globalement, tout ce qui peut aider votre futur successeur ou vos collègues à la compréhension de la construction de votre organisation est bon à prendre, n’hésitez pas à versionner vos documents s’ils changent afin de retracer les prises de décisions.

Chez 2PACE, nous avons à coeur de mettre en pratique les meilleures pratiques issues des expériences de chaque consultant. Chaque projet, chaque organisation étant unique, chaque expert apporte sa vision sur une situation donnée, en mettant en exergue ce qui fonctionne, mais également ce qui n’a pas marché, afin d’alimenter les points de vues et choisir la résolution la plus appropriée à cette situation.

Et c’est d’ailleurs l’une de notre plus grande force : notre communication ! Qu’elle soit entre nous ou avec les parties prenantes de nos projets. Le plus important reste la compréhension commune d’un besoin donné et de la manière dont le besoin va être satisfait.

Comme évoqué dans le point 4 du préambule de cet article, ces bonnes pratiques n’ont de valeur que si elles apportent une plus value à votre projet, elles ne sont pas nécessaires, mais vous aideront fortement dans votre quotidien si vous les mettez en place.

Allez, maintenant que je vous ai partagé un peu de bonnes pratiques, dites moi celles que j’ai oubliées et qui vous semblent essentielles ! C’est le moment de partager votre connaissance et de nous faire découvrir vos meilleures méthodes en commentaires de nos articles Linkedin !

‍

Petit bonus 1 : liens complémentaires :

• https://tddprojects.atlassian.net/wiki/spaces/SF/pages/58818647/New+Salesforce+Org
• https://wiki.sfxd.org/books/managing-a-salesforce-project/page/auditing-a-salesforce-org
• https://medium.com/@sqlahmansour/soldez-vos-comptes-remboursez-votre-dette-technique-dans-salesforce-d3bfa3ca9bd4

Petit bonus 2 :

Vous saviez que les champs montants de Salesforce peuvent prendre en compte les abréviations ?

Ex : “1K” = “1000“ ou encore “1,3M” se transforme en “1300000”

Petit bonus 3 / Malus :

Cet article à été rédigé via un cerveau avec une intelligence non artificielle !

Pour ceux qui seraient intrigués de connaître la réponse d'une IA à la rédaction d'un guide des bonnes pratiques du consultant Salesforce en situation de découverte d'une nouvelle organisation, je vous invite à suivre notre page Linkedin 2PACE et à attendre la semaine prochaine pour le reveal !