Nous vantons souvent les mérites de la pensée intuitive, qui est un outil puissant pour trouver des solutions créatives. Cependant, avoir un marteau ne fait pas de chaque problème un clou. Souvent, le fait de penser de manière créative pour résoudre un problème technique complexe et à fort enjeu peut être carrément dommageable. La pensée structurée (ou convergente) peut organiser un flot d'informations pour révéler des lacunes suspectes dans les données, apportant efficacité et rapidité à l'investigation des problèmes. L'utilisation d'une approche cohérente axée sur les données critiques, associée à une représentation visuelle de cette pensée, améliore considérablement la communication et la collaboration. En plus de faire progresser de manière significative la recherche de la véritable cause première.
Voici un exemple d'information qui a été enregistrée dans un champ typique, de forme libre :
L'application DPM n'est pas disponible du côté DC et HQ, mais 80% ou plus des données n'ont pas été mises à jour pendant 0 à 4 heures dans 1 ou plusieurs DC. IMOD n'a pas été informé de ce problème avant que 4 heures ne se soient écoulées. Il a informé le gestionnaire des incidents pour la distribution.
Voici les mêmes informations en utilisant une approche de pensée structurée :
Lequel est le plus facile à lire et à analyser ? Plus important encore, quel format vous dit ce que nous savons ET ce que nous devons savoir ?
Dans un champ de texte libre, nous avons naturellement tendance à faire l'une des deux choses suivantes : a) nous saisissons autant d'informations que possible pour remplir l'espace vide - que ces informations soient pertinentes ou non - afin de montrer tout le travail qui a été effectué ; b) nous laissons l'espace vide. Ce n'est pas seulement un problème pour une bonne analyse des causes profondes (RCA), mais c'est aussi un problème de communication pour le transfert d'informations, pour l'analyse des tendances et pour relier les problèmes aux incidents et vice versa.
Le format présenté ci-dessus décrit une partie de l'ITIL®-L'approche de Kepner-Tregoe, reconnue par la Commission européenne, est appelée "spécification du problème". L'énoncé du problème (en haut) et les huit rubriques d'informations IS/IS NOT nous permettent de voir, en un coup d'œil, ce que nous savons et ce que nous ne savons pas. Cela stimule la pensée critique, fournit une structure et facilite la communication.
L'importance d'un énoncé de problème de qualité ne peut être sous-estimée (et ce n'est pas la même chose que le titre du cas). Dans le cadre de notre travail avec des organisations d'assistance internationales, nous avons constaté que le fait d'obtenir systématiquement un énoncé du problème correct permet de réduire le temps moyen de résolution de 18% ou plus. Un énoncé de problème de qualité est essentiel pour tout ce qui suit dans le processus RCA.
Considérez ces énoncés de problèmes en italique, de qualité variable :
- Problèmes de serveur - L'objet de cette mesure n'est pas clair et elle peut répondre à plusieurs problèmes.
- Serveur de base de données hors service - C'est une amélioration, mais nous pouvons être plus précis. Quel serveur est en panne ? Et savons-nous déjà pourquoi il est hors service ? Nous voulons continuer à demander pourquoi jusqu'à ce que nous ne sachions plus la réponse.
- Le serveur de base de données d'inventaire n'a plus d'espace de stockage - Cette déclaration précise davantage le problème et nous prépare à une analyse ciblée des causes profondes. L'énoncé est spécifique, il implique un seul objet et un seul défaut, et la cause est inconnue. C'est là que notre analyse du problème peut commencer.
Une remarque sur la documentation :
La documentation n'est l'activité préférée de personne, mais elle est importante. Aucun d'entre nous n'aime passer beaucoup de temps à documenter, mais sans cela, il n'y a pas de connaissances réutilisables pour nos collègues dans l'organisation, pas de piste d'audit et pas d'apprentissage organisationnel. L'important est de se concentrer sur les informations les plus critiques. En ce qui concerne les logiciels de gestion des connaissances, la clé est de modeler l'outil après le processus... et non l'inverse.
Un engagement à penser de manière structurée et claire apporte des résultats de qualité qui favorisent la stabilité informatique critique et produisent de réelles économies de coûts, car nous cessons de résoudre les mêmes problèmes encore et encore et encore.
