Des processus définis mais rarement bien déployés

La phase de définition des processus nécessite une énergie importante. S’ils sont généralement bien définis avec par exemple des kits de communication, ces derniers ne sont en revanche que partiellement déployés. Or, la phase de déploiement mobilise une énergie au moins aussi importante que la phase de définition.

Les DSI sont aujourd’hui bien dotées d’équipes de processus transverses. Mais celles-ci n’arrivent toujours pas à gagner en légitimité et à mobiliser les équipes opérationnelles, générant ainsi des pratiques hétérogènes.

Élargir au maximum le réseau d’acteurs au sein de la DSI 

Les équipes de processus transverses ont l’habitude de définir les premières briques du processus mais sans impliquer les opérationnels. Ces mauvaises habitudes engendrent une réelle complexité à le déployer. Celui-ci peut même être parfois rejeté par les équipes.

Impliquer des représentants d’opérationnels, en ciblant les plus impactés par le processus, s’avère ainsi nécessaire dès le début du projet. L’enjeu est alors de pouvoir répondre aux interrogations suivantes : quels enjeux opérationnels se cachent derrière la mise en place ou la revue du processus ? Quels sont les bénéfices financiers attendus ? Quelle est notre ambition et quels moyens mettre à disposition des acteurs pour atteindre les objectifs définis ?

Les premiers échanges avec les acteurs sont précieux. Il s’agit là de créer le premier cercle de votre réseau de processus. Par la suite, ce premier cercle travaille sur une première conception (formalisation, identification des acteurs et des rôles / responsabilités associés, ainsi qu’une précision des outils nécessaires).

Après cette première définition, il est nécessaire de présenter cette première version à d’autres acteurs de la DSI. Cette action a un double enjeu : challenger le processus défini et réaliser une première communication autour du processus. Rester à l’écoute de tout acteur et prendre en compte les remarques pertinentes permet de concevoir un processus en phase avec les attentes et besoins des opérationnels.

Ajouter ses « amis  métiers » dans le cercle de définition… et avoir un ami proche avant de déployer

Afin de donner plus de légitimité au processus défini, des présentations régulières auprès d’acteurs métiers peuvent être réalisées. Ainsi votre cercle continue à s’élargir tout en assurant une bonne précision des travaux réalisés. A ce stade, de nouveaux ajustements peuvent être apportés suite aux retours de ce réseau. L’implication du métier est un des leviers de motivation des acteurs de la DSI dans le déploiement des processus. Il reste à vérifier que le processus est bien adapté au terrain.

Quand cela est possible, il ne faut pas hésiter à déployer sur un périmètre restreint (site pilote). Il s’agit de la dernière étape pour apporter les derniers ajustements et assurer une prise en compte des retours terrain avant le déploiement. Ce travail privilégiant un périmètre limité permet de mettre en évidence les bénéfices réels et les éventuelles difficultés rencontrées. Un bilan est à faire à l’issue du pilote et à partager avec l’ensemble du réseau de votre processus

Par cette démarche, l’ensemble des acteurs ont pris connaissance du processus, ont pu mesurer les bénéfices et éventuelles difficultés grâce au site pilote. Ils sont maintenant prêts à le mettre en œuvre. Une bonne implication des opérationnels les plus concernés dès les premières phases de définition du processus  ainsi qu’un réseau large impliquant d’autres acteurs de la DSI et Métiers facilitera et œuvra à la réussite du projet.

Insistons néanmoins sur le fait qu’une mise en place de processus ne se limite pas à son déploiement. La gouvernance associée au processus et le dispositif d’amélioration continue sont également à définir avec deux rôles clés : le process owner et le process manager. Deux rôles fondamentaux pour asseoir une relation DSI métiers de qualité.

Cet article Les processus : réseauter pour mieux déployer ? est apparu en premier sur RiskInsight.

La plupart des entreprises ont démarré un projet de migration afin de gérer l’obsolescence des composants XP, tant au niveau du système d’exploitation que des outils fournis aux utilisateurs (navigateur internet, suite bureautique, etc.), mais aussi pour améliorer leur attractivité et l’image de leur DSI. Ce type de projet doit également être un levier de réduction du TCO (Total Cost of Ownership) du poste de travail.

