Bonjour Yves,


A ma connaissance, le terme anomalie (fault) est généralement employé pour décrire : "une condition qui empêche une unité fonctionnelle d'exécuter la fonction requise."

Les analyses par arbre de panne (Fault Tree Analysis) permettent d'ailleurs d'évaluer l'impact de l'anomalie d'un équipement sur la disponibilité du service, et de mettre en exergue les points uniques de défaillances (Single Point of Failure) dans l'infrastructure.

Des solutions de redondance ou de haute disponibilité pourront être mises en oeuvre selon les besoins.

Cdlt,

Bonjour,

Mon souci est, comme souvent, lié à l’historique de la situation.
Dans mon contexte, les « incidents » ont été mis en place après les « anomalies ». Les « anomalies » servent aux équipes applicatives à suivre les dysfonctionnements aussi bien de développement, recette, intégration que production.
Ainsi, aujourd’hui lorsqu’un dysfonctionnement est lié à une application, c’est souvent une anomalie qui est enregistrée.

Vos réponses me confortent sur mes positions. En environnement de production tous dysfonctionnement est un incident.
Par contre, pour les autres environnements, ITIL donne peu de clés sur le suivi des dysfonctionnements applicatifs. C’est souvent CMMi qui fourni des préconisions, et donc le suivi se fait au travers d’anomalies. Êtes-vous d’accord avec ça ?

Donc je me retrouve aujourd’hui avec des développeurs qui ne jurent que par des anomalies, quelque soit l’environnement, et des équipes SD & exploitations qui doivent jongler entre incident et anomalie.

Bonjour,

Et si l'incident était le constat et l'anomalie le diagnostique ?

Ce qui pose la question : avec quel philisophie construire un arbre de diag dans un outil de help desk ?

