Migrer un parc informatique sur une nouvelle version de système d’exploitation


Changer de version de système dans une entreprise

système informatiqueL’informatique fait partie de ses technologies qui évoluent rapidement.

A peine une version de système d’exploitation est-elle installée dans les serveurs qu’il faut préparer la prochaine migration.

Les performances de l’entreprise sont liées aux performances de son système d’information et donc de toute son infrastructure informatique.

Les coûts induits par un changement imposé par les fabricants d’ordinateur et autres matériels représentent une part importante des dépenses d’une entreprise, surtout lorsqu’il s’agit d’une entreprise de services, comme une banque ou une assurance.

Comment gérer un tel grand projet, sur des lieux multiples, pour que tout se passe bien ?

Première étape : un inventaire

il convient tout d’abord d’avoir un inventaire complet de toutes les machines concernées : matériels et logiciels.
Comme elles ne vont pas être changées ou évoluées en même temps, il va falloir travailler par lieux et par lots, ce qui est la bonne démarche.

L’objectif premier est la continuité du service.
Une fois la procédure rodée, de préférence sur un petit nombre de machines dans un lieu le moins critique possible, elle pourra être étendue et améliorée au fur et à mesure des changements.

L’équipe de projet étendue

L’équipe de projet sera composée de personnels locaux et d’une équipe mobile (ou plusieurs selon le nombre de lieux).

L’équipe locale sera en charge de l’installation de la nouvelle version.
A elle de préparer le personnel utilisateur des éventuelles perturbations et de préparer un plan de secours en cas d’incident en cours de migration.

L’équipe mobile devra être capable de conseiller l’équipe locale dans la procédure et en cas d’incident pour trouver le plus vite possible une solution aux problèmes éventuels.

Changer ou garder le matériel

Deux cas se présentent :

    • Remplacement des ordinateurs incapables de supporter le nouveau système
    • Conserver les ordinateurs, quitte à les faire évoluer, par exemple en ajoutant de la mémoire

Les vérifications de bon fonctionnement

La migration en tant que telle est techniquement de la routine.

Par contre, il y a des tests de bon fonctionnement à faire après réinstallation de tous les logiciels utilisés.
Plus ils sont nombreux et plus le contrôle du bon fonctionnement des logiciels sera long.

De plus, les logiciels doivent être compatibles avec la nouvelle version.
Généralement, c’est le cas, mais parfois le fournisseur du logiciel ou vos développeurs devront mettre en place une nouvelle version du logiciel, compatible.

Mieux vaut avoir prévu suffisamment de temps, de disponibilité des compétences et un budget pour cette partie du grand projet.

Documentation et communication

Il est impératif de rédiger une documentation pour les techniciens, par l’équipe mobile pour pallier à toute erreur dans la migration.

Par ailleurs, il faut une communication à destination des responsables et des utilisateurs avec dates précises des interventions.
Lire la suite dans ce second article

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :


En complément :

Système d’exploitation
UNIX
Salle informatique : Quelle surface faut-il prévoir ?

DSI RSI Mieux communiquer en interne en cinq conseils
Windows propre ou le nettoyage physique se confond avec le virtuel
Loi de Heare des grands programmes

Autres  Informatique et Management :

Récapitulatif 19 Informatique
Récapitulatif 19 Management

abonnez_vous_ICI_a_la_Newsletter

Sécurité informatique : L’audit des vulnérabilités


L’audit des vulnérabilités

épée de Damoclès

L’épée de Damoclès

Dans le cadre de la sécurité informatique et des mesures à prendre pour pallier aux défauts, pannes, malveillance, etc., il convient de faire le point sur les mesures déjà existantes avant d’envisager d’étendre la protection du système d’information.

La vulnérabilité

La vulnérabilité est le caractère, qui, par ses insuffisances, ses imperfections, peut donner prise à des attaques (Petit Larousse).

C’est au travers d’un audit des vulnérabilités d’un système d’information, que l’on va évaluer son degré de maturité en termes de protection.

Moins il y a de vulnérabilités et mieux le SI sera protégé

