Paradoxe de Martech #1 : Centraliser et décentraliser

Technologies marketing et opérations marketing (2/4)

martech3-border

Paradoxe de Martech #1 : Centraliser et décentraliser

Scott Brinker
Par Scott Brinker - Editeur chiefmartec.com


Traduit avec la permission de Scott Brinker

Commençons par centraliser et décentraliser. Les organisations sont aux prises avec ce compromis depuis des lustres : plus de pouvoir et de contrôle au centre de l’organisation (p. ex., entreprise) par rapport à plus de liberté et de souplesse en bordure (p. ex., le domaine, les géos, les secteurs d’activité).

Un tel bras de fer alterne les va-et-vient au fil du temps dans une fonction ondulante.

 

 

Les dirigeants en périphérie repoussent les limites pour atteindre leurs objectifs sur le terrain — jusqu’à ce qu’une telle décentralisation commence à menacer l’unité de l’ensemble ou bien l’efficacité globale. Alors en réaction, le centre exige plus de contrôle. Puis, afin d’exécuter les tâches demandées, les gens sur le bord trouvent des manières créatives de répondre aux contraintes centralisées qu’ils jugent trop restrictives. Et le jeu de force se répète.

Nous souhaitons les deux. Nous voulons l’efficacité et la cohésion de la marque apportée par la centralisation — elles nous donnent de la mesure. Cependant, nous voulons aussi l’adaptabilité rapide et l’expérimentation créative de la décentralisation — elles nous donnent de la souplesse.

Mais s’il s’agit d’un compromis, d’un équilibre entre la centralisation et la décentralisation, peut-on améliorer les deux en même temps ? Cela semble être un paradoxe.

Les technologies marketing, à leur meilleur, mettent fin à ce paradoxe. Voici quelques exemples :

Un CMS centralisé fournit des modèles standardisés, avec des barrières bien établies qui empêchent les créateurs de contenu de publier accidentellement des HTML mauvais ou brisés. Pourtant, cela permet aussi à un ensemble beaucoup plus large d’individus en périphérie de l’organisation de créer rapidement et en toute sécurité des pages d’accueil pour des campagnes de lancement et des billets de blogue, sans avoir à passer par une unité de production centrale. C’est une meilleure centralisation et une meilleure décentralisation.

 

 

Les plateformes de données clients (CDP), à la mode de nos jours, offrent un moyen centralisé de rechercher des données dans l’ensemble de l’organisation et de les structurer à l’aide d’une identité client standardisée. Vous pouvez analyser et utiliser ces données séparément de l’application source qui les génère. Par conséquent, bien qu’elles centralisent ces données diverses, les architectures ouvertes des CDP facilitent la prise en charge d’un grand nombre de sources de données réparties à travers l’organisation.

Ce n’est pas parce que les activités de collecte et d’activation de données sont distribuées de manière centrale qu’elles sont pour autant cloisonnées, au contraire. L’accès aux données permet de cette façon de gagner la souplesse de démarrer de nouvelles activités dans l’organisation au besoin, en les adaptant au contexte local dans lequel elles sont appliquées, et ce, sans sacrifier la cohésion et le potentiel offert par les données centralisées.

Encore une fois, une meilleure centralisation et une meilleure décentralisation.

Google Sheets nous montre un exemple encore plus simple. En créant des standards de marque dans un outil communément utilisé pour les feuilles de calcul — un acte de centralisation —, il devient alors plus facile pour n’importe qui dans l’organisation de produire des modèles, de les partager, de collaborer avec d’autres, etc. Ces effets de réseau de la centralisation donnent des avantages croissants aux équipes et aux individus décentralisés. Il n’est pas question de limiter ce qui peut être conçu, mais bien de canaliser cette créativité à travers un conduit efficace qui module la façon dont un produit est créé et distribué.

L’un des exemples les plus avancés est une nouvelle catégorie de logiciels connue sous le nom Application Platform-as-a-Service (aPaaS). Ces plateformes à faible code ou même sans code permettent aux utilisateurs réguliers, c’est-à-dire toute autre personne qu’un ingénieur logiciel, de créer des applications Web, des applications mobiles et des chatbots. Comme un CMS, la plateforme sous-jacente est gérée par une équipe technologique centralisée qui offre de l’autonomie à ces « développeurs citoyens » à travers un ensemble de balises, de sorte qu’ils ne puissent pas accidentellement nuire ou diverger des données de base, des normes ou des politiques qui doivent couvrir la totalité de l’organisation.

Tous ces exemples créent un potentiel centralisé plus évolutif et plus efficace, tout en donnant de l’autonomie et une plus grande fonctionnalité que les équipes décentralisées peuvent exercer de manière créative et agile. Il ne s’agit plus d’un paradoxe.

Quand on y pense, c’est un peu comme la dynamique des plateformes sur le marché en général. La plateforme centralisée de l’iPhone a permis une explosion décentralisée de millions d’applications spécialisées. L’amélioration croissante des plateformes martech centralisées facilite en fait une plus grande diversification des solutions spécialisées et verticales au sein de leurs écosystèmes tiers.

La meilleure façon de renforcer simultanément la centralisation et la décentralisation est de structurer nos compétences centralisées en tant que « plateformes » à utiliser par un « écosystème » décentralisé du reste de l’organisation.

Un excellent guide à suivre dans la poursuite de cette mission est 7 Key Principles of Platform Design de Simone Cicero (disponible en anglais) :

  1. Reconnaître le potentiel qui se développe en périphérie de l’organisation.
  2. Concevoir pour l’émergence — aider de nouvelles compétences à découler d’innovations en périphérie.
  3. Utiliser l’auto-organisation pour fournir de la personnalisation de masse — l’adapter localement avec le contexte.
  4. Permettre l’apprentissage continu en VICA (volatilité, incertitude, complexité et ambiguïté).
  5. Concevoir pour la désobéissance — laisser les créateurs en périphérie plier les règles pour innover.
  6. Concevoir pour l’interconnexion — aider les créateurs en périphérie à se regrouper.
  7. Laisser tomber l’identité, s’identifier au tout — les technologies marketing et les opérations marketing sont la somme du noyau centralisé combiné avec toutes les expérimentations créatives de la périphérie.

 
Platform Revolution (Geoffrey G. Parker, Marshall W. Van Alstyne, Sangeet Paul Choudary) est un livre formidable sur le sujet que vous pouvez adapter aussi aux plateformes internes.

 


Cette article fait partie de la série Technologies marketing et opérations marketing de Scott Brinker. Pour en savoir plus, vous pouvez vous référer aux autres articles de la même série:

Technologies marketing et opérations marketing (1/4) - Les 5 règles du leadership en technologies marketing et opérations marketing

Technologies marketing et opérations marketing (2/4) - Paradoxe de Martech #1 : Centraliser et décentraliser

Technologies marketing et opérations marketing (3/4) - Paradoxe de Martech #2 : Automatiser et humaniser

Technologies marketing et opérations marketing (4/4) - Au-delà du paradoxe : équilibrer les 5 forces

 

Notre infolettre.

Le scénario idéal est plus facile à imaginer qu'à implanter.
Inscrivez-vous à notre infolettre pour savoir par où commencer.