Est-ce que cette arbre de diag va aider mon N1 à trouver la bonne procédure de résolution en fonction des indications de son interlocuteur (l'utilisteur) ? (par le constat, construction de l'arbre par le métier en principal) ?
Est-ce que mon N1  écoutera son interlocuteur, fera un pré diagnostique et catégorisera son incident dans la bonne case ? (par le diagnostique, construction de l'arbre par le technique et le fonctionnel en principaux) ?

Question subsidiare : quel est le profil de N1 que je dois embaucher ?

Evidemment, je pense qu'il y a pas de bonne réponse ... ;-))

A +

chtitil a écrit:

Ce qui pose la question : avec quel philisophie construire un arbre de diag dans un outil de help desk ?

De mon point de vue, l'arbre de diag dépend souvent de la stratégie que le SD souhaite mette en œuvre. S'il doit aider le N1 l'investissement amont est souvent plus important que s'il s'alimente au fur et à mesure.
L'orientation métier permet en général d'être plus efficace dans la compréhension du client mais réclame une meilleure traduction de la part du Desk, donc plus d’investissement.

chtitil a écrit:

Question subsidiare : quel est le profil de N1 que je dois embaucher ?

Pour ma part, de ce que j'ai vu ou du définir, le choix s'est vite fait en fonction de stratégie de l'entreprise :
- le SD doit être un centre de service pour réduire les durées d'incident et donc augmenté la productivité de l'entreprise
- le SD est un centre de cout et c'est aux utilisateurs de contacter le SD en cas de réel incident.
Sur la première approche, les N1 doivent avoir une bonne connaissance général, une bonne flexibilité d'esprit, comprendre le métier et les criticités de l'entreprise. Bref, des généralistes de bon niveau
Pour la seconde approche, les N1 sont sollicités sur des périmètres définis selon des cas prévus. Donc, un profil moins "chère"

chtitil a écrit:

Evidemment, je pense qu'il y a pas de bonne réponse ... ;-))

Bref, comme souvent le $$$ aide dans les choix.

robby a écrit:

je dirais que l'anomalie est le coeur de la préocupation d'une explotiation car:
- elle peut provoquer des incidents (c.a.d interrompre ou dégrader un service utilisateur)
- elle peut faire l'objet d'un projet d'éradication via la gestion des problèmes.

Bonjour,

Comment qualifiez vous une anomalie ?
Pour ma part, je retourve en général ce terme utilisé pour désigner un "bug" applicatif. Auusi bien avant mise en production qu'après.
En est-il de même pour vous ?

Puisque vous associez le terme d'anomalie aux équipes applicatives (les « anomalies » servent aux équipes applicatives à suivre les dysfonctionnements), vous évoquez donc la gestion qui consiste à diagnostiquer la cause de l'anomalie, puis à déterminer une ou plusieurs solutions d'éradication, et pourquoi pas une solution de contournement en attendant l'éradication, puis à la mise en place de la solution d'éradication.
- Une telle gestion côté exploitation s'appelle la gestion des problèmes.
- Une telle gestion côté développement s'appelle la gestion des anomalies / bug.

2 équipes, 2 gestions:
- La gestion des problèmes permet à l'exploit de suivre le planning de l'éradication (et donc de relancer les équipes de développement)
- La gestion des bugs permet aux études de tracer et de prioriser le traitement des bugs.

En tout cas, le rythme de traitement d'une anomalie est de l'ordre de qqs jours à qqs mois.

jp a écrit:

En synthèse: une anomalie c'est le terme habituellement utilisé dans le monde du développement pour désigner un problème (au sens ITIL).

Merci.
C'est également ma vision, mais je préferais m'assurer de la partager.

A mon avis, pour éviter toute incompréhension, dans tous les cas, il faut oublier le mot anomalie qui ne fait pas partie du vocabulaire ITIL et de façon générale, ne pas essayer de donner des synonymes aux mots du vocabulaire ITIL, car selon le contexte, l'entreprise, la culture des personnes, on va au devant de certains ennuis...
Rque : il existe le mot Erreur qui correspond assez bien à la définition que vous donnez de Anomalie

J'abonde dans le sens de ceux qui indiquent qu'un incident ne concerne pas la phase de conception du service (étude, développement, test, recette...)
Mais attention, de façon générale un incident concerne le Service (au sens prestation) fourni aux utilisateurs/clients
Si le service est de fournir un environnement aux équipes de développement... on ne peut plus affirmer ce qui a été dit plus haut : "un incident est propre à un environnement de production" car dans cet exemple, l'environnement de test est un environnement de production de service...
je m'en tiens donc personnellement à la définition qui parle de "service" et non pas de "production"

Bonjour,

Je suis assez d'accord avec la notion de service plutôt que de production, sauf que dans 90 % des cas il s'agit bien de la production et reconnue et appelée comme telle dans l'entreprise.

Ce qui m'amène à dire que si dans le vocabulaire d'une entreprise on parle d'anomalie ou de bug ou que sais-je au lieu d'erreur, j'utiliserais anomalie ou bug. Au nom de quoi, et surtout pas au nom de pratiques se voulant résolument tournées "clients" j'irai imposer mon vocabulaire en expliquant qu'il est le mieux adapté ?  ITIL serait un peu trop écrêteur des cultures ?
Est-ce un effet obligatoire de la mondialisation ? Sommes nous devenus dogmatiques ?  Faut-il casser l'oeuf par le petit ou le gros bout ?  ;-))

Bonjour,

Peter Gerritsen a écrit:

eviter d'utiliser/creer des acronyms Français pour les termes ITIL, donc ne pas utiliser CCC mais de preference CAB et non plus parler de MEP, GDP etc. Cela n'aide pas vraiment à rendre le choses clair et en plus la langue Française est deja "gavé" des sigles et acronyms... donc pourquoi en ajouter encore?

D'accord sur le fond, il est vrai qu'il serait plus simple que nous (informaticiens) parlions tous la même langue.

Maintenant chaque entreprise à sa culture et son histoire. Ce présenter un matin et expliquer à une DSI que d'une part les méthodes sont à améliorer et que d'autre part il n'y a plus de CCC ou d'anomalie mais des CAB et des Erreurs/incidents/problèmes est "un peu" délicat.
J'exagère mais, peut-être plus en France qu'ailleurs, l'esprit contestataire et rétif aux changements est assez marqué.

Personnellement, je me focalise sur les termes marquant d'ITIL : Incident-Problème-Changement-CMDB. Si l'entreprise souhaite franciser chaque mot c’est en générale pour mieux s’approprier la méthode et maintenir son identité.
Certaines entreprises souhaitent que l’informatique suive les règles communes à l’entreprise, la terminologie française en fait partie.
Ainsi, je consomme beaucoup d’énergie pour mettre en place un CAB et non un CCC.

Pour ma part, je suis d’accord avec ch’titil. ITIL nous donne les bonnes pratiques, avec bien sûr tout un corollaire de termes. A nous (informaticiens sensibles à ITIL) de faire appliquer les bonnes pratiques et de simplifier/unifier/clarifier les terminologies de l’entreprise par rapport à ces bonnes pratiques. Que ce soit des termes ITIL ou des termes propres à l’entreprise.

Je prend un carte de menbre du CCCCC également