Nouvelle mission chez EDF
Missions et références
Depuis juin 2012 : Architecture technique SAP chez EDF :
- Etude de fusion des 8 instances SAP FI/CO pour la comptabilité EDF
- Etude d’un parcours de migration vers une solution de Cloud Computing pour SAP
- Rédaction de DATs (Document d'Architecture Technique) décrivant l'interface entre les besoins métier, les exigences de disponibilité/sécurité/confidentialité, les fonctionnalités du progiciel et les contraintes de production de l'infogérant
- Migration de 90 instances SAP : ECC6, BW, Sap Content Server, SAP PI, SAP GRC, Solution Manager : Interface entre la MOA EDF, la DSI EDF et l'infogérant
De février à mai 2012 : Groupe Casino à Saint-Etienne avec les objectifs suivants :
- Rationaliser et améliorer les procédures de copie/refresh d'instances SAP
- Gérer le projet de migration OS/DB de Windows/SQL Server vers Aix/DB2 de l'instance SAP orienté FI/CO
- Mener des campagnes de mesure et d'amélioration de performances SAP
- Qualifier et spécifier la mise en œuvre du monitoring des Business Processes avec Solution Manager
- S'intégrer à l'équipe de support N3 et y apporter son expertise
Décembre2011-Janvier 2012 : OTAN CEPMA (Central Europe Pipeline Management Agency)
Mise en oeuvre d'un PRA pour la production Oracle/SAP
Réalisation technique :
- Reprise de l’instance de production sur un serveur de secours
- Import ZFS des volumes répliqués au niveau de la baie de disques Compellent
- Paramétrage Oracle et SAP
- Recette technique et fonctionnelle
De janvier à septembre 2011 : Tereos (Industrie du sucre et des céréales)
Définition de l'architecture technique permettant d'exécuter les nouveaux environnements de production
- SAP ECC6 et Business Objects BI 4.0 : 40 000 SAPs
- Autres environnements SAP : GRC, APO, TDMS
- CI/DB Serveurs Sun M9000 + SAN HDS AMS2500
Gestion du projet de déploiement
- Rédaction du Plan Qualité de Projet
- Rédaction et suivi de planning
- Coordination des intervenants
« Faire ce qu’on dit et dire ce qu’on fait », c’est une règle de base pour la gestion de projet dans le domaine de la communication. . Ce qui est vrai pour un texte, d’après Jean Guitton « Le secret de tout art d'exprimer consiste à dire la même chose trois fois: on dit qu'on va la dire, on la dit, on dit qu'on l'a dite » est vrai aussi pour une tâche d’un projet : « On dit qu’on va la faire, on la fait, on dit qu’on l’a faite ». Est-ce que ça suffit à résumer la communication au sein d’un projet ? Évidemment non. Ça répond juste au besoin de cohérence entre les faits et ce que l’on en rapporte. Mais ça ne répond pas suffisamment au QQOQCCP :
- Qui communique et à qui ?
- Quoi : doit ou peut être communiqué aux autres acteurs du projet ?
- Où déposer l’information ? Où est-elle ?
- Quand : à quelle fréquence ?
- Comment : Par écrit, par oral, lors d’une réunion ?
- Combien : Quel est le niveau de détail requis ?
- Pourquoi : Quel type d’événements mérite une communication spécifique ?
Le plan de communication d’un projet ne peut pas, ne doit pas, chercher à couvrir tous les cas de figure. Il peut poser un certain nombre de règles, par exemple celles-ci que l’on peut trouver sur http://www.gestiondeprojet.net/articles/plan_communication.html
- « Les méthodes utilisées pour collecter et conserver différents types d’informations. Les procédures doivent également préciser les modalités de collecte et de diffusion des mises à jour et des corrections apportées à des documents précédemment diffusés.
- Les destinataires de l’information en fonction de la nature des informations (rapports d’avancement, données, calendrier, documentation technique...), les méthodes utilisées pour diffuser les divers types d’information et les diffuseurs de ces informations.
- Une description de l’information à diffuser : le format, le contenu, le degré de détail, les conventions et définitions à utiliser.
- Les calendriers d’émission qui précisent à quel moment chaque type d’information est émis
- Les méthodes pour accéder à l’information entre deux communications prévues
- Une méthode de mise à jour et de redéfinition du plan de communication au cours du projet »
Il est d’ailleurs rare qu’un plan de communication puisse atteindre ce degré de précision, et surtout être appliqué à ce même niveau. À ce plan de communication formelle, il faut rajouter des techniques, plus informelles, et qui relèvent plus de la conversation que de la communication :
- L’organisation en plateau projet où l’ensemble des acteurs partagent un même espace propice aux échanges de tous ordres
- La machine à café, les pots, les événements festifs,
- Les réunions, qui mélangent les genres entre communication formalisée et discussion libre, voire confrontation et affrontement
Mais de quel moyen le chef de projet dispose-t-il pour s’assurer que son plan de communication est respecté, et surtout s’il est efficace ?
La technique traditionnelle de gestion de projet repose sur la décomposition en tâches que l’on va planifier dans un logiciel de type MS Project. Le chef de projet est alors trop souvent perçu comme un planificateur. Sin principal rôle sera de s’assurer que les délais sont respectés, optimiser les durées, essayer de paralléliser au maximum ce qui peut l’être. Implicitement, cette vision repose sur l’idée que l’on a tout prévu au départ, que les objectifs ont été fixés et qu’il n’y a plus qu’à suivre le plan. C’est une vision centralisée avec le risque de mauvaise qualité des produits, et de maquillage des résultats. Comme tout est censé avoir été prévu au départ, les acteurs du projet se retrouvent dans une position où ils n’ont plus qu’à appliquer le plan d’une manière passive. On peut parler d’une gestion de projet 1.0
On ne peut plus, et d’ailleurs on ne veut plus travailler comme ça. Les acteurs du projet veulent apporter leurs compétences propres. Nous vivons dans un monde de partage des expériences et de la connaissance. De plus, il faut pouvoir apporter la souplesse nécessaire à la vie du projet tout en gardant à l’esprit l’objectif final. Pour reprendre la comparaison précédente, on peut parler de gestion de projet 2.0.
Il apparaît alors rapidement le besoin de savoir où est l’information, dans quel état, qui la produit à cet instant et qui la consomme. Le flux d’information acquiert une importance presque équivalente à la livraison des produits. À vrai dire la livraison des produits doit inclure les informations liées. Par rapport au modèle DIKW, il faut arriver au moins au niveau « knowledge » pour pouvoir gérer un projet.
Car en effet, le propre de la gestion de projet est de pouvoir prendre des décisions en temps réel, par rapport à l’information qui circule. Contrairement à la gestion 1.0 où l’effort est tourné vers un contrôle fixiste des activités et du planning, il nous faut pouvoir concilier :
- La visée vers l’objectif initial
- La prise en compte du déroulement réel du projet
- Les décisions prises par le comité de direction
- Les remontées d’information de l’équipe projet
On voit qu’on est loin du simple « dire ce qu’on fait », et toujours pour reprendre la comparaison avec la notion de 2.0, le chef de projet doit aussi se considérer comme un agrégateur d’informations
Écrire commentaire
Cheryl Hatchell (mercredi, 01 février 2017 12:00)
I have read so many articles or reviews about the blogger lovers but this paragraph is really a nice piece of writing, keep it up.