Analyse d'un projet  réseaux

 

Les règles  de bases des audits informatiques microsoft

 

 

Ces analyses sont personnelles et ne peut réprensenter en quelques facons que ce soit une vison général de des technologies Microsoft et se  basées sur une  experience  limité  partis  mes opinions de Technicien informatique  technique, tels a été ma mission chez france telecom et teleperformance techniciens de  projets informatiques cela ma nécessité une grande étude des  cachiers des charges de prototypages   de fonction polymorphisme c++ abstrait, avec  l'études objets et la connection des  réseaux sociaux .

Cela m'a permis de prendre en compte l'impact de la technologie sur l'homme , la nature et son aspect psychologiques et ceci à pour  but de produire en moi une compréhension des réseaux  technologiques et de ses possibilité , de ses  fludités technologiques de son impact communicationnel  sociaux vu l'émmergence de cette possiblité  tel que facebook , linkedin , viadeo ouvre de nouvelles portes aux nouvelles technologiques , cette information la diffussion sur le n@t-work-ing.

 

Ces données numériques , la cohérence du systéme d'information , de l'entretien technique informatique mais aussi  apprendre de ses erreurs. Je vais vous détails quelques idées .

 

Dans cette partie je vais traiter de manière importante de l’aspect humain dans la gestion de ce projet. Si cela semble accessoire, il faut se souvenir de l’aspect économique de la  mission: «  Le but d’information est de développer fortement l’activité consulting ,e-service,m-service et de sécurité . »

 

Il est donc primordial que le sentiment du client soit celui qui l’amène à refaire appel à nos services dans de futures opérations comparables.

 

Si dans un temps court et sous la pression de la production nous sommes parvenus à effectuer les mesures et les modifications escomptées, il n’en reste pas moins que nous avons rencontré de trop nombreux problèmes pour que je considère ce projet comme un succès.

 

Cette opération techniquement réussie, aura été sans cesse dominée par un sentiment aigu de stress et de risque. Si je suis intervenu, depuis, dans une autre entreprise du groupe pour ce type de prestation (Pierrot Gourmand), l’équipe Andros ne renouvellera pas l’expérience pour la migration de Windows 2000 à Windows 2003.

 

Le cycle en cascade

Les raisons du succès sont sans nul doute à mettre sur le compte de l’application du cycle en cascade. Ce cycle a été garant d’une grande précision dans la procédure et de l’acquisition, pour ma part, des compétences-terrain minimales.

 

Les phases de vérification et validation du document « Résultat Audit Réseau Andros et Plan de Migration de NT4 à 2000 » ont permis de passer en revue un grand nombre de possibilités d’incidents et de mettre en place une procédure adaptée.

 

Les difficultés de maquettage « confidentiel » de l’équipe ont aussi été un élément d’échange constructif.

 

Les compétences

On ne saurait, bien sûr, aborder ce type de projet sans avoir de compétences minimales. La double compétence « consultant/homme de terrain » permet de trouver des solutions à beaucoup de problèmes.

 

 

L’ambiguïté du rôle de consultant ou la gestion "multi-têtes" d’un projet

Dans le cas de projets de ce type, l’industriel et les équipes gérant le système d’information et de production vont tenter de réduire le risque et leurs responsabilités. Pour cela l’industriel fait appel à une aide externe de référence.

Si cette personne ne peut être officiellement chef de projet, elle va devoir être force de proposition et référent technique.

 

 

 

Cette situation est équivoque, elle participe de la frustration finale du client à qui le projet finalement a échappé.

 

Le client a suivi plusieurs cours avec le consultant comme formateur. Dès la première réunion, en position d’attente - retrouvant naturellement la combinaison historique - il pousse par son attente le consultant à animer la réunion. Les jeux sont faits. Le consultant est de fait le chef de projet et non plus seulement un référent technique. Dans notre système de valeur latin, ou comme dit le philosophe Francis Bacon (1561-1626) « Le vrai pouvoir, c’est la connaissance. ». Il est très difficile pour le client de prendre la direction des opérations et pour le consultant de renoncer à celle-ci.

 

 

conséquences présentes pendant la migration.

• Les techniciens intervenant uniquement en production et pendant les pannes.

• Il est impossible de faire une estimation sur l’état général de la chaîne de traitement de l’information.

• Les techniciens sont démotivés et stressés.

 

 

La solution est pour chacun d’eux de limiter sa participation dans des opérations à risque et donc de refuser les responsabilités. Ceci est un des fondements du problème de gestion des rôles.

 

 

• Les techniciens ne connaissent pas le parc à maintenir mais seulement les machines posant problèmes. Ils ont souvent des machines à réparer qu’ils n’ont jamais vu fonctionner correctement. « Ceci se retrouve sur le problème majeur des transpalettes. »

• Si personne ne remarque de dysfonctionnement, certaines erreurs peuvent perdurer.

 

On retrouve ici une des causes de l’erreur qui à amené la coupure réseau avec les transpalettes. Il n’est pas possible de gérer un projet sur de l’existant sans avoir une bonne connaissance de celui-ci.

 

 

Un projet peut-il exister sans chef de projet ?

 

Selon la définition de C.Sibertin-Blanc un projet est défini par une organisation propre et l’identification et les rôles des intervenants.

 

 

