Stratégie Informatique : Buy or Build or Rent ?

 

 

L’informatique est un actif stratégique dont l’efficience conditionne très fortement la performance des entreprises, quel que soit le marché dans lequel elles  opèrent.  Acheter un progiciel (produit-logiciel) ou développer soi-même ? Une décision lourde de conséquences et qui doit s’inspirer principalement de votre vision stratégique, de votre politique commerciale, de votre aversion aux risques, de vos moyens de financement et enfin de vos besoins d’intégration technique, organisationnelle ou même culturelle: l’Informatique peut être une ‘arme anti-silos’ permettant de mieux fédérer les différentes entités d’un groupe tout en unifiant sa gamme de services.

Le service aux Fonds d’Investissements recouvre plus de 10 métiers. Aux 4 piliers que sont la Comptabilité, la Banque Dépositaire, l’Agent de transfert et la Gestion de Portefeuilles, il convient d’ajouter  le global TA (intermédiation), le contrôle des restrictions d’investissements, la gestion de la vie sociale, les services de publication, les services juridiques, l’administration des fonds alternatifs... De même, les développements informatiques sont souvent proposés comme un service à part entière, se déclinant en prestations personnalisées de reporting, construction d’interfaces, migrations….Un tel patchwork soulève des défis considérables en termes de maîtrise des coûts et des risques, pilotage de l’innovation, tout spécialement dans la conjoncture très concurrentielle et très régulatrice que nous connaissons.

Les défis. Chaque métier dispose de sa propre application. Symétries : les nomenclatures ne sont jamais codées de manière identique entre les systèmes et elles ne sont pas toujours univoques ; ceci amenant une inflation de ‘passerelles’ dont la seule valeur ajoutée est de servir d’interprètes, de convertisseurs de données entre les applications. La recherche du Graal informatique qui se qualifie par les mots-clé : ‘alignment, integration, quality, responsiveness, flexibility, costs containment, scalability, re-usability, inter-operability...’

L’offre des services d’hébergement et d’administration s’est élargie avec le ‘cloud computing’ et ses différents déclinaisons (AaaS, SaaS, PaaS,….) mais des choix cornéliens subsistent : comment se différencier ? Acheter un package ou développer soi-même ?  Opter pour une architecture hybride composées d’un ou de plusieurs progiciels alimentant une base de données internes servant de socle pour des services personnalisés (reporting…) ?

Buy or Rent an IT solution

Acheter ou louer un progiciel ? Comptablement et pratiquement, cela revient au même, dans la mesure où cette option est inconcevable si elle n’est pas assortie d’un service de maintenance.  Généralement on achète ou loue un droit d’utilisation.

Le recours à un progiciel se justifie prioritairement pour les prestataires qui ont opté pour une stratégie de « domination  par les coûts » car ce choix permet de profiter des effets de mutualisation tout en minimisant les coûts d’opportunité du fait de la réduction des délais de mise en place. Vous pourriez objecter, à juste titre, que vous retrouverez ces mêmes coûts d’opportunité lorsque vous devrez attendre le bon vouloir du fournisseur pour livrer de nouvelles fonctionnalités: vous serez évidemment ‘prisonnier’ du calendrier des nouvelles versions. Certains éditeurs consentent à maintenir des versions ou modules spécifiques par client : il s’agit d’un pis-aller dangereux qui vous expose à une inflation de coûts et une baisse de qualité car votre fournisseur pourrait éprouver des difficultés à appliquer les tests de non-régression sur les éléments dont vous avez l’exclusivité.

Acheter un progiciel avec la capacité de le faire évoluer soi-même représente un investissement et une somme de risques que peu d’entreprises sont prêtes à prendre, sans parler des délais ‘d’apprentissage’ de l’architecture des programmes et de la documentation, points de passage obligés avant d’envisager tout développement.

Build

Si vous optez pour la ‘domination par la qualité’, une solution interne vous offrira en théorie plus de souplesse pour personnaliser le service selon les besoins de vos clients. Une telle option doit être recommandée si les critères suivants sont réunis :

• Un marché très distribué sur le plan géographique, chaque nouveau client pouvant nécessiter des adaptations, au niveau des interfaces, du reporting ou mêmes des processus de calculs (commissions, valorisation, fiscalité). Il est clair qu’il vous sera difficile de répondre à ce type de demandes si vous êtes dépendant du calendrier des versions du fournisseur.
• Des délais et coûts « compatibles » pour la mise en place: éviter les stratégies de rattrapage, méfiance vis-à-vis des projets pharaoniques, un plan directeur garantissant des résultats échelonnés.

A la longue, les solutions internes vont soulever 3  types de problèmes:

