Parmi les 2 500 et quelques billets publiés sur « C'est pas mon idée ! », il en est un qui a connu une histoire particulière : mes premières réactions au lancement de Hello Bank! ont été les seules à recueillir plusieurs commentaires de clients, plutôt négatifs. Un bout de voile s'est récemment levé sur les possibles raisons des difficultés observées.
Une des plaintes les plus fréquemment entendues à l'encontre de la banque mobile de BNP Paribas concerne les délais d'ouverture de compte. J'ai voulu croire, au début, il y a presque 4 ans, qu'il s'agissait de défauts de jeunesse cumulés à un engorgement face à un flot de demandes inattendu. Malheureusement, les mêmes échos me parviennent toujours aux oreilles aujourd'hui, les attentes de 3 ou 4 semaines sans nouvelles de l'avancement d'un dossier restant apparemment monnaie courante (également confirmées par un nombre conséquent de messages sur le forum dédié).
Or, une étude de cas publiée par la société Contextor laisse entendre que des mesures ont été prises afin de pallier à ces déficiences. Le spécialiste de la « Robotic Process Automation » (RPA pour les intimes) explique en effet avoir déployé sa solution sur le processus de création de compte, qui aurait permis de réduire le temps moyen de traitement de 80%. Toutefois, comme il est question par ailleurs de 5 minutes au lieu de 25, cette évolution n'aidera pas les malchanceux qui patientent plusieurs jours.
Les détails de l'initiative apportent pourtant des informations intéressantes sur le fonctionnement (et les limitations) de Hello Bank! Ainsi, Contextor automatise les interactions avec 17 traitements de données (saisie, enregistrement, acquisition de documents, contrôles…), gérés par 12 applications hétéroclites, qui étaient jusqu'alors pris en charge par des opérateurs humains ! Voilà la réalité profonde d'une nouvelle application mobile bâtie sur des fondations historiques, oubliées de la modernisation.
On est bien loin de l'image rêvée (et encore largement véhiculée par les médias) d'une « néo-banque » moderne, robuste et efficace. Or, ce n'est pas l'ajout d'une couche de robotisation – qui, rappelons-le, se contente de reproduire les actions d'un humain sur son poste de travail – qui va permettre de corriger le tir. Certes, une partie des traitements vont être accélérés et les opérateurs vont disposer de plus de temps pour des tâches plus importantes. Hélas, l'initiative représente aussi un sérieux danger latent.
Le concept de RPA qui semble soudain (re-)devenu à la mode dans les institutions financières est un avatar d'une longue lignée de technologies destinées à redonner une nouvelle jeunesse à des systèmes informatiques anciens. Qui se souvient des solutions de « revamping » puis de « servicisation » des vieux écrans à caractères verts ? Ces précédents nous enseignent que ce genre d'approche entraîne presque irrémédiablement un risque de paralysie progressive insidieuse, reposant sur des illusions.
D'abord, en s'attaquant à la surface des problèmes – à savoir l'interface utilisateur, au niveau du poste de travail –, ces outils évitent trop facilement aux entreprises de s'interroger sur l'obsolescence de leurs processus et systèmes existants. D'autre part, les succès initiaux conduisent souvent à une propagation de leur usage, qui va, petit à petit, handicaper toute velléité de modernisation : si des composants sont modifiés ou si les processus doivent évoluer, l'impact sur les robots deviendra un point de blocage, par son coût direct et par la menace qu'il fait peser sur les investissements.
Qu'on ne s'y trompe pas : les RPA apportent (peut-être ?) une réponse tactique à des problèmes ponctuels. Mais il faut être parfaitement conscient que, par exemple, ils ne lèveront jamais les contraintes internes engendrées par l'étanchéité des silos applicatifs. Alors, pour éviter de tomber dans le piège de la paralysie, ils ne devraient être envisagés, dès l'origine, que comme des solutions temporaires, APRÈS la définition et le lancement d'un vrai projet de transformation et en attendant son aboutissement.
Une des plaintes les plus fréquemment entendues à l'encontre de la banque mobile de BNP Paribas concerne les délais d'ouverture de compte. J'ai voulu croire, au début, il y a presque 4 ans, qu'il s'agissait de défauts de jeunesse cumulés à un engorgement face à un flot de demandes inattendu. Malheureusement, les mêmes échos me parviennent toujours aux oreilles aujourd'hui, les attentes de 3 ou 4 semaines sans nouvelles de l'avancement d'un dossier restant apparemment monnaie courante (également confirmées par un nombre conséquent de messages sur le forum dédié).
Or, une étude de cas publiée par la société Contextor laisse entendre que des mesures ont été prises afin de pallier à ces déficiences. Le spécialiste de la « Robotic Process Automation » (RPA pour les intimes) explique en effet avoir déployé sa solution sur le processus de création de compte, qui aurait permis de réduire le temps moyen de traitement de 80%. Toutefois, comme il est question par ailleurs de 5 minutes au lieu de 25, cette évolution n'aidera pas les malchanceux qui patientent plusieurs jours.
Les détails de l'initiative apportent pourtant des informations intéressantes sur le fonctionnement (et les limitations) de Hello Bank! Ainsi, Contextor automatise les interactions avec 17 traitements de données (saisie, enregistrement, acquisition de documents, contrôles…), gérés par 12 applications hétéroclites, qui étaient jusqu'alors pris en charge par des opérateurs humains ! Voilà la réalité profonde d'une nouvelle application mobile bâtie sur des fondations historiques, oubliées de la modernisation.
On est bien loin de l'image rêvée (et encore largement véhiculée par les médias) d'une « néo-banque » moderne, robuste et efficace. Or, ce n'est pas l'ajout d'une couche de robotisation – qui, rappelons-le, se contente de reproduire les actions d'un humain sur son poste de travail – qui va permettre de corriger le tir. Certes, une partie des traitements vont être accélérés et les opérateurs vont disposer de plus de temps pour des tâches plus importantes. Hélas, l'initiative représente aussi un sérieux danger latent.
Le concept de RPA qui semble soudain (re-)devenu à la mode dans les institutions financières est un avatar d'une longue lignée de technologies destinées à redonner une nouvelle jeunesse à des systèmes informatiques anciens. Qui se souvient des solutions de « revamping » puis de « servicisation » des vieux écrans à caractères verts ? Ces précédents nous enseignent que ce genre d'approche entraîne presque irrémédiablement un risque de paralysie progressive insidieuse, reposant sur des illusions.
D'abord, en s'attaquant à la surface des problèmes – à savoir l'interface utilisateur, au niveau du poste de travail –, ces outils évitent trop facilement aux entreprises de s'interroger sur l'obsolescence de leurs processus et systèmes existants. D'autre part, les succès initiaux conduisent souvent à une propagation de leur usage, qui va, petit à petit, handicaper toute velléité de modernisation : si des composants sont modifiés ou si les processus doivent évoluer, l'impact sur les robots deviendra un point de blocage, par son coût direct et par la menace qu'il fait peser sur les investissements.
Qu'on ne s'y trompe pas : les RPA apportent (peut-être ?) une réponse tactique à des problèmes ponctuels. Mais il faut être parfaitement conscient que, par exemple, ils ne lèveront jamais les contraintes internes engendrées par l'étanchéité des silos applicatifs. Alors, pour éviter de tomber dans le piège de la paralysie, ils ne devraient être envisagés, dès l'origine, que comme des solutions temporaires, APRÈS la définition et le lancement d'un vrai projet de transformation et en attendant son aboutissement.
 |
