adapter la gestion des risques aux décideurs part. 2

Pour illustrer mon dernier article, voici un exemple concret :

le contexte

Un consortium délivre des services à des organisations gouvernementales traitant des informations classifiées. Parmi les prestations, il y a un support aux utilisateurs (des organisations gouvernementales).

Parmi les problèmes connus du DSI et du RSSI figurent:

1. Le central téléphonique VoIP n’a pas de redondance et subit régulièrement des coupures. Il a été dimensionné uniquement sur le nombre de téléphones et d’appels simultanés et non la criticité du service.
2. Le serveur d’emails du service de support est situé aux Etats-Unis. Les données classifiées traitées ne devraient pas quitter le pays concerné.
3. Les serveurs de monitoring générant les alarmes automatiques ont souvent des pannes dû à leurs limitations d’événements pouvant être traités à la minutes. Tous les événements détectés durant le redémarrage n’auront pas de ticket créé automatiquement, y compris les détections d’intrusions sur des sites inoccupés.

Ces problèmes ont été remontés plusieurs fois aux dirigeants mais aucun budget n’a été accordé pour résoudre les problèmes. Au détour d’une conversation avec le DSI et RSSI sur « pourquoi les dirigeants ne comprenait pas l’informatique », ils m’ont demandé si je pensais pouvoir les aider.

ce qui a été fait

Une évaluation des risques basées sur les 3 processus métiers les plus importants, parmi lesquels le traitement d’incident. Le délivrable final était un Top 5 des risques les plus importants.

Pourquoi seulement trois processus et un top 5 et non pas tous les risques priorisés ? Deux raisons : la première pas de budget et pas de certitude que l’on pourrait résoudre les problèmes après l’évaluation des risques. La deuxième basé sur le bon sens. Il ne faut pas attendre d’avoir tous les risques identifiés pour commencer à prioriser et agir pour réduire les risques. On réduit les plus gros, sur les processus métier les plus importants d’abord, puis on fait une deuxième évaluation de risques, puis une troisième et on recommence avec les premiers et ainsi de suite. L’évaluation des risques doit être un processus continu ayant un cycle court pour être efficace.

Les trois risques cités ci-dessus sont ressortis lors de l’évaluation. Et pour chacun, un budget a été attribué pour y remédier.

pourquoi cette fois et pas les autres ?

Qu’est-ce qui a fait changer d’avis les décideurs ?

pour le risque 1

La perception des dirigeants était que l’infrastructure n’était pas fiable. C’est à l’informatique de s’en occuper ou au fournisseur et qu’il y avait un contrat de support avec le fournisseur pour cela. Qu’il fasse son boulot !

Lorsqu’on leur a expliqué que la première étape du processus métier ne fonctionnait pas comme attendu et que c’était visible de chez le client, les décideurs ont immédiatement compris qu’il s’agissait d’un problème métier, créé par un dirigeant « métier » qui avait refusé l’offre technique de redondance, ne la comprenant pas.

pour le risque 2

Les dirigeants ne comprenaient pas en quoi un service externalisé fonctionnant bien (les emails peuvent être reçus et envoyés normalement) devrait être internalisé. D’autant plus que les investissement en terme de machines et de licences n’étaient pas négligeables. Il était même soupçonné que l’informatique cherchait à se créer du travail par peur de perdre des postes.

Lorsqu’on a remis les choses dans leur contexte, avec des exemples de contenu d’emails, c’est devenu une priorité absolue.

pour le risque 3

Les dirigeants ne comprenait pas où était le problème puisque les événements eux-mêmes n’étaient pas perdus, seul le ticket automatique n’était pas créé selon la sévérité de l’événement. Les agents de support peuvent bien créé de temps à autre des tickets « à la main » ! Il le font déjà quand l’utilisateur appelle par téléphone, alors ?

Lorsqu’on a expliqué que si le ticket n’était pas créé, les agents ne pouvaient pas détecter l’événement car ils étaient noyé sous le nombre d’événements (plus de 10 000 en 1 minutes) et ils sont 8 au maximum. Ainsi, des graves incidents pouvaient ne pas être traités. Dans ce contexte, le budget alloué a permis d’adresser la cause du problème générant autant d’événements à la minute ainsi que le développement d’un petit script permettant d’identifier les événements clés en cas de plantage du serveur. Comme on a changé la demande de budget en charge unique et non pas récurrente, le CFO était beaucoup plus enclin à accepter.

conclusion

On a transformé la perception des risques techniques en risques métiers, et cela a tout changé. À aucun moment, une conséquence financière n’a été articulée ou communiquée aux dirigeants. Ils ont compris d’eux-mêmes les conséquences financières potentielles et fait le calcul de l’investissement proposé.

Johny

crédit photo : © alphaspirit - Fotolia.com