Forum ITIL France

Pour compléter vos remarques qui sont toutes les deux justes, je dirais que ITIL (v3) pénètre le "monde projet" grâce aux domaines de processus Stratégie, Conception et Transition, dont ce dernier a justement  la volonté de réconcilier les "2 mondes" Projets et Opérations. Dans le même temps les référentiels et normes qui traitent de la gestion de projet ne peuvent complètement éluder les opérations.

La fusion des référentiels est à mon avis, sinon le sens de l'histoire, au moins une direction évidente qu'il faut féliciter.

machintruc a écrit:

Je ne pense pas que le méta-référentiels soit une si bonne chose.
On risque de se retrouver confronté au syndrome du téléphone portable multimédia.
Je m'explique, maintenant les téléphones font: téléphone (heureusement), lecteur MP3, appareil photo, caméra, GPS, console de jeux... Ils font tout, mais ne font rien de bien: mauvais lecteurs, mauvais appareils photos, mauvaises consoles etc etc

Je ne dis pas que ce schéma est l'apanacé, mais je trouve que c'est une bonne base de compréhension voir de réflexion car on ne peut maitriser tout ces référentiels.

Je mettrais tout de même un bémol à cette dernière remarque.

Travaillant actuellement à la rédaction d'un standard unifié (projet FUSING(.ppt)), je pense qu'il est tout à fait concevable de prétendre consolider les référentiels actuels au sein d'un méta-référentiel unique.

C'est même une très forte attente de bon nombre de clients et notamment les PME-PMI à qui ce standard s'adresse en particulier.

Certes il ne sera pas totalement évident d'éviter les écueils classiques avec ce genre de projets tels que l'appauvrissement de certaines problématiques spécifiques à chaque corpus; cela étant dit, l'initiative n'y devrait rien perdre ni de sa pertinence, ni de son intérêt premier : permettre l'adoption des meilleures pratiques dans des environnements de petites et moyennes entreprises.

A mon sens, les deux approches ont leur raison d'être et l'une ne peut se substituer à l'autre; le projet de méta-référentiel est une vraie avancée initiée par le marché demandeur de ce type de méthodologie unique et simplifiée; (au sens noble du terme).

chtitil a écrit:

La gestion d'UN projet est effectivement unique en soi et défini dans le temps (enfin quelque fois ;-))
.

Défini dans le temps ne veux pas dire qu'il n'y aura pas de retard, le tout est de savoir rapidement que le projet dérive et de maitriser cette dérive. D'ailleurs, un retard peut être considéré comme un risque mineur voir négligeable contrairement à une dérive budgétaire... par exemple. (je referme la parenthèse)

chtitil a écrit:

La gestion DE projet(s) peut être cadrer  et par conséquent être soumise (ou définie, ou approchée) par un référentiel. L'objectif étant par exemple de former aux bonnes pratiques les chefs de projet et de mesurer les effets du référentiel pour la gestion de CHAQUE projet. Amélioration continue du processus de gestion DE projets ... est alors appropriée.

Je ne suis pas sure de bien comprendre, donc ne m'en veuillez pas si je réponds à coté.

Un projet, ça se pilote et on peut s'appuyer sur des référentiels tels que Pmbok ou ICB par exemple. Mais là on se limite à la gestion de projet, quelque soit le projet.
Ensuite, par exemple pour une entreprise developpant elle même ses outils logiciels, on va vérifier (je reste dans le périmètre gestion de projet) que cette entreprise à une méthodologie dans la gestion de projet, c'est dans CMMI par ex.

C'est dans ce dernier cas que l'on est en amélioration continue, dans une meilleure maitrise de la gestion de projet. Ce sont deux choses bien distinct.
Je crois qu'il en est de même pour ITIL, les spécialistes confirmeront ou non.

D'où, et je reviens à mon schéma, la gestion de projet et la fondation de tous les autres référentiels car pour améliorer ses process (et gagner en niveau de maturité), il faut maitriser la gestion de projet... c'est la base.
Et celle ci ne s'adresse pas simplement aux chefs de projet mais bien à tous ceux qui travaillent en mode projet. Une équipe s'impliquera d'autant mieux dans ce type d'organisation de travail si elle est sensibilisé à ces méthodologies.