Comme l’informatique et les systèmes d’information évoluent en permanence et à une vitesse toujours de plus en plus croissante, l’audit des vulnérabilités est donc à reconduire régulièrement.
Dans l’idéal, ce sera à chaque changement d’un des composants physiques ou logiciels.

Cependant, dans la réalité et pour tenir compte de l’établissement des budgets dans une organisation, c’est une fois par an que cet audit devrait avoir lieu.

Les domaines de l’audit

Le systématisme est nécessaire pour éviter d’oublier l’un ou l’autre des domaines d’un système d’information dans l’audit des vulnérabilités.

Voici les domaines de cette analyse :

  1. Organisation de la sécurité
  2. Sécurité des sites et des bâtiments
  3. Sécurité des locaux
     
  4. Réseau étendu (intersites)
  5. Réseau local (LAN)
  6. Exploitation des réseaux
     
  7. Sécurité des systèmes et de leur architecture
  8. Production informatique
  9. Sécurité applicative
     
  10. Sécurité des projets et développements applicatifs
  11. Protection de l’environnement de travail
  12. Juridique et réglementaire

Les questions à se poser

Pour analyser ces 12 domaines, il convient de se poser les questions appropriées à chacun d’eux :

  1. Qui s’occupe de la sécurité ? Avec quels moyens et quel mode de fonctionnement ?
  2. Comment les sites et les bâtiments sont-ils surveillés et protégés : gardien de nuit, caméras, etc. ?
  3. Quels systèmes sont en place : alarme, détecteur de présence, anti-incendie, identification des visiteurs, etc. ?
     
  4. Quels moyens ont été déployés pour protéger l’accès à distance des informations : identification, chiffrement, etc. ?
  5. Comment et par quoi le réseau local est-il protégé : parafoudre, pare-feu, armoires de brassage fermées, etc. ?
  6. Quels sont les moyens de pallier aux défauts de l’exploitation du réseau : maintenance des serveurs, enregistrements des mouvements des personnels (arrivants et partants), etc. ?
     
  7. Comment les systèmes et architectures sont-ils protégés : sauvegardes, virtualisation, etc. ?
  8. Par quels moyens la production informatique, c’est-à-dire les données sortantes du système d’information sous forme de papier ou à l’écran, est-elle protégée ?
  9. Comment les applications, progiciels ou logiciels sont-elles sécurisées : autorisations d’accès, archivage des versions, etc. ?
     
  10. De quelles manières sont protégés les projets informatiques, de l’idée à leur réalisation : fuite d’information, erreurs de programmation, paramétrages, etc. ?
  11. Quelles sont les protections de l’environnement de travail en place : démultiplication des prises, fermeture des écrans inutilisés pendant quelques minutes, etc.
  12. Quelles mesures de bons comportements sont-elles en place : déclarations CNIL, charte informatique et d’Internet, etc. ?

Cette liste de questions et les quelques exemples associés montrent l’étendu, non exhaustif, des questionnaires à mettre en place pour déterminer le degré de maturité des mesures de protection contre les vulnérabilités détectées.

Vigilance

Il faut être particulièrement vigilant en matière de sécurité informatique.

Par exemple, pour le point 1, il faut que le responsable de la sécurité informatique soit une personne indépendante de la hiérarchie des informaticiens. Son indépendance vis-à-vis de cette hiérarchie va permettre de surveiller et d’agir contre tout informaticien indélicat, responsable du service inclus.

Pour cela,

  • soit un service séparé doit être défini et rattaché, par exemple, directement au responsable de l’établissement, pour une entreprise importante,
  • soit à un collaborateur d’un autre service qui en sache suffisamment en matière informatique, pour des organisations plus petites.

Philippe Garin, plus de 20 ans de management en entreprise

Pour mieux protéger votre système d’informations, contactez-moi : phgarin@gmail.com

Pour en savoir plus :


En complément :

Lexique informatique
Menace – Vulnérabilité – Risque
Parefeu : Utilité et risques

Liste des risques de sécurité informatique
Plan d’un rapport d’audit en entreprise
RCO, LCC et MTBF expliqués pour les nuls

Autres Informatique, Management, Organisation et Sécurité :

