Make or Buy

Dès lors que la stratégie business et les besoins métiers qui en découlent ont été définis, les « pourquoi » et « quoi », le  » comment » est à designer. Je parle là de la Solution « Technique » à mettre en oeuvre si cette nécessité est avérée.

Cela incombe dans la grande majorité des cas aux équipes des Directions des Systèmes d’Informations.  Les choix qui s’offrent sont alors les suivants

• Réaliser un développement spécifique de façon ad’hoc  (make)
• Intégrer un développement spécifique à un applicatif existant (integrate)
• Acheter un logiciel couvrant le périmètre (buy)
• Louer un service implémentant les fonctions nécessaires (lease)

L’avènement des offres « cloud » peut faire converger les approches buy et lease. Evidemment pour certains secteurs et activités la différence en le « onPremise » et le « Cloud » demeure.

Cette décision nécessite bien sûr de s’interroger sur le cœur de métier de la Société et ce qui la différencie de sa concurrence néanmoins des éléments de contexte doivent entrer en ligne de compte : compétences et ressources disponibles, dette technologique, impératifs calendaires (dead-lines).

Si les processus métiers ne sont pas maîtrisés et/ou qu’ils ne sont pas considérés comme stratégiques et différenciant pour la société ou si les compétences et ressources ne sont pas suffisantes, aller vers de l’externalisation fait sens (buy ou lease).

En effet, dans le premier cas, les métiers pourront se « nourrir » des retours d’expériences et de processus déjà implémentés dans l’application, « l’achat » de la technologie vous permettra également d’accélérer votre projet, dans le second cas, inutile de réinventer la roue.

Sur les activités stratégiques il est bon de faire la distinction entre celles qui « en plus » contribuent à la performance opérationnelle.

En effet les fonctions stratégiques peuvent faire l’objet d’un partenariat avec un éditeur et/ou prestataire par contre il souhaitable de « posséder » (make) celles qui améliorent également votre performance opérationnelle.

Enfin un mot sur la solution « integrate », cette dernière permet les « quick win ». En effet adosser une fonctionnalité développée ad-hoc à un applicatif existant peut vous faire gagner du temps ou du budget. Veillez toutefois à ne pas multiplier ces solutions qui peuvent sortir votre applicatif existant de la roadmap éditeur donc il ne bénéficiera plus automatiquement des montées en version. Le début de la dette.

Vous l’aurez compris, il est important de se poser quelques questions simples et importantes avant de se lancer dans des développements périlleux ou des appels d’offres inutiles.

—- le « cloud »
Les solutions disponibles dans le cloud permettent aux DSI de s’affranchir en partie du design, de l’exploitation et de la supervision des infrastructures supportant les applications. Nous aurons l’occasion de reparler des avantages et points de vigilance autour du Cloud lors d’un autre post.

—- côté méthode
Même si les méthodes Agiles peuvent vous permettre de délivrer des développements spécifiques en évitant l’écriture complète de spécifications – dans le cas où le besoin métier est long à formaliser ou que les équipes aMOA ne sont pas suffisamment dimensionner – ne perdez pas de vue que le choix d’une logiciel/plateforme peut être un catalyseur. Les métiers peuvent également se nourrir de la technologie, et des méthodes en gap-analysis combiné à un respect du standard du produit peut accélérer vos projets.