une transformation de certaines valeurs de la culture de l’entreprise. En effet, le Lean et les principes du Lean Software Development présentent un cadre idéal pour obtenir un travail prospère avec Scrum.
Mais avant tout, l’organisation de ce mémoire s’est construite autour d’une question clef ; la réponse à celle-ci a requis une démarche qui s’est déroulée en deux temps. Tout d’abord, une analyse qualitative aura permis d’approfondir les dimensions du processus des systèmes de Portfolio Management à la recherche des éléments qui contribuent à la réduction du taux de rejet des interfaces bancaires. En guise de rappel, la première (et globale) question de recherche s’est articulée autour des éléments à potentiel non exploité mais propices à la réduction du taux de rejet des interfaces qualifiées de PSI.
A partir de cette première recherche qualitative, de nombreuses possibilités ont été explorées à l’aide de huit hypothèses émises, et au fur et à mesure vérifiées. Toutefois, l’ensemble de ces efforts et de ces démarches entreprises ont ensuite visé une seule réponse argumentée quant à la question de recherche fondamentale pour ce manuscrit :
« Quel modèle organisationnel de développement de PSI présente la meilleure adéquation
avec l’environnement du PMS pour réduire son taux de rejet ? »
La légitimité de concentrer les efforts de ce travail à l’importance du développement des interfaces PSI est fondée par le lien direct entre la performance de ces interfaces et la performance globale des PMS. En effet, la question de recherche s’inscrit au cœur d’un facteur déterminant de la performance d’un logiciel de Portfolio Management. Les deux facteurs clefs sont notamment la performance des fonctionnalités permettant la gestion de portefeuille et l’accès instantané à l’information (e.g. les interfaces).
Du point de vue du responsable de produit, la réduction du taux de rejet d’une PSI se justifie par son influence négative sur la valeur ajoutée du PMS. En effet, les interfaces sont un des attributs saillants d’un logiciel PMS et son dysfonctionnement se traduit par une diminution de la valeur perçue par le client. Le dernier argument justifiant le choix du sujet de recherche concerne la rentabilité de l’utilisation du produit. Par un niveau bas du taux de rejet, l’utilisation d’un tel outil de PMS nécessite un investissement moindre en ressources quant à son entretien (mise à jour). Or ce dernier élément améliore le ROI de l’acquisition du produit.
Le recensement de l’état actuel du taux de rejet s’est avéré plus compliqué que prévu initialement à cause de l’absence de statistiques. En effet, les résultats obtenus varient entre 5 et 15%. En revanche, les réponses obtenues quant au recueil des catégories de rejet étaient unanimes. La catégorie de rejet la plus importante est celle liée à la nature particulière de certains instruments financiers. Cette description est large mais la catégorie comprend principalement les produits sans identifiant unique (ISIN, IBAN, options américaines, produits des marchés primaires, etc.) et certains autres produits dérivés (contrats particuliers). La deuxième grande catégorie de rejet concerne les incompatibilités des contenus de données transférées par les banques (incompatibilité des Backend Portfolio Datas).
L’analyse de l’environnement et du processus de PMS a relevé que les exigences quant au développement d’un outil de PMS sont effectivement élevées. Une telle affirmation s’explique par la complexité élevée à la fois des fonctionnalités de l’outil et de son environnement. En guise de rappel, le contexte du développement d’un tel
Par leurs connaissances métiers, la capacité réelle « d’interfacer » les transactions rejetées incombe à un employé d’un établissement bancaire, d’un centre d’opération ou encore d’un Family Office. A court terme, une piste possible d’amélioration des logiciels d’interfaçage consiste dans le transfert et la traduction de ces connaissances métiers aux développeurs des interfaces. Le développeur, quant à lui, tente de comprendre et de reproduire quelques-unes des pratiques métiers (cf. Tableau 3) par le logiciel des interfaces.
Tableau 3 – Meilleures pratiques métiers
Nom Description Acteur(s) clef(s)
Code d’opération
Le code d’opération désigne la nature d’une transaction financière mais il est propre à la banque. Dans le cas de l’absence du no ISIN d’autres difficultés, la banque détermine déjà la nature du produit. Or, le code d’opération peut servir d’éventuel identifiant unique quant à un produit.
IS bancaire Back-Office bancaire
Base centrale des produits
Les banques entretiennent une propre base de données dans le cas d’un produit sans identifiant unique (dérivé en forme de contrats particuliers, options américaines, produits OTO, etc.). Dès la régulation d’un tel instrument financier, il est réalloué à l’identifiant unique des marchés électroniques.
IS bancaire Back-Office bancaire
Référentiel de prix
Dans le cas courant de consolidation multi-banque, la création d’un référentiel de prix constitue une solution possible pour garantir l’unicité des prix. Cette pratique vient du milieu bancaire mais ne s’est pas (encore) démocratisée chez les entreprises PMS (à cause de difficultés juridiques).
(PMS direction) PSI développeur PMS consolidation
Compte fiducies
Il s’agit d’un compte technique, purement virtuel, qui permet la gestion des contrats à terme sur devise. Or, tout PMS doit disposer de la fonction de la création d’un compte virtuel mais avec certaines astuces, le logiciel peut potentiellement identifier ces transactions (reconstitution d’une information fractionnée). PMS consolidation Back-Office bancaire Analyse de transaction par nature
Cette pratique est généralement utilisée pour la correction des transactions rejetées. Par la compréhension des événements liés aux transactions d’un logiciel (e.g. maturité, mouvement de cash, settlement, out of money etc.), ce dernier arriverait à diminuer le taux de rejet.
PMS consolidation Back-Office bancaire
Daily Mangement
Par une analyse quotidienne ou hebdomadaire des transactions rejetées, on connaîtrait le nombre exact et les causes des différentes catégories de rejet. Cette pratique est la première démarche dans la résolution de problème : N.B. la compréhension des données.
PMS consolidation
Série de tests
Les séries de tests sont conduites lors du développement d’une interface. Des fonctionnalités mal définies et testées se traduisent potentiellement par des taux de rejet plus élevés causés par des problèmes techniques initiaux.
PMS consolidation PSI développeur IS bancaire Back-Office bancaire
Tests d’intégrité des données manuels
Les tests consistent dans la vérification des données obtenues (Backend Portfolio Data) par des tests manuels supplémentaires.
PMS consolidation PSI mise à jour
Source : Auteur (2013)
Avec comme objectif le développement d’un certain nombre de nouvelles fonctionnalités imitant les pratiques métiers, l’analyse de l’adéquation entre le modèle organisationnel et l’environnement PMS démarre. A titre d’exemple, l’une des nouvelles fonctionnalités pourrait s’articuler comme : « l’interface imite trois pratiques de
l’analyse par nature des instruments financiers qui permettent l’interfaçage des trois catégories de rejet les plus courantes ».
Les caractéristiques de l’organisation actuelle du déroulement d’un projet de développement d’une nouvelle interface ressemblent fortement au modèle de cycle en « V » ou de RAD, avec une préférence pour les caractéristiques des modèles prédictifs (planification initiale, déroulement linéaire, absence de séparation des aspects liés aux différents métiers), mais avec toutefois un certain degré de liberté. En effet, l’interaction entre les différents membres de l’équipe de développement, avec un transfert réel des connaissances et un niveau élevé de dialogue, est marquée par un esprit fortement favorable à une approche agile. Cette dynamique permet une plus grande réactivité quant à la détection et à la correction des erreurs de planification commises.
Pour la recherche de nouvelles idées novatrices propices à la résolution d’une partie du problème du taux de rejet, l’équipe actuelle de développeurs est limitée par leur compétence purement technique. Désormais, les solutions possibles sont multidisciplinaires et contiennent des aspects des différents métiers et composants du processus global de PMS. Or cette même pluralité doit se refléter dans les différentes compétences disponibles au sein de la nouvelle équipe de développement. Par conséquent, ce rapport recommande que des personnes
avec un profil Back-Office bancaire ou opérateur du centre de traitement (consolidation), voire même un client (PSI mise à jour), s’ajoutent toujours à l’actuelle équipe.
Les facteurs clefs de réussite de l’organisation d’un projet agile sont une réactivité forte et continue avec son environnement, une créativité et une autonomie élevée des équipes et le transfert réel de connaissances. Généralement, les nouveaux mots clefs quant au cadre organisationnel et à la gestion de l’équipe gagnante sont :
Acceptation de l’incertitude dans un cadre défini Equipes et projets autogérant
Chevauchement des phases de développement (itérations) Compétences multidisciplinaires
Contrôle subtil
Transfert des leçons et meilleures pratiques apprises
Le choix du modèle organisationnel a porté sur Scrum pour sa forte compatibilité avec ces derniers principes organisationnels et l’environnement des PMS ou PSI. Scrum est un modèle fortement agile qui se base sur une planification et un déroulement du travail par cycle (appelé Sprint). Avant tout, Scrum se présente comme un condensé des meilleures pratiques en termes de développement de logiciel de ces cinquante dernières années. Les différentes dimensions de ses pratiques s’articulent autour des rôles, des revues et adaptations (séances), des artéfacts (tableau de bord) et des techniques.
Scrum soutient étroitement l’approche hautement collaborative qui met au profit les compétences multidisciplinaires des membres à la réalisation d’une meilleure interface. L’équipe de développement est gérée avec un haut degré d’autonomie. Les bénéfices de telles approches se traduisent généralement par un comportement plus responsable des membres. En revanche, ces modes de travail exigent une grande ouverture d’esprit pour ces membres, tout comme pour la direction et le management qui les soutiennent.
Scrum permet avec ces bonnes pratiques et des outils simples quant à la gestion et à la visualisation de l’organisation du travail un déroulement contrôlé des projets, et ce même avec une équipe plus grande. Avec Scrum, l’effet de tunnel et la problématique du delivery-gap sont fortement réduits. En effet, les risques liés à ces deux phénomènes se situent désormais au niveau de la durée d’un Sprint (voire d’un jour selon l’efficacité de la gestion quotidienne des projets) et plus au niveau de la quasi-totalité de la durée.
A court terme, le coût des projets risque de dépasser le coût moyen actuel. Cependant, ce coût supplémentaire est un investissement pour obtenir une qualité supérieure des interfaces avec un taux de rejet moindre. Au-delà de la qualité améliorée des interfaces, les ressources humaines de l’entreprise bénéficient également de la nouvelle structure organisationnelle avec un poste de travail plus valorisant, intéressant et motivant. A terme, ces mêmes facteurs bénéficient à l’entreprise et à l’amélioration de ses structures de coût des projets. Scrum soutient étroitement ce processus et assure l’atteinte du ROI équilibré dans des délais intéressants.
Parallèlement, la probabilité de réussite est un des facteurs clefs et décisifs face à tout changement organisationnel. En général, le facteur de réussite avec Scrum est particulièrement élevé. Dans le cas présent du développement d’une PSI, les critères de réussite de projets comprendront désormais également le taux de rejet comme étant le nouveau critère décisif. Cette démarche de qualité assure l’alignement stratégique des projets de développement des interfaces et accélère le changement de la culture d’entreprise.