Acheter une solution d’éditeur ou la construire soi-même ? Voici une question qui revient fréquemment en DSI. La réponse classique distingue coeur et contexte, et invite à construire ses outils coeur de métier (sous-entendu : ceux qui sont différenciateurs) et acheter ce qui fait le contexte. Mais cette approche binaire résiste-t-elle à l’épreuve de l’expérience ?
Quelques éléments d’histoire du marché du logiciel commercial
Le marché du logiciel a connu en 20 ans un mouvement de balancier important.
Au commencement étaient les ERPs et leur promesse d’unifier toute l’activité de l’entreprise (gestion de la production, comptabilité, fichier client, etc.). Ces solutions captaient l’essentiel des énergies des DSI et ont permis l’émergence de très grands groupes. Mais leur force constitue aussi leur grande limite : colorier c’est facile tant qu’on n’arrive pas aux bords ; de la même façon, difficile pour un ERP d’adresser toutes les spécificités de chaque business unit, leurs recompositions etc.
Entre 2005 et 2015, le slogan fut “there’s an app for that!”. Chacun d’entre nous dispose sur son téléphone d’applications spécialisées (celles qui ont réussi ont réussi car elles répondaient de façon très effficiente à un besoin, et un seul) et, dans la foulée, chaque micro-fonction de l’entreprise (même celles qui ont dû longtemps se débrouiller avec Excel) a pu bénéficier d’outils très adaptés à ses besoins.
Le retour de balancier est en train de se produire. Depuis 5 à 8 ans, chaque éditeur d’application essaie de conquérir de nouveaux marchés et pour cela de couvrir un périmètre fonctionnel plus large, jusqu’à s’ERP-iser.
Les **DSI se retrouvent à devoir jongler **avec
Moult outils de CRM (le CRM généraliste, l’outil de segmentation, l’outil de marketing automation, le canon à email qui prétend être une CRM, l’outil de retargeting, le centre de contact plus ou moins omnicanal, l’outil de ticketing etc.) voire plus si les BU ont fait des choix autonomes,
plusieurs ERPs (mais pourquoi est-ce la solution spécialisée en gestion de stocks et d’ordonnancement de lots de production qui gère les devis et commandes clients pour telle BU ?)
N SIRH (la solution choisie pour gérer la formation était en fait un SIRH complet, d’ailleurs celui pour gérer la paie aussi, mais c’est aussi un ERP), etc.
Ajoutez à cela les fusions et acquisitions d’éditeurs, les reboots laissant sur le carreau de l’obsolescence technologique la solution phare que vous avez achetée il y a 5 ans et dont vous venez de terminer à prix d’or l’intégration, et vous comprenez le quotidien de beaucoup de DSI et leur cycle infernal de remplacements d’ERPs tous les 5 ans (comprenez, vu ce qui précède, qu’ils ne changent en fait que 20% du SI, donc le plus vieil ERP qui tourne toujours chez vous a sans doute 25 ans et est maudit par chaque nouvel arrivant).
Dans ces conditions, difficile de considérer le logiciel comme un actif durable de l’entreprise. Et quand il est durable, ce n’est pas par ses mérites propres mais par l’énergie considérable nécessaire pour le faire évoluer.
La difficulté de borner le coeur du contexte ?
Comment distinguer le coeur et le contexte sans se couper un bras, ou à l’inverse réinventer la roue ? L’arbitrage n’est pas toujours aisé.
Certains pourront limiter le coeur au seul produit de l’entreprise.. mais dans certains cas, c’est bien restrictif quand on sait aujourd’hui que le choix d’une marque dépend côté B2C essentiellement de l’expérience client, où la relation-client joue un rôle au moins aussi important que le produit.
Outre cet aspect “visibilité du client”, un deuxième axe entre en ligne de compte quand on parle de logiciel : la notion de maturité technologique.
Simon Wardley a proposé une approche intéressante consistant à cartographier sur un repère “visibilité client x maturité technologique”. Cette approche permet de sortir du dualisme entre make et buy.
La troisième voie : assembler !
Sur ce chemin de maturité technologique, un certain nombre de solutions se sont “commoditisées”. Par exemple, vous pouvez aujourd’hui faire du text-to-speech sans aucune connaissance en machine-learning, via un simple appel d’API.
Mais en quoi l’approche “assemble” se distingue-t-elle de “buy + intégrer” ?
L’entreprise qui achète des solutions et les intègre a in fine N applications possédant chacune sa base de données, s’appuyant chacune sur sa propre représentation du processus métier, dépendant chacune de la roadmap (et du cycle de vie) de son éditeur, où il est souvent impossible de planquer les écrans inutiles par un jeu de rôles adéquats (sans parler de la gestion de l’identité des utilisateurs, qui fait souvent partie du pack premium hyper cher). A ces applications, il faut ajouter un paquet de jobs d’ETL ou d’ESB qui font souvent un plat de spaghetti. Dans un tel écosystème, la DSI est remplie de gens qui n’ont aucune focalisation sur le métier de l’entreprise.
L’approche “*assemble” *est en fait radicalement différente. **Dans cette approche, on n’achète plus des produits d’éditeurs packagés, mais des briques à assembler pour en faire un produit unique (et unifié) maîtrisé en interne. Ces briques ont un **cycle de vie beaucoup plus stable que les solutions d’éditeurs, car elles répondent à la logique de spécialisation qui fut le “second âge du logiciel” que j’ai décrit auparavant ; elles ne s’appuient pas sur un silo de données ; on mobilise uniquement celles qui sont nécessaires.
Le passage à un modèle d’assemblage nécessite un haut niveau de dialogue entre la DSI et les métiers.
Côté métier, cela nécessite de renoncer à choisir soi-même ses solutions (souvent sur la base de jolis dashboards que personne ne consultera une fois la solution lancée) en cédant au harcèlement des commerciaux et préférer exprimer des besoins auprès de sa DSI ;
Côté DSI, ça veut dire adopter une mentalité de *builder orienté client*, en sortant d’une sur-spécialisation (un dev front ne peut plus se complaît dans sa seule expertise web-design et doit penser solution pour faire vraiment de l’UX) avec le développement d’une compétence essentielle, celle de **l’architecture solutions (qui doit être répartie **dans les équipes et pas juste l’apanage d’une cellule architecture hors-sol).
Besoin d’aide pour construire cette culture ? Avec TerraCloud, je vous aide à diffuser cette mentalité d’architecture solutions dans vos équipes et à mobiliser la boîte à outils / lego du cloud pour construire les solutions qui vous permettront de soutenir votre business de demain (et d’après-demain !)
Top comments (0)