Skip to main content
Question

[FR] Conformité entre Business Strategic Importance, et choix make or buy

  • February 27, 2026
  • 2 replies
  • 25 views

Gauthier

Bonjour

Nous évaluons les “Strategic Importance” de nos Business Capa afin d’appliquer un “Pace Layering”

Notre stratégie digitale “Make or Buy” indique en conséquence : 

  • si la BC est typée “commodity” alors normalement les applications qui la réalise devraient être de type “Buy” (nous avons créé un attribut pour indiquer si l’appli est de type “Make” (dévt spécifique) ou “Buy” (achat d’une solution marché) : notamment sur de l’ERP, car non différentiant sur le marché.
  • si la BC est typée “Innovation” alors normalement les applications qui la réalisent devraient être de type “Make”.. et pas dans de l’ERP, car on dévierait du standard et on aurait un Time to market trop long.

Nous cherchons à montrer simplement (par un report type Radar ou graphe à bulle, etc..) la cohérence sur notre stratégie.

Nous sommes rapidement bloqués dans les reports type radar ou portfolio (graphe à bulles) …

ESt-ce que vous avez déjà mis en place ce genre de stratégie et quels reports avez-vous proposé pour montrer les résultats ?

 

2 replies

Gunther
  • Rookie
  • March 2, 2026

Bonjour Gauthier,

Il me semble qu’à moins de faire porter l’attribut “make or buy” par la relation entre application et capacité métier plutôt que par l’application elle-même, vous ne deviez recourir à un diagramme pour mettre en corrélation par filtres adaptés les attributs de deux classes d’objets différentes.

D’ailleurs, je ferais plutôt porter l’attribut par la relation entre application et composant IT, voire même par le composant IT, considérant que vous pouvez par ailleurs vous en passer si vous modélisez également votre structure de développement interne comme fournisseur d’un “service” de développement et des logiciels internes pour identifier le périmètre “make”.

Vous pourriez ainsi représenter un diagramme en couches (avec conteneurs le cas échéant) : capacités métier <> applications <> composant IT <> fournisseur, en jouant sur les vues des attributs de chaque classe pour mettre en évidence et distinguer la règle d’alignement et les écarts.

Enfin, vous avez deux approches possibles selon le compromis entre vos objectifs de communication et contraintes de faisabilité : montrer un état global de la situation, ou faire un focus sur les divergences p/r à la stratégie (en vous appuyant sur le principe de management par exception). Voulez-vous ainsi montrer que tout est aligné, ou attirer l’attention sur les dérogations à arbitrer ?

Cordialement,

Gunther

 


Gauthier
  • Author
  • Here To Stay
  • March 2, 2026

Merci Gunther pour le retour !

Je souhaite effectivement mettre l’accent sur les dérogations à arbitrer. 

Pour l’instant, j’ai fait un report specific filtrant les BC en “Commodity” et les application en “HomeDev”, afin de les traiter avec les product managers et déterminer le pourquoi et la vision à terme. 

Je n’ai pas réussi en revanche de montrer sur un seul report l’ensemble des infos (ex. color mapping des BC sur les strategic Importance, et color mapping sur l’attribut” Maje or Buy” des applications)