Compte tenu des enjeux économiques et de support, il faut noter une forte volonté de réduire au maximum le nombre de postes fonctionnant sous Windows XP d’ici avril 2014. Néanmoins, il peut être envisageable qu’une partie du parc soit maintenue sous cet OS. Selon la quantité de postes restant à migrer après avril 2014, une négociation avec Microsoft peut en effet être envisagée afin de bénéficier d’une extension de support. Mais les risques induits ne sont pas à négliger : risques opérationnels dus à des applications potentiellement non compatibles, risques techniques dus à des pilotes matériels qui ne sont plus pris en charge, risques liés à la sécurité des postes, etc. Il est donc préférable de réduire au maximum le nombre de postes sous Windows XP, afin d’éviter notamment des coûts liés à une double administration d’OS.

Une industrialisation du processus de déploiement au service de la migration

L’industrialisation du processus de déploiement doit permettre d’optimiser au maximum la migration tout en la sécurisant. Pour cela, les choix d’architecture réalisés en amont devront être pensés de façon à minimiser les impacts éventuels sur la migration, tout en assurant la reprise des données. Il est en effet impératif d’assurer la sauvegarde de certaines données utilisateurs. Se baser sur les outils de sauvegarde existants ou sur les outillages de synchronisation de données pourra faciliter la démarche. Certaines entreprises font le choix de laisser la responsabilité à l’utilisateur. Il est alors chargé de récupérer et stocker ses données avant la migration de son poste, puis de les restaurer une fois la migration effectuée.

À moins d’un an de la fin de support XP, la stratégie de déploiement doit désormais être pensée de façon à optimiser les délais et les coûts. Plusieurs types de scénarios peuvent être considérés, d’une gestion manuelle à l’utilisation d’outils et de technologies d’automatisation. La migration « au fil de l’eau », basée sur le renouvellement du matériel, peut être un levier simple à mettre en place. Cette stratégie est généralement complétée par un projet de migration compte tenu des échéances.

Au vu des délais de moins en moins flexibles, il faudra si possible capitaliser au maximum sur les outils de télédistribution déjà implémentés au sein de l’entreprise. Pour les parcs informatiques importants, se baser sur les infrastructures existantes, permettra d’industrialiser le déploiement, tout en faisant baisser le TCO du poste de travail, notamment sur les aspects de gestion courante, comme la remasterisation et le renouvellement du poste.

L’industrialisation du déploiement se base également sur un inventaire détaillé des utilisateurs et des machines, la planification des rendez-vous avec les utilisateurs, le suivi du déploiement via des outils de reporting, le provisioning et la masterisation des postes. Il faudra veiller à définir le type de support apporté aux utilisateurs durant la migration, tout en mettant en place une véritable conduite du changement, à adapter aux profils plus ou moins technophiles, à leur localisation par plaque régionale pour un ajustement à la culture locale, à leur mobilité, à leur statut dans l’entreprise et de façon plus générale à la culture d’entreprise.

Piloter les inventaires, qualifications et remédiations applicatives

La gestion des applications et de leur compatibilité avec le futur système d’exploitation est un autre levier important pour sécuriser le désengagement de Windows XP et son déploiement.

En premier lieu, il est important d’identifier les applications critiques avec un fort impact business. La qualification de ces applications permettra de mettre en évidence et d’anticiper les éventuelles incompatibilités logicielles de façon proactive. Celles-ci devront alors faire l’objet d’une remédiation pour les adapter au système d’exploitation cible. Le déploiement devra être bloqué tant que ces incompatibilités n’auront pas été remédiées. En se basant sur le statut éditeur ou en réalisant des tests fonctionnels, plusieurs méthodes permettent d’évaluer la compatibilité des applications vers l’OS cible. Les applications web par exemple, devront généralement être redéveloppées, de même que les macros Excel et les développements VBA.

