Un des sujet les plus importants en architecture est de savoir s'il convient de rester sur du mono-org ou partir sur du multi-org. Lors de cette session Dreamforce, Allison Park nous présentait une méthodologie pour faire le bon choix.
En général, plus l'entreprise sera grande, plus il sera compliqué de répondre à cette question. En effet, de nombreux facteurs entre en jeu, car il ne s'agit pas ici de choix purement techniques, bien au contraire. Décider d'avoir une ou plusieurs Orgs sera plutôt une orientation qui sera basée des aspects Business.
Déterminer le modèle opérationnel
En architecture d'entreprise, on remonte au plus haut niveau de réflexion, ou d'abstraction. On ne parle pas de technique à ce moment. On se demande pour quel modèle opérationnel Business on va élaborer le projet de CRM. Ou tout autre projet d'ailleurs, c'est toujours le même principe peu importe la technologie.
On a donc besoin d'identifier comment fonctionnera l'entreprise une fois le CRM mis en place, selon deux axes :
L'intégration des processus Business : est-ce que le projet connectera les employés, les données et les applications.
La standardisation des processus Business : est-ce que les processus seront effectués à chaque fois de la même manière et de la manière la plus efficace.
Dans "Enterprise Architecture as Strategy", les auteurs proposaient un schéma qu'Allison Park nous explique comme ci-dessous.
Appliquer la bonne stratégie d'Org
Une fois le modèle opérationnel de votre entreprise établi, on peut déterminer la stratégie d'Org Salesforce à appliquer.
Unification : Les entreprises positionnées dans ce cadrant devraient rester en Mono-Org. C'est le cas le plus simple : des données partagées entre les BU et des processus communs. Exemple : une entreprise qui vend de sa poudre à lessiver, sous 5 marques différentes (bravo aux marketers d'ailleurs).
Réplication : Ces entreprises devraient plutôt utiliser du multi-org, tout en mutualisant les développements par package. On part ici d'un Org dite "principale" depuis laquelle seront livrées les différentes évolutions à l'aide de packages. Dans ce modèle, on a donc des données locales, séparés par Business Unit, tout en conservant une homogénéité dans les processus commerciaux. Exemple : un groupe financier qui pour des raisons légales ne peut partager les données de ses clients entre les différentes BU.
Coordination : Ces entreprises devraient avoir le moins d'Org possible. Dans ce modèle opérationnel, les données sont communes à toutes les Business Units, mais les processus sont indépendants, différents, et impactent ces données partagées. C'est pour cette raison que l'on préfèrera toujours d'avoir le moins d'Org possible, le mieux étant de n'en avoir qu'une seule. La gestion des différents process couplés avec des données partagées devra en effet aller de paire avec une stratégie de gouvernance claire qui représente un coût non négligeable dans le projet. Exemple : une entreprise faisant de la location et de la vente de biens, avec des clients comme Jean-Michel qui est à la fois propriétaire et locataire.
Diversification : En général, ces entreprises partiront toujours sur du Multi-Org. Les modèles de données et les processus métiers sont tellement différents que tenter de les aligner serait quasi mission impossible. De plus les différentes BU ne collaborant pas, il n'y a que peu de chance que l'on arrive à un consensus, même s'il est tout de même possible de mutualiser le développement de certaines fonctionnalités qui devraient s'avérer communes. Exemple : Une entreprise gérant des laboratoires pharmaceutiques, ayant une filiale spécialisée dans la R&D des prothèses.
Revoir sa position
Le choix de la stratégie est donc cruciale, puisqu'elle va déterminer l'organisation du projet tant au niveau technique qu'organisationnel. Et parfois, ces choix sont à reconsidérer quelques années après le lancement de la plateforme, pour un tas de raisons.
D'expérience, les plus courantes que nous ayons rencontrées sont d'une part la gestion des volumes de données ou des transactions qui atteignent un seuil critique (et peuvent exploser certaines governor limites) et d'autre part un problème d'alignement des processus pour lesquels soit on arrive pas à un consensus entre les BU, soit si consensus il y a, demandera une telle complexité de mise en place que ce sera une vraie usine à gaz, ni pérenne, ni maintenable dans le temps.
En opposition au Split des Orgs (expansion), on peut parfois être amenés à les fusionner (rationalisation). C'est déjà plus rare, mais ça existe aussi. C'est le cas d'une entreprise qui rachèterait une autre entreprise et déciderait de ne conserver qu'une seule Org. Et même dans ce cas, il ne suffit pas de se dire qu'on va garder une seule Org parce que "c'est plus facile". Il faudra refaire la même analyse que pour un nouveau projet.
Toujours aller au plus simple
De base, il vaut toujours mieux essayer de rester en Mono-Org parce que ce type de stratégie permettra :
d'avoir une V360 du client, reprenant l'ensemble des produits/services et activités de l'entreprise.
d'avoir une vision claire sur le pipeline global de l'entreprise.
de faire de l'upsell / du cross-sell.
de renforcer la collaboration entre les divers acteurs de l'entreprise et développer la culture interne.
de mettre en place des processus logiques et efficaces de bout-en-bout.
de faire des économies d'échelle.
Contrairement à ce que l'on pourrait penser de prime abord au Multi-Org n'est pas la solution magique. Certes, certains problèmes techniques disparaitront, mais il ne faut pas oublier que le parti pris de la facilité technique apporter également une complexité dans la gouvernance et les processus de déploiement.
Donc avant de mettre la poussière sous le tapis, et de croire qu'une deuxième Org va régler le problème des limites, il vaut mieux s'occuper de la dette technique qui pourrait être responsable de ces problèmes de limites. Avoir une Org avec un mauvais design, que l'on réplique dans une seconde Org, ne sera rien de plus q'une autre Org avec un mauvais design.
Mutualisation des développements par Packages
Dans le cas de la réplication où les données sont séparées dans des Org différentes, mais où les processus métiers sont identiques, il convient d'optimiser les efforts (et donc le budget) de développement.
Les évolutions sont livrées dans une Org (principale) et déployés ensuite par package dans d'autres Org.
Cela permet d'aligner toutes les Orgs sur un même processus métier, et de faire bénéficier les différentes BU (ou Orgs) de nouvelles fonctionnalités demandées par les autres BU.
Cette mutualisation a cependant un coût puisqu'elle demandera la mise en place de solutions de DevOps pour gérer les livraisons.
Et bien sûr un alignement/approbation du Data Model entre toutes les BU. Ce qui peut parfois être impossible à obtenir. La gouvernance devenant alors un véritable casse-tête.
Conclusion
Le choix d'une stratégie Mono-Org vs. Multi-Org est fonction de facteurs Techniques, Business et Organisationnels. On n'en a pas parlé, mais les coûts sont souvent un facteur déterminant. Une solution aura beau être "Ze Solution", si on a pas le budget pour la mettre en place, ce sera toujours la bonne solution, mais seulement sur papier.
Prenez le temps de déterminer les critères les plus importants en terme d'intégration et de standardisation. Tout changement de stratégie est un projet en soi, qui bloquera si non tout, en partie, les évolutions de la solution.
Planifiez la revue de votre stratégie. Rien n'est figé dans le marbre et un architecte devrait toujours pouvoir être capable de remettre en question certaines orientations prises, d'autant plus s'il en est à l'origine.
Voilà pour le contenu de cette session qui présentait un sujet aussi important qu'intéressant.
et un tout grand merci au Speaker pour toutes ces informations :
Allison Park - Principal Enterprise Architect, Salesforce
Comments