| Simone Giertz – YouTube |
Robot du pauvre, l'expression est magnifique et tout à fait justifiée. De fait, BNP Paribas est toujours dans la position "Vitrine" afin de paraitre jeune (djeuns ?), moderne, innovante, férue des nouvelles technologies... mais en arrière-salle, tant son organisation que ses systèmes d'information sont ante-diluviens et l'on s'aperçoit que les chabots, la mobilité, les smartphones, l'XML ne sont pas compatibles avec l'assembleur !
RépondreSupprimerBonjour Philippe, il est clair que BNPP est favorable à l'innovation (comme l'ensemble des acteurs bancaires) mais n'oublions pas que ce secteur a des cycles de développement différents en fonction de la criticité des systèmes. Comme vous le savez sûrement, les sytèmes "Legacy" des banques n'ont pas la même souplesse que les dernières tendances d'innovation à savoir la mobilité, chatbot, ou plus généralement toute forme d'interaction Homme machine.
SupprimerCependant, Je ne suis pas d'accord avec votre dernière phrase (prenons la au sens large de l'intégration des jeunes technologies avec les moins jeunes). La modernisation digitale s'accélère aussi dans les coeurs des systèmes bancaires pour la simple et bonne raison que le marché, les lois poussent à ouvrir plus facilement ces systèmes (j'ai à l'esprit à PSD2).
Donc oui, ce décallage innovatif peut, parfois, paraître frustrant pour les clients mais cela est justifié par la prudence des banques des menaces qui rôdent.
Enfin, je peux vous assurer que toute innovation technologique peut facilement se greffer à des coeurs bancaires. Tout est question d'architecture, d'agilité et de priorité :). J'ai moi même travailler sur les stratégies mobiles, PSD2, des chatbots et les paiements instantanés dans le contexte bancaire. Tout fini par appelé de l'assembleur ou du COBOL à un moment donné ... sans toucher le coeur bancaire :)
Merci Alexis de cet éclairage ! Je vous rejoins sur les cycles de développement en m'appuyant sur l'affirmation d'un banquier "N'oubliez pas que nous n'avons que deux vitesses : parking et lent"... ce que vous confirmez.
RépondreSupprimerOk sur la prudence des banques qui confine le plus souvent à l'immobilisme ou à un conservatisme selon l'antienne pourquoi changer quelque chose qui, après tout, fonctionne depuis des lustres ?
Votre fervent discours en défense de l'assembleur et du Cobol est juvénile