De l'utilité d'avoir une bonne approche de la garantie ou "Pourquoi le métier passe-t-il son temps à critiquer l'IT ?"

De l'utilité d'avoir une bonne approche de la garantie

ou

Pourquoi le métier passe-t-il son temps à critiquer ce que l'IT met a sa disposition ?

Il a toujours existé un décalage entre le métier (le business) et l’informatique. Il y a des années, l’IT était toute puissante (le CIGREF la définit comme une informatique « cathédrale », ce qui me semble assez juste). Mais à l’heure actuelle l’IT doit savoir s’adapter aux besoins du métier. Hélas, on assiste assez souvent à deux approches :

• soit l’IT fournit des services informatiques qui sont performants, mais peu fiables
• soit l’IT fournit des services informatiques qui ne sont pas adaptés aux besoins du métier, mais qui sont d’une robustesse à toute épreuve

L’écart entre ce que voudrait le client et ce qu’apporte l’IT peut être abordé de multiples manières et ITIL offre de nombreuses pistes sur le sujet. Une de mes favorites est l’approche basée sur l’utilité et la garantie du service informatique.

Pour ITIL, un service informatique doit être défini sur deux axes :

• l’utilité (ce que fait le service, ses fonctionnalités)
• la garantit (la manière dont le service est réalisé, son approche technique)

Il n’est pas toujours facile de comprendre la différence entre les deux, je vais donc vous expliquer l’approche que j’utilise dans mes cours.

Imaginez une banque agissant en milieu rural. Cette banque possède des commerciaux qui parcourent (joyeusement) la campagne à la recherche de clients voulant bien accepter une offre de prêt. Lorsque le client signe l’offre, démarre alors un processus :

• Le commercial passe à son agence pour déposer la liasse de demandes de prêts (une fois par semaine, le vendredi)
• La liasse de demandes de prêts passe par un circuit d’approbation qui dure deux jours
• Une fois la demande approuvée, l’argent est transféré sur le compte du client ce qui prend aussi deux jours.

L’application de ce processus va provoquer de nombreux délais, ainsi si un client signe son prêt le lundi matin il n’a l’argent sur son compte que deux semaines plus tard, le vendredi matin !

Comment pouvons-nous améliorer tout ceci ? Déjà en utilisant l’approche de l’utilité : quelles sont les contraintes actuellement présentes et comment les supprimer ? Nous en avons identifié trois majeures :

• Le fait de devoir déposer les liasses de demandes à l’agence,
• Le fait de devoir passer par un circuit d’approbation qui dure deux jours,
• Le fait de devoir attendre le virement d’argent qui dure aussi deux jours.

Attaquons-nous aux deux premières :

• Mettons en place une solution qui va éviter au commercial de rentrer à l’agence pour commencer le traitement de la demande. Ainsi les données peuvent être transmises en temps réel vers l’agence et les documents papier seront déposés le vendredi à des fins d’archive et de contrôle. Rien qu’avec cela nous arrivons à gagner jusqu’à 5 jours !
• Automatisons le circuit d’approbation. Après examen des règles d’approbation, il s’avère que lorsqu’un client n’a pas été en négatif depuis deux ans et que la demande de prêt est inférieure à 11000 euros, alors il est systématiquement accordé. Codons ceci sous la forme d’une matrice électronique d’approbation. Il devient alors possible d’avoir la réponse à la demande de prêt de manière instantanée !!!

Avec ces deux approches, je réduis drastiquement le temps de traitement, car il ne me reste plus que le transfert d’argent. Donc, si un client signe le lundi matin, il obtient l’argent sur son compte le mercredi matin ! Je suis passé de deux semaines à deux jours de traitement ! 

Cependant, ce gain réalisé grâce à l’utilité n’est rien sans avoir une bonne garantie. Cette dernière s’exprime dans quatre domaines :

• La disponibilité
• La continuité
• La capacité
• La sécurité

Nous allons donc maintenant voir comment la solution que nous mettons en oeuvre va répondre et satisfaire aux exigences de chacun de ces domaines.

• La disponibilité : le principal problème de disponibilité que nous allons rencontrer va être lié à la couverture réseau. Pour faire transiter nos données de la solution mobile du commercial vers les serveurs de la banque, nous devons passer par le réseau 3G. Or, vous le savez peut-être, en milieu rural le réseau 3G s’appelle EDGE voir GPRS… Ma solution va donc devoir être conçue pour ne transiter que peu de données, sans doute par l’utilisation de matrices de correspondances utilisées à la fois sur le serveur et sur le terminal du commercial. Mais que se passe-t-il si la solution se retrouve hors réseau ? Avant toute chose, il faut que le client puisse avoir la réponse à sa demande de prêt, donc la matrice d’approbation devra être codée en dur dans l’outil. Ensuite, il faut que le terminal du commercial soit capable de se connecter de lui-même pour transférer les données une fois en zone de couverture, du coup nous allons sans doute nous orienter vers une solution à base de tablette.
• La continuité : que se passe-t-il si jamais la tablette du commercial est volée ou détruite ? Nous allons mettre 2 tablettes en spare dans chaque agence, le commercial n’a plus qu’à rentrer à l’agence et à prendre une nouvelle tablette. En se connectant, il va pouvoir récupérer ses données (notre solution doit donc se synchroniser en permanence).
• La capacité : notre plus gros souci de capacité va être lié à la batterie et à l’autonomie de la tablette. Ca tombe bien : les tablettes ont une très forte autonomie et peuvent être rechargées sur la prise allume-cigare de la voiture, voici donc un autre aspect résolu.
• La sécurité : les données de la tablette seront cryptées et nous allons former les utilisateurs à la sécurité en leur expliquant que, lorsqu’ils vont boire l’apéro ils ne laissent pas la tablette sur le siège passager de la voiture.

C’est donc l’association de l’utilité et de la garantie qui vont nous permettre d’avoir des services informatiques qui seront à la fois fiables et adaptés aux besoins de nos clients.