SI bancaires dans les nuages !

De plus en plus, dans les journaux spécialisés, dans les séminaires et conférences dédiés aux SI bancaires, on parle de cloud computing et d’infrastructures externalisées et distribuées ; et on commence même à voir ces notions déclinés pour le grand public sur divers supports publicitaires (internet, TV…).

Concrètement, il s’agit d’une offre d’allocation dynamique de services informatiques comprenant une combinaison d'applications, plates-formes et / ou de capacité de matérielle, au travers d’un réseau de systèmes géographiquement disséminés. Le cloud computing peut être interne (private cloud) ou externe (public cloud), dans ce qui suit, on ne s’intéressera qu’à ce dernier.

Un des grands avantages du cloud, est celui des coûts, où on promet des réductions significatives en terme de coûts de détention et d’utilisation des infrastructures IT (logicielles et matérielles). Matérielles, dans le sens où on se préservera de mettre en place des ressources dédiées pour telle ou telle application avec ce qu’on connaît comme coûts d’achat et de maintenance. Quant aux avantages sur les coûts des logiciels, il s’agira de ne payer que les logiciels au moment de leur utilisation et non plus payer des licences souvent chères pour une utilisation qui risque d’être limitée.

Les Cloud Service Providers (CSPs) qui offrent des services de IaaS (Infrastructure as a Service), de DaaS (Database as a Service) ou de SaaS (Software as a Service) proposent des modèles de tarification « adaptés » à l’utilisation des dits systèmes ou infrastructures de telle façon à ce qu’on ne paye que ce qu’on a exactement consommé. Le problème c’est que ces modèles de tarification et de facturation sont encore trop compliquées dans une grande partie des cas et donc difficilement cernables par les clients.

 Ceci dit le modèle promet d’être très bénéfique sous plusieurs aspects, dont une meilleure gestion de la trésorerie, dans la mesure où il n’y a plus d’investissements lourds et d’immobilisations de capitaux puisqu’on passe à un modèle proche de la location de services et d’infrastructures. D’un autre côté, ce modèle offre une meilleure flexibilité et réactivité face à une augmentation ou une baisse de charge significative relevant de l’activité de la banque. Par ailleurs, ceci devrait permettre à l’équipe SI interne de la banque de se décharger de certaines tâches quotidiennes de maintenance, de patchs de logiciels… et de se concentrer sur les problématiques à vrai valeur ajoutée pour leur banque.

Tout cela est trop beau, mais qu’en est-il de la réalité des banques ?

Il faut dire que certaines banques (en majorité américaines) ont déjà opté pour ce modèle, mais à quel point ? A ma connaissance, aucune ne l’a encore fait pour ses données ou applications critiques. Ceux qui ont tenté l’expérience, l’ont fait essentiellement pour les applications bureautiques ou encore pour certaines applications de support et données non critiques. Et il est encore tôt pour en tirer les leçons.

Il faut dire que certaines questions restent encore sans réponses ou du moins pas très satisfaisantes. On peut citer, le problématique de capacité et de fiabilité des infrastructures réseau, celle de l’emplacement physique et de l’accessibilité aux données (problématique légale dans la majorité des pays), et surtout la question de la sécurité qui reste Le principal défi à relever par les CSPs.

La conduite de changement ou les conditions de succès d’un nouveau système d’information

Conduire un projet de refonte d’un système d’information bancaire, que ce soit totale ou partielle, est toujours une tâche très compliquée et qui nécessite l’implication de plusieurs compétences fonctionnelles, techniques et managériales très pointues.

Partons du postulat qu’on est dans une banque qui a beaucoup d’expérience dans la gestion de ses projets, qui a su choisir la solution la plus adéquate avec une très bonne équipe d’intégrateurs, de consultants MOA et une équipe d’experts métiers internes triés sur le volet. Cela lui permettra certainement d’atteindre ses objectifs de mise en place de son système dans les meilleurs délais, avec la meilleure qualité et avec un minimum de dépassement de budget. Mais cela ne lui garantit en rien que ce système ne soit pas rejeté totalement ou partiellement par ses futurs utilisateurs et donc, in fine, les objectifs business ou stratégiques visés par la mise en place de ce nouveau système ne seront probablement jamais atteints.