Apès on peut s'interroger ou non sur le fait que les référentiels en gestion de projet sont distincts des autres.
Mais ces référentiels peuvent s'appliquer à tout type de projets: IT, production, évenementiel, batiment (secteur à l'origine de ces référentiels d'ailleurs)... donc pourquoi en faire une véru sur un autre référentiel?

chtitil a écrit:

D'autre part, l'image du "téléphone faisant tout moyennement", n'est-il pas une application pragmatique des référentiels (je pense que l' exemple de FIF, application d'un "fusing pour les PME qui n'ont pas les moyens ni l'envie  d'embrasser tous les référentiels est à méditer).

Je suis bien d'accord avec vous, c'est toujours mieux que rien.

Sinon concernant les référentiels, on est pas dans l'obligation de les mettre en place dans leur totalité, tout dépend du périmètre sur lequel on veut agir.
A moins de vouloir atteindre des dégrés de maturité ou de certification X ou Y pour des raisons commerciales ou d'image.

Personnelement c'est de cette manière que j'ai abordé COBIT .
Si on s'attaque au pavé d'un coup, il y a de quoi prendre peur, alors que tout compte fait il n'y rien de bien compliqué dans ce référentiel (c'est pas ce que vous dira un consultant qui en vie, ça c'est sure).
Idem pour MEHARI, si on prend les plus de 700 cas d'emploi, il y a de quoi se pendre.
Mais tout ce qui concerne (pour MEHARI) les attaques terroristes, les risques seveso, les modifications de codes sources logiciels... si on est pas concerné, on zappe des pans entier du référentiel et on se retrouve avec un référentiel buvable et abordable qui entre dans le périmètre défini.

Rien de bien compliqué dans tout ça, un référentiel est tout à fait pragmatique puisque tous ceux cités sont nés de l'empirisme et non de la théorie.

Dernière modification par machintruc (30-04-2009 09:37:50)

Sur le constat, vous avez bien expliqué la problématique que l'on rencontre trop souvent dans les grands groupes.

Et je reviens au management, qui ne doit pas traiter le problème au final mais bien en amont.
Pour que ces démarches fonctionnent, qui plus est lorqu'on en applique plusieurs il faut impérativement:
- Ne pas mettre ses démarches en place sous le joug des responsables métiers (dev/prod).
Le groupe de pilotage doit dépendre de la direction et non de la DSI ou DOSI et ne rendre compte qu'a cette même direction.
Dans ce cas de figure on évite les écueils cités.
Ce ne doit pas être les responsables dev ou prod IT qui décident d'améliorer leur processus mais bien dans le cadre d'un plan de gouvernance SI sponsorisé par la direction.

Mais bon, ça c'est le monde parfait me direz vous... pourtant dans les démarches d'amélioration continue/supply chain/kanban/six sigma ou autre que l'on retrouve en production, c'est de cette manière que les entreprises agissent (pour l'entreprise dans laquelle je me trouve et la précedente) et ça fonctionne.

Pourquoi tout ce qui touche à l'IT est il toujours à la traine?
C'est, à mon avis et j'en reviens toujours à ça, un problème de management, surement dû à un problème de formation trop axée technique.
Le domaine de la production (fabrication) a depuis longtemps intégré ces problématiques, en IT on en est encore à l'age de pierre.

Mais c'est en train de changer, ayant terminé l'an dernier un master suite à une reprise d'étude, j'ai pu voir qu'une partie non négligeable des formations IT tournait autour de l'organisationnel dont la gouvernance, le management, la conduite du changement et la gestion.
Mais de retour dans le monde professionnel, je remarque que les habitudes ont la vie dure et que le prèche (car on en est à ce niveau malheureusement) doit être presque quotidien tout simplement parce que la plupart de l'encadrement à été formé il y a 10 à 20 ans sans réélle formation depuis remettant en cause leurs méthodes de travail.

Dernière modification par machintruc (30-04-2009 12:03:02)