Dans les Coulisses de l'Échec : Pourquoi Votre Concurrent Génère Deux Fois Vos Revenus avec le Même Effectif
Ne vous êtes-vous jamais demandé pourquoi certaines entreprises surpassent constamment leurs concurrents malgré des conditions de marché et des ressources similaires ?
Avis de non-responsabilité : Toute ressemblance avec des personnes réelles, vivantes ou décédées, ou des événements réels, ou des organisations réelles est purement fortuite.
Résumé exécutif:
Les entreprises mondiales aux processus fragmentés paient un impôt invisible sur leur performance, ce qui explique souvent pourquoi leurs concurrents génèrent deux fois plus de revenus par employé. Les inefficacités se multiplient à travers les pays, suivant deux schémas courants : une personnalisation locale excessive ou une centralisation dangereuse reposant sur quelques individus. L'architecture des processus reliant les besoins commerciaux à l'implémentation technique fournit le fondement manquant pour l'exécution stratégique. La construction de cette fondation nécessite un inventaire des processus, un référentiel basé sur les données et une gouvernance, avec des retours visibles en moins de 18 mois. La solution ne consiste pas à éliminer l'autonomie locale, mais à créer un cadre structuré dans lequel elle peut s'exercer.
Ne vous êtes-vous jamais demandé pourquoi certaines entreprises surpassent constamment leurs concurrents malgré des conditions de marché et des ressources similaires ? Ou pourquoi des organisations composées de personnes brillantes et disposant de budgets considérables continuent de lutter contre l'inefficacité et la redondance dans leurs opérations mondiales ?
J'ai passé des années à observer ces schémas au sein des multinationales, et je m'apprête à partager des réflexions qui pourraient transformer votre conception de la stratégie d'entreprise.
Laissez-moi vous emmener dans une conférence téléphonique où cette réalité est devenue douloureusement évidente.
Le directeur technique de la petite entreprise SaaS était ponctuel. Et sans surprise, c'était un homme. Cheveux parfaitement coiffés. Chemise bleu clair, bien repassée. Un bureau spacieux et bien éclairé. Discours assuré. Gestes précis. Il ressemblait à quelqu'un qui avait répété la clarté, puis s'était présenté en avance pour la livrer.
C'était une séance d'analyse comparative typique, partie de notre routine avant de prendre la décision douloureuse de développer en interne. Si nous pouvions trouver une solution logicielle robuste et prête à l'emploi, nous le ferions. Cela signifiait que nous pourrions éviter l'épreuve : sécurité, infrastructure, développement logiciel, gestion des versions, équipes de support, rotations d'astreinte et tout ce que nous préférerions ne pas gérer en interne.
Et ce que nous ne voulions pas construire nous-mêmes, nous l'examinions minutieusement chez les autres. La mise sur liste blanche est un processus long et détaillé, qui s'étend à l'architecture, à la sécurité, au flux de données, à la criticité et aux fonctions commerciales que le logiciel impactera. Nous avons commencé par notre concentration habituelle : l'architecture et la sécurité. Le test "sous le capot". Nous avons posé des questions. Parcouru silencieusement nos listes de contrôle mentales. Nous n'avions pas besoin de les énoncer à voix haute, nous étions passés par là de nombreuses fois. Puis nous avons interrogé sur l'architecture.
Il a partagé son écran. Et c'est là que tout a changé. Ce qui a suivi était une vision du monde. Il a commencé par les fonctionnalités. Logique, bien organisé. Puis vint le schéma de flux de travail. Puis l'architecture elle-même. Ensuite les données : comment elles circulaient, comment elles se transformaient. Puis la feuille de route : ce qui était prévu, ce qui était à venir, ce qui était encore en cours d'exploration.
En quelques clics, nous pouvions voir : Quelles données supportaient quels processus métier, comment les données étaient transformées et où elles aboutissaient, quels composants étaient construits sur mesure par opposition aux intégrations tierces, ce que le logiciel actuel faisait, et ce qui arriverait dans la prochaine version et la vision à long terme, clairement structurée, déjà prototypée. C'était un système en couches, mais pas comme nous en avions l'habitude. Il commençait par le métier, pas par le backend. Chaque couche répondait à une question soulevée par la précédente :
Quelle est la fonction ? Qu'est-ce qui soutient cette fonction ? Quelles données l'alimentent ? Où vont ces données ? Qu'est-ce qui change ensuite ?
Pas besoin de chercher, de deviner ou de contacter quatre équipes pour assembler une carte mentale. Tout était là. En direct. Transparent. Structuré.
J'ai regardé notre directeur technique. Il ne semblait pas remarquer ce que je voyais. Il évaluait le logiciel à sa manière habituelle : cherchant des raisons de le disqualifier. Et je savais déjà ce qu'il dirait après : "Ce n'est pas ce que je cherchais." Il ne voulait pas être dans la réunion en premier lieu. J'avais dû le pousser à y assister. Il avait déjà pris sa décision : il préférait un autre outil. Pourquoi ? Parce que celui-là était étiqueté "Architecture d'Entreprise."
Mais ceci, ce que nous venions de voir, c'était de l'architecture d'entreprise en pratique, pas en théorie. Ce n'était pas une présentation PowerPoint. Ce n'était pas un document de vision. C'était de l'architecture vivante : visible, connectée, rationnelle et mesurable.
Et cela ne venait pas de nous.
Nous étions la grande entreprise mondiale. Nous avions les ressources. Les effectifs. L'infrastructure. Mais ce qui nous manquait était exactement ce que cette startup avait conçu dès le premier jour : une visibilité transversale entre les couches, ancrée dans la logique métier.
Les petites entreprises peuvent surpasser les géants en matière d'architecture lorsqu'elles construisent à partir de principes centrés sur le métier, et non sur des attentes héritées du passé.
Nous aimons parler d'"alignement", de "transformation", d'"intégration". Mais souvent, ce que nous voulons dire, c'est : un alignement PowerPoint. Une transformation que nous pouvons financer mais pas décrire. Une intégration qui vit dans un schéma que personne n'a mis à jour depuis deux ans.
Ce que j'ai vu ce jour-là n'était pas révolutionnaire. Mais c'était indéniable.
Cela rendait quelque chose clair : lorsque vous construisez l'architecture à partir de la fonction plutôt que de l'étiquette, lorsque vous connectez la logique métier aux données puis à la livraison, et lorsque vous rendez cette structure explorable, les gens n'ont pas besoin d'explications.
Ils le voient simplement.
L'anatomie du chaos des processus
Lorsque vous opérez dans 10 à 40 pays, des modèles émergent. Vous commencez à voir les fils conducteurs communs, les différences légitimes et, plus troublant encore, les variations inutiles qui épuisent les ressources et compromettent les performances. D'un point de vue où les processus de tant de pays peuvent être scrutés comme des cellules sous un microscope, votre cerveau commence à construire une carte visuelle : des chevauchements clairs, de véritables divergences, puis les zones grises qui n'ont tout simplement pas de sens. Vous rencontrez d'innombrables équipes qui font leur propre chose sans communiquer au-delà des frontières, réinventant la roue, dépensant de l'argent et, étrangement, obtenant l'approbation de la direction pour cela.
Permettez-moi de vous montrer les deux extrêmes de cette dysfonction.
Le labyrinthe surdimensionné
Dans une opération sud-américaine, une équipe de 80 développeurs a créé 20 versions de la même base de données. Chaque copie avait ses propres transformations et prenait en charge un ensemble différent d'applications. L'architecture ressemblait à une énorme pelote de laine emmêlée, des copies de copies, interconnectées sans API, chaque base de données contenant une logique isolée. Localement, cela fonctionnait. Mais d'un point de vue global, l'absence de principes d'ingénierie de base et le manque de discipline architecturale criaient à l'attention.
Les parties prenantes métier avaient un accès complet aux données de production. Elles pouvaient lire, écrire et même cloner des bases de données pour construire leurs propres outils. Si quelqu'un était perçu comme compétent en informatique et voulait déployer une fonctionnalité opérationnelle sans impliquer l'équipe informatique, l'accès était accordé, sans coordination nécessaire. La vitesse l'emportait sur la structure.
Chaque fois que nous avions besoin d'informations pour une initiative à l'échelle de l'entreprise, travailler avec ce pays devenait un cauchemar logistique. Presque toute l'équipe devait être consultée – une personne en pointant une autre, chacune responsable d'une infime partie du système. Nous devions reconstituer comment les données étaient interconnectées, pourquoi elles étaient configurées ainsi, et quelle version (ou copie d'une copie) de l'ensemble de données était la plus proche de ce dont nous avions réellement besoin. La complexité était stupéfiante, et entièrement auto-infligée.
Le point unique de défaillance
À l'autre extrémité du spectre, un autre pays faisait tout passer par une seule personne. CRM, ERP, tableaux de bord, pipelines de données, outils financiers—nommez-le, et le même nom revenait. S'il était renversé par une voiture (que l'univers nous en préserve), les opérations du pays entier seraient paralysées.
En grattant la surface, on découvrait le même schéma : des systèmes critiques pour l'entreprise construits sur une base de tutoriels YouTube, assemblés par essais, erreurs et improvisation. Des rustines sur des rustines. Des configurations qui ignoraient les bases de l'ingénierie. Il était ingénieux, sans aucun doute, et un maître du système ERP. Mais en dehors de ce domaine, il aurait dû confier les choses à des ingénieurs avec une expertise plus profonde. Il ne l'a pas fait. Parce qu'il ne pouvait pas. Parce que personne d'autre n'était là.
La raison ? L'argent. Ce marché ne générait pas autant de revenus. La situation économique était mauvaise. Les décisions d'investissement local étaient directement liées à la rentabilité locale. Moins vous gagniez, moins vous pouviez dépenser—même pour les systèmes qui maintenaient l'entreprise en marche.
La prochaine fois que vous examinerez les opérations mondiales de votre entreprise, demandez-vous : l'un de ces scénarios pourrait-il se produire sous votre supervision ? Si vous ne pouvez pas répondre non avec confiance, vous pourriez avoir le même problème fondamental.
Avez-vous déjà calculé le coût réel de l'incohérence de vos processus ? Lorsque vous lancez une initiative mondiale, savez-vous combien de façons différentes elle sera mise en œuvre dans les régions ? Combien de vos systèmes résolvent essentiellement le même problème commercial avec des approches différentes ?
Comme l'a observé le légendaire Peter Drucker, "Les erreurs les plus graves ne sont pas commises en raison de mauvaises réponses. La chose vraiment dangereuse est de poser la mauvaise question." Pendant des décennies, les multinationales ont cherché à optimiser leurs opérations mondiales sans d'abord établir si elles construisaient sur une base cohérente.
Le coût caché de l'incohérence
Ces problèmes structurels ne sont pas simplement des curiosités organisationnelles, ils se traduisent directement par des coûts mesurables. Notre analyse a révélé que la duplication des processus dans 40 pays entraînait environ 320 000 heures de travail gaspillées annuellement, équivalant à 153 employés à temps plein. Le coût de maintenance des systèmes redondants s'élevait en moyenne à 78 000 dollars par pays et par an, totalisant plus de 3,1 millions de dollars en dépenses inutiles - et il s'agit d'un calcul conservateur.
Pourtant, ces coûts directs pâlissent en comparaison du désavantage stratégique. Pendant que nous étions occupés à réinventer des outils et des processus internes, notre concurrent mettait en œuvre des systèmes cohérents qui lui permettaient d'avancer plus vite, de s'adapter plus rapidement et de déployer des innovations une fois au lieu de 40.
Quel est l'impôt caché de l'incohérence dans votre entreprise ? Combien de vos projets informatiques ne sont que des recréations de solutions déjà mises en œuvre ailleurs ? Quand avez-vous demandé pour la dernière fois si deux régions ont vraiment besoin de processus différents pour remplir la même fonction ?
Le modèle était cohérent : les pays riches rejetaient les plateformes standardisées, citant des "exigences uniques". Pendant ce temps, les opérations à ressources limitées improvisaient silencieusement, évitant la visibilité et essayant de résoudre les problèmes localement avec ce qu'elles avaient. Les conditions économiques n'impactaient pas seulement les nations. Elles façonnaient aussi les structures d'entreprise internes.
Les besoins commerciaux dans ces régions étaient souvent presque identiques. Ce qui changeait, c'était l'approche. Dans les pays plus riches, les dirigeants voulaient maintenir l'illusion du contrôle, cachant souvent les problèmes sous la complexité des processus. Dans les pays plus pauvres, les défis étaient cachés sous l'ingéniosité locale : l'informatique parallèle, le développement ad hoc, les données manipulées et les fonds créativement réalloués et catégorisés. La créativité humaine n'a pas de limites quand il s'agit de contourner les obstacles opérationnels.
Un brillant architecte de systèmes m'a montré un jour un diagramme de notre paysage d'entreprise, un portrait fidèle de la façon dont les choses fonctionnaient réellement. Il avait passé trois ans à essayer de le montrer à la direction. "Personne ne veut le voir," dit-il. "Parce qu'une fois qu'ils le verront, ils devront le réparer."
Tout comme "Two Gun" Crowley de Carnegie, dont les actions n'étaient jamais mauvaises dans son propre esprit, les pays et les départements de notre entreprise justifiaient leurs écarts. "Notre marché est différent," disaient-ils, mais rarement avec des données pour le prouver.
La fondation manquante
Pour démontrer quelque chose factuellement, vous avez besoin de données. Pas un schéma dessiné dans Visio, mais un système structuré qui capture les flux de travail, les systèmes informatiques, les connexions réseau et les modèles de données.
C'est précisément ce que la petite entreprise SaaS avait compris et ce que tant d'entreprises mondiales négligent.
Mon impression de leur directeur technique n'était pas une révélation. C'était une confirmation. J'avais entendu les mêmes critiques pendant des années, dans des conversations de couloir avec des architectes qui n'étaient pas issus des canaux informatiques traditionnels mais avaient rejoint l'entreprise du côté métier. Ces "esprits critiques" avaient identifié le problème depuis longtemps. Ils soumettaient des rapports. Ils exprimaient des préoccupations. Mais leurs commentaires se heurtaient constamment au même mur : "Les choses sont comme elles sont," ou "Ce n'est pas la priorité de l'entreprise en ce moment. Concentrez-vous ailleurs."
Des années avant cette réunion, ces voix avaient déjà décrit ce que je voyais maintenant. Nous exploitions le même modèle d'affaires dans plusieurs pays. Nous avions des milliers d'applications, la plupart construites ou gérées localement. Mais pas un seul système ne fournissait une vue consolidée de nos processus métier, fonctions, systèmes d'enregistrement, couches d'infrastructure et transformations qui les reliaient.
Personne ne pouvait expliquer pourquoi l'Argentine gérait un service d'une façon, tandis que le Brésil ou l'Allemagne l'abordaient différemment, malgré l'offre du même service exactement. Personne ne savait pourquoi les logiciels associés, les approbations, les flux de travail et les pipelines de données divergeaient d'un pays à l'autre.
Si je demandais à dix de vos directeurs nationaux de décrire comment fonctionne un processus central, recevrais-je dix réponses différentes ? Quelqu'un dans votre organisation pourrait-il me montrer une carte complète et précise de la façon dont vos systèmes se connectent réellement au-delà des frontières ? Savez-vous lesquelles de vos variations régionales sont basées sur de véritables exigences du marché par opposition à des accidents historiques ?
Les questions cruciales
Mais que se passe-t-il si vous n'avez pas le système ?
Que se passe-t-il si vos processus métier n'existent que dans la tête des gens ? Ou dans la documentation du projet de la mise en œuvre originale d'un système, des documents qui n'ont pas été mis à jour après une centaine d'améliorations ? Que se passe-t-il si vos diagrammes d'architecture ne reflètent pas la connectivité réelle entre les systèmes ? Et si les adresses IP et les ports sont erronés ? Et si tout a été déplacé vers le cloud grâce à une autre initiative, mais que vos diagrammes montrent toujours les chemins du centre de données ?
Que se passe-t-il si personne ne peut vous dire quel est le système de vérité pour vos KPI et OKR les plus critiques ? Et si vous recevez l'agrégation mensuelle, mais que personne n'a vérifié si la méthode de calcul ou l'ensemble de données source est valide ou cohérent d'un pays à l'autre ? Et si les gens manipulent les données avant de les envoyer au siège, cachant les problèmes pour améliorer les chiffres ? Et si le même processus s'exécute sur des systèmes entièrement différents selon le continent ? Et si les données ne proviennent même pas du système principal, mais d'une base de données clonée transformée de manière non documentée ? Et si la seule façon de savoir comment cela fonctionne est de demander à un ingénieur de lire le code ?
Presque toutes les entreprises – à l'exception de quelques rares qui sont véritablement orientées processus – ne peuvent pas répondre à ces questions. Leurs systèmes sont interconnectés, oui, mais sans logique centrale. Aucune application ne part du besoin métier, ne s'écoule à travers le flux de travail, ne construit les couches informatiques, l'infrastructure, la sécurité, les API et ne montre les ensembles de données, les transformations, les sorties et la lignée qui relient tout cela.
Certains soutiennent que capturer autant d'informations en un seul endroit rendrait le système trop critique, un point unique de défaillance. Mais est-ce vraiment différent de ce qui existe déjà dans votre ERP ? Ventes, finances, approvisionnement, fabrication, tarification ; des milliards de transactions circulent dans un système quotidiennement, et personne ne se demande si cette consolidation est risquée. Alors pourquoi les fondements de vos opérations sont-ils dispersés à travers des milliers de dessins Visio, de documents Word, de fichiers Excel et de mémoires d'employés, sans référentiel centralisé, structuré et auditable ?
J'ai vu ces vérités exprimées dans des conversations latérales, dans des fils de courriels jamais suivis, et autour des machines à café où les architectes expriment des préoccupations seulement pour se heurter au mur du "les choses sont comme elles sont" ou "la priorité est ailleurs." Nous savions que des informations critiques nous manquaient. Nous savions que nous réinventions la roue. Mais sans une base fondée sur les données, nous ne pouvions pas le prouver de manière assez convaincante pour forcer le changement.
La voie à suivre
Lincoln a écrit une lettre cinglante au général Meade après la bataille de Gettysburg, le critiquant pour avoir laissé l'armée de Lee s'échapper. Puis Lincoln a fait quelque chose de remarquable : il ne l'a jamais envoyée. Il a reconnu que la critique n'améliorerait pas la situation ; elle ne créerait que du ressentiment et de la résistance.
De même, blâmer les opérations nationales ou les départements informatiques pour la fragmentation des processus ne résoudra pas le problème. Concentrez-vous plutôt sur la construction de la fondation qui rend la cohérence possible :
Créez un inventaire des processus en documentant les flux de travail existants dans trois pays représentatifs, généralement votre plus grand marché, votre marché à la croissance la plus rapide et votre marché le plus efficace. Utilisez des outils d'exploration de processus pour analyser l'utilisation réelle du système plutôt que de vous fier uniquement aux entretiens.
Établissez un référentiel de processus basé sur les données qui capture les flux de travail, les systèmes, les modèles de données et les transformations. Il ne s'agit pas simplement d'une documentation, mais d'un système opérationnel qui sert de source unique de vérité sur le fonctionnement de votre entreprise.
Instaurez un cadre de gouvernance exigeant que tous les nouveaux processus et systèmes soient enregistrés dans ce référentiel avant approbation. Cela empêche la fragmentation future tout en amenant progressivement les opérations héritées vers l'alignement.
Avec ce système en place, vous ne dépendez plus d'un architecte pour se souvenir de toutes les interconnexions, ou d'un ingénieur réseau pour vérifier quels autres systèmes sont connectés à une base de données avant de la déplacer, ou d'un leader d'entreprise spécifique pour savoir pourquoi le processus au Canada diffère de celui des États-Unis. Tout est dans le système, visible pour de multiples parties prenantes. Vous multipliez vos points de vigilance, le nombre de personnes qui peuvent voir, analyser, remarquer et fournir des commentaires.
La prochaine fois que vous serez assis dans une réunion stratégique où quelqu'un présente une nouvelle initiative brillante, demandez-vous : cette solution sera-t-elle mise en œuvre de manière cohérente, ou deviendra-t-elle vingt versions différentes d'elle-même en traversant les frontières et les départements ? La réponse révèle si vous avez une fondation pour votre stratégie ou simplement un plan qui sera réinterprété par chaque constructeur.
Une fondation pour le succès
Ralph Little a observé qu'une entreprise se compose d'une idée, d'un capital et d'une gestion—la gestion étant l'actif le plus critique. Une mauvaise gestion des ressources rend inévitablement votre entreprise moins compétitive que les rivaux qui assurent des systèmes de gestion cohérents.
La solution ne consiste pas à éliminer l'autonomie locale, mais à créer un cadre structuré dans lequel elle s'exerce. Si la Colombie ne peut pas se permettre le même système ERP que les États-Unis, la solution n'est pas de leur permettre de construire une alternative maison. C'est de financer la solution standard par le groupe, car la cohérence des processus globaux génère finalement plus de valeur que les économies à court terme des exceptions localisées.
C'était l'une des principales raisons pour lesquelles cette entreprise avait pris du retard dans la compétition, voyant son principal concurrent réaliser deux fois plus de revenus avec le même nombre d'employés. Comme l'entreprise avait grandi organiquement et démontrait une croissance, personne n'avait prêté attention à l'effet composé de mauvaises prises de décision, de mauvaise gestion, de mauvais processus et de mauvaises habitudes. Tout le monde pensait que comme ces problèmes étaient localisés et principalement cachés dans des zones éloignées, ce qui est "loin des yeux est loin de l'esprit" et ne nécessitait pas d'attention particulière. Néanmoins, permettre à un pays de mettre en œuvre son propre processus, puis permettre à un autre de réinventer la roue pour le même processus épuisait l'argent de l'entreprise. À première vue, il ne s'agissait que de quelques dizaines de milliers de dollars ici et là, mais multiplié par le nombre de pays, de "lignes d'activité indépendantes" et de départements faisant leurs propres choses, cela se composait en millions de dollars de revenus de l'entreprise chaque année, devenant encore plus significatif à mesure que les variations du marché, les prix de l'énergie, le COVID, les situations économiques et d'autres changements affectaient les opérations.
Ce qui importe lorsqu'on dirige une entreprise depuis un lieu ou depuis des centaines de lieux, c'est la cohérence des processus et du flux d'information. Même le premier lieu que vous démarrez a besoin de processus, de flux de travail, de systèmes et de données pour fonctionner. Et ces mêmes éléments peuvent être exportés vers les nouveaux lieux que vous ouvrez. Plus tôt vous structurez "l'ingénierie des processus métier", la documentez dans un système basé sur les données et déployez le même plan et le même manuel partout où c'est possible, mieux vous pourrez optimiser les opérations et améliorer la productivité dans tous les domaines. Les spécificités locales existeront toujours dans les réglementations, les lois et l'organisation nationale de la prestation de services, mais de nombreux processus communs peuvent être optimisés en même temps en adoptant une approche basée sur les données pour capturer, optimiser et automatiser les processus métier.
Comme l'a observé Peter Drucker, père de la gestion moderne : "Il n'y a rien d'aussi inutile que de faire avec une grande efficacité quelque chose qui ne devrait pas être fait du tout." Quand je vois des entreprises exploiter vingt versions du même processus dans vingt pays, chacune "optimisée" pour les conditions locales, je me souviens de la sagesse de Drucker. Nous ne faisons pas seulement des choses inutiles efficacement ; nous les faisons en double, en triple et parfois vingt fois.
Demain, lorsque vous ouvrirez votre boîte de réception ou assisterez à votre prochaine réunion stratégique, je vous mets au défi de poser trois questions : Premièrement, savons-nous vraiment combien de façons différentes nous résolvons le même problème dans notre organisation ? Deuxièmement, notre concurrence pourrait-elle nous surpasser simplement parce qu'elle met en œuvre des processus fondamentaux de manière cohérente ? Et troisièmement, que se passerait-il si nous investissions autant dans notre fondation de processus que dans nos initiatives stratégiques ? Vos réponses honnêtes révéleront si votre entreprise construit sur du roc ou sur du sable.
Lorsque vous vous engagez à construire cette fondation, trois avantages transformateurs émergent : Premièrement, les transformations numériques qui prenaient autrefois des années s'achèvent en mois parce que vous changez un système cohérent unique, pas des dizaines de variations. Deuxièmement, les innovations s'étendent sans effort du pilote à l'entreprise parce que les processus sous-jacents sont cohérents. Troisièmement, les acquisitions s'intègrent en moitié moins de temps parce que vous avez un plan clair de fonctionnement de votre entreprise. Comme les intérêts composés, chaque avantage s'appuie sur le précédent, créant un écart de performance toujours plus grand entre vous et les concurrents coincés dans la fragmentation.
Souvenez-vous de ce principe par-dessus tout : La stratégie sans fondation n'est qu'aspiration. Même le plan stratégique le plus brillant échouera lorsqu'il sera construit sur des processus fragmentés. Le monde est jonché de stratégies visionnaires qui sont mortes sur l'autel de l'exécution incohérente. Construisez d'abord votre fondation. Votre stratégie existante, celle en laquelle vous croyez déjà, livrera soudainement des résultats que vous n'auriez jamais crus possibles lorsqu'elle reposera enfin sur un terrain solide.
Avertissement : Toute ressemblance avec des personnes réelles, vivantes ou décédées, des événements réels ou des organisations existantes serait purement fortuite.