La virtualisation d’applications présente alors un intérêt fort en tant que solution de contournement. Cette technologie va permettre de supprimer les adhérences de l’application avec le système d’exploitation, en créant une bulle applicative où elle s’exécutera. Utiliser la virtualisation d’application pour faire de la remédiation reste toutefois un détournement de la solution et n’offre aucune garantie. D’un point de vue fonctionnel, la virtualisation peut effectivement permettre une montée de version de l’application, car indépendante de l’OS. Mais d’un point de vue technique, cela ne doit être envisagé qu’en tant que solution palliative court-terme. La virtualisation d’application, MED-V ou Citrix ne sont en aucun cas des solutions définitives. Pour faciliter l’étape de remédiation, il est ainsi conseillé de mettre à disposition des métiers des processus de remédiation standards, tout en industrialisant et en pilotant les travaux de ce chantier de packaging applicatif.

Idéalement, ces étapes permettront de participer à la rationalisation du portefeuille applicatif en éliminant notamment quelques logiciels non utilisés ou en doublons. La connaissance fine du parc applicatif étant généralement trop faible, il est illusoire de penser pouvoir traiter simultanément déploiement du poste de travail et rationalisation profonde du parc applicatif. Pour les contextes les plus matures, la gestion de portefeuille applicatif est légèrement enrichie et la mise en œuvre d’une solution de self-service est réalisée. Cette stratégie de shift-left visant à apporter un maximum d’autonomie à l’utilisateur sur les activités de gestion du poste à faible valeur-ajoutée, peut constituer un levier important de réduction du TCO des postes.

Il s’agit d’un chantier long et laborieux à anticiper, la meilleure solution étant de définir des processus récurrents, afin de suivre les mises à jour logicielles de façon optimale. Il faudra pour cela veiller à identifier les couches métier impactées et intégrer ces processus avec les plannings de migration, afin de lisser le déploiement selon les Métiers. Mais cela nécessite l’implémentation d’une vraie gouvernance et un bon niveau de maturité sur la gestion applicative et de leurs composants, ainsi que sur la gestion des licences.

Quoiqu’il en soit, lancer un projet de migration suscite bien des remises en question ! Elle permet de réviser les règles de sécurité déjà implémentées pour mieux les adapter au contexte de l’entreprise. Mais c’est aussi par exemple l’occasion d’adapter les services aux nouveaux usages, tout en réduisant le TCO des postes et en favorisant la flexibilité des services fournis aux utilisateurs, via par exemple des outils modernes de self-service du type application store. Un projet riche sur bien des plans donc.

Cet article Obsolescence programmée : comment réussir le passage à un nouvel environnement de travail ? est apparu en premier sur RiskInsight.

Pourquoi et comment adopter le Zero Touch ?

Le choix d’une stratégie de déploiement se fait en premier lieu en fonction du nombre de postes concernés. Un parc informatique composé de quelques dizaines de postes impliquera une action manuelle, là où un parc plus conséquent nécessitera l’automatisation de tout ou partie de ce processus. Les solutions d’automatisation permettent de limiter, voire de supprimer totalement les interactions avec les utilisateurs pendant la phase de déploiement. Cela induit une industrialisation du processus – via une action de nuit sans interaction humaine – et par là-même une réduction des coûts de support.

Mais comment y aller ? En réalité, le choix du déploiement Zero Touch (déploiement automatisé) implique le plus souvent la création d’un « master » (ou socle) unique et modulaire. Ce master doit comporter l’ensemble des composants qui seront distribués et installés sur le poste (OS, pilotes de périphériques, base applicative commune…). Ces éléments peuvent être structurés par couches permettant justement ce découpage modulaire en fonction de variables d’environnements collectées en amont du processus ou lors de la phase de déploiement (le modèle de poste, la langue cible, les usages métiers etc.).

Les avantages du master modulaire

Une stratégie de master unique et modulaire permet de se détacher des contraintes liées à la dépendance matérielle. Le tronc commun des composants peut ainsi être entièrement dissocié des éléments spécifiques au poste.

