déjà ITIL n'est pas une méthode — c'est un recueil de bonnes pratiques — rien que le nom donne un indice : Information Technology Infrastructure Library
Effectivement, tous ceux qui ont calé leur organisation sur le découpage proposé par ITIL — qui ne présage à la base pas de l'organisation — ont rencontré des problèmes. Un point à retenir : c'est la pratique qui s'adapte à l'organisation, pas le contraire.
Exemple typique : pas forcément besoin de 3 intervenants... simplement, le même intervenant mais n'ayant pas les mêmes activités lorsqu'il intervient sur un incident (qui ne requière que peu d'analyse a priori, celui qui ouvre, traite et ferme le ticket peut être la même personne) ou sur un problème (qui mobilise un ensemble d'incidents, et là peut requérir un peu plus de lourdeur et de coordination inter-équipes à la marge, cas que l'on souhaite éviter : délais, coûts qui seraient à imputer à un projet et à la maintenance d'une application).
À ce titre, les déclinaisons d'ITIL que j'ai pu rencontrer sont au mieux bancales (la classique erreur d'équipes distinctes « Changement / Incident+Problème ») ou catastrophiques comme tu l'indiques en terme de lourdeur administrative lorsque le principe de subsidiarité n'est pas respecté : son pendant étant de n'impliquer que les personnes concernées et de ne pas rajouter de lourdeur inutile.
Comme toujours, si l'outil est la solution, c'est le début des problèmes :D
[^] # Re: ITIL
Posté par BAud (site web personnel) . En réponse au journal Et l’intelligence humaine, alors ?. Évalué à 7.
déjà ITIL n'est pas une méthode — c'est un recueil de bonnes pratiques — rien que le nom donne un indice : Information Technology Infrastructure Library
Effectivement, tous ceux qui ont calé leur organisation sur le découpage proposé par ITIL — qui ne présage à la base pas de l'organisation — ont rencontré des problèmes. Un point à retenir : c'est la pratique qui s'adapte à l'organisation, pas le contraire.
Exemple typique : pas forcément besoin de 3 intervenants... simplement, le même intervenant mais n'ayant pas les mêmes activités lorsqu'il intervient sur un incident (qui ne requière que peu d'analyse a priori, celui qui ouvre, traite et ferme le ticket peut être la même personne) ou sur un problème (qui mobilise un ensemble d'incidents, et là peut requérir un peu plus de lourdeur et de coordination inter-équipes à la marge, cas que l'on souhaite éviter : délais, coûts qui seraient à imputer à un projet et à la maintenance d'une application).
À ce titre, les déclinaisons d'ITIL que j'ai pu rencontrer sont au mieux bancales (la classique erreur d'équipes distinctes « Changement / Incident+Problème ») ou catastrophiques comme tu l'indiques en terme de lourdeur administrative lorsque le principe de subsidiarité n'est pas respecté : son pendant étant de n'impliquer que les personnes concernées et de ne pas rajouter de lourdeur inutile.
Comme toujours, si l'outil est la solution, c'est le début des problèmes :D