Bonjour à tous,
Question compliquée en ce début de semaine : comment est perçue la philosophie "buy versus make" côté équipes finance ? De ce que j'ai pu comprendre, dans une économie qui fonctionne, il sera toujours plus intéressant de faire confiance au marché (et donc de buy) que de forcer l'intégration verticale, qui serait source additionnelle de bureaucratie et de gestion (et donc fort impact sur le ROCE)
En tant que financier, qu'est-ce que vous conseillez aux fondateurs / gérants (dans la plupart des cas) ? Est-ce que vous conseillez aux entreprises, par exemple, d'absorber la charge supplémentaire de la conception de certains inputs vitaux ou au contraire est-ce à fuir comme la peste (et donc toujours d'acheter à une entreprise externe) ?
Ca tape fort pour un lundi matin mais bon !
Bonne semaine quand meme :-)
Commentaires (4)
Expert Finpal
Très bonne question et oui ça pique pour un début de semaine !
Côté finance, on raisonne surtout valeur créée vs capital immobilisé.
Par défaut, je conseille le "buy" :
moins de CAPEX
plus de flexibilité
ROCE généralement meilleur
moins de complexité opérationnelle
Le "make" peut se justifier aussi dans 3 cas :
Avantage compétitif clé (savoir-faire différenciant, IP stratégique)
Risque critique sur l’approvisionnement (qualité, délais, dépendance)
Effet d’échelle réel qui améliore durablement les marges
Sinon, l’intégration verticale apporte souvent :
plus de coûts fixes
plus de management
plus de bureaucratie
dégradation du ROCE à moyen terme
Mon petit tips :
Externalisez tout ce qui n’est pas au cœur de votre avantage concurrentiel et gardez en interne ce qui fait vraiment la différence pour le client.
La bonne question n’est pas "peut-on le faire" mais "est-ce que ça mérite d’être financé et porté dans la durée ?"
Expert Finpal
Merci @Mehdi Saoud pour ta réponse détaillée, je n'aurais pas dit mieux !
En complément, j'ajouterais peut être 3 pistes de réflexion :
d'abord le fait de bien amortir les développements (je suis toujours surpris de constater à quel point les frais liés à des développements internes ne sont pas amortis, alors qu'ils pourraient souvent l'être !)
Ensuite, si l'on parle de développement qui peuvent avoir une incidence directe sur l'état de l'art de la connaissance sur une thématique, ça peut valoir le coup de regarder du côté des crédits d'impôts (CIR/CII/IPBOX)
Et enfin, un sujet que je découvre récemment en tant que DAF d'une agence de cybersécurité, les questions de souveraineté de l'entreprise sur son système d'information, et la sécurité de ce dernier. Par exemple, nous avons certains clients qui exigent un niveau de souveraineté important, et notre DSI interdit l'usage d'API pour faire communiquer les outils entre eux. Dans ces cas là, la question du make or buy ne se pose (presque) pas.
Merci et meilleurs voeux !
Intéressant l'idée de l'amortissement, est-ce lié à la courbe d'expérience ? Si on "make" au lieu de "buy", à terme cela signifie que l'on gagne de l'exp sur la conception du produit ainsi crée, réduisant à terme son running cost non ?
J'ai l'impression que le coût principal n'est souvent pas la conception et l'exploitation en eux-mêmes, mais surtout le suivi des normes et du cadre juridique, où justement le coût du conseil et de la mise en conformité peuvent s'envoler versus une solution/produit vendu prêt à l'emploi
Dans ma boîte (SaaS), le fait de vouloir tout faire nous-mêmes a crée une dette technique assez conséquente, qu'on espère pouvoir rattraper avec de l'agentique.
A bon entendeur ...