Sur le long terme, cela permet aussi une forte évolutivité et un meilleur support des modifications du master. Par exemple, l’ajout d’un nouveau modèle supporté nécessite beaucoup moins de d’actions. Il suffit d’intégrer les spécificités matérielles (pilotes de périphériques) au master existant, plutôt que de le recréer dans sa totalité.

Par ailleurs, le packaging applicatif unifié est un autre avantage non négligeable inhérent au choix de master unique. En effet, on utilise la même méthode de packaging pour la conception du master que pour la télédistribution d’une application sur un poste préalablement déployé. Cela permet une rationalisation des éléments constituants le master, et ainsi d’en faciliter l’exploitation, le support et la maîtrise dans le temps.

Le Zero Touch, une source d’économies potentielles

Lorsqu’une entreprise répond aux critères permettant l’emploi d’une stratégie Zero Touch, elle peut envisager, comme nous l’avons vu précédemment, de réaliser des économies significatives sur les phases de déploiement et de post-déploiement :

• La réduction d’interactions humaines en bout de chaîne permet de limiter les coûts unitaires liés au déploiement d’un poste.
• La configuration cible unique sur l’ensemble du parc permet de réduire les risques d’incompatibilité. Cela se traduit par une limitation des coûts d’assistance post-déploiement ainsi que les coûts de maîtrise de parc.
• Sur le long terme, la cellule de gestion du parc peut s’appuyer sur le master modulaire pour réaliser ses actions récurrentes (telles que la montée de version applicatives, télédistribution de nouvelles applications, l’intégration et le support de nouveaux matériels …) et réduire significativement les durées associées.

« Tout le monde ne peut pas faire du Zero Touch ! »

Si le Zero Touch peut sembler la solution miracle, il a pourtant certaines contraintes qu’il parait important de rappeler :

• L’infrastructure requise pour mettre en place ce type de stratégie est conséquente. Seules les grandes entreprises peuvent en réalité l’adopter. L’infrastructure réseau doit notamment pouvoir supporter le transit d’images système lourdes.
• La construction de ce type de master ainsi que la conception de l’infrastructure implique un niveau de compétence élevé. Ce niveau d’expertise est rarement trouvé en interne.
• Le déploiement sans interaction humaine nécessite de récolter les informations relatives aux utilisateurs cibles en amont du déploiement. Ce recueil d’informations représente un travail conséquent. La constitution d’une cartographie organisationnelle de l’entreprise doit permettre de définir les éléments modulaires à déployer ainsi que les variables d’attributions sur une échelle macroscopique.

Windows 8, tremplin vers de nouvelles opportunités ?

Si le déploiement reste sensiblement le même avec Windows 8, la dernière mouture du système d’exploitation de Microsoft n’est pas en reste sur les actions post-déploiement. L’écosystème offre en effet de nouvelles possibilités intéressantes concernant la télédistribution d’applications.

La  télédistribution d’applications peut actuellement se faire par deux biais : le déploiement d’une base applicative lors de l’installation du nouveau système et la télédistribution à l’initiative des équipes IT post-déploiement. L’écosystème Windows 8 vient proposer un troisième vecteur : la télédistribution à l’initiative de l’utilisateur. En effet, Windows 8 propose nativement un « Store applicatif ». Celui-ci peut être rendu inaccessible par la plupart des réseaux d’entreprises mais la DSI peut choisir de proposer par substitution son propre « Store d’entreprise ».

Ce portail permet de distribuer 4 types de ressources logicielles :

• Les applications « Metro » développées en interne et non publiées dans le « Windows Store » classique.
• Les logiciels qui sont distribués sous licence en interne dans l’organisation.
• Les web-applications, lancées directement via le navigateur.
• Des liens vers les applications autorisées du « Windows Store ». Ceci permet d’informer les utilisateurs d’applications utiles autorisées par l’entreprise.

Dans ce contexte, le rôle de la DSI évolue. Elle doit désormais gérer la notion d’approbation pour la gestion des licences ainsi que les droits d’attributions des applications sur l’ensemble de son parc.

Cet article Zero Touch : une migration bénéfique ? est apparu en premier sur RiskInsight.