le changement de système d’exploitation, ce projet n’était pas un projet « fantôme ». C’est à dire que ce changement, non prévu, non budgétisé et à une date mal choisie, avait été mené sans avertir la direction de l’entreprise. Ceci expliquerait le quota maximum de trois jours facturés. Un jour d'audit et trois jours pour installer un serveur devient un timing « confortable ». Ceci expliquerait aussi le relatif désintérêt du directeur informatique d’Andros, l’absence de système de gestion de projet et le manque de documentation technique concluant le travail effectué.

Dans ce cas, le projet d’entreprise : « Migration du Réseau Andros de Windows NT4 vers Windows 2000 », n’aurait jamais existé.

 

 

L’ensemble des erreurs techniques que nous avons commises sur ce projet peu sembler lié à un manque de compétences et à un facteur d’erreur commun : « j’applique sur une information nouvelle un masque d’une information connue similaire ».

• L’arrêt de service « Client DHCP » est dû au fait que la personne ne savait pas ce que faisait ce service. Elle a, en fait, présupposé que le nom du service correspondait à l’ensemble de ces fonctions; ce qui était faux.

• L’oubli ou la méconnaissance de la technologie de la gestion des emplacements des palettes est bien sûr plus inquiétant. L’oubli est révélateur d’un problème de fond. Il est une faute.

 

Dans la réalité ces erreurs sont dues au manque de méthode et de documents référents. Se reposer sur la mémoire et la compétence des hommes pour la gestion d’une entité telle qu’Andros est insuffisant. Seul la mise en place de règles de procédures et de méthodes peuvent être les garant du succès.

 

 

moyens, plus de compétences techniques ?

On a coutume de dire que si un projet échoue, c’est que l’on a pas eu assez de temps , de compétences techniques, ou de moyens.

Plus de temps, de moyens, de compétences auraient ils été des facteurs de réussite ? La réponse est non. Clairement nous avons accompli cette migration dans un temps trop court, dans la précipitation et pendant une période critique, mais ceci ne change rien à l’affaire.

 

 

Avec plus de temps, j’aurais pu par exemple participer aux maquettages. Ceux-ci auraient alors fonctionné mais nous n’aurions pu maquetter des mouvements de transpalette dont nous ignorions l’existence. Le manque de méthode tant dans la gestion du projet que dans celle de la gestion du réseau et des équipes est responsable de nos erreurs. Ces méthodes ont un coût, mais sans la volonté et le savoir faire, plus de temps n’aurait servi qu’à perdre du temps.

 

 

Comment tâcher de ne pas retomber dans ces travers ? Une analyse des causes nous permet ici de proposer des règles de fonctionnement qui devraient améliorer le fonctionnement des futurs projets de ce type. Comme toujours, ces règles se doivent de ne pas faire payer leurs avantages par un temps de mise en œuvre

 

• Fixer les rôles

 

• Fixer les objectifs

 

• Fixes les contraintes matérielle et im-matérielle

 

 

De façon à éviter tout flou dans la structure des équipes-projet. Le rôle du consultant doit être déterminé .

 

 Technicien informatique  technique, tels a été ma mission chez france telecom , assistanté d'un chef de projet » . Le seul fait de nommer ce rôle obligera les intervenants à une réflexion salutaire.

 

Dans l’idée de limiter sa responsabilité, tout en gardant théoriquement la gestion du projet, le client peut souhaiter un fonctionnement de type collégial.

 

Mais même dans ce cas, une réflexion préalable sur les rôles de chacun, lui permettra de mesurer les enjeux de ses choix.

 

Si le consultant se voit allouer un rôle de chef de projet, cela lui donnera une vraie légitimité.

Pour éviter tous litiges et modifications, ceci doit être fait par la cellule commerciale d’iBFormation en amont de la prestation et contractualisé.

 

• Créer une liste des contrôles techniques à faire avant la migration ou toutes autres phases critiques

 

 

 

Ces migrations logicielles comportent un grand nombre de tâches répétitives. Il sera judicieux de tenir à jour une liste de points de contrôle à effectuer avant chacune des tâches techniques présentant un risque.

Cette liste aurait ainsi été enrichie de : Vérifiez le fonctionnement et l’état du service « Client DHCP «  sur le serveur Windows 2000 avant l’installation du service « Active Directory ».

Cette liste devra être partagée et alimentée par l’ensemble des formateurs consultants iBFormation.

 

• Modifier la mission des équipes du support informatique chez Andros

Andros doit modifier le fonctionnement de ses équipes informatiques. Une gestion par projet et un ensemble d’activité de fond permettront une meilleure efficacité. Ces activités pourraient être :

• • • • l’établissement de mesures quotidiennes sur le réseau (bande passante utilisée, type de trafic …),

      • auto-formation de fond,

      • contrôle régulier des serveurs (disques, ressources mémoires, CPU …),

      • Contrôle régulier d’une partie des postes des utilisateurs.

 

• Créer une liste de contrôle, un jeu de mesures et de points de tests validant le système d’information Andros dans sa totalité.

Attendre qu’un problème se manifeste pour lui chercher une solution est à la fois une erreur technique et de une erreur de management.

La création d’une liste de contrôle, et l’automatisation des tests critiques permettraient :

• • • • Une remontée des problèmes avant que ceux-ci ne se signalent par un dysfonctionnement plus coûteux,

      • Une meilleure connaissance des processus de traitement de l’information par les équipes,

      • La création de cette liste et des tests peut être une mission de fond allouée à l’équipe informatique

      •