Récapitulatif 15 Informatique
Récapitulatif 15 Management
Récapitulatif 15 Organisation
Récapitulatif 15 Sécurité

abonnez_vous_ICI_a_la_Newsletter

Management de projet : 5 causes de l’échec


Management de projet : 5 causes de l’échec

la chance comme styme de management Une étude menée par Standish Group aux États-Unis indique que seulement 16% des projets se terminent dans les budgets et délais initiaux, et seulement 9% dans les grandes entreprises.

Fort de ce constat, il faut reconnaître que les dépassements, de budget ou de délais, sont tellement courants que les prévisions et les estimations de coûts sont systématiquement faussées malgré les 10 à 20% de « réserve pour dépassement » que le responsable interne ou l’entreprise extérieure ajoute, « à toutes fins utiles ».

L’échec d’un projet se traduit par les dépassements et aussi par un arrêt du projet, ce qui représente une perte sèche pour l’entreprise et pire un retour en arrière, lorsque c’est encore possible.

Les causes de l’échec

Les causes de l’échec sont multiples. Elles sont présentes tout au long du projet, à commencer par la définition du projet, de la description de la situation en cours à la situation prévue, en passant par toutes les étapes d’un projet. Le choix des participants au projet est du ressort du management. Plus le projet est important pour l’entreprise et plus haut remontent la responsabilité.

Des exemples :

  • La mise en place d’un nouveau serveur informatique est du ressort du responsable technique du service informatique, voire du responsable informatique.
  • La mise en place d’un système de surveillance d’un bâtiment est du ressort du responsable de l’établissement.
  • L’achat d’une entreprise qui va devenir filiale est du ressort du comité directeur, voire du patron lui-même.

Parmi toutes les causes possibles, en voici 5 qui nous paraissent intéressantes à analyser ;

1. La peur du changement

C’est LE classique. Le motif le plus courant est la peur du changement. C’est une illustration de la peur de l’inconnu, du futur, de devoir changer ses habitudes, de ne pas être à la hauteur. C’est la crainte de la perte de son pouvoir, de son image ou que l’on découvre son incompétence bien cachée jusque là.

2. La rivalité

Dès qu’un nouveau projet est évoqué, la rivalité entre personnes devient plus apparente. Les conflits augmentent avec les enjeux du projet, politiques, personnels, financiers.

La rivalité commence à l’intérieur de l’organisation, et se poursuit entre les acteurs internes et externes à la société, et même entre fournisseurs concurrents.

Toutes ces questions de personnes, entre compétences et égos, conduisent à des pertes de temps, d’argent, de ressources matérielles et humaines, donc à l’échec du projet.

3. Le résultat

La difficulté pour le décideur consiste à s’imaginer le résultat auquel il veut parvenir, puis à choisir la personne qui mènera le projet jusqu’à son terme et dans le budget prévu, – cette personne peut être elle-même -enfin, la description du chemin par lequel il faut passer pour parvenir au résultat attendu. Le projet est composé de plusieurs tâches : Les unes se succèdent alors que d’autres peuvent être exécutées par des acteurs différents, en parallèle, c’est-à-dire en même temps.

Selon l’ampleur du projet, des jalons avec dates précises et résultats intermédiaires précis, sont fixés ou sont complètement absents. Le manque de jalons ou points de situation intermédiaires, le manque de contrôle et de rapports du chef du projet au décideur conduisent immanquablement à l’échec.

4. Les mesures

Pour anticiper et réagir aux aléas d’un projet, plusieurs indicateurs sont nécessaires. Quel que soit le degré d’importance du projet, il faut être capable de mesurer son avancement et sa réussite, tout au long du projet et pas seulement en constatant le résultat final ou intermédiaire obtenu. Cependant, que les mesures soient définies, dans les tableaux de bord, en jours/homme, en rapport dépenses/économies ou gain, ces chiffres sont souvent inutilisables ou/et incompréhensibles pour le décideur. Même un chef de projet professionnel est amené à « sentir » l’avancement de son projet, malgré toute la rigueur et l’organisation mises en place. Il reste que nombre d’actions nécessaires pour mener une tâche à bien sont improvisés. Donc, dérapage et échec à la clé.

