Pour réussir son projet de migration messagerie concurrentielle, il faut bien s'organiser et surtout ne pas omettre certaines phases du projet. En effet, la mise en œuvre opérationnelle de la nouvelle infrastructure messagerie (souvent pensée comme « le projet ») peut au final ne représenter que 20% du projet. Celui-ci couvre souvent, à 80%, une migration orchestrée, monitorée et procédurée des logiciels clients, des données d'archives et des habitudes.
1. Définir les spécifications
Dans une premier temps, il convient d'étudier l'existant en terme de messagerie, mais aussi de système d'annuaire, de réseau (WAN, LAN, accès extérieurs entrant/sortant), de poste client et de données.
Ensuite, il sera défini l'architecture générale ou plutôt les différentes options.
Celle-ci sont souvent liées à différentes architectures ActiveDirectory, comme disposer d'une forêt de ressources.
Elles sont liés à la centralisation/décentralisation, la haute disponibilité attendues (cluster, redondance, PRA) et aux disposition des données (SAN, réplication, sauvegardes).
Sont également étudiées et retenues la solution de monitoring de la plate-forme cible, comme SCOM ainsi que les solutions périphérique liées aux flux et à la sécurité : proxy applicatif, passerelle filtrées, autorité de certification, solution d'accès des smartphones et blackberry.
Les aspects de virtualisation des systèmes de messagerie sont validés à ce stade, soit Hyper-V soit le plus souvent sous Vmware.
Peuvent être alors enfin choisis les meilleures solutions globales de licencing.
La phase suivante va viser à définir le client d'accès (lourd ou web), en fonction des usages (notamment agenda, nomadisme) et lié à la version de Office déployé. Attention, OWApp dispose d'un look moderne 2010, avec ruban de fonctions, alors que le OutLook lourd du parc peut ne pas en être encore à ce stade d'ergonomie.
Vient alors l'étude de la stratégie de déploiement du nouveau client de messagerie. Celle-ci peut se faire par GPO, par outil (LanDesk, SCCM, Refresh, ….) ou par publication sous Citrix. Ce déploiement sera une opération conduite dans le temps avec un monitoring centralisé et installation manuelle de certains postes. Elle s'effectuera légèrement en amont de la migration des comptes et des BALs.
Ensuite, il est défini la stratégie de migration des données : savoir ce que l'on récupère des comptes, des boites aux lettres, des archives, des agendas, des carnets d'adresses, … en fonction du choix, un outil s'imposera (voir prototypage).
Enfin, il doit être abordé l'effort d'accompagnement en terme de communication, transition, formation.
Cette stratégie de migration et de formation conditionnera la phase de cohabitation entre les 2 systèmes, plus ou moins longue.
C'est assez important car deux systèmes signifient pour l'IT : deux administrations, deux manières de travailler pour les utilisateurs, deux supports, ...Parfois, mieux vaut viser un big-bang qui impactera brutalement, les utilisateurs, mais qui durera moins longtemps.
A ce stade, il est alors déjà possible de définir le macro-planning du projet car celui-ci est basé sur le chemin critique. Or, c'est bien souvent la complexité ou la profondeur de la migration, avec l'accompagnement utilisateur retenu, qui définit ce chemin critique.
2. Prototyper pour valider l'infra, les outils et le processus
Suite aux spécifications, il est utile de monter une maquette, en fait un prototype car le système deviendra le système de production une fois réglé, complété et optimisé (c'est devenu possible grâce à la virtualisation favorisant cette mise au point et les retours arrières).
Quelques clients sont déployés et des BALs sont migrées, ainsi que des archives.
Les outils de migration sont alors validés.
Il en existe de nombreux types :
- des outils de conversion locaux de données, comme les carnets d'adresses
- des outils centralisant la création des comptes et la migration des BALs (ex Quest)
- des outils orchestrant tout le processus de migration, y compris le provisionning via workflow utilisateur, et la communication (ex Refresh IT)
La communication / formation est également validée.
La communication doit épauler l'utilisateur et décharger le helpdesk de l'effort de support.
- Elle doit débuter longtemps à l'avance, avec des messages courts et simples, puis, devenir plus précise lorsque la date approche
- Elle doit expliquer, avec une touche motivante et positive, ce qu'apporte la migration à l'utilisateur et lui dire que l'impact sera minime
- Elle devra indiquer toutes les sources d'information et de support disponibles : le numéro du support, les coordonnées du CDP, des référents de proximité pour le projet (migrés et formés en premier et disposant de l'expérience), la FAQ du projet sur l'intranet, les éléments de planning et d'inscription (si l'utilisateur dispose d'une latitude, ce qui est conseillé)
La formation peut s'établir sous 2 formes :
- de manière classique, avec formateur et session de formation en salle (nécessite lourde logistique à organiser, et déplacement des élèves)
- de manière virtuelle, avec solution & processus de e-Formation, ou l'on s'inscrit à une session, puis ou l'on assiste à une formation via son écran, en disposant d'un vrai formateur pédagogique distant (ex solutions Mandarine)
- Seule la deuxième solution permet de conduire simplement des « transitions » rapide en formant de 50 à 400 utilisateurs par jour, en dupliquant simplement les formateurs distants.
- Pour compléter les solutions, il est possible également :
- d'organiser des formations avancées personnalisées pour certaines populations (comme les assistantes)
- de fournir à certains utilisateurs des triptyques papier décrivant les principales nouvelles fonctions du nouveau client messagerie
La phase de prototypage donne souvent lieu à la formation des équipes IT aux techniques d'administration
3. Conduire un Pilote
Une fois les spécifications et le prototype validé, il est possible de conduire un pilote sur une population retenue.
Le pilote permettra de valider le processus industriel de déploiement client, de migration BAL et archives.
Le choix des groupes est important. Il conviendra de placer les VIP ensembles, leur assistante en formation au même moment, définir des groupes d'utilisateurs « anti migration », comme des groupes de « pro-migration » (à bien identifier en amont). Ne pas inclure ces populations au pilote car elle perturberont la validation. Leur donner un discours légèrement adapté en argumentaire.
Sur le pilote, pour qu'il soit riche d'enseignements, ne pas retenir uniquement des utilisateurs de la DSI (peu représentatifs) mais un panel d'utilisateurs de différentes entités et métiers.
Un nombre de 30 utilisateurs est correct.
Faire un retour d'expérience pour tuner et optimiser le processus tant de déploiement, de migration et de formation.
La phase pilote donne souvent lieu à la formation des équipes IT aux techniques d'exploitation.
4. Conduire la Généralisation
Une fois staffées les équipes de déploiement, de migration, de formation, de helpdesk, il est possible de conduire la généralisation par lots (site, services, populations, …).
La campagne de communication et de validation des inscriptions aux migrations et aux formations se lance alors.
Les équipes de déploiement sont alors rassemblées, informées, préparées pour le démarrage.
En fonction des outils retenus, la phase de généralisation pourra s'établir sur 1 mois ou sur 1 an.
Le planning est fortement conditionné par la capacité de l'entreprise à gérer une transition vis à vis de son équipe IT mais aussi des habitudes des utilisateurs.
La capacité à impacter les utilisateurs par cette opérations en regard de leur métier quotidien y est pour beaucoup. Certaines populations, comme les personnels médicaux, ont du mal à fixer dans le temps leur créneau de migration et formation car, par définition, ils gèrent souvent des urgences.
Les équipes d'administration doivent avoir été renforcées pour assurer la migration en sus de leurs tâches quotidiennes.
Le help-desk renforcé vient aussi appuyer cette généralisation, tout en étant déchargé par la communication orientant les questionnements vers les éléments de la formation ou la FAQ.
La généralisation se conduit, puis se clôture alors par le traitement des cas d'exception (ex grands nomades, grands congés-arrêts) et par un bilan / retour d'expérience.
Les utilisateurs ont été alors basculés en douceur et avec accompagnement sur la nouvelle plate-forme que, bien souvent, ils apprécient déjà et oublient vite l'ancienne.
Le temps de la désinstallation des anciens serveurs et clients est alors venu.
Le mode opératoire complet rôdé ici sur le projet d'évolution messagerie aura nécessité un certain investissement technique et humain. Mais il n'est pas perdu. Son usage et ses bonnes pratiques peuvent être réemployés rapidement, par exemple, pour une migration vers Windows 7 / Office 2010 se déroulant quelques mois plus tard.
Aucun commentaire:
Enregistrer un commentaire