Qu’est ce qui a pu clocher, pourtant, à priori, toutes les conditions de réussite étaient là ?

Lors de la mise en place d’un nouveau SI au sein d’une banque, le focus est souvent mis sur les aspects techniques, fonctionnels, sur le planning de réalisation, sur les risques, la qualité… Un projet de SI est aussi souvent accompagné (ou précédé) par une refonte ou une revue des processus et méthodes opérationnels ou même d’un changement d’organisation des équipes ou des bureaux ; c’est aussi l’occasion de lancer ou développer de nouveaux produits ou services.

Un aspect est parfois négligé ou du moins souvent mal abordé, et qui est l’aspect humain et sa capacité à adhérer et adopter les changements ; et c’est là qu’on doit s’intéresser à la Conduite du Changement.

La conduite du changement vise à définir et mener les actions de communication, de formation et d'organisation qui prépareront les services utilisateurs à l'arrivée et à l'utilisation d'une application informatique. Ces actions sont menées tout au long du cycle de développement et de mise en œuvre d'un projet.  (Source : http://www.minefe.gouv.fr)

Concrètement, il s’agit de faire participer les futurs utilisateurs du système aux différents choix fonctionnels et organisationnels durant tout le long du projet, de mettre en place une communication permettant de suivre l’avancement du projet mais aussi qui permette de mieux comprendre les choix et les décisions prises et enfin il s’agit de bien former ces utilisateurs à l’utilisation et l’appropriation du futur système.

Toutes ces actions doivent avoir comme objectifs principaux de faciliter l'acceptation des changements induits par la mise en œuvre de ce nouveau système et de réduire les facteurs de rejet.

Parmi les clés de réussite d’une telle démarche, c’est le partage de la vision stratégique et la participation des utilisateurs dans les différentes étapes du projet et aux différents choix (Au moins donner l’impression de le faire, car ce n’est pas toujours évident de prendre des décisions collectives). Il faudrait aussi les impliquer et les responsabiliser, voire les motiver, sur les résultats du projet ; ce qui les aidera à s’approprier le projet et la nouvelle organisation et donc à atténuer les facteurs de rejet. Ceci aidera, notamment, à anticiper certains risques liés aux changements.

Présentée de cette manière, la problématique pourrait paraître assez simple, mais en réalité elle n’est pas moins complexe que les autres aspects du projet.

Enfin, je dirai que mettre en place un démarche de conduite de changement efficace pour accompagner un projet de changement de système informatique au sein d’une banque nécessite le recours à des compétences pointues et très expérimentées qui impliquent principalement les fonctions de DSI, de PMO, de DRH, de communication interne, de MOA, de direction générale (selon l’importance du projet), et certainement l’aide d’un cabinet externe.

La Tunisie et Bâle III

Voilà une question que m’a posé certains de mes collègues au moment où tout le monde en Europe, aux Etats-Unis passant par la Chine et le Japon essayait de mieux cerner ces nouvelles « directives » ou réglementations et comprendre leur impact sur leur système financier et plus généralement le système économique mondial et que toute la presse mondiale, spécialisée ou pas, se déchaîne sur la question. Alors pourquoi pas nous aussi, nous ne cherchons pas à traiter la question sous notre angle ?

Rappelons que les accords de Bâle III étaient prévus initialement pour 2015, mais crise financière oblige, ces nouveaux accords ont été anticipés et viennent d’être publiés et doivent être entérinés lors du sommet du G20 en Novembre à Séoul.

Sans rentrer dans les détails techniques de la réforme, citons qu’elle a pour principaux objectifs de renforcer la capacité des banques à résister à de nouvelles crises et surtout les banques d’importance systémique ou ce qu’on appelait les « too-big-to-fail ».

Revenons maintenant à notre contexte Tunisien et rappelons « fièrement » que malgré la crise mondiale notre secteur financier est en bonne santé et affiche depuis des années des taux de croissance importants atteignant parfois les deux chiffres chez certaines banques cotées. Rappelons aussi que suite aux efforts de la banque centrale depuis quelques années, on voit les actifs des banques s’améliorer nettement et être mieux provisionnés.