5. Les outils de pilotage

Plus une entreprise est grande ou plus le nombre de projet est important pour l’organisation et plus la présence d’outils de pilotage de projets est nécessaire et même indispensable.

Le nombre de tâches et les enchaînements entre elles devient croissant au point de devoir se procurer des outils qui vont indiquer à chaque collaborateur impliqué dans les projets, la liste des tâches à accomplir à chaque journée planifiée, avec quels moyens techniques ou en coordination avec d’autres personnes, en interne ou externes à l’entreprise.

Plus le pilotage est informatisé et plus le chef de projet se base sur ses outils et moins sur les relations humaines, pourtant indispensables. L’encouragement ou la réprimande font partie des éléments de motivation du responsable du projet vis-à-vis de ses collaborateurs. Passer à côté de cela et c’est l’échec assuré.

Des règles de bon sens

  • Sortir la tête du guidon est un bon moyen de faire le point « vu d’en haut » (certains disent « vu d’avion »)
  • Se faire accompagner par une personne extérieure au projet, comme un organisateur ou un responsable qualité ou encore un coach, permet de poser le crayon et de se demander si et comment les méthodes employées vont conduire au succès du projet.
  • Définir des jalons est bien ; définir les « délivrables » est mieux. Il s’agit de résultats intermédiaires documentés. La documentation doit être terminée, sans remise en question par des jalons précédents. Si ce n’est pas le cas ou si la qualité est insuffisante, alors il faut corriger, refaire ou abandonner, avant d’aller plus loin vers l’échec.
  • Savoir de quoi on parle et choisir les indicateurs de pilotage compréhensibles par tout et utiles pour prendre des décisions. Là encore, le bon sens doit permettre de s’y retrouver suffisamment facilement pour comprendre, juger et décider de la suite à donner, attribuer des félicitations, des encouragements ou des reproches.
  • Former le personnel aux outils, notamment le responsable au pilotage de son ou ses projets, permet de gagner du temps et de monter d’un ou plusieurs degrés la qualité du management et les chances de succès du projet.
  • Penser que l’échec d’un projet est une exception et non la règle malgré tous les risques que le projet contient par sa nature.

C’est avec des principes de bon sens que la rivalité entre personnes sera amoindrie et les conflits entre personnes réduits.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en avoir plus :


En complément :

Un cahier des charges pour éviter des conflits entre client et fournisseur
Que se passerait-il si le projet n’avait pas lieu ?
Le TCO ne suffit pas pour changer de logiciel en entreprise

Évolution du besoin en cours de projet
Analyse de dysfonctionnements et réduction de coûts cachés en 10 étapes
A savoir sur la gestion des ressources pour un chef de projet

Autres Management :

Récapitulatif 14 Management

abonnez_vous_ICI_a_la_Newsletter

Projet : Que se passerait-il si le projet n’avait pas lieu ?


Gestion de Projet : Que se passerait-il si le projet n’avait pas lieu ? Ou s’il était retardé ?

hésitation j'y vais ou pasVoilà une question que le donneur d’ordre, le maître d’ouvrage, doit se poser lorsqu’il souhaite lancer un nouveau projet, informatique ou autre.

Plusieurs facteurs rendent le démarrage d’un projet indispensable

  • Les contraintes législatives : Le passage à l’Euro a été imposé à tous, les changements de taux de TVA, etc.
  • Les changements de réglementations dans son domaine d’activité : Accords de branche et conventions collectives, traçabilité des produits dans la Distribution, etc.
  • La concurrence : Nécessité de mener des actions marketing ou commerciales pour contrer les attaques de la concurrence
  • La position de leader, l’image de la société : Lancement de projets de « prestige », construction de beaux bâtiments, dont les aménagements doivent rassurer le client ou le banquier
  • Etc.

Dans tous les cas, c’est la volonté du dirigeant de l’entreprise qui donne l’impulsion et dénoue les cordons de la bourse, mobilise le personnel pour œuvrer dans le projet

Un chef d’entreprise qui, mis au courant des risques pris pour l’entreprise, du démarrage, du retard ou de l’abandon d’un projet, dois prendre la décision qui convient.

