Des dinosaures et des météores: 2 modèles différents (et controversés) d’adoption technologique

Mon garçon, est-ce que j'ai battu un nid de frelons

Il y a quelques semaines, j'ai partagé un article de MIT Sloan Management Review . Premièrement, posez des questions plus tard (ou pas du tout) de Stephen J. Andriole. Résumé rapide:

En raison des outils SaaS faciles à acquérir et de la pression exercée pour exploiter les possibilités relativement inconnues des technologies émergentes avant leurs concurrents, les entreprises contournent de plus en plus les processus lourds de «collecte des exigences» des systèmes d’information classiques en entreprise. au lieu de cela, essayez plus rapidement de nouvelles applications logicielles pour voir ce qui fonctionne. Certaines de ces adoptions itèrent et évoluent. Certains sont jetés sur le tas de ferraille.

Crikey, y a-t-il eu des commentaires polarisés en réaction à cette action!

Certaines personnes ont convenu avec enthousiasme: ceux qui ne l'avaient pas fait étaient des dinosaures qui marchaient à l'extinction. D’autres se sont vivement opposés: ceux qui ont agi de la sorte étaient des météores, qui se dirigeaient vers la désintégration dans un accident violent.

De toute évidence, il existe une large bande de milieu entre ces deux extrêmes. Mais je n’ai pas vu cette réponse dramatique et divisée depuis que je pensais que les spécialistes du marketing devraient peut-être gérer leurs propres piles de technologies il ya 10 ans. («Meurs, démon du démon!)

Franchement, j'ai été surpris. En substance, l'article révélait simplement un autre cas de chute agile dépassant agile. Je ne pensais plus que cela était considéré comme radical. Et, empiriquement, ne voyons-nous pas tous des tonnes d'exemples de personnes essayant des applications SaaS avec une fraction des coûts liés aux achats des dernières décennies?

J'ai donc passé un tour pour illustrer les deux modèles côte à côte – un brouillon de l'illustration en haut de ce post . J'ai pensé qu'en voyant l'avantage du délai d'adoption et la preuve organique de l'utilité de l'approche «agile», les opposants du précédent fil conducteur admettraient que l'approche agile pouvait être bonne dans de nombreuses circonstances.

Cela donnait de nouveaux coups de pied dans le nid de frelons, sur les débats Twitter et LinkedIn .

Mais le débat de mêlée qui s'ensuivit fit surface. Premièrement, même si nous considérons que ces deux modèles constituent un choix binaire (l'un ou l'autre, ce qui n'est clairement pas le cas), chacun a plus de sens.

Dans les situations où les coûts d'adoption sont plus élevés – en particulier si le coût de l'adoption même est élevé – ou s'il existe des risques ou des dépendances plus importants autour de l'adoption, le modèle de cascade est probablement un meilleur ajustement. Les enjeux sont plus importants et tester et apprendre est moins attrayant. Le logiciel de pilote automatique pour un avion à réaction, par exemple.

Mais il y a un deuxième axe à considérer: la certitude . Ou plutôt, l'incertitude.

L'agile était fait pour l'incertitude

Les approches en cascade reposent sur l'hypothèse que vous savez réellement ce qui fonctionnera. Plus vous avez la certitude – à un horizon temporel raisonnable bien entendu – que vous êtes mieux en mesure de planifier à l'avance la bonne solution et d'optimiser votre adoption.

Mais je suggérerais humblement que, dans le contexte actuel de perturbations et changements technologiques rapides – la ligne de fond exponentielle de la loi de Martec – nous opérons souvent dans une incertitude beaucoup plus grande. C’est certainement (ha!) Le cas en marketing.

L’incertitude pousse les projets dans la partie gauche du graphique ci-dessus, ce qui rend agile préférable dans davantage de circonstances, même lorsque les coûts et le risque sont importants.

Après tout , risk existe à la fois dans les approches agiles et dans les approches en cascade. Ils sont juste différents types de risques :

Vous pouvez choisir le groupe de risques que vous préférez, mais aucun déjeuner gratuit.

