CFIA est un processus définis originalement par IBM dans les années 80 pour améliorer la disponibilité des services. Ce processus analyse les configuration hardware/software pour déterminer les impacts réels si un des composants vient à ne plus fonctionner. CFIA fait maintenant parti des bonnes pratiques ITIL et est utilisé pour documenter et étendre la résilience d’infrastructures larges. Principalement l’on pourra retrouver l’utilisation de CFIA dans les processus de “Incident Management“, “Problem Management“, “Change Management“, “Configuration Management“, “Availability Management” et “Capacity Management“.

CFIA permet donc :

• d’identifier les CIs qui peuvent causer une panne.
• de localiser les CIs qui n’ont pas de sauvegardes.
• d’évaluer les risques d’une panne pour tous les CIs.
• de localiser des SPOF.
• de justifier de futurs investissements.
• d’assister à la création et la maintenance de la CMDB.

Pour développer un CFIA, il vous suffit d’utiliser un tableur du type Excel et de suivre les étapes suivantes :

• Sélectionner un “Service IT” et répertorier les CIs (normallement tirer du processus de “Configuration Management“) qui en dépendent.
• Lister les CIs en vertical (un CI par ligne) et placer le “Service IT” en horizontal.
• Pour chacun des CIs placer :

1. un “X” si la panne de ce CI peut causer un arrêt du “Service IT”.
2. un “A” si le CI a une sauvegarde à chaud.
3. un “B” si le CI a une sauvegarde intermédiaire.

• Examiner maintenant tous les “X” et ensuite les “B”, en vous posant les questions suivantes :

1. Est-ce que ce CI est un SPOF ?
2. Quel est l’impact business si le CI vient à avoir une panne ? (Combien d’utilisateurs seront impactés ? Quel serait le coût de cette panne pour le business ?)
3. Quel est la probabilité de panne ?
4. Est-il possible de combler ce SPOF pour minimiser l’impact ?

Vous avez maintenant une matrice CFIA où chaque “X” et “B” sont des CIs à risques. Vous pouvez aussi considérer que les procédures de “recovery” sont des CIs dont le “Service IT” dépend. De rajouter les procédures en tant que CIs d’un service IT, vous permez d’examiner autant l’organisationnel que la partie infrastructure.

• Comment répondons-nous en cas de panne sur un CI ?
• Quels sont les procédures à suivre en cas de panne sur un CI ?
• Est-ce que ces procédures existent au format numérique ou papier ?
• Est-ce que ces procédures peuvent être améliorées ?

1. Est-ce que ces procédures peuvent être améliorées en formant les techniciens ?
2. Est-ce que ces procédures peuvent être améliorées par de nouveaux outils ? (Est-ce que ces procédures peuvent être automatisées ? Est-ce que des maintenances préventives peuvent limiter les pannes ? )

Si un CFIA complet est mis en place, normalement le “Service Desk” devrait voir sa réactivité augmentée pour les processus “Incident Management” et de “Problem Management“.

Un diagramme RACI, ou encore matrice RACI, est utilisé pour décrire les rôles et responsabilités, de différentes équipes et personnes, sur un projet ou sur des processus courants. Il est très pratique pour éclairer les R&R des projets sur lesquelles plusieurs équipes travaillent.

Le diagramme RACI décompose les tâches en quatres type de responsabilités, qui sont alors attribuées à différents rôles. Ces quatres types de responsabilités sont :

• Responsible (Réalisation) : Les R sont ceux qui réalisent l’action. Ces équipes, ou personnes, peuvent être responsable de plusieurs tâches. Si les R ne remplissent pas leurs objectifs, c’est le A qui assume.
• Accountable (Approbation) : Celui qui doit rendre des comptes sur l’avancement d’un projet. Il ne peut y avoir qu’un seul A par tâche.
• Consulted (Consultation) : Ceux qui sont consultés pour la réalisation de la tâche.
• Informed (Information) : Ceux qui sont informés de l’évolution du projet.

Vous pouvez trouver ci-dessous un exemple de diagramme RACI, qui est en fait une matrice en deux dimensions. Afin de créer un diagramme RACI, il faut nommer de façon claire les tâches à effectuer et de façon non générique (afin d’éviter les confusions). Si possible, placer toujours les A et les R le plus à gauche du diagramme RACI. Chaque ligne doit au moins contenir un A et un R, même si ce sont les mêmes personnes. La présence de deux R pour la même tâche signifie une duplication de l’éxécution de celle-ci, il est alors préférable de découper cette tâche en sous tâches.

Un diagramme RACI apporte plusieurs avantages :

• Les rôles et responsabilités sont clairement définis.
• Cette méthode encourage le travail en équipe, réduit l’incertain et éprouve la communication entre les différentes équipes.
• La redondance des tâches est éliminées et cela réduit l’obligation de former des gens au mêmes tâches.
• La productivité est augmentée.