Pour continuer à financer mes recherches, j'ai accepté quelques autres contrats rémunérés, ce qui revenait à devenir une mercenaire. Le cloud computing entrait en collision avec la scène technologique et il y avait beaucoup de confusion. J'ai donc assisté à un flux constant de conférences — dont certaines étaient payantes — et j'ai eu de nombreuses occasions de travailler occasionnellement. C'était le Far West de l'informatique, avec malheureusement des pratiques assez louches et de l'exploitation humaine dans l'industrie. J'ai essayé de ne pas faire de mal, mais j'avais un talon d'Achille en matière de simplicité.
L'un des obstacles à la cartographie était que certaines personnes la trouvaient complexe. Ce n'est pas vraiment surprenant, car vous exposez les personnes à un monde que la majorité d'entre eux ne connaît pas. Peu d'entreprises ont une expérience pratique de la connaissance de la situation ou de l'utilisation de cartes. Nombreux sont ceux qui ne comprennent pas en quoi cela peut être important. Il faut également du temps et des efforts pour se sentir à l'aise avec la création d'une carte. La réponse la plus fréquente est : “pouvez-vous créer la carte pour nous ?”, en pensant qu'ils appliqueront ensuite leur stratégie générale à la carte. Cela dégénère toujours en “pouvez-vous nous montrer quels sont les mouvements que nous pouvons faire” auquel ils appliqueront leur stratégie générale. En fin de compte, il s'agit de “quel mouvement devrions-nous faire”, puis d'un hochement de tête général d'approbation.
Cependant, la confusion autour du "cloud computing" a créé une opportunité pour une nouvelle façon de penser et espérons-le, d'apprendre. Hélas, le fait d'empiler la complexité de la cartographie sur une personne déconcertée qui n'a aucun lien avec la connaissance de la situation peut engendrer davantage de confusion. La plupart des personnes voulaient simplement des réponses qu'ils pouvaient accepter, comme la manière de répondre à leur besoin d'être dans le cloud sans trop secouer le bateau. C’est la raison pour laquelle il y a eu beaucoup d'efforts discutables dans le domaine des clouds privés.
J'ai donc cherché des moyens de simplifier la cartographie, de la rendre plus acceptable et plus familière. J'ai commencé par faire du marquage. Je prenais un diagramme de processus d'entreprise ou diagramme en boîte pour un système existant, comme notre voiture elfique à conduite autonome dans la figure 36 (chapitre 4), puis je colorais les différentes parties selon qu'elles étaient plus en phase genèse ou en phase commodité. Je produisais quelque chose comme la figure 83.
Figure 83 — Marquage des composants d'une voiture elfique à conduite autonome
Ces diagrammes annotés, en plus d'être colorés, étaient plus familiers et moins agressifs pour les personnes qui avaient rédigé les originaux. Ils m'ont permis d'introduire assez facilement les concepts d'évolution dans une organisation et donc d'avoir une discussion sur les méthodes à utiliser. Mais, sans la position et le mouvement, ces diagrammes n'étaient d'aucune utilité pour une remise en question efficace et un apprentissage continu des modèles économiques ou des formes de Gameplay. Il y a eu un compromis entre la simplicité et l'utilité.
La loi d'Ashby sur la variété requise décrit comment le mécanisme de contrôle d'un système doit être capable de représenter ce qui est contrôlé. Les organisations sont en même temps des choses compliquées et complexes. Elles sont d'habitude compliquées parce qu'elles ont une grande portée, qu'elles contiennent de nombreux composants qui nécessitent une spécialisation et qu'elles sont difficiles à appréhender et à gérer. Elles sont également complexes parce qu'elles présentent de nombreux comportements émergents. Par exemple, ils ont de nombreux composants dans l'espace inexploré pour lequel il y a de l'incertitude et que vous ne pouvez pas prédire. Le mieux que vous puissiez faire est de tâter le terrain. Si la cartographie vous offre une fenêtre sur cette situation, vous devez disposer d'une capacité de gestion capable d'y faire face.
Il existe malheureusement une autre solution à la loi d'Ashby. Au lieu de faire face à un environnement compliqué qui contient de la complexité, vous faites le choix de prétendre que ce qui est géré est simple. Dans le monde des affaires, nous aimons les diagrammes 2x2, non pas parce qu'ils représentent la réalité, mais parce qu'ils l'obscurcissent et sont donc faciles à comprendre. Nous troquons notre capacité à apprendre continuellement sur l'environnement contre une illusion de simplicité et de facilité de gestion.
Il est important de faire une distinction ici. Le fait de prendre quelque chose de compliqué (comme une machine) et de le décomposer en composants petits, mais gérables, ou d'utiliser un mécanisme pour détecter un changement incertain dans un environnement complexe n'est pas la même chose que d'essayer de gérer un tel système en prétendant qu'il s'agit d'une matrice de 2x2. Comme le dirait Einstein, “Tout doit être rendu aussi simple que possible, mais pas plus simple”.
Finalement, j'ai été confronté à un choix. Est-ce que je continue d'utiliser ces diagrammes “ponctuels”, rendant ainsi les concepts de l'évolution plus accessibles, et est-ce que j'accepte les défauts (et l'argent) ou est-ce que j'emprunte un chemin plus lent et essaie de pousser les organisations vers une meilleure compréhension de la position et du mouvement ? S'ils refusent toujours, je pourrais faire un compromis et faire le gros du travail pour eux en leur fournissant simplement une carte et les résultats. Cependant, je savais déjà que cela les rendrait dépendants de moi, ce qui était exactement ce que je combattais chez les consultants. Je désirais libérer de leur chaînes les personnes et non de les enchaîner encore plus à un consultant de plus. Ce compromis était hors de question. Je devais prendre le chemin le plus lent. J'aime à penser que j'ai tenu bon, mais avec très peu d'entreprises qui cartographient, des factures qui s'accumulent et des clients qui s'intéressent aux concepts simplifiés, il est juste de dire que je commençais à chanceler.
Mon salut est venu d'un travail rémunéré que j'affectionne particulièrement. Il s'agissait d'une question d'efficience par rapport à l'efficacité et pour avoir un espoir de l'expliquer, nous devons d'abord introduire trois concepts — le développement fondé sur la valeur, la granularité de la tarification et le flux. Ensuite, nous pouvons les relier entre eux pour examiner cette question. Pour ce faire, je vais devoir faire des sauts dans l'histoire, mais j'espère pouvoir rester cohérent.
En 2003, la société que je dirigeais construisait et exploitait des systèmes de petite taille pour d'autres. Il n'y avait pas de gros systèmes, ils étaient plutôt de l'ordre de 100 000 à 2 millions d'euros et couvraient quelques millions d'utilisateurs. Nos clients voulaient généralement rédiger une spécification détaillée de ce dont ils avaient besoin pour s'assurer que nous les livrions. Cela ne semble pas si mal, mais même à cette petite échelle, certains des composants de ces projets se trouvaient dans un espace inexploré et personne ne savait donc exactement ce qu'il voulait. Cependant, à l'époque, je ne disposais pas du langage nécessaire pour l'expliquer. Nous avons donc construit et exploité les systèmes et, inévitablement, nous avons connu des tensions sur le contrôle des modifications et des disputes sur les caractéristiques à inclure ou à exclure d'un contrat particulier.
Au cours de l'une de ces discussions, j'ai fait remarquer au client que nous étions assis autour d'une table pour discuter d'un bout de papier, mais qu'aucun d'entre nous ne parlait des besoins des utilisateurs. Le contrat n'était pas vraiment pour le client, mais pour les utilisateurs finaux du client. Nous devions changer cette discussion et nous concentrer sur l'utilisateur final. J'ai suggéré que nous créions une mesure de la valeur basée sur l'utilisateur final, quelque chose à laquelle nous pourrions tous deux travailler. L'idée est tombée dans l'oreille d'un sourd, car le client était préoccupé par le contrat, mais au moins la graine était plantée. Peu de temps après, un autre projet nous a donné l'occasion de tester cette idée. Le client m'a remis un cahier des charges et m'a demandé combien coûterait la construction. J'ai répondu : “Que diriez-vous de la gratuité ?”
Ils ont été un peu choqués, mais j'ai ajouté : “Cependant, nous devrons être payés pour faire fonctionner le système. Nous devons déterminer une mesure de la valeur et je serai payé sur cette base”. Il y a eu quelques discussions, mais nous avons fini par accepter d'essayer une méthode de développement fondée sur la valeur.
Dans ce cas, l'objectif du système était de fournir des pistes pour une gamme coûteuse d'imprimantes grand format (“Large Format Printers” — LFP). Le client voulait plus de pistes. Ses utilisateurs finaux potentiels voulaient un moyen d'en savoir plus sur ces imprimantes et de les tester. J'ai conçu un produit qui répondrait à ces deux besoins différents. Mais, au lieu que le client paie d'avance et prenne tous les risques, je l'ai construit gratuitement et j'ai pris une commission sur chaque nouveau client potentiel créé.
Nous (le client et mon entreprise) n'étions plus concentrés sur ce qui faisait partie ou non d'un contrat, mais sur une seule tâche : créer plus de prospects. Nous étions tous deux incités à le faire. J'avais également une nouvelle motivation pour la rentabilité, car plus le système était efficace, plus je conservais de bénéfices. Nous nous sommes mis d'accord et j'ai donc construit et exploité un système qui permettait aux consommateurs de télécharger une image, de la tester sur une imprimante grand format et d'obtenir la livraison de leur impression ainsi que des informations sur les performances du produit et un appel de vente. Le système s'est envolé.