La question se pose d’abord avant de lancer le projet.

Elle se pose aussi et différemment quand le projet a déjà démarré, car des frais ont été engagés, des autorisations ont été parfois demandées

  • Choisira-t-il de maintenir sa décision initiale, malgré les risques ?
  • Changera-t-il d’avis ?
  • Quel sera l’impact de cette nouvelle décision sur son image en tant que manager auprès de ses employés, de ses concurrents, de ses fournisseurs, de ses clients ?
  • Combien cela lui coûtera-t-il de maintenir sa décision ou d’en changer ?

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :


En complément :

Projet : Go / no Go ou Faut-il y aller ;?
Règles et axiomes d’un chef de projet en trois langues
Bien définir son besoin

Questions à poser à un client de référence
Modèle de cahier des charges
Questions préliminaires liées au Management de projet

Autres Informatique et Management :

Récapitulatif 1 Informatique
Récapitulatif 2 Informatique
Récapitulatif 7 Informatique
Récapitulatif 5 Management
Récapitulatif 7 Management

Tous les articles de ces catégories sont listés dans les pages Informatique et Management

abonnez_vous_ICI_a_la_Newsletter

Management de projet : Neuf erreurs les plus courantes du Chef de projet


Les 9 erreurs les plus courantes du Chef de projet

chercher les neuf erreursSous la pression de son donneur d’ordre, un chef de projet informatique, ou autre, a peu de moyens pour réaliser son projet dans le temps imparti.

Parfois, la date de fin est imposée, parfois c’est lui qui doit la donner.

Dans les 2 cas, le dépassement est plus ou moins long. Très rares sont les projets qui finissent à la date prévue.

Voici une liste des 9 erreurs les plus courantes qui conduisent à un retard :

  1. Prendre en compte des besoins mal définis
  2. Se précipiter au début du projet
  3. Sous estimer la charge, les moyens et les coûts
  4. Accepter des évolutions fonctionnelles demandées en cours de projet, sans révision du projet
  5. Nommer une équipe sans diversité des talents et compétences techniques (débutant, expérimentés)
  6. Rester inflexible sur une méthodologie trop lourde et trop contraignante
  7. Choisir des outils aux contraintes techniques trop rigides
  8. Choisir des technologies trop récentes et potentiellement non pérennes
  9. Ne pas suffisamment penser aux évolutions dans le temps du système d’information, objet du cahier des charges

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :


En complément :

Règles et axiomes d’un chef de projet
Les 11 phases du déroulement d’un projet informatique
Le rôle des ressources internes dans un projet

Rôle des acteurs majeurs dans un projet
Ajouter des ressources en cours de projet ou le principe chinois
Composition d’une équipe de projet : juniors et seniors

Autres Informatique :

Récapitulatif 6 ;informatique

Tous les articles de cette catégorie sont listés dans la Page Informatique

abonnez_vous_ICI_a_la_Newsletter

Le rôle des ressources internes dans un projet


Le rôle des ressources internes dans un projet

ressources internes d'un projetUn des rôles du Chef de Projet est de désigner les personnes qui vont travailler dans le projet : les ressources.

Il y a ceux qui vont y travailler de bout en bout et ceux qui interviendront sur une partie du projet.

Utiliser des ressources internes à l’entreprise qui a décidé du projet est la première idée qui vient à l’esprit.

Qui sont les ressources internes ?

Pour un projet informatique, le service informatique est sollicité. C’est son travail habituel. Les informaticiens sont là pour cela. Ils en ont l’habitude.

Cependant, si la finalité du projet est la mise à disposition d’utilisateurs fonctionnels un logiciel ou un matériel alors les utilisateurs doivent être représentés dans le projet.

En général, le responsable hiérarchique, chef de service ou directeur, est impliqué dans le projet, dans la mesure où il décide du temps qu’il accorde à son ou ses collaborateurs pour travailler dans le projet.

Le meilleur choix est celui qui consiste à désigner l’utilisateur final ou l’un des futurs utilisateurs, celui qui sera confronté aux résultats du projet.

Il faut qu’il soit motivé et convaincu que son apport dans le projet sera déterminant pour sa réussite.