• Vieillissement accéléré avec comme symptômes : une croissance constante des coûts de maintenance et une dégradation du taux de disponibilité des applications.  Ces 2 paramètres doivent être surveillés attentivement en définissant les bons KPI dans votre « management cockpit (*)».
• Financement et planification du remplacement, avec des charges financières extrêmement lourdes pour maintenir en même temps l’ancienne et la nouvelle architecture, pendant la durée du projet, laquelle peut se chiffrer en années.
• Coûts de structure générés par tout le staff requis pour assurer les développements de nouvelles fonctionnalités (analyse, programmation, tests), l’administration des bases de données et des logiciels systèmes, etc.  Certaines de ces charges peuvent être externalisées par exemple en recourant au cloud computing.

Ces 3 ‘pathologies’ peuvent également se présenter avec un progiciel mais en principe de manière plus modérée et plus facile à maîtriser.

Se différencier avec un progiciel

Il existe de nombreuses possibilités pour personnaliser un progiciel et pour être plus performant que vos concurrents utilisant la même plateforme.

 

Maîtrise du logiciel. Soignez tout particulièrement la mise en place : une réflexion soutenue et formalisée (cahier de charges) doit être menée sur le business model (segments clients/produits), la cartographie des processus (*), les sécurités… avant de commencer à paramétrer le système : faire l’économie de cette préparation vous expose à des déceptions, des coûts et une sous-utilisation de la plateforme. Ne confondons pas vitesse et précipitation, synonyme d’improvisation, tâtonnements…coûts et retards !

Pour gagner du temps, il est souvent tentant de s’appuyer sur le paramétrage natif, généralement hérité d’autres clients. Une attention extrême doit  être accordée au respect des concepts, typologies et autres nomenclatures. A titre d’exemple, il peut être tentant de contourner une limitation sur un calcul de commission en clonant un code opération ou un type d’instrument financier: une telle action va provoquer des séquelles difficilement réparables car elle va polluer les historiques et nécessiter des regroupements spécifiques dans le reporting, les traitements comptables, etc. Ces regroupements seront nécessaires pour occulter les artifices mis en place.

Aujourd’hui certains logiciels disposent d’un ‘moteur de règles’ permettant de paramétrer directement des règles de gestion (sortes de ‘macros’), en utilisant un meta-langage suffisamment convivial que pour pouvoir être utilisé par des utilisateurs non-informaticiens. Cette souplesse ne permet en aucune manière de faire l’économie des tests et de la documentation de ces algorithmes.

Formation et expertise. Il n’est jamais simple de maîtriser les corrélations entre toutes les ‘typologies’ permettant de configurer une application (instruments, opérations, schémas comptables…) et surtout d’appréhender correctement les multiples impacts que tout changement peut apporter. L’acquisition de ce savoir-faire est tout simplement vital (business critical) pour garantir la qualité et la disponibilité des services.

 

Intégration (STP, STE, synchronisation, symétries fonctionnelles) avec les solutions déjà en place, gage de domination par les coûts grâce aux gains de productivité.

Profiter des évolutions fonctionnelles amenées régulièrement par le fournisseur. Eviter les retards de versions mais sans nécessairement faire la course en tête : vous pourriez devoir absorber les maladies de jeunesse et le payer en qualité de services et productivité.

Base de données et reporting. La plupart des fournisseurs offre la possibilité de déverser les données applicatives dans une base de données exploitable par des outils de ‘Business Intelligence’. La même attention doit être accordée au design de cette solution. Bien des Bases de données ont été construites par empilement successif de strates de données et n’ont pas été préparées par une définition de l’architecture cible globale. La conséquence en est des univers de données aux contours imprécis et parfois redondants.

L’Informatique est un actif stratégique

• Il est possible de se différencier avec un progiciel, en se dotant de toutes les compétences requises pour en exploiter pleinement les fonctionnalités et en veillant à respecter scrupuleusement toutes les nomenclatures : gages de qualité et de performance et un excellent moyen d’en retarder le vieillissement.
• Les projets informatiques peuvent également être un fort levier d’intégration organisationnelle et même culturelle ainsi que de rationalisation et de standardisation de votre gamme de services.
• La bonne fin des projets est toujours un enjeu stratégique. Un projet réussi est un projet qui a atteint ses objectifs, en respectant le budget et le planning. Un projet pleinement réussi a également su maîtriser les risques, n’a pas causé de dommages collatéraux et a permis de mettre en place des solutions pérennes, évolutives, documentées et des processus possédant la ‘maturité’ (*) requise (stables, performants, avec un personnel formé et encadré…).
• L’Informatique est un actif stratégique et un outil dont l’efficience doit être systématiquement présentée dans votre ‘Management Cockpit’ (*) en vous dotant des KPI permettant d’en mesurer la performance, le vieillissement, la disponibilité, les risques, l’avancement des projets…

Le débat principal n’est peut-être pas ‘buy or build’ mais comment construire l’architecture permettant de répondre au mieux aux besoins stratégiques, tactiques et opérationnels, comment assurer l’intégration et l’intégrité de toute cette architecture et les réponses semblent évidentes : par la mise en place d’une fonction gestion globale des données au niveau de l’entreprise, fonction s’appuyant sur Base de Données permettant de fédérer les différents applicatifs.