Cependant, le modèle agile a pour inconvénient que les coûts et les risques pour les pilotes test-and-learn sont généralement considérés comme relativement peu importants. Et les risques associés à la mise à l'échelle n'entrent en jeu que lorsque le projet pilote a été un succès – à ce stade, vous avez sans doute atténué le risque le plus important de l'adoption d'un logiciel: cette application produira-t-elle réellement les résultats souhaités?

Freemium abaisse la courbe coût / risque

À l'ère du logiciel-service (SaaS), le coût direct associé à la mise à l'essai de nouvelles applications logicielles a également considérablement diminué. Les modèles SaaS destinés au marché, tels que freemium, les essais gratuits, les achats intégrés, la tarification transparente et évolutive, même pour les logiciels dits «d'entreprise», sont de plus en plus répandus, ce qui permet aux acheteurs d'essayer plus facilement des applications avec des essais moins étendus.

Je sais qu'il existe encore un débat sur les modèles freemium-ish dans les logiciels d'entreprise. Mais Box, Canva, Dropbox, G-Suite, GitHub, LinkedIn, Slack, Zoom, etc., ont prouvé que ce n’était certainement pas un mythe. Cela peut ne pas convenir à chaque application ou plate-forme, bien sûr. Mais les acheteurs exigent de plus en plus un meilleur alignement entre la tarification des fournisseurs et une adoption plus agile des logiciels.

Les déploiements de logiciels à la volée, de type big bang, sont de moins en moins attrayants.

Cela ne veut pas dire qu'il n'y en a pas non plus. coûts liés à l'adoption de logiciels autres que le prix direct de l'application, tels que l'intégration et la formation.

Mais même ces coûts diminuent progressivement, grâce à de meilleures intégrations dans des écosystèmes de plates-formes en expansion – vous saviez que j'allais relier cela à la plate-forme en pensant d'une certaine manière, n'est-ce pas? – et à de meilleurs flux UX et d'intégration associés à la consumérisation de l'informatique.

Une approche agile ne travailler pour tout. Mais cela fonctionne dans plus de scénarios que vous ne l'auriez imaginé il y a quelques années.

Concrètement, Waterfall et Agile sont mélangés

Je me suis longtemps battu contre les fausses dichotomies sur ce blog . surtout quand il s'agit de être agile ou stratégique . Nous avons une variation sur ce thème ici.

Il existe très peu de projets «purs» en cascade ou agiles dans la nature. Presque tout ce que nous faisons a un certain degré de planification et d’adaptation en cours de route. Tous les bons projets agiles commencent par un besoin, une hypothèse, un «travail à faire» lié à la valeur commerciale.

Au lieu d'argumenter les extrêmes, nous devrions être en mesure de convenir que la plupart des projets logiciels se déroulent dans un continuum entre ces deux pôles:

Cependant, je dirais que le point de consigne de l'adoption de la technologie tout au long de ce continuum s'est progressivement déplacé vers la droite. Et qu'au cours de cette décennie, nous avons assisté à un saut significatif vers la fin agile du spectre.

Je vous laisse avec cette citation de l'article d'Andriole dans MIT Sloan Management Review :

Nous avons entendu un thème cohérent. Comme l’a expliqué un responsable des processus d’une société pharmaceutique figurant au classement Fortune 100: «Nous avons abandonné le processus d’adoption« exigences – d’abord, ensuite de technologie », peu importe ce que cela signifie vraiment. Pourquoi? Parce que nous voulons rester agiles et compétitifs et que nous voulons tirer parti des nouvelles technologies. Rassembler les exigences prend une éternité et n’a pas rendu plus fructueux nos projets antérieurs. “

Sommes-nous cool? Ou est-ce que je viens encore de frapper le nid de frelons?

P.S. Si vous êtes intéressé par la gestion agile et l’adoption de logiciels dans le marketing (et les moyens de les associer de manière productive), vous devriez vraiment assister à la conférence MarTech qui se tiendra à Boston du 16 au 18 septembre. Le tarif de préinscription prend fin le 13 juillet.

<! –

->