Comment motiver la ressource interne ?

Le Chef de projet se verra amener à le motiver car cet utilisateur considérera ses activités dans le projet comme un surcroît de travail, car il privilégiera son travail quotidien aux tâches du projet.

Le représentant des « fonctionnels » dans un projet a pour tâches :

  • D’expliquer le fonctionnement actuel et futur des activités à informatiser ou à améliorer
  • De participer au paramétrage du logiciel
  • De définir les résultats attendus, tant dans les saisies des informations que leurs traitements et la restitution des résultats, sous forme d’écrans de saisie ou de lecture, d’éditions ; etc.
  • De tester les programmes et de vérifier que les résultats soient conformes aux attentes
  • De valider le travail des informaticiens
  • De rédiger les manuels utilisateurs ou d’y prendre part, de façon à ce que le vocabulaire utilisé soit son propre langage professionnel et non pas celui des informaticiens
  • De former ou/et d’informer sa hiérarchie et ses collègues, futurs utilisateurs, de l’avancement du projet

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :


En complément :

Rôle des acteurs majeurs dans un projet
Ajouter des ressources en cours de projet ou le principe chinois
Estimez la charge de travail, le coût et l’implication à leurs justes valeurs

Stress : maladie contagieuse ou faute du management ?
Devise 033 : ça ne fait pas de mal de flatter son patron
Management de projet informatique : Neuf erreurs les plus courantes du Chef de projet

Autres Informatique :

Récapitulatif 5 Informatique

abonnez_vous_ICI_a_la_Newsletter

Rôle des acteurs majeurs dans un projet


Rôle des acteurs majeurs dans un projet

Les 7 merceilles du monde antique

source : Wikimedia

Désigner, nommer une ressource dans un projet, c’est désigner les personnes qui vont travailler dans le projet, c’est-à-dire exécuter les tâches à réaliser pour mener le projet à bien.

La nomination des ressources est une des premières tâches du chef de projet.

Lorsque le projet est important, pour la stratégie de l’entreprise, la Direction créé un Comité de Pilotage.

Le Comité de Pilotage,

composé généralement de la Direction Générale ou/et du PDG, et des Responsables fonctionnels concernés, en plus du Chef de Projet

  • définie les limites du projet, c’est-à-dire les objectifs du projet,
  • fixe un budget,
  • nomme le Chef de projet

A son tour, le Chef de projet,

  • découpe le projet en tâches, plus ou moins élémentaires selon l’ampleur du projet
  • désigne les ressources matérielles et humaines, nécessaires pour l’exécution des tâches
  • estime et calcule la durée des tâches et fixe les points de contrôle et la date de fin du projet

NB : La date de fin du projet peut être l’un des objectifs fixés par le Comité de Pilotage ou Comité de Projet, en anglais Steering Comitee, à moins que des événements extérieurs imposent la date de fin, par exemple, la date de début d’une nouvelle réglementation ou d’une loi.

Souvent, la notion de projet démarre avec la maîtrise d’œuvre.

A partir d’un cahier des charges, le Chef de projet démarre le projet.

Néanmoins, pour les projets importants, la maîtrise d’ouvrage fait souvent partie du projet. C’est la partie en amont du projet ou au début du projet qui permet de définir le besoin et de rédiger le cahier des charges. La maîtrise d’ouvrage est assimilée au donneur d’ordres.

A partir d’une seule analyse de besoins, plusieurs projets peuvent être définis et mis en œuvre, l’un après l’autre ou en parallèle.

Philippe Garin, plus de 20 ans de management en entreprise

Pour plus de conseils, contactez-moi : phgarin@gmail.com

Pour en savoir plus :


En complément :

Plan compte rendu Comité de projet
Organisation de la Gestion de Projet
Composition d’une équipe de projet : juniors et seniors

A savoir sur la gestion des ressources pour un chef de projet
Evaluation de projet : L’échelle européenne
Le rôle des ressources internes dans un projet

Autres Informatique :

Récapitulatif 5 Informatique

abonnez_vous_ICI_a_la_Newsletter

%d blogueurs aiment cette page :