Cependant, tout le monde ou presque s’accorde pour dire que nos banques sont trop petites comparées à celle de pays ayant le même niveau de développement ; si on se compare au Maroc, par exemple, le total de bilan du champion national Attijariwafa Bank est, presque, trois fois plus important  que ceux des trois plus importantes banques tunisiennes BIAT, STB, et BNA réunies.

Ceci étant exposé, je dirait que les accords de Bâle III ne nous concernent en aucun cas (en tout cas pour le moment), pour deux raisons très simples : nos banques sont trop petites (pas de banques à risque systémique chez nous) et nos banques sont en bonne santé.

Mais, depuis quelques mois et avec l’annonce d’un projet de fusion STB-BH,  tout le monde s’accorde pour dire qu’il nous faut un champion local, une très grosse banque en Tunisie, un mastodonte de la finance locale. Outre le fait que nos voisins ont de très grandes banques, la première raison avancée est le fait d’avoir des banques capables de financer seules de très gros projets. Deuxième principales raison, est que ladite banque aura la possibilité de prendre des risques plus importants.

Si on s’arrête à ces deux arguments, je dirai qu’on doit s’y mettre très vite à Bâle III, mais avant ça à Bâle II et créons une banque géante qui lorsqu’elle coulera, nous coulera tous avec elle, qu’elle soit conforme à Bâle III ou Bale XXII, mais ça c’est un autre débat !

Je finirai par une citation de Warren Buffet qui dit  “Of one thing be certain: if a CEO is enthused about a particularly foolish acquisition, both his internal staff and his outside advisors will come up with whatever projections are needed to justify his stance. Only in fairy tales are emperors told that they are naked”.

Système de gestion des crédits : Comment choisir la meilleure solution

Dans mon précédent post sur l’importance du système de gestion de crédit dans un SI système d’information bancaire , j’ai essayé de présenter de façon simple et synthétique le pourquoi et le quoi, c'est-à-dire ce qu’on peut et ce qu’on doit trouver dans une solution de gestion de crédits. Aujourd’hui j’essaierai de donner quelques pistes sur comment trouver la meilleure solution.

Quand on commence à chercher on peut tomber sur des dizaines d’éditeurs et de solutions de gestion de crédit « ou d’engagements », et pour cela il suffit de visiter quelques sites spécialisés ou lancer une simple recherche dans google. Et là une première problématique se pose, comment faire en sorte de restreindre ce nombre (plusieurs dizaines) à cinq ou six de façon à ce qu’on puisse faire facilement notre choix ?

Mais une fois ce premier choix fait, la question est de savoir maintenant, la quelle de ces solutions est LA meilleure ?

1-     Tout d’abord, il faut savoir qu’il n’existe pas une meilleure solution dans l’absolue.

2-     Avant de commencer à consulter les éditeurs et les intégrateurs, il faudrait savoir exactement ce qu’on cherche ! Rédiger un bon cahier des charges détaillé, paraît évident pour certains mais croyez moi, c’est loin d’être le cas pour toutes les banques.

3-     Vous pouvez rédiger le cahier des charges seuls ou vous faire aider par des consultants externes, mais le plus important c’est que ce soit fait en forte collaboration avec les équipes internes d’utilisateurs clés. Attention surtout à ne pas le faire rédiger par ces derniers, le résultat peut être surprenant.

4-     La rédaction du cahier des charges doit se fonder sur l’existant de la banque et ses spécificités, sur l’organisation actuelle et future de la banque, sur l’évolution du marché et des produits et sur les contraintes et évolutions technologiques et réglementaires.

5-     Souvent un projet de changement de système d’information est accompagné par un projet de refonte ou d’optimisation des processus et méthodes.

6-     Au moment de réfléchir à faire un choix sur la mise en place ou non d’une fonctionnalité, la question à se poser ne doit jamais être « Pourquoi pas », mais plutôt « POURQUOI » ? Car vouloir mettre en place dans son nouveau SI des fonctionnalités qui n’ont ni justification business ni process, peut être très coûteux et peut avoir des conséquences dramatiques sur le projet et le fonctionnement de la banque.

7-      Il faut toujours se méfier des fonctionnalités et termes à la mode que tous les éditeurs adorent présenter comme si ça allait révolutionner le métier du crédit et votre façon de faire ; Ils se feront un plaisir fou à vous venter les mérites de leur super système de workflow totalement automatisé ou de leur séparation Front, Middle et back-office ou encore vous bâtir des châteaux en Espagne avec de la SOA et du web 2.0.

8-     Une fois votre cahier des charges finalisé, consultez les 5 ou 6 éditeurs (max) dont le système semble coller au mieux à vos attentes.

9-     Outre le fait que la solution doit coller au mieux à vos besoins, il faudrait privilégier les éditeurs qui ont déjà des références locales, ou régionales de leur produit. Ca permettrait d’éviter un certain nombre de surprises et de développements spécifiques ; terme que tous les éditeurs adorent vous sortir une fois le bon de commande signé et le projet démarré.

10- N’hésitez pas à demander aux éditeurs de vous faire visiter des banques semblables à la votre et qui ont déjà mis en place leur solution.

11- N’hésitez pas à vous renseigner autour de vous, auprès de vos collègues et concurrents sur les solutions qu’ils utilisent et sur leurs atouts et défauts. Ca sera très utile pour faire le choix final.

12- Et enfin, faites très attention au choix de l’intégrateur, car c’est presque aussi important que la solution.

Maintenant que le choix est fait, il ne vous reste qu’à mettre en place la solution. Et c'est là que les vrais problèmes commencent...

Système de gestion des crédits : la brique la plus importante dans un SI bancaire

Qu’on l’appelle système de gestion des crédits, système de gestion des engagements, qu’on vous parle de front office, middle ou back office, de gestion des garanties de gestion commerciale ou de workflow, alors on parle plus ou moins de la même chose.

Le raisonnement est très simple, si une banque maîtrise sa gestion des crédits, alors là elle peut se faire beaucoup d’argent, et au contraire, si elle n’arrive pas à le faire correctement, ce sera le moyen le plus rapide pour faire faillite.

Certes la banque a d’autres ressources, les investissements ou les commissions pour ne citer que ces deux là. Pour la première cela se joue (au vrai sens du terme) essentiellement sur les marchés financiers alors que pour la deuxième, il faudrait l’oublier avec la concurrence et les réglementations de plus en plus restrictives.

Un système de gestion de crédits n’est pas simplement un système de comptabilisation (débit, crédit)  et de balances des comptes clients, mais cela doit être un vrai système d’informations.

Un système où on devrait parler de CRM (Customer Relationship Management), de workflow, de GED, de front-office, de scoring, de gestion des risques, de suivi des garanties, de système d’aide à la décision…

Un système qui doit être souple et évolutif, afin qu’il puisse s’adapter aux spécificités de chaque banque sans trop de peine ou de charges et qui lui permette d’innover pour devancer sa concurrence et mieux « servir ses clients ». Ce système doit être administré de façon dynamique et doit pouvoir évoluer au fur et à mesure que la banque et son environnement évoluent.

Un bon système de gestion de crédits doit permettre de remonter les alertes pour que la banque puisse agir à temps sur les performances des crédits, des différents produits et mêmes de ses agents. Sans cela la banque risque gros et on pourrait dire qu’elle navigue à vue.

Maintenant que je viens d’exposer quelques unes des principales fonctionnalités qui font qu’un système de gestion de crédits soit moderne et « up-to-date », il s’agit maintenant pour la banque de faire son choix et de trouver LA solution qui lui convienne le mieux!

Question très difficile à laquelle doivent répondre les responsables du crédit et des systèmes d’information dans les banques au moment de faire leur choix !

Entre rallonger leur budget consacré pour l’acquisition de leur module « core banking » acquis à prix d’or auprès de Temenos, FIS, Fiserv ou encore Delta ou autres, acquérir une solution auprès d’un éditeur local, régional ou international ou encore se faire développer la solution sur commande, le choix s’avère difficile.

J’essayerai de développer cela lors d’un prochain post.