Le débat « construire ou acheter » traite un problème de séquencement comme un problème de propriété. La meilleure question est de savoir quelles parties de votre système vous voudrez encore maîtriser dans cinq ans.
Tôt ou tard, quelqu’un demande s’il faut construire ou acheter. La discussion qui suit porte généralement sur le coût et la maîtrise, et elle se termine généralement par une décision appliquée à l’ensemble du système.
C’est là l’erreur. Il ne s’agit pas d’une seule décision.
Tout système d’une certaine importance comporte des parties qui diffèrent sur deux points essentiels : la vitesse à laquelle le besoin évolue, et l’endroit où réside ce qui vous distingue.
Les règles de calcul de la paie changent quand la législation change et ne contiennent rien de votre avantage concurrentiel. La façon dont vous tarifez un risque, planifiez une équipe de terrain ou décidez quel sinistre exige un regard humain peut en constituer l’essentiel.
Une fois les parties séparées selon ces deux axes, la décision se prend presque d’elle-même. Ce qui est courant et évolue lentement s’achète. Ce qui est spécifique et évolue vite, vous voulez pouvoir le modifier un mardi sans ouvrir de ticket de support auprès d’un éditeur situé dans un autre fuseau horaire.
L’erreur coûteuse est l’inverse : une organisation construit et maintient sa propre version d’un élément parfaitement standard, tandis que la partie qui porte son véritable avantage se trouve enfermée dans un progiciel qu’elle ne peut pas modifier.
L’an dernier, certains pensaient qu’une production logicielle moins chère ferait tout pencher vers la construction. Ce n’est pas le cas, pour la même raison que dans l’article précédent de cette série.
La production n’a jamais représenté tout le coût. Le coût, c’est ce que vous prenez en charge : les décisions, les mises à niveau, l’obligation de maintenir quelque chose correct aussi longtemps qu’il est utilisé, la personne qui devra le comprendre dans quatre ans, quand aucun de ses auteurs ne sera plus là. Rien de tout cela n’est devenu moins cher. Une partie est même devenue un peu plus difficile, car un travail rapide à produire est aussi rapide à accumuler.
Une production moins chère change toutefois une chose. Elle abaisse le seuil à partir duquel construire la partie spécifique devient raisonnable. Un besoin qui ne justifiait pas un logiciel sur mesure au coût de l’an dernier le justifie parfois au coût de cette année.
Nous utilisons quatre questions, dans cet ordre.
Ce besoin diffère-t-il de la pratique des autres acteurs du secteur, et cette différence compte-t-elle pour un client ? Si ce n’est pas le cas, vous décrivez un achat.
À quelle fréquence change-t-il ? Un besoin qui évolue chaque mois et dépend du cycle de versions d’un éditeur restera une source de frictions aussi longtemps que vous le posséderez.
Que coûte une erreur qui dure six mois ? C’est la question que l’on saute. Elle distingue les décisions qui méritent une évaluation de celles qui méritent un après-midi.
À quoi ressemble la sortie ? Un système que vous ne pouvez pas quitter finira par être tarifé en conséquence.
L’essentiel se règle par l’intégration.
Un système acheté qui échange des données proprement avec le reste du parc informatique est un atout. Le même système, accessible uniquement par un fichier nocturne et un rapprochement manuel, est un problème qui grossit. Nous travaillons depuis des années sur ce point de jonction, et le schéma se répète : les organisations qui avancent vite sont celles dont les systèmes peuvent communiquer entre eux sans lancer de projet.
Depuis l’époque de BizTalk, l’essentiel de notre travail d’intégration porte sur ce point de jonction, et c’est par là que nous commençons avec le parc d’un nouveau client : une cartographie de ce qui a été acheté, de ce qui a été construit et de la manière dont on accède à chaque partie, avant que quiconque propose de remplacer quoi que ce soit. Les modèles que nous utilisons sont présentés dans gestion des API et événements, messagerie et données, et la sortie d’une plateforme vieillissante dans modernisation des systèmes hérités.
Alors : quelles parties de ce système entendez-vous encore maîtriser dans cinq ans, et les éléments que vous n’avez pas construits sont-ils accessibles depuis ceux que vous avez construits ?
De ce qui se construit à la manière dont on le livre : le prochain article porte sur ce qui change, et sur ce qui ne doit pas changer, quand un outil rédige le travail.
Fait partie de la série Insights. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
L’IA change le rythme auquel le travail de livraison est produit. Elle ne change rien à la question de savoir qui en répond. C’est la place de cette ligne qui fait d’une livraison assistée par l’IA un avantage ou un risque.
L’assistance de l’IA a eu sur nos projets un effet que nous n’attendions pas. Elle a creusé l’écart entre le travail bâti sur une base éprouvée et le travail parti de rien.
Dernier de trois articles. Un processus peut devenir spectaculairement plus rapide sans que l’entreprise avance vraiment. Le chiffre le plus modeste impressionnait beaucoup moins et